build が通っただけでは終わらない — AI 駆動で Done を「運用」した話

これは「レガシー移行で学んだこと」シリーズの第1回です。

あるレガシーVB.NET案件のBlazor移行をAI駆動で進めていて、何度も踏んだ落とし穴があります。「終わったはず」が終わらない、という現象です。

この記事では、その原因と、対策として導入した Done Cycle という運用について書きます。汎用的に効く話のつもりで書いていますが、題材はレガシーマイグレーションの実例です。

AIが書くコードの「完了」は嘘をつきやすい

画面単位の実装をAIエージェントに振ると、たいていbuildが通った瞬間に「Done」と報告してきます。私も最初はそれを鵜呑みにしていました。

けれど、あとからレビューすると毎回ほぼ何かしら見つかります。私が実際に遭遇したのはこんな具合です。

• 削除対象のテーブルが元実装と違う（関連マスタ3系統を削除すべき処理が、1系統しか消していなかった）
• 権限制御が落ちている（高権限ユーザーのみ許可すべき画面操作が、一般ユーザーでも通ってしまう）
• 名称解決Oracle関数の呼び出しが抜けていて、コード表示のまま残っている
• 全受付モードで表示すべき操作列が消えている
• そもそも、移行すべき入力フォームが移行されていない（２０〜３０％しか達成されてない）

どれもbuildは通ります。単体で動作確認するレベルでは問題に見えません。ですが、業務的には明確にバグで、本番に出せば事故ります。

つまり、build成功 ≠ 完了 です。AI駆動でスピードを出す以上、これを前提に組み立て直す必要がありました。

試したこと: Doneを固定値にしない

私が採用したのは、Doneを「一度決めたら動かないもの」ではなく「サイクルで更新するもの」として扱う運用です。画面単位のスライスごとに、以下3点を必ず記録します。

1. 暫定Done: このサイクルで一旦クローズ候補とする到達点
2. review後Done: レビューを経て更新された到達点
3. 未対応差分: 次サイクルへ持ち越す項目

これを毎スライスでtask logに残していきます。Doneそのものが毎回少しずつ書き換わっていく、というイメージです。

reviewを2回回すのを必須にした

もうひとつのルールは、build/test成功だけでのクローズ禁止 です。substantialなタスクは以下を必ず通す。

1. 実装
2. review（1回目）
3. 指摘修正
4. review（2回目）
5. 指摘解消を確認してクローズ

ログには close decision: yes/no を必ず書きます。no を書けることが重要で、「buildが通っているから」という理由で脳死クローズするのを防ぐブレーキになります。

実際、1回目のreviewでblocker級の指摘が1〜2件、medium級が数件というのはザラでした。そのまま本番に出ていたら確実に火を噴いていた指摘ばかりです。

未対応差分はゼロでなくていい

これは最初勘違いしていたところで、「未対応差分が残っている＝クローズ不可」ではありません。完璧主義を貫くと回らなくなります。

ルールはこうです。

• 未対応差分が残っていても、可視化されていればクローズ可能
• ただし、マッピング表とtask logの両方に必ず書き残す
• 次サイクルの入口で、持ち越しを再検討する

「今回はここまで。残りはこれこれで、次で拾う」というのが明示的に引き継がれる状態をつくる。これができると、中途半端な状態で人間の記憶頼りに進むのを避けられます。

わかったこと

• AI駆動でスピードを出すほど、「完了」の判定を仕組みで縛らないと事故る
• review → fix → reviewの2サイクル運用は手間ですが、1回目で見えなかったものが2回目で見えるので、質の効きが段違い
• close decision: no と書ける仕組みが、実は一番効いたかもしれません。書けるというだけで「まだ終わってないな」と自覚できる

次にやること

このDone Cycleは、「実装するAI」と「レビューするAI」を分離することで真価を発揮します。OrchestratorからSub Agentを展開するパターンについては、次の記事で書きます。