一覧へ
1 分で読めます

AIエージェントが書いたコードを検証する7ステップパイプライン

エージェントが1日3,000コミットを押し出す時代、人間にはすべてをレビューできない。機械がコードを検証する仕組みの作り方。

これは今最もホットなトピックだ。エージェントが1日に何百ものコミットを量産しており、誰もそのすべてをレビューできない。

OpenClawの開発者であるPeterは、1日に3,000件を超えるコミットをプッシュすることがある。これは人間が処理できる限界をはるかに超えている。人間だけでは対応できないタスクになってしまった。

最初は解決策などないと思っていた。しかしRyan Carsonの「Code Factory」を読んで、全体像がつながった。すべてを読もうとするのではなく、機械がコードを検証する仕組みを構築するのだ。

マージルールを単一のJSONファイルに定義する

どのパスがハイリスクで、どのチェックが必須かを1つのファイルにまとめる。ドキュメントとスクリプトが乖離するのを防げるのがポイントだ。

  • ハイリスクパスはReview Agentとブラウザベースのエビデンスが必要
  • ローリスクパスはポリシーゲートとCIを通過すればマージ可能

CIの前に資格チェックを実行する

レビューすら通っていないPRでビルドを走らせるのは無駄なコストだ。CIのファンアウト手前にrisk-policy-gateを置くことで、不要なCIコストを大幅に削減できる。

  • 固定順序:ポリシーゲート → Review Agent確認 → CIファンアウト
  • 未通過のPRはテスト・ビルドステージに入らない

古いコミットの「pass」を信用しない

これはCarsonが最も強調したポイントだ。古いコミットの「pass」が残っていると、最新のコードが検証なしにマージされてしまう。プッシュのたびにレビューを再実行し、一致しなければゲートをブロックする。

  • Review Check RunはheadShaと一致している場合にのみ有効
  • synchronizeイベントごとに強制的に再実行

再実行リクエストは必ず1か所から発行する

複数のワークフローが再実行をリクエストすると、コメントの重複や競合状態が発生する。些細に見えるが、これを放置するとパイプライン全体が不安定になる。

  • Marker + sha:headShaパターンで重複を防止
  • すでに送信済みのSHAはリクエストをスキップ

修正もエージェントに任せる

Review Agentが問題を検出したら、Coding Agentがパッチを当てて同じブランチにプッシュする。Carsonの投稿で最も鋭い指摘は、モデルバージョンを固定することだ。そうしないと毎回結果が変わり、再現性が失われる。

  • Codex Actionが修正 → プッシュ → 再実行トリガー
  • モデルバージョンを固定して再現性を確保

ボット同士のスレッドだけを自動クローズする

人間が参加したスレッドには絶対に手を触れない。この区別がないと、レビュアーのコメントが埋もれてしまう。

  • 現在のheadでクリーンな再実行が完了した後にのみ自動解決
  • 人間のコメントがあるスレッドは常にオープンのまま

目に見える検証可能なエビデンスを残す

UIが変わったならスクリーンショットを撮るだけでは不十分だ。CIで検証可能なエビデンスを要求する。本番インシデントをテストケースに変換して、同じ障害が再発しないようにする。

  • リグレッション → ハーネスのギャップissue → テストケース追加 → SLAトラッキング

Carsonのツール選定

参考までに、Carsonが選んだツールを紹介する。コードレビューエージェントにはGreptile、修正エージェントにはCodex Actionを採用し、3つのワークフローファイルが重要な役割を担っている greptile-rerun.ymlが正規の再実行、greptile-auto-resolve-threads.ymlが古いスレッドのクリーンアップ、risk-policy-gate.ymlがプリフライトポリシーをそれぞれ処理する。

正確性を超えて:ビジュアル検証

ここまでのステップはコードが正しいかどうかを検出するものだ。しかし実際には、出力がどのように見えるかも検証する必要がある。

2つのアプローチが際立っている。

Nico Bailonのビジュアルエクスプレイナーは、ターミナルのdiffをASCIIではなくHTMLページとしてレンダリングし、変更セットを一目で読めるようにする。

Chris Tateのエージェントブラウザは別のアプローチを取る。実際のブラウザ画面をピクセル単位で比較し、CSSやレイアウトの崩れを検出する。bisectと組み合わせることで、どのコミットがリグレッションを引き起こしたかを正確に特定できる。

codexBridgeを開発しながらこのことを考えている。どのエージェントがどのコードを書いたかを追跡するには、セッションログだけでは不十分だ。取得しやすい検索構造が必要になる。

結論

「エージェントが書いたコードを誰が検証するか」という問いへの答えは、人間ではない。機械が生み出したエビデンスを機械が判定する仕組み、それが答えだ。

ニュースレターに登録

最新のプロジェクト、記事、AIとWeb開発の実験に関する情報をお届けします。