前回のアプリケーションセキュリティ編(1)（https://cloudsecurityalliance.jp/newblog/2026/02/22/apsec_1/）では、AIシステムのうちエージェンティックAI固有のセキュリティ課題や対策について取り上げた。今回は、AIシステムの橋渡し役を担うAPIのセキュリティに焦点を当てる。
LLMアプリケーションを支えるAPIセキュリティ
クラウドセキュリティアライアンス（CSA）の2021年5月11日付ブログ記事「OWASP APIセキュリティ Top 10の理解」（関連情報（https://cloudsecurityalliance.org/blog/2021/05/11/understanding-the-owasp-api-security-top-10/））では、CSAとグローバルレベルで連携するOWASPのドキュメントの中で、アプリケーション・プログラミング・インターフェース（API）特有の脆弱性やセキュリティリスクを理解し、それらを軽減するための戦略とソリューションに焦点を当てた「OWASP APIセキュリティ Top 10」初版（2019年12月公開）を紹介している（関連情報（https://owasp.org/API-Security/editions/2019/en/0x11-t10/）。その後2023年6月、OWASPは「OWASP APIセキュリティ Top 10」第２版を公開している（関連情報（https://owasp.org/API-Security/editions/2023/en/0x11-t10/））。第２版のAPIセキュリティTop 10各項目は、以下の通りである。
・API1:2023 BOLA (オブジェクトレベルの認可不備) ：
IDを指定してデータを得る際、他人のデータにアクセスできてしまう問題（最重要）。
・API2:2023 認証の不備：
パスワードやトークンの管理、JWTの検証ミスなど。
・API3:2023 オブジェクトプロパティレベルの認可不備：
特定のフィールド（例：管理用フラグ）の読み取りや書き換えを許してしまう問題。
・API4:2023 制限のないリソース消費：
呼び出し回数やデータ量の制限がなく、DoS状態や高額請求を招く問題。
・API5:2023 機能レベルの認可不備：
一般ユーザーが管理者用APIエンドポイントを実行できてしまう問題。
・API6:2023 機密性の高いビジネスフローへの無制限アクセス：
買い占めやスパムなど、正規の機能でも自動化されるとビジネスに害を及ぼすケース。
・API7:2023 SSRF (サーバーサイドリクエストフォージェリ) ：
APIサーバーを踏み台にして、内部ネットワークに攻撃を仕掛けられる問題。
・API8:2023 セキュリティ設定のミス：
不要な機能の有効化、古いパッチ、不適切なCORS設定など。
・API9:2023 不適切なインベントリ管理：
放置された旧バージョン（ゾンビAPI）や未把握のAPI（シャドウAPI）の放置。
・API10:2023 APIの安全でない利用：
連携先のサードパーティAPIから届くデータを盲信し、検証せず処理してしまう問題。
さらにCSAは、2025年5月9日付で、「LLMのためのOWASP Top 10：CSAによる戦略的防御プレイブック」（関連情報（https://cloudsecurityalliance.org/blog/2025/05/09/the-owasp-top-10-for-llms-csa-s-strategic-defense-playbook））と題するブログ記事を公開している。ここでは、OWASPの「LLMアプリケーションのためのOWASP Top 10 (2025年版)」（2024年11月17日公開、関連情報（https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/））を紹介している。LLMアプリケーションのためのOWASP Top 10各項目は、以下の通りである。
・LLM01:2025 プロンプトインジェクション：
ユーザー入力によってモデルの挙動が意図せず変更される。ジャイルブレイク(脱獄)も含む。
・LLM02:2025 機密情報の漏えい：
モデルが学習・出力する内容により、個人情報や知的財産が漏えいする可能性。
・LLM03:2025 サプライチェーンの脆弱性：
トレーニングデータや外部モデルの改ざん・汚染によるリスク。
・LLM04:2025 データおよびモデルのポイズニング：
故意に不正なデータを混入させて、モデルの出力を操作する攻撃。
・LLM05:2025 出力の不適切な取り扱い：
モデルの出力を無検証で使用することにより、誤情報や有害な結果を招く。
・LLM06:2025 過剰なエージェンシー：
モデルが過度に自律的に判断・行動することで、制御不能なリスクが生じる。
・LLM07:2025 システムプロンプトの漏えい：
内部設定や指示が外部に漏れることで、攻撃者に悪用される可能性。
・LLM08:2025 過剰なリソース消費：
LLMが過剰な計算資源を消費し、サービス停止やDoSにつながる。
・LLM09:2025 不適切なアクセス制御：
モデルや関連システムへのアクセス制御が不十分で、情報漏洩や改ざんのリスクがある。
・LLM10:2025 ガバナンスとコンプライアンスの欠如：
法規制や倫理的枠組みに対する配慮が不足し、企業リスクを高める。
CSAは、「LLMアプリケーションのためのOWASP Top 10」を実行可能なセキュリティファーストの指針へと対応づけることにより、組織が責任を持って、かつレジリエントにAIを導入できるよう支援することを目指すとしている。
なお、LLMアプリケーションのためのOWASP Top 10では、LLMアプリケーションにおけるAPIの役割を、以下のように位置付けている。
・APIは外部アプリケーションがLLMの機能を利用するためのゲートウェイである。
・APIは外部アプリケーションとLLMとの通信のルールを定めている。
・APIはアプリケーションからのリクエストをLLMに渡し、生成されたコンテンツを再びアプリケーションに返す仲介役である。
・APIキーやトークンによる認証を通じて、アクセス制御を行うことにより、不正利用やデータ漏えいのリスクを軽減する。
AIで急増するM2MトラフィックがもたらすAPIの変容
次に、CSAのブログ記事「AI時代におけるAPIセキュリティ」（関連情報（https://cloudsecurityalliance.org/blog/2025/09/09/api-security-in-the-ai-era））では、API（アプリケーション・プログラミング・インターフェース）の利用形態の変容について触れている。かつてAPIは、主にWebやモバイルアプリの舞台裏で機能する統合レイヤーであったが、現在ではAIシステム、クラウドサービス、そして分散型アプリケーションにとっての「主要なゲートウェイ」となっている。
このようなAPIの変容は、単なる規模の変化にとどまらず、脅威モデルそのものに変化をもたらしている。大規模言語モデル（LLM）を搭載したAIシステムは、膨大な量のデータを消費・生成する。そのデータの多くは、従来のネットワーク・インターフェースに比べて監視が不十分になりがちなAPIを通じて流れている。事実上、APIは企業の機密データにおける「正面玄関」であり、「配送トラック」であり、時には「金庫」そのものになっているのが実情である。
セキュリティ企業Traceableの報告書（関連情報（https://www.traceable.ai/2025-state-of-api-security））によると、APIに関連するデータ侵害は増加傾向にあり、その検知も不十分である。さらに、AIによるAPI利用の導入が、攻撃の量と種類の両面を拡大させている。
かつてAPIの呼び出しの多くは、ポータルへのログイン、データのリクエスト、フォームの送信といった「人間による操作」がトリガーとなっていた。しかし現在では、マシン・ツー・マシン（M2M）トラフィックを介して、AIシステムが自律的かつ大規模なスケールでAPIの呼び出しを行っている。かつては1日に数百回程度だったAPIへのアクセスが、AI駆動のワークロードによって、今や1分間に数千回ものリクエストが発生するようになっている。
また、AIエージェントは複数のAPIを連鎖させ、次にどのエンドポイントにアクセスすべきかを複雑に判断することも可能である。これらのツールは、ユーザーのプロンプトや環境データに基づいて多様なリクエストを生成するため、比較対象となる固定されたベースライン（基準）のパターンが存在せず、異常検知をより困難なものにしている。
攻撃者はAIを悪用してペイロード（データ本体）を改ざんし、悪意のあるコードを難読化したり、単純なシグネチャベースのルールを回避する「合成（synthetic）」リクエストシーケンスを生成したりする。数百ものAPIを抱える組織にとって、露出したすべてのエンドポイントをカバーできるよう検知ルールを迅速に修正・更新し続けることは困難である。WAF（Web Application Firewall）のルールやOWASP Top 10の対策だけに依存していては、大きなセキュリティギャップが残ることになる。
生成AIツールは、公開されているAPIドキュメントを自動的に解析し、即座に実行可能な攻撃シナリオを生成できるため、攻撃側の手作業を劇的に削減する。また、モデルの学習、知的財産の窃盗、あるいは競合情報の収集といった目的のために、公開APIからのデータ収集を自動化することも可能になっている。
AI主導の統合が進むことにより、APIの採用は加速している。コンテンツAPI、データAPI、サービスAPI、ストリーミングAPI、さらにはその他の派生形が、多くのチームが追跡や保護を行える速度を超えて次々と登場している。この急速な拡大従って、以下のようなリスクが顕在化しつつある。
・シャドウAPI（Shadow APIs）: セキュリティレビューを回避して公開された、ドキュメント化されていないエンドポイント。
・ゾンビAPI（Zombie APIs）: 更新が停止しているにもかかわらず、アクセス可能な状態で放置された古いAPI。
・孤立したAPI（Orphaned APIs）: 組織内に明確な所有者が存在しないエンドポイント。
特に、社内のAI実験のために開発されたAPIは、適切なドキュメント化やバージョン管理が欠如していることが多く、結果として長期的な「セキュリティ上の負債」となる。さらに、AIシステムはサードパーティAPIの連鎖（チェイン）に依存する場合があり、組織が直接制御できない外部の脆弱性が持ち込まれるリスクもある。ベンダー側でのAPI変更により、通知なくセキュリティ上の退行（リグレッション）が発生する可能性も否定できない。
そこでこのブログでは、以下の通り、11の実行可能な推奨事項とベストプラクティスを提示している。
1.リアルタイムのAPIインベントリの構築と維持：
クラウド、オンプレミス、コンテナ、エッジの全環境をスキャンし、APIを自動検出するツールを導入する。それらを「公開」「パートナー用」「内部用」に分類し、AIシステムに関連するものはタグ付けする。インベントリチェックをCI/CDに統合し、デプロイ前に新しいAPIが登録されるようにする。また、ネットワークやアプリの目録と定期的に照合し、シャドウAPIや放置されたAPIを特定しておく。
- AI統合APIへの「ポジティブセキュリティモデル」の採用：
OpenAPIやSwaggerの仕様書を使用して、「正当な」トラフィックの定義を明確に行う。APIゲートウェイでスキーマ検証を強制し、仕様に一致しないリクエストは拒否する。AIによる過剰なリクエストを防ぐためにレート制限を適用する。また、振る舞い検知を導入してAIエージェントの標準的なパターンを学習させ、逸脱をリアルタイムで検知する。このモデルは固定せず、APIの変更に合わせて更新し続ける生きたプロセスとして扱うこと。 - APIの認証と認可の保護：
自動期限切れ機能を持つ短命トークンを導入し、キーを定期的にローテーションする。認証情報はシークレット管理プラットフォームで安全に保管しておく。マシン・ツー・マシン（M2M）のAPIコールにはmTLS（相互認証TLS）を必須とする。OAuth 2.0のスコープやABAC（属性ベースアクセス制御）ルールを適用し、トークンの権限を制限しておく。特にAIエンドポイントでは、権限過剰を防ぐため、学習データのアップロード、推論、モデル管理などの機能ごとに権限を分離する。 - APIドリフト（仕様乖離）と不正な変更の監視：
稼働中のAPIの挙動と承認済み仕様を比較する、自動化された「ドリフト検知」をセットアップしておく。すべてのAPI仕様にバージョン管理を導入し、特にAI関連の変更にはコードレビューを義務付ける。ドリフト監視とエンドポイントのフィンガープリント（指紋認証）を組み合わせることにより、ガバナンス外で追加された新しい機能やパラメータを迅速に発見できるようにする。 - データ漏えいの検知と遮断：
APIゲートウェイにDLP（データ損失防止）ルールを実装し、外部へのレスポンスに個人識別情報（PII）、APIキー、知的財産などの機密パターンが含まれていないかスキャンする。正規表現やAIベースのコンテンツフィルタを用いて、より深い検査を行っておく。異常に大きなレスポンスペイロード、特にAIエンドポイントからのものには警告を発する。「LLMに接続されたAPI経由で財務データが流出する場合にフラグを立てる」といったコンテキストに基づくルールを適用し、漏えいが確認された場合はリアルタイムで遮断することを検討しておく。 - 敵対的AI（Adversarial AI）の脅威への備え：
プロンプトインジェクション、不正な形式のデータ、モデル回避の試みなど、悪意のある入力を用いてAPIをテストする。AIモデルに到達する前に、すべてのテキスト、ファイル、画像入力に対して無害化を行う。ポイズニング（学習データ汚染）が検知された場合に備え、安全なモデルバージョンに巻き戻すためのロールバック計画を維持しておく。開発者が敵対的なパターンを認識し、AIの出力を信頼する前に検証できるようトレーニングを行い、開発ライフサイクルに「AI安全性の視点」を組み込む。 - API主導の侵害に対するインシデントレスポンスの強化：
IP、トークンID、リクエストのフィンガープリントを含む詳細なAPIログをSIEM（セキュリティ情報イベント管理）に集約する。連絡先、封じ込め手順、復旧プロセスを詳述したAPI専用のランブックを整備しておく。APIの連鎖攻撃やAI関連の不正利用を含むシミュレーションを実施し、対応ワークフローの有効性を検証して、検知から対応までの時間を短縮する。 - DevSecOpsへのAPIセキュリティの組み込み：
CI/CDパイプラインにおいて、静的・動的テストによるAPIスキャンを自動化する。安全でないエンドポイントの導入や認証のバイパスを許すビルドは避ける。AI向けAPIを本番公開する前には、セキュリティ部門の承認を必須とする。依存関係スキャンを利用して、AI関連ライブラリにパッチが適用されていることを確認する。仕様検証やファジーテストは、定期的なレビューだけでなく、継続的インテグレーションの一部として組み込む。 - 組織内におけるAPIセキュリティ専門知識の育成：
OWASP API Top 10、AI APIのリスク、敵対的機械学習の脅威に関するターゲットを絞ったトレーニングを実施する。開発者、セキュリティエンジニア、AIスペシャリストが定期的に知見を共有する場を作っておく。セキュリティ会議やワークショップへの参加を奨励し、社内ハッカソンでAPIの攻防シナリオをシミュレートすることにより、実践的なスキルを向上させる。 - 初日からの「最小権限の原則」の適用：
すべてのAPIに対して、ロールベース（RBAC）および属性ベース（ABAC）のアクセス制御を使用する。「推論用」と「モデル学習用」でトークンを分けるなど、きめ細かなスコープを割り当てておく。機密性の高いAPIエンドポイントへのアクセスを、承認されたIP範囲やデバイスに制限する。管理者アクションには一時的な認証情報を発行し、使用後は直ちに失効させます。権限がビジネスニーズと一致しているか、定期的に監査を行っておく。 - データ・サプライチェーンの保護：
デプロイ前にすべてのAIモデル資産（アーティファクト）に署名し、検証を行っておく。すべてのデータパイプラインを保護し、転送中のデータは暗号化する。リリース前にAIライブラリを含むすべての依存関係に脆弱性がないかスキャンする。データセットとモデルのバージョン管理を徹底しておく。APIの統合においてもソフトウェア部品構成表（SBOM）の原則を適用し、すべてのコンポーネントを追跡・検証できるようにする。
APIはもはや、単なるバックエンドの利便性のためのツールではない。AI時代において、APIはデジタルビジネスの「中枢を担う動脈」である。その露出度、複雑性、そして変化の速度は劇的に増大しており、それらを標的とする脅威も同様に高度化している。継続的な可視化（継続的なモニタリング）と、適応型の「AIを考慮したセキュリティプラクティス」を組み合わせることのできるITおよびセキュリティの専門家こそが、組織を保護するための最善のポジションを確保することになるだろうと結論付けている。
米国NISTがクラウドネイティブシステムのAPI保護ガイドライン更新版を公開
米国立標準技術研究所（NIST）は、2026年3月16日、「NIST SP 800-228-upd1クラウドネイティブシステムにおけるAPI保護のためのガイドライン」（関連情報（https://csrc.nist.gov/pubs/sp/800/228/upd1/final））を公開した。本書は、2025年6月27日に公開された同ガイドライン初版（関連情報（https://csrc.nist.gov/News/2025/nist-releases-sp-800-228））の更新版である。
現代のエンタープライズITシステムは、組織のビジネスプロセスを支える統合手段として、一連のAPIに依存している。APIを安全にデプロイするためには、APIライフサイクルの各フェーズにおけるリスク要因や脆弱性の特定、および管理策や保護措置の開発が必要となる。今回の更新版ガイドラインでは、この目的を達成するために以下の側面を扱っている。
(a) APIの開発およびランタイムにおける様々なアクティビティ中のリスク要因、または脆弱性の特定と分析
(b) APIのプリランタイム（実行前）およびランタイム（実行時）の各段階において推奨される、基本的および高度な管理策と保護措置
(c) セキュリティ実務者が、リスクに基づいた段階的なアプローチで自社のAPIを保護できるよう、これらの管理策を実現するための様々な実装オプションに関する長所と短所の分析
本更新版ガイドラインは、以下のような構成になっている。
エグゼクティブ・サマリー
- はじめに
1.1. ゼロトラストとAPI：消失する境界
1.2. APIライフサイクル
1.3. 本文書の目的
1.4. 他のNIST文書との関係
1.5. 本文書の構成 - APIのリスク：脆弱性とエクスプロイト（攻撃）
2.1. 企業インベントリにおけるAPIの可視性の欠如
2.2. 認可の欠如、誤り、または不十分な認可
2.3. 認証の不備（Broken Authentication）
2.4. 制限のないリソース消費
2.4.1. 制限のないコンピューティングリソースの消費
2.4.2. 制限のない物理リソースの消費
2.5. 権限のない呼び出し元への機密情報の漏えい
2.6. 入力データの検証不十分
2.6.1. 入力バリデーション
2.6.2. 悪意のある入力からの保護
2.7. クレデンシャルの正規化：管理策のための準備段階
2.7.1. 境界をまたぐゲートウェイ
2.7.2. サービスIDはあるがユーザーIDがないリクエスト
2.7.3. ユーザーIDはあるがサービスIDがないリクエスト
2.7.4. ユーザーIDとサービスIDの両方を持つリクエスト
2.7.5. 他システムへのアウトリーチ
2.7.6. 「混乱した代理人（Confused Deputy）」問題の緩和
2.7.7. アイデンティティの正規化 - APIに推奨される管理策
3.1. プリランタイム（実行前）保護
3.1.1. 基本的なプリランタイム保護
3.1.2. 高度なプリランタイム保護
3.2. ランタイム（実行時）保護
3.2.1. 基本的なランタイム保護
3.2.2. 高度なランタイム保護 - API保護の実装パターンとトレードオフ
4.1. 中央集約型APIゲートウェイ
4.2. ハイブリッドデプロイメント
4.3. 分散型ゲートウェイパターン
4.4. 関連技術
4.4.1. Webアプリケーションファイアウォール（WAF）
4.4.2. ボット検知
4.4.3. 分散型サービス拒否（DDoS）攻撃の緩和
4.4.4. APIエンドポイント保護
4.4.5. Web Application and API Protection (WAAP) - 結論とまとめ
参考文献
附表A. API分類の体系
A.1. 公開度に基づくAPI分類
A.2. 通信パターンに基づくAPI分類
A.3. アーキテクチャスタイルまたはパターンに基づくAPI分類（APIタイプ）
A.4. データの機密性に基づくAPI分類
附表B. DevSecOpsのフェーズと関連するAPI管理策のクラス
附表C. ランタイム中に設定される制限のタイプ
附表D. リスクカテゴリ別のAPIリスク一覧
附表E. APIライフサイクル段階別の推奨セキュリティ管理策一覧
附表F. 変更履歴
APIは、企業のデジタルインフラにアプリケーションを統合する上で極めて重要な役割を果たしている。物理的・論理的なアプリケーションがいずれも高度に分散している現状を踏まえ、NISTは、APIが外部に公開されているか、あるいは企業インフラ内の他のアプリケーションによって消費されるものであるかにかかわらず、ゼロトラスト原則に基づいて運用することを推奨している。すべてのソフトウェアと同様に、APIは反復的なライフサイクル（開発、構築、デプロイ、運用）を経て、これらは大きく「プリランタイム（実行前）」と「ランタイム（実行時）」の段階に分類される。
APIデプロイメントの急激な拡散、それらが動作する異種混合のインフラ、そしてAPIが可能にする貴重な企業データへのアクセスは、これらが攻撃の標的になる背景となっている。APIセキュリティを確保するために適切な保護手段や管理策を特定するには、脆弱性とそれらを悪用する可能性のある攻撃ベクトルの詳細な分析が前提条件となる。このNIST文書では、正式なスキーマの欠如、不適切なインベントリ管理、堅牢な認証・認可サポートの欠如、リソース消費の不適切な監視、機密情報の漏洩に対する不十分な制御など、脆弱性を引き起こすさまざまなリスク要因を分析している。
本ガイドラインで推奨される管理策は、「プリランタイム保護」と「ランタイム保護」に分類されている。さらに、企業がリスクに基づいた段階的なアプローチでデジタル資産を保護できるよう、これらは「基本保護」と「高度な保護」に細分化されている。プリランタイム保護はAPI仕様のパラメータ（構文的および意味的側面）に焦点を当て、ランタイム保護はAPIのリクエストおよびレスポンス操作（暗号化された通信チャネル、適切な認証・認可など）に焦点を当てている。
このガイドラインは、各タイプの保護、デプロイ、またはパターンの利点と欠点を説明することにより、推奨される管理策を構成・適用するための実用的かつ標準的な実装オプションを提示している。NISTは、これにより、実務者が情報に基づいた意思決定を行い、自社にとって堅牢でコスト効率の高いAPIセキュリティインフラを実現することを可能にするとしている。
APIは今やビジネスの中枢を担う動脈となりつつある。従来の境界型防御に頼るのではなく、継続的な可視化とAIの特性を考慮した適応型セキュリティへのシフトが不可欠となっている。
CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司
