ゾンビAPIとは？生成AI時代に増える“見えないAPI”の棚卸しと統制7ステップ

2026.03.20
読了時間目安 9分

生成AIやAIモデルを業務に導入するとき、最大の盲点になりやすいのが「ゾンビAPI」です。
結論から言うと、ゾンビAPIとは新しいシステムに置き換えられた、または非推奨となったにもかかわらず、完全に削除されずに稼働し続けている古いAPIを指します。AI導入により、外部SaaS・LLM基盤・プラグイン・データ連携が増えるほど、APIは爆発的に増え、棚卸しと統制の難易度が一気に上がります。

では、なぜ今ゾンビAPIが危険なのでしょうか。
理由はシンプルで、「守っているつもりの範囲」から漏れたAPIが、最短距離で侵害につながるからです。APIはWebアプリ以上に機械的に叩け、認証・認可の欠陥、レート制限不足、古いエンドポイント放置などがあると、情報漏えい・不正操作・アカウント乗っ取りに直結します。API攻撃が増加している現実は、Akamaiのレポートでも繰り返し示されています。
さらに生成AI・AIモデルの導入は、サプライチェーン攻撃（モデル、パッケージ、外部サービス連携）の経路を増やします。
たとえば「社内のアプリ→API→外部LLM→外部ツール→外部データ」という形で依存関係が複雑になると、どこか1点の“見えないAPI”が侵入口になった時、被害範囲は連鎖的に広がります。

本記事では、ゾンビAPIの定義を明確化し、生成AI時代にありがちな発生パターン、そして棚卸し・リスク評価・統制（ガバナンス）を現場で回すための具体策を、実務目線で整理します。

ゾンビAPIとは何か：一言でいうと「廃止したはずなのに到達可能なAPI」
- シャドーAPIとは何か
なぜAPIは狙われるのか：侵害の主戦場が「画面」から「インターフェース」へ
生成AI導入でゾンビAPIが増える理由：連携の爆発と「実験の常態化」
ゾンビAPIの見つけ方：棚卸しは「台帳」ではなく「観測」から始める
- 観測ソース（現実的に効く順）
リスク評価の軸：AI連携を前提に「データ×権限×露出×依存」で見る
統制（ガバナンス）の実装：ゾンビ化を防ぐ7つの仕組み
すぐ使えるチェックリスト：あなたの組織にゾンビAPIがいるサイン
まとめ：ゾンビAPI対策は「可視化→優先度→統制」で最短ルートを作る
参考・出典

ゾンビAPIとは何か：一言でいうと「廃止したはずなのに到達可能なAPI」

ゾンビAPIは、deprecated（非推奨）や置き換え済みのはずが停止されず、運用の盲点として残り続けるAPIです。典型例は次のとおりです。

旧バージョン（v1）が互換性の名目で残り、実際には保守されていない
移行後に不要になったエンドポイントや連携（Webhook、ETL、バッチ）が消し切れず残存
過去の仕様・委託開発の機能が置き換えられたのに、古いAPIだけ稼働し続ける
棚卸しはされていても監視・パッチ適用が薄く、攻撃者に狙われやすい

シャドーAPIとは何か

シャドーAPIとは、企業内に存在するAPIのうち、次のようにセキュリティ/運用の管理対象から漏れているAPIを指します。

公式なAPI管理台帳に載っていない
WAF/APIセキュリティ製品の保護対象外
認証・認可・レート制限・監査ログが不十分
そもそも「誰が」「何の目的で」作ったかが曖昧（PoC、旧機能、委託先開発など）

更に似た概念に「未管理API」がありますが、実務上はまとめて“見えていないAPI”が最大の問題になります。なぜなら、守る以前に把握できていないからです。

ポイントは、「誰も使っていない」ではなく「誰も把握していない」ことです。ログ監視・WAF設定・脆弱性診断・認証統制・オーナー管理など、基本的な防御が適用されないことが多く、攻撃者から見れば“都合のよい入口”になります。

なぜAPIは狙われるのか：侵害の主戦場が「画面」から「インターフェース」へ

APIはアプリの中核機能（認証、顧客情報、決済、操作命令）に直結しており、攻撃者は画面を操作するより効率よく狙えます。Akamaiのホワイトペーパーでも、API侵害を防ぐために「発見」「可視化」「認証・認可」「継続的モニタリング」等の体系的対策が重要である趣旨が述べられています。
出典：Akamai「How to Prevent an API Breach」
https://www.akamai.com/site/en/documents/white-paper/2024/how-to-prevent-an-api-breach.pdf

特にゾンビAPIは、次の条件が揃いやすいです。

認証はあるが認可が甘い（他人のIDのデータにアクセスできる等：BOLA/IDOR系）
レート制限がなく総当たり・スクレイピングに弱い
監視対象外で異常が検知されない
仕様書（OpenAPI）が更新されず、脆弱な使い方が残る
廃止済みのはずが残り、パッチ・鍵更新が止まる

生成AI導入でゾンビAPIが増える理由：連携の爆発と「実験の常態化」

生成AI活用は、これまでより短いサイクルで「試す→つなぐ→回す」が起きます。すると、APIが次のように増殖します。

1) 外部LLM・AIサービス連携が増える

社内アプリから外部LLM（推論API）へ投げるだけでなく、ベクトルDB、ログ基盤、評価基盤、プロンプト管理、ガードレール製品など連携点が増えます。連携点＝APIであり、そのたびに鍵・権限・監視・契約条件が増えます。

2) モデル／パッケージ／ツールのサプライチェーンが長くなる

AI導入ではOSSライブラリ、モデル配布、コンテナ、推論サーバ、プラグイン、RAG用のコネクタなどの依存が重なります。NISTはサイバーサプライチェーンリスク管理（C-SCRM）の文脈で、調達・利用に伴うリスクを組織的に扱う必要性を示しています。
出典：NIST「Guidelines for API Protection for Cloud-Native Systems（NIST SP 800-228）」
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-228.pdf

3) PoCのまま本番化しやすい

PoC等のAPIは「動作優先」で認証や監視が欠落しがちです。これらが正規の統制を経ずに本番利用されると「シャドーAPI」化し、防御の死角として攻撃者に狙われます。

ゾンビAPIの見つけ方：棚卸しは「台帳」ではなく「観測」から始める

ゾンビAPI対策の第一歩は、API一覧をExcelで集めることではありません。まず観測して“存在するAPI”を確定させ、その後にオーナー・用途・リスクを付与して台帳化します。

観測ソース（現実的に効く順）

APIゲートウェイ／リバースプロキシ／LBのログ：実際に呼ばれているエンドポイントが出ます
WAF／Bot対策のイベント：外部から探索されている兆候が出ます
クラウドのフローログ（VPC Flow Logs等）：到達経路と宛先が分かります
DNS・証明書発行履歴：忘れられたサブドメインが見つかります
ソースコード検索：/v1/、/internal/、外部API URL、Webhook URL、秘密情報など
SaaS管理（CASB/SSPM）：部門SaaSの“勝手API連携”が見えます

ここで重要なのは、「呼ばれていないAPIは安全」と誤解しないことです。呼ばれていなくても、到達可能なら探索されます。Akamaiの調査・レポート類でも、APIが継続的に狙われる前提での可視化・監視が鍵になります。
出典：Akamai「API Attacks Costs: Impact on 4 APAC Countries」
https://www.akamai.com/site/en/documents/white-paper/2025/api-security-study-asia-pacific-2025.pdf

リスク評価の軸：AI連携を前提に「データ×権限×露出×依存」で見る

棚卸ししたら、次は優先順位付けです。おすすめは以下の4軸でスコアリングすることです。

データ機微度：個人情報、認証情報、営業秘密、学習データ、プロンプト/回答ログ
権限の強さ：参照のみか、更新・削除・送金・権限付与までできるか
露出（Exposure）：インターネット公開、パートナー公開、社内限定、ゼロトラスト配下
依存関係：外部LLM、外部ツール、OSS、モデル配布元、CI/CD、プラグインの数

生成AI特有の観点として、次も加点要素にすると事故が減ります。

プロンプト注入等の入力悪用で「外部ツール実行」や「データ参照」が連鎖する設計か
モデル/ツール側の仕様変更が業務ロジックに直撃するか
ログに機微情報が残る設計か（プロンプト・回答・コンテキスト）

統制（ガバナンス）の実装：ゾンビ化を防ぐ7つの仕組み

ゾンビAPIは「一度退治して終わり」ではなく、再発防止の仕組みが本体です。実務で効く施策を7つにまとめます。

1) APIオーナーを必ず割り当てる（不在なら停止候補）

台帳に「責任者」「保守期限」「利用者」を必須項目にします
オーナー不在のAPIは、原則として段階的停止の対象にします

2) 入口をAPIゲートウェイに寄せる（集中制御）

認証・レート制限・スキーマ検証・監査ログを共通化します
“例外的に直公開”を許すとゾンビ化が再発します

3) 認証「だけ」でなく認可をテストする（BOLA/IDOR対策）

ユーザーIDを変えて他人のデータが取れないか
管理者専用APIに一般ユーザーが到達できないか
テストケース化しCIに組み込みます

4) 仕様（OpenAPI）を“契約”として運用する

仕様がないAPIは新規公開不可
仕様変更はレビューと互換性方針（バージョニング）必須
仕様と実トラフィックの差分検知でゾンビ候補が見つかります

5) 廃止プロセスを制度化する（期限・通知・遮断）

「廃止予定→並行期間→遮断→削除」までのテンプレを持ちます
旧版を残す場合も終了日を契約します（“永遠の互換”がゾンビの温床）

6) AI連携は「最小権限」と「鍵のライフサイクル」を必須にする

外部LLM鍵は環境分離（本番/検証）
期限付きトークン、ローテーション、漏えい時の無効化手順
外部ツール実行権限は必要最小限（RAG検索・社内DB参照・チケット発行等）

7) 継続監視：異常検知を“API単位”で持つ

失敗率急増、深夜帯の急増、特定パラメータの偏り
1ユーザーからの連続アクセス、地理的に不自然なアクセス
Akamaiの資料でも、侵害を防ぐには継続的な監視と検知が重要である趣旨が示されています。
出典：Akamai「How to Prevent an API Breach」
https://www.akamai.com/site/en/documents/white-paper/2024/how-to-prevent-an-api-breach.pdf