—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
EU AI法への対応は、単なる透かし（ウォーターマーク）の付与にとどまりません。2026年8月までに、機械可読な来歴情報、ツール呼び出しの追跡、そして改ざんを検知可能なログをパイプラインに組み込むことが不可欠です。
エージェントや生成AIのパイプラインにおいて、真の脅威は「来歴情報がドキュメントに存在しないこと」ではありません。真の問題は、モデルが何を認識し、何を出力するかを決定するパイプラインのコンポーネント自体によって、来歴情報が回避、削除、あるいは改ざんされ得る点にあります。
これは本質的に「完全性（インテグリティ）」の課題です。「何が生成されたのか」「どのツール呼び出しによって生成されたのか」「どのような入力を用いたのか」「どのようなポリシー制約下にあったのか」を証明できなければ、コンプライアンス対応は単なるチェックボックスの埋め合わせに過ぎず、むしろ攻撃対象領域（アタックサーフェス）と化してしまいます。
米国連邦政府の指針では、すでに「事後的なセキュリティ対策」ではなく「設計段階からのセキュリティ（Secure by Design）」という考え方が定着しています。米サイバーセキュリティ・インフラセキュリティ庁（CISA）は、インシデント発生後の後付けではなく、システムや調達の段階でセキュリティを組み込むよう組織に強く推奨しています（Source）。これをEU AI法の透明性への期待と照らし合わせれば、結論は明白です。透明性を確保するためのアーティファクトは、事後的に付与するのではなく、パイプライン自身が実行時に生成しなければなりません。攻撃者はまさに、その「事後の隙」を狙うからです。
本稿では、セキュリティ制御プレーンの観点から論じます。エージェントのセキュリティログと機械可読な来歴管理を、認証や認可、監査ログと同等の必須要件として扱うべきです。これは単なる「コンプライアンスの追加」ではなく、ランサムウェア集団などの脅威アクターが悪用するログ操作や実行内容の不透明性を排除するための措置です。
エージェントのパイプラインは、通常以下の3つのステップで進行します。
各段階が改ざんの入り口となります。ツール呼び出し経路が侵害されれば入力が密かに変更される恐れがあり、出力経路が侵害されれば、生成されたコンテンツが改ざんされた上で、不十分な「ベストエフォート型」のマーカーだけが残される可能性があります。
CISAのランサムウェア対策ガイダンスでは、攻撃者の目的が単なる暗号化にとどまらないことが明示されています。彼らはシステム全体を標的にし、業務プロセスを混乱させ、運用上の混乱を捏造します。ランサムウェアが注目されがちですが、その手法は「監視や対応を含むシステムへの信頼を毀損させる」という常套手段に基づいています（Source）。もしエージェントのログが無効化、上書き、あるいは実行トレースから切り離されれば、攻撃者はフォレンジックの痕跡を完全に消し去ることができてしまいます。
したがって、AIエージェントの最低限のセキュリティ姿勢はシンプルです。因果関係を再構成できること――どのリクエストがどのツール呼び出しを導き、どのようなパラメータが使われ、その結果としてどのようなモデル出力が得られたのかを追跡できなければなりません。「機械可読な来歴管理」とは、PDFのような文書ではなく、機械が解析、検証、監査できるイベントチェーンを指します。
NIST（米国国立標準技術研究所）のセキュアハッシュ標準は、インテグリティログにおける改ざん検知の暗号学的基盤を提供しています。具体的な実装は環境によりますが、ハッシュベースの完全性検証は、記録された内容が後から変更されていないかを検知する基本原則です（Source）。実務上、来歴記録は監査記録と同様に「追記専用（Append-only）」の性質を持ち、完全性チェックと厳格な書き込み制限が適用されるべきです。
「アーキテクチャによるコンプライアンス」は、データプレーンと並行して「制御プレーン」を構築することから始まります。データプレーンがプロンプトや検索結果、モデル出力を流す場所であるのに対し、制御プレーンは検証可能なイベントを記録し、ポリシーコンテキストを付与し、順序と完全性を維持する場所です。
制御プレーンは、以下の3つの実行時アーティファクトを核とします。
・エージェントセキュリティログ： すべてのツール呼び出しと意思決定ステップに関する、構造化された時系列イベント。 ・ツール呼び出しの来歴： どのツールが呼び出され、どのような入力（適切に秘匿化されたもの）が使用され、どのような出力が返されたかを記述する機械可読な記録。 ・安全なコンテンツマーキング： そのコンテンツがAIによって生成されたものか、どのような変換工程を経たかを示すメタデータ。
曖昧さを避けるため、これらはバラバラのログではなく、単一の証跡ストリームとして扱います。具体的には、制御プレーンを「領収書（レシート）」システムとして設計します。
・レシートの境界： エージェント実行セッションごとに新しいレシートを作成し（セッションID）、決定論的なステップ（ツールの呼び出し、応答、モデルの完了、後処理）が完了するたびに更新します。 ・レシートの内容： (a) 不変のイベントメタデータ（タイムスタンプ、ツール名、ツール呼び出しID、実行主体）、(b) 完全性データ（各ステップの入力・出力データのハッシュ値）、(c) ポリシー情報（ポリシーバージョン、秘匿化マーカー、適用結果）を保持します。 ・レシートの連結： パイプラインを離れるすべての出力（最終的なユーザー向けテキスト、要約、抽出されたフィールドなど）には、レシートへの参照を解決するためのアーティファクトIDを含める必要があります。
多くのチームが陥る落とし穴は、「ツール呼び出しをログに記録するだけ」で満足してしまうことです。重要なのは、証跡ストリームが事後的に独立して検証可能であることです。制御プレーンは「追記専用の書き込み」「読み取り時の完全性検証」「エージェント実行と証跡記録の厳格な権限分離」をサポートしなければなりません。
強固な制御プレーンには、以下の制御ポイントが含まれます。
・制約付き書き込みインターフェース： エージェントの実行エンジンが直接ストレージに書き込むのではなく、狭いAPI経由でログサービスにステップイベントを送信します。このAPIは必要なフィールドを検証し、不正なリンクや情報漏洩を排除します。
・完全性チェーン戦略： レシート更新のたびにステップのペイロードをハッシュ化し、直前のハッシュと連結します（例：H(ステップ || 前のハッシュ)）。途中で改ざんされれば検証は失敗します。
・書き込み時の証明： ログサービスは独自のIDでレシート更新に署名し、「誰が証跡を書いたか」を検証可能にします。
・信頼境界の分離： 証跡ストアとその署名鍵を、モデルやツールの実行プロセスから切り離します。これにより、ランタイムが侵害されても歴史の書き換えを防ぎます。
CISAが提唱する「設計段階からのセキュリティ」とは、事後的な追加ではなく、システム構築のプロセス自体にセキュリティを組み込むことです（Source）。エージェントパイプラインにおいても、ログと来歴のスキーマをワークフロー定義に組み込むことが重要です。
機械可読な来歴管理は運用面でも不可欠です。出力アーティファクトをプログラムで追跡できなければ、インシデント対応や内部監査、自動的なポリシー適用は不可能です。EU AI法の透明性要件は、ログが最初から解析可能かつ検証可能であれば、容易に達成できます。
ログ層については、「攻撃者はランタイムのアーティファクトを改ざんする」という前提で設計してください。NISTのセキュリティおよびプライバシー管理指針に基づき、ログへの書き込み権限を制限し、ハッシュチェーンによって事実上の不変性を担保し、ストレージをモデルランタイムから分離してください。
改ざん検知はスローガンではありません。検知なしに書き換えが困難なログ記録が必要です。NISTの暗号学的ガイダンスが支持するように、各イベント記録をハッシュ化し、連鎖させることで変更を可視化します（Source）。
CISAのガイダンスにある通り、ログの作成・保存・ローテーション・保持・監査というログのライフサイクル全体を管理する必要があります（Source）。「コスト削減」を理由にログを無効化したり、保持を「ベストエフォート」にしたりすれば、インシデント発生時のフォレンジックという最も重要な運用要件を満たせなくなります。
実践的な改ざん検知ワークフローは、以下の失敗モードを明示的に処理する必要があります。
・書き換え： 攻撃者が過去のイベントを改ざん。対策：完全性チェーンによる検証（取得時にチェーンの正当性を再計算し、不一致があればエラーとする）。 ・切り捨て： 攻撃者がログの末尾を削除。対策：完了チェックの強制（セッション終了マーカーの確認）と、期待される更新がない場合の警告。 ・抑制： 攻撃者が証跡作成を停止。対策：高リスクなアーティファクトの出力ゲートを閉じる（フェイルクローズ）、あるいは最小限のログモードへの強制移行。
調達も重要です。来歴管理機能や監査可能なログ出力を要求せずにシステムを調達すれば、後から高コストな再設計を強いられることになります。米政府のソフトウェア調達ガイドが強調するように、調達要件はライフサイクル全体のセキュリティ成果を左右します（Source）。来歴管理を調達の必須要件としてください。
EU AI法の透明性要件および「AI生成コンテンツの透かし」についても、機械でチェック可能なメタデータが鍵です。このメタデータはアーティファクトに付随し、変換後も維持され、制御プレーンの記録と照合可能でなければなりません。
スキーマの問題を軽視してはいけません。来歴記録が自由形式のテキストであれば、ポリシーの強制やイベントの相関分析、自動監査は不可能です。スキーマが不十分だと、調査のたびにマッピングを再発明することになり、それが攻撃者にとっての隙となります。
スキーマは以下の3つの識別子を軸に構築します。(1) 実行セッションID、(2) アーティファクトID、(3) ツール呼び出しID。すべてのログエントリがこれらのIDを参照するようにします。
ENISA（欧州ネットワーク・情報セキュリティ機関）のNIS2指令に関する技術ガイダンスが示す通り、ポリシーの意図だけでなく、現実的な制約下での具体的な統制が重要です（Source）。ガバナンスの義務を、具体的な構造化ドキュメントや運用プロセスへと変換してください。
エージェントはモデルだけでなく、ツールも呼び出します。検索システム、内部サービスへの接続、ウェブスクレイパーなど、モデル周辺のアダプターこそがゼロデイ攻撃の主要な標的です。
CISAの指針に基づき、ツールのアダプターが侵害されたり悪意のあるデータを返したりする前提で防御を構築してください（Source）。来歴制御プレーンには、何が起きたかを記録するだけでなく、入力の正当性を検証するための十分なコンテキストを記録する必要があります。
EU AI法への対応を見据え、以下のスケジュールで実装を進めることが現実的です。
・2026年5月： 来歴イベントスキーマとID戦略を確定。ツール呼び出しと出力をリンクさせるログ形式を固定。スキーマの妥当性を確認する統合テストを開始。 ・2026年6月： 完全性保護と制約付き書き込みパスを備えた制御プレーンのログサービスを実装。インシデントモードでの動作を保証。 ・2026年7月： 来歴情報の削除を防ぐ自動強制機能を追加。有効な来歴記録が付与できない高リスクな出力の配送をブロックする。 ・2026年8月： 来歴の完全性に焦点を当てたレッドチーム演習を実施。ツール出力を改ざんし、制御プレーンが検証可能な証跡を提供できるかをテスト。
2026年8月までに、「このAI生成出力は、どのツール呼び出しと入力から作られたのか？」という問いに対し、暗号学的な完全性をもって自動的に回答できる状態を目指してください。これが、平時はもちろん、インシデント発生時の過酷な状況下でも耐えうる唯一の道です。