このドキュメントについて
対象読者: Claude Codeを使い始めたいエンジニア・使ってみたが勝手に変なコードを書くので困っているエンジニア
扱わない範囲: インストール手順（公式ドキュメントを参照）、CLAUDE.mdの階層の詳細（公式ドキュメントを参照）
概要
Claude Codeの出力品質は、指示の構造で決まります。
この記事では「AIの判断がセッションごとに失われる」問題に対して、判断の境界を設計し、蓄積するサイクルを紹介します。
ユースケース
- Claude Codeを導入したが、毎回同じことを説明している
- AIが勝手に判断して意図しない実装をしてしまう
- AIが勝手に判断する場所を把握したい
- プロジェクト固有の制約をAIに伝える方法がわからない
注意事項
- CLAUDE.mdなしでClaude Codeを使うと、プロジェクト文脈のない汎用的な出力になります
- UserまたはLocalスコープのCLAUDE.mdには、AIへの振る舞い指示（Stop Rules等）の記載を推奨します（AIの使い方は人によるため）
- ProjectスコープのCLAUDE.mdには、技術事実（スタック、規約）のみの記載を推奨します
フロー
手順
1. CLAUDE.mdに「止まれ」を書く
Claude CodeにはいくつかCLAUDE.mdがあります。今回は以下の2つを利用します。
- Projectスコープ（リポジトリの
CLAUDE.md）: 技術スタック、ディレクトリ構造、コーディング規約など「事実」を書く - Userスコープ（
~/.claude/CLAUDE.md）: 作業の進め方、報告ルール、止まるべき条件など「振る舞い」を書く- Localスコープでも構いません
詳細は公式ドキュメント: Settingsを参照してください。
ここで最も重要なのは、UserスコープのCLAUDE.mdにStop Rulesを書くことです。
「分からないなら止まって聞け」を設定することで、Gray Zone（判断に迷う項目）のループによる改善が可能になります。
以下はStop Rulesの記載例です。
### Stop Rules
Stop implementation and report to the user if any of the following apply:
1. A branching point requiring a design decision is encountered
2. An unexpected error occurs and the cause is unknown
3. The scope of changes exceeds what the instructions anticipated
4. **You are uncertain about a requirement, constraint, or expected behavior**
**Epistemic honesty is essential.**
If you don't know, say so explicitly:
- "I'm unsure about X. Should I assume Y or wait for clarification?"
- "The instructions don't specify Z. What should I do?"
Do not silently fill gaps with "reasonable defaults."
このStop Rulesがないと、Claude Codeは「勝手に推測した状態」で実装を進めます。結果として、レビューで初めて意図とのズレに気づくことになります。
また、作業報告のルールも合わせて記載しておくと、Claude Codeの作業がブラックボックスになることを防げます。
### Report on Milestone Completion
Upon completing each Milestone or a meaningful unit of work, report the following:
1. List of changed files (output of `git diff --name-only`)
2. Summary of what was done (3 lines or fewer)
3. Handoff notes for the next step
4. Self-disclosure of any points where judgment or interpretation was required
ポイントは4つ目の「判断や解釈が必要だった箇所の自己申告」です。Claude Codeが黙って判断した箇所を可視化することで、暗黙知がセッション内に閉じることを防ぎます。
（モデルの指示追従性によると思いますが、今のところClaude Sonnetで問題なく動作しています）
2. AIへの指示書で指示を渡す
Claude Codeのターミナルの入力欄で全ての指示を出すと、指示の抜け漏れや曖昧さが生まれやすくなります。AIへの指示書は、実装指示を構造化したMarkdownドキュメントです。
AIへの指示書の基本構造は以下の通りです。
- What We Decided: 何を作るか
- Why This Design: なぜその設計か（却下した代替案も記録）
- Implementation Boundaries: Must do / Must NOT do / Gray zone（判断に迷う項目）
特にGray zoneの明示が重要です。「迷ったら止まれ」の具体化であり、Claude Codeが遭遇したときに実装を止めてユーザーに相談する項目を事前に定義します。
## Implementation Boundaries
**Must do:**
- バリデーションは既存のFormRequestパターンに従う
**Must NOT do:**
- 既存テーブルのカラム削除
**Gray zone（ユーザー判断必要）:**
- 既存APIのレスポンス形式を変更するかどうか
- エラーメッセージの日英どちらで返すか
AIへの指示書は実装完了後に解体し、判断の記録はADRやCLAUDE.mdに移譲します。あくまで「建設現場の足場」であり、恒久的なドキュメントではありません。
3. 判断を蓄積する
Step 1-2を実践すると、Claude Codeが止まった箇所 = 判断が必要だった箇所の記録が溜まっていきます。これをgray-zone.mdとして記録します。
[2026-02-20 Session]
Q: 既存APIのレスポンス形式を変更するか？
A: 後方互換を維持。新フィールドは追加のみ
Decision: 指示書に反映、CLAUDE.mdにも制約として追記
[2026-02-20 Session]
INTERRUPT: Claude Codeがマイグレーションファイルを自動生成しようとした
Reason: 既存テーブルへの影響を確認してからにしたい
Action: Must NOT doに「マイグレーション自動実行禁止」を追加
このサイクルのポイントは、gray-zoneに溜まった判断をCLAUDE.mdにフィードバックさせることです。
たとえば「ciの実行コマンドのミス」がgray-zoneに記録されたら、CLAUDE.md（.claude/rules）にci実行コマンドとして記録すべきです。
gray-zone.md（個別の判断記録）
↓ パターンが見えたら
CLAUDE.md（恒久的なルール）、`.claude/rules` （言語レベルなど分割されたルール）
↓ Claude Codeが次回から参照
判断品質の向上
さらに発展的な運用として、Claude Codeのサブエージェント機能を使ったレビューと振り返りがあります。
- critic agent: 実装者とは独立したコンテキストでコードレビューを行う
- retrospective agent: 指示書・gray-zoneレポート・criticのレビューレポートを用いた振り返りを行い分析する
これらは実装セッションの記憶を持たない独立エージェントとして動作するため、実装Claudeのコンテキストに引きずられないレビューが可能です。
4. 完了状態
以下の状態になっていれば、Claude Codeの運用サイクルが回り始めています。
- ユーザーレベルのCLAUDE.mdにStop Rulesと報告ルールが記載されている
- 実装指示をAIへの指示書（または同等の構造化ドキュメント）で渡している
- gray-zone.mdに判断記録が蓄積され、定期的にCLAUDE.mdへフィードバックしている
確認方法
以下のチェックで運用が機能しているか確認できます。
- Claude Codeが「分からない部分」で止まるようになったか（Stop Rulesが効いている）
- 同じ説明を繰り返さなくなったか（CLAUDE.mdが参照されている）
1つでも「いいえ」があれば、CLAUDE.mdやgray-zone.mdの記載を見直してみてください。