OWASPのエージェンティックAI成熟度モデル：CISOガイド

クラウドセキュリティアライアンス（CSA）は、IoTセキュリティやアプリケーション実装のセキュリティなどの領域で。OWASPとグローバルに連携している。

2026年7月3日、CSAラボ・スペースは、「OWASPのエージェンティックAI成熟度モデル：CISOガイド」と題するブログ記事を公開した（関連情報：OWASP’s Agentic AI Maturity Model: A CISO Guide（https://labs.cloudsecurityalliance.org/research/csa-research-note-owasp-agentic-ai-governance-maturity-v2-20/））。本ブログ記事は、OWASP GenAI Securityプロジェクトが2026年6月1日に公開した「エージェンティックAIのセキュリティとガバナンスの現状 Version 2.01」（関連情報：State of Agentic AI Security and Governance 2.01（https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/））を受けて、作成されたものである。

[要約] 「OWASPのエージェンティックAI成熟度モデル：CISOガイド」は、自律型AIのリスクが「想定」から「現実の脅威」へ変化したことを受け、CISO向けに策定されたガバナンス指針である。中心となる「企業導入成熟度モデル」では、シャドーAIから複数エージェント連携までの9段階の「導入層（Tier）」と、5段階の「ガバナンス成熟度」を掛け合わせたマトリクスを提示している。自社のセキュリティ体制が適正かを評価し、未管理AIの排除や、安全性とセキュリティの統括、継続的な監視体制の構築を求めている。

・[要点1] 安全性とセキュリティの境界を越えたエージェンティックAIの脅威
・[要点2] 導入層とガバナンス成熟度のマトリクスによるリスクの評価
・[要点3] シャドーAIの発見からマトリクスに応じた管理策の実装・継続的運用へ

本ブログ記事「OWASPのエージェンティックAI成熟度モデル：CISOガイド」は、以下のような構成になっている。

・主要なキーメッセージ
・背景
・セキュリティ分析
・推奨事項・対策
・CSAリソースとの整合性
・参考文献

安全性とセキュリティの境界を越えたエージェンティックAIの脅威

OWASPは2025年12月、100名以上の専門家の知見を統合し、エージェンティックAI特有のリスクを分類した世界初の標準体系「OWASP Top 10 for Agentic Applications（ASI01〜ASI10）」（関連情報（https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/））を策定した。これには、エージェント目標の乗っ取り（ASI01）、ツールの不正利用（ASI02）、権限濫用（ASI03）、サプライチェーンの脆弱性（ASI04）などが含まれる。最新のv2.01では、これらほぼすべてのカテゴリにおいて、机上の理論にとどまらず「実際の侵害事例」が確認されている。

従来、AIの誤作動や正常稼働時の安全性の欠如と、悪意ある境界突破によるセキュリティ侵害は、異なるチームが個別に対応してきた。しかし、AIが本番環境で自律動作する現代、この境界は崩壊している。たとえば、「プロンプト注入によってサンドボックスを突破されるケース（セキュリティ侵害）」と「曖昧な指示を誤解して本番データベースを誤削除するケース（安全性の欠如）」は異なる原因であるが、「自律動作によるインフラ破壊」という同一の結末を招く。そのため、企業はこれらを一元的に検知・対処できる単一のインシデント対応体制を構築せねばならない。また、欧米の最新法規制（DORAやNIS2等）も、定期監査ではなく「リアルタイムの継続的な監視」を前提とした迅速な報告義務を課し始めている。

そこで、OWASPの文書では、リスクを精緻に評価するため、以下の「3つの独立した次元」と「1つの横断的要素」からなる多角的なエージェント分類法を導入した。

・エージェントタイプ（何をするか）：企業内アシスタント、コーディング、対顧客、個人用、インフラ・運用管理など。
・実装パターン（どう構築されたか）：オーケストレーション（LangGraph等）、SDK軽量ライブラリ、Copilot Studioなどのローコードプラットフォーム。構成によって企業の監査可能性が異なる。
・コンポジションパターン（どう構成されているか）：単一、緊密に連携する複数エージェント、分散エージェントチェーン（MCP等）、親が子を動的生成する階層型。
・自律性レベル（横断的リスク尺度）：常に人間が承認する「有人監視」から、異常時のみ確認する「半自律」、そしてキルスイッチや予算上限、エージェント専用IDで制御する「完全自律」までのスケール。

従来の「OWASP Top 10 for Large Language Model Applications」（関連情報（https://owasp.org/www-project-top-10-for-large-language-model-applications/））では、 LLM単体のリスクが「プロンプトへの入力や出力の制御」に主眼を置かれていたのに対し、自律的に外部ツールを呼び出してアクションを実行する「エージェント型」に焦点を絞った標準体系としてく機能していることがわかる。

「導入層」と「ガバナンス成熟度」のマトリクスによるリスクの評価

このような背景を踏まえ、「セキュリティ分析」では、エージェントAIの導入レベルを示す「導入層（Adoption Tier）」と、組織の統制能力を示す「ガバナンス成熟度（Governance Maturity）」という2つの独立した評価軸を定義し、それらを交差させた「マトリクス評価モデル」および「直近1年間の具体的な脅威動向」を解説している。

2つの評価軸の定義は、以下の通りである。

・導入層（Adoption Tier）：（AT0〜AT8）
組織の意図に関わらず、信頼境界や自律性のリスクレベルに応じて9段階に分類される。
-AT0（シャドーAI）：組織の許可なく従業員が個人用AIツール等を業務利用する制御不能な状態。
-AT1〜AT3：ベンダー組み込み型のアシスタント（M365 Copilot等）や、コード実行を伴わないプラットフォーム統合、ノーコードでの市民開発エージェント。
-AT4〜AT5：権限を持ってコードを自動生成・実行するエージェント、および独自開発のカスタムエージェント。
-AT6〜AT8：外部ツール・API（MCPサーバー等）と連携するエージェント、組織内マルチエージェント、そして信頼境界を越えて連携する最上位の「連邦型（Federated）エージェント」。

・ガバナンス成熟度（Governance Maturity）：レベル0〜4）
-レベル0〜1：リスクの認識がなくその場しのぎの対応や、ガードレールのない実証実験段階。
-レベル2： ポリシーが策定され、高影響度の意思決定には「人間による介入（Human-in-the-loop）」が義務化されている状態（ただし監視は定期的）。
-レベル3〜4： リアルタイムの異常検知や即時停止スイッチ（キルスイッチ）を備えた連続的な監視体制を敷き、さらにはテレメトリ（稼働監視データ）等を用いて自動的・適応的にガードレールを調整できる最先端の状態。

次に、ガバナンス・マトリクス（評価と課題）として、これらを掛け合わせた「成熟度マトリクス」により、組織のガバナンスが「十分」か「重大な欠陥があるか」を視覚化する。

・重大な欠陥（Critical Gap）：ガバナンスがレベル0〜1の状態で、AT6（外部連携）やAT7（マルチエージェント）を運用する場合、検証や認証のないまま全ての「OWASP Agentic Top 10」リスクに晒される。
・配備禁止（Do-Not-Deploy）：最上位の連邦型（AT8）は、継続的監視と暗号学的ID管理が可能な「レベル3以上」の成熟度に達していない限り、いかなる場合も配備すべきではないと警告されている。
・シャドーAI（AT0）の扱い：管理外であるためガバナンスでの改善は不可能であり、ネットワーク検知やデータ流出防止（DLP）シグナルを用いて「検知・排除」するか、管理された層（Tier）へ移行させる必要がある。また、エージェント棚卸ツールが未整備な組織が多く、このマトリクスに基づく正確な現状把握には数四半期に及ぶ調査コストを要する点が指摘されている。

その上で、最新の脅威データと実例についてみると、過去1年で、脅威は「設計上の懸念」から「実環境での悪用」へとシフトした。

・プロンプトインジェクション：LLMがシステム指示と外部コンテンツを区別できない性質を突き、10個あるOWASP Agenticリスク（ASI）のうち6つに悪用される主要な攻撃経路となっている。
・エージェント・サプライチェーン攻撃： AT6に関連するインシデントが急増しました。例えば、悪意あるコードを仕込まれたMCPサーバー（postmark-mcp）や、開発者向けインフラ「mcp-remote」で発見された極めて深刻なリモートコード実行の脆弱性（CVE-2025-6514、CVSS 9.6）が挙げられる。
・開発エージェントの悪用： Cursor AIコードエディタの脆弱性（CVE-2026-22708）では、攻撃者がエージェントの指示を操ることにより、コマンド実行時のホワイトリスト判定を無効化できることが実証された。さらに、GitHubの構成ミスを突き、認証情報を窃取してPython Package Index（PyPI）にバックドア付きパッケージを自動配信した「意図的に兵器化された自律型ボット」による攻撃キャンペーンも確認されており、エージェント環境における自動化された敵対行為の現実味を示している。

シャドーAIの発見からマトリクスに応じた管理策の実装・継続的運用へ

さらに「推奨事項」として、組織がエージェントAIのリスクに対処するための具体的な対策を、「即時（Immediate）」、「短期（Short-Term）」、「戦略的（Strategic）」の3つのフェーズに分けて提示している。

【即時対応策】
・シャドーAI（AT0）の発見を最優先にする：管理外のエージェントAI利用を把握（棚卸し）できなければ、成熟度モデルの他のどのステップも意味をなさない。組織内にシャドーAIは「確実に存在する」という前提に立ち、ネットワークテレメトリ、データ流出防止（DLP）ツール、従業員への構造化アンケートを用いて、個人用AIアカウント、ブラウザ拡張機能、ローカル実行モデルなどの利用実態を浮き彫りにする必要がある。
・現状の自己評価とレジストリの作成：組織は0〜4の基準を用いて現在のガバナンス成熟度レベルを率直に自己評価すべきです。同時に、配備されているすべてのエージェントのレジストリ（登録簿）を作成・補完し、それぞれに「導入層（Adoption Tier）」のタグを付与する。多くの組織は、ベンダー組み込み型アシスタントから、市民開発者による自動化、未把握のカスタムコーディングエージェントまで、4〜5つの異なる層にまたがって同時に運用しているのが実態である。

【短期的な緩和策】
・マトリクスに基づく強制措置： エージェントを層（Tier）ごとに分類した後は、「成熟度マトリクス」と照らし合わせ、「重大な欠陥（critical gap）」または「デプロイ禁止（do-not-deploy）」に該当するセルを強制的な契機（フォース・ファンクション）として扱う。つまり、ガバナンス成熟度を要求されるレベルまで引き上げるか、さもなければエージェントの自律性と信頼境界を現在の能力に合わせて縮小させなければならない。
・層（Tier）に応じたリスク対策の優先順位付け： 制御のための投資は、組織がアクティブに運用している最高位の層（Tier）の主要リスクに基づいて優先順位を付ける。
-AT1〜AT4： エージェントの目標乗っ取り（Goal Hijack）、予期せぬコード実行、メモリおよびコンテキストの汚染に焦点を当てる。
-AT6以上： ASI01〜ASI10の全領域をカバーし、特にサプライチェーンの検証、エージェント間認証、連鎖的失敗の封じ込めに注力する。
・具体的なコントロールの導入：
-エージェント自身が影響を行使できるエージェント設定側ではなく、リポジトリ層でブランチ保護や必須レビュー担当者ポリシーを強制する。
-エージェントを外部ツールに接続する前に、デフォルトの資格情報や署名キーをローテーションする。
-「機密データへのアクセス」、「信頼できないコンテンツへの露出」、「外部との通信能力」の3つの特性が組み合わさったエージェントセッション（1回のプロンプトインジェクションで攻撃チェーンが完了する条件）には、必ず「人間による承認（Human-in-the-loop）」を組み込む。

【戦略的考慮事項】
・安全性とセキュリティの組織的一体化： システムが本番環境に対して自律的に動作する以上、AIの安全性（Safety）とセキュリティ（Security）を組織的に切り離すことはできない。インシデント対応、脅威モデリング、およびガバナンスの所有権は、AI安全性部門とセキュリティ運用部門で分断（同じテレメトリを異なる原因として調査）させるべきではなく、単一の責任ある構造の下に配置するべきである。
・段階的なガバナンス投資： エージェントの配備の複雑さが増すにつれて、静的でドキュメント主導の監視から、テレメトリに裏打ちされた適応型の制御ループへと、ガバナンスへの投資を意図的にシーケンス化（段階構造化）する。すべての配備を進める前に、一律で最高位の「レベル4（適応型ガバナンス）」を目指す必要はない。
・高度な配備における前提条件： AT7（マルチエージェントオーケストレーション）やAT8（連邦型配備）にアプローチする組織は、「ガバナンスレベル3の継続的監視（動作するキルスイッチや暗号学的エージェントIDを含む）」を、配備後に達成する目標ではなく、配備するための必須の前提条件として扱う必要がある。レポートが明確に指摘している通り、連邦型の信頼関係は、低い成熟度レベルでは統制不可能なためである。

最後に、「CSAのリソースとの整合性」では、OWASPのレポートとクラウドセキュリティアライアンス（CSA）が提供する各種フレームワークとの相互補完関係について、以下のように説明している。

・脅威モデリング（MAESTRO）：OWASPは、エージェントのリスクが単一のレイヤーではなく、モデルの推論能力、ツール、メモリ、エージェント間の信頼関係の相互作用から生じるという点で、CSAの「MAESTRO」フレームワーク等と結論が一致したと明記している。組織はMAESTROの7つの階層分解（基盤モデル、データ運用など）を用いることで、OWASPマトリクスで「欠陥」とされたセルを具体的なアーキテクチャの修復策へと落とし込める。
・管理基準（AI Controls Matrix）： OWASPモデルのAT4〜AT8層で求められる資格情報のローテーション、IDのスコープ定義、サプライチェーン検証などの管理策は、CSAの「AI管理マトリクス」に直接マッピングされる。これにより、ノンヒューマンID管理やサードパーティAI統合の防御基準を構築できる。
・ゼロトラスト（Zero Trust）：連邦型配備（AT8等）において相互認証や暗号学的信頼を必須とするOWASPの主張は、ネットワーク上の暗黙の信頼を否定するCSAの「ゼロトラスト」ガイダンスを、エージェント間の信頼境界（AT6〜AT8）に適用したものである。
・共通語彙：レポートの基盤となる「ASI01〜ASI10」の分類は「OWASP Top 10 for Agentic Applications」そのものであり、CSAのインシデント研究でも共通のリファレンスとして一貫して使用されている。

前述の通り、「プロンプト注入によってサンドボックスを突破されるケース（セキュリティ侵害）」と「曖昧な指示を誤解して本番データベースを誤削除するケース（安全性の欠如）」は異なる原因であるが、「自律動作によるインフラ破壊」という同一の結末を招く。すなわち、エージェントがシステムへの書き込み権限（ファイル削除、API実行など）を持つことにより、「悪意ある攻撃」と「AIの仕様上の誤解」がインフラに与える実質的な被害は同じになることを意味している。

これを受けて、インシデント対応チーム（CSIRTなど）を分断せず、テレメトリ（監視データ）を一元化して「単一の責任構造」に統合するという推奨事項は、実務において非常に現実的かつ先進的なアプローチとなっている。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

サイバーレジリエンス法（CRA）が企業の脆弱性管理に及ぼす影響

クラウドセキュリティアライアンス（CSA）は、欧州における「クラウドコンピューティングのためのセキュリティガイダンス」や「クラウドコントロールマトリックス（CSA CCM）」の実装・啓発活動を通じて、欧州連合サイバーセキュリティ庁（ENISA）と連携してきた。

2026年5月18日、CSAラボ・スペースは、「ENISA CVE Root：多国籍企業における二元的な脆弱性ガバナンスの構築」と題するブログ記事を公開した（関連情報：ENISA CVE Root: Dual Vulnerability Governance for Multinationals（ https://labs.cloudsecurityalliance.org/research/csa-research-note-enisa-cve-root-dual-governance-20260518-cs/））。CSAラボ・スペースは、コミュニティ内のメンバーやグループが、クラウドセキュリティアライアンス（CSA）と連携して展開したい独立したプロジェクトのために用意されたスペースである。

[要約] 2025年11月、ENISAは、脆弱性識別子「CVE」のプログラムにおいて「管理権限組織（Root）」に昇格し、欧州独自の脆弱性統治レイヤーを確立した。これにより多国籍企業は、従来の米国主導（MITRE/NIST）に加えて欧州主導（ENISA）の「二元的な脆弱性ガバナンス」への対応を迫られる。特に、2026年9月11日に先行適用開始となる「欧州サイバーレジリエンス法（CRA）」により、対象製品のメーカーは悪用された脆弱性を24時間以内にENISAの単一報告プラットフォーム（SRP）へ報告する義務が生じる。企業は、NISTとENISA双方のデータベース（EUVD）を相互参照し、異なる報告期限や脅威コンテキストを調整できる新たな運用ワークフローの構築が必要である。

・[要点1] ENISAの管理権限組織昇格による二元管理の発生
・[要点2] 欧州サイバーレジリエンス法（CRA）による厳格な報告義務
・[要点3] 運用ワークフローとデータベースの統合の必要性

ENISAのCVE管理権限組織への昇格がもたらす変化

本ブログ記事は、以下のような構成になっている。

・背景
・セキュリティ分析
-欧州における並行的な脆弱性管理権限
-欧州脆弱性データベース（EUVD）：設計の意図と現在の限界
-CRA（サイバーレジリエンス法）の報告義務：動かせない期限
-文化面および運用面における摩擦
・推奨事項
-即座に講ずべきアクション（即時対応）
-短期的な緩和策
-戦略的検討事項
・CSAリソースとの整合
・参考文献

本ブログ記事によると、従来のCVEプログラムは、クラウドセキュリティアライアンスと連携している米国MITREを頂点とする階層構造であり、EUの規制や制度的枠組みを反映していなかったため、米欧双方の規制に対応する企業にとってガバナンスの不一致が課題となっていたとしている。

このような状況に対しENISAは、2024年1月、まず欧州のコンピュータセキュリティインシデント対応チーム（CSIRT）等が発見・報告した脆弱性を対象とするCVE採番機関（CNA）に認定された。並行してNIS2指令に基づき、米国立脆弱性データベース（NVD）を補完する「欧州脆弱性データベース（EUVD）」の開発を進め、2025年5月に完全運用を開始して技術的基盤を整えた。そして2025年11月、ENISAは単なる採番機関を超え、傘下のCNAを育成・監督する「Root CNA」へと昇格した。これにより、欧州の国家機関やCSIRTネットワークに属するCNAの監督権限がMITREからENISAへと移管され、欧州独自の脆弱性管理体制が確立された。

さらにENISAは、意思決定機関であるCVEプログラム理事会への参画を見据え、最高位の「TL-Root CNA」への昇格も視野に入れている。この構造的変化は、MITREが全体統括を維持しつつも、EU市場で活動する多国籍企業やグローバルITベンダーの脆弱性管理プロセスに直接的な影響を与えている。

欧米双方で事業展開する企業に求められる脆弱性の二元管理

CVEエコシステムの権限階層は、フラットではなく「階層レイヤー構造」と捉えるのが正確である。最上位のTL-Rootである米国MITREが全体を統括し、その下にCISAやJPCERT/CC、そして新たに加わったENISAなどの「プログラムレベルRoot」が位置し、各ドメインやベンダー固有の「CNA」、さらに「Sub-CNA」を監督する仕組みによって、グローバルな規模拡大と識別子の一貫管理を両立している。

ENISAのRoot昇格は、この構造に欧州独自のレイヤーを挿入した。これにより、ENISAのスコープ内にある欧州のCNA（全510組織中90以上が該当）は、MITREからENISA Rootへ自発的に移管できるようになった。すでに数組織が移行を完了または新規加入しており、今後移行が進むにつれ、各CNAのエスカレーションや調整ワークフローは、MITREのデフォルト基準ではなく、欧州の規制カレンダーやENISAの運用ペースに同期していくと予想される。

このような変化は多国籍企業に「構造的な非対称性」をもたらす。米欧双方に導入されている製品で脆弱性が発生した場合、CVE識別子自体は共通であるものの、管理プロセスはMITRE主導とENISA主導という2つの異なるガバナンスチェーンに同時並行で組み込まれる。結果として、企業の主要拠点の位置や影響を受ける加盟国に応じて、開示義務、メタデータの付与、法的な規制通知などの対応が二分化されることになる。

ENISAが開発した「欧州脆弱性データベース（EUVD）」は、米国のNIST NVDと同様にCVEレコードを集約し、CVSSスコアや欧州独自の脅威インテリジェンス等を付加する仕組みである。NIS2指令下の組織にとっては、EUの通知義務やENISAの既知の悪用された脆弱性（KEV）リストに直結する規制上の公式な基準となる。

しかし、現在の運用上、EUVDは実績のあるグローバルな情報源に比べ大幅な網羅性の遅れが指摘されている。本ブログの分析によれば、主要APIにおいてNVD等より5万件以上もCVEデータが不足しており、企業のセキュリティチームが単一の情報源として依存するには不十分だと指摘されている。そのため、EUVDが成熟するまでは、NVDとEUVDの双方を照合する「デュアル・データベースモデル」の採用が実務的に評価されている。

この二元管理は運用に複雑性をもたらすことになる。欧州の研究者が報告した脆弱性はNVDと異なるメタデータが付与される可能性があり、欧州特有の脅威を反映した悪用フラグは米CISAのKEVカタログとも乖離する可能性がある。結果として、NVDで低優先度とされる脆弱性が、EUVDでは欧州インフラへの攻撃を理由に高緊急度と評価される事態も起こるため、セキュリティチームはこれら乖離したシグナルを統合・調整できるツールやプロセスを備える必要があるとしている。

欧州サイバーレジリエンス法（CRA）とNIS2による厳格な報告義務

しかしながら、欧米双方で事業展開する企業にとって最も差し迫った課題は、ENISAのCVE Root昇格そのものよりも、同機関が運営を担う欧州サイバーレジリエンス法（CRA）の通知フレームワークへの対応である。CRA第14条に基づき、EU市場にハードウェア、ソフトウェア、接続サービスなどの「デジタル要素を持つ製品」を販売する製造企業は、2026年9月11日より、以下のような期限設定で、悪用された脆弱性や重大な影響を及ぼすセキュリティインシデントを報告する法的義務を負う。

・24時間以内: 悪用された脆弱性を覚知した後の「早期警戒通知」
・72時間以内: 詳細を網羅した「完全な通知」
・14日以内: 是正措置（パッチ等）が利用可能になった後の「最終報告」

さらにENISAは、これらの通知を受け付ける「単一報告プラットフォーム（SRP）」を構築・運営する任務を負っている。提出された報告は、製造元がEU域内に置く主要拠点の国における「国家CSIRTコーディネーター」およびENISAに、同時で共有される。

報告を受け取った国家CSIRTは、その製品が流通している他のEU加盟国のCSIRTや、関連する市場監視当局に対して遅滞なく情報を共有・分散する義務がある。ただし、特に機微な報告についてはセキュリティ上の理由から初期の共有を保留することが認められており、その場合もENISAに通知され、リスクがシステム全体に及ぶと判断されれば、ENISAの権限でより広範な共有を推奨することができる。

EU域内に「製品の製造基盤」と「自社のインフラ」の両方を持つ多国籍企業にとって、CRAの報告義務と、並行して走る「ネットワークおよび情報システム指令2（NIS2指令）」（第23条）の要件との相互作用は、運用の複雑さをさらに増大させることになる。

NIS2では、重要主体に対し、重大なインシデントの発生から24時間以内の初期報告と72時間以内の包括的評価を求めており、このタイムラインはCRAの製品脆弱性報告の時計とほぼ重なり合う。企業は発生した事象が、CRA（製品レベルの脆弱性、SRP経由でENISAへ）に該当するのか、NIS2（組織レベルのインシデント、加盟国の指定CSIRT経由）に該当するのか、あるいはその双方に同時に該当するのかを即座に判断し、どちらの報告チェーンも遅延させない仕組みを確立しなければならない。

これら2つの法的枠組みは、以下の通り、それぞれ独立していながらも相互に補完し合う強力なペナルティ構造を敷いている。

・NIS2指令：重要主体に対し、最高1,000万ユーロ、またはグローバル年間総売上高の2%のいずれか高い方の制裁金。
・サイバーレジリエンス法（CRA）：核心的義務（第14条の報告義務を含む）に違反した場合、最高1,500万ユーロ、またはグローバル年間総売上高の2.5%のいずれか高い方の制裁金。

この極めて高いペナルティの上限は、欧州一般データ保護規則（GDPR）の構造を模したものであり、EUの立法府が脆弱性の開示遵守を、単なる管理上の手続きではなく、最高レベルの規制義務として重く捉えている明確なシグナルと言えるとしている。

文化面および運用面の摩擦への対応がグローバル脆弱性管理の課題に

ENISAの権限昇格は、単なる組織構造や法規制の次元を超えて、EUが「脆弱性開示」という行為そのものをどのように捉えるかという、現在進行形の大きな文化的シフト（意識改革）を反映している。これに伴い、EU市場に関わるすべての組織は、その姿勢の根本的な転換を迫られることになる。

これまで多くの伝統的な産業セクターにおいて、脆弱性の開示は「防御的」あるいは「消極的」に扱われてきた。企業の法務チームは、企業のレピュテーションリスクや法的責任・損害賠償リスクへの懸念から、セキュリティ上の欠陥を公に認めることに対して極めて慎重であり、結果として形式的な脆弱性開示ポリシー（VDP）すら存在しないか、あっても形骸化しているケースが一般的であった。

しかし、NIS2指令および欧州サイバーレジリエンス法（CRA）の登場によって、この構図は一変した。これらの法制により、「協調的な脆弱性開示（CVD）」を、単なる推奨されるベストプラクティスから「明確な法的義務」へと昇格させた。特にCRAにおいては、附属書I（Annex I）に規定される必須のサイバーセキュリティ要件の一部として、製品の製造元に対し「協調的な脆弱性開示に関するポリシーを策定し、確実に実施・強制すること」を明確に義務付けている。

ENISAが2026年4月に発表した見解（関連情報：New CVE Numbering Authorities Under ENISA Root（https://www.enisa.europa.eu/news/new-cve-numbering-authorities-under-enisa-root））の中でも、この文化的・組織的な移行には相応の時間がかかることが認められている。特に、これまでセキュリティ研究者（ホワイトハッカーなど）のコミュニティと密接な関わりを持ってこなかったセクターにおいては、そのギャップが顕著になっている。具体的には、金融サービス、医療、産業用制御システム（ICS/OT環境）、そしてその他の重要インフラ分野が該当する。これらのセクターに属する企業の多くは、NIS2指令において「重要主体（必須または重要な組織）」に指定されており、インフラ運用者としての義務を負うと同時に、製品のサプライヤーとしてCRAの適用も受けるという、二重の網をかけられた状態にある。

これらの組織にとって、CRAが求める運用上の開示要件を満たすためには、単にITシステムや手順書をアップデートするだけでは不十分である。社内におけるセキュリティインシデントの上層部への報告や承認のプロセス自体に、本質的な変革を起こす必要がある。

従来のトリアージ（優先度判定）やインシデント対応のワークフローでは、外部への一切の通知・開示を行う前に、まず法務チームや広報（PR）チームによる綿密なリーガルチェックおよび対外コミュニケーションのレビューを挟むことが一般的であり、ここに多くの時間が費やされていた。しかしCRAの体制下では、脆弱性を覚知してから「24時間以内」に、ENISAのプラットフォームへ第一報（早期警戒通知）を送信完了していなければならない。

したがって企業は、従来の「リスクを隠蔽・遅延させる承認プロセス」を完全に排し、法的リスクを管理しつつも、24時間の時間制限内に自動的かつ確実にENISAへの通知を出力できる、極めて迅速でダイレクトな内部トリアージ体制を再設計することが求められるとしている。

欧米進出企業の運用ワークフローと脆弱性データベースの統合に向けて

最後に本ブログ記事では、多国籍企業が2026年9月の欧州サイバーレジリエンス法（CRA）先行適用までに講ずべき対策と戦略の推奨事項として、以下のように提示している。

・即時対応策
EU市場に上市している全製品の棚卸しを行い、SaaSなどの対象範囲を確認する。報告先となる国家CSIRTを決定するため、EU域内の「主要拠点」を早期に確定させる必要がある。また、脆弱性管理ツールを改修し、網羅性に遅れのあるEUVDとNVDの双方を相互参照して、データの乖離を検知できる体制を整える。

・短期的な緩和策
24時間以内の早期警戒通知に対応できるよう、従来の数日かかる承認フローを排したCRA準拠の協調的脆弱性開示ポリシー（VDP）を策定する。インシデント対応の手順書を更新し、NIS2（組織レベル）とCRA（製品レベル）の報告基準を明確に区別させ、法務や広報、セキュリティ部門間で承認権限を事前に合意しておく。また、欧州ベンダーのCNAがENISA Rootへ移管するかどうかも注視する。

・戦略的検討事項
EUVDの成長に伴い依存度を高める計画を策定する。さらに、ENISAが最高位の「TL-Root」へ昇格すれば、世界の脆弱性管理の基準自体が欧州主導で変化する可能性があるため、長期的な動向を追跡する必要がある。

なお、ENISAのCVE Root昇格と欧州の脆弱性ガバナンスの拡大に関しては、クラウドセキュリティアライアンスの基盤的なフレームワークと直接的に連動している。具体的には、以下の通りである。

・AIコントロールマトリクス（AICM）：
欧州サイバーレジリエンス法（CRA）の適用で新たなコンプライアンスの課題が生じやすい「AI製品やサービス」を対象に、サプライチェーンの整合性や脆弱性管理の管理策を提供する。脆弱性開示義務がAIモデルやインフラに拡大する中、AICMはCRAの技術要件とCSAのAIセキュリティ基準の双方を満たしているかを監査する構造的基盤となる。

・STAR（Security Trust Assurance and Risk）プログラム：
NIS2指令に準拠した管理策をカバーしており、CRAの適合性を証明する第三者保証メカニズムとしての活用が評価されている。企業はSTARレジストリを参照することで、CRA第14条の開示要件を満たす脆弱性管理の成熟度を確認できる。

・ゼロトラストガイダンス：
「侵入を前提（Assume Breach）」とし、継続的な検証を行う原則は、CRAが求める「後手に回らない積極的な脆弱性監視」に合致し、24時間・72時間以内の迅速な報告の実現を支える。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

法規制対応から戦略投資への転換点となるEUクラウド・AI開発法(CADA）

クラウドサービスに対する地政学的リスクや低減策が議論となる中、CSA支部がある国・地域では、様々な取り組みが行われている。CSAジャパン関西支部では、欧州やアジア・太平洋地域、カナダなど、米国以外のCSA支部が密接に取り組んでいる最新情報を取り上げていく。

[要約] 欧州委員会は2026年6月、米系へのクラウド集中リスク解消とデジタル自律性の強化に向け、半導体法2.0やクラウド・AI開発法(CADA）など4つの柱からなる「技術主権パッケージ」を発表した。CADAでは政府調達等に4段階の主権評価フレームワークを導入し、外資企業に対し構造的な障壁を課す方針である。これら一連のEU規制は、サプライチェーンを通じて民間企業へ連鎖的に波及している。グローバルITガバナンスが分断する中、企業にはマルチクラウドの確保やリスク可視化、暗号アジリティの組み込みといった、デジタル・レジリエンス確立への戦略的転換が求められている。

・[要点1] 欧州委員会による「技術主権パッケージ」の発表と4つの柱
・[要点2] クラウド・AI開発法（CADA）」の核心と4段階の欧州認証フレームワーク
・[要点3]「コンプライアンスの連鎖（カスケード）

欧州委員会が提案する「技術主権パッケージ」とは？

2026年6月3日、欧州委員会は、半導体、人工知能（AI）、クラウド、オープンソースにおいて、欧州のデジタルの自律性とレジリエンスを強化する「技術主権パッケージ」提案を発表した（関連情報（European Commission, ”Commission proposes tech sovereignty package to strengthen Europe’s digital autonomy and resilience（https://digital-strategy.ec.europa.eu/en/news/commission-proposes-tech-sovereignty-package-strengthen-europes-digital-autonomy-and-resilience））。

このパッケージには、「半導体法2.0（Chips Act 2.0）」と「クラウド・AI開発法（Cloud and AI Development Act）」の2つの法案に加え、「オープンソース戦略」、および「エネルギー分野におけるデジタル化とAIのための戦略的ロードマップ」が含まれている。

「半導体法2.0」提案は、域内の半導体産業を活性化し、最先端チップの生産能力を強化するための新たな施策である。従来の半導体法の進捗を土台に、欧州が強みを持つ汎用チップ分野を補強しつつ、次世代の半導体技術の開発を進める。これにより、AI普及に伴う深刻な域外依存やサプライチェーンの脆弱性を解消し、欧州のデジタルの自律性とインフラの安全性を高めることを目指している。

次に「クラウド・AI開発法（CADA）」提案は、域内のクラウドとAIのエコシステム、投資、およびインフラを強化するための法案である。AI普及に伴う急激な需要増に対応するため、データセンターの設置認可手続きを簡素化・加速させ、今後5〜7年で域内の処理能力を少なくとも3倍に拡大することを目指す。さらに、EU独自の主権評価フレームワーク（4つの保証レベル）を導入することで、域外プロバイダーへの過度な依存を減らし、重要セクターにおけるデジタルの自律性と安全性を確立するとしている。

さらに、「EUオープンソース戦略」は、域内のデジタルインフラにおけるオープンソースソフトウェア（OSS）の役割を強化するためのロードマップである。本戦略は、重要公共インフラや行政システムへのOSSの導入を加速し、透明性とサイバーセキュリティを向上させるとともに、EU独自のデジタルエコシステムの自律性を高めることを目指している。また、オープン開発コミュニティへの支援を通じて、ベンダーロックインを防ぎ、EU域外の技術への過度な依存を減らしてイノベーションを促進するとしている。

また、「エネルギー分野におけるデジタル化とAIのための戦略的ロードマップ」は、脱炭素化の加速とエネルギー効率の向上を目指す施策である。AIやデジタル技術をスマートグリッドや再生可能エネルギー分野に大規模に導入し、需給バランスの最適化や運用の効率化を図る。また、急増するデータセンターの電力需要に対応するため、事業者や行政、エネルギー関係者による三者間合意（EUモデル）の枠組みを構築し、持続可能なエネルギーシステムへの統合と欧州のクリーンエネルギー転換を推進するとしている。

これら4つの施策は一体となり、欧州が「AI大陸」になるという野望を支え、デジタルの自律性を強化し、より持続可能なデジタルの未来を築くことに貢献するとしている。また、EUの企業、市民、そして行政機関にとって、コアテクノロジーにおける選択肢を広げることにもつながるという。

クラウド・AI開発法（CADA）と欧州認証フレームワーク

このパッケージが発表された直後の2026年6月5日、CSAラボ・スペースは、「欧州の技術主権：クラウド集中リスクとコンプライアンスの連鎖」と題するブログ記事を公開した（関連情報：EU Tech Sovereignty: Cloud Concentration Risk and the Compliance Cascade （https://labs.cloudsecurityalliance.org/research/eu-tech-sovereignty-cloud-ai-enterprise-risk-v1-0-csa-styled/））。参考までにCSAラボ・スペースは、コミュニティ内のメンバーやグループが、クラウドセキュリティアライアンス（CSA）と連携して展開したい独立したプロジェクトのために用意されたスペースである。

本ブログ記事において、EUは、域内のデータ、インフラ、AI技術が米国のハイパースケーラー（AWS、Microsoft、Googleなど）に過度に依存している現状を「国家・域内の安全保障、および経済的自立における重大なリスク（クラウド集中リスク）」と捉えているとしている。

このクラウド集中リスクに対応するため、EUは一般データ保護規則（GDPR）を皮切りに、DORA（デジタルオペレーショナルレジリエンス法（DORA）、データ法（Data Act）、欧州クラウド認証スキーム(EUCS）、EU AI法などを次々と法制化した。これらの規制は、単に直接の対象企業（金融機関やテック企業など）に留まらず、そのサプライチェーン全体、ひいてはグローバルで事業を展開するすべてのエンタープライズ企業へと連鎖的に波及している。本ブログでは、この現象を「コンプライアンス・カスケード（コンプライアンスの連鎖）」と定義し、企業が負うべき新たなリスクと、その防衛策を提唱している。

欧州委員会の「技術主権パッケージ」のうち、クラウド・AI開発法（CADA）提案では、公共部門、重要インフラ事業者、および公的契約に基づいてサービスを提供する事業者を対象に、クラウドおよびAIの主権を評価する厳格なガバナンスフレームワークを創設している。その最大の技術的特徴は、以下の通り、データの機密性とリスクに応じてクラウドサービスを分類する「4段階の欧州認証（Union Assurance）フレームワーク」の導入である。

[認証レベル 1]
主な要求事項：インフラがEU域内に所在、データレジデンシーがEU域内であること。
適用ユースケース例：一般的な公的行政、非機密ワークロード。
[認証レベル 2]
主な要求事項：第三国（米国など）の法的管轄権からの独立、ソフトウェアサプライチェーンの透明性。
適用ユースケース例： 機密性の高い行政データ、医療記録、金融データ。
[認証レベル 3]
主な要求事項：EUによる所有および支配、従事人員の国籍（市民権）要件、高度なガバナンス。
適用ユースケース例：国家安全保障に隣接する機能、国防関連の調達。
[認証レベル 4]
主な要求事項： ソフトウェアサプライチェーンの完全な透明性、第三国からのいかなる干渉も排除。
適用ユースケース例：重要な主権機能、機密（Classified）と同等の国家ワークロード。

加盟国やEU機関は、それぞれのユースケースに応じて必要な認証レベルを特定するリスク評価が義務付けられることになる。特にレベル3およびレベル4においては、米国CLOUD法などの管轄下にある米国系ハイパースケーラーに対し、契約上の工夫だけでは解決できない構造的な障壁（EUによる所有・支配、人員の国籍制限など）を課している点が極めて重要である。

なお、このCADAは、欧州サイバーセキュリティ庁（ENISA）が主導していた「欧州クラウドサービスサイバーセキュリティ認証制度（EUCS）」を事実上上書き・吸収する形で機能する。従来のEUCSでは産業界からの圧力で削除された「主権要件（EU本社の義務付けなど）」が、CADAによって政府調達の一次要件として実質的に復活した形となる。

クラウド・AI開発法（CADA）と複雑に絡み合うEU法規制への対応

本ブログ記事では、集中リスクの排除と主権確保のために機能する、以下のようなEU法規制を挙げている。

・デジタルオペレーショナルレジリエンス法（DORA）：
金融セクターに対し、情報通信技術（ICT）障害への耐性を義務化する。サードパーティ（クラウド側）の集中リスク評価を徹底させる。
・データ法：
クラウド事業者間の「乗り換え」の障害となるデータロックインを排除する。解約手数料の撤廃や相互運用性の確保を義務化する。
・欧州クラウド認証スキーム（EUCS）：
クラウドの安全性評価基準。特に高いセキュリティレベルにおいては、外国籍企業のインフラへのアクセス制限や、データのEU域内保管が議論の中心となる。
・EU AI法：
生成AIやハイリスクAIシステムに対する透明性と安全性の確保を義務化する。AIを稼働させる基盤クラウドの監査も必要となる。

本ブログでは、コンプライアンスの連鎖の観点から、特に民間企業に対する影響として、以下のような点を挙げている。

・データ法との連動：2025年9月に発効したデータ法が定める「クラウド切り替え（ベンダーロックインの解消）義務」を補完し、ベンダー移行の流動性を高める。
・ネットワーク・情報システムのセキュリティに関する指令2（NIS2）およびデジタルオペレーショナルレジリエンス法（DORA）：重要インフラ（NIS2）や金融セクター（DORA）に課されているICTサードパーティリスク管理において、クラウドベンダーの「主権リスク（外資依存リスク）」が企業の取締役会やリスク委員会で直接的な監査対象として浮上している。
・AIモデルの規制：EU域外でトレーニングやホスティングが行われたフロンティアAIモデルに対して、データ移転やサプライチェーンの観点から新たな制限が課されるリスクが生じている。

これらにより、民間企業であっても公共セクターにシステムを納品するサプライチェーン企業、規制対象セクター（金融・医療など）の企業、公的資金による研究プログラムに参加する企業などは、否応なしにCADA準拠の欧州系ローカルクラウドへの移行や、アーキテクチャの見直しを迫られることになるとしている。
欧州で事業展開する日本企業の課題はサードパーティベンダーリスク管理

本ブログ記事では、これからのグローバルITガバナンスが「米国、欧州、アジア太平洋（APAC）の3つの互換性のないコンプライアンス領域」に分断していくと警告している。この大転換に対し、企業のCISO（最高情報セキュリティ責任者）や取締役会は、以下のような戦略的な転換を直ちに行う必要があるとしている。

・マルチクラウド相互運用性の確保：
特定のクラウドにロックインされることを防ぐため、クラウドネイティブ技術（アプリケーションコンテナなど）を活用し、別のクラウドやオンプレミス環境へ迅速にワークロードを移行・分散できるポータビリティを重視した設計を採用する。
・サードパーティおよびフォースパーティ・リスクの可視化：
自社が使っているサードパーティベンダーだけでなく、そのベンダーが裏側で依存しているクラウド基盤のフォースパーティベンダーがどこなのかを棚卸しし、集中リスクを特定・評価する。
・デジタルインフラのローカライズ（ソブリン・クラウドの活用）：
EU域内のデータ主権を完全に満たすため、欧州ローカルのプロバイダーや、米ハイパースケーラーが提供する「ソブリン・クラウド」の導入を適材適所で検討する。
・「暗号アジリティ（俊敏性）」の組み込み
データの暗号化だけでなく、法規制や地政学的要件の変化に応じて、データの保管場所や暗号鍵の管理権限（BYOK: Bring Your Own Keyなど）を企業自身が完全にコントロールできるようにする。

このようなEUの「技術主権」への動きは、一過性の政治トレンドではなく、世界のクラウド利用における不可逆的な構造シフトだとしている。企業は、規制対応を単なる「法務上の手続き（コスト）」として捉えるのではなく、不確実なグローバル市場を生き抜くための「競争優位性とデジタル・レジリエンスの確立（戦略投資）」へとマインドセットを転換することが求められているとしている。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

前回のアプリケーションセキュリティ編(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を特定しておく。

2. AI統合APIへの「ポジティブセキュリティモデル」の採用：
   OpenAPIやSwaggerの仕様書を使用して、「正当な」トラフィックの定義を明確に行う。APIゲートウェイでスキーマ検証を強制し、仕様に一致しないリクエストは拒否する。AIによる過剰なリクエストを防ぐためにレート制限を適用する。また、振る舞い検知を導入してAIエージェントの標準的なパターンを学習させ、逸脱をリアルタイムで検知する。このモデルは固定せず、APIの変更に合わせて更新し続ける生きたプロセスとして扱うこと。
3. APIの認証と認可の保護：
   自動期限切れ機能を持つ短命トークンを導入し、キーを定期的にローテーションする。認証情報はシークレット管理プラットフォームで安全に保管しておく。マシン・ツー・マシン（M2M）のAPIコールにはmTLS（相互認証TLS）を必須とする。OAuth 2.0のスコープやABAC（属性ベースアクセス制御）ルールを適用し、トークンの権限を制限しておく。特にAIエンドポイントでは、権限過剰を防ぐため、学習データのアップロード、推論、モデル管理などの機能ごとに権限を分離する。
4. APIドリフト（仕様乖離）と不正な変更の監視：
   稼働中のAPIの挙動と承認済み仕様を比較する、自動化された「ドリフト検知」をセットアップしておく。すべてのAPI仕様にバージョン管理を導入し、特にAI関連の変更にはコードレビューを義務付ける。ドリフト監視とエンドポイントのフィンガープリント（指紋認証）を組み合わせることにより、ガバナンス外で追加された新しい機能やパラメータを迅速に発見できるようにする。
5. データ漏えいの検知と遮断：
   APIゲートウェイにDLP（データ損失防止）ルールを実装し、外部へのレスポンスに個人識別情報（PII）、APIキー、知的財産などの機密パターンが含まれていないかスキャンする。正規表現やAIベースのコンテンツフィルタを用いて、より深い検査を行っておく。異常に大きなレスポンスペイロード、特にAIエンドポイントからのものには警告を発する。「LLMに接続されたAPI経由で財務データが流出する場合にフラグを立てる」といったコンテキストに基づくルールを適用し、漏えいが確認された場合はリアルタイムで遮断することを検討しておく。
6. 敵対的AI（Adversarial AI）の脅威への備え：
   プロンプトインジェクション、不正な形式のデータ、モデル回避の試みなど、悪意のある入力を用いてAPIをテストする。AIモデルに到達する前に、すべてのテキスト、ファイル、画像入力に対して無害化を行う。ポイズニング（学習データ汚染）が検知された場合に備え、安全なモデルバージョンに巻き戻すためのロールバック計画を維持しておく。開発者が敵対的なパターンを認識し、AIの出力を信頼する前に検証できるようトレーニングを行い、開発ライフサイクルに「AI安全性の視点」を組み込む。
7. API主導の侵害に対するインシデントレスポンスの強化：
   IP、トークンID、リクエストのフィンガープリントを含む詳細なAPIログをSIEM（セキュリティ情報イベント管理）に集約する。連絡先、封じ込め手順、復旧プロセスを詳述したAPI専用のランブックを整備しておく。APIの連鎖攻撃やAI関連の不正利用を含むシミュレーションを実施し、対応ワークフローの有効性を検証して、検知から対応までの時間を短縮する。
8. DevSecOpsへのAPIセキュリティの組み込み：
   CI/CDパイプラインにおいて、静的・動的テストによるAPIスキャンを自動化する。安全でないエンドポイントの導入や認証のバイパスを許すビルドは避ける。AI向けAPIを本番公開する前には、セキュリティ部門の承認を必須とする。依存関係スキャンを利用して、AI関連ライブラリにパッチが適用されていることを確認する。仕様検証やファジーテストは、定期的なレビューだけでなく、継続的インテグレーションの一部として組み込む。
9. 組織内におけるAPIセキュリティ専門知識の育成：
   OWASP API Top 10、AI APIのリスク、敵対的機械学習の脅威に関するターゲットを絞ったトレーニングを実施する。開発者、セキュリティエンジニア、AIスペシャリストが定期的に知見を共有する場を作っておく。セキュリティ会議やワークショップへの参加を奨励し、社内ハッカソンでAPIの攻防シナリオをシミュレートすることにより、実践的なスキルを向上させる。
10. 初日からの「最小権限の原則」の適用：
    すべてのAPIに対して、ロールベース（RBAC）および属性ベース（ABAC）のアクセス制御を使用する。「推論用」と「モデル学習用」でトークンを分けるなど、きめ細かなスコープを割り当てておく。機密性の高いAPIエンドポイントへのアクセスを、承認されたIP範囲やデバイスに制限する。管理者アクションには一時的な認証情報を発行し、使用後は直ちに失効させます。権限がビジネスニーズと一致しているか、定期的に監査を行っておく。
11. データ・サプライチェーンの保護：
    デプロイ前にすべての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.1. ゼロトラストとAPI：消失する境界
   1.2. APIライフサイクル
   1.3. 本文書の目的
   1.4. 他のNIST文書との関係
   1.5. 本文書の構成
2. 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. アイデンティティの正規化
3. APIに推奨される管理策
   3.1. プリランタイム（実行前）保護
   3.1.1. 基本的なプリランタイム保護
   3.1.2. 高度なプリランタイム保護
   3.2. ランタイム（実行時）保護
   3.2.1. 基本的なランタイム保護
   3.2.2. 高度なランタイム保護
4. 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)
5. 結論とまとめ
   参考文献
   附表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リーダー
笹原英司

CSAジャパン関西支部では、「海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(1)」（https://cloudsecurityalliance.jp/newblog/2025/07/14/smb_aisec_1/）および「海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(2)」（https://cloudsecurityalliance.jp/newblog/2025/09/16/smb_aisec_2/）で、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発された人工知能（AI）セキュリティ固有のガイドを紹介したが、今回は、エージェンティックAIのガバナンスについて取り上げる。

シンガポール政府が世界初のエージェンティックAIガバナンス文書を発行

2026年1月19日、シンガポール情報通信メディア開発庁（IMDA）は、「エージェンティックAI向けモデルAIガバナンスフレームワーク」（https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf）を公開している。現時点で、エージェンティックAIに特化した包括的なガバナンス文書を発行したケースとしては、本書が世界初となる。

本文書は、エージェンティックAIの導入に伴う新たなリスクに対して、組織が信頼性と安全性を確保しながら活用できるように支援することを目的としており、以下のような構成になっている。

エグゼクティブ・サマリー

1. エージェンティックAIの紹介
   1.1 エージェンティックAIとは？
    1.1.1 エージェントの中核構成要素
    1.1.2 マルチエージェント構成
    1.1.3 エージェント設計がその限界と能力に与える影響
   1.2 エージェンティックAIのリスク
    1.2.1 リスクの発生源
    1.2.2 リスクの種類
2. エージェンティックAI向けモデルAIガバナンスフレームワーク
   2.1 リスクを事前に評価し、制限する
    2.1.1 エージェント導入に適したユースケースの特定
    2.1.2 エージェントの限界と権限を定義することで設計段階からリスクを制限
   2.2 人間の意味ある責任を確保する
    2.2.1 組織内外における責任の明確な割り当て
    2.2.2 意味ある人間による監督を設計に組み込む
   2.3 技術的な制御とプロセスを実装する
    2.3.1 設計・開発段階における技術的制御の活用
    2.3.2 導入前のエージェントのテスト
    2.3.3 導入時の継続的な監視とテスト
   2.4 エンドユーザーの責任を可能にする
    2.4.1 ユーザーの多様性とニーズの違い
    2.4.2 エージェントと直接やり取りするユーザー
    2.4.3 エージェントを業務プロセスに統合するユーザー
   附表A：参考資料 .
   附表B：フィードバックと事例の募集

エージェンティックAIを構成する6つのコアコンポーネント

本フレームワークにおいて、エージェンティックAIシステムとは、AIエージェントを用いて、特定の目的を達成するために複数のステップにわたる計画を立てて実行できるシステムを指す。一般的に、エージェントは、ユーザーが定めた目標を達成するために、ある程度自律的に計画を立て、行動を実行する能力（例：ウェブ検索やファイルの作成など）を備えていることが多い。

エージェントは言語モデルの上に構築されており、以下のような6つの中核的要素により構成される。

エージェンティック AI向けモデルAIガバナンス・フレームワーク（MGF）は、エージェント型AIに関するリスクと、それらのリスクを管理するための新たなベストプラクティスを、組織が体系的に把握できるようにするための枠組みである。リスクが適切に管理されれば、組織はより安心してエージェンティックAIを導入することができるとしている。

エージェンティックAI実装に際して考慮すべき4つの領域

このMGFは、自社でAIエージェントを開発する場合でも、外部のエージェントソリューションを利用する場合でも、エージェンティックAIの導入を検討している組織を対象としている。これまでのモデルガバナンス・フレームワークを基盤として、エージェントに関して組織が考慮すべき4つの主要な領域を以下のように整理している。

1. リスクを事前に評価し、制限する
   ・組織は、エージェントによって新たに生じるリスクを考慮し、内部の構造やプロセスを適応させる必要がある。その第一歩は、エージェントの行動によってもたらされるリスクを理解することであり、エージェントが取り得る行動の範囲、行動の可逆性、エージェントの自律性の度合いなどが関係する。
   ・リスクを早期に管理するために、組織は計画段階でエージェントの影響範囲を制限する設計（例：ツールや外部システムへのアクセス制限）を行うことが推奨される。また、エージェントの行動が追跡可能かつ制御可能であるように、堅牢なID管理やアクセス制御を導入することも重要である。
2. 人間の意味ある責任を確保する
   ・エージェンティックAIの導入に「ゴーサイン」が出た後は、人間の責任を確保するための措置を講じる必要がある。ただし、エージェントの自律性が高まることにより、従来の静的なワークフローに基づく責任の割り当てが複雑化する可能性がある。さらに、エージェントのライフサイクルには複数のステークホルダーが関与するため、責任の所在が分散するリスクもある。
   ・組織内外の関係者の責任範囲を明確に定義し、技術の進化に応じて迅速に対応できるよう、適応的なガバナンス体制を整備することが重要である。特に、ヒューマン・イン・ザ・ループ（HITL：Human-in-the-Loop）の設計は、自動化バイアスへの対処を含めて再考する必要がある。たとえば、重大な判断や不可逆な行動には人間の承認を必須とするチェックポイントを設けることや、人間による監督が時間とともに有効に機能しているかを定期的に監査することが求められる。
3. 技術的な制御とプロセスを実装する
   ・エージェントを安全かつ信頼性の高い形で運用するために、ライフサイクル全体にわたって技術的な対策を講じる必要がある。
   ・開発段階では、計画機能、ツール、成熟途上のプロトコルなど、エージェンティック AI特有の新しい構成要素に対して、技術的制御を組み込むことが重要である。これにより、新たな攻撃対象領域から生じるリスクに対応できる。
   ・導入前には、エージェントの基本的な安全性と信頼性（実行精度、ポリシー遵守、ツール使用の適切性など）を検証する必要がある。これには、従来とは異なる新しいテスト手法が求められる。
   ・導入時および導入後には、エージェントが環境と動的に相互作用するため、すべてのリスクを事前に予測することは困難である。そのため、段階的な導入と継続的なモニタリングが推奨される。
4. エンドユーザーの責任を可能にする
   ・エージェントの信頼性ある導入は、開発者だけでなく、それを使用するエンドユーザーの責任ある利用にも依存する。
   ・責任ある利用を促すために、最低限として、ユーザーにはエージェントの行動範囲、アクセス可能なデータ、ユーザー自身の責任について明確に伝える必要がある。
   ・組織は、人間とエージェントの相互作用を適切に管理し、効果的な監督を行うための知識を従業員に提供するトレーニングを実施することも検討すべきである。これは、従業員が自身の専門性や基本的なスキルを維持しながら、エージェントと協働できるようにするためである。 　シンガポールサイバーセキュリティ庁のサイバーセキュリティ認証プログラムに準拠したAIセキュリティガイドラインが、AIシステム全般（モデル、データ、インフラ）を対象とし、セキュリティ・バイ・デザイン、攻撃耐性、アクセス制御の観点から、技術的セキュリティ対策（設計・運用）に焦点を当てているのに対して、本フレームワークは、エージェンティックAIを対象とし、リスク評価、責任分担、技術制御、ヒューマン・イン・ザ・ループの観点から、ガバナンス、責任、リスク管理、ユーザー教育に焦点を当てている。

AIセキュリティ認証プログラムは、エージェンティックAIを含むAIシステム全般の技術的な安全性と堅牢性を担保するための基盤を提供する一方、エージェンティック AI向けモデルAIガバナンスフレームワークは、エージェンティックAIの設計・導入・運用におけるリスク管理と責任の明確化を通じて、信頼性ある社会実装を支援する。両者は、技術とガバナンスの両輪として、シンガポールにおけるAIの安全・信頼・倫理的な活用を支える枠組みとなっている。

エージェンティックAI固有のセキュリティ課題

　シンガポールのエージェンティックAI向けモデルAIガバナンスフレームワークは、クラウドセキュリティアライアンス（CSA）の公開情報の中で、「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」（2025年5月12日公開、https://cloudsecurityalliance.org/blog/2025/05/12/agentic-ai-understanding-its-evolution-risks-and-security-challenges）と、「エージェンティックAIにおけるアイデンティティ／アクセス管理：新たなアプローチ」（2025年8月18日公開、https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach）を参照している。

前者の「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」では、エージェンティックAIのセキュリティ課題として、安全性（エージェントが有害な行動を取らないようにする）およびセキュリティ（悪意ある攻撃者による悪用を防ぐ）を挙げた上で、以下のような脅威例を挙げている。

・意図の破壊・目標の操作：プロンプトインジェクションなどにより、エージェントの目的を誤認させる。
・メモリポイズニング：履歴やデータストアを改ざんし、意思決定を誤らせる。
・連鎖的なハルシネーション：LLMが誤情報を生成し、それがシステム全体に波及する。

そして、エージェンティックAIのセキュリティが重要な理由として、以下のような点を挙げている。

・データやシステムの悪用リスク：アクセス権限を持つエージェントが乗っ取られると深刻な被害に遭う
・予期せぬ結果：モデルの非決定性により、意図しない行動が発生する可能性がある
・自律性のリスク：人間の関与が減ることで、過剰な自律性が暴走する恐れがある
・規制・コンプライアンス対応：将来的にはエージェンティックAIにも特有の法的要件が課される見込みである

エージェンティックAIは、自律性・適応性・複雑なタスク処理能力を備えた次世代AIとして期待される一方で、新たなセキュリティリスクやガバナンス課題をもたらす。これに対応するには、従来のサイバーセキュリティに加え、以下の通りAI特有のリスクに対応した新しいフレームワークとプロアクティブな対策が不可欠だとしている。

・新たなガバナンス基準やフレームワークが必要（例：OWASP Top 10 for LLM Apps、MITRE OCCULTなど）。
・設計段階からのセキュリティ重視、エージェントの認証・認可・監視の強化が求められる

エージェンティックAIで進化するアイデンティティ／アクセス管理

　次に、後者の「エージェンティックAIにおけるアイデンティティ／アクセス管理：新たなアプローチ」では、エージェンティックAIにおけるアイデンティティ／アクセス管理（IAM）が、従来のID管理システムとは根本的に異なるパラダイムシフトを示している点を強調している。従来のIAMプロトコルは、予測可能な人間のユーザーや静的なアプリケーションを対象に設計されていたが、エージェンティックAIシステムは自律的に動作し、動的な意思決定を行い、リアルタイムで適応可能なきめ細かなアクセス制御を必要とする。

しかしながら、OAuth 2.1やSAMLといった従来のプロトコルは、粗い粒度の静的な性質や、マシンレベルの高速な認証処理への非対応、そして自律的なAIの運用に必要な文脈認識の欠如といった理由から、エージェンティックAIには適していない。

この課題に対する解決策としては、以下の機能を統合した包括的なフレームワークが求められる。

・ゼロトラスト・アーキテクチャ
・分散型ID管理
・動的なポリシーベースのアクセス制御
・継続的な監視

これにより、安全性・説明責任・コンプライアンスを確保したAIエージェントの導入が可能になるとしている。

従来のIAMシステムは、主に人間のユーザーや静的なマシンIDを対象に、OAuth、OpenID Connect（OIDC）、SAMLなどのプロトコルを通じて設計されてきた。しかし、これらのシステムは、複数の知的エージェントが相互に連携して動作するマルチエージェントシステム（MAS）のような、動的・相互依存的・一時的な性質を持つAIエージェントのスケーラブルな運用には本質的に不十分である。

CSAは、以下の通り新たなエージェンティックAI向けアイデンティティ／アクセス管理（IAM）フレームワークの必要性を提唱している。

1. 既存プロトコルの限界の分析：
   まず、マルチエージェントシステム（MAS）に既存のプロトコルを適用した際の限界を分解し、粗い粒度の制御、単一エンティティへの最適化、文脈認識の欠如がなぜ効果的でないのかを具体例を交えて説明する。
2. 新たなIAMフレームワークの提案：
   エージェントの能力、出自、行動範囲、セキュリティ姿勢を包括的に表現できる、検証可能なリッチなエージェントアイデンティティ（ID）に基づいたフレームワークを提案する。これには、分散型識別子（DID）と検証可能な資格情報（VC）を活用する。

このフレームワークには以下の要素が含まれる。

・Agent Naming Service（ANS）：
エージェントの安全かつ能力認識に基づく発見（ディスカバリ）を可能にする命名サービス。
・動的かつきめ細かなアクセス制御メカニズム：
属性ベースアクセス制御（ABAC）、ポリシーベースアクセス制御（PBAC）、ジャストインタイム（JIT）アクセスなどを活用する。
・統合されたグローバルセッション管理とポリシー強制レイヤー：
リアルタイム制御と一貫したアクセス権の取り消しを、異種のエージェント通信プロトコル間で実現する。

さらに、ゼロ知識証明（ZKP）を活用することにより、プライバシーを保護しながら属性情報を開示し、ポリシー準拠を検証可能にする方法についても検討するとしている。

CSAは、この新しいIAMパラダイムのアーキテクチャ、運用ライフサイクル、革新的な貢献点、セキュリティ上の考慮事項を概説し、エージェンティックAIとその複雑なエコシステムに必要な信頼性・説明責任・セキュリティの基盤構築を目指すとしている。

このようにみていくと、シンガポールは、エージェンティックAIの社会実装に向けたガバナンスとセキュリティの両面で世界をリードしている。シンガポールサイバーセキュリティ庁のAIセキュリティガイドラインとシンガポール情報通信メディア開発庁のエージェンティックAI向けフレームワークは、相互補完的に機能し、信頼性あるAI活用の基盤構築に寄与している。その中で、クラウドセキュリティアライアンスのクラウドセキュリティおよびAIセキュリティ関連文書も有効活用されている。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

前回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみたが、今回は、AIの普及とともに急増する人間以外のアイデンティティ（NHI：Non-Human Identity）に焦点を当てる。

ノンヒューマン・アイデンティティ（NHI）とAIワークロードの関係

クラウドセキュリティアライアンス（CSA）のブログ記事「ノンヒューマン・アイデンティティ管理」（関連情報（https://cloudsecurityalliance.org/blog/2024/07/15/non-human-identity-management））によると、ノンヒューマン・アイデンティティ（NHI）とは、現代の企業システムにおいて、マシン同士や人とマシンとの間のアクセスおよび認証を安全に行うためのデジタル・ゲートキーパーとして機能するものである。イノベーションの推進により、マイクロサービス、サードパーティ製ソリューション、クラウドベースのプラットフォームの導入が進み、相互に接続されたシステムの複雑なネットワークが形成されているという背景がある。

そしてノンヒューマン・アイデンティティ管理（NHIM）とは、非人間の識別情報のライフサイクル全体を統制・自動化するプロセスであり、以下のような項目が含まれるとしている。

・発見と分類
・プロビジョニング（識別情報の作成と割り当て）
・所有者の割り当て
・状態の監視と異常検知
・保管庫への格納と安全な保存
・資格情報のローテーション（定期的な更新）
・コンプライアンス対応
・廃止（使用終了時の適切な処理）

他方、AIワークロードとは、機械学習モデルのトレーニング、推論、データ処理、API連携など、AIが関与する一連の処理やタスクのことを指す。AIワークロードはクラウドやオンプレミス環境で自動的に実行されることが多く、人間の介在なしに動くのが特徴となっている。

AIワークロードは、以下のような人間以外のエンティティによって構成されていることが多い：

・AIモデル自体（例：推論エンジン）
・スクリプトやバッチ処理
・APIクライアント
・コンテナやマイクロサービス
・CI/CDパイプラインの自動化ツール

これらはすべて人間ではないが、システムにアクセスし、機密データを扱い、他のサービスと通信する存在となっている。そこで、誰が何にアクセスしているのかを明確にするためには、NHIの管理が不可欠になる。

NHIに対するリスク認識と具体的セキュリティ対策のアンバランス

CSAでは、ボット、APIキー、サービスアカウント、OAuthトークン、シークレットなどノンヒューマン・アイデンティティ（NHI）セキュリティで見落とされがちな側面を理解するために、2024年6月にオンライン調査を実施し、ITおよびセキュリティ専門家から818件の回答を得た。この結果を取りまとめたのが、2024年9月11日に公開された「ノンヒューマン・アイデンティティ・セキュリティの現状」である（関連情報（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report））。

この報告書では、以下の点について洞察を提供している。

・NHIとそのセキュリティリスクに関する認識
・現在のNHIのセキュリティ対策、ポリシー、管理
・サードパーティベンダーとの接続に関する課題
・APIキーの現在の管理とポリシー

主な調査結果は以下の通りである。

・NHI攻撃の防止に高い自信を持つ組織はわずか15%で、69%が懸念を表明している。これは、リスクを認識しているものの、現在のセキュリティ対策に自信がないことを示している。
・主な問題点としては、サービス アカウントの管理、監査と監視、アクセスと権限の管理、NHI の検出、ポリシーの適用などが挙げられる。
・APIキーのオフボーディングと失効に関する正式なプロセスを設けている組織はわずか20%であった。APIキーのローテーション手順を設けている組織はさらに少ない。
・多くの組織は、NHI向けに特別に設計されていないセキュリティツールを混在して使用している結果、一貫性と有効性が欠如している。
・有望な傾向として、NHI セキュリティ機能への投資が増加している。組織の 24% が今後 6 か月以内に、36% が今後 12 か月以内に投資する予定としている。

新たなノンヒューマン・アイデンティティ（NHI）のリスクとは？

前述のブログでは、MITRE ATT&CK Matrix for Enterprise（関連情報（https://attack.mitre.org/matrices/enterprise/））を参照しながら、管理されていないノンヒューマン・アイデンティティ（NHI）が、以下のような攻撃者の戦術・技術に関与することがあるとしている。

初期アクセス：攻撃者がネットワークへの侵入を試みる段階
・サプライチェーンの侵害（T1195）
・信頼された関係性の悪用（T1199）
・正規アカウントの悪用（T1078）
永続化：攻撃者がアクセスを維持しようとする段階
・アカウント操作（T1098）
・アカウントの新規作成（T1136）
・正規アカウントの悪用（T1078）
資格情報へのアクセス：攻撃者が権限昇格や横展開を目的に、認証情報を盗もうとする段階
・パスワードストアからの資格情報取得（T1555）
・保護されていない資格情報の取得（T1552）
・アプリケーションのアクセストークンの窃取（T1528）

そして攻撃者は、以下のような脅威ベクトルを通じてノンヒューマン・アイデンティティ（NHI）を悪用し、アクセスを獲得するとしている。

1. 放置された特権NHI（資格情報のローテーションなし）：
   ・特権アクセスを持ちながらも、所有者不在や責任の所在不明、資格情報の未更新により放置されたアカウントは、攻撃者にとって格好の標的となる。
2. 退職者に晒された未ローテーションのシークレット：
   ・退職した従業員が依然としてアクセス可能なシークレットがローテーションされずに残っている場合、特にそれがインターネット上でアクセス可能で特権を持っていると、重大なリスクとなる。
3. 放置されたストレージアカウント
   ・長期間使用されていないストレージアカウントは、古い設定のまま放置されていることが多く、機密データが不正アクセスや漏洩の危険にさらされる可能性がある。
4. 有効期限が50年以上のアクティブなシークレット：
   ・極端に長い有効期限を持つシークレットは、攻撃者にとって脆弱性を突くための長期間のチャンスを提供してしまい、セキュリティリスクが高まる。
5. 未使用のアクセスポリシーを含むボールト（保管庫）
   ・使われていないアクセスポリシーが残されたボールトは、見落とされがちなセキュリティギャップとなり、意図しないアクセス権を通じて機密リソースやデータへの不正アクセスを許す可能性がある。

AIエージェントで複雑化するノンヒューマン・アイデンティティの保護

CSAの「AIエージェント時代におけるノンヒューマン・アイデンティティの保護」（2025年4月29日公開）では、人間1人に対して45のノンヒューマン・アイデンティティが存在しており、AIエージェントの普及によりこの数はさらに増加すると指摘している（関連情報（https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025））。

AIエージェントは、サービスアカウント、APIキー、シークレット情報のようなNHIを使ってシステムにアクセスする。これらは組織の機密データや重要なシステムにアクセスするための鍵となるため、攻撃者にとって格好の標的になる。

しかしながら、従来のアイデンティティ・アクセス管理（IAM）は静的なアプリケーションや人間のユーザー向けに設計されており、AIエージェントのような存在には対応しきれない。AIエージェントは、自律的に意思決定を行い、タスクごとに一時的なIDを使い分けて、他のAIエージェントに権限を委譲するといった特徴を持つため、新しいIAMの枠組みが必要となる。

CSAでは、ノンヒューマン・アイデンティティ（NHI）について、以下のようなセキュリティ課題を挙げている。

・NHIに関する可視性の欠如：多くの組織が、どのNHIがどこで使われているかを把握できていない
・アクセス権の過剰付与：最小権限の原則が徹底されていない
・認証情報の管理不備：APIキーやシークレットが適切に保護・ローテーションされていない

これらに対して、以下のような対策を推奨している。

・NHIの発見・分類・監視の自動化
・エージェンティックIAMの導入
・ゼロトラスト原則に基づいたアクセス制御

適切なノンヒューマン・アイデンティティ管理プラットフォームの選び方

AIに代表される新技術の導入とともに、アイデンティティが新たなセキュリティ境界となる中で、人間のアイデンティティだけに注目していたのでは不十分な状況となっている。今や、ノンヒューマン・アイデンティティ管理（NHIM）は、アイデンティティ＆アクセス管理（IAM）における大きな転換点となっている。

非人間エンティティの特有の要件に対応するために、NHIMプラットフォームには以下の基本要件を満たすことが求められる。

1. 包括的かつコンテキストに基づく可視性：
   ・非人間アイデンティティの全体像を把握することが不可欠である。
   ・NHIMプラットフォームは、使用状況、依存関係、エコシステム内の関係性を含む包括的な可視性を提供すべきである。
2. ハイブリッドクラウド全体での対応力：
   ・NHIMプラットフォームは、従来のインフラの枠を超え、ハイブリッドクラウド環境全体でシームレスに動作する必要がある。
   ・AWS、Azure、Google Cloudなどの主要なIaaSだけでなく、PaaSやSaaS、オンプレミス環境もカバーすべきである。
3. アクティブなポスチャー管理：
   ・脅威が進化する中で、リアルタイムでのセキュリティ状態の評価とリスク軽減のための能動的な対策が不可欠となる。
   ・NHIMプラットフォームは、これを可能にする機能を備えている必要がある。
4. ライフサイクル管理と自動化：
   ・プロビジョニングから資格情報のローテーション、廃止に至るまで、NHIのライフサイクル管理は自動化されるべきである。
   ・NHIMプラットフォームは、これらのタスクを自動化し、運用効率とセキュリティの両立を実現する機能を提供すべきである。
5. シークレット管理ツールやPAMとの連携：
   ・主要なシークレット管理ソリューションと統合できること。
   ・特権アクセス管理（PAM）ソリューションと連携し、発見されたシークレットを安全に保管・管理できることが求められる。
6. 開発者に優しい設計：
   NHIMプラットフォームは、堅牢なAPIを備え、アプリケーションやサービスとの統合が容易であるべきである。
   ・Infrastructure as Code（IaC）ツール、ITサービス管理（ITSM）システム、ログフレームワーク、開発ツールなど、運用スタックとのシームレスな統合も重要である。

必要なエコシステムとの統合機能や各種機能を備えた堅牢なノンヒューマン・アイデンティティ管理（NHIM）プラットフォームを導入することにより、組織は非人間アイデンティティを効果的に管理し、セキュリティ体制を強化し、自動化やシステム間連携の利点を最大限に活用することができるとしている。

　なお特権アクセス管理（PAM）に関連して、CSAでは、2025年11月24日に「クラウドファースト時代における特権アクセス管理」を公開している（関連情報（https://cloudsecurityalliance.org/artifacts/managing-privileged-access-in-a-cloud-first-world）、日本語版（https://www.cloudsecurityalliance.jp/site/?p=41892））。

OWASP Non-Human Identities Top 10とは？

参考までに、CSAと連携するOWASPでは、「OWASP Non-Human Identities Top 10」を公開している（関連情報（https://cloudsecurityalliance.org/blog/2025/06/30/introducing-the-owasp-nhi-top-10-standardizing-non-human-identity-security））。具体的な10項目は、以下の通りである。

・NHI1:2025 – 不適切なオフボーディング
不適切なオフボーディングとは、サービスアカウントやアクセスキーなどのノンヒューマン・アイデンティティ（NHI）が不要になった際に、適切に無効化または削除されないことを指す。監視されていない、または廃止されたサービスが脆弱なまま残る可能性があり、それに関連するNHIが攻撃者に悪用され、機密性の高いシステムやデータへの不正アクセスにつながるおそれがある。
・NHI2:2025 – シークレット漏えい
シークレット漏えいとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ（NHI）が、ソフトウェア開発ライフサイクル全体を通じて、許可されていないデータストアに漏えいすることを指す。たとえば、ソースコードにハードコーディングされたり、平文の設定ファイルに保存されたり、公的なチャットアプリで送信されたりすると、これらのシークレットは露出しやすくなり、悪意ある第三者に悪用されるリスクが高まる。
・NHI3:2025 – 脆弱なサードパーティNHI
サードパーティのノンヒューマン・アイデンティティ（NHI）とは、統合開発環境（IDE）やその拡張機能、サードパーティのSaaSを通じて、開発ワークフローに広く統合されている。もしサードパーティの拡張機能が、セキュリティの脆弱性や悪意あるアップデートによって侵害された場合、それを悪用して認証情報を盗んだり、付与された権限を不正に使用されたりする可能性がある。
・NHI4:2025 – 安全でない認証
開発者は、内部および外部（サードパーティ）のサービスをアプリケーションに頻繁に統合する。これらのサービスは、システム内のリソースにアクセスするために、認証情報を必要とする。しかし、一部の認証方式はすでに非推奨であったり、既知の攻撃に対して脆弱であったり、古いセキュリティ慣行により安全性が低いと見なされたりしている。安全でない、または時代遅れの認証メカニズムを使用すると、組織は重大なリスクにさらされる可能性がある。
・NHI5:2025 – 過剰な特権を与えられたNHI
アプリケーションの開発や保守の過程で、開発者や管理者がノンヒューマン・アイデンティティ（NHI）に、その機能に必要以上の権限を付与してしまうことがある。こうした過剰な権限を持つNHIが、アプリケーションの脆弱性やマルウェア、その他のセキュリティ侵害によって侵害されると、攻撃者はその過剰な権限を悪用する可能性がある。
・NHI6:2025 – 安全でないクラウド展開構成
CI/CD（継続的インテグレーションおよび継続的デプロイ）アプリケーションは、コードのビルド、テスト、そして本番環境へのデプロイを自動化するために、開発者に広く利用されている。これらの統合には、クラウドサービスとの認証が必要であり、通常は静的な認証情報やOpenID Connect（OIDC）を使用して実現される。静的な認証情報は、コードリポジトリ、ログ、設定ファイルなどを通じて、意図せず漏えいする可能性がある。もしこれらが侵害されると、攻撃者に対して永続的かつ特権的なアクセス権を与えてしまう恐れがある。一方、OIDCはより安全な選択肢であるが、IDトークンが適切に検証されていなかったり、トークンクレームに厳格な条件が設定されていなかったりすると、不正なユーザーがその弱点を突いてアクセスを得る可能性がある。
・NHI7:2025 – 長きにわたるシークレット
長期間有効なシークレットとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ（NHI）が、非常に長い有効期限を持っていたり、まったく期限切れにならないように設定されていたりする状態を指す。こうしたシークレットが漏えいした場合、有効期限が長いために、攻撃者が時間の制限なく機密サービスへアクセスできてしまうリスクがある。
・NHI8:2025 – 環境の分離
環境の分離とは、クラウドアプリケーションのデプロイにおける基本的なセキュリティ対策であり、開発・テスト・ステージング・本番といった環境を分けて運用することを指す。アプリケーションのデプロイプロセスやライフサイクル全体において、ノンヒューマン・アイデンティティ（NHI）が頻繁に使用される。しかし、同じNHIを複数の環境、特にテスト環境と本番環境で使い回すと、重大なセキュリティ脆弱性を招く可能性がある。
・NHI9:2025 – NHIの再利用
同じノンヒューマン・アイデンティティ（NHI）を、異なるアプリケーション、サービス、またはコンポーネント間で使い回すことは、たとえそれらが一緒にデプロイされていたとしても、重大なセキュリティリスクを引き起こす。もしある領域でNHIが侵害された場合、攻撃者はその認証情報を悪用して、同じ資格情報を使用している他のシステム部分にも不正アクセスできてしまう可能性がある。
・NHI10:2025 – 人間におけるNHIの使用
アプリケーションの開発や保守の過程で、開発者や管理者が本来は適切な権限を持つ人間のIDで実行すべき手作業を、ノンヒューマン・アイデンティティ（NHI）を使って行ってしまうことがある。このような運用は、NHIに過剰な権限を与える原因となり、また人間と自動化の活動が区別できなくなることで、監査や責任追跡が困難になるなど、重大なセキュリティリスクを引き起こす。

　今後、「OWASP Non-Human Identities Top 10」に関しては、CI/CDやIaC（Infrastructure as Code）、サードパーティ統合など、クラウドネイティブな開発環境におけるNHIの利用実態に即したベストプラクティスの整備が期待されている。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

CSAジャパン関西支部では、2024年7月15日にCSA本部が公開した「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）と前後して、クラウドワークロードセキュリティおよびアプリケーションセキュリティの観点から、以下のようなブログを展開してきた。

・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (前編)（2024年6月25日）https://cloudsecurityalliance.jp/newblog/2024/06/25/devsecops_3/
・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (後編)（2024年7月16日）https://cloudsecurityalliance.jp/newblog/2024/07/16/devsecops_4/
・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年8月13日）https://cloudsecurityalliance.jp/newblog/2024/08/13/cloud_workload/
・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年9月8日）https://cloudsecurityalliance.jp/newblog/2024/09/08/ssdlc/

今回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみていく。

膨大な量の学習用データを処理するAIワークロードとリスク低減策

前述の「クラウドコンピューティングのためのセキュリティガイダンス V5」のうち、「ドメイン8: クラウドワークロードセキュリティ」の「8.6 AIワークロード」では、AIワークロードについて、AI機能の構築、提供、または利用に関わるタスク、プロセス、あるいはオペレーションを指すとしている。AIワークロードは、ユーザー行動に基づく製品の推奨から、車両の自律的な操縦に至るまで、非常に幅広い複雑性と応用分野を包含しているのが特徴である。

AIワークロードは、モデルのトレーニングに大量のデータセットを必要とし、効率化のためにGPU（グラフィックス処理ユニット）やTPU（テンソル処理ユニット）などの専用ハードウェアを活用するなど、かなりの処理能力を要求する。さらに、これらのワークロードは、需要の変動に対応するために動的にスケールする必要があり、クラウド環境によって提供される柔軟なコンピューティングリソースが重要になる。AIワークロードへの取り組みは、単に計算能力を活用することだけではなく、様々な分野でイノベーションと価値を解き放つために、データ、アルゴリズム、リアルタイム処理の複雑な要素を乗りこなすことでもあるとしている。

　CSAガイダンスV5では、AIワークロードセキュリティにおけるリスク低減策として、以下のような点を挙げている。

・データセキュリティ：データを保護するために、暗号化、差分プライバシー、セキュアなマルチパーティ計算を利用する
・モデルセキュリティ：敵対的な攻撃に対してモデルをハードニングし、堅牢なトレーニング手法を利用し、盗難防止のために固有識別子を組み込む
・インフラストラクチャセキュリティ：割当・レート制限を実装し、クラウドサービスに関するベストプラクティスをフォローする
・サプライチェーンセキュリティ：サイバーセキュリティポリシーを定義し、定期的にサードパーティの依存性を監査し、信頼されたリソースを利用する

CSA DevSecOps WG が「MLOpsの概要」を公開

CSA DevSecOps WGは、2025年8月27日に「MLOpsの概要」（https://cloudsecurityalliance.org/artifacts/machine-learning-ops-overview）を公開している。

機械学習(ML)は、ますます企業の中核的な業務機能と結びつくようになっており、それに伴いMLパイプラインのセキュリティ確保が不可欠となっている。そこで本書では、MLSecOps（Machine Learning Security Operations）の概念を紹介し、ML資産を保護する上で特有の課題や、従来のセキュリティ対策がMLシステムに対する新たな脅威に対して十分に機能しない理由について説明することを目的としている。

・謝辞
・目次
・はじめに
・目標.
・対象読者
・エグゼクティブサマリー（概要）
・MLOpsとは？
・LLMOps vs. AgentOps vs. 従来型MLOpsの融合
・MLOpsのステークホルダー
－データサイエンティスト
－機械学習エンジニア
－運用チーム
－プラットフォームチーム
―セキュリティチーム／セキュリティエンジニア.
―プライバシーチーム
―データおよびコンプライアンスチーム
―Cレベル職／経営層.
―プロジェクト／プロダクトチーム
―顧客
・MLOpsの各ステージ
―設計ステージ
―モデル開発ステージ
―運用ステージ
―継続的フィードバックステージ
・MLOpsの課題
・結論

ここ数年で、従来のMLOpsの概念は、古典的な機械学習モデルを運用化するための一連のプラクティスやワークフローとして業界内で発展してきた。しかし、近年の大規模言語モデル（LLM）およびLLMを活用したAIエージェントの進化に伴い、これらの技術を運用化する際に特有の課題に対応するための新たなプラクティスやワークフローを表す用語として、「LLMOps」や「AgentOps」といった言葉が業界で使われるようになっている。LLMは、従来の機械学習モデルと比べてはるかに高い計算複雑性を持ち、専門的なインフラや最適化技術が必要とされる。LLMOpsは、こうしたLLMモデルを本番環境で学習・デプロイ・管理するために進化してきたものである。

本書では、MLOps(機械学習運用)、LLMOps(大規模言語モデル運用)、AgentOps(エージェント運用)の特徴を以下のように整理している。

【MLOps（機械学習運用）】
・対象範囲：一般的な機械学習モデル（分類、回帰、強化学習など）
・モデルサイズ：通常は数MB〜数GBの小〜中規模モデル
・データ要件：構造化データ／表形式データ、画像、時系列、小規模なテキストデータセット
・学習プロセス：モデルはゼロから学習されるか、小規模なデータセットでファインチューニングされる
・インフラ要件：従来型のMLモデルは、スケーラビリティとクラウドネイティブ環境に重点を置いた中程度のインフラを必要とする
・モデルのデプロイ：モデルは通常コンテナ化され、DockerやKubernetesなどのプラットフォーム、および自動化されたCI/CDパイプラインを用いて継続的にデリバリーされる
・推論：予測モデルはREST APIとしてデプロイされるか、アプリケーションに組み込まれる
・モニタリングと可観測性：モニタリングはモデルの性能、レイテンシ、ドリフト検出、精度に焦点を当てる。PrometheusやGrafanaなどの可観測性ツールが一般的
・バージョン管理：モデルのバージョン、特徴量、ハイパーパラメータを追跡
・ガバナンスとコンプライアンス：ガバナンスはデータプライバシー、規制遵守（例：GDPR、CCPA）、モデルおよびデータへの安全なアクセスに重点を置く
・最適化手法：従来型のML最適化（例：ハイパーパラメータチューニング、特徴量エンジニアリング）
・ライフスパンと更新：モデルは新しいデータセットや変化するトレンドに応じて頻繁な更新と再学習が必要

【LLMOps(大規模言語モデル運用)】
・対象範囲：大規模言語モデル（LLM）に特化しており、ファインチューニング、推論、プロンプトエンジニアリングを含む
・モデルサイズ：数百億〜数千億パラメータ規模の大規模モデル
・データ要件：学習・ファインチューニング・継続学習のための膨大な非構造化テキストデータや埋め込みベクトル
・学習プロセス：事前学習済みモデル（例：OpenAIのChatGPT、MetaのLLaMA）をファインチューニングするか、プロンプトベースで適応させる手法が一般的
・インフラ要件：LLMは大規模なインフラ資源を必要とし、分散コンピューティング、高性能GPU/TPU、大規模データセットや並列学習に対応する高度なストレージソリューションが求められる
・モデルのデプロイ：推論効率を高めるために、量子化、モデル分割、知識蒸留などの最適化技術が用いられることがある。また、エッジAIやハイブリッドクラウドでの展開も行われる
・推論：プロンプトベースの推論、リアルタイムのテキスト生成、チャット型インターフェースなど
・モニタリングと可観測性：言語生成の品質、応答時間、モデルの倫理的側面（例：バイアス、不適切な応答、幻覚、攻撃的表現など）の監視が追加で求められる
・バージョン管理：プロンプト、モデルのチェックポイント、ファインチューニングされたバリアントのバージョン管理を含む
・ガバナンスとコンプライアンス：責任あるAIの実践、大規模モデルにおける知的財産の管理、生成AIシステムに対する倫理的ガイドラインの遵守に強く焦点を当てる

【AgentOps(エージェント運用)】
・対象範囲： ユーザー、ツール、環境と対話する自律型AIエージェントの管理、およびマルチステップ推論、記憶、ツール使用のオーケストレーション
・モデルタイプ： 計画・推論・ツール使用が可能な動的かつ対話型のエージェント
・デプロイ： API、データベース、ユーザーとやり取りするサービスとしてエージェントをデプロイ
・推論： マルチステップ推論、反復的な意思決定、ツールの活用
・モニタリングと可観測性： エージェントの推論の正確性、ハルシネーションの検出、状態の追跡
・バージョン管理： エージェントのプロンプト、推論ログ、記憶状態、ツール統合の履歴を追跡
・最適化手法： エージェントの記憶のファインチューニング、推論ステップの改善、ツール使用の最適化

MLOpsを取り巻く多様なステークホルダーの存在

業界では現在、MLOps、LLMOps、AgentOpsといった用語を区別して使う傾向があるが、CSAとしては、これらの用語は最終的に統合されるべきであり、「MLOps」という用語が、機械学習に関連するすべての運用プラクティス、ワークフロー、技術アーキテクチャを包括するべきだと考えている。

定義上、機械学習の世界は、あらゆる学習手法とモデリングアーキテクチャを含む上位概念（スーパーセット）であり、現在LLMが使用しているトランスフォーマーのような手法、畳み込みニューラルネットワーク（CNN）、再帰型ニューラルネットワーク（RNN）、長短期記憶（LSTM）といった他の生成系AIの学習技術、さらにはサポートベクターマシン（SVM）、回帰モデル、人工ニューラルネットワーク（ANN）などのより古典的な機械学習手法もすべて含まれる。従って、本書においては、「MLOps」という用語を業界標準とは異なる意味で使用しており、LLMOpsやAgentOpsをも内包する広義の概念として扱っている。

MLOpsは、機械学習モデルの調査、データ収集、トレーニング、開発に多くの時間が費やされるため、従来のDevOpsと比べてややアジャイル性が低い傾向がある。MLOpsのプラクティスを導入することによって、機械学習モデルのライフサイクルに自動化を取り入れることが可能になる。MLOpsのパイプラインには複数の重要なステークホルダーが関与しており、それぞれが異なる役割を担いながら、機械学習と運用の橋渡しを行い、MLOpsを実現している。

　本書では、以下の通り、10の重要なステークホルダーを挙げている。

・データサイエンティスト：
データサイエンティストは、機械学習モデルを作成・学習させるためのアルゴリズムやデータを含む、モデルエンジニアリングのパイプラインを管理することが多い。彼らの役割には、モデルの作成、トレーニング、評価、テスト、パッケージ化などが含まれる。ただし、データサイエンティストは、実運用に耐えるソフトウェアサービスを構築する熟練のソフトウェアエンジニアであるとは限らない。

・機械学習エンジニア：
機械学習エンジニアは、データサイエンスチームから引き渡されたモデルを、呼び出し可能なアーティファクト（例：API統合）へと変換する役割を担うことが多い。大規模な機械学習モデルのトレーニング、モデルの保存、コードリポジトリやモデルレジストリへのアップロード、モデルのデプロイと利用可能な状態への展開、さらにスケーラブルな推論パイプラインやアプリケーションの構築などが、機械学習エンジニアの主な業務である。

・オペレーションチーム：
オペレーションチームは、継続的インテグレーション（CI）および継続的デリバリー（CD）のパイプラインを管理する。機械学習のデプロイメントにおいては、データ、モデル、トレーニング成果物といった複数のワークフローに対応する必要があるため、従来のソフトウェアのCI/CDフロー（例：開発 → QA → 本番）よりもパイプラインが複雑になる。モデルは頻繁に更新されるのではなく、全体として繰り返しリリースされる傾向があるため、データ用のパイプラインとモデル用のパイプラインが分かれて存在することが一般的である。

・プラットフォームチーム：
プラットフォームチームは、インフラの管理、自動化、スケーラビリティ、システムの監視を担当する。機械学習の文脈においては、MLモデルを迅速かつ信頼性高くスケーラブルにデプロイするためのフレームワークを設計・維持する上で、非常に重要な役割を果たす。

・セキュリティチーム／セキュリティエンジニア：
セキュリティチームは、MLOpsライフサイクル全体において、セキュリティ対策が設計段階から統合されていることを確保するという重要な役割を担う。このチームは、機械学習システムの脅威モデリングの実施、データおよびモデルにおける潜在的な脆弱性の特定、セキュリティガードレールの実装、セキュリティインシデントの監視、セキュリティポリシーや標準への準拠の確保などを担当する。

・プライバシーチーム：
MLOpsライフサイクルにおいて、プライバシーチームは、モデルの開発やトレーニングに使用されるデータが、適用されるプライバシー規制および組織の基準に準拠していることを確保する責任を担う。このチームは、データ最小化の原則の適用、個人識別可能情報（PII）の特定、そしてデータの匿名化、仮名化、差分プライバシーといった技術の導入を通じて、ユーザーデータの保護を行う。プライバシーチームは、MLOpsライフサイクル全体にわたってプライバシーの観点が組み込まれるようにし、倫理的なAIの実践と規制遵守の両方を支援する。

・データ／コンプライアンスチーム：
データ／コンプライアンスチームは、データライフサイクルの管理を担い、機械学習モデルが高品質で関連性があり、偏りのないデータでトレーニングされることを確保する責任がある。これには、さまざまなソースからの新たなデータの導入や収集、データ管理、分析、データセキュリティなどが含まれる。MLOpsパイプラインにおいては、データセキュリティが最重要事項の一つであり、コンプライアンスチームは機密情報を保護・管理するための対策を講じる必要がある。

・Cレベル職／経営層：
経営層やCレベルのチームは、社内プロセスの最適化や顧客向けビジネスの強化を目的として、機械学習の導入に関心を持っている。このチームは、MLOpsによって実現される開発期間の短縮、モデルの信頼性や最新性の確保、コストや稼働率の要件への適合、そしてビジネスの主要業績評価指標（KPI）や各種メトリクスに対する大きなインパクトに注目している。

・プロジェクト／プロダクトチーム：
プロダクトチームは、機械学習プロダクトのビジョンを導くうえで不可欠な存在であり、しばしばMLのユースケースの優先順位付けを担当する。一方、プロジェクトチームは、そのプロダクトビジョンを実現し、目標期日までに成果を届けるための推進役として重要な役割を果たす。

・顧客：
顧客は、自身のデータがMLOpsパイプラインにおいてどのように活用されているかに関心を持っている。具体的には、自分のデータがモデルのトレーニングに使用されているかどうか、機密データが適切に保護されており、マルチテナント環境で他の利用者に漏洩しないこと、退会後にデータが適切に削除され、機械学習モデルに機密情報が残らないことなどを気にしている。また、機械学習モデルの信頼性や説明可能性についても高い関心を持っている。

MLOpsパイプラインにおけるセキュリティ部門の役割とは？

次に本書では、以下の通り、MLOpsパイプラインの4つのステージを紹介し、各ステージにおける主要なステークホルダーとの関係を説明している。

1.設計ステージ：
・要求事項の収集、設計、計画策定
（ステークホルダー）経営層／リーダーシップ、製品／プロジェクトチーム、データサイエンティスト、機械学習エンジニア、セキュリティエンジニア

2.モデル開発ステージ：
・データ準備／モデルのためのデータ収集
（ステークホルダー）データ／コンプライアンスチーム、プライバシーチーム、データサイエンティスト、機械学習エンジニア
・モデル検証とテスト
（ステークホルダー）データサイエンティスト

3. 運用ステージ：
   ・モデルトレーニング
   （ステークホルダー）機械学習エンジニア、データサイエンティスト
   ・デプロイ
   （ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム
   ・モニタリング
   （ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム、サイト信頼性エンジニア

4.継続的なフィードバックステージ
・モデルの結果の利用
（ステークホルダー）下流アプリケーション、内部ステークホルダー、外部顧客
・新たなモデルのアップデート
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム

早期からDevSecOpsの導入に取り組んできたユーザー企業をみると、既存のオンプレミス環境をベースとするレガシーなエンタープライズシステム体制の改革からスタートし、クラウド環境への移行を図ってきたケースが多い。これに対してMLOpsの場合、DevOpsやDevSecOpsの原則やプラクティスを拡張し、機械学習（ML）のライフサイクルに適用することを目指すが、前述のステークホルダーの顔ぶれを見てもわかるように、組織の開発部門（Dev）や運用部門（Ops）、情報セキュリティ部門（Sec）だけでなく、社内のCレベル職／経営層やユーザー部門、組織外にある外部委託先／パートナー、顧客など、多様なステークホルダーとのコミュニケーションを行いながら、プロジェクトを進めることが必要になる。

その一方でMLOpsは、人間による操作を最小限に抑え、エンドツーエンドの自動化を実現するために、AIワークロードを実行する「非人間アイデンティティ（NHI: Non-Human Identity）」を活用しており、従来とは異なる認証／認可管理やアクセス制御ポリシーの策定が不可欠になってくる。参考までにCSAでは、2024年9月11日に「ノンヒューマンアイデンティティ・セキュリティの状況」（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report）を公開している。

このようなMLOps固有のセキュリティ対策が設計段階から組み込まれるよう確保することが、今後、セキュリティチーム／セキュリティエンジニアの重要な役割となってくる。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司