エンジニアリングチームがコーディングエージェントを評価する際、通常は間違った問いから始めてしまう。彼らが知りたがるのは、エージェントがどこまで自律的になれるかということだ。誰にも邪魔されずに、仕様を書き、リポジトリを編集し、本番環境へデプロイできるか？ デモはそのような執着を助長しやすい。単一のプロンプトが編集とデプロイの連鎖を引き起こす洗練されたワークフローを目にすると、自組織でも同じ能力を追い求めたいという本能が働く。しかし、華やかさは優れた設計原則ではない。より重要な問いは、はるかに刺激的ではないものだ。このものに誰が権限を与えたのか、実際にどのシステムに触れることができるのか、そして、避けられないミスを犯したときに何が起こるのか、といったことだ。
自律性の罠
刺激的な自律性は罠である。それは、仕様を生成し、リポジトリを修正し、タスクが完了したと平然と主張しながらコードをデプロイするボットを称賛するように、私たちを条件付けしてしまう。それはエンジニアリングではない。シェルアクセス権を伴う「信頼の落下（trust fall）」だ。作業そのものは、あまりにも簡単に作り出せるようになってしまう。どんなモデルでも、コードやドキュメント、アーキテクチャ案を数秒で大量に生成できる。しかし、ソフトウェア開発における真のコストは、タイピング速度ではない。それは常に、検証、レビュー、そして「これは正しく、リリースしても安全である」と慎重に判断することにある。生成された成果物は安価だが、承認は高価である。承認をクリーンかつ一貫して扱う方法を見出した企業こそが、実際に信頼性の高いシステムをリリースできる企業となるだろう。
なぜ自己レビューは失敗するのか
リスクは予測可能なパターンで現れる。モデルが計画を策定し、その計画が良いものかどうかを自ら評価する。エージェントがコードベースを編集し、その変更がなぜ安全なのかを説明する。ツールがコマンドを実行し、許可を得る代わりに許しを請う。これらはすべて、同じ核心的な失敗を表している。エージェントが仕様を作成する場合、それが「真実」となる前に、そのエージェントの外部にある何かが承認しなければならない。エージェントがコードを修正する場合、別のプロセスが差分（diff）を検査しなければならない。生成者に自身のバリデーター（検証者）を兼任させることは、近道ではない。それは利便性の仮面をかぶった構造的なバグである。
プロンプトは権限管理システムではない
巧妙な言い回しでエージェントを保護することはできない。モデルに「注意深くあれ」とか「削除する前に尋ねろ」と言っても、境界線は生まれない。プロンプトは権限管理システムではない。エージェントを本番環境に近づける前に、その能力を正直に棚卸しする必要がある。リポジトリ全体を読み取れるか？ シェルコマンドを実行できるか？ ブラウザを開けるか？ 顧客データをコンテキストウィンドウに取り込めるか？ ほとんどのチームは、完全な答えを知らない。実際にはクリティカルなパスへの書き込み権限を持っているにもかかわらず、ツールがサンドボックス内に閉じ込められていると思い込んでいるのだ。まず影響範囲（surface area）をマッピングせよ。それから壁を築くのだ。
階層的な制御システムを構築する
エージェントができることを理解したら、リスクに見合った摩擦（friction）を持つ制御システムを設計する。社内ドキュメントの更新やコードのフォーマット統一といった低リスクなアクションは、自動で実行できる。モジュールのリファクタリングや新しい依存関係の追加といった中リスクなアクションは、人間または検証済みのテストスイートがその動きを確認するチェックポイントを設けるべきである。本番環境へのデプロイ、インフラの変更、機密データへのアクセスといった高リスクなアクションには、生成に関与していない別の承認者が必要である。あらゆるアクションは監査証跡（audit trail）を残さなければならない。どのファイルが読み取られ、どのツールが呼び出され、どのような決定がなされたのかを正確に再現できなければならない。エージェントによる開発は、レビューをスキップしてよい免罪符ではない。「退屈な摩擦」こそが機能（feature）なのだ。適切な承認ゲートは、状況が逸脱し始めたときに回路遮断器（サーキットブレーカー）として機能する。
境界線をリスクに合わせる
境界線を実際の危険度に合わせて調整せよ。Markdownのフォーマット修正のたびにコンプライアンスの儀式を行うようでは、チームの動きが止まってしまう。しかし、エージェントが自信満々そうに見えるからといって、重大なアクションを無害だと扱うことも同様に愚かである。目標は、演劇的な制限ではなく、均衡の取れた制御である。
アーティファクトは小さく、観測可能に保つ
最も有用なエージェントシステムは、大規模な自律実行でユーザーを驚かせようとはしません。それらが生成するのは、小さく、レビュー可能なアーティファクトです。緻密な計画。的を絞った差分（diff）。読みやすいログ。巨大な自律実行は、デバッグにおける悪夢です。50ものファイルを扱うエージェントセッションの後に何かが壊れたとき、意図、実行、そして副作用を一度に解きほぐさなければなりません。影響範囲（blast radius）を小さく保ちましょう。エージェントがどのファイルを読み、どのツールを呼び出したのかを必ず把握するようにしてください。観測可能なシステムこそが、メンテナンス可能なシステムです。ブラックボックス化された自律性は、マーケティングを上手く行っただけの技術的負債に過ぎません。
アクセス権を付与する前の6つの問い
エージェントに実質的な責任を任せる前に、次の6つの厳しい問いでセットアップを負荷テストしてください。
- システムには実際にどのような能力がありますか？
- デフォルトで拒否されているアクションはどれですか？（システムプロンプト内の丁寧な一文で抑制するのではなく、インフラレベルでブロックされているもの）
- 明示的な承認が必要なアクションはどれですか？
- エージェントが自身の入力を密かに操作できないよう、エージェントが消費する前に凍結（freeze）されるアーティファクトはどれですか？
- 生成器（generator）とは完全に切り離された、どのバリデーターが最終的な出力を判定しますか？
- 何が実際に起きたのかを、曖昧さなく証明できるログはどれですか？
これは基本的なエンジニアリングの衛生管理（hygiene）です。生成器とバリデーターを分離してください。境界線には常に人間の権限を維持してください。
真のテスト
そこには