AI英会話で返ってくる「そこは過去形ですね」という一言は、どこで生まれているのか。
訂正フィードバックは、AIが自動的に持っている機能ではない。
誰かが指示文を書き、誰かが採点の項目を選び、誰かが出力の形式を決めた結果として出てくる。
しかもその材料になっているテキストは、あなたが実際に発した音そのものではない。
途中で整形（フォーマット）という工程が入っているからだ。
だから同じ間違いをしても、サービスによって指摘されたりされなかったりする。
この記事では、AIの部品を売っている会社の開発者向け公式ドキュメントの記述だけを使って、訂正フィードバックがどの層でどう組み立てられているのかを分解する。
サービスの順位づけはしない。設計の話だけをする。
【結論】訂正フィードバックは「採点」と「指示文」の2層でできている
先に答えを置く。
AI英会話の訂正フィードバックは、性質のまったく違う2つの層からできている。
| 層 | 何が訂正されるか | 誰が形を決めているか |
|---|---|---|
| ①発音の採点 | 音のずれ・抜け・余分・区切り・抑揚 | 音声サービス側の仕様。項目名が公式に固定されている |
| ②言語モデルの返事 | 文法・語彙・言い回し・話題の適合 | サービスを作る側が書いた指示文。固定された項目名は無い |
①は、返ってくる値の名前が公式ドキュメントに列挙されている。何が出るかが事前に分かる。
②は、指示文しだいで内容も口調も出力形式も変わる。
⇒ 訂正フィードバックのばらつきは、ほぼ全部②から来ている。
そしてもう1つ、両方の手前に「テキストを整える層」がある。ここが見落とされやすい。
訂正フィードバックの材料は、届く前に整えられている
訂正の対象になるテキストは、あなたの発話の生写しではない。
Microsoftの 音声テキスト変換での表示テキストの書式設定 には、文字起こしに自動で適用される整形機能が4つ書かれている。
- 逆テキスト正規化（ITN）＝話し言葉を記号の書き方に直す。公式は「『よん』という音声は、『4』という記述形式に変換されます」と書き、これは構成できませんと明記している。
- 大文字化＝文頭や固有名詞を自動で大文字にする。
my name is jennifer smith→My name is Jennifer Smith. - 不要な言葉の除去＝口ごもり・単語の重複・つなぎ言葉を落とす。
its its not that big of uhm a deal→It's not that big of a deal. - 句読点＝自動で句読点を付ける。
how are you→How are you?
ここで起きていることは、すでに一種の訂正だ。
ただしこの訂正は、あなたに報告されない。黙って直されて次の層へ渡る。
⇒ 大文字・句読点・言いよどみについて訂正フィードバックが返ってこないのは、腕が良いからではなく手前で消えているからという場合がある。
なお同じページには、結果の LexicalForm と NormalizedForm には不適切表現フィルターが適用されない、という区別も書かれている。生に近い形と整形後の形が別々に存在する、ということだ。
訂正フィードバックの第1層｜発音の誤りは型が仕様で決まっている
発音側の訂正は、返ってくる誤りの種類が公式に列挙されている。
Microsoftの 発音評価の使用方法 には、ErrorType として取りうる値が書かれている。
ErrorType の値 | 公式の説明に沿った意味 |
|---|---|
None | この単語にエラーが無い |
Omission | 単語が省略された |
Insertion | 単語が挿入された |
Mispronunciation | 単語が不適切に発音された |
UnexpectedBreak | 区切りが不適切に挿入された |
MissingBreak | 句読点のところで中断が無い |
Monotone | 発話が単調（上昇・下降・フラット） |
公式はさらに「単語の発音 Mispronunciation が 60 未満の場合は、エラーの種類を AccuracyScore できます」と書いており、スコアと誤り種別が連動していることも示している。
⇒ この7種類の外側にある指摘は、発音採点の層からは出てこない。
たとえば「もっと感情を込めて」という助言は、この列挙のどこにも対応していない。出てきたとしたら、それは第2層の言語モデルが書いた文だ。
訂正フィードバックの第1層が沈黙する条件｜参照テキストと miscue
発音の訂正が細かく出るかどうかは、設定2つでほぼ決まる。
1つ目が ReferenceText だ。
公式は「ReferenceText パラメーターは省略可能です。読み取り言語学習シナリオのスクリプト化された評価を実行する場合は、参照テキストを設定します。スクリプトなしの評価を実行する場合は、参照テキストを設定しないでください」と書いている。
2つ目が EnableMiscue だ。
公式の説明はこうだ。「発音された単語が参照テキストと比較されるときに、誤りの計算を可能にします。この値が True の場合、ErrorType 結果の値を比較に基づいて Omission または Insertion に設定できます」。そして既定値は False と明記されている。
| 設定 | 既定 | 訂正フィードバックへの影響 |
|---|---|---|
ReferenceText | 省略可能 | 無い場合はスクリプトなしの評価になる |
EnableMiscue | False | 既定のままだと Omission / Insertion が付かない |
Granularity | Phoneme | 音素・音節・単語・全文のどこまで返すかが変わる |
GradingSystem | FivePoint | 0〜5か0〜100かという点数の見え方が変わる |
さらに公式は、プロソディ評価について「プロソディ評価は、en-US ロケールでのみ利用可能です」と注記している。
⇒ 抑揚やリズムの訂正フィードバックは、英語一般ではなく en-US という1ロケールの機能だ。
同じ注記には、スクリプトなしの評価では使われる音声テキスト変換モデルが異なるとも書かれている。自由会話と読み上げでは、そもそも測り方が違う。
訂正フィードバックの第2層｜文法と語彙の指摘は指示文で作られている
ここが、この記事でいちばん伝えたい部分だ。
文法・語彙の訂正フィードバックは、専用エンジンではなくチャットモデルへの指示文で作られている。
それを公式ドキュメントが実例つきで示している。発音評価の使用方法 の「コンテンツ評価」には、チャットモデルに渡すメッセージの実物が載っている。
システムメッセージはこうだ。
You are an English teacher and please help to grade a student's essay from vocabulary and grammar and topic relevance on how well the essay aligns with the title, and output format as: {"vocabulary": *.*(0-100), "grammar": *.*(0-100), "topic": *.*(0-100)}.
「あなたは英語の先生です」から始まる、ただの文章だ。
採点の基準は、この1文の中にしか存在しない。
ユーザーメッセージ側には、さらに具体的な手順が書かれている。公式の原文から、処理の順序を抜き出すとこうなる。
please first add punctuations when needed＝必要に応じてまず句読点を足す。remove duplicates and unnecessary un uh from oral speech＝話し言葉の重複と不要なunuhを取り除く。then find all the misuse of words and grammar errors in this essay＝そのうえで語の誤用と文法の誤りを全部見つける。find advanced words and grammar usages＝高度な語彙や文法の使用も見つける。and finally give scores based on this information＝最後にこの情報をもとに点を付ける。
同じユーザーメッセージには、採点ずみの例文を3つ並べる書き方（Example1〜Example3）も含まれている。
⇒ 訂正フィードバックの正体は、指示文と例文である。
なお公式は、このコンテンツ評価（プレビュー）が Speech SDK バージョン 1.46.0 以降から廃止され、代わりに Azure OpenAI のチャットモデルを使う方法を案内している。専用機能から汎用のモデル＋指示文へ移った、という流れがそのまま書かれている。
訂正フィードバックの指示文はどう組まれるか｜公式が示す4ブロック
指示文の書き方そのものも、公式ガイドに型がある。
OpenAIの Prompt engineering ガイド は、開発者メッセージに置くべきセクションを順番つきで挙げている。
| ブロック | 公式の説明 | 訂正フィードバックでの中身の例 |
|---|---|---|
| Identity | アシスタントの目的・話し方・高いレベルの目標 | 英語学習者の発話を直す教師役であること |
| Instructions | 何をすべきで、何を絶対にしてはいけないか | 何個まで指摘するか／直した文を必ず添えるか |
| Examples | 入力と、望ましい出力の例 | 誤った英文と、理想的な訂正の返し方 |
| Context | モデルが必要とする追加情報 | 学習者のレベル・今日の話題・過去の指摘 |
公式は Context について This content is usually best positioned near the end of your prompt と書いている。
また instructions パラメーターについては Any instructions provided this way will take priority over a prompt in the input parameter と明記されている。
⇒ 訂正の厳しさ・指摘の数・口調は、この4ブロックのどこかに書かれた文で決まっている。
逆に言えば、どのブロックにも書かれていない観点は、訂正フィードバックとして安定して返ってこない。
訂正フィードバックの安定度を上げる手｜例を数個見せる
指示だけでは形が揺れる。だから公式は例を置けと書いている。
OpenAIの Prompt engineering ガイド は Few-shot learning をこう説明している。
Few-shot learning lets you steer a large language model toward a new task by including a handful of input/output examples in the prompt, rather than fine-tuning the model.
さらに When providing examples, try to show a diverse range of possible inputs with the desired outputs. とも書かれている。多様な入力例を見せろ、という指示だ。
先ほどのMicrosoftのコンテンツ評価の例が、まさにこの形になっている。採点ずみの例文を3つ並べてから本番の1文を渡している。
- 例が0個＝訂正の粒度も形式もモデル任せになる。
- 例が数個＝出力の形（何を挙げ、どう直すか）が揃いやすくなる。
- 例が偏っている＝その偏りごと訂正フィードバックに乗る。
⇒ 訂正フィードバックが毎回違う形で返ってくるサービスは、例が置かれていない可能性がある。
これは品質の良し悪しではなく、設計の粒度の違いだ。
訂正フィードバックと会話を両立させる構造｜どこに差し込むか
会話の途中で直すか、終わってからまとめて直すかは、アーキテクチャの選択と直結している。
OpenAIの Voice agents ガイド は、音声エージェントの構成を3つに整理している。
| 構成 | 公式が挙げる向いている用途 |
|---|---|
| GPT-Live | Full-duplex conversations with a separate backend（別のバックエンドを持つ全二重の会話） |
| Realtime API | Speech, reasoning, and tool use in one session（音声・推論・ツール利用を1セッションで） |
| Chained voice pipeline | Control over each speech and text stage（音声とテキストの各段を制御する） |
このうち chained（連鎖）型について、公式はこう書いている。
Use the chained path when you want to inspect or transform text between speech recognition, your agent, and speech generation.
音声認識とエージェントと音声合成のあいだで、テキストを検査したり変換したりしたいときに使うという説明だ。
⇒ 訂正フィードバックのように「一度テキストを見て、そこに手を入れる」処理は、この連鎖型に素直に乗る。
公式はさらに you might store the transcript, run policy checks before the text agent responds と書いており、返事の前に検査を挟む使い方を具体的に挙げている。
一方で全二重の会話を担う側については、Prompting GPT-Live に Keep detailed procedures in the backend prompt（詳細な手順はバックエンドの指示文に置く）と書かれている。しゃべる層と、細かく判断する層を分けろ、という設計思想だ。
訂正フィードバックが毎回変わる理由｜出力は非決定的だと公式が書いている
同じ間違いをしても指摘されたりされなかったりするのは、気のせいではない。
OpenAIの Prompt engineering ガイド は、はっきりこう書いている。
Because the content generated from a model is non-deterministic, prompting to get your desired output is a mix of art and science.
モデルの生成内容は非決定的であると、公式ドキュメント自身が前提として置いている。
同じページは、この揺れに対する実務上の対処も2つ挙げている。
- 本番アプリを特定のモデルスナップショットに固定する（
Pinning your production applications to specific model snapshots）。 - 指示文の挙動を測るテストと評価の仕組みを作る（
Building tests and evaluation suites that measure prompt behavior）。
さらに、モデルの性格の違いについても説明がある。公式は推論モデルを like a senior co-worker、GPTモデルを like a junior coworker. They'll perform best with explicit instructions と表現している。
⇒ 同じサービスでも、裏のモデルが変われば訂正フィードバックの粒度は変わりうる。
利用者から見ると「今日は厳しい」「今日は甘い」になるが、仕組みの側では設定と非決定性の合成結果でしかない。
訂正フィードバックを受け取る側が押さえておくこと
仕組みが分かると、どの指摘をどれだけ信じるかの線が引ける。
- 大文字・句読点・言いよどみの指摘が無いのは、直っている証拠にならない。整形の層で先に消えている可能性がある（表示テキストの書式設定）。
- 音のずれの指摘は、値の名前が仕様で決まっている。
OmissionInsertionMispronunciationUnexpectedBreakMissingBreakMonotoneの7種類だ。 - 抑揚の指摘は
en-US前提。プロソディ評価はen-USロケールのみと公式が明記している。 - 文法・語彙の指摘は「先生役の指示文」の出力だ。もれることがある前提で受け取る。
- 指摘されなかった＝正しい、ではない。公式が非決定的だと書いている以上、無指摘は合格判定ではない。
それでも、訂正フィードバックには人間の講師にない性質がある。何度同じ間違いをしても相手が疲れない、という点だ。
回数を稼ぐ道具として使い、判定の最終権限は渡さない。これが仕組みから言える使い方になる。
なお、文字起こしの精度そのものを上げる手も公式にある。Realtimeの文字起こし設定には prompt と keywords があり、公式は Use prompt to describe the recording or its setting. Use keywords for product names, acronyms, and other literal terms と書いている（出典＝Realtime transcription ガイド）。
訂正フィードバックに関するよくある質問
Q. 訂正フィードバックはAIが自動で持っている機能か。 A. 文法・語彙の側は違う。Microsoftはコンテンツ評価の実装として、チャットモデルに You are an English teacher… というシステムメッセージを渡す方法を公式に示している（発音評価の使用方法）。指示文が無ければ、その形の訂正は出てこない。
Q. 訂正フィードバックの指摘がもれるのはなぜか。 A. 公式が the content generated from a model is non-deterministic（モデルの生成内容は非決定的である）と明記している。もれは想定内の挙動として扱ったほうがいい。
Q. 訂正フィードバックで抑揚まで直してくれるサービスとそうでないサービスがあるのは何が違うか。 A. プロソディ評価を有効にしているかどうかが1つの分かれ目になる。公式は、プロソディ評価の有効化は省略可能であり、利用できるのは en-US ロケールのみと書いている。
Q. 訂正フィードバックは会話の途中で出すのと、あとでまとめて出すのとどちらが仕様に沿っているか。 A. どちらも可能だ。公式は、途中でテキストを検査・変換したいときに chained voice pipeline を使うと書き、run policy checks before the text agent responds という例を挙げている（Voice agents ガイド）。
Q. 訂正フィードバックを自分で強くする方法はあるか。 A. 利用者が触れる範囲は、そのサービスが何を設定として開いているかによる。設計側の手としては、指示文に Identity・Instructions・Examples・Context を書き分ける方法と、採点ずみの例を数個見せる Few-shot が公式ガイドに書かれている（Prompt engineering ガイド）。
まとめ｜訂正フィードバックは仕様と指示文の合成物である
もう一度整理する。
- 訂正フィードバックの手前に整形の層がある。句読点・大文字・言いよどみは、報告されないまま直されていることがある。
- 発音側の訂正は仕様で固定されている。
ErrorTypeはNoneを含めて7種類しか公式に列挙されていない。 - 細かさは設定で決まる。
EnableMiscueの既定はFalse、プロソディ評価はen-USのみ。 - 文法・語彙の訂正は指示文の出力だ。Microsoftの公式ドキュメントに、英語教師役のシステムメッセージと採点手順がそのまま載っている。
- 揺れるのは仕様どおり。公式が生成内容は非決定的だと書いている。無指摘は合格の証明にならない。
⇒ 訂正フィードバックに期待するなら、何の層が何を見ているかを分けて考える。音のずれは仕様、文の誤りは指示文、そのどちらでもないものは誰も見ていない。
そのうえで、回数を重ねられるという利点を取りにいく。これが公式ドキュメントの記述だけから言える、いちばん堅い結論だ。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments