これまでのAIセキュリティ記事では、公開した推論エンドポイントからのモデル抽出や、プロンプトインジェクションの構造的防御、エージェントの脅威モデリング（MAESTRO／STRIDE）まで、「個々の攻撃をどう防ぐか」を一つずつ積み上げてきました。設計時の脅威モデリング、公開前のレッドチーミング、事故後のインシデント対応（IR）——守りの部品はひととおり揃ってきたはずです。
ところが現場でよく起きるのは、こんな事態です。「対策は入れた。でもいま自社に“どんなAI資産が・どのリスク状態で”存在しているのか、誰も正確には言えない」。気づけば部署が勝手にAI SaaSを契約し、検証用に立てたモデルが本番に残り、エージェントに付けたAPIキーの権限は付与時のまま拡大している——。個別対策（点）を貼り終えた次にやるべきなのは、その「点」を運用中に常時可視化して束ねることです。このカテゴリをAI-SPM（AI Security Posture Management／AIセキュリティ・ポスチャー管理）と呼びます。
この記事では、AI-SPMを「一回きりのチェックリスト」ではなく継続ディスカバリを行うツールカテゴリとして定義し、CSPM／DSPM／CNAPPとの違い、可視化すべき4つの対象、シャドーAI・過剰権限ドリフトの検知方法、そして中小企業でも今日から始められる最小構成までを、実装目線で解説します。
前提——AIセキュリティの「4象限」を整理する
AI-SPMの位置づけを理解するには、AIセキュリティの取り組みを次の4象限で整理すると分かりやすくなります。多くの組織は左3つに投資してきましたが、右下の「運用中の常時可視化」だけがぽっかり抜けがちです。
| 象限 | いつ守るか | 問い | 代表的な取り組み |
|---|---|---|---|
| 点の対策 | 個別の攻撃ごと | この攻撃をどう防ぐ？ | モデル抽出対策・プロンプトインジェクション対策・レート制限 |
| 面の設計 | 設計時 | どこが弱い？ | 脅威モデリング（MAESTRO／STRIDE） |
| 検証 | 公開前 | 本当に防げる？ | レッドチーミング・引用回帰テスト |
| 姿勢管理（AI-SPM） | 運用中（常時） | いま何が・どんなリスク状態で存在する？ | 継続ディスカバリ・シャドーAI検出・権限ドリフト可視化 |
ポイントは、AI-SPMは他の3つを置き換えるものではなく、束ねて“常時見える化”するレイヤーだという点です。脅威モデリングで洗い出した弱点も、レッドチーミングで塞いだ穴も、運用が続けば新しい資産の追加・設定変更・権限拡大でじわじわ崩れていきます。その「ドリフト（漂流）」を継続的に捉えるのがAI-SPMの役割です。
第1章：AI-SPMとは何か——CSPM／DSPM／CNAPPとの関係
1.1 「ポスチャー管理」という考え方の系譜
「ポスチャー管理（Posture Management）」は、AIで突然生まれた概念ではありません。クラウドの世界では、設定ミスや過剰権限を継続的にスキャンして可視化・是正する仕組みが先に発達してきました。
- CSPM（Cloud Security Posture Management）：クラウド基盤の設定ミス・IAMの過剰権限・公開ストレージなどを継続検出。
- DSPM（Data Security Posture Management）：機密データが「どこに・誰がアクセスできる状態で」存在するかを発見・分類し、データフローを追跡。
- CNAPP（Cloud-Native Application Protection Platform）：CSPMやワークロード保護などを束ねた統合プラットフォーム。
AI-SPMは、この「継続的に発見し、リスク状態を可視化し、是正へつなげる」という発想をAI固有の資産（モデル・推論エンドポイント・学習/RAGデータ・エージェント・NHI・システムプロンプト・ガードレール設定）に拡張したものです。
1.2 CSPM・DSPM・CNAPPとの違いと重なり
| カテゴリ | 主な対象 | 典型的な問い | AI-SPMとの関係 |
|---|---|---|---|
| CSPM | クラウド基盤の設定・IAM | 公開設定や過剰権限はないか | 土台。AIワークロードもクラウド上にある |
| DSPM | 機密データの所在・アクセス | 機密データが漏れやすい場所にないか | 「学習/RAGデータに機密が混入していないか」で重なる |
| CNAPP | クラウドアプリ全体の保護統合 | コードから実行までを守れているか | AI-SPMを機能として取り込む動きが進行中 |
| AI-SPM | モデル・エンドポイント・エージェント・NHI・プロンプト/設定 | どんなAI資産が・どんなリスク状態で稼働しているか | AI固有の可視化に特化。CSPM/DSPMの上に乗る |
言い換えると、DSPMが「データ」を、CSPMが「クラウド設定」を見るのに対し、AI-SPMは「AIという新しい資産クラス」を見るという分担です。既にCSPM/DSPMを導入済みなら、AI-SPMはその隣に置く新しいレンズだと考えると導入検討がスムーズになります。
1.3 なぜ「一回きりのチェックリスト」では足りないのか
AIガバナンスの出発点として、統合監査チェックリストやNIST AI RMFに沿った棚卸しは非常に有効です。ただし、それらは本質的に「ある時点のスナップショット」です。AI資産は次のスピードで増減・変化します。
- 新しいAIツール／SaaSが部署単位で日々追加される（シャドーAI）。
- 検証用モデルやエンドポイントが「消し忘れ」で本番に残る。
- エージェントに新しいMCPサーバー／ツールが接続される。
- NHI（サービスアカウント・APIキー・OAuthトークン）の権限が拡大していく。
要点：チェックリストは「基準」を与え、AI-SPMは「基準からの逸脱を継続的に検出」する。両者は対立ではなく、基準 × 継続監視のセットで初めて機能します。
第2章：AI-SPMが可視化する4つの対象
AI-SPMを「何を継続ディスカバリするのか」で分解すると、次の4対象に整理できます。導入時は、この4つを資産インベントリの列として設計するとブレません。
| 可視化対象 | 具体的に見るもの | 主なリスク |
|---|---|---|
| ① モデル／エンドポイント | 本番稼働モデル、バージョン、ファインチューニング系譜、公開エンドポイント、外部AI API利用 | 放置エンドポイント、来歴不明モデル、無許可の外部API |
| ② データフロー | 学習・RAG・推論に流れるデータ、ベクトルDB、データ系譜（リネージ） | 機密データのモデル流入、学習データ汚染 |
| ③ エージェント・NHI | エージェント、接続ツール（MCP）、サービスアカウント／APIキー／トークンと権限 | 未承認ツール接続、過剰権限、認証情報の露出 |
| ④ 設定・権限 | システムプロンプト、ガードレール設定、RAGソース、IAMロール | ガードレール無効化、設定ドリフト、最小権限からの逸脱 |
2.1 モデルとエンドポイント
最初の問いは「本番でいま何のモデルが動いているか」です。自社ホスティングのモデルだけでなく、外部AI API（各社のLLM API）への呼び出しも“利用中のモデル資産”として数えます。特に危険なのは、検証・PoCで立てて消し忘れたエンドポイントと、来歴（どのベースモデルを・どのデータでファインチューニングしたか）が不明なモデルです。系譜が追えないモデルは、脆弱性対応もライセンス確認もできません。
2.2 データフロー（データ系譜）
次に「どのデータが・どのモデルに・どの経路で流れているか」を追います。ここはDSPMと最も重なる領域で、狙いは機密データが学習・RAG・プロンプトに意図せず混入していないかの把握です。ベクトルDBに投入した埋め込みが機密を含んでいないか、RAGの参照ソースに社外秘が混ざっていないか、という視点で系譜を可視化します。
2.3 エージェントとNHI（非人間アイデンティティ）
エージェント時代に一気に増えるのがNHI（Non-Human Identity＝非人間アイデンティティ）です。サービスアカウント、APIキー、OAuthトークンなど、人間ではない主体が持つ認証情報を指します。エージェントは人間の代わりに動くため、その権限は人間ユーザー以上に広くなりがちで、しかも棚卸しの対象から漏れやすいのが実情です。「どのエージェントが・どのNHIで・どのツール（MCPサーバー）に・どんな権限で接続しているか」を一枚で見えるようにするのがAI-SPMの中核です。
2.4 設定と権限
最後は「安全側に設定されているか、そしてそれが維持されているか」です。システムプロンプト、ガードレール（入出力フィルタ）、RAGの参照範囲、IAMロールなどが対象です。よくあるのは、デバッグ時にガードレールを一時的に緩めてそのまま、あるいは権限を「とりあえず広め」に付けて縮小し忘れるケース。この“設定の漂流”を差分で検出します。
第3章：継続ディスカバリの実装
ここからが実装の核心です。AI-SPMの「継続ディスカバリ」は、大きく①シャドーAI検出／②MCP・ツール接続の棚卸し／③過剰権限ドリフトの検知の3本柱で回します。
3.1 シャドーAIの検出
シャドーAIとは、IT／セキュリティ部門が把握していないAIの利用・構築です。無許可のAI SaaS利用、私物アカウントでのLLM利用、部署が独自に立てたモデルなどが含まれます。検出の入口は、既存の運用データを使うのが現実的です。
- ネットワーク／プロキシ／DNSログ：AI関連ドメイン・APIエンドポイントへの通信を洗い出す。
- CASB／SaaS棚卸し：契約・利用中のSaaSからAI系サービスを抽出する。
- クラウドの構成情報：AI関連サービス・GPUインスタンス・推論エンドポイントの新規作成を検知する。
検出したら「禁止」ではなく「公認（承認）へ導線を作る」のが定着のコツです。使いたいニーズ自体は正当なことが多いため、棚卸し→リスク評価→公認、の流れに乗せます。
3.2 MCP／ツール接続の棚卸し
エージェントがツールを呼ぶ標準としてMCP（Model Context Protocol）の利用が広がると、「どのエージェントが・どのMCPサーバーに・何の認証で接続しているか」が新たな攻撃面になります。棚卸しでは次を台帳化します。
| 棚卸し項目 | 確認する内容 |
|---|---|
| 接続先MCPサーバー | 自社／サードパーティ／出所不明の区別、承認済みか |
| 公開ツール | そのサーバーが提供するツール（=エージェントが取れる行動）の一覧 |
| 認証方式 | APIキー／OAuth／トークンの種類と保管場所 |
| 権限スコープ | 読み取り専用か、書き込み・削除・外部送信まで可能か |
| データ露出 | ツール経由で外部へ出得るデータの範囲 |
特に出所不明のサードパーティMCPサーバーは、ツール定義自体に悪意ある指示が仕込まれる「ツールポイズニング」の入口になり得ます。承認済みリスト（allowlist）方式で運用し、新規接続は検知して審査に回すのが基本です。
3.3 過剰権限ドリフトの検知
NHIの権限は「付けたら付けっぱなし」で拡大しがちです。詳しくはAgentOps⑥・権限ライフサイクルの記事で扱っていますが、AI-SPMの観点では次の“ドリフト”を継続監視します。
- 付与時からの拡大：初期スコープに対し、後付けで権限が足されていないか。
- 未使用権限：付与されているが一定期間使われていない権限（＝縮小候補）。
- 最小権限／JITからの逸脱：本来は都度付与（Just-In-Time）すべき権限が常時付与になっていないか。
- 孤児NHI：紐づくエージェント／用途が消えたのに残っている認証情報。
実装のコツ：クラウドの権限分析機能（未使用アクセスの検出など）を使えば、専用ツールがなくても「過剰権限NHIの一覧」は今日から作れます。まずは棚卸し→未使用権限の可視化→縮小、の順で回すのが現実的です。
第4章：リスクスコアリングと経営レポート
4.1 資産リスクスコアの組み立て方
資産が並んだだけでは動けません。優先順位を付けるためのスコアリングが要ります。おすすめは「露出 × 影響 × 統制の弱さ」で単純化する方法です。各AI資産に対し、次のような要因を加点していきます。
| リスク要因 | 加点の考え方（例） |
|---|---|
| 公開度 | 外部公開エンドポイント＞社内限定＞オフライン |
| 機密データ接触 | 機密データに触れる資産ほど高い |
| 権限過剰度 | 書き込み・削除・外部送信が可能なほど高い |
| シャドー度 | 未承認・来歴不明ほど高い |
| 既知の弱点 | ガードレール未設定・古いモデル・未パッチ依存 |
厳密な数式より、「同じ基準で全資産を相対比較できること」が重要です。まずは高・中・低の3段階から始め、運用しながら精緻化していきます。
4.2 ISO/IEC 42001・NIST AI RMFへのマッピング
スコアと台帳は、既存のAIガバナンス枠組みにひも付けておくと監査・説明が一気に楽になります。
- NIST AI RMF：4機能GOVERN／MAP／MEASURE／MANAGEに対応させる。継続ディスカバリはMAP（文脈と資産の把握）とMEASURE（測定）、是正はMANAGE、方針はGOVERNに紐づく。
- ISO/IEC 42001：AIマネジメントシステム（AIMS）の運用エビデンスとして、資産インベントリとリスク評価記録を残す。
AI-SPMの出力（資産一覧・リスクスコア・是正履歴）が、そのままこれらフレームワークの“証跡”になる設計にしておくのがコツです。
4.3 経営層に見せる4つのKPI
経営レポートは、詳細な技術指標ではなく「増えているか・減っているか」が一目で分かる少数KPIに絞ります。
- シャドーAI件数（未承認AI資産の数と推移）
- 過剰権限NHI件数（最小権限を逸脱した認証情報の数）
- 未承認MCP／ツール接続数
- 高リスク資産数とリスクスコア推移
この4つを月次で並べるだけで、「対策が効いているか」を経営と共有できます。
第5章：中小企業向けの最小構成
「専用のAI-SPMツールを買わないと始められない」わけではありません。中小企業は既存の道具と手作業から始め、増えたら自動化で十分に成立します。
5.1 まず「AI資産台帳」から始める（コストゼロ）
最初の一歩は、スプレッドシート1枚のAI資産台帳です。列は第2章の4対象に対応させます。
- 資産名／種別（モデル・エンドポイント・エージェント・SaaS）
- 所有部署・担当者
- 接触するデータ（機密の有無）
- 接続ツール（MCP）・NHIと権限
- 公開範囲・承認状況・リスク（高/中/低）
これを作るだけで、「誰も全体像を言えない」状態からは抜け出せます。
5.2 既存ツールで継続ディスカバリを回す
台帳を「手動更新」から「半自動」へ育てます。追加投資を抑えるなら、次の既存機能が使えます。
- シャドーAI検出：プロキシ／DNSログ、既存CASB、SaaS棚卸しからAI系を抽出。
- 過剰権限：クラウドのIAM権限分析・未使用アクセス検出を定期実行。
- 設定ドリフト：既存CSPMのルールにAI関連リソースを追加。
5.3 OSS／商用ツールの選択肢
本格化したら専用機能の導入を検討します。主要クラウドやセキュリティベンダーがCNAPP／CSPMの一機能としてAI-SPMを提供し始めており（例：大手クラウドプラットフォームのAIセキュリティ姿勢管理機能、統合クラウドセキュリティ製品のAI-SPMモジュールなど）、既存のCSPM/CNAPPを使っているなら同系列で拡張するのが移行コストの面で有利です。OSS寄りでは、クラウドの設定監査ツールにAI関連リソースのルールを足す運用から始められます。
導入順序のおすすめ：①資産台帳（今日）→ ②既存ログ・IAM分析で継続ディスカバリ（今月）→ ③リスクスコア＆月次KPI（今四半期）→ ④専用AI-SPM/CNAPP機能へ拡張（必要になったら）。
よくある質問（Q&A）
Q1. すでにCSPMやDSPMを入れています。AI-SPMは別に必要ですか？
土台としては有効ですが、モデルの来歴・エージェントの接続ツール・システムプロンプト/ガードレール設定といったAI固有の資産はCSPM/DSPM単体では見えません。まずは既存ツールの隣に「AI資産の台帳」を足す形で始めるのが現実的です。
Q2. NIST AI RMFの棚卸しをやりました。それで十分では？
RMFは「基準」を与えますが、それ自体はある時点のスナップショットです。AI-SPMは基準からの逸脱を継続検出する役割で、両者はセットで機能します。RMFの4機能にAI-SPMの出力を紐づけると監査が楽になります。
Q3. シャドーAIは「禁止」すれば解決しませんか？
禁止は地下化を招きがちです。検出→リスク評価→公認への導線を用意し、正当なニーズは安全に使える形へ載せ替えるほうが定着します。
Q4. NHI（非人間アイデンティティ）の棚卸しは何から？
まず「どのエージェント／サービスが・どのAPIキーやトークンで・何に接続しているか」の一覧化からです。その後、未使用権限の洗い出し→縮小、と進めます。クラウドの権限分析機能で第一歩は無料で踏み出せます。
Q5. 中小企業でも本当に始められますか？
はい。スプレッドシート1枚の資産台帳＋既存ログ・IAM分析で最小構成は成立します。専用ツールは、資産数が手作業で追えなくなってからで十分です。
まとめ
個別攻撃対策（点）・脅威モデリング（面）・レッドチーミング（検証）・IR（事後）——これらを積み上げても、運用が続けば「いま何のAI資産が・どんなリスク状態で存在するか」は必ず漂流していきます。その漂流を継続ディスカバリで常時可視化し、点の対策を“常時可視の姿勢管理”に束ねるのがAI-SPMです。
要点は3つです。第一に、AI-SPMはCSPM/DSPMを置き換えるものではなく、AIという新資産クラスを見る隣のレンズであること。第二に、チェックリストやNIST AI RMFは基準を与え、AI-SPMは基準からの逸脱の継続検出を担う——両者はセットであること。第三に、始めるのに専用ツールは要らず、資産台帳1枚＋既存ログ・IAM分析から今日でも回せること。
「対策は入れた。でも全体像は誰も言えない」——もし心当たりがあれば、それは点を束ねるレイヤー、すなわちAI-SPMを始める合図です。
参考リンク
- NIST AI Risk Management Framework（AI RMF 1.0）
- ISO/IEC 42001（AIマネジメントシステム）
- OWASP／MITRE ATLAS（AI/MLの攻撃・防御ナレッジ）
コメント