「昨日は一発で狙いどおりだったのに、今日は同じ指示なのに雑な仕上がり」——Claude Code のこの「日によるブレ」、あなたのせいでも、運のせいでもありません。
うまくいった日のプロンプトを再現しようにも、何が良かったのか思い出せない。「AIで効率化するはずが、AIの機嫌をうかがう時間が増えている」と感じたら、黄色信号です。
結論からお伝えすると、ブレの正体は「毎回書くプロンプトに頼っていて、常設のルールがないこと」です。プロンプトは一時的、構造は永続的。Claude Code が毎セッション自動で読み込む CLAUDE.md に「仕事の型」を常設すれば、出力の質は安定に向かいます。
この記事では、実運用中の CLAUDE.md「7つのルール」を全文公開し、導入手順（3ステップ）・効きの確認方法・よくある失敗まで正直にお伝えします。
同じ指示なのに、AIの仕事の質が日によって違う理由
Claude Code は、セッション（会話）が終わると、その中でのやりとりを引き継ぎません。「今日うまくいった指示・注意・修正」は、明日のセッションには残っていないのです。
昨日は「完了の基準」「やってほしくないこと」「報告の仕方」が会話の中に積み上がっていた。今日はゼロから。AIの能力が変わったのではなく、渡している前提の量が日によって違うのです。
よく挙がる対策「/clear でリセット」「セッション分割」も有効ですが、どちらも「悪くなった状態を消す」対処。「良い状態を毎回再現する」仕組みではありません。消す仕組みと、積む仕組みは別物です。
結論：CLAUDE.mdに「仕事の型」を常設する
Claude Code の公式ドキュメント（Memory ・2026年7月時点）によると、CLAUDE.md は毎セッション開始時に自動で読み込まれる、永続的な指示ファイルです。全プロジェクト共通で効く User スコープ（~/.claude/CLAUDE.md）と、そのプロジェクトだけに効く Project スコープ（./CLAUDE.md）など複数の置き場所があり、複数ある場合は上書きではなく連結で読み込まれます（このほか組織全体用・個人ローカル用のスコープもあります。使い分けは手順の章で扱います）。
ここで大事なのは、何を書くか。出力の「質のブレ」に効くのは、技術スタックやディレクトリ構成といった設定情報よりも、完了の基準・確認の仕方・やってはいけないこと——人間の新人に渡す「仕事の型」です。
ひとつ正直に補足すると、公式自身が「強制される設定ではなくコンテキスト扱い・厳密な遵守の保証はない」と明言しています。それでも常設する価値は、守られる確率を毎セッション底上げできることと、ブレたら「ルールの何番に戻って」と言える基準になること。詳しくは後半の「よくある失敗」で扱います。
実運用CLAUDE.mdの「7つのルール」全文公開
ここからが本題です。毎日の実運用で ~/.claude/CLAUDE.md に常設している「仕事の型・7つのルール」を、固有の社内情報だけ外した汎用版としてそのまま公開します。
公式推奨の 1ファイル200行以内に対し、この7つのルールはわずか十数行。余裕で収まります。
# 作業の型（7つの運用ルール）
## 必ず守る7つ
1. **完了を機械的に判定する**：着手前に「完了」を1行で定義する（例：このテストが通る／このコマンドが正常終了する／この見出しが本文に入る）。書けない場合は、何が決まれば書けるかを質問してから進む。
2. **複数解釈を勝手に選ばない**：指示に2つ以上の読み方がある場合、黙って1つを選ばない。候補を列挙し推奨を1つ添えて確認する。どの解釈でも成果物が変わらない場合だけそのまま進めてよい。
3. **ついで改善を禁止**：依頼されていない変更を実装しない。「ついでに直した」「より良い設計にした」は禁止。隣の改善点は実装せず提案として列挙する。
4. **「動いた」でなく「検証した」を報告**：完了報告には実行した検証（コマンド・戻り値・テスト結果・表示確認）の証拠を含める。実行していないものを「動くはず」と書かない。スキップした検証は理由まで明記。
5. **同じエラーへの修正は2回まで**：2回失敗したら3回目の変種を試さない。現状・試したこと・残る仮説を短く報告し、方針転換する。
6. **完了前に初見レビュー**：初めて読む人として自分の変更を見直す。壊れうる隣接箇所を1つ挙げる。懐疑的なシニアの反論を書き、それに答える。
7. **確信度と進捗を正直に**：自信のない箇所には確信度（高・中・低）を付け、中・低なら確認してから進むか聞く。長い作業は区切りごとに「完了したこと／次にやること／気になっていること」の3点だけ報告。「問題なく進んでいます」だけの報告は禁止。
以下、それぞれが「なぜブレに効くのか」を短く添えます。
ルール1：完了を機械的に判定する
なぜ効くか：「完了」の解釈をAI任せにすると、仕上げの深さが日によって変わるからです。
着手前に「このコマンドが正常終了したら完了」と1行で決めさせるだけで、途中で止まる・やりすぎる、の両方が減ります。
ルール2：複数解釈を勝手に選ばない
なぜ効くか：「今日は雑」と感じるブレの多くは、能力の差ではなく解釈の取り違えだからです。
解釈が割れたら候補を並べて確認させる。これだけで「頼んだものと違う」が構造的に減ります。
ルール3：ついで改善を禁止
なぜ効くか：頼んでいない変更こそ、後から見つかる「勝手に壊れた」の温床だからです。
改善案は実装ではなく提案として出させれば、判断はあなたの手に残ります。
ルール4：「動いた」でなく「検証した」を報告
なぜ効くか：検証の証拠を報告の条件にすると、「動くはず」のまま混ざる未検証コードが減るからです。
推測の「できました」と実測の「できました」を、読む側が区別できるようになります。
ルール5：同じエラーへの修正は2回まで
なぜ効くか：ハマったときの「微修正の無限ループ」を構造的に打ち切れるからです。
2回で打ち切らせると、泥沼の時間が「方針転換の判断材料」に変わります。
ルール6：完了前に初見レビュー
なぜ効くか：提出前のセルフレビューを義務にすると、雑な仕上げが手前で止まるからです。
「初めて読む人として見直す」「壊れそうな隣接箇所を1つ挙げる」を完了の条件に入れると、人間のレビューに届く前に粗が1段減ります。
ルール7：確信度と進捗を正直に
なぜ効くか：「問題なく進んでいます」という中身のない報告を禁止し、不確かさを見えるようにするからです。
確信度ラベルがあれば、どこを重点確認すべきか一目で分かります。
自分のCLAUDE.mdに入れる手順（3ステップ）
導入は3ステップ、数分で終わります。
全プロジェクト共通で効かせたい場合は User スコープ＝ ~/.claude/CLAUDE.md に置きます（ホームディレクトリの .claude フォルダ内。なければ作成します）。特定の案件だけに効かせたい場合はプロジェクト直下の ./CLAUDE.md です。両方に書いた場合は上書きではなく連結で読み込まれるので、「仕事の型は User 側・案件固有ルールは Project 側」の分担がおすすめです。
前章のコードブロックをそのままコピーして貼り付けます。自分の業務に合わせて言い換えても構いませんが、その際は公式のガイドにある基準——「この行を消したら Claude はミスをするか？」を各行に自問し、しないなら削る——を守ってください。全体で200行以内が公式推奨です。
CLAUDE.md は「セッション開始時」に読み込まれるため、いま開いているセッションには反映されません。いったんセッションを終了し、新しく起動し直します。起動後に「いまの作業ルールを要約して」と聞いて、7つのルールが返ってくれば常設完了です。
効いているかの確認方法
貼って終わりにせず、効き目を確認します。目安は、公式が「CLAUDE.md に書き足すべきタイミング」として挙げる2つの基準です。
- 同じミスを2回した時
- 前のセッションと同じ訂正をまた打っている時
これを裏返すと、「同じ訂正を打つ回数が減っているか」が、効きの判定基準になります。導入後の1週間で、次の3点を観察してみてください。
- 着手前に「完了の定義」を自分から言うようになったか（ルール1の効き）
- 曖昧な指示に、候補＋推奨で聞き返すようになったか（ルール2の効き）
- 完了報告に検証の証拠が付くようになったか（ルール4の効き）
そしてもうひとつ。出力がブレたとき、長い説明をやり直す代わりに「ルール4に従って、検証の証拠を付けて報告し直して」と番号で戻せます。軌道修正のコストがまるで違います。ここがポイントです。
よくある失敗3つ（正直に書きます）
CLAUDE.md は万能ではありません。つまずきやすい3点を、確認できた事実の範囲で挙げます。
失敗1：「書けば必ず守られる」と思ってしまう
公式が明言しているとおり、CLAUDE.md は「強制される設定」ではなく「コンテキスト」です。7つのルールを入れても破られる日はあります。「守られる確率を上げる装置」と「ブレたときに戻る基準」——この2つとして使うのが正しい期待値です。「何があっても止めたい」禁止事項（本番環境の変更など）は、強制力のある hooks 側で止めるのが公式の推奨です。
失敗2：張り切って書きすぎて、逆に効かなくなる
公式ドキュメントには「肥大化した CLAUDE.md は、本当に守ってほしい指示を無視させる原因になる」という趣旨の警告が明記されており、推奨は1ファイル200行以内です。増やす前に、STEP 02 の基準「この行を消したらミスが起きるか？」に立ち返る。どうしても強調したい行に IMPORTANT や YOU MUST を付けるのは、公式も認める書き方です。
失敗3：ブレの原因を、すべて自分の書き方のせいにする
2026年3月から4月にかけて、Anthropic 側の原因による品質低下の期間が実際にありました（PC Watch・2026年4月24日報道）。CLAUDE.md の書き方がどれだけ適切でも、提供側の問題でブレる期間は存在し得ます。急に全体的な劣化を感じたら、自分の設定を疑う前に公式の障害情報を確認する。この切り分けができること自体が、「基準を常設している人」の強みです。
まとめ：プロンプトは一時的、構造は永続的
要点は3つです。
- ブレの主因は、モデルの気分ではなく「前提が毎回リセットされる構造」。毎セッション読み込まれる CLAUDE.md に「仕事の型」を常設する
- 常設する中身は設定情報よりも「完了の定義・解釈の確認・検証つき報告」といった運用ルール。本記事の7つのルール（公式推奨200行のごく一部）はそのまま貼って使える
- ただし強制力はない。「守られる確率を上げる＋ブレたら番号で戻す」が正しい使い方。書きすぎ（200行超）と提供側起因のブレには別の対処を
プロンプトは一時的、構造は永続的。昨日の正解を、明日の初期値にする——CLAUDE.md は、そのための置き場所です。
CLAUDE.md と Skills はどちらも「毎回の説明を減らす」ための仕組みですが、役割が違います。使い分けは Claude Codeの「Skills」と「CLAUDE.md」とは？ で説明しています。
設定そのものをひと通り整えたい方は Claude Codeの初期設定 もどうぞ。
まずは ~/.claude/CLAUDE.md に7つのルールを貼るところから、次のステップに進む準備ができました。Web サイト制作や AI 業務効率化の相談は、お問い合わせフォームから気軽にどうぞ。
AI活用のご相談はこちらから
「AIを仕事に取り入れたいけれど、どこから手をつければいいか分からない」
——そんなときは、お気軽にご相談ください。
どの作業をAIに任せられるか、一緒に整理するところからお手伝いしています。
