第4章: コンテキストウィンドウ ─ 有限な「机」の上で考える

4.1 そもそも、なぜ “context” を気にするのか

第1章で見たように、エージェントはループする。 ループするということは、過去のやり取りが 次のターンに持ち越される ということだ。

ChatGPT を 1 回叩いて答えをもらうだけなら、入力は短い質問 1 個で済む。 ところが Claude Code はこうなる:

1. ユーザー: 「fibonacci.py のバグを直して」
2. LLM: 「Read(fibonacci.py) を呼ぶ」
3. 道具: ファイル中身 80 行を返す
4. LLM: 「Bash(pytest) を呼ぶ」
5. 道具: テスト失敗ログ 200 行を返す
6. LLM: 「Edit(...) を呼ぶ」
7. …

6 ターン目に LLM が見ているのは、6 ターン目の入力だけではない。 1〜5 ターン目の全部 ── ユーザー指示、ファイル中身、テストログ、過去の道具呼び出し ── が 頭から積み上がって 入力されている。

4.2 トークンという最小単位

ここで一度、第1章でぼかしておいた「トークン」を本格的に定義する。

トークン (token)

LLM がテキストを扱うときの最小単位。文字でも単語でもなく、その中間 ── おおよそ「英単語 1 つ」「日本語 2〜3 文字」「記号 1 つ」程度の細切れの文字列。 LLM は内部的にテキストを丸ごと扱っているのではなく、トークン列に分解してから 処理する。

たとえば英語の Hello, world! は 4 トークン程度、日本語の こんにちは は 5 トークン前後になる。コードはもう少し変動が大きく、関数 1 つで数十〜数百トークンに収まることが多い。

正確な数値を覚える必要はない。重要なのは次の感覚だ。

「1 ファイル読んだだけで、入力が 1,000 トークン重くなる」── この感覚を持っておくと、後の話が一気に腑に落ちる。

4.3 入力も出力も、同じ “机” の上に乗っている

LLM の世界で context window と呼ばれるのは、モデルが一度に見られるトークンの最大数 のこと。 ここで多くの初学者が誤解する点がある。

直感的に書くとこういう関係になる。

[ context window 全体 ]
├── input tokens (system prompt + 過去ターン全部 + 今回のユーザー入力 + 道具の出力)
└── output tokens (LLM が今から書く分)

2026 年初頭時点の代表的なモデル の context window はこのくらいだ（数値は世代で動くので大枠だけ覚える）。Claude Opus 4 系を含め 1M トークン context が一般化 しつつあるのが、この時期の大きな変化点だ。

「100 万トークン載るならもう context は気にしなくていいのでは？」── と思った人は、この章の残りで答えが分かる。広い机にも、固有の問題がある。

4.4 ループが回るたびに膨らむ ── 図で掴む

第1章で出した「LLM + 道具 + ハーネス」の図を、ターン軸 で並べ直してみよう。

ポイント:

• system prompt はどのターンでも毎回頭に乗る（次章で詳述）
• 過去の道具呼び出しと結果 はターンが進むほど積み上がる
• LLM は毎ターン 過去の全部を読み直して から続きを書いている

ChatGPT で 10 回チャットするのと、Claude Code で 10 ターン回すのとでは、1 ターンあたりの入力サイズが桁違い。 これが、エージェントの世界で context window がすぐ問題になる構造的な理由だ。

4.5 prompt caching ── 「同じ前置きを毎回課金するな」

ここで素直な疑問が出てくる。

「毎ターン system prompt と過去の道具結果を全部読み直すなら、毎回そのぶんの料金を取られる ことになるのでは？」

その通りで、対策が必要になる。それが prompt caching だ。

prompt caching

「直前と同じプレフィックス（入力の先頭部分）」が来たとき、モデル側が前回の計算結果を再利用する仕組み。 キャッシュが効いた部分は 入力料金が大幅に割引（おおよそ 1/10 程度）になり、応答速度も上がる。 キャッシュには寿命 (TTL) があり、Anthropic API では既定で約 5 分 で消える。

Claude Code は意図的に、入力の構造をキャッシュが効きやすいように組んでいる:

[system prompt]            ← ほぼ不変。キャッシュが効く
[CLAUDE.md など長期記憶]    ← セッション中はほぼ不変。キャッシュが効く
[過去のターン全部]          ← 直前のターンまで同じ。キャッシュが効く
[今回新しく増えた部分]      ← ここだけ毎回計算される

つまり、毎ターン 「机の上の昨日までの内容」は再利用 し、「今日積んだぶんだけ計算する」。 このおかげで、context が長くなっても料金と速度の劣化がある程度抑えられている。

4.6 context rot ── 広い机にもある問題

「広い context window さえあれば長丁場も大丈夫」と思いきや、もう一つの壁がある。

context rot

入力が長くなるほど、LLM の 回答精度や指示追従性が劣化 していく現象。 「文脈の腐敗」と訳されることもある。技術的には、長文脈の中の重要情報を LLM がうまく拾えなくなる現象が主な原因とされる（その理論的背景と研究は 第15章で詳しく扱う）。

具体的にはこういう症状で現れる:

• 序盤に決めた仕様を、終盤で 無視し始める
• CLAUDE.md に書いたルールを 守らなくなる
• 同じファイルを 何度も読み直す（前に読んだことを忘れている）
• ツール選択が 下手になる（前は的確だったのに、的外れな道具を呼び始める）

100 万トークン載るモデルでも、実用的な精度を保てる長さは数万〜十数万トークン にとどまる、と経験的に言われている。 Claude Code が Context left: 30% のあたりから /compact を勧め始めるのは、この経験則を踏まえている。

4.7 ではどうするか ── 圧縮と分割の二大戦略

机が満杯になってきた、あるいは context rot が出始めた ── そのときに使う打ち手は、おおまかに二つに分けられる。

ここでは名前だけ覚えておけばいい。詳しい使い方と判断基準は第Ⅱ部に譲る。

• compaction = 第Ⅱ部「コマンド: セッション制御」グループ (/compact) で詳述
• /clear による仕切り直し = 第Ⅱ部「コマンド: セッション制御」グループで詳述
• sub-agent によるコンテキスト分裂 = 第9章で詳述

4.8 この章の振り返り

• エージェントの入力は ループが回るたびに線形に膨らむ（system + 過去ターン全部 + 今回入力）
• LLM はテキストを トークン という単位に分解して扱う。日本語 2〜3 文字や英単語 1 個程度
• context window は入力＋出力の合計の上限。入力で埋めると出力の余地がなくなる
• 代表モデルは 128k〜200k、拡張版で 1M トークン。広いほど良いわけではない
• prompt caching で「同じプレフィックス」を再利用すると、料金が約 1/10、応答が高速化。TTL は約 5 分
• context rot = 長文脈で精度・指示追従性が劣化する現象。広い机にも腐敗はある
• 打ち手は二つ ── 圧縮 (compaction) と 分割 (sub-agent / clear)

この章で読めるようになるツイート / ブログ

• 「200k あるはずなのに、150k 越えたあたりから挙動が雑になる」 → context rot を踏んでいる。/compact か /clear で席を立て直すタイミング
• 「席を 10 分外したら、戻ったとき 1 ターン目だけ重くなった」 → prompt caching の TTL (約 5 分) が切れて、巨大なプレフィックスを再計算しているサイン
• 「1M context モデルが出たから、もう /compact いらないでしょ」 → 載るかどうかと 精度を保てるか は別問題。context rot はモデルが大きくなっても残る

次章はこの章で何度も登場した system prompt を、構造編の主役として真正面から扱う。 「同じ Claude モデルなのに、Claude Code と ChatGPT で人格が違って見える」── その正体に踏み込む。