Claude実践大全第12章:CLAUDE.md──ガードレールを設計する「少ないほど豊か」の逆説

本記事は、『Claude実践大全:Chat・Cowork・Codeで「動くAI」を仕事に組み込む技術』を1章ずつ紹介するシリーズの第12回です。各記事では1つの章のエッセンスをダイジェストでお届けします。

CLAUDE.mdはプロンプトではありません。会話のたびにリセットされるシステムプロンプトとは違い、自分の組織という文脈の中でClaudeがどう振る舞うかを定めた「生きた憲法」です。あらゆる会話、あらゆる統合、あらゆるワークフローに付き従う、永続的な振る舞いの仕様書。第12章は、この憲法をどう書けば本当に効くのか――そして書きすぎるとなぜ効かなくなるのか――を解き明かします。直感に反する話が、たくさん詰まっています。

「Xをするな」ではなく「Yを優先せよ」

核心はシンプルです。CLAUDE.mdの主目的は、悪い振る舞いの抑止ではなく、良い振る舞いの定義にあります。「Xをするな」と禁止を並べるのではなく、「常にYを優先せよ」と肯定形で書く。この違いは決定的です。肯定的な制約は否定的な制約よりはるかに効率的で、より創造的で文脈に即した応答を引き出すからです。

本書の医療機関の例が鮮やかです。避けるべきHIPAA違反を何百も列挙する代わりに、明快な原則を1つだけ立てる。「患者データの取り扱いはすべてHIPAA準拠のフレームワークに従う。迷いがあれば、進める前にコンプライアンス責任者に相談する」。これは禁止事項を網羅するより効果的で、制約を「恣意的な禁止」ではなく「ドメイン専門家との協働」として位置づけています。

なぜ「少ないほど豊か」なのか

プロンプトエンジニアリングには強力な法則があります。CLAUDE.mdが膨らむほど、効果はかえって下がるのです。ルールを足すたびにトークンを消費し、モデルに認知的負荷をかける。さらに厄介なことに、ルール同士が干渉し始めます。冒頭の指示が500行後の指示に書き換えられ、明確さどころか曖昧さを生む――これが「指示の劣化(instruction decay)」です。

💡 ポイント: Kubernetesクラスタ管理の200行を、たった1つの原則に圧縮できます。「クラスタ変更の提案はすべて、ダウンタイムゼロのデプロイを優先し、ロールバック手順を含めること」。未知のシナリオにも、かえって柔軟に対応できます。

解決策は、容赦ない優先順位づけ。よく設計されたCLAUDE.mdには、土台となる核心原則がせいぜい3〜5個あり、その後に最も重大なリスクへ対処する具体ルールが続きます。あらゆる状況を列挙する必要はなく、未知の状況を適切に処理する「推論の枠組み」を確立すればよいのです。

階層で分け、段階的に開示する

複数チームを抱える組織では、単一のCLAUDE.mdはたちまち手に負えなくなります。そこで階層構造です。ルートに全社共通の価値観を置き、チーム固有・プロジェクト固有の調整はサブディレクトリへ。Claudeは作業中の文脈に応じて両方を読み込み、段階的にコンテキストを得ます。全社の一貫性を保ちつつ、各チームに裁量を残し、1対話あたりのトークンコストも妥当に収まる――いいことずくめのアプローチです。