—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
NISTの重要インフラ向けAI RMFが監査チェックリストとして機能し始めている。本稿では、AIガバナンスをOT（運用技術）環境におけるアクセス制御、監視、変更管理、そして監査対応可能な証跡管理へと接続するための指針を解説する。
OTの制御室オペレーターは、アラームの発生と消滅を視覚的に把握できます。しかし、彼らに見えていないのは、その背後にある「意思決定のプロセス」です。どのAIツールがその解釈を導き出したのか、どのようなデータが消費されたのか、そしてそのツールはメンテナンス期間中に更新されていたのか――こうした情報は往々にしてブラックボックス化しています。
これこそが、NIST（米国国立標準技術研究所）の重要インフラ向け「AI RMF（AIリスク管理フレームワーク）」ドラフトコンセプトノートが解決しようとしている運用のギャップです。このノートは、ガバナンスの課題を監査チームが管理策や証跡パイプラインへと落とし込める言語で定義しています（NIST Draft Concept Note, Trustworthy Use of AI in Critical Infrastructure Profile）。実務上の転換点はシンプルです。ガバナンスを単なる理念の羅列に留めてはなりません。システムアクセス、モデルやツールの変更、テレメトリ、インシデント対応、そして監査人が検証可能な証跡を繋ぐ「測定可能なチェーン」へと進化させる必要があります。
CISA（米サイバーセキュリティ・インフラセキュリティ庁）のガイダンスは、「既知の悪（Known Bad）」という枠組みを明確にしています。CISAの「既知の悪用された脆弱性（KEV）カタログ」は、実際に悪用されている脆弱性のリストであり、組織はこれに基づく是正が求められます。これはAIガバナンスにおいても重要です。AIプラットフォームを構成する要素（OSイメージ、コンテナベース、モデル配信スタック、オーケストレーションノードなど）も、他のインフラと同様のパッチ適用サイクルに従う必要があるからです（CISA Known Exploited Vulnerabilities Catalog）。監査の焦点は、「AIを導入したOT環境が、信頼できるテレメトリと安全ロジックを維持するために、既知の脆弱性を十分に回避できていたか」という点に集約されます。
NISTのドラフトコンセプトノートでは、重要インフラにおけるAIのガバナンス課題として、信頼性の高い利用を「主張」するだけでなく、運用レベルでいかに「実証」するかについて論じています。実務者にとって、測定できないガバナンスの課題は、アクセス制御、変更管理、インシデント対応、そして監視における死角となります。
以下に、アーキテクチャレビューや監査準備で活用できる管理策のマッピングを示します。
・アクセスガバナンス：AIツールがOTの結果に影響を与える場合、特権的なインターフェースとして扱う必要があります。モデルやツールの展開者、および運用環境で推論を要求できるユーザーに対し、強力な認証・認可を義務付けてください（NIST SP 800-63-4によるアイデンティティ保証の指針を参照）。 ・変更ガバナンス：ガバナンスには追跡可能性が不可欠です。コミットからアーティファクトのビルド、デプロイ、そしてOTへの影響期間までを紐付ける変更記録が必要です。NIST SP 800-161 Rev.1の更新版は、ソフトウェアコンポーネントのセキュアなコーディングとサプライチェーンについて直接言及しており、モデルをデータアーティファクトとして扱う場合でも、AIソフトウェア（モデルサーバー、プロンプトテンプレート、データパイプライン）の管理に適用できます（NIST SP 800-161r1-upd1）。 ・監視ガバナンス：監視を単なる「アラートの記録」に留めてはなりません。AI特有の証跡（使用したモデルバージョン、入力特徴量、出力結果、下流のOTシステムへの影響）を含める必要があります。これは、一度の信頼付与ではなく、アクセスやデバイス・ユーザーの状態を継続的に評価するというCISAのゼロトラストの原則と一致します（CISA Zero Trust）。 ・インシデントガバナンス：インシデント対応の手順書（プレイブック）では、AIの挙動を「シグナル」として扱う必要があります。CISAのランサムウェア対策ガイダンスが強調する準備、対応連携、復旧の基本原則を、インシデント発生前に運用環境に影響を与えた可能性のあるAIシステムにも適用してください（CISA Ransomware）。
鍵となるのは「監査証跡への変換」です。ガバナンス管理策は、監査当日にエンジニアがフォレンジックを行う必要がないよう、ログアーティファクト、承認記録、追跡記録を生成するものであるべきです。
OT環境において、監査可能性は「設計上の制約」として扱うべきです。次のAIパイロット運用を開始する前に、各AIツールに対して「許可されたアクセス経路」「記録されたデプロイ変更」「推論テレメトリ」「AIが意思決定に及ぼした影響を明示したインシデントプレイブック」のセットを義務付けてください。
重要インフラでAIを使用する場合、ベンダーや運用者は「ブラックボックス」という説明に頼ることはできません。モデルやツールの系譜、意図された使用上の制約、制限事項、システム監視方法など、開示をサポートする構造化された証跡パイプラインが必要です。NISTのコンセプトノートが信頼性の高い利用を定義しているのは、まさに証跡生成がガバナンスの一部であるためです。
課題は「モデルを説明できるか」ではなく、「OTシステムが意思決定を行った02:14 UTCの時点で、正確にどの挙動が実行されていたかを再現できるか」にあります。その再現には、時間が限定され、識別子と紐付いており、かつ消失耐性のある証跡が必要です。
証跡パイプラインは契約上の要件にもなります。ベンダーに透明性の確保を求めるなら、PDFやスライドではなく、貴社のセキュリティツールが取り込める形式のアーティファクトを調達要件に含めるべきです。証跡は機械可読であり、インシデントのタイムラインで使用する識別子と一致させる必要があります。
実務においては、以下の取り込み要件と保持ルールを定義してください。
・モデル・ツールインベントリ：不変の識別子（コンテナイメージのダイジェストや署名鍵のフィンガープリント、モデルのハッシュ値など）に基づいたインベントリデータ。 ・推論ログの仕様：リクエスト/推論ID、タイムスタンプ（タイムソース明記）、モデル/ツールバージョン、入力特徴量リスト（またはハッシュ化）、出力スコア、下流のターゲット識別子を含むログ契約。 ・評価アーティファクトとシナリオ追跡：インベントリ識別子と紐付いた評価実行結果。攻撃やストレス条件、テストケースを含め、本番環境の挙動と比較可能にすること。 ・デプロイからOTへの影響期間を網羅した変更記録：全ての変更（モデル、プロンプト、データパイプライン等）に対し、承認メタデータとOTへの影響期間を記録。 ・インシデント対応の証跡フック：調査時にエクスポート可能な証跡パッケージ。誰が、どこで、何を操作し、何に影響を与えたかを回答するために必要な最小限のログとマッピング。
CISAのゼロトラスト成熟度モデルは、能力の成熟度を測るための有用な指標となります（CISA Zero Trust Maturity Model Version 2）。ベンダーに証跡開示を求める前に、ログのスキーマや結合キーを設計し、インシデント発生時に即座に活用できる体制を整えてください。
AIがOT/ICS（産業制御システム）に関与する場合、単なるAIリスク管理の声明以上のものが必要です。NIST AI RMFの期待値と、既にSOCやOTエンジニアリングで運用しているサイバー管理策との「クロスウォーク（対応表）」を作成し、運用を止めることなく監査に合格できる体制を構築してください。
・インベントリの整備：OTに影響を与える、またはOT関連データを処理する全てのAIツールを特定し、バージョン、イメージダイジェスト、設定を追跡します。 ・ツール許可リストの定義：各OTゾーンで実行可能なツールを制限し、広範な暗黙の信頼を排除するゼロトラスト原則を適用します。 ・推論ログの実装：入力ソース、バージョン、タイムスタンプ、出力スコア、ターゲット識別子を最低限記録し、AIの挙動をインシデントのタイムラインに紐付けます。
・評価アーティファクトの蓄積：シナリオ追跡を伴う評価結果を、本番環境のログと同一の識別子で記録します。 ・AI経路のレッドチーム演習：攻撃者がAIの入力を操作したり、信頼性を低下させたりできるかを確認する証跡を作成します。 ・プレイブックの更新：AIの出力をリスクシグナルとして扱い、SOCがAIテレメトリに基づいて影響を受けるツールバージョンや入力ソースを隔離できる手順を整備します。
AIプラットフォームも結局はソフトウェアです。攻撃者は「AIを破壊」する必要はなく、配信レイヤー、テレメトリパイプライン、アイデンティティ制御を侵害するだけで十分です。CISAのKEVカタログを活用し、モデルサーバーやオーケストレーションノードを優先的にパッチ適用対象としてください。また、AIの推論やデプロイ操作には、例外を認めないアイデンティティベースの認可を強制してください。
侵害発生時、セキュリティチームにとって最大の難関は検出ではなく「証跡の確保」です。システムが復旧・再構築される間も有効なログ、変更記録、タイムラインの整合性が必要です。NIST SP 800-61 Rev.3を骨子とし、AI特有の証跡要件を各段階（準備、検出、分析、封じ込め、根絶、復旧）に組み込んでください。
NISTの重要インフラ向けAI RMFは、単なる理念ではなく「運用チェックリスト」へと変貌しています。監査の圧力は、AIポリシーの有無ではなく、「AIが何を許可され、実際に何を行い、障害時にどう対応したか」を機械検証可能な証跡で示せるかどうかにかかっています。
今後180日間で、インシデント対応とゼロトラスト成熟度測定を既に運用している組織は、それらのシステムをAI推論とツール展開にまで拡張するでしょう。監査は「AIポリシーを見せてください」から「証跡の追跡記録を見せてください」へとシフトします。AIセキュリティの証跡パイプラインを先に構築し、OTへの影響を推測ではなく「追跡可能な変数」として管理してください。