—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
ランサムウェアがAIの「死角」を突く今、AIガバナンスには監査可能な証跡が不可欠です。本稿では、重要インフラを守るため、CISAの対応ガイダンスとNIST AI RMFの管理策をいかに統合すべきかを論じます。
ランサムウェアの被害が発生した日、それが「攻撃の始まり」であることは稀です。多くの場合、以前から存在していた侵害経路やID保護の不備、監視の隙を突かれ、攻撃者に時間を稼がれた結果として表面化します。米国サイバーセキュリティ・インフラセキュリティ庁（CISA）がInterlockランサムウェア対策に関する共同勧告を発出したのは、まさにこのためです。この勧告には、予防策に加え、疑わしい活動を検知した際の明確な運用手順が示されています。（CISA共同勧告）
Interlockが重要視される理由は、それが組織の「多層防御」における綻びを浮き彫りにするからです。アラートを解釈できる人員が限られている、インシデント対応手順書（プレイブック）がID管理やログ収集と連携していない、あるいは「ガバナンス」がツールの進化についていけないスプレッドシート管理に留まっている――。こうした状況こそが、ランサムウェア集団が狙う隙であり、対応の遅延を招く原因となります。CISAのランサムウェア対策ガイダンスは、「予防と対応能力は別個の規律ではない」と断言しています。これらは手順、可視性、そして復旧準備を通じて一体化されていなければなりません。（CISAランサムウェア対策ガイド）
ここにAI運用が加わると状況はさらに複雑になります。現在、多くの重要インフラ組織が、アラートのトリアージ、資産分類、異常検知などにAIを活用しています。AIは有効な武器となり得ますが、同時に「モデルのドリフト（性能劣化）」「ベンダーの仕様変更」、そして監査証跡が設計に組み込まれていない場合に生じる「誰が何を承認したのか」という問いといった、新たな失敗モードももたらします。本稿の目的は明確です。AIガバナンスを単なる事務作業と捉えるのをやめ、設計段階から監査可能性を担保する「コントロールスタック（管理策の積み重ね）」として扱うことです。NISTの重要インフラ向けAI RMFプロファイルのコンセプトノートは、「AIの信頼できる利用（Trustworthy Use of AI）」というアプローチでその方向性を示しています。（NIST AI RMFプロファイル・コンセプトノート）
Interlockのようなランサムウェアへの対処は、単一製品の問題ではなく、管理策の統合問題として捉えてください。AIガバナンスの証跡には、インシデント発生時に、ID管理、監視、データ整合性、インシデント対応の各制御が正常に機能していたこと、そしてモデルの進化に伴う変更が安全に行われていたことを証明する能力が求められます。
NISTのサイバーセキュリティフレームワーク（CSF）プロファイルは、各組織が自身のコンテキストに合わせてCSFの成果やカテゴリーを調整するために活用されています。（NIST CSFプロファイル）AI RMFプロファイルも同様に、既存のセキュリティ運用と並行して実装・テスト・証明可能な「コントロールスタック」として活用すべきです。
重要なのは「ポリシーのマッピング」ではなく「管理策のマッピング」という視点です。これは運用上の難問を突きつけます。「インシデント発生時、どの管理策が有効で、どのシグナルが監視され、どのような行動が取られ、AIコンポーネントの挙動に対してどのような承認フローが適用されたのか」を即座に示せるでしょうか。Interlockのような事案では、タイミングと意思決定の質がすべてです。AI層が検知や優先順位付けに関与している場合、そのデータ系列、構成、変更履歴を再現できなければ、運用上の安定性を守ることはできず、意思決定の妥当性を説明することもできません。
ここで「設計による監査可能性（Auditability by Design）」が運用上の実体となります。AIシステムは進化し続けます。モデルの再学習、プロンプトの更新、サードパーティ製コンポーネントの入れ替え、ベンダーによるパッチ適用などが日常的に行われるため、ガバナンスの証跡はこうした変化に耐えうるものでなければなりません。
NISTのCSF 2.0クイックスタート構造は、テンプレートと実装オプションに焦点を当てており、優れた基準となります。テンプレートが重要なのは、ガバナンスを「後から監査人が追いかけるもの」から「エンジニアが実行するもの」へと変えるからです。（NIST CSF 2.0 クイックスタート・ガイド）目指すべきは、ログ記録や構成管理、変更管理のために既に利用しているパイプラインを通じて、AIガバナンスの証跡が自動生成される仕組みです。
「AIガバナンスがあるか」を問うのはやめましょう。「インシデントの証跡を作成するのと同じ時間枠で、AIガバナンスの証跡を作成できるか」を問うべきです。AIの変更履歴、モデル・データ系列、承認記録を、SOCやインシデント対応チームが既に依存している運用ワークフローに組み込んでください。
CISAのランサムウェア対策資料は、予防と対応の実践を強調しています。（CISAランサムウェア対策ページ）管理策のマッピングは具体的であるべきです。すべてのランサムウェア対策は、検知、調査、封じ込め判断、データ処理に影響を与えるAI制御と紐付ける必要があります。
・IDおよびアクセス管理：ランサムウェアはIDの弱点を突いて横展開（ラテラルムーブメント）します。AIがアクセス変更を推奨する場合、その推奨が正確なIDデータに基づいていること、および通常のワークフローで承認されていることの証跡が必要です。 ・データの整合性とログ記録：ログが改ざんされたり不完全だったりすると「真実」が失われます。ログのトリアージを行うAIには、整合性が保証されたログを消費していること、およびどのログイベントをアウトプットに使用したかの記録を保持することが求められます。 ・監視と検知：AIを監視に利用する場合、測定可能なパフォーマンス閾値を設定し、ドリフト検知によってロールバックや人間のレビューをトリガーできるようにします。 ・インシデント対応：CISAが求めるインシデント対応能力の要件を満たすには、モデル更新や構成変更でAIの挙動が変わっても、対応プレイブックが一貫性を保てるかどうかが運用上の試験となります。
AI支援ワークフローの「1対1セキュリティ管理策マッピング」を作成してください。セキュリティ判断に関与するすべてのAI機能に対し、ランサムウェア対策ガイダンスのどの管理策に対応するかを明記し、保存すべきAI固有の証跡を定義します。
モデルのドリフトは、本番環境では検知の質の低下や、アナリストを疲弊させる誤検知の増加、封じ込めを遅らせるシグナル漏れとして現れます。監査可能性を設計段階から組み込むとは、インシデント後に証跡をかき集めるのではなく、変更の瞬間に証跡を作成することを意味します。
具体的には以下の記録が必要です。 ・構成スナップショット：デプロイ時のモデルバージョン、プロンプトテンプレート、機能フラグ、依存関係を記録します。 ・データ系列（リネージ）：出力生成に使用されたデータセットやログソースを記録します。 ・意思決定ログ：AIの出力と影響を与えた入力、および人間による承認（承認/拒否）を記録します。 ・ロールバック能力：ドリフト閾値を超えた場合に、既知の正常な構成へ戻せるようにします。
ドリフトを「本番環境の停止リスク」と見なしてください。セキュリティ運用で使用されるすべてのAI更新に対し、インシデント対応チームが即座に照会可能な証跡（モデルバージョン、入力系列、人間の判断記録）を生成するよう義務付けます。
多くの環境で失敗の要因となるのは、ツール不足ではなく、検知・調査・対応の間のワークフローの分断です。AIが介入する際、SOCが証跡の連鎖を伴わないブラックボックスなアウトプットを受け取ってしまえば、ガバナンスやインシデント後の学習は不可能です。
堅牢なワークフローの例：
AIの出力をインシデント管理システムの「監査可能なフィールド」にしてください。SOCには「AIがXを推奨した」という記録だけでなく、なぜそう判断したのかを証明する証跡の束（モデルバージョンと入力系列）を紐付けるよう徹底させます。
「感覚」に頼ったガバナンスを避けるため、以下の指標を追跡してください。 ・証跡完全性率（ECR）：必須証跡がすべて揃ったAI支援チケットの割合。 ・証跡の網羅率（EAC）：AI出力のうち、アナリストの行動と証跡が紐付けられた割合。 ・意思決定ログの整合性成功率（DLISR）：入力、構成ポインタ、出力、人間の承認がイミュータブル（追記のみ可能）な形式で記録された割合。 ・ワークフロー時間の変化（ΔTTA）：AI導入前後での初動までの時間変化。
完璧なAIメトリクスを待つ必要はありません。まずは証跡の完全性とワークフローの時間を測定し、どのAIアラートが監査可能で、それが対応速度や品質にどう寄与したかを可視化するダッシュボードを構築してください。
AIガバナンスを「コンプライアンスの産物」から「インシデント対応を支える安全装置」へと昇華させてください。