AIモデルへの指示書「CLAUDE.md」の書き方：効く制約と無効な指示の境界線
本記事は、大規模言語モデル（LLM）であるClaudeなどのAIを開発プロセスに組み込む際、その挙動を効果的に制御するための指示書（CLAUDE.md）の書き方について、実践的な知見を解説しています。筆者は、個人アプリを10本作る過程で、何がAIに「効く」指示であり、何が「効かない」指示であるかを検証し、その線引きを提示しています。
【効かない指示の原則】
AIモデルは「きれいなコード」「保守性の高い設計」「パフォーマンスを意識する」といった形容詞や、DRY原則、単一責任の原則といった一般的なベストプラクティスを「判定」することができません。これらの指示は抽象的すぎるため、モデルが遵守しているかどうかの検証手段が存在せず、実質的に無効となります。また、コードを読めば分かる情報（例：状態管理にZustandを使用していること）を記述しても、情報量が増えるだけで効果は薄いです。
【効果的な指示の原則】
最も効果的なのは、「禁止」を「機械で判定できる形」で記述することです。例えば、「純黒 `#000000` と純白 `#ffffff` を使わない」といった具体的な制約は、`grep`などのツールで違反を検出できるため、モデルの行動を厳密に制御できます。また、「〜する」という能動的な指示よりも、「〜できない」という禁止事項の方が、解釈の幅が狭く、より高い制約力を持ちます。さらに、制約にぶつかった際の「逃げ道」として、例外処理（例：Scope外として扱わないもの）を事前に明示することが、ルールの形骸化を防ぐ上で極めて重要です。
【その他の重要ポイント】
指示書は、権限の制限（Scopeの定義）や、作業の順序・依存関係（例：UI仕様書が完了するまで着手しない）を明確に記述することで、開発フロー全体を構造化できます。また、情報伝達の効率性から、状態やラベルの一覧は箇条書きよりも表形式で記述することが推奨されています。最後に、指示書は「念のため」という理由で膨らませるのではなく、常に「このルールが破られたとき、自分は気づけるか」という検証視点を持つことが、簡潔かつ強力な指示書を作成する鍵となります。
背景
近年、LLM（大規模言語モデル）を開発ワークフローに組み込むことが一般的になり、AIの出力をより高品質かつ予測可能に制御する必要性が高まっています。本記事は、単なるプロンプトエンジニアリングを超え、AIの行動を「ルールベース」で制約するための具体的な手法を提示しています。
重要用語解説
- CLAUDE.md: AIモデル（Claudeなど）に対する、プロジェクト固有のルールや制約を記述した指示書ファイル。モデルの挙動を制御するための設計図として機能する。
- DRY原則: Don't Repeat Yourself（自分自身を繰り返すな）の略。コードや情報が重複して記述されるのを防ぎ、保守性を高めるための一般的なソフトウェア開発のベストプラクティス。
- Scope: プロジェクトやタスクにおいて、変更や作業が許容される範囲や境界線。AIの権限を制限する際に、どこまでが許容範囲かを明確に定義する概念。
今後の影響
本知見を適用することで、AIによるコード生成や設計が、単なる「提案」の域を超え、厳密に管理された「制約内での実行」が可能になります。これにより、開発の品質保証プロセスが大幅に効率化し、AIを単なるアシスタントではなく、制約遵守型の「エージェント」として活用するワークフローが確立されると予想されます。