AI-SPM（AI Security Posture Management）実装アーキテクチャ—AIBOM・シャドーAI・ガードレール監視を束ねる5機能の設計

シャドーAIの検出、AIBOMの整備、ガードレールの適用——AI Trust Review（AITR）ではこれまで個別に解説してきたが、現場で問われるのは「これらをどう一つの運用に束ねるか」だ。その答えがAI-SPM（AI Security Posture Management）である。本記事ではAI-SPMの5機能の相互関係と、「収集→評価→是正」の3層パイプラインによる実装アーキテクチャを整理する。点での対策を面に変えるための設計指針として読んでほしい。

1. なぜいまAI-SPMが必要か

AITRが過去に取り上げてきたテーマは、いずれもAIシステムの「ある一面」を捉えたものだった。

• シャドーAI：把握できていないAI利用をどう見つけるか
• AIBOM：AIシステムの部品表をどう作るか
• プロンプトインジェクション：入出力のガードレールをどう敷くか
• MCPスコープクリープ：エージェント権限をどう絞るか

これらは個別に重要だが、バラバラに整備しても「組織としてAIを安全に使えている状態」は説明できない。経営層や監査からの「うちのAI、安全なんですよね？」という問いに、点の対策の積み上げで答えるのは無理がある。

AI-SPMは、これら個別の対策をひとつの姿勢管理（Posture Management）として継続的に評価・改善する基盤として設計される。クラウドセキュリティでCNAPPがCSPM・CWPP・CIEMを束ねたのと同じ構造だ。

2. AI-SPMの5機能と相互関係

AI-SPMが束ねるのは次の5機能である。

5機能は独立ではなく、①AIBOMを起点に他の4機能が繋がる構造になっている。AIBOMが「正規のAI利用の集合」を定義することで、それ以外を④シャドーAIとして検出でき、AIBOMに登録されたコンポーネントに対して②脆弱性スキャンや③ガードレール適用状況を評価できる。⑤コンプライアンスは①〜④のメタデータを規制要件にマッピングして証跡化する。

つまりAIBOM無きAI-SPMは成立しない。これは前回のAIBOM入門で「まずAIBOMから着手すべき」と書いた理由でもある。

3. 実装アーキテクチャ：収集 → 評価 → 是正の3層パイプライン

AI-SPMはイベントドリブンの3層パイプラインで実装するのが現実的だ。

┌─────────────────────────────────────────────────────────┐
│ 収集層 (Collect)                                        │
│  ├─ SASE/SSE（CASB・SWG）/ Proxy / DNSログ              │
│  │                                   → シャドーAI検出   │
│  ├─ 社内AI Gateway（API呼び出しログ） → AIBOM自動更新   │
│  ├─ MCP Registry（接続中のサーバー）  → AIBOM / 脆弱性   │
│  └─ ガードレール製品のイベントログ    → 適用状況         │
└────────────────────┬────────────────────────────────────┘
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 評価層 (Assess)                                         │
│  ├─ AIBOM突合（正規 vs 観測）         → 差分=シャドーAI │
│  ├─ CVE / 改ざん検知                  → 脆弱性スコア    │
│  ├─ ガードレール・カバレッジ計算      → 未適用AIの一覧  │
│  └─ 規制要件マッピング                → 適合性スコア    │
└────────────────────┬────────────────────────────────────┘
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 是正層 (Remediate)                                      │
│  ├─ チケット起票（既存のチケット管理ツール）            │
│  ├─ AI Gatewayでの自動ブロック / 警告                   │
│  ├─ 担当エージェント所有者への通知                      │
│  └─ 監査用エビデンスの自動アーカイブ                    │
└─────────────────────────────────────────────────────────┘

3層の設計上のポイントは次の3つ。

• 収集層は「既存ログの再利用」を最優先する。SASE/SSE（CASB・SWG）・Proxy・社内AI Gatewayはすでに動いているケースが多く、AI-SPM専用エージェントを各端末に入れる発想は最後の手段。
• 評価層では「正規＝AIBOM」を絶対の基準に据える。観測ログとAIBOMの差分を機械的に計算できる構造にしておけば、シャドーAI検出は自然に派生する。
• 是正層は既存のチケット運用に同居させる。AI-SPM専用ダッシュボードだけだと「見られない」運用になりがち。SOCのSIEMアラートと同じワークフローに乗せると定着する。

4. CNAPPからAI-SPMへ — 既存SOCチームが横展開する動線

AI-SPMはゼロから作る新領域ではなく、CNAPPの方法論を継承して構築できる。両者の対応関係は次のとおり。

運用面で重要な含意は、AI-SPMは情シスやSOCの新規ヘッドカウントを必須としないということだ。CNAPPを運用しているチームは、ログソースとルールセットを差し替えるだけで多くの機能を継承できる。

逆に言えば、CNAPPすら未整備の組織にとってAI-SPMはハードルが高い。その場合は、まず**「AIBOM＋ガードレール製品やAIゲートウェイ（DataSignのAI MONBAN等）のログ活用」**という最小構成からAI-SPMを段階的に立ち上げるのが現実解になる。AI-SPMを掲げる製品も登場しているが、対象範囲は製品ごとに異なるため、既存基盤を組み合わせるアプローチも現実的な選択肢になる。

5. 3軸評価との接続

AI-SPMは3軸評価フレームワークのうちTrust軸を運用で証明する基盤として位置付けられる。

• Technology軸：脆弱性スキャンとガードレール・カバレッジで、技術的な健全性を継続評価する
• Business Value軸：AIBOMに紐づく利用ログから、どのAIが何の業務にどれだけ貢献しているかを可視化する
• Trust軸：シャドーAI検出・コンプライアンス・監査エビデンスにより、「説明できる状態」を担保する

PoC前のチェックリスト（3軸評価）が入口の判断を支えるのに対し、AI-SPMはPoC後の運用での証明を支える。両者は時系列で補完関係にある。

6. 導入チェックリスト：最初の30日で立ち上げる8問

完璧なAI-SPMを最初から構築する必要はない。次の8つの問いにYesで答えられる状態を、まず30日で目指す。

• 業務利用しているLLMサービスのトップ10を、ログから把握できているか
• それらのうち、法人契約のあるものが何割かを把握しているか
• 自社プロダクトに組み込んだAI機能の一覧（簡易AIBOM）を持っているか
• エージェントが呼ぶMCPサーバー / 外部APIの一覧を持っているか
• 各AIにどのガードレールが適用されているかを表で説明できるか
• EU AI Act / 改正個情法のうち、自社が該当する条項を整理しているか
• 上記の差分・例外を検出した際の通知先（担当・チャンネル）が決まっているか
• 監査時に出すエビデンスのフォーマットを1つ決めているか

8問すべてにYesになれば、AI-SPMは「最低限の継続運用に乗った」状態と言える。そこから②脆弱性スキャンや④シャドーAIの自動化を段階的に深めていけばよい。

関連：AITBの3 Pillars / 3軸評価フレームワーク ／ AIBOM入門 ／ シャドーAI

AI-SPMの初期立ち上げ・既存CNAPP運用との接続設計についてのご相談は AITBの無料相談 から承ります。