設計を担うリーダーと実装を担う AI エージェントで開発を分担するとき、実装計画ドキュメントをどの粒度まで事前に落とすかの判断基準。粗すぎると実装エージェントが対象コードを再探索して時間を失い、細かすぎるとリーダーが実装を散文で二重に行うことになる。

判断基準

計画に書くもの:

• 境界をまたぐ契約は確定値で書く: モジュール・リポジトリ間にまたがる決定（データスキーマ、エラー挙動、上限値）。実装後の変更コストが高く、複数実装者の並列作業の前提になるため、計画段階で確定させる。契約が確定していれば、依存モジュールの実装を待たずモック相当の検証で並列に進められる。
• 探索の地図を添える: 触るファイルの名指しと、模倣すべき既存パターンの参照（「X は既存の Y と同型」の形）。リーダーは設計探索で既に知っているため書き出しコストがほぼゼロだが、実装者が再発見するには数十分かかる。この非対称性が地図の費用対効果の根拠。
• 検証設計（テストが検知すべき退行）を挙動ごとに列挙する: 完了条件を「テスト green」とだけ書くと、実装者はテストの検知力までは担保しない — 弱いテストでも green は green で、完了条件を形式的に満たせてしまう。挙動変更（条件分岐・表示切り替え・デフォルト値など）ごとに「これを壊したらどのテストが落ちるべきか」を計画に列挙する。特にテスト対象のファイル列挙だけでは、変更の本丸（挙動が変わるコンポーネント）のテストが漏れやすい: 実装者は列挙されたテストファイルへのケース追加は忠実に行うが、列挙にないテストは自発的に設計しない。実測では、レビュー往復3件がすべて「実装は正しいがテストがこの退行を検知できない」型で、計画側に検証設計があれば往復を先回りできた。
• 完了条件とやらないこと: スコープ外を明示し、実装者の善意の拡張を防ぐ。

書かないもの:

• diff レベルの逐一指示（どのファイルをどう書き換えるかのコード近傍の指示）。理由は2つ。(1) リーダーがそれを書くにはコードを深く読む必要があり、実装を散文で一回やる二重作業になる。(2) 仕様変更時に計画側の手戻り面積が大きい。安定なもの＝契約を計画に書き、揮発しやすいもの＝実現方法は実装者の裁量に残す。

完成条件のテスト: 「実装者が、計画＋名指しされたファイル＋リポジトリの規約文書だけで着手できるか」。

実装中の仕様変更の扱い

実装開始後に気づいた仕様追補は、契約の誤りでない限り実装者へ即時反映せず、フォローアップとして実装完了後に1バッチで回す。実装中の追補は直後に手戻り修正を生むことをコミット履歴で確認した。即時反映してよいのは、放置すると他モジュールの実装が誤った契約の上に積み上がる契約バグのみ。

検証方法

効果測定と診断はコミットタイムスタンプの内訳分析で行える。設計確定から最初のコミットまでの間隔（再探索コスト）、モジュール間の消化順（直列化コスト）、仕様追補の記録と直後の修正コミットの対応（実装中変更の手戻り）を読み取り、ボトルネックを特定してから対策を選ぶ。レビュー起因の手戻りは指摘の型を分類する: 「実装バグ」型が多ければ契約の精度、「テストが弱い」型が多ければ検証設計の欠落が原因で、対策が異なる。感覚ではなく履歴で「1時間の内訳」を分解すると、計画粒度・並列化・変更タイミングのどれに効かせるべきかが分かる。