permissions と settings.json の設計。Claude Code の境界をどう引くか

はじめに

Step 5 ハーネス設計シリーズの2本目です。1本目「Claude Code のハーネスとは何か」で、ハーネスは7つの部品でできていると整理しました。本記事ではそのうち、境界を決める部分——permissions と settings.json の設計を扱います。

毎日触る道具なら、やっていいこと・確認してほしいこと・絶対やらないでほしいこと をはっきり言葉にしておく方が、お互いの消耗が減ります。これを Claude に伝える窓口が settings.json の permissions です。

本記事では、(1) settings.json の3つの階層、(2) permissions の3区分（allow / ask / deny）、(3) それらを踏まえた設計の手順、の3点を順に扱います。読み終えたあとには、自分用の settings.json を 最小から組める 感触がつかめるはずです。

permissions と settings.json の関係

ハーネスの7部品のうち、settings.json は 設定の本体 にあたります。1ファイルに、権限の境界（permissions）・自動化の仕掛け（hooks）・外部接続（mcp）など、ハーネスの中身がほぼ全部詰まっています。

本記事で焦点を当てる permissions は、その中の 「Claude にどの操作を許すか」 だけを担当する区画です。家のたとえで言えば、settings.json が家全体の設計図、permissions はそのうち 玄関の鍵まわり にあたります。

以降は permissions の中身を中心に話を進めますが、hooks（次回・3本目）も MCP（既存記事「MCP とは何か」）も、書き場所はすべて同じ settings.json の中、ということだけは押さえておいてください。

境界をどう引くか：3つの態度

permissions を設計するときの態度には、大きく3つあります。

ひとつめは 「全部許可」。インストール直後の素の状態に近く、Claude が何をやるにも確認なしで進みます。最初は楽ですが、取り返しのつかない操作 がうっかり走ったときに止められません。Web 制作で言えば、.htaccess を一切書かずに本番サーバーを置くようなものです。

ふたつめは 「毎回確認」。すべての操作に確認ダイアログが入ります。安全ですが、確認の連打で消耗します。慣れてくると確認画面を流し読みするようになり、結局は一番危ない瞬間にうっかり Yes を押す——という事故が起きやすくなります。

みっつめは 「中間点を設計する」。日常的に走る安全な操作は確認なし、いつもと違う操作だけ確認、危険な操作は問答無用でブロック。これが本記事で目指す姿勢です。最初は厳しめに作って、運用しながら緩めていく のが安全な順番です。

permissions を書く目的は、毎回の確認を減らすことではなく、確認すべきタイミングを正しく残すこと です。ここを取り違えると「確認が出るから煩わしい」と全部許可に倒したくなりますが、それは目的が逆になっています。

permissions の3区分と書き方

permissions は3つの配列でできています。

区分	意味
`allow`	確認なしで実行する
`ask`	実行前に毎回確認を出す
`deny`	実行を拒否する

書き方の基本は、Tool または Tool(対象パターン) の形です。

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Read(~/.zshrc)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(rm *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

ここで覚えておくべき大事な性質が2つあります。

ひとつめは 評価の順序が deny → ask → allow という点。3つの配列に同じ操作が出てきても、deny がいちばん強く効きます。「危険なものを必ず止める」を確実にできるのは、この順序のおかげです。

ふたつめは ワイルドカード が使えること。Bash(npm run *) はすべての npm run で始まるコマンドにマッチします。ファイルパスでは *（同じ階層のみ）と **（深い階層まで）の2種類が使えるので、Read(./secrets/**) のように書くと secrets/ の下のすべてのファイルが対象になります。

パスの書き方は、./path（プロジェクト基準）・/path（同じくプロジェクト基準・スラッシュなしと等価）・//path（絶対パス）・~/path（ホームディレクトリ基準）の4種類。.env のような「プロジェクトの中の特定ファイル」を指したいときは Read(./.env) のように書きます。

仕様の細かい網羅は公式の permissions ページに任せますが、初学者が最初に押さえるべきはここまでです。Tool か Tool(パターン)、* と **、評価は deny 優先——この3つを頭に入れておけば、書き始められます。

settings.json の3階層スコープ

settings.json は 3つの場所 に置けます。

settings.json の3階層スコープ図。User（~/.claude/settings.json、全プロジェクト共通）・Project（.claude/settings.json、案件単位で git 共有）・Local（.claude/settings.local.json、自分のマシンのみ・git に上げない）の重なり関係を示す

それぞれの役割は次のとおりです。

場所	適用範囲	git に上げるか
User	`~/.claude/settings.json` ／あなたの全プロジェクト共通	自分用なので関係なし
Project	`<案件>/.claude/settings.json` ／その案件の中だけ	上げる（チームと共有）
Local	`<案件>/.claude/settings.local.json` ／その案件、かつ自分のマシンだけ	上げない（`.gitignore` で除外）

3つが揃ったときの 配列の合体ルール はとてもシンプルです。同じ allow や deny が複数の場所に書かれていたら、全部つなげて重複を取り除く——置き換えではなく 足し算 で動きます。

具体的には、こう使い分けます。

User：どのプロジェクトでも共通でやってほしい安全策（例：Read(~/.ssh/**) を deny、Bash(curl *) を deny）
Project：その案件特有のルール（例：Bash(npm run test *) を allow、Read(./.env) を deny）
Local：自分のマシンでだけ効かせたい設定（例：個人の検証コマンドの allow、デバッグ用の一時的な許可）

優先順位は Local > Project > User。同じ操作を複数階層で扱うときは、より下の（自分に近い）設定が強く効くと覚えておけば大丈夫です。Web 制作で言えば、.htaccess をディレクトリごとに重ねていく感覚に近いです。深い階層の .htaccess の方が、上位を上書きできるあの感じです。

なお、組織用の Managed という4つ目の階層もありますが、これは個人運用ではまず触れません。「会社が一斉に強制するルール」が必要になったときに、改めて公式ドキュメントを確認するくらいで十分です。

設計の手順：3ステップ

実際に settings.json の permissions を書くときは、順番を守る と迷いません。

Step 1. 絶対やらせたくない操作を `deny` に書く

まず最初は 「事故を起こさないこと」 が優先です。deny から書きます。代表例はこのあたりです。

"deny": [
  "Read(./.env)",
  "Read(./.env.*)",
  "Read(./secrets/**)",
  "Bash(curl *)",
  "Bash(rm -rf *)"
]

.env 系は、API キー流出の事故源として一番ありがちな場所です。curl は外部に情報が出る経路、rm -rf は取り返しがつかない操作の代表。まずこの3系統を塞ぐ ところから始めると、後の設計が安心して進みます。

Step 2. 確認したい操作を `ask` に書く

次に、「自動でやってほしくないけど、自分が判断すれば進めてもいい」 ものを ask に入れます。

"ask": [
  "Bash(git push *)",
  "Bash(rm *)"
]

git push は遠くまで影響が及ぶので、毎回意識的にやる方が良い 操作です。rm は deny に入れるほどではないけれど、確認なしで走るのは怖い、という温度感。自分が止めたい瞬間 を言葉にする作業です。

Step 3. 確認なしで進めたい操作を `allow` に書く

最後に、「日常的に何度も走るので、毎回確認されると消耗する」 操作を allow に入れます。

"allow": [
  "Bash(npm run lint)",
  "Bash(npm run test *)",
  "Bash(git status)",
  "Bash(git diff *)"
]

ここに何を入れるかは、自分の作業内容で変わります。普段使うコマンドを思い出して、繰り返し叩くもの から順に入れていけば、自然と必要なリストになります。

書く順番は deny → ask → allow。これは Claude Code の 評価順 と同じです。書く側もこの順で考えると、頭の整理がぶれません。

ありがちな失敗

ふたつだけ、ありがちな失敗を共有しておきます。

ひとつめは allow から書き始めてしまう こと。「これは安全だから許可、これも安全だから許可」と積み上げていくと、いつの間にか deny を書く気力が尽きます。境界は禁止から作る のが鉄則です。.htaccess で Order allow,deny の順を意識するのと同じ感覚で、まず塞いでから許す順で進めます。

ふたつめは Local と Project の使い分けを間違える こと。チームで共有したい設定を settings.local.json に書いてしまうと、自分のマシンでしか効きません。逆に、自分専用のデバッグ用許可を settings.json に書くと、git でチーム全員に配ってしまいます。「みんなに配るか、自分用か」 を毎回ひと呼吸おいて判断するクセをつけると事故が減ります。

まとめと次回

要点を振り返ります。

permissions は settings.json の中の 境界を決める区画
3区分は allow / ask / deny、評価順は deny → ask → allow
書式は Tool または Tool(パターン)、ワイルドカードは * と **
settings.json の置き場所は User / Project / Local の3階層、Local が一番強い
設計手順は deny → ask → allow の順。禁止から作る のが安全
Local と Project の使い分けは「みんなに配るか、自分用か」で判断

次回（3本目）は、ハーネスのもう一本の柱——「hooks による自動化設計」を扱います。permissions が「やっていいかの境界」を決める道具なら、hooks は「特定のタイミングで自動的に何かを起こす」道具です。境界の次は仕掛け、という順序で読むと、ハーネス設計の地図がもう一段はっきり見えてきます。