AIガバナンスから継続的アシュアランスへ：エージェント型システムにおけるコンプライアンスエビデンスのエンジニアリング

ポリシーや年次レビューは、意図されたコントロールを記述するものです。エージェント型システムには、もう一つの層が必要です。それは、実際に発生したリリース、ID、アクション、結果に対して、関連するコントロールが確実に適用されたという証拠です。

従来のガバナンス成果物は、誰がユースケースを所有しているか、どのポリシーが適用されるか、どのリスク階層が割り当てられているか、どのコントロールが設計されたか、誰がデプロイを承認したかといった重要な問いに答えます。エージェント型システムでは、さらに困難な問いが加わります。このリリースが、このIDとコンテキストの下でこのアクションを試みた際、関連するコントロールは機能したのか、という問いです。

その答えは、ポリシー文書だけでは得られません。また、膨大なトレースログの山から得られるものでもありません。アシュアランスには、義務をコントロールの目的、強制ポイント、保存されたエビデンス、そして合格・失敗・例外・不明を区別できるテストへと結びつける、一連の主張の連鎖が必要です。

これこそが、継続的アシュアランスの実際的な意味です。すべての法的判断が自動化されることや、すべてのイベントがリアルタイムで検査されることを意味するわけではありません。システムが変化する中で、以前有効だった主張がもはや成立しなくなったことを検知できるほど実行に近いエビデンスを用いて、アシュアランスが維持されることを意味します。

ダッシュボードではなく、アシュアランスの主張から始める

図1は最小限の連鎖を示しています。義務はシステムプロパティに変換され、名前付きコンポーネントがそのプロパティを強制し、記録がどのような決定が下されたかを証明し、テストが明示的な基準に基づいて記録を評価します。リンクが一つでも欠けていれば、ダッシュボードにはアクティビティが表示されても、意図したコントロールが適用されたという証明にはなりません。

「高額な払い戻しには人間の承認が必要である」という要件を考えてみましょう。これでは曖昧すぎてテストできません。コントロールの目的は次のように定義できるかもしれません。「定義されたしきい値を超える払い戻しが送信される前に、資格のあるレビュアーが正規化された操作を一度承認しなければならない。承認は15分経過後、または顧客、注文、金額、通貨、宛先に重大な変更があった場合に失効する。決済システムは引き続き払い戻しを承認し、実行しなければならない。」

これで強制ポイントが特定可能になります。アプリケーションは金額や重要なフィールドを分類します。ゲートウェイまたはランタイムがツール呼び出しを保持します。IDシステムがレビュアーの資格を判定します。コマースプラットフォームが払い戻しポリシーを適用し、結果を確定させます。エビデンスには、ポリシーバージョン、リクエスターとエージェント、正規化された操作のダイジェスト、承認、タイムスタンプ、操作識別子、ツールの結果、照合された払い戻し記録が含まれます。

アシュアランスのテストは、合格か不合格か以上のことを報告できます。「不明」は極めて重要です。相関関係の欠如、エビデンスの抑制、時計のズレ、または観測されていないバイパスは、成功としてカウントされるべきではありません。例外には、誰が、なぜ、どの範囲で、いつまでそれを受け入れたのかを明記する必要があります。これにより、コントロールの設計が運用上の契約へと変わります。

コントロールの設計と運用を分離する

設計エビデンスは、アーキテクチャ、構成、ポリシー、レビュー記録、テスト計画、所有者など、コントロールが存在することを示します。運用エビデンスは、コントロールが関連する実行に適用されたことを示します。どちらも重要です。完璧に構成されたゲートウェイも、それをバイパスするトラフィックをカバーすることはできません。ランタイムイベントは、デプロイされたポリシーがレビュー済みのバージョンであったことを証明するものではありません。下流のトランザクションは、どのエージェントや承認がそれを生成したかを説明することなく、結果を証明するだけかもしれません。

カバレッジモデルを構築しましょう。対象となるエージェント、環境、モデルルート、MCPサーバー、直接APIパス、認証情報、記録システムを列挙します。コントロールごとに、その強制対象とエビデンス対象を特定します。次に、期待されるトラフィックと観測されたトラフィックの間のギャップをテストします。バイパス経路を無視する継続的アシュアランスは、継続的な誤った自信に陥る可能性があります。

コントロールの所有者は、リスクとエビデンスのレイテンシに基づいて頻度を定義すべきです。IDが存在したか、ツールが許可されたか、ガードレールが実行されたか、承認が存在したかなど、すべてのリクエストで評価できる主張もあります。一方で、結果が照合されたか、保持が実行されたか、アクセスが適切であり続けたか、あるいは集団レベルの公平性指標が承認された範囲内に収まっているかなど、定期的なサンプリングやバッチ結合を必要とするものもあります。「継続的」とは、すべての義務をミリ秒単位で評価することではなく、リンクが維持され、タイムリーに検知が行われることを指します。

階層化されたエビデンスモデルを構築する

図2では、エビデンスを構成（Configuration）、実行（Runtime）、結果（Outcome）の3つのレイヤーに分類しています。構成レイヤーは、その時点で何が意図され、何が有効であったかを説明します。実行レイヤーは、エージェントとコントロールプレーンが何を観測したかを説明します。結果レイヤーは、権限のあるシステムが何を確定させ、誰に影響を与えたかを説明します。これらのレイヤーは、相関識別子、有効時刻の記録、同期されたクロックによって結合されており、どれか一つで他を代替することはできません。エビデンスの整合性が重要である場合、エクスポート、アクセス制御、保持、および改ざん検知の仕組みは、単なるトレースの存在から推測するのではなく、明示的に設計する必要があります。

構成エビデンスには、エージェントとワークフローのリリース、モデルの適格性、プロンプトとスキルの改訂、ツールのスキーマ、ID付与、承認ポリシー、ガードレールポリシー、ログ記録ルール、および環境設定が含まれます。ここで重要なのは「有効時刻」のセマンティクスです。8月の実行を調査する監査人は、今日確認できる設定ではなく、当時適用されていたポリシーと権限を必要とします。

実行エビデンスには、セッションおよびターンの識別子、アクターとサブジェクト、選択されたモデル、トークンとレイテンシのメタデータ、ツールの意図、正規化された引数または保護されたダイジェスト、承認およびガードレールの結果、承認ステータス、再試行とキャンセルのイベント、および完了状態が含まれます。これらは、提案、試行、承認、拒否、失敗を区別する必要があります。モデルが返金を行うとメッセージを出したとしても、それはツールの試行ではなく、ツールの応答があったとしても、必ずしも返金が確定したとは限りません。

結果エビデンスは、返金トランザクション、アクセス権の変更、通知の送信、サポートケースの作成、アーティファクトのデプロイ、顧客への影響記録など、権限のあるシステム内に存在します。照合（Reconciliation）によって、操作識別子とその状態が結び付けられます。このレイヤーは有効性テストに不可欠です。なぜなら、コントロールが設計通りに動作していてもビジネス上の結果が失敗する場合や、観測されていない経路が期待される実行エビデンスなしに結果を生み出す場合があるからです。

検証可能性を損なわずにエビデンスを最小化する

コンプライアンスプログラムでは、不確実性への対応として「すべてを保持する」という手法がとられがちです。しかし、エージェント型システムの場合、これは新たなリスクを生む可能性があります。プロンプト、ツールのペイロード、取得したドキュメント、モデルの応答には、個人データ、認証情報、機密性の高い通信、ソースコード、規制対象の記録が含まれる可能性があるためです。エビデンスの設計は、まず何を証明すべきか（クレーム）を定義し、それを検証するために必要な最小限のフィールドを保持することから始めるべきです。

ID、リリース、モデル、ツール、ポリシー、決定、相関関係には構造化されたメタデータを使用してください。レビュー担当者が中央トレースに完全なペイロードを保持することなく、承認がアクションと一致していることを証明する必要がある場合は、正規化されたフィールドのダイジェストを保存します。機密性の高い本文は、目的のために必要な場所にのみ保持し、マスキング、厳格なアクセス制御、保持期間の設定、削除の仕組みを適用してください。すべてのビジネスオブジェクトをAIオブザーバビリティストアにコピーするのではなく、権限のある記録へのマッピングを維持するようにします。

TrueFoundryの文書化されたログ設定は、この区別を示す良い例です。ルールによって、リクエストおよびレスポンスの本文を保存するかどうか、また保存されたコピー内でどの機密パターンをマスキングするかが決定されます。コスト、トークン、レイテンシ、メタデータは記録されたままとなります。これはプライバシーに配慮したエビデンス設計をサポートしますが、法的な目的、保持期間、アクセス権、ローカライゼーション、および定義済みまたはカスタムのパターンが自社のデータに対して十分かどうかは、組織が判断する必要があります。

テレメトリをコンプライアンスの判定結果にしない

トレースはエビデンスの基盤であり、それ自体が評価者やコントロールテスト、あるいは法的な結論ではありません。保証サービスには、それらの記録に対する明示的なロジックが必要です。具体的には、母集団の定義、期待されるイベント、許可されるシーケンス、タイミング、例外処理、結果の照合、およびデータ欠損時の対応などが含まれます。

行動コントロールについては、オフラインの回帰セットとバージョン管理されたリリースに対する軌跡チェックを使用してください。運用コントロールについては、本番環境のイベントと結果を評価します。統計的な義務については、分母、コホート、信頼度、重要性、エスカレーション基準を定義してください。単一の「コンプライアンススコア」は、どのクレームが失敗したのか、またエビデンスが欠如していたのか、それとも否定的な結果であったのかを隠蔽してしまう傾向があります。

法的な解釈と技術的なテストロジックは、関連付けつつも分離しておく必要があります。弁護士やコンプライアンス担当者が適用される義務を判断し、コントロールの目的を承認します。エンジニアリング部門がその強制とエビデンスの実装を行います。内部監査や保証機能は、その設計と運用がクレームを裏付けているかを評価します。ゲートウェイベンダーは、単に機能が有効になっているという理由だけで、顧客がコンプライアンスに準拠していると宣言すべきではありません。

保証を「変更トリガー型」にする

図3は、このループを完結させるものです。リリース、モデル、ツール、ID、ポリシー、規制の変更は、ロールアウト前またはロールアウト中に、ターゲットを絞った再評価をトリガーする可能性があります。本番環境での動作や照合された結果は、事後の封じ込めや再認証をトリガーする可能性があります。事前の承認は、その前提条件、範囲、およびエビデンスが有効である間のみ有効です。

定期的なレビューも有用ですが、重要なイベントが発生した場合はそれを待つべきではありません。新しいツールは権限を変更します。モデルルートの更新は、アプリケーションコードを変更せずに動作を変える可能性があります。スキルの改訂は手順を変更する可能性があります。IDプロバイダーのマッピングは、誰がアクセス権を得るかを変更する可能性があります。ログ記録ポリシーの変更はエビデンスを削除する可能性があります。新しい規制の解釈は、システムに変更がなくてもコントロールの目的を変更する可能性があります。

変更が脅かすクレームに基づいて分類を行ってください。プロンプトやモデルの変更は、行動および軌跡の評価をトリガーします。ツールやサンドボックスの変更は、機能、依存関係、封じ込めのテストを追加します。IDやポリシーの変更は、認可およびネガティブアクセス（不正アクセス）のテストをトリガーします。ログ記録の変更は、エビデンスの完全性とプライバシーのテストをトリガーします。ダウンストリームのスキーマ変更は、照合および事後条件のテストをトリガーします。

重要な変更には、段階的なロールアウト、対象範囲の限定、監視、およびロールバックを活用してください。ロールバックは必ずしも元の状態への復元を意味しません。エージェントがすでに外部への影響を確定させている場合、組織は補償措置を講じる必要があるかもしれません。したがって、保証には単なるリリースの昇格だけでなく、封じ込めと復旧に関するエビデンスを含めるべきです。

透明性の義務をアーキテクチャに慎重にマッピングする

欧州委員会は、2026年8月2日以降、特定の対話型AIシステムはユーザーに対してAIと対話していることを通知しなければならず、また特定のAI生成コンテンツや改変コンテンツには、適用されるラベル付けや機械可読なマーキングの要件が課されると発表しました。具体的な義務は、役割、システム、コンテンツ、例外規定、および実施ガイダンスによって異なります。エンジニアリング部門は、すべてのワークフローに「AI開示有効」といった汎用的なチェックボックスをコピーするのではなく、適用される法的結論を検証可能な要件へと変換する必要があります。

対話型エージェントの場合、検証可能な要件には、開示テキスト、チャネル、タイミング、言語、ハンドオフ時の継続性、およびそれが表示されたことの証拠などが含まれます。生成コンテンツの場合、要件には、どの出力クラスにマーキングが必要か、どこにマークを適用するか、変換によってマークが保持されるか、どの例外が適用されるかなどが含まれます。エージェントのランタイムは、開示メタデータを作成したことを記録できますが、配信チャネルやコンテンツプラットフォームは、ユーザーが実際にそれを受け取ったか、保持したかを証明しなければなりません。

これは中心的なパターンを示しています。つまり、義務はシステムの境界を越えて発生するということです。モデル、ゲートウェイ、ランタイム、アプリケーション、ユーザーインターフェース、および記録システムは、それぞれ証拠の一部を保持しています。継続的な保証とは、単一のプラットフォームが法を支配していると主張することではなく、規律ある結合によって実現されるものです。

TrueFoundryとTrueForgeの役割

実装においては、各リクエストにユースケース、環境、リリース、コントロールセット、操作識別子をタグ付けし、モデルやMCPのトラフィックを意図したコントロールプレーン経由でルーティングし、TrueForgeのイベントシーケンスを保持し、関連するメタデータをエクスポートすることが可能です。その後、別の保証プロセスが期待されるコントロールを評価し、権威ある結果を結合し、例外を処理します。この分業により、トラフィックに近い場所での強制力を維持しつつ、コンプライアンスの判断を明確かつレビュー可能な状態に保つことができます。

具体例：カスタマーサポートの返金処理

カスタマーサポートエージェントは、注文に関する質問に回答し、返金を提案できます。一定額以下の返金は、対象となる注文に対して自動的に実行されますが、高額な返金や特殊なケースでは人間の承認が必要です。また、組織はチャットチャネルでAIによる開示を行う必要があり、監視対象のデータ内に不要な支払い情報や個人情報を保持しないようにしなければなりません。

コントロールセットは、エージェント、プロンプト、スキルのリリースを固定し、対象となるモデルとツールを定義します。また、エージェントの最初の応答前にチャネルで開示を表示することを義務付け、IDに基づいて返金ツールを制限し、高額な呼び出しには一度限りの承認を適用します。ログルールは、機密情報を抑制または編集しつつ、識別子と決定メタデータを保持します。コマースサービスは、返金対象かどうかを独自に評価し、べき等な操作識別子をサポートします。

ランタイム保証は、すべての返金処理において、認証された対象者とエージェント、期待されるポリシーバージョン、承認結果、必要な承認、操作識別子、および最終イベントをテストします。スケジュールされた結合処理により、成功したツール呼び出しとコマース取引を比較し、ツール呼び出しのみが成功したものや、管理されたランタイムパスを通っていない取引をフラグ立てします。チャネルレベルのテストでは、セッションをサンプリングして、エージェントが単に開示メタデータを出力しただけでなく、実際に開示が表示されたことを検証します。

返金しきい値が変更された場合は、承認コントロールのテストと影響を受けるシナリオが再実行されます。モデルのルートが変更された場合は、行動回帰テストと軌跡テストが再実行されます。チャットクライアントが変更された場合は、開示表示が再認定されます。相関関係にギャップが生じた場合は、システムは「不明」と報告し、例外をオープンして調査を行います。証拠が欠落していることをコンプライアンスに準拠していると見なすことはありません。

要件を満たす監査パケットの構築

有用な監査パケットは、要件（クレーム）に基づいたものです。これには、範囲と対象、義務の根拠、承認されたコントロール目標、所有者、アーキテクチャ、関連するリリースおよびポリシーのバージョン、強制ポイント、証拠スキーマ、テスト方法、期間ごとの結果、例外、是正措置、および既知の制限事項が含まれます。サンプルは、許可されている場合、相関識別子を通じて保護された基盤レコードにリンクされます。

また、証拠によって何を証明できないかを明記する必要があります。例えば、ゲートウェイログはルーティングされたトラフィックはカバーしますが、ベンダーへの直接呼び出しはカバーしないこと、ランタイムイベントはツールの応答を記録しますが、コマース台帳がコミットメントを証明すること、本文の抑制はコンテンツの再構築を制限すること、公平性分析は別の結果データセットで実行されること、法的適用性はプラットフォームではなく組織によって決定されたことなどが挙げられます。

このような誠実な姿勢が保証の質を高めます。範囲が限定された要件の方が、欠落している範囲を隠蔽するような広範なダッシュボードのラベルよりも、はるかに説得力があります。

継続的な保証とは、継続的な確実性ではなく、維持された証拠である

エージェント型システムは変化が激しく、多くの境界を越え、ランタイムで多くの選択を行うため、定期的なドキュメント作成だけでガバナンスの負担をすべて担うことはできません。しかし、その解決策は、包括的な監視や自動化された法的判断ではありません。

より優れた設計は、適用される義務、承認されたコントロール目標、指定された強制ポイント、プライバシーに配慮した証拠、明示的なテスト、説明責任のある例外、および権威ある結果という、維持されたチェーンを構築することです。TrueFoundryとTrueForgeは、モデル、ツール、ID、承認、ランタイム状態全体にわたって、重要なコントロールとテレメトリのインターフェースを提供できます。組織は依然として、カバレッジ、ビジネスポリシー、評価、法的解釈、および最終的な保証の結論に対して責任を負います。

この責任の分担は、隠すべき制限ではありません。それこそがシステムを監査可能にするものです。インフラストラクチャは信頼性が高く、境界が明確な証拠を作成すべきであり、保証プロセスはその証拠が何を証明するのかを正確に述べるべきです。

参考文献

1. IBM — AIガバナンスからAI保証へ：Think 2026で共有したこと.
2. 欧州委員会 — 2026年8月2日以降の執行および透明性要件.
3. 欧州委員会 — AI法に関するポリシー概要.
4. OWASP — 2026年版エージェント型アプリケーション向けトップ10.
5. TrueFoundry — ログ設定.
6. TrueFoundry — MCPゲートウェイ.
7. TrueFoundry — MCPツール承認.
8. TrueFoundry — エージェントレジストリ.
9. TrueForge — SDKの概念.

編集上の開示 本記事は、2026年9月13日時点における、引用された公開資料に対するTrueFoundryの技術的解釈を反映したものです。製品機能の範囲はリンク先のドキュメントに準拠します。記載されている例は説明を目的としたものであり、法的助言、監査意見、独立したベンチマーク、あるいはコンプライアンスやセキュリティの保証を構成するものではありません。

‍