Claude Codeを個人の開発補助ではなく、チームや企業の標準ツールとして使うときに必ず出てくるのが、「誰が、どの端末で、AIに何を依頼したのかを後から確認できるのか」という問題です。
Anthropicは2026年8月11日、Claude Enterprise向けのCompliance APIを拡張し、ユーザー端末上で動作するClaude CodeとCoworkのローカルセッションについて、セッション情報と会話記録を取得できるようにしました。対象はClaude Enterprise組織で、一般の個人向けプランに同じ管理機能が提供されたという発表ではありません。
実務上のポイントは、Claude Codeが「便利な開発ツール」から「監査対象となる業務システム」に近づいていることです。企業導入では、利用許可だけでなく、ログの保管、閲覧権限、従業員への周知、インシデント時の確認手順まで設計する必要があります。
先に結論：Claude Code導入では「使えるか」より「追跡できるか」が重要になる
今回の更新により、Claude Enterprise組織では、企業アカウントでサインインしてユーザー端末上で実行されたClaude CodeやCoworkのローカルセッションをCompliance APIから確認できるようになりました。
Anthropicの公式ドキュメントでは、ローカルセッション一覧、個別セッションのメタデータ、セッション内メッセージを取得するエンドポイントが案内されています。利用にはCompliance Access Keyとread:compliance_user_dataスコープが必要です。
これによって企業側は、少なくとも公式仕様上、Claude Code利用を「各開発者のPC内だけで完結する見えにくい作業」にせず、コンプライアンスや監査の仕組みに接続しやすくなります。
一方で、監査できるから自由に使わせてよい、という話ではありません。AIに入力してよい情報、取得したセッション記録を誰が閲覧できるか、保存期間をどう扱うかを決めなければ、監査機能そのものが新しい情報管理リスクになります。
2026年8月11日に何が変わったのか
AnthropicのClaude Platformリリースノートでは、2026年8月11日付で、Compliance APIがユーザー端末上で実行されるCoworkとClaude Codeのセッション記録を返せるようになったと案内されています。現在はClaude Enterprise組織向けのベータ機能です。
公式に示されている主なエンドポイントは次の3つです。
GET /v1/compliance/apps/sessions/local：組織内のローカルセッション一覧を取得GET /v1/compliance/apps/sessions/local/{session_id}：特定セッションのメタデータを取得GET /v1/compliance/apps/sessions/local/{session_id}/messages：特定セッションの会話記録を取得
ここでいう「ローカル」は、Claude CodeがローカルPCで動作すること自体を指すだけではありません。Anthropicの説明では、Claude Enterpriseアカウントでサインインしたユーザーが、自分の端末上で動かしたClaude CodeまたはCoworkのセッションが対象です。
対象になるClaude Codeは、ターミナル、Claude Desktop、IDE拡張で動かすセッションです。Claude ConsoleのAPIキーで認証している場合や、Amazon Bedrock、Google Cloud、Microsoft Foundryなど第三者のクラウド経由で動かすClaude Code、Claude Code on the webはこのローカルセッション取得の対象外です。
また、Compliance APIが無効になっている期間のセッションは後から復元できません。導入するなら、監査を始めたい時点より前に設定を確認しておく必要があります。
Compliance APIは何のための機能か
Compliance APIは、企業のセキュリティ、法務、コンプライアンス担当者がClaudeの利用状況をプログラムから確認するためのAPIです。
Anthropicの公式説明では、組織のActivity Feed、ユーザーやロール、設定、チャット、ファイル、プロジェクト、セッションなどへのアクセスを提供し、監査やeDiscovery、データ損失防止（DLP）、アカウント削除対応などに利用できるとされています。
一般的な利用状況レポートとは役割が異なります。Analytics APIが利用量やコストなどの集計値を見るための仕組みであるのに対し、Compliance APIは個別のイベントやコンテンツを監査する用途を想定しています。
また、リアルタイムで危険なプロンプトを止める機能とも別物です。AnthropicはInference hooksについて、推論前に組織側のセキュリティサーバーへプロンプトを送り、許可・拒否を判断する仕組みとして説明しています。Compliance APIは基本的に「後から記録を取得する」側です。
この違いは企業導入時に重要です。監査ログが取れることと、危険な操作を事前に防げることは同じではありません。
セッション記録で分かること・分からないこと
ローカルセッションのトランスクリプトには、Claudeへ何を依頼し、Claudeが何を返したかが記録されます。ツール呼び出しやツール結果が会話に含まれていれば、それも調査材料になります。
ただし、端末上で起きたことをすべて記録する仕組みではありません。Anthropicも、ローカルファイルやネットワーク操作について、APIへ届かない活動までは取得されないと説明しています。
たとえば、Claude Codeが参照していないローカルファイル、別プロセスで実行されたコマンド、OS側だけで発生した変更などは、Compliance APIのセッション記録だけでは分かりません。
そのため、インシデント調査ではCompliance APIだけに依存せず、Git履歴、CI/CDログ、クラウド監査ログ、EDR、OSログなどを組み合わせる必要があります。
SE実務ではどんな場面で役立つのか
SEや開発チームの現場で考えると、今回の更新は「AI利用ルールを作った後、それを運用で確認する」場面に効いてきます。
インシデント発生時の確認
たとえば、開発端末から意図しないファイル変更や外部送信が発生し、Claude Codeの利用が関係している可能性がある場合です。
セッション記録を確認できれば、どのような依頼が行われ、どのような応答が返されていたのかを調査する材料になります。ただし、取得できる記録だけで事故原因をすべて確定できるとは限りません。
情報持ち出しルールの監査
顧客情報、秘密情報、ソースコード、認証情報などをAIへ入力してよいかは、案件や契約によって条件が変わります。
「入力禁止」と規定するだけでは、現場で実際に守られているかを確認できないことがあります。Compliance APIによるセッション取得は、ルール違反の調査や監査手順を設計する際の選択肢になります。
AI利用ガイドラインの改善
ログを監査する目的は違反者探しだけではありません。現場で頻繁に起きている使い方を把握できれば、「どこまで自動化を許可するか」「何を入力禁止にするか」「どの権限を標準にするか」といったガイドラインを現実に合わせて修正できます。
企業導入で見落としやすい注意点
監査可能であることを利用者へ明確にする
ローカルで動かしているツールだから「会話内容は自分のPCだけにある」と利用者が認識している場合、実際の管理仕様とのずれが問題になります。
企業で利用するなら、どの利用記録が取得される可能性があるのか、誰が閲覧できるのか、何の目的で確認するのかを社内規程や利用ガイドラインで明確にする必要があります。
閲覧権限を広げすぎない
セッション記録には、ソースコード、エラーログ、設計情報、ファイル名、顧客情報などが含まれる可能性があります。監査APIにアクセスできる担当者を増やしすぎると、監査データ自体が機密情報の集中地点になります。
Compliance Access Keyは通常のAPIキーと同じ感覚で共有せず、最小権限、保管方法、ローテーション、利用記録を含めて管理したいところです。
保存期間を確認する
Anthropicの公式ドキュメントでは、ローカルのCowork・Claude Codeセッション記録はデフォルトで6年間保持されると説明されています。ただし、組織で有限のカスタム会話保持期間を設定している場合は、その期間が適用されます。
長期間保持できることは監査には有利ですが、保存期間が長ければよいとは限りません。自社の情報管理規程、顧客契約、削除要件と整合しているかを確認する必要があります。
すべてのEnterprise環境で同じ記録が取れるとは限らない
ゼロデータ保持（ZDR）が適用されるセッションはローカルセッション取得の対象外です。また、HIPAA readinessが有効な組織ではローカルセッションデータは取得されません。顧客管理暗号鍵（CMEK）を使う組織では、セッション自体は一覧・取得できても、現時点ではメッセージ本文が返らない制約があります。
「Enterpriseなら必ず全文監査できる」と考えず、自社テナントのデータ保持・暗号化・コンプライアンス設定まで確認する必要があります。
監査ログだけで予防できるわけではない
Compliance APIは記録取得の仕組みです。危険なプロンプト、過剰な権限、外部通信、機密ファイルへのアクセスを事前に止める機能ではありません。
実務では、端末権限、Claude Codeの権限設定、ネットワーク制御、Git保護ルール、人間によるレビュー、必要に応じたInference hooksなどを組み合わせることが重要です。
フリーランスSEには直接関係するのか
今回のローカルセッション取得はClaude Enterprise組織向けなので、個人でClaudeを契約しているフリーランスSEが自分で使う場合に、そのまま同じ管理機能が付くという話ではありません。
ただし、クライアント企業のClaude Enterprise環境へ参加してClaude Codeを使う場合は意味が変わります。企業側の契約・設定によっては、業務中のClaude Codeセッションが監査対象になり得ます。
そのため、客先案件でClaude Codeを使う前には、少なくとも次を確認したいところです。
- 個人アカウントではなく企業指定アカウントを使う必要があるか
- AIへ入力してよいソースコードや文書の範囲
- Claude Codeの利用ログやセッションが企業側で取得されるか
- 個人案件と顧客案件の作業環境を分離する必要があるか
- 契約終了後のデータ保持やアクセス権がどう扱われるか
特に、1台のPCで複数顧客の案件を扱う場合は、作業ディレクトリ、認証情報、Claudeアカウントを混在させない方が管理しやすくなります。
導入するなら最初に決めたい5つの項目
Claude Codeを企業導入する場合、Compliance APIを接続する前に運用ルールを決めておく方が安全です。
- 入力可能なデータ範囲
公開情報、社内情報、顧客情報、認証情報などを分類し、何をClaudeへ渡してよいか決めます。 - Claude Codeの実行権限
ファイル変更、コマンド実行、外部通信、Git操作など、どこまで許可するかを標準化します。 - 監査対象と閲覧者
どのセッションを誰が確認できるか、通常時とインシデント時の権限を分けます。 - ログの保管と削除
Anthropic側の保持仕様だけに任せず、自社規程や顧客要件との整合を確認します。 - インシデント対応手順
問題が起きたときに、Compliance API、Git、端末、クラウド、ネットワークのログをどの順で確認するか決めます。
ここまで決めて初めて、Claude Codeを「導入した」ではなく「業務システムとして運用できる」状態に近づきます。
向いている組織と、まだ急がなくてよい組織
今回の機能が特に有効なのは、Claude Codeを複数の開発者へ展開し、顧客データや非公開コードを扱う組織です。金融、医療、受託開発、大企業の社内システムなど、説明責任や監査証跡を求められる環境では検討価値があります。
一方、少人数チームで機密性の低い検証だけを行っている場合、最初から大規模な監査基盤を作る必要はないかもしれません。その場合でも、Git履歴、端末分離、最小権限、レビューといった基本的な管理は先に整えた方がよいでしょう。
また、Compliance APIのコンテンツ取得機能はClaude Enterprise組織向けです。個人向けプランや別プランで同じことができると誤解しないよう注意が必要です。提供条件は今後変更される可能性があるため、導入前には最新の公式ドキュメントを確認してください。
まとめ
2026年8月11日の更新で、Claude Enterprise向けCompliance APIは、ユーザー端末上で実行されたClaude CodeとCoworkのローカルセッションを取得できるようになりました。
この更新の意味は、単なる「ログ取得機能の追加」ではありません。Claude Codeを企業で使うときに、ローカルPC上のAI作業も監査・ガバナンスの対象として扱いやすくなった点にあります。
SE実務では、導入可否をモデル性能だけで決めず、入力データ、実行権限、監査、保存期間、利用者への説明まで含めて設計する必要があります。特に顧客情報や非公開コードを扱う組織では、Claude Codeの利便性と同時に「後から説明できる運用」を用意しておくことが重要です。
これから企業導入を検討するなら、まずはClaude Codeの利用ルールと権限設計を整理し、その上でCompliance APIを監査基盤へどう接続するか考える順番が現実的です。
コメント