爆発半径を制御する

AI Codingについて議論するとき、多くのチームが今も最初に考えるのは同じ問いだ。Agentがコードを書いたあと、誰がReviewするのか。Mergeさせてよいのか。問題が起きたら誰が責任を負うのか。

どれも間違った問いではない。ただし、そこには古い前提が引き継がれている。一度のコード変更は高コストで危険だから、mainブランチへ入る前にまとめて検査し、慎重に通さなければならないという前提だ。

PRのワークフローは、この前提のもとで発達した。人がコードを書くには時間がかかるため、一度の変更は大きくなりやすい。Reviewできる人も限られている。そこでチームは、コードをいったん止めて検査する明確な関門を必要とした。Mergeは門のようなものになる。門の手前は下書きで、通過したあとに初めて現実の世界へ入る。

Agentはこの損得勘定を変える。小さな変更を次々と提出し、テストを自動で実行し、失敗が見つかれば修正を続けられる。Gitには完全な履歴も残る。変更が十分に小さく、問題をすぐに発見でき、失敗から実際に復旧できるなら、すべての変更を仰々しい人間のReviewに並ばせることが、かえってシステムで最も遅い部分になりうる。

問うべきなのは、もはや「PRがあるか」ではない。この変更の爆発半径は、どれほど大きいのか。

信頼の根拠は損失が限定されていること

個人用のTodo Listは、たいてい失敗コストの低いソフトウェアだ。一方、銀行の勘定系システムは失敗コストが高く、責任密度も高い。ソフトウェアのリスクの高低は、機能の複雑さだけでなく、現実にどれほど大きな結果をもたらしうるかで決まる。

失敗コストの低い仕事をAgentに自律的に任せるために、AIが絶対に間違えないと証明する必要はない。Agentに自由を与えるのは、十分に賢いと信じるからではなく、間違いのコストが低く、見つけやすく、元に戻せるからだ。

したがって、優れたAgent基盤は「より多くのことをさせる」だけでなく、一つひとつの行動の爆発半径を小さくし続けなければならない。

隔離されたワークスペースを使い、複数のタスクが互いに汚染しないようにする。
コミットを十分に小さく保ち、いつでも原因を特定して取り消せるようにする。
Feature Flag（機能フラグ）、段階的リリース、自動ロールバックで影響範囲を制限する。
まずテスト環境で動かし、そこから少しずつ実際のユーザーへ近づける。
Agentにはコードだけでなく、根拠も提出させる。
一つの大きな変更を、個別に検証できる小さな変更へ分解する。

Sandbox（サンドボックス）は、こうした制約をタスク環境の性質に変える。Agentごとに独立した環境、明確なライフサイクル、限定されたタスク境界を用意する。人がすべてのTerminalを見張らなくてもタスクを走らせることができ、問題が起きても作業環境全体を巻き込まずに済む。

Gitが取り消せるのはコードであって、世界ではない

Gitの可逆性は、安心できそうな錯覚を生みやすい。バージョン管理があるのだから、何を恐れる必要があるのか。問題が起きたらRevertすればよい、と。

データベースから削除されたデータは、コードをロールバックしても自動では戻らない。送信済みのメールは取り消せず、引き落とした金額も自動では返金されない。漏洩した秘密情報が再び秘密に戻ることもない。誤ったAPIレスポンスを顧客のシステムが受け取り、それに基づいて行動したなら、その行動も消えない。

こうした操作が、Agentの前に置かれた核の発射ボタンだ。

核の発射ボタンは、必ずしも恐ろしい見た目をしていない。普通のDELETE、データベースマイグレーション、通知を送るAPI、あるいは一見いつもどおりの本番デプロイかもしれない。危険なのはコマンドそのものではない。実行された時点で世界が変わり、Gitでは元に戻せないことだ。

だからAgentのガバナンスに必要なのは、「すべての操作を人が承認すること」でも、「すべて自動化し、失敗したらロールバックすること」でもない。より合理的な境界は、爆発半径の小さい操作をAgentに自律的に任せ、不可逆で爆発半径の大きい操作の最終承認を人に残すことだ。

境界はPromptだけでなく権限に組み込む

この境界をPromptに書くだけでは足りない。Coding Agentが本番データベースへの書き込み権限、クラウドアカウントの管理者権限、外部へメッセージを送る能力を同時に持っているなら、どれほど優れたシステムプロンプトも丁寧なお願いにすぎない。

信頼できるHarness、つまりAgentを支える実行環境、ツール、権限体系は、能力を分離しなければならない。Agentはマイグレーションスクリプトを準備できるが、直接実行はできない。メールを作成できるが、会社を代表して送信はできない。隔離環境へデプロイできるが、本番へ進むには別の独立した検証が必要になる。

人の役割も変わる。これまで人は、コードを一行ずつReviewして品質を管理してきた。これからより重要になるのは、変更の境界を設計することかもしれない。何を自動で試してよいのか。失敗をどう検出し、どう復旧するのか。一度実行したら取り消せない操作は何か。最後のボタンを押せるのは誰か。

すべてのコードを一行ずつ確認すれば、全体をまだ掌握しているという安心感を得やすい。しかし本当に危険なのは、ある一行が美しく書かれているかどうかではない。ありふれた間違いを、システムが収拾のつかない事故へ拡大してしまうかどうかだ。

新しい世界にも門はある。ただし、すべてのMergeの前に機械的に置くべきではない。

爆発半径が急に広がる場所にこそ、その門を置くべきだ。