ステージ2 — コンテキスト設計 (Context)
エージェントが毎回同じ質問を繰り返さないよう、知識とルールを資産として用意する。
このステージの目的
同じモデルを使っても成果物の品質を分けるのはコンテキストの品質だ。このステージの目標は、エージェントがプロジェクトのルール・構造・用語・慣例を毎回問い直さずに参照できる資産を備えることだ。新規プロジェクトなら最小の骨格を立て、既存プロジェクトなら前サイクルで積み上がった資産を点検し更新する — 両者を混同すると、新規プロジェクトに過剰な文書を、既存プロジェクトに放置された文書を残すことになる。
実行順序
- プロジェクトルールファイルの骨格を作成する。
CLAUDE.md(または同等のファイル)に、コーディング規約、禁止事項、よく使うコマンドを最小単位で埋める。 - アーキテクチャ決定記録(ADR)を残す。 「なぜこの構造を選んだのか」を代替案・根拠とともに短く記録し、後で同じ論争が繰り返されないようにする。
- ドメイン用語集を整理する。 チーム内で意味が分かれる用語(例: 「アカウント」vs「ユーザー」)を一箇所に固定し、エージェントと人が同じ意味で対話できるようにする。
- コーディング規約を明示する。 ネーミング、フォルダ構造、テスト配置ルールのように毎セッション繰り返し指示されるものをルールファイルへ移す。
- 再利用可能なスキルを点検する(既存プロジェクト)。 前サイクルで作ったスキル・プロンプト・サブエージェント定義が最新のコードと食い違っていないか確認し更新する。
成果物
- プロジェクトルールファイル — CLAUDE.md例
新規プロジェクトは上記五項目のうち1・4番(ルール骨格、規約)だけで始めても十分だ。既存プロジェクトは五項目全体を「点検・更新」の観点で見渡す — 新しく書くよりも古い部分を見つけて直す作業がほとんどだ。
完了基準チェックリスト
- [ ] ルールファイルが存在し、プロジェクトを初めて見るエージェントがそれだけを読んで作業を始められる
- [ ] 最近の主要なアーキテクチャ決定にADRが残っている
- [ ] チーム内で意味が分かれる用語が用語集に固定されている
- [ ] コーディング規約が毎セッション口頭で繰り返されず、ファイルとして存在する
- [ ] (既存プロジェクト) ルールファイルの記述が実際のコード状態と一致する
よくある誤り
- ルールファイルにすべてを詰め込んでコンテキストが肥大化。 毎セッション全体を読まねばならないファイルが数千行になると、肝心のルールがノイズに埋もれ、トークンコストだけが増える。詳細ルールは参照リンクで分離する。
- 文書と実際のコードの不一致を放置。 リファクタリング後にルールファイルを更新しないと、エージェントは存在しない構造を前提にコードを生成する。コンテキスト資産はコードが変わるだけともに変わってこそ資産であり、そうでなければ負債だ。
Claude Codeなら
TIP
CLAUDE.mdは階層で管理する。ユーザーホームのグローバルCLAUDE.mdには個人の作業習慣・全域ルールを、プロジェクトルートのCLAUDE.mdにはそのプロジェクトだけに適用されるルールを置く。マルチプロジェクトのワークスペースでは、上位ディレクトリに組織共通ルールを、下位プロジェクトにプロジェクト別ルールを置き、重複なく継承させる。
繰り返される作業手順は.claude/skills/にスキルとして、特定の役割に繰り返し委任する作業はサブエージェント定義として抜き出しておく。どちらの場合も「一つのセッションで臨機応変に使ったプロンプト」ではなく「次サイクルでもそのまま再利用可能な資産」かどうかが基準だ。再利用されたことのないスキルはコンテキスト肥大化の候補なので、整理対象として印を付けておく。