Claude Codeおすすめ設定まとめ【2026年5月】

Claude Code をインストールしたのに、デフォルトのまま使っていてもったいない設定が山積みになっていないか。適切に設定するだけで、毎回のパーミッション確認が消え、プロジェクトの方針をAIが自動で把握し、繰り返し作業がHooksで自動化される。

この記事では、2026年5月時点のClaude Code最新バージョンで効果が高いおすすめ設定を、実際に使っている設定例とともに紹介する。CLAUDE.md・settings.json・Hooks・カスタムスラッシュコマンド・モデル選択まで一通り設定すれば、開発体験が大きく変わるはずだ。

設定ファイルの全体像：3つの層を理解する

Claude Code の設定は3層構造になっている。この全体像を把握してから各設定に入ると、どこに何を書けばいいか迷わなくなる。

層	ファイル	適用範囲	Git管理
グローバル設定	~/.claude/settings.json	全プロジェクト共通	しない
プロジェクト設定	.claude/settings.json	プロジェクト全体（チーム共有）	する
ローカル設定	.claude/settings.local.json	プロジェクト内の個人設定	しない
AIへの指示	CLAUDE.md	プロジェクトのコンテキスト	する

原則として、「機械的に強制したいこと」はsettings.json、「柔軟な判断が必要なルール」はCLAUDE.md に書く。この役割分担を守ると、設定が肥大化せず管理しやすくなる。

例えば、「node_modulesを読まない」はsettings.jsonのdenyリストに書き、「コメントは日本語で書く」はCLAUDE.mdに書く。前者は機械的に強制すべきことで、後者はコンテキストに依存する判断だからだ。

CLAUDE.md 設定：AIへの指示書を作る

CLAUDE.md はプロジェクトを開くたびにClaude Codeが自動で読み込む指示書だ。プロジェクトの背景・禁止事項・コーディングスタイルを書いておくと、毎回同じことを説明しなくて済む。

書くべき内容と書かなくていい内容

書くべきこと:

• プロジェクトの目的・技術スタック・ディレクトリ構成
• 禁止事項（「package-lock.jsonを直接編集しない」など）
• よく使うコマンド（pnpm dev・pnpm test など）
• コーディングスタイル・命名規則
• 関連ドキュメントへのパス

書かなくていいこと（settings.jsonで管理するもの）:

• パーミッション設定
• 環境変数
• Hooks の設定

CLAUDE.md が長くなるほどトークン消費が増えるため、長い背景説明は別の docs/ ファイルに書き、CLAUDE.md からは「詳細は docs/xxx.md を参照」と参照するポイントだけ書くコツがある。

実際のCLAUDE.md テンプレート

# プロジェクト名

## 概要
このプロジェクトは〇〇を目的としたWebアプリケーション。
技術スタック: TypeScript / Next.js / PostgreSQL

## よく使うコマンド
- 開発サーバー起動: `pnpm dev`
- テスト実行: `pnpm test`
- 型チェック: `pnpm typecheck`
- DB マイグレーション: `pnpm db:migrate`

## 禁止事項
- `package-lock.json` を直接編集しない
- 環境変数をコードに直書きしない（.env を使う）
- テストを削除・スキップしない

## コーディングスタイル
- コメントは日本語
- 関数は単一責任の原則を守る
- 型は明示的に書く（any を避ける）

## 詳細ドキュメント
- 設計書: docs/design/
- 要件定義: docs/requirements/

/init コマンドを実行するとClaude Codeがコードベースを分析して自動生成してくれる。生成後に不要な部分を削ぎ落としていくのがおすすめだ。

settings.json 設定：権限設定でストレスを減らす

毎回「Bashコマンドを実行してもいいですか？」と確認が出てくるのは開発リズムを崩す。よく使うコマンドをallowリストに追加することで、これを解消できる。

permissions の設定方法

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(pnpm *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(ls *)",
      "Read(**)",
      "Edit(**)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(curl * | bash)"
    ]
  }
}

パターンには *（単一セグメント）と **（再帰的マッチ）が使える。Bash(pnpm *) と書けば pnpm install・pnpm dev・pnpm test など pnpm コマンド全体を一括許可できる。

denyリストのポイント: rm -rf・git push --force・パイプ実行（curl | bash）は明示的に拒否しておくと、意図しない破壊的操作を防ぐ安全網になる。

設定の適用範囲を使い分ける

開発チームで共通の許可設定は .claude/settings.json にコミットし、個人の好みの設定は ~/.claude/settings.json に書く。例えば「自分はpnpmではなくyarnを使う」という個人設定はグローバルに書くのが自然だ。

Claude Code Hooks 設定：開発ワークフローを自動化する

Hooks はClaude Codeの動作に合わせてシェルコマンドを自動実行する仕組みだ。実際に使うと開発フローが大きく変わる設定の一つで、競合記事でも注目度が高い。

Hooksの種類

Hook	実行タイミング	主な用途
PreToolUse	ツール実行前	危険コマンドのブロック・ログ
PostToolUse	ツール実行後	通知・後処理
Notification	通知発生時	デスクトップ通知
Stop	エージェント停止時	完了通知・サマリー生成

実践的なHooksレシピ

① ESLint自動実行（PostToolUse）

ファイル編集のたびに手動で eslint --fix を実行する手間がなくなる。特にClaude Codeが複数ファイルを一気に書き換える場面でリント漏れを防ぐのに効果的だ。

ファイル保存のたびにESLintを走らせる:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "cd $PROJECT_ROOT && npx eslint --fix $TOOL_INPUT_FILE_PATH 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

② 危険コマンドの自動ブロック（PreToolUse）

settings.jsonのdenyリストと違い「実行しようとしたこと自体をログに残す」ため、後から何が起きたか追いやすくなる。チームで使う場合は audit log として活用できる。

rm -rf が含まれるコマンドを自動ブロックする:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$TOOL_INPUT_COMMAND\" | grep -q 'rm -rf' && echo 'BLOCKED: rm -rf は禁止されています' && exit 1 || exit 0"
          }
        ]
      }
    ]
  }
}

③ 作業完了をデスクトップ通知（Stop）

長い処理中に別タスクへ移っても完了を見逃さなくなる。画面を張り付いて待つ必要がなくなるため、実際に使うとワークフローの感覚が一番変わる設定だ。5分以上かかるリファクタリングやテスト実行を任せて他の作業に集中できるようになる。

Claude Codeが作業を終えたらmacOSの通知を出す:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Codeが作業を完了しました\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

実際に使ってみると、Stopフックで完了通知を出す設定が一番体感の変化が大きい。長い処理を実行中に別の作業に移れるようになるためだ。

カスタムスラッシュコマンド設定：繰り返し作業を1コマンドに

.claude/commands/ ディレクトリに Markdown ファイルを作ると、/ファイル名 でそのプロンプトを呼び出せる。繰り返し使うプロンプトをコマンド化しておくことで、毎回同じ指示文を打つ手間が省ける。

実用的なコマンド例

/review（コードレビュー）

.claude/commands/review.md:

以下の観点で現在のブランチの差分をレビューしてください。

1. バグ・ロジックエラーの可能性
2. セキュリティ上の問題（XSS・SQLインジェクションなど）
3. パフォーマンスへの影響
4. テストが必要なケース
5. ドキュメント・コメントの不足

`git diff main...HEAD` の内容を読んで、問題点を優先度順に箇条書きで報告してください。

/daily（日次サマリー）

.claude/commands/daily.md:

今日の作業内容を整理してください。

1. `git log --oneline --since=today` でコミット一覧を確認する
2. 各コミットの変更内容を要約する
3. 未解決の課題・次のタスクをまとめる
4. 明日の作業予定を提案する

コマンドファイルには $ARGUMENTS を使うことで引数を渡すことも可能だ。例えば /review feature-branch と実行すると、$ARGUMENTS が feature-branch に置換される。

モデル設定とコスト最適化

2026年5月時点でClaude Codeで使えるモデルと特徴を整理しておく。

モデル	用途	入力コスト（1Mトークン）	出力コスト（1Mトークン）
claude-opus-4-7	複雑な設計・判断が必要なタスク	$15	$75
claude-sonnet-4-6	日常的な開発タスク（バランス型）	$3	$15
claude-haiku-4-5	軽量タスク・大量処理	$0.80	$4

デフォルトはSonnetで、ほとんどの開発作業に十分な品質が出る。大規模リファクタリングや設計レビューにはOpusを使い、ログ解析や大量ファイルの一括処理にはHaikuを使う、というコスト分けが現実的だ。例えば1日20回のコーディング支援をSonnetで使うと月間コストは概算で$10〜30程度、同じ量をOpusで使うと$50〜150になる計算だ。

モデルを変更するには /model コマンドか --model フラグを使う:

# Opusで起動
claude --model claude-opus-4-7

# 会話中に切り替え
/model claude-haiku-4-5

Claude Max プランを使っている場合: Fast モード（/fast）でOpusを高速モードで使える。品質を落とさずにレスポンス速度を上げたいときに有効だ。

よくある質問

Q: CLAUDE.mdはどこに置くべき？

A: プロジェクトルートに置くのが基本だ。また、サブディレクトリに置いたCLAUDE.mdはそのディレクトリ以下でのみ読み込まれる。モノレポ構成では、ルートのCLAUDE.mdに全体方針を書き、packages/api/CLAUDE.md に個別の設定を書く使い方が便利だ。

Q: settings.json を間違えて変な設定をしてしまったら？

A: ~/.claude/settings.json を削除するとグローバル設定がリセットされる。プロジェクトの .claude/settings.json はGitで管理していれば git checkout で戻せる。設定ファイルに問題があってもClaude Codeは起動するため、Claude Codeを使って設定ファイル自体を修正する方法もある。

Q: Hooksのデバッグはどうやる？

A: Hooksのコマンドは /tmp/ にログを書き出すようにすると確認しやすい。例えば echo "$(date) $TOOL_INPUT_COMMAND" >> /tmp/claude-hooks.log を各Hookに追加しておくと、実際に実行されたかどうかを確認できる。

Q: カスタムスラッシュコマンドとMCPはどう使い分ける？

A: カスタムスラッシュコマンドは「プロンプトのショートカット」、MCPは「外部ツールや外部APIとの接続」という違いがある。例えばGitHub Issueを読んでタスクを整理するにはMCPのGitHub連携を使い、コードレビューのプロンプトテンプレートを呼び出すにはカスタムスラッシュコマンドを使う、という使い分けが自然だ。