AIエージェントのガバナンス：企業チームのためのフレームワーク

はじめに

要約：AIエージェントガバナンスとは、自律型エージェントを安全な範囲内に留めておくための、ID管理、ポリシー、監視、監査の制御の総称です。従来のITガバナンスは、固定されたルールに従うソフトウェア向けに構築されたものであるため、エージェントが独自に意思決定を行い、ツールを呼び出し、データにアクセスする仕組みに対応できていません。本ガイドでは、エージェントガバナンスとは何か、それが対処するリスク、そしてエージェントが重要なワークフローに組み込まれる前に導入できるフレームワークについて解説します。

AIエージェントは、人間がどの段階にも関与することなく、チケットを読み取り、3つの内部システムにクエリを実行し、回答案を作成し、記録を更新することができます。その自律性こそが重要な点であり、同時に、既存のガバナンス制御の多くが適合しない理由でもあります。アクセスルールは、あらゆるアクションの背後に人が存在することを前提としており、監査ログは、そのアクションをその人物まで遡って追跡できることを前提としています。エージェントは、この両方の前提を覆します。

AIエージェントガバナンスは、そのギャップを埋めます。各エージェントに固有のIDを付与し、各エージェントに許可される動作を決定し、実際の動作を監視し、後で質問に答えられるだけの詳細な情報を記録します。本記事では、それが実際にどのように機能するか、カバーすべき具体的なリスク、そしてTrueFoundryでの取り組みについて解説します。

AIエージェントガバナンスとは何か？

AIエージェントガバナンスとは、自律型エージェントがどのように認証を行うか、どのツールやデータにアクセスできるか、そしてその行動がどのように監視・記録されるかを管理する分野です。これは、エージェントを、それを展開した人間の単なる延長としてではなく、それ自体が独立した主体として扱います。

この区別が重要なのは、エージェントが独立した判断を行うからです。データベースエージェントが読み取り権限を持っていても、真の問題は、特定のリクエストに対して顧客レコードを含むテーブルをクエリすべきかどうかという点にあります。ガバナンスとは、数週間後のレビュー時ではなく、呼び出しが行われたその瞬間にその問いに答えるものです。ガバナンスがなければ、チームは「まだ問題が発生していない」という理由だけで、エージェントが許容範囲内にとどまると信頼することになってしまいます。

優れたガバナンスは、実用性も兼ね備えていなければなりません。制御措置によってエージェントの動作が遅くなったり、展開が困難になったりすると、チームはそれを回避するようになり、結果として、ガバナンスポリシーが紙の上だけのものとなり、管理されていないエージェントの状態に戻ってしまいます。

従来型のアクセス制御がエージェントに対して不十分な理由

標準的なアクセス制御では、ユーザーに権限を割り当て、ユーザーアカウントに対するアクションをログに記録します。エージェントは、3つの点でこのモデルを曖昧にします。

責任の所在が不明確になる。エージェントが動作すると、ログには通常、リクエストを発行した人間や、そのアクションに至った一連の判断ではなく、サービスアカウントが表示される。何か問題が発生した場合、クエリが実行されたことは確認できるが、その理由や誰の代理で実行されたのかは分からない。

ツールへのアクセスが拡散する。1人のエージェントが、それぞれ独自の権限モデルを持つ数十のツールやデータソースにアクセスできる。その対象範囲は、手動によるポリシー策定プロセスでは追いつけないほど急速に拡大し、その隙間にインシデントが発生する。

動作が変動する。従来のソフトウェアは、同じ入力に対して同じ出力を返します。しかし、エージェントはそうではありません。エージェントの応答は、会話履歴、コンテキスト、および基盤となるモデルの変更に応じて変化するため、先月は安全だった制御も、今日では異なる動作をする可能性があります。

これらはどれも例外的なケースではありません。これらはエージェントにとっての通常の動作条件であり、だからこそ、ガバナンスは古いシステムから流用するのではなく、エージェントに合わせて設計されなければならないのです。

エージェント・ガバナンス・フレームワークの4つの柱

実用的なフレームワークは、互いに補強し合う4つの要素に基づいています。

まず第一に「アイデンティティ」です。すべてのエージェントには、それを構築または起動する人間とは区別された、スコープが定義された権限を持つ独自のアイデンティティが必要です。エージェントを区別できなければ、何も強制したり監査したりできないため、これが他のすべてを可能にする基盤となります。

ポリシーの適用は実行時に実施されなければなりません。監視とガバナンスの違いは、システムが不正なアクションを実行前にブロックできるかどうかにあり、単に事後にフラグを立てるだけでは不十分です。読み取り専用エージェントは書き込みができないようにすべきであり、単に書き込みを試みたという報告を受けるだけでは不十分です。

可観測性により、エージェントの動作をリアルタイムで可視化できます。異常、ポリシー違反、リスクの高い呼び出しを発生と同時に把握することで、不完全なログから事象を再構築するのではなく、シグナルに基づいて迅速に対応できるようになります。

監査ログは意思決定の経緯を記録します。すべてのツール呼び出し、データアクセス、および応答は、監査担当者やインシデント対応者に提出できる形式で、実行主体とコンテキストとともに記録されるべきです。これが、「エージェントが適切に動作した」と主張することと、それを証明できることとの違いです。

AIエージェントのリスクと軽減策

エージェントは、通常のアプリケーションセキュリティでは完全にはカバーできないリスクをもたらします。エージェント型AIのリスク管理は、まずそれらのリスクを特定することから始まります。

プロンプトインジェクションは、最も注目されるリスクです。ユーザーコンテンツや外部データソースに隠された悪意のある入力により、エージェントがデータを漏洩させたり、本来行うべきではないアクションを実行させられたりする可能性があります。信頼できないコンテンツを処理するエージェントは、最もリスクにさらされています。

これに続いて、認証情報の漏洩が挙げられます。APIキーやトークンを保持するエージェントは、それらの値が処理の過程で検出され、マスキングされない限り、出力やログに漏洩させてしまう可能性があります。

PII（個人識別情報）の漏洩は、気づかれないうちに発生します。エージェントを経由する顧客データが、誰の意図もなく、会話ログやエラーメッセージ、あるいは下流の呼び出しに表れてしまうことがあります。

過剰な権限とは、エージェントに必要な以上の権限を与えるリスクのことです。本番環境のリポジトリへの書き込みアクセス権を持つコードエージェントには、読み取り専用アクセスであれば完全に排除できるリスクが伴います。解決策はスコープの設定です。各エージェントに必要な最小限の権限のみを付与し、それ以上は与えないようにします。

これらのリスクを低減するには、複数の制御策を組み合わせる必要があります。認証情報、PII、および禁止コンテンツについて、境界を越える前に入力と出力を検査します。各エージェントが呼び出せるツールをデフォルトで許可するのではなく、許可リストに登録します。リスクの高い決定が人間にエスカレーションされるようエスカレーションの閾値を設定し、本番環境で実際に発生している状況に基づいてそれらの閾値を調整します。

エージェントごとの識別情報とスコープ付き認証情報

共有サービスアカウントは最も一般的な手っ取り早い方法ですが、最も多くの問題を引き起こします。複数のエージェントが1組の認証情報を共有すると、どのエージェントが何を行ったかを特定できなくなります。そのアカウントが侵害されると、侵害されたエージェントだけでなく、そのアカウントを使用しているすべてのエージェントに影響が及びます。また、各エージェントは、自身の業務に適したスコープではなく、共有アカウントの権限セット全体を継承してしまいます。

エージェントごとの識別情報があれば、これら3つの問題をすべて解決できます。デプロイされた各エージェントは、個別にローテーションや失効処理が可能な独自の認証情報、その目的に応じた権限、そして明確な監査証跡を取得します。これは、チームがエージェントを立ち上げる速度が、誰にも追跡できないほど速くなってしまう「エージェントの無秩序な増加」に対する解決策でもあります。すべてのエージェントに登録された識別情報があれば、無秩序な増加は目に見えなくなり、管理が可能になります。

エージェントのID管理には、ユーザー管理とは異なる抽象化が必要です。エージェントには、単一のセッションを超えて存続する永続的なID、独立してローテーションされる認証情報、そして作成者ではなくエージェントの動作に紐づけられた権限範囲が必要です。

コンプライアンスと監査対応

規制は自律システムに追いつきつつあり、SOC 2、HIPAA、GDPR などのフレームワークは、すでにエージェントの展開が満たさなければならない義務を定めています。実用的な要件は、監査の前に誰かが手作業で作成する文書ではなく、インフラストラクチャ自体が証拠を生成することです。

つまり、すべてのエージェントのアクションが、実行者、タイムスタンプ、コンテキストとともに記録される包括的な監査証跡が必要です。また、事後編集が不可能な不変の記録も求められます。さらに、記録の種類や管轄区域の規則に準拠した保存期間の確保、およびチームが既に運用しているセキュリティツールへログをエクスポートする機能も不可欠です。

規制対象のチームにとって、エージェントがどこで実行されるかは、そのガバナンス方法と同様に重要です。自社のVPC内、オンプレミス、またはエアギャップ環境内でエージェントを実行することで、機密データを自社の境界内に保持しつつ、同一のID、ポリシー、およびロギング制御を適用できます。

TrueFoundryのエージェントガバナンスへのアプローチ

当社のプラットフォームは、ガバナンスが後から追加されたレイヤーではなく、エージェントの実行方法に組み込まれるように設計されています。Agent Gatewayは、各エージェントにスコープが設定され、ローテーション可能な認証情報を備えた独自のIDを付与します。これにより、アクションの帰属が明確になり、権限は作成者のアクセス権ではなく、エージェントの役割に合致するようになります。

ツールへのアクセスも、同じコントロールプレーンを経由します。エージェントはMCPを介してツールやデータにアクセスし、すべてのツール呼び出しにOAuth2、RBAC、およびメタデータポリシーが適用されるため、データベースの読み取りを許可しつつ書き込みをブロックすることが可能です。 ガードレールは、入力および出力の両パスにおいて、リクエストとレスポンスを検査し、PII（個人識別情報）やその他の禁止コンテンツを検知します。また、可観測性と監査のために、すべての呼び出しがログに記録されます。このプラットフォームは、SOC 2、HIPAA、およびGDPRに対応し、お客様のVPC、オンプレミス、またはエアギャップ環境内で実行されるため、エージェントがどこで実行されていてもガバナンス制御が適用されます。

その結果、ID管理、実行時ポリシー、監視、監査が、4つのばらばらのツールではなく1か所から提供されるようになり、これがフレームワークを大規模な環境でも一貫して機能させる要因となっています。

テクノロジーを軸とした実践の構築

コントロールは、組織がそれを支持して初めて機能します。ガバナンスを障害と見なすチームは、それを回避する方法を見つけ出すでしょう。したがって、目標は、ガバナンスが適用された経路を「容易な経路」にすることです。

段階的な導入が効果的です。まず、すでに稼働しているエージェントを特定し、それらにIDを割り当て、監視機能を有効にし、その後、コンプライアンスの証拠収集を自動化します。そのタイミングは、環境の複雑さや適用される規制によって異なります。併せて、プラットフォームエンジニアリング、法務、コンプライアンス、運用を網羅する部門横断的なグループが、ポリシー決定の主導権を握り、既存のポリシーではカバーされていない新たなケースに対処すべきです。 トレーニングによって全体が完成し、エージェントを構築する担当者が権限モデルを理解し、自身のユースケースにガードレールを適用する方法を習得できるようになります。

よくある質問

AIエージェントガバナンスとは何ですか？

AIエージェントガバナンスとは、自律型エージェントの認証方法、アクセス可能なツールやデータ、およびその行動の監視・監査方法を管理する一連の制御措置のことです。これは、エージェントが展開した担当者のアクセス権を継承させるのではなく、各エージェントをスコープが定義された権限を持つ独立した主体として扱うものです。

エージェント型AIのリスク管理は、通常のアプリケーションセキュリティとどのように異なりますか？

プロンプトの注入、エージェントの出力を通じた認証情報の漏洩、会話ログにおける個人識別情報（PII）の露出、および過度に広範な権限による過剰な自律性など、標準的なセキュリティでは完全に対処できないリスクが追加されます。これらを管理するには、実行時の入力および出力の検査、ツールレベルの許可リスト、およびエージェントごとの最小権限のスコープ設定が必要です。

なぜエージェントごとの識別子が重要なのでしょうか？

サービスアカウントを共有すると、どのエージェントがアクションを実行したかを特定できなくなり、認証情報が漏洩した場合の影響範囲が広がり、すべてのエージェントに必要以上のアクセス権が与えられてしまいます。エージェントごとの識別情報により、各エージェントに独自のローテーション可能な認証情報、明確な帰属、およびその目的に合ったスコープが提供されます。

エージェントのガバナンスは、自社のVPCやオンプレミスで実行できますか？

はい。TrueFoundryは、お客様のVPC、オンプレミス、エアギャップ環境、またはクラウド間をまたいで実行されるため、データがお客様のドメイン外に出ることはありません。エージェントがどこで実行されても、同一の識別情報、ポリシー、および監査制御が適用されます。これが、規制対象のチームがSaaSのみのゲートウェイではなく、セルフホスト型モデルを選択する理由です。

SOC 2、HIPAA、GDPRに対応していますか？

TrueFoundryは、RBAC、SSO、および不変の監査ログ機能を標準搭載しており、SOC 2、HIPAA、GDPRの各基準に対応しています。この組み合わせにより、エージェントの展開は監査対応済みとなり、監査前に慌てて文書化を行う必要がなくなります。

まとめ

AIエージェントのガバナンスこそが、スケール可能なエージェントと、ただ「うまくいくことを願うしかない」エージェントとを分けるものです。このフレームワークは、原理的には複雑ではありません。すべてのエージェントにIDを割り当て、アクションの実行時にポリシーを適用し、エージェントの行動を監視し、責任を持って説明できる記録を残す――これだけです。 難しいのは、チームの作業を遅らせることなく、これら4つの要素をすべてのエージェントに対して同時に実行することです。私たちが提供しようとしているのは、まさにそのレイヤーです。TrueFoundryのAI Gatewayが、エージェントのための単一のガバナンス付きコントロールプレーンに、ID、ポリシー、モニタリングをどのように統合しているかをご覧ください。