Fastly AI Firewall、ランタイム制御とともに登場――ただし真の試練はエッジセキュリティ

Fastlyは9月21日、Fastly AI Firewall、AI Runtime Control、拡張API Securityを含む、連携する3つのAI制御機能を発表した。この統合リリースにより、モデルルーティング、プロンプト検査、利用上限、エージェント制限が、Fastlyの既存エッジリクエスト経路に組み込まれる。

この位置付けには中心的な緊張関係がある。Fastlyは、単独で機能するモデルフィルターを新たに売り出しているわけではない。同社は、アプリケーション、AIプロバイダー、ユーザー、企業APIの間に位置する制御点として、自社インフラを利用してもらうことを狙っている。

CloudflareとPalo Alto Networksはすでに、このポジションの一部を巡って競合している。そのためFastlyは、許容しがたい遅延、コスト、プライバシー上の露出、導入の複雑さを増やすことなく、自社のエッジアーキテクチャが有用な制御を提供できると証明しなければならない。

今回の発表は、Fastlyのネットワークで機械トラフィックの比重が増すなかで行われた。Fastlyによれば、2026年7月と8月には、機械生成のリクエストがネットワークトラフィックの半分を超えたという。また1月から5月にかけて、AIトラフィックは人間によるトラフィックの6.5倍の速度で増加したとしている。

これらの数値は、広範なインターネットに対する独立した測定ではなく、Fastly自身のネットワーク観測に基づくものだ。それでも、エッジプロバイダーがAIガバナンスを独立したセキュリティカテゴリではなく、インフラの機会と捉える理由を説明している。

Fastly AI Firewall、エッジをAIの制御点に転換

Fastlyのリリースは、本番環境のAIリクエストにおける異なる部分を扱う3つの制御機能を組み合わせている。

AI Runtime Controlは、アプリケーションとモデルプロバイダーの間に位置する。アプリケーションは各プロバイダーを直接呼び出す代わりに、Fastlyの1つのエンドポイントを介してモデルリクエストを送信する。

Fastlyは、仮想キーを使用して基盤となるプロバイダー認証情報を保護する。管理者は、パブリックまたはセルフホスト型のプロバイダーへのアクセスを維持しながら、それらのキーをモデル、ユーザー、予算、トラフィック制限に関連付けられる。

このアーキテクチャにより、運用担当者はリクエスト量、トークン消費、プロバイダー選択、モデル応答を一元的に把握できる。また、設定済みのサービスが利用不能になった場合には、プロバイダーのフェイルオーバーもサポートする。

Fastly AI Firewallは、その制御プレーンにセキュリティ検査を加える。プロンプトを転送前に確認し、対象となる応答をアプリケーションへ返す前に検査する。

同社によれば、ファイアウォールは既知のプロンプトインジェクションおよびジェイルブレイクのパターンを検出する。プロンプトインジェクションは、信頼できない入力が、モデルを統制すべき指示を置き換えたり上書きしたりしようとする際に発生する。

顧客は、ファイアウォールをロギングモードまたはブロッキングモードで実行できる。ロギングは検出を記録しつつリクエストを維持し、ブロッキングは一致したリクエストをプロバイダーに到達する前に拒否する。

3つ目のコンポーネントは、企業APIを呼び出すエージェントに対応する。Fastlyの拡張API Securityは、受信リクエストを公開済みのAPIコントラクトと比較できる。APIコントラクトは、サービスが受け付ける操作とデータ形式を定義する。

組織は、それらのコントラクトに違反するリクエストを監視またはブロックできる。この制御は、従来型アプリケーション、支援型ワークフロー、自律型エージェントに適用される。

この区別は重要だ。エージェントは、サポートされていない操作を試みながらも、構文上は有効なネットワークトラフィックを生成できる。従来の可用性チェックでは、要求されたアクションがエージェントの権限範囲に属するかどうかは判定できない。

Fastlyは、この3つのコンポーネントを1つのリクエスト経路システムとして提示している。モデル呼び出しはルーティングと計測が可能で、プロンプトは検査され、エージェントのアクションはAPI境界で制限できる。

発表資料によると、Fastlyが発表した時点で、3つの機能はすべて利用可能になっていた。このリリースは、将来のプレビューや招待制の研究プロジェクトについては説明していない。

Fastlyはまた、これらの制御機能が既存のグローバルプラットフォーム上で動作すると述べている。同社によれば、そのネットワーク容量は2026年6月30日時点で毎秒622テラビットだった。

Fastlyによると、3月31日時点で同プラットフォームは1日あたり5兆件超のリクエストを処理していた。これらの数値はプラットフォームの規模を示すが、新しいAI製品の性能を裏付けるものではない。

それでも戦略的な変化は明白だ。Fastlyは、配信およびアプリケーションセキュリティにおける自社の位置付けを、AI支出とセキュリティポリシーを同時に強制できるモデルリクエスト経路へと拡張した。

これは、単体のプロンプトフィルターより幅広い販売提案を生み出す。一方で顧客には、機微なモデルのやり取りを別の運用レイヤー内に配置することも求める。

AI Runtime Controlがインフラ競争になりつつある理由

エンタープライズAIは、ルーティング、コスト、認可という問題を同時に生み出す。

初期段階のAIアプリケーションでは、多くの場合、1つの認証情報で1つのモデルプロバイダーに直接接続する。本番システムはより複雑であり、チームは複数のモデル、アカウント、リージョン、フェイルオーバー経路を使用する。

エージェントはこの複雑さをさらに拡大する。人間がすべてのネットワーク呼び出しを承認しなくても、ツールを選択し、リクエストを送信し、データを取得し、操作を実行できる。

Fastly AI Runtime Controlは、プロバイダーに到達する前に、こうしたやり取りを標準化しようとする。仮想キーは呼び出し元を識別し、Fastlyはリクエスト経路の後段で実際のプロバイダー認証情報に置き換える。

これにより、アプリケーションや開発環境全体にプロバイダーキーが広がることを抑えられる可能性がある。また、レートと予算のポリシーを適用する一貫した場所も組織に提供する。

Fastlyのランタイムドキュメントによると、レート制限は1分あたりのリクエスト数またはトークン数に基づいて機能する。予算ルールは、設定済みのしきい値を超えた後に管理者へ警告したり、追加アクティビティをブロックしたりできる。

トークンベースの強制には重要な条件がある。Fastlyは、最終的なトークン数は応答が完了するまで不明であるため、トークン制限はベストエフォート方式で動作すると説明している。

つまりこの制御プレーンは、完全に正確なトークン強制を保証せずに利用量を制約できる。高コストの応答は、その最終トークン数が会計記録に反映される前に完了する可能性がある。

同じドキュメントでは、管理者がリクエストと応答の記録を検査できるとしている。ログには、モデル名、仮想キー、セッションデータ、タイムスタンプ、トークン数が含まれる場合がある。

この可視性は運用上の価値を提供するが、同時にガバナンス上の問題も生む。プロンプトと生成結果には、社内文書、顧客データ、認証情報、個人情報が含まれる可能性がある。

これらの記録を一元化する前に、セキュリティチームは明確な保持、アクセス制御、地域処理のポリシーを必要とする。統合ログが有用なのは、組織が誰にその内容を検査する権限があるかも統制する場合に限られる。

トラフィック管理とセキュリティを組み合わせるFastlyの判断は、より大きな市場の変化を反映している。AIゲートウェイは、単純なプロキシではなく、ポリシー強制ポイントになりつつある。

たとえばCloudflareは、自社ネットワーク上でAI Gatewayの監視機能とアプリケーションセキュリティ制御を組み合わせている。そのプロンプトインジェクション制御では、リクエストにスコアを付与し、顧客はそれをファイアウォールまたはレート制限ルールで使用できる。

Palo Alto Networksは、この問題にエンタープライズセキュリティの観点から取り組む。同社のランタイムセキュリティは、モデル、アプリケーション、エージェント、プラグイン、データ、外部サービス間のライブなやり取りを検査する。

これらの製品は、アーキテクチャやカバレッジが同一ではない。しかし、AIのやり取りをなお観測し、停止できるという同じ価値の高い地点を巡って競争している。

Fastlyの優位性は、アプリケーショントラフィックの配信と保護においてすでに担っている役割にある。すでに同社のエッジネットワークを利用している顧客は、別の独立したゲートウェイを導入するよりも、確立済みの制御プレーンを拡張することを好むかもしれない。

その不利な点も同様に直接的だ。購入者は、すでに自社のモデル、ID、データ制御により近い場所にあるクラウドプラットフォーム、セキュリティベンダー、専門ゲートウェイを選択できる。

この競争は、インフラプロバイダーと企業の購入者の双方に圧力をかける。プロバイダーは、相反するポリシーシステムを生まずに、パフォーマンス、セキュリティ、可観測性、コストガバナンスを結び付けなければならない。

購入者は、権限をどこに置くべきかを決めなければならない。ネットワークエッジは広範な可視性を提供する一方、アプリケーションコードはより詳細なビジネスコンテキストを維持できる。

すべてを把握できる単一のレイヤーは存在しない。ゲートウェイはリクエストを検査できるが、要求されたアクションが特定の顧客やワークフローに適切かどうかは、アプリケーションの方が理解している場合がある。

Fastlyは、アプリケーションが独自の認可ロジックを保持しつつ、エッジが共通の強制レイヤーになれると見込んでいる。AI Runtime Controlの価値は、この2つのレイヤーがどれほどうまく連携するかにかかっている。

製品の仕組みそのものが限界も定義する

Fastly AI Firewallはリクエスト経路での露出を減らすが、プロンプトインジェクションや危険なエージェント挙動を排除するものではない。

Fastlyは、その検査を決定論的なものとして説明している。ファイアウォールは、すべてのプロンプトを別の生成モデルに通すのではなく、既知のインジェクションおよびジェイルブレイクのシグネチャに照らしてリクエストを確認する。

この選択には実用的な魅力がある。決定論的なチェックは予測可能な挙動を提供でき、すべてのやり取りで第2のモデルを実行するコストを避けられる。

Fastlyはまた、信頼できない入力を暗号学的な境界トークンでラップする。付随する指示は、ラップされた素材を権威あるコマンドではなくデータとして扱うようモデルに伝える。

この手法は、言語モデルアプリケーションの基本的な弱点に対処する。システム指示と信頼できないテキストは、意図された権限が異なるにもかかわらず、最終的には関連するトークンストリームとしてモデルに届く。

したがって、悪意ある文書には、それを読み取るモデルに向けた指示を含めることができる。ペイロードが取得コンテンツ、メール、Webサイト、その他の外部ソースから入る場合、攻撃は間接的になる。

Fastlyは、攻撃がモデルに影響を与えた証拠について、対象となる出力を確認する。管理者は、他のリクエスト情報とあわせて、検出タグ、脅威分類、カナリア結果を確認できる。

これらの制御は既知の攻撃に対する摩擦を加えるが、攻撃者は表現、エンコーディング、言語、コンテキストを変えられる。シグネチャシステムは、新たな回避手法の出現に応じて変化し続けなければならない。

OWASPは、大規模言語モデルアプリケーションにおける主要リスクの2025年リストで、プロンプトインジェクションを1位に位置付けている。その防止ガイダンスは、単一のフィルターに依存せず、多層防御を推奨している。

これらの防御には、指示とデータの分離、モデル権限の制限、出力の検証、重要なアクションに対する人間の承認、挙動の監視が含まれる。

Fastlyのドキュメントは、別の境界も明らかにしている。応答の検査には完全な応答が必要なため、ストリーミングリクエストは出力検査なしで通過する。

ストリーミングは、完全な回答を待つ代わりに、生成テキストを段階的に配信する。応答性の高いチャットインターフェースを支えるが、アプリケーションが受信を開始する前に、ファイアウォールが完了済み応答を評価することはできない。

構造的な分離は、リクエストにトークンも追加する。Fastlyは、顧客のモデルプロバイダーが、通常の利用料金のもとでそれらの追加トークンを請求すると述べている。

だからといって、この保護策が実用に適さないわけではない。だが顧客は、本番環境のトラフィック規模において追加トークンのコストが許容範囲に収まるかを測定する必要がある。

レイテンシーについても同様に慎重な検証が求められる。インライン検査は、ユーザーがすでにモデル推論、ツール実行、データ取得を待っている経路に処理を追加する。

Fastlyのエッジ網は、多くのリクエストでネットワーク距離を短縮するはずだ。ただし発表では、ファイアウォールおよびコントロールプレーンの一連の処理全体に関する独立したレイテンシーベンチマークは示されていない。

誤検知は別のトレードオフをもたらす。セキュリティに関する議論、デバッグ用プロンプト、研究コンテンツには、攻撃で使われるものと同じ語句が正当に含まれる場合がある。

ログモードでは、チームはブロックする前にこうした検知を観察できる。一方で、評価期間中は該当するリクエストが通過し続ける。

ブロックモードはそのリスクを抑えるが、正当なトラフィックを拒否するおそれがある。顧客は、単一のポリシーがすべてのアプリケーションに適するものとして扱うのではなく、ワークロード固有のテストを実施する必要がある。

API強制コンポーネントも、正確なコントラクトに依存する。古くなった、あるいは不完全なスキーマは、正当なエージェントの活動をブロックしたり、ビジネス文脈でしかリスクが見えない操作を許容したりする可能性がある。

コントラクト準拠は認可と同義ではない。エージェントは不適切な目的を追求しながら、許可されたエンドポイントを有効なデータで呼び出すことができる。

そのため、この製品はより広範なシステムの一層として導入する場合に最も効果を発揮する。アプリケーション権限、アイデンティティ制御、ツール制限、監査ログ、人間による承認は依然として必要だ。

今回のローンチが重要なのは、これらの制御を既存インフラの内部に組み込んだ点にある。その重要性を、ネットワーク検査がエージェントセキュリティの問題全体を解決するという主張と混同すべきではない。

Fastly、同じリクエスト経路をめぐりCloudflareやセキュリティベンダーと競合

主要な競争は、基盤となるモデルの所有ではなく、AIトラフィックの制御をめぐるものだ。

Fastlyは、顧客が単一のモデルプロバイダーに標準化する必要はない。AI Runtime Controlは、共通エンドポイントを通じてパブリックモデルとセルフホスト型モデルのリクエストをルーティングするよう設計されている。

プロバイダー非依存は、障害、モデル性能の変化、単一ベンダーへの依存を懸念するチームにとって魅力的になり得る。同時に、顧客が運用し信頼しなければならない中央仲介レイヤーも生み出す。

Cloudflareも関連するエッジ戦略を採る。AI Gatewayはモデルの可観測性と制御を担い、AI Security for AppsはWebアプリケーションファイアウォールを通じてプロンプト、トピック、データ関連の検知を追加する。

Cloudflareが公開しているインジェクション検知システムは、1から99までの段階的なスコアを用いる。Fastlyは、決定論的シグネチャ、境界トークン、検知タグ、そして顧客が選択するログまたはブロックの挙動を強調している。

利用可能なドキュメントは異なる制御面を説明しているが、決定的な精度比較を裏付けるものではない。独立したテストには、共通のデータセット、構成、モデル、攻撃手法が必要となる。

Palo Alto Networksは、より広範なセキュリティの枠組みを提供する。同社のランタイム製品は、インジェクション、汚染されたコンテンツ、悪意のあるリンク、データ漏えい、モデルの相互作用、エージェント活動への保護を掲げている。

この広がりは、すでにセキュリティ運用をPalo Alto Networksに標準化している組織に適している可能性がある。Fastlyは、アプリケーション配信への近接性と既存顧客にとって馴染みのあるアーキテクチャで対抗できる。

AIセキュリティに特化した企業も、別の圧力源となる。一般的な配信ネットワークを維持せずに、モデル評価、レッドチーミング、ガードレール、エージェントの振る舞いに狭く焦点を当てられる。

専門企業は、特定の脅威カテゴリー内で迅速に革新できる場合がある。一方で、顧客に別のベンダー、プロキシ、ポリシー言語、テレメトリストアを追加させることにもなる。

したがって、購買判断は機能チェックリストだけでは決まらない。チームは、導入場所、データ処理、モデル対応範囲、ポリシー表現力、可観測性、障害時の挙動を比較しなければならない。

障害時の挙動には特に注意が必要だ。インライン制御は、検査、ログ記録、ポリシーサービスが利用不能になった際、トラフィックを継続させるかを判断しなければならない。

フェイルオープンは可用性を守るが、未検査のトラフィックを通す。フェイルクローズは強制力を維持するが、セキュリティ依存コンポーネントがアプリケーション障害へと発展するおそれがある。

FastlyはAI Runtime Control内のプロバイダーフェイルオーバーを強調している。購入者は、ファイアウォール検査、ログ記録、ポリシー評価、API検証における障害をプラットフォームがどう扱うかを別途確認すべきだ。

ベンダー統合には独自の緊張関係もある。配信、アプリケーションセキュリティ、AIルーティング、エージェント制御に一つのプラットフォームを用いれば、運用上の分断を減らせる。

しかし同時に、一つのリクエスト経路への依存も高まる。設定ミス、プラットフォーム障害、アカウント侵害が複数のレイヤーに同時に影響する可能性がある。

厳格な分離要件を持つ組織は、別々のプロバイダーや強制ポイントを選好するかもしれない。他方、より簡素な運用と統合テレメトリを得るために集中を受け入れる組織もある。

Fastlyは、既存のエッジ顧客が同社にモデルの相互作用を管理してほしいと考えるかも証明しなければならない。Webアセットの配信と完全なAI会話の検査では、プライバシーとコンプライアンスに対する期待が異なる。

短期的に最も有力な導入経路は、おそらく既存のFastly顧客を通じたものだ。彼らはすでにアプリケーショントラフィックをネットワーク経由で送っており、その設定モデルを理解している。

新規顧客にとっては比較がより難しい。Fastlyは、専業ベンダーと競える十分なセキュリティの深さと、モデル呼び出しを再ルーティングする価値を正当化する十分な運用上の価値を示さなければならない。

これが、このリリースが単なる機能発表にとどまらない理由だ。Fastlyはアプリケーションの保護から、それらのアプリケーションが生み出すAI活動の統治へと領域を拡大しようとしている。

FastlyのAIセキュリティへの賭けが成功するかを示す3つのシグナル

導入の証拠、独立したセキュリティテスト、競合各社の対応が、エッジが持続的なAI制御レイヤーとなるかを明らかにする。

第一のシグナルは、本番導入だ。Fastlyは最終的に、どのモデル、ワークロード、ポリシーがAI Runtime Controlを通じて運用されているかを説明する顧客事例を開示すべきだ。

有用なケーススタディでは、導入範囲、移行の労力、ブロックされた活動、誤検知への対応、運用上の成果を報告するだろう。可視性やセキュリティに関する一般論では、証拠としての価値は低い。

顧客は、プロンプトと完了ログをどのように統治しているかも説明すべきだ。その情報によって、集中型の可観測性がプライバシー、コンプライアンス、社内アクセスのレビューを乗り越えられるかが分かる。

第二のシグナルは、Fastly AI Firewallの独立評価だ。テストでは、直接インジェクション、間接インジェクション、ジェイルブレイク、エンコードされたプロンプト、多言語攻撃、無害なセキュリティコンテンツにわたる検知率を測定すべきである。

また、誤検知率、レイテンシー、追加トークン消費量、ストリーミング時の挙動も公表すべきだ。これらの測定がなければ、購入者はアーキテクチャを比較できても、防御性能を検証して比較することはできない。

テストは、変化するモデルと攻撃手法を考慮に入れなければならない。既知のシグネチャに対して良好に機能する制御でも、適応的な攻撃やアプリケーション固有の攻撃には苦戦する可能性がある。

第三のシグナルは、Cloudflare、Palo Alto Networks、そして専門ベンダーがどう対応するかだ。より統合されたルーティング、アイデンティティ、データ損失防止、エージェント認可が登場すれば、Fastlyの統合プラットフォームへの圧力は高まる。

Fastly自身のロードマップも重要になる。現在のドキュメントはすでに、ベストエフォートのトークン強制や、ストリーミング応答に対する不完全な検査など、実務上の制約を示している。

これらのギャップを埋めれば、一つのコントロールプレーンを採用する根拠は強まる。変わらないままであれば、アプリケーションレベルまたは競合するセキュリティレイヤーの余地が残る。

エンタープライズチームは、市場が落ち着くまで待たずに今回のリリースを評価できる。まずログモードで限定的なワークロードを試し、検知結果を既存の制御と比較すればよい。

パイロットには、代表的な無害なプロンプト、敵対的テスト、ストリーミング応答、プロバイダー障害、予算上限のシナリオを含めるべきだ。チームはFastlyが何を保存し、各レコードに誰がアクセスできるかも確認すべきである。

エージェントの試験には、追加のテストが必要になる。エージェントは、明示的なツール権限とAPIコントラクトの下で、正当なワークフローと未認可のワークフローの両方を試行すべきだ。

結果は、ネットワークリクエストのレベルだけでなく、ビジネスアクションのレベルで測定すべきである。形式が正しいリクエストでも、許容できない行動を引き起こす可能性がある。

Fastly AI Firewallが注目に値するのは、セキュリティをルーティング、支出、エージェントAPIの強制と結び付けているからだ。この組み合わせは、孤立したプロンプトフィルターよりも、本番AIの運用形態に近い。

未解決の問題は、Fastlyがネットワーク上の立場をAIの振る舞いに対する信頼できる権限へと転換できるかどうかだ。エッジ検査は可視性と強制の機会をもたらすが、ビジネス文脈は依然として別の場所にある。

開発者とセキュリティリーダーにとって、次の行動は具体的だ。FastlyのAI制御を実際のワークロードでテストし、すべての死角を文書化し、競合するリクエスト経路の防御策と結果を比較するべきである。製品の価値は、その下にあるネットワークの規模ではなく、障害と攻撃の下で測定された挙動から明らかになる。