Claude Access Transparencyとは何か

Claude Access Transparencyは、Anthropic社員が組織のデータを人手で閲覧するたびに、その事実をコンプライアンスAPIの記録として残す仕組みです。自動処理された安全性チェックは対象にならず、人間が実際に内容を見た場合だけイベントが発生します。有効化は申請制で、対象顧客のみアカウントチーム経由で利用できます(Anthropicの透明性への取り組み全体像はAnthropicのTransparency Hubとは何かで扱っています)。

人が見たときだけイベントが出る

記録の設計は、閲覧理由・記録の範囲・届け先・改ざん検知の4点で成り立っています。人手の閲覧は、公開されているReason code(理由コード)のもとでしか起きません。Anthropic社内で対象コンテンツに到達できるツールには、閲覧のたびにイベントを発行する仕組みが組み込まれています。

イベントは既存のCompliance API Activity Feedにそのまま流れます。新しいエンドポイントも認証情報も要りません。記録が後から消されていないかを確かめる署名付きログもあります(詳しくは後半の「見える化であって制限ではない」で扱います)。

境界線は、人間が見たかどうかです。

自動処理にも1つだけ例外があります。自動処理が保存期間を超えてコンテンツを保存した場合は、cmek_preserveという別種のイベントが記録されます。このイベントは自動処理が起点でも出るため、空のフィードを読むときは人の閲覧と保存を分けて考えます。

自分の使い方は対象になるか

Access Transparencyがカバーするのは、Claude Messages APIまたはClaude Codeセッションを通じて送信されたプロンプトと応答のコンテンツです。対象範囲はZDR(Zero Data Retention)がカバーする範囲と一致するように設計されており、ZDRの対象外の機能はAccess Transparencyの対象にもなりません。

ZDR対象外の例として、Files APIのほかにAnthropicがホストするステートフルなアプリケーションも挙がっています。

組織自身の操作は対象外です。自社のAPI呼び出し・管理者操作・Compliance APIの読み取りは、標準のActivity Feedイベントとして別に記録されます。Access Transparencyが可視化するのは、Anthropic側の人間が組織のデータを見た記録だけです。

フィードが空のときの読み方も、対象かどうかで変わります。対象のサーフェスだけを使っている組織なら、空のフィードは「Anthropicの人間が内容を見ていない」ことを意味します。ただし自動処理は動き続けているので、「処理されていない」という意味にはなりません。Batch APIやFiles APIが主な使い方なら、そもそも記録の対象外なので、空のフィードから何も読み取れません。

イベントに入っている項目

anthropic_accessのイベントには、標準のActivityフィールドに加えて次の項目が入ります。

組織の識別子(organization_id・organization_uuid)と、閲覧がワークスペースに紐づく場合のworkspace_id・workspace_uuidも入ります。resource_details.parentは、会話IDのような親リソースを入れるための欄です。nullか省略になります。

resource_details.idはMessages APIのレスポンスが返すid(msg_...)と同じ形式です。自社システム側でリクエストIDを、アプリケーション・エンドユーザー・会話単位のメタデータと一緒にログしておけば、イベントが届いたときに「どのリクエストが閲覧されたか」を突き合わせられます。

取得はactivity_types[]で絞り込みます。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=anthropic_access" \
  --data-urlencode "limit=50" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

公式のレスポンス例から組織IDを省いた形です。reason_codeがsafety_review、accessor_departmentがSafeguardsで、閲覧の約3.3秒後に記録されています。

{
  "id": "activity_013b013744txqZtFHLUaRqLr",
  "type": "anthropic_access",
  "created_at": "2026-06-08T17:12:09.812446Z",
  "accessed_at": "2026-06-08T17:12:06.478035Z",
  "actor": { "type": "anthropic_actor", "email_address": null },
  "resource_details": { "type": "message", "id": "msg_1234ABCD" },
  "accessor_department": "Safeguards",
  "reason_code": "safety_review",
  "transparency_log_leaf_index": 41
}

通知は最大2営業日遅れる

取り込み側の設計で効くのは、時間窓の取り方です。created_atの窓で定期取得している場合、anthropic_accessとcmek_preserveについては連続する窓を2営業日以上重ねる必要があります。重ねないと、遅れて索引された1件が窓の外に落ちたままになります。重なった分は、Activityのidで重複を除きます。

週末をまたぐと、暦日では2日より長くなります。日次の取り込みでも、窓の下限を前回の上限から数日戻す前提で組むことになります。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=anthropic_access" \
  --data-urlencode "created_at.gte=2026-06-01T00:00:00Z" \
  --data-urlencode "created_at.lt=2026-06-08T00:00:00Z" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

accessed_atは閲覧が起きた時刻で、フィードに現れる最大2営業日前のこともあります。SIEMのアラートやスケジュール実行のエクスポートは、この遅延を見込んだ遡り期間で設計します。

Reason codeで閲覧理由を分類する

イベントには、閲覧の理由を示すReason codeが必ず付きます。コードの集合は閉じていて、新しいコードが加わるときはドキュメントが更新されます。

後ろの2つは「閲覧」ではなく「保存」を指しています。公式のJSON例でも、policy_violation_investigationはcmek_preserveイベントに付いています。理由別に集計するときは、anthropic_accessとcmek_preserveを同じ集計に入れるのか分けるのかを先に決めておくと、保存の件数が閲覧の件数に混ざりません。

保存イベントとCMEK

Customer-Managed Encryption Keys(CMEK)を使う組織では、保存イベントの意味が重くなります。まれなケースとして、安全性調査で重大な有害コンテンツが確認され、調査継続のために標準の保持期間を超えて保存されることがあります。この保存も、顧客に見える形で記録されます。

cmek_preserveのフィールド構成はanthropic_accessと同じで、イベントタイプだけが異なります。片方をパースできる実装はもう片方もそのまま扱えます。保存が人間の判断で始まったか、自動の安全性パイプラインで始まったかにかかわらずイベントは書き込まれます。

CMEK組織では、保存された内容が顧客の鍵の外側で再暗号化されます。鍵が動く操作なので、cmek_preserveが鍵の外に出たことの記録になります。それ以外の保持データは引き続き顧客の鍵の下に残ります。

絞り込みは、アクティビティタイプを差し替えるだけです。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=cmek_preserve" \
  --data-urlencode "limit=50" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

CMEKの鍵利用ログ(CloudTrail、Cloud Audit Logs、Azure Monitor)は、鍵が短時間キャッシュされるため、1回ごとの閲覧を必ずしも別々に記録しません。1回ごとのアクセス記録の正はAccess Transparencyのフィードで、KMSログは鍵の利用パターンを独立に裏付ける役割です。

有効化はセルフサーブではない

有効化は組織全体に一括で適用され、ワークスペースごとの段階的な導入は使えません。導入前に「組織全体に適用してよいか」を決めておく必要があります。

カバーされるのは、有効化以降にAPIへ書き込まれたコンテンツへの人的アクセスです。それ以前のデータへのアクセスは、イベントが出ることはあっても保証されません。有効化から実際にカバーされるまでに最大2時間のずれもあるので、監査の開始日は有効化日を起点にします。

見える化であって制限ではない

Access Transparencyはアクセスを記録するだけで、付与も制限もしません。Anthropic社員がどんな目的でコンテンツにアクセスできるかは契約とUsage Policiesが決め、有効・無効にかかわらず同じです。変わるのは「何が起きているかを組織が知れるか」で、「何が起きるか」ではありません。

記録の改ざんは、透明性ログ(ベータ)で検証できます。ログは組織ごとに1本あり、追記のみで署名付きです。フィードに載るイベントは先にログへ追記され、そのうえでフィードに出ます。イベントのtransparency_log_leaf_indexはログ内の位置を指す目印にすぎず、検証が済むまでは「ログに載っている」証明にはなりません。

検証できるのは、ログに書かれた内容がその後変わっていないことです。すべてのアクセスが記録されたこと、記録が実際のアクセスを正確に表していることまでは、ログも保証しません。最初のイベントが記録されるまでは、ログのエンドポイントは404を返します。実際の検証手順はAccess Transparencyの検証手順で扱っています。

よくある質問

自社のエンドユーザーにClaudeを提供するプラットフォームでも有効化できますか

プラットフォーム型のデプロイでは使えません。ユースケースによっては相談の余地があるため、アカウント担当に問い合わせる形になります。

自分の組織で有効化されているかを確かめるには

アカウント担当に問い合わせます。

Access Transparencyの利用をやめたら、記録は消えますか

消えません。利用をやめても透明性ログは同じエンドポイントから読めます。再び有効にすると、同じログが続きます。

まとめ

Access Transparencyが答えるのは「Anthropicの人間が、いつ、どのチームから、どの理由でこのメッセージを見たか」だけです。導入前にZDRの対象範囲と照らして、自社の使い方が記録の対象に入るかを確かめるのが先になります。組織のデータ保持ポリシー全体はClaude Zero Data Retentionが有効になる契約形態の切り分け、PHIを扱う組織向けの取り決めはClaude APIのZDRとHIPAA readinessは何が違うかで扱っています。