AIに読んでもらうルールの書き方

AIに同じ注意を何度もしている。
そんな状態になったことはないでしょうか。

「余白は8pxの倍数で」と伝えたのに、次の実装では13pxが出てくる。
指摘すればその場では直りますが、翌日の作業でまた同じ間違いが繰り返されます。

私も同様の問題があったため、注意した内容をファイルに書き出し、作業を始める前に読んでもらうことにしました。
それでも守られませんでした。

原因は、AIの理解力ではなく、私の書き方にありました。
AIが理解できない文章でルールを書いていたからです。

この記事では、私がAIに読んでもらうルールを書くときに使っている基準を紹介します。

私がAIに渡しているルールファイル

先に、この記事で「ルール」と呼んでいるものを整理します。

ルールは、役割ごとに4階層へ分けて管理しています。

workspace/
├── CLAUDE.md                    全体の入口（Codex用は AGENTS.md）
├── .claude/rules/general.md     全体の共通ルール
├── docs/
│   ├── web-coding-rules.md      分野別ルール（Web・デザイン・検証・文章）
│   ├── design-rules.md
│   ├── verification-rules.md
│   └── coding-rules/            さらに詳細な個別ルール
│       ├── 02-html.md
│       ├── 03-css.md
│       └── 04-responsive.md
├── tools/                       完了前に通すゲート
└── 01_Projects/
    └── <案件フォルダ>/CLAUDE.md   その案件だけのルール

それぞれの役割は次のとおりです。

• 入口ファイル（CLAUDE.md / AGENTS.md）: 作業のたびに必ず読まれる場所。判断の原則と、どのルールをいつ読むかの案内を書く
• 分野別ルール（docs/ 直下）: Web、デザイン、検証、文章など、作業の種類ごとの実務ルール
• 個別ルール（docs/coding-rules/）: HTML、CSS、レスポンシブなど、さらに詳細な領域のルール
• 案件ルール（案件フォルダの CLAUDE.md）: その案件だけの決めごと

私はClaude CodeとCodexを併用しているため、入口ファイルだけが2つに分かれています。
分野別ルールから下は共通で、どちらのAIも同じファイルを読みます。

これ以降で「ルール」と書いているのは、この4階層すべてが対象です。
節によって主に関係する階層が違うので、そのつど補足します。

ここからは、ルールの書き方についてご紹介します。

具体的な基準がないルールは守られない

私が最初に書いた間違いルールの一つが「大きすぎる変更はしない」でした。

私と長年仕事を一緒にしている人が読めば、「大きすぎる変更はしない」と伝えるだけでなんとなくニュアンスは分かってくれるかもしれません。
しかし、AIから見ると、何をもって「大きすぎる」のかが書かれていないので基準が分からず、判断ができないか、間違った判断になってしまいます。

これと同じことは「なるべく」「適切に」「注意する」といった指示でも起きます。
これらには明確な基準が含まれていません。
基準のないルールは、その都度違う判断で作業されます。

ルールが効くかどうかは、指示の丁寧さで決まるものではありません。
AIが自分でルールを守れたかを判定できる基準があるかどうかで決まります。

これは4階層のどこに書くルールでも共通です。

数値と禁止形と確認コマンドのどれかを入れる

私はルールを1つ書くたびに、次の3つのどれかを必ず含めるようにしています。

• 数値（上限・件数・期限）
• 禁止形（〜しない）
• 確認コマンド

たとえば、先ほどの「大きすぎる変更はしない」は数値を入れて書き直せます。

NG: 大きすぎる変更はしない
OK: 1コミットの変更は10ファイル未満。超えそうなら分割計画を先に出す

余白の指示なら、禁止形が使えます。
これは docs/coding-rules/ に置いている個別ルールの例です。

NG: 余白の付け方に注意する
OK: セクション間の縦余白は margin-bottom で作る。margin-top で余白を作らない

作業の終わりに通す手順は、確認コマンドをそのまま書きます。

NG: 完了前にコードをチェックする
OK: Webコードを編集したら、完了前に tools/web-coding-gate.sh --target <対象パス> を実行する

案件ごとの数値を、判定できるルールにする

余白やフォントサイズ、カラーなどの値そのものは、すべての案件で共通にするものではありません。案件ごとのデザインルールやスペーシングトークンで値を決め、OKとNGの境目を数値や具体的な条件で書くと、AIが判定できる形になります。ここでの64pxは一例です。

NG: なるべく余白を広めに
OK: セクション間の余白は64px以上

自分で解釈せずとも明確に理解できる内容になっています。

ルールにAIが考えなくても分かる指示を入れるようにしてから、同じ間違いを指摘する回数が減りました。

基準を文にできないときはOK例とNG例を明示する

数値にできない内容もあります。

デザインの印象、文章のトーン、命名の善し悪し。
このあたりは、上限や禁止形だけでは表現しきれません。

その場合、私は基準を無理に言語化せず、OK例とNG例を提示して方向性を理解してもらうようにしています。

抽象的な説明を詳細に書くより、対になった具体例を提示するほうが伝わりやすくなります。
説明文だけのルールを書いてしまったときは、例を1組足せないかを考えます。

ルールは置き場所で効き方が変わる

ルールの内容が改善されても、ルールの置き場所を間違えると使われません。

私は次のように分けています。

• 全体に効かせたいルールは、docs/ の分野別ルールに置く
• 特定の領域だけに効かせたいルールは、docs/coding-rules/ の個別ルールに置く
• その案件だけに効かせたいルールは、案件フォルダの CLAUDE.md に置く

入口ファイルには、原則としてルール本体を書きません。
毎回読まれる場所なので、判断の原則と、どのルールをいつ読むかの案内に留めます。

新しく書くときは、まず既存のルール内容で足りないかを確認します。
効かせたいルールに近いファイルがあればそこへ追記し、無いときだけ新規に作ります。

置き場所を決めずに書き足していくと、同じ内容が何か所にも散らばります。
そうなると、片方だけを更新したときに内容がずれていきます。

矛盾したときは対象範囲が狭い文書を優先する

ルール文書が増えると、矛盾は必ず出ます。

そのため、どちらを優先するかを入口ファイルに書いてあります。
私が使っている順番は次のとおりです。

1. 対象ファイルにいちばん近い個別ルール（docs/coding-rules/03-css.md など）
2. 案件フォルダの CLAUDE.md
3. 分野別ルール（docs/web-coding-rules.md など）
4. 全体の入口ファイル（CLAUDE.md / AGENTS.md）

狭い範囲の文書を優先する理由は、現場に近いほど事情を反映しているからです。
案件ごとの事情は、全体ルールでは書ききれません。

もう一つ決めているのは、下位の文書で上位の文書を丸ごと書き写さないことです。

同じ内容が2か所にあると、更新のたびに両方を直す必要が出てきます。
上位の文書は参照だけ示して、その領域だけの差分を書きます。

ルールの文章化もAIに任せる

ここまで書き方の話をしてきましたが、ルール文書そのものは私が書いていません。

決めごとが固まった時点で、文章化はすべてAIに任せています。
私が用意するのは、守ってほしい内容と、その理由です。

自分で書かなくなった理由は2つあります。

1つは、書き方の基準をルール化してあるため、AIのほうが安定して形式を守れることです。
数値・禁止形・確認コマンドのどれかを入れる、1ルールは1〜2行に収める、といった条件は、私が手で書くと抜けます。

もう1つは、既存のルールを探す作業を任せられることです。

書き始める前に既存を検索してもらう

文章化を頼むときに、毎回セットで指示しているのが既存ルールの検索です。

同じ内容がすでにどこかにある場合が多く、文書が10を超えたあたりから、私自身も全体を把握できなくなりました。

指示に含めているのは次の2つです。

• 要点のキーワードで docs/ 配下と案件の CLAUDE.md を検索する
• 近い記述があれば、新規に追記せず既存の文書へ統合する

検索は目視ではなく、コマンドで実行してもらいます。

grep -rin "<要点のキーワード>" docs/

-r でディレクトリ全体、-i で大文字と小文字の区別なし、-n で行番号を表示します。
どのファイルの何行目に近い記述があるかが、一覧で返ってきます。

このとき、キーワードは1語で終わらせません。
「余白」「margin」「スペース」のように、同じ内容が別の言葉で書かれていることがあるため、2〜3語で試してもらいます。

見つかった重複はAIに直させない

もう一つ決めているのは、矛盾や重複が見つかったときに、AIへ判断させないことです。

統合するか、片方を削るか、言い換えるか。
この判断は、決めごとの経緯を知らないと選べません。

AIには、見つけた時点で止まって報告するところまでを任せています。

1文書150行を超えたら追記でなく整理する

ルールは運用するほど増えます。

放っておくと、1つの文書が数百行になっていきます。
そこで私は、目安の数字を決めました。

• 1文書は約150行まで
• 1つの節は約12項目まで
• 1つのルールは1〜2行の命令文に収める

この目安を超えたら、追記ではなく統合・分割・短縮を検討します。

毎回読んでもらう文書が長くなるほど、1つ1つのルールの重みは下がります。
20項目の中の1行と、5項目の中の1行では、同じ文でも扱いが変わってきます。

行数の上限を決めておくと、書き足したくなったときに、どこを削るかも一緒に考えるようになります。

人が書いた値をAIの判断で整形させない

これは、実際に困ってから足したルールです。

私が指定したコード例や設定値を、AIが親切のつもりで変えてしまうことがあります。
単位を揃える、命名の流儀を合わせる、書式を統一する。

見た目は整いますが、その値に理由があった場合に、意図ごと消えます。

そこで、私が提示したルール文・コード例・設定値は、そのまま記録すると決めました。
整形、補正、単位変換、命名変更は、AIの自己判断ではさせません。

新しいルールを足した結果、過去の設定値を変えたほうがよさそうに見えることもあります。
その場合も、変更する前に一度確認させます。

ルールはAIが判定できる状態にしないと効かない

AIに読んでもらうルールを書くときに私が注意していることは以下です。

• 数値・禁止形・確認コマンドのどれかを入れる
• 基準を文にできないときはOK例とNG例を提示する
• 入口・分野別・個別・案件のどこに置くかを決める
• 矛盾したときは対象範囲が狭い文書を優先する
• 文章化はAIに任せ、書き始める前に既存を検索してもらう
• 1文書150行を超えたら追記でなく整理する
• 私が書いた値はAIの判断で整形させない

ルールを増やすことと、AIが守れるルールを持つことは別の作業です。

書いた本人が読み返して、守れたかどうかを判定できないルールなら、AIにも判定できません。
まずはこの1点だけを確認してみることをおすすめします。