AI がアプリを書いたあと：その diff をレビューして Merge できるか

まず結論から。AIがどんなコードでも書けるようになったとき、「速く書ける」はもはや優位性ではない——誰もが持っているからだ。本当に希少なのは、あなたがあのMergeボタンを押せるかどうかである。そして押せるかどうかは、AIがあなたに手渡したものが、審査でき、ガバナンスでき、責任を負えるものかどうかにかかっている。

すでに毎日起きている場面から見ていこう。

あるエンジニアがコーディングエージェントに「カスタマーサポートの返金用の小さなアプリを作って」と頼んだ。30分後、動くアプリが現れた。フロントエンド、API、データベースのマイグレーション、テスト——すべて揃い、CIは全部グリーン。彼女はPRを開き、一行の文字を見る。+8,142 −0。

そこで彼女は固まった。

この8,000行は彼女が書いたものではない。一行も読んでいない。返金額の上限チェックはどのファイルにある？このAPIは他人の返金記録まで返してこないか？これをいじったら帳簿の突合にも波及しないか？わからない——誰もわからないからだ。CIがグリーンなのは「コードが矛盾なく動いた」ことを証明するだけで、「それが正しいことを、許された範囲だけやっている」ことは証明しない。

彼女には二つの選択肢があり、どちらも最悪だ。腹をくくって審査したフリをしてMergeを押す——誰も理解していないブラックボックスを本番に投入する。あるいは本当にこの8,000行を一行ずつ読む——それなら自分で書いたほうがマシだ。これこそがAI時代の真の新しいボトルネックである。コードを書くことではなく、Mergeを押すことだ。

コードを書くことはコモディティ化したが、「信頼」はしていない

この10年、エンジニアの希少な能力は「それを書き上げられること」だった。その能力はいま、AIによって急速かつ徹底的に均（なら）されつつある。アプリを一つ生成する限界費用がゼロに近づくとき、「速い」はもはや誰の堀でもない——あなたの競合のエージェントだって同じくらい速い。

前面に押し出されてきたのは、ずっとそこにあったのにコードを書くコストに覆い隠されていた別のことだ。誰かがこのコードに責任を負わなければならない。 「それはどのデータを読み、どんな操作ができ、間違いは誰の責任で、監査は追えるのか」に答えられる人間が要る。AIが「書く」コストをゼロに削った後、「審査とガバナンス」がプロセス全体で最も高価で、最も重要な区間になる。レビュー可能性こそが、AIがコードを書く時代の新しい堀だ——誰がたくさん生成するかではなく、誰が生成したものを本番に出せるかである。

これはまさに Vibe Coding の技術的負債 と AI Agent 試験導入が本番に進めない理由 の二本が語ったのと同じことの別の面だ。Vibe Codingは誰もがアプリを生成できるようにしたが、生成し終えても誰も本番に出せない——審査できる人も、保証できる人もいないからだ。違いは視点だけ。あの二本が企業や意思決定者の視点で見たのに対し、本稿はあなた——あのMergeボタンに指をかけている本人——の視点で見る。

「もう一つのAIに審査させる」がなぜ環を閉じられないか

最も自然な反論はこうだ。AIが書けるなら、AIにreviewさせればいいじゃないか、と。コードレビューエージェントも自動セキュリティスキャンも、いまや揃っている。

この道は一部を防げる。だが、本当に致命的な環は閉じられない。

あの GET /api/refunds に戻ろう。それは全員の返金記録を返してしまった——にもかかわらず、ほぼすべての自動チェックを通過しうる。構文は正しく、ヌルポインタもなく、テストもある（テストも同じエージェントが書いたので、当然「返金が取得できる」しかテストしておらず、「他人の返金を取得してよいのか」はテストしない）。AIレビューが得意なのは、コードがそれ自身に対して正しいかだ。バグがないか、既知の脆弱性パターンに合致しないか、スタイルが一貫しているか。だが、コードの外側にある三つの問いには答えられない。このコードはこのテーブルを読んでいいのか？この操作はこの金を動かしていいのか？これは私たちが望んだビジネスルールなのか？

これらの答えはコードの中にはない——権限モデルの中に、承認ポリシーの中に、ビジネス上の意図の中にある。二つのAIが互いに頷き合っても、ガバナンスにはならない。 監査担当者、法務、セキュリティチームが求める「誰が承認し、誰が責任を負うか」という答えには、どれだけ賢いレビューモデルでもサインできない。だから「AIにAIを審査させる」が省けるのは人がコードを読む労力であって、人がやらなければならない「やっていいのか」の判断は省けない。問題は振り出しに戻る。人が審査できなければならない。だが8,000行は、人には審査しきれない。

出口：AIがあなたに渡すものを、審査できる大きさまで縮める

8,000行を審査できないことと、このシステムが半年後に腐ることは、同じ一つの原因だ——あの実装の塊を誰も本当には理解していない（これがあの記事の言う「理解の負債」である）。

ならばAIが届ける形態を変えればいい。実装を生成させるのではなく、宣言を生成させる。同じ返金アプリでも、AIがあなたに渡すべきは8,000行のコードではなく、こんなメタデータの diff だ。

+ object: support_refund
+   amount: currency (min 0)
+ permission: support_agent
-   allowDelete: true        # エージェントが生成した初版は与えすぎていた
+   allowDelete: false       # 審査で取り戻す：サポート担当は返金を削除できない
+ flow: refund_amount > 500 → 経理の承認が必要

この十数行なら、あなたは一行ずつ読んで理解でき、5分でレビューでき、ワンクリックでロールバックできる。さらに重要なのは末尾の数か所だ。審査はもはや「読み切れるか」ではなく、「この権限は正しいか、この承認しきい値は妥当か」——あなたが本当に判断でき、あなたが判断すべきビジネス上の問いになる。あの漏洩する GET /api/refunds はここには端から現れない。support_refund の読み取り権限は「呼び出し元の権限に従う」と宣言され、ランタイムがそれを強制する。越権という道は、源流で閉ざされている。

では実装はどこへ行った？実装は、繰り返し監査され、すべてのアプリが共有するランタイム（ObjectOS）に属する。各アプリがそれぞれ一份ずつ生成するものではない。「やっていいのか」——読めるのか、削除できるのか、承認が要るのか——はランタイムが実行時に強制するのであって、8,000行のどこかに埋まって運任せになるのではない。

本当に閉じられるループ

これを流れに描けば、人が常にその場にいながら、コード量に溺れることのない閉ループになる。

④のステップに注目してほしい。ビジネス定義それ自体がオブジェクトと権限を宣言しているので、ランタイムはそれを一組のガバナンスされたツールへと投影する——その結果、同じエージェントがこのアプリを「書いた」だけでなく、その後も同じ権限境界の内側でそれを操作できる（返金を照会する、返金を起こす）。一つひとつのステップが身元を帯び、痕跡を残す。書くことと使うことが、一つのガバナンスを共有する。

まず冷や水を浴びせておく

この戦法には境界がある。はっきりさせておこう。

第一に、すべてがメタデータになるわけではない。まったく新しいリアルタイムアルゴリズム、独自のレンダリングパイプライン——これらは依然として本物のコードを必要とし、依然として誰かが腹をくくってその部分をreviewする必要がある。メタデータは助けにならないし、無理に当てはめればかえって事を損なう。それが得意なのは、企業の中で何度も再構築される、あの90%の業務システムだ。

第二に、信頼は移転されたのであって、消滅したのではない。あなたはもう各アプリの実装を一つずつreviewしないが、その信頼をあのランタイムに賭けている——それは一度真剣に審査され、継続的に保守されなければならない。だが計算してみよう。従来のやり方では、AIがアプリを一つ生成するたびに、新しいコードの塊を一から信頼し直さなければならなかった。メタデータのやり方では、ランタイムを一度審査すれば、その後そこから派生する各アプリは、検証済みの同じ権限と監査を自動的に継承する。一度審査すれば、千回審査するに勝る。 これはずっと割のいい取引だ。だが、それは取引であって、魔法ではない。

結びに

AIがコードを書けるようになることは、エンジニアを失業させはしない。だがエンジニアが最も守るべき関所を変える。「書けるかどうか」から、「AIが書いたものに、サインできるかどうか」へ。

そしてサインできるかどうかは、AIがあなたの前に何を置いたかにほぼ完全に左右される——読み切れない8,000行の実装か、それともあなたが審査でき、ランタイムがガバナンスできる数十行の宣言か。あなたのエージェントに大量のコードを書かせるのはやめて、あなたが審査でき、ランタイムが支えられる目標を生成させよう。

npm i -g @objectstack/cli && os start

「CRUDを作って」の一言ではなく、宣言的でガバナンス可能な目標をあなたのコーディングエージェントに指し示そう——そして次のPRの diff が、ついにあなたがMergeを押せるほど小さくなっているか、見てみよう。