「常に許可」が積もると、settings.json に穴があく——Claude Code の権限設定を棚卸しした話

※トップの画像は、この記事の後半でつくる自作ツールの画面です。

Claude Code を実務で毎日使っています。ある日ふと settings.json を開いたら、許可リスト（allow）が 277行まで膨らんでいました。Claude Code は「このコマンドを常に許可しますか？」に「はい」を押すたび、そのコマンドを設定へ追記します。便利な反面、一回きりのコマンドが延々と積もっていく。気づけば、自分でも把握していない許可の山ができていました。

棚卸しして、ひやりとしました。deny（禁止）ブロックが一つも無い。つまり、許可をすり抜けた操作を止める“最後の砦”が無い状態です。

何が無防備だったか

具体的に挙げます。

• 秘密ファイルを守る deny が無い。 .env や wp-config.php（DB接続情報）を、AIがそのまま読める状態。プロンプトで「読むな」と書いても、それは口約束で、設定上の門番ではありません。
• 本番へ任意コマンドが通るワイルドカード許可。 過去の作業の名残で ssh <本番> * のような許可が残っていました。理屈の上では rm -rf すら無確認で本番に流せてしまう。
• 破壊コマンドが確認も遮断もされない。 rm -rf や git push --force が、確認なしで通る。

大事なのは、これが特別だらしない設定だったわけではないことです。allow は「常に許可」を押すたびに自動で伸びる。放っておけば、誰の設定もこうなります。構造的な落とし穴です。

何を直したか——判断のログ

検知するだけなら誰でもできます。価値があるのは「何を足し、何を捨て、なぜそう裁いたか」のほうだと思っています。

• 足した①：deny の床（最低限ここだけは守る“下限”。秘密ファイル遮断）を“グローバル”に。 .env／wp-config.php／鍵ファイルを読み書きさせない。案件ごとに重複させず、全案件に一度で効くよう、ユーザー全体の設定に置きました。
• 足した②：破壊操作は deny ではなく ask（毎回確認）に。 rm -rf や git push --force は完全に禁じると実務で困る場面があります。止めるのではなく、毎回ひと呼吸おいて確認する——これが安全と速度の折り合いだと判断しました。
• 捨てた：危険なワイルドカード許可（ssh *／cat > *／node -e など）。利便性は下がりますが、“何でも実行できる口”を残すリスクのほうが重い。消しても、次に使うとき一度だけ確認が出るだけです。

AIに任せた所と、人が裁いた所

正直に書きます。検知ルール（どんな文字列が危ないか）の洗い出しは、AIと一緒に詰めました。そこはAIが速い。ですが、「何を完全に禁止し、何を確認に留め、何を許すか」の線引きは、人が決めるべき判断でした。プロジェクトの事情と、壊れたときに取り返しがつくかの肌感覚が要る。AIに丸投げできない部分です。

作ったもの：cc-guard

同じ穴を他の人も持っているはずだと思い、貼るだけで診断して直す単一ページを作りました。settings.json を貼ると、上の穴を検知して赤で示し、安全の床（deny / ask）をマージした“完成形の settings.json”を返します。それを丸ごとコピーして置き換えるだけ。

ひとつ決めたのは、入力を一切サーバーに送らないこと。設定ファイルは機微情報です。全部ブラウザの中だけで処理し、通信もAPIもありません。診断ツールが情報を抜いていては本末転倒なので。

試せます： https://include-jp.com/labs/cc-guard/

まとめ

AIに開発環境を任せるほど、「自分が何を許しているか」を定期的に見る習慣が要ります。allow は放置で膨らむ。たまに棚卸しして、せめて deny の床だけは敷いておく——それだけで事故の芽はだいぶ減ります。

この記事で扱った権限設計は、受託の現場でClaude Codeを実務運用するための一領域です。任せ方の線引きから環境トラブル、本番反映の作法まで、全体像は「Claude Code実務運用ガイド」にまとめています。