「コトルカ — ことばの島」は、私たちが開発・試用している英語学習アプリです。 物語の冒険や仲間の育成を楽しみながら、英単語や英文を練習できるようにしています。単語を復習するカードや、お手本の音声を聞く練習、手書き・英作文などを組み合わせたアプリで、その開発中に直面した発音評価の課題が、本記事の出発点です。
コトルカの「まねっこスピーキング」では、お手本を聞いて、まねして話し、自分の録音を聞き直します。そこから一歩進めて、「次にどの音を練習するとよいか」まで伝えるには、録音のどこを根拠に助言すればよいのでしょうか。ここで立ち止まったのが、録音を文字にできることと、発音の質を評価できることは、どこまで同じなのかという問題です。文字起こしが正しい英文になったからといって、その子音・母音・強勢まで確かめられたとは限りません。
現時点でコトルカに合うと考えているのは、音声を扱う専用の評価で根拠を集め、確認できたことだけを短い助言にする構成です。LLMには、観測結果を分かりやすい日本語へ整える役割を持たせられます。ただし、音声対応LLMで直接評価する方法や、音の特徴を文章へ変換して評価する研究にも、それぞれ使いどころがあります。
2026年10月14日時点で、コトルカのAzure Pronunciation Assessment接続機能は既定で無効、実APIは未接続・未検証です。本記事では開発コード、模擬応答による33件のテスト、公式資料と研究論文を照合しました。学習者の実録音を使った各方式の精度比較や、発音改善の効果測定をした記事ではありません。
「発音がよい」を、一つの点数にまとめる前に
まず、何を評価したいのかを分けます。読み上げ課題の「指定された語を言えたか」、音の区別、話の滑らかさは、それぞれ別の問いです。学習者にとっては、低い点数を見せられることより、次にどこを聞き直せばよいかが分かることに価値があります。
| 評価したいもの | 確かめたい問い | 混同したくないこと |
|---|---|---|
| 内容・読み上げの達成 | 指定した語句を話したか | 正しい文字列に認識されたことだけで、音まで正しいとは言えない |
| 子音・母音の正確さ | たとえばshipとsheepの音の区別があるか | 綴りをIPAへ変換しただけでは、実際の声を測ったことにならない |
| 流暢さ・韻律 | 不自然な途切れ、強勢、リズム、抑揚はどうか | 一語だけの録音から、会話全体の流暢さは評価しない |
| 通じやすさ | 聞き手に語や意味が伝わるか | 目標アクセントに似ている程度と、理解できるかは同じではない |
| 録音品質 | 音割れ・極端な小音量・重なりはないか | 録音不良を、発音能力の低さとして扱わない |
なまりの強さ、聞き取れた内容、理解にかかる負担を分ける考え方には、MunroとDerwingの原著研究があります。目標を「米語のこの音を練習する」と定めることと、目標から外れた話し方を一律に「通じない」と判定することは分けて考えたいところです。
六つの方法を比較する：LLMが受け取る根拠が違う
以下は、開発で選べる構成や導入方法の比較です。互いに完全に独立した分類ではなく、たとえば専用APIの結果をLLMへ渡す組み合わせもできます。音声から測る部分と、結果を説明する部分に着目すると選びやすくなります。
| 方法 | 入力と得意な役割 | 主な弱点・導入の負担 |
|---|---|---|
| ① 文字起こし＋テキストLLM | 認識文から内容・文法・課題達成を確認 | 音の細部は失われる。文字だけから個別の発音点を作れない |
| ② 音素・GOP＋専用評価モデル | 音声から音素ごとの適合度や発話全体の特徴を調べる | 辞書・音響モデル・採点基準の準備と校正が必要 |
| ③ 専用の発音評価API | 音声と課題文を送り、音素・語などの結果を得る | クラウド送信・費用・言語別機能・対象利用者での検証が必要 |
| ④ 音声対応LLMへ直接依頼 | 音声と評価基準を一緒に渡す | 音声対応だけで採点の妥当性は保証されない。甘い採点や説明の誤りを点検 |
| ⑤ 評価用に追加学習した音声LLM | 人が評価した音声と点数で目的に合わせる | 教師データ、計算資源、独立した評価データが必要 |
| ⑥ 音声特徴を文章化＋テキストLLM | 音素列や休止などを実音声から抽出して渡す | 特徴抽出器の誤りを引き継ぐ。普通の文字起こしだけとは異なる |
① 文字起こし＋LLM：何を言ったかを確かめる
ASR（自動音声認識）で録音を文字へ変換し、その文をLLMへ渡す構成です。指定した話題に答えたか、英文の内容が通るか、表現をどう直すかには使えます。コトルカの既存AIコーチも、文字起こしを扱う経路では発音・アクセント・流暢さを採点しない設計にしています。
たとえば、二つの異なる録音がどちらも「ship」と文字起こしされた場面を考えます。これは説明用の仮定です。テキストLLMが受け取る文字が同じなら、その情報だけから二つの母音の違いを取り戻すことはできません。反対に、別の単語へ認識された場合も、発音、雑音、マイク、認識器のどれが原因かは、その文字列だけでは決まりません。
WER（単語誤り率）は、正しい文字起こしに対する認識結果の誤りを測る指標です。「1−WER」を発音の正しさの点数に置き換えないことが大切です。発音評価のレビュー論文も、音素と韻律を含む複数の評価手法を整理しています。文字の一致は、発音評価のすべてではありません。
② 音素・GOP：音のどこを調べたかを残す
音素は、意味の違いにつながる子音・母音の単位です。GOP（Goodness of Pronunciation）は、対象の音の区間が、期待した音素にどれくらい適合するかを音響モデルの確率などから測る方法の総称です。実装によって計算方法は異なり、その値がそのまま「正しく話せた確率」になるわけではありません。
よく使われる前処理に、音声と既知の文を対応付け、各語や音素の時間区間を求める「強制アラインメント」があります。ただし、対応付けの成功と採点の成功は別です。Montreal Forced Alignerの公式英語モデルカードは、多様な発音を許容して位置合わせするモデルであり、発音の良否を正確に評価する用途には使えないと明記しています。
位置合わせの誤りや、音の挿入・脱落の扱いを改善する研究もあります。CTCを使う音素単位の評価研究は、その一例です。「単語のタイムスタンプが取れたから採点も完成」とせず、評価用の仕組みを別に確かめる必要があります。
GOPTは、GOPの特徴をTransformerに入力して、音素・語・発話の複数の粒度で評価する研究です。Transformerを使っていても、自由な文章を返す汎用チャットLLMとは役割が異なります。どの音が疑わしいかという情報を、説明用LLMへ渡す構成の候補になります。
③ 専用API：アプリへ組み込みやすいが、点数の意味は検証する
Azure Pronunciation Assessmentは、課題文がある読み上げ練習を扱えます。Accuracy、Fluency、Completenessなどを分けて受け取り、機能によって音素単位の結果も使います。コトルカではこの専用経路の接続を準備していますが、採点の実測はまだです。公式の設定・結果の説明を起点に、必要な粒度を選ぶ方式です。
2026年10月14日に確認した同資料では、IPAの音素名などの詳細機能と韻律評価にはen-USの条件があります。サービス全体の対応言語数と、欲しい機能の対応言語は同じではありません。また、日本人が英語を練習する場合は、学習対象の英語に合わせた言語設定を使います。ja-JPは日本語の発音を評価する指定で、日本語による助言の表示とは別です。対応言語一覧も併せて確認してください。
費用はAPIの音声処理分に加え、使う追加機能にも左右されます。Azureの公式説明では、基本の発音評価は標準の音声認識に準じる料金で、韻律評価は追加課金です。正確な額は契約・リージョン等の条件と料金の説明を確認します。助言用に別のLLMを呼べば、その費用も加わります。
専用APIでも、利用者や録音環境が変われば結果は変わります。Microsoftの制約資料は、対象場面の実データによる評価と、子ども・成人などの用途に応じた閾値の調整を勧めています。点数が0〜100で返ることと、80点なら学習目標を達成したと言えることは別です。
④ 音声対応LLM：直接聞かせても、評価者としての検証が要る
音声を受け取れるLLMへ、録音と「音の正確さ」「間」「強勢」などの基準を一緒に渡す方法です。文字起こしだけを使う構成より多くの音声情報を入力でき、文脈を含む説明を得られる可能性があります。しかし、音声を入力できること自体が、細かな発音を公平に採点できる証拠にはなりません。
Qwen2-Audio-7B-Instructを調べたSLaTE 2025の研究では、Speechocean762の5,000発話を、追加学習せず基準を指示する条件で評価しました。低品質の発話にも高めの点を付ける傾向などが報告されています。これは特定のモデル・指示・データでの結果であり、音声LLM全般の性能を決めるものではありません。
対象データの学習者は中国語母語話者です。そこでの成績を、日本語母語話者の英語や、コトルカの利用者へそのまま当てはめることもできません。音声LLMを試す場合は、気持ちのよい説明が出るかだけでなく、同じ音声の再評価で結果が揺れないか、実際にない誤りを指摘していないかを確認します。
⑤ 専用に追加学習する：汎用モデルへの指示とは別の工程
人が採点した学習者の音声を用意し、音声LLMを発音評価へ適応させる方法もあります。2025年のQwen2-Audioを調整したプレプリントは、単語・文レベルの評価と、より難しい音素レベルの評価を扱っています。これは、汎用モデルに「発音の先生になって」と指示するだけの方法とは異なります。
製品として進めるなら、どの音をどう評価したラベルなのか、学習に入っていない話者でも合うかを確かめる必要があります。追加学習用データと評価用データを話者ごとに分け、対象の母語・年齢・端末が変わった条件も調べます。少人数向けアプリの初期段階では、データ整備と検証にかかる負担が大きい選択肢です。
⑥ 音声特徴を文章化する：テキストLLMに「測った音」を渡す
TextPA／Read to Hear（EMNLP 2025）は、実音声から抽出した音素列や休止などを、人が読める形にしてLLMへ渡す研究です。普通の文字起こしに発音記号を足すだけではありません。音声から得た特徴があるから、テキストLLMにも発音を考える手がかりが届きます。
この方法なら、何の観測をLLMへ渡したかを追いやすく、音響処理と説明を別々に改善できます。一方で、特徴抽出器が間違えばその誤りを引き継ぎます。論文は韻律の表現や説明の誤りなどの限界も挙げています。テキスト化した情報だけで、声のすべてを表せるわけではありません。
実装の際は「文字から作った理想の音素列」と「録音から推定した音素列」を別の項目にします。この区別がないと、正解の発音記号をLLMに見せて、その録音が正しかったかのように説明させる取り違えが起きます。
コトルカで決めたこと：高い数値が返っても、そのまま褒めない
実装では、まず録音形式・長さ・信号不足・音割れを確認します。次に、返された結果が練習中の課題へ対応しているか、単語や音素の情報が欠けていないかを検査します。判定できない場合には、低い発音点ではなく「確認できなかった」という結果を返します。入力検査は、音声評価へ進めるかを見るためのもので、発音の良否を判定するものではありません。
| 人工のテスト入力 | 期待する処理 | 守りたいこと |
|---|---|---|
| 課題はsee /siː/。応答はseeの音素として/k/だけを返し、点数は99 | 判定不能にして助言を作らない | 高得点というだけで、対象外の音を褒めない |
| 課題と別の単語の結果、または一部の音素しかない | 根拠不足として保留 | 別課題や部分的な結果を、現在の録音の評価にしない |
| 無音や極端な音割れを含む模擬WAV | 入力段階で評価を保留 | 録音不良を発音の下手さに置き換えない |
2026年10月14日、発音関連の既存テスト3ファイルを実行し、33件がすべて成功しました。サーバーのAPI応答は模擬し、実APIへの通信を使わず確認した結果です。これは「不適切な入力や応答を受け取ったときに処理を止められるか」の検査であり、発音モデルの精度が高いことの証明ではありません。
さらに、音素ラベルが課題と一致することも、正しい発音の証明にはなりません。課題文に対応する音素名を返す方式では、ラベルの整合と音響スコアの妥当性は別だからです。今の検査は保守的な試作で、許容できる別の発音まで保留にする可能性があります。実録音による校正が必要です。
現在の助言はLLM生成ではなく、固定ルールで「よい点」「次の聞き比べ箇所」を各最大一つに絞っています。音ごとの助言は単語が対象で、短文は一般的な聞き比べ案内に限っています。数値スコアはそのまま画面へ出さず、習得・ごほうび・復習間隔へも反映しません。低い音素スコアだけから「舌の位置が違う」と原因を断定することも避けています。
LLMを足すなら、音を測る処理の後に置く
コトルカで次に検討したいのは、専用評価の検証が進んだ後で、根拠のある結果を日本語の練習提案へ変える使い方です。以下は設計案であり、実装済みのLLM発音コーチの説明ではありません。
専用APIの生の応答を、そのまま丸ごとLLMへ流す必要はありません。対象の語・音、観測結果、保留理由、出してよい助言の範囲を整理して渡します。時間区間を確実に得られないときは、秒数を作らず、単語全体を聞き比べる案内にとどめます。
あなたは発音評価結果を学習者に説明する補助役です。新しい音声採点はしません。
入力には、対象課題、評価器の名前と版、確認済みの観測、確認できなかった点、許可された練習の説明を渡します。
・判定保留なら、よい／悪いの評価や点数を作らず、保留理由と次の確認方法だけを述べる。
・音素や時間区間は、入力に明示されているものだけを使う。
・文字起こしの一致から、発音が正しいと結論しない。
・日本語母語話者にありがちな誤りを、この録音の事実として補わない。
・音素スコアから舌や唇の動きを断定しない。
・出力は「確認できたこと」と「次に一つ試すこと」。それぞれ根拠となる入力項目を添える。
・許可された練習の説明にない矯正方法を新しく作らない。この指示文だけで誤った説明がなくなる保証はありません。出力に含まれる語・音素・区間を元の根拠と照合し、外れたら固定の案内へ戻す処理も必要です。短い助言で足りる段階なら、コトルカの現行実装のように固定文を使うほうが、挙動を確認しやすい場合があります。
ローカルLLMだけで完結させられるか
構成としては、ローカルの音声処理と評価モデル、ローカルの説明用LLMを組み合わせられます。ただし、テキスト用LLMをMacへ入れるだけでは、音声の観測機能は増えません。必要なのは、音の特徴を抽出・評価する前段まで含めた仕組みです。
| ローカルで使う候補 | 役割 | 今回確認できた範囲 |
|---|---|---|
| Montreal Forced Aligner | 語・音素の位置合わせ | 公式の用途と制約を確認。発音採点器としては扱わない |
| GOPTなどの研究実装 | GOP特徴から複数粒度の評価 | 著者のコードは公開されているが、自前音声への組み込みは別工程 |
| Qwen2-Audio系の音声対応モデル | 音声とテキスト指示の処理 | 音声対応の代表例として紹介。このMacでの採点実測はしていない |
| テキスト用ローカルLLM | 検証済みの根拠から助言を整える | 音声の前処理・評価は別に必要。モデル単体で発音点を保証しない |
GOPTの公式実装には、自分の音声を使う推論手順の報告済み不具合への注意書きがあります。Qwen2-Audioの公式実装も、依存ライブラリやモデルの準備が必要です。ここで紹介した研究用構成を、ワンクリックで動く採点アプリや、このMacで検証済みの構成として紹介することはできません。
ローカル化で音声の外部送信を減らすには、ASR・特徴抽出・採点・助言の全経路を確認します。最後の説明だけをローカルLLMにしても、前段がクラウドAPIなら録音は外部へ送られます。また、APIの従量費用がなくても、モデル取得、メモリ、計算時間、保守の負担は残ります。
なお、UTMOSv2のような音声の品質評価も別の選択肢ですが、聞き心地などの評定を予測することと、学習者が特定の母音を区別できたかを診断することは目的が異なります。TTSの自然さを測る指標を、そのまま学習者の発音点へ転用しないようにします。
最初の実録音検証で、何を確かめるか
コトルカで次に必要なのは、モデルの名前を増やすことより、実際の利用条件で評価を確かめることです。以下はこれから行う検証の案です。小さな試用で全利用者の精度を証明することはできませんが、どの条件で指摘を控えるべきかを見つける助けになります。
- 1課題を固定する。単語の音の区別、短文の間・強勢、自由会話を混ぜず、まず読み上げ課題から始める。許容する発音変種も決める。
- 2録音条件を記録する。マイク、距離、雑音、音量を変えたときの差を調べる。端末ごとの違いを学習者の上達と取り違えない。
- 3人の評価と照合する。同じ基準を使う複数の評価者に確認してもらい、評価者の意見が割れる音声も別に残す。
- 4誤った指摘を数える。問題のない発音へ直すよう勧めた割合、見逃し、判定保留率を分けて見る。保留ばかりで使えない構成にも注意する。
- 5点数と説明を別に検査する。点が人の評価に近くても、理由や練習方法が音声の根拠と合うかを点検する。同じ録音を再評価したときの揺れも見る。
- 6調整に使わなかった話者で確認する。母語・年齢・端末などの範囲を記録し、未確認の条件へ結果を広げない。
「相関が高い」だけでも十分ではありません。全員の点数へ同じ値を上乗せしても、順位や相関は変わらないことがあります。細かな誤りの指摘が正しいとも限りません。人の評定との点差、誤指摘、保留、説明の根拠を併せて見ることで、学習支援としての判断がしやすくなります。
録音を集める場合は、対象者に利用目的を説明し、保存期間と削除方法を決めます。少なくとも、開発検証のための録音を、無断で公開記事や別目的の学習データに転用する運用にはしません。この記事にも個人の録音や学習記録は掲載していません。
最初に作りたいのは「採点する先生」より、根拠のある練習相手
コトルカでは、録音して聞き比べる体験を先に成立させ、発音評価は任意の検証機能として扱っています。次の段階では、実録音で専用評価の得意・不得意を確かめ、確かめられた一か所だけを練習へつなげる。その説明にLLMが役立つなら加える、という順番が妥当だと考えています。
導入しやすさを重視するなら専用API、評価器の中身やローカル運用を重視するなら音素・GOP系、研究開発として柔軟な判断を試すなら音声LLMやTextPA型が候補です。どれを選んでも、入力した音声にない根拠を説明へ足さないことと、判定できない結果を学習者の失敗にしないことが、設計の中心になります。
音声認識と後段のLLMを分けて考える点は、Foresightで日本語の会議音声を試した記事にも通じます。モデルの機能表を確認するだけでなく、自分たちの言語・声・端末で、何ができて何が確認できなかったかを残すことが大切です。仕様・研究資料と開発状態の確認日は2026年10月14日です。