「CLAUDE.mdの4原則」は運用で本当に成り立つか検証する
X上で拡散した65行のCLAUDE.mdが掲げる4原則を運用の実例で検証する。原則自体は妥当だが、文章で書くだけでは守られず、守らせるのは機構だという結論を示す。
X（旧Twitter）で、ある投稿が広く共有された。
「Claude Codeには初日から、この65行のCLAUDE.mdが必要だった」という主張で、4つの原則を並べたものだ。
書く前に考える、シンプルさを最優先する、外科手術のように変更する、成功基準で動く。
いずれも短く、読んだ瞬間に納得感がある。
こうした原則集がバズるのは珍しくない。
AIコーディングを運用していれば、誰もが一度は似た失敗に当たり、似た教訓に行き着くからだ。
この4原則も、すでに投稿の形で広く紹介されている。
だからこの記事の狙いは、原則をもう一度紹介することではない。
各原則が実際の運用でどこまで成り立つのか、CLAUDE.mdに文章として書いた瞬間にモデルの行動が本当にその通りに変わるのか、という点を検証することにある。
原則そのものの是非ではなく、CLAUDE.mdに書いた文章がどこまで行動を変えるか、という点を実例に沿って見ていく。
書く前に考える、を破るのはどんな場面か
第一の原則は、前提を勝手に決めず、迷ったら聞くという内容だ。
一文だけ見れば当たり前のことを言っているように読める。
しかしこれは、4原則の中で最もコストが高くつく原則でもある。
LLMは、不明点に直面したとき「聞く」よりも「埋める」方向に倒れやすい。
質問して手を止めるより、それらしい値を補って先に進む方が、応答としての体裁が整うからだ。
この傾向が最悪の形で表面化するのが、出典のない数値や固有名の捏造である。
たとえば記事生成や要約のタスクで、根拠となる一次情報に具体的な数値が存在しないとき、LLMはその欠落を埋めるように、もっともらしい統計や社名を本文に混ぜ込むことがある。
書いている本人（LLM）に悪意はなく、文章として自然な形を完成させようとした結果として数値が生まれる。
厄介なのは、この種の捏造が文体としては違和感なく仕上がる点だ。
数値が具体的であるほど読者の信頼を得やすく、同時に検証もされにくい。
誤りが表面化するのは、たいてい読者や第三者が出典を辿ろうとした後になる。
しかも、この種の誤りは通常の文章校正では拾えない。
文法は正しく、文脈にも合っており、読み手が数値の妥当性を疑う手がかりが本文のどこにもないからだ。
この原則が守られる条件は明確で、根拠のない値を書く代わりに「不明」と明示するか、生成前に参照データを渡すかのどちらかしかない。
CLAUDE.mdに「不明点は聞け」と書いても、LLMは会話を止めてまで確認する挙動を自発的に選ばない。
会話を止めて聞き返すことは、タスクを完了させるという目的から見れば遠回りに映るため、埋めて先に進む方が選ばれやすい。
原則の中身は正しいが、それを促すには、出典を伴わない数値や固有名を検出して差し戻すような、生成後のチェックが要る。
書く前に考えさせることが難しいなら、書いた後に考えさせればよい、という発想の転換がここでの実務上の答えになる。
シンプルさ最優先、は何をシンプルにする話か
第二の原則は、最小限のコードで解決し、余計な推測をしないという内容だ。
一見すると、これはモデルの振る舞いに対する注文に読める。
しかし運用で効くのは、モデルの振る舞いを変えることではなく、そもそも何をモデルに解かせるかという判断の方だ。
単純な整形や置換のように、決定論的なスクリプトで確実に片付く作業がある。
こうした作業に高性能なモデルを充てても、出力の品質は上がらない。
むしろ、モデルは決定論的な変換ですら文脈によって解釈を変えてしまうため、同じ入力に対して毎回同じ出力が返る保証がなくなる。
その不安定さを飲み込んだうえで、トークンと時間だけが余分に溶ける。
ここから導ける含意は、原則の字面よりも一段深い。
「LLMにシンプルにやらせる」ことを目指すのではなく、「シンプルにできる作業はそもそもLLMに投げない」という判断を先にする方が効く。
置換や整形はスクリプトに任せ、判断や文章生成が要る部分だけをモデルに渡す。
この切り分けができていれば、原則2は自然に守られる。
切り分けをせず、あらゆる作業を一律にモデルへ投げる運用を続ける限り、CLAUDE.mdに「シンプルに」と書いても、何がシンプルにできる作業なのかの判断自体をモデルに委ねてしまい、原則は機能しない。
判断の主体を取り違えている点で、この原則は原則1と対になっている。
原則1は「モデルが判断してよい範囲」を狭める話であり、原則2は「モデルに判断させる前に、そもそもタスクを渡すかどうか」を人間が決める話だ。
どちらも、CLAUDE.mdの文言そのものより、その手前にある作業設計の方に効き目の大半がある。
外科手術のように変更する、が宣言だけでは守られない理由
第三の原則は、必要な場所だけを触り、隣接するコードやファイルには触れないという内容だ。
この原則は、宣言と実態が最も乖離しやすい。
「関係ない場所を触るな」とCLAUDE.mdに書いても、生成タスクは指定した出力先を無視し、既存の原本を上書きすることがある。
原因は、モデルが悪意を持って越境するからではない。
タスクの文脈に「編集」や「更新」に類する語が混じると、モデルは指定された新規パスよりも、意味的に近い既存ファイルの方を編集対象として選びやすくなる。
出力先をパスで固定しても、モデルにとってそのパスは数ある手がかりの一つに過ぎず、絶対的な制約としては扱われない。
さらに厄介なのは、一度この越境が起きて注意書きを足しても、しばらく運用を続けると同じ越境が再発する点だ。
CLAUDE.mdの記述は会話が長くなるほど参照の優先度が下がり、直近の文脈の方が強く働くため、過去に足した注意書きは徐々に効力を失う。
つまりこの原則は、宣言では守られない典型例になっている。
原則3が実際に守られる条件は、書き込み先を文章で指定することではなく、書き込み先そのものを物理的に固定することだ。
許可されたパス以外への書き込みをツール呼び出しの段階で拒否する仕組みがあれば、モデルがどの文脈でどう判断したかに関わらず、越境は起こり得ない。
ここで効いているのは、モデルの判断精度を上げることではなく、判断の結果が及ぶ範囲そのものを制限することだ。
判断を信頼する設計と、判断の結果を制限する設計は別物であり、外科手術のような正確さを求めるなら後者を選ぶしかない。
成功基準で動く、が最も効果を確認しやすい理由
第四の原則は、完了条件を先に定義し、それを検証できるまで作業を進めるという内容だ。
4原則の中で、これは最も守った効果を観測しやすい原則である。
完了条件を「残存ゼロ」「構造が変わっていない」「実データで確認できる」のように先に決めておき、作業後にその条件を一つずつ照合する運用は、実際に機能する。
条件が具体的であるほど、達成したかどうかを機械的に判定でき、判定の余地に解釈が入り込まない。
一方で、この原則が欠けると起きるのが、出力を確認せずに「できました」と報告する虚偽の完了である。
生成や変換のタスクを終えたモデルは、処理が走ったという事実と、処理が意図通りの結果を生んだという事実を区別せずに報告することがある。
ファイルが生成された、コマンドがエラーなく終了した、といった表面的なシグナルだけで完了と判断すれば、中身が壊れていても報告は「完了」になる。
この原則が守られる条件は、完了条件を作業前に固定し、報告の前に必ずその条件へ照合する手順を挟むことだ。
事前に基準がなければ、何を確認すればよいかという判断自体が作業後の後知恵になり、都合よく緩められる。
原則3と原則4は、同じ弱点を裏表の関係で共有している。
原則3はモデルが望ましくない場所に触れてしまう問題であり、原則4はモデルが望ましくない報告をしてしまう問題であって、どちらも行動の結果を事後にモデル自身の申告だけで判断しようとすると崩れる。
逆に言えば、行動の結果を人間や別の仕組みが機械的に照合できる形にしておけば、この2つの原則は同じ手当てで両方とも守りやすくなる。
まとめ
4つの原則はどれも妥当であり、目新しい主張ではない。
聞く前に埋めない、無駄な複雑さを持ち込まない、関係ない場所を触らない、完了を確認してから報告する。
いずれも、AIコーディングを一定期間続けた人が、高いコストを払って学ぶ内容と一致する。
ただし原則3と原則4で見た通り、これらをCLAUDE.mdに書いても、越境や虚偽の完了は文章では止まらない。
実際に効くのは、書き込み先を物理的に固定するフックや、モデルの出力を必ず通す決定論的な後段処理といった、強制の層である。
CLAUDE.mdは、モデルに何を守らせたいかを示す入口としては正しい。
しかし規律を最終的に固定するのは、テキストではなく機構の側になる。
4原則を読んで頷いた開発者がまず書くべきなのは、原則をなぞった長い指示書ではない。
その原則が破られたときに、どの機構が代わりに止めるかという設計の方だ。