複数プラットフォームにわたるAIエージェントのガバナンス

ほとんどの企業は、5つのプラットフォームにわたってAIエージェントを導入することを意図したわけではありません。それは自然発生的に起こりました。Microsoft Copilotは生産性スイートとともに登場し、ServiceNowはNow Assistをチケットキューに組み込み、SalesforceはCRM内でAgentforceを有効にしました。その他のデータプラットフォームやSaaSプラットフォームも、記録システムと並行してエージェントを稼働させ始めました。各プラットフォームは独自のAIランタイムをもたらし、そして静かに、プラットフォームの境界で止まる独自のガバナンス体制をもたらしたのです。

その結果、単一のアプリケーションプラットフォームベンダーだけでは埋めることが難しいガバナンスのギャップが生じています。あるプラットフォーム内のエージェントがAPIを呼び出したとき、誰がそれを承認したのでしょうか？別のプラットフォームのエージェントが機密文書を要約したとき、どのポリシーがその応答を管理したのでしょうか？そして、本番環境でエージェントが不適切な動作をした場合、複数のベンダーコンソールやサポートキューを横断して調整することなく、誰が迅速にそれを封じ込めることができるのでしょうか？

これは将来的なリスクではありません。複数のAIプラットフォームを個別に導入したあらゆる組織にとって、これはすでに運用上の現実です。そして、これは大企業ではますます一般的になっています。

問題の構造

解決策について語る前に、なぜこれが本当に難しいのかを正確に理解しておく価値があります。この困難は構造的なものであり、同時に4つの側面で現れます。

そして、ユーザーが実際に 何かを サードパーティ製エージェントでしようと試みた瞬間に初めて明らかになる5つ目の問題があります。それは「認証情報の負担（credential tax）」です。

隠れた認証情報の負担

Copilotスタイルのアシスタントにインストールされた公式のサードパーティ製エージェントに送信される、日常的なプロンプトを考えてみましょう。ユーザーが初めてそのエージェントに触れると、ユーザーがそのサードパーティサービスに直接サインインするまで、エージェントは応答できません。

これはバグではありません。各エージェントが個別に販売される製品である場合、これは唯一安全なアーキテクチャです。しかし、企業の全ツールインベントリにわたって積み重なると、実際の運用上の影響が生じます。

• ユーザーごと、ツールごとの手間。 すべての従業員は、エージェントを初めて使用する際に、その都度再認証を行います。これを従業員の数とツールインベントリの数で掛け合わせてみてください。
• トークンの乱立。 接続されたすべてのサービスに対するOAuthトークンは、ユーザーIDストア全体に散らばってしまいます。コンプライアンスは、単一の監査証跡ではなく、ベンダーごとの問題となります。
• 一元的な取り消しができない。 契約変更やインシデントによりアクセス遮断が必要になった際、組織は一つの集中管理ポイントではなく、各ベンダーとの関係を通じてその対応に追われます。

クロスプラットフォームなコントロールプレーンの仕組み

このギャップに直接対処するアーキテクチャパターンは、これらすべてのプラットフォームが共通して持つレイヤーでガバナンスを行うことです。どのプラットフォームでホストされていても、すべてのエージェントは最終的にLLM呼び出しまたはツール呼び出しを行います。これを傍受してガバナンスを行うことで、 そこを、その共有実行レイヤーを経由するエージェントのアクティビティを、すべてのアプリケーションプラットフォームに再構築を求めることなくガバナンスできます。

これがTrueFoundryのAgent Gatewayの根底にある考え方です。これは、本番環境のAIエージェント専用の制御レイヤーであり、すべてのエージェントが依存するモデルとツールの手前に位置します。TrueFoundryは、ステートレスなプロンプトとトークンを管理するAIゲートウェイと、 エージェント ゲートウェイを明確に区別しています。エージェントゲートウェイは、ステートフルなセッション、多段階実行、エージェントとそのツール間を移動するデータなど、エージェントAIのデータプレーンです。これは、エージェントシステム専用に構築されたサービスメッシュのように機能します。

ゲートウェイの上には第4のレイヤー、Agent Harnessがあります。ハーネスはLLMを囲むランタイムであり、計画を立て、ツールを呼び出し、コンテキストを管理し、承認を通じて機密性の高いアクションをゲートし、すべてのステップをトレースに記録するオーケストレーションループです。これは、モデル呼び出しを信頼性の高い、長時間稼働するエージェントに変えるものです。

TrueFoundryはこれをフレームワークとしてではなく、マネージドサービスとして提供しています。サンドボックス化された実行環境がコードと長時間実行タスクを実行します。人間が介在する承認ゲートは、ユーザーが承認するまで機密性の高いツール呼び出しを一時停止します。バージョン管理されたスキルレジストリは、RBAC付きの再利用可能な指示を保持します。そして重要な点として、APIキーや認証情報はエージェント定義には決して存在しません。それらはゲートウェイに存在し、プラットフォームチームが一度アクセスを設定すれば、エージェント開発者はシークレットに触れる必要がありません。

重要なことに、検出はプラットフォーム上で構築したエージェントに限定されません。Bedrock、LangGraph、カスタムHTTPサービス、または他のベンダーのプラットフォームなど、他の場所で実行されているエージェントも、リモートエージェントとして同じインベントリに、同じメタデータと制御機能で登録されます。分散したフリートが単一のマップになります。

04注目すべき5つの機能

このギャップを埋める方法を検討しているチームにとって、以下の5つの機能は綿密に検討する価値があります。それぞれの機能が内部的に何を必要とするかについての注記も添えています。

‍