AI英会話の添削は何をしているのか。質を決めているのは英語力ではなく「指示の設計」だと公式ガイドから分解した

公開日 2026年9月12日(土) 05:17更新日更新なし

AI英会話の「添削」は、英語ができる先生が赤ペンを入れる作業とは、まったく別のことをしている。

添削を担当しているのは言語モデルで、言語モデルがやっているのは指示に沿ってテキストを生成することだ。

つまり「どこまで直すか」「何を指摘するか」「どんな形で返すか」は、モデルの英語力ではなく、裏側に書かれている指示文（プロンプト）が決めている。

ここを知らないまま使うと、「毎回指摘の粒度が違う」「細かいミスを飛ばされる」「直してほしくないところまで書き換えられた」というズレが、全部モデルの能力不足に見えてしまう。

この記事では、OpenAI が公開している開発者向けのガイドに書かれている記述だけを材料にして、AI英会話の添削が何をしているのかを1段ずつ開けていく。

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

TOC

【結論】AI英会話の添削の質は、英語力ではなく「指示の設計」で決まる

先に答えを置く。

OpenAI のプロンプトエンジニアリングのガイドは、冒頭でこの分野をこう定義している。「Prompt engineering is the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements.」（プロンプトエンジニアリングとは、モデルが要求を満たす内容を一貫して生成するように、効果的な指示を書く作業である）OpenAI Prompt engineering ガイドより。

ここで注目すべきは consistently（一貫して）という語だ。

同じガイドは続けて、「Because the content generated from a model is non-deterministic」（モデルが生成する内容は非決定的であるため）と書いている。

⇒ 出力がブレるのは前提で、そのブレを指示の設計で押さえにいく、というのが公式の立場だ。

添削に置き換えると、こうなる。

添削で起きること	本当の原因がある場所	ガイドでの呼び名
指摘の立場がバラつく（先生役だったり友達役だったり）	役割の指定	`Identity`
直してほしくない箇所まで書き換えられる	やること／やらないことの列挙	`Instructions`
返ってくる形が毎回違う	お手本の提示	`Examples`
自分のレベルや目的を無視した直し方になる	参照情報の投入	`Context`

この4つの名前は、私が整理のために付けたものではない。OpenAI のガイドが「developer メッセージには、通常この順序で次のセクションが含まれる」として挙げている4つそのものだ。

⇒ AI英会話の添削は、英語の知識量の勝負ではなく、この4つをどこまで書き込んであるかの勝負になっている。

AI英会話の添削は「文法チェッカー」ではない｜生成の一種である

ここが、いちばん最初にずれる場所だ。

従来の文法チェッカーは、辞書とルールで「この形は誤り」と判定する装置だった。

言語モデルはそうではない。ガイドの1行目は、モデルの仕事を「generate text from a prompt」（プロンプトからテキストを生成する）と書いている。

そして生成できるものとして 「code, mathematical equations, structured JSON data, or human-like prose」（コード、数式、構造化されたJSONデータ、人間らしい散文）が並んでいる。

⇒ 「添削」という専用機能があるのではなく、「添削に見える文章を生成させている」というのが構造だ。

この違いは実害として出る。

網羅性が保証されない。 ルールを総当たりしているわけではないので、同じ文でも拾う誤りが変わりうる。
「直す理由」も生成物である。 説明文は、判定結果の記録ではなく、その場で作られた文章だ。
指示が変われば結果が変わる。 同じ英文でも、裏の指示文が違えば別の添削になる。

だから「AIの添削は当てにならない」という感想は、半分正しくて半分ずれている。

正確には、当てになる範囲は指示の書き方で動く、ということになる。

AI英会話の添削で最初に効くのは「役割」の指定｜誰の指示が勝つのか

プロンプトには、書いた人によって強さの序列がある。

ガイドは 「You can provide instructions to the model with differing levels of authority」（異なる権限レベルで指示を与えられる）と書き、OpenAI Model Spec の chain of command を参照している。

役割は3つある。

役割	ガイドの説明（原文の要点）	AI英会話では誰が書くか
`developer`	「instructions provided by the application developer, prioritized ahead of `user` messages」＝アプリ開発者が与える指示。`user` より優先される	サービスを作った側
`user`	「instructions provided by an end user, prioritized behind `developer` messages」＝利用者が与える指示。`developer` の後ろに置かれる	あなた
`assistant`	「Messages generated by the model」＝モデルが生成したメッセージ	AI側の発言

⇒ あなたがチャット欄に打つ「もっと厳しく直して」は、サービス側があらかじめ書いた指示よりも後ろに置かれる。

これは、AI英会話で「頼んでもその通りにならない」ときの構造的な説明になる。

ガイドはこの関係を、プログラミングのたとえで書いている。「You could think about developer and user messages like a function and its arguments」（関数とその引数のようなもの）。

developer メッセージ＝「the system’s rules and business logic, like a function definition」＝関数の定義にあたる、システムのルール。
user メッセージ＝「inputs and configuration to which the developer message instructions are applied」＝その定義が適用される入力と設定。

⇒ 利用者は関数の中身を書き換えられない。渡せるのは引数だけだ。

なお、API の instructions パラメータについては 「Any instructions provided this way will take priority over a prompt in the input parameter.」（この方法で与えた指示は、input のプロンプトより優先される）と明記されている。

AI英会話の添削が的外れになる理由｜モデルは「直してほしい範囲」を知らない

添削で最も多い不満は、精度そのものではなく「範囲」のズレだ。

文法だけ見てほしいのに言い回しごと書き換えられる。逆に、自然さを上げてほしいのに冠詞の指摘だけで終わる。

これはモデルが空気を読めないからではなく、範囲という情報がプロンプトに入っていないからだ。

ガイドの Instructions セクションの説明が、そこをそのまま言っている。「What rules should it follow? What should the model do, and what should the model never do?」（どんなルールに従うべきか。何をすべきで、何を決してすべきでないか）。

⇒ 「やらないこと」を書く欄が、公式の型の中に用意されている。

ガイドが載せている実例のプロンプトを見ると、禁止事項が1行で書かれているのが分かる。コード生成用の例には 「Do not give responses with Markdown formatting, just return the code as requested.」（Markdown の書式で返すな。要求されたコードだけを返せ）とある。

レビュー分類用の例では、さらに強い。「Only output a single word in your response with no additional formatting or commentary.」（追加の書式や注釈なしで、1語だけを出力せよ）。

⇒ 出力を絞りたいときは、「何を出すか」だけでなく「何を出さないか」を書くのが公式の例の書き方になっている。

添削に当てはめるなら、「文法の誤りだけを指摘し、自然さの提案はしない」という一文が、指摘の粒度を決めるということだ。

AI英会話の添削を安定させる指示の型｜公式が挙げる4つのセクション

ガイドには、指示文の構成そのものが書かれている。

原文は 「In general, a developer message will contain the following sections, usually in this order」（一般に developer メッセージは、通常この順序で次のセクションを含む）という書き出しだ。

セクション	ガイドの説明（要点）	添削に置き換えると
`Identity`	「Describe the purpose, communication style, and high-level goals of the assistant.」＝目的・話し方・上位の目標	誰として直すか（試験対策の講師か、会話の相手か）
`Instructions`	「What should the model do, and what should the model never do?」＝やること／やらないこと	指摘の範囲と禁止事項
`Examples`	「Provide examples of possible inputs, along with the desired output」＝入力と望ましい出力の例	添削結果の見本
`Context`	「private/proprietary data outside its training data」など追加情報。位置は「usually best positioned near the end of your prompt」	学習者のレベル・過去の誤り・目的

⇒ 「レベルや目的といった前提情報は、プロンプトの終わりのほうに置くのがよい」と公式が位置まで指定している。

この4節を区切る方法についても記述がある。

ガイドは Markdown と XML タグの併用を挙げ、「Markdown headers and lists can be helpful to mark distinct sections of a prompt, and to communicate hierarchy to the model.」（Markdown の見出しとリストは、プロンプトの各セクションを区切り、階層をモデルに伝えるのに役立つ）と書いている。

XML タグのほうは役割が違う。「XML tags can help delineate where one piece of content (like a supporting document used for reference) begins and ends.」（参照用の資料などが、どこで始まりどこで終わるかを区切るのに役立つ）。

⇒ 添削してほしい英文を、指示文と混ざらない形で囲むこと自体が、公式が推奨している技術になっている。

実際、ガイドが載せている例では <user_query> や <product_review id="example-1"> というタグで入力側を囲み、<assistant_response> で望ましい出力を囲んでいる。

AI英会話の添削は「例示」と「出力形式の指定」で形が決まる

添削の出力形式を決めているのは、たいてい説明文ではなく見本のほうだ。

ガイドには 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.」（モデルをファインチューニングするのではなく、入力と出力の例をいくつかプロンプトに入れることで、新しいタスクへ導く）。

その次の1文が、添削の挙動をほぼ説明している。「The model implicitly “picks up” the pattern from those examples and applies it to a prompt.」（モデルは例からパターンを暗黙的に「拾い上げ」、それをプロンプトに適用する）。

⇒ 「こういう形で返して」と説明するより、「こういう返し方」を1個見せるほうが効く、というのが仕組みのうえでの結論になる。

例の選び方にも注意書きがある。「When providing examples, try to show a diverse range of possible inputs with the desired outputs.」（例を出すときは、起こりうる入力の幅を広く見せるようにせよ）。

ガイドの実例では、肯定・中立・否定の3種類が並べてある。同じ型ばかり3つ並べるのではなく、違う種類を並べることに意味があるという設計だ。

添削で言えば、「直す必要がない文」の例も1つ混ぜておくと、過剰な書き換えが起きにくい形になる。
例は developer メッセージの一部として置くのが典型だとガイドは書いている（「Typically, you will provide examples as part of a developer message」）。
つまり例示の枠は、利用者ではなくサービス側が握っていることが多い。

AI英会話ごとに添削の見た目が違うのは、モデルの差ではなく、ここに入っている見本の差である可能性が高い。

そしてもう一段、添削結果が表やリストで整って出てくるのも、偶然ではない。

ガイドには 「In addition to plain text, you can also have the model return structured data in JSON format – this feature is called Structured Outputs.」（プレーンテキストに加えて、JSON 形式の構造化データを返させることもできる。この機能を Structured Outputs と呼ぶ）という記述がある。

ガイドの末尾では、この機能の役割をもっと短く言い切っている。「Ensure JSON data emitted from a model conforms to a JSON schema.」（モデルが出す JSON データが、スキーマに適合することを保証する）Structured Outputs のガイドより。

⇒ 「誤り箇所」「訂正後」「理由」「重要度」といった欄を、毎回同じ形で埋めさせることが技術的に可能だ、ということになる。

ここから、利用者側にとって実用的な読み方が1つ出る。

添削画面の見え方	裏で起きていそうなこと	注意点
毎回きっちり同じ欄が埋まっている	出力の形が固定されている	欄を埋めるために、優先度の低い指摘が混ざることがある
自由な文章で返ってくる	形の固定が弱い	指摘の量と粒度が回ごとに動きやすい
指摘が0件の回がある	「直す必要なし」も出力として許されている	網羅性の保証とは別の話として読む

形が整っていることと、内容が網羅的であることは、別々の話だ。

AI英会話の添削が回ごとにブレる理由｜指示は持ち越されず、モデルでも変わる

「一度お願いした直し方が、数ターン後には戻っている」という現象にも、公式ガイドに対応する記述がある。

ひとつは instructions パラメータの適用範囲だ。

原文はこう書いている。「Note that the instructions parameter only applies to the current response generation request. If you are managing conversation state with the previous_response_id parameter, the instructions used on previous turns will not be present in the context.」（instructions は現在の生成リクエストにのみ適用される。会話状態を previous_response_id で管理している場合、前のターンで使った instructions はコンテキストに残らない）。

⇒ 指示は自動的に持ち越されない。持ち越すかどうかは、実装した側の設計しだいになる。

もうひとつは容量の問題だ。

ガイドには 「Models can only handle so much data within the context they consider during a generation request. This memory limit is called a context window」（生成時に考慮できるデータ量には上限があり、この記憶の上限をコンテキストウィンドウと呼ぶ）とあり、その大きさは 「from the low 100k range up to one million tokens for newer GPT-4.1 models」（10万台から、新しい GPT-4.1 系では100万トークンまで）とモデルによって違うと書かれている。

長い会話を続けるほど、初期に置いた添削ルールは押し出されやすくなる。
だからレッスンを短く切って、毎回同じ条件で始めるほうが、仕組みのうえでは安定しやすい。
ガイドは繰り返し使う内容をプロンプトの先頭側に置くことも勧めている。理由はコストと遅延で、prompt caching の節に書かれている。

加えて、モデルそのものが変われば挙動も変わる。

ガイドは 「Even different snapshots of models within the same family could produce different results.」（同じ系列のモデルでも、スナップショットが違えば異なる結果になりうる）と書き、対策として 「Pinning your production applications to specific model snapshots」（特定のスナップショットに固定すること）を推奨している。

⇒ アップデートのあとに添削の癖が変わったように感じるのは、気のせいとは限らない。

そもそも、同じ頼み方がどのモデルでも同じように効くわけではない。

ガイドは reasoning モデルと GPT モデルを分けて説明している。

「reasoning models will provide better results on tasks with only high-level guidance. This differs from GPT models, which benefit from very precise instructions.」（reasoning モデルは高レベルの指示だけのタスクでよい結果を出す。これは、非常に精密な指示から利益を得る GPT モデルとは異なる）。

ガイドはこの差を人にたとえている。

モデルの種類	ガイドのたとえ	添削で効きやすい頼み方
reasoning モデル	「like a senior co-worker」＝目標を渡せば細部は任せられる先輩	「自然さを上げる方向で直して」など、目的を渡す
GPT モデル	「like a junior coworker」＝明示的な指示で最もよく働く後輩	「時制の誤りだけを列挙して」など、手順を渡す

⇒ 「もっと丁寧に直して」が通らないときは、頼み方の粒度がモデルの種類と合っていない可能性がある。

なお最新モデル向けの指示の書き方については、ガイドが別ページを用意していて、latest model prompting best practices を参照するよう案内している。

その中の実務的な助言のひとつが、添削にもそのまま効く。コーディング用の項目には 「define the agent’s role, enforce structured tool use with examples」（エージェントの役割を定義し、例を使って構造化された使い方を守らせる）とある。

⇒ 役割の定義と例示は、どの用途でも先頭に来る。

AI英会話の添削は、音声で話すときだけ別の設計になる

テキストで打つ添削と、話しながら直される添削は、裏の作りが違う。

OpenAI の音声エージェントのガイドは、冒頭で設計の分岐点をこう書いている。「The key design choice is how speech connects to reasoning and tools」（鍵となる設計上の選択は、音声を推論やツールにどう接続するかである）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	「Inspect or transform intermediate text and replace each component independently」＝途中のテキストを検査・変換でき、各部品を独立に差し替えられる	認識されたテキストを見てから添削できる

⇒ 「自分の発話がどう文字になったか」を見せてくれる作りかどうかは、この方式の選択で決まっている。

チェーン方式について、ガイドは3段構成だと明記している。「1. Speech-to-text 2. The agent workflow itself 3. Text-to-speech」。

そのうえで使いどころを 「Use this path when each stage needs to be visible or replaceable.」（各段階を可視化または差し替え可能にしたいときに使う）と書き、例として 「you might store the transcript, run policy checks before the text agent responds」（書き起こしを保存し、テキストエージェントが応答する前にチェックを走らせる）を挙げている。

⇒ 添削を「話した後に文字で見返す」形にできるのは、この設計を採っている場合だ。

リアルタイム型のほうも、振る舞いの決め方はテキストと同じだ。Realtime API のガイドのサンプルコードでは、RealtimeAgent に instructions の文字列を渡して性格を決めている。

同ガイドは 「Keep audio transport concerns in the session layer, and keep business logic in the agent definition.」（音声の伝送はセッション層に、業務ロジックはエージェント定義に置け）と設計指針まで書いている。

音声エージェントのガイドには、評価についての一文もある。「A natural-sounding response does not prove that a tool ran or that application state changed.」（自然に聞こえる応答は、処理が実際に走ったことの証明にはならない）。

⇒ 流暢に「いいですね、その言い方で大丈夫です」と返ってくることは、添削が働いた証拠にはならない。

AI英会話の添削を自分の側から作り変える手順

ここまでの記述から、そのまま導ける手順だけを並べる。精神論は入れない。

役割を先に1行で渡す。 ガイドの Identity に当たる。目的・話し方・上位の目標を書く欄として公式の型に存在する。
やらないことを書く。 「何を決してすべきでないか」は Instructions の説明文そのものに入っている項目だ。
望む返し方を1つ見せる。 few-shot は「例からパターンを暗黙的に拾う」と定義されている。説明より見本が早い。
直してほしくない例も見せる。 「起こりうる入力の幅を広く見せよ」という注意書きに沿う形になる。
自分の英文を記号で囲む。 資料の始まりと終わりを区切るのに XML タグが役立つ、と明記されている。
前提情報は最後に置く。 Context は「プロンプトの終わり近くに置くのが最良であることが多い」とされている。
会話を長く伸ばさず、区切って始め直す。 コンテキストウィンドウの上限があり、instructions は自動では持ち越されない。
指示の効き方を自分で記録する。 ガイド自身が「プロンプトの挙動を測るテストと評価の仕組みを作る」ことを勧めている。

この8つは、どれも英語力とは無関係の操作だ。

ただし developer 側の指示を書き換えることはできないので、効く範囲には上限がある。

AI英会話の添削に関するよくある質問

Q. AI英会話の添削は、すべての間違いを拾ってくれるのか。 A. 網羅を保証する記述は、参照した OpenAI のガイドには見当たらない。ガイドが書いているのは「モデルが生成する内容は非決定的である」という性質のほうで、だから「一貫して要求を満たすように指示を書く」作業が必要だと説明されている。網羅性は前提にせず、同じ英文を条件を変えて2回投げるほうが仕組みに合っている。

Q. 「厳しく添削して」と頼んでも変わらないのはなぜか。 A. 役割の優先順位が理由になりうる。ガイドは developer メッセージが user メッセージより優先されると書いている。利用者の指示は、サービス側があらかじめ書いた指示の後ろに置かれる。

Q. 同じ英文なのに、日によって添削結果が違う。 A. ガイドは生成が非決定的であることに加えて、「同じ系列でもスナップショットが違えば異なる結果になりうる」と明記している。対策としてモデルの固定を推奨しているのは、サービスを作る側の話だ。

Q. 添削の精度を上げる、利用者側でできる一番効く操作は何か。 A. 例示だ。few-shot learning は「入力と出力の例をいくつか入れることで新しいタスクへ導く」と定義されていて、モデルは例からパターンを拾い上げると書かれている。望む形の添削を1つ書いて見せるのが早い。

Q. 音声で話すタイプの添削と、書いて出すタイプの添削は違うのか。 A. 設計として別物になりうる。音声エージェントのガイドは、途中のテキストを検査・変換できるチェーン方式と、1セッションで完結するリアルタイム方式を別の選択肢として並べている。書き起こしを見せてくれるかどうかは、その選択の結果として表に出る。

Q. 添削の「理由の説明」は信用していいのか。 A. 説明文も生成されたテキストである、という前提で読むのが筋になる。ガイドはモデルの仕事を「プロンプトからテキストを生成する」ことと定義しており、説明が判定ログであるとは書かれていない。英語の形についての指摘と、その理由づけは分けて扱うほうが安全だ。

まとめ｜AI英会話の添削は「指示の設計」を見れば読み解ける

もう一度整理する。

添削は専用機能ではなくテキスト生成の一形態だ。だから出力は非決定的で、一貫性は指示の設計で作りにいくものだと公式ガイドが定義している。
指示には序列がある。developer が user より優先されるので、利用者の頼み方が届く範囲には上限がある。
公式の型はIdentity・Instructions・Examples・Context の4節。「やらないこと」と「前提情報を末尾に置くこと」まで書かれている。
形を決めるのは説明ではなく例示。few-shot は「例からパターンを暗黙的に拾う」仕組みとして説明されている。
指示は自動で持ち越されない。instructions は現在のリクエストにのみ適用されると明記されており、会話を長く伸ばすほどブレやすくなる。