Help Net Securityによる今回のインタビューでは、meshIQのGlobal Head of Engineeringを務めるGourab Basu氏が、AIエージェントシステムにおけるガバナンスについて語ります。同氏は、プロンプトに書き込まれた指示だけではエージェントの挙動を制御するには不十分だと指摘します。なぜなら、エージェントは作業を進める中で自らの行動経路を変更できるからです。真の制御とは、提案されたアクションが本番システムに到達する前にそれをチェックすることを意味します。たとえば、高額な返金処理を人間の承認待ちで一時停止させるといった対応がこれに当たります。
同氏はまた、企業がエージェントを10体から1000体規模へとスケールさせた際に何が破綻するのか、そして異なるエージェントフレームワーク間でも機能するガバナンスをどう構築すべきかについても解説しています。
現在AIエージェントシステムを構築している多くの人々がまだ学んでいない、統合作業から得られる教訓とは何でしょうか。まだ痛い目を見ていないために気づいていないことは何ですか。
統合エンジニアがずっと以前に学んだ教訓の一つは、オーケストレーションと制御は同じものではないということです。従来の統合ワークフローは基本的に決定論的です。エンジニアが基盤となるコネクタの上に経路を定義し、ワークフローはその設計どおりに実行されます。AIエージェントは、非決定論的なオーケストレーション層を持ち込みます。エージェントに目標を与えると、どのツールを使うか、どの順序で使うか、ワークフローが進行する中で経路をどう調整するかを、エージェント自身が判断するのです。
この柔軟性は強力な反面、プロンプトを制御境界にすることはできないということも意味します。統合エンジニアは数十年前に、呼び出し元を盲目的に信頼することをやめました。エージェントが常にプロンプト内の指示に従うと仮定することは、パートナーシステムが常に完璧な形式のXMLを送ってくると信じ込む発想の現代版だと言えます。実行経路が動的に変化し得るのであれば、ガバナンスもその経路に追従し、何が起きるかを制御したいのであればフローの内部で機能しなければなりません。
具体例を挙げてください。エージェントがあるアクションを提案し、実行経路内に組み込まれた制御機構がそれを本番システムに到達する前に阻止した、というケースです。それはどのようなアクションで、もし通過していたら何が起きていたでしょうか。
単純なビジネスルールを持つ返金ワークフローを考えてみましょう。100ドル未満の返金は自動処理を許可し、それを超える金額は人間の確認を必須とするというルールです。従来の統合ワークフローであれば、この条件は実行経路に明示的に組み込むことができます。しかしAIエージェントの場合、同じルールがプロンプト内にしか存在しなければ、それは単なる指示にとどまってしまいます。
フロー内に組み込まれたガバナンス層があれば、返金が実行される前に、提案されたツール呼び出しとそのパラメータを検査できます。しきい値を下回る返金はそのまま進める一方、100ドルを超える返金は人間が確認するまで一時停止させます。ここで重要なのはタイミングです。エージェントが承認済みのしきい値を超えて返金を実行してしまったことを事後に発見するのではなく、そのアクションをまだ止められるうちにポリシーを執行するということです。これこそが、ガバナンスを単なる観察から真の制御へと変える要素です。
ある企業が1年でエージェントを10体から1000体に増やしたとします。あなたの経験上、最初からフローにガバナンスが組み込まれていなかった場合、真っ先に静かに破綻し始めるものは何でしょうか。
最初に失われるのは、企業の基幹システムに対する変更が一貫して統制されているという確信です。エージェントが10体程度であれば、チームはどのエージェントがどのシステムにアクセスできるかをまだ把握でき、手作業による監視で補うことも可能です。しかし1000体規模になると、企業の記録を変更できるエージェントの数は劇的に増加し、より高性能なモデルはそれらのエージェントが試みるアクションの範囲をさらに拡大させる可能性があります。
問題は、既存の企業向け制御の多くが人間のユーザーや従来型アプリケーションを前提に設計されているという点です。こうした防御策は依然として重要ですが、インテリジェントなエージェントが次に取るべきアクションを動的に判断している状況では、システムの記録先だけでガバナンスに頼るのでは不十分です。あるアクションを支配するルールがそのシステムに到達する前も一貫して保たれるよう、ガバナンスはエージェントの実行フローの一部として組み込まれなければなりません。
これは非決定論的なエージェントを決定論的なものに変えるわけではありません。非決定論的な実行の周囲に、予測可能な境界線を作り出すのです。そして規模が拡大するにつれ、どのアクションが自動的に進行してよく、どのアクションが本当に人間の介入を必要とするのかを、ポリシーによって判断できるようにする必要もあります。そうしなければ、手作業によるレビューはボトルネックと化すか、あるいは省略されてしまうでしょう。
単一のフレームワーク内だけでなく、複数のフレームワークにまたがって機能するようにガバナンス層を再構築、あるいは移行した経験について教えてください。何を変える必要があり、何がそのまま維持されたのでしょうか。
ガバナンスを複数のエージェントフレームワークにまたがって機能させるには、アーキテクチャを疎結合な層に分離する必要があります。中心に位置するのは、フレームワークに依存しないガバナンスエンジンです。ポリシーモデル、判断の意味論（許可・確認要求・エスカレーション・拒否といった区分）、監査記録のフォーマット、評価スイート、人間参加型の制御機構、そしてポリシーの記述方法は、組織がフレームワークを変更したからといって変わるべきものではありません。
変わるのは、割り込み(インターセプト)の仕組みです。異なるフレームワークは、ツール実行のライフサイクルの異なる時点でそれを公開しています。あるフレームワークはコールバックを使い、別のものはFastMCPのようなon_call_toolの仕組みを使い、さらに別のものは生のツールループを露出させている場合もあります。実行前に確実に割り込める地点を全く提供していないフレームワークもあるでしょう。アダプターはこうした違いを吸収し、ガバナンスが実行に関与できる地点を確立する必要があります。
この分離が重要なのは、ガバナンスがエージェントアーキテクチャ全体を横断すべきものだからです。企業は目的に応じて異なるフレームワークを使い分けるでしょうし、その選択も時とともに変化していきます。エージェントに許可されている行動を規定するポリシーは、基盤となる技術が変わっても一貫していなければなりません。
若手エンジニアから、自律システムのスケーリングで犯した過ちを繰り返さないためのアドバイスを求められたら、最初にどんな話をしますか。
私が最初に伝えたい教訓は、制御よりも先に能力をスケールさせてはいけないということです。AIは非常に強力な技術であり、自律システムにできることばかりにまず目が向いてしまいがちです。小規模なうちは、手作業によるレビューや綿密な監督によって、チームは弱い制御を補うことができる場合が多いでしょう。しかしそれは、企業規模になるとリスクの高い賭けになってしまいます。
自律システムをスケールさせる前に、制御・可観測性・ガバナンスをアーキテクチャそのものの一部として考え抜いてください。エージェントが何にアクセスできるのか、どのようなアクションを取り得るのか、どこで人間の判断が必要なのか、そしてその判断が事後にどのように再構成されるのかを理解することです。こうした能力は、エージェントがすでに本番ワークフローに組み込まれてしまった後で後付けしようとすると、はるかに困難になります。進歩の指標は、単にどれだけの自律性を導入できるかではなく、拡大していく自律性をどれだけ自信を持って統制できるかにあるのです。
翻訳元: https://www.helpnetsecurity.com/2026/09/16/gourab-basu-meshiq-ai-agent-governance/
