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