基礎

LLMエージェントのコンテキストウィンドウ:何が入るのか、なぜエージェントはルールを忘れるのか

更新日: · Skillaria.Top

LLMのコンテキストウィンドウは、モデルが応答を生成するたびに見ることのできるテキストの全体です。システムプロンプト、指示ファイル、会話の履歴、読み込んだファイル、ツールの出力が含まれます。ウィンドウにはトークンの上限がありますが、注意の質はその上限よりずっと前から落ちます。そのため長いセッションではエージェントがルールを失いがちで、短い指示、コンパクション、計画ファイルを使った新しいセッション、ノイズの多い作業のサブエージェントへの委譲が効果的です。

LLMのコンテキストウィンドウとは

LLMのコンテキストウィンドウとは、モデルが次の応答を生成するときに受け取る入力テキストの全体です。モデルには人間のような記憶がありません。今このタスクについてモデルが「知っている」ことはすべて、このウィンドウの中にあります。ウィンドウに入っていないものは、モデルにとって存在しないのです。

ウィンドウの大きさはトークン、つまり単語の断片で測られます。日本語のテキストは、1文字あたりのトークン数が英語の単語と異なり、同じ内容でも文字数に応じて変わります。現在のモデルのウィンドウは数十万トークンに及ぶので、すべてが入りきるように思えます。しかし実際には、エージェントの場所はあなたが思うより早く埋まり、性能はそれよりさらに早く落ち始めます。

エージェントのウィンドウに入るもの

プログラミング用のエージェントが情報を得る経路は、基本的に3つです。タスクを記述したシステムプロンプト、読み込んだファイルの内容、呼び出したツールの出力です。この3つは同じウィンドウに入り、場所を奪い合います。

内容入るタイミング通常のコスト
エージェントのシステムプロンプトとツールの説明セッションの最初固定費。あなたの操作ではほとんど変わらない
CLAUDE.md、AGENTS.md などの指示ファイルセッションの最初に全文数百から数万トークン。あなたの書き方しだい
あなたのメッセージとエージェントの応答会話全体で蓄積やり取りのたびに増える
読み込んだファイルエージェントがそれを開いたとき大きなファイルは一度に数千トークン
コマンドの出力:テスト、ログ、ビルド、grepツールを呼ぶたびに多くの場合、最も大きく、最も役に立たない部分

重要なのは、これらが自然に消えることはないという点です。20ステップ前には必要だった失敗テストのログも、ウィンドウに残り続け、現在のステップの注意を奪います。長いセッションは、どんどん積み上がる藁の山のようなもので、そこから針を見つけるのはますます難しくなります。

長いセッションでエージェントがルールを忘れる理由

よくある不満があります。セッションの最初はエージェントが CLAUDE.md のルールを几帳面に守っているのに、1時間後には破り始める。エージェントは文字通りに「忘れた」わけではありません。ルールのテキストはまだウィンドウの中にあります。問題は、モデルが長いテキストの中に注意をどう配分するかです。

Lost in the middle

Liu らによる2023年の研究は、言語モデルが長いコンテキストの中で、途中の情報よりも先頭と末尾の情報をよく使うことを示しました。指示ファイルはセッションの最初に読み込まれますが、会話が進むにつれ、その上と下にテキストがどんどん積み上がります。目立っていたルールは、やがてモデルが最も見えにくい領域に沈んでいきます。

ルールがウィンドウに占める割合の低下

新しいセッションでは、指示はコンテキストのかなりの割合を占めます。しかし100回のツール呼び出しの後には、ログ、差分、読んだコードの中に紛れる小さな断片になります。信号は同じでも、周囲のノイズは何十倍にもなります。

新しい例が古いルールを上回る

モデルは、会話の中で最近起きたことに強く影響されます。エージェントがルールを迂回する操作を何度か続けて行い、それがたまたま通ってしまうと、その行動のパターンが履歴の中で、冒頭にある指示の一行より重みを持つようになります。

Context rot:ウィンドウの上限の前に品質が落ちる

Context rot(コンテキストの腐敗)とは、ウィンドウが埋まるにつれてモデルの応答の質が落ちる現象です。技術的な上限にはまだ遠くても起きます。モデルは理論上20万トークンを受け付けても、15万トークンの時点では2万トークンの時より性能が劣ります。細部を取り違え、すでに却下された解決策を繰り返し、指示を失っていきます。

セッションが「腐った」兆候は次のとおりです。

  • 30分前に一緒に却下したアプローチを、エージェントが再び提案する。
  • すでに話題になったファイル名や関数名を取り違える。
  • 最初は自分で実行していた検証を、実行しなくなる。
  • 応答が長くなり、ぼやけていき、余計な「ついでに直しました」が増える。

これに対して、ルールを1つ追加しても効果はありません。新しいルールも同じノイズの中で埋もれてしまいます。必要なのは、ノイズを減らすことです。

コンテキストのコンパクション

コンパクション(圧縮)とは、セッションの履歴を要約することです。モデルが何が起きたかの短い概要を書き、以後の会話は、完全な履歴ではなくその概要をもとに続きます。ウィンドウに空きができ、作業の本質は残ったように見えます。

Claude Code には /compact コマンドがあり、圧縮時に何を重視するかのヒントを渡せます。ウィンドウが上限に近づくと、Claude Code は自動でもコンパクションを行います。/clear は履歴を完全に消して白紙から始めるコマンドです。/context は、ウィンドウの中身が何で埋まっているかを表示します。

/context
/compact 保持: タスクの目標、理由つきで決めたこと、変更したファイル一覧、残っている検証
/clear

コンパクションの危険性

要約は必ず細部を失います。却下した案とその理由、要件の正確な言い回し、途中で軽く合意した細かな点は、要約から抜け落ちるかもしれません。コンパクションの後、エージェントは自分のセッションの他人が書いたメモをもとに作業することになります。そのため、重要なことは会話の履歴ではなく、どんなコンパクションも生き延びるファイルに残してください。

コンパクションか、新しいセッションか

状況対応
タスクはほぼ完了していて、もう少しだけ空きが必要何を残すかのヒントつきでコンパクション
1つのタスクを終え、次のタスクを始める新しいセッション。古い履歴は邪魔になるだけ
セッションが「腐って」、エージェントが堂々巡りをしている状態を計画ファイルに書き出し、新しいセッションを始める
コードやログを長く調べる必要がある調査をサブエージェントに任せる

コンテキストウィンドウを節約する方法

コンテキストの節約はトークンの価格の話ではありません。作業の質の話です。ウィンドウのノイズが少ないほど、タスクとルールに注意が向きます。

1. 短いルーター型の指示ファイル

入口となる CLAUDE.md や AGENTS.md は、毎セッション全文が読み込まれます。600行のファイルは、常にかかる1万から2万トークンの固定費です。テストコマンド、厳格な制約、プロジェクトの地図だけを書き、詳細はテーマ別の文書に分け、エージェントが必要なときだけ開くようにしてください。

2. 必要なときに読み込まれる知識

Claude Code のスキルは、コンテキストにまず短い説明だけが入り、タスクでスキルが必要になったとき初めて全文が読み込まれる仕組みです。デプロイ、マイグレーション、リリースなどめったに使わない手順を、毎セッション費用を払うことなく手元に置けます。

3. ノイズの多い作業はサブエージェントに

サブエージェントは独自のコンテキストウィンドウで作業し、メインのセッションには結果だけを返します。大きなコードの検索、長いログの解析、なじみのないモジュールの調査などを任せると、生の出力が数千行ではなく、結論の数段落として戻ってきます。

4. 静かなツール出力

コマンドの出力はウィンドウの最大の食いつぶし役です。検証コマンドは、成功したときは1行だけ表示し、失敗したときは要点だけ、つまり失敗したテストとそのメッセージだけを表示するように設定してください。ビルドログの全文ではなく。

# 騒がしい:実行のたびに数千行がウィンドウへ
pytest -v

# 静か:成功時は1行、失敗時は失敗したテストだけ
pytest -q --tb=short

# ログは全文ではなく、末尾とエラーだけ
tail -n 50 app.log | grep -i error

5. 1つのタスクに1つのセッション

無関係な3つのタスクを1つのセッションで続けないでください。最初のタスクの履歴は3つ目には役に立ちませんが、場所を取り、エージェントを混乱させます。終わったら結果を記録し、新しいセッションを開いてください。

6. 履歴ではなくファイルに状態を残す

コンパクションや新しいセッションを生き延びるべきことは、すべてリポジトリに書いてください。目標、理由つきで決めたこと、却下した案、完了したこととその検証方法、次のステップ。例えば PLAN.md や PROGRESS.md です。そうすれば新しいセッションは要約ではなく正確な文書から始まり、履歴を安心して消せます。

# PROGRESS.md
## 目標
割引の計算を、整数の最小通貨単位(銭・分単位)に変更する

## 完了(検証済み)
- app/payments/discount.py: float を int に変更、make test が緑
- マイグレーション 041 を追加、ローカルに適用済み

## 決定事項
- 丸め方式は銀行丸め。決済プロバイダーに合わせる

## 却下した案
- モデルに Decimal を使う: Webhook のシリアライズが壊れる

## 次のステップ
注文フローの E2E シナリオを更新し、make e2e を実行

重要なルールはウィンドウの中だけに置かない

どれほど整った文脈でも、ルールの遵守を保証はできません。ウィンドウのテキストは、モデルに影響を与えるものであって、実行される禁止事項ではありません。違反が許されないなら、ルールは機械的に検査されるべきです。Claude Code にはそのための仕組みがあります。エージェントのイベントで実行され、操作をブロックできるフック、そして特定のツールやコマンドを禁止する権限の設定です。リンター、テスト、CI は、エージェントのウィンドウの中で何が起きていても独立して働きます。

ハーネスの良いルールは次のとおりです。自動で検査できるものはすべて自動で検査し、コンテキストに残すのは判断を必要とするものだけにします。

まとめ

LLMのコンテキストウィンドウは、エージェントがあなたのタスクを見ることのできる唯一の場所です。そしてそれは思っているより速く埋まります。指示、履歴、読んだファイル、コマンドの出力が、セッションの終わりまで積み上がっていきます。品質は技術的な上限よりずっと前に落ち、中盤にあるルールは埋もれ、コンパクションは場所を確保する代わりに細部を失います。指示は短く保ち、必要な知識は必要なときに読み込み、ノイズの多い作業はサブエージェントに任せ、状態はファイルに残し、重要なルールはフックと検査で支えてください。コンテキストの扱い方は、ハーネスエンジニアリングのコースで実践的に扱っています。

よくある質問

Claude のコンテキストウィンドウは何トークンですか?

モデルやプランによって異なります。標準的な目安は約20万トークンですが、モデルや設定によってはそれより大きい場合もあります。正確な値は、使用するモデルについての Anthropic の公式ドキュメントで確認してください。

大きなウィンドウを持つモデルなら、ルールを忘れる問題は解決しますか?

一部だけです。場所は増えても、lost in the middle や context rot の影響はなくなりません。大きなウィンドウは、短い指示ときれいなセッションの代わりにはなりません。

エージェントが重要なルールを破ったとき、メッセージでそのルールを繰り返すべきですか?

1回の注意喚起は効果があります。コンテキストの末尾にある新しいテキストは、モデルがより良く見るからです。しかし何度も注意が必要なら、そのルールを検査かフックで仕組み化すべきです。

Claude Code でコンテキストが何に使われているかは、どう確認しますか?

/context コマンドで、システムプロンプト、ツール、メモリファイル、メッセージ履歴がどれだけ場所を取っているかを表示できます。肥大化した CLAUDE.md や長い履歴が、ウィンドウを圧迫しているかを素早く確認できます。

コンパクションで最初に失われるものは何ですか?

会話の中にしか存在しなかった合意事項です。却下した案、要件の細かな言い換え、小さなニュアンスなどです。リポジトリのファイルに書かれたものは、エージェントが読み直せます。