Claude Code auto modeと権限スキップ：確認を減らす設定と注意点

このフラグで省略される確認は何ですか？

--dangerously-skip-permissionsと--permission-mode bypassPermissionsは、同じモードを選択します。Claudeは通常の承認待ちで停止することなく、ファイルの変更、シェルコマンドの実行、その他のツール呼び出しを進められます。保護対象のパスへの書き込みも許可されます。対話形式で初めて起動すると、利用者の責任について警告が表示されます。同意しなければClaude Codeは終了します。Anthropicのバイパスモードの説明

権限確認が作業場の「承認窓口」なら、環境の隔離は作業場を囲う「壁」です。窓口をなくしても、壁ができるわけではありません。途中で止まらずに作業できる一方、不適切な操作を実行前に見つける機会を失います。

つまり、操作を一つずつ承認する進め方から、先に実行環境を定め、最後に結果を確認する進め方へと変わります。コードの正しさが保証されるわけでも、悪意ある指示が無害になるわけでもありません。

バイパスしても残る制御は何ですか？

「スキップ」といっても、すべての制御がなくなるわけではありません。無人で動かしているはずの処理が停止したり、操作を拒否したりする場合は、次の違いを押さえておく必要があります。

最後の行に対応する読み取り設定は、正確にはpermissions.blockReadsOutsideWorkingDirectories: trueです。ファイルを読み取る操作として認識されるBashコマンドは、許可されたディレクトリの外では引き続き確認を求める場合があります。サンドボックスによるブロックは、これとは挙動が異なります。-pを使った非対話形式のバイパス実行では、なお確認が必要な呼び出しは承認を待たずに拒否されます。どのモードでも自動承認されない操作、ディレクトリ外の読み取り設定

操作をブロックするPreToolUseフックも、ツールの承認処理に引き続き関わります。ただし、EndConversationには特別な例外があり、ほかのツールが利用可能な間は、denyルールやaskルールによる制約を受けません。インストールされたmodは、管理ポリシーによらない権限判断の一部を上書きできます。そのため、チームで必須とする制御は管理ポリシーに置くべきです。管理者は"permissions": {"disableBypassPermissionsMode": "disable"}でバイパスを禁止できます。--restrictedで開始したセッションも、バイパスモードを拒否します。フックとルールの優先順位、バイパスを無効にする設定

バイパスモードでは保護対象のパスにも書き込めます

.gitや.claudeへの書き込みには、引き続き確認が入ると思わないでください。 バイパスモードでは、保護対象のパスへの書き込みが許可されます。これは、先ほどの重要ディレクトリの削除チェックとは別の仕組みです。

Anthropicが挙げている保護対象のパスには、次のものがあります。

.claude内には、Claude自身のworktree、現在の計画ファイル、バックグラウンドセッションの一時作業領域、一部のメモリー用Markdownファイルなど、限定的な例外があります。通常のManualモードとacceptEditsのセッションでは、保護対象への書き込みに確認が入ります。autoモードでは分類器が判断します。設定ファイルのallowルールで、これらの書き込みを事前承認することはできません。保護対象のパスと例外

Claude Code auto modeなど、確認を減らす四つの方法

何が作業を止めているのかに合わせて、制御方法を選びましょう。多くの開発者にとって、バイパスを導入する前に必要なのは、承認ポリシーをより細かく設定することです。

普段のコーディングにはautoモードを使います

claude --permission-mode autoでセッションを開始します。提案された操作を別のモデルが審査する「分類器」が、通常の承認判断を担当します。ターミナルでの既定値として継続的に使うには、~/.claude/settings.jsonに"permissions": {"defaultMode": "auto"}をマージします。

この値を.claude/settings.jsonや.claude/settings.local.jsonに書いても、autoモードは有効になりません。また、対応モデルや組織の設定によって利用できるかどうかが変わり、明示的なaskルールに一致する操作では引き続き確認が入ります。中断を減らす機能であり、安全を保証するものではありません。既定モードの設定、autoモードの利用条件

この審査モデルがどのようなワークフローに向いているかは、Claude Code autoモードのガイドで解説しています。

定型作業を許可し、特定の操作を拒否します

内容を確認したコマンドにはpermissions.allow、ブロックしたい操作にはpermissions.denyを使います。Claude Codeはdeny、ask、allowの順に評価します。広い範囲を許可するallowルールでも、一致するdenyルールを打ち消すことはできません。権限ルール

信頼できるリポジトリでは、次のように対象を絞った承認ルールと、操作をブロックするフックを組み合わせられます。既存のキーを残したまま、.claude/settings.jsonにマージしてください。この例では、記載した承認ルールを働かせるため、意図的にターミナルのセッションをManualモードで開始します。テストやlintのコマンドを承認する前に、プロジェクトの各スクリプトが実際に何を実行するかを確認してください。

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

プロジェクト内の個人用設定で上書きする場合は、.claude/settings.local.jsonを使います。自分で作成した場合は、.gitignoreにも追加してください。/permissionsを開くと、有効なルールとその設定元のファイルを確認できます。設定の適用範囲

これらのパターン指定は、ファイルシステムやネットワークを隔離する仕組みではありません。コマンドの書き方を変えるとBashのパターンに一致しなくなる場合があります。また、ファイル操作ツールにdenyルールがあっても、任意のスクリプトから間接的にファイルを読み取ることは可能です。機密情報は実行環境の外に置き、アクセスを確実に遮断する必要がある場合はサンドボックスで制限してください。Bashルールの限界、ファイル用ルールの限界

広範囲を変更する前にplanモードを使います

claude --permission-mode planで起動するか、プロジェクトの設定に"permissions": {"defaultMode": "plan"}を指定します。ソースの編集を承認する前に、Claudeが調査し、作業内容を提案します。最上位の設定"useAutoModeDuringPlan": falseを指定すると、計画中のコマンドに対する分類器の承認が無効になります。そのため、組み込みの読み取り専用コマンドの範囲を超える操作には、利用者の承認が必要です。planモードの設定

planモードを使うときは、バイパスを利用可能にするフラグを付けず、新しいセッションを開始してください。対話型ターミナルのセッションでバイパスが選択可能になっていると、planモードで通常適用される編集とコマンドのブロックが働きません。これは、バイパスを即座に有効化せず、後から選べるようにする--allow-dangerously-skip-permissionsを指定した場合も同じです。planモードとバイパスの選択可否

特定のコマンドはフックでブロックします

先ほどの例では、hooks.PreToolUseのハンドラーにmatcher: "Bash"、type: "command"、if: "Bash(rm *)"を指定しています。条件に一致すると、シェルコマンドが理由を表示し、終了ステータス2で終了してツール呼び出しをブロックします。別のスクリプトは不要です。このシェルコマンドは、Anthropicが公開しているフックのフィールドと、ブロックを指示する終了ステータスを使った、本記事の簡単な実装例です。フックの設定、ブロックを指示する終了コード

この例がブロックするのは、条件に一致するrmの呼び出しです。ファイルを削除するあらゆる手段を防ぐわけではありません。チーム独自のデプロイやクリーンアップ用コマンドに合わせて、レビュー済みの検証処理に置き換えることもできます。チェックの対象は、内容を理解し、テストできる範囲に絞ってください。設定方法とデバッグについては、Claude Codeフックの解説で取り上げています。

Anthropicはどの環境でバイパスの実行を認めていますか？

Anthropicが一般的な構成をまとめた表では、コンテナ、VM、サンドボックスランタイムのいずれかが必要とされ、LinuxとmacOSでは非rootユーザーでの実行が求められています。バイパスの説明では、ホストに損害を与えられない隔離環境を前提とし、インターネットに接続できない環境にも言及しています。一方、devcontainerのガイドでは、Claudeに必要なサービスへの外向き通信だけを許可する、ネットワーク接続のある構成を紹介しています。通信先を制限しないネットワーク接続は、別のリスクとして扱ってください。必要な隔離環境、devcontainerのネットワーク制限

LinuxとmacOSでは、rootユーザーやsudo経由でバイパスを起動すると、通常は拒否されます。ドキュメントには、認識されたサンドボックス内では自動的に例外が適用されるとの記載がありますが、紹介されているdevcontainerの構成は非rootアカウントを使います。rootに関するエラーを解消するために、この制限を緩めないでください。

参照用devcontainerで始める手順

信頼できるリポジトリを、破棄できる作業用コピーとしてチェックアウトします。Docker、VS Code、Dev Containers拡張機能をインストールしたうえで、Anthropicの参照用プロジェクトから始めます。

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. VS CodeでDev Containers: Reopen in Containerを実行します。この参照構成には、CLI、永続ボリューム、外向き通信を制限するファイアウォールが含まれています。remoteUserに非rootアカウントが指定されていることを確認してください。
2. コンテナ内のターミナルでid -uを実行し、結果が0でないことを確認します。claudeを実行してサインインしたら、そのセッションを終了します。
3. 同じコンテナ内のターミナルで、claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissionsを実行します。
4. 自分のプロジェクトに適用する場合は、参照構成の.devcontainer/ディレクトリを破棄可能な作業用コピーにコピーし、ツールチェーンに合わせてDockerfileを調整します。タスクが終わるたびに、ワークスペースの差分を確認してください。

この手順は、Anthropicの参照用コンテナのワークフローに沿ったものです。参照構成は動作するサンプルであり、継続的に保守されるベースイメージではありません。外向き通信の制限は維持するか、同等のネットワーク制御を用意してください。

マウントしたワークスペースにはコンテナ内からも書き込めるため、変更はホストにも反映されます。~/.ssh、クラウドの認証情報ファイル、無関係なディレクトリはマウントしないでください。悪意あるプロジェクトは、Claudeの認証情報を含め、コンテナ内でアクセスできる情報を外部に漏らす可能性があります。信頼できるリポジトリを使い、作業の様子を確認してください。devcontainerの限界

クラウドセッションではバイパスの既定値が無視されます

クラウドセッションは、設定ファイルのdefaultMode: "bypassPermissions"とdefaultMode: "dontAsk"を通知なく無視します。起動時には、クラウド側のモード選択ドロップダウンに表示されているモードが使われます。リポジトリにコミットしたJSON設定で、クラウドセッションを強制的にバイパスへ切り替えることはできません。クラウドでのモードの挙動

ローカルの~/.claude/settings.jsonは、Anthropicがホストするクラウドセッションには引き継がれません。リポジトリの設定にも制約があります。複数のリポジトリにまたがるセッションでは、各リポジトリの権限ルールとフックは読み込まれません。ターミナルの設定がそのまま適用されていると思い込まず、クラウド環境で実際に有効なポリシーを確認してください。クラウドセッションの設定

作業に合った権限モードを選びます

多くの場合、最も効果が大きいのは、既存のワークフローから繰り返し発生する承認を減らすことです。私なら、次の順番で導入を検討します。

CIの例でAnthropicが出発点として示しているのは、claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"です。通常なら確認が必要になる操作は拒否されます。一般的な構成例

どのモードを選ぶ場合も、Claude Codeのベストプラクティスを併せて活用してください。権限設定は実行を制御するためのものです。成果を採用できるかどうかは、検証によって判断します。

チームで開発する価値がある二つのツール

最も有望なのは、権限設定をチェックするツールです。 DataForSEOの推計では、「claude code permissions」の米国での月間検索数は720件です。これは必要な情報を見つけにくいという課題を示していますが、購入意向があると証明するものではありません。開発基盤を担当するチームなら、設定の適用範囲を説明し、無視されるdefaultModeの値を指摘し、広範囲に一致するコマンドルールの挙動を事前に確認できる小さなチェッカーを作れます。同僚への導入前に役立つでしょう。まず価値を出せる成果物は、修正案を含むレポートです。課題は、Claude Codeの設定の挙動が変わるたびに保守が必要になることです。

使い捨て環境での実行を立ち上げるランチャーは、無人タスクを繰り返すチームに役立つ可能性があります。 同じ需要調査では、「claude code docker」の米国での月間検索数は260件と推計されています。MVPでは、レビュー済みのコンテナテンプレート、許可されたマウント、非root実行、外向き通信のポリシーを検証し、実行後の差分とログを保守担当者向けに収集するとよいでしょう。価値は、毎回一貫した環境を用意できることにあります。ただし、ランチャーがあっても、信頼できないリポジトリのコードが安全になるわけではありません。Dockerがあるという理由だけで、隔離を保証することもできません。

どちらも、実際の利用者とともに有用性を確かめるべき社内ツールの案です。開発者の端末でバイパスを既定にする必要は、どちらにもありません。

週明けに取り組むなら、まずは繰り返し行う作業を一つ選び、実際に実行されるコマンドを確認しましょう。その作業を最後まで進められる、最小限の承認ポリシーを設定します。その範囲を超える無人実行が必要になってから、使い捨てのコンテナへ移行してください。

チームでこうしたワークフローの構築・保守が必要な場合は、本番運用向けAIシステムの構築支援をご覧ください。