Claudeの利用ログを管理者は見られるか — 閲覧範囲は鍵で決まる

Claude Enterpriseの組織では、Cowork・Claude Code・Claude for Microsoft 365などのセッション文字起こしが、既定で最大6年間Anthropic側に保存されます。SIEMへの取り込み設計はCompliance APIのSIEM連携にあります。読める範囲を決めるのは役職ではなく、発行された鍵がread:compliance_user_dataスコープを持つかどうかです。このスコープを持つ鍵が1本あれば、primary ownerも見ていない会話まで遡って読めます。

管理者がチャット履歴を見られるかどうかは、立場ごとに次のように分かれます。

一方で、自分のClaude Codeの会話が記録されているかどうかは、サインインの方法で変わります。Console APIキーやAmazon Bedrockで使っているClaude Codeは、この仕組みの対象外です。

自分のClaude Codeは記録されているか

結論から言うと、Claude EnterpriseのアカウントでサインインしたClaude Codeは記録されます。Claude Codeは、ターミナル、Claude Desktop、IDE拡張のどれから使っても同じです。Anthropicはクライアントが送るClaude APIへのリクエストをサーバー側で記録しており、端末にエージェントを入れる方式ではありません。

記録されない側の条件は、次のようにまとまっています。

• Console APIキーで認証したClaude Code
• Amazon Bedrock・Google Cloud・Microsoft Foundry経由のClaude Code
• Claude Codeのクラウドセッション(クラウドで動くroutinesを含む)
• ゼロデータ保持(ZDR)が効いているセッション
• 端末の中だけで起きてAPIに届かない操作(読まれなかったローカルファイルなど)

3つ目は紛らわしい点です。クラウドで動くClaude Codeセッションは、リモートセッションのエンドポイントにも出ません。リモートセッションとして返るのはCoworkだけだからです。

記録の有無はCompliance APIの有効・無効にも連動します。Claude Enterpriseでは、有効化できるのはprimary ownerだけで、設定は子の組織すべてに波及します。無効の間に行われたセッションは記録されず、後から有効にしても遡って復元できません。単独のClaude Console組織では、Console側のSecurity画面のトグルを組織のadminが切り替えます。ただしConsole組織で見られるのはActivity Feedだけで、メッセージ本文は取れません。Console側での切り替え自体は、org_compliance_api_settings_updatedとしてActivity Feedに残ります。

保存期間はどう決まるか

保存期間は、セッションがどこで動いたかと、組織の設定で決まります。数字だけ並べると次のとおりです。

数字

Compliance APIで読める期間

• ローカルセッション

  6年

  捕捉から。既定値

• HIPAA readiness有効

  30日

  Cowork・Claude Codeのみ返る。カスタム期間が短ければそちら

• リモートのCowork

  6年

  ユーザーが消すまで

• Activity Feed

  6年

  有効化より前には遡れない

ローカルセッションとリモートセッションでは、消えるきっかけが違います。

くらべる

消える条件の違い

ユーザーのマシンで動く

ローカルセッション

Claude Code・Cowork(Claude Desktop)・Claude Science(ベータ)・Claude for Microsoft 365・Claude in Chromeが対象です。Compliance APIは読み取り専用なので、管理者側からも削除できません。

Microsoft 365のアドインで会話を消しても、APIには反映されません。保存期間が過ぎるまで一覧に残ります。

claude.aiのweb・モバイルで動く

リモートセッション

対象はCoworkだけです。ユーザーがセッションを削除すると、Compliance APIはそのセッションを返さなくなります。

内容は復元できません。

組織がclaude.ai > Organization settings > Data and privacyで有限のカスタム保存期間を設定していれば、ローカルセッションではその期間が優先されます。既定より長くても短くても同じです。複数のカスタム期間が併存する組織では、最も短い期間が適用されます。

期間を変えたときの挙動には、読み違えやすい点があります。設定を変えた時点で、APIは新しい期間より古い記録を返さなくなります。ところが、保存されている各メッセージは、捕捉された時点で有効だった期間で保持されます。あとから期間を延ばしても、すでに失効した内容は戻りません。

ローカルセッションの保存は、API呼び出しごとに個別に期限が来ます。古い呼び出しから順に期限が切れるので、長いセッションではcreated_atが後ろにずれていきます。すべての呼び出しが期限切れになると、セッション自体が一覧から消えます。

手元の履歴とは別の記録である

ここまでの「ローカル」は、Compliance APIの用語です。端末のディスクに残る履歴とは別物で、混同すると社内説明が噛み合わなくなります。

Claude Codeは既定で会話を~/.claude/projects/の下にJSONLで保存します。期限を過ぎたものはバックグラウンドの掃除で消えます。この設定を短くしても、Anthropic側に捕捉された記録は消えません。逆に、Compliance APIが有効でも、手元の履歴は設定どおりに消えます。

手元の保存期間の調整はcleanupPeriodDaysの設定で扱っています。

鍵を持つ人はどこまで読めるか

役職では決まらず、Compliance Access Keyという専用の鍵にread:compliance_user_dataスコープが付いているかどうかがすべてです。このスコープを持つ鍵は、組織内の全ユーザーのチャット・ファイル・プロジェクト・セッション文字起こしを、primary ownerが見ていない内容も含めて読めます。

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

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

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

スコープは作成後に変更できません。変えたいときは、新しい鍵を作って古い鍵を削除します。鍵には有効期限がなく、削除した瞬間から使えなくなり、猶予期間はありません。

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

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

• retention_elapsed — そのターンが保存期間を過ぎて消えている
• client_aborted — クライアントが応答完了前に接続を切った(アシスタント側の応答のみ対象。途中まで流れた出力も含まれない)
• oversize — 1メッセージが上限サイズを超えている。メッセージ自体は返るが、contentが空になる
• not_captured — 内容が取れていないターン

not_capturedは「記録が存在しない」ことの証明にはなりません。Anthropicのデータ取り扱い方針でCompliance APIには出さない内容も、同じ理由で返ります。このほかにcmek_key_revokedという予約値があります。顧客管理の暗号鍵(CMEK)が使えない間は、この値の代わりに503が返ります。

文字起こしに含まれるのは、ユーザーの発言、アシスタントの応答テキスト、ツール呼び出しとその結果です。thinkingブロックは含まれません。画像やPDFは[image content not shown]のような文字列に置き換わります。会話の途中でクライアントが履歴を圧縮(コンパクション)すると、その位置にマーカーが挿入されます。

CLAUDE.mdのようなプロジェクト指示ファイルは、ユーザーロールの通常のテキストとして記録されます。Skillの内容もクライアントがメッセージとして送った場合は、ほかのユーザーテキストと区別なく残ります。

HIPAA readinessが有効な組織では、ローカルセッションのエンドポイントがCoworkとClaude Codeのセッションだけを返します。保存は捕捉から30日で、組織のカスタム期間がそれより短ければそちらになります。6年の既定は適用されません。ZDRが効いているセッションは一覧から除外され、個別に取得しようとすると404になります。HIPAAとZDRの違いはZDRとHIPAA readinessの違いに整理されています。鍵のスコープとは別に、組織のデータ取り扱い設定が記録の有無を決めている点は、社内説明で見落とされがちです。

何のために使われるのか

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

Coworkの可視性では、OpenTelemetryで拾えるイベントとCompliance APIの役割が分かれます。詳細はCowork監査ログと権限管理にあります。OpenTelemetryはトークン・コスト・ホスト情報などのメタデータをリアルタイムで流す別の仕組みで、事後に取得するCompliance APIとは補完関係です。設定によってはプロンプトと応答も送れますが、内容の取得にはCompliance APIが推奨されています。セッション取得APIの個別の挙動はCompliance APIのセッション文字起こしで扱っています。

似た仕組みに、Inference hooks(ベータ)があります。組織のAI security serverが、Claudeへの各リクエストを推論前に検査し、必要なら拒否します。事後に読むCompliance APIに対し、その場で介入する点が違うので、社内説明では混同しないようにします。

自分の組織に鍵があるかを確かめる

自分の組織がread:compliance_user_dataの鍵を発行しているかは、primary ownerかorganization ownerなら自分で確認できます。

手順

鍵の有無を確認する

1. 1

   Compliance APIが有効かを見る

   Claude Enterpriseでは、claude.aiのOrganization settings > APIでprimary ownerが有効化します。API画面が見えない、または鍵の作成時にcompliance系スコープが選べないときは、役割が足りないか、まだ有効化されていません。

2. 2

   Keysセクションの一覧を開く

   同じ画面のKeysセクションに、発行済みの鍵とScopes列が並びます。Scopes列にread:compliance_user_dataがあれば、会話内容を読める鍵が存在します。

3. 3

   Admin keysの一覧も見て鍵の種類を見分ける

   Admin API keyは、Claude ConsoleのSettings > Admin keysに並びます。claude.aiのKeysにcompliance系スコープの鍵が無く、Admin keys側だけなら、会話内容を読める経路は組織にありません。手元に控えた鍵なら、sk-ant-api01-で始まるものがCompliance Access Key、sk-ant-admin01-で始まるものがAdmin API keyです。後者はActivity Feed専用です。

4. 4

   403のメッセージで補足する

   スコープを超える呼び出しは、Missing required scopes. Got: [...] Needed one of: [...]という403で返ります。鍵が持つスコープがそのまま出るので、手元の鍵の確認にも使えます。

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

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

読まれた記録は残ります。Compliance APIによる閲覧は、Activity Feedにcompliance_api_accessedというイベントで記録されます。鍵が漏れた場合は、actor.api_key_idでどの鍵がいつ何を読んだかを追えます。「読める鍵がある」ことと「読まれた記録が残らない」ことはイコールではありません。

ユーザーが自分で消せる範囲にも違いがあります。claude.aiのチャットをユーザーが削除すると、Compliance APIはチャットとメッセージをdeleted_at付きで返しますが、中身は返りません。Activity Feed自体は、有効化した時点より前の活動には遡れません。保持期間や鍵種別ごとの違いはCompliance APIのFAQ — データ保持とアクセス範囲にまとめています。

鍵が漏洩したときの被害も説明に入れておきます。read:compliance_user_dataを持つ鍵が1本漏れると、全メンバーのセッション文字起こしと、チャット・ファイル・プロジェクトが読める状態になります。チャットなどの保存期間は組織の設定に従い、既定では無期限です。鍵は本番データベースの認証情報と同格に扱い、シークレットマネージャーで管理する運用が公式に示されています。読み取りと削除で鍵を分ける設計も、漏洩時の被害を限定します。漏洩を疑ったら、鍵を削除し、Activity Feedのcompliance_api_accessedを鍵ごとに洗い、その鍵が届く下流の認証情報も入れ替えます。

まとめ

Claudeの利用ログが誰に見えるかは、役職ではなく鍵のスコープで決まります。ただし、そもそも記録されるのはEnterpriseアカウントでサインインしたセッションが中心で、APIキー経由やBedrock経由、ZDR、HIPAA readinessの組織では前提が変わります。社内で聞かれたら、自分の利用形態が記録の対象かを先に確かめてから、保存期間と鍵の有無を答えるのが確実です。