Claude Codeのおすすめ設定7つ｜設定先と効かない時の切り分け方

Claude Code のおすすめ設定として、この記事では公式ドキュメントの記述をもとに次の7つを選びました。/init で CLAUDE.md を作る、lint とテストのコマンドを許可する、.env を読ませない、権限モードは既定のまま bypassPermissions を常用しない、完了通知を受け取れるようにする、Shift+Enter で改行できるようにする、ステータスラインでコンテキスト使用量を見えるようにする、の7つです。settings.json に書いた設定の読み込みは /status、CLAUDE.md の読み込みは /context で確認でき、通知・改行・表示は実際の動作で確かめます。

この記事では、それぞれを「どの設定場所に何を書くか」と「効かないときに何を見るか」まで含めて説明します。各キーの網羅的な一覧は settings.json の解説記事、インストール直後の流れは初期設定ガイドに分けています。

Claude Code のおすすめ設定7つは何か？

先に一覧で示します。「書く場所」は次の章で説明するスコープです。

#	設定	何が良くなるか	書く場所
1	`/init` で CLAUDE.md を作る	ビルド方法や規約を毎回説明しなくて済む	`./CLAUDE.md`（チームで共有）
2	lint・テストのコマンドを `allow` に入れる	定型コマンドで毎回止まらない	`~/.claude/settings.json` か `.claude/settings.json`
3	`.env` を `Read` の `deny` に入れる	秘密情報のファイルを Claude のファイルツールに読ませない	同上
4	権限モードは既定のまま、`bypassPermissions` を既定にしない	公式が案内する auto mode の安全確認をそのまま使う（この記事の提案）	変更しない
5	完了通知を受け取る（`preferredNotifChannel`）	端末から離れているとき、タスク完了や権限確認待ちを通知で知れる	`~/.claude/settings.json`
6	Shift+Enter で改行できるようにする（`/terminal-setup`）	複数行のプロンプトを打てる	コマンドを一度実行するだけ
7	ステータスラインを出す（`/statusline`）	モデル名やコンテキスト使用率を常に見られる	`/statusline` が設定を自動で更新する

この記事の方針として、hooks やモデルの既定値などは、この7つが落ち着いてから必要になった時点で足すことを勧めます。hooks とモデルについては後半の「hooks やモデルはいつ設定すればよいか？」で触れます。

設定はどのファイルに書けばよいか？

公式ドキュメントでは、設定ファイルは4つのスコープに分かれています。インストールしただけではどのファイルも作られないので、必要なものを自分で作るか、Claude Code に作らせます。

スコープ	ファイル	効く範囲	向いている設定
User	`~/.claude/settings.json`	自分の、このマシン上の全プロジェクト	テーマ、既定モデル、自分の権限ルール
Shared project	`.claude/settings.json`	そのフォルダで作業する全員（git にコミットして共有）	チームの権限、hooks、プラグイン、環境変数
Project local	`.claude/settings.local.json`	自分の、そのプロジェクトだけ	個人的な上書き、共有前の試し
Managed	`managed-settings.json` など	組織が配布した全員	セキュリティポリシー、コンプライアンス

同じキーが複数の場所にあるときは、Managed、コマンドライン（起動時に --settings で渡す JSON、そのセッションのみ）、Project local、Shared project、User の順に上が優先されます。ただし permissions.allow のようなリストは上書きではなく結合されるため、User に書いた許可とプロジェクトに書いた許可は両方効きます。

迷ったときの目安は次のとおりです。

自分だけの好み（通知、ステータスライン、自分がよく使うコマンドの許可）は User に書く
チーム全員に効かせたい作業ルール（.env の拒否、プロジェクトのテストコマンドの許可）は Shared project に書いてコミットする
そのプロジェクトで自分だけ変えたいことは Project local に書く

Bash コマンドの権限確認で「Yes, and don’t ask again」を選ぶと、その許可は .claude/settings.local.json に allow ルールとして保存されます。Claude Code が初めてこのファイルを書くときは git の除外設定に追加しますが、自分で手作業で作った場合は .gitignore への追加も自分で行います。

権限のおすすめ設定は何を許可し、何を拒否するか？

公式の設定ドキュメントには、lint とテストを確認なしで実行させ、.env を読ませない例がそのまま載っています。おすすめ設定の2と3はこれです。

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

npm run lint や npm run test の部分は公式の例なので、自分のプロジェクトで使うコマンドに合わせて書き換えてください。$schema の行を入れておくと、VS Code や Cursor などで補完と入力チェックが効きます。公式によるとスキーマは最新の CLI より遅れることがあり、新しく文書化されたキーに警告が出ても設定が誤っているとは限りません。

許可を広げる前に押さえておきたい仕様が3つあります。

評価順は deny、ask、allow の順。最初に一致したものが結果を決め、ルールの具体性は順番に影響しません。広い deny を書くと、より狭い allow で例外を作ることはできません。
権限ルールを強制するのはモデルではなく Claude Code 本体。CLAUDE.md に「.env を読まないで」と書いても、許可される範囲は変わりません。読ませたくないファイルは deny に書きます。.claudeignore は効かないので、その中身は Read の deny ルールに移します。
deny はセキュリティ境界そのものではない。Read の deny は、ファイル名を指定せずに読む grep -r や、Python や Node のスクリプトが内部で開くファイルまでは止めません。Bash の deny も、同じプログラムを別の形で呼び出した場合には一致しません。すべてのプロセスから守りたい場合は、公式はサンドボックスを有効にするよう案内しています。

今どのルールがどのファイルから効いているかは、セッション中に /permissions を開くと一覧で見られます。公式のベストプラクティスも、確認を減らしたいときは /permissions で信頼できるツールを事前に許可し、/sandbox でサンドボックス内のコマンドを確認なしで走らせる組み合わせを勧めています。サンドボックスの設定はサンドボックス設定の解説に分けています。

権限モードは変えたほうがよいか？

おすすめ設定の4は「変えない」です。公式のベストプラクティスによると、v2.1.283 以降では、対話型のターミナルと VS Code のセッションは auto mode で始まるのが既定です。auto mode では別の分類モデルが大半の操作を確認し、危険に見えるものだけを止めます。それより前のバージョンでは、auto mode が既定になるのは Pro、Max、Team プランだけです。

公式によると、bypassPermissions は権限確認と安全チェックを無効にしてツール呼び出しをすぐ実行するモードで、向いている場面は「隔離したコンテナや VM のみ」とされています。

セッション中は Shift+Tab でモードを切り替えられます。bypassPermissions について公式は、プロンプトインジェクションや意図しない操作への保護がないとし、確認を減らしたいなら auto mode を使うよう案内しています。組織の管理者はマネージド設定で permissions.disableBypassPermissionsMode を "disable" にして、このモードを禁止できます。

permissions.defaultMode の値 auto と bypassPermissions は、Shared project と Project local の設定ファイルに書いても効きません。User かマネージド設定に書くか、そのセッションだけ --permission-mode で指定します。リポジトリ経由で全員を bypassPermissions で始めさせることはできない作りです。モードごとの細かな挙動は権限モードの解説にまとめています。

CLAUDE.md には何を書くべきか？

おすすめ設定の1は、/init で CLAUDE.md のたたき台を作り、使いながら直すことです。公式のベストプラクティスは、CLAUDE.md を毎回の会話の最初に読み込まれる特別なファイルとし、コードからは推測できない前提を書く場所としています。

公式が挙げる「入れるもの」は、Claude が推測できない Bash コマンド、既定と違うコードスタイルのルール、テストの手順、ブランチ名や PR の作法、必須の環境変数などです。反対に、コードを読めばわかること、頻繁に変わる情報、ファイルごとの説明は入れないものとされています。

判断の基準として公式は、各行について「これを消したら Claude が間違えるか」を問い、そうでなければ削るよう勧めています。肥大化した CLAUDE.md は実際の指示が無視される原因になり、1ファイルは200行未満が目安です。読み込まれたかどうかは /context で確認できます。たまにしか使わない手順や知識は、毎回読み込まれる CLAUDE.md ではなく Skills に分けます。

置き場所は、チームで共有するなら ./CLAUDE.md か ./.claude/CLAUDE.md、全プロジェクト共通の自分の好みなら ~/.claude/CLAUDE.md、そのプロジェクトで自分だけの内容なら ./CLAUDE.local.md（.gitignore に追加）です。見出しの組み立て方や例文は CLAUDE.md の書き方ガイドで扱っています。

待ち時間を減らす操作まわりの設定は？

おすすめ設定の5から7は、作業そのものではなく、待ち方と入力のしやすさを整える設定です。

完了通知（5）。公式によると、Claude がタスクを終えたときや権限確認で止まったときに、端末から離れていると判断されると通知イベントが発生します。Claude Code が既定でデスクトップ通知を送るのは Ghostty、Kitty、iTerm2 だけです。それ以外のターミナルでは、~/.claude/settings.json に次の1行を入れるとターミナルのベルが鳴るようになります。

{
  "preferredNotifChannel": "terminal_bell"
}

通知が出ない場合は、OS の設定でターミナルアプリに通知の許可があるか、tmux の中で動かしているなら passthrough を有効にしているかを確認します。音を鳴らすなど独自の動きにしたい場合は Notification hook を使います。

Shift+Enter での改行（6）。Ghostty、Kitty、iTerm2、WezTerm、Warp、Apple Terminal、Windows Terminal では設定なしで使えます。VS Code、Cursor、Zed などでは /terminal-setup を一度実行します。tmux や screen の中ではなく、ホストのターミナルで直接実行するのが条件です。gnome-terminal と JetBrains IDE では使えないため、Ctrl+J か \ のあとに Enter で改行します。

ステータスライン（7）。/statusline に表示したい内容を自然な言葉で伝えると、Claude Code が ~/.claude/ にスクリプトを作り、設定も自動で更新します。公式の例は次のとおりです。

/statusline show model name and context percentage with a progress bar

コンテキストの使用率が常に見えると、会話が長くなりすぎる前に区切る判断がしやすくなります。表示項目の作り込みはステータスラインの設定方法で扱っています。

hooks やモデルはいつ設定すればよいか？

hooks は、7つに入れていません。公式は hooks を「例外なく毎回実行したい処理」のための仕組みと位置づけ、CLAUDE.md の指示が助言にとどまるのに対し、hooks は決定的に実行されると説明しています。たとえば、CLAUDE.md に書いたのに守られないルールが出てきたら、hooks を検討する場面と考えられます。公式は「ファイルを編集するたびに eslint を実行する hook を書いて」のように Claude 自身に書かせる方法も紹介しており、設定済みの hooks は /hooks で確認できます。書き方は hooks の解説に分けています。

モデルは、/model で選んだ値がそのまま新しいセッションの既定として保存されます。設定ファイルを手で書く代わりに、使い分けたくなったときに /model で選ぶ方法があります。モデルの違いはモデルの選び方を参照してください。

設定が効かないときはどう確かめるか？

設定を書いたら、まずセッション内で /status を実行します。設定反映を示すStatus タブの Setting sources 行に、そのセッションで読み込まれた設定ファイル（User settings や Project local settings など）が並びます。組織のマネージド設定が効いている場合もここに出ます。

効かないときは、ここでは次の順で確認します。

JSON が壊れていないか。設定ファイルは厳密な JSON で、// のコメントや末尾のカンマは構文エラーになり、次の起動時に Settings Error として報告されます。権限設定ルールの書き方の誤りなど一部の項目だけが不正な場合は Settings Warning になり、その項目だけが読み飛ばされます。
診断コマンドで不正な項目を探す。ターミナルで次を実行すると、セッションを起動せずにインストールと設定の診断が表示されます。修正の提案まで欲しい場合は、セッション内で /doctor を使います。
```
claude doctor
```
上位のスコープや環境変数に上書きされていないか。公式は、効かない設定の多くは別のスコープか環境変数による上書きだとしています。前述の優先順位を見直し、組織のマネージド設定が同じキーを持っていないかも /status で確認します。
チームで共有した allow が効かない。.claude/settings.json の permissions.allow は、各メンバーがそのフォルダを信頼するまで適用されません。deny と ask はすぐに効きます。また、「Yes, and don’t ask again」で保存した allow は、プロジェクトやマネージド設定の ask ルールより優先されません。
反映のタイミング。permissions や hooks の編集は再起動なしで反映されますが、model や effortLevel はセッション開始時にしか読まれません。途中で変えたい場合は /model や /effort を使います。

それでも原因がわからない場合は、まっさらな設定で起動して比べます。公式の手順では、新しい設定ディレクトリを指定し、プロジェクト側の設定（.claude/settings.json、CLAUDE.md、.mcp.json など）を読み込ませずに起動します。

CLAUDE_CONFIG_DIR=~/claude-clean/config claude --setting-sources user

この状態で問題が消えれば、原因は自分の user かプロジェクトの設定にあります。~/.claude.json と ~/.claude 内のファイルを1つずつ新しいディレクトリへ戻し、問題が再現したところが原因です。エラーメッセージ別の対処はエラー対処ガイドにまとめています。

公式の記述で今後変わりうる点

この記事の内容は、2026年10月18日に取得した公式ドキュメント（code.claude.com）の記述に基づいています。特に、auto mode が既定の開始モードになるバージョン（v2.1.283 以降）とプランの条件、既定でデスクトップ通知が届くターミナルの範囲、Shift+Enter が設定なしで使えるターミナルの一覧は、Claude Code のアップデートで変わりうる部分です。挙動が記事と違う場合は、この3点から公式ドキュメントの該当ページを見直してください。

まとめ

Claude Code のおすすめ設定は、CLAUDE.md、lint とテストの許可、.env の拒否、既定の権限モードの維持、完了通知、Shift+Enter、ステータスラインの7つが、確認の手間を減らしつつ権限の扱いを整理する出発点になります。自分だけの好みは ~/.claude/settings.json、チームのルールは .claude/settings.json、自分だけの例外は .claude/settings.local.json に書き、書いたら、読み込まれたファイルは /status、設定の不正は claude doctor で確認します。hooks やモデルの既定は、守られないルールや使い分けの必要が出てきてから足せば十分です。

設定を自分で読み直し、運用に合わせて調整していく練習の場として、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」（lab.no-wave.jp）もあります。