ClaudeCodeのBash実行許可で迷わない安全設定7手順

ClaudeCodeで作業していると、Bashの実行前に何度も確認が出て、つい「全部許可したい」と感じる場面があります。けれど、確認を雑に消すと、ファイル削除、外部送信、本番環境への操作まで通してしまう危険があります。大切なのは、よく使う安全な操作だけを静かに通し、危ない操作は止め、迷う操作は確認に戻すことです。

Bash実行許可で最初に理解すること

ClaudeCodeのBash実行許可は、単に「実行してよいか」を決めるだけではありません。作業中のAIに、どこまで任せるかを決める安全装置です。初心者が最初に押さえるべきなのは、許可を増やすほど速くなるが、止めるルールが弱いほど危なくなるという関係です。

確認画面が出る理由

Bashは、フォルダ一覧を見るだけにも、ファイルを消すにも、外部へデータを送るにも使えます。画面に確認が出るのは、ClaudeCodeが「この操作を本当に実行してよいか」を人間に戻している状態です。たとえば、読み取りだけの操作なら問題が小さい一方、削除、上書き、送信、デプロイ、本番接続は一度実行すると戻しにくいことがあります。

最初から全部許可しない

初心者がやりがちな失敗は、確認が面倒になって危険なスキップ系オプションを使うことです。これを使うと、確認画面が消える代わりに、編集、削除、外部通信までまとめて通りやすくなります。ローカルの実験用コンテナや使い捨て環境なら選択肢になりますが、普段使う開発環境では避けるのが安全です。

安全な設定はdenyから作る

Bash実行許可は、よく使うコマンドを先に許可したくなります。しかし、実務では逆です。まず止めるものを決めます。なぜなら、許可設定が広すぎたときでも、拒否設定が残っていれば最後の防波堤になるからです。

止めるべき操作を先に決める

最初に止めたいのは、削除、強制上書き、外部送信、秘密情報の読み取り、本番環境への変更です。たとえば、rm系、curl系、認証情報ファイル、環境変数ファイル、秘密鍵、force付きGit操作は、初心者ほど自動許可に入れないほうが安全です。

場面	おすすめ判断
フォルダ確認やログ確認	よく使うものだけ許可します。
ファイル編集やテスト実行	プロジェクト内だけ許可し、範囲外は確認にします。
削除や外部通信	原則として拒否または毎回確認にします。
本番環境への接続	自動許可せず、Hookや別環境で守ります。

この表の判断に沿って設定すると、「便利だけど怖い」状態から抜け出せます。まず危険な操作を拒否し、その後で読み取り系だけを少しずつ許可すると、設定ミスの影響を小さくできます。

allowよりdenyを強く考える

allowは確認なしで通す設定、askは毎回確認する設定、denyは止める設定です。安全設計では、denyを最優先の安全線として扱います。たとえば、一覧表示を許可していても、特定の危険な場所や危険な操作は拒否に入れておきます。これにより、普段の作業は速くなり、危ない操作だけ止められます。

初心者向けの実践設定手順

設定は一気に完成させようとすると失敗します。最初は小さく始め、実際に確認画面が出たコマンドだけを見直すほうが安全です。半角空白が必要なコマンド例は、読みやすさのために「␠」で表します。実際に入力するときは「␠」を半角空白に置き換えます。

settings.jsonで迷うポイント

初心者が混乱しやすいのは、User設定とProject設定の違いです。個人だけの習慣はユーザー側、プロジェクト全体で守るべきルールはプロジェクト側に置くと整理しやすくなります。ただし、拒否したい危険操作は、個人設定かプロジェクト設定かに関係なく、明示的に止める意識が必要です。

広すぎる許可は事故のもと

「gitなら全部安全」「npmなら全部安全」と考えるのは危険です。git␠statusは読み取りですが、git␠pushやgit␠resetは結果が大きく変わります。npm␠testは安全寄りでも、npm経由で任意のスクリプトが動く場合があります。許可はコマンド名だけでなく、何をする操作かで判断してください。

AutoModeと危険なスキップの違い

2026年時点のClaudeCodeでは、確認を減らす選択肢としてAutoModeがあります。AutoModeは、すべてを無条件で通すものではなく、安全そうな操作を自動で進め、危険そうな操作は止めたり確認に戻したりする考え方です。

AutoModeが向いている場面

テスト、軽い修正、読み取り中心の調査、作業ブランチ内の編集には向いています。作業中に確認画面で何度も止まるストレスを減らしつつ、危険な操作はそのまま通りにくくなります。Shift+Tabで権限モードを切り替えられる環境では、計画を確認してから実行寄りに変える使い方がしやすくなります。

危険なスキップを避けるべき理由

危険なスキップ系の起動方法は、確認そのものを大きく外します。便利に見えますが、AIが読んだファイルに悪意ある指示が含まれていた場合や、作業対象を勘違いした場合に、止める機会が減ります。使うなら、ネットワークとファイルを制限したコンテナ、使い捨てリポジトリ、復元可能な検証環境に限定するのが現実的です。

Hookで一段深く守る

allowやdenyだけでは、複雑なBashの形を判断しにくいことがあります。たとえば、コメント付きのコマンド、複数コマンドの連結、リモート実行、オプション順序の違いです。このような場面では、PreToolUseHookでBash実行前に独自チェックを入れると安全性が上がります。

Hookが役立つ場面

Hookは、ClaudeCodeがBashを実行する直前に割り込めます。リモート接続先、実行内容、危険な引数、対象ブランチ、対象ファイルを見て、許可、確認、拒否を返せます。特にSSH、クラウドCLI、Kubernetes、Terraform、Dockerのように、同じコマンド名でも結果が大きく変わる操作に向いています。

Hookだけに頼らない

Hookは強力ですが、設定を間違えると安全な操作まで毎回確認になったり、逆に危険な操作を通したりします。基本はsettings.jsonで大枠を作り、複雑な判定だけHookに任せます。さらに、クラウド側のIAM、保護ブランチ、削除保護、コンテナ隔離を組み合わせると、ClaudeCode側の設定ミスだけで大事故になりにくくなります。

ClaudeCodeのBash実行許可に関する疑問解決

Bash実行許可でいちばん大切なのは、「毎回聞かれない状態」を目指すことではありません。聞かれなくてもよい操作だけを聞かれない状態にすることです。ここを間違えると、作業効率は上がっても、安心して任せられなくなります。

読み取り系だけ許可すれば十分？

最初は十分です。pwd、ls、git␠status、git␠diff、git␠log、grep系、テスト実行のような操作だけを許可すると、日常作業の確認はかなり減ります。編集や削除は、慣れるまで確認に残してください。数日使って問題がないものだけ追加すると、設定が自然に育ちます。

なぜコマンドの文字列だけで判断すると危ない？

Bashは書き方を少し変えるだけで、見た目と意味が変わります。環境変数を前に付ける、複数コマンドをつなぐ、リダイレクトする、サブシェルで包む、リモート先に渡す、という形があります。単純な前方一致だけで許可すると、想定外の実行まで通ることがあります。だから、広いワイルドカードをallowに入れるより、狭く許可し、危険操作はdenyやHookで止めるほうが安全です。

許可設定を増やすタイミングは？

確認画面が出た瞬間にすぐ許可へ追加するのではなく、「その操作は読み取りか」「失敗しても戻せるか」「秘密情報に触れないか」「本番や共有環境に影響しないか」を見ます。この4つに全部安心して答えられるなら、許可候補です。ひとつでも迷うならaskのままにしてください。

初心者が最初につまずく落とし穴

設定ファイルを作ったのに反映されない

いちばん多いのが、プロジェクトのフォルダで.claude/settings.jsonを作ったのに、ClaudeCodeを開いてBash実行を頼むと、前と同じように確認画面が出続ける場面です。「あれ、設定を書いたのに効いてない？」となって、ここで手が止まります。

原因はだいたい2つです。1つ目は、settings.jsonを置く場所が今作業しているプロジェクト直下ではないこと。2つ目は、ClaudeCodeを起動したあとに設定を作っていて、今のセッション（作業中の会話のまとまり）に反映されていないことです。

この場面で、プロジェクト直下に置くことと、起動し直すことだけ覚えておけば、かなりの確率で解決します。ぶっちゃけ、最初は高度な設定より「どこに置いたか」のほうが大事です。

許可したはずのコマンドでまた確認される

次につまずくのが、gitstatusを許可したつもりなのに、ClaudeCodeがgitstatus–shortのような少し違う形で実行しようとして、確認画面が出る場面です。初心者から見ると「同じgitstatusじゃないの？」と思います。

原因は、Bashの許可設定がかなり細かく見られることです。人間には同じ作業に見えても、ClaudeCode側では「別の書き方のコマンド」として扱われることがあります。

この場面で大事なのは、確認画面が出るたびにイライラして全部許可しないことです。確認されたコマンドを1個ずつ見て、安全なものだけ通す。最初の3日間はこのやり方がいちばん安全です。

dangerouslyという言葉を見ても危険度がピンとこない

初心者が本当にやりがちなのが、確認が面倒になってdangerously-skip-permissions系の起動方法を試してしまうことです。名前にdangerouslyと書いてあっても、「公式にあるなら大丈夫でしょ」と思ってしまいます。

これは、家の鍵を開けたまま「今日は誰も入ってこないはず」と言って出かけるようなものです。動けば速いですが、万が一のときに止める場所がありません。

ぶっちゃけ、初心者のうちはdangerouslyと付くものは触らないで十分です。1か月くらい普通の許可設定に慣れてからでも遅くありません。

知っているとできるの差を埋める実践ロードマップ

1日目は何も許可せず観察する

所要時間は15分です。ClaudeCodeをいつものプロジェクトで開き、「このプロジェクトの構成を確認して」と頼みます。確認画面が出たら、すぐに許可設定へ追加せず、表示されたBashコマンドをメモします。

完了の判断基準は、最低3個のコマンドをメモできていることです。たとえばpwd、ls、find、gitstatusのようなものが並びます。この日は設定をいじらず、ClaudeCodeが何を実行したがるのかを見るだけでOKです。

2日目は読み取り系だけを許可する

所要時間は20分です。1日目にメモしたコマンドの中から、見るだけの操作を選びます。pwdの場面で実行を許可すると、現在地の確認が自動で進みます。lsの場面で実行を許可すると、フォルダ一覧の確認が止まらず進みます。gitstatusの場面で実行を許可すると、変更状況の確認が毎回止まらなくなります。

完了の判断基準は、ClaudeCodeに「現在の変更状況を確認して」と頼んだとき、読み取り系の確認が1回以上減っていることです。全部消す必要はありません。1回減れば前進です。

3日目は拒否リストを先に作る

所要時間は25分です。settings.jsonを開き、削除、強制変更、外部送信に関係する操作をdenyに入れます。rmの場面でdenyを入れると、ファイル削除を自動では通さない状態になります。gitpushの場面でdenyまたはaskにすると、リモートリポジトリ（ネット上の共有保管場所）へ勝手に送る事故を防げます。

完了の判断基準は、ClaudeCodeに危険そうな操作を頼んだとき、確認または拒否になることです。初心者はここで安心感がかなり変わります。

4日目はテスト実行だけ許可候補にする

所要時間は20分です。プロジェクトで普段使うテストコマンドを1つだけ選びます。npmtest、pytest、bundleexecrspecなど、環境によって違います。テスト実行の場面で、その1つだけを許可すると、コード修正後の確認がスムーズになります。

完了の判断基準は、ClaudeCodeに「修正後にテストを実行して」と頼み、想定したテストだけが動くことです。ここで複数のテストやビルドまでまとめて許可しないでください。まず1つで十分です。

5日目は確認画面の文章を読む練習をする

所要時間は15分です。確認画面が出たら、コマンド名だけでなく、後ろの引数（コマンドに渡す細かい指定）まで読みます。rm-rfの場面で-rfを見つけたら強い削除だと判断できます。curlの場面で外部の宛先が出ていたら、データ送信の可能性を疑えます。

完了の判断基準は、確認画面を見て「これは見るだけ」「これは変更する」「これは外へつなぐ」の3分類ができることです。この分類ができると、怖さがかなり減ります。

6日目は1つだけ許可を追加する

所要時間は10分です。5日間使って何度も出た確認のうち、本当に安全だと判断できるものを1つだけallowに追加します。gitlogの場面で許可すると、履歴確認が止まりません。grepやrgの場面で許可すると、コード検索がスムーズになります。

完了の判断基準は、追加した1つの操作だけ確認が出なくなり、それ以外の危ない操作はまだ止まることです。1日に5個も10個も追加しないでください。増やすほど、あとで何が危ないかわからなくなります。

7日目は自分用の安全ルールを3行で書く

所要時間は15分です。プロジェクトのメモやCLAUDE.mdに、自分用のルールを3行だけ書きます。たとえば「削除は毎回確認」「pushは自分で実行」「読み取り系だけ自動許可」のように書きます。

完了の判断基準は、次にClaudeCodeを開いたときに、その3行を見れば自分の運用方針を思い出せることです。設定より先に運用ルールを短く持つと、迷ったときに戻れます。

現実でよくあるある失敗と専門家の対処法

失敗1:確認が面倒で全部通してしまう

作業がノッてきた夜23時、テスト修正を急いでいて、Bashの確認画面が5回連続で出ます。最初はちゃんと読んでいたのに、だんだん「はいはい、許可」と押し続けます。すると、途中で想定していないファイル変更や削除が混ざっていて、あとから差分を見て焦ります。

根本原因は、確認画面を安全装置ではなく邪魔なポップアップとして扱っていることです。疲れていると、人間は確認を読む精度が一気に落ちます。

専門家なら、確認を減らす前に作業を2つに分けます。調査の場面で読み取り系だけ許可すると、構成確認や検索が止まらず進みます。変更の場面で編集や削除をaskに残すと、事故りやすい操作だけ人間に戻ってきます。最後に、Gitの差分確認の場面でgitdiffを実行すると、何が変わったかを自分の目で確認できます。

予防策は、作業開始前に「今日は許可を追加しない」と決めることです。特に夜、急ぎ、疲れている、締切前の4条件がそろったら、設定変更をしないほうがいいです。設定を変えるのは翌日の朝10分でやるほうが安全です。

失敗2:gitなら安全だと思って広く許可する

初心者はgitstatusやgitlogをよく使うので、「git系は全部大丈夫そう」と思いがちです。その結果、gitで始まるコマンドを広く許可してしまいます。数日後、ClaudeCodeがgitpushやgitcleanに近い操作を提案し、そこで初めて怖さに気づきます。

根本原因は、コマンド名だけで安全性を判断していることです。同じgitでも、見るだけの操作と、履歴やファイルを変える操作があります。

専門家なら、gitを3つに分けます。gitstatus、gitlog、gitdiff、gitshowの場面では読み取りなので許可候補にします。gitaddやgitcommitの場面では変更を記録する操作なので確認にします。gitpush、gitreset、gitcleanの場面では共有先や作業状態に影響するので拒否または毎回確認にします。

予防策は、コマンド名ではなく動作で分けることです。「見る」「ローカルで変える」「外へ送る」の3分類にして、外へ送るものは絶対に自動許可しない。このルールだけで、Gitまわりの事故はかなり減ります。

失敗3:設定を育てずに完成形を探し続ける

初心者はよく「おすすめの完璧なsettings.json」を探し始めます。30分、1時間と調べて、結局どれが自分の環境に合うかわからず、設定ファイルを作らないまま終わります。これはかなりあるあるです。

根本原因は、ClaudeCodeのBash実行許可がプロジェクトごとに違うからです。Webアプリ、Python分析、インフラ管理、個人メモでは、安全なコマンドがまったく違います。

専門家なら、完成形を探さず、最初の1週間で自分の作業から設定を育てます。確認画面が出た場面でコマンドをメモすると、自分が本当に使う操作だけが集まります。3日後に同じ確認が3回以上出たものだけ許可候補にすると、無駄な許可が増えません。7日後に使っていない許可を消すと、設定がスリムになります。

予防策は、最初から100点を狙わないことです。初日は0点でいいです。2日目に読み取り系を3つ許可できれば十分です。7日目に「自分の作業で困らない最低限」になっていれば成功です。

ぶっちゃけこうした方がいい！

ぶっちゃけ、初心者は最初からHook、AutoMode、細かいパターン設計まで全部やらなくていいです。そこに行く前に疲れます。まずは読み取り系だけ自動許可に集中するのがいちばんコスパいいです。

最初の目標は、「確認画面をゼロにする」ではありません。「何を見ているだけで、何が危ない操作なのかを自分で判断できるようになる」ことです。この感覚がないまま許可を広げると、設定は便利な道具ではなく、事故の入口になります。

正直、最初のおすすめはかなりシンプルです。pwdの場面で自動許可すると、作業場所の確認が止まりません。lsの場面で自動許可すると、フォルダ確認が止まりません。gitstatusの場面で自動許可すると、変更状況の確認が止まりません。gitdiffの場面で自動許可すると、何が変わったかをすぐ見られます。まずはこのあたりだけで十分です。

逆に、ぶっちゃけ最初はやらなくていいものもあります。クラウドCLI（AWSやGCPなどを操作する道具）の自動許可は後回しでいいです。SSH（別のサーバーに入る仕組み）の自動許可も後回しでいいです。docker操作も、コンテナ（小さな隔離環境）を壊すだけに見えて、ネットワークやファイルに影響することがあるので後回しでいいです。

まず7日間は、ClaudeCodeを「勝手に全部やってくれる相棒」ではなく、「作業を提案してくれる後輩」くらいに見るのがちょうどいいです。後輩にいきなり本番サーバーの鍵は渡さないですよね。最初は資料を探してもらう、差分を見てもらう、テストを回してもらう。そのくらいから始めるのが安全です。

初心者が最短で結果を出す近道は、毎日10分だけ確認画面を見直すことです。作業後の場面で、今日出た確認を3つだけ見返すと、「これは毎回出ても仕方ない」「これは許可していい」「これは絶対に止める」が見えてきます。これを1週間続けるだけで、設定の精度はかなり上がります。

最後にかなり本音を言うと、Bash実行許可で失敗する人は、技術が足りないというより、最初に欲張りすぎています。最初から自動化を完成させようとしないでください。まずは見るだけ。次にテストだけ。その次に限定的な編集。外へ送る操作や削除は、しばらく人間が握る。この順番がいちばん事故りにくく、しかもちゃんと速くなります。

今日やることは1つでいいです。プロジェクトを開いて、読み取り系の確認を3つだけメモしてください。明日、その中から1つだけ許可します。これだけで、ClaudeCodeのBash実行許可は「怖くて触れないもの」から「自分で育てられる道具」に変わります。

よくある質問

毎回Bashの確認が出るのは設定ミスですか？

必ずしも設定ミスではありません。ClaudeCodeは安全側に倒して確認を出すことがあります。まずは確認画面に出たコマンドを見て、読み取りだけの操作か、変更を伴う操作かを分けてください。読み取りだけで何度も使うものはallowへ、変更を伴うものはaskへ、危険なものはdenyへ入れると整理できます。

AutoModeだけ使えば設定は不要ですか？

不要にはなりません。AutoModeは確認を減らす助けになりますが、プロジェクト固有の禁止事項までは完全には理解できません。たとえば「このリポジトリではmainへ直接pushしない」「この.envは絶対に読ませない」「このクラウドアカウントは参照だけ」というルールは、settings.jsonやHookで明示したほうが安全です。

チームで設定を共有するときの注意点は？

個人が便利にするための許可と、チーム全体で守るべき禁止を混ぜないことです。共有設定には、危険操作のdeny、秘密情報のRead拒否、最低限の読み取り系allowだけを入れます。個人の作業効率化はローカル設定に分けると、チーム全体の安全線を崩さずに済みます。

まとめ

ClaudeCodeのBash実行許可は、確認を消すための設定ではなく、安心して作業を任せるための設計です。最初にdenyで危険操作を止め、allowは読み取り系から小さく始め、迷う操作はaskに残します。AutoModeは確認を減らす便利な選択肢ですが、プロジェクト固有の禁止ルールはsettings.jsonやHookで明示するほうが安全です。
今日から始めるなら、まずプロジェクトの.claude/settings.jsonを開き、削除、外部送信、秘密情報、本番変更をdenyに入れてください。そのうえで、毎日使う読み取り操作だけをallowに加えます。この順番なら、作業は軽くなり、危ない操作は止まり、初心者でも安心してClaudeCodeにBash実行を任せられるようになります。