無料相談する

カテゴリー / 導入・研修

Claude Code運用ルールの作り方｜CLAUDE.mdと権限設定の分担

NO WAVE公開 更新 読了目安 15分

この記事の目次

Claude Codeの運用ルールは、置き場所を2つに分けて作ると効きます。「この現場ではこうしてほしい」という作法はCLAUDE.mdに書き、「起きたら取り返しがつかないこと」はsettings.jsonの権限管理ルール（allow / ask / deny）やフックで止めます。公式ドキュメントはCLAUDE.mdを「context, not enforced configuration」（強制力のある設定ではなく文脈）と説明しており、CLAUDE.mdに「本番にpushしない」と書いただけでは操作は止まりません。チームではCLAUDE.mdと .claude/settings.json をリポジトリにコミットして配り、個人の例外は各自のローカルファイルに置きます。

Claude Codeそのものの説明はClaude Codeとは？非エンジニアのための入門ガイドにまとめています。

Claude Codeの運用ルールはどこに書けば守られるのか

最初に決めるのは、ルールの中身より「強制したいかどうか」です。公式の設定トラブル解説ページ（Debug your configuration）は、CLAUDE.mdを「we do it this way here」（ここではこうする）に使い、セキュリティ上の安全境界や決して起きてはいけないことには、助言ではなく確実な制止が要るので権限やフックを使う、と整理しています。権限ルールのページにも、権限ルールはモデルではなくClaude Code本体が強制するもので、CLAUDE.mdの指示はClaude Codeが何を許可するかを変えない、と書かれています。

ルールの性質 置き場所 効き方
規約、テストのタイミング、ファイルの置き場所など「やり方」 CLAUDE.md（または .claude/rules/） Claudeが読んで従う。強制ではない
特定のコマンドやファイルを禁止・確認制にしたい settings.json の permissions Claude Code本体が実行前に判定する
文字列一致では表しきれない条件で止めたい PreToolUse フック スクリプトが判定し、終了コード2でブロックできる
組織として誰にも上書きさせたくない managed settings ユーザーやプロジェクトの設定では上書きできない

迷ったら「Claudeがこのルールを読み落としたら、取り返しがつくか」で決めます。つくならCLAUDE.md、つかないなら権限ルールかフックです。

「やってはいけない操作」はsettings.jsonでどう止めるのか

権限ルールはConfigure permissionsのとおり、settings.jsonの permissions に、allow（確認なしで実行）、ask（確認を求める）、deny（実行させない）で書きます。公式の設定ページには、lintとテストを確認なしで走らせ、.env を読ませない例があります。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

書く前に押さえたい仕組みは3つです。

  • 評価はdeny、ask、allowの順に固定です。 最初に一致したものが結果を決め、具体性は順序を変えません。Bash(aws *) をdenyにすると、Bash(aws s3 ls) をallowに書いても実行されません。「基本は禁止、この1つだけ許可」とは書けません。
  • 複合コマンドの中でもdenyとaskは効きます。 サブシェルやコマンド置換、for ループの中のサブコマンドにも一致します。
  • ls、cat、grep などの読み取り専用コマンドは確認なしで実行されます。 この一覧は変更できないので、確認を挟みたいならaskかdenyを足します。

顧客データや認証情報のファイルは Read のdenyで守ります（公式の例は Read(./.env) や Read(./secrets/**)）。Read のdenyは同じパスへのEdit・Writeと新規作成も止めます。.claudeignore は公式が「it has no effect」と明記しているので、中身は Read のdenyへ移します。

権限ルールだけでは止まらないもの

公式が認める限界は2つあります。1つ目に、Bashルールはコマンドの文字列に一致するもので、プログラムそのものを囲う境界ではありません。Bash(rm *) のdenyは /bin/rm や find -delete を止めない、という例が公式に載っており、確実に止めるならPreToolUseフックかサンドボックスを使うよう案内されています。2つ目に、ReadとEditのdenyは、PythonやNodeのスクリプトが内部で開くファイルには効きません。すべてのプロセスをOSレベルで止めるにはサンドボックスを有効にします。

重要度の高い禁止事項だけをフックやサンドボックスに上げる、という段階の付け方が現実的です。設定方法はClaude Code hooksの仕組みと設定手順とClaude Codeのサンドボックスで制御できる範囲で扱っています。

CLAUDE.mdにはどんな運用ルールを書けばよいのか

CLAUDE.mdは強制できませんが、Claudeが迷う場面で方向を決めます。公式のCLAUDE.mdのページが挙げる書き方の要点は3つです。

  • 検証できる具体さで書く。 公式は「Test your changes」ではなく「Run npm test before committing」と書くよう勧めています。「気をつける」のような指示は、守ったかどうかを判定できません。
  • 1ファイル200行未満を目安にする。 長いほどコンテキストを使い、遵守率が下がります。一部のコードにだけ関係する指示は .claude/rules/ に分け、paths で対象ファイルを絞ると、該当ファイルを扱うときだけ読み込まれます。
  • 矛盾を残さない。 矛盾する2つの指示があると、Claudeがどちらかを任意に選ぶことがあります。

運用ルールとして書くと効きやすいのは、コミット前に実行するテストやlintのコマンド名、触る前に相談してほしいディレクトリ、外部サービスへ送信する前に内容を提示して確認を取ること、顧客名や個人情報を出力に含めないこと、などです。後半の「情報を外に出さない」系は、CLAUDE.mdで方向付けしたうえで、送信に使うコマンドやツールを権限ルールのaskに入れておくと、Claudeが読み落としても実行前に人の確認が入ります。

書き方の型はCLAUDE.mdの書き方にまとめています。

チームで同じ運用ルールを共有するにはどのファイルを使うのか

共有するファイルと個人用のファイルを分けます。

用途 指示 設定
チームで共有 ./CLAUDE.md または ./.claude/CLAUDE.md .claude/settings.json
自分だけ・このプロジェクト ./CLAUDE.local.md（.gitignore に追加） .claude/settings.local.json
自分だけ・全プロジェクト ~/.claude/CLAUDE.md ~/.claude/settings.json

公式の設定ページは、.claude/settings.json をコミットすればクローンした全員が同じ権限・フック・プラグインを得て、個人の例外は各自の .claude/settings.local.json で上書きできると説明しています。.claude/settings.local.json はClaude Codeが作った場合はgitの対象外になりますが、手で作ったら自分で .gitignore に足します。

チーム運用で混乱しやすい仕様は次の4つです。

  • 優先順位は高い順に、managed settings、コマンドライン、.claude/settings.local.json、.claude/settings.json、~/.claude/settings.json。
  • permissions.allow のようなリストは上書きではなく結合されます。 共有ファイルにdenyを入れておけば、個人ファイルのallowでは打ち消せません。
  • 共有ファイルのallowは、ワークスペースの信頼を承認した後にだけ効きます。 denyとaskは制限するだけなので影響を受けません。「共有したallowが効かない」と言われたら、信頼ダイアログを承認したかを確認します。
  • Bashコマンドの実行確認で「Yes, and don’t ask again」を選ぶと、allowルールが .claude/settings.local.json に保存されます。 繰り返すと個人ファイルにallowが溜まり、共有ルールは厳しめでも手元では広く許可されている、という状態になりえます。

書式の全体像はClaude Codeのsettings.json｜配置場所・優先順位と権限の設定で説明しています。

組織として上書きさせない運用ルールはどう配るのか

組織として誰にも変えさせたくないルールは、managed settingsで配ります。公式の権限ページによれば、managed settingsはユーザーやプロジェクトの設定で上書きできません（一部のセキュリティ上のキーを除く）。配布経路は、claude.aiの管理コンソールなどから取得するサーバー管理設定、MDMやOSレベルのポリシー、システムディレクトリの managed-settings.json です。

運用ルールを固めるときに使う主な設定は次のとおりです。

  • permissions.deny: どこかのレベルでdenyされたツールは、他のどのレベルでも許可できません。managed settingsのdenyは起動時の --allowedTools でも上書きできません。
  • permissions.disableBypassPermissionsMode / permissions.disableAutoMode: "disable" にすると、bypassPermissionsモードやautoモードを使えなくします。上書きされないmanaged settingsに置いたときに最も役立つと公式は書いています。
  • allowManagedPermissionRulesOnly: managed settingsだけを権限ルールの供給元にし、プロジェクトや個人のallowを効かせなくします。

組織全体への「やり方」の指示は、managed policyのCLAUDE.mdで配れます（macOSは /Library/Application Support/ClaudeCode/CLAUDE.md、Linux / WSLは /etc/claude-code/CLAUDE.md、Windowsは C:\Program Files\ClaudeCode\CLAUDE.md）。公式の対応表も、ツールやファイルパスのブロックは permissions.deny、コードスタイルやデータ取り扱いの注意喚起はmanaged CLAUDE.md、と分けています。

社内審査の論点はClaude Codeのセキュリティを企業で検討する際の論点で扱っています。

権限モードは運用ルールとどう組み合わせるのか

権限モードは確認をどれだけ挟むかの全体設定で、起動時のモードは defaultMode で決められます（Configure permissions）。運用ルールとして決めておきたいのは bypassPermissions（確認を省略するモード）の扱いです。公式は、このモードを「Claude Codeが損害を与えられないコンテナやVMのような隔離環境」だけで使うよう警告しています。業務端末で使わせないなら、前の章の permissions.disableBypassPermissionsMode で止めておきます。

なお .git や .claude などの保護パスへの書き込みは、bypassPermissionsなど一部の例外を除いて自動承認されません。各モードの選び方はClaude Codeの権限モードとは？種類と選び方を参照してください。

運用ルールが効いていないときはどこを確認するのか

まずルールが読み込まれているかを確かめ、次に書き方を疑います。公式の設定トラブル解説ページ（Debug your configuration）が挙げる確認コマンドは次のとおりです。

確認したいこと コマンド
CLAUDE.mdやルールがコンテキストに入っているか /context
どのCLAUDE.mdがどこにあるか /memory
今効いているallow / denyルール /permissions
登録されているフック /hooks
有効な設定の出所、managed settingsが効いているか /status

/permissions は各ルールがどのsettings.jsonから来たかも表示するので、共有ファイルと個人ファイルの重なりを確認できます。

CLAUDE.mdが守られない場合。 サブディレクトリのCLAUDE.mdは必要になった時点で読み込まれるため、開始直後の /context には出ません。それ以外で読み込まれるはずのファイルが出ていなければ、置き場所などを確認します。読み込まれているのに守られないなら、公式は書き方の問題である可能性が高いとしています。曖昧さ、矛盾、長さを疑います。

設定が反映されない場合。 settings.jsonは厳密なJSONで、// コメントや末尾のカンマは構文エラーになり、次回起動時にSettings Errorとして報告されます。セッションを始めずに無効な設定ファイルを探すには、ターミナルで次を実行します。

claude doctor

フックが動かない場合。 /hooks に出なければ読み込まれていません。よくある原因は、matcher を配列で書いている（"Edit|Write" のように1つの文字列で書く）ことと、フックを単独ファイルに書いている（settings.jsonの "hooks" キーに書く）ことです。出ているのに動かないなら、次のコマンドで起動し、フックが反応するはずのツール操作を実行します。各イベント、照合されたmatcher、フックの終了コードと出力がデバッグログに残ります。

claude --debug

denyしたのに実行された場合。 Bashルールは文字列一致なので、別の形で呼ばれたコマンドには一致しません。確実に止める操作はPreToolUseフックかサンドボックスへ移します。

運用ルールはいつ、何を見直せばよいのか

公式のセキュリティページは、/permissions での定期的な監査、承認済みの権限設定のバージョン管理での共有、managed settingsによる組織標準の強制を挙げています。セッション中の設定変更を記録・ブロックしたい場合はConfigChangeフックが使えます。見直しでは次の4点を確認します。

  • 個人の .claude/settings.local.json に意図しないallowが溜まっていないか
  • CLAUDE.mdが長くなりすぎていないか、古い指示や矛盾が残っていないか
  • CLAUDE.mdに「〜しない」と書いただけで、実際には止まっていない重要な操作がないか
  • denyで止めたつもりの操作が、別の呼び方で実行できてしまわないか

ヒヤリとした出来事があったら、「CLAUDE.mdで伝えれば足りたのか、強制が必要だったのか」を問い直すと、ルールが正しい置き場所に収まっていきます。

ここで挙げたコマンド名と設定キーは、2026年10月19日に取得した公式ドキュメント（Configure permissions、Settings files and precedence）などと照合した時点の記述です。導入時には現行の仕様をこの2ページで確認してください。

CONTINUE THE SESSION

関連記事