第7章: コンテキストウィンドウ ── 有限の机の広さ
Claude Code を使い始めて 30 分。最初は機嫌よく動いていたエージェントが、なぜか急に挙動がおかしくなる。
- さっき自分で書き換えたファイルを、もう一度頭から読み直し始める
- 序盤に「pnpm を使え」と伝えたのに、終盤で
npm installを叩こうとする - 同じテストを 3 回連続で走らせる
そして画面の端に、小さな警告が出ている。
Context left: 28%
Cursor の Agent モードでも、Codex CLI でも、Devin でも、長く粘ると遅かれ早かれ同じ場所にたどり着く。 机が、狭くなってきたのだ。
LLM の “賢さ” には、人間の集中力の限界とよく似た 物理的な天井 がある。 この章は、その天井 ── コンテキストウィンドウ ── を真正面から扱う。
7.1 そもそも、なぜ “机” の話を一章割いてするのか
前章までで見た通り、エージェントは LLM・道具・ハーネスの三角形で動く。 そして第3章で見た通り、ループは think → act → observe のリズムで、1 ターンごとに何かが積み上がっていく。
ここで素朴な疑問が湧くはずだ。
ループが回るたびに、何が、どこに積み上がっているのか?
答えは 入力テキスト だ。LLM はそもそも記憶を持たないので、第1章のチャットボットと同じく、毎ターン過去の全部を入力として渡し直すしかない。
ChatGPT で 10 往復するのと、Claude Code で 10 ターン回すのとでは、1 ターンあたりの入力サイズが桁違いになる。ループする という設計を採った瞬間に、入力サイズの問題が一気に前面に出てくる。
ループするということは、毎ターン入力が線形に膨らむということ。 コンテキストウィンドウは、そのループ設計と切っても切れない兄弟概念だ。 チャットボットの時代には脇役だったこの概念が、エージェントの時代に主役級に格上げされたのは、この理由による。
7.2 コンテキストウィンドウとは ── LLM の “机の広さ”
定義を入れておく。
コンテキストウィンドウ (context window)LLM が一度に読み込めるトークン数の上限。入力 + その回の出力 の合計トークン数で測られる。 大事なのは「入力の上限」ではないこと ── 入力で机を埋めると、LLM が答えを書く余地がなくなる。
「トークン」は第1章で軽く触れたが、ここで改めて感覚を持っておきたい。
| 何か | おおよそのトークン数 |
|---|---|
| 短いユーザー指示 1 行 | 数十 |
| 100 行のソースファイル | 1,000 〜 2,000 |
| pytest の失敗ログ | 数百 〜 数千 |
| プロジェクト全体の概要 (CLAUDE.md) | 数千 |
| エージェント本体のシステムプロンプト | 数千 〜 1 万超 |
| 800x600 のスクリーンショット 1 枚 | 1,000 〜 2,000 相当 |
「1 ファイル Read しただけで、入力が 1,000 トークン重くなる」── この感覚が、この章を読み解く鍵になる。
7.3 200k、1M ── プロダクトごとの机のサイズ
主要 LLM の 2026 年初頭時点の コンテキストウィンドウを並べてみよう。数値は世代で動くので、桁感だけ覚えればいい。
| モデル | コンテキストウィンドウ |
|---|---|
| GPT-4o 系 | 128k トークン |
| Claude Sonnet 4.6 / Opus 4.5 標準 | 200k トークン |
| Claude Opus 4.5（1M 拡張） | 1M トークン |
| Gemini 1.5 / 2.0 系 | 1M トークン（実験的に 2M） |
各エージェントプロダクトは、内部的にこのどれかを使っている。
- Claude Code / Cursor / Cline は主に Claude 系（200k〜1M）
- Codex CLI は GPT 系（128k）
- Devin / OpenHands / Aider はモデルを切り替えられる
「机が広いプロダクトほど偉い」── と思いたくなるが、ここで踏み込んでおきたい疑問がある。
200k あっても足りなくなるのに、1M トークンに広げれば全部解決するのか?
答えは No だ。広い机には広い机なりの問題がある（7.6 節で詳述）。 まずは「なぜ 200k あってもすぐ足りなくなるのか」を見ておこう。
7.4 ループが回るたびに、机に紙が積まれる
ターン軸で入力サイズの推移を見るのが、いちばん直感的だ。
ここで効いてくる事実がいくつかある。
- システムプロンプトはどのターンでも先頭に乗る（数千〜1 万トークン）
- 過去の道具呼び出しと結果は、消されない限り全部残る
- LLM は毎ターン、机の上の紙を全部読み直してから 次の続きを書いている
具体的にどんなターン操作がどれくらい机を圧迫するか、表にしておく。
| 操作 | 机に積まれる量 |
|---|---|
Read 大きめのファイル 1 つ | 1,000 〜 5,000 tok |
Bash でビルドログ全文を返す | 2,000 〜 20,000 tok |
WebFetch で記事 1 本 | 3,000 〜 10,000 tok |
| スクリーンショット 1 枚を貼る | 1,000 〜 2,000 tok |
| ターミナルから巨大な JSON が返る | 数万 tok もありうる |
「Bash(npm install) を呼んだだけで、出力ログが机を 1/4 埋めた」── これは Claude Code でも Codex CLI でもごく普通に起きる。
7.5 200k なのに、なぜ足りないのか
「200k トークンって、原稿用紙でいえば 500 枚分くらいでしょ。1 タスクで使い切れる気がしないんだけど」と思った人へ。
実際の現場ではこういう積み方になる。
- システムプロンプト + ツール定義 で 1 万トークン消費して始まる
- プロジェクトメモリ（
CLAUDE.md/AGENTS.md、第8章で詳述）で +数千トークン - ユーザーが「このリポジトリ全体を理解して直して」と頼む
- エージェントが 10 個のファイルを
Readして +2 万トークン Bash(pnpm test)でログ +1 万トークン- もう一度ファイルを
Readし直して +1 万トークン - デバッグログを
Bashで取って +1.5 万トークン - …
10 ターンも回らないうちに 5 万、8 万トークンに達するのは普通のことだ。
30 分粘ると 150k を超える。これが 200k のモデルでの「Context left: 28%」の正体である。
コンテキストウィンドウは、人間の集中力でいえば “未読の紙の山” だ。 机の引き出しではない。捨てない限り、机の上に積まれっぱなしになる。 机の広さ自体が大きくなっても、紙を積むスピードがそれ以上に速ければ、いずれは満杯になる。
7.6 広い机にも病気がある ── context rot
「だったら 1M トークンの Gemini や Claude Opus 4.5 の拡張版を使えば大丈夫では?」
ここで本書がもうひとつ伝えておきたい、重要な概念がある。
context rot（コンテキスト汚染）入力が長くなるほど、LLM の 回答精度や指示追従性が劣化していく現象。 「文脈の腐敗」と訳されることもある。机が広くてもなお現れる、LLM 固有の弱点。
具体的な症状はこうだ。
- 序盤に決めた仕様を、終盤で無視し始める（「pnpm を使え」と伝えたのに
npmを叩く） - CLAUDE.md / AGENTS.md のルールが守られなくなる
- 同じファイルを何度も
Readし直す（前に読んだことを忘れている） - ツール選択が下手になる（前は的確だったのに、的外れな道具を呼び始める）
- 回答が冗長になる、あるいは逆にやけに雑になる
「1M トークン載るぞ!」とうたうモデルでも、実用的な精度を保てる長さはせいぜい数万〜十数万トークン だと、現場では経験的に言われている。 これはハーネスの問題ではなく、LLM そのものが長い文脈で性能を落とす という、現代 LLM の構造的な弱点だ。
広い机を渡されると、人間も判断が鈍る。 書類が 500 枚積まれた机で重要事項を即決しろと言われたら、誰でも 5 枚だけの机より下手な判断をする。 LLM もそれと似たことが起きる。机の広さと、机の上で出せる判断の質は、ある段階から反比例する。
Claude Code が Context left: 30% のあたりから /compact を勧め始めるのは、この経験則に基づいている。
机を埋めるのが怖い のではなく、机が埋まる前に判断が鈍る のが怖いのだ。
7.7 文脈量と判断の質 ── ループ長との関係
第3章の think → act → observe を思い出してほしい。 ループが長く回るほど、observe の累積で机が埋まる。すると次の think が鈍り、act の選択が悪くなる ── 悪くなった act の結果がさらに机を埋める ── という 負のスパイラル に入りうる。
これを断ち切る打ち手は、おおまかに二つに分けられる。
| 戦略 | 何をするか | 各プロダクトでの呼び名 |
|---|---|---|
| 圧縮 (compaction) | これまでの履歴を要約してまとめ直し、机を整理する | Claude Code の /compact、Cursor の自動要約 |
| 分割 (delegation) | 別の机（別のループ）に独立した文脈で作業させ、結果だけ受け取る | サブエージェント、/clear で仕切り直し |
ここでは名前だけ覚えておけばいい。第8章で メモリ階層と圧縮 を、第9章で サブエージェントによる分割 を、それぞれ正面から扱う。
机は無限ではないし、広くても腐る。 だからこそエージェントには「圧縮」と「分割」という二つの逃げ道が、ハーネス側で必ず用意されている。 プロダクト名（Claude Code / Cursor / Codex / Devin）の違いを超えて、この二つの逃げ道はどこにでも存在する。ループ設計の必然 だからだ。
7.8 この章の振り返り
- エージェントの入力は ループが回るたびに線形に膨らむ（system + 過去ターン全部 + 今回入力）
- コンテキストウィンドウ は入力＋出力の合計の上限。机の広さの比喩で掴むとよい
- 代表モデルは 128k〜200k、拡張版で 1M トークン。広いほど良いわけではない
Read/Bash/WebFetch/ 画像はそのまま机に積まれ、10 ターンで数万トークン消費は普通- context rot = 長い文脈で精度・指示追従性が劣化する現象。机が広くてもなお現れる
- 机の広さと判断の質はある段階から反比例する ── これが文脈量を気にする本当の理由
- 打ち手は二つ ── 圧縮 (compaction) と 分割 (サブエージェント / クリア)。次章以降で詳述
この章で読めるようになるツイート / ブログ
- 「200k あるはずなのに、150k 越えたあたりから挙動が雑になる」
→ context rot を踏んでいる。
/compactか/clearで席を立て直すタイミング - 「1M context モデルが出たから、もう要約とかいらないでしょ」 → 載るかどうかと精度を保てるかは別問題。広い机にも腐敗はある
- 「
Bash(pnpm install)を 1 回呼んだら、Context leftが一気に減った」 → ビルドログ全文がそのまま机に積まれた結果。道具の出力サイズも文脈コスト
次章は、有限な机という制約の上で、エージェントがどうやって「長く粘れる」ようにしているか ──
プロジェクトメモリ・セッションメモリ・外部記憶 からなる メモリ階層 を腑に落とす。
CLAUDE.md / AGENTS.md / .cursorrules がプロダクト横断で同じ役割を担っている、その正体に踏み込む。