ビルドが自らを検証する仕組み

0:00 — ビルドが完了します。エージェントは「完了しました」と言いますが、それはコードを書いたという主張であって、コードが動くという主張ではありません。AIビルダーを使ったことのある人なら誰もが一度は、この2つの主張のギャップを感じたことがあるはずです。プレビューを開き、3番目のボタンをクリックしても何も起こらない、というように。私はまさにその瞬間にデモルームが静まり返るのを見たことがあります。だからこそ、人間が見る前に、ビルドは約6分間、自分自身と議論するチェーンを通過します。実際にどんなものかを、失敗して修正された1つのビルドを追いながら見ていきましょう。

0:02 — コードレビューが始まります。コードを書いたエージェント自身が自分の宿題を読み返すのではなく、別のエージェント、異なるプロンプト、ビルドが通るかどうかに利害関係のないエージェントが行います。この分離は見た目以上に重要です。午後2時14分に「エラーハンドリングのないfetch呼び出しでも問題ない」と判断したエージェントは、自分の作業を確認するよう頼まれても午後2時15分にも同じ判断をするでしょう。「何が壊れているか見つけて、ファイルを指摘して」と指示された新規のレビュアーは、あなたが本当に欲しい、口うるさいシニアエンジニアのように振る舞います。過去のあるビルドでは、カートの合計が静かに更新されなくなる不具合を発見しました――`updateTotal`が`Cart.jsx`で定義されているのに、数量変更のハンドラーに接続されておらず、関数は存在するのに一度も実行されない状態でした。これがコードレビューが対象とするカテゴリです――コンパイラが見逃す類のものです。

0:04 — セキュリティ監査。見た目より対象は絞られていて、意図的にそうしています。これはペネトレーションテストではなく、AI生成コードで実際によく見られる少数の間違いのパターンハンティングです。文字列連結によるSQL。すべてを説明しているかのように信頼されているクライアント側だけの検証。そして特に目立つのが、ハードコードされたAPIキーです。その機能を書いたエージェントの目の前に環境変数の慣習が用意されていなかったため、うまくいく方法に手を伸ばしてしまったのです。これはあまりに頻繁に見かけるので、もはや驚きにもなりません。

0:07 — リンクとSEO。地味ですが、顧客が気づくまで誰も気づかないものを検出します――ナビゲーションリンクが /pricing を指している一方、実際のページは /price、404になるページのサイトマップエントリ、テンプレートのプレースホルダーテキストがそのまま残ったメタディスクリプション。どれもビルドを壊しはしません。しかし、そのすべてが静かに、ユーザーの多くがサイトを作った本来の目的——見つけてもらい、クリックしてもらうこと——を台無しにしています。

0:09 — アクセシビリティ。これは完全な手動監査ではなく、自動化されたaxe-coreのパスです。このトレードオフが何をもたらすかは正直に言っておく価値があります。axe-coreはコントラスト比、alt属性の欠落、ラベルのないフォーム入力、タブ順序の罠を検出します――機械的なレイヤー、完全なWCAGレビューが指摘する内容のおよそ30〜40%程度です。技術的には準拠しているが実際に使うと本当に分かりにくいスクリーンリーダー体験は検出できません。数秒で実行でき、ここを通るもののほとんどがマーケティングサイトや小さなツールであって、部分的な監査が誰かにとって本当のリスクになるようなアプリケーションではないため、自動化のみを選びました。

0:11 — 適合性チェック。このレイヤーが問うのは「これは良いか」ではなく「約束通りになっているか」です。計画では4ページ用意すると言っていたのに、ビルドが3ページしか出さなかった――適合性チェックがそれに気づきます。計画では動作する問い合わせフォームを約束していたのに、実際に出てきたのは送信アクションのないフォームだった――同じレイヤー、同じ検出です。これはユーザーに最も直接的に応える検証です。抽象的な品質概念ではなく、ユーザーが述べた意図そのものと照らし合わせて測定するからです。

0:13 — ブラウザ内チェック。ここで実際に、私たちのビルドが壊れました。このレイヤーはコードを読むのではなく、実際にブラウザを操作するため、ごまかしが最も難しいものです――クリックし、入力し、待ち、DOMが期待通りに変化したかを確認します。今回のビルドはアイドルゲームで、ゲームにはこのレイヤーで追加の検証が入ります。ゲームはピクセル完璧に描画されていても遊べないことがあるからです――スコア表示は完璧に見えても、実際のスコアロジックとまったく繋がっていないことがあります。検証者はゲームをプレイしました。スコアは問題なく更新されました。音は一切鳴りませんでした。

3回の試行、そしてエスカレーション

この発見は不具合報告として私たちに届いたのではなく、直接修正パスに送られ、チェーンはビルド内で最大3回まで再検証を行いました。1回目:修正はミキサーの初期化部分に触れましたが、そこはすでに問題なかったため、音は依然として鳴りませんでした。2回目:別の修正が、隣接して見えるロード状態のエッジケースに対処しましたが――これは想定以上によく起こることですが――元の問題を解決しないまま小さな新しい問題を生んでしまいました。3回目:それでも音は鳴らず、この時点では通常、本当に難しい問題か誤検知のどちらかを見ていることになりますが、今回は前者、本当に難しいケースでした。

そこでプラットフォームは自らエスカレーションしました。残っている発見だけに絞った追加の修正実行をキューに入れ、ビルド本体ではなくクローン上で作業を行いました――つまり、このエスカレーション実行が失敗しても、すでに手元にある動作するバージョンを失うことはありません。その実行が実際の原因を突き止めました。以前のデバッグパス中に設定されたまま元に戻されていなかったミュートフラグが、過去2回の修正が触れていたのとはまったく別のファイルに残っていたのです。フラグを解除して再検証したところ、通過しました。このビルドが誰かに見られる前には、すでに正常に動作していました。

次回はスキップすること

そのアイドルゲームが動く数か月前、私たちはシステム全体のもっと緩いバージョンを試したことがあります――検証者が、どんな懸念でも、どんな言い方でも自由に提起できるというものです。結果として出てきたのは「これはヘルパー関数に切り出した方がいいのでは」「この変数名はもっと分かりやすくできるのでは」といった、丁寧に見えて何も修正しない指摘でした。修正パスは丸ごと1ラウンドを、実際に壊れているものの修正ではなく文章の磨き上げに費やしてしまいました。私たちはルールを「ファイルを指摘する、失敗を説明する、さもなければ何も言わない」に厳格化しました。検証者からの出力はおよそ半分に減り、残ったもののほとんどが実行可能な内容になりました。もしゼロから作り直すなら、緩いバージョンは完全に飛ばして、最初から証拠のルールに行くでしょう。この教訓を高くついて学ぶ必要はなかったのに、実際にはそうしてしまいました。

このルールには本当のコストがあり、それを隠すつもりはありません。「このAPI設計は半年後に誰かを苦しめるだろう」といった、漠然としているが真実味のある懸念は、今では取り上げられません。検証者はそれを具体的な失敗に結びつけられないからです。私たちはそのトレードオフを受け入れています。アーキテクチャレビューも行うチェーンでは、すべてのビルドに対して実行できるほどの速さは出ません。そして速さこそが、人間に頼むのではなく自動でこれを実行する意味そのものです。

誰かに聞かれたら、4回目のラウンドを追加するのもやめておくべきだと答えます。ラウンド数は実際のビルドに対してチューニングしたもので、3回目を超えた限界的な価値は急激に下がります。1回目で修正可能な発見のほとんどが解決され、2回目は主に1回目が生んだ問題の後始末をし、3回目に残っているものは本当に難しいか、そもそもあまり壊れていなかったかのどちらかです。4回目のラウンドは、同じ結果のために待ち時間を長くするだけです。

これらはすべて無料ではなく、また完璧でもありません。6つのレイヤーと、必要な数だけの修正ラウンドが加わることで、すべてのビルドに実際の時間がかかります――1分未満で完了するのと、数分かかるのとの違いです。自分の顧客の前に出すものであれば、これは正しいトレードオフだと私たちは考えていますが、「速い」ことと「検証済み」であることは相反する方向に引っ張り合うもので、私たちは検証済みを選びました。検証者もLLMなので、実際には壊れていないものを時々指摘したり、実際に壊れているものを見逃したりすることがあります。証拠のルールと複数回のループは、それに対するヘッジであって保証ではありません。

最終的に手に入るのは記録です――どのレイヤーが実行され、何が見つかり、何が修正され、あなた自身の判断に委ねられた内容が何かというものです。この記録こそが、コードそのものよりも実際の製品に近いものです。完成しているように見えるからビルドを信頼するのと、何か敵対的なものが最初に壊そうとして失敗したからビルドを信頼するのとの違いです。