LLM 英会話の中身を分解する。AIの会話は「指示・履歴・確率」の3つでできている

公開日 2026年9月13日(日) 09:00更新日更新なし

AI英会話の「会話の中身」を作っているのは、LLM（大規模言語モデル）という1個の部品だ。

あなたの声を文字に変えるのは音声認識、文字を声に変えるのは音声合成で、そのどちらもLLMではない。

LLMが担当しているのは、文字になったあなたの英文を受け取って、次に返す英文を作るところだけだ。

ここが分かっていないと、「なぜ設定を忘れるのか」「なぜ毎回言うことが違うのか」「なぜ間違いを指摘してくれない回があるのか」が、全部ふしぎな現象に見える。

ところが、LLMを売っている会社が開発者向けに公開しているドキュメントを開くと、その理由はたいてい仕様として書いてある。

この記事では、OpenAIの公式ドキュメントに実際に書かれている記述だけを材料にして、LLMが英会話の中で何をしていて、何をしていないのかを分解する。

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

TOC

【結論】LLM英会話の中身は「指示・履歴・確率」の3つで決まる

先に答えを置く。

LLM英会話で「AIが英語を理解して答えている」ように見えているものは、次の3つの掛け算でできている。

要素	公式ドキュメントでの呼び名	誰が決めているか
①指示	`instructions` ／ `developer` メッセージ	アプリを作った側
②履歴	conversation state（会話の状態）	アプリを作った側
③生成	non-deterministic な出力	モデル（毎回ゆれる）

この3つは、どれも「モデルの中身が賢いかどうか」の話ではない。

アプリ側が毎回組み立てて渡している入力と、モデルが確率的に返してくる出力の話だ。

OpenAIの公式ドキュメントは、テキスト生成のリクエストについて「While each text generation request is independent and stateless」＝それぞれのテキスト生成リクエストは独立していて、状態を持たない、と明記している（Conversation state）。

つまりLLMは、さっき何を話したかを自分では持っていない。

覚えているように見えるのは、アプリ側が過去のやりとりを毎回まとめて送り直しているからだ。

⇒ LLM英会話の体験は、モデルの性能よりも「毎回そこへ何を渡しているか」で決まる部分が大きい。

そもそもLLMとは何か｜LLM英会話の話し相手の正体

LLMは、英語の先生として作られた部品ではない。

OpenAIの公式ガイドは、LLMのことを「a large language model to generate text from a prompt」＝プロンプトからテキストを生成する大規模言語モデル、と説明している（Prompt engineering）。

そして出せるものの例として「code, mathematical equations, structured JSON data, or human-like prose」＝コード、数式、構造化されたJSONデータ、人間らしい文章、を並べている。

英会話はこの最後の「人間らしい文章」の使い道の1つでしかない。

だからLLM英会話は、英語教育のために作られた装置ではなく、汎用のテキスト生成装置を英語の会話相手として使っている状態にある。

同じ公式ガイドは、モデルの種類による性格の違いにも触れている。

Reasoning models＝内部で思考の連鎖を作ってから答える型。複雑な課題や多段の計画に強い代わりに「generally slower and more expensive to use」＝おおむね遅く、費用も高い、と書かれている。
GPT models＝速くて費用効率がよいが「benefit from more explicit instructions around how to accomplish tasks」＝やり方をより明示的に指示したほうが結果が良くなる、とされている。
大きいモデルと小さいモデル（mini・nano）＝速度・費用・賢さのトレードオフ。大きいほどプロンプトの理解と問題解決に強く、小さいほど速くて安い。

アプリがどれを使っているかは画面から分からないことが多い。

ただし公式ガイドは「different model types」＝モデルの種類が違えば「might need to be prompted differently」＝指示の書き方も変えたほうがよい場合がある、とはっきり書いている。

⇒ LLM英会話の「うまさ」は、モデルと指示文の組み合わせで動く。どちらか片方だけでは決まらない。

LLM英会話の1往復で何が起きているか｜音声とLLMの分業

LLM英会話の1往復は、公式ドキュメントの言葉では3つの段に分かれている。

OpenAIの「Voice agents」ガイドは、途中のテキストを覗ける構成（chained voice workflow）について、アプリ側が管理する段を3つ挙げている（Voice agents）。

Speech-to-text＝あなたが出した音を英文テキストに変える段。
The agent workflow itself＝エージェントのワークフロー本体。ここがLLMの担当。
Text-to-speech＝返ってきたテキストを声に変える段。

LLMが触っているのは、真ん中の1段だけだ。

だから最初の段で認識を取り違えられたら、LLMは間違ったまま文字になった英文を受け取ることになる。

そのときLLMは「これは聞き間違いではないか」とは考えない。渡された文字列に対して、自然につながる返事を作るだけだ。

この構成の利点を、公式ガイドは「Inspect or transform intermediate text and replace each component independently」＝途中のテキストを検査・変換でき、各部品を独立に差し替えられる、と説明している。

裏を返すと、自分の発話の文字起こしが画面に出るアプリは、この段ごとに分かれた構成を採っているということだ。

公式ガイドは用途の例として、文字起こしを保存する、テキストのエージェントが答える前にポリシー検査を走らせる、社内システムを呼ぶ、承認された答えになってから初めて音声を生成する、という流れを挙げている。

⇒ 「返事が遅い」と感じるアプリは、真ん中でこうした処理をはさんでいる可能性がある構成だと、仕様の側から読める。

LLMは会話を覚えていない｜LLM英会話が話の流れを保てる仕組み

LLMが状態を持たないなら、なぜ「さっきの話」が続くのか。

答えは、アプリ側が会話の状態（conversation state）を管理しているからだ。

公式ドキュメントは、その持たせ方を大きく3通り示している。

手で積む＝過去のメッセージを毎回 input の配列に並べて送り直す。公式は「providing additional messages as parameters to your text generation request」と書いている。
Conversations API＝会話を「a long-running object with its own durable identifier」＝固有の永続的な識別子を持つ長命のオブジェクトとして保存する。セッション・端末・ジョブをまたいで使い続けられる、と説明されている。
previous_response_id＝直前の応答のIDを渡して、応答どうしを鎖のようにつなぐ。

ここに、長い会話の挙動を決める一文がある。

IDでつないでいる場合でも「all previous input tokens for responses in the chain」＝その鎖にある過去の入力トークンは、すべて入力トークンとして課金される、と書かれている。

⇒ 履歴はどこかに置きっぱなしになっているのではなく、毎ターンまるごと運ばれている。

保存についても、公式ドキュメントははっきり書いている。

応答のオブジェクトは既定で30日保存され、ダッシュボードのログで見られる。store を false にすればこの挙動は無効にできる、とされている。

いっぽうで会話オブジェクトとその中の項目は30日で消える扱いにはならず、会話に紐づいた応答は期限なしで残る、とも書かれている。

そして訓練利用については「OpenAI does not use data sent via API to train our models without your explicit consent」＝APIで送られたデータを、明示的な同意なしにモデルの訓練には使わない、と明記されている。

LLM英会話の人格と難易度は「指示文」で決まる｜LLMへの命令の書き方

LLM英会話の「先生のキャラ」は、モデルではなく指示文が作っている。

公式ガイドは instructions パラメータを、モデルがどう振る舞うべきかという高い水準の指示を与えるもので、その中には tone（口調）、goals（目標）、examples of correct responses（正しい応答の例）が含まれる、と説明している。

そのうえで「Any instructions provided this way will take priority over a prompt in the input parameter」＝この方法で与えた指示は、input に入れたプロンプトより優先される、と書いている。

公式ガイドの例は極端で分かりやすい。"instructions": "Talk like a pirate."（海賊のように話せ）という1行を足すだけで、同じ質問への答え方が変わる。

英会話アプリの「やさしい先生」「厳しめの面接官」も、まったく同じ層で作られている。

そして、この層には優先順位がある。

役割	公式の説明	LLM英会話での実体
`developer`	アプリ開発者が与える指示。`user` より優先される	アプリが最初に敷いた設定
`user`	エンドユーザーが与える指示。`developer` の後ろに置かれる	あなたの発言
`assistant`	モデルが生成したメッセージ	AIの返事

公式ガイドは、この関係を関数にたとえている。

developer メッセージは関数定義のようにシステムの規則と業務ロジックを与え、user メッセージは引数のように入力と設定を与える、という説明だ。

⇒ あなたが会話の中で「もっとやさしい英語で話して」と頼むのは、user の層からの要求であって、アプリが敷いた developer の層を上書きできるとは限らない。

指示文の中身も、公式ガイドが型を示している。

developer メッセージは通常、Identity（目的・話し方・高い水準の目標）、Instructions（何をして、何を絶対にしないか）、Examples（入力と望ましい出力の例）、Context（追加で渡す情報）の順に並ぶ、と書かれている。

難易度の設定もここに入る。音声モデル向けの公式プロンプトガイドには、応答の長さを調整する例として「For routine questions, give one or two short sentences.」＝定型の質問には短い文を1〜2個で返せ、という指示がそのまま載っている（Prompting GPT-Live）。

話す言語も指示文の担当だ。同じガイドは「Write your prompt in the language you want the model to speak.」＝モデルに話させたい言語で、プロンプトそのものを書け、と指示している。

さらに、例をいくつか見せて型を覚えさせる手法は few-shot learning と呼ばれている。

公式ガイドはこれを「The model implicitly “picks up” the pattern from those examples」＝モデルはその例からパターンを暗黙に拾い上げる、と説明している。

⇒ アプリごとの添削のクセは、この Examples に何が入れてあるかで変わる。モデルの善し悪しだけの話ではない。

LLMが設定を忘れるのはなぜか｜LLM英会話とコンテキストウィンドウ

「さっき決めたはずの設定」が落ちるのには、仕様上の理由が2つある。

1つめは、コンテキストウィンドウという上限だ。

公式ドキュメントは「The context window is the maximum number of tokens that can be used in a single request」＝1回のリクエストで使えるトークンの最大数、と定義し、その中に入力・出力・推論のトークンがすべて含まれると書いている。

そして上限に近づいたときの挙動も明記されている。プロンプトを大きくしすぎると「might result in truncated outputs」＝出力が途中で切られることがある、とされ、さらに「Tokens generated in excess of the context window limit may be truncated in API responses」とも書かれている。

会話が長くなるほど、古いやりとりは押し出される側に回るということだ。

大きさはモデルによって違い、公式ドキュメントは「from the low 100k range up to one million tokens for newer GPT-4.1 models」＝10万トークン台の低いところから、新しいモデルでは100万トークンまで、と幅を示している。

音声でその場のやりとりをする側は、もっと窮屈だ。GPT-Live向けの公式プロンプトガイドは「The live model has a small context window.」＝ライブモデルのコンテキストウィンドウは小さい、と書き、細かい手順はバックエンド側のプロンプトへ置けと指示している。

2つめの理由は、指示文が届く範囲の狭さだ。

公式ガイドは「Note that the instructions parameter only applies to the current response generation request」＝instructions はその回の応答生成にだけ効く、としたうえで、previous_response_id で会話をつないでいる場合、前のターンで使った instructions はコンテキストに残らない、と書いている。

⇒ キャラや難易度は、毎ターン言い直されていなければ薄れていく。忘れっぽいのではなく、そういう作りだ。

長くなった履歴を畳む仕組みも用意されている。

OpenAIのエージェント向け公式ガイドは、運用をOpenAI側に任せる構成の特長として「automatic context compaction」＝自動のコンテキスト圧縮を挙げている（Agents）。

圧縮は要約に近い処理なので、畳まれた側の細かい言い回しは残らない。

LLMに柵をかける｜LLM英会話のガードレールと人のレビュー

LLM英会話では「何を言わせないか」も、モデルの外側で設計されている。

OpenAIの公式ガイドは、自動の検査を guardrails、人が承認する仕組みを human review と呼び分けている（Guardrails and human review）。

定義はそれぞれ「Guardrails validate input, output, or tool behavior automatically.」＝入力・出力・ツールの挙動を自動で検証する、「Human review pauses the run so a person or policy can approve or reject a sensitive action.」＝実行をいったん止めて、人かポリシーが承認か拒否を決める、とされている。

止めたい場面	使う仕組み
本題のモデルが動く前に、許可しない要求を止める	入力ガードレール
最終出力が外に出る前に検証・伏せ字化する	出力ガードレール
関数ツールの引数や結果を前後で確かめる	ツールガードレール
取り消し・編集・コマンド実行など、副作用の前で止める	人による承認

止め方は「tripwire」＝仕掛け線という言葉で説明されている。

公式のサンプルコードは、宿題の代行かどうかを判定する小さな別エージェントを先に走らせ、条件に当たったら本体の実行を打ち切る形になっている。

英会話アプリで「その話題には答えられない」と返ってくる回があるのは、モデルが気を利かせているのではなく、こうした層が先に動いている場合がある。

ただし、この柵は会話全体を覆ってはいない。

「Input guardrails run only for the first agent in the chain.」＝入力ガードレールは、連鎖の最初のエージェントにだけ効く。
「Output guardrails run only for the agent that produces the final output.」＝出力ガードレールは、最終出力を作るエージェントにだけ効く。
「Tool guardrails run on the function tools they’re attached to.」＝ツールガードレールは、取り付けた関数ツールにだけ効く。

公式ガイドは、副作用を起こすツールのすぐ隣に検証を置け、とまで書いている。

⇒ 柵は、立てた場所にだけ立っている。LLMそのものに安全装置が内蔵されているという理解は、仕様の読み方としてずれている。

LLMは事実を保証しない｜LLM英会話の答えをどこまで信じられるか

ここが、LLM英会話でいちばん誤解されやすいところだ。

公式ガイドは、プロンプトエンジニアリングを説明する冒頭でこう書いている。「Because the content generated from a model is non-deterministic」＝モデルが生成する内容は非決定的であるため、と。

同じことを同じように頼んでも、毎回同じ答えが返るとは限らない、という前提が最初に置かれているということだ。

そして公式ドキュメントは「保証しない（do not guarantee）」という言い方を、自分から何度も使っている。

「Prompts do not guarantee exact capture.」＝プロンプトを書いても、正確に聞き取ることは保証されない。だから名前・日付・数字が不明瞭なときは推測せず聞き返せ、という指示例が続く。
「A voice choice does not guarantee a regional accent.」＝声を選んでも、その地域のなまりになる保証はない。
「do not treat model-generated speech as guaranteed verbatim playback」＝モデルが生成した音声を、指定どおりの逐語再生として扱うな。
「A prompt does not guarantee duplicate work will be avoided.」＝プロンプトを書いても、重複した処理が避けられる保証はない。検査はアプリ側に置け、と続く。

いずれもアプリを作る側への注意書きだが、使う側にとっての意味は同じになる。

⇒ 指示文は「お願い」であって、「設定」ではない。

バージョンによる差も、公式が自分で認めている。

「Even different snapshots of models within the same family could produce different results」＝同じ系列のモデルでも、スナップショットが違えば違う結果が出うる、と書かれている。

対策として勧められているのは2つで、本番ではモデルのスナップショットを固定すること、そして挙動を測るテストと評価スイートを作ることだ。

音声エージェントの評価ガイドには、もっと直接的な一文がある。

「A natural-sounding response does not prove that a tool ran or that application state changed.」＝自然に聞こえる応答は、ツールが動いたことも、アプリの状態が変わったことも証明しない。

流暢さと正しさは別の軸で測れ、という指示だ。英語の添削や解説を受け取る側にとっても、この区別はそのまま当てはまる。

公式ガイドは出力の読み取り方についても「It is not safe to assume that the model’s text output is present at output[0].content[0].text」＝モデルのテキスト出力が決まった位置にあると決めてかかるのは安全ではない、と書いている。返ってくる形すら固定ではない。

LLM英会話の作り方は3通りある｜構成の違いが体験の違いになる

LLM英会話は、作り方が1つではない。

公式の Voice agents ガイドは、音声と推論のつなぎ方を3通りに整理している。

構成	公式が挙げる向き先	会話者から見た特徴
GPT-Live	別のバックエンドを持つ全二重（full duplex）の会話	聞きながら話せる。考えている間も会話が止まらない
Realtime API	音声・推論・ツール利用を1つのセッションで扱う	1つのモデルが音を解釈し、判断し、声で返す
Chained voice pipeline	音声とテキストの各段を自分で制御する	途中のテキストを見られる・段ごとに差し替えられる

Realtime API について、公式ドキュメントは「The model works directly with audio, maintains conversation state, and can call tools」＝モデルが音声を直接扱い、会話の状態を保ち、ツールを呼べる、と書いている（Realtime API）。

向いている場面も名指しされていて、「barge-in, low first-audio latency, natural turn taking, and realtime tool use」＝割り込み、最初の音が出るまでの短さ、自然な話者交代、その場でのツール利用、が挙がっている。

この構成では、セッションが音声のターン、ツール、割り込み、引き継ぎを面倒みる、と説明されている。

割り込みの扱いは、性能ではなく指示文の項目として書かれている。

音声モデル向けの公式プロンプト例には「Interruption policy: Stop speaking when the user interrupts. Listen to what they say.」＝ユーザーが割り込んだら話すのをやめて、相手の言うことを聞け、という行がそのまま載っている。

相づちも同じで、「Backchannel policy: Use moderate backchannels.」＝相づちは控えめに、という行が既定のテンプレートに入っている。

⇒ AIが言いかけたところを遮れるか、うなずいてくれるかは、設計と指示文で決まっている項目だと分かる。

評価の進め方も、公式は3段で示している。

Crawl は合成音声による単発の依頼、Walk は人の録音を再生しての単発の依頼、Run は独立した模擬発話者との連続した会話、という順に難度を上げていく形だ。

同じガイドは、入力側の認識について「accents, background noise, language switches, names, and numbers」＝なまり、背景雑音、言語の切り替え、名前、数字、を横断して試験せよとも書いている。

LLM英会話に関するよくある質問

Q. LLMは私の英語を「理解」しているのか。 A. 公式ドキュメントが説明しているのは「プロンプトからテキストを生成する」という働きまでで、理解という言葉は使われていない。生成の性質は「non-deterministic」＝非決定的だと書かれている。

Q. 途中で設定した「ゆっくり話して」が効かなくなるのはなぜか。 A. instructions はその回の応答生成にだけ効き、previous_response_id で会話をつないでいる場合、前のターンの instructions はコンテキストに残らないと公式が明記している。加えて、履歴が伸びればコンテキストウィンドウの上限にも当たる。

Q. AIの文法の指摘は信じていいか。 A. 公式は「A natural-sounding response does not prove that a tool ran or that application state changed.」と書き、自然さと正しさを別々に測れと指示している。流暢に説明されたことと、その内容が正しいことは、仕様のうえで別の話だ。

Q. 話した内容はどこに残るのか。 A. 応答オブジェクトは既定で30日保存され、store を false にすれば無効にできると書かれている。会話オブジェクトに紐づいた項目は30日の期限の対象外で残る、ともある。訓練利用については「明示的な同意なしには使わない」と明記されている。ただし、これはAPIの仕様であって、個々のアプリがどう設定しているかは各アプリの表記を見るしかない。

Q. イギリス英語のなまりで話してほしい。指示すれば変わるか。 A. 公式プロンプトガイドは「A voice choice does not guarantee a regional accent.」＝声を選んでも地域のなまりは保証されない、と書いている。指示は効き得るが、保証はされない。

Q. アプリによって添削のクセが違うのはなぜか。 A. 公式ガイドは、モデルの種類が違えば最良の指示の書き方も変わり、同じ系列でもスナップショットが違えば結果が変わりうると書いている。そこへアプリごとの Identity・Instructions・Examples が乗るので、差が出るのは構造上あたりまえだ。

まとめ｜LLM英会話は「モデルの賢さ」より「渡され方」で決まる

もう一度整理する。

LLMは会話の真ん中の1段だけを担当している。音を文字にする段と、文字を声にする段は別の部品で、公式ガイドはこの3段を分けて説明している。
LLMは前のやりとりを自分では持っていない。公式は「each text generation request is independent and stateless」と書いており、履歴はアプリ側が毎回組み直して渡している。
人格も難易度も言語も、指示文（instructions ／ developer メッセージ）で決まる。あなたの発言は user の層にあり、公式は developer のほうが優先されると書いている。
設定が薄れるのは仕様。instructions はその回だけに効き、コンテキストウィンドウには上限があって、超えた分は切られることがあると明記されている。
LLMは正しさを保証していない。公式ドキュメント自身が「non-deterministic」「do not guarantee」という言葉を繰り返し使い、自然に聞こえることは何の証明にもならないと書いている。