Claude Code を毎日安全に回す：承認とsandboxの線引き運用術

「とりあえず承認ダイアログは出るから、まあ大丈夫だろう」

導入したての頃、僕はそう思っていました。Claude Code が何かするたびに確認が出る。読んでOKを押す。安全運転している気でいた。

ところが2週間後、自分の指がどう動いているかに気づいて青ざめました。確認文を読まずに、反射でEnterを押している。「いつもの流れ」になった操作は、もう確認していない。git push も、外部APIへの書き込みも、内容を見ずに通していました。事故が起きなかったのは、運がよかっただけです。

承認ダイアログは、増やせば安全になるものじゃありません。多すぎると人は読まなくなる。少なすぎると戻せない操作まで流れる。今日はこの「線引き」を、設定の細目ではなく毎日どう判断するかに絞って書きます。

この記事の要点

• 承認は「全部止める」でも「全部流す」でもなく、戻せる作業は速く、戻せない作業は遅くするのが軸。undo できるかどうかで線を引く。
• permission mode（default / acceptEdits / plan / auto / dontAsk / bypassPermissions）は作業フェーズで切り替える。探索は plan、レビューしながら直すなら acceptEdits。
• --dangerously-skip-permissions（= bypassPermissions）は日常で使わない。代わりに auto mode か sandbox を使う。
• sandbox は Bash が触れる「範囲」をOSレベルで狭める仕組み。macOS / Linux / WSL2 で動き、native Windows では動かない。
• チームでは「承認の置き場所」を人の気合いに頼らず、deny ルールとフックで物理的に固定する。

設定ファイルの書式そのものは姉妹記事の Claude Code 権限設定リファレンス に、CLAUDE.md と権限を組み合わせる具体レシピは CLAUDE.md × 権限レシピ にまとめてあります。この記事は「どこで止めるか」の運用判断に徹します。

承認は「戻せるか」で線を引く

線引きで迷ったら、技術的なリスクの大小より先に、ひとつだけ自問してください。

「これ、5分後に取り消せる？」

ファイルを読む、grep する、差分を見る、npm run build を回す。これは何回やってもやり直せます。最悪でも git checkout で戻る。だから速く回したい。逆に git push、本番 deploy、メール送信、外部DBへの書き込みは、押した瞬間に外の世界が変わります。取り消せない。だからわざと遅くする。

僕がよく使う3段の分け方はこうです。

操作	判断	理由
閲覧・grep・差分・build・test・lint	allow	戻せる。速度を落としたくない
ブランチ上のコード編集	ask か acceptEdits	リポジトリの成熟度しだい
push・deploy・publish・メール送信・外部API書き込み	ask	外の世界に影響する。取り消せない
.env 読み取り・rm -rf・git reset --hard・curl | sh	deny	事故ったときの被害が大きすぎる

ここで一番迷うのが「編集」です。編集は何でも危険、ではありません。テストが揃っている個人用リポジトリなら、編集を速く回しても怖くない。むしろ怖いのは、テストが弱い本番寄りのリポジトリで編集を野放しにすること。だから判断基準は「編集を許すか」ではなく、編集のあと何で検証するかです。検証コマンドが整っているなら編集は速くしていい。整っていないなら ask に残す。

deny は「念のため」で広めに置いて損はありません。.env 読み取りや破壊コマンドは、allow に上げる日が来ない前提で最初から塞いでおく。危険なプロンプト集 で挙げたような「permissions 飛ばして最速で」系の指示は、この境界をわざわざ壊す行為です。deny に入れておけば、プロンプト側で何を言われても本体が止めます。

permission mode はフェーズで切り替える

allow/ask/deny が「何を」止めるかの設定なら、permission mode は「いまどのくらい止めるか」のギア選択です。Shift+Tab で default → acceptEdits → plan を切り替えられます。公式の permission modes に全モードがまとまっていますが、運用で覚えるべきは次の対応です。

モード	確認なしで動く範囲	こういうとき
default	読み取りのみ	初めてのリポジトリ、慎重に進めたい作業
plan	読み取りのみ（編集せず計画だけ立てる）	コードベースを把握してから動きたい
acceptEdits	読み取り＋作業フォルダ内の編集	自分でレビューしながら直す
auto	ほぼ全部（裏で分類器が安全チェック）	長い作業、確認疲れを減らしたい
dontAsk	事前に allow したものだけ	CI やスクリプトの締め切った環境
bypassPermissions	全部（チェックなし）	隔離コンテナ・VM の中だけ

僕の使い分けはシンプルです。新しい仕事の入り口は plan。Claude にまず読ませて段取りを出させ、方向が合っていることを確認してから動かす。方向が固まったら acceptEdits に落として一気に編集させ、結果を git diff でまとめて見る。1行ずつ承認するより、あとでまとめて読むほうが集中して読めます。これは「最後に必ず見る」を仕組みにする話で、ハーネスエンジニアリング で書いた「門番を機械に置く」考え方と地続きです。

注意点をひとつ。bypassPermissions 以外のどのモードでも、protected paths への書き込みは自動承認されません。.git、.claude、.bashrc、.npmrc といった、壊れるとリポジトリや設定そのものが死ぬ場所です。acceptEdits で気持ちよく編集していても、ここだけは確認が入る。これは邪魔ではなく、最後の安全網だと思ってください。

--dangerously-skip-permissions を使わずに済ませる

「確認が多すぎてだるい」を解決しようとして、多くの人が --dangerously-skip-permissions（= bypassPermissions モード）に手を伸ばします。名前のとおり、全部のチェックを切るフラグです。

これを日常の対話で常用したら、もう「監督つきのエージェント」ではありません。たまたままだ事故っていないだけです。公式ドキュメントもこのモードを「隔離されたコンテナ・VM の中だけ」と明記していて、rm -rf / や rm -rf ~ のような最悪のケースを除いて、何のプロンプトも出ません。prompt injection への防御もゼロです。

でも「だるい」という気持ち自体は正しい。だから潰すべきは確認の数で、安全網ではありません。代替は2つあります。

ひとつは auto mode。これは確認を消すけれど、別の分類器モデルが裏で各操作を見ていて、curl | bash や本番 deploy、main への直 push、force push といった危ない操作はブロックします。会話の中で「push しないで」と言えば、それも一時的なブロック信号として効きます。確認は減るのに、危険操作は止まる。bypassPermissions とは別物です。ただし auto mode は research preview なので、機微な操作のレビューを丸ごと省く道具ではなく、「方向は信頼できる作業」で使うものです。

もうひとつが sandbox。次の章で説明します。

確認を減らしたいなら、まず acceptEdits か auto、それでも足りなければ sandbox。bypassPermissions はコンテナ専用と割り切る。この順番で考えると、わざわざ安全網を全部外す理由はほぼなくなります。

sandbox は「触れる範囲」をOSで縛る

承認が「その操作をしてよいか」を聞く仕組みなら、sandbox は Bash が触れるファイルとネットワークの範囲そのものを、OSレベルで狭める仕組みです。承認は「実行前のチェック」、sandbox は「実行中の壁」。レイヤーが違います。

ここが効くのは、承認の弱点を埋めてくれるからです。承認はコマンド文字列を見て判断するので、npm run build が裏で想定外のことをしても気づけない。でも sandbox なら、そのコマンドが書き込めるのはデフォルトで作業フォルダの中だけ。名前のとおりに振る舞わなくても、OSが物理的に止めます。

/sandbox を実行すると設定パネルが開いて、2つのモードを選べます。

• auto-allow: sandbox 内なら確認なしで Bash を実行する（範囲がコンテナしているから安全）。範囲外に出る操作だけ通常の承認に戻る。
• regular permissions: sandbox の中でも、いつもどおり承認を出す。制御は強いが確認は多い。

つまり「確認は減らしたいけど、何でも実行されるのは怖い」という人にちょうどいい。範囲で守るから、いちいち聞かなくていいわけです。

ただし重要な制約があります。sandbox が動くのは macOS / Linux / WSL2 だけで、native Windows では動きません。Windows ユーザーは WSL2 の中で Claude Code を動かす必要があります。WSL を使えない、あるいは素の Windows で使うなら、sandbox に期待せず、allow/ask/deny の分け方を厳しめにしてください。deploy・publish・secret 周りは特に ask に寄せる。これが Windows での現実的な落としどころです。

sandbox の設定はこんな形です。作業フォルダの外に書き込みが必要なツール（例: kubectl が ~/.kube を触る）だけ、明示的に穴を開けます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.aws", "~/.ssh"]
    }
  }
}

failIfUnavailable: false は「sandbox が使えない環境なら警告だけ出して通常実行に落ちる」設定です。逆に組織で sandbox を必須にするなら true にして、起動そのものを止めます。あと地味に大事なのが denyRead。sandbox のデフォルトはほぼ全ファイルを読めてしまうので、~/.aws や ~/.ssh のような秘密は明示的に塞いでおくと安心です。

「毎日の運用」に落とす設定の出発点

ここまでの判断を1ファイルにすると、日常運用の出発点はこのくらいで十分です。書式の細かい意味（Bash(npm run build) と Bash(npm*) の違いなど）は 権限設定リファレンス に譲ります。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

やっていることは3つだけです。読み取りと検証は速く回す。外に影響する操作は必ず止める。明らかに危険なものは最初から禁止する。defaultMode: "plan" を入れているのは、新しいセッションを「まず読んで計画」から始めたいからです。あとは作業しながら Shift+Tab で acceptEdits に上げていけばいい。

編集（Edit / Write）を allow にも ask にも書いていないのは意図的です。mode 側（acceptEdits）で制御したいから。ルールとモードの両方で編集を縛ると、どっちが効いているか分からなくなります。編集はモードで、外部副作用はルールで、と役割を分けると頭が整理されます。

チームでは「承認の置き場所」を物理で固定する

ここまでは個人の話でした。チームになると、もうひとつ問題が増えます。人によって線引きがバラバラになること。慎重な人もいれば、bypassPermissions で回したがる人もいる。気合いと良識に頼ると、いちばん緩い人の運用がチームの実効ラインになります。

だから、止めたい場所は人の判断に任せず、物理で固定します。具体例を3つ。

1. コミット前に secret 混入を止める。 PreToolUse フックで git add の前に .env がステージされていないか機械チェックする。人が「あ、これ入れちゃダメだった」と気づく前に、コミットが止まる。

2. deploy 前に build を強制する。 「ローカルで build 通したつもり」を信じない。deploy コマンドの前にフックで npm run build を必ず走らせる。

3. 編集後に検証を自動で回す。 Edit / Write のあとに npm run test を流す。薄い修正でも検証が走るので、壊れたまま進めない。

最小構成はこのくらいです。フックは多いほど良いわけではなく、止めるフック1つ・検証フック1つくらいが運用が壊れにくい。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

Windows なら grep の部分は findstr か小さな Node スクリプトに差し替えれば動きます。大事なのはコマンドそのものより、「commit 前に止める / deploy 前に build / 編集後に検証」という3つの形です。組織レベルで縛るなら、managed settings で bypassPermissions を disable にし、sandbox を必須にする手もあります。チーム規模になったら 導入相談ページ で運用ルールごと設計するのが結局いちばん早いです。

よくある失敗例

3つとも、僕か僕の周りが実際にやらかしたやつです。

全部 ask にして満足する

最初の1日は安全に見えます。でも1週間後には確認文を読まずにOKを押し始める。これは deny が弱い状態より危ない。「確認したつもり」という錯覚が残るからです。ask を並べる前に、まず deny を固める。

--dangerously-skip-permissions が口癖になる

「これ早いな」と一度味をしめると戻れなくなります。でもそれは監督を外しただけ。確認がだるいなら auto mode か sandbox の auto-allow を使う。安全網ごと外す必要はどこにもありません。

build 成功を release 成功と勘違いする

これはコンテンツ運用でも開発でも頻出です。ローカル build は通ったのに、公開URLが古い、1言語だけ未反映、CTA がスマホで崩れている。承認や sandbox ではこの失敗は防げません。必要なのは公開後の確認です。僕はこれで何度も「出したつもり」をやりました。

よくある質問

Q. auto mode と sandbox の auto-allow、何が違うんですか？ A. 守り方が違います。auto mode は分類器モデルが「この操作は危ないか」を判断してブロックします。sandbox の auto-allow は、操作の中身ではなく「触れる範囲」をOSで縛って安全を確保します。判断で守るのが前者、範囲で守るのが後者。両方を組み合わせることもできます。

Q. Windows で sandbox は使えますか？ A. native Windows では使えません。WSL2 の中で Claude Code を動かせば使えます。素の Windows で使う場合は sandbox に頼らず、deploy・publish・secret 周りを ask に寄せて、deny を厳しめにしてください。

Q. plan mode と acceptEdits mode、どう使い分けますか？ A. plan は「読むだけ・編集しない」で、コードベースを把握して段取りを立てるフェーズ用。acceptEdits は「作業フォルダ内の編集を確認なしで通す」で、方向が固まって一気に直すフェーズ用。僕は plan で始めて、合意できたら acceptEdits に落とします。

Q. deny に入れた操作を、どうしても1回だけ実行したいときは？ A. deny は Claude Code 本体が強制するので、プロンプトでは緩められません（それが deny の価値です）。本当に必要なら、その場で settings から外して実行し、終わったら戻す。「一時的に外した」という手間自体が、危険操作のブレーキになります。

Q. フックと permission、役割が被りませんか？ A. 被りません。permission は「その操作を実行してよいか」を制御し、フックは「実行の前後に何を必ず走らせるか」を制御します。secret 混入を止める・deploy 前に build する、のような決定論的なチェックはフックの担当です。

実際に試した結果

この考え方を、このサイトの daily automation にそのまま入れ直しました。いちばん変わったのは、AIの出力品質そのものより「どの時点で人間が止まるか」がはっきりしたことです。

以前は「何か1つ進める」だけの曖昧な運用で、既存記事をちょっと直して run が終わることもありました。いまは plan で段取り → acceptEdits で編集 → deploy 前にフックで build → 公開後に全言語をスマホ確認 という流れが固定されています。bypassPermissions を使うのをやめて acceptEdits + sandbox に切り替えてから、「気づいたら外部に何かしていた」というヒヤッとが消えました。

賢いAIに全部任せるより、戻せない操作の手前に一呼吸を置く。遠回りに見えて、毎日安心して回せるのはこっちでした。まずは 無料チートシート を横に置いて、自分の deny リストを1行ずつ埋めるところから始めてみてください。