Claude Code 監査ログ完全ガイド｜取得経路・保存設計・コンプライアンス対応

社内でClaude Codeの導入が進むにつれ、最初にセキュリティ部門から飛んでくる質問はだいたい同じです。「誰が、いつ、どのコードに対して、どんな操作をAIに依頼したかを後から追えますか？」——監査ログの設計は、エンタープライズ環境で Claude Code を「便利な道具」から「統制可能な業務基盤」に格上げするための要件 です。

しかし、Claude Codeの監査ログは1か所には存在しません。Anthropicの管理画面、OpenTelemetry経由のテレメトリ、Hooksによるイベント捕捉、ローカルの会話ログ——4つの取得経路が用途別に分かれて存在し、組み合わせて初めて「監査可能な状態」になる という構造になっています。

本記事では、Claude Codeの監査ログを取得・保存・分析する具体的な方法と、SOC2 / ISO27001 などのコンプライアンス要件にどう対応付けるかを整理します。Claude Codeのエンタープライズ導入やセキュリティ・情シス向けの審査ポイントとあわせて読むことで、申請書類・運用設計・監査対応の3点が揃います。

結論 — 監査ログは「4つの経路 × 3つの目的」で設計する

Claude Codeの監査ログ設計でまず押さえるべきは、「何のために何を残すか」を先に決めてから、取得経路を組み合わせる という順序です。経路から考えると、ログだけが大量に蓄積されて活用されない「ログ墓場」になります。

目的	主な取得経路	確認したい問い
コンプライアンス対応	Anthropic Admin API / SSO	誰がいつ利用したか、組織として承認した範囲か
インシデント調査	Hooks / OpenTelemetry	どのコマンドがどのファイルに影響したか
コスト・利用状況の可視化	Admin API / OpenTelemetry	誰がどれだけトークンを消費したか

この3つの目的を明確化したうえで、4つの取得経路（Admin API、OpenTelemetry、Hooks、ローカル会話ログ）から必要なものだけを組み合わせる——これが過不足のないログ設計の出発点です。

Claude Code が記録できる4つのログ経路

Claude Codeの監査ログは、取得元・粒度・到達範囲が異なる4つの経路に分けて理解すると整理しやすくなります。

経路1 — Anthropic Admin API / 管理コンソール

Anthropic の組織管理機能（Team / Enterprise 相当のプラン向け）が提供する 公式の管理APIで、監査の入力データとして活用できる経路 です。組織レベルで「いつ・誰が・どのプロジェクトで・どれだけ利用したか」を集計でき、SSO（SAML / OIDC）と組み合わせれば本人確認まで一気通貫で追跡できます。

Admin API および管理コンソールから参照できる主な情報：

• メンバーごとの利用統計（リクエスト数・トークン消費・モデル種別）
• プロジェクト / ワークスペース単位のコスト集計
• メンバー招待・ロール変更などの管理者操作（管理コンソールから参照）
• 組織のメンバー一覧と権限構成

特徴は 「組織の境界で誰がどれだけ利用したか」をベンダー側で確実に提供してくれる 点です。逆に、個別のコマンド粒度（どのファイルを読んだ・編集したか）までは見えません。Admin API は 監査の補助情報として 利用し、コマンド粒度の証跡は後述の Hooks や OpenTelemetry で補う設計が現実的です。提供範囲は更新が早いため、Anthropic 公式の管理者向けドキュメントを必ず確認 してください。

経路2 — OpenTelemetry によるテレメトリエクスポート

Claude Code は OpenTelemetry（OTel）に対応しており、環境変数を設定するだけで メトリクスとイベントを既存の観測基盤（Datadog / New Relic / Grafana / Elastic 等）に送信 できます。

代表的な環境変数：

# テレメトリ機能を有効化
export CLAUDE_CODE_ENABLE_TELEMETRY=1

# 何をエクスポートするか（メトリクスとログ）
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp

# プロトコル（grpc または http/protobuf）と OTLP エクスポート先
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel.example.com:4317"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>"

# サービス名と環境タグを付与
export OTEL_SERVICE_NAME="claude-code"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment=prod,team=platform"

要注意 — プロンプト本文の送信制御
既定の OpenTelemetry 設定では、プロンプト本文やコード本体は送信されません。ただし、OTEL_LOG_USER_PROMPTS=1 / OTEL_LOG_TOOL_DETAILS=1 / OTEL_LOG_TOOL_CONTENT=1 / OTEL_LOG_RAW_API_BODIES=1 を有効化すると 会話本文・ツール入出力・APIリクエストレスポンス全文が送信される 構成になります。意図せず機密情報が外部観測基盤に流れることを防ぐため、組織側で これらのフラグを既定無効に固定する運用ルール を整備してください。

取得できる情報の例：

• セッション開始・終了イベント
• ツール呼び出しの種類と回数（Edit / Bash / Read など）
• API リクエスト数・レイテンシ・エラー
• トークン消費量（入力 / 出力 / キャッシュ）

「監査と運用観測を同じ基盤に統合したい」場合の本命 です。既存の SIEM や APM に流し込めば、相関分析・アラート・ダッシュボード化までを既存運用の延長で実現できます。

経路3 — Hooks によるイベント単位の捕捉

Hooks は、Claude Code の各イベント（ツール実行前後・セッション開始・完了など）をローカルで捕捉できる仕組みです。「どのコマンドが、どんな引数で実行されたか」をユーザー手元で完全制御できる のが最大の強みです。

監査用途では、PostToolUse フックでコマンド実行ログを社内ログ基盤に転送する構成がよく採用されます。

// ~/.claude/settings.json（抜粋）
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/local/bin/claude-audit-forwarder.sh"
          }
        ]
      }
    ]
  }
}

claude-audit-forwarder.sh 側で標準入力に渡される JSON（ツール名・ツール入力 / 出力・実行ディレクトリなど）をそのまま社内ログ基盤やS3に転送すれば、OTel メトリクスでは見えない「Bash で何のコマンドを実行したか」「Edit で何のファイルをどう変更しようとしたか」レベルの粒度 で記録できます（変更行数や差分はフォワーダー側で集計）。詳しくはClaude Code Hooks による自動化ガイドを参照してください。

監査用フックには 2つの運用ルールを必ず固定 してください。

• exit code は常に 0（exit 2 はツール実行をブロックする挙動）。ログ転送が失敗しても Claude Code の作業を妨げない設計にする
• 転送スクリプト側でマスキング処理（APIキー / トークン / 個人情報）を必ず実装する

経路4 — ローカル会話ログ（~/.claude/projects/）

Claude Code は、ユーザーごとのプロジェクト単位で会話・ツール実行履歴を JSONL 形式でローカルに保存しています。

~/.claude/projects/
└── {project-hash}/
    ├── {session-uuid}.jsonl   # セッションごとの全イベント
    └── ...

このファイルは インシデント調査時に最も詳細な情報源 になります。プロンプト、AI の応答、ツール呼び出しの引数と結果まで時系列で残っているため、「何が起きたか」を再現するのに最適です。

ただし、個人端末ローカルに保存される性質上、組織横断の監査基盤としては機能しません。エンタープライズ運用では、Hooks や OTel で組織側に転送し、ローカルログは「補助的な詳細ソース」と位置づけるのが現実的です。

経路の選び分け — 「どれを採用するか」の判断基準

4つすべてを採用する必要はありません。目的とプランによって、必要なものだけを段階的に積み上げる のが運用負荷を抑えるコツです。

状況	推奨する組み合わせ
まず「誰が使っているか」だけ把握したい	Admin API
インシデント時にコマンド粒度で追跡したい	Admin API + Hooks
既存 SIEM / 監視基盤に統合したい	Admin API + OpenTelemetry
規制業界で完全な操作監査が必要	Admin API + Hooks + OpenTelemetry

ローカル会話ログ（経路4）は 常に副次的な参照ソース であり、これ単体を「監査基盤」と呼ぶことはありません。あくまで個別案件のフォレンジック調査時に活用するものと割り切ってください。

監査ログの保存設計 — 保管期間・アクセス制御・暗号化

ログを取得しても、保管設計が甘いと監査として成立しません。最低限、以下の3点は最初に決めておきます。

保管期間

「どれだけ残すか」の設計を誤ると、コスト超過か証跡不足のどちらかに必ず振れます。最初に 層別保管（直近は詳細・古いものは集計のみ） を前提に、用途別の保管期間を決めるのが定石です。

• コスト系ログ: 月次集計の根拠として 13〜25か月（前年同月比の比較に必要、経験則）
• コンプライアンス系ログ: 業界規制および自社が遵守する規格の最低保管期間に合わせる（後述のコンプライアンスマッピング参照）
• インシデント調査用の詳細ログ: 90日〜1年 が現実的。それ以上は容量とコストに見合わないことが多い

アクセス制御

ログ自体が次のインシデントの種にならないよう、閲覧と変更の権限分離が必須です。

• ログ閲覧権限は 「読める人」と「変更できる人」を分離（Read-only IAM ロールが基本）
• 管理者自身の操作も別ログに記録する（管理者特権の悪用検知）
• ログ転送経路に最低限 TLS 1.2 以上を強制

暗号化と改ざん防止

監査人が最も重視するのは「ログそのものが信頼できるか」です。改ざん耐性を担保する仕組みを最初から組み込みます。

• 保管時は暗号化（KMS 管理鍵 / クラウド事業者管理鍵）
• 監査ログは WORM（Write Once Read Many）相当 の保存形式を選ぶと改ざん耐性が高まる（S3 Object Lock / Azure Blob Immutable Storage / GCS Bucket Lock など）

監査ログから読み取るべき5つの観点

ログを保存しても、何を見るべきかが曖昧だと活用されません。監査・セキュリティ部門が定常的にチェックすべき観点を5つに絞り、ダッシュボードと月次レビューに組み込む のが現実的です。

1. 異常な利用時間帯: 深夜・休日の集中アクセスは内部不正やアカウント乗っ取りのシグナル
2. 特定リポジトリへの集中アクセス: 機密リポジトリへの想定外ユーザーからのアクセス
3. 失敗系コマンドの急増: 権限エラーや拒否されたコマンドの増加は、ポリシー違反試行の可能性
4. トークン消費の外れ値: 平均から大きく外れた個人・チームのコスト異常
5. 想定外の長時間セッション: 通常稼働を大きく超えるセッションは、データ抽出の試行や外部 API 乱用の兆候

コンプライアンス要件への対応マッピング

監査ログ設計は、組織が遵守すべき規格や規制の要件と紐づけて初めて完成します。代表的な規格との対応関係を整理します。

規格・規制	関連する監査ログ要件の例	Claude Code での主な対応経路
SOC 2 Type II	アクセス制御の証跡、変更管理、インシデント対応	Admin API + Hooks + SSO
ISO/IEC 27001	アクセスログの取得・保管、特権アクセス監視	Admin API + OpenTelemetry
GDPR / 個人情報保護法	処理活動の記録、データアクセス記録	Admin API + データフロー設計（DPIA等）
FISC（金融機関全般）	操作ログ取得、特権操作管理、改ざん防止	Hooks + WORM 保存
関連法令（金商法・銀行法等）	取引記録の長期保管（業務種別ごとに7〜10年）	Hooks + WORM 保存（長期保管領域に層別化）
PCI-DSS（カード会員データを扱う場合のみ）	CDE 内のコード変更・操作の追跡	Hooks + アクセス分離設計
医療情報システム安全管理ガイドライン（3省2ガイドライン）	アクセスログ取得、暗号化、本人特定	Admin API + Hooks + 暗号化保管
法定保存期間（医師法・医療法施行規則等）	文書種別ごとに法定の保存期間に従う	業務システム側保管に準じて設計

実務では、「規格の各管理策（コントロール）に対し、Claude Code 側で何の証跡を提示できるか」をマトリクスで管理する ことが効果的です。監査時に「該当ログをどの経路から、どのフォーマットで提示するか」を即答できる状態にしておけば、内部監査・外部監査の双方をスムーズに通過できます。

なお、業界規制の保管期間は 法令と所管庁ガイドラインの双方を確認 し、最新の改定内容を反映してください。本表は設計の出発点として位置づけ、最終的な保管期間は法務部門と協議して決定するのが安全です。

導入時のよくある落とし穴

監査ログ設計でつまずく組織には共通したパターンがあります。

落とし穴1 — 「全部取れば安心」と考える

OTel・Hooks・Admin API・ローカル全部から最大粒度でログを集めた結果、月数十GBのログが蓄積してコストと検索性能が破綻 するケース。目的別に取得粒度を最初から絞り込む のが鉄則です。

落とし穴2 — 個人情報・機密情報がログに混入する

Hooks で送信するコマンド引数に、ファイル内容や認証情報が含まれてしまうケース。フォワーダースクリプト側でマスキング処理を必ず実装 し、ログ閲覧権限を最小化します。

落とし穴3 — ログを「取って終わり」にする

ダッシュボードもアラートも作らず、監査時にしか見ない。これでは異常検知が機能しません。月次レビュー会と異常閾値アラートの2点はリリース時から運用に組み込む のが望ましい運用です。

落とし穴4 — ログ取得を後付けで導入する

導入後にログ要件が出てきて、過去のセッションを再現できないケース。監査要件は PoC 段階から含めておく ことで、後からの大規模なリトライを避けられます。

koromo の実践から

koromo では Claude Code を活用したコード生成と運用を行うクライアント企業向けに、監査ログ設計の支援を行っています。あるSaaS事業者では、SOC 2 Type II 認証取得を控えていたため、監査人からの「AIによるコード生成イベントを証跡として残せるか」という質問に対応する必要がありました。

採用したのは Admin API + Hooks + 既存 OTel Collector の3経路構成です。Admin API で組織レベルの利用統計、Hooks で PostToolUse イベントを社内 S3（Object Lock 有効）に転送、OTel で開発側の運用観測——という役割分担で、運用負荷を増やさずに監査要件を満たすことができました。

導入で最も効果が高かったのは、「監査時に何を提示するか」をマトリクスとして先に作ったこと です。SOC 2 の各コントロールごとに「どの経路の、どのログから、どんなレポートを生成するか」を1ページの一覧に落とし込んだ結果、監査人とのやり取りが大幅に短縮されました。

逆に、初期に陥ったのは前述の「落とし穴1」（全部取れば安心）の典型例でした。Hooks で全ツール実行を未加工で転送した結果、1日1GBのログが蓄積する事態になり、3週間で再設計。ツール種別と影響範囲でフィルタを入れる ことで、ログ量を1/10に圧縮しつつ必要な粒度は維持できました。

まとめ

Claude Codeの監査ログは、Admin API・OpenTelemetry・Hooks・ローカル会話ログの4経路を 目的別に組み合わせて設計する のが本質です。「全部取る」ではなく「コンプライアンス・インシデント調査・コスト可視化のどれを優先するか」から逆算することで、運用負荷とコストを抑えながら監査要件を満たせます。

エンタープライズ環境での Claude Code 運用は、技術ではなく 証跡設計 が成否を分けます。本記事のマッピング表をベースに、自社のコンプライアンス要件と取得経路を1枚のマトリクスにまとめれば、社内承認・外部監査・インシデント対応の3場面すべてで使える設計書になります。