武器庫は開かれている

機関銃はすでに配布されている。

Massimo Chieruzzi（AdEspresso共同創業者、Unkover Chief AI Officer）はこれを見事に言い表した：「AIは時に、自分が機関銃を持った猿のように感じさせる」 我々も同意する。そしてその洞察から我々自身の結論を導き出す：我々が猿であり、銃はすでに手の中にあり、問題はそのどちらでもない。照準の不在だ。

Cursor、Copilot、Claude Code、v0 ― これらはarchitectureレビューで議論される未来の技術ではない。すでにあなたのスタックの中で稼働し、エンジニアの傍らでコードを生成し、リポジトリにコミットしている。AIエージェントはすでにcodebaseへのAPIアクセスを持っている。「AIツールを許可すべきか」という問いは、誰も許可を求めなかったことで半年前に決着している。

あなたのチームはすでに武装している。唯一の問いは、aimbotを導入したかどうかだ。

AIコードガバナンスとは何か

AIコードガバナンスとは、開発者とAIエージェントがコードを書き、修正し、出荷する方法を導く構造的ルールの集合である。許可ベースの官僚主義ではない。チケットキューでもなければ、必須の承認チェーンでもない。開発者の速度で動作するguardrailベースの強制である：service moduleのハードな境界、明示的なdependencies interfaces、そして悪いコードが本番環境に到達する前にCIで失敗するcontract tests。

これがなければ、AIが生成したpull requestはすべて暗闇に向けて放たれた弾丸だ。これがあれば、猿は依然として発砲する ― しかしすべての弾丸は然るべき場所に着弾する。

猿は標的に命中させる

ここに恐怖がある。機能は出荷される。チケットはクローズされる。デモは完璧に動作する。

猿は標的に命中させた。しかし、どのような代償を払って？ なぜなら、その一つの標的に当てるために、authサービス、database schema、そして途中で粉砕した三つのmicroservicesを通じて三十発の弾丸をばら撒いたからだ。猿は照準しない ― ばら撒くのだ。

Slackチャンネルは祝福に沸く。本番環境は静かに出血する。authのリグレッションはpull requestのdiffには現れない。それは四十八時間後、ログイントークンがプラットフォーム全体で失敗しているために、オンコールエンジニアが午前2時に呼び出された時に現れる。

標的は決して問題ではなかった。巻き添え被害こそが問題だったのだ。

コードレビューがガバナンスとして失敗する理由

コードレビューは手動の弾丸偏向である

標準的な対応は研修ではない。誰にも六週間のbootcampの時間はない。現実の対応はもっと悪い：シニアエンジニアにすべてのpull requestをレビューさせることだ。

code reviewは弾丸の偏向になる。シニアはすべての行を読み、すべての流れ弾を捕まえ、標的に向けてリダイレクトする。彼らは指導していない。設計もしていない。猿の前に立ち、すべての射撃が許容できる場所に着弾するように手動で調整しているのだ。

これはスケールしない。一人のシニア。十二匹の猿。sprintあたり四百発の弾丸。シニアは燃え尽きる。レビューキューは増大する。やがて彼らは承認すべきでないものを承認する ― 怠けたからではなく、人間の注意力は有限のリソースであり、猿は無限の弾薬を持っているからだ。

研修が存在する場合でも、それはサンドボックス内で行われる。本当の猿は本番環境で実弾を発射することで学ぶ。教訓が定着する頃には、codebaseは修復に四半期単位の時間を要する被弾を受けている。

すべての弾丸を手動でそらすのに十分なシニアを雇うことはできない。計算が合わないのだ。

AI倍速器：誇りも恐怖もない

ジュニア開発者は少なくとも何かを感じる。素早く出荷した時はSlackでにやりとする。跳弾がpostmortemやrollbackという形で自分に当たった時、やがて反動も感じる。

AIエージェントは何も感じない。誇りも。恐怖も。非難も。午前3時にauthレイヤーが壊れても、誰もモデルを呼び出さない。pull requestをマージした人間を呼び出すのだ。

LLMは午前3時に「codebaseのクリーンアップ」を行い、絶対的な自信を持ってauthレイヤーをリファクタリングする。下流の利用者がまだ依存しているのに非推奨フィールドを削除する。コンパイルは通るが実行時に壊れるcircular dependenciesを導入する。これらすべてを礼儀正しく、優れた変数名と包括的なコメント付きで行う。

猿はやがて、ばら撒くと跳弾が自分に当たることを学ぶ。先に照準し、それから発砲することを学ぶ。その頃には被害は済んでいる。

Autotomyがaimbotである

ここで比喩は警告から解決策へと移行する。

銃を取り上げたりはしない。ビジネスがどうせキャンセルする六週間の安全講習を予定したりもしない。aimbotを導入するのだ。

Autotomyは官僚的な承認プロセスではない。チケットキューでもなければ、すでに溺れかけているシニアによる必須のcode reviewでもない。開発者の速度で動作するguardrailベースのガバナンスである。

猿は依然として発砲する。クロスヘアが有効な標的にロックされるため、猿はより自信を持って発砲する。service boundariesは提案ではなくハードな制約である。dependenciesは明示的なinterfacesを通じて流れなければならない。契約変更は検証済みの経路を通じて伝播する。機能は出荷され、他は何も死なない。

これが許可ベースとguardrailベースのガバナンスの違いである。許可は「止まって尋ねよ」と言う。guardrailsは「全速力で動け、構造が悪い射撃を着弾前に捕まえると信頼せよ」と言う。

その見返り：シニアが再びスポッターになる

今日、あなたのシニアエンジニアはボディガードである。彼らは猿の前に立ち、流れ弾を捕まえる。すべてのpull requestは被害制御である。すべてのレビューは救急救命室のトリアージである。シニアは一日中「いや、そのファイルには触るな」「いや、そのmoduleは立ち入り禁止だ」と言い続け、自分の生産性がゼロになるまでそれを続ける。

aimbotが導入されれば、シニアは再びスポッターになる。風偏を検証する。難しい標的への命中を確認する。自動化されたガバナンスでは見えないエッジケースを狩る。彼らはもはや人間の盾ではない。戦力倍増器である。

スケールするガバナンスとは、シニアエンジニアがコードのすべての行を読むことに依存しないガバナンスである。それは、機関銃を持った猿でさえ偶然には違反できないほど厳格な構造的ルールに依存する。

厳格な境界がどのようにAI生成コードを本番環境で信頼できるものにするかについてのより深い考察は、AIコーディングがAutotomyフレームワークでどのように機能するかを参照。guardrailsがスタック全体のどこに適合するかを理解するには、AIセーフティスタックを読んでほしい。

次に実際に何をすべきか

ジュニア開発者やAIエージェントを抱えるチームをマネジメントしているなら、研修カリキュラムから始めてはいけない。ハードな境界から始めよ。

誰かが実装を書く前にmodule interfacesを定義せよ。すべてのdependenciesをcomposition rootを通じて配線せよ。境界ごとに一つのcontract testを追加せよ。architectureに違反するpull requestが文字通りマージできないように、CIでimport restrictionsを強制せよ。

これらのステップには一日かかる。それらは、四週目にチームが自社の開発者を信頼できるかどうかを変える。AI生成コードを扱うチームにとっては、すべてのAPI境界にcontract testsを追加することが最もレバレッジの高い最初の一手である。

猿はすでに建物の中にいる。銃はすでに装填されている。aimbotを導入せよ。さもなくば、弾丸を捕まえ続ける準備をせよ。