生成AIセキュリティというと、どうしてもモデルそのものの防御に目が向きがちです。たとえば、プロンプトインジェクションをどう防ぐか、危険な出力をどう抑えるか、レッドチーミングをどう回すか、といった話です。

もちろんそれは重要です。ただ、実際に業務で生成AIを使い始めると、守るべき対象はモデルだけではありません。

AIエージェントが呼び出すAPI
社内システムとの連携
外部SaaSとの接続
管理されていないシャドーAPI
いつの間にか増えた古いAPIや未管理API

このあたりが見えていないと、そもそも何を守るべきか分かりません。

AppWorld 2026でF5が打ち出した API discovery の拡張を見ていて、今回あらためて感じたのは、生成AIガバナンスはモデルの外側、つまりAPIの可視化から始まるということです。AppWorld 2026全体でも、F5は AIアプリやワークフローを 「展開し（deploy）、拡張し（scale）、保護する（protect）」 することを前面に出していました。

API discovery 拡張概要

今回のF5のAPI discovery拡張は、単なるAPI管理機能の追加ではありません。
生成AIセキュリティの文脈で見ると、役割はかなり大きいです。

理由はシンプルで、AI Guardrails や AI Red Team を本当に効かせるには、AIシステムの周辺APIが見えている必要があるからです。F5自身も、AI Guardrails / AI Red Team を API security や WAF、DDoS防御と組み合わせることで、既存アプリとAIシステムを一貫して守れると説明しています。

つまり、今回の話はこう整理できます。

AI Guardrails / AI Red Team はモデルやAI入出力を守る中心装置
API discovery は、その周辺の攻撃面を見える化する土台
両方が揃って初めて、生成AIガバナンスが現実の運用に乗る

この視点で読むと、今回のAPI discovery拡張はかなり面白いです。

なぜAPI discoveryが生成AIガバナンスに効くのか

生成AIシステムは、単独で完結することがほとんどありません。
実務では、次のような構成になりがちです。

LLM本体
プロンプト処理層
エージェント
社内DBや業務システム
外部API
ツール呼び出し
認証・認可まわりの仕組み

つまり、生成AIは「モデル」ではなく、APIと接続の集合体として動いています。

このとき怖いのは、モデルの防御が弱いことだけではありません。
それと同じくらい、どんなAPIが存在しているか分からないことが危険です。

F5のAPI Securityページでも、同社は API security を discover, govern, protect の一体型で捉えていて、完全かつ継続的な可視性を強調しています。これは生成AIにもそのまま当てはまります。見えていないAPIは、当然ガバナンスの対象にもなりません。

AppWorld 2026で何が拡張されたのか

今回F5が打ち出したのは、APIを事前登録して管理する仕組みの強化というより、実際の通信やログをもとに、どんなAPIが使われているかを見つけやすくする仕組みの拡張です。

ここでいう API discovery は、Azure API Management のように「登録済みのAPIを管理する」イメージとは少し違います。
F5がやろうとしているのは、BIG-IP や NGINX などを通る実際の通信データを見て、未管理のAPIや shadow API を見つけることです。

F5のブログによると、拡張ポイントは大きく3つあります。

1. BIG-IP向けの API discovery 拡張

まず分かりやすいのが、BIG-IP を使っている環境向けの拡張です。

BIG-IP は、F5のロードバランサー/アプリケーション配信基盤として使われることが多く、アプリやAPIへの通信がそこを通るケースがあります。
今回の拡張では、その BIG-IP を流れるAPI通信を out-of-band で分析 できるようになりました。

つまり、APIを管理台帳から探すのではなく、実際に流れている通信を見て「こういうAPIが使われている」と把握する イメージです。
その結果として、以下のようなものを見つけやすくなります。

すでに存在しているのに管理されていない API
台帳に載っていない shadow API
もう使われていないはずなのに残っている deprecated API

あわせて、API inventory の更新にもつなげられます。

2. BIG-IP以外にも広げた

今回のポイントは、BIG-IP だけで終わらないことです。

F5は discovery の対象を、NGINX OSS、NGINX Plus、Kong、Apigee などにも広げています。
さらに、さまざまな gateway や proxy からログを収集して分析する universal discovery も打ち出しています。

つまりF5の考え方は、
「F5製品の中だけを見る」のではなく、「実際にAPI通信が見える場所から広く拾う」
という方向です。

これによって、環境ごとに製品がばらばらでも、APIの実態を見つけやすくなります。

3. クラウドに出せない環境にも対応した

もう1つ重要なのが、local API discovery です。

これは、クラウドにデータを送れない環境向けの仕組みです。
たとえば、閉域環境や規制の厳しい業界では、ログや通信データを外に出せないことがあります。

そうした環境でも、100%ローカルで API discovery を動かせるようにしたのが今回のポイントです。

何がそんなに重要なのか

今回の機能拡張で特に重要なのは、F5が発見対象として明示しているものです。

ブログでは、次のような検出が強調されています。

shadow API
unmanaged API
deprecated / forgotten API
OpenAPI schema の生成
sensitive data detection
risk insights の付与

これは生成AIガバナンスの観点でかなり意味があります。

たとえば、AIエージェントが社内の未管理APIを呼び出していたとしても、そのAPI自体が台帳に載っていなければ、統制も監査も不可能です。
Guardrails で入力と出力を守っていても、接続先の棚卸しができていなければ、攻撃面は残ります。

逆に言うと、API discovery によって

どのAPIが存在するのか
どのAPIが古いのか
どのAPIが管理外なのか
どのAPIが機密データに触れるのか

が見えるようになると、生成AIシステムの周辺をガバナンス対象にできます。
ここで初めて、AI Guardrails や AI Red Team の価値も運用全体に広がります。

AI Guardrails / AI Red Team とどうつながるのか

ここを整理しておくと、全体像がかなり分かりやすいです。

AI Guardrails

F5 AI Guardrails は、モデル非依存のランタイム保護レイヤーとして、プロンプトインジェクション、jailbreak、データ漏えい、コンプライアンス違反への対応を担います。さらに、AI入出力の可観測性と監査性も強調されています。

AI Red Team

F5 AI Red Team は、継続的かつ自動化された adversarial testing によって、AIモデルやAIアプリの脆弱性を検証します。F5は、毎月1万件以上の新しい攻撃手法が追加されるような進化する脅威環境を前提に、継続的な保証を提供すると説明しています。

API discovery

一方の API discovery は、モデルそのものを守る機能ではありません。
役割は、モデルやエージェントの周辺で何がつながっているかを明らかにすることです。

この関係をひとことで言うと、

AI Guardrails / AI Red Team はAIそのものを守る
API discovery はAIの外側の接続面を見える化する

です。

生成AIガバナンスを現場に落とすには、この両方が必要です。
モデルだけ見ても足りないし、APIだけ見ても足りない。F5はそこを ADSP 全体でつなごうとしているように見えます。

まとめ

F5のAPI discovery拡張を生成AI文脈で読むと、ポイントはとてもシンプルです。

生成AIガバナンスは、モデルだけ見ても始まらない。まずAPIが見えている必要がある。

AI Guardrails や AI Red Team はとても重要です。
ただ、それらを本当に効かせるには、AIシステムの外側にある API、gateway、proxy、接続先まで含めて把握しないといけません。

その意味で、今回の API discovery 拡張は脇役ではなく、
AI Guardrails / AI Red Team を現実の運用に接続するための土台
として見るのが自然だと思います。