トークンはAI英会話の会話をどう区切っているのか。長さの上限が生む挙動を分解した

公開日 2026年9月17日(木) 13:16更新日更新なし

AI英会話を続けていると、あるところで相手の記憶が急に薄くなったり、返事が途中で切れたりすることがある。

これは気のせいでも不具合でもなく、トークンという単位で会話に上限が引かれていることから来ている。

トークンは、AIが言葉を扱うときの最小単位だ。

そして会話の長さ、覚えていられる範囲、返事の長さのすべてが、この単位で数えられている。

ややこしいのは、トークンが「文字数」でも「単語数」でもないことだ。

この記事では、AIの部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、トークンが会話をどう区切っているかを開けていく。

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

TOC

【結論】トークンはAI英会話の会話を「かたまり」で数えている単位だ

先に答えを置く。

OpenAIの公式ドキュメントは、トークンをこう説明している。

「This memory limit is called a context window, which is defined in terms of tokens (chunks of data you pass in, from text to images).」（Prompt engineering・OpenAI）

訳せば、コンテキストウィンドウという記憶の上限はトークン（渡すデータのかたまり。テキストから画像まで）で定義される、ということだ。

別の公式ドキュメントは、トークンの役割をさらに具体的に書いている。

「Model inputs and outputs are metered in tokens, which are parsed from inputs to analyze their content and intent and assembled to render logical outputs.」（Conversation state・OpenAI）

⇒ 入力も出力もトークンで計測されている。会話は「文」ではなく「トークンの列」として処理されている。

あなたが話した英語は、文字起こしされてトークンに分解される。
AIの返事も、トークンを1つずつ並べて作られる。
会話の履歴も、トークンの量として積み上がっていく。

だから「どれくらい話したか」は、体感の時間ではなくトークンの量で決まる。

トークンはAI英会話の会話でどこに積み上がるのか

公式ドキュメントは、トークンを役割で3つに分けている。

Conversation state のページが挙げているのは、次の3つだ。

種類	公式の説明	AI英会話でいうと
Input tokens	inputs you include in the `input` array	あなたの発言と、それまでの会話履歴
Output tokens	tokens generated in response to your prompt	AIが返してくる英語
Reasoning tokens	used by the model to plan a response	返事を組み立てるためにモデルが内部で使う分

ここで大事なのは、3つ目のReasoning tokensだ。

これは画面には出てこないのに、上限は消費する。

公式も「This max tokens number includes input, output, and reasoning tokens.」と書いている。

⇒ 見えている文章の量だけでは、実際に使われたトークンの量は分からない。

出力側には、入力とは別に独立した上限が置かれている。

公式の例示はこうだ。「Each model has different limits for output tokens. For example, gpt-4o-2024-08-06 can generate a maximum of 16,384 output tokens.」

⇒ 「返事が長くならない」のは、性格ではなく出力トークンの上限が効いている場合がある。

トークンの上限＝コンテキストウィンドウがAI英会話の記憶を決めている

AI英会話が「さっき言ったこと」を覚えていられる範囲は、ここで決まる。

公式の定義文はこうだ。

「The context window is the maximum number of tokens that can be used in a single request.」

そして具体的な数も公式に書かれている。

「For example, gpt-4o-2024-08-06 has a total context window of 128k tokens.」

別の公式ページには、モデルによる幅も書かれている（Prompt engineering・OpenAI）。

「Models have different context window sizes from the low 100k range up to one million tokens for newer GPT-4.1 models.」

公式に書かれている値	意味
128k tokens（`gpt-4o-2024-08-06` の総コンテキストウィンドウ）	1回のリクエストで使えるトークンの総量
16,384 output tokens（同モデルの出力上限）	1回の返事で作れるトークンの上限
low 100k 〜 one million tokens（モデルによる幅）	製品によって記憶の広さが桁で違う

⇒ 同じ「AI英会話」でも、裏で動いているモデルが違えば、覚えていられる会話の長さは桁で変わる。

アプリの画面には、この数字はまず出てこない。

だが挙動の差として、必ず表に出てくる。

トークンが上限を超えるとAI英会話はどう振る舞うのか

ここが、いちばん体感に直結する部分だ。

公式は、上限を超えたときに何が起きるかを2か所で書いている。

1つ目。「If you create a large prompt—often by including extra context, data, or examples for the model—you run the risk of exceeding the allocated context window for a model, which might result in truncated outputs.」

2つ目。「Tokens generated in excess of the context window limit may be truncated in API responses.」

truncated は「切り詰められる」という意味だ。

⇒ 上限を超えたとき、エラーで止まるのではなく、黙って途中で切られる形になりうる。

長い会話のあとでAIの返事が尻切れになる。
序盤で自己紹介した内容を、後半で忘れているように見える。
同じ質問を繰り返されたり、設定した役割から外れたりする。

これらは、トークンの上限という1つの原因から説明できる範囲の現象だ。

ただし、実際のアプリがどう処理しているかは製品ごとの実装によるので、すべてがこれで説明できると言い切ることはできない。

トークンを減らすためにAI英会話の裏で走っている「圧縮」

会話が長くなり続ける以上、上限にはいつか当たる。

そのための仕組みが公式に用意されている。コンパクション（compaction）だ（Compaction・OpenAI）。

公式の説明はこう始まる。

「To support long-running interactions, you can use compaction to reduce context size while preserving state needed for subsequent turns.」（Compaction・OpenAI）

⇒ 会話の続きに必要な状態だけを残して、文脈のサイズを減らす仕組みだ。

起動の条件も数字で決まっている。

「When the rendered token count crosses the configured threshold, the server runs server-side compaction.」

設定項目の名前は compact_threshold で、公式のサンプルコードでは 200000 という値が使われている。

圧縮された結果は、人が読める形では返ってこない。

公式はこう書いている。「The returned compaction item carries forward key prior state and reasoning into the next run using fewer tokens. It is opaque and not intended to be human-interpretable.」

方式	公式の説明（要点）	いつ走るか
サーバー側コンパクション	`context_management` に `compact_threshold` を設定して有効化する	トークン数がしきい値を越えたとき自動
スタンドアロンの compact エンドポイント	「You send a full context window … and the endpoint returns a new compacted context window」	作り手が明示的に呼んだとき

後者には制約も付いている。

「The window you send to /responses/compact must still fit within your model’s context window.」

⇒ 圧縮するにも、いったん上限の中に収まっている必要がある。無限には伸ばせない。

そして公式は、コンパクションの目的を「quality, cost, and latency」のバランスと書いている。

品質・コスト・応答の速さは、トークンの量を通じて同じ1本の線でつながっている。

トークンは会話を続けるたびにAI英会話で数え直されている

会話を継続する仕組みにも、トークンの話が絡んでいる。

公式には previous_response_id という、前の返事にひもづけて会話を続ける方法がある。

一見すると、履歴を毎回送り直さなくて済むように見える。

だが公式はきっぱりこう書いている。

「Even when using previous_response_id, all previous input tokens for responses in the chain are billed as input tokens in the API.」

⇒ 書き方を変えても、会話が長くなればトークンの積み上がりは消えない。

これは、AI英会話のセッションが一定の長さで区切られがちな構造的な理由の1つになる。

ついでに、履歴の保存についても公式は明記している。

「Response objects are saved for 30 days by default.」「You can disable this behavior by setting store to false when creating a Response.」

保存するかしないかは、アプリを作る側が選べるようになっている。

トークンはAI英会話の音声モードでも会話を区切っている

音声で話すモードには、テキストにはない区切りの問題がある。

途中で割り込んだとき、AIが「どこまで言ったことになっているか」を決め直す必要があるからだ。

公式はこれを truncation（切り詰め）と呼び、こう説明している。

「We call this truncating the model’s last response, that is, removing the unplayed portion of the model’s last response from the conversation.」（Realtime conversations・OpenAI）

⇒ まだ再生されていない部分は、会話の履歴から削られる。

削る位置はミリ秒で指定される。公式のサンプルには "audio_end_ms": 1500 という値と、「truncate audio after 1.5 seconds」というコメントが並んでいる。

そしてここに、知っておくと納得のいく制約がある。

「The realtime model doesn’t have enough information to precisely align transcript and audio, and thus conversation.item.truncate will cut the audio at a given place and remove the text transcript for the unplayed portion.」

⇒ 音声と文字起こしは正確には対応づけられておらず、割り込んだ分のテキストはまるごと消える扱いになる。

接続方式によって、誰がこれをやるかも変わる。

WebRTCとSIP＝公式いわく「The server will automatically truncate unplayed audio when there’s a user interruption.」サーバーが自動でやる。
WebSocket＝「the client manages audio playback, and thus must stop playback and handle truncation.」アプリ側が自前でやる必要がある。
つまり割り込み後の会話の噛み合い方は、接続方式と実装で変わる。

同じサービス名でも体験が違う理由は、こういうところに潜んでいる。

トークンの数はAI英会話の外でも自分で数えられる

トークンは概念だけの話ではなく、実際に数えられる。

公式ドキュメントは、そのための道具を案内している（Conversation state・OpenAI）。

「Use the tokenizer tool, built with the tiktoken library, to see how many tokens are in a particular string of text.」

さらに「You can estimate the number of tokens your messages will use with the tokenizer tool.」とも書かれている。

⇒ 自分が書いた英文が何トークンになるかは、実際に測れる数字だ。

ここまでを踏まえると、AI英会話の挙動の見え方が変わる。

体感している現象	トークンの側から見た説明
長く話すと前半を忘れる	会話全体がコンテキストウィンドウの上限に近づいている
返事が急に短い／途中で止まる	出力トークンの上限、または切り詰めが効いている
設定した役割から外れていく	最初の指示が積み上がった履歴の中で埋もれている
セッションが一定時間で区切られる	履歴が毎回入力として数え直される構造による
割り込んだあと話が噛み合わない	未再生部分の切り詰めと、文字起こしの対応づけの限界

どれも「AIの頭が悪い」わけではなく、上限の設計がそのまま表に出た形だ。

トークンの上限とうまく付き合うためにAI英会話で何ができるか

ここからは、公式仕様から言えることだけを並べる。効果を約束する話はしない。

1セッションを長く引っぱらない。 履歴はトークンとして積み上がり、公式は継続時も「all previous input tokens … are billed as input tokens」と明記している。
大事な設定は会話の後半でもう一度言う。 上限に近づくほど、序盤の指示は相対的に埋もれる位置に来る。
返事が尻切れなら、短く返すよう頼む。 出力トークンにはモデルごとの上限があると公式が書いている。
話題を変えるときは会話を分ける。 前の話題のトークンを引きずらずに済む。
「忘れた」を実力の話にしない。 記憶の範囲は設計値であり、学習者の側の問題ではない。

なお、公式はコンパクションについて遅延の助言も添えている。

「After appending output items to the previous input items, you can drop items that came before the most recent compaction item to keep requests smaller and reduce long-tail latency.」

⇒ トークンを減らすことは、応答の速さにも効く設計になっている。

トークンに関するよくある質問

Q. トークンは文字数のことか。 A. 違う。公式はトークンを「chunks of data you pass in, from text to images」と説明しており、テキストだけの単位でもない。公式が案内しているのは換算式ではなく、実際に数えるための tokenizer tool のほうだ。

Q. AI英会話が前半の話を忘れるのはなぜか。 A. コンテキストウィンドウは「the maximum number of tokens that can be used in a single request」と定義されており、会話が長くなるほど古い部分が上限の外に出ていく構造になっている（出典）。

Q. 返事が途中で切れるのはバグか。 A. 公式は「Tokens generated in excess of the context window limit may be truncated in API responses.」と書いている。上限を超えた分が切り詰められるのは、仕様として想定されている挙動だ。

Q. 会話を要約して続ける機能があると聞いた。 A. 公式にはコンパクションという仕組みがあり、「reduce context size while preserving state needed for subsequent turns」と説明されている。ただし返ってくる圧縮結果は「opaque and not intended to be human-interpretable」で、人が読める要約ではない。

Q. 自分の英文が何トークンか知る方法はあるか。 A. 公式は tiktoken ライブラリで作られた tokenizer tool を案内しており、「to see how many tokens are in a particular string of text」と用途を明記している。