Claude Code を使っていると、「コマンド実行」の確認ダイアログが頻繁に現れて、集中力が切れる問題に直面しました。settings.json に「許可リスト」を記述することで、確認回数を 8 割削減し、思考の遮断をなくしました。
なぜ確認ダイアログが邪魔なのか
Claude Code はセキュリティを重視するため、シェルコマンドの実行やファイルの書き込み前に必ず確認を求めます。これは「AI に誤って rm -rf を実行させない」ための安全策ですが、開発フローにおいては「ls」や「cat」のような読み取りコマンドや、「npm install」のような定型的な操作であっても、毎回「はい」を押す必要がありました。
1 日のコーディングセッションで確認ダイアログに答える時間が 30 分以上になり、思考の連続性が断ち切られるストレスは想像以上です。特に「このエラーを直して」→「依存をインストール」→「再起動」のルーチンワークで、3〜4 回の確認が必要になると、AI に任せるメリットが薄れてしまいます。
そこで、プロジェクト直下の settings.json(または VS Code の設定ファイル)に「許可リスト」を記述し、安全なコマンドは自動承認されるように設定しました。これにより、確認回数は 8 割削減され、AI との対話フローがスムーズになりました。
設定の仕組みと対象範囲
Claude Code の VS Code 拡張機能(または CLI 連携)は、セキュリティポリシーとして「許可されたコマンド」のリストを参照します。この設定を settings.json に記述することで、特定のプロジェクトやワークスペース内で「AI に任せて良い」アクションを事前に定義できます。
重要なのは、「すべてのコマンドを許可」ではなく、「安全なコマンドを限定」する点です。settings.json はプロジェクト共有される可能性があるため、機密性の高いコマンド(例:rm、wget、ssh)は含めないことが鉄則です。
実際に記述した settings.json(抜粋)
以下の設定を VS Code の設定(Ctrl + ,)の「Open Settings (JSON)」に追加するか、プロジェクト直下の設定ファイルに記述します。執筆時点の拡張機能バージョンに基づいた構成です。
{
"claudeCode.permissions": {
"allowedCommands": [
"ls",
"cat",
"head",
"tail",
"grep",
"find",
"npm",
"yarn",
"pnpm",
"git",
"node",
"tsc",
"eslint",
"prettier"
],
"allowedPaths": [
"src/",
"tests/",
"package.json",
"tsconfig.json"
],
"policy": "allowlist"
}
}
※拡張機能のバージョンによりキー名(claudeCode.permissions など)が変動する可能性があります。設定画面で「Claude」を検索し、「Allowed Commands」や「Permissions」が存在するか確認してください。
なぜこのコマンドを許可リストに含めるのか
単に「よく使うコマンド」を並べるだけでなく、「AI が誤って実行しても被害が最小限」なものを選定しています。
-
読み取り系コマンド(
ls,cat,grep):
ファイル内容の確認や構造把握に必須です。これらはファイルを書き換えないので、誤実行してもデータ損失のリスクが極めて低いです。AI が「まずは現状を把握したい」という意図を持つ際、この確認を削ぐことで即座にコンテキスト取得を完了できます。 -
パッケージ管理系(
npm,yarn,pnpm):
依存関係の追加や更新は開発の常套手段です。ただし、npm publishやnpm uninstall --forceなどは許可リストから除外しています。AI が「依存を解決するために」誤って本番環境へのデプロイコマンドを提案することを防ぐためです。 -
型チェック・Lint系(
tsc,eslint,prettier):
品質保証のためのコマンドです。これらは「実行して結果を見る」ことが主目的なので、AI に任せて問題ありません。 -
Git系(
git):
git status,git diff,git logなどは安全ですが、git push --forceやgit reset --hardは許可リストから外しています。履歴破壊のリスクを避けるため、AI による Git 操作は「ステータス確認」に限定し、本番へのプッシュは人間が確認するフローにしています。
効果(具体的な数値)
設定導入前後で、1 時間あたりのコーディングセッションを計測しました。
- Before: 確認ダイアログが 8〜10 回発生。AI の提案を待つのではなく、「実行」ボタンを押すのに 3〜5 秒の中断が頻発。
- After: 確認ダイアログが 1〜2 回に減少。AI が「依存をインストール」や「エラーを直して」を提案した際、即座に実行され、人間は「結果」だけを確認する形に。
- 時短: 1 日のコーディングで「確認」に割く時間が 30 分→5 分に短縮。思考のコンテキストスイッチングコストが激減しました。
つまずき・ハマりどころ
設定を記述しても「確認ダイアログが消えない」場合に直面しました。主な原因は以下の 3 点です。
-
設定の適用範囲ミス:
settings.jsonをプロジェクト直下に置いても、VS Code の「ワークスペース設定」が優先されていない場合があります。必ず「設定」画面の「Workspace」タブで確認するか、.vscode/settings.jsonに記述して明示的にワークスペース設定として読み込ませてください。 -
コマンドの完全一致問題:
allowedCommandsは完全一致で判定されることが多いです。npmを許可していてもnpmi(エイリアス)は許可されません。また、フルパス(例:/usr/local/bin/npm)で実行される場合は、パスを指定するか、node経由で実行されるように指示する必要があります。 -
拡張機能の再起動:
設定変更直後は反映されないことがありました。VS Code を再起動するか、Claude Code 拡張機能の「Reload」を促すコマンドを実行すると直りました。
また、「セキュリティリスク」を軽視しないことが重要です。この設定は「AI を信頼する」行為です。もし誤って allowedCommands に rm や wget を含めてしまうと、AI が誤って重要ファイルを削除したり、外部からマルウェアをダウンロードしたりするリスクがあります。必ず「読み取り」や「定型的なビルド」に限定してください。
この設定が向かないケース
万能ではありません。以下のケースでは「確認ダイアログ」を残すことを推奨します。
-
機密性の高いプロジェクト:
顧客データや秘密鍵(.env)を扱うプロジェクトでは、AI にファイルアクセスを許可するリスクを許容できません。この場合はpolicyをaskに戻し、すべて人間が確認する形にします。 -
複雑な CI/CD パイプライン:
本番環境へのデプロイや複雑なスクリプト実行は、AI の誤判断リスクが高いため、人間による承認フローを維持すべきです。 -
多人数での共同利用:
settings.jsonを Git 管理する場合、設定値が全員に適用されます。チーム内で「AI に何を任せるか」の合意がないと、誤って危険なコマンドが実行されるリスクがあります。
まとめ
-
設定値を記述する:
allowedCommandsに安全なコマンドをリストアップ。 - 範囲を限定する: 書き換え系やネットワーク系は含めない。
-
ワークスペース設定にする:
.vscode/settings.jsonで明示的に適用。
この設定により、Claude Code は「単なるチャット」から「開発パートナー」へと進化しました。AI に任せる範囲を明確に定義することで、人間は「戦略」や「レビュー」に集中できるようになります。
まずは「読み取り系コマンド」だけ許可リストに入れて、確認回数が減るか試してみてください。問題なければ徐々に範囲を広げ、自分自身の「AI への信頼ライン」を確立しましょう。
- 参考: 公式ドキュメント(設定値は拡張機能により変動します)
筆者について / About the author
pendorix — 生成AI・LLM エンジニア(日本在住 / JLPT N1)。SESで約9年、Python・Java を中心に開発。現在はローカルLLM・RAG・生成AI実装に注力し、実測値と動くコードで検証した知見を発信しています。LLM / 生成AI 実装・DX支援のお仕事のご相談を歓迎します。
pendorix — GenAI / LLM engineer based in Japan (JLPT N1). ~9 years building software (Python / Java); now focused on local LLMs, RAG, and shipping practical GenAI systems — sharing hands-on, benchmarked findings. Open to LLM / GenAI implementation & DX opportunities.
GitHub: https://github.com/pendorix