Compliance APIは内部統制の記録保存義務にどこまで応えるか

Compliance APIが内部統制の証跡になりうる理由

内部統制の報告制度(いわゆるJ-SOX)や個人情報保護法の安全管理措置は、いずれも「誰が・いつ・何をしたか」を後から追跡できることを前提にしています。Claudeを業務に組み込む企業が増えるほど、統制の対象にAIエージェントの操作履歴が入ってきます。Compliance APIは、この追跡可能性をプログラムで確保するための仕組みです。

Compliance APIが返すのは、組織のActivity Feed(操作イベントの記録)と、claude.ai上のチャット・ファイル・プロジェクト、Cowork・Claude Code・Claude Science・Claude for Microsoft 365(Excel・Word・PowerPoint・Outlook)のセッション文字起こしです。セッション種別ごとの取得範囲の詳細はCompliance API FAQの領分なのでそちらを参照してください。Activity Feedは6年間保持され、Compliance APIが組織で有効化された時点から記録が始まります。有効化前の活動は遡って補完されません。この「有効化タイミングが記録の起点になる」という性質は、内部統制の整備を検討する企業がまず押さえるべき制約です。

一方でチャット・ファイル・プロジェクトの内容は組織自身のclaude.ai保持ポリシーに従い、ユーザーが先に削除すればCompliance APIでも取得できなくなります。証跡として残したい範囲があるなら、保持ポリシーの期限が来る前にエクスポートして自社のアーカイブに移す設計が要ります。

5つの保持期間を統制設計の入力にする

Compliance APIの公式ドキュメントは、取得できるデータの保持期間を5種類に分けて定義しています。内部統制の証跡設計では、この表がそのまま「何をいつまでにアーカイブすべきか」の判断材料になります。

内部統制の監査証跡として6年を超える保存が必要な場合(訴訟対応のリーガルホールドなど、統制上の要求が6年を上回るケース)は、Activity Feedとセッション文字起こしを取得しながら自社アーカイブへ逐次エクスポートする以外に方法がありません。逆にコンテンツの保持ポリシーがeディスカバリーの対象期間より短い場合は、ポリシーの期限が切れる前にチャット・ファイルの内容を書き出しておく必要があります。ローカルセッションの文字起こしも同様で、組織がカスタムの保持期間を短く設定すると、その時点で古い文字起こしから返らなくなり、後で期間を延ばしても消えた分は復元されません。

エクスポートに回すか、都度取得に任せるか

保持期間の制約が分かったところで、実際の統制運用では「Compliance APIをそのまま参照する」か「自社のアーカイブに逐次エクスポートする」かを判断する必要があります。公式ドキュメントが挙げる判断基準を、内部統制の実務でよく出る条件に沿って並べると次のようになります。

最後の行が示すとおり、該当条件が無いなら常設のアーカイブ基盤を別途構築する必要はありません。統制の過剰投資を避ける意味でも、まず自社がどの条件に当てはまるかを先に確定させる方が合理的です。

Compliance API経由の削除は取り消せない

DLP(データ漏えい防止)の運用でCompliance APIのハード削除エンドポイントを使う設計を検討している場合、削除には復旧の猶予期間が無い点が内部統制上の重大な制約になります。誤った削除リクエストが証跡そのものを消してしまうリスクがあるため、削除を実行する前に対象コンテンツを取得してアーカイブする手順を統制のフローに組み込む必要があります。この点はCompliance APIで組織のユーザーとグループを取得する手順で扱う取得・削除エンドポイントの仕様と併せて確認しておくと、削除フローの設計時に手戻りが少なくなります。

誰がCompliance APIにアクセスしたかも証跡に残る

内部統制で見落とされがちなのが、Compliance API自体へのアクセス履歴です。Compliance APIへの呼び出しはcompliance_api_accessedというActivity種別として記録され、Activity Feedを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を社内のID基盤の識別子と突き合わせれば、証跡アクセスの棚卸しを定期監査の一部として自動化できます。

Compliance APIが証跡に含めないもの

内部統制の証跡設計で見落とすと後から困るのが、Compliance APIが取得できない範囲です。公式ドキュメントは除外項目を明記していますが、統制の対象範囲文書にそのまま転記するには次のようにコンテンツ系とActivity Feedの適用範囲差を先に押さえておく必要があります。チャット・ファイル・プロジェクト・添付・ローカル/リモートのセッション文字起こしを返すコンテンツ系エンドポイントはClaude Enterpriseのデータのみを対象とし、Activity Feedは組織全体の管理・リソースイベントを対象とします。この違いを踏まえたうえで、除外項目は次のとおりです。

• Claude ConsoleやAPIキー認証のワークロードにおけるプロンプト本文・モデル応答
• ローカルセッションのうちAnthropicに送信されていないオンデバイスの活動(Claudeが読まなかったローカルファイルなど)
• サードパーティのクラウド基盤(Amazon Bedrock・Google Cloud・Microsoft Foundry)経由やWeb版で実行したClaude Codeの利用
• HIPAA readinessやゼロデータ保持(ZDR)が有効な組織のローカルセッション
• セッション文字起こし内のシンキングブロック・画像などのバイナリコンテンツ
• ローカルセッションのシステムプロンプト本文(マーカーメッセージに置き換わる)
• セッション文字起こし内のツール定義とMCPサーバー設定、およびローカルセッション文字起こしのcitationメタデータ
• claude.aiが抽出テキストとして保存した添付ファイルの原本(Word・PowerPoint・PDFの一部。ファイル内容エンドポイントは抽出テキストを返す)
• CMEK(顧客管理暗号鍵)が現在使用できない組織のローカルセッション本文(リクエストは503を返し、セッションのメタデータだけは一覧される)
• 組織の保持ポリシーで削除済みのコンテンツ、ユーザーがclaude.aiで削除したチャットの内容、ユーザーが削除したリモートセッション、Compliance API経由でハード削除したコンテンツ

これらは統制の「対象範囲」を文書化する際にそのまま除外事項として書き起こせる項目です。特にサードパーティクラウド経由の利用やZDR適用組織のセッションは、統制の網から漏れやすいポイントとして事前に洗い出しておく価値があります。

内部統制はCompliance APIをどう位置づけるべきか

Compliance APIは「規則違反を止める」仕組みではなく、「起きたことを後から証明できるようにする」仕組みです。この性格はInference hooksのようなリアルタイム制御の仕組みと対照的です。Inference hooksは各リクエストを推論前に審査し、その場で拒否できますが、Compliance APIは事後に記録を取得するだけで、リアルタイムの介入はできません。内部統制の3点セット(整備・運用・評価)に当てはめると、Compliance APIが担うのは主に「運用状況の記録」と「評価のための証跡収集」で、統制活動そのものの実行(承認フロー・権限制御)は別の仕組みで担保する必要があります。

完全性の検証で最初に押さえるべきは、Activity Feedの配信保証がat-least-onceである点です。正しくページングして走査すれば全件が最低1回は返りますが、部分的な取得失敗の後にリトライすると、すでに保存済みの活動が再配信されることがあります。取得したActivityはidフィールドで重複排除する運用が前提になります。

証跡の網羅性を検証する際は、活動件数の多さを完全性の根拠にしない点も統制設計上の注意点です。公式ドキュメントは、claude_chat_viewedのような閲覧系のActivityがアプリの読み込みパターンに依存すると明記しており、ある期間にチャットメッセージがあるのに閲覧系のActivityが少ないからといって、それだけではデータ欠落の証拠にならないとしています。完全性を担保するには、取得開始のカーソルと終了時のlast_id、取得件数、実行時刻とリクエストIDをログに残す運用が必要です。

個人情報保護法の「外的環境の把握」との接続

個人情報保護法のガイドラインは、外国にあるサーバーで個人データを取り扱う場合、その国の制度を把握したうえで安全管理措置を検討するよう求めています。Claudeを業務に使う組織がこの「外的環境の把握」にどう応えるかはClaude Data Residencyは個人情報保護法の「外的環境の把握」にどう効くかで扱っていますが、Data Residencyがデータの所在(どこに置くか)を扱うのに対し、Compliance APIは取り扱いの記録(誰が何をしたか)を扱う点で役割が異なります。安全管理措置の文書化では、両方を組み合わせて「データがどこにあり、誰がいつアクセスしたか」の両輪を揃える設計が必要になります。

まとめ

Compliance APIは、Activity Feedの6年保持を土台に、内部統制やJ-SOX対応で求められる「誰が・いつ・何をしたか」の証跡をプログラムで確保できます。ただしチャット・ファイルの内容は組織の保持ポリシー、ローカルセッションの文字起こしは組織が設定した期間に従うため、6年を超える保存や短い保持ポリシーが先に効くケースでは、自社アーカイブへのエクスポート設計が別途必要です。ハード削除の不可逆性と、Compliance API自体へのアクセスも証跡化されている点は、統制フローを組む前に必ず確認しておく価値があります。