Agent Observabilityとは：会話を集中保存しない監視設計
この記事で学べること
- Zero Data Retentionが「すべての情報が保存されない」と同義ではない理由
- 会話や文書の全文ログが新しい機密情報の保管場所になる仕組み
- 会話内容を扱う経路と、安全上の兆候を扱う経路を分ける設計
- 記録項目を必要最小限へ絞るチェックリストの使い方
Agent監視は会話内容と安全上の兆候を分けて設計できる
プライバシーに配慮したAgent監視では、会話や文書を一か所へ集めず、安全判断に必要な兆候だけを別の経路で扱います。2026年8月19日、OpenAIはZero Data Retention対象環境向けのPrivate Safety Processingを発表しました。処理後の入力や回答をOpenAI側に保持せず、複数のやり取りにまたがる兆候を処理する仕組みです。発表時点では初期顧客との試験段階にあり、一般提供済みの完成仕様としては扱えません。
この記事では、「会話内容を中央へ保存せずに、Agentの危険な連続動作をどう検知し調査すればよいか」という問いに焦点を当て、確認済みの変化、影響を受ける判断、現時点で残る不確実性を扱います。
最後まで読むと、「会話内容を中央へ保存せずに、Agentの危険な連続動作をどう検知し調査すればよいか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
全文ログは監視を容易にする一方で保護対象を増やす
従来のAgent監視では、Prompt、回答、Tool Call（Agentが外部の検索、ファイル、APIなどを操作した記録）、利用者、時刻を一つのログ基盤へ送る方法がよく使われます。原因調査には便利ですが、ログ基盤が元の業務システムと同じ機密情報を持つことになります。
たとえばM&Aの調査Agentなら、未公開の財務資料、契約条件、関係者名が会話に含まれます。全文Trace（処理の経過を時系列で追える記録）を外部の監視サービスへ複製すると、障害調査はしやすくなりますが、保存場所、閲覧者、削除期限、越境移転、委託先の管理範囲も増えます。
OpenAIの公式ドキュメントでは、通常のAPI利用でAbuse monitoring logsが最大30日保持される場合があり、承認された顧客はZero Data RetentionまたはModified Abuse Monitoringを設定できると説明されています。[1] ただし、APIの機能によってApplication state（処理を成立させるための保存状態）の扱いが異なり、第三者のMCPサーバーへ送ったデータは、そのサービスの保持方針に従います。
会話や文書と安全上の兆候を別の経路で扱う
Privacy-Preserving Agent Observabilityは、内容と判断材料を別の経路へ分けます。ここでは、Prompt、文書、Toolの結果、回答を扱う領域をContent Plane、安全上の分類と制御判断を扱う領域をSafety Signal Planeと呼びます。これはOpenAIの正式な製品用語ではなく、発表内容を企業設計へ移すための整理です。[2]
| Content Planeに残すもの | Safety Signal Planeへ送る候補 |
|---|---|
| Promptと回答 | リスク区分 |
| 社内文書と検索結果 | 検知時刻 |
| Toolの入力と出力 | 仮名化したAgentまたはSession ID |
| 顧客・従業員・案件の詳細 | 適用したPolicy ID |
| 調査用の生Trace | stop、continue、reviewなどの処置 |
Safety Signal Planeに内容の要約を入れすぎると、別名の全文ログになります。反対に、単一の「異常あり」だけでは、誤検知の見直しや影響範囲の判断ができません。何を送らないかと、どの判断に必要な情報を残すかを同時に決めます。
短期間の状態を使って危険な連続動作を捉える
Agentの危険性は、一回の依頼だけでは見えない場合があります。顧客検索、一覧の出力、外部接続、停止指示後の継続が別々の操作として現れても、連続すると意図から外れた動きになる可能性があります。Private Safety Processingの発表は、複数のやり取りを横断する兆候を扱う必要性を示しています。[2]
内容を中央保存しない設計でも、顧客管理領域の中で短い期間の状態を持ち、次のような順序を判定できます。
- 参照だけを許可したAgentが大量出力を開始した
- 社内データを読んだ直後に、未承認の外部接続を試した
- 利用者が停止を求めた後も、新しいTool Callを続けた
- 同じPolicy違反が短時間に複数のSessionで発生した
必要なのは、会話を永続保存することではなく、判定に必要な期間と項目を定義することです。検知用の短期状態、監査用のSignal、例外調査用の生Traceを同じ保存期間にしない方が、目的と保持を対応付けやすくなります。
詳しい実行記録の閲覧は例外調査として段階的に許可する
最小限のSignalだけでは原因を確定できない場合があります。そのときは、誰でも中央ログを検索できる状態に戻すのではなく、顧客管理領域で生Traceへアクセスする例外調査を設けます。
調査手順では、対象Session、調査理由、承認者、閲覧者、閲覧範囲、期限、持ち出し可否、終了時の削除を記録します。高いリスクを検知した場合でも、Signalだけで従業員の不正や顧客の違反を断定せず、元のPolicy、Agentの権限、実行結果を確認します。
また、Metadataも機密情報になり得ます。Agent ID、時刻、リスク区分、発生頻度を組み合わせると、未公開案件の存在や組織の活動を推測できる場合があります。Safety Signal Planeにもアクセス制御、保存期限、目的外利用の禁止が必要です。
最小限の監視項目を判断目的から選ぶ
監視項目を決めるときは、「取得できるか」ではなく「どの判断に必要か」から始めます。次のChecklistは、一つのTelemetry項目を追加する前の確認に使えます。
| 確認 | 合格条件 |
|---|---|
| 判断目的 | 検知、停止、調査、報告のどれに使うか説明できる |
| 最小粒度 | 内容を送らずに同じ判断ができないか確認した |
| 識別子 | 実名や顧客IDを仮名化できるか確認した |
| 保存期間 | 検知用、監査用、調査用を分けた |
| 閲覧権限 | 通常監視と例外調査の権限を分けた |
| 第三者送信 | 送信先の保持、地域、再委託を確認した |
| 削除と失効 | 期限後の削除と鍵・識別子の失効方法がある |
| 誤検知対応 | 人が見直し、停止を解除し、記録を訂正できる |
Zero Data Retentionは、このChecklistを自動的に満たす認証ではありません。OpenAIのドキュメントには、ZDR対象外の機能や一時的なApplication state、第三者サービス、法令や重大な安全リスクに関する例外が記載されています。[1] 契約、利用機能、接続先、地域、法的義務を自社の構成で確認します。
まとめ：ログをContent・Signal・Investigation Evidenceに分けて最小化する
Privacy-Preserving Agent Observabilityは、監視のために会話を集中保存する前提を外し、内容、最小限のSignal、例外調査を別々に設計する考え方です。監視を弱めるのではなく、どの情報を、どの目的で、どの期間、誰が扱うかを明確にします。
最初の作業は、現在のログ項目をContent、Signal、Investigation Evidenceに分類することです。各項目へ判断目的と削除期限を付け、目的を説明できない全文項目から削減候補にすると、監視とデータ最小化を同じ設計表で検討できます。
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
参考文献
- OpenAI API Documentation, Data controls in the OpenAI platform
- OpenAI, Offering Zero Data Retention for frontier models, 2026年8月19日
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。