Claude Access Transparencyとは何か

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

Access Transparencyが記録する仕組み

Access Transparencyの設計は4つの原則に基づいています。まず、Anthropic社員による顧客コンテンツへのアクセスは、公開されているReason code(理由コード)のもとでしか発生しません。次に、対象コンテンツへの人的な閲覧はすべて記録されます。Anthropic社内でその種のコンテンツに到達できるツールには、閲覧のたびにイベントを発行する仕組みが組み込まれています。3つ目に、記録されるのは人間によるアクセスだけです。安全性分類器や不正利用検知パイプラインといった自動処理は、暗号化された経路で対話的な人的アクセスなしに動作するため、イベントは発生しません。唯一の例外は、自動処理が保存期間を超えてコンテンツを保存する「保存(preservation)」処理で、これはcmek_preserveという別種のイベントとして記録されます。最後に、これらのイベントは既存のCompliance API Activity Feedにそのまま流れてくるため、新しいエンドポイントや認証情報を追加で用意する必要はありません。

Access Transparencyが対象にする範囲

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

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

Reason codeで閲覧理由を絞り込む

Access Transparencyのイベントには、なぜその閲覧が発生したかを示すReason codeが必ず付きます。コードの一覧は公開されており、Anthropicが新しいコードを追加する場合はドキュメントが更新される方針です。

閲覧理由がこの4種類に閉じているため、Activity Feedを監視するだけで「なぜAnthropic社員がこのメッセージを見たのか」を機械的に分類できます。理由が想定外のカテゴリで頻発するようであれば、それ自体が異常検知のシグナルになります。

Compliance APIでイベントを受け取る実装

Access Transparencyのイベントはanthropic_accessというアクティビティタイプでActivity Feedに届きます。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"

レスポンスには標準のActivityフィールドに加えて、accessed_at(実際に閲覧が発生した時刻)・accessor_department(閲覧したAnthropicのチーム名)・reason_code・resource_details.id(閲覧されたメッセージのID)が含まれます。resource_details.idはMessages APIのレスポンスが返すidフィールドと同じ形式(msg_...)なので、自社システム側でリクエストIDをアプリケーション・エンドユーザー・会話単位のメタデータと一緒にログしておけば、イベントが届いたときに「どのリクエストが閲覧されたか」を突き合わせられます。

CMEKと組み合わせたときの保存イベント

Customer-Managed Encryption Keys(CMEK)を併用している組織では、安全性調査のためにコンテンツが保存期間を超えて保持されることがあります。この保存処理は、cmek_preserveという別タイプのイベントとしてフィードに記録されます。フィールド構成はanthropic_accessと同じで、イベントタイプだけが異なるため、片方をパースできる実装はもう片方もそのまま扱えます。保存が人間の判断で開始されたか自動の安全性パイプラインで開始されたかにかかわらずイベントは書き込まれ、CMEK組織では保存された内容が顧客の鍵の外側で再暗号化されます。CMEKの鍵利用ログ(CloudTrailやCloud Audit Logs)はキャッシュの都合で1回ごとの閲覧を必ずしも記録しないため、Access Transparencyのフィードが「1回ごとのアクセス記録」の正、KMSログは鍵の利用パターンを独立に裏付ける記録という役割分担になります。

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

Access Transparencyは、対象顧客からの申請を受けてAnthropicが組織単位で有効化する仕組みで、Consoleの設定画面から自分で切り替えられるセルフサーブ機能ではありません。有効化の流れは3段階です。まずアカウント担当チームにAccess Transparencyの利用を申請します。次にAnthropicが組織の適格性を確認し、条件を満たせば組織レベルで機能を有効化します。最後に、既存のCompliance Access Keyを使ってanthropic_accessイベントを既存のActivity Feedエンドポイントから受け取れるようになります。新しいエンドポイントや専用の認証情報を別途発行する必要はなく、すでにCompliance APIを使っている組織であれば、受信側の実装はイベントタイプのフィルタを追加するだけで済みます。

有効化はワークスペース単位ではなく組織全体に一括で適用されます。一部のワークスペースだけ有効化するといった段階的な導入はサポートされていないため、導入を検討する段階で「組織全体に適用してよいか」を先に決めておく必要があります。また、有効化のタイミングも重要です。カバーされるのは有効化した時点以降にAPIへ書き込まれたコンテンツへの人的アクセスで、それより前のデータへのアクセスに対する保証はありません。有効化から実際にコンテンツがカバーされるまでには最大2時間のずれが生じることがあるため、監査対応のスケジュールを組む際はこの遅延も織り込んでおく必要があります。

Access Transparencyは「見える化」であって「制限」ではない

Access Transparencyという名前から、これがAnthropic社員のアクセス自体を制限する機能だと誤解されがちですが、公式ドキュメントはこの点を明確に否定しています。Access Transparencyはアクセスを記録するだけで、付与も制限もしません。Anthropic社員がどんな目的でコンテンツにアクセスできるかは、契約とUsage Policiesによって決まり、Access Transparencyの有効・無効にかかわらず同じです。つまりこの機能が変えるのは「何が起きているかを組織が知れるかどうか」であって、「何が起きるか」そのものではありません。

この設計は、監査ログ機能全般に共通する考え方でもあります。ログを取ることは統制を作ることとイコールではなく、統制自体は別の契約条件やポリシーの側にあります。Access Transparencyを導入する担当者は、「これを有効にすればAnthropic社員のアクセスが減る」という期待ではなく、「今起きているアクセスを事後的に検証できるようになる」という期待で評価する必要があります。

よくある質問

Access Transparencyを有効にすると、過去のデータへのアクセスも見えますか

保証されません。カバーされるのは有効化した日以降にClaude APIへ書き込まれたコンテンツへの人的アクセスです。有効化前に書かれたデータへのアクセスについてもイベントが見えることはありますが、それは保証された挙動ではありません。

accessor_departmentから閲覧した社員個人を特定できますか

できません。イベントのactorフィールドは常に{"type": "anthropic_actor", "email_address": null}で固定されており、個人のメールアドレスや氏名は開示されない設計です。accessor_departmentが返すのは閲覧を行ったAnthropicのチーム名(例:Safeguards)までの粒度で、担当者個人の識別子は含まれません。組織側で追跡できるのは「どのチームが」「いつ」「どの理由コードで」見たかまでです。

ZDR対象外の機能(Batch APIやFiles API)を使っている場合、Access Transparencyでは何が見えますか

何も見えません。Access Transparencyの対象範囲はZDRの対象範囲と一致するように設計されているため、もともとZDR対象外のBatch APIやFiles APIへの人的アクセスはanthropic_accessイベントとして記録されません。ここで注意したいのは、イベントが来ないことを「アクセスが発生していない証拠」と読み替えてはいけない点です。フィードが空なのは、対象範囲外だからか、実際に人的アクセスが無かったからかのどちらかであり、Access Transparency単体ではこの2つを区別できません。

まとめ

Access Transparencyは、Anthropic社員による人的な閲覧をReason code付きで記録し、既存のCompliance API Activity Feedに流し込む仕組みです。対象範囲はZDRと同じ基準で決まり、自動処理は記録の対象になりません。通知には最大2営業日の遅延があるため、リアルタイム監視ではなく事後検証・監査証跡としての活用が前提になります。何が起きたかを可視化する機能であり、アクセス権限そのものを変える機能ではない、という理解が導入判断の起点になります。組織のデータ保持ポリシー全体を確認したい場合はClaude Zero Data Retentionが有効になる契約形態の切り分け、PHIを扱う組織向けの取り決めはClaude APIのZDRとHIPAA readinessは何が違うかで扱っています。