Claude Code設定は何から整える？｜CLAUDE.md・Hooks・Plan Modeで失敗を減らす始め方

まず押さえること：設定は「性能アップの裏技」ではなく、仕事の前提づくりです

Claude Code公式docsでは、各セッションは新しいコンテキストから始まり、CLAUDE.mdのようなファイルでプロジェクトの指示を読み込ませる仕組みが説明されています。これは欠点というより、必要な前提をこちらが与える設計です。

人間でも、新しい現場に入った初日に「このリポジトリの約束、テスト方法、触ってはいけない場所」を知らなければ迷います。Claude Codeも同じです。毎回チャットで説明するのではなく、プロジェクト側に前提を置いておくと、推測で動く場面を減らせます。

7つの設定層：最初から全部ではなく、順番に足す

Claude Codeの設定は、一気に全部入れるより、失敗が多い場所から順番に足す方が続きます。初心者なら、まずはCLAUDE.mdとPlan Mode。その後、権限、Hooks、subagents、skillsへ広げるのが自然です。

CLAUDE.mdには「毎回言っていること」だけを書く

CLAUDE.mdは、Claude Codeがセッション開始時に読むプロジェクトのメモです。公式docsでも、コーディング規約、アーキテクチャ判断、推奨ライブラリ、レビュー項目などを置く場所として説明されています。

ただし、何でも入れればよいわけではありません。長すぎるCLAUDE.mdは、毎回コンテキストを消費します。まずは「毎回チャットで説明していること」「一度間違えたら二度と間違えてほしくないこと」だけに絞ります。

# CLAUDE.md

## Project
このリポジトリはi-Styleの静的Webサイトです。
新規Blog記事は blog/{slug}.html に作成します。

## Commands
- Build: npm run build
- Test: npm run test:all
- Git確認: git status --short && git diff --stat

## Rules
- 本番公開・main pushは人間の明示承認まで行わない
- 記事は title / article:title / H1 を一致させる
- 秘密情報、.env、secrets配下は読まない
- 作業完了前に build/test 結果を報告する

## Writing
- 初心者にもわかる言葉で書く
- 参考リンクは公式/一次情報を優先する
- 推測と確認済み事実を分ける

このファイルは「お願い」です。絶対に止めたい操作は、次のsettings.jsonやHooksへ移します。

settings.jsonとpermissionsで、止まる場所を先に決める

Claude Code公式docsでは、settings.jsonが階層的な設定の公式メカニズムとして説明されています。個人全体なら~/.claude/settings.json、プロジェクト共有なら.claude/settings.json、自分のPCだけの調整なら.claude/settings.local.jsonという分け方です。

ポイントは、確認プロンプトをなくすことではなく、確認すべきものと毎回通してよいものを分けることです。buildやtest、git statusのような読み取り・検証は通し、本番push、削除、秘密情報の読み取りは止めます。

{
  "permissions": {
    "allow": [
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(npm run build)",
      "Bash(npm run test:all)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Read(./.env*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)"
    ]
  }
}

便利そうだからといって、広い権限を一気に渡すのはおすすめしません。小さく許可し、危ない操作は明示的に止める。この方が夜間作業や長時間作業でも安心して見守れます。

Hooksは「守ってほしい」を「守らないと進めない」に変える

公式docsでは、HooksはPreToolUse、PostToolUse、Stop、SessionStartなどのイベントに対して処理を挟める仕組みとして説明されています。特にPreToolUseは、ツール実行前に危険操作を止める場所です。

CLAUDE.mdに「.envを読まない」と書くだけでは、最終的にはモデルの判断に依存します。絶対に止めたいなら、Hookで「その操作は不可」と返す。ここが、設定上手な人と素のまま使う人の大きな違いです。

Plan Modeは、手を動かす前に「読む・考える」を分けるための設定

Claude Code公式のCommon workflowsやBest practicesでは、複雑な変更では先に探索し、計画し、その後に実装する流れが勧められています。Plan Modeでは、Claudeがファイルを読み、計画を出し、承認されるまで編集しません。

これは中小企業のAI活用でもかなり実用的です。いきなり編集されるのが怖い作業、影響範囲が広い作業、初めて触るリポジトリでは、まずPlan Modeで読ませる。人間が「その方向でよい」と判断してから実装に進めます。

コツは、Plan Modeで「どのファイルを読んだか」「何を変更するつもりか」「どう検証するか」まで出してもらうことです。計画に検証が入っていないなら、その時点で足します。

subagentsとskillsは、会話を汚さないために使う

大きなログ、長い仕様書、広いコード探索をメイン会話で全部読むと、文脈がすぐに膨らみます。公式docsでも、大きな調査はsubagentsへ委譲し、結果だけを戻す使い方が紹介されています。

また、無関係な作業へ切り替えるときは/clearで会話を区切り、長くなった作業は必要に応じて/compactで要点を残す、というコンテキスト管理も重要です。設定を整えるほど、会話の片付け方も仕事の品質に効いてきます。

一方、skillsは長い手順やチェックリストを会話の外に置くために使えます。毎回CLAUDE.mdへ詰め込むのではなく、必要なときだけ呼び出す。これは、人間で言えば「机の上の付箋」と「棚に置いた手順書」を分けるようなものです。

導入順は「今日」「今週」「繰り返し作業が見えた後」で分ける

設定を一気に作り込もうとすると、設定そのものが目的になります。おすすめは、今日できる最小構成から始め、失敗や繰り返しが見えたところだけ増やすことです。

この順番なら、最初から大げさなAI基盤を作らなくても、失敗しやすいところから着実に改善できます。

やってはいけない設定：便利さより事故範囲を見る

設定を整える目的は、何でも自動化することではありません。安心して任せられる範囲を広げることです。特に、権限を広く渡しすぎる設定、秘密情報をファイルへ直書きする設定、検証なしで完了扱いにする設定は避けます。

まとめ：Claude Code設定は、AIを賢くするより「迷わせない」ためにある

• ・CLAUDE.mdは、プロジェクトの前提を毎回渡すための短いメモです。
• ・settings.jsonとpermissionsは、許可する操作と止める操作を分けるために使います。
• ・Hooksは、お願いではなく強制したい安全ルールに向いています。
• ・Plan Modeは、編集前に読む・考える・検証計画を作るための安全な入口です。
• ・subagentsとskillsは、会話を軽く保ち、繰り返し作業を再利用するために使います。

i-Styleでは、AI導入の差は「どのAIを使ったか」だけでなく、「AIが迷わない環境を用意したか」に出ると見ています。まずは大きな自動化より、CLAUDE.md、Plan Mode、build/testの完了条件から。そこを整えるだけでも、毎日のAI作業はかなり落ち着いてきます。

参考リンク

• 議題元: Claude Code設定に関するX投稿（議題確認のみ / 2026年7月31日確認）
• 公式docs: How Claude remembers your project（Claude Code Docs / 2026年7月確認）
• 公式docs: Claude Code settings（Claude Code Docs / 2026年7月確認）
• 公式docs: Hooks reference（Claude Code Docs / 2026年7月確認）
• 公式docs: Create custom subagents（Claude Code Docs / 2026年7月確認）
• 公式docs: Common workflows（Claude Code Docs / 2026年7月確認）
• 公式docs: Best practices for Claude Code（Claude Code Docs / 2026年7月確認）
• 参考: Claude Code設定に関する海外X検索（X / 2026年7月確認）

関連記事