# 委譲先の「テスト全通過」を信じない — 実データ 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 して出力を読む」だけ。 ---