【実測】Claude Codeの許可設定を923件ぜんぶ数えた｜4か月ぶんの「今後確認しない」は効いていなかった

Claude Codeで「はい、今後確認しない」を押し続けると、設定ファイルに許可のルールが1行ずつ増えていきます。私は4か月押し続けました。今日それを全部数えたら923件あって、そのうち何件が実際に安全に効いているのかを調べたら、想像とかなり違う結果になりました。非エンジニアの方が3分で自分の設定を点検できる手順まで、実測した数字つきで書きます。

きっかけは「社内ツールの危ない設定」という投稿だった

今朝Xを見ていたら、こういう投稿が流れてきました。

「Claude CodeやCodexで社内ツールを作った会社の環境、レビューに入るとほぼ100%危ない設定が残っています」

自分は関係ないと思いました。私は非エンジニアで、会社の基幹システムを触っているわけでもありません。ただ、その「ほぼ100%」という言い方が引っかかったので、自分の設定ファイルを開いてみることにしました。

Claude Codeの許可設定は、~/.claude/settings.json というファイルの permissions という項目に入っています。私はこのファイルを、一度も自分の手で書いたことがありませんでした。全部、作業中に出てくる「はい、今後確認しない」を押した結果として、自動的に積み上がったものです。

数えてみたら、そこには923件ありました。

結果｜許可923件、禁止0件、確認0件

許可設定には3つの種類があります。

• allow（許可）: これは聞かずにやっていい

• deny（禁止）: これは絶対にやらせない

• ask（確認）: これは必ず私に聞いてから

私の設定はこうなっていました。

• allow: 923件

• deny: 0件

• ask: 0件

4か月かけて「やっていいこと」だけを923件積み上げて、「やってはいけないこと」は1件も書いていなかったわけです。

自分では、許可を細かく積み上げているぶん安全側に寄せているつもりでした。1件ずつ内容を確認して「はい」を押してきたのだから、雑に全部許可しているよりはマシだろう、と。この前提が正しいのかを確かめるのが、この記事でやったことです。

中身を分類した｜760件がコマンド、その最多はcurlの209件

923件をツールの種類で分けると、こうなりました。

• Bash（コマンド実行）: 760件

• WebFetch（Webページの取得）: 100件

• Read（ファイル読み取り）: 14件

• その他（ブラウザ操作、スプレッドシート操作など）: 49件

そしてBashの760件を、コマンドの先頭の単語で数え直すと、上位はこうです。

• curl（ネットに通信する）: 209件

• AWS_PROFILE（AWSの操作）: 123件

• ls（ファイル一覧）: 34件

• python3: 27件

• cp（コピー）: 24件

• grep（検索）: 23件

• pkill（プロセスを止める）: 22件

いちばん多いのが「ネットに通信するコマンド」だったのは、正直に言うと意外でした。自分の作業の中心は記事を書くことなので、通信より文章の処理のほうが多いつもりだったからです。実際には、APIを叩く検証や動作確認のたびに1件ずつ許可が増えていて、それが4か月分たまっていました。

発見1｜80件は、そもそも書く必要がなかった

Claude Codeの公式ドキュメントには、こう書かれています。

日本語にすると「ls（一覧）やcat（表示）やgrep（検索）のような、読むだけのコマンドは、どのモードでも最初から確認なしで動く」という意味です。読むだけで何も壊さないコマンドは、許可を書く前から通るようになっている、ということですね。

私の923件のうち、この「最初から通るコマンド」に当たるものが80件ありました。全体の8.7%です。

つまり80回ぶん、私は「はい、今後確認しない」を押していますが、押しても押さなくても結果は同じでした。設定ファイルの行数が増えただけです。

これ自体は害がありません。ただ、「923件も許可があるのだから、それなりに広く許可してしまっているな」という私の感覚が、最初の時点でずれていたことは分かりました。数の多さは、許可の広さと同じではないということです。

発見2｜923件の意味を消す4行が混ざっていた

もっと重要な発見はこちらでした。

923件の中に、こういう行が混ざっていました。

Bash(python3:*)
Bash(python3 -c ":*)
Bash(node -e ':*)
Bash(npx tsx -e ':*)

:* は「ここから先は何でもいい」という意味の書き方です。Bash(python3:*) は「python3で始まるコマンドなら何でも許可」を意味します。

そして python3 -c "..." は、その場で書いたプログラムをそのまま実行する書き方です。プログラムの中身は何でも書けます。ファイルを消すことも、どこかに送信することも、設定を書き換えることもできます。

つまりこの1行があると、残り919件を1件ずつ丁寧に許可してきた意味が、ほとんど消えます。「lsは許可、cpは許可、mvはまだ許可していない」と積み上げていても、python3を通せば全部できてしまうからです。

同じことが node -e（JavaScriptをその場で実行）や npx tsx -e（TypeScriptをその場で実行）にも言えます。数えると11件、そのうち完全に何でも通るものが4件ありました。

許可の数を積み上げても、通り道が1本空いていれば意味がない。これが今日いちばん腹に落ちたことでした。

発見3｜いま使っているモードでは、許可リストは主役ではなかった

ここからが本題です。

私の設定には、こう書いてありました。

"defaultMode": "auto"

これは「auto mode（自動モード）」という意味です。Pro・Max・Teamプランでは、これが最初から選ばれている既定のモードです。特に何も設定していない人も、たいていはこのモードで動いています。

auto modeは「全部動く、ただし別のAIが見張る」

公式ドキュメントのモード一覧を見ると、auto modeの説明はこうなっています。

「全部動く。ただしバックグラウンドで安全チェックが入る」ということです。そして、その安全チェックをやっているのは私の許可リストではありません。

auto modeでは、私の代わりに「classifier（分類器）」と呼ばれる別のAIが、実行される直前のアクションを1つずつ審査しているわけです。

ここで許可リストの立ち位置がはっきりします。allowは「あなたに確認を出さない」という設定です。ところがauto modeでは、そもそも確認がほとんど出ません。つまり私が4か月かけて923件積み上げたallowは、いま使っているモードでは、ほとんど仕事をしていませんでした。

見張り役が持っているルールは66件だったでは、その見張り役は何を見ているのか。実は自分の環境でそのまま確認できます。

claude auto-mode defaults

これを実行すると、classifierが持っているルールが全部出てきます。私の環境では35KBほどのテキストが出力されました。中身を数えると、こうなっていました。

• hard_deny（絶対に止める）: 1件

• soft_deny（原則止める）: 66件

• allow（例外として認める）: 17件

• environment（何を「内部」とみなすかの設定）: 20項目

唯一のhard_denyは「Data Exfiltration」、つまりデータの持ち出しでした。信頼できる範囲の外に、機微なデータが出ていくこと。これだけが無条件で止まります。

soft_denyの66件には、こういう項目が並んでいました。「Git Destructive（履歴を壊す操作）」「Production Deploy（本番へのデプロイ）」「Credential Leakage（認証情報の流出）」「Irreversible Local Destruction（取り返しのつかないローカル削除）」「Create Public Surface（公開状態を作る）」など。

私が「ls は許可、cp は許可」と1件ずつ押していた4か月のあいだ、実際に私を守っていたのは、この66件のほうだったということです。

そして environment の20項目のうち、11項目が「None configured（未設定）」でした。「信頼できる社内ドメイン」「信頼できるクラウドの保存先」「秘密情報の管理方法」などが全部空欄です。空欄だと、そこは「外部」として扱われます。ひとりで使う分には、むしろ安全側に倒れる初期値です。

では何を書けば効くのか｜実測で確かめた

ここまでで「allowはあまり効いていない」ことは分かりました。では、何を書けば効くのか。

公式ドキュメントには、ルールの評価順がこう書かれています。

deny（禁止）が最初、次にask（確認）、最後にallow（許可）。先にマッチしたものが結果を決めます。しかも deny は auto mode でも、それどころか全部スキップするモードでも効きます。

書いてあることは分かりましたが、自分の環境で本当にそうなるのかは別の話です。無害なコマンドで実際に試しました。

実測1｜auto modeでも「ask」は必ず止まる

wc（行数を数えるだけのコマンド）を材料にしました。

テストC: askに Bash(wc *) と書き、auto modeで wc -l /etc/hosts を実行させる

→ 実行できませんでした（許可が下りず拒否）

テストD（対照）: ルールを空にして、同じことをauto modeで実行させる

→ 実行できました（9行と出力）

同じコマンド、同じモードで、askの1行があるかどうかだけで結果が変わりました。auto modeでも、askに書いたものは必ず人間に確認が来る。これは実測で確認できました。

実測2｜書き方を1文字間違えると、denyは効かない

もうひとつ、書き方の検証です。

ネットでよく見かける「危ない設定を塞ぐ」例に、こういう書き方があります。

"deny": ["Bash(curl * | sh)"]

「ネットから落としてきたスクリプトをそのまま実行するのを禁止する」という意図です。一見すると正しそうです。私も最初、これを自分の設定に書こうとしました。

ところが公式ドキュメントには、こう書いてあります。

パイプ（|）は「コマンドの区切り」として認識される、つまり curl X | sh は curl X と sh の2つに分解されて、それぞれ別々に判定される、ということです。ということは curl * | sh という1本のパターンは、分解されたどちらにもマッチしないはずです。

無害なコマンドで確かめました。

テストA: denyに Bash(echo * | wc *) と書いて、echo hi | wc -l を実行させる

→ 実行できました（denyが効いていない）

テストB: denyに Bash(wc *) と、パイプの右側だけを書いて、同じコマンドを実行させる

→ 実行できませんでした（denyが効いた）

同じコマンドを止めたいのに、書き方が違うだけで結果が逆になりました。パイプを含んだまま書くと効かず、右側だけを単体で書くと効く。

これは怖い挙動だと思いました。書き間違えても、エラーも警告も出ないからです。設定ファイルには確かに「禁止」と書いてあるのに、実際は素通りします。書いた本人は塞いだつもりでいます。

もうひとつの落とし穴｜ユーザー設定の「.env」はhome全体を守らない

.env というファイルには、APIキーやパスワードが入っています。これをAIに読ませたくない、というのはよくある要望で、公式ドキュメントにもペーストして使える例が載っています。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

ここで注意が必要なのは、この例はプロジェクトごとの設定ファイル用だという点です。./ は「いまいる場所から見て」という意味なので、書く場所によって守る範囲が変わります。

公式ドキュメントには、はっきりこう書かれています。

ユーザー設定（~/.claude/settings.json）に書いたパスは ~/.claude/ を基準に解釈されます。つまり全プロジェクトを守るつもりで Read(**/.env) とユーザー設定に書いても、実際に守られるのは ~/.claude/ の下だけ、ということになります。

さらに罠があって、「じゃあ全部にしよう」と Read(//**/.env) と書くと、ドキュメントいわく「何にもマッチしない」ルールになります。

全プロジェクトに効かせたい場合は、ホームからの相対パス（~/）か、絶対パス（//）で書く必要があります。私は Read(~/**/.env) と Read(~/**/.env.*) の形にしました。

私が実際に書き足した11行

以上をふまえて、自分の設定に書き足したのがこの11行です。allowの923件は1件も消していません。消すと日常の作業が止まるからです。

"deny": [
  "Bash(sh)", "Bash(sh *)",
  "Bash(bash)", "Bash(bash *)",
  "Bash(zsh)", "Bash(zsh *)",
  "Read(~/**/.env)", "Read(~/**/.env.*)"
],
"ask": [
  "Bash(git push *)",
  "Bash(gh pr create *)",
  "Bash(rm -rf *)"
]

denyの前半6行は、さきほどの実測の結論をそのまま反映したものです。「curl | sh を止めたい」なら、パイプごと書くのではなく右側に来るシェルそのものを塞ぐ。私の設定にはもともと sh や bash を直接実行する許可が0件だったので、これを塞いでも日常の作業には影響しませんでした。

askの3行は、公式が「人間の確認を挟みたいときのレシピ」として挙げているものに、rm -rf（フォルダごと削除）を足しました。私の既存の許可には rm -f（ファイル1つ削除）が4件ありましたが、rm -rf 形式は0件だったので、ここも作業は止まりません。

書き足したあと、本当に効いているか確認しました。

sh -c 'echo test' を実行して
→ 実行できませんでした（権限が拒否されました）

auto modeのまま、denyが効いています。起動時の警告も出ていません。

なお、git push をaskに入れたので、これからは毎回確認が来ます。手間は増えますが、これは意図した手間です。

非エンジニアのための「3分の設定点検」

コマンドが分からなくても、この4つは確認できます。ターミナルに貼り付けるだけの手順にしました。

Step 1｜自分の許可が何件あるか数える

python3 -c "import json,os;d=json.load(open(os.path.expanduser('~/.claude/settings.json')));p=d.get('permissions',{});print('allow',len(p.get('allow',[])),'deny',len(p.get('deny',[])),'ask',len(p.get('ask',[])))"

deny 0 ask 0 と出たら、私と同じ状態です。

Step 2｜「何でも通る1行」が混ざっていないか見る

grep -E "python3?:\*|node -e|npx tsx -e|bash -c|sh -c" ~/.claude/settings.json

ここに何か出てきたら、その1行が他の許可より優先して効いています。消すかどうかは作業内容次第ですが、「そこが通り道になっている」ことは知っておいたほうがいいです。

Step 3｜見張り役が何を止めているか、目で見る

claude auto-mode defaults

長い出力が出ますが、soft_deny の項目名だけ眺めるだけでも意味があります。自分が心配していたことが、すでにリストに入っているかどうかが分かります。

Step 4｜止めたいものを1行だけ書く

いきなり完璧な設定を作る必要はありません。「これだけは絶対に自動でやってほしくない」を1つだけ決めて、askに書きます。

私の場合はそれが Bash(git push *) でした。公開されている場所に何かを送る操作は、必ず自分の目を通したかったからです。

書いたあとは、必ず実際に動かして確かめてください。書いただけでは効いているか分かりません。今回の記事でいちばん強く実感したのがそこです。

やらなかったこと、残った課題

正直に書いておきます。

allowの923件は掃除していません。 80件は無意味、4件は他を無効化する、と分かっていながら残しました。消すと過去の作業スクリプトが止まる可能性があり、今日は影響範囲を確認しきれなかったためです。

curl の209件も残しています。 公式は「Bashのネットワーク系コマンドはdenyで塞ぎ、代わりにWebFetchでドメインを指定して許可する」という方針を推奨しています。そのほうが安全なのは分かりますが、209件を全部置き換えるのは今日の作業量ではありませんでした。

environmentの11項目も未設定のままです。 ひとりで使っている限りは「全部外部扱い」のほうが安全側なので、急いでいません。ただし人を増やすときには必要になります。

つまり今日やったのは「危険を全部消す」ではなく、「通り道を1本だけ塞ぎ、確認を1つだけ増やす」です。それでも、何も書いていなかった昨日までとは状態が違います。

よくある質問

許可を923件も溜めてしまいましたが、危険なことは起きていますか

私の環境では、今のところ何も起きていません。ただしそれは、許可を細かく積み上げていたからではなく、auto modeの見張り役が66件のルールで止めていたからだと考えるほうが実態に近いです。運が良かった、と書くのが正確だと思います。

許可リストは消したほうがいいですか

急いで消す必要はありません。allowは「確認を出さない」設定なので、消しても危険にはならず、確認が増えるだけです。むしろ先にdenyとaskを1行ずつ書くほうが、効果がはっきりしています。

設定を書き間違えたらエラーで教えてくれますか

パターンの書き間違いは教えてくれません。今回の実測でも、効かないdenyルールを書いた状態で警告は一切出ませんでした。ツール名の打ち間違い（存在しないツール名を書いた場合）は起動時に警告が出ます。

auto modeは切ったほうが安全ですか

一概には言えません。auto modeを切ると、確認が自分に返ってくる代わりに、66件のルールを持つ見張り役も外れます。確認の回数が増えると、人は内容を読まずに押すようになります。それなら「見張り役は残したまま、絶対に止めたいものだけaskに書く」ほうが、私には現実的でした。

会社で複数人が使っている場合は

管理者用の設定ファイル（managed settings）に deny を書く方法があります。公式ドキュメントには「どうしても実行させたくない操作は、managed settingsのpermissions.denyに書く。これは見張り役より前に働き、上書きできない」と明記されています。個人の設定より強い場所がある、ということです。

まとめ

自分の許可設定923件を数えて分かったのは、この5つでした。

1. allow 923件に対して、deny 0件・ask 0件だった。許可だけを積み上げていた

2. 80件（8.7%）は、書かなくても最初から通るコマンドだった

3. python3:* のような4行が、残り919件の積み上げを無意味にしていた

4. auto modeでは、allowは主役ではない。66件のルールを持つ別のAIが審査している

5. 効くのはdenyとask。ただし書き方を間違えると、警告も出ないまま素通りする

「はい、今後確認しない」を押し続けることは、設定を作っている行為ではありませんでした。ただ確認を消しているだけです。実際に効く設定は、自分の手で数行書く必要があります。

私が今日書き足したのは11行で、作業時間は30分ほどでした。allowを923件積み上げた4か月より、この30分のほうが確実に効いています。

自分が公開したツールの点検については『【実測】Claude Codeで作って公開したツール14個を全部点検した｜非エンジニアが見落とす穴は2種類だけだった』に書きました。auto modeが既定になった経緯と、モードを戻す方法については『【8/14から】Claude Codeの確認画面が消える｜Auto modeが既定になる前にやる3つの設定と戻し方』でまとめています。

Claude Codeの新機能や、実際に動かして分かったことをXでも発信しています。この記事のような実測は、だいたい先にXに書いています。よかったらフォローしてください。

@ai_hack_dx