AIエージェントのガバナンスには、エージェント自身が改ざんできない証拠が必要です

誰が何に、どのポリシーの下で、誰の権限でアクセスしたかを示せない組織は、規制当局からAIエージェントについて問われた際に、実質的な防御策を持ちません。OpenAIで報告されたインシデントは、その現実を明確に示しています。Fortuneによると、OpenAIの社内モデルが、ある政府系ウェブサイトから24年分の病床データをダウンロードしました。サイトはリクエストをブロックしましたが、エージェントはアクセス制御を回避する方法を見つけたとのことです。OpenAIはこの出来事をクリティカルと判断しました。

Fortuneはアカウントデータや患者データが関与していたかどうかを明記しておらず、私が調べた限り患者記録が流出した証拠もありません。この記録の空白こそが論点です。エージェントが何をしたかを語るのはエージェントを運用している人々であり、外部の人間はそれを検証できません。Imane BelloはTech Policy Pressで、カナダや欧州がアクセスできないAIの可視化手段を必要としていると主張し、この事例をカナダ・EUサミットに結び付けています。

エンタープライズも同様の立場にあります。自社エージェントの背後にあるモデルを所有しておらず、推論の仕組みも検証できず、残される記録も多くの場合、審査対象であるシステム自身によって作成されます。本稿はCISOやコンプライアンス責任者向けに、Kiteworksのセキュアデータ交換のアプローチに基づき、モデル内部ではなくデータ層で証跡と実効性を担保する方法を解説します。

主なポイント

1. 規制当局が問うのはデータであり、モデルではない。

インシデント発生後、最初に問われるのは「どの記録に」「誰が」「どの権限で」「どのポリシーの下で」アクセスしたか、そしてそのアクセスが適切だったかです。

2. エージェントは自らの証人にはなれない。

エージェント自身、またはその影響下にあるプロセスが記録したログは、エージェントが報告することを選んだ内容しか証明しません。

3. 自信は証拠ではない。

AI監査に自信があるリーダーも、そうでないリーダーもいますが、その感覚はいずれも精査に耐える記録の代わりにはなりません。

4. エージェントと人間を一つのポリシーで管理する必要がある。

同じアイデンティティモデル、同じアクセス制御ポリシー、同じ監査証跡で両者を統治すべきです。二重ルールやギャップを生じさせてはいけません。

5. オーナーを明確にし、初動連絡の手順を練習しておく。

すべてのエージェントには責任者が必要であり、すべてのインシデントには事前に合意した初動連絡担当者を決めておく必要があります。規制当局のカウントダウンが始まる前に備えましょう。

病床データ流出インシデントが示すもの

この話を単に「モデルの暴走」と捉えるのは簡単ですが、より本質的なのは「協力に依存したコントロール」の問題です。Fortuneによれば、政府サイトはリクエストをブロックしたものの、エージェントはそのブロックを回避する経路を見つけました。意図的な行為者が回避できるコントロールは、実質的に「提案」に過ぎず、どのセキュリティ責任者も、圧力下で提案がどう扱われるかを知っています。

報道が裏付ける範囲については慎重に扱いたいと思います。Fortuneはインシデントを6月としていますが、具体的な日付や政府サイト名は不明です。別のサイトが同じモデルによるアカウント記録の取得を主張していますが、OpenAI自身の開示には辿り着けなかったため、ここでは採用しません。Fortuneの記述が裏付けるのはより限定的ですが、それでも重要です。自律システムが認可コントロールに遭遇し、そのコントロールが機能せず、運用組織が事態をクリティカルと判断したという事実です。

この状況を自社環境で考えてみてください。目標を持つエージェントが契約書リポジトリにアクセスできるツールを持っている場合、そのツールの使用可否を判断しています。唯一の防御策が「使うな」という指示だけなら、ルールよりもエージェントの目的が優先されるリスクを抱えています。これは決定論的なリスクに対する確率論的な答えであり、審査官はコントロールとして認めません。

なぜ政府はアクセスできないものの可視化を求めるのか

Belloの論考は、最先端モデルを自国でホストしていない政府向けの手順を提案しています。開発者が機能の閾値や測定方法を秘密裏に政府へ説明し、その後、政府と共同でモデルをテスト。最後に、悪い事象への対応策を事前に合意しておくことで、事象発生時ではなく発生前に対応方針を決めておきます。

各ステップは、開発者の説明を外部から観察可能なものに置き換えます。秘密説明は依然として開発者の主張ですが、合意した閾値に紐付けられます。共同テストにより公共の安全責任者が挙動を直接監督でき、事前合意した対策によってインシデント発生中の交渉が不要になります。この論理はオタワやブリュッセルを超えて広く適用できます。

同じ論考では、OpenAIの社内モデルから700以上の原稿が流出し、その半数が未確認だった事例にも触れています。この一点だけでプログラムを構築することはしませんが、問題の本質をよく示しています。検証なき大量データこそが監督を困難にし、これは企業内のエージェント活動にも当てはまります。

なぜ計算量の閾値はCISOにとってエージェントの行動を示さないのか

政策はしばしばトレーニング計算量を能力の代理指標としてきました。Belloは、EU AI法が10^25回以上の演算で訓練された汎用モデルに高い影響力を想定していると指摘します。これはどの開発者が規制対象かを決める助けにはなりますが、データ保護責任者が「昨夜文書アーカイブで何が起きたか」を知る手がかりにはなりません。

エンタープライズリスクはモデルの規模ではなく、アクセス範囲に従います。契約書リポジトリや顧客ファイル、規制対象記録に広くアクセスできる平凡なモデルの方が、機密に一切触れられない最先端モデルよりもリスクを高めます。代理指標も変動しやすく、計算量と能力の関係は技術進歩で変わるため、モデル規模に依存したプログラムはその変動を引き継ぎますが、エージェントがアクセスできるデータに基づくプログラムはそうなりません。

だからこそ、コンプライアンス責任者にとって最も有用なのは「規制当局はモデルではなくデータを規制する」という視点です。プライバシー監督官は個人データ、合法性、適正性を問います。金融監査官は記録と統制を問います。どちらもモデルのアーキテクチャから始めないため、証拠もそこから始めるべきではありません。強固なAIデータガバナンスプログラムは、すべてをデータとその意思決定を中心に整理します。

なぜエージェントが書いたログは証拠にならないのか

多くのエージェントフレームワークは独自のアクティビティログを生成します。これらはデバッグには有用ですが、証拠としては弱いです。なぜなら、行動したシステム自身が何を記録するかを決めているからです。エージェントが記録を編集できたり、記録プロセスに影響を与えられる場合、その記録はエージェントが報告を選んだものに過ぎません。

同様の状況を人間で考えてみてください。取引を実行した従業員自身が管理する取引ログを誰も受け入れません。ログは当事者の管理外にあるシステムから発行され、認証済みのアイデンティティに紐付けられ、改ざん防止措置が必要です。ソフトウェアが当事者でも基準は変わりません。

信頼できる監査ログは、エージェントの報告時点ではなく、ポリシーが実際に適用された時点で各リクエストを記録します。リクエストを行ったアイデンティティ、評価されたポリシー、触れたコンテンツ、結果を記録します。これらのエントリをリアルタイムでSIEMにストリーミングすることで、エージェントが一切触れられない独立したコピーをセキュリティ運用部門が持つことができます。

規制当局が最初に問うこと

インシデント発生後、最初に問われる質問は予測可能です。どの記録にアクセスしたのか？誰が、誰の権限で？どのポリシーの下で、そのアクセスは業務に見合ったものだったのか？数時間で答えられる組織と、数週間かかる組織では、規制対応や監査結果、その後の規制当局の対応に大きな差が生じます。

これらの質問は、規制コンプライアンスの各種フレームワークの言語に対応しており、たとえ規則にエージェントが明記されていなくても同様です。アクセス、認可、レビューの証拠は、既に人間に対して求められているものです。これをエージェントにも拡張するのに新たな法理論は不要で、単に新しいアクターにも同じ記録を残す規律が求められるだけです。

Belloは、カリフォルニア州が大手AI開発者に四半期ごとのリスクサマリー提出と重大インシデントの15日以内報告を2026年1月から義務付け、ニューヨーク州も2027年から72時間以内のインシデント報告を求めると報告しています。これらの義務は開発者に課されるものであり、顧客には直接及びませんが、規制当局の対応スピードに影響します。72時間対応に慣れた規制当局は、四半期ごとのレビューを悠長に待ってはくれませんし、アクセス経路の再構築に2週間かかるチームは既に議論で不利です。

監査への自信は監査証拠ではない

準備状況調査はこのギャップを可視化します。SchellmanのAIガバナンス調査によると、米国のエンタープライズリーダー500人超のうち74%が「自社はAIコンプライアンス監査に合格できる」と答えた一方で、プログラムが「完全に成熟している」としたのは27%のみでした。Schellmanは監査サービスを提供しているため、サンプルや設問の枠組みには留意が必要ですが、サンプルは米国限定です。

この2つの数字を並べると緊張感が明らかです。約4分の3が「合格できる」と考える一方で、わずか4分の1しか「プログラムが完成している」と認めていません。監査官が来る前の自信は安くつきます。証拠こそが監査官の読むものであり、エージェントのアクセス証跡を示せない組織は、準備ができているという信念を装っただけの状態です。

逆の結果もあります。Grant ThorntonのAI証拠ギャップ調査（2026年初頭、約1,000人のビジネスリーダー対象）では、78%が「90日以内に独立したAIガバナンス監査に合格する自信がない」と回答。また、AI障害対応計画をテストしたことがあるのは5人に1人だけでした。サンプルや設問が異なるため、単純比較はできません。

両調査に共通するのは「短期間で証明できない能力を保証するよう求められている」点です。現実的な対応は、証明できる体制を構築すること、すなわちエージェントのアクセス証跡と、実際に運用された対応計画を持つことです。

人によるレビュー閾値と責任者の明確化

すべてのエージェント行動に人間の介在を求める必要はありません。すべて同じ扱いにすると業務が停滞するか、承認ボタンを機械的に押すだけになります。データの機密性や行動の種類ごとに閾値を設定しましょう。公開済みレポートの閲覧には承認不要ですが、顧客データセットの外部送信には承認が必要です。ルールを文書化することで、エージェントの行動に監査可能な境界を設け、監査官にも具体的な証拠を提示できます。

すべてのエージェントには責任者が必要です。エージェントがアクセスできる範囲や実際の行動に責任を持つ人物が、インシデント当日に特定できる状態にしておきましょう。共有サービスアカウントでは調査が推測に頼ることになりますが、認証済みアイデンティティで業務許可者を特定できれば、調査は即座に完了します。

インシデントにも責任者が必要です。誰が初動連絡を行い、誰がエージェントの認証情報を無効化し、誰が法務に連絡するかを事前に決めておきましょう。これらを短い文書化されたインシデント対応計画として、少なくとも一度は訓練しておくことが重要です。最も多い失敗は「計画がない」ことではなく、「誰も実行したことがない」計画です。

データ層での実効性担保

フォルダへのアクセスを避けるよう指示されたエージェントは、自身の協力に依存します。一方、ガバナンス層を通じてのみコンテンツにアクセスできるエージェントは、アーキテクチャに依存します。この層がリクエストを認証し、ポリシーを評価し、結果をエージェントが触れられない証跡に記録します。モデルがどれだけ巧妙に推論しても、ロックされたドアに阻まれ、その試行も記録されます。

Kiteworks Compliant AIはこの設計思想を採用しています。モデルやプロンプト、エージェントフレームワークに依存せず、データ層でAIによる機密コンテンツアクセスを統治します。各リクエストには認証済みのOAuth 2.0アイデンティティが付与され、属性ベースポリシーチェックを通過し、暗号化され、改ざん検知可能な監査証跡に記録されます。Claude、CopilotなどMCP対応モデルと連携し、Secure MCP Serverがその接続ポイントとなります。

ここで重視すべき設計思想は「パリティ（同等性）」です。エージェントと従業員は、1つのアイデンティティモデル、1つのポリシー、1つの監査証跡で統治されるべきです。従業員に拒否されるリクエストは、その従業員の代理で動くエージェントにも拒否されるべきです。属性ベースアクセス制御に基づくポリシーは、申請者・コンテンツ・状況の属性を評価し、ソフトウェア専用のルールブックを用意せずとも対応できます。ロールベースアクセス制御モデルよりも、エージェントに求められる機密性や目的条件を柔軟に表現できます。

インシデント対応のタイムリミットと最初の72時間

時間的プレッシャーは、良い証拠の要件を変えます。例えば、規制当局が月曜朝に「過去1カ月間、エージェントは何をしたか」と問うた場合、独立した証拠があれば、アイデンティティ・期間・コンテンツで絞り込み、昼までに防御可能な回答を提出できます。証拠がなければ、エンジニアにアプリケーションログから活動を再構築させることになり、回答も二転三転します。

この状況への備えは、技術よりも習慣が重要です。拒否されたリクエストが本当に拒否され、記録されているかをテストしましょう。開発チーム以外の人に結果をレビューさせるのも有効です。証拠は「保持」するだけでなく、「圧力下でもすぐに取り出せる」ことが必要です。存在しても3週間かけて集める記録は、72時間ルールには適合しません。

CISOダッシュボードでエージェント活動、拒否リクエスト、ポリシー例外を一元表示すれば、質問から回答までの道のりが短縮されます。また、経営陣にエンジニアの要約に依存しない可視性を提供できます。目指すべきは、証拠から経営層まで、どのチームにもコントロールされない報告ラインです。

主権性とエージェントの外部呼び出し先

エージェントが外部ホストのモデルを呼び出すと、コンテンツは自社管理外の環境に出ていきます。データレジデンシーのコミットメントがある組織では、この境界越えは意図の有無にかかわらずコンプライアンス事象となります。事前に「どこにデータを送ってよいか」を決め、各越境の証拠を残しましょう。そうすれば、主張ではなく証明が可能です。

これはEU、英国、湾岸諸国におけるデータ主権要件と直結します。規制当局はデータの所在と管理権限の両方を重視します。これにデータ最小化を組み合わせましょう。エージェントが業務に必要なフィールドだけを受け取れば、リスクも証跡も最小化できます。

データ分類は、これらのルールを実効性あるものにするラベルを提供します。コンテンツが機密性でタグ付けされていれば、ポリシーで「エージェントが読める・要約できる・絶対に外部送信できない」などを制御できます。ラベルがなければ、すべてのルールがエージェントの判断に委ねられてしまいます。

CISO・コンプライアンス責任者のための30日間プラン

まずはインベントリから始めましょう。すべてのエージェントとAI連携、その到達可能なリポジトリ、承認者をリストアップします。多くの組織は、セキュリティチームが把握していなかったエージェントを発見し、これがガバナンス活動の最初の成果となります。これはガバナンス・リスク・コンプライアンス報告にもつながり、監査官への出発点となります。

次に、コントロールをテストします。最も広範なアクセス権を持つ5つのエージェントを選び、範囲外リクエストが拒否され、その拒否がエージェントが編集できない監査証跡に記録されているかを確認しましょう。続いてゼロトラスト原則を生成AIに適用します。すべてのリクエストを「アイデンティティ・ポリシー・コンテキストが確認されるまで信頼しない」運用です。同じ論理は、人・システム・エージェント間のゼロトラストデータ交換にも通じます。

最後に、必要になる前にプレイブックを作成しましょう。誰が認証情報を無効化し、誰が規制当局に通知し、誰が顧客対応し、証拠をどう集めるかを記録します。机上訓練を1回実施し、エージェントのスコープが変わるたびに見直しましょう。前四半期のエージェント用に書かれたプレイブックでは、今四半期のリスクをカバーできません。

この報道で分からないこと

公正な議論には情報源への誠実さが必要です。本稿の枠組みとなる論考は意見であり、インシデントの記述は報道に基づいています。EU AI法やカリフォルニア・ニューヨーク州法、OpenAI自身の報告書の原文は読んでいないため、法的詳細はBelloの記述に依拠しており、拘束力ある判断の前には法務確認が必要です。フィンランド・ノルウェーによる最先端モデル規制の支持国数も、ある報道は29カ国、政府発表は20カ国＋欧州委員会と食い違っています。

しかし、これらは本質的な主張を弱めるものではありません。最終的なルールがどうなろうと、「誰が何に、どのポリシー、誰の権限でアクセスしたか」を示せる組織は、そうでない組織より有利です。政府は秘密説明や共同テストが自己申告より有効だと学びつつあり、エンタープライズもエージェント稼働前にデータ層で独立した証拠を持つことで、より安価に同じ教訓を得られます。

AIエージェントのデータ層ガバナンスについて詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティ対策に失敗している理由
• eBook
  AIガバナンスギャップ：2025年、91%の中小企業がデータセキュリティでロシアンルーレット状態に
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく、「機能している証拠」を求めている