【Claude活用③】Claude Codeの設定ファイル「settings.json」とは? 権限の書き方と判断の順序を理解する

Claude Codeは、同じ指示を出しても、設定次第で「確認なしで動く範囲」が変わります。その範囲を決めているのが、settings.jsonという設定ファイルです。仕組みを知っておくと、任せてよい作業と止めたい作業を自分で線引きできるようになると考えられます。

Oikon・前川蒼『Claude Code実践入門 Agentic Coding』(SBクリエイティブ)を参考にして。

目次

「settings.json」はClaude Codeの動き方を決める設定ファイル

CLAUDE.mdとの違い

「settings.json」は、権限・出力スタイル・モデルの選択・Hook(決まったタイミングで自動実行する仕掛け)など、Claude Code自身の「動作」を記述するファイルです。

CLAUDE.mdがプロジェクトをどう理解させるかを伝えるファイルであるのに対し、settings.jsonはClaude Code自身をどう動かすかを担います。

4つの置き場所と優先順位

同じ設定ファイルでも、置く場所によって効く範囲が変わります。

置き場所効く範囲
マネージドポリシー(管理者が配布)組織内の全ユーザー
ユーザー設定自分のすべてのプロジェクト
プロジェクト設定(Gitに登録)チームメンバー全員
ローカル設定(Git管理外)自分のそのプロジェクトのみ

優先順位は、強い順にマネージドポリシー、ローカル、プロジェクト、ユーザーです。

同じ項目が複数の場所に書かれていれば、優先順位の高い値が採用されます。

ローカル設定は自分の手元だけで反映されるため、チームに影響を与えず、自分だけ一時的に権限をゆるめて試すといった使い方ができます。

settings.jsonの4つの置き場所を、優先順位の高い順にマネージド設定、ローカル設定、プロジェクト設定、ユーザー設定と並べ、それぞれの効く範囲を示した図

設定画面から変えられること

主な項目は、設定画面(/config)から切り替えられます。

会話が長くなったときに内容を自動で縮める「自動圧縮」、時間をかけて深く考える「拡張思考」、既定の権限モード、出力スタイル、言語、モデルなどが対象です。

どのプロジェクトでも共通で使いたい設定はユーザー設定に、プロジェクトごとに変えることもある出力スタイルはローカル設定に保存されます。

出力スタイルをすべてのプロジェクトに反映したい場合は、ローカル設定に書かれた内容をユーザー設定へ移すことになります。

出力スタイルは、応答の粒度やテンションを変える機能で、標準(Default)・即実行(Proactive)・簡潔(Concise)・解説(Explanatory)・学習(Learning)の5種類があります。

たとえば、「解説」にすると、回答に加えて「なぜその回答になったのか」を説明するブロックが付くため、処理の中身が見えにくいと感じるときに役立ちます。

設定ファイルを直接編集すると、設定画面よりも広い範囲を細かく調整できます。

サンドボックス(隔離された実行環境)、環境変数、Git連携、プラグイン、MCPサーバー、エージェントなども、このファイルで扱う対象。

権限は「許可・確認・禁止」の3つで決める

allow・ask・denyの評価順序

Claude Codeは、ファイルの読み取りや検索には原則として都度の承認を求めませんが、コマンドの実行やファイルの編集は初回に承認を求めます。

この扱いをツールの種類ごとに決めるのが、permissionsという項目です。

書き方は、次の3つの配列に分かれます。

  • allow
    追加の承認なしで実行する
  • ask
    実行のたびに確認する
  • deny
    実行をブロックする

評価は「deny、ask、allow」の順に行われ、最初に当てはまったルールが適用されます。

たとえばallowに書いたコマンドでも、denyにも書いてあればブロックされます。

迷ったときに安全側へ倒れる設計です。

動作モードによって挙動は変わります。

確認を求めずにブロックだけを行うdontAsk、確認の代わりに分類器が判断するauto、確認の仕組みを使わずほぼすべてを実行できるbypassPermissionsなどがあります。

実行したい操作がdeny、ask、allowの順に判定され、最初に一致したルールで禁止・確認・許可が決まる流れを示した図

書くときの注意点

ルールは「ツール名(条件)」の形で書き、条件には任意の文字列を表す「ワイルドカード」を使えます。

次の3点に注意が必要です。

  • 単語の区切り
    ワイルドカードを付ける位置によって、似た名前の別のコマンドまで対象に含まれる場合がある
  • 複合コマンド
    複数のコマンドを「&&」でつなぐと、1本のコマンドとしては扱われず、左側だけ許可しても、右側まで自動で許可されることはない
  • ファイルのパス
    先頭の書き方によって、絶対パス・ホームフォルダ・設定ファイルの置き場所・現在のフォルダのどこを基準にするかが変わる

禁止設定にも限界がある

機密ファイル(.envなど)の読み取りをdenyにすると、読み取り用のツールに加え、Claude Codeが読み取りと認識できるコマンドもブロックされます。

ただし、別のシェルを経由した間接的な実行や、ファイルを自分で開くPythonスクリプトのような別プロセスには、この設定は適用されません。

プロセス全体で止めたい場合は、サンドボックスとの併用が現実的と考えられています。

当事務所でも、認証情報などの機密ファイルはClaude Codeが読めないよう、禁止設定で止めています。

ただ、同じ書き方でもツールによって効き方が違うことがあるため、ダミーのファイルで実際に読み取りを試し、効いているかを確かめています。

Autoモードは便利、でも任せきりにしない

分類器が危険性を判断する仕組み

Autoモードは、ツールを呼び出すたびに「分類器」が危険性を判定し、安全と判断された操作だけを承認なしで実行するモードです。

分類器は、Claude Code本体とは別に、操作の危険性だけを評価する専用のモデルです。

すべてを素通しにするbypassPermissionsとは違い、危険な操作は止められます。

判断は3段階で進みます。

  • 通常のルール
    deny・ask・allowのどれかに当てはまれば、その場で決まります
  • 自動承認
    どれにも当てはまらない場合、読み取りと作業フォルダ内の編集は自動で承認されます
  • 分類器の判定
    それ以外は分類器が判定し、ブロックされるとClaude Codeが別の方法を試します

セッションの開始時からAutoモードにしたい場合は、既定の権限モードにautoを指定します。

分類器の基準には、2つの強さがあるとされます。

ユーザーの意図やallowルールによって覆ることがある「soft_deny(強制的なGit操作、外部コードの実行、本番へのデプロイなど)」と、意図に関わらず無条件でブロックされる「hard_deny(機密情報の外部への送信など)」です。

Autoモードの判断が、通常のルール、自動承認の対象、分類器の判定の3段階で進むことを示した図

任せきりにしない場面

Autoモードは、試験提供(Research preview)の段階にあり、見逃しがゼロではないようです。

本番環境への反映や、元に戻せない変更を伴う作業では、Autoモードだけに頼らないことが大切であると考えられます。

任せる範囲を広げるほど、作業の完了条件を明確にしておく必要もあります。

当事務所でも、任せる範囲はあらかじめ決め、ファイルの削除は人が行う運用にしています。

また、Claude Codeには、不要になったファイルを「削除確認用フォルダ」へ移すところまでを任せ、最終的に消すかどうかは人が判断します。

白いトレーに並んだGODIVAの10個入りデザート

この記事が気に入ったら
いいね または フォローしてね!

  • URLをコピーしました!

この記事を書いた人

長崎で活動する
税理士、キャッシュフローコーチ

酒井寛志税理士事務所/税理士
㈱アンジェラス通り会計事務所/代表取締役

Gemini・ChatGPT・Claudeなど
×GoogleWorkspace×クラウド会計ソフトfreeeの活用法を研究する一方、
税務・資金繰り・マーケティングから
ガジェット・おすすめイベントまで、
税理士の視点で幅広く情報発信中

目次