【保存版】CLAUDE.md設計ガイド｜Claude Codeが指示を無視する原因と12の設計ルール

「CLAUDE.mdにルールを書いたのに、Claude Codeが全然守ってくれない…」
「”日本語で返して”と書いているのに英語で返ってくる」
「”テストを実行してから完了報告して”と書いたのにスキップされる」

——こうした経験、ありませんか？

実はこれ、Claude Codeの性能の問題ではありません。CLAUDE.mdの「設計」の問題です。

多くの方がCLAUDE.mdを「お願いリスト」として書いてしまっています。「こうしてほしい」「ああしてほしい」と希望を羅列するだけのファイルです。しかし、Claude Codeが高い精度で指示に従うCLAUDE.mdには、明確な設計パターンがあります。

Anthropic公式ドキュメントでは「CLAUDE.mdはシステムプロンプトではなくガイダンスとして機能する」と明記されています。つまり、書き方次第で「守られるルール」にも「無視されるお願い」にもなるということです。

この記事では、Anthropic公式のベストプラクティスと、AI研究者Andrej Karpathy氏の問題提起から生まれたコミュニティ知見をもとに、CLAUDE.mdの設計品質を上げる12のルールをBefore/After付きで解説します。

Claude Codeの基本操作や初期設定がまだの方は、先に以下の記事をご覧ください。

2026.04.20

【保存版】Claude Code絶対すべき初期設定9選｜”育成ゲーム”で性能を引き出すコツ

---

「AI活用のリアルな事例を知りたい」「まず全体像をサクッと掴みたい」という方には、以下の資料がおすすめです。

CLAUDE.mdを書いたのに「指示が無視される」3つの原因

CLAUDE.mdに書いたルールが守られない。その原因は大きく3つに分類できます。

原因1. CLAUDE.mdが長すぎる

Anthropic公式ドキュメントでは、CLAUDE.mdは1ファイルあたり200行以下を目標にすることが推奨されています。

開発者コミュニティでも短いCLAUDE.mdが好まれる傾向があり、一般に長くなるほど指示の遵守率が落ちやすいことが知られています。

500行、1,000行とルールを詰め込むほど、重要なルールが「ノイズ」に埋もれて無視される確率が上がります。

原因2. 表現が曖昧すぎる

「きれいなコードを書いてください」「適切にフォーマットしてください」——こうした表現は、人間には通じてもAIには解釈の余地が広すぎます。

Claude Codeは「きれい」の定義を知りません。「2スペースインデント、セミコロンなし、シングルクォート」と書いて初めて、確実に従える指示になります。

原因3. CLAUDE.mdの位置づけを誤解している

ここが最も重要なポイントです。CLAUDE.mdはシステムプロンプトではありません。 Anthropic公式の表現を借りれば、CLAUDE.mdは「コンテキストとして注入されるガイダンス」です。

つまり、CLAUDE.mdに書いたルールは100%強制されるものではないということです。絶対に守らせたいルールには、後述するHooks（フック）という別の仕組みを使う必要があります。

この「ガイダンスであって強制ではない」という前提を理解したうえで、守られやすいCLAUDE.mdを設計するのが本記事の目的です。

【原則編】Karpathy氏の問題提起から生まれた4つの基本ルール

2026年1月、AI研究者のAndrej Karpathy（アンドレイ・カーパシー）氏がX（旧Twitter）に投稿した一連のポストが、CLAUDE.md設計論の出発点になりました。

Karpathy氏はClaude Codeを数週間集中的に使った経験から、AIコーディングエージェントの根本的な課題を指摘しています。

The models make wrong assumptions on your behalf and just run along with them without checking. They don’t manage their confusion, don’t seek clarifications, don’t surface inconsistencies.

（モデルはあなたに代わって間違った仮定を立て、確認もせずにそのまま突き進む。混乱を管理せず、明確化を求めず、矛盾を報告しない）

They really like to overcomplicate code and APIs, bloat abstractions, don’t clean up dead code.

（コードやAPIを過度に複雑化し、抽象化を膨らませ、不要なコードを片付けない）

この問題提起を受けて、Forrest Chang（フォレスト・チャン）氏がGitHubリポジトリ「andrej-karpathy-skills」として4つの基本原則に整理しました。このリポジトリは10万スター以上を獲得し、世界中の開発者のCLAUDE.md設計に影響を与えています。

以下、その4原則をBefore/After付きで解説します。

ルール1. コードの前に「前提」を明示させる（Think Before Coding）

Claude Codeの最大の問題行動は、曖昧な指示に対して勝手に仮定を置き、確認なしに実装を進めてしまうことです。

このルールをCLAUDE.mdに明記することで、「わからないことがあれば止まって聞く」という行動パターンをClaude Codeに刷り込みます。

Before（ルールなし）:

# プロジェクトルール
- TypeScriptで開発する
- テストを書く

この状態で「ユーザー認証を実装して」と依頼すると、Claude Codeは「JWT？セッション？OAuth？」を確認せず、自分の判断で実装を進めてしまいます。

After（ルール追記）:

# プロジェクトルール
- TypeScriptで開発する
- テストを書く
- 不明点がある場合は実装前に選択肢を提示し、確認を取ること。推測で進めない

この1行を追加するだけで、Claude Codeは「JWT認証とセッション認証のどちらで実装しますか？」と確認してから作業に入るようになります。

ルール2. 最小構成で解かせる（Simplicity First）

Karpathy氏が指摘した「過度な複雑化」への対策です。Claude Codeは放っておくと、要求されていないリトライ機能、キュー管理、テンプレートエンジンまで「親切心」で実装してしまいます。

Before:

# コーディング方針
- 保守性の高いコードを書く
- 拡張性を考慮する

After:

# コーディング方針
- 要求された機能だけを実装する
- 将来の拡張性のための抽象化や、要求されていない機能の追加は行わない
- 100行で済む処理を1,000行のフレームワークにしない

「保守性」「拡張性」という曖昧な言葉が、過剰実装の免罪符になっていた構造を断ち切ります。

ルール3. 変更範囲を限定させる（Surgical Changes）

「このバグを直して」と依頼したのに、関係ないファイルまでリファクタリングされていた——そんな経験はありませんか？

Claude Codeは「ついでにこっちも直しておきました」という行動を取りがちです。このルールは、その「余計な親切」を止めます。

Before:

# 作業ルール
- コードの品質を保つ

After:

# 作業ルール
- 変更は依頼された範囲に限定する
- 隣接コードの改善やリファクタリングは、明示的に依頼されない限り行わない
- すべての変更行に「なぜこの変更が必要か」の理由があること

ルール4. 成功条件を先に定義させる（Goal-Driven Execution）

「何をするか」の手順を書くのではなく、「何が達成されたら完了か」を書く。これがKarpathy氏の提唱する「目標駆動」の考え方です。

Karpathy氏は次のように述べています。

Don’t tell it what to do, give it success criteria and watch it go. LLMs are exceptionally good at looping until they meet specific goals.

（何をすべきかを指示するな。成功基準を与えて、やらせろ。LLMは特定の目標を満たすまでループすることに非常に長けている）

Before:

# テスト方針
- ユニットテストを書く
- テストを実行する

After:

# テスト方針
- 実装後、npm test を実行し、全件パスすることを確認してから完了を報告する
- テストが失敗した場合は、修正→再実行を自動で繰り返す

手順の列挙（「テストを書く」「実行する」）ではなく、検証可能な成功基準（「全件パスしてから報告する」）を書くのがポイントです。

【構造編】CLAUDE.mdの「器」を整える4つのルール

原則編の4ルールは「Claude Codeの行動をどう制御するか」でした。ここからは、CLAUDE.mdファイル自体の設計品質を上げるルールです。

ルール5. CLAUDE.mdは200行以下に保つ

Anthropic公式ドキュメントで明確に推奨されている数字です。

前述のとおり、CLAUDE.mdが長くなるほど指示の遵守率は下がります。Anthropic公式ドキュメントでも「長いファイルはコンテキストを消費し、遵守率が低下する」と明記されています。

「あれもこれも」と詰め込みたくなる気持ちはわかりますが、情報を増やすほど1つ1つの指示の遵守率は下がります。

対策のポイント:

• コアルールを60〜100行に厳選する
• 詳細は後述する .claude/rules/ に分割する
• 「書けば書くほど賢くなる」は誤解。削れば削るほど精度が上がる

ルール6. 「削除テスト」を通る行だけ残す

Anthropic公式ベストプラクティスに記載されている、シンプルだが強力な判断基準です。

この行を削除したら、Claude Codeは間違いを犯すか？

答えが「No」なら、その行は削除してください。

削除すべき行の例:

- きれいで保守性の高いコードを書く
- ベストプラクティスに従う
- 適切なエラーハンドリングを行う

これらはClaude Codeがデフォルトで行うことです。わざわざ書いても精度は上がらず、コンテキストの枠を浪費するだけです。

残すべき行の例:

- テスト実行コマンド: npm test（推測不能なプロジェクト固有情報）
- APIハンドラは src/api/handlers/ に配置する（プロジェクト固有の規約）
- 環境変数は .env.local から読む。.env は本番用なので編集しない（非自明な注意点）

Anthropic公式の基準を整理すると、CLAUDE.mdに書くべきものは以下の5つです。

書くべきもの	理由
Claude Codeが推測できないBashコマンド	プロジェクト固有の手順は推測不能
デフォルトと異なるコードスタイル	標準に反するルールは明示が必要
テスト手順と検証コマンド	プロジェクトごとに違う
アーキテクチャ上の決定事項	コードだけでは意図が伝わらない設計判断
環境固有の制約・非自明な注意点	知らないと事故を起こす情報

逆に、書いてはいけないものは以下です。

書いてはいけないもの	理由
コードを読めばわかること	二重管理になり、乖離のリスクが生まれる
標準的な言語規約	Claude Codeは既に知っている
頻繁に変わる情報	メンテナンスコストが高すぎる
長い説明文やチュートリアル	コンテキスト枠の浪費
「きれいなコードを書く」のような自明な規範	書いても精度は変わらない

ルール7. 具体的・検証可能な表現で書く

曖昧な表現は、Claude Codeに「解釈の自由」を与えてしまいます。指示が無視されるのではなく、あなたの意図と異なる解釈をされているだけかもしれません。

Before（曖昧な表現）:

- コードを適切にフォーマットする
- ファイルは整理して配置する
- エラーは適切にハンドリングする

After（具体的・検証可能な表現）:

- インデントは2スペース。セミコロンなし。シングルクォートを使用
- コンポーネントは src/components/ 配下に、1コンポーネント1ファイルで配置
- API呼び出しのエラーは try-catch で捕捉し、ユーザー向けメッセージを表示する。console.log でのエラー出力は禁止

判断基準: その指示を読んだ2人の開発者が、同じ実装をするか？「適切に」という言葉が入っている指示は、ほぼ確実に人によって解釈が異なります。

ルール8. 5つの階層を使い分ける

CLAUDE.mdには5つの配置場所があり、それぞれスコープが異なります。

階層	配置場所	対象範囲	用途
組織ポリシー	OS固有のシステムパス	組織全員（除外不可）	セキュリティポリシー等
ユーザー（グローバル）	~/.claude/CLAUDE.md	自分の全プロジェクト	個人の共通設定
プロジェクト	./CLAUDE.md	チーム全員（git管理）	プロジェクト固有ルール
ローカル	./CLAUDE.local.md	自分だけ	個人の好み（.gitignore推奨）
サブディレクトリ	子ディレクトリの CLAUDE.md	そのディレクトリ作業時のみ	モジュール固有の注意事項

すべてのCLAUDE.mdは結合されて読み込まれます。上書きではなく追加です。

よくある失敗: 個人の好み（「コメントは英語で書く」「コミットメッセージのフォーマット」など）をプロジェクトの ./CLAUDE.md に書いてgitにコミットしてしまうケース。チームメンバーの好みと衝突します。

正しい使い分け:

• 自分だけの好み → ~/.claude/CLAUDE.md（グローバル）または ./CLAUDE.local.md（プロジェクトローカル）
• チーム共有のルール → ./CLAUDE.md（gitで管理）
• 特定ディレクトリだけの注意事項 → サブディレクトリの CLAUDE.md

「Claude Codeをチームで導入したいが、ルール設計や運用体制をどう整備すべきかわからない」——そんな課題を感じている方は、以下の研修プログラムもご活用ください。

【運用編】精度を上げ続ける4つのルール

CLAUDE.mdは一度書いたら終わりではありません。使いながら育てることで、プロジェクトに最適化されたルールファイルに進化していきます。

ルール9. .claude/rules/ でルールをモジュール分割する

ルール5で「200行以下に保つ」と書きましたが、大きなプロジェクトではルールが膨らみがちです。その解決策が .claude/rules/ ディレクトリです。

.claude/rules/ 配下に .md ファイルを置くと、CLAUDE.mdへの明示的な記述なしで自動的に読み込まれます。さらに、YAMLフロントマターで特定のファイルパスに対してだけ適用されるルールを定義できます。

<!-- .claude/rules/api-rules.md -->
---
paths:
  - "src/api/**/*.ts"
---

- APIレスポンスは必ず { data, error, meta } の形式で返す
- 認証ミドルウェアは src/api/middleware/auth.ts を使う
- レート制限: 1エンドポイントあたり100リクエスト/分

<!-- .claude/rules/testing.md -->
---
paths:
  - "**/*.test.ts"
  - "**/*.spec.ts"
---

- モックは最小限に。外部API呼び出しのみモック化する
- テストデータは fixtures/ ディレクトリに集約

この設計により、ルートのCLAUDE.mdはプロジェクト全体の基本方針だけに集中させ、詳細なルールはモジュール別に分離できます。

ただし注意点があります。@import 構文やこの .claude/rules/ でインポートされたファイルは、セッション開始時にすべて展開されてコンテキストに入ります。ファイルを分割してもコンテキスト消費量は変わりません。分割の効果は「整理しやすくなる」「パス条件で不要なルールを除外できる」点にあります。

ルール10. Hooksで「100%守らせたいルール」を強制する

CLAUDE.mdはガイダンスです。どれだけ設計を工夫しても、100%の遵守は保証されません。

「本番データベースを絶対に削除しない」「mainブランチに直接pushしない」——こうした破ったら事故になるルールは、CLAUDE.mdではなくHooksに書くべきです。

Hooksとは、Claude Codeの特定の操作（コマンド実行・ファイル編集など）の前後に自動実行されるスクリプトです。CLAUDE.mdと違い、Hooksは100%実行されます。

.claude/settings.json に以下のように設定します。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "script": "if echo \"$TOOL_INPUT\" | grep -q 'rm -rf /'; then echo 'BLOCK: 危険なコマンドをブロックしました' >&2; exit 2; fi"
      }
    ]
  }
}

CLAUDE.md と Hooks の使い分け:

項目	CLAUDE.md	Hooks
強制力	ガイダンス（守られないことがある）	100%実行
用途	コーディング方針・スタイル・手順	セキュリティ・禁止操作・自動チェック
設定方法	Markdownで記述	JSON + シェルスクリプト
例	「テストを実行してから報告」	「rm -rf をブロック」

判断基準: そのルールが守られなかった場合、取り返しがつかない事故になるか？ Yesなら Hooks、Noなら CLAUDE.md です。

Hooksの詳しい設定方法はClaude Code初期設定9選で解説しています。👇

2026.04.20

【保存版】Claude Code絶対すべき初期設定9選｜”育成ゲーム”で性能を引き出すコツ

ルール11. 同じミスが2回起きたら即座に追記する

Anthropic公式ドキュメントでは、CLAUDE.mdに追記すべきタイミングとして以下が挙げられています。

• Claude Codeが同じ間違いを2回した時
• 前回のセッションで入力した訂正を、また今回も入力している時
• 「いつもこう直すんだけどな」と感じた時

CLAUDE.mdを「最初に一度書くもの」だと思っていると、同じ指摘を何度も繰り返すことになります。

実践のコツ:

• チャットで訂正を入力したら、その場で「CLAUDE.mdに追記して」とClaude Codeに依頼する
• セッション終了時に「今日のセッションで繰り返し訂正した内容をCLAUDE.mdに反映して」と依頼する

これを習慣化するだけで、セッションを重ねるごとにClaude Codeの精度が上がっていきます。

ルール12. /compact後も生き残る設計にする

Claude Codeには /compact コマンドがあります。会話が長くなった時にコンテキストを圧縮する機能ですが、ここに重要な仕様があります。

プロジェクトルートのCLAUDE.mdは、/compact 後に自動で再読込されます。 つまり、compactでコンテキストが圧縮されても、ルートのCLAUDE.mdに書かれたルールは失われません。

一方、サブディレクトリのCLAUDE.mdは再注入されません。 compact後にそのディレクトリのファイルを触れば再読込されますが、保証はありません。

設計方針:

• 全セッションで絶対に必要なルール → プロジェクトルートの CLAUDE.md に書く
• 特定の作業時だけ必要なルール → サブディレクトリの CLAUDE.md に書く（compact後に消えても許容できるもの）
• 長時間のセッションでは、ルートのCLAUDE.mdに書いたルールが「最後の砦」として機能する

すぐ使えるCLAUDE.mdテンプレート

ここまでの12ルールを踏まえた、実践的なテンプレートを紹介します。プロジェクトに合わせてカスタマイズしてください。

基本テンプレート（個人開発向け）

# プロジェクト概要
- [プロジェクト名]: [1行で何をするプロジェクトか]
- 技術スタック: [言語/フレームワーク/主要ライブラリ]

# 行動原則
- 不明点がある場合は実装前に選択肢を提示し、確認を取る
- 要求された機能だけを実装する。未要求の機能追加は行わない
- 変更は依頼された範囲に限定する

# コードスタイル
- [インデント/クォート/セミコロン等の具体的なルール]
- [命名規則: 例) 変数はcamelCase、コンポーネントはPascalCase]

# テスト・検証
- テスト実行: [コマンド]
- 実装後、テストが全件パスすることを確認してから完了を報告する

# プロジェクト構成
- [重要なディレクトリとその役割を3-5行で]

# 注意事項
- [環境固有の制約や非自明な注意点を箇条書きで]

チーム開発テンプレート

# プロジェクト概要
- [プロジェクト名]: [1行で何をするプロジェクトか]
- 技術スタック: [言語/フレームワーク]
- ドキュメント: [内部Wiki/Notionのリンク等]

# 行動原則
- 不明点は実装前に確認する。推測で進めない
- 要求された機能のみ実装する
- 変更は依頼された範囲に限定する
- 実装完了の条件: テスト全件パス + 型チェック通過

# コードスタイル
- Linter: [ESLint/Prettier等の設定ファイルパス]
- [プロジェクト固有のスタイルルール]

# Git規約
- ブランチ: feature/[チケット番号]-[説明]
- コミットメッセージ: [フォーマット]
- PRは必ずdraft状態で作成する

# 開発コマンド
- 開発サーバー: [コマンド]
- テスト: [コマンド]
- ビルド: [コマンド]
- Lint: [コマンド]

# アーキテクチャ
- [重要なディレクトリ構成と設計判断を簡潔に]

# 禁止事項
- [やってはいけないことを具体的に]

テンプレートはあくまで出発点です。ルール11で述べたとおり、使いながらプロジェクトに合わせて育てていくことが最も重要です。

まとめ｜CLAUDE.mdは「お願いリスト」ではなく「行動契約書」

この記事で紹介した12のルールを振り返ります。

【原則編】Claude Codeの行動を制御する4ルール

ルール	ポイント
1. 前提を明示させる	推測で進めず、不明点は確認させる
2. 最小構成で解かせる	要求されていない機能を追加させない
3. 変更範囲を限定させる	「ついでの改善」を止める
4. 成功条件を定義させる	手順ではなく達成基準を書く

【構造編】CLAUDE.mdの「器」を整える4ルール

ルール	ポイント
5. 200行以下に保つ	削るほど精度が上がる
6. 削除テストで選別する	書かなくても正しく動く行は削除
7. 具体的・検証可能に書く	「適切に」は禁句
8. 5つの階層を使い分ける	個人の好みとチームルールを分離

【運用編】精度を上げ続ける4ルール

ルール	ポイント
9. .claude/rules/ で分割する	パス条件で適用範囲を限定
10. Hooksで強制する	事故防止ルールはCLAUDE.mdに書かない
11. ミス2回で即追記する	使いながら育てる
12. /compact後を想定する	重要ルールはルートに集約

CLAUDE.mdの設計は、Claude Codeの出力品質に直結します。「AIの性能が足りない」と感じたら、まずCLAUDE.mdの設計を見直してみてください。問題はモデルではなく、指示の出し方にあるかもしれません。

Claude Codeの基本的な使い方をまだ把握していない方は、Claude Codeとは？料金プラン・使い方を初心者向けに解説から始めるのがおすすめです。すでに使いこなしている方は、Claude Codeの活用事例10選で実践的なヒントが見つかるかもしれません。

2026.04.20

Claude Codeとは？Web版やCoworkとの使い分けから使い方・料金を徹底解説

2026.04.20

【実践編】Claude Codeの活用事例10選｜非エンジニアでも業務が10倍速になる使い方

---

「AIツールの導入を検討しているが、何から始めればいいかわからない」という方は、以下の資料で全体像を掴んでみてください。