結論から書きます。Claude Code に「してほしくないこと」は、指示文（プロンプトや CLAUDE.md）に書くだけでなく、権限ルール（permission rules）として設定しておくのが基本です。ただし、権限ルールにも効かない範囲があることが公式ドキュメントに明記されています。導入前に、その範囲まで把握しておくことをおすすめします。
本稿は、Claude Code の公式ドキュメント「Configure permissions」の記載をもとにしています。機能の内容は今後のバージョンで変わる可能性があるため、実際に設定するときは最新のドキュメントをご確認ください。
「お願い」と「設定」は別のもの
ドキュメントには、権限ルールはモデルではなく Claude Code 自体が強制するもので、プロンプトや CLAUDE.md の指示は Claude が何をしようとするかに影響するものの、Claude Code が何を許可するかは変えない、と書かれています。アクセスを許可・取り消しするには、/permissions や権限ルール、権限モード、PreToolUse フックを使うよう案内されています。
医療・ヘルスケアのシステム開発では、「本番環境には触れない」「秘密鍵は読まない」といった約束事が多くあります。こうした約束事を指示文に書くだけで済ませず、設定として残しておくことが出発点になります。
3種類のルールと評価の順番
権限ルールには3種類あります。
- Allow：確認なしでツールを使わせる
- Ask：使うたびに確認を求める
- Deny：ツールの使用を止める
ルールは deny、ask、allow の順に評価され、この順で最初に一致したものが結果を決めます。ルールがどれだけ細かく書かれているかは、この順番に影響しません。たとえば Bash(aws *) という広い deny ルールがあると、Bash(aws s3 ls) という狭い allow ルールに一致する呼び出しも止まります。allow ルールで deny ルールに例外を作ることはできない、とされています。
ドキュメントには、npm スクリプトと git commit は確認なしで実行させ、git push で始まるコマンドは拒否する設定例が載っています。
{ "permissions": { "allow": [ "Bash(npm run *)", "Bash(git commit *)" ], "deny": [ "Bash(git push *)" ] } }
ただし同じ箇所に、git -C . push のように別の書き方をした push には一致しない、とも書かれています。これは次の節で扱う「効かない範囲」につながります。
秘密の情報が入ったファイルを読ませない
ファイルの読み取りを止めるには、Read(./.env) や Read(./secrets/**) のような Read の deny ルールを使います。ドキュメントには、プロジェクトに .claudeignore ファイルがあっても効果はないので、その中身を Read の deny ルールに移すよう書かれています。また、Read の deny ルールは同じパスに対する Edit・Write ツールも止める（新しいファイルの作成を含む）とされています。
一方で、効く範囲には限りがあります。ドキュメントによると、Read と Edit の deny ルールが及ぶのは次のものです。
- Claude Code に組み込まれたファイル操作ツール
- Bash の中で Claude Code が認識するファイル操作コマンド（
cat、head、tail、sed、teeなど） > fileや< fileのようなリダイレクトの対象
逆に、ファイル名を指定せずに読むコマンド（そのファイルがあるディレクトリで実行した grep -r pattern . など）や、Python や Node のスクリプトが自分でファイルを開く場合には及ばない、と明記されています。「deny ルールを書いたから、その端末ではもう読まれない」とは考えないほうが安全です。
Bash のルールは「よく使う書き方」を止めるもの
Bash のルールは、Claude が書いたコマンドの文字列に対して照合されます。ドキュメントは、deny や ask のルールは Claude がふだん生成する書き方を対象にするもので、そのプログラムの周りに張られた安全の境界ではない、と説明しています。例として、Bash(rm *) は rm -rf build/ を止めますが、/bin/rm -rf build/ や bash -c 'rm -rf build/' は止めない、と示されています。
コマンドの文字列に頼らない制限としては、次の2つが案内されています。
- サンドボックス：OS のレベルで、シェルコマンドのファイルとネットワークへのアクセスを制限します。対象は Bash、PowerShell、Monitor のコマンドとその子プロセスに限られる、とされています。
- PreToolUse フック：コマンドの全文を自前の処理で点検してから実行させる仕組みです。設定ファイルに書いた PreToolUse フックが allow を返しても、一致する deny ルールは呼び出しを止め、ask ルールは確認を求める、とされています。
ドキュメントは、権限ルールとサンドボックスを補い合う層として併用する（多層防御）よう勧めています。どれか一つで十分と考えず、層を重ねる設計が前提になっています。
組織で使うなら：管理設定と優先順位
組織で導入する場合は、管理者が配布する管理設定（managed settings）が使えます。ドキュメントによると、管理設定のルールはコマンドライン引数を含むほかのどの階層からも上書きできません。また、どこかの階層で deny されたツールは、ほかの階層で allow できないとされています。ユーザー設定で allow、プロジェクト設定で deny の場合も、deny が優先されます。
確認を省く強いモードについても記載があります。bypassPermissions モードは確認の大部分を省くため、コンテナや仮想マシンのように隔離された環境でのみ使うよう警告されています。このモードや auto モードを使わせないためには、permissions.disableBypassPermissionsMode や permissions.disableAutoMode を "disable" に設定します。これらは管理設定に置くと上書きされないため、特に有用だとされています。
さらに、リポジトリの .claude/settings.json にある allow ルールは、そのフォルダについてワークスペースの信頼確認を受け入れたあとにだけ適用されます。deny と ask のルールは制限しかしないため、この確認の影響を受けません。外部から受け取ったリポジトリを開くときに関係する点です。
医療・ヘルスケアの開発で使うときの位置づけ
権限ルールは、AI に「どのツールで、どこまで操作させるか」を決める仕組みです。どのデータを開発環境で扱ってよいかを決める仕組みではありません。本稿は、患者情報や従業員の健康情報をこうしたツールに入力する使い方を勧めるものではありません。実データの扱いは、所属する組織の規程、契約、関係する法令に沿って、個別に判断する必要があります。
そのうえで、開発チームとしては次の順で確認しておくと整理しやすくなります。
- 秘密鍵や設定ファイルなど、読ませたくないパスを Read の deny ルールに入れる
- push や削除など、取り消しにくい操作を deny または ask にする
- ルールが及ばない経路（スクリプト経由の読み取り、別の書き方のコマンド）を把握し、サンドボックスやフックを併用するか判断する
- 組織で使う場合は、管理設定で強いモードを使えないようにするか検討する
AI 開発支援ツールの設定やシステム開発の進め方についてのご相談も承っています。お気軽にご相談ください。
この記事は note でも発信しています。