Claude Codeを社内で使い始めた会社から、こんな声を聞きます。
「Claude Codeが操作を止めたり、確認を求めてきたりします。でも、どの設定が止めたのか分からず、毎回そこで手が止まります」
「自動モードで動かしていると、何を止めて、何を通したのかを、あとから確かめる方法がありません」
「社員が『その場だけ許可』を押した操作を、管理する側として把握しておきたいです」
結論を先に言います
Claude Codeのsafety_eventとは、権限ルールや自動モードの判定役など、どのチェックがツールの呼び出しを拒否したか、または確認を求めたかを記録するOpenTelemetryのイベントです。
Claude Code 2.1.307で追加され、利用には2.1.307以降が必要です。記録には、チェックの種類を表す category のほか、decision、reason_code、rule_source などの項目が含まれます。ただし、どのコマンドだったかまで見るには、別のイベントと詳細ログの設定が要ります。何を送り、どこに保存するかを先に決めてから有効にするのがいいかなと思います。
この記事で持ち帰れること
- safety_eventとは何か、何を記録するイベントなのか
- 記録から読める項目と、「知りたいこと」ごとに見るイベント
- 有効にする方法と、リポジトリの設定ファイルでは有効にできない点
- コマンドの中身を見るときに、記録に残る内容が増えることへの注意
- 部署別の使いどころと、止まった記録を運用に生かす方法（弊社の考え）
safety_eventとは：止めた・確認した操作の記録
Claude Codeの公式changelog（https://code.claude.com/docs/en/changelog）には、バージョン2.1.307の項目に「権限ルール、自動モード、安全チェック、フック、サンドボックスが止めた、確認を求めた、または差し戻したツール呼び出しごとに、claude_code.safety_event というOpenTelemetryのイベントを追加した」という趣旨の記載があります。GitHubのCHANGELOG.md（https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md）にも、2.1.307の項目に同じ内容が載っています。
Agent SDKの公式ドキュメント「Observability with OpenTelemetry」（https://code.claude.com/docs/en/agent-sdk/observability）では、safety_eventを「権限ルールや自動モードの判定役（classifier）など、どのチェックがツールの呼び出しを拒否したか、または確認を求めたか」を示すイベントとして紹介しています。利用にはClaude Code v2.1.307以降が必要で、safety_eventが出ない呼び出しもある、とされています。
同じページによると、これらのイベントは claude_code. で始まる名前のログとして出力されます。ツール呼び出しごとの許可・拒否と結果を記録する tool_decision や tool_result、権限モードの変更を記録する permission_mode_changed と並ぶ、監査向けのイベントの1つという位置づけです。
記録から何が読めるのか：知りたいことごとに見るイベント
公式ドキュメント「Monitoring」（https://code.claude.com/docs/en/monitoring-usage）の「Audit security events」の節には、知りたいことと、見るべきイベント・項目の対応表があります。safety_eventに関わるものを中心に整理すると、次のとおりです。
| 知りたいこと | 見るイベント | 主な項目 |
|---|---|---|
| どのチェックが拒否したか、確認を求めたか | safety_event（category がチェックの種類を表す。例：managed_policy、permission_rule、hook、auto_mode_block） | category、decision、reason_code、rule_source、tool_name、tool_use_id |
| どのツール呼び出しをフックが拒否したか、どの結果やターンの終了をフックが止めたか | safety_event（category が hook で decision が reject、または category が hook_review） | category、decision、hook_event |
| サンドボックスのネットワークプロキシが、Bash・PowerShellのコマンドの接続や通信を拒否したか | safety_event（sandbox_violation_count があり、"0" ではないもの） | sandbox_violation_count、category、sandbox_enabled、tool_use_id |
| ツール呼び出しが許可されたか拒否されたか、その判断が設定・フック・人のどこから来たか | tool_decision | decision、source、permission_mode、tool_name |
| 権限モードが切り替わったか | permission_mode_changed | from_mode、to_mode、trigger |
同じ表では、実行されなかった呼び出しのsafety_eventは decision が reject になる、とされています。なお、safety_eventが出ない呼び出しもある、とされています。
どのコマンドだったかは、別のイベントで見る
同じ表によると、実行したコマンドや触ったファイルを知りたいときは、OTEL_LOG_TOOL_DETAILS=1 を設定したうえで、実行されたものは tool_result、拒否されたものは tool_decision の tool_parameters を見る、とされています。
Agent SDKの「Observability with OpenTelemetry」でも、OTEL_LOG_TOOL_DETAILS=1 にすると、ファイルのパスやシェルのコマンドなどのツールへの入力が tool_result イベントに付くと説明されています。自動モードの判定役が止めたときに挙げたルールも、classifier_category として tool_decision と safety_event に付くようになります。
異常の検知は、受け取る側の仕事
「Monitoring」のページでは、Claude Codeが出すのはイベントそのものだけで、異常の検知や平常値との比較、セッションをまたいだ突き合わせ、アラートは、受け取る側のSIEMや監視の仕組みが担う、とされています。safety_eventを出しただけで、危ない操作を知らせてくれるわけではない点は押さえておきたいところです。
有効にする方法と、見るときの注意
safety_eventは、Claude CodeのOpenTelemetryの出力を有効にすると出てきます。「Monitoring」のページのクイックスタートと設定の説明では、次のような環境変数を使います。
| 環境変数 | 役割 |
|---|---|
CLAUDE_CODE_ENABLE_TELEMETRY=1 | テレメトリーの収集を有効にする（必須） |
OTEL_LOGS_EXPORTER | ログ・イベントの出力先の種類。otlp、console、none |
OTEL_EXPORTER_OTLP_ENDPOINT | OTLPで送るときの送り先 |
OTEL_LOG_TOOL_DETAILS=1 | ツールのパラメータや入力も記録する（既定は無効） |
注意したいのは、リポジトリの .claude/settings.json や .claude/settings.local.json に書いても、テレメトリーは有効にできないことです。ドキュメントでは、OpenTelemetryの出力に関する変数はこれらのファイルでは無視されるため、管理者設定（managed settings）に書くか、開発者それぞれがシェルや ~/.claude/settings.json で設定する、と説明されています。
もう1つは、OTEL_LOG_TOOL_DETAILS=1 にすると、Bashのコマンドやツールへの入力まで記録に残ることです。Agent SDKの「Observability with OpenTelemetry」でも、扱うデータを保存してよいと承認された仕組みでない限り、こうした変数は設定しないよう勧めています。どこへ送り、どこに保存するかを先に決めておくのがいいかなと思います。
権限ルールとフックの関係も押さえておく
safety_eventを読むときは、権限ルールの仕組みも知っておくと迷いにくくなります。公式ドキュメント「Permissions」（https://code.claude.com/docs/en/permissions）によると、ルールは拒否（deny）、確認（ask）、許可（allow）の順に評価され、最初に当てはまったものが結果になります。
また、終了コード2で止めるフックは、権限ルールが評価される前にツールの呼び出しを止めるため、許可ルールがあっても止まる、とされています。safety_eventの category が hook なのか permission_rule なのかを見れば、どちらで止まったのかを切り分けられます。
部署別の使いどころ（ここからは弊社の見解です）
ここからは、弊社が考える使い方です。
| 部署・立場 | 見るとよさそうなもの | 生かし方 |
|---|---|---|
| 情報システム部門 | 管理者設定で止まった件数と、その種類 | 会社として禁止している操作が、実際にどれくらい試されているかを把握する |
| 開発チーム | その場だけ許可した操作 | 毎回許可している操作は、チームの設定ファイルのルールにする |
| AIに定型業務を任せている部署 | 自動モードで止まった操作 | 止まり続ける操作は、AIへの指示や手順のほうを直す |
| 少人数の会社 | 止まった操作の一覧を週に1回 | まずは手元の画面への出力で、止まり方の傾向をつかむ |
正直、いきなり社外の監視サービスへ全部送る必要はないかなと思います。最初は、止まった件数と種類を週に1回見るくらいで十分ではないでしょうか。
CodeClimbの見解
弊社は、Claude Codeを自社の業務で毎日使っています。WordPressの本番操作は専用のフックで止め、固定ページの変更や公開状態の変更、削除はAIからできないようにしています。この記事の公開も、出典の確認と事実チェックを通ったものだけが進む仕組みにしています。
そのうえで実感しているのは、止まること自体より、止まった理由が分からないことのほうが困るということです。
たとえば弊社では、許可リストに入れていたコマンドが、パイプなどを継ぎ足しただけで一致しなくなり、止められていたことがありました。当時は設定が足りないと思い込み、原因が分かるまでに1日かかっています。記事を公開する処理が自動モードの判定で止まり、専用の許可を足したこともあります。どちらも、どの仕組みが止めたのかがすぐ分かれば、もっと早く直せたはずです。
safety_eventは、まさにこの「どこで止まったか」を残す仕組みだと考えています。ただし、弊社もまだsafety_eventを有効にして運用した実績はありません。試すなら、まず手元の画面への出力で、止まる操作の傾向を見るところから始めるつもりです。
あとは、記録を取ること自体が目的にならないようにしたいところです。その場の許可が多い操作は設定ファイルのルールにする、止まり続ける操作は手順を直す。記録は、この見直しのための材料かなと思います。
Claude Codeの業務での管理については、Claude Codeの業務管理の記事や、クラウドセッションの使い方でも書いています。他社のAIのサンドボックス管理と比べたい方は、GitHub Copilotのローカルサンドボックスの記事もあわせてどうぞ。
よくある質問
Q. safety_eventだけを有効にする設定はありますか
「Monitoring」のページのクイックスタートでは、CLAUDE_CODE_ENABLE_TELEMETRY=1 でテレメトリーを有効にし、OTEL_LOGS_EXPORTER でログ・イベントの出力先を選びます。safety_eventは、このログとして claude_code.safety_event という名前で出力されます。
Q. 社員それぞれのPCで、まとめて有効にできますか
「Monitoring」のページでは、リポジトリの設定ファイルではテレメトリーを有効にできないため、管理者設定（managed settings）に書くか、開発者それぞれがシェルや ~/.claude/settings.json で設定する、と説明されています。会社としてそろえるなら、管理者設定を使う形になります。
Q. サンドボックスが止めた通信も分かりますか
「Monitoring」のページによると、サンドボックスのネットワークプロキシがBashやPowerShellのコマンドの接続や通信を拒否した場合は、safety_eventのうち sandbox_violation_count があり、その値が "0" でないものを探すと見つけられます。
まとめ
Claude Codeのsafety_eventとは、どのチェックがツールの呼び出しを拒否したか、または確認を求めたかを記録するOpenTelemetryのイベントです。2.1.307で追加されました。
記録には、チェックの種類を表す category や、rule_source などの項目が含まれます。一方で、どのコマンドだったかを見るには OTEL_LOG_TOOL_DETAILS=1 と tool_decision などの別のイベントが必要です。リポジトリの設定ファイルでは有効にできない点も押さえておきたいところです。
止まった理由が残れば、同じ所で毎回迷わずに済みます。まずは小さく出してみて、止まり方の傾向を見る。この順番で考えておくのがいいかなと思います。
社内のAIの「止め方」を、一緒に決めませんか
CodeClimbは、AIツールを売る側ではなく、自社の業務をAIに任せる仕組みを作って回している側の会社です。AIに任せる操作と止める操作を分け、止まったときに理由が分かる形にするところからお手伝いしています。
「Claude Codeを社内で使わせたいけれど、どこまで許可すればいいか分からない」という段階からでも構いません。AI活用支援のサービス内容をご覧いただいたうえで、お問い合わせから今の状況をお聞かせください。
出典
https://code.claude.com/docs/en/changelog ｜ Claude Code Docs（Changelog） ｜ 参照 2026-10-27
https://code.claude.com/docs/en/monitoring-usage ｜ Claude Code Docs（Monitoring） ｜ 参照 2026-10-27
https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md ｜ GitHub anthropics/claude-code（CHANGELOG.md） ｜ 参照 2026-10-27
https://code.claude.com/docs/en/permissions ｜ Claude Code Docs（Permissions） ｜ 参照 2026-10-27
https://code.claude.com/docs/en/agent-sdk/observability ｜ Claude Code Docs（Agent SDK: Observability with OpenTelemetry） ｜ 参照 2026-10-27
