[AI書房] 第23章 コンテキスト管理の技術: アシスタントを賢く使う
Claude Code完全攻略
第6部
第23章 コンテキスト管理の技術: アシスタントを賢く使う
金京鎮
導入
アシスタントに「先月決定された新製品発売日はいつでしたか？」と尋ねた際、エージェントが数秒で正確な日付とその理由まで見つけてくれたとしたら — それはエージェントが賢いからではありません。情報が正しい場所に適切な形式で保存されているからです。
逆の状況を想像してみましょう。すべての情報が CLAUDE.md という単一のファイルに詰め込まれています。ユーザー情報、チーム構成、プロジェクトの進捗、意思決定の記録、スキル使用方法まで、500行を超える文書をエージェントが毎回最初から最後まで読み込まなければなりません。モデルが処理できるトークンが急速に枯渇し、コンテキストウィンドウの限界にすぐに達してしまいます。エージェントの応答は遅くなり、精度も低下します。
コンテキスト管理（Context Management）は、エグゼクティブアシスタントのパフォーマンスを左右する目に見えないインフラです。華やかなスキルよりも、このインフラをいかに設計するかこそが、アシスタントの性能の上限を決定します。
context、decisions、archives フォルダの役割
プロジェクトフォルダ内には、3 つの重要なフォルダがあります。名前だけ見れば平凡に思えますが、それぞれが担当する時間軸は異なります。
context フォルダ：現在を収める場所。このフォルダには、今この瞬間に有効な情報が格納されます。me.md にはユーザーの名前、役割、好みが、work.md には事業体の現在の構造と主要製品が、team.md には共に働く人々の名前と役割が、priorities.md には今週および今四半期の主要課題が記録されます。
goals.md には、年次目標と四半期ごとのマイルストーンが記載されています。
エージェントがモーニングコーヒースキルを実行したり、コンテンツを作成したり、リサーチを行ったりする際、このフォルダ内のファイルが判断基準となります。「今四半期の目標は何だったか」という問いにエージェントが答えられるのは、context/goals.md を読み取るだけで済むからです。
このフォルダ内のファイルは静的ではありません。四半期が変われば priorities.md が更新され、新しいチームメンバーが合流すれば team.md に追加されます。エージェントに「priorities を更新して」と指示すれば、エージェントが直接ファイルを修正します。
decisions フォルダ：過去の判断を保存する場所です。重要な意思決定が行われるたびに、このフォルダの log.md に記録が残されます。日付、決定内容、理由、当時の文脈が一緒に保存されます。
なぜこの記録が重要なのかというと、2 ヶ月後に「なぜ西部への拡大を 4 月に延期したのか」という問いが浮かんだとき、エージェントがそのログを検索して回答できるからです。記憶に頼る必要はありません。組織が大きくなるほど、過去の決定理由を追跡することが難しくなりますが、このフォルダがその課題を解決します。
archives フォルダ：過去のシーズンの記録を保管する場所です。四半期が終わると、その四半期の目標と進捗記録がここに移されます。context フォルダには現在の四半期の情報のみを残し、過去の四半期のデータはアーカイブします。これにより、context フォルダが肥大化するのを防ぎつつ、必要に応じて過去の記録を検索できます。
[図 23-1] context、decisions、archives フォルダのタイムラインダイアグラム
3 つのフォルダの関係をまとめると、context は現在、decisions は決定の歴史、archives は過去のスナップショットとなります。時間が経過すると、context の一部が archives へ移動し、新しい情報が context に補充されます。decisions は継続的に蓄積されていきます。
情報の階層的配置
第20章では、CLAUDE.md がルーターの役割を果たすと説明しました。この概念をさらに深く掘り下げてみましょう。
エージェントがユーザーのメッセージを処理する順序は以下の通りです。
1. CLAUDE.md を読み込みます（すべての対話の起点）。2. ユーザーの要求を分析します。3. 必要な情報がどこにあるかを、CLAUDE.md の案内に従って特定します。4. 該当するファイルのみを必要に応じて読み取ります。
この構造がなければどうなるでしょうか？CLAUDE.md にすべての情報を詰め込むか、エージェントがプロジェクト全体を探索することになります。前者はモデルが生成するトークンの無駄であり、後者は時間の無駄です。
[図 23-2] 情報階層構造：CLAUDE.md → ルーティング → 個別コンテキストファイル
CLAUDE.md にはこのような形で記載されています。
この方式の利点は、モデルが生成するテキストの削減だけではありません。情報の単一の真実源（Single Source of Truth）が維持されます。ユーザー情報は me.md の 1 箇所にのみ存在するため、修正する際は 1 つのファイルだけを変更すればよいのです。もし CLAUDE.md と me.md の両方にユーザー情報が重複して記載されている場合、片方だけを修正すると不整合が生じます。
ルーティング構造を設計する際の原則は明確です。
スキルファイルにおいても同じ原則が適用されます。スキルの YAML フロンットマターには名前と説明のみを含め、エージェントがスキルを選択した後にのみ、完全な指示文を読み込みます。参照ファイルやスクリプトは必要な場合にのみ追加で読み込まれます。この 3 段階の読み込みを、段階的コンテキスト読み込みと呼びます。
[図 23-3] 段階的コンテキスト読み込みの 3 つの段階
プロジェクト管理ツールとの連携
context フォルダ内のファイルがどれだけ整理されていても、リアルタイムのデータが欠けていれば、アシスタントの判断は過去のままにとどまってしまいます。チームメンバーが今朝タスクを完了したにもかかわらず、priorities.md にはそのタスクがまだ「進行中」と記載されていれば問題です。
このギャップを埋めるのが、プロジェクト管理ツールとの連携です。ClickUp、Notion、Asana などのツールにエージェントが直接接続して最新データを取得します。連携方式は大きく分けて 2 つあります。
API 連携。該当ツールの API キーを.env ファイルに保存し、エージェントが API を呼び出してデータを読み書きできるようにスキルを構成します。エージェントに「ClickUp 連携のスキルを作成してください。API キーは.env に格納します」と伝えれば、エージェントは API ドキュメントを調査し、スキルを記述します。
MCP 接続サーバーとの連携。MCP（Model Context Protocol）サーバーを介して接続する方式です。MCP 接続サーバーは、プロジェクト管理ツールとエージェントの間の架け橋として機能します。Claude 用の MCP 接続サーバーが用意されていれば、エージェントは自然言語で「今週の締め切りがあるタスクを表示してください」と要求できます。
[図 23-4] プロジェクト管理ツール連携アーキテクチャ図
連携が完了すると、モーニングコーヒースキルやパルスチェックスキルがリアルタイムデータに基づいて動作します。priorities.md に記載された静的情報と、プロジェクト管理ツールから取得した動的情報が結合されることで、エージェントの判断精度が向上します。
連携プロセスにおいて注意すべき点があります。エージェントがプロジェクト管理ツールからデータを検索する際、毎回リストを探索して ID を抽出するプロセスが、モデルが生成するトークン数を大幅に消費する可能性があります。21 章で言及した通り、頻繁に使用するリスト ID をスキルファイルに事前に記録しておくことで、このコストを削減できます。
エージェントの作業過程を観察して、反復される探索パターンを発見した場合は、それをハードコードすることが実用的な最適化となります。
毎日使用するほど精密になるアシスタントの進化の道筋
アシスタントを1ヶ月間毎日使用すると、プロジェクトフォルダの姿は大きく変わります。初日にはcontextフォルダに4つのファイルとCLAUDE.mdしかなかったのが、30日後にはスキルフォルダに複数のスキルが追加され、リサーチレポートが積み重なり、意思決定ログが長くなり、プロジェクト別のフォルダには成果物が充満しています。
この蓄積こそがアシスタントの知能です。エージェント自体のモデルが変わらなくても、参照できるデータが豊かになることで、応答の精密さが向上します。
進化の道筋を時系列で描いてみましょう。
1週目：基礎の確立。インタビューを通じてcontextファイルを充実させ、最初のスキルを作成します。まだエージェントの応答は全般的に感じられるかもしれません。「自社のことをよく知らない新人秘書」と対話している感覚です。
2 週目：パターンの発見。毎日使用していると、繰り返されるリクエストが見えてきます。「これはスキルにできる」という感覚が生まれます。既存の ChatGPT プロジェクトやカスタム GPT のプロンプトをスキルへ転換します。エージェントに修正意見を伝えながら、スキルの品質が向上していきます。
3 週目から 4 週目：定着。モーニングコーヒー・スキルを毎日実行し、リサーチ・スキルで週 2〜3 回調査を行い、コンテンツ生成・スキルでソーシャルメディアの投稿を作成します。エージェントが事業の文脈を深く理解するにつれ、提案の的中率が目に見えて向上します。「1 ヶ月前とは全く異なるツールを使っているようだ」と感じる時点です。
[図 23-5] アシスタント進化のタイムライン：1 週目 → 2 週目 → 4 週目
進化を加速させるいくつかの習慣があります。
エージェントに「覚えておいて」と伝える。「私はいつも午前中に集中作業を好むことを覚えておいてください。」エージェントはこの情報を me.md や適切なファイルに保存します。次のモーニングコーヒー・スキル実行時に、集中作業が自然と午前中に配置されます。
スキル実行を観察し、修正意見を伝えます。最初の数回、エージェントがスキルを実行する過程を見守ります。不要なAPI呼び出しが見られたら、「その過程は省略し、このIDを直接使用してください」と指示します。エージェントがスキルファイルを修正すれば、次の実行からはより効率的に動作します。
定期的にコンテキストファイルを点検します。エージェントはCLAUDE.mdに記載された週次、月次、四半期ごとの周期に従ってファイル更新を提案します。週次では自動メモリの整理、月次ではpriorities.mdの更新、四半期ごとに目標ファイルの更新を行います。このルーチンに従えば、コンテキストが古くなることはありません。
.claudeフォルダ構造の深掘り
.claudeフォルダはアシスタントの内部設定を格納する場所です。プロジェクトのルートに位置し、主に3つのサブフォルダで構成されています。
skillsフォルダ。各スキルは独立したサブフォルダを持ちます。スキルフォルダ内にはskill.mdがあり、必要に応じてreferences/やscripts/のサブフォルダが追加されます。参照ファイルやスクリプトの位置は、必ずしも.claude/skills/内にある必要はありません。skill.md内で正確な経路を指定していれば、プロジェクト内のどこに配置しても構いません。
agents フォルダ。補助エージェントの設定ファイルが保存されます。各エージェントファイルには、役割、使用するモデル、実行するタスクが記載されています。メインエージェントがタスクを委任する際に、このファイルを参照します。
rules フォルダ。コミュニケーションスタイル、フォーマット規則、禁止表現など、エージェントの行動を規制するルールが格納されます。「箇条書きを使用」「簡潔なトーン」「ダッシュの使用禁止」などの詳細な指示です。
[図 23-6] .claude フォルダの内部構造と各サブフォルダの役割
この構造における核心は、分離と参照です。すべての設定を一つのファイルにまとめるのではなく、用途ごとに分離し、必要な場所でパスを通じて参照します。スキルが 10 個、20 個と増えても、この原則を守れば管理は難しくありません。
グローバルスキル（Global Skill）という概念もあります。.claude/skills ではなく、ユーザーのホームディレクトリにスキルをインストールすれば、どのプロジェクトを開いてもそのスキルを利用できます。フロントエンドデザインスキルのように、特定のプロジェクトに限定されない汎用的なスキルに適しています。
まとめ
コンテキスト管理は派手ではありません。フォルダを作成し、ファイルを整理し、パスを明確にする — 退屈に見える作業です。しかし、このインフラがなければスキルは文脈なく機能し、アシスタントの応答は一般的な水準に留まり、使うほど賢くなる好循環は始まりません。
「context」フォルダが現在を収め、「decisions」が判断の歴史を記録し、「archives」が過去を保存し、「CLAUDE.md」がこれらすべての交差点として機能する構造 — これがアシスタントを単なるチャットボットではなく、事業の脳へと変える基盤です。
この基盤の上でスキルは次第に洗練され、エージェントは利用者の判断パターンを学習し、一ヶ月前には想像もできなかったレベルの自動化が日常となります。しかし、一つのエージェントがすべての処理を担うことには限界があります。複雑な作業を複数の専門エージェントに分担して委譲する構造、すなわち補助エージェントの世界が次章で展開されます。