結論：prompt_textは監査の材料だが、保存許可ではない
Claude Code 2.1.287ではOpenTelemetryのuser_prompt eventに、dotted keyを扱うbackend向けのprompt_textが追加されました。監査で使える粒度は上がりますが、promptには秘密情報、個人情報、ソースコードが含まれ得ます。本文を送る前に、目的、マスキング、アクセス権、保持期間、削除、送信先を承認してください。最初は本文を保存しない識別子とメタデータで検知し、必要性が証明できた範囲だけ段階的に増やします。
公式Claude Code changelogは、2.1.287でuser_prompt eventへprompt_textを追加し、promptをdropまたはmaskする場所で同じ扱いにするよう示しています。公式OpenTelemetry monitoring referenceは、OTEL_LOG_USER_PROMPTS、OTEL_LOG_TOOL_DETAILS、OTEL_LOG_RAW_API_BODIES、content limitなどの設定を説明します。既存のHook出力のOTel監視がhookの大きさや保存数を扱うのに対し、本稿は利用者のprompt本文と監査目的の分離が主題です。
監査目的ごとに必要なデータを分ける
| 目的 | 本文なしで使える記録 | 本文が必要な場合の条件 |
|---|---|---|
| 誰が使ったか | user、account、session、repository、version | 原則不要 |
| 費用と利用量 | model、token、cost、tool、時間 | 業務名を識別子で付ける |
| 危険操作の検知 | tool名、判定、exit、承認結果 | command本文はマスキング後に限定 |
| prompt injection調査 | 検知ルール、hash、発生時刻 | 短期・限定アクセスの隔離保存 |
| 品質改善 | 評価ID、結果、修正理由 | 匿名化した評価入力だけを別管理 |
監査の目的が「利用状況の把握」なのにprompt本文まで集めると、漏えい時の影響と保持コストが増えます。反対に、重大インシデントの再現では一時的な本文保存が必要になる場合もあります。その場合も全利用者の常時収集ではなく、対象session、期間、担当者、削除日を限定します。
OTelの設定を比較する
公式リファレンスでは、telemetryを有効にするCLAUDE_CODE_ENABLE_TELEMETRY=1、prompt本文を記録するOTEL_LOG_USER_PROMPTS=1、toolの詳細を追加するOTEL_LOG_TOOL_DETAILS=1、raw API bodyを出すOTEL_LOG_RAW_API_BODIESなどが分かれています。名称が似ていても、収集範囲は同じではありません。
| 段階 | 設定の考え方 | 使いどころ |
|---|---|---|
| 最小 | telemetry、metrics、redacted event | 利用量と稼働を把握する |
| 監査 | tool details、repository属性、判定結果 | 危険操作と責任範囲を追う |
| 限定調査 | prompt本文を対象・期間限定で有効化 | 承認済みの事故分析 |
| 高リスク | raw API bodyを原則無効化 | 会話履歴を含むため例外承認が必要 |
OTEL_LOG_RAW_API_BODIESは会話履歴を含み得ます。本文の一部だけを見たいという理由で有効化すると、想定以上のデータが送られる可能性があります。collector側でdropやredactionをするだけでなく、Claude Code側の収集設定、環境変数の配布、managed settingsの上書きを確認します。
安全な監査パイプラインを8手順で作る
- 監査目的を、利用量・安全・品質・事故調査から一つずつ分けます。
- 各目的の合格条件と、本文が本当に必要かを台帳へ書きます。
- user、session、repository、version、tool、結果、costの保持項目を決めます。
- 秘密情報、個人情報、prompt、tool input、raw bodyのデータ分類を付けます。
- collector、保存先、暗号化、アクセス権、保持期限、削除方法を確認します。
- 本文なしの設定でテストし、redacted eventが監査目的を満たすか評価します。
- 必要な場合だけ対象者・期間・repositoryを限定してprompt本文を有効化します。
- ログの欠損、送信失敗、collector停止、設定変更を検知し、停止条件を試します。
2.1.287のprompt_textは、backendがdotted keyを扱う場合の可搬性を高めるフィールドです。新フィールドが追加されたからといって、従来のmask/drop方針を緩める理由にはなりません。既存のcollector schema、SIEMの検索、アクセス制御、削除ジョブが新フィールドを誤って保存・公開しないかを回帰テストします。
変更前チェックリスト
- prompt_textを収集する目的と、収集しない代替案を比較した
- 本文、tool input、raw API bodyを別々のデータ分類にした
- OTEL_LOG_USER_PROMPTS、OTEL_LOG_TOOL_DETAILSの既定値と変更者を記録した
- collectorでのdrop・mask・保存先・アクセス権・保持期限を試験した
- prompt_textの追加で既存のdotted key処理が二重保存にならない
- 秘密情報を含むテストpromptの送信、検索、削除を確認した
- 設定変更、collector停止、漏えい疑い時のrollbackと報告先がある
組織の利用状況を見たい場合はtelemetryのuser属性を、秘密情報を含むMCP診断を扱う場合はMCP secret保護を確認します。監査ログは多ければよいのではなく、目的に対して必要十分で、削除できることが品質です。
FAQ
- prompt_textを保存しないと監査できませんか？
- 利用量、version、session、repository、toolの判定、承認結果などで多くの監査目的を満たせます。本文が必要な目的だけ、対象と期間を限定して別保管します。
- OTEL_LOG_USER_PROMPTSを有効にする前に何を確認しますか？
- 入力に含まれるデータ分類、送信先、アクセス者、保持期限、削除、collectorのredactionを確認します。環境変数を配布した人だけでなく、データ責任者も承認します。
- 監査ログ設計を相談できますか？
- できます。監査目的、ログ項目、データ分類、保存先、保持期間、インシデント時の範囲を無料診断（60秒）で整理してください。
本文を保存しない監査でも、イベントの欠損を検知できなければ説明責任は果たせません。collectorへ届いた件数、送信失敗、時刻ずれ、version、設定digestを監視し、利用者の操作とログの空白を比較します。本文の代わりに評価IDや業務IDを使う場合は、対応表を本番ログと分離し、限られた担当者だけが照合できる状態にします。
prompt_textを許可する調査では、開始時刻と終了時刻、対象session、担当者、検索語、エクスポート先、削除確認をチケットへ記録します。事故調査のために保存した本文を、品質改善やモデル評価へ二次利用しないよう目的を分けます。アクセスログも監査対象にし、閲覧者が必要な情報だけを見られるようにします。
設定は環境変数を一行追加するだけに見えても、managed settings、shell profile、CI、Desktop、SDKなど実行面ごとに結果が異なります。代表的な入口でeffective configurationを確認し、本文ログが意図せず有効になっていないかテストします。バージョンアップ時は新しいフィールド名をschema validatorへ追加し、未知フィールドを無制限に保存するfallbackを避けます。