以前のブログ記事では、Mythosクラスのモデルに対しては、攻撃を検知するかどうかよりも、どこで阻止するかが重要であり、トラフィック経路は推論能力を持つ攻撃者が迂回できない唯一の制御ポイントであると論じました。本記事では、この議論を企業内に広げます。組織がAIを活用し始めると、その経路を実際に何が通るのか、そしてその答えによってセキュリティ設計がどう変わるのかを考察します。
数か月前、ある企業のAIに関する議論に同席しました。その議論は、多くの場合と同じように始まりました。どのモデルを使うべきか。自社で運用するのか、それとも公開モデルを呼び出すのか。精度を高め、ハルシネーションを減らすにはどうすればよいか。どれも重要な問いです。しかし、モデルを選んだ後に何が起こるのかを問う人はいませんでした。
実際には、次のような処理が行われます。ユーザーがプロンプトを送信すると、アプリケーションがそれを受け取り、ユーザーの本人確認を行い、ドキュメントストアやデータベースからコンテキストを取得して、複数の内部APIを呼び出します。エージェントがツールの必要性を判断する場合もあります。こうして組み立てられたリクエストがモデルに到達すると、モデルはトークンを生成します。そのトークンは回答になることもあれば、次のAPI呼び出しやワークフロー、あるいは記録システムの変更をトリガーする指示になることもあります。
このように捉えると、モデルははるかに長い一連の処理を構成する1つの要素にすぎません。ここでいう「推論パス」とは、この一連の処理を指します。そして、本記事の前提となる考察はシンプルです。推論パスはトラフィックパスです。
“従来のトラフィックが運ぶのはデータです。推論トラフィックが運ぶのは、意図、コンテキスト、そして意思決定です。”
推論パスの実態
トレーニングではモデルに学習させます。推論とは、トレーニング済みモデルを実際に稼働させるプロセスです。従業員がエンタープライズアシスタントに「最新の結果を要約し、経営陣向けのメールの下書きを作成して」と依頼すると、そのリクエストはおおむね次のような経路をたどります。
ユーザー → アプリケーション → アイデンティティ → コンテキストと検索 → API → エージェント → モデル → ツール → モデル → 応答 → ユーザー
その一連の処理における各ホップは、ネットワークおよびアプリケーションのトラフィックです。それぞれにエンドポイント、レイテンシ、ルーティングの判断があり、アイデンティティが関連付けられています。データを伝送し、予算を消費するだけでなく、何らかの処理を実行する権限を伴うケースも増えています。
同僚のLori MacVittieは今年初め、これに関連する指摘をしました。推論は本番環境におけるランタイムの動作であり、ユーザー、トラフィックパターン、レイテンシへの感度、障害モード、コスト上の制約、セキュリティリスクを伴うアプリケーション層のように機能します。F5の最高製品責任者であるKunal Anandは、同じジャーニーについてプロンプトからイングレス、ワークフローと推論を経てユーザーに戻るまでの、新たな価値のサプライチェーンであると説明しています。この捉え方を受け入れるなら、セキュリティに関する議論もそれに合わせて変える必要があります。F5のAIセキュリティ担当製品管理バイスプレジデントであるMani Ganesanは、最近のブログ「AIは今や攻撃対象領域に。保護する準備はできていますか？」で、この変化が攻撃対象領域に何を意味するのかを考察しています。
見直すべき4つの前提
CISOがAIセキュリティを強化するうえで、誰もが見直すべき4つの思い込みをご紹介します。
- 「重要なのはモデルだけだ」モデルは目に見える部分であるため、注目を集めます。しかし、プロンプトには機密データが含まれる可能性があり、検索ステップでは機密レコードを取得する場合があります。また、エージェントがAPI認証情報を保持し、エージェントが呼び出すツールがデータベースへの書き込み権限を持つ可能性もあります。モデルだけを保護するのは、データベースと通信するアプリケーションやAPIを無視して、データベースだけを堅牢化するようなものです。攻撃対象領域は、その一連の経路全体にあります。
- 「パイロットから本番環境への移行は、規模を拡大するだけの作業である」通常、パイロット環境には1つのモデル、少数のユーザー、1つのアプリケーション、手動で承認されたアクセスしかありません。本番環境はそれとはまったく異なります。F5の「2026年アプリケーション戦略の現状レポート」によると、組織が連携させているAIモデルは平均7つで、77%がトレーニングではなく推論を現在の主要なAI活動と回答し、52%が複数のモデルを連鎖またはオーケストレーションしています。これは、同じアーキテクチャでユーザー数が増えただけではありません。異なるアーキテクチャであり、それに応じてセキュリティモデルも変更する必要があります。
- 「速度、セキュリティ、ガバナンスはそれぞれ独立したレイヤーである」 個人情報を含むプロンプトを考えてみましょう。ユーザーからモデルに届くまでの間に、そのリクエストを処理中のまま検査し、ポリシーで求められる場合は情報をマスキングし、承認済みのモデルにルーティングするとともに、監査のために監視してログに記録する必要があります。「このリクエストをどこに送るか」を判断する同じポイントで、「そもそもそこに送ってよいのか」も判断しなければなりません。これは、3つの機能を後付けで組み合わせたものではなく、単一のトラフィック処理判断です。
- 「ポイントツールをつなぎ合わせればよい」確かに、APIゲートウェイ、WAF、DLP、IAM、AIガードレール、モデルゲートウェイ、オブザーバビリティ、SIEM、エージェント制御、MCPセキュリティを組み合わせてスタックを構築することは可能です。これらのツール自体に問題があるわけではありません。問題は、ツール間の継ぎ目です。1つのリクエストが、それぞれ独自のポリシーエンジンとアイデンティティコンテキストを持つ6つの制御ポイントを通過する状況を想像してください。プロンプトを入力したユーザーと、現在ツールを呼び出しているユーザーが同一のアイデンティティであることを、誰が把握できるでしょうか。API呼び出し、モデル呼び出し、ツール呼び出しが1つのトランザクションであることを、誰が確認できるでしょうか。一連の処理全体に一貫したポリシーを適用し、後から何が起きたのかを証明できるのは誰でしょうか。
以前のブログでは、推論能力を持つ攻撃者がまず目を向けるのは、ツール間の継ぎ目であると指摘しました。悪意はなくても、単にポリシーから逸脱してしまうエージェントについても同じことが言えます。
トラフィックが意図を伴うようになるとき
AIにより、従来のリクエスト、ルーティング、ポリシー、レスポンスという一連の流れに、コンテキスト、検索、オーケストレーション、ツール呼び出しという新たな段階が加わります。しかし、より本質的な変化は、トラフィックが運ぶ内容にあります。従来のトラフィックが運ぶのはデータですが、推論トラフィックは意図、コンテキスト、意思決定を運びます。
この違いが最も重要になるのは、エージェントの場合です。質問に答えるだけのアシスタントと、顧客記録の読み取り、チケットの起票、メールの送信、コードの実行、インフラストラクチャの変更、支払い指示の発行まで行えるエージェントとでは、意味がまったく異なります。推論経路はアクションの実行経路となり、誤った判断による影響範囲は、情報だけにとどまらなくなります。
推論トランザクションがセキュリティの新たな単位に
従来のセキュリティでは、ユーザー、デバイス、アプリケーション、API、ワークロード、データを基に判断します。ゼロトラストによって、「誰であるか」だけでなく、「何にアクセスしようとしているのか」も問うようになりました。AIシステムでは、さらに3つ目の問いが必要です。「どのデータを使い、どのモデルを通じて、AIに何をさせようとしているのか。そして、このやり取りによってどのようなアクションが実行される可能性があるのか」
この問いに答えるには、既存の単一の制御では把握できないコンテキストが必要です。認証済みのユーザーが財務コパイロットを利用するケースを考えてみましょう。そのリクエストによって機密性の高い財務データが外部モデルに取り込まれ、財務エージェントに引き継がれた後、最終的にERP APIが呼び出され、支払指図が作成されます。この判断をユーザーのアイデンティティだけに基づいて行うことはできません。トランザクション全体を考慮する必要があります。
だからこそ、アイデンティティ、アプリケーションセキュリティ、APIセキュリティ、AIセキュリティ、トラフィック管理が融合しつつあります。その融合の単位となるのが、アイデンティティ、プロンプト、コンテキスト、モデル、データ、ツール、出力、アクションで構成される推論トランザクションです。これはHTTPリクエストよりもはるかに多くの情報を含むオブジェクトです。
トランザクション単位で考えると、セキュリティは単なるチェックポイントではなく、継続的なループになります。推論の前には、誰が要求しているのか、どのようなデータを提供しているのか、プロンプトに悪意があるか、どのモデルに送るべきかを確認します。
推論中に問われるのは、リクエストがポリシーと予算の範囲内にあるか、エージェントが許可されていないツール呼び出しを試みていないかです。推論後には、レスポンスを安全に返せるか、何らかのアクションがトリガーされたか、何をログに記録する必要があるかを確認します。こうした判断は、すべてのコンテキストが同時にそろう唯一の場所である、トラフィックが流れる場所で行う必要があります。
CISOにとっての意味
このパターンは過去にも見られました。モノリスは分散アプリケーションへ、クライアントサーバーはAPIとマイクロサービスへと移行し、境界型セキュリティはアイデンティティとアプリケーションを認識する制御へと置き換わりました。そのたびに、トラフィックを配信し保護するインフラストラクチャの戦略的重要性が高まりました。推論は、このサイクルの次の転換点です。
したがって、アーキテクチャチームに問うべきなのは、モデルがどこに存在するかだけではありません。推論トラフィックがどこを流れ、何を運び、どこに到達でき、どのような判断を下し、どのようなアクションを引き起こせるのかを確認してください。そして、最も難しい問いを投げかけます。アプリケーションの速度を低下させることなく、これらすべてに対するポリシーをどこで適用できるのでしょうか。
AI時代には、最も重要なセキュリティ境界は、もはやモデルの周囲ではなく、モデルに出入りする経路上にあるかもしれないからです。
F5のアプローチについて詳しくは、F5 AI Gatewayのページをご覧ください。また、私の以前のブログ記事「フロンティアAIをネットワーク境界で阻止：インライン制御がMythosクラスのモデルへの対策で中核的な優位性となる理由」もぜひお読みください。
著者について
関連するブログ記事
経営幹部が抱くAIに関する4つの誤解
AIに関する誤解は数多くあります。ここでは、組織が自社環境にAIを導入する際に見直す必要があるかもしれない4つの誤解を紹介します。
IT/OTコンバージェンスの現状と、セキュリティを最優先すべき理由
ITシステムとOTシステムの融合が進むにつれ、攻撃対象領域は拡大します。組織が安全に統合する方法と、F5 ADSPが大規模な運用の保護にどのように役立つかをご紹介します。
AIのレイテンシ：セキュリティを犠牲にできない理由
AIのレイテンシは、単なる速度の問題ではありません。パフォーマンス、セキュリティ、信頼性のバランスを考慮したシステム設計が重要です。
AIアプリケーションを大規模に提供する：ADCの役割
AIアプリケーションを確実に提供するには、高速なモデルや柔軟に拡張できるインフラストラクチャだけでは不十分です。AIアプリケーションの利用方法を管理するための制御レイヤーが必要です。
MCP：AI対応のアプリケーションデリバリを実現する鍵
Model Context Protocol（MCP）は、最新のアプリケーションにおける安全で低遅延なAI統合を可能にします。将来を見据えたアプリケーションデリバリ戦略にMCPが不可欠な理由をご覧ください。
AIガードレールとは？基盤モデルプロバイダーの枠を超えて進化する安全対策
急速に変化する組織の脅威領域におけるリスクをより包括的に捉えるために、AIガードレールの進化が必要な理由をご覧ください。