企業のあらゆる領域において、承認と説明責任をめぐるルールは不変であることが期待されている。アプリケーションが独立した承認なしに自ら権限を付与することはない。トレーダーが事前承認基準を経ずに自らの取引を承認することもない。あらゆる機能には独立した統制が横に置かれ、問題が起きたときに誰が責任を負うのかについて明確な答えがある。
多くの企業リーダーは、人間向けに構築されたそうした統制をそのままAIエージェントに適用しようとする。しかし私の経験では、それはうまくいかない。
ここで登場するのがAIエージェントガバナンスである。これは人間を統治するのとは全く異なるアプローチだ。従来のあらゆるシステムは、「アクションを起こす主体」と「その責任を負う主体」が同一人物であることを前提としている。しかし、AIエージェントはこの2つを分断してしまう。
それにもかかわらず、エージェントはこの分離がなされないまま構築されることが多いため、デモでは円滑に機能したエージェントのワークフローが、本番環境で破綻することが珍しくない。実行されるべきでないアクションが発火する。古い権限に基づいて動作するエージェントがユーザーのデータに触れる。復元できないレコードが削除される。責めを負わされるのはモデルだが、問題の本質はアーキテクチャにある。チームが、「何をすべきかの判断」と「その実行」の双方を単一のシステムで処理するように構築してしまったからだ。この設計で不具合が生じた場合、検査すべき独立した層（レイヤー）が存在せず、ポリシーが介入する余地すらない。
私自身の会社でこうしたシステムに取り組む中で学んだのは、エージェントに何を許可するかは、モデルやエージェントそのものの外側で決めるべきだということだ。より賢いモデルであっても、推論と行動がまったく異なる仕事であるという事実は変わらない。この点を正しく設計して初めて、AIエージェントガバナンスを実際に機能させられる。モデルは変わり得るし、切り替えることもできる。しかしアクションレイヤーは変わらない。
大半のエージェントに欠けている「実行層」
多くのチームは、エージェントにツールへのアクセスを与え、推論によってアクションに到達させるところから始める。この設計では、モデルがGitHubにプッシュすると決めれば、プッシュされる。モデルがレコードを削除すると決めれば、削除される。ループは1つしかない。モデルの判断を形づくるガードレールはあるかもしれないが、モデルが行動すると決めた後に何が起きるかを統制するものはない。
これはデモ段階ではうまくいくこともあるが、エンタープライズ規模では以下の3点が往々にして破綻する。
1. 認可と制御の粒度が、本番環境で実際に求められるレベルに比べて大まかすぎることがほとんどである。エージェントは通常、サービスアカウントや共有認証情報で動作している。そのため行動する際には、通常なら個々のユーザーが持つ権限よりも広い権限で実行する。モデルがGoogleドライブからファイルを取り出したり、Salesforceのレコードを更新したりする場合、それは特定の誰かに属するわけではなく、結果として全員に属するアクセス権で実行されているのだ。
2. 承認と執行がより厳密であっても、ポリシーの置き場は依然として存在しない。判断と実行の間に、ルールが介入し、承認を要求し、あるいはエージェントのアクションを完全にブロックできる独立したレイヤーがない。モデルは、プロンプトが求めた内容に基づいてアクションを取るか、取らないかのいずれかである。プロンプトは要求であり、何かを強制するものではない。
OpenAIとHugging Faceの間で発生した最近のインシデントを例に挙げてみよう。プロンプトはエージェントに不正侵入を命じたわけではなく、セキュリティ能力のテストを試みていただけだった。しかし、エージェントは自ら回答を探すためにサンドボックス（隔離環境）を脱出し、制止する仕組みが存在しなかったため、結果としてHugging Faceのシステムを侵害してしまった。
3. 独立したアクションレイヤーがなければ、監査証跡はせいぜい願望にすぎない。モデルが「何をするつもりだった」と述べたことはログに残せる。しかし、私の経験上、実際に何をしたか、誰のために、どのような権限の下で行ったかを確実にログに残すことはできない。推論自体から分離されたレイヤーでその執行が行われない限りは。
真の説明責任を構築する方法
これらの問題はいずれも、同じ意思決定が先送りされていることに起因する。私自身も目にしてきた。チームはアイデンティティとガバナンスを後回しにし、まず他の機能を動かし、自分たちに「いずれ戻ってくればよい」と言い聞かせる。だがその時が来ると、それが予想以上に大きな問題であることにすぐ気づく。アーキテクチャは、モデルの振る舞いが約束するだけのことを強制する。
だからこそ、本番運用に耐えるエージェントには、推論とアクションのレイヤーを分離し、その間にガバナンスの効いた境界を設けることが重要なのである。
推論レイヤーは、どのツールを呼び出すか、どの順序で呼び出すか、どの入力を使うかを決める。これはモデルと、その周囲のオーケストレーションフレームワークである。このレイヤーが認証情報、トークン、承認コンテキストを保持してはならない。役割は判断であり、判断は設計上、確率的なものだからだ。
実際に物事が実行されるのは、アクションランタイムによって動くアクションレイヤーである。ここはモデルの意図を受け取り、それを現在のポリシーと現在のユーザーの実際の権限に照らして確認する。そのうえで、実行の適切な瞬間に適切な認証情報を取得し、実行し、ログを残す。役割は執行であり、執行は決定論的である。呼び出しを許可するか、しないかのどちらかだ。
両者の境界こそが、AIエージェントガバナンスの存在する場所である。ポリシーフック、人間が介在するチェックポイント、トークン注入はここで行われる必要がある。モデルが出力するどんな内容も、このレイヤーを言いくるめて通過できてはならない。アクションレイヤーはモデルの出力を読んでいるのではなく、呼び出しそのものを評価しているからである。
この分離を構築するのは容易ではない。それでも私は、ガバナンスがチームの優先順位の低いところに置かれ続け、実装する以外に選択肢がないと気づくまで放置される例を何度も見てきた。だがチームがAIエージェントガバナンスを後付けとして扱えば、構造的に起こり得る、場合によっては避けがたいインシデントの是正に何カ月も費やすリスクを負う。
結論
アクションレイヤーは、チームが運用するあらゆるエージェントを、実際のビジネスシステムの中で安全に動かせると信頼できるようにするものでなければならない。あなたのAIエージェントが行動するとき、ポリシーはどこにあり、誰の認証情報を使い、完全な監査証跡を提示できるのか。
多くのチームは、自分たちのアーキテクチャが本来あるべき状態にないことをすでに理解している。問われているのは、次のインシデントが修正を強いる前に、あなたのチームがそれを直すかどうかである。
