AI英会話の文法指摘がぶれる理由を分解した。文字起こしの整形と指示の設計から追う

AI英会話の文法については、正反対の不満が同時に出てくる。

「間違っているのに何も指摘されない」と、「合っているはずの文まで直された」だ。

この2つは矛盾しているように見えるが、原因は同じ1か所にある。

あなたの英語を「文字にする部品」と、「文法を見る部品」が別物だからだ。

しかも文字にする側は、あなたが話したままの形を返していない。読みやすく整形してから次へ渡している。

つまり文法を見る部品が読んでいるのは、あなたの生の英語ではなく、機械が一度手を入れたあとの英文だ。

この記事では、AIの部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、その整形の中身と、文法の指摘がどこで決まるのかを開けていく。

サービスの順位づけはしない。仕組みの話だけをする。

【結論】AI英会話の文法は、文字起こしの整形と指摘の指示という2段で決まる

先に答えを置く。

AI英会話であなたの発話が文法の指摘に変わるまでには、次の3工程がある。

工程	誰が担当しているか	あなたの英語に何をするか
①音を単語に変える	音声認識（Speech to Text）	声を英単語の並びにする
②読みやすく整える	同じ音声認識サービスの書式設定機能	句読点・大文字・数字表記を足し、言い直しを削る
③文法を見て指摘する	言語モデル（LLM）	②を通ったあとの英文だけを読んで判断する

②はおまけの処理ではない。マイクロソフトは音声テキスト変換での表示テキストの書式設定という独立したドキュメントを立てて、「音声テキスト変換では、文字起こしされたテキストを明確で読みやすくするために、一連の書式設定機能が提供されます」と書いている。

⇒ AI英会話の文法指摘は、整形済みの英文に対して行われている。

だから「指摘されなかった」の多くは、言語モデルが見落としたのではなく、②の時点でその痕跡が消えていた可能性がある。

そして「指摘されすぎる」のほうは、③の言語モデルに与えられた指示の問題になる。

以下、②と③を順に分解する。

AI英会話の文字起こしは、話した通りの形では出てこない

ここがこの記事でいちばん伝えたい部分だ。

表示テキストの書式設定ドキュメントには、文字起こしに対して働く機能が名前つきで並んでいる。

• 逆テキスト正規化（ITN）＝「言語化されたフォームを対応するシンボリックな書き込み形式に変換するプロセス」。
• 大文字化＝「読みやすさ、正しさ、文法を向上させるために大文字にする必要がある単語を認識します」。
• 不要な言葉の除去＝口ごもり、単語の重複、つなぎ言葉を「表示テキストから除去できます」。
• 句読点＝「音声テキスト変換は、テキストに自動的に句読点を付けてわかりやすくします」。
• 不適切表現フィルター＝不適切な語をマスク・削除・そのまま表示のいずれかにする。

この5つは、あなたが話した音の情報を、テキストの段階で確実に書き換えている。

しかもドキュメントは「大文字化」の説明のなかで、その目的として文法という語をはっきり使っている。

つまり音声認識の側が、すでに文法的な体裁を整える仕事をしている。

結果のデータ構造も1本の文字列ではない。同じドキュメントには、結果が Text MaskedNormalizedForm LexicalForm NormalizedForm という複数のプロパティを持つことが書かれており、不適切表現フィルターは前の2つにだけ適用されると明記されている。

⇒ 画面に出ている英文は、複数ある形のうちサービス側が選んだ1つでしかない。

そしてもう1つ、整形の手前にある「誤認識」も文法の話に化ける。

あなたが正しく言った単語が別の単語として認識されれば、その文はテキスト上で崩れた英文になり、言語モデルはそれを文法の誤りとして扱いうる。

そして認識の精度は、マイクと音声の扱いで動く。グーグルの Speech-to-Text のベストプラクティスは、「applying noise-reduction signal processing to the audio before sending it to the service」＝サービスへ送る前に音声へノイズ低減処理をかけることは、「typically reduces recognition accuracy」＝ふつう認識精度を下げる、と書いている。さらに「All noise reduction processing should be disabled.」とまで指示している。

⇒ 身に覚えのない文法の指摘が来たときは、自分の英語ではなく入力側を疑う余地がある。

AI英会話が消す手がかり①｜逆テキスト正規化は設定で止められない

逆テキスト正規化（ITN）は、5つの機能のなかで唯一「切れない」と明記されている。

ドキュメントの原文はこうだ。「音声テキスト変換サービスがこのプロセスを完了し、これは構成できません」。

対象になる形式も書いてある。日付、時刻、小数点、通貨、住所、メール、電話番号などだ。

公式に載っている変換例を、画面に出るほうの形から並べてみる。

表示テキスト	元の音声（公式の例）	テキストから消えた練習項目
The time is 6:45 PM.	the time is six forty five p m	時刻の言い方
That will cost $900.	that will cost nine hundred dollars	金額と単位の語順
I live on 35 Lexington Ave.	I live on thirty five lexington avenue	住所の読み上げと略語
Send it to support@help.com.	send it to support at help dot com	メールアドレスの言い方

真ん中の列を見てほしい。あなたが英語で組み立てた「言い方」は、左の列では全部記号に畳まれている。

数字の読み上げ、時刻の言い方、住所の語順、メールアドレスの言い方は、英語学習では独立した練習項目だ。

ところがテキストになった時点で、その言い方は $900 や 6:45 PM という記号に畳まれている。

そのテキストしか見ていない言語モデルには、あなたが数を英語でどう言ったのかという情報が残っていない。

⇒ 数字・日付・住所まわりの言い方は、テキストベースの文法チェックの対象外になりやすい。

これは精度の話ではなく、仕様として「構成できません」と書かれている以上、設定でどうにかする余地が無い部分だ。

AI英会話が消す手がかり②｜大文字化と句読点は、あなたではなく機械が足している

句読点は、書き言葉の文法そのものだ。それを機械が勝手に付けている。

公式の例を見ると、付け方の判断まで機械がしていることが分かる。

表示テキスト	元の音声（公式の例）	機械が足したもの
How are you?	how are you	文頭の大文字と疑問符
We can go to the mall, park, or beach.	we can go to the mall park or beach	列挙のカンマと終止符
My name is Jennifer Smith.	my name is jennifer smith	固有名詞の大文字化
I want to visit New York City.	i want to visit new york city	地名の大文字化
I got an XL t-shirt.	i got an x l t shirt	大文字化とハイフン

2つ目の例が分かりやすい。列挙のカンマをどこに入れるかは、話者ではなくサービスが決めている。

⇒ 句読点の使い方について文法の指摘が来ないのは、そもそもあなたが打った句読点ではないからだ。

ただし、この自動付与を上書きする道も用意されている。

継続的認識では「明示的な句読点を認識するように」構成でき、句読点を声に出して話せる。speechConfig.EnableDictation(); でディクテーション モードを有効にすると、「音声構成インスタンスが、句読点など文構造の単語の表現を解釈します」と書かれている。

• 「are you sure question mark」と声に出せば、表示テキストは Are you sure? になる。
• 「they entered the room dot dot dot」は They entered the room... になる。
• 「the options are apple forward slash banana forward slash orange period」なら、スラッシュ区切りの The options are apple/banana/orange. になる。

つまり「句読点を自分で決める」練習は、アプリ側がディクテーション モードを使っているかどうかで可否が変わる。

会社が変われば扱いも変わる。グーグルの Cloud Speech-to-Text overview は「additional recognition features such as automatic punctuation and word-level confidence」と書き、これらを「You enable these features in the recognition configuration in requests」＝リクエスト側で有効にする機能として説明している。

ドキュメントの目次にも「Enable automatic punctuation」「Enable spoken punctuation and spoken emoji」「Enable profanity filtering」という手順ページが並んでいる。

⇒ 句読点が付くか付かないかは、英語力ではなくアプリ開発者の設定で決まる。

AI英会話が消す手がかり③｜言い直しとつなぎ言葉は削られてから渡される

ここがいちばん誤解されやすい。

ドキュメントは「不要な言葉の除去」について、「音声には、口ごもりや、単語の重複や、『えーと』や『あー』のようなつなぎ言葉が含まれることがよくあります」と前置きしたうえで、それらを除去できると書いている。

公式の例を見ると、削られるのはつなぎ言葉だけではない。

表示テキスト	元の音声（公式の例）	削られたもの
I think tomorrow should work.	umm i think tomorrow should work	文頭の口ごもり
It’s not that big of a deal.	its its not that big of uhm a deal	単語の重複とつなぎ言葉
I said that we can go to the movies.	i uh said that we can go to the uhmm movies	文中に2回入ったつなぎ言葉

2行目に注目してほしい。its its という単語の重複が1つに畳まれ、さらにアポストロフィまで補われて It's になっている。

言い直しの回数も、所有格と短縮形の区別も、この1手で表示テキストからは見えなくなる。

ドキュメント自身が、この機能の用途を「台本のない生のスピーチを文字起こしして後で読み直すための優れた機能です」と説明している。読みやすさのための機能であって、学習者の記録を残すための機能ではない。

そして同じ課題は、別の会社の側でも認識されている。

OpenAI の Speech to text ガイドは、文字起こしに prompt を添える有効な場面の1つとして「Preserving punctuation, capitalization, and filler words.」（句読点・大文字・つなぎ言葉を保つこと）を挙げている。

⇒ つなぎ言葉を「保つ」ことがわざわざ指示項目になっている＝何もしなければ保たれるとは限らない。

フィラーの多さや言い直しの癖を直したい人にとっては、ここは知っておく価値がある。

AI英会話の文法指摘は言語モデルの仕事で、指示しだいで出たり消えたりする

ここから③の話に移る。

整形済みの英文を読んで「ここが違う」と言うのは、音声認識ではなく言語モデルの担当だ。

そして言語モデルの振る舞いは、開発者が書いた指示文で決まる。OpenAI の Prompt engineering ガイドは、プロンプトエンジニアリングを「the process of writing effective instructions for a model」＝モデルに向けて効く指示文を書く工程だと定義し、その目的を「such that it consistently generates content that meets your requirements」＝要求を満たす内容を一貫して生成させることだと書いている。

同じガイドは前提もはっきり書いている。「Because the content generated from a model is non-deterministic」＝出力は決定的ではない、と。

⇒ 同じ英文を2回投げて、同じ指摘が2回返る保証は仕様上どこにも無い。

さらに、誰の指示が強いかも決まっている。

• developer＝アプリ開発者が与える指示。user より優先される。AI英会話で言えば、アプリを作った会社の方針にあたる。
• user＝利用者が与える指示。developer の後ろに置かれる。あなたが会話中に打つお願いがここだ。
• assistant＝モデルが生成したメッセージ。返ってくる英語と、文法の指摘そのもの。

ガイドは両者の関係を「You could think about developer and user messages like a function and its arguments in a programming language.」と説明し、developer がルールと業務ロジック、user はそこへ渡す入力だと書いている。

⇒ 「文法をもっと厳しく直して」というあなたの頼みは、アプリ側の方針より下の優先度で扱われる。

アプリが「初心者を萎縮させないため、細かい文法は指摘しない」という方針を developer 側に書いていれば、そちらが先に効く。

もう1つ、会話が続くときの落とし穴もガイドに書かれている。

「Note that the instructions parameter only applies to the current response generation request.」

続けて、previous_response_id で会話状態を管理している場合、前のターンで使った instructions は文脈に残らない、とある。

⇒ 会話の途中で1回だけ「これから全部直して」と頼んでも、実装によっては次のターンでその指示が消える。

「最初は直してくれたのに、途中から指摘が減った」という体感は、この構造で説明がつく場合がある。

モデルそのものが変わる要因も書いてある。ガイドは「Even different snapshots of models within the same family could produce different results.」として、本番アプリを特定のモデルスナップショットに固定することを強く推奨している。

アプリ側がモデルを差し替えれば、同じ使い方でも指摘の細かさは変わりうる、ということだ。

AI英会話の文法採点は「別のモデルへの発注書」でできている

ここは仕様が具体的に公開されている、珍しい部分だ。

マイクロソフトの発音評価のドキュメントには「コンテンツ評価」という節があり、「認識された音声によっては、ボキャブラリ、文法、トピックの関連性に関するコンテンツ評価の結果を取得することもできます」と書かれている。

注目すべきは、その扱いだ。ドキュメントは「コンテンツ評価 (プレビュー) は、Speech SDK バージョン 1.46.0 以降から廃止されます」と告知し、代わりに Azure OpenAI のチャット モデルを使う方法を提示している。

⇒ 文法の採点は、音声側の専用機能ではなく、チャットモデルへの依頼文として実装される形に移っている。

その依頼文の中身まで、ドキュメントにそのまま載っている。

• システム メッセージは、モデルに「You are an English teacher」と名乗らせたうえで、「to grade a student’s essay from vocabulary and grammar and topic relevance」＝語彙・文法・トピックの関連性から生徒のエッセイを採点せよ、と頼む形になっている。
• 出力形式＝{"vocabulary": *.*(0-100), "grammar": *.*(0-100), "topic": *.*(0-100)} という3項目のスコア。
• ユーザー メッセージには、採点例が3つ並べられている（Example1〜Example3）。

そして、そのユーザー メッセージの一節がこの記事の主題そのものだ。

前半はこうだ。「The transcript is from speech recognition so that please first add punctuations when needed」。

訳せば、これは音声認識から来た文字起こしなので、まず必要に応じて句読点を足せ、となる。

採点する側が、渡されたテキストをそのまま信用していない。

後半に、削る指示と探す指示が続く。「remove duplicates and unnecessary un uh from oral speech」、そして「then find all the misuse of words and grammar errors」。

つまり重複と不要な un や uh を話し言葉から取り除いてから、語の誤用と文法の誤りを全部探せという順番になっている。

⇒ 文法を採点する前に、もう一度整形せよと指示されている。

つまり整形は1回ではなく、認識側と採点側で二重にかかりうる。

ここまでの流れを1本の線に並べると、こうなる。

• あなたが話す。
• 音声認識が単語に変え、句読点・大文字・数字表記を足し、言い直しとつなぎ言葉を削る。
• その英文が言語モデルに渡る。
• 言語モデルは「まず句読点を足し、重複を取り除いてから」誤りを探すよう指示される。
• 残ったものだけが、あなたへの文法の指摘になる。

⇒ 指摘されなかった＝間違っていなかった、ではない。

なお、発音側のスコアは文法を見ていない。同じドキュメントの発音スコアは、精度・プロソディ・流暢さ・完全性を重み付けした PronScore = 0.4 * s0 + 0.2 * s1 + 0.2 * s2 + 0.2 * s3 という式で計算されると書かれており、この4項目に文法は入っていない。

• 発音スコア（PronScore）＝発音評価の機能が出す。中身は精度・プロソディ・流暢さ・完全性の4項目で、文法は入っていない。
• コンテンツ評価のスコア＝チャットモデルへの依頼として実装される。中身は vocabulary・grammar・topic で、文法はこちら側にある。

発音の点が高くても文法が見られているとは限らない、というのは仕様から言えることだ。

AI英会話で文法の指摘を安定させるための、仕組みから言える使い方

ここまでの仕様から、そのまま導けることだけを並べる。精神論は入れない。

• 指示は毎ターン言い直す。 instructions は現在のリクエストにしか効かず、会話状態を引き継ぐ実装では前のターンの指示が文脈に残らないと公式が書いている。
• 「直して」ではなく、出力の形を指定する。 コンテンツ評価の例文は出力形式を {"vocabulary": ..., "grammar": ..., "topic": ...} と固定していた。形を決めると答えが安定しやすい。
• 例を2〜3個見せる。 ガイドは Few-shot learning を「a handful of input/output examples in the prompt」でモデルを新しいタスクへ誘導する手法として説明している。公式のコンテンツ評価の例文も、採点例を3つ並べていた。
• 指示は構造化して書く。 ガイドは developer メッセージの標準構成として Identity・Instructions・Examples・Context の4節を挙げ、Markdown の見出しや XML タグで境界を示すことを勧めている。
• 数字・時刻・住所の言い方は、テキストの指摘に頼らない。 逆テキスト正規化は「構成できません」と明記されており、言い方は記号に畳まれる。
• つなぎ言葉の癖を直したいなら、文字起こしの設定側を疑う。 「Preserving punctuation, capitalization, and filler words.」がわざわざ指示項目として挙がっている。
• キーワードの指定は万能ではない。 Realtime transcription ガイドは「Keywords are hints, not required output.」と書いている。固有名詞や専門用語を渡しても、その通りに出るとは限らない。

最後に1つ、公式が置いている注意も添えておく。

OpenAI のガイドは、文字起こしをテキストモデルで後処理する方法を紹介したうえで、「Evaluate corrections against the original audio to avoid changing what the speaker said.」＝話者が言ったことを変えてしまわないよう、修正を元の音声と照らして検証せよと書いている。

後処理で英文がきれいになることと、あなたの英語が正しかったことは別の話だ、という警告として読める。

AI英会話の文法で、そもそも判定できないもの

構造上どこにも乗っていないものは、期待しても返ってこない。

• 話したままの語順や言い直しの回数。 表示テキストの段階で重複とつなぎ言葉が除去されうる。
• 数の言い方、時刻の言い方、メールアドレスの言い方。 逆テキスト正規化で記号に変換され、これは構成できないと明記されている。
• 句読点の打ち方。 自動で付与されるか、ディクテーション モードで声に出すかのどちらかで、いずれも機械側の設定に依存する。
• 発音スコアからの文法判定。 PronScore の式に入っているのは精度・プロソディ・流暢さ・完全性の4項目だけだ。
• 指摘の網羅性。 出力は non-deterministic だと公式が書いている以上、毎回もれなく同じ指摘が出るとは考えないほうがいい。

⇒ ここは「AIが劣っている」のではなく、そのデータが工程のどこにも残っていないという話だ。

逆に言えば、整形を通り抜けて残る誤り、たとえば時制・語順・冠詞・語の選び方といった部分は、言語モデルが読むテキストにそのまま乗る。

AI英会話の文法チェックが得意なのは、そちら側だ。

AI英会話の文法に関するよくある質問

Q. 間違えて話したのに指摘されないのはなぜか。 A. 指摘する前に整形が入っているからだ。表示テキストの書式設定では、単語の重複やつなぎ言葉が除去され、句読点と大文字が自動で足される。さらにコンテンツ評価の例文でも、採点前に「句読点を足し、重複と un uh を取り除け」と指示されている。

Q. 逆に、合っている文まで直されるのはなぜか。 A. 何をどこまで直すかは開発者の指示文で決まるからだ。developer の指示は user より優先されると公式ガイドに書かれている。厳しめの方針が設定されていれば、あなたの「そこはそのままでいい」は後ろに置かれる。

Q. 「毎回すべての文法ミスを指摘して」と頼めば解決するか。 A. 一時的には効くことがある。ただし instructions は現在のリクエストにのみ適用され、会話状態を引き継ぐ実装では前のターンの指示が文脈に残らないと明記されている。毎ターン言い直すほうが仕組みに合っている。

Q. 数字や時刻の英語の言い方は練習できるか。 A. 声に出す練習はできる。ただし文字起こし上は $900 6:45 PM のような記号に変換され、その変換は「構成できません」と公式ドキュメントに書かれている。テキストの指摘で確認するのは向いていない。

Q. 発音の点数が高ければ文法も大丈夫か。 A. 別物だ。発音スコアは精度・プロソディ・流暢さ・完全性を重み付けした式で計算され、文法はその4項目に入っていない。文法は コンテンツ評価側の vocabulary・grammar・topic で扱われる。

Q. アプリごとに指摘の細かさが違うのはなぜか。 A. 句読点を有効にするかどうかがリクエスト側の設定であること、指示文が開発者側で書かれること、モデルのスナップショットによって結果が変わりうることが、すべて公式ドキュメントに書かれている。差は英語力ではなく実装の差だ。

まとめ｜AI英会話の文法は「整形されたあとの英文」に対する判定でしかない

もう一度整理する。

• AI英会話の文法指摘は、音声認識・書式設定・言語モデルの3工程の最後で起きる。読まれているのは生の発話ではなく整形後の英文だ。
• 逆テキスト正規化は「構成できません」と公式に書かれており、数字・時刻・住所・メールの言い方は記号に畳まれて消える。
• 句読点と大文字は機械が足している。 自分で決めたい場合はディクテーション モードのような別の仕組みが要る。
• 言い直しとつなぎ言葉は削られうる。 それを保つことが、わざわざ指示項目として公式に挙げられている。
• 指摘の強さは developer の指示で決まり、出力は non-deterministic。 指摘のもれは前提として扱い、指示は毎ターン言い直すのが仕組みに合っている。

⇒ 「AI英会話は文法に弱い」ではなく、「自分が直したい誤りは、整形を通り抜けてテキストに残るのか」で見る。

時制・語順・冠詞・語の選び方のように文字として残るものは、言語モデルの得意分野にそのまま乗る。

逆に、言い方そのものや言い直しの癖は、テキストになる前に落ちている。そこは別の方法で確認するしかない。

※本記事の一次ソースはすべて2026-09-11に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。