Claude Code の Approval / Sandbox 設定ガイド | 安全に毎日使うための実践ルール

Claude Code を安全に使ううえで、いちばん危ないのは「一応 approval は出るから大丈夫だろう」と思い込むことです。実際には、確認ダイアログが多すぎると人は読まなくなります。逆に allow を広げすぎると、今度は戻せない操作まで AI に流してしまいます。

この問題は、Claude Code 入門ガイド を読んで便利さを理解したあとに、ほぼ確実にぶつかります。日常の開発で本当に必要なのは「毎回ビビりながら全部 ask にする」ことでも、「面倒だから全部 allow にする」ことでもありません。必要なのは、元に戻せる作業は速く、元に戻せない作業は遅くする設計です。

概念から整理したいなら ハーネスエンジニアリング完全ガイド を、設定項目を網羅的に見たいなら Claude Code 権限設定完全ガイド を、事故パターンから入りたいなら セキュリティ失敗事例 を先に読むと理解しやすいです。この記事ではそこから一歩進めて、次の問いに絞って説明します。

どの操作を自動にして、どの操作を承認にして、どの操作を最初から禁止にするべきか。

approval があるだけでは安全にならない

安全な Claude Code 運用は、approval ダイアログだけでは成立しません。最低でも次の 3 層が必要です。

制御	何を守るか	代表例
permission ルール	そもそも何を allow / ask / deny するか	.env、破壊コマンド、deploy
approval フロー	人間をどこで止めるか	git push、本番反映、メール送信
sandbox	Bash が触れる範囲そのものを狭める	build、検証、探索的なスクリプト実行

公式情報は必ず一次ソースで確認してください。Anthropic の公式ドキュメントでは Claude Code permissions、settings、hooks が基本です。permissions の説明では、読み取り系ツールは approval なしで動かせる一方、シェルコマンドやファイル編集は review を挟めることが整理されています。settings ではスコープ別設定や permission の優先順位、hooks ではツール実行の前後で決定論的なチェックを差し込む方法が説明されています。

ここで重要なのは、approval を増やせば安全になるわけではないことです。全部 ask にすると最初は慎重になりますが、1 週間後には反射で OK を押し始めます。逆に allow を広げすぎると、本番 deploy や秘密情報の読み取りまで「いつもの流れ」で通してしまいます。安全設計は「全部止める」でも「全部流す」でもなく、戻せる作業は速く、戻せない作業は遅くすることです。

毎日使うなら、この分け方から始めれば十分

個人開発でも小さなチームでも、最初は次の分け方でほぼ足ります。

操作	推奨	理由
ファイル閲覧、grep、差分確認	allow	低リスクで価値が高い
build、test、lint、analytics 実行	allow	反復速度を落としたくない
ブランチ上でのコード編集	ask かセッション単位 allow	リポジトリの成熟度次第
git push、deploy、publish、メール送信	ask	外部副作用がある
.env 読み取り、rm -rf、git reset --hard	deny	事故の被害が大きすぎる
外部 API への書き込み	ask	現実世界に影響する

ここで迷いやすいのが「編集」です。編集は何でも危険というわけではありません。テストが整っている個人用 sandbox リポジトリなら、セッション限定で allow に寄せても回ります。逆に、本番に近いリポジトリでテストが弱いなら、編集も ask に残しておくべきです。大事なのは「編集を許すかどうか」ではなく、編集のあとに何で検証するかです。

危険なプロンプト集 にあるように、「とにかく最速でやって」「permissions を飛ばして」系の指示は、この境界線をわざわざ壊す行為です。approval や sandbox があっても、プロンプト側でガードレールを外せば意味がありません。

まずは .claude/settings.json をこう置く

日常運用の出発点としては、次のようなプロジェクト設定が実用的です。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "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
  }
}

この設定でやっていることはシンプルです。

1. 読み取りや検証は速く回す。
2. 外に影響する操作は必ず止める。
3. 明らかに危険なものは最初から禁止する。

sandbox については環境差があります。現時点の公式 sandbox 設定ページでは、Bash sandboxing は macOS、Linux、WSL2 を前提に説明されています。つまり Windows で同等の境界がないなら、sandbox に期待しすぎず、allow / ask / deny の分け方を厳しめにするべきです。Windows では特に deploy、publish、secret 周辺の操作を ask に寄せたほうが安全です。

Hooks を入れると「悪い癖」が減る

permissions は「その操作を実行してよいか」を制御します。hooks は「実行前後に何を必ず走らせるか」を制御します。この 2 つを組み合わせると、チームの悪い癖をかなり減らせます。

たとえば、コンテンツサイトやアプリのリポジトリなら次のような hooks が実用的です。

{
  "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.js スクリプトに置き換えれば大丈夫です。重要なのはコマンドそのものではなく、次の構造です。

• commit 前に secret 混入を止める
• deploy 前に build を強制する
• 編集後に決定論的な検証を自動で走らせる

Hooks ガイド をすでに読んでいる人ほど、ここでやりがちなのが「なんでも hook で自動化する」ことです。でも実務では、hook は多いほど良いわけではありません。止める hook を 1 つ、検証する hook を 1 つのほうが、運用が壊れにくいです。

実例1: 記事運用では「書く」より「公開確認」が重要

コンテンツ運用でありがちなのは、「記事を書いたから終わり」と思ってしまうことです。でも実際の運用はもっと長いです。

1. 直近 7 日の analytics を見る
2. 伸びているクラスタの隣にある検索意図を選ぶ
3. 新規記事を書く
4. 多言語版を揃える
5. build する
6. deploy する
7. 公開 URL を開く
8. Playwright でスマホ表示を確認する

このサイトでも、今日ここを実際に見直しました。以前は「何か 1 つ進める」運用だったので、既存記事の更新だけで run が終わりえました。いまはルールを変えて、毎回 1 本の新規記事を公開し、さらに既存タスクも 1 つ進め、最後に全言語 URL を mobile で確認する形にしています。これくらい具体的にしないと、approval や hooks があっても「なんとなく終わった運用」になりやすいからです。

実例2: アプリ開発では branch 内作業と本番副作用を分ける

アプリのリポジトリで Claude Code が得意なのは、次のような作業です。

• 関連ファイルを探す
• 差分を読む
• ブランチ内でリファクタリングする
• build や test を回す

逆に、次の操作は ask に残すべきです。

• shared branch への push
• DB migration の適用
• 本番 admin API の実行
• infra 設定の変更

この切り分けが曖昧だと、「テストを直したかっただけなのに本番 deploy まで流れた」という事故が起きます。セキュリティベストプラクティス や 本番インシデント集 は、そういう事故を防ぐ前提知識としてかなり役に立ちます。

実例3: 営業やバックオフィス自動化は「送る瞬間」を必ず止める

AI エージェントは調査や下書きには強いですが、送信や公開には強すぎます。

たとえば営業やバックオフィス自動化なら、次は自動でもよいことが多いです。

• 公開サイトを読む
• リードを分類する
• サンプル LP を下書きする
• 提案メールを作る

でも、次は必ず ask にしてください。

• メールを送る
• スプレッドシートの本番行を書き換える
• 公開ページを publish する

ここを allow にしてしまうと、「下書きを作ってほしかった」だけなのに「もう送信済み」まで起きます。外部副作用をともなう瞬間だけ friction を入れる、というのが approval 設計の核心です。

よくある失敗例

失敗1: 全部 ask にして満足する

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

失敗2: --dangerously-skip-permissions が日常になる

公式ドキュメントでも、こうしたスキップは CI/CD や完全に把握した自動化に限定すべきという立て付けです。日常の対話でこれを常用すると、もう supervised agent ではありません。たまたままだ事故っていないだけです。

失敗3: build 成功を release 成功と勘違いする

これはコンテンツ運用でも開発でも頻出です。ローカル build は通ったのに、公開 URL が古い、1 言語だけ未反映、CTA が mobile で崩れている。approval や sandbox だけではこの失敗は防げません。公開確認と Playwright 検証が必要です。

導入チェックリスト

次の順番で入れると失敗しにくいです。

1. secrets と破壊コマンドを deny に入れる
2. push・deploy・publish・send を ask に入れる
3. 読み取りと検証系コマンドは allow に寄せる
4. 止める hook を 1 つ、検証 hook を 1 つ入れる
5. deploy 後は公開 URL の確認を必須にする
6. 毎週 1 回 approval を見直し、本当に安全だと分かった作業だけ allow に昇格させる

最後の見直しが重要です。ずっと怖がるために permissions を作るのではありません。安全を積み上げながら、自動化を少しずつ増やすために作ります。

実際に試した結果

この記事で紹介した考え方を、このサイトの daily automation にそのまま入れ直しました。すると「既存記事の更新だけで終わる run」が消え、新規記事公開 -> 既存タスク改善 -> Playwright で mobile / 全言語確認 という流れが固定されました。体感としていちばん大きかったのは、AI の出力品質そのものよりも、「どの時点で人間が止めるか」が明確になったことです。

次にやること

まずは 無料チートシート で daily work の基本を横に置いてください。設定や hooks、CLAUDE.md、CI/CD までコピペできる形で固めたいなら The Complete Claude Code Setup & Configuration Guide が最短です。チーム導入や安全運用ルールの設計まで一緒に詰めたいなら 導入相談ページ からどうぞ。