AIエージェントの所有責任は信頼の土台です

2026年5月15日、ネゲヴ・ベン＝グリオン大学、ノースイースタン大学、Amrita Vishwa Vidyapeethamの研究者たちは、エージェント帰属の問題を「観測されたAIエージェントのやり取りを、ホスティング事業者側の責任あるアカウントへ結びつけること」と定義しました。¹

この表現だけを見ると、狭い問題に聞こえます。しかし、実際にはそうではありません。エージェントは、ユーザーにスパムを送り、システムをスクレイピングし、サポート担当者になりすまし、サイバー作業を実行し、ツールを呼び出し、費用を発生させ、インフラを変更できます。その一方で、被害を受けた側には挙動しか見えず、そのエージェントを展開した運用者を特定できないことがあります。¹

AIエージェントの所有責任は、欠けていた信頼の基本要素です。自律的なすべての行動は、責任を負うアカウント、セッション、権限範囲、人間または組織の所有者、停止経路に結びついているべきです。ログは何が起きたかを示します。所有責任は、誰が説明責任を負えるかを示します。

要約

エージェントのセキュリティは、ツール権限、実行時の制御、最終回答の証拠だけでは止まれません。これらの制御は重要ですが、「稼働中のエージェントを誰が所有しているのか」という説明責任の問いには答えられません。

新しいエージェント帰属の論文は、カナリアを使って、観測された有害なやり取りを事業者側のセッションとアカウントへ結びつける、事業者仲介型のプロトコルを提案しています。¹ その研究が対象にしているのは、不正利用への対応と法的な説明責任です。プロダクトチームには、自分たちのシステム内で日常的に使える、より小さな版が必要です。すべてのエージェント実行には、アカウント、セッション、権限範囲、ツール活動、確認経路、停止スイッチを結びつける所有責任の記録を持たせるべきです。

重要なポイント

エージェントプラットフォームチームへ： - 所有責任は請求処理の後付けではなく、実行時のフィールドとして扱いましょう。 - すべてのエージェント実行に、所有者、アカウント、セッション、ツール範囲、停止制御を付与してください。

セキュリティチームへ： - 所有責任のないログは、インシデント対応を遅らせます。ログのない所有責任は、証拠を弱くします。 - 行動の記録と、責任あるアカウントへたどる経路の両方を必須にしてください。

プロダクトチームへ： - 誰が、または何がユーザーの代わりに動いているのかを示してください。 - 委任された行動と、委任された説明責任を分けて扱いましょう。

ポリシーと信頼チームへ： - 帰属の仕組みは、安易な匿名解除ではなく、権限ある対応のために設計してください。 - 被害を止め、不正利用を確認し、適正手続きを尊重できるだけの情報を記録しましょう。

所有責任はプロフィール名ではありません

多くのプロダクトは、すでに何らかの形でアイデンティティを表示しています。チャット画面には、ワークスペース、ユーザーアバター、ボット名、APIキーのラベル、組織名などが表示されるかもしれません。こうした表示は人間が状況を把握する助けにはなりますが、所有責任の証明にはなりません。

エージェントの所有責任には、より厳密な契約が必要です。

この一覧が運用寄りに見えるのは、所有責任そのものが運用上の問題だからです。エージェントが2,000件の不適切なメッセージを送ったり、サードパーティのエンドポイントを叩き続けたりしたとき、ラベルだけでは役に立ちません。対応チームが必要とするのは、セッション、アカウント、権限範囲、停止経路です。

エージェントキーにはリスク予算が必要ですでは、権限の側面を扱いました。キーは狭く、サーバー側で強制される能力だけを付与するべきです。所有責任が扱うのは説明責任の側面です。その権限の使用すべてが、責任ある記録へ戻れるようにする必要があります。

帰属論文が加えたもの

この論文は、エージェント運用者ならすぐに認識できる空白を形式化しています。被害者にはエージェントの挙動が見えます。事業者にはモデル呼び出しとアカウントログが見えます。しかし、どちらか一方だけでは両方の視点を見られません。¹

提案されたプロトコルは、カナリアによってその2つの視点をつなぎます。権限を持つ当事者が、疑わしいエージェントが取り込みそうなコンテンツに目印を挿入します。エージェントがそのコンテンツを事業者ホストのモデル呼び出しへ渡した場合、事業者は狭い時間枠のセッションログを検索し、カナリアを見つけ、セッションを復元し、そのセッションをアカウントへ結びつけられます。¹

論文では、扱いやすいケースと難しいケースが分けられています。

有用性を持つという考え方が重要です。詐欺エージェントには、標的の感情的な手がかりが必要かもしれません。Webエージェントには、表示されているページ内容が必要かもしれません。サイバーエージェントには、ファイル名や応答の成果物が必要かもしれません。運用者が過剰にフィルタリングすると、帰属の証拠と一緒に、エージェントの作業性能も落ちます。¹

論文のサイバーエージェント実験は、そのトレードオフを具体的に示しています。カナリアを意識した敵対者が、作業に関連する成果物を抑制によって取り除いた場合、エージェントの解決率は51%から9%に下がりました。一方で、ファイル名と表示本文内の識別子は、それぞれ77%と70%の帰属証拠を維持しました。敵対的な意味カナリアのトラックでは、意味的カナリアが少なくとも98%の真陽性率に達しました。¹

これらの数字をプロダクトマーケティングに使うべきではありません。論文が検証しているのは、特定のエージェント、ラッパー、カナリア群です。それでも教訓は残ります。帰属は、エージェントが実際に必要とするコンテンツに信号を載せたとき、最もよく機能します。

ログは必要ですが、それだけでは足りません

OpenAIのCodex安全性記事は、成熟した制御の形を説明しています。境界づけられた実行、承認、管理されたネットワークポリシー、認証情報の保存、ルール、管理された設定、エージェントネイティブなテレメトリです。² テレメトリには、ユーザープロンプト、承認判断、ツール実行結果、MCPサーバー利用、ネットワークプロキシの許可または拒否イベントに関するOpenTelemetry記録が含まれます。²

OpenAIはまた、Codexログを使って、不審なエンドポイントアラートの周辺にある元の依頼、ツール活動、承認判断、ツール結果、ネットワークポリシー判断を確認するセキュリティトリアージの流れも説明しています。²

この証拠は必要です。それでも所有責任が必要です。

ツールの記録は、次のようなことを言えます。

エージェント実行記録は実行時の契約ですでは、記録が経路を証明すると論じました。所有責任は、その経路の背後にいる責任ある当事者を証明します。強いシステムには、セッション単位で結合された両方の記録が必要です。

Codexが、この問題がもはや理論ではないことを示しています

OpenAIの5月14日のCodex発表では、週あたり400万人以上がCodexを使っていると述べられています。また、ユーザーがスマートフォンから出力を確認し、コマンドを承認し、モデルを変更し、作業を開始し、スクリーンショット、ターミナル出力、diff、テスト結果、承認を追えるモバイルワークフローも説明されています。³ 同じ発表では、Remote SSHが一般提供になり、Codexがリモートマシンや管理環境内でスレッドを実行できるようになったとも述べられています。³

このプロダクト形状では、エージェント作業がデバイス、マシン、スレッド、承認、認証情報、ローカルツールをまたいで広がります。1つのエージェント実行に、ノートPC、スマートフォンでの承認、リモートホスト、プロジェクト、プラグイン、ブラウザー、シェル、バージョン管理操作が関わることもあります。

所有責任の記録は、実行と一緒に移動しなければなりません。そうでなければ、システムは「どのコマンドが実行されたか」には答えられても、「そのコマンドが実行された時点で誰がその実行を所有していたのか」を失います。

Codex Hooksがローカル実行基盤を現実にしますでは、フック、承認、Git管理、証拠、審美眼を、エージェント作業を囲む運用層として位置づけました。所有責任も同じ層に属します。フックは危険な行動をブロックできます。記録は完了した行動を説明できます。所有責任は、その実行を、両方の結果について説明できるアカウントと運用者へ結びつけます。

実行時の所有責任契約

すべての内部タスクに完全なカナリア帰属プロトコルが必要なわけではありません。必要なのは、何かが起きる前から帰属を日常化する、ファーストパーティの所有責任契約です。

まず、エージェント実行ごとに1つの記録を持たせます。

この記録は、チャットの会話履歴より下、低レベルのインフラログより上に置くべきです。プロダクトサポートが使えます。セキュリティが使えます。コンプライアンスが使えます。エンジニアリングもロールバック時に使えます。

フィールド名そのものよりも、不変条件が重要です。責任ある実行記録のないエージェント行動を許さないことです。

所有責任にはプライバシー境界が必要です

帰属は、全員の身元を初期状態で明かす許可だとチームが扱ってしまうと、乱用につながります。所有責任の論文はこのリスクを直接指摘し、権限があり監査可能な主体、ポリシー上の立場、法的手続きを前提にプロトコルを構成しています。¹

プロダクトチームも、その抑制を取り入れるべきです。

所有責任を安易な監視にしてはいけません。強い帰属は、被害者、プラットフォーム、事業者、運用者に対応経路を与えます。弱いガバナンスは、同じ基本要素を別の信頼問題に変えてしまいます。

設計原則は単純です。すべてのエージェントをシステムに対して説明可能にし、すべての所有責任の照会をポリシーに対して説明可能にすることです。

所有責任は既存のエージェント制御のどこに入るのか

所有責任は、他のスタックを置き換えるものではありません。

OpenAIのAgents SDK発表も、同じ層状の形を示しています。SDKは、制御されたワークスペース、ファイルとツールの検査、MCP、スキル、AGENTS.md、シェル、パッチ適用、サンドボックス実行、マニフェストベースのワークスペースをエージェントに提供します。⁴ AgentTrustは補完的なセキュリティ論点を提示しています。ツール呼び出しを実行前に検査し、許可、警告、ブロック、確認といった構造化された判定を返すというものです。⁵

これらのシステムは、エージェントが次に何をできるかを決めます。所有責任は、その実行について誰が説明するのかを決めます。

AIエージェントはモデルを呼び出すべきですでは、エージェントは推定をでっち上げるのではなく、訓練済みモデルを呼び出すべきだと論じました。所有責任は、同じ規律を権限へ広げます。その行動が、人間のクリック、エージェントセッション、モデルツール、スケジュール済み自動化、委任されたポリシーのどれに由来するのかを、システムは把握しているべきです。

この区別はユーザーを守ります。ユーザーは、ある行動が自分によるものなのか、自分のアカウントの下で動くアシスタントによるものなのか、組織ポリシーによるものなのか、侵害された自動化によるものなのかを推測させられるべきではありません。

エージェントには監督のための表示面が必要ですでは、この問題のユーザー向け側面を扱いました。所有責任は、その表示面の下にある記録を提供します。確認パケットが新しい最終回答ですでは、完了時の成果物を扱いました。所有責任は、その成果物を受け入れ、拒否し、取り消せる当事者を提供します。

判断基準

他人や外部システムに影響を与えられるエージェントを展開する前に、1つだけ問いましょう。

明日このエージェントについて苦情が来たとき、その実行、アカウント、権限範囲、承認イベント、そして停止できる人またはチームを特定できますか。

答えがいいえなら、そのエージェントは本番準備ができていません。

プロダクトには、すでにログがあるかもしれません。権限もあるかもしれません。モデルに行儀よく振る舞うよう指示するプロンプトもあるかもしれません。しかし、それらが1つの説明責任ある記録につながるまでは、所有責任とは言えません。

エージェントの所有責任は、リクエストID、監査ログ、APIキーと同じくらい当たり前になるべきです。この作業は官僚的に聞こえるかもしれません。しかし、代替案はもっと悪いものです。誰もその行動について説明できないまま、自律システムが動けてしまうことです。

FAQ

AIエージェントの所有責任とは何ですか。

AIエージェントの所有責任とは、エージェントの行動を、その実行に責任を持つアカウント、セッション、運用者、権限範囲、記録、停止経路へ結びつける実行時の記録です。

エージェントの所有責任とエージェント帰属はどう違いますか。

エージェントの所有責任は、ファーストパーティのプロダクト契約です。システムは、実行前と実行中に所有責任を記録します。エージェント帰属は、より難しい事後問題を解きます。影響を受けた側が所有者をまだ知らないとき、観測された有害な挙動を責任ある事業者アカウントへ結びつける問題です。¹

ログだけではなぜ不十分なのですか。

ログは、コマンド、ツール呼び出し、承認、ネットワーク判断を示せます。しかし、誰が実行を委任したのか、誰が権限範囲を所有していたのか、誰がエージェントを止めたり確認したりできるのかに答えられなければ、ログだけでは足りません。

事業者は、求められたら誰にでもエージェント所有者を明かすべきですか。

いいえ。所有責任の照会には、権限あるアクセス、ポリシー上の立場、監査が必要です。外部開示には適切な手続きが必要です。帰属が信頼を守るのは、その照会経路自体にガバナンスがある場合だけです。¹

本番環境で最低限必要なものは何ですか。

外部システムに影響を与えられるすべてのエージェント実行には、実行ID、アカウントID、運用者ID、権限バンドル、承認記録、記録へのポインター、停止制御、確認責任者、保持ポリシーが必要です。

参考文献