Claude Code を使い始めると、すぐに「許可してよいのか」で手が止まります。
ファイルを読ませるだけならまだ分かります。けれど、ファイル編集、コマンド実行、削除、外部サービスへの接続が出てくると、急に判断が重くなります。
最初は慎重に読んでいても、何回も確認が出ると、だんだん Yes を押す作業になります。これはよくあります。面倒です。ただ、ここを流すと、あとで差分を見たときに「これ、いつ変わった？」となります。
tomo許可画面が怖いのは、普通です。怖いまま使うのではなく、どこを見ればいいかを決めておくと少し落ち着きます。
この記事では、Claude Code の許可画面で初心者が見るべき場所を整理します。細かい権限設定を最初から覚える必要はありません。まずは、読むだけの操作と、手元の環境を変える操作を分けるところから始めます。
許可画面では、「何をするか」「どこに影響するか」「戻せるか」を見ます。削除、上書き、外部サービスへの書き込み、秘密情報に触る操作は、分からないまま通さないでください。
許可画面は作業が変わる合図
Claude Code は、ただ文章で答えるだけの道具ではありません。プロジェクト内のファイルを読み、必要なら編集し、シェルコマンドを実行できます。
ここが便利です。エラーの原因を探す、テストを実行する、README を直す、複数ファイルの関係を見る。普通のチャットより、実際の作業に近いところまで進められます。
そのかわり、操作によっては確認が入ります。許可画面は、作業の邪魔をするために出ているわけではありません。Claude Code が、手元の環境に影響するかもしれない操作へ進もうとしている合図です。
読むだけの操作と、環境を変える操作を分ける
最初に見るのは、Claude Code が「読むだけ」なのか「何かを変える」のかです。
読み取りだけなら、手元のファイルは変わりません。たとえば、プロジェクト構成を説明してもらう依頼です。
このプロジェクトの構成を説明してください。主要なファイルを5つまで挙げてください。まだファイルは編集しないでください。この依頼なら、Claude Code はファイルを読んで説明します。初心者が最初に試すには悪くありません。
気をつけるのは、次のような操作です。
- ファイルを作る
- ファイルを書き換える
- ファイルやフォルダを削除する
- コマンドを実行する
- ネットワークや外部サービスへアクセスする
- 権限や設定を変える
全部を怖がる必要はありません。ただ、読み取りから一歩進む操作では、何をするのかを見ます。
「よく分からないけれど、たぶん大丈夫」で許可しないでください。分からないなら、Claude Code に説明させてからで十分です。
Allow、Ask、Denyをざっくり理解する
Claude Code では、/permissions で権限ルールを確認できます。
/permissions考え方は大きく3つです。
| 種類 | 意味 | 初心者の考え方 |
|---|---|---|
Allow | 指定した操作を確認なしで許可する | よく分かる操作だけに絞る |
Ask | 実行前に確認する | 最初は多めでよい |
Deny | 指定した操作を拒否する | 秘密情報や危ない操作に使う |
最初から Allow を増やしすぎると、確認が減る代わりに、見落としやすくなります。慣れるまでは Ask が多いくらいでちょうどいいです。
たとえば npm test のように、そのプロジェクトで何度も実行する確認コマンドなら、あとで Allow に寄せる余地があります。一方で、削除や外部サービスへの書き込みは、毎回止まるほうが安全です。
Yesを押す前に見るところ
許可画面で毎回すべてを細かく読むのは大変です。
なので、見る場所を決めます。最初は、対象ファイル、対象フォルダ、コマンド名、外部アクセス、秘密情報。この5つだけで十分です。
対象ファイルとフォルダを見る
ファイル操作の許可が出たら、まず対象パスを見ます。
dist や build のような生成物なら、消して作り直せることがあります。もちろんプロジェクトによりますが、手で書いたファイルよりは戻しやすい場合が多いです。
一方で、次のようなファイルは重いです。
src配下のソースコードpackage.jsonやビルド設定.envや秘密情報を含むファイル.git配下のGit管理情報
同じ「ファイル変更」でも、README の誤字修正と .env の書き換えでは意味が違います。
分からないときは、こう聞きます。
変更しようとしているファイルを一覧にしてください。それぞれ、なぜ変更が必要なのか説明してください。まだ編集しないでください。この質問で、作業範囲が見えます。ここで予想外のファイルが出てきたら、いったん止めます。
コマンドの意味を一文で説明できるか見る
コマンド実行の許可が出たら、コマンド名を見ます。
たとえば、次は確認系として読みやすいです。
git statusnpm testgit status はGitの状態を見ます。npm test はテストを実行します。もちろんテストの中身が外部サービスへ接続する可能性はありますが、少なくともコマンド名から目的を想像しやすいです。
一方で、次のようなコマンドは止まって見ます。
rm -rf distRemove-Item -Recurse .\distgit push origin mainnpm publish削除、公開、外部への書き込みが入っています。ここは流れで通さないほうがいいです。
コマンドの意味が分からないなら、Claude Code に聞きます。
このコマンドは何を確認するものですか？ファイルを書き換えますか？外部サービスにアクセスしますか？まだ実行しないでください。
tomo一文で説明できないコマンドは、許可前に止める。これだけでもかなり事故を減らせます。
初心者が止まるべき危険操作
Claude Code の許可画面で、毎回びくびくする必要はありません。
見るべき操作はある程度決まっています。削除、上書き、外部サービスへの書き込み、秘密情報。この4つが出たら、いったん止まります。
削除と上書きは対象パスを読む
削除系のコマンドは、対象パスがすべてです。
rm -rf distRemove-Item -Recurse .\distこの例では dist が対象です。生成済みHTMLやビルド結果だけなら、作り直せるかもしれません。けれど、対象が src や .env なら、話が変わります。
特に -Recurse や -Force が付いているときは、フォルダごと消す、確認を減らして消す、といった意味を持つことがあります。Windows の PowerShell でも、Remove-Item -Recurse はフォルダ配下をまとめて対象にします。
上書きも同じです。
設定ファイルを今の構成に合わせて修正します。この提案だけでは、何を変えるのか分かりません。package.json、CI設定、デプロイ設定、.env.example などは、小さな変更でも影響が広がります。
許可前には、こう聞きます。
削除または上書きする対象パスを一覧にしてください。生成物か、手で書いたファイルかも分けてください。まだ実行しないでください。ここで自分が読める説明が返ってこないなら、まだ進めなくていいです。
外部サービスへの書き込みは最後を自分で持つ
ローカルファイルの変更と、外部サービスへの書き込みは重さが違います。
たとえば、次の操作です。
git push origin maingh pr merge 123npm publishnpm run post -- articles/example.mdGitHub に push する、PR をマージする、npm に公開する、WordPress に下書き投稿する。これらは外側に影響します。
WordPress の下書き投稿は公開ではありません。それでも、ローカルだけの作業ではありません。投稿先サイトにデータが作られます。
初心者のうちは、手順作成と最後の実行を分けるのが安全です。
デプロイ手順を作ってください。ただし、実際のデプロイコマンドは実行しないでください。最後に私が実行するコマンドを一覧にしてください。慣れてきたら、下書き投稿やPR作成まで任せてもよい場面はあります。ただ、外部に書き込む操作は「何が作られるか」を読んでから通すほうが安心です。
秘密情報には触らせない
.env、APIキー、アクセストークン、秘密鍵、本番DBの接続情報。このあたりは、最初から線を引きます。
エラー調査で必要そうに見えても、.env の中身を丸ごと読ませる必要はありません。まずは、キー名とエラー文だけで進めます。
.env の中身は見せません。関係しそうな環境変数名とエラー文だけから、原因候補を出してください。まだファイルは編集しないでください。必要なら、値を伏せた例を渡します。
DATABASE_URL=postgres://***:***@example.com:5432/appAPI_KEY=***秘密情報は、あとから「見せすぎた」と気づいても面倒です。最初から読ませない前提にしておくほうが楽です。
本番DB、決済、管理画面、APIキーに関わる操作は、Claude Code が提案してもそのまま承認しないでください。ローカル作業とは別物として扱います。
permission modesは速さより止まれることを優先する
Claude Code には、確認の出方を変える permission modes があります。
細かい設定はあとで構いません。初心者が最初に知るべきなのは、速く進むモードほど、人間が途中で止める機会が減るということです。
| モード | ざっくりした意味 | 初心者の使いどころ |
|---|---|---|
default | 読み取り中心で、必要な操作ごとに確認する | 最初の基本 |
plan | 調査と計画に寄せて、編集前に止まりやすい | 大きめの作業前 |
acceptEdits | ファイル編集の確認を減らす | 差分確認に慣れてから |
auto | 安全確認を挟みつつ、作業を長めに進める | 方向が固まった作業 |
bypassPermissions | 多くの確認を飛ばす | 隔離環境以外では避ける |
最初はdefaultかplanでよい
最初は default で十分です。確認は多いですが、そのぶん途中で止まれます。
大きめの作業では、plan が向いています。いきなり編集せず、先に方針を出してもらえます。
claude --permission-mode planまたは、会話の中でこう頼みます。
まず計画だけ出してください。どのファイルを読むか、どのファイルを変更するか、確認方法を説明してください。まだファイルは編集しないでください。計画を見れば、触ってほしくないファイルが含まれていないか確認できます。あとから差分を戻すより、編集前に止めるほうが軽いです。
bypassPermissionsは隔離環境以外で使わない
bypassPermissions は、許可確認を大きく減らします。--dangerously-skip-permissions という名前でも見かけます。
これは、普段の作業フォルダで気軽に使うものではありません。壊れても戻せるコンテナや仮想マシンなど、隔離された環境で使う前提の強いモードです。
確認が面倒だから、という理由で使うのは危ないです。
本命のプロジェクト、仕事のリポジトリ、秘密情報がある環境では、bypassPermissions を使わないでください。速さより、止まれることを優先します。
Yes連打を減らす頼み方
許可画面が多くなる原因は、Claude Code 側だけではありません。依頼が大きすぎると、読むファイルも、動かすコマンドも、変更する範囲も増えます。
つまり、頼み方を小さくすると、許可画面も読みやすくなります。
「まだ編集しないでください」で調査だけにする
まず調査だけにします。
このエラーの原因を調べてください。関係しそうなファイル名と、そう考えた理由を説明してください。まだファイルは編集しないでください。この依頼なら、原因候補を知るところで止まれます。
いきなり次のように頼むと、範囲が広がりやすいです。
動くように全部直してください。「全部」は便利な言葉ですが、差分を読みにくくします。初心者のうちは、調査、方針、編集を分けます。
まず原因を調べてください。次に修正方針だけ出してください。私が確認するまで、ファイルは編集しないでください。この一文を入れるだけで、許可する内容がかなり見やすくなります。
変更ファイルを先に出してもらう
編集に進む前に、変更予定ファイルを出してもらいます。
修正する前に、変更予定のファイル名と理由を一覧にしてください。削除、上書き、外部アクセスがある場合は分けて書いてください。まだ編集しないでください。ここで README.md だけなら、比較的読みやすいです。package.json、CI設定、デプロイ設定、.env が出てきたら、もう少し細かく聞きます。
今回は変更範囲を小さくしたいです。README.md だけを対象にした場合、どこまで直せますか？作業範囲を小さくすると、許可画面も差分も小さくなります。Claude Code を疑うというより、自分が追えるサイズにするための工夫です。
tomo「調査だけ」「方針だけ」「この1ファイルだけ」と分けると、Claude Code はかなり扱いやすくなります。
まとめ
Claude Code の許可画面で見ることは、難しくありません。
まず、読むだけなのか、手元の環境を変えるのかを分けます。次に、対象ファイル、対象フォルダ、コマンド名、外部アクセス、秘密情報を見ます。
最初に止まるべき操作は、このあたりです。
- 削除や上書き
-Recurse、-Force、rm -rfが入る操作git push、npm publish、デプロイ、WordPress投稿のような外部への書き込み.env、APIキー、トークン、本番DBに触る操作- 自分が一文で説明できないコマンド
迷ったら、こう聞けば大丈夫です。
この操作を許可する前に、何をするのか初心者向けに説明してください。ファイル変更、削除、外部アクセス、秘密情報へのアクセスがあるかも分けてください。安全に使うというのは、Claude Code に何もさせないことではありません。自分が止まれる場所を残したまま、少しずつ任せることです。
最初は遅くて構いません。Yes を押す前に、何をする操作なのか説明できるかを見る。そこから始めれば、許可画面はただの怖い表示ではなく、作業を区切る目印になります。
