はじめに
Claude Code を使い続けると、あるタイミングで壁にぶつかります。
「コンテキストウィンドウがいつも足りなくなる」「途中からモデルの返答が的外れになる」「長い会話の後半で、前半に決めたことを忘れている」。
このような問題の根っこは、コンテキストに何を入れるかの設計にあることが多いです。
LLM はコンテキストウィンドウに入っているものだけを見て返答します。
裏を返せば、いま必要な情報だけを渡す設計ができれば、コンテキスト消費を抑えながら精度を保てます。
本記事では、Claude Code を実業務で運用するなかで自分が実践している「need-to-know 原則」に基づくコンテキスト管理のパターンを6つに整理して紹介します。
対象読者
- Claude Code を日常的に使っており、コンテキスト不足や精度の揺らぎを経験している方
- CLAUDE.md の設計や、サブエージェント活用を考え始めている方
前提
- Claude Code の基本的な使い方（プロジェクト設定、CLAUDE.md）は知っている想定です
- 「このパターンを使えば必ず改善する」という保証はできません。自分の環境・ユースケースで検証してください
得られるもの
- コンテキストを浪費している箇所の見つけ方
- 6つの管理パターン（命名・課題・やり方・効果）
- 各パターンを組み合わせる考え方
なぜコンテキストを「設計」する必要があるのか
一文で言うと、LLM はコンテキストウィンドウに入っているものをすべて読んでいるからです。
最近 Zenn で話題になった記事に「LLM はマークダウンファイル全体を読んでいる。その必要はない」という観察がありました。
長いドキュメントを渡すと、関係のない部分まで処理に使われます。
その結果、トークンを消費するだけでなく、ノイズが増えて精度が落ちることもあります。
逆に考えると、必要な部分だけを渡すことは、コスト節約と精度向上を同時に達成できる手段です。
もう一つ重要な観点があります。
Claude Code は長い会話を続けると、会話の中だけで決めた事項が要約に丸められ、前半の方針が薄まることがあります。
前半で合意した設計方針や制約が、後半では曖昧になってしまうのはこのためです。
「どこに何を置くか」を最初から考えておくことが、長期的な精度維持につながります。
パターン 1：オンデマンド読込（常時読込を最小化する）
課題
CLAUDE.md は常時読み込まれるため、何でも書くと関係のないタスクでもその内容がコンテキストに乗ります。
「文書執筆のガイドライン」がコードデバッグ中にコンテキストを占有する、といった無駄が生まれます。
やり方
ガイドラインを「常時読込」と「オンデマンド読込」に分けます。
常時読込：あらゆるタスクで参照が必要なもの（役割定義、ガードレール、判断軸など）
オンデマンド読込：特定タスクのときだけ必要なもの（記事執筆規範、コードスタイル、テスト方針など）
CLAUDE.md に「文章を書くタスクでは docs/writing-guidelines.md を読んでから着手する」と書いておき、ガイドライン本文は別ファイルに分離します。
タスクが発生したときだけ Claude にそのファイルを読ませ、それ以外のタスクでは読まないままにします。
なお、CLAUDE.md に @docs/writing-guidelines.md のように @ 付きでファイルを記載すると、起動時に常時インポートされます。
ここで説明しているオンデマンド読込（「タスクのときだけ読む」という運用ルールをテキストで書く）とは別の仕組みです。混同しないよう注意してください。
# CLAUDE.md（抜粋）
## オンデマンドで読むファイル
| タスク | 読むファイル |
|--------|------------|
| 文章・記事の執筆 | `docs/writing-guidelines.md` |
| コード実装・レビュー | `docs/coding-standards.md` |
| データベース操作 | `docs/db-conventions.md` |
効果
常時読込ファイルを薄くすることで、どのタスクでも最初から「使える余白」が増えます。
自分の環境では、CLAUDE.md を「役割定義＋振り分け表＋ガードレール」だけに絞り、詳細規範はすべて別ファイルに切り出してから、長い作業セッションでの精度低下が体感的に減りました（定量測定はしていないため断言はできません）。
パターン 2：サブエージェントへの委譲でコンテキストを隔離する
課題
調査・分析・執筆などの重い処理を親の会話でそのままやると、途中経過の思考がすべてコンテキストを消費します。
「候補を10個調べて比較して」とお願いすると、10個分の調査内容がそのまま蓄積されていきます。
やり方
Claude Code のサブエージェント機能を使い、重い処理を別コンテキストで実行させます。
親の会話では「依頼」と「結果の受取」だけを行います。
途中の試行錯誤・調査ログ・比較過程はサブエージェントのコンテキストで完結し、親には最終結果だけが返ってきます。
# 親への委譲指示の例
以下の調査をサブエージェントとして実行してください。
目的: ○○の実装方針を3案に絞る
制約:
- 最終メッセージに結論・根拠・未確認事項を含めること
- 「完了しました」だけの回答は禁止
- 調査過程ではなく、最終判断を返すこと
ポイントは「最終メッセージに成果物を含めること」を明示することです。
これを書かないと、期待した成果物ではなく短い完了報告だけが返ってくることがあります。
効果
親のコンテキストは「依頼の送受信」だけになります。
10回の調査をすべて親でやれば10倍のコンテキストを使いますが、サブエージェントに委譲すれば親には要約が返るため、詳細を親で全部読むよりコンテキスト消費を大きく抑えられます（消費がゼロになるわけではありません）。
並列実行も可能で、互いに依存しない調査タスクを同時に複数走らせれば、時間コストも下げられます。
パターン 3：観点分担（複数の視点を別エージェントに割り当てる）
課題
「コードをレビューしてください」と一度に依頼すると、Claude は複数の観点（バグ・設計・テスト・セキュリティ）を同時に考えようとします。
観点が多いほど、各観点の深さが浅くなりやすいです。
Zenn で紹介されていた「7人の意地悪なQAを仕込んでテストケースの観点漏れを潰した」という記事はこの問題への回答でした。
一つのエージェントに一つの観点だけを持たせると、その観点の深掘りに集中できます。
やり方
タスクを観点ごとに分解し、それぞれを別のサブエージェントに割り当てます。
# 並列レビューの委譲例
以下のコードを、観点ごとに分担してレビューしてください。
[サブエージェント A]
観点: バグ・ロジックの誤り のみ
対象: （コード本文）
出力: 問題箇所と修正案
[サブエージェント B]
観点: セキュリティ（入力検証・認証・権限） のみ
対象: （コード本文）
出力: 問題箇所と修正案
[サブエージェント C]
観点: テスト容易性・境界値 のみ
対象: （コード本文）
出力: 見落としやすいケース一覧
観点の割り方はユースケースによって変わります。
コードレビューであれば「バグ/設計/セキュリティ/テスト」、記事の校正であれば「事実確認/文体/読者層への適合/機密漏れ」といった分け方が考えられます。
効果
各エージェントが一つの観点に集中するため、取りこぼしが減ります。
また、結果を並列で集めることで時間を節約できます。
全観点を一つのプロンプトに詰め込むより、観点ごとに分けたほうが各観点の深さが増す傾向があります。
ただし、サブエージェントの数が増えるとコストも増えるため、観点を絞ることとのバランスが必要です。
パターン 4：必要部分だけ読ませる（全文読み込みを避ける）
課題
「このファイルを参考にして」と長いファイルをそのまま渡すと、関係のないセクションもすべてコンテキストに乗ります。
500行のドキュメントのうち、実際に参照が必要なのは30行だけ、というケースは珍しくありません。
やり方
Read ツールの offset・limit パラメータを活用する
必要なセクションの行番号を特定してから、その範囲だけを読み込みます。
まず対象ファイルの目次や見出しだけを確認してください（先頭30行）。
必要なセクションの行番号がわかったら、その範囲だけを読んでから作業を始めてください。
Grep で必要な箇所を先に特定する
ファイル全体を読む前に、キーワードで必要な行を絞り込みます。
「エラーハンドリング」に関する記述を grep で探してから、その周辺だけを読んでください。
見出しだけ先に把握する
ファイル全体を読む前に、見出しだけを抽出して構造を把握します。
rg '^#' ファイル名 で Markdown の見出し行だけを取り出すか、Read の offset・limit で先頭数十行だけを読んで目次を確認します。
必要なセクションの行番号がわかれば、そこだけを Read に渡せます。
「全文を読んでから要約させる」方法は、全文読み込みが発生するため、省トークンにはなりません。
効果
ファイルの全文を渡す場合と比べて、コンテキスト消費量を大幅に削減できます。
特に設計書・仕様書・ログファイルのような長いドキュメントを扱うときに効果が出やすいです。
ただし、ファイルを部分的にしか読んでいない場合、Claude が「まだ読んでいない部分」に重要な情報があっても気づけないリスクがあります。
「ファイル全体を把握する必要があるか、特定の情報だけでよいか」を自分で判断してから使い分けてください。
パターン 5：コンテキスト注入マニフェスト（委譲先が読むべきファイルを列挙する）
課題
サブエージェントへの委譲で精度が出ない原因の一つは「文脈不足」です。
CLAUDE.md やルールファイルはサブエージェントでも読み込まれますが、会話の中だけで積み上げた前提（先行調査・決定済みの方針）は、通常のサブエージェントには引き継がれません。
その結果、的外れな出力が返ってきたり、既に決まったことを再考し始めたりします。
やり方
委譲するときに「読むべきファイルのリスト」を明示的に渡します。
# 委譲プロンプトへの追記例
着手前に、以下のファイルを読んでください。
- `docs/writing-guidelines.md`（文体規範。遵守してください）
- `outputs/research/2026-06-20-topic.md`（先行調査。これを一次情報として使ってください）
- `docs/target-audience.md`（想定読者の定義）
上記を読んでから、以下の作業を実行してください。
さらに複数ファイルを繰り返し参照する場合は、リスト自体をファイルに書き出しておくと管理しやすくなります。
{"file": "docs/writing-guidelines.md", "reason": "文体規範の遵守"}
{"file": "outputs/research/2026-06-20-topic.md", "reason": "一次情報"}
{"file": "docs/target-audience.md", "reason": "想定読者の定義"}
委譲前にこのリストを展開して、委譲プロンプトの冒頭に貼り付けます。
効果
文脈の引き継ぎが構造化されるため、委譲先の出力品質が安定します。
また「どのファイルを渡したか」が記録に残るため、後から振り返りやすくなります。
パターン 6：会話セッションを意図的に分割する
課題
一つの会話を長く続けると、2つの問題が起きます。
- コンテキストウィンドウが埋まっていき、新しい情報を入れる余地が減る
- 会話の先頭が圧縮され、初期に決めた方針や制約が薄まる
Zenn で話題になった「tmux のタブを会話させてコンテキストを分割する」という記事は、この問題に対するアプローチの一つです。
やり方
フェーズで会話を区切る
「調査フェーズ」「設計フェーズ」「実装フェーズ」のように、作業の区切り目で意図的に新しい会話（セッション）を始めます。
次のセッションに渡すときは「引き継ぎメモ」を書き出しておきます。
# 引き継ぎメモの例（次のセッションの冒頭に貼る）
## 決定済みの方針
- ○○ライブラリを使う（理由: △△）
- エラーハンドリングは集約型で実装する
## 残っている作業
- ○○機能の実装
- テストの追加
## 参照すべきファイル
- `src/api/types.ts`（型定義）
- `docs/api-spec.md`（仕様書）
タスクの種類ごとにタブ（tmux や IDE）を分ける
長期にわたるプロジェクトでは、「機能Aの開発」「バグ調査」「ドキュメント整備」のように、タスクの種類ごとに別のセッションを持ちます。
それぞれのセッションは独立したコンテキストを持つため、一方の調査ログがもう一方の実装作業を圧迫しません。
効果
各セッションを「目的に特化した状態」で保てます。
引き継ぎメモを書く習慣は、作業の整理にもなります。
ただし、セッションをまたいだ文脈は自動では引き継がれません。
引き継ぎメモに書き忘れると、次のセッションで同じ調査をやり直すことになります。
「どこまで決まっていて、何が残っているか」を確実に記録してから区切ってください。
6つのパターンの組み合わせ
各パターンは単独でも効果がありますが、組み合わせることで補い合います。
| 状況 | 使うパターン |
|---|---|
| 作業が始まった | 1（オンデマンド読込）で必要なガイドラインだけ読む |
| 重い調査・分析がある | 2（委譲・隔離）でサブエージェントに任せる |
| 品質を多角的に確認したい | 3（観点分担）で観点ごとに並列チェック |
| 長いファイルを参照する | 4（部分読み込み）で必要箇所だけ渡す |
| サブエージェントに背景を伝えたい | 5（注入マニフェスト）で読むべきファイルを明示 |
| 会話が長くなってきた | 6（セッション分割）で引き継ぎメモを書いて区切る |
「コンテキストが足りなくなってから対処する」より、「最初から必要なものだけを入れる」設計が有効です。
まとめ
本記事では、Claude Code でのコンテキスト管理を6つのパターンに整理しました。
- オンデマンド読込 — 常時読込ファイルを最小化し、必要なときだけ読む
- 委譲による隔離 — 重い処理はサブエージェントで完結させ、親に結果だけ返す
- 観点分担 — 複数の観点を別エージェントに割り当てて取りこぼしを減らす
- 部分読み込み — ファイルの全文ではなく必要な箇所だけを渡す
- コンテキスト注入マニフェスト — 委譲先に読むべきファイルを明示して文脈を渡す
- セッション分割 — フェーズの区切りで会話を新しくし、引き継ぎメモで連続性を保つ
共通するのは「need-to-know 原則」です。
LLM がいま必要としている情報だけを渡すことで、コンテキストの余白を保ち、精度を安定させます。
全パターンを一度に導入しようとすると混乱するので、まず自分の作業で「コンテキストが一番無駄に使われている場面」を一つ特定して、そこに一つのパターンを試してみてください。
参考
- LLM はマークダウンファイル全体を読んでいる。その必要はない。（著者: oubakiou） — ファイル全体を渡すことのコスト
- Claude Codeに全部抱え込ませるのをやめた。tmuxのタブを会話させてコンテキストを分割する — セッション分割の実践
- Claude Code に「7人の意地悪なQA」を仕込んでテストケースの観点漏れを潰した — 観点分担の実践
- Claude Code 公式ドキュメント