Claude Codeの権限設定｜安全と手数の折衷ライン

「Claude Codeの権限設定って、安全にするにはどこをいじればいいの？」
「毎回の確認が多すぎるから全部許可にしてしまいたい！」

Claude Codeを使い始めて最初に面倒になるのが、コマンドのたびに出る確認です。
だからといって全部許可にすると、今度は取り返しのつかない事故のほうが近づいてきます。

結論から言うと、安全と手数のバランスは「絶対に触らせない場所をdenyで固め、日常の作業だけallowで通す」形が現実解でした。
この記事では権限モードの選び方から、サンドボックスでの資格情報の守り方までをまとめています。

Claude Codeの権限設定を省いたときに起きること

Claude Codeの権限設定を考える前に、確認を素通りさせると何が起きるのかを押さえておきます。

ここでは、危険の中身を3つに分けて見ていきますね。

確認を素通りさせたときに起きること

Claude Codeは、ツールの種類ごとに承認の必要性を変えています。

ファイルの読み取りやGrepは作業ディレクトリの中なら確認なしで通り、シェルの実行とファイルの書き換えは確認が入る形です。この確認が、実質的にいちばん最後の砦になっています。

ここを外すとどうなるか。判断する主体が、自分からモデルへ丸ごと移るということですね。

とくに厄介なのが、悪意のあるコードを書かせるまでもなく起きるという点です。

Webページやリポジトリの中に「この手順を実行して」と書いてあれば、それを指示だと受け取って動いてしまう可能性があります。

いわゆるプロンプトインジェクションですね。自分は普通に開発しているだけなのに、読ませた資料の側から操作されるという構図です。
この種のリスク全般はAIエージェントのセキュリティリスクの記事で整理しました。

全許可運用がとくに危ないところ

--dangerously-skip-permissions は、名前のとおり確認をまるごと飛ばすオプションです。

楽なのは間違いないのですが、公式ドキュメントでも隔離された環境でのみ使うよう明記されています。

危ないのは削除だけではありません。

設定ファイルを書き換えられるというのが、いちばん怖いところでした。一度そこを許すと、あとから締め直しても意味がなくなります。

実際にやってしまいがちなのが、「今日だけ急ぐから」と一時的に外して、そのまま常用に変わっていく流れです。私も締め切り前に一度やって、翌週には何も考えず付けるようになっていました。

なお、このモードでも rm -rf / のようなルート削除には確認が残ります。
ただしそれは最後の回路遮断器であって、安全に使えるという意味ではありません。

ルールを守らせているのはAIではないという前提

ここが誤解されやすいところです。

CLAUDE.mdに「本番環境には触らないでください」と書いておけば安全になる、と思ってしまいますよね。

実際には、権限ルールを実装しているのはClaude Code本体であって、モデルではありません。

前者はお願いで、後者は関門です。お願いは、文脈が長くなったり、外から別の指示が紛れ込んだりすると効かなくなります。

この違いは、確認ダイアログでどこまで見えるかにも表れます。ダイアログで Ctrl+E を押すとコマンドの説明とリスク評価が出てきますが、これはClaude Code側が用意している情報です。

だから本当に守りたい線は、必ず権限ルール側に書いてください。
CLAUDE.mdの書き方そのものはClaude Code CLAUDE.mdの書き方にまとめています。

Claude Codeの権限モードを場面で使い分ける

権限設定の入口は、ルールを書くことではなくモードを選ぶことです。

ここでは用意されているモードと、ふだん使うべき組み合わせを見ていきます。

用意されているモードの違い

モードは Shift+Tab で切り替えられます。

公式ドキュメントに載っている一覧を、実務で使う順に並べ替えてみました。

おもしろいのが dontAsk です。これは「許可したもの以外は聞かずに落とす」という、いちばん厳しい方向の自動化でした。

確認が煩わしいという不満に対して、緩める方向と締める方向の両方が用意されているわけですね。自動化されたバッチ処理に向いていて、想定外のことを始めたらその場で止まってくれます。

また auto モードは、単なる全許可ではありません。実行しようとしている内容がリクエストと合っているかを別の仕組みが見たうえで通す形なので、確認を減らしつつ判断は残せます。

ふだん使いで足りる組み合わせ

私が日常的に使っているのは、planとacceptEditsの2つだけです。

調査と方針決めはplanモードで進めて、方針が固まったらacceptEditsに切り替えて実装させる。

この2段構えにすると、確認の回数がかなり減ります。

ポイントは最後の行です。planモードは調査に集中させたいときにも効くので、コードベースを把握させる場面では最初からここに入れています。

acceptEditsが自動で通すのは、あくまで作業ディレクトリ内のファイル操作だけで、外部に影響するコマンドは別途確認されます。

それでも、pushやデプロイの手前で一度defaultに戻すと気持ちが引き締まりますよ。
既定のモードを固定したいときは、設定ファイルの defaultMode に書いておけます。

bypassPermissionsを選んでよい場面

では、確認を飛ばすモードは絶対に使ってはいけないのか。

そんなことはなくて、使ってよい条件のほうがはっきりしています。むしろ条件を満たす環境なら、確認を挟むほうが時間の無駄になる場面もありました。

Claude Codeが壊しても困らない場所であること、これに尽きました。

逆に言えば、ふだんの開発マシンでこれを常用するのは無理があります。ホームディレクトリに鍵もトークンも入っているからです。

ちなみにこのモードは、LinuxとmacOSでroot権限やsudo経由の実行だとブロックされます。root権限と確認なしが揃うと、システム上のどのファイルにも手が届いてしまうからですね。

組織で配る場合は、permissions.disableBypassPermissionsMode を "disable" にして使えなくする手もあります。
自分の設定に書いて、自分自身をロックアウトしておくのも有効でした。

Claude Codeの権限ルールを書く手順

ここからは settings.json に権限ルールを書いていきます。

順番を守ると、あとで迷わない設定になりますよ。

【ステップ1】permissionsコマンドで現状を確かめる

まずは、いま何が許可されているのかを見ます。

/permissions

このコマンドで、すべての権限ルールと、それがどの settings.json から来ているかが一覧表示されます。

Allow・Ask・Denyの3つに分かれて出るので、意図しない許可が混ざっていないかを確認してください。

allowルールは、確認ダイアログで「はい、今後は聞かない」を選ぶたびに増えていきます。

気づくと、そのときの気分で通したコマンドが積み上がっているんですよね。

ちなみに確認ダイアログで Ctrl+E を押すと、そのコマンドの説明とリスク評価が表示されます。
見慣れないコマンドが出てきたときは、押してから判断すると安心です。

【ステップ2】denyから書き始める

設定はallowからではなく、denyから書きます。

理由は評価の順番にあって、deny・ask・allowの順で最初にマッチしたものが結果を決めるからでした。

つまりdenyが最強で、ほかのどこで許可されていても通りません。

ここで大事な性質がひとつあります。

denyルールに「ただしこれだけは許す」という例外を書き足すことはできません。

ルールの具体性は順序を変えないので、Bash(aws *) をdenyしたうえで Bash(aws s3 ls) だけallowする、という設計は成立しないんです。
広く塞ぐか、塞ぐ範囲を最初から狭く書くか、どちらかを選ぶことになります。

{
  "permissions": {
    "deny": [
      "Read(//**/.env)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(git push *)",
      "Bash(curl *)"
    ]
  }
}

ここで1つ注意があります。

ReadとEditのdenyは、Claudeの組み込みツールと cat のような認識済みのコマンドには効きますが、Pythonスクリプトがファイルを自力で開くような間接的な読み取りまでは止められません。

そこを含めて塞ぎたいなら、後半で扱うサンドボックスと組み合わせる必要があります。

【ステップ3】allowで日常のコマンドを通す

塞ぐ場所が決まったら、次に通す場所を書いていきます。

ここは欲張らず、毎日使うのに毎回確認されるのが面倒なものだけに絞るのがコツでした。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git commit *)"
    ]
  }
}

逆に、git push やパッケージのインストールは入れないほうが無難です。インストールは、依存の中身ごと持ち込むことになるからですね。

外に影響が出る操作は、多少面倒でも目で見てから通したいですからね。

なお、ls・cat・grep のような読み取り専用コマンドは、書かなくても最初から確認なしで動きます。
この一覧は変更できないので、逆に確認したい場合はaskかdenyを足してください。

【ステップ4】パスとワイルドカードの書き方に注意する

最後に、設定ミスがいちばん出やすいところを押さえます。

まずパスです。先頭のスラッシュ1つは、ファイルシステムのルートではなく設定ファイルの場所を指します。

つまりユーザー設定に Read(/secrets/**) と書くと、守られるのは ~/.claude/secrets/** になってしまいます。

次に気をつけたいのがワイルドカードの書き方です。

Bashのルールで * の前にスペースを入れるかどうかで、マッチする範囲が変わります。

Bash(ls *) は ls -la にマッチしますが lsof にはマッチしません。
スペースなしの Bash(ls*) だと、lsof まで通ってしまいます。

複合コマンドの扱いも覚えておくと役に立ちます。

Claude Codeは && や | でつながったコマンドを分解して、それぞれ独立に判定します。

そのため Bash(npm test *) を許可していても、npm test && rm -rf dist がまるごと通ることはありません。
ここは素直に安心できる仕様でした。

Claude Codeのサンドボックスで資格情報を守る

権限ルールだけでは届かない範囲を埋めるのが、サンドボックスです。

ここでは仕組みの違いから、資格情報を守る設定までを見ていきます。

権限ルールとの守備範囲の違い

権限ルールとサンドボックスは、止めている場所がまったく違います。

権限ルールはコマンドが実行される前に、その文字列を見て判断する仕組みです。

いっぽうサンドボックスは、OSの機能を使って実行中のプロセスに境界を敷きます。

この違いが効いてくるのが、さっき触れた間接的な読み取りです。

Pythonスクリプトを1本書いて、その中でファイルを開いて外に送る。この動きは、コマンド文字列を見るだけでは止められません。

サンドボックスならOSが止めてくれるので、子プロセスまでまとめて境界の中に入ります。
権限ルールとサンドボックスは、どちらかではなく両方を重ねて使うものだと考えてください。

有効にする手順と対応するOS

サンドボックスはClaude Codeに組み込まれていて、追加のインストールなしで始められます。

/sandbox

このコマンドでパネルが開き、モードと設定を確認できます。

macOSは標準のSeatbeltを使うので、そのまま動きました。

Linuxなら sudo apt-get install bubblewrap socat のように入れてから、Claude Codeを再起動します。

すべてのプロジェクトで有効にしたいときは、ユーザー設定に sandbox.enabled を書いておくのが早いです。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

既定では、書き込めるのは作業ディレクトリとセッション用の一時ディレクトリだけです。
ビルドツールがそれ以外の場所に書きたいなら、allowWrite でそのパスだけを開けます。ツールごとサンドボックスから外す（excludedCommands）よりも、こちらのほうが穴が小さくて済みますよ。

資格情報を隠すマスクという選択肢

ここが今回いちばん紹介したい設定です。

サンドボックスの既定の読み取りポリシーは意外と緩くて、~/.aws/credentials や ~/.ssh/ は読める状態になっています。

環境変数に入れたトークンも、そのまま子プロセスへ引き継がれてしまうんですよね。

deny は確実ですが、副作用があります。
環境変数を消してしまうので、それで認証している gh や npm まで動かなくなるんですよね。
そこで使えるのがマスクでした。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GH_TOKEN", "mode": "mask", "injectHosts": ["api.github.com"] }
      ]
    }
  }
}

マスクを設定すると、サンドボックスの中のコマンドが見るのはセッションごとの偽の値だけになります。
実際の通信が指定したホストに出ていくときに、プロキシが本物の値へ差し替える仕組みです。

つまりログに書き出されても本物は残らないのに、認証は通るという状態を作れます。
ファイル側は deny しか選べないので、鍵ファイルは素直に塞いでおきましょう。

ネットワークを絞るときの限界

ネットワークについても、少し正直な話をしておきます。

サンドボックスのプロキシは、既定ではTLSの中身を見ません。

つまり接続先のホスト名で許可を判断しているだけで、暗号化された通信の内容までは検査していないんです。

それでも、既定で許可されているドメインが1つもないという設計は助かります。最初は何もつながらない状態から始まり、必要なものだけを足していく形になるからです。

新しい接続先が出てくるたびに確認が入るので、想定外の通信には気づけるんですよね。

脅威モデルがもっと厳しいなら、TLSを終端して中身を検査する独自プロキシを立てる道も用意されています。
そこまでやるかどうかは、扱っているコードの機密度で決めることになります。

Claude Codeの権限設定をチームへ配る管理設定

個人で決めた設定は、そのままではチームに効きません。

ここでは、組織として外せないルールを配る方法を見ていきます。

設定ファイルの優先順位

Claude Codeの設定は、複数の場所に分かれて置かれます。

優先順位は上から順に決まっていて、いちばん強いのが管理設定でした。

ここで覚えておきたいのは、denyだけは順位を飛び越えるという点です。どのレベルであれ拒否されたものは、ほかのレベルで許可し直せません。

管理設定に至っては、コマンドライン引数でも上書きできません。--allowedTools を付けたところで、管理側のdenyは外れないということですね。

逆に --disallowedTools のように制限を足す方向は、いつでも効きます。締める方向には誰でも動かせて、緩める方向には上位の設定が要る、という作りになっています。

ユーザー設定でdenyしたものを、プロジェクト設定でallowすることもできないわけですね。

この性質のおかげで、自分の設定に「絶対に触られたくない場所」を書いておけば、どのプロジェクトへ行っても守られます。プロジェクト側の親切なallowで穴が開くことはありません。

管理設定でしか効かない項目

組織で本気で締めるなら、管理設定からしか読まれないキーを使います。

これらはユーザー設定に書いても効かないので、抜け道になりません。手元で同じキーを書いた開発者がいても、単に無視されるだけです。

サンドボックスを必須にしたい場合は、次の3つをセットで配るのが定番です。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

failIfUnavailable は、依存パッケージが足りないときに黙って素通りさせず、起動そのものを止める設定です。

これがないと、環境の準備ができていない端末ではサンドボックスなしで動いてしまいます。
セキュリティの関門として使うつもりなら、必ず入れておいてください。

フックで足りないところを埋める

ルールの書式では表現しきれない判断は、フックで補います。

PreToolUse フックは権限の確認より前に走るので、独自の条件で止められるんですよね。

たとえば「Bashは全部通すけれど、URLに社外のドメインが入っていたら落とす」といった書き方ができます。

ひとつ知っておきたいのは、フックの判断はdenyルールを上書きできないということです。

フックが「許可」を返しても、denyルールにマッチしていればブロックされます。

逆に、終了コード2で止めるフックはallowルールより強く効きます。
書き方はClaude Code hooksの使い方にまとめているので、そちらを見てみてください。

Claude Codeの権限設定で現実的な折衷ライン

最後に、実際どこまで締めればいいのかという話をします。

厳しくしすぎると使われなくなるので、そこの見極めが肝心でした。

個人で開発するときの線引き

個人開発なら、そこまで凝った設定は要りません。

やることは、資格情報をdenyで塞いで、日常のコマンドをallowで通すだけです。

あとはplanとacceptEditsを行き来すれば、確認の回数はかなり減ります。

これで、うっかり事故のほとんどは防げます。私はここに Bash(curl *) のdenyも足していて、外に出すときは自分でやると決めました。

逆に、個人開発で最初から管理設定まで作り込む必要はありません。自分でいつでも書き換えられる状態なので、統制の仕組みを重ねても手間が増えるだけでした。

読み込みたい情報があるならWebFetchを使わせればいいので、困ったことはありません。
むしろ、どのドメインを見に行ったかが記録に残るぶん安心できます。

業務で使うときの線引き

会社で使う場合は、個人の設定に頼らない形にしないと成立しません。

ここが個人との最大の違いで、各自の善意で成立している状態は統制とは呼べません。

だから、外せないルールは管理設定で配ります。

右の列を十分に緩めておくのが、意外と大事なところです。確認だらけで仕事にならないと、誰かが必ず抜け道を探し始めます。

導入時にありがちなのが、情シス側が締めるだけ締めて、開発側が「使いものにならない」と言って離れていく流れですね。締める設計と同じ熱量で、緩める設計もやったほうが結果的に安全になります。

そのときに --dangerously-skip-permissions が使えてしまうと、統制は一瞬で崩れますよね。
だからこそ、締めると同時に「日常はストレスなく動く」状態も作っておいてください。

迷ったときの決め方

最後に、個別の判断で迷ったときの基準をひとつ。

そのコマンドが失敗したときに、自分の手で元に戻せるかどうかで決めています。

戻せるならallow、戻せないならaskかdenyです。この一言だけ覚えておけば、新しいコマンドが出てきても迷いません。

この基準にすると、コマンドの見た目の危なさに惑わされません。rm が入っていても、ビルド成果物を消すだけなら戻せます。

チームで基準を共有するときも、この言い方だと揉めにくいです。「危険だから禁止」だと感覚の話になりますが、「戻せないから確認する」なら誰でも同じ判断ができますよね。

逆に curl は一見おとなしいのに、一度送ってしまったものは取り消せません。
危険度ではなく可逆性で分ける、これがいちばん迷わない基準でした。

Claude Codeの権限設定と安全性に関するよくある質問

ここでは、権限まわりで実際によく聞かれる疑問に答えていきます。

Q：確認が多すぎて作業になりません。全部許可にしてもいいですか？

A：全部許可にする前に、denyで塞ぐ場所を決めるほうが先です。資格情報とpushだけ塞いでおけば、残りは思い切って通しても事故になりにくくなります。

それでも足りないなら、サンドボックスを有効にしたうえで自動許可モードを使う手があります。OSが境界を守ってくれるので、確認を減らしても壊れる範囲は限定されたままです。

Q：CLAUDE.mdに「本番に触るな」と書けば守ってくれますか？

A：守ろうとはしますが、保証はありません。権限ルールを実装しているのはClaude Code本体で、CLAUDE.mdはあくまでモデルへのお願いです。

会話が長くなったり、外部のファイルに別の指示が紛れ込んだりすると効かなくなることがあります。絶対に守りたい線は、必ずdenyルール側に書いてください。

Q：denyしたコマンドの一部だけ許可することはできますか？

A：できません。ルールはdeny・ask・allowの順に評価され、最初にマッチしたものが結果を決めます。ルールが具体的かどうかは順序に影響しません。

そのため Bash(aws *) をdenyしたうえで Bash(aws s3 ls) だけallowする、という書き方は成立しません。塞ぐ範囲を最初から狭く書くか、askにして毎回確認するかを選びます。

Q：サンドボックスを有効にすれば権限ルールは要りませんか？

A：両方必要です。サンドボックスが守るのはBashコマンドとその子プロセスだけで、Read・Edit・WriteやWebFetch、MCPツールは権限ルール側の管轄になります。

逆に権限ルールだけだと、スクリプトが自力でファイルを開くような間接的な読み取りを止められません。重ねて使うことで、それぞれの穴を埋め合う形になります。

まとめ

Claude Codeの権限設定は、全部許可か毎回確認かの二択ではありません。

絶対に触らせない場所をdenyで固め、日常の作業をallowで通し、残りをサンドボックスで受け止める。この3枚を重ねるのが現実的でした。

設定を厳しくしすぎると、今度は誰も守らなくなります。日常の手数を減らすことと、線を引くことは、どちらも同じくらい大事です。

まずは /permissions を1回打って、いまの自分がどこまで許してしまっているのかを見てみてください。
そこから、締めるべき場所が見えてくるはずです。

ここまでの内容を一人で回せるようになったら、次は同じやり方をチームや社内に広げる段階に入ります。体系立てて学び直したい方や、研修という形で社内に展開したい方は、社会人におすすめの生成AI研修スクール｜スクール6校を比較を参考にしてみてください。