8月31日、Dan Abramov（The Hacker Newsに寄稿するセキュリティライター。React開発者の同名人物とは別人）が「Securing Claude Code: The New Compliance API, Local Visibility, and Identity Governance」と題した記事を公開した。企業セキュリティ担当者の82%が「把握していないエージェントを発見した」と回答し、ローカルエージェントが全体の**68.6%**を占めるという調査結果を背景に、AnthropicのCompliance APIだけでは埋められない3つのガバナンスのギャップを3層構造で解説している。
Compliance APIだけでは足りない——それが本題だ
2026年8月11日、AnthropicはClaude Codeのローカルセッションを対象とした新しいCompliance APIエンドポイントを公開した。これまでAnthropicのCompliance APIはclaude.aiのWebインターフェースやClaude Desktopの操作ログが中心で、Claude Codeのカバレッジは薄かった。今回の追加で、エンドポイント上で動くエージェントの活動をある程度把握できるようになった。
ただし、記事の核心はそこではない。「Compliance APIを使えば大丈夫」ではなく、「それでもまだ足りない理由」を3層構造で解説している点が、企業導入エンジニアにとって実務直結の内容となっている。具体的なギャップは「静的ポリシーが動的コンテキストを捕捉できない」「オフラインのローカル設定がAPIログに残らない」「IDと意図の紐付けができない」の3点だ。
なぜClaude Codeはガバナンスが難しいのか
Claude Codeはブラウザ上で完結するチャットボットではなく、開発者のマシン上でbashコマンドを実行し、MCPサーバーに接続し、ファイルを読み書きするローカルエージェントだ。
ここでいうMCP（Model Context Protocol）とは、LLMが外部ツールやサービスを呼び出すためにAnthropicが策定したオープンプロトコルで、Claude CodeはこのMCPを通じてJiraやGitHub等の外部サービスと連携できる。
重要な構造として、LLM（モデル本体）はAnthropicのクラウドで動くが、実際にコマンドを叩いたり認証情報を使ったりするのは「ハーネス（harness）」と呼ばれるローカル側のオーケストレーターである。原文のharnessは「制御・統御する仕組み」を指す技術用語で、ここではClaude Codeのローカルプロセス全体を指す。記事はこれを「脳はクラウドにあるが、手足はエンドポイントにある」と表現している。
Token Securityが顧客環境で調査した結果、AIエージェントの68.6%がこのようなローカルエージェントであり、多くが従業員の認証情報やネットワーク権限をそのまま引き継いでいる。さらに同社がCloud Security Alliance（CSA）と共同で実施した418名のIT・セキュリティ専門家へのアンケートでは、82%が「過去1年でセキュリティ/IT/ガバナンスが把握していないエージェントを発見した」と回答している。
3層のガバナンス構造と各層のギャップ
ギャップ1 — Layer 1: Managed Settings（ポリシーベースライン）
Claude Codeはインストール時にマネージド設定ファイル（MacとLinuxはJSON、WindowsはレジストリエントリD）を参照する。これがすべてのセッション設定より優先される。設定できる内容は以下の通りだ。
- MCPサーバーの許可/拒否リスト
- bashコマンドへの正規表現フィルタ
- スキルによるコマンド実行の無効化
ここでのギャップは「静的ルールは動的な実行コンテキストを把握できない」点だ。定義済みパターン以外の実行を制限しきれないうえ、開発者の行動の幅を大きく制限するという副作用もある。
ギャップ2 — Layer 2: Compliance API（セッションログ）
今回追加された主要エンドポイントは3つだ。
| エンドポイント | 取得できる内容 |
|---|---|
GET /v1/compliance/apps/sessions/local |
セッションのメタデータ一覧 |
GET /v1/compliance/apps/sessions/local/{session_id} |
個別セッションのメタデータ |
GET /v1/compliance/apps/sessions/local/{session_id}/messages |
セッションのトランスクリプト |
ログはテキスト、tool_use、tool_resultの3種類のブロックで構成される。ユーザープロンプト、bashコマンド、ファイルの読み書き、MCPコマンドまでカバーされる。
ただし、見落とせない制約がある。
- Anthropicのモデル以外（Bedrock、Foundry、Google Cloud上のモデル）を使うセッションはCompliance APIに記録されない
- エンドポイント上でLLMに到達しない処理（フックによるコマンドブロック等）はログに残らない
- トランスクリプトにはPII、シークレット、顧客データが含まれる可能性があり、それ自体がセンシティブなデータソースになる
このレイヤーのギャップは「オフラインのローカル設定や、APIを経由しない処理がログに残らない」点だ。
ギャップ3 — Layer 3: エンドポイント固有の情報
Compliance APIとOTel（OpenTelemetry）——分散システムのトレース・メトリクス・ログを収集するオープン標準——が「エージェントが何をしたか」を記録するのに対し、ディスク上の静的情報はエンドポイントからしか収集できない。 スキル/プラグインの.mdファイル、設定ファイル、セッション外で起動されたプロセスなどがこれにあたる。Token Securityの調査では、ローカルエージェント1つあたり平均10個以上の設定ファイルがエンドポイント上に散在しているという。
なお、Claude Codeはデフォルトで30日間セッション履歴をローカルに保存する。エンドポイントへの不正アクセスが発生した場合、これらのファイルも読まれるリスクがある。
このレイヤーのギャップは「LLM固有のセマンティックコンテキスト——そのプラグインが正規のものかどうか——はEDRでも判別できない」点だ。
3層を組み合わせても埋まらないギャップ
記事はこの3層の限界を率直に認めている。
| レイヤー | 主な役割 | カバーできないもの |
|---|---|---|
| マネージド設定 | 静的ポリシーの適用 | 動的な実行コンテキスト |
| セッショントランスクリプト | セッション単位のアクション記録 | オフラインのローカル設定 |
| エンドポイント/EDR | 静的設定収集・プロセスログ | LLM固有のセマンティックコンテキスト |
最大の問題はIDと意図の紐付けだ。トランスクリプトを見ても、「そのプラグインが内部エンジニアが書いた正規のものか、インターネットから引っ張ってきた悪意のあるものか」は判断できない。
記事はこの解決策として、エンドポイント上で動いているスキルやプラグインを社内リポジトリと照合して正当性を確認すること、そしてエージェントの所有者・目的・認証情報・権限を結びつける「アイデンティティを制御プレーンとして扱う」アプローチを提示している。
トランスクリプトのパース実務
MCPサーバーはtool_useブロックのnameフィールドにmcp__<server>__<command>という形式で現れる。ベンダー製はmcp__jira__create_issueのように読みやすい名前だが、ユーザーが接続したサーバーはUUIDになる。注目すべき点として、Token Securityが発見したMCPサーバーの35.1%がコミュニティ製または出所不明だという。
スキルの検出はやや間接的で、ハーネスがモデルにSKILL.mdを渡すときのファイルReadのパスからスキル名と場所を特定できる。プラグインはさらに難易度が高く、バンドルされたファイルのパス命名規則から推測する形になる。
詳細はSecuring Claude Code: The New Compliance API, Local Visibility, and Identity Governanceを参照していただきたい。
