![[AIコンテキスト #1] エージェントはなぜ指示を忘れるのかのカバー画像](/assets/images/posts/04ff8585-2d8d-44f7-87e9-2a975fd9176a/1.jpg)
Claude Codeなどのコーディングエージェントを使っていると、画面下に「Context left until auto-compact: 8%」という警告が表示されます。チャット型AIでは見ない表示です。ところが、この数字が減る理由や0になると何が起きるのかを説明できる人は意外に少ないでしょう。セッションの序盤に「テストには触れないで」と念を押したのに、1時間後にエージェントが平然とテストファイルを修正していたら、ほぼ間違いなくこの数字が関係しています。
この記事は、AIエージェントのコンテキストを原理から実践まで扱う連載の第1回です。/compactや/clearを使うタイミング、サブエージェントで作業を分割する理由といった実践知は、すべて「コンテキストウィンドウは有限」という制約の上に成り立ちます。そこで第1回は基礎から始めます。コンテキストウィンドウとは何か、なぜ無限に拡張できないのかを、トークン、アテンション、KVキャッシュという3つの鍵で解説します。
トークン、AIが文章を数える単位
コンテキストウィンドウの単位は文字でも単語でもなく、トークン（token）です。LLMはテキスト全体を読めず、トークナイザー（tokenizer）が細かく分割した断片の列として受け取ります。分割にはBPE（Byte Pair Encoding）系のアルゴリズムを使います。学習データで頻繁に隣り合う文字列ほど1つにまとめる仕組みです。英語の「the」や「ing」のような頻出の組み合わせは1トークンになり、珍しい単語は複数に分かれます。
ここで韓国語ユーザーに重要な事実があります。トークナイザーの学習データは英語の比率が圧倒的に高いため、同じ内容でも韓国語は英語より通常1.5〜2倍多くのトークンを使います。「コンテキストウィンドウ20万トークン」は英語文書なら長編小説2冊分でも、韓国語文書では体感容量が大きく減る理由です。
コンテキストウィンドウとは、このトークン単位で「モデルが一度に読める最大量」を指します。システムプロンプト、会話履歴、添付文書、モデルが生成中の回答まで、すべてこの上限に収める必要があります。
エージェントのコンテキストはなぜ特に早く埋まるのか
LLMについて最初に知るべきことがあります。モデルは状態を持たない（stateless）機械です。1つのリクエストを処理し終えると、その内容をどこにも保存しません。昨日の会話どころか、直前のターンさえモデルにとっては存在したことがないのです。
では会話はどう続くのでしょうか。答えは拍子抜けするほど単純です。アプリが各ターンで、システムプロンプトから現在までの履歴全体をそのまま再送します。10回目の回答を書くモデルは、前の9回を「記憶」しているのではなく、毎回最初から読み直しているのです。
チャット型AIなら履歴は人間の入力文とモデルの回答だけなので、ゆっくり増えます。エージェントは違います。1ターンにツール呼び出しが伴うからです。ファイルを1つ読めば全内容が、テストを実行すれば数百行の失敗ログが、検索すれば結果全体がコンテキストに積み上がります。ユーザーは「バグを直して」と1行入力しただけでも、エージェントが10個のファイルを読み、ビルドを3回実行すれば、その1ターンで数万トークンが消費されます。コーディングエージェントに残量表示があるのはこのためです。チャットなら数日かかる消費が、エージェントでは1〜2時間で起きるのです。
上限に達すると、アプリは何かを捨てる必要があります。古いターンから削除するか要約に圧縮しますが、セッション序盤に決めた「テストに触れないで」といった指示が押し出されると、モデルはその約束をしていない状態で次のターンを始めます。記憶力が悪くなったのではなく、そもそも記憶はなく、読める範囲の外へ押し出されただけです。
有限である理由その1、アテンションの二乗コスト
では、ウィンドウを1億トークンほどに拡張すればよいのでしょうか。Transformerの中核演算であるアテンション（attention）が壁になります。
アテンションは、新しいトークンを処理する際、そのトークンが前の全トークンとどれほど関連するかを計算する仕組みです。コードにuserという変数があれば、3000行前の宣言部と結び付けられる能力はここから生まれます。LLMが文脈を理解しているように見える理由であり、同時にコストの源です。
すべてのトークンがすべてのトークンを見るため、計算量は長さの二乗に比例します。コンテキストが10倍になると、アテンション演算は100倍です。疎なアテンション、スライディングウィンドウ、FlashAttentionなどの最適化で100万トークンのモデルも登場しましたが、「文脈全体を参照する能力には、長さに応じて急増するコストがある」という本質は変わりません。
有限である理由その2、KVキャッシュというメモリ請求書
問題は演算だけではありません。メモリ側にはKVキャッシュ（Key-Value cache）という別の請求書があります。
モデルが回答を1トークンずつ生成するたびに文脈全体を最初から計算し直すのは非効率です。そこで、トークンごとに計算したアテンションの中間結果（Key・Valueベクトル）をGPUメモリに保存して再利用します。これがKVキャッシュです。問題は、このキャッシュがレイヤーごと、アテンションヘッドごとに蓄積され、コンテキスト長に比例して増えることです。
目安として、700億パラメータ級のオープンソースモデルは、メモリ節約手法（GQA）を使ってもKVキャッシュが1トークンあたり約300KBあります。コンテキストを12万8000トークン埋めると、キャッシュだけで約40GBとなり、モデルの重みとは別に高性能GPU 1枚分のメモリを占有します。コンテキストウィンドウの拡張がソフトウェア設定ではなく、ハードウェアと費用の問題である理由です。
このコストはユーザー料金にそのまま反映されます。LLM APIは入力トークン数に応じて課金します。毎ターン履歴全体を再送する仕組みと合わさることで、長いセッションほど後半に高価で遅くなる理由も説明できます。
まとめ
- コンテキストウィンドウは、モデルが一度に読める最大トークン数です。韓国語は英語より1.5〜2倍多くトークンを使うため、仕様の数字をそのまま信じてはいけません。
- LLMはstatelessです。会話の記憶は毎ターン履歴全体を再送する再読であり、エージェントはツール呼び出しの結果も蓄積するため、チャットよりはるかに早くコンテキストが埋まります。
- ウィンドウが有限なのは、アテンション演算が長さの二乗で増え、KVキャッシュが長さに比例してGPUメモリを占有するためです。コンテキストは能力であると同時にコストでもあります。
次回は、コンテキストは大きいほどよいという通説を崩します。実際には、コンテキストが長いほどモデル性能が低下する現象が複数の研究で確認されています。lost in the middleとcontext rot、仕様上の数字と実効容量が異なる理由を扱います。