この記事にはプロモーションを含みます。本文中には私が販売している有料noteへのリンクがあり、記事の前後にはサイト共通の広告が表示されます。

頼んだ作業が、途中で止まる。画面には「この操作を実行していいですか」という確認。yesを押していいのか分からないまま、手が止まります。

中身を最後まで読めば安全です。ただ、読むほどの内容でもない確認にまで毎回許可を求められる。かといって読まずに毎回yesを押す癖がつくと、本当に見るべき1回を素通りしてしまいます。

覚えることは多くありません。Claude Codeがどこで止まる作りなのかさえ掴めば、押していい承認と止める承認は分けられます。判断軸は1つだけです。

まだ導入していない人は、Claude Codeのインストールと初期設定の手順を先に済ませてください。この記事はインストールが終わっている前提で進めます。

Claude Codeが毎回聞いてくるのはなぜ？

Claude Codeが毎回聞いてくるのは、実行される前に人間が止められるようにするためです。止める対象は、ファイルの書き換えとコマンドの実行です。

止められる場所は1か所しかありません。実行の直前です。動いた後では、書き換わったファイルも走ったコマンドも元には戻りません。

読むだけの操作は聞いてこない

公式ドキュメントによると、既定のManualモードは読み取りから始まります。ファイル一覧の表示や中身の閲覧、gitの状態確認は読むだけの操作です。あらかじめ許可された組み合わせとして、毎回確認なしで動きます。

つまり、画面が止まって毎回許可を求めてきた時点で、それは読むだけでは終わらない操作です。ここが最初の分かれ目になります。

聞かれるのは、あなたの環境が変わる操作

毎回許可を求められるのは、ファイルを書き換える操作と、パソコン上でコマンドを走らせる操作。この2つが中心です。

判定しているのはAIの気分ではありません。公式ドキュメントは、許可のルールを守らせているのはClaude Code本体だと明記しています。指示文やCLAUDE.mdに何を書いても、許可の範囲そのものは変わりません。

だから毎回確認が入るのは、調子が悪いからでも設定を間違えたからでもない。そういう作りだから、が答えです。

Claude Codeが止まる瞬間は2つしかない

止まるのは、ファイルを書き換える直前と、Bashでコマンドを走らせる直前。この2つに集約されます。

既定のManualモードは読み取り側から始まり、書き換え側へ進むところで毎回許可を求めてきます。承認画面が出た時点で、Claude Codeは読むだけの範囲を越えようとしている。

この区切りを知ってから、承認画面の見方が変わりました。全部を疑う必要はありません。書き換えと実行の2つだけを見れば足ります。

毎回「はい」を押し続けると、何が起きる？

中身を見ないまま毎回yesを押し続けると、承認は安全確認として働かなくなり、作業を進めるためのボタンに変わります。

これが承認疲れです。Claude Codeの公式ドキュメントも、繰り返しの確認を減らす方法を案内しています。よく使う安全なコマンドを、許可リストに入れておくやり方です。

裏を返せば、何も設定しないまま毎回確認に付き合い続ける状態は、公式が想定している使い方ではありません。

承認疲れは、気合いで直らない

同じ形の確認が何度も出れば、人は読まなくなります。注意力の問題ではありません。同じ刺激が続いたときに、誰にでも起きる反応です。

私自身、受託の開発中は同じ種類の確認が続きます。そこで内容を読み飛ばす癖がついた状態のまま、次の案件で別のフォルダを触る作業に入るのが一番まずい。承認疲れが怖いのは、疲れている自覚がないところです。

読まずに毎回yesを押す癖がつくと、どこが危ないのか

危ないのは、毎回確認が入ること自体ではありません。承認疲れで毎回yesを押す速度が上がった結果、範囲の外に出た1回を素通りさせてしまうことです。

Claude Codeが毎回許可を求めてくる画面は、安全な操作も範囲外の操作も同じ形で出てきます。見た目が同じだからこそ、読む習慣が切れた瞬間に見分けがつかなくなる。

だから私は、毎回yesを押す速さを競わないようにしています。承認疲れをためないほうが、結局は早く終わりました。

押した後で「思っていたのと違う」となったとき

承認したのに、期待した結果になっていない。この状態は、承認の判断ミスとは限りません。変更が保存されていない、別の場所に書かれている、といった原因のほうが多くあります。

そちらは切り分けの手順が別なので、Claude Codeで変更が保存されないときの確認手順にまとめてあります。承認を押した記憶はあるのに反映されていない人は、先にそちらを見てください。

私が許可を出している対象と、出していない対象

私の判断軸は1つです。今さっき自分が頼んだ作業に、その操作が出てくるはずかどうか。

コマンド名で危険度を覚えようとすると続きません。名前を知らないコマンドは常に出てくるからです。

頼んだ内容と、画面に出ている操作を突き合わせる。これだけなら、非エンジニアでも毎回できます。

押している承認

頼んだ作業の中身として、当然そうなるはずの操作は押します。

文言を直してと頼んで、そのファイルの書き換えが出てきた。テストを通してと頼んで、テストの実行コマンドが出てきた。ここで止める理由はありません。

この判断ができると、実際の作業は止まりません。私はこの押し方で3件の仕事を仕上げました。

内訳は、受託したWordPressテーマとStripe予約決済プラグインの納品。稼働中サイトのドメイン移管。レコプラの自動化スクリプト群です。

3件とも、承認を押しながら進めた仕事です。

このうち納品案件は、Claude CodeでWordPressの予約決済サイトを受託開発した記録にまとめてあります。毎回許可を出しながら何を作ったのか、中身はそちらに書きました。

止めて理由を聞く承認

頼んだ範囲から外に出ている操作は、押さずに理由を聞きます。押さないと決めてしまう前に、なぜ必要なのかを一度言わせる。納得できれば押します。

表の右2列だけを見ても判断はできません。左の列、つまり自分が何を頼んだかとセットで初めて意味を持ちます。同じ操作でも、頼んだ内容によって押す日と止める日があるということです。

止めると決めた承認は、閉じずに理由を聞く

範囲の外だと思った承認は、そのまま閉じません。その操作が何のために必要なのかを、Claude Codeに1行で説明させます。

納得できる説明なら押します。頼んだ内容と結びつかない説明が返ってきたら、依頼の書き方が悪かったと考えて頼み直す。毎回確認が入る仕組みは、この聞き返しの時間を作ってくれています。

この一手間を入れてから、毎回許可を出すか止めるかで固まる時間が短くなりました。

許可はプロジェクト単位で切る

私は許可の範囲を、プロジェクトごとに切って考えます。パソコン全体でまとめて決めることはしません。自分のブログの自動化スクリプトを触る作業と、他人のサイトを触る作業では、止める位置が違うからです。

実際の切り方はこうです。受託で預かっているシステムのフォルダには、環境変数ファイルと鍵ファイルの読み取りを禁止側に、本番へ反映する操作と依存パッケージの追加を要確認側に置いています。自分のブログのフォルダに書いてあるのは、記事チェック用スクリプトの実行を含む3行だけ。同じClaude Codeでも、開くフォルダが変われば止まる位置が入れ替わります。

線を引く場所さえ決めておけば、あとは表の突き合わせだけで済みます。毎回確認のたびに一から考え直す必要はありません。承認疲れがたまりにくいのは、この決め方をしているときです。

全部スキップする設定は、本当に必要？

全部スキップする設定は、公式ドキュメントが隔離された環境に限定して案内しているものです。

公式が挙げているのは、コンテナや仮想マシン、インターネットにつながっていない開発用コンテナです。Claude Codeがホスト側を壊しようがない環境でのみ使うこと、と書かれています。

条件付きの案内であって、誰にでも勧められている設定ではありません。

権限をバイパスする設定の実際の挙動

Claude Codeで承認スキップにあたる指定は --dangerously-skip-permissions です。公式ドキュメントによると、--permission-mode bypassPermissions と同じ指定です。

セッションの途中から切り替えることはできず、起動時にしか指定できません。

Claude Codeの初回起動時には、責任の所在を確認するダイアログが出ます。rootやsudoでの実行は拒否されます。設定ファイルにこの権限モードを書いても効かず、その場合セッションはManualで始まります。

見落としやすいのが、denyルールの扱いです。denyはどの権限モードでも効きますが、allowルールは権限をバイパスした状態では意味を持ちません。禁止だけは残る、と覚えておくと理解が早くなります。

私が使っていない理由

私は使っていません。理由は単純で、母艦のWindowsで他人の納品物を触っているからです。隔離環境ではない場所で全部を素通しにする理由が、私の側にない。

費用の話でもありません。私の契約は月額200ドルの定額なので、承認を減らしても請求は変わらない。私が承認を減らしたい動機は、手が止まる時間のほうです。

逆に、ネットから切り離したコンテナの中だけで検証している人なら、判断は変わります。自分の環境が公式の言う隔離環境に当てはまるかどうか。そこが先です。

自分の環境が隔離環境かどうか

見分け方は難しくありません。その環境が壊れたときに、仕事の納品物や自分のサイトが巻き添えになるか。答えがはっきりノーでないなら、Claude Codeの設定は既定のまま置いてください。

私のWindowsには、受託の作業フォルダもレコプラの自動化スクリプトも同居しています。毎回許可を求められる状態をそのまま残しているのは、この同居が理由です。

環境を分けたうえで承認スキップを検討するなら、順番としては筋が通ります。先に分けるのは環境で、設定はその後です。

承認を押す前にやっている準備

承認画面で迷う時間は、頼む前の準備でほとんど消えます。

迷いが生まれるのは、頼んだ範囲が広すぎて、どこまでが想定内か自分でも分からなくなっているときです。範囲が狭ければ、突き合わせは一瞬で終わります。

頼む範囲を1つに絞る

まとめて5つ頼むと、出てくる承認がどの依頼に対応するのか分からなくなります。1つ頼んで、終わらせて、次を頼む。地味ですが、これだけで毎回確認の中身が読めるようになります。

範囲を絞ると、承認の回数そのものは減りません。減るのは1回あたりの判断時間です。承認疲れに効くのは、回数より判断時間のほうでした。

戻せる状態にしてから頼む

変更前の状態に戻せるようにしてから頼むと、毎回許可を出す重さが変わります。押した結果が違っても戻せると分かっていれば、必要以上に構えずに済みます。

もう1つやっているのが、案件ごとにフォルダを分けておくことです。1つのフォルダに入れるのは1案件ぶんのファイルだけ。その案件のフォルダを開いてからClaude Codeに頼むので、関係ない案件のファイル名が承認画面に出てきません。出てきたとしたら、それは頼んだ範囲の外だと一目で分かります。

区切りをつけてから次を頼む

1つの依頼が終わったら、そこで一度止めます。動いている途中に次の依頼を重ねると、出てきた承認がどちらの依頼のものか分からなくなるからです。

区切りをつけると、承認画面に出るファイル名が直前の依頼とそのまま一致します。突き合わせに使う情報が頭に残っている状態で判断できる。

私はこの止め方で、稼働中サイトのドメイン移管のような戻しにくい作業も進めました。急いでいるときほど、区切りを増やすほうが速く終わります。

準備が済んでいれば、あとは頼んだ内容と画面を突き合わせて毎回yesを押すだけ。承認疲れが起きるのは、この準備を飛ばして長い依頼を投げたときです。

Antigravityの中から呼ぶと、承認の見え方はどう変わる？

Antigravityの中のターミナルからClaude Codeを呼んでも、毎回聞いてくる中身は変わりません。変わるのは、承認を読むときに横に何が見えているかです。

私はターミナルが苦手なところから始めました。いまはAntigravityの中のターミナルでClaude Codeを呼ぶ形に落ち着いています。同じ承認画面でも、段階ごとに読みやすさがまるで違いました。

私の環境が変わってきた4段階

4段階を通して、毎回確認が入る回数も条件も変わっていません。変わったのは、承認に書かれたファイル名の読み方です。今開いているファイルかどうかを、見た瞬間に判断できるようになりました。

呼び出し方より、頼み方のほうが効く

環境を変えれば承認疲れが消える、というほど単純ではありませんでした。効いたのは、頼む範囲を狭くしたことのほうです。

デスクトップ版でもAntigravityの中でも、Claude Codeが毎回許可を求めてくる操作の種類は同じでした。変わったのは私の側の速さだけです。

承認に出たファイル名と、いま開いているファイルが一致しているか。これを一目で見られる配置にしたことが、毎回許可を出すか止めるかの判断を軽くしました。

何を頼めるかがまだ掴めていない人は、Claude Codeでできることの具体例を先に見てください。頼む中身が分かると、承認の中身も読みやすくなります。

Claude Codeが毎回聞いてくるのを減らしたいときに見る場所

承認を減らす作業は、/permissions で今の設定を表示するところから始まります。

公式ドキュメントによると、このダイアログは今効いているルールを一覧で出します。それぞれのルールがどの settings.json から来ているかも並びます。

自分が何を許可済みなのか分からないまま設定を足すと、承認を減らすどころか挙動が読めなくなります。

allow、ask、denyの3種類と順番

ルールは3種類です。allowは確認なしで実行、askは毎回確認を出す、denyは実行させない。

判定される順番は決まっていて、まずdeny、次にask、最後にallowの順で見られます。先に一致したものが結果になり、書き方の細かさでは順番は変わりません。広いdenyを1本置くと、その内側にある細かいallowは通らないということです。

書き方は Bash(npm test) のように、ツール名と対象を組みで書く形です。Bash のようにツール名だけをdenyに書くと、そのツール自体が使われなくなります。

承認を減らすなら、狭いところから

承認を減らすときに広い許可から出すと、あとで何を許可したのか自分で追えなくなります。私は、何度も出てきた操作のうち、対象が狭くて中身の読めるものから順に考えます。

たとえばテスト実行のように、対象も結果もはっきりしている操作。ここを許可に回すだけで、毎回確認が出る回数は目に見えて減ります。

公開側へ反映する操作や外部へ送る操作は、毎回許可を求められる側に残しておきます。承認を減らすのは、確認をゼロにするためではありません。

私は場所によって書く量を変えている

私が allow と deny を設定ファイルに書き込んでいるのは、受託で預かっているシステムのフォルダです。禁止側に環境変数ファイルと鍵ファイルの読み取り、要確認側に本番へ反映する操作と履歴を書き換える操作を並べています。他人の資産を触る場所だけは、その場の判断に任せません。

自分のブログのフォルダに書いてあるのは3行だけです。壊しても困るのが自分だけの範囲なので、残りはその場に出た確認を読んで決めています。書く量を場所ごとに変えるやり方が、私の作業には合っていました。

設定を書かずに承認を減らす手もあります。公式は /sandbox やサンドボックスの有効化によって確認の回数が下がることも案内しています。承認スキップに踏み込む前に、まずサンドボックス側を見るほうが安全です。

まとめ｜Claude Codeが毎回聞いてくるのは味方に回せる

Claude Codeが毎回聞いてくるのは、実行前に人間が止められる場所を残すためでした。止まること自体は不具合ではありません。

判断軸は最後まで1つです。今さっき自分が頼んだ作業に、その操作が出てくるはずか。出てくるはずなら押す、範囲の外なら止めて理由を聞く。

そして承認を減らしたくなったら、/permissions で今の状態を見て、何度も出る安全な操作だけを許可に回す。全部を素通しにする設定は、隔離環境の話として切り分けておく。それで十分です。

毎回確認が入る状態は、慣れれば作業の区切りとして使えます。止まるたびに、自分が何を頼んだのかを思い出せるからです。

承認疲れを感じているなら、押す速さを上げるのではなく頼む範囲を狭くしてください。毎回yesを押す判断が軽くなり、Claude Codeに任せられる作業も増えていきます。

任せられる作業が増えたら、次は仕事として受ける話になります。単価から知りたい人はClaude Codeを副業にするときの始め方と単価相場を見てください。

Claude Codeが毎回聞いてくることへのよくある質問

公開日 2026年9月10日｜最終更新日 2026年9月10日

記事に書ききれなかった細かい判断や、詰まったところの相談はレコプラの公式LINEで受け付けています。