ClaudeのBypass permissions（権限をバイパス）って実際危ない？──Auto modeとの違いとEnterprise導入の判断基準【Claude Code】

1. 結論：Bypassは「危険な機能」ではなく、隔離を前提にした危険な権限設定

Claude Codeの Bypass permissions は、名前どおり通常の許可プロンプトとAuto modeの安全分類を飛ばし、ツール呼び出しを即時実行させるモードだ。Anthropic自身も、インターネットへ接続していないコンテナ、VM、dev containerのような隔離環境だけで使うよう明記している。^[1]

したがって「実際危ないのか」への短い答えは、開発者の普段使いのPCで広く解放するなら、かなり危ない。使い捨ての隔離環境で、秘密情報も本番権限も持たせないなら、危険範囲を現実的に小さくできる、となる。

ここで大事なのは、BypassがClaudeをrootへ昇格させる機能ではないことだ。Claude Codeはローカル実行時、「その利用者がターミナルから実行できるコマンド」を扱える。つまり被害上限を決めるのはモード名ではなく、そのOSユーザー、読み取れるファイル、環境変数、SSH鍵、クラウド認証情報、接続先ネットワーク、Gitの権限である。^[2] 開発者のPCは、しばしば本番へ届く鍵束そのものだ。だから「rootではない」は安心材料にならない。

Enterpriseの既定方針としては、Bypassを無効化し、Auto＋OSレベルのsandbox＋明示的なask/denyルールを標準にするのが妥当だ。Bypassが必要な自動処理だけ、資格情報を絞った専用runnerや使い捨てdev containerへ分離する。全社スイッチをオンにして各人の注意力へ委ねる設計は避けたい。

AutoとBypassは、どちらも止まりにくい。しかしAutoは判断ゲートを残し、Bypassは外側の隔離だけを頼りにする。見た目の速さが似ていても、事故時の構造は違う。

2. まず名前を揃える：Claude Codeには6つのpermission modeがある

2026年9月2日に公式ドキュメントとローカルのClaude Code 2.1.258を照合すると、CLIの--permission-modeは manual、acceptEdits、plan、auto、dontAsk、bypassPermissions を受け付ける。設定ファイルやSDKではManualをdefaultと書く点が少し紛らわしい。^[1]

Accept Editsは「文章だけを編集する安全モード」ではない。現行ドキュメントでは、作業ディレクトリ内のmkdir、touch、rm、rmdir、mv、cp、sedなども自動承認の対象に含まれる。Git差分やClaude Codeのcheckpointで戻せる編集には便利だが、remote API、DB、deployの副作用はcheckpointで戻らない。^[1][2]

Planも絶対的なread-only sandboxではない。通常は編集を止めるが、Bypassを利用可能にして開始したセッションでは、Plan中の編集やshell実行にも通常のブロックが掛からない場合がある。計画と実行を技術的に分離したい組織が、Bypassを同じセッションで利用可能にするのは設計矛盾になりうる。^[1]

3. AutoとBypassの決定的な差：Autoは「無確認」ではなく「確認者を別モデルに替える」

Auto modeでは、読み取りと作業ディレクトリ内の通常編集などが先に許可され、それ以外のshell、外部サービス、作業範囲外の操作などが分類器へ送られる。入力側では、ファイル、Web、shell出力などに含まれるprompt injectionらしき内容を別のprobeが検出する。出力側では、ユーザーの依頼と実行予定のtool callを分類器が比較する。^[3]

つまり「Autoでは全操作をAIが二重チェックする」という説明も厳密には違う。リポジトリ内の通常編集は、Gitでレビュー可能という前提から分類器を通らない。明示的なaskとdenyルールは分類器より先に評価されるため、Autoのままでもgit push前だけ人を戻す、といった設計は可能だ。^[4]

Anthropicが2026年3月に公開した内部評価は、Autoの価値と限界を同時に示す。実トラフィック1万件で、正常操作を誤って止める率は最終パイプラインで0.4%。一方、実際の「先回りしすぎた危険操作」52件では17%を見逃し、合成した情報持ち出し1,000件では5.7%を見逃した。サンプルの小さい社内評価であり、これを事故確率へ直接変換してはいけない。それでも、Autoは安全保証ではなく、Bypassより安全側へ寄せる確率的な中間層だと分かる。^[3]

同社のデータでは、利用者は許可プロンプトの約93%を承認していた。人間を毎回挟めば常に安全、という前提も現実には弱い。大量のダイアログは「確認」から「反射クリック」へ変わる。Autoの狙いは、人間を消すことではなく、注意力を本当に重要な境界へ戻すことにある。^[3][5]

Autoの二層構造。外から入る情報に注入の兆候がないかを見て、外へ出る高リスク操作はユーザー意図と照合する。ただし、どちらも確率的な防御である。

4. Bypassは何を外し、何を外さないのか

Bypassを有効にすると、通常のpermission promptとAutoのclassifierを待たずにtool callが進み、.git、.claude、.vscode、shell profileなど「protected path」への書き込みも可能になる。--dangerously-skip-permissionsは同等の起動フラグで、Linux/macOSではrootやsudo配下での起動を拒否する。^[1]

ただし「全ての安全策が消える」と断言するのも正確ではない。現行仕様では、明示的なpermissions.denyはBypassでも優先される。内容指定のaskルール、ユーザー操作を必須とするtool、組織が毎回承認にしたconnector、filesystem rootやhome directoryを狙う一部削除なども、なお停止または確認の対象になる。OSのユーザー権限、container、VM、ネットワーク制御、下流サービスのIAMも別レイヤーとして残る。^[1][6]

それでも危険度が高い理由は、日常の事故がrm -rf /ほど派手ではないからだ。

• 誤解した「整理」でremote branchやcloud objectを消す
• 失敗した認証を直そうとして、別用途のtokenを探索・利用する
• issue、README、Webページに仕込まれた間接prompt injectionへ従う
• git push、migration、IaC apply、メール送信の対象を取り違える
• .git、hook、package script、Claude自身の設定を書き換え、後続処理へ持続的な影響を残す

AnthropicはAutoの設計記事で、remote branch削除、GitHub tokenの内部clusterへのupload、本番DBへのmigration試行を、実際の内部incident logに基づく例として挙げている。悪意のあるAIだけが問題なのではない。親切すぎる先回り、対象の取り違え、外部コンテンツによる誘導が、十分な原因になる。^[3]

5. Enterpriseで「Bypassを解放」のリスクは、端末ではなくblast radiusで測る

万能な事故確率は公表されておらず、企業ごとの権限構成も違うため「危険度37%」のような数字は出せない。実務では、起きやすさ × 到達可能な被害で評価する。NISTも生成AIについて、用途に応じたrisk tier、追加のhuman review、追跡、文書化、管理監督を求めている。OWASPは、過剰な機能・権限・自律性の組み合わせを「Excessive Agency」と整理し、最小権限と高影響操作の人間承認を推奨する。^[7][8]

ここで「Bypassを選べるようにする」と「Bypassを既定で実行する」は別だ。だがEnterprise全体で選択肢を解放すれば、誤操作、個人スクリプト、古い手順書、第三者pluginがその経路を利用できるため、latent riskは増える。さらにserver-managed settingsは現時点で組織全員へ一様に適用され、group別設定をサポートしない。例外を作るなら、対象端末へ配るMDM設定や専用runnerなど、環境そのものを分ける方が境界を説明しやすい。^[9]

Bypassの危険度は、ボタンそのものではなく、その端末から何へ届くかで決まる。資格情報と接続先が多いほど、一つの誤判断が複数システムへ伝播する。

6. 推奨構成：Autoを便利にしつつ、越えてはいけない線を決定論的に置く

Enterprise導入では、最初から細かなallowlistを完璧に作るより、まずBypassをmanaged settingsで無効にし、sandboxをfail-closedで強制し、重要操作だけをaskまたはdenyへ置くとよい。managed settingsはユーザー、project、command lineより優先され、ローカルから上書きできない。^[10][6]

次は概念例であり、実際のdomain、path、commandは自社環境で検証する必要がある。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.example.com", "registry.example.com"]
    }
  }
}

特にgit pushを明示的なaskへ戻す意味は大きい。現行のAuto modeは、作業中repositoryの設定済みremoteに対する通常pushを、default branchを含めて許可しうる。古い解説にある「Autoならmainへのpushは必ず止まる」を運用前提にしてはいけない。force push、秘密を外へ出す変更、deploy targetへのpushなどは別途分類されるが、組織が求める人間のcheckpointは明示ルールで固定すべきだ。^[1][4]

Sandboxはpermission modeの代用品ではなく、別の層である。macOSではSeatbelt、Linux/WSL2ではbubblewrapを使い、Bashとその子processのfilesystem・network到達範囲をOSレベルで制約する。一方、組み込みのRead/Editやcomputer useは別境界で動く。TLSを通常は終端検査しないなどの限界もあるため、「sandbox on」の一行だけで審査を終えない。^[11]

例外的にBypassを使うrunnerでは、少なくとも次を満たしたい。

1. 毎回破棄されるVM/containerで、hostのhomeをmountしない。
2. egressは原則拒否し、必要domainだけをproxyで許可する。
3. tokenはjobごとの短命・最小scopeにし、本番用credentialを置かない。
4. default branchへ直接書けず、成果はPRまたはartifactとして人がreviewする。
5. 監査logだけを予防策と呼ばず、下流IAM、branch protection、DB承認で強制する。

Bypassを安全側へ寄せるのは、警告文ではなく物理的な境界だ。破棄可能、秘密なし、外へ出られない、成果はreview経由。この四条件が直通運転のblast radiusを小さくする。

7. Claude Desktop、CLI、Cowork、Chatは同じ「Auto」でも同じものではない

Claude DesktopのCodeタブでLocal sessionを選ぶ場合、実行場所は利用者のPCで、CLIと同じsettingsを読み、folderごとにmode選択を記憶する。DesktopはUIであって、安全なcloud sandboxへ自動的に変換するわけではない。Remote sessionならAnthropic管理のVM、SSHなら接続先hostが実行境界になる。^[12][13]

またWeb版Claude Codeのcloud sessionではBypassは提供されない。Remote Controlもコードは手元PCで動くが、app側から選べるmodeはManual、Accept Edits、Planに限られ、AutoとBypassは選べない。どの画面から話しかけるかより、どこでprocessが動き、どのmodeが実際に有効かを見る必要がある。^[1]

CoworkはClaude Codeのpermission modeを流用していない。CoworkにはManual、Automatically approve、Skip all approvalsという独自の3段階がある。Autoではconnectorやbrowserなどのactionを安全確認し、Skipでは自動確認をしない。ただし永久的なfile削除など、modeにかかわらず明示許可を求める操作もある。Coworkのcode executionは隔離環境で動くが、許可したlocal folder、connector、browser、computer useを通じた現実世界のactionまで無害になるわけではない。^[14][15]

Team/EnterpriseではCoworkのAuto可否、write可能connectorの毎task承認、network egress、pluginなどを別々に管理する。Compliance APIやOpenTelemetryはClaude Code/Coworkの可視化に役立つが、logは実行後の検知であり、最小権限や強制approvalの代わりではない。^[16][17]

8. 導入判断：全社で解放するかではなく、どの環境へ閉じ込めるか

最終判断はシンプルにできる。

• 普段の開発：Auto＋sandbox。push、deploy、migration、IAM変更はaskまたはdeny。
• 機密・本番・規制業務：ManualまたはPlanを基本にし、下流システム側でも承認を要求。
• 非対話CI：dontAsk＋狭いallowlistを第一候補にする。
• Bypass：ネットワークとcredentialを絞った使い捨て環境に限定し、一般端末ではmanaged settingsで無効化。

Bypass permissionsは「押した瞬間に必ず事故が起きるボタン」ではない。権限のないcontainer内なら、壊せるのはそのcontainerに限られる。反対に、cloud admin権限、顧客DB、署名鍵、GitHubの強いtokenを持つPCでは、rootでなくても事業上の重大事故へ届く。

だからEnterpriseで問うべきは「Claudeを信頼できるか」ではない。Claudeが間違えたり、外部文書に誘導されたりしても、どこまでしか壊せないかである。Autoはその途中に確率的な警備員を置く。Bypassを使うなら、警備員を外しても成立する壁、鍵、短命な身分証、出口制限を先に用意する。それがない状態での全社解放は、便利さに対してリスクが大きすぎる。

検証時点と免責：本記事は2026年9月2日時点のAnthropic公式資料とClaude Code 2.1.258の--helpを照合して作成した一般的な技術・リスク解説です。Claude Code、Claude Desktop、Coworkの既定値・対象plan・provider・管理機能は更新が速いため、導入時は必ず最新の公式資料と自組織の実効設定を確認してください。本記事は個別の法務、監査、セキュリティ認証判断を代替しません。