委譲先の「テスト全通過」を信じない — 実データ dry-run で完成報告を潰す手順

AI に実装を委譲すると「テスト N/N 通過・exit 0・完了しました」と返ってくる。これを完了の証拠として受け取ると壊れたものが本番に出る。テストは実装者が書いた前提しか検証しないからだ。

この指示書は、委譲した実装を受け取る側（監督役の AI、またはレビューする人間）が、実データで1回動かすだけで完成報告の嘘を機械的に暴く手順。

なぜテストが通っても壊れているのか

委譲先はテストとコードを同時に書く。前提を間違えていれば、その間違った前提でテストも書かれる。だから両方が整合したまま揃って間違う。実データだけが外部から与えられた事実であり、唯一の検証軸になる。

実測例（外部へ通知を送るバッチを委譲したケース）: テスト 13/13 通過・exit 0 の報告に対し、実データで1回 dry-run しただけで4種類の欠陥が出た。

欠陥の型	症状	なぜテストで出ないか
スコープ漏れ	関連リソースの検索範囲が広すぎ、別プロジェクトの無関係なものを拾って提示していた	フィクスチャに1プロジェクト分しか無い
外部状態の未参照	失敗ステータスを取得せず、常に「正常」と判定していた	モックが常に成功を返す
宛先解決の全滅	通知先が全件解決できず、全部フォールバック先（管理者）へ流れた。機能の目的そのものが未達	フィクスチャには宛先が埋まっている
文字化け・null	実データの壊れた文字列でタイトルが化け、状態が null になった	フィクスチャの文字列は綺麗

4つとも「テストが甘い」ではなく「実データにしか存在しない条件」が原因。テストを増やしても出ない。

手順

1. 委譲の指示書に、実データの具体値で完了条件を書く

これが最重要。「テストが通ること」を完了条件にすると、委譲先はテストを通して終わる。

悪い完了条件:

- テストが通ること
- dry-run が正常終了すること

良い完了条件（実データの固有値を名指しする）:

1. `<コマンド> --dry-run --json` が exit 0 で終わること
2. その出力で `<実データの識別子>` の関連リンクが `<期待する具体的な値>` を指していること
3. 出力に状態が null のエントリが 0 件、文字化けしたタイトルが 0 件であること
4. `<識別子A>` の宛先が、フォールバック先ではなく `<本来の宛先>` に解決されていること
5. フォールバックに落ちた件数が N 件から減っていること。減らなければ、各件について
   「一次ソースのどこを見て、なぜ解決できなかったか」を1行ずつ根拠付きで報告すること

4 と 5 が効く。「目的が達成されたか」を数で書くと、委譲先は「動いたが目的未達」を完了と偽れなくなる。

さらに指示書に明記する:

- 完了条件はすべて実機 dry-run の出力で示すこと
- テスト通過だけを根拠に「直った」と報告するな

2. 破壊的な副作用には必ず dry-run を用意させる

外部送信・課金・削除を伴うものは、--dry-run を実装の必須要件にする。無いと検証できず、検証しないまま本番投入する以外になくなる。

合わせて要求する:

• --dry-run では状態ファイル（送信済み台帳など）を一切書き換えない
• 検証者は実行前後で状態ファイルのハッシュを取り、一致を確認する

ハッシュ一致の確認まで含めて初めて「dry-run は安全」と言える。委譲先が「dry-run です」と言っただけでは、副作用の有無は分からない。

3. 検証は実装者とは別のセッション／別のエージェントにやらせる

同じ文脈を持つエージェントに検証させると、自分の前提を再利用して同じ見落としをする。別エージェントに投げ、次を明示する:

- 委譲先の自己申告は検証対象であって根拠ではない
- 自分が実行した生出力だけを根拠にせよ
- 自己申告と食い違う点は必ず明記せよ。取り繕うな
- `--dry-run` を絶対に外すな（外すと実際に外部送信される）
- コードを直すな（検証のみ）
- マージするな

「取り繕うな」を入れると食い違いが実際に返ってくる。入れないと、検証役が忖度して「概ね一致」と丸める。

4. 期待値が古くなっていないかを疑う

検証で「完了条件を再現できませんでした」と返ってきたとき、実装の不備とは限らない。指示書を書いた後に実データ側が変わった可能性がある。

実測例: 「対象が状態Aのまま6日以上経過していること」という完了条件を書いたが、その間に関連する変更がマージされ、対象は正当に状態Bへ遷移していた。実装は正しく、期待値の方が陳腐化していた。

判定手順:

1. 状態ファイルの実物から、対象の現在値とタイムスタンプを引用させる
2. その値が「正当な遷移の結果」として説明できるかを確認する
3. 説明できるなら実装は正常。指示書の期待値を書き直す

委譲先が取り繕わず差異を報告してきたときは、それを正しい振る舞いとして扱う。ここで「なぜ条件を満たさない」と責めると、次から辻褄合わせが返ってくるようになる。

5. 受け取り側のチェックリスト

マージ前に、この5つを実出力の引用付きで埋める。埋まらない項目は「未確認」と書く（推測で埋めない）。

• テストの成功／失敗の生の数字
• --dry-run の exit code と、状態ファイルのハッシュが前後一致すること
• 実データの固有値が期待どおりに出力されていること（指示書の完了条件 2〜4）
• 目的が達成された件数（「動いた」ではなく「何件が本来の宛先に届く状態になったか」）
• 副作用の無い証拠（外部へ送っていない、ファイルを書いていない）

落とし穴

「テストを増やせばいい」ではない。 上の4欠陥はどれもテストでは出ない。増やすべきはテストではなく、実データを通す回数。

マージしただけでは動かないことがある。 配置先のコードが自動更新されているか（定期的に取得しているか）を確認する。更新の仕組みが無ければ、マージは「本番に出た」を意味しない。手順の最後に「実際に動く場所で1回動かして、配線と動作を確認する」を入れる。

作業ツリーにゴミを残さない。 自動同期の仕組みがある環境では、未追跡ファイルが1つ残るだけで同期が止まり、退避ブランチが量産されることがある。委譲の指示書に「作業後に未追跡ファイルを残すな」を1行入れ、受け取り側でも git status --porcelain を確認する。

効果

この手順を入れる前は、委譲先の完了報告をそのまま信じてマージしていた。入れた後は、2回の委譲でそれぞれ4欠陥・1欠陥を検出し、いずれも本番投入前に潰せた。追加コストは「実データで1回 dry-run して出力を読む」だけ。