—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
「監査可能性」がモデル層で止まれば統治は芝居になります。IntelのOCIが、監査証跡はチップからゲートまで一貫したテレメトリでつなぐべきだと示します。
ガバナンスチームがリスク評価を実施し、モデルカードに承認印を押し、文書を整えているとしても、それだけでは監査に耐えられないことがあります。監査で求められるのは、インシデント発生時に「何が、AIスタック全体で実際に変わったのか」を組織が説明し、裏づけられるかどうかです。
しかし不都合な真実があります。多くの場合、「AIガバナンス」は政策のファイル綴じのように振る舞っています。文書を整理することはできても、規制当局が求めるレベルの“証明”を生み出してはいないのです。
このギャップを最も露わにするのが、インフラ層の存在です。IntelのOptical Compute Interconnect（OCI）のチップレット実証は、高速なAIデータセンター通信のために設計されており、最初の実装では**双方向で最大4テラビット毎秒（Tbps）**のデータ転送を支えるとされています。(Intel press release)
この種の建築的な加速は、レイテンシーを抑えスループットを高める一方で、「何が起きたか」を再構成しにくくします。失敗（あるいは政策上重要な逸脱）は、光学系の問題として発生することもあれば、ノード単位のオーケストレーションに由来することもあります。また、スケジューリングからデプロイメントへの引き渡し部分で生じることもあるからです。
したがって問いは構造的になります。組織は、**インシデント責任（incident accountability）**を、テレメトリと制御（controls）にエンドツーエンドで結びつける監査証跡パイプラインを生成できるのでしょうか。証拠が光学相互接続の境界で途切れる、あるいはクラスタ・スケジューラの境界で断絶するなら、企業のリスク機能は「物語」ではなく「証明」に依存できなくなります。
Optical Compute Interconnect（OCI）は、より速いケーブルではありません。それは、物理層と論理層のあいだに新しい制御面（control surface）を持ち込みます。チップレット、光学I/O、データセンターネットワークの振る舞い、そして決定的に重要なのは、「どこでワークロードを動かすか」を決めるソフトウェアです。Intelは、OCIがIntel CPUプラットフォームと統合され、実証では「ライブデータ」を用いることを明確に述べています。つまり、状態はMLの成果物だけでなく、計算と相互接続の振る舞いにまたがって成立するのです。(Intel press release)
「計算と相互接続にまたがる」点が、証拠パイプラインが破綻する大半の理由です。ログが存在しないからではなく、ログが相関（correlatable）できないからです。実務上、アプリケーションサーバーやモデルサーバーから豊富なテレメトリを集められても、監査で必要になるのがインシデント時に効くクロスレイヤーの結合だと、監査は失敗します。
これが重要なのは、現代のAIオペレーションがすでに“ゲートの連鎖”だからです。すなわち、ハードウェアの準備状況 → クラスタ・スケジューリング → データ／モデル段階の選択 → デプロイ承認 → 実行時の強制（runtime enforcement）。ゲートを独立したものとして扱うガバナンス戦略は、継ぎ目で失敗します。そこでは、テレメトリが存在するかどうかではなく、テレメトリが次の問いに答えられるかが決定的です。入場時の境界条件のもとで、どの“正確な”ワークロードと“正確な”アーティファクトが、どの承認ゲートで承認されたのか？
NISTのAIリスク管理枠組み（AI RMF 1.0）は、信頼できるAIには、設計、開発、利用、評価の各段階にリスク管理を埋め込む必要があると強調しています。事後の“信頼の宣言”に留めるべきではありません。(NIST AI RMF 1.0 landing page)
スタックに高帯域の光学相互接続のような“高速パス”が入ると、監査可能性の要件は「監視したか」から**「判断が下された時点で、同じ証拠キーで監視できていたか」**へと拡張されます。制御の検証は、相関設計の問題になります。識別子はチップ／プラットフォームのテレメトリ、スケジューリングイベント、デプロイメントゲート承認で一貫しているのか。さらに、インシデントのトリアージを生き残れるだけの保持期間があるのか。ここが勝負です。
実務上のガバナンス戦略は、監査証拠を“産物”として捉え直すことから始まります。
「書類はあるか？」ではなく、
「インシデント発生時に、すべての重要な制御について、機械検証可能な証拠を出せるか？」と問うのです。
このとき、規格の言語が実装可能な形に落ちてきます。たとえばISO/IEC 42001:2023（AIマネジメントシステム）は、監視／測定と内部監査を継続的なシステムの一部とみなし、結果についての文書化された証拠を求めています。(ISO/IEC 42001 text (download))
証拠が継続的に生成され、判断と結びついていないなら、劣化します。特にインフラが変化する局面では、その劣化は致命的になり得ます。
以下は、ガバナンスチームが構築できるエンドツーエンドの形です。（目的は「何でもログに残すこと」ではなく、制御検証を支える証拠を生成することです。）
OpenTelemetryのGenAIセマンティック規約は、組織がテレメトリの形を標準化するための要素の一つです。OpenTelemetryプロジェクトは、生成AIのセマンティック規約（イベントやスパンを含む）に関する仕様を公開し、AIワークフローのテレメトリを標準化して、システムをまたいで一貫して分析できるようにすることを意図しています。(OpenTelemetry GenAI semantic conventions docs)
多くのガバナンス上のインシデントは「モデルだけ」の出来事ではありません。それはライフサイクルの出来事です。
不適切なデプロイ、破損したアーティファクト、誤設定されたランタイム、あるいは政策上重要な異常は、しばしばオーケストレーション層から立ち上がります。スケジューラがワークロードを別の場所に置いた、アドミッションチェックが迂回された、あるいはロールアウトゲートが必要条件を満たさないアーティファクトを受け入れた――というパターンです。
NISTのAI RMF 1.0は、マッピング、計測、管理、そしてガバナンスプロセスといった機能を含み、ライフサイクル全体でリスク処理を改善するための枠組みを提示しています。(NIST AI RMF 1.0 landing page)
ただし、枠組みは実装上の選択をまだ要求します。どう測るのか。どう監視するのか。証拠を“生む”設計はどうするのか？ ここが実装の核心になります。
責任を検証可能にするには、スケジューリングとデプロイメントの行為に伴う「制御の受領書（control receipts）」を実装すべきです。受領書は、ただ保存されるだけではなく、自動的に検証できる形で同梱されなければなりません。
最低限、受領書には再検証を支える4つの要素が含まれるべきです。
admission_decision_id、deployment_approval_id）。意思決定の地点で生成します。job_id、model_artifact_hash、runtime_config_hash、必要に応じてcluster_version／firmware_version識別子）。これにより責任は、再現可能なクエリになります。
「時刻Tに、モデルアーティファクトXのデプロイ承認IDが何であるか。その承認が下された時点で有効だった相互接続健全性クラスと、スケジューラのアドミッション制約を示せ」という問いです。受領書が自動的に結合できない場合、組織は監査人に対して“ベストエフォートの調査”を求めているに等しくなります。制御検証ではなく、捜索の作業になってしまうのです。
ISO/IEC 42001のシステム論――継続的監視と内部監査、そして文書化された証拠――は、このエンジニアリングの発想を支えます。証拠は、監査人が尋ねた後に用意されるのではなく、必要になる時点で存在しなければならないからです。(ISO/IEC 42001 download)
英国では、規制当局がガバナンスを監査証跡（audit trails）やアクセスログの観点で説明しています。これは、証拠パイプラインが実世界に存在しなければならないことを示す強いシグナルです。情報コミッショナー・オフィス（ICO）は「AIにおけるガバナンスと説明責任」に関するガイダンスを公開し、データセットへのアクセスをログし監視するために包括的な監査証跡を整えることを含めています。(ICO: Governance and accountability in AI)
またICOは、法改正によりガイダンスが更新され得ることにも触れています。具体的には、2025年6月19日に施行される「Data (Use and Access) Act」を明示的に挙げ、そのガイダンスがレビュー中であることを記しています。(ICO guidance page)
ガバナンスチームにとっての実務上の教訓は、証拠パイプラインが運用層でのデータと判断の統治方法をカバーしていなければ、法改正のタイミングで監査ストーリーが崩れ得るという点です。
ゆえに戦略は変化に耐える必要があります。政策、デプロイのスケジュール、インフラのバージョンが変わっても、制御がテレメトリへ対応づけられる状態を維持する設計が求められます。
理論からシステムとしての説明責任へ移るには、事例の“土台”が必要です。
何が起きたか： Intelは、Intel CPUと共同パッケージされた、統合型の光学コンピュート相互接続（OCI）を実証し、ライブデータを動かしました。最初のOCI実装は、双方向で最大4Tbpsのデータ転送を支えるとされています。(Intel press release)
タイムライン： プレスリリースは、実証がOFC 2024に関連していることを述べ、実装の詳細を示しています。(Intel press release)
ガバナンス上の含意： 光学相互接続が計算プラットフォームの一部になると、インシデント調査には相互接続境界をカバーするテレメトリが必要になります。そうでなければ、「デプロイメントゲートが発火した時点で、どのインフラ状態が存在していたか」を再構成できません。“ガバナンス”は復元不可能になります。
何が起きたか： OpenTelemetryは、生成AIセマンティック規約の仕様書を公開しています。これは、AIワークフローをまたいだトレーサビリティと分析性を高めることを意図した標準化されたテレメトリ語彙を提供するものです。(OpenTelemetry GenAI semantic conventions)
タイムライン： ドキュメントはOpenTelemetryプロジェクトの一部として公開され、維持されています。アドホックなログから、標準化された計装（structured instrumentation）へ移行していく流れを示しています。(OpenTelemetry docs)
ガバナンス上の含意： テレメトリの意味論が標準化されていないと、証拠パイプラインは個別対応になりがちです。標準化されたセマンティック規約があるなら、企業のリスクチームは、クラスタ、モデル、デプロイメントをまたいで一貫して制御を検証できます。とりわけ、インシデント責任を問われる局面で効いてきます。
これらは単なる“ガバナンスの失敗”ではありません。むしろ、監査に耐えられるガバナンスを成立させるためのインフラとテレメトリの前提条件を定義しているのです。
ガバナンスチームは、硬い目標を必要とします。以下の数値は、保持期間、カバレッジ、相関時間、検証間隔といった制御パラメータに変換すべき“種類”のものです。
標準やガイダンスを横断する専門家の方向性は一貫しています。ガバナンスは、実行の“織り地”の中に入り込んで初めて機能します。NISTは、AI RMFを、信頼性（trustworthiness）の考慮をAIシステムの設計、開発、利用、評価に組み込むための枠組みとして位置づけており、信頼を外部メッセージとして扱う考え方を退けています。(NIST AI RMF 1.0 page)
OECDもまた、透明性と説明責任は相補的な概念であり、説明責任は一度きりの開示ではなく、監視と継続的なリスク管理に依存すると整理しています。(OECD: Governing with Artificial Intelligence)
一方、OpenTelemetryのアプローチは、監査証拠をより“持ち運び可能”にする道筋も示します。テレメトリが標準的な語彙に従うなら、証拠パイプラインは組織の境界やシステム変更をまたいで監査可能になります。光学相互接続やクラスタ基盤が、ガバナンスプロセスの更新より速く進化する時代には、これは不可欠な性質です。
機能するガバナンス戦略は、次のような形になります。
ここで、エンドツーエンドのシステムとしてのガバナンスが「書類コンプライアンス」を上回ります。テレメトリと制御が相関していないなら、インシデントはブラックボックスになり、ブラックボックスは監査証拠の要件を満たせません。
AIガバナンスは“証拠の時代”へ入ります。最も防御力の高い戦略は、単に文書を作ることではありません。AIスタック全体にわたり、制御に紐づく監査グレードのテレメトリを生成することです。とりわけ、障害が生まれやすいインフラ境界での整合が要になります。
英国政府は、ICOおよび関連するアシュアランスの利害関係者を通じて、AIクラスタ・インフラの調達およびデプロイ契約に「設計により監査可能にする（auditability-by-design）」条項を含めることを求めるべきです。
具体的には、以下3点についてテレメトリカバレッジと証拠の相関を提供することを、契約上コミットさせる必要があります。
（1）相互接続の健全性信号、（2）クラスタ・スケジューリング判断、（3）デプロイメントゲート判断。
これは、AIガバナンスと説明責任に関する包括的な監査証跡とデータアクセスのロギングを重視するICOの考え方と整合します。(ICO: Governance and accountability in AI)
2027年Q4までに、高スループットの相互接続技術（IntelのOCIのような光学相互接続アプローチを含む）を用いるAIクラスタ・インフラを導入する企業は、自社の内部リスク機能と外部アシュアランスの双方から、監査証拠のパッケージングの一部として、**インフラ状態テレメトリとモデルデプロイメントゲート結果の“エンドツーエンド相関”**を示すことを求められる見込みです。
この予測の根拠は単なる“方向性”ではなく、監査のメカニズムそのものにあります。アシュアランス側は次を求めるからです。
（a）証拠の完全性（必要な信号が、特定の意思決定に対して生成されているか？）
（b）証拠の完全性（保存された参照が意思決定アーティファクトへ再結合できるか？）
（c）証拠の適時性（テレメトリ・スナップショットとゲート判断の間にシステムが変わり得たのか？）
これらの問いは、NIST AI RMF 1.0のライフサイクルガイダンス、ISO/IEC 42001:2023におけるシステム証拠の期待、そしてICOガイダンスで強調されるトレーサブルな監査証跡とアクセス統治の重要性へ、直接対応しています。(NIST AI RMF 1.0 page, ISO/IEC 42001 download, ICO guidance page)
次にすべきことは、いま計装を始めることです。次の調達サイクルの前に「受領書の監査（receipts audit）」を実行してください。代表的なトレーニングまたは推論パイプラインを1つ選び、光学／ネットワークの入場、スケジューラの入場、デプロイ承認における制御ポイントを定義します。そして、機械検証可能な結合（decision IDs → テレメトリ参照 → モデルアーティファクトハッシュ）で、再実行できるインシデントの物語を作れるか試してください。もし1週間で答えられないなら、後々インシデント圧力が高まったときには苦戦します。相関窓が締まり、システムがフェイルオーバーし、必要になる境界テレメトリがもう利用できない可能性があるからです。
要するに、ガバナンスはモデル層だけでは解決できません。ガバナンスは、制御プレーンとして設計され、証拠を継続的に生み続ける必要があります。モデルが実行を許される瞬間まで含めてです。