2026年8月11日にAnthropicは、Claude Enterprise向けのCompliance APIで、ユーザー端末上で動くClaude CodeとCoworkのローカルセッション履歴を取得できるようにしたと公表しました。今回の意味は、これまで見えにくかったローカル実行分の証跡を、既存のCompliance Access Keyで横断確認しやすくなったことです。社内監査やDLP運用の観点では、Claude Codeを本番展開する前に押さえたい更新です。
結論：Claude Codeのローカル履歴を監査フローに載せやすくなった
Anthropicの8月11日付リリースノートによると、今回ベータ公開されたのは `GET /v1/compliance/apps/sessions/local`、`GET /v1/compliance/apps/sessions/local/{session_id}`、`GET /v1/compliance/apps/sessions/local/{session_id}/messages` の3系統です。対象はClaude Enterprise組織のみで、既存のCompliance Access Keyに `read:compliance_user_data` scope が付いていれば利用できます。つまり新しい監査製品を足すというより、既存のCompliance API運用をClaude Codeのローカル実行まで広げやすくした更新です。
特に重要なのは、取得対象が『ユーザーのマシンで走ったセッション』だと公式に明記されている点です。ブラウザ上のチャット履歴だけを追っていると、CLIやデスクトップ経由の実作業が監査証跡から抜けやすい状態でした。今回の更新で、セッション単位のメタデータと transcript を追える土台が整いました。
何が取得できるのか：一覧、詳細、transcript の3段階
運用上は、まず一覧APIで期間内のセッションを拾い、インシデントや退職対応の対象だけ詳細とメッセージを掘る流れが現実的です。全件を毎回深掘りするより、段階的に取れる設計の方が監査コストを抑えやすいからです。特に `/{session_id}/messages` が増えたことで、『いつ使われたか』だけでなく『どんなやり取りだったか』まで追跡できる余地が広がりました。
Compliance content data のドキュメントでは、この系統のAPIが eDiscovery、DLP、アカウント削除対応を想定していると説明されています。したがって『管理者が常時のぞき見るための機能』として扱うより、『必要時に証跡を引けるコンプライアンス基盤の整備』として社内説明した方が受け入れられやすいでしょう。
導入前に確認したい制約：Enterprise限定、user filterなし、Admin API key不可
制約もはっきりしています。まず対象はClaude Enterpriseのみで、Teamや個人プラン向けの機能ではありません。次に、公式ドキュメントでは local session list には user filter がないとされています。組織横断で一覧を持ってから必要なセッションを絞り込む運用を考える必要があります。
さらに、このページの各エンドポイントは Admin API key では利用できず、claude.ai上で発行した Compliance Access Key が必要です。既存の管理API鍵を流用できると思い込むと403で止まります。監査チームが鍵を保管し、開発チームは参照手順だけを持つような運用分離も検討しやすい更新です。
保持期間と例外条件：6年保持が基本だが、ZDRでは見えなくなる
公式ドキュメントでは、ローカルセッション transcript はデフォルトで6年間保持され、有限の custom conversation retention period を設定している組織ではその保持期間に従うとされています。つまり『どこまで見えるか』だけでなく、『どれだけ残るか』も導入判断の論点です。監査証跡を優先するのか、保持最小化を優先するのかを先に決めておかないと、現場と監査の期待値がずれます。
加えて、Anthropicの zero data retention ドキュメントには、ZDRが有効なローカルセッションや、HIPAA readinessが有効な組織のローカルセッションは Compliance API に取り込まれないとあります。Compliance APIがあるから全件追えるのではなく、厳しい保持制御を選ぶほど見えない領域も増えます。法務・情シス・セキュリティで前提を合わせておくべきです。
実務では何から始めるべきか：3つの確認で十分
最初から全社ロールアウトの議論に広げすぎる必要はありません。第1に、Compliance Access Key に `read:compliance_user_data` が付いているか。第2に、Claude Codeを使う対象部門がEnterprise配下か。第3に、ZDRやHIPAA readinessの設定でローカル履歴が欠落しないか。この3点が揃って初めて『監査可能なClaude Code運用』の前提ができます。
実装順としては、1) 一覧APIで日次取得、2) 高リスク案件だけ session_id を保存、3) 退職・インシデント・法務照会時のみ transcript を取得、の三段階が扱いやすいでしょう。日常監視ではなく必要時に絞って読む設計にした方が、運用コストとプライバシー配慮のバランスを取りやすいはずです。
FAQ：いま確認しておきたい疑問
Q. Web版Claudeの会話と同じ取得方法ですか？ A. 完全に同一ではありません。今回は local sessions 用エンドポイントが別に増えたため、既存の chat 一覧取得だけではClaude Codeのローカル履歴を十分に拾えません。Q. 既存のAdmin API keyで足りますか？ A. いいえ。公式には Compliance Access Key が必要で、Admin API key では403になります。Q. user_idで一覧を絞れますか？ A. local session list には user filter がないため、組織横断の一覧取得を前提に設計した方が安全です。
監査設計まで含めて相談したい場合
Claude Codeを本格展開する前に、ログ保持、権限制御、DLP、社内ルール整備まで一緒に設計したい場合は、 AI導入・運用設計の相談はこちら 。要件整理からPoC設計まで支援できます。
今回の更新は、Claude Codeの利便性を保ったまま、Enterprise運用で求められる監査性を補強する一歩です。2026年8月12日時点ではベータ公開なので、まずは小さく検証し、取得できる範囲を社内で明文化してから広げるのが堅実です。
