Claude CodeやCodex、Cursorといった自律型AIエージェントを活用してソフトウェア開発を行うエンジニアが増える中で、標準的なお作法として広まったのが`CLAUDE.md`や`.cursorrules`といった設定ファイルにプロジェクトのルールや指示を書き込む手法です。
開発が進むにつれて「コーディング規約」「ディレクトリ構成」「ビルド手順」「過去のエラー対策」などの指示を次々とそのファイルに追記していく運用が一般的です。しかし、このファイルを際限なく膨らませていく運用を続けていると、ある段階からAIの応答精度が急激に悪化し、指示を無視したり関係のない出力を出したりするトラブルに直面することになります。
単一のルールファイルへ大量のテキストを詰め込むアプローチの構造的な限界と、タスクの文脈に合わせて動的に必要なナレッジだけをAIへ給餌する「動的コンテクスト供給アーキテクチャ」の思考法を解説します。
単一ルールファイルにルールを詰め込むことの弊害
設定ファイル（`CLAUDE.md`等）に大量のルールを詰め込む手法が失敗する最大の理由は、それが「プロンプトの先頭や末尾に、常に数千〜数万文字の固定テキストをくっつけて送っているのと同じ状態」だからです。
コンテキストウィンドウが巨大化した現代のLLMであっても、以下の3つの問題が発生します。
- 重要指示の埋没（Attentionの拡散）: 大量のルールが並ぶことで、現在のタスクにおいて最も守るべき核心的な指示に対するAIの注意が薄れ、無視されやすくなる。
- トークンコストと遅延の増大: 毎回無関係な大量のルールをAPIへ送るため、レスポンス速度が低下し、API利用コストが無駄に膨れ上がる。
- ルールの相互矛盾: ファイルが大きくなるにつれて、過去に書いたルールと新しく追加したルールが衝突し、AIがどちらに従うべきか迷ってしまう。
ルールを1つのファイルに無計画に足し続ける運用は、中長期的なエンジニアリングにおいて明確なアンチパターンとなります。
解決策：タスクの文脈に応じた「動的コンテクスト注入」
この問題を根本解決するための正解は、設定ファイルを巨大化させるのではなく、「AIが今実行しようとしているタスクの種類に応じて、必要な知識だけをデータベースやナレッジファイルから都度引っ張ってきて注入する仕組み」を構築することです。
具体的には以下のような設計を施します。
- ルールファイルのディレクトリ分離: `rules/database.md`, `rules/frontend.md`, `rules/testing.md` のように領域ごとにルールを小さく分割管理する。
- タスクカテゴリの事前判定: ユーザーからの指示（例: 「データベースのマイグレーションコードを書いて」）を受けた際、AIまたはスクリプトがカテゴリを判定する。
- 必要なルールのみの動的ロード: データベースに関連する最小限のルール（50行程度）のみを選択してシステムプロンプトへ注入し、実行させる。
| コンテクスト設計アプローチ | ルールの管理方法 | プロンプトのサイズ | AIの指示遵守精度 | レスポンス速度・コスト |
|---|---|---|---|---|
| 1. 巨大単一ファイル型 | `CLAUDE.md`へ全ルール追記 | 非常に巨大（無関係な指示多数） | 低い（指示の無視や混同が発生） | 遅い / コスト高 |
| 2. 動的コンテクスト注入型 | 領域別に最小単位で分離保持 | 最小限（現在のタスク専用） | 非常に高い（過不足なく遵守） | 爆速 / 最小コスト |
コンテクスト枯渇（Context Exhaustion）の予兆を見抜く
長時間AIエージェントとやり取りを続けていると、AIが急に過去に決めた仕様を忘れたり、簡単なミスを連発し始めることがあります。これはコンテクストウィンドウ内が不要なログで溢れ返り、AIの思考精度が著しく低下している「コンテクスト枯渇（Context Exhaustion）」のシグナルです。
こうした状態に陥った際、粘ってやり取りを続けるのではなく、一度セッションをクリアし、現在の最新状態と必要なファイルパスだけをクリーンに整理して新しいセッションに渡す「コンテクストの再初期化プロトコル」を習慣化することが重要です。
1つのAIモデルに固執せず、タスクによってモデルを切り替える柔軟性
コンテクストの設計と同時に重要なのが、「すべての作業を1つのAIモデルだけで完結させようとしない」という柔軟なスタンスです。
たとえば、複雑なロジックの設計やリファクタリングには論理思考力の高いモデル（Claude 3.5 Sonnet等）を使い、単純なコード修正やテストコードの量産にはスピードとコストに優れるモデル（Gemini Flash等）に切り替える。さらに、あるモデルでエラーが解決せず詰まった場合、意地にならずに別のモデルへ全く同じコンテクストを渡してみると、案外すんなり解決することが多々あります。
コンテクストの「密度と美しさ」を設計するエンジニアリング
AI駆動開発において、エンジニアの腕の見せ所は「コードを書くスピード」から「AIに与えるコンテクストの密度と美しさを設計すること」へと完全にシフトしました。
無駄なノイズを削ぎ落とし、必要な瞬間に必要な情報だけをクリアに提供する。この洗練されたコンテクスト設計の思考を身につけることで、AIエージェントのパフォーマンスを100%引き出し、圧倒的に軽快な開発体験を手に入れることができるのです。
コンテクスト空間の定期的なガベージコレクション
長時間にわたってセッションを継続していると、AIの内部コンテクストには過去の失敗したコードの試行錯誤や無用な思考プロセスが不要なゴミ（ガベージ）として蓄積されていきます。
私たちは一定の区切りごとに、AIに対して「これまでの議論の核心と採択された仕様のみを要約して出力せよ」と命じ、その要約結果だけを新しいセッションに受け渡す「コンテクストのガベージコレクション（ゴミ清掃）」を定期的に実行しています。これにより、常にクリアで高い推論精度を維持したまま長大な開発を完遂することが可能になります。
ナレッジグラフとコンテクスト供給の未来像
今後は単なるファイルの分割にとどまらず、AIがリポジトリ内のコード、過去のPRレビュー、社内Wikiを自動的にナレッジグラフとして解釈し、指示の内容から関連ノードをリアルタイムで抽出してシステムプロンプトへ最適注入する完全自動化のコンテクストエンジンへと進化していきます。コンテクストの設計と管理を高度化させることこそが、AIエンジニアリングの最前線です。
