Claude Code を監査対応にする設定|全コマンド分類と応答ログ

個人で Claude Code を速く回せるようになっても、いざ企業案件になると「ログは残るのか」「危険なコマンドは止まるのか」と問われて手が止まる開発者は多いはずです。2026-06-25 公開の v2.1.193 では、全シェルコマンドを分類器に通す設定、モデル応答をトレース基盤へ記録するログイベント、リモート操作のデバイス認証が出そろいました。本記事では、これらを使って「監査に通る Claude Code」を組み、その設計力を高単価案件に変える手順を整理します。

Conclusion

v2.1.193 の肝は三点です。設定 autoMode.classifyAllShell で Bash/PowerShell の全コマンドを分類器に通せる ようになり(従来は任意コード実行パターンのみ)、危険操作の検出網が広がりました。これは 「全部ブロック」ではなく「全部いったん判定する」 仕組みで、止めるか通すかは分類結果に従います。出典はリリースノートです。

二つ目が監査証跡です。OpenTelemetry のログイベント claude_code.assistant_response を有効化するとモデルの応答テキストを記録 できます。既定では無効で、環境変数による明示的な有効化が必要 なため、入出力を可観測性基盤に集約する運用は意図して設計しないと始まりません。

三つ目が Trusted Devices for Remote Control で、Team/Enterprise 管理者が リモート操作時のデバイス認証を必須化 できます。これらを「設定パッケージ+監査証跡設計+教育」として束ねられる人材は希少で、企業導入のボトルネックそのものを解く高単価案件に直結します。

Contents (13)

なぜ今「監査に通る Claude Code」がエンジニアの武器になるのか

AI コーディング支援の「速く書ける」部分は、もはや差別化要因になりにくくなりました。最先端モデルは各社が横並びで提供し、補完や生成のスピードだけでは案件単価が上がりません。一方で企業が本気で財布を開くのは、「事故らない」「説明責任を果たせる」運用設計です。誰が何を実行し、AI が何を返したかを後から追えること、危険な操作が握り潰されないこと——この監査可能性こそが、現場で最後まで残る課題になっています。

政策面でも統制要件は年々具体化しています。政府は人工知能基本計画の改定素案をまとめてパブリックコメントを実施し(https://www8.cao.go.jp/cstp/stmain/20260619ai.html )、行政自身も生成 AI 活用の取り組みを公開しています(https://www.digital.go.jp/en/policies/genai )。本記事は公開情報の範囲で触れるにとどめますが、調達・統制の文脈で「監査に耐える AI 運用」を示せる人材への需要は確実に高まっています。

「速さ」から「任せられる安全さ」へ要求が移った

ここ数か月で現場の問いは明確に変わりました。「どれだけ速いか」ではなく「どこまで安全に任せられるか」です。チーム導入では、個人の生産性より統制が優先され、ログ・分類・認証の三点セットが導入可否を分けます。この移行を理解している開発者は、提案の最初の一言から評価が変わります。

全コマンド分類 autoMode.classifyAllShell — 何が変わり、どう設定するか

v2.1.193 で追加された autoMode.classifyAllShell は、Bash および PowerShell で実行されるコマンドの扱いを変える設定です(https://github.com/anthropics/claude-code/releases/tag/v2.1.193 )。従来は「任意コード実行パターンに該当するコマンドのみ」を分類器に通していましたが、この設定を有効にすると全シェルコマンドを分類器に通すようになります。一見ありふれた lscat も含めて、いったん判定の対象に乗せるという発想の転換です。

重要なのは、これが「すべてを一律ブロックする」設定ではないという点です。分類に通すこと自体は、止めることと同義ではありません。分類器が安全と判断すれば通り、危険と判断すれば止まる——つまり検出の網を広げる設定であって、業務効率を一律に犠牲にするものではありません。ここを誤解して「全部止まって使えなくなる」と説明すると、提案先の信頼を失います。

設定を有効化する手順

監査前提の環境で全コマンド分類を有効にする流れは次のとおりです。

  1. 対象組織の設定方針を決める。個人検証なら自分の設定ファイル、チーム配布なら共有設定として配る。
  2. autoMode.classifyAllShell を有効化し、全シェルコマンドを分類対象に含める。
  3. 検証環境で普段使うコマンド列を一通り流し、過剰に止まる運用上の摩擦がないかを観察する。
  4. 摩擦が出た場合は、止めるべき操作と通してよい操作の線引きを記録し、運用ルールに反映する。
  5. 線引きを文書化したうえで、本番環境やチームへ展開する。

この「いきなり全展開せず、検証で摩擦を測ってから配る」順序が、導入後のクレームを防ぐ肝になります。

「分類に通す」≠「ブロック」を提案先に正しく伝える

提案資料では、この設定を「危険操作の検出網を広げるもの」と位置づけてください。全コマンドを判定対象にすることで、これまで素通りしていた操作も評価の俎上に載る——この説明は、統制を求める情シスにとって魅力的に響きます。一方で「業務が止まる」懸念には、分類はブロックと別物であり、止まるのは危険と判断された操作だけだと具体例で示すと納得が得られます。

応答ログをトレース基盤へ — claude_code.assistant_response の有効化と監査証跡設計

監査で問われるのは「何を実行したか」だけではありません。「AI が何を返したか」も証跡として残せるかが鍵になります。v2.1.193 では OpenTelemetry のログイベントとして claude_code.assistant_response が追加され、モデルの応答テキストをトレース基盤へ記録できるようになりました(https://support.claude.com/en/articles/12138966-release-notes )。これにより、入力だけでなく出力までを含めた監査証跡を組み立てられます。

ただし、このイベントは既定で無効です。記録するには環境変数による明示的な有効化が必要で、何もしなければ応答ログは残りません。これは合理的な初期値で、応答にはコードや業務情報が含まれ得るため、記録するかどうかを組織が意図して選ぶ設計になっています。だからこそ「黙っていても残る」と誤解せず、有効化と保管方針をセットで設計できる人材に価値が生まれます。

監査証跡として残すための設計手順

応答ログを可観測性基盤に集約し、監査に耐える形にする流れは次のとおりです。

  1. 記録の目的と保管期間を先に決める。何のために残し、いつ消すかを定義する。
  2. 環境変数で claude_code.assistant_response を含む応答ログを明示的に有効化する。
  3. 出力先の可観測性基盤(Datadog や Grafana など)を指定し、入出力を一元集約する。
  4. 機密情報の取り扱い方針を定める。応答に含まれ得る情報の保護・マスキング方針を文書化する。
  5. アクセス権限を設計し、ログを誰が閲覧できるかを限定する。

この一連の設計は、そのまま提案先への監査証跡ドキュメントに転用できます。

可観測性基盤に集約する運用イメージ

応答ログを基盤に流し込むと、いつ・どのプロジェクトで・どんな出力が生成されたかを後から検索できます。インシデント発生時の調査、利用状況の把握、コンプライアンス報告——いずれも証跡があって初めて成立します。記録を有効化していなかったために「何が起きたか分からない」状態を避ける、その守りの設計こそが企業に響く付加価値です。

Trusted Devices とリモート操作の統制 — デバイス認証を必須化する

v2.1.193 と同日には Trusted Devices for Remote Control が提供開始され、Team/Enterprise 管理者がリモート操作時のデバイス認証を必須化できるようになりました(https://support.claude.com/en/articles/12138966-release-notes )。これにより、管理者は「認証されたデバイスからのリモート操作のみを許可する」というゲートを設けられます。誰のどの端末から操作されたかを統制下に置く仕組みです。

この機能が効くのは、外部委託先やリモート環境への展開場面です。社外のメンバーや自宅環境からの操作にデバイス認証を挟めると、統制の不安から導入をためらっていた組織でも展開の障壁が下がります。「どの端末を信頼するか」を管理者が握れることは、分散したチームほど価値が大きくなります。

委託・リモート展開の障壁を下げる文脈で語る

提案では、この機能を「外部委託や在宅環境でも統制を保ったまま AI 支援を広げられる仕組み」として位置づけると刺さります。セキュリティ部門が懸念するのは、管理外の端末からの操作です。デバイス認証を必須化できれば、その懸念に正面から答えられ、導入範囲を広げる交渉材料になります。

これを"案件"に変える — 企業導入支援・運用設計で単価を上げる動き方

ここまでの三点——全コマンド分類、応答ログの監査証跡、デバイス認証——を個別の機能として知っているだけでは案件になりません。価値が生まれるのは、これらを束ねて「設定パッケージ+監査証跡設計+教育」という提案メニューに仕立てたときです。企業が AI コーディング支援を導入できない理由の多くは、統制と説明責任の設計が描けないことにあります。そのボトルネックを丸ごと引き受けられる人材は希少で、高単価が成立します。

具体的には、自分の検証環境で再現した設定一式をそのまま提案資料に転用し、「このとおり設定すれば監査に通る」と示せる粒度まで落とし込むことが武器になります。機能の存在を知っている人は多くても、検証済みの運用パッケージとして提示できる人は少数です。週末に手を動かして再現しておけば、月曜にはそのまま提案できます。

今週末に試す具体ステップ

提案メニュー化に向けて、まず手を動かす順序は次のとおりです。

  1. 個人の検証環境で autoMode.classifyAllShell を有効にし、全コマンド分類の挙動と摩擦を記録する。
  2. 応答ログのイベントを環境変数で有効化し、可観測性基盤へ出力されることを確認する。
  3. 記録した設定と画面を、そのまま「監査対応 設定手順書」として一枚にまとめる。
  4. Team/Enterprise 文脈のデバイス認証は、公開情報をもとに「展開時に必須化できる統制」として提案に位置づける。
  5. 「設定パッケージ+監査証跡設計+教育」の三本立てで見積もりメニューを作る。

この順序で進めれば、最新トピックの知識が、そのまま企業導入支援という高単価案件の提案資料に変わります。速く書く段階から、組織が安全に任せられる段階へ——その設計を担える側に回ることが、これからのエンジニアの稼ぎ方です。

出典

Helpful? ♡
Clauder Navi Editorial Team
@clauder_navi

Delivering the latest Claude / Claude Code news and practical insights daily. Learn more about us at About this site.