Claude Code の社内ルールの作り方【2026年10月】— フォルダ・コマンド・秘密情報を settings と CLAUDE.md で線引きする

Claude Code をひとりが試す段階から、チームで使う段階に進むと、「どのフォルダを触ってよいか」「どのコマンドを許すか」「秘密情報をどう守るか」を口頭の申し合わせではなく、ファイルに落とす必要が出てきます。ここで多いのが、全部を CLAUDE.md に文章で書いてしまい、守られたり守られなかったりする状態です。

この記事では、Claude Code の公式ドキュメント（2026年10月時点）だけを出典に、社内ルールを「文章（CLAUDE.md）」と「設定（settings.json の permissions）」の2層に分けて書く方法を整理します。4つの設定ファイルの使い分け、フォルダ・コマンド・秘密情報の3つの線引き、そのまま使える雛形、セルフチェックリストを付けました。読者は、業務改善・情報システム・Web の担当として、社内の数人〜数十人に Claude Code を配る立場の人を想定しています。

管理者が会社全体に強制する管理設定の配り方は、Claude Code の法人導入ガイドに分けて書きました。この記事は、現場のチームがリポジトリの中で決めるルールに絞ります。

1. ルールは2層に分ける。 「禁止」は settings.json の permissions に書き、「なぜ・どうやって」は CLAUDE.md に書く。公式ドキュメントは CLAUDE.md を「文脈であって強制される設定ではない」と明記している
2. チーム共通は .claude/settings.json、個人の例外は .claude/settings.local.json。 同じリストはファイル間で結合され、どこかの deny はどこの allow でも外せない
3. フォルダは Read(...) と Edit(...)、コマンドは Bash(...) のルールで線を引く。 Read の deny は同じパスへの Edit・Write も止める
4. 秘密情報は3重に守る。 .env 等の Read deny、サンドボックスの credentials、環境変数の扱いを決める
5. CLAUDE.md は短く、具体的に。 目安は200行未満。設定で止められることを文章で繰り返さず、判断に迷う場面の「こうする」を書く

最初に押さえるべき事実は1つです。CLAUDE.md の指示は Claude が読んで従おうとする「文脈」で、settings.json の権限ルールは Claude Code 本体が「強制」するものです。公式ドキュメントは、権限ルールについて「Claude Code が適用するもので、モデルが適用するものではない」と書き、プロンプトや CLAUDE.md の指示は「Claude が何を試みるかを形づくるが、Claude Code が何を許すかは変えない」と明記しています。

※ 出典: Claude Code Docs — Configure permissions（取得 2026-10）

同じ考え方は、CLAUDE.md の公式ページにも「どんな決定をしても動作を止めたいなら PreToolUse フックを使う」という形で書かれています。社内ルールを設計するときは、決めたいことを次の表で2つに仕分けるところから始めます。

※ 出典: Claude Code Docs — How Claude remembers your project（取得 2026-10）

公式ページは、組織向けに「ツール・コマンド・パスの禁止は管理設定の permissions.deny、コードの書き方やデータの扱いの注意は CLAUDE.md」という分担表も載せています。チーム単位でも同じ分担で考えると迷いません。

Claude Code は4つの設定ファイルを読みます。チームのルールを置く場所を間違えると、「自分の環境では効くのに同僚の環境では効かない」が起きます。

※ 出典: Claude Code Docs — Settings files and precedence（取得 2026-10）

運用で効く仕様が4つあります。

• 同じキーのリストは結合される。 permissions.allow や permissions.deny を複数のファイルに書くと、どれか1つが選ばれるのではなく、全部が足し合わされます
• deny はどの階層でも勝つ。 ユーザー設定で allow していてもプロジェクト設定で deny していれば止まり、その逆も同じです。deny はどの階層のものも allow より先に評価されます
• プロジェクトの allow は「信頼」の後で効く。 .claude/settings.json の allow ルールと additionalDirectories は、各メンバーがそのフォルダの信頼ダイアログを承認してから有効になります。deny と ask は承認前から効きます
• defaultMode の auto と bypassPermissions はプロジェクト設定からは効かない。 ユーザー設定か管理設定に置くか、起動時のフラグで渡します

.claude/settings.local.json は、確認ダイアログで「今後は聞かない」を選んだときに Claude Code が自動で書き込むファイルでもあります。Claude Code が作った場合は git の除外対象に自動で追加されますが、手で作った場合は自分で .gitignore に足す必要があります。

Claude Code は起動したフォルダとその下を作業ディレクトリとして扱い、そこから外のファイルを読み書きするときは確認を出します（Manual モードの場合）。この境界は「確認」であって「遮断」ではないので、承認した Bash コマンドはユーザー権限で届く場所ならどこにでも書けます。

※ 出典: Claude Code Docs — Security（取得 2026-10）

フォルダの線引きは、Read(...) と Edit(...) のルールで書きます。パスの書き方は4種類あり、先頭の記号で基準が変わります。

※ 出典: Claude Code Docs — Configure permissions（取得 2026-10）

間違えやすい点を3つ挙げます。

• /Users/alice/file のような1本スラッシュは絶対パスではなく、設定ファイルの出所が基準になります。絶対パスは // で始めます
• ファイル名だけの Read(.env) は、どの深さの .env にも一致します（Read(**/.env) と同じ）。親フォルダや別プロジェクトの .env には届きません
• deny・ask ルールの Read(secrets/**) は、どの深さにある secrets フォルダにも一致します。allow ルールの Edit(src/**) は直下の src だけに一致し、どの深さでも許したいなら Edit(**/src/**) と書きます

Read の deny は、同じパスへの Edit・Write（新規作成を含む）も止めます。NotebookEdit だけは対象外なので、絶対に変えさせたくないパスには Edit の deny も足します。一方で、Read・Edit のルールが効くのは Claude の組み込みツールと、cat・head・tail・sed・tee のように Claude Code が認識する Bash のファイル操作、リダイレクトの対象までです。grep -r のようにファイル名を指定しない読み方や、Python・Node のスクリプトが自分で開くファイルには効きません。OS レベルで全プロセスに効かせたいなら、サンドボックスを有効にします。

作業ディレクトリの外に「読んでよい共有フォルダ」があるなら、permissions.additionalDirectories に追加します。追加したフォルダはファイルの読み書きだけが広がり、そこにある .claude/ の設定やスキルは読み込まれません。逆に、作業ディレクトリの外をどのモードでも読ませたくないときは permissions.blockReadsOutsideWorkingDirectories を true にします。この値はどの階層に書いても true が優先されます。

Bash のルールは Bash(コマンドの形) で書き、* が任意の文字列（空白を含む）に一致します。* のない形は完全一致です。git log * のように、サブコマンドの後ろに * を置くのが基本で、git * main のように前に置くと git -c core.fsmonitor=<スクリプト> diff main まで一致してしまうため起動時に警告が出ます。

※ 出典: Claude Code Docs — Configure permissions（取得 2026-10）

評価の順番は「deny → ask → allow」で、最初に一致したルールで決まります。Bash(aws *) を deny に書けば、Bash(aws s3 ls) を allow に書いていても止まります。allow で deny の例外を作ることはできません。

複合コマンドの扱いも決まっています。&&・||・;・|・改行などで区切られた各部分に、ルールがそれぞれ一致する必要があります。Bash(npm *) を allow にしても npm test && rm -rf build の後半は通りません。逆に deny と ask は、サブシェルや $(...) の中、for ループの本体に入っている部分にも一致します。timeout・time・nice・nohup・stdbuf のような決まった前置きは剥がして照合されるので、Bash(npm test *) は timeout 30 npm test にも一致します。

ここで一番大事なのは、Bash のルールは「Claude が書いたコマンド文字列」との一致であって、プログラムそのものの境界ではないという点です。

※ 出典: Claude Code Docs — Configure permissions（取得 2026-10）

右の列を止めたいなら、コマンド文字列に依存しない層が要ります。ファイルとネットワークはサンドボックス、コマンドの中身を自分のロジックで検査したいなら PreToolUse フックです（後述）。

なお、ls・cat・echo・pwd・head・tail・grep・find・wc・which・diff・stat・du・cd と読み取り専用の git は、組み込みの「読み取り専用コマンド」としてどのモードでも確認なしに動きます。この一覧は変更できませんが、特定のコマンドに確認を出したいなら ask か deny のルールを足せば上書きできます。curl・wget のように外から取得するコマンドは既定では自動承認されず、止めたいなら permissions.deny に入れます。

秘密情報の守り方は、3つの層を重ねます。

※ 出典: Claude Code Docs — Sandboxing（取得 2026-10）

権限ルールだけで止まらない理由は、線引き1で書いたとおり、スクリプトが自分で開くファイルには Read の deny が効かないからです。サンドボックスの既定は、書き込みが「作業ディレクトリ・ユーザーごとの一時ディレクトリ・追加したディレクトリ」に限られる一方、読み取りは ~/.ssh や ~/.aws/credentials のような認証情報ファイルを含めて「マシンの大半」に届きます。環境変数も、Claude Code の環境にある秘密情報を含めてそのまま引き継がれます。つまり、サンドボックスを有効にしただけでは秘密情報は守られず、credentials の設定で明示的に deny する必要があります。

公式ドキュメントの例は、AWS の認証情報ファイルと SSH ディレクトリの読み取りを拒否し、GITHUB_TOKEN と NPM_TOKEN をサンドボックス内のコマンドの環境から外す形です。社内ルールとしては、「秘密情報は .env と secrets/ にだけ置く」「それらは Read deny と credentials の両方に載せる」「新しい秘密情報を増やしたら両方を更新する」の3点を決めておくと、設定が追いつかない状態を防げます。

設定で禁止を書き終えたら、CLAUDE.md には「なぜ」と「どうやって」を書きます。公式ドキュメントの指針は次の3点です。

• 具体的に書く。 「コードを適切に整形する」ではなく「インデントは2スペース」、「変更をテストする」ではなく「コミット前に npm test を実行する」
• 短く保つ。 1ファイル200行未満が目安。長いほど文脈を消費し、従われにくくなる。一部のフォルダだけに関係する指示は .claude/rules/ のパス指定ルールに移す
• 矛盾を残さない。 2つの指示が食い違うと、Claude はどちらかを任意に選ぶ。/doctor prompt-audit で古い指示や矛盾を点検できる

※ 出典: Claude Code Docs — How Claude remembers your project（取得 2026-10）

置き場所は4か所あり、広い範囲から順に読み込まれます。

※ 出典: Claude Code Docs — How Claude remembers your project（取得 2026-10）

社内ルールの観点で、CLAUDE.md に書かないほうがよいものも決めておきます。

1. 設定で止めている禁止事項の繰り返し（「.env を読むな」など）。設定が正で、CLAUDE.md には理由と代替手順だけを書く
2. コードから分かること（ディレクトリ構成・依存一覧）。文脈を消費するだけで、/doctor の点検でも削る対象になる
3. 特定の作業でしか使わない長い手順。スキルに分けて必要なときだけ読ませる

社内ルールの分担表と設定の雛形を自分たちで組む場合の進め方は、企業向けの有料の実務書にもまとめています。

業務自動化のリポジトリ（集計スクリプト・レポート生成・社内ツールの保守）を想定した雛形です。パスやコマンドは自社の構成に合わせて置き換えてください。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(python -m pytest *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(rm *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./secrets/**)",
      "Edit(./data/raw/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

設定ファイルは厳密な JSON で、// のコメントや末尾のカンマがあると起動時に Settings Error になります。$schema の行を入れておくと、VS Code などの編集画面で補完と検証が効きます。保存したら /status で読み込まれたファイルを確認し、claude doctor で捨てられたエントリが無いかを見ます。

※ 出典: Claude Code Docs — Settings files and precedence（取得 2026-10）

allowUnsandboxedCommands を false にすると、サンドボックス内で失敗したコマンドをサンドボックス外で再実行する逃げ道が閉じます。サンドボックスは macOS・Linux・WSL2 で動き、ネイティブ Windows では動かない点に注意してください。

CLAUDE.md の雛形は次のとおりです。禁止の列挙ではなく、「この作業ではこうする」を書きます。

# このリポジトリでの作業の約束

## 前提
- 月次集計と社内レポート生成のリポジトリ。本番データは data/raw/ にあり、読み取り専用
- 秘密情報は .env と secrets/ にだけ置く（設定で読み取りを止めている。別の場所に複製しない）

## 作業の進め方
- 集計ロジックを変えるときは、先に tests/ にテストを足してから実装する
- 外部 API を呼ぶコードを書くときは、呼び先と送る項目を PR の説明に書く
- 判断に迷う操作（削除・一括更新・外部送信）は、実行せずに手順を提案して止まる

## 報告の形
- 変更したファイルと、確認した手順（実行したコマンド）を最後に列挙する
- 数値を出すときは、元データのファイル名と行数を添える

パス限定の指示が必要なら、.claude/rules/ にファイルを置き、frontmatter の paths で対象を絞ります。paths の無いルールは起動時に読み込まれ、paths のあるルールは一致するファイルを Claude が読み書きしたときに読み込まれます。

---
paths:
  - "scripts/export/**/*.py"
---

# 外部送信スクリプトの約束
- 送信先のホストと項目は config/export.yaml に書く。コードに直書きしない
- 送信前に件数と合計を標準出力に出し、人が確認できるようにする

権限ルールで表現できない条件は、PreToolUse フックで検査します。フックはツール呼び出しの前に実行され、終了コード 2 で止めると、標準エラー出力の内容が Claude に理由として渡ります。フックによる遮断は allow ルールより優先され、逆に deny ルールはフックが allow を返しても適用されます。

#!/bin/bash
# .claude/hooks/check-command.sh — 標準入力の JSON からコマンドを取り出して検査する
input=$(cat)
command=$(jq -r '.tool_input.command' <<<"$input")

if [[ "$command" == *"--force"* ]]; then
  echo "Blocked: --force 付きのコマンドは社内ルールで禁止です" >&2
  exit 2
fi
exit 0

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-command.sh",
            "args": [],
            "onFailure": "block"
          }
        ]
      }
    ]
  }
}

※ 出典: Claude Code Docs — Hooks reference（取得 2026-10）

onFailure を "block" にしておくと、スクリプトのパス間違いやクラッシュで検査が素通りすることを防げます（既定は "continue" で、失敗すると操作はそのまま進みます）。

もう1つ、社内ルールで効くのが ConfigChange フックです。セッション中に設定ファイルが変わったときに実行され、user_settings・project_settings・local_settings・policy_settings・skills のどれが変わったかを source で受け取れます。記録を残すだけでなく、終了コード 2 や {"decision": "block"} で変更の適用を止められます。ただし管理設定（policy_settings）の変更は止められません。公式のセキュリティのページも、チーム向けの対策として「ConfigChange フックで設定変更を監査または遮断する」を挙げています。

サンドボックスを有効にすると、作業ディレクトリの中でも .claude の設定ファイル・.claude/hooks・.claude/skills・.claude/agents・.mcp.json、シェルの起動ファイル（.bashrc 等）、.git の中の hooks と config は書き込み拒否になります。これは「コマンドが自分で権限を広げる」ことを防ぐためで、allowWrite や Edit の allow ルールでも解除できません。

1. 決めたいことを仕分ける。 前提の表を使い、「禁止」「確認」「方針」の3列に分ける。禁止と確認は設定、方針は CLAUDE.md
2. .claude/settings.json を書いてコミットする。 deny から書き、allow は「確認疲れを起こすコマンド」だけに絞る。/status で読み込みを確認する
3. 各メンバーが信頼ダイアログを承認する。 allow と additionalDirectories は承認後に効く。承認前は deny と ask だけが効いている状態なので、最初の1週間は「確認が多い」と感じて正常
4. CLAUDE.md を書く。 200行未満。/context で Memory files に載っていることを確認する。パス限定の指示は .claude/rules/ に分ける
5. フックとサンドボックスを足す。 ConfigChange の記録フックを先に入れ、設定が誰にいつ変えられたかを追えるようにしてから、PreToolUse の検査とサンドボックスを有効にする

• 禁止したいことが CLAUDE.md ではなく permissions.deny に書かれている
• チーム共通のルールは .claude/settings.json にあり、git にコミットされている
• .claude/settings.local.json が git の管理外になっている（手で作ったなら .gitignore に入れた）
• .env・.env.*・secrets/ の Read deny がある
• 変えさせたくないフォルダに Edit の deny がある
• curl・wget の扱い（deny か ask か）を決めてある
• git push・rm のような取り消しにくい操作が ask に入っている
• disableBypassPermissionsMode が "disable" になっている
• サンドボックスを使うなら credentials に秘密情報のファイルと環境変数を載せた
• CLAUDE.md は200行未満で、設定で止めている禁止の繰り返しが無い
• /status と /context で、設定と CLAUDE.md が読み込まれていることを確認した
• 設定変更を記録する ConfigChange フックがある

1. CLAUDE.md に禁止を書いて安心する。 文脈であって強制ではないので、守られたり守られなかったりする。禁止は設定へ
2. 個人の settings.local.json にチームのルールを書く。 自分の環境でしか効かない。共有ルールは .claude/settings.json にコミットする
3. Bash(curl *) の deny で通信を閉じたつもりになる。 /usr/bin/curl や sh -c には一致しない。OS レベルで閉じるならサンドボックスのネットワーク隔離
4. サンドボックスを有効にして秘密情報が守られたと思う。 既定の読み取り範囲は認証情報ファイルを含む。credentials の deny を明示する
5. allow を広げすぎて確認が消える。 確認は「人が読む最後の関所」。読み取り系・検査系だけを allow にし、破壊・外部送信・秘密情報は確認か禁止に残す

• Configure permissions — ルールの構文、評価順、Bash と Read/Edit の一致規則
• Settings files and precedence — 4つの設定ファイルと優先順位、リストの結合
• How Claude remembers your project — CLAUDE.md の置き場所、書き方、.claude/rules/
• Security — 作業ディレクトリの境界、プロンプトインジェクション対策、チーム向けの推奨事項
• Sandboxing — 既定の読み書き範囲、credentials、保護されるパス
• Hooks reference — PreToolUse・ConfigChange の入力と判定

なりません。公式ドキュメントは、CLAUDE.md を「文脈であって強制される設定ではない」と明記しています。読ませたくないファイルは settings.json の permissions.deny に Read(./.env) のように書きます。deny ルールは Claude Code 本体が適用するので、Claude がどう判断しても覆りません。CLAUDE.md には「なぜ触らないか」「代わりにどうするか」を書き、禁止そのものは設定に置く、という分担が基本です。

チーム共通のルールはリポジトリの .claude/settings.json に書いてコミットします。個人の例外は .claude/settings.local.json に書きます。このファイルは Claude Code が作ったときは自動で git の除外対象になり、手で作った場合は自分で .gitignore に足します。同じキーのリスト（allow・deny など）はファイル間で上書きではなく結合されるので、個人の allow がチームの deny を外すことはありません。

完全には止まりません。Bash のルールはコマンド文字列との一致なので、/usr/bin/curl や sh -c 'curl …' のような別の書き方には一致しないと公式ドキュメントが明記しています。コマンドの文字列に依存しない制限が必要なら、サンドボックスのネットワーク隔離を併用します。サンドボックスは OS レベルで効き、許可ドメインは空の状態から始まります。

対策は2つあります。1つはサンドボックスで、有効にすると .claude の設定ファイルや hooks、.mcp.json は作業フォルダの中でも書き込み拒否になります。もう1つは ConfigChange フックで、設定ファイルが変わったときに記録したり、終了コード 2 で変更を無効にしたりできます。管理設定（policy_settings）の変更だけはフックで止められない設計です。

まず、いまのリポジトリで「禁止したいこと」を5つ書き出し、それが CLAUDE.md に文章で書かれているか、.claude/settings.json の deny に書かれているかを確かめてください。文章だけなら、この記事の雛形を元に deny へ移し、/status で読み込みを確認します。それだけで「守られたり守られなかったり」の状態は解消します。

どの操作を確認に残すか、サンドボックスをどの端末から有効にするか、既存の CLAUDE.md をどう短くするかを相談したい場合は、お問い合わせから現在の構成をお知らせください。契約前提ではありません。Claude 導入支援の全体像はClaude 導入支援ハブに、既にある CLAUDE.md・hooks・permissions の構成が安全かを確かめる無料の診断はハーネス健全度診断にまとめています。

• 2026-10-16: 初版公開

• Claude Code の法人導入ガイド【2026年9月】— 管理者が先に決める設定配布・権限・利用上限・監査
• ハーネスエンジニアリング実践ガイド — Claude Code を「育てる」ための 5 つの型とテンプレ
• Claude Code を決まった時刻に動かす【2026年9月】— ヘッドレスモードの定期実行と、無人で許す操作の決め方
• Claude Code のサブエージェントで作業を分ける【2026年10月】— 調べる・書く・点検するを別々に任せる設定と、任せすぎの失敗例
• 生成 AI の社内利用ガイドラインの作り方【2026年9月】— AI事業者ガイドライン第1.2版をそのまま使える規程テンプレに落とす
• Claude 導入支援ハブ