セキュリティチームがAIゲートウェイに真に求めるものとは？

セキュリティ担当者10人にAIゲートウェイの役割を尋ねれば、10通りの答えが返ってくるでしょう。「APIキーを入れ替えるプロキシ」「プロンプトを記録する場所」「チャットボット用のファイアウォール」などです。どれも間違いではありませんが、全体像を捉えているわけでもありません。「部分的に正しい」状態と「AI利用を実際に統制できている」状態の間のギャップこそが、侵害が発生する場所なのです。

IBMの「2025年データ侵害コストレポート」によると、侵害を受けた組織の20%がシャドーAIを通じて侵入を許していました。これは、セキュリティ部門が承認も把握もしていない生成AIツールを従業員が使用していたことを意味し、侵害による平均コストを約67万ドル押し上げています。これらの組織のうち97%には適切なアクセス制御が欠如しており、Ponemon Instituteが600の組織を対象に行った調査では、63%がAIガバナンスポリシーを全く策定していないことが判明しました。 [1]

コストの可視化とガバナンスは、ツールを一つ追加購入すれば解決するような問題ではありません。本稿では、CISOが抱くような疑問に沿って解説します。組織内のすべてのAI利用を可視化・統制できるか、可視化した後に何ができるか、そして既存のスタックと連携できるか、という点です。

問い1：組織内のすべてのAI利用を可視化し、統制できるか？

ほとんどのセキュリティリーダーに、社内で使用されているすべてのAIツールをリストアップするよう求めても、それは不可能です。AIの利用経路は少なくとも4つあり、それぞれに対して異なるアプローチが必要です。

自社の開発者が構築したアプリやエージェント。 最も容易なケースです。チームがコードを管理しているため、生のAPIキーではなく、スコープが制限された取り消し可能な認証情報を介して呼び出しをルーティングできます。TrueFoundryでは「仮想アカウントトークン」を使用してこれを実現します。特定のアプリケーションに紐付けられ、ログ上でもそのアプリケーションとして識別され、個別に無効化が可能です。

従業員がすでに使用しているデスクトップツールやCLIツール。 Cursor、Claude Code、Codex CLIなどは通常、通信先のエンドポイントを設定可能です。そのため、これはインターセプト（傍受）の問題ではなく、設定の問題となります。MDM（Jamf、Intuneなど）を通じて、TrueFoundryのゲートウェイエンドポイントを全社的に展開してください。

コンシューマー向けWebアプリ。 ChatGPTやClaudeのWebインターフェースは難題です。設定ファイルも変更すべきコードも存在しません。TrueFoundryはこれを以下で解決します。 aitori、これはVPNクライアントのように動作するデバイス上のプロキシです。OSレベルでトラフィックを傍受し、デバイス証明書を介してゲートウェイにリダイレクトします。オープンソースであり、 コードはGitHubで公開されています。

すでに利用料を支払っているSaaSツールに組み込まれたAI。 SalesforceのEinsteinやSlackのAI要約などの機能は、例外的な存在です。モデルの呼び出しがベンダーのサーバーから外に出ることはないため、傍受する対象がありません。現時点ではTrueFoundryを含め、どのゲートウェイもこれを解決することはできません。代替策として、CASB形式の制御やベンダー独自の管理設定を利用することになります。

4つの扉のうち3つは今日解決可能です。残る1つはそうではなく、それを解決できると主張するベンダーがあれば、改めて検討し直す価値があります。

問い2：トラフィックを可視化できたとして、実際に何ができるのでしょうか？

可視化は「何が起きているか」を明らかにします。それに対するアクションは、3つの領域に分類されます。

アクセス管理

多くの人はこれを「退職時にいかに素早くアクセス権を無効化するか」という1つのシナリオで捉えがちです。TrueFoundryは、SCIM、JIT、または招待制プロビジョニングを備えたSSOを通じてこれに対応しており、IdPのグループ変更が自動的にアクセス権の変更に反映されます。さらに、認証（Okta、Entra、Google Workspaceと連携したトークンで、IdPアカウントが無効化された瞬間に失効）、最小権限の原則に基づくロールベースアクセス、そして現在誰が特権アクセスを保持しているかの継続的な監視もカバーしています。

多くのベンダーが見落としているのが、 非人間アイデンティティです。チームはあらゆるフレームワーク（LangGraph、CrewAI、Bedrock、自作スクリプトなど）でエージェントを構築しますが、内部ツールを呼び出す前にその存在を宣言する義務はありません。これはシャドーITの一種ですが、単にデータを読み取るだけでなく、実際にアクションを実行できてしまう点が問題です。TrueFoundryの解決策は、エージェントの アイデンティティ （どのエージェントか。すべてのエージェントに必須）と、その 登録 （誰の代理として、何ができるか）を分離することです。プランニングエージェントからリサーチエージェント、検索エージェント、ツール呼び出しへと続くチェーンにおいて、TrueFoundryはトークン交換を利用します。各ホップで新しいトークンが発行され、人間が責任主体として維持されるとともに、すべての実行エージェントが記録されるため、人間の名前の裏に隠れてしまうことはありません。 エージェントのアイデンティティとマルチエージェントガバナンスの詳細はこちら（OktaのCross-App AccessやMicrosoft EntraのOn-Behalf-Ofへのマッピング方法を含む）

単一ゲートウェイでのトークン交換：主体（ユーザー）は保持され、実行エージェントは記録され、スコープは次の呼び出し先へと限定されます。

MCPガバナンスとガードレール

MCPツールはデータベースへの書き込みやメール送信など、チャットの返信よりもはるかに影響範囲の広い「実際のアクション」を実行します。TrueFoundryのMCPゲートウェイは、呼び出し元の認証方法、どのユーザーやアプリがどの特定のサーバーやツール（サーバー全体ではなくツール単位）にアクセスできるか、そしてゲートウェイがインバウンドとは独立してサーバーに対してどのようにアウトバウンド認証を行うかを分離します。これにより、プライベートなVPCホスト型サーバーであっても、インバウンドポートを開放することなく、開発者ごとではなく中央で一括登録されたトンネル経由でアクセス可能になります。

導入前と導入後：MCPゲートウェイによる違い

これだけでは、呼び出しの中身までは分かりません。ガードレールは、双方向のペイロードを読み取り、MCPツール呼び出しを含めて内容を検閲・編集します。TrueFoundryのAIゲートウェイには、組み 込みのガードレール（PII/PHI検出、プロンプトインジェクション防御、コンテンツモデレーション、シークレット検出、CedarやOPAによるカスタムポリシー）が搭載されており、既存のガードレールベンダーのツールと連携させることも可能です。 MCPガバナンスとランタイムガードレールの詳細はこちら、および ID関連の詳細はこちら。

LLMリクエストのガードレールフロー

3つのニーズを網羅する監査証跡

「すべてをログに記録する」という言葉は、通常、次の3つのいずれかを意味します。継続的な可視性を実現するライブダッシュボード、フォレンジック調査のためにすべてのプロンプト、応答、ID、コストを自動的にキャプチャする機能、あるいはコンプライアンスの証拠としてSIEM（Splunk、Datadog、Grafana）へクリーンにエクスポートする機能です。TrueFoundryは、これらすべてを単一のログからカバーしており、これがSOC 2やHIPAA準拠の裏付けとなる真の証明となります。 監査証跡の全チェックリストはこちら。

質問3：これは既存のセキュリティスタックを置き換えるものですか、それとも連携するものですか？

ここで懸念されるのは、技術的な問題よりも、多くの場合「変更管理」です。誰もが信頼しているツールをわざわざ入れ替えたくはないはずです。適切に構築されたAIゲートウェイは、既存の環境の下流で機能するように設計されています。

SWG（Zscaler、Netskopeなど）からのAI向けトラフィックを、ユーザーIDをヘッダーに付与した状態でTrueFoundryのゲートウェイに向けることで、SWGの役割を奪うことなく制御が可能になります。JamfやIntuneを使用すれば、他のエージェントと同様にaitoriを全社展開できます。CrowdStrike Falconは、エンドポイントで未承認のAIアプリを直接ブロックするバックストップとして、異なる役割を果たします。これらは、既存のスタックとTrueFoundryのどちらかを選ぶという話ではなく、TrueFoundryを既存のスタックに組み込むというアプローチです。

これらすべてを運用するベンダーを信頼できますか？

思い込みではなく、確認することが重要です。SOC 2 Type II、HIPAA、GDPRへの対応状況を確認し、公開されている証明書（TrueFoundryの証明書は以下から確認可能）を参照してください。 trust.truefoundry.com）、文書化されたアクセスレビューのスケジュール、追跡・修正が行われる年次ペネトレーションテスト、そして公開された短いサブプロセッサーリストの有無を確認してください。

関連資料

• マルチエージェントA2Aガバナンスとエージェントゲートウェイ：エージェントID、トークン交換、および委任
• MCPゲートウェイ、クロスアプリアクセス、およびID管理されたエージェントアクセス：OktaおよびEntraによるMCP固有のID管理
• MCP GatewayランタイムガードレールによるエンタープライズAIセキュリティ：MCPツール呼び出しに対するガードレールの適用
• シャドーAI検出ツール：未承認のAI利用の特定
• AI監査チェックリスト：上記の監査項目を構築する

結論

AIゲートウェイを評価する際は、次の3つの問いを検討すべきです。あらゆる種類のAIトラフィックを可視化・管理できるか、トラフィックを可視化した上で実効性のある制御が可能か、そして既存のスタックに組み込めるか、という点です。

自社組織での導入をご検討中の方は、 TrueFoundryのAI Gatewayがどのように全体を網羅しているかをご覧ください。

‍