1.7B の小型 LLM に英語スピーキング練習のコーチをさせようとして失敗した
はじめに
こんにちは、クラスメソッドオペレーションズの watabo です。
今回は普段の業務から外れて、ラズパイとローカルLLMで「やってみた」記事の投稿です。
環境
| 項目 | 詳細 |
|---|---|
| ハードウェア | Raspberry Pi 5 / 8GB RAM |
| OS | Raspberry Pi OS (bookworm, aarch64) |
| LLM 実行環境 | Ollama（CPU 推論、num_gpu: 0） |
| モデル | Qwen3:1.7b（Q4_K_M, 1.4GB）/ gemma3:1b（Q4_K_M, 815MB） |
やろうとしたこと
Raspberry Pi 5 上で完全オフライン動作する英語のスピーキングドリルを作っています。AI がお手本フレーズを読み上げ、ユーザーが復唱し、音声認識の結果をもとにフィードバックを返す流れです。
例えばこんな感じのものを想定していました。
（テーマを少し技術英語寄りに設定しているので、そのコンテキストが含まれています。）
AI: "This solution leverages serverless architecture."
ユーザー: "This solution leverages severless architecture."
AI: 「serverless」の発音に注意しましょう。「サーバーレス」です。
このフィードバック生成に 「ローカルLLM」 を使っています。
ローカル LLM とは
ローカル LLM とは、ChatGPT のようなクラウド API を使わず、手元のデバイス上で直接動かす生成 AI のことです。
近年はモデルの軽量化が進み、パラメータ数 10 億〜20 億（1B〜2B）クラスのモデルであれば、Raspberry Pi のような小型コンピュータの CPU だけでも実用的な速度で推論できるようになりました。
今回は Ollama という LLM 実行ツールを使い、Qwen3:1.7b（17 億パラメータ）を Pi 5 の CPU で動かしています。このモデルにフィードバックの生成を任せたところ、日本語でも英語でもそのままでは使えないレベルでした。
Qwen3 は多言語モデルであり、日本語の応答も可能です。
ちなみに Qwen3 の関連記事については、こちらもご参照ください。
※ 今回は記事で登場する LLM-8850 は使用しておりません。
やってみた
最初は「日本語のフィードバックこそ LLM の出番だろう」と考えました。
どこが誤っていたかを具体的に指摘する日本語 1 文を返してほしい。
システムプロンプトとあわせて、以下のような few-shot 例（お手本の入出力ペア）をプロンプトに含めました。
システムプロンプト:
あなたは英語発音コーチです。必ず日本語1文のみで返答してください。
差分情報を元に具体的なフィードバックをしてください。
few-shot 例（5組、抜粋）:
入力: ターゲット: This is a deep dive.
発話: This is deep dive.
差分: 欠落=[a]
出力: 「a」が抜けていますが、全体的に良い発音です。
入力: ターゲット: We use AWS for our infrastructure.
発話: We use AWS for our architecture.
差分: 変化=[infrastructure→architecture]
出力: 「infrastructure」が「architecture」になっています、正しく発音しましょう。
日本語フィードバックが壊滅した
流石に丸投げではうまくいかないことはわかっていたので、差分情報はルールベースで事前計算したものを渡しています。
LLM の仕事は「差分を自然な日本語で説明する」ことだけです。
これならいけるだろうと思ったのですが、結果はこうなりました。
ターゲット: What challenges are you facing with your current setup?
ユーザー: What challenges are you facing at current your setup?
# 差分: 変化=[with→at], 語順違い=[your, current]
AI: 「any」が「anyway」に発音されています
このケースで期待されるフィードバックは、
「with」が「at」になっていて、「your current」の語順が入れ替わっています。 といったところでしょう。
実際のレスポンスは上記の通りでした。
入力のどこにも "any" も "anyway" も存在しません。差分情報を渡しているにもかかわらず、LLM が差分計算を試みて、完全に架空の単語を捏造してしまいました。
これは極端な例ですが、このようなハルシネーション（入力に存在しない単語の捏造）や、差分の取り違え（語順の入れ替わりを「欠落」と誤診するなど）が頻発しました。few-shot 例を増やしても改善しません。
1.7B のモデルにとって、2つの英文を比較して差分を正しく特定するタスクは荷が重すぎたようです。
別のアプローチとしてカタカナ読みを添えるフィードバックも試しましたが、「serverless」→「セット」のようにデタラメな読みが返ってくるばかりでした。
満点の発話に対しては別の問題もありました。プロンプトに「日本語で返答してください」と書いているのに、次のように満点時に英語で返答するパターンが頻出しました。
入力: Lambda scales automatically. (完全一致、満点)
# 期待: 完璧です！その調子で次のフレーズに挑戦しましょう。
出力: Great job! Your pronunciation is perfect.
小型モデルでは言語指定の遵守が難しいケースがあるようです。
英語ではどうか？
ここまでの失敗を受けて、同じ差分情報を渡して英語のフィードバックを生成させてみました。モデルも追加で Google の gemma3:1b（10 億パラメータ）を試しています。Qwen3 とは異なるアーキテクチャの小型モデルで、こちらも Ollama で CPU 推論できます。
日本語よりは安定しましたが、別の問題が出ました。以下のようなテストケースで検証しています。
| テスト | ターゲット | ユーザー発話 | 差分 |
|---|---|---|---|
| article_missing | "This is a deep dive session." | "This is deep dive session." | 欠落=[a] |
| extra_word | "We use AWS for our infrastructure." | "We use the AWS for our infrastructure." | 余分=[the] |
| perfect | "Nice to meet you." | "Nice to meet you." | なし |
6 テストケース x 2 モデル で検証した結果です（代表的な 3 件を掲載）。
いくつかプロンプトも試してみましたが、最終的には正答率は上昇しませんでした。
| 方式 | 正答率 | 代表的な致命的誤り |
|---|---|---|
| gemma3:1b | 1/6 | 間違いを "Great job!" と褒める (4 件) |
| qwen3:1.7b | 4/6 | 余分な語を「追加しろ」と逆の指示 |
gemma3:1b は差分があっても "Great job!" と褒めてしまい、qwen3:1.7b は余分な単語を「足りないから追加しろ」と逆方向の指摘をします。
具体的にはこんな出力です。
テスト: extra_word（"the" が余分）
ターゲット: We use AWS for our infrastructure.
ユーザー: We use the AWS for our infrastructure.
gemma3:1b: "Focus on the 'e' sound in 'AWS'"
# 余分な "the" に触れず、的外れな指摘をしてしまう
qwen3:1.7b: "Don't forget 'the' — watch 'the' — you said 'the'."
# "the" は余分なのに「忘れるな」と追加を指示。逆。
どちらも発音ドリルとしては致命的です。
テンプレートに統一した
結局、英語・日本語ともにルールベースのテンプレートで生成する方式に落ち着きました。差分の種類ごとにバリエーションを用意し、入力テキストのハッシュで決定的に選択します。
# changed（単語が変わった）: 6パターン
"「{target}」が「{spoken}」になっています。もう一度挑戦しましょう！"
"惜しい！「{target}」を「{spoken}」と発音しています。"
# missing（単語が欠落）: 6パターン
"「{word}」が抜けています。意識して入れてみましょう！"
# perfect（完璧）: 7パターン
"完璧です！その調子で次のフレーズに挑戦しましょう。"
"バッチリです！自信を持って次にいきましょう！"
テンプレートは差分情報から決定論的に生成するので、方向を間違えることがありません。速度も 1ms 以下で、LLM の 2〜4 秒と比べると圧倒的です。
まとめ
現段階の小型 LLM では、2つの文を比較して差分を正しく特定するタスクや、日本語を含む単語を生成するタスク（英単語をカタカナに変換するなど）は安定しません。
英語でも「間違いを褒める」「指摘の方向が逆」といった致命的な誤りが残ります。
テンプレートで済む仕事はテンプレートに任せ、LLM には LLM にしかできないこと（自由な会話の生成など）だけを頼むのが、エッジ環境での現実的な設計だと感じました。
