![[AIコンテキスト #4] CLAUDE.mdはなぜ短くすべきか、AIエージェントの常時ロードコンテキスト設計のカバー画像](/assets/images/posts/5c28e3e8-171c-46b9-a58c-3251910b2fe3/1.jpg)
第3回では、/clearで会話履歴を消去する方法を見ました。しかし直後に残りのコンテキストを確認しても、100%には戻りません。Claude Codeで/contextを実行すると理由が分かります。システムプロンプト、ツール定義、CLAUDE.md、MCPサーバーが登録したツールだけで、すでに数万トークンを消費しています。会話を始める前からです。
今回は「常時ロードされるコンテキスト」を扱います。会話履歴が変動費なら、こちらは固定費です。毎ターン必ず送られ、/clearでも消えず、セッション中ずっとモデルの注意力の一部を占有します。固定費の設計が不十分だと、どのセッションも最初から不利な状態で始まるため、会話管理より先に見直すべき箇所です。
セッション開始前からロードされているもの
エージェントのコンテキストウィンドウは、白紙から始まるわけではありません。最初のユーザー入力が届く前に、すでにいくつかの層が積み重なっています。
最下層はシステムプロンプトです。Claude Codeのような実行環境であるエージェントハーネスが注入する基本指示で、ツールの使用規則や応答形式などが数千トークン規模で含まれます。ユーザーが変更できない領域です。
その上にツール定義が載ります。モデルがツールを使うには、各ツールの名前、説明、パラメータスキーマを知る必要があり、これらがすべてテキストとしてコンテキストに入ります。標準ツールだけなら負担は大きくありませんが、MCPサーバーを接続すると話が変わります。1つのサーバーが数十個のツールを登録することは珍しくなく、数台接続するだけでツール定義だけに数万トークンが消費されます。一度も使わないツールまで毎ターン往復します。
最後がCLAUDE.mdのようなプロジェクト指示ファイルです。グローバル、プロジェクト、サブディレクトリの設定まで自動的にロードされます。この層だけがユーザー自身で設計できます。
CLAUDE.mdの原則、常に正しいことだけを短く
CLAUDE.mdに何を入れるかを判断する基準は1つです。「このプロジェクトのすべての作業で常に正しいか」。毎ターン、すべての作業に載るファイルなので、作業によって該当したり無関係になったりする内容は、場所に見合う価値を持ちません。
ビルド・テストコマンド、コードベースの大まかな構造、違反してはいけない少数のルール。これらは合格です。一方、特定機能の詳細仕様、ライブラリの使い方の全文、過去の作業記録は、その作業のときだけ必要な情報なので不合格です。
長さには逆説があります。指示を増やすほど守られそうに思えますが、実際は逆に近い結果になります。第2回で見たように、コンテキストが長くなると個々の項目への注意が薄れ、数百行の指示ファイルでは重要なルールがlost in the middleに埋もれます。50個のルールを書けば50個すべてがぼんやり守られ、10個なら10個がより明確に守られる、という傾向です。エージェントがCLAUDE.mdのルールに何度も違反するなら、ルールを増やす前にファイルを短くするのが先かもしれません。
すべてを載せず、ポインターだけを載せる
では、合格しなかった情報、つまり必要になることがある詳細文書はどこに置けばよいのでしょうか。答えは「コンテキストの外に置き、場所だけ知らせる」です。
CLAUDE.mdにデータベースマイグレーション手順の全文を載せる代わりに、「マイグレーション手順はdocs/migration.mdを参照」と1行だけ書きます。エージェントはマイグレーション作業のときだけそのファイルを読みます。詳細は必要なセッションのコンテキストにだけ入り、無関係なセッションは1行のポインター分しか負担しません。
同じ原理を体系化したものがClaude Codeのスキル（skill）です。スキルは特定作業の手順書で、通常は名前と1行の説明だけがコンテキストに載り、その作業が始まると本文がロードされます。「デプロイ手順」をCLAUDE.mdに常駐させる代わりにスキル化すれば、デプロイしない99%のターンでそのトークンを節約できます。
ツール側も整理が必要です。接続しているのに使わないMCPサーバーがあるなら、停止するだけで数万トークンの固定費が消えます。普段は名前だけを置き、必要なときに完全なスキーマをロードする遅延ロードに対応するハーネスも増えています。方向性は同じです。すべてを常に載せるのではなく、必要なものを必要なときに載せるのです。
固定費を点検するルーティン
常時ロードされるコンテキストは、一度膨らむと気づきにくいものです。毎セッション同じコストが発生するため、比較対象がないからです。だからこそ、時々意識的に点検する価値があります。
Claude Codeでは/contextで、現在のコンテキストがどこでどれだけ使われているかを分解して確認できます。システムプロンプト、ツール、MCP、メモリーファイルごとのトークン数が表示されるので、ツール定義が会話より異常に大きければ、まずMCPサーバーを整理します。CLAUDE.mdは四半期に1度ほど開き、「先月、この行が実際に役立ったか」を基準に行を削除します。指示ファイルは放置すると増える一方なので、短く保つには枝刈りをルーティン化する必要があります。
まとめ
- システムプロンプト、ツール定義、CLAUDE.mdは毎ターン載る固定費です。/clearでも消えないため、会話管理より前に設計する必要があります。
- CLAUDE.mdの基準は「すべての作業で常に正しいか」です。長いほど個々のルールがぼやけるため、ルールが守られないなら、まずファイルを短くします。
- 詳細文書は本文ではなくポインターだけを載せ、繰り返し手順はスキルに分離し、使わないMCPサーバーは停止します。必要なものを必要なときだけ載せるのが原則です。
ここまで行えば、1つのセッションのコンテキストはかなり整理されます。しかし、どれだけ節約しても、大きな作業が1つのセッションに収まらない瞬間があります。次回はそのための構造的な解決策、サブエージェントを扱います。探索を別のコンテキストに任せ、結論だけを受け取る隔離パターンが、どのようにコンテキストを守るのかを見ていきます。