結論：会話全文ではなく「判断の連鎖」を残す
先に答えると、Claude Codeの監査ログは、会話をすべて保存するだけでは不十分です。誰が、どの業務目的で、何を対象にし、どの権限を承認し、生成結果をどう検証し、採用・却下したかを一つの記録IDでつなぎます。技術ログと人間の判断記録を分けて関連付けると、事故時にも通常時にも説明できます。
読者の具体的な困りごとは、変更はGitに残っていても「なぜAIへ任せ、誰が承認したか」を説明できないことです。読了後は、自社に必要な十項目と保存範囲を決められます。次の行動は、次回のClaude Code作業に業務ID、担当者、承認者、採否理由の四欄を付けることです。
監査目的を先に固定する
ログを集める前に、何を説明するための記録かを決めます。情報漏えい、権限逸脱、誤変更、品質事故、費用超過、契約違反では必要な証跡が違います。「すべて保存」は保管コストと機密リスクを増やし、重要な判断を埋もれさせます。対象業務、保存期間、閲覧者、削除方法を先に決めます。
開発者監視を目的にすると現場が隠す運用になります。目的は人を責めることではなく、変更の再現、承認の確認、事故の封じ込め、運用改善です。ログを見る担当者と評価する担当者を分け、通常レビューと事故調査の閲覧範囲を分けます。
技術ログと判断記録を分ける
技術ログには、セッション時刻、モデルや実行面、ツール利用、権限要求、結果、エラー、利用量などがあります。判断記録には、業務目的、対象、入力区分、承認理由、検証結果、採否、例外が含まれます。技術ログだけでは「なぜ許可したか」を説明できず、判断記録だけでは「実際に何が起きたか」を確認できません。
二つを業務IDや変更IDで関連付けます。コード変更ならチケット、pull request、commit、レビューをつなぎます。調査だけで変更がない場合も、依頼、参照範囲、出力、採否を残します。AIの文章を最終判断として保存せず、人間が確認した結論を別欄に書きます。
例えば、脆弱性修正をClaude Codeへ依頼した場合、プロンプト全文よりも、対象CVE、影響範囲、変更ファイル、実行したテスト、レビュー担当、採用理由を追えることが重要です。提案を却下した場合も、誤りの内容と代替対応を残せば、同じ提案を別担当者が採用する事故を防げます。採用と却下の両方が運用改善の材料です。
企業が残す監査ログ10項目
- 業務ID、日時、担当者、所属を記録します。
- 利用目的と完了条件を一文で残します。
- 対象リポジトリ、環境、データ区分を残します。
- 利用した認証経路と組織を記録します。
- 要求された権限と承認者、承認理由を残します。
- 主要なツール実行と外部接続先を記録します。
- 生成・変更された成果物と差分を関連付けます。
- テスト、レビュー、readbackの結果を残します。
- 採用、修正、却下とその理由を記録します。
- 例外、事故、停止、再発防止を関連付けます。
すべてを手入力すると続きません。Git、チケット、CI、Claude Codeのテレメトリなど既存証跡を参照し、人間だけが書ける目的、承認理由、採否へ入力を絞ります。リンク切れを防ぐため、記録IDと保存期間を共通にします。
OpenTelemetryで取得できる範囲
Anthropic公式Monitoringガイドは、Claude CodeがOpenTelemetryで利用量、費用、ツール活動をmetrics、events、任意のtracesとして出力できると説明しています。組織管理者はmanaged settingsで設定を配布できます。これは技術的な観測基盤であり、人間の採否や業務目的を自動で保証するものではありません。
導入時は、取得するsignal、送信先、認証、閲覧者、保持期間を決めます。コレクターへ到達するか、正常なセッションで想定イベントが入るかを確認します。ログ本文へプロンプトや機密情報を含める設定は、必要性と法的条件を確認せず有効化しません。収集不能時の通知も用意します。
監視基盤へ送れたことと、監査として十分なことも分けます。イベントが欠けた期間、端末がオフラインだった期間、設定変更で収集が止まった期間を可視化します。ログ欠損時は作業を全面停止するのか、高リスク操作だけ止めるのかを業務別に決めます。欠損を正常値として扱わないことが重要です。
記録様式には版番号と管理者を付けます。項目を追加・削除した日と理由を残し、古い記録を新基準で評価したように見せません。監査で不足が見つかった時は、責任追及だけでなく次回の入力欄、通知、レビュー手順へ反映します。
権限承認を監査可能にする
Claude Codeでは、読み取り、編集、コマンド、外部接続など作業ごとにリスクが異なります。承認記録には「許可した」という結果だけでなく、対象、期間、目的、承認者を残します。広い権限を恒久的に許可した場合ほど、理由と見直し日が必要です。
緊急対応で例外を認めた時は、終了時刻と戻し作業を同じチケットへ置きます。口頭承認だけで進めた場合は、作業後すぐに追認の記録を作ります。ただし、禁止情報の入力や権利不明なデータ利用は、後から承認を付けても正当化できません。停止条件を優先します。
保存期間とアクセスを決めるチェックリスト
保存前に、法令・契約上の必要期間／業務上の再調査期間／個人情報／営業秘密／削除責任者／バックアップ／閲覧権限／エクスポート／改ざん防止／期限到来時の削除、を確認します。長期保存ほど安全とは限りません。不要なプロンプト全文や秘密値は保存対象から外します。
閲覧権限は最小限にし、ログ管理者自身の閲覧とエクスポートも記録します。監査ログを一般共有フォルダへ置かず、事故調査で一時共有した複製には期限を付けます。退職者、異動者、外部委託先のアクセス解除も定期レビューへ含めます。
月次レビューと事故時の使い方
月次では、権限例外、却下された変更、同じ失敗の再発、ログ欠損、長期未レビュー、費用異常を確認します。件数だけで評価せず、なぜ例外が必要だったかを運用ルールへ反映します。繰り返す承認は、安易な常時許可ではなく、安全な標準手順へ昇格できるかを検討します。
事故時は、対象業務IDから担当者、権限、ツール、変更、検証、採否を時系列でたどります。推測で責任者を決めず、確認済み事実と未確認事項を分けます。証跡を編集する前に保全し、秘密情報を含む場合は会社の事故対応手順へ引き継ぎます。
内部リンクと公式情報
承認ルールはClaude Codeの権限設定、導入全体の責任分担はClaude Codeの企業導入、入力範囲はClaudeへ入力してはいけない情報を確認してください。
組織向けテレメトリの最新仕様はAnthropic公式Monitoringガイド、費用と利用量の確認経路は公式Manage costs effectivelyでreadbackしてください。取得項目や管理機能は変わるため、導入時と設定変更時に再確認します。
Miraigentの無料診断では、目的、権限、証跡、保存期間、事故時の責任者を一枚の運用表へ整理します。ログを集めるだけでなく、判断を説明し改善へ使える状態を作ります。