Claude Codeの権限設定｜確認プロンプトの扱い

確認プロンプトは何のためにあるか

Claude Codeは、ファイルを書き換える前・コマンドを実行する前に「これをやっていいか」と聞いてきます。この確認には2つの意味があります。

• 事故の防止──意図しない変更を、実行前に止められる
• 学習の機会──AIが何をしようとしているかを読む練習になる

特に2つ目が、初期に確認を切ってはいけない理由です。「何を任せてよいか」の勘は、確認プロンプトを読むことでしか育ちません。面倒に感じ始めた頃には、勘が育っているので線引きの判断ができるようになっています。

許可の与え方は3段階

実用的なのは3段目です。「毎回聞かれてうんざりする操作」を1つずつ許可リストへ入れていくのが、無理のない育て方になります。最初から完璧な設定を作ろうとしないでください。

設定作業そのものはClaude Codeに頼めます。「テストの実行はいちいち聞かないようにして」と伝えれば、該当する設定を追加してくれます。

自動承認してよい操作・だめな操作

判断基準は「間違っていた場合、取り消せるか」の一点です。gitで戻せる範囲の変更は自動承認して構いません。取り消せない操作（削除、送信、外部への反映）だけは、面倒でも確認を残してください。

危険な操作を機械的に止める

許可の設定は「何を通すか」の話ですが、逆方向、つまり「何を絶対に通さないか」も設定できます。

これはhooksの役割です。コマンド実行の直前に検査を挟み、条件に合えば止めます。許可リストと組み合わせると、次のような構成になります。

• 許可リスト──日常的な操作を通して、確認の手間をなくす
• hooksのブロック──本番への操作や削除系を、許可設定に関わらず止める
• プランモード──大きな変更の前に、人が計画を確認する（解説）

この3層があると、普段は快適で、危ない時だけ止まる状態が作れます。確認プロンプトを全部残すのは安全ですが、実際には「読まずにEnterを押す」ようになるので、かえって危険になります。

チームで設定を共有する

設定はプロジェクト単位で共有できます。リポジトリに含めれば、全員が同じ許可範囲で作業できます。

共有する場合の注意は2つです。個人の好みの設定と、組織として守らせたい設定を分けること。そしてブロック条件は事前に合意を取ること。知らないうちに自分の操作が止められる状態は、単純に摩擦を生みます。

会社での導入では、この設定を「AI利用ルールの実装」として扱えます。文書で「気をつける」と決めるより、設定で機械的に守らせる方が確実です（法人導入の整理）。