手元で動いていた分が、監査の対象に入った

2026 年 8 月 11 日、Claude の Compliance API がローカル実行のセッションに対応 しました。対象は、利用者のマシン上で動く Claude Code と Cowork です。Claude Enterprise 組織向けの beta として提供されています。

まず、これまでの穴から書きます。手元で動く分だけ、組織側から中身を取り出す手段が揃っていませんでした。 claude.ai 上のチャットやファイルは Compliance API で取得でき、Anthropic 側のクラウドで動くセッションも取得できます。一方で、開発者の端末で走った Claude Code のやり取りは、別の仕組みを自分で用意する必要がありました。

そこが塞がった、という変更です。

追加された 3 エンドポイント

リリースノートに書かれているのは次の 3 つです。

エンドポイント返るもの
GET /v1/compliance/apps/sessions/local組織横断のセッション一覧
GET /v1/compliance/apps/sessions/local/{session_id}個別セッションのメタデータ
GET /v1/compliance/apps/sessions/local/{session_id}/messagesそのセッションのトランスクリプト

いずれも 既存の Compliance Access Key と read:compliance_user_data スコープでそのまま呼べます。 新しい鍵の発行は不要です。既に Compliance API を使っている組織なら、追加の申請なしで対象範囲が広がります。

補足

Compliance Access Key は claude.ai 側で作る鍵です。Claude Console で作る Admin API key は Activity Feed にしか届かないので、この 3 エンドポイントには使えません。呼び出しが 403 で止まるときは、まず鍵の種類を確認してください。

対象になる範囲を先に確認する

公式ドキュメントの表現では、対象は「利用者が Claude Enterprise のアカウントでサインインした状態で、自分のマシン上で実行した Cowork と Claude Code のセッション」です。

条件が 2 つ重なっています。

  1. Claude Enterprise のアカウントでサインインしていること
  2. そのセッションが利用者のマシン上で実行されていること

自分なら、ここは先に社内で照合します。個人契約の Claude Code を業務で使っている人がいる場合、その分は今回の対象に入りません。「Compliance API で全部見える」と説明してしまうと、実態とずれます。

契約が混在している状態そのものは、監査の観点では先に潰す対象です。全社導入の進め方は Claude Code 全社導入 完全ガイド にまとめています。

OpenTelemetry との使い分け

似た用途に見える仕組みが 2 つあるので、切り分けておきます。

仕組み取れるものタイミング
OpenTelemetryトークン数・コスト・ホスト情報など動いている最中
Compliance APIセッションのトランスクリプトあとから取得

OpenTelemetry は流し続ける監視、Compliance API は後から取り出す監査です。 異常に早く気づきたいなら前者、何が起きたかを追いたいなら後者になります。どちらか一方で足りる場面は少ないと考えています。

自分の見方としては、事故が起きたときに効くのは後者です。インシデントの調査は、事後にしか始まりません。 流れていくメトリクスだけ持っていても、そのとき何を指示して何が返ったかは復元できません。

FIXITFIXIT

手元の作業まで全部見られるのって、やりすぎじゃない？

DodaiDodai

見る前提がないと、事故のときに何も追えません。そこは事故ります。

FIXITFIXIT
でも監視されてるみたいで嫌がられそう。
DodaiDodai

だから取得できることは先に周知します。黙って取るのが一番まずいです。

運用に乗せるときの注意点

取れるようになったからといって、全部を毎日取りにいく設計にはしないでください。理由は 2 つあります。

1 つはレート制限です。 /v1/compliance/* は親組織あたり毎分 600 リクエストの制限を共有します。リモートセッションのエンドポイントには追加のリクエスト予算が乗りますが、今回のローカルセッションには乗りません。全社分を一括で取りにいく処理は、間隔を空けて回す前提で組んでください。

もう 1 つは、取ったあとの保管です。 トランスクリプトには、コードの断片も、社内の固有名も、場合によっては個人情報も含まれます。取得した先の保管期間とアクセス制御を決めずに引き込むと、Anthropic 側から自社側へ、守るべきデータを移しただけ になります。生成 AI 利用時のデータの扱いは 生成 AI の情報漏えい対策 に整理しました。

自分の推奨は次の形です。

  1. 常時取得は一覧とメタデータまでにする
  2. トランスクリプトは、調査が必要になったセッションだけ個別に取る
  3. 取得した内容の保管先・保管期間・閲覧できる人を先に決めておく
  4. 取得できる状態になったことを、利用者に周知する

4 番を外さないでください。黙って記録を取る運用は、あとで必ず揉めます。 先に伝えておけば、それは制度になります。

監査方針をどこまで書き換えるか

既に ISMS などの枠組みで運用している場合、更新するのは 1 か所です。「AI ツールの利用記録の取得範囲」に、手元で実行されたセッションが含まれるようになったこと を追記します。

これまで対象外として書いていたなら、その但し書きが不要になります。逆に、取得できるのに取得しない方針を選ぶなら、その理由を残しておいてください。選択の記録がないと、次の監査でまた同じ議論をやり直します。

インライン検査の側で止める仕組みとは別の話です。実行前に止める仕組みについては Claude Enterprise の inference hooks を参照してください。入口で止める仕組みと、あとから追える仕組みは、どちらも要ります。

まとめ

  • Compliance API が、手元で動く Claude Code と Cowork のトランスクリプトを返すようになった
  • 追加は local セッションの一覧・メタデータ・トランスクリプトの 3 エンドポイント
  • 既存の Compliance Access Key と read:compliance_user_data スコープでそのまま呼べる
  • 対象は Claude Enterprise のアカウントでサインインした状態のセッションに限られる
  • レート制限は /v1/compliance/* 全体で親組織あたり毎分 600 リクエストを共有する
  • 常時取得は一覧まで、トランスクリプトは必要なときだけ。保管方針は先に決める
  • 取得できる状態になったことは、利用者へ先に周知する