結論：取得前に対象・目的・保存期限を固定する

Compliance APIは、Claude CodeとCoworkの利用監査を補強できますが、まず対象者、対象surface、取得目的、閲覧者、保存期限を決め、metadata一覧から必要sessionだけを取得します。Anthropicは2026年8月26日、CoworkとClaude Code sessionsのCompliance API session endpointsがbetaを終了したと公式releaseで案内しました。一般提供は「無制限に収集してよい」という意味ではありません。Enterprise契約、Compliance Access Key、必要scope、社内規程を確認して段階導入します。

読者の具体的な困りごとは、Claude Codeで誰がどの作業を行ったかをincident後に確認できず、端末log、git履歴、本人の説明が一致しないことです。読了後には、どのsessionをAPIで取得し、どの証跡と突合するか判断できます。次の行動は、監査目的を一つ選び、少人数の同意済み検証groupで取得から削除までtestすることです。

公式releaseはlocal session endpointsがClaude CodeとCoworkのtranscriptを扱うと説明しています。公式文書では一覧、session metadata、messagesの取得経路を分けています。取得結果にはprompt、応答、tool利用など機密情報が含まれ得るため、通常のapplication logより高いdata区分にします。料金やrate limitは契約・公式API文書で確認し、一般提供という表現だけから無料または無制限と推測しません。

取得範囲を5軸で決める

  1. 目的：incident調査、規程違反確認、定期監査のどれかを一件ずつ定義します。
  2. 対象：organization、利用者、期間、product surfaceを必要範囲へ限定します。
  3. 証跡：session transcriptだけでなくgit、ticket、端末管理logと突合します。
  4. 閲覧：Compliance Access Key保持者と取得data閲覧者を分けます。
  5. 期限：取得原本、調査copy、集計結果の保存期間を別々に決めます。

全sessionの常時保存は検索しやすい一方、個人情報、顧客情報、秘密情報の集中保管になります。まずmetadataで候補を絞り、目的に該当するsessionのmessagesだけを取得する方がriskを抑えられます。定期監査では本文を無条件に読むのではなく、期間、件数、product surface、異常条件で抽出し、人の閲覧を承認制にします。

Claude Codeの作業ではtranscriptとrepository結果が同じとは限りません。提案だけで実行しなかった操作、実行後に人が変更したfile、別terminalのcommandが存在します。commit SHA、pull request、CI、file integrity、endpoint detectionの証跡を合わせて判断します。Coworkでは参照したfileと最終成果物、共有範囲、接続service側のaudit logを対応させます。

公式情報はClaude ScienceやMicrosoft 365連携の一部surfaceをbetaとして追加したことも示します。Claude Code・CoworkがGAでも、他surfaceまで同じ提供状態と断定しません。API responseのproduct_surfaceを保存し、未知値を自動的に既知製品へ分類しない設計にします。

安全に導入する8手順

  1. 監査目的、法的根拠、社内規程、従業員への通知を確認します。
  2. Enterprise契約とCompliance APIの利用条件を管理者が確認します。
  3. 専用Compliance Access Keyへ必要最小のread:compliance_user_data scopeを設定します。
  4. keyをsecret managerへ保存し、通常の生成API keyと分離します。
  5. 一覧endpointで少人数・短期間のmetadataを取得します。
  6. 対象sessionのmetadataとmessagesを取得し、欠損・時刻・surfaceを検証します。
  7. 暗号化保管、閲覧承認、access log、自動削除をtestします。
  8. gitやticketとの突合結果をreviewし、対象拡大のGO/HOLDを決めます。

paginationを無視すると取得漏れが起きます。next page、同時更新、再実行、重複排除をtestし、session IDと取得時刻を記録します。再取得で内容が変わる可能性に備え、原本hash、API version、取得script versionを残します。一覧が成功してmessagesが失敗する、退職者のsessionだけ見えない、権限変更中に欠損するなどの例外も想定します。

監査dataをLLMへ再投入して要約する場合は別のrisk評価が必要です。prompt本文をそのまま外部serviceへ送らず、識別子のmask、data分類、利用model、retention、human reviewを確認します。異常検知の自動判定だけで懲戒や人事判断を確定せず、本人確認と原本reviewを挟みます。

運用チェックリストとHOLD条件

  • 監査目的が一文である
  • Enterprise条件を確認した
  • 対象者へ通知した
  • 必要scopeだけを付けた
  • 生成keyと分離した
  • secret managerへ保存した
  • product surfaceを記録する
  • paginationをtestした
  • 取得漏れを検証した
  • 閲覧承認がある
  • access logを残す
  • 保存期限を自動化した
  • git等と突合する
  • 削除testを完了した

HOLD条件は、従業員への通知や規程が未確認、keyを共有chatへ置く、全sessionを目的なく収集、閲覧者が無制限、削除期限がない、transcriptだけで違反を断定する場合です。APIがGAでも、取得対象の完全性とorganization固有の契約条件は実環境でreadbackします。障害時に「証跡なし」を「問題なし」と扱わないことも重要です。

よくある質問と次の行動

GAならbeta headerは不要ですか？

session endpointの現行認証とrequest仕様を公式referenceで確認します。別機能のbeta条件を混同しません。

全従業員を最初から対象にしますか？

通知、目的、保存を固め、少人数・短期間から取得と削除をtestします。

transcriptだけで監査は完結しますか？

完結しません。git、ticket、端末、接続serviceの証跡と突合します。

一次情報はClaude Platform release notesとCompliance sessions公式文書です。関連するClaude Code監査ログ、入力禁止情報、Enterprise権限管理も確認してください。Miraigentの無料診断では、取得対象とHOLD条件を60秒で整理します。