Compliance APIは内部統制の記録保存義務にどこまで応えるか
Compliance APIの保持期間・証跡範囲を、日本企業の内部統制やJ-SOX対応で求められる記録保存の要求と突き合わせてまとめます。
Compliance APIが内部統制の証跡になりうる理由
内部統制の報告制度(いわゆるJ-SOX)では記録の保存と評価が、個人情報保護法の安全管理措置では取り扱いの記録が、それぞれ土台になります。Claudeを業務に組み込む企業が増えるほど、統制の対象にAIエージェントの操作履歴が入ってきます。Compliance APIは、その履歴を後から確かめられるようにする仕組みです。
返ってくるのは、組織のActivity Feed(操作イベントの記録)と、claude.ai上のチャット・ファイル・プロジェクトです。加えて、Cowork・Claude Code・Claude Science・Claude for Microsoft 365(Excel・Word・PowerPoint・Outlook)・Claude in Chromeのセッション文字起こしも取れます。セッション種別ごとの取得範囲はCompliance API FAQにまとまっています。
Activity Feedは6年間保持されます。ただし記録が始まるのはCompliance APIが組織で有効化された時点からで、有効化前の活動は遡って補完されません。内部統制の整備を検討する企業は、この起点の制約を先に押さえておく必要があります。
チャット・ファイル・プロジェクトの内容は、組織自身のclaude.ai保持ポリシーに従います。ユーザーが先に削除すれば、Compliance APIでも内容は取れません。証跡として残したい範囲があるなら、保持ポリシーの期限が来る前に自社のアーカイブへ移す設計が要ります。収集製品側の設定はClaudeの会話をアーカイブ・eDiscoveryに回す手順にあります。
保持期間は5種類ある
取得できるデータの保持期間は、公式ドキュメントで5種類に分けて定義されています。内部統制の証跡設計では、この表が「何をいつまでにアーカイブするか」の判断材料になります。
| データ | 保持期間 | 保持を決める主体 |
|---|---|---|
| Activity Feedの記録 | 保持期間6年間 | 保持を決める主体Anthropic |
| チャット・ファイル・プロジェクトの内容 | 保持期間組織のclaude.ai保持ポリシー(ユーザーが先に削除すれば短縮) | 保持を決める主体組織 |
| ローカルセッションの文字起こし | 保持期間既定6年間。有限の期間を組織が設定していればその期間。HIPAA readiness有効の組織は30日(カスタム期間のほうが短ければそちら) | 保持を決める主体既定はAnthropic、設定時は組織 |
| リモートセッションの文字起こし | 保持期間6年間(ユーザーが先に削除すれば取得不可) | 保持を決める主体Anthropic |
| Compliance API経由でハード削除した内容 | 保持期間保持されない(削除は即時かつ恒久) | 保持を決める主体削除を実行した側 |
ローカルセッションの保持期間には、2つの時間軸が絡みます。組織が有限のカスタム期間を設定すると、エンドポイントは設定の変更と同時に、その期間より古い活動を返さなくなります。一方、取り込み済みの各メッセージは、取り込み時点で有効だった期間だけ保存されます。
このため、期間を後から延ばしても、すでに期限切れになった内容は戻りません。カスタム期間は既定の6年より長くも設定でき、複数のカスタム期間があるときは最も短いものが適用されます。HIPAA readiness有効の組織では、6年の既定が適用されず30日になります。
文字起こしに期限切れの部分があると、先頭にretention_elapsedという理由付きのcontent_unavailableプレースホルダーが置かれ、残った部分が続きます。セッション全体が期限切れなら、メッセージ取得は404を返します。
エクスポートに回すか、都度取得に任せるか
保持期間の制約が分かったら、「Compliance APIをそのまま参照する」か「自社のアーカイブへ逐次エクスポートする」かを決めます。公式ドキュメントの判断基準を、内部統制の実務でよく出る条件に沿って並べました。
| 統制上の条件 | 対応方針 |
|---|---|
| 監査・リーガルホールドの対象期間が6年を超える | 対応方針Activity Feedとセッション文字起こしを取得の都度、自社アーカイブへ書き出す |
| コンテンツの保持ポリシーがeディスカバリー対象期間より短い | 対応方針保持ポリシーの期限が切れる前にチャット・ファイル内容をエクスポートする |
| ユーザー削除後もチャットやリモートセッションを保持する必要がある(リーガルホールド等) | 対応方針取得の都度、チャット・ファイル・アーティファクト・リモートセッションの内容をアーカイブする |
| DLP対応などでハード削除を実行する可能性がある | 対応方針削除の前に対象コンテンツを取得・アーカイブしておく |
| 上記のいずれにも該当しない | 対応方針Compliance APIへの直接照会に任せ、並行コピーは持たない |
該当条件が無いなら、常設のアーカイブ基盤を別途構築する必要はありません。統制の過剰投資を避けるうえでも、自社がどの行に当てはまるかを先に確定させるのが近道です。
Compliance API経由の削除は取り消せない
DLP(データ漏えい防止)の運用でハード削除エンドポイントを使う設計では、削除に復旧の猶予期間が無い点が統制上の重い制約になります。誤った削除リクエストが証跡そのものを消すおそれがあるため、削除の前に対象を取得してアーカイブする手順を、統制のフローへ組み込みます。
ユーザーがclaude.aiで削除したチャットは、一覧には残りdeleted_atが入りますが、内容は取れません。取得・削除エンドポイントの仕様はCompliance APIで組織のユーザーとグループを取得する手順と併せて見ると、削除フローの設計で手戻りが減ります。
取り込みジョブを証跡として成立させる条件
アーカイブへのエクスポートは、設計を誤ると「取れたつもりで欠けている」状態を作ります。公式の連携パターンから、統制の観点で効く数字を先に並べます。
取り込みジョブの設計で効く数字
取得可能になるまで
1分
created_at.lt は現在より1分以上前に置く
1ページの上限
5,000件
limit の最大値
リクエスト上限
600回/分
親組織で全キー・全エンドポイント共有
ページトークン
24時間
ローカルセッションの取得で有効な時間
1分の遅延を軽く見ると、証跡が静かに欠けます。created_at.ltが現在に近すぎると、インデックスが遅れた活動が取得ウィンドウから永久に漏れ、後のウィンドウでも回収できません。時間窓で回収する方式なら、ウィンドウを数分重ねるか、古い窓を定期的に再照会する突き合わせ処理を足します。
状態を持てるなら、前回のfirst_idをbefore_idに渡すカーソル方式のほうが取りこぼしを避けやすくなります。Activity Feedのカーソルは、再試行しても有効なままです。期限があるのはローカルセッションのpageトークンです。文字起こしの取得は最初のページから24時間で切れ、400が返ります。セッション一覧のトークンは24時間を過ぎても受理されますが、現在の保持境界で再評価されるため、期限切れの分を取りこぼすことがあります。
カーソル方式で取り込む1回分の流れ
- 1
前回のカーソルから読む
保存してあった
first_idをbefore_idに渡し、limit=5000で取得します。 - 2
保存してから次へ進む
ページを自社の保管先へ書き込んでから、そのページの
first_idを新しいカーソルにします。失敗したリクエストは位置を進めないので、同じカーソルで再試行します。 - 3
`has_more`が`false`になるまで繰り返す
trueのあいだは追いついていません。カーソルを永続化するのはfalseになってからです。 - 4
重複を`id`で除く
配信保証はat-least-onceです。全件が最低1回は返りますが、部分的な失敗の後のリトライでは、保存済みの活動が再配信されます。
- 5
実行の記録を残す
開始カーソルと終了時の
last_id、書き出した件数、実行時刻、最後のページのrequest-idを記録します。一覧にはtotal_countもチェックサムも無く、完全性を示せるのはこの記録です。
活動件数の多さは、完全性の根拠になりません。claude_chat_viewedのような閲覧系の活動は、アプリがチャットを読み込むたびに記録され、重複排除もされません。Webやデスクトップ、モバイルで読み込みの契機が違うため、件数は送信メッセージ数や人が画面を見た回数とは対応しません。メッセージがあるのに閲覧系の活動が少ない期間があっても、それだけでは欠落の証拠になりません。
証跡として保管するときは、取得元エンドポイント、クエリパラメーター、実行時刻、各レコードのコンテンツハッシュを来歴メタデータとして添えると、保管の連続性(チェーン・オブ・カストディ)を説明しやすくなります。
ファイル名についても注意があります。ファイル・プロジェクト文書・アーティファクトに関する活動のうちfilenameとtitleは、2026年9月24日以降、それ以前の記録を含めて常にnull・空文字列・省略のいずれかです。名前が必要なら、活動に含まれるclaude_file_*などのIDで、コンテンツ取得のメタデータエンドポイントを引きます。対象が削除されていれば名前は引けません。
誰がCompliance APIにアクセスしたかも証跡に残る
内部統制で見落とされがちなのが、Compliance API自体へのアクセス履歴です。呼び出しはcompliance_api_accessedというActivity種別で記録されます。activity_types[]=compliance_api_accessedで絞り込めば、誰がいつ組織のコンプライアンスデータを照会したかを追えます。「証跡を見る権限を誰が持ち、実際に使ったか」の記録は、証跡管理そのものの信頼性を支える工程です。
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--header "anthropic-version: 2023-06-01" \
--data-urlencode "activity_types[]=compliance_api_accessed" \
--data-urlencode "limit=100"actor.typeがapi_actorの活動では、actor.api_key_idから、どのCompliance Access KeyまたはAdmin APIキーが使われたかを特定できます。この絞り込みはクライアント側で行います。
SIEM(Splunk・Datadog・Microsoft Sentinelなど)との突き合わせでは、actor.user_idを結合キーにします。user_idはメールアドレスや表示名が変わっても変わらない安定した識別子で、公式もメールアドレスより優先するよう示しています。actor.ip_addressとactor.user_agentは、アクターの種類によっては含まれないので、読む前にactor.typeを判別します。
キーが漏えいしたときは、削除してから、このActivityを漏えいしたキーのIDで絞り、被害範囲を調べる流れになります。
Compliance APIが証跡に含めないもの
証跡設計で後から困るのは、Compliance APIが取得できない範囲です。チャット・ファイル・プロジェクト・添付・セッション文字起こしを返すコンテンツ系エンドポイントはClaude Enterpriseのデータだけが対象で、Activity Feedは組織全体の管理・リソースイベントを対象にします。この差を踏まえると、除外項目は次のとおりです。
- Claude ConsoleやAPIキー認証のワークロードにおけるプロンプト本文・モデル応答
- ローカルセッションのうちAnthropicに送信されていないオンデバイスの活動(Claudeが読まなかったローカルファイルなど)
- Claude Consoleのキー認証や、Amazon Bedrock・Google Cloud・Microsoft Foundry経由のClaude Code、およびClaude Codeのクラウドセッション(ルーティンを含む)
- HIPAA readiness有効の組織における、CoworkとClaude Code以外のローカルセッション(CoworkとClaude Codeは30日保存で返ります)
- ゼロデータ保持(ZDR)が有効なローカルセッション(一覧から除かれ、取得は404)
- セッション文字起こし内のシンキングブロック・画像などのバイナリコンテンツ
- ローカルセッションのシステムプロンプト本文(マーカーメッセージに置き換わる)
- セッション文字起こし内のツール定義とMCPサーバー設定、およびローカルセッション文字起こしのcitationメタデータ
- claude.aiが抽出テキストとして保存した添付ファイルの原本(Word・PowerPoint・PDFの一部。ファイル内容エンドポイントは抽出テキストを返す)
- CMEK(顧客管理暗号鍵)が現在使えない組織のローカルセッション本文(503が返り、メタデータだけは一覧される)
- 組織の保持ポリシーで削除済みの内容、ユーザーが削除したチャットの内容とリモートセッション、Compliance API経由でハード削除した内容
この除外項目を踏まえた読み方に癖が2つあります。まず、not_capturedは「記録が無い」ことの証明になりません。Anthropicのデータ取り扱い方針で伏せられている内容も、同じ理由で報告されます。
次に、組織が有限の保持期間を設定していて、新しい内容にアシスタントメッセージが含まれる場合の挙動です。クライアントがコンテキスト圧縮などで履歴を書き換えた時点以降の新しい内容は、最後のアシスタントメッセージまで伏せられます。その後の利用者メッセージだけが続く形になります。セッション一覧にも、取得開始前に走ったセッションが載ることがあり、その文字起こしは各メッセージが「内容なし」で返ります。
サードパーティクラウド経由の利用やZDR適用組織は、統制の網から漏れやすい領域です。事前に洗い出しておく価値があります。
事後記録と事前制御を分けて設計する
Compliance APIは「規則違反を止める」仕組みではなく、「起きたことを後から証明できるようにする」仕組みです。内部統制に当てはめると、担うのは運用状況を評価するための証跡収集です。承認フローや権限制御といった統制活動そのものは、別の仕組みで担保します。
Compliance APIとInference hooks
Compliance API
記録を後から取りに行きます。組織設定や、テキスト以外のファイルを含む豊かなデータを返しますが、リアルタイムの介入はできません。
Inference hooks(ベータ)
組織のAIセキュリティサーバーが各リクエストを推論前に受け取り、その場で拒否できる、推論の前段の仕組みです。
個人情報保護法の「外的環境の把握」との接続
個人情報保護法のガイドラインは、外国にあるサーバーで個人データを取り扱う場合、その国の制度を把握したうえで安全管理措置を検討するよう求めています。Claudeを業務に使う組織の対応はClaude Data Residencyは個人情報保護法の「外的環境の把握」にどう効くかで扱っています。
Data Residencyがデータの所在(どこに置くか)を扱うのに対し、Compliance APIは取り扱いの記録(誰が何をしたか)を扱います。安全管理措置の文書化では、両方を組み合わせて「データがどこにあり、誰がいつアクセスしたか」の両輪を揃える設計になります。
まとめ
Activity Feedの6年保持は証跡の土台になりますが、チャットやローカルセッションの内容は組織の保持設定で先に消えます。最初に決めるのは、自社が先の早見表のどの行に当たるかです。6年超の保存、短い保持ポリシー、ユーザー削除後の保持のどれかに当たるなら、取り込みジョブを1分の遅延と重複排除まで含めて設計します。紙の原本の電子化には別の記録保存義務があり、電子帳簿保存法のスキャナ保存要件をClaudeで確認できるかで要件を整理しています。