Claudeの利用ログの閲覧範囲は誰が決めるか

Claude EnterpriseやClaude Console組織で交わされたセッションの文字起こしは、既定で6年間保存されます(SIEMへの取り込み設計はCompliance APIのSIEM連携を参照)。チャット・ファイル・プロジェクトは組織の保存ポリシーが許す期間だけ保存されます。読める範囲を決めるのは会社の裁量ではなく、発行された鍵がread:compliance_user_dataスコープを持つかどうかです。このスコープを持つ鍵1本があれば、primary ownerも見ていない会話まで遡って読めます。

誰が読めるかは役職でなく鍵のスコープで決まる

「上司や情シスは自分の会話を読めるのか」という社内説明でよく出る質問に対する答えは、役職では決まりません。Compliance Access Keyという専用の鍵にread:compliance_user_dataスコープが付いているかどうかがすべてです。このスコープを持つ鍵は、組織内の全ユーザーのチャット・ファイル・プロジェクト・セッション文字起こしを、primary ownerがまだ見ていない内容も含めて読めます。

鍵を発行できるのはprimary owner(親組織全体をカバーする鍵)とorganization owner(自分の組織限定の鍵)だけです。Console組織側のorganization adminはAdmin API鍵を作れますが、この鍵が触れるのはActivity Feed(誰が・いつ・何をしたかのイベント一覧)だけで、チャット内容そのものには403 Forbiddenが返ります。Admin API鍵とCompliance Access Keyの取得手順・鍵種別ごとの使い分けはClaude Admin APIキーの取得方法とスコープ選択で扱っているので、鍵の作り方はそちらを参照してください。

Compliance Access Keyのスコープは4種類あり、組み合わせで権限を絞れます。

会話内容そのものが読めるのはread:compliance_user_dataだけです。Activity Feed(read:compliance_activities)が返すのは「いつ誰がチャットを作成したか」というイベント記録であり、そのチャットの中身は含まれません。組織の変更履歴(メンバー追加・設定変更)を追う既存の監査ログ機能との違いはClaude監査ログの見方が詳しく扱っています。

Claude Codeのローカルセッションは6年、Coworkのリモートセッションはユーザーが消せる

保存期間は「ローカルセッション」か「リモートセッション」かで挙動が変わります。

Claude Code・Cowork・Claude for Microsoft 365のようにユーザーのマシン上で動くセッション(ローカルセッション)は、既定で捕捉から6年間保存されます。組織がclaude.ai > Organization settings > Data and privacyでより短い、または長いカスタム保存期間を設定していれば、その期間が優先されます。複数のカスタム期間が設定されている組織では、最も短い期間が適用されます。

一方、claude.ai web/mobile上で動くCoworkのリモートセッションは、ユーザー自身がセッションを削除しない限り6年間保存されます。ユーザーがセッションを削除すると、Compliance APIからもそのセッションは取得できなくなり、復元はできません。この「ユーザーが消せば本当に消える」という挙動は、ローカルセッションには無い特徴です。ローカルセッションはユーザーや管理者が能動的に削除する手段がなく、保存期間の経過に伴って順に取得対象外になるだけです。

読めない範囲もある — content_unavailableの4つの理由

read:compliance_user_dataを持つ鍵でも、セッションの中身が常に全部読めるわけではありません。文字起こしの各ターンにはcontent_unavailableという状態があり、理由は主に4種類です。

• retention_elapsed — そのターンが保存期間を過ぎて消えている
• client_aborted — クライアントが応答完了前に接続を切った(アシスタント側の応答のみ対象)
• oversize — 1メッセージが上限サイズを超えている
• not_captured — 組織でCompliance APIが有効化される前のセッションなど、そもそも記録されていない

リモートセッションの文字起こしでは、thinkingブロックと画像は文字起こしに含まれません。ツール呼び出しとその結果、ユーザーの発言、アシスタントの応答テキストだけが対象です。CLAUDE.mdのようなプロジェクト指示ファイルは、クライアントがメッセージ内容として送る通常のユーザーロールのテキストとして記録されるので、Skillの内容と区別なく残ります。

そもそも記録の対象外になるセッションもあります。HIPAA readinessを有効にしている組織のローカルセッションは、そもそも記録されずローカルセッションのエンドポイントは何も返しません。ゼロデータ保持(ZDR)が効いているセッションも同様に一覧から除外され、個別に取得しようとすると404になります。鍵のスコープが足りているかどうかとは別に、組織のデータ取り扱い設定そのものが記録の有無を決めている点は、社内説明で見落とされがちです。

何のために使われるのか — 目的で使い分けが変わる

Compliance Access Keyのread:compliance_user_dataは、法務・コンプライアンス・セキュリティ調査のための機能です。典型的な用途はeDiscovery(訴訟対応の証拠保全)、インシデント発生時の該当ユーザーのセッション精査、SIEMへのアクティビティ連携の3つです。組織のメンバー追加・削除やロール変更のような管理操作を追いたいだけなら、必要なのはread:compliance_activities(Activity Feed)、あるいはより手軽な監査ログのCSVエクスポート機能で足ります。両者の使い分けはClaude監査ログの見方の「監査ログとCompliance APIの使い分け」が具体的です。

Cowork特有の可視性(OpenTelemetryで拾えるイベント種別とCompliance APIとの役割分担)は、Cowork監査ログと権限管理にまとまっています。CoworkのローカルセッションもCompliance APIのセッション取得対象である一方、OpenTelemetryはトークン・コスト・ホスト情報といった実行時のメタデータをリアルタイムでストリームする別の仕組みで、両者は補完関係にあります。

自分の組織にその鍵があるかを確認する方法

「うちの組織はread:compliance_user_dataの鍵を発行しているのか」は、primary ownerかorganization ownerであれば自分で確認できます。claude.aiのOrganization settings > APIを開き、Keysセクションの一覧を見れば、発行済みキーとそのScopes列が並んでいます。鍵のプレフィックスからも見分けられ、sk-ant-api01-で始まるものがCompliance Access Key、sk-ant-admin01-で始まるものがAdmin API keyです。後者はActivity Feed専用なので、この形式のキーしか見当たらなければ、会話内容を読める経路は組織に存在しないと判断できます。

Compliance APIそのものが無効化されている組織では、この確認以前にActivity Feedへのイベント記録自体が止まっています。有効・無効は組織のセキュリティ設定画面のトグル1つで管理者が随時切り替えられ、切り替えの事実そのものもActivity Feedのイベントとして残ります。

似た仕組みにInference hooks(ベータ)があります。組織が用意したAI security serverが、Claudeへの各リクエストを推論前にリアルタイムで検査し、必要なら拒否できる仕組みで、Compliance APIのように事後にデータを取得するのではなく、その場で介入する点が違います。「事後に読める」Compliance APIと「その場で止める」Inference hooksは目的が異なるので、社内説明では両者を混同しないことも重要です。

社内説明ではどこを強調すべきか

稟議や説明会で聞かれるのは「見られるのか」ではなく「普段は見られていないのか」です。答えは、Compliance Access Keyが実際に発行され、read:compliance_user_dataスコープが付与されているかどうかに尽きます。鍵を発行していない組織、あるいはActivity Feed専用のスコープしか付けていない組織では、日常的にチャット内容が閲覧される経路はありません。鍵の発行自体が「読める人を作る」操作だという説明が、役職ベースの説明より正確です。

さらに、Compliance APIによる閲覧そのものがActivity Feedにcompliance_api_accessedというイベントとして記録される点も社内説明で押さえておく価値があります。鍵が漏洩した場合も、actor.api_key_idでどの鍵がいつ何を読んだかを事後に追跡できるため、「読める鍵がある」ことと「読まれた記録が残らない」ことはイコールではありません。保持期間の詳細や鍵種別ごとの違いはCompliance APIのFAQ — データ保持とアクセス範囲にまとめているので、あわせて参照してください。

もう1つ伝えるべきなのは、鍵が漏洩したときの被害範囲です。read:compliance_user_dataを持つ鍵1本が漏れると、組織の全メンバーのセッションの文字起こし(既定6年分)とチャット・ファイル・プロジェクト(組織の保存ポリシーが許す期間分)が読める状態になります。この鍵を本番データベースの認証情報と同格で扱い、シークレットマネージャーで管理する運用が公式にも推奨されています。読み取りと削除で鍵を分け、漏洩時の被害を限定する設計も有効です。

まとめ

Claudeの利用ログが誰にどこまで見えるかは、組織の役職ではなく発行された鍵のスコープと保存期間の設定で決まります。会話内容そのものを読めるのはread:compliance_user_dataを持つCompliance Access Keyだけで、これを発行できるのはprimary ownerとorganization ownerに限られます。ローカルセッションは既定で6年、リモートセッションはユーザーが消すまで6年という保存の違いも押さえておくと、社内説明で「いつまで残るのか」という質問にも一次資料のまま答えられます。