仮想的なシナリオを考えてみましょう。AIファクトリー内のエージェントがドキュメントを取得します。その中には、ユーザーがエージェントに実行させる意図のなかった命令が隠されています。エージェントはその命令に従い、接続を確立し、Model Context Protocol（MCP）経由でツールを呼び出し、誰も要求していないレコードを取得して、誰も承認していない宛先に送信します。本来これを検知すべきガードレールは同じコンテナ内のサイドカーだったため、エージェントはまずそれを無効にしました。ログもエージェントの制御下にあったため、この事象は記録されませんでした。所要時間は1秒未満です。経路上に検知できるものが何もなかったため、誰にも気付かれませんでした。
これは特殊な障害ではありません。制御機能がエージェントのすぐそばにあり、同じ信頼ドメイン内に置かれている環境では、これが標準的に起こり得る障害です。侵害された、または誤誘導されたエージェントは、制御機能を無効化したり、迂回したり、証拠を改ざんしたりできます。端的に言えば、エージェント自身にエージェントを監視させることはできません。
The F5 Application Delivery and Security Platformは、あらゆるアプリとAPIを配信し、保護します。次に対象となるAIエージェントは、従来とは異なる動作をします。モデルを呼び出し、MCP経由でツールを起動し、他のエージェントと通信するほか、ファクトリー内外のAPIにアクセスします。価値を提供するには、エージェントがサンドボックス外のモデル、ツール、API、データに制御された形でアクセスでき、そうしたやり取りに強制適用可能なポリシーが常に適用される必要があります。NVIDIA OpenShell Reference Architectureは、NVIDIAがNVIDIA GTC Berlinで発表するもので、まさにこの考え方に基づいて構築されています。エージェントのランタイム権限、ハードウェアによる強制適用、推論をNVIDIAハードウェアの3つの階層に配置し、それらを結ぶ経路にパートナーが参画できる余地を設けています。各要素の役割を最も明確に示すには、サンドボックスから送信されるリクエストを追っていくのが効果的です。
NVIDIA OpenShell Reference Architectureの役割
このリファレンスアーキテクチャは、エージェントを信頼できないものとする前提に立ち、それに応じてハードウェアを分離します。
安全なAIエージェント向けのNVIDIA OpenShell Reference Architectureでは、NVIDIA OpenShellがNVIDIA Vera CPU上で動作し、エージェントのランタイム権限を管理します。そのスーパーバイザーは、外部へのリクエストを評価し、設定済みのHTTP、GraphQL、MCPトラフィックにきめ細かな制御を適用するとともに、認証情報を保護し、各ポリシー判断を記録します。エージェントはサンドボックス内で動作しますが、エージェントを管理するスーパーバイザーはサンドボックス内では動作しません。
NVIDIA Sentryは、NVIDIA BlueField-4 DPUs上に独立したハードウェア監視・制御レイヤーを追加します。このレイヤーは、エージェントがアクセスも変更もできない隔離されたセキュリティドメインで、脅威検知、リクエストとレスポンスの検査、エージェントのガバナンス、ミリ秒単位の封じ込めを行います。NVIDIA Sentryはオプションのレイヤーであり、NVIDIA Vera Rubinシステムではモデルへの経路上に配置されます。
NVIDIA Vera Rubin NVL72インフラストラクチャは、エージェントが呼び出すモデルを実行します。そのため、このアーキテクチャでは、エージェントがアクセスできないインフラストラクチャから、エージェントによるアクションの可否をすでに判断し、その動作を監視しています。F5は、AIトラフィック向けに構築されたコンテンツ検査、レッドチーミング、アプリケーションデリバリによって、これらの制御を補完します。これは、エージェントのサイバーセキュリティに関するNVIDIAとの協業を基盤としています。
OpenShellとNVIDIA Sentryが判断すること
OpenShellは、どのエージェントがどのポリシーに基づいてリクエストを行ったか、また、その宛先とメソッドが許可されているかを把握します。保護をさらに強化するため、NVIDIA SentryはNVIDIA DOCAを使用してNVIDIA BlueField-4上で動作し、エージェントを独立して監視するとともに、シリコン上でポリシーを適用し、数ミリ秒以内にエージェントを隔離します。OpenShellとNVIDIA Sentryにより、エージェントが動作を許可されるかどうかは、エージェント自身が制御できないところで判断されます。それこそが、この設計の要点です。
ランタイム権限、動作監視、AIに特化したコンテンツ検査により、相互補完的な保護レイヤーを提供します。F5は、対応するプロンプト、モデルの応答、ツール呼び出しを検査し、プロンプトインジェクション、ジェイルブレイク、機密データの漏えいに対処します。これにより、OpenShellのランタイムガバナンスと、NVIDIA Sentryによる継続的な動作監視およびハードウェア分離型のポリシー適用を補完します。
F5がエージェントの送受信内容を検査
F5 AI Guardrailsは、OpenShellが制御するプロトコルで送信されるプロンプト、モデルの応答、ツール呼び出しなど、適用パスからルーティングされた対応トラフィックを検査します。検出した内容に対して3つの処理を行います。プロンプトインジェクション、ジェイルブレイク、ポリシーに違反するツール呼び出しをブロックします。機密データが外部に送信される前に編集します。すべての判定をセッションレコードに記録して監査できるようにします。判定結果とテレメトリはOpenShellとNVIDIA Sentryで利用できるため、ブロックされたリクエストは、オペレーターのポリシーに基づき、封じ込めを含むエージェントレベルの判断に反映できます。インターセプトはエージェントのコンテナ内ではなく適用パス上で行われるため、エージェントがGuardrailsを無効にしたり、迂回したりすることはできません。無効にできるサイドカーはありません。
F5 AI Red Teamは、ガードレールが適切に機能しているかを検証します。プライベートかパブリックかを問わず、ユーザーと同じ経路を通じてエージェントとモデルを攻撃し、検出した内容をガードレールポリシーに反映することで、防御策が対象のエージェントの進化に対応できるようにします。
エージェントをガバナンスするには、その動作を証明することも必要です。F5コントロールプレーンは、ユーザー、プロンプトのコンテキスト、ツール呼び出し、承認済みパラメーターなどのセッション記録を保持します。OpenShellはポリシー判断の記録を保持します。NVIDIA Sentryは、ファイルアクセス、カーネル呼び出し、DPUパケットメトリクスなどのシステム記録を保持します。これらの記録を相関させることで、モデルが意図したこと、エージェントが試みたこと、実際に行ったことを、エージェントが操作できない情報源に基づく1つのタイムラインとして把握できます。
The F5 AI Security PlatformのコントロールプレーンとAI Red Teamは、ファクトリー内のサーバー側で稼働します。エージェントが呼び出す本番環境の推論モデルはNVIDIA Vera Rubin NVL72上で稼働し、AI Red TeamもセキュリティテストにGPUリソースを使用します。AI Guardrailsに必要なのはArm CPUのみであるため、NVIDIA VeraおよびBlueField-4上で実行できます。以下の2つのリファレンスアーキテクチャは、各コンポーネントの配置を示しています。
NVIDIA OpenShell上の2つのF5リファレンスアーキテクチャ
NVIDIAの3つの階層に重ねて配置します。Vera上のAI Guardrailsは、OpenShell内のエージェントハーネスに適用されます。NVIDIA BlueField-4上にもAI Guardrailsを配置し、エージェントの障害影響範囲外で、AIファクトリーが必要とする場合にデータプレーンとともに動作させます。コントロールプレーンとAI Red Teamは、モデルとともにVera Rubin NVL72上に配置されます。これにより、2つのリファレンスアーキテクチャが構成されます。どちらもNVIDIA OpenShell Reference Architectureを基盤とし、同じポリシーとコントロールプレーンを使用します。違いは、エージェントの処理経路上に何を配置するかです。
リファレンスアーキテクチャ1：F5 AI GuardrailsとNVIDIA OpenShellおよびNVIDIA Sentry
NVIDIAスタックを設計どおりに運用する事業者向けです。F5 AI Guardrailsは、1つのポリシーの下で2か所に配置されます。1つはNVIDIA Vera上で、OpenShell内のエージェントハーネスに適用されます。もう1つはNVIDIA Sentryに統合されたBlueField-4 DPU上で、エージェントからはアクセスできません。前者は、エージェントが送信する内容を送信時に検出します。後者は、エージェントが無効化できません。Guardrailsは、ルーティングされた対応トラフィックをブロック、編集、監査します。また、BlueField上での判定結果はNVIDIA Sentryで利用でき、エージェントを即座に封じ込めることができます。追加のハードウェアは不要です。NVIDIAスタックを標準採用するNVIDIA Cloud Partnerは、ほかに何も変更することなくコンテンツ検査を導入できます。
より大規模な環境とエンタープライズグレードのデリバリーに対応します。F5 BIG-IP Next for Kubernetes は、ファクトリーのデータプレーンとしてNVIDIA SentryとともにNVIDIA BlueField-4 DPU上、またはホストCPU上で稼働し、その内部では同じポリシーの下でF5 AI Guardrailsが稼働します。NVIDIA Sentryが基本的な適用を担い、BIG-IP Next for Kubernetesがトラフィックを処理します。BIG-IP Next for KubernetesはNVIDIA Dynamoと統合し、Vera Rubin NVL72上のモデルインスタンス間でエージェントとアプリケーションのトラフィックをルーティングし、負荷分散します。テナントを分離し、Model Context Protocol（MCP）接続をスケーリングして保護するとともに、テナントごとのトークン使用量を管理し、テナントとモデルを横断する統合ビューを運用担当者に提供します。また、BIG-IP Next for Kubernetesは、自身を経由するトラフィックに運用担当者の外部向けエグレスポリシーを適用し、OpenShellのランタイムアクセス制御とNVIDIA Sentryのインフラストラクチャポリシー適用を補完します。
どちらを選択するかは運用者が決定します。OpenShellとNVIDIA SentryにAI Guardrailsを導入するか、AI Guardrailsを内蔵したBIG-IP Next for Kubernetesを追加します。どちらもポリシーとコントロールプレーンは同じです。 後者では、ファクトリー全体にテナント分離、エグレス制御、トラフィック管理が追加されます。
個別に測定されたため、セキュリティアーキテクチャとは分けて示す数値があります。NVIDIA BlueField-3 DPU上でBIG-IP Next for Kubernetesを使用したThe Tolly Groupのテスト（レポート#226104、2026年3月公開）では、BIG-IP Next for Kubernetesは、テスト対象のベースラインと比べてトークンスループットが40%向上しました。このテストでは、データパスをホストCPUからオフロードしています。これは、BIG-IP Next for Kubernetesのデータプレーン単体の測定結果です。ここで説明した検査機能は含まれていません。AIにおいて、パフォーマンスは経済性に直結します。
ファクトリー内にとどまるセキュリティ
完全にセルフホストされた環境では、F5のセキュリティ処理と監査記録はオペレーターの環境内に保持されます。コントロールプレーンとRed Teamはモデルとともにサーバー側に配置され、検査はVeraとBlueField-4で行われます。外部のモデルやサービスへのアクセスには、引き続きエンタープライズポリシーが適用されます。図にパブリックな接続先が示されているのには理由があります。すべてのプロンプトと応答をAIファクトリー内に保持するには、ローカルでホストされる接続先と、外部へのエグレスに対する制限も必要です。このアーキテクチャにより、それが可能になります。実際に保持するかどうかはオペレーターのポリシーによって決まり、そのエグレスポリシーはBIG-IP Next for Kubernetesによって適用されます。
エージェント時代の到来によって新たなセキュリティ要件が生まれたというよりも、最も重要な制御ポイントが、エージェントのエグレス、つまりエージェントが操作できないインフラストラクチャ上へと移りました。F5は30年にわたり、まさにこのような経路に取り組んできました。NVIDIA OpenShell Reference Architectureでは、エージェントが言葉巧みに回避することのできない経路となっています。
詳細については、F5の「F5 AI Security Platform」、「F5 AI Guardrails」、「F5 AI Red Team」、「F5 BIG-IP Next for Kubernetes」の各Webページをご覧ください。
著者について
Kunal Anandは、最高製品責任者としてF5の製品部門を率いています。製品のビジョン、戦略、実行を統括し、重要な課題を解決して優れた顧客体験を生み出す画期的なソリューションの開発を推進しています。前職の最高技術・AI責任者としては、F5のテクノロジーおよびAIに関する戦略とビジョンを策定しました。 F5入社以前は、Impervaで最高技術責任者と最高情報セキュリティ責任者を兼任していました。2013年に共同創業したアプリケーションセキュリティのスタートアップPrevotyが2018年に買収されたことを機に、Impervaに加わりました。Prevoty以前は、BBC Worldwideでテクノロジーディレクターを務めました。イノベーションと技術分野で豊富な実績と専門知識を有し、Gravity、MySpace、NASA Jet Propulsion Labでは、セキュリティ、データ、テクノロジー、エンジニアリングの各チームを率いる役職を歴任しました。 AIと機械学習の分野で15年以上の経験を持ち、モデルのトレーニング、AIを活用したアルゴリズムによる製品強化、AIアーキテクチャの設計と実装に携わってきました。 Babson Collegeでコンピューターサイエンスの理学士号を取得しています。
Kunal Anandのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。