ルールは一か所に — AIルールファイルの書き方 (2)

AIに同じことを3回目に繰り返しているなら、 それは会話ではなく、ルールとして書き留めるときが来た合図です。

口で繰り返すルールは漏れていく

「原本データには触るな」「数字には必ず根拠をつけろ」「結果はこのフォルダに日付別で」。AIと働いていると、毎セッション同じ指示を繰り返すことになります。口で伝えるルールはセッションが終わると消え、次のセッションでは、そのルールを忘れたAIが原本を上書きしたり、根拠のない数字を出したりします。

前回で見たとおり、AIはセッションをまたいで記憶できません。であれば、ルールは会話ではなく、AIが開始時に自ら読むファイルに置くべきです。

すでに標準となったルールファイルたち

これは特定のツールの話ではなく、AIコーディングツール全般に定着した慣行です。

• CLAUDE.md — AnthropicのClaude Codeは、セッションを開始するときにこのファイルを自動でコンテキストに読み込みます。グローバルなルールとプロジェクトごとのルールを分けて置けます（公式ドキュメント、ベストプラクティス）。
• AGENTS.md — 特定の企業に縛られないオープンな標準で、「エージェントのためのREADME」を掲げています。サイト自身の集計で6万件以上のオープンソースプロジェクトが使っており、OpenAI Codex・Google Jules・Cursor・Copilotなど20あまりのツールが対応しています（agents.md）。
• Cursorのルール — プロジェクトのルールを .cursor/rules/ にファイルとして置くと、エージェントのコンテキストに注入されます（単一の .cursorrules はレガシーとして整理中、公式ドキュメント）。
• GitHub Copilotのリポジトリ指示 — .github/copilot-instructions.md に書いておくと、そのリポジトリに関するすべての会話に自動で適用されます。2025年1月21日にパブリックプレビューとして導入されました（GitHubチェンジログ）。

名前と場所は違っても、原理は一つです。常に守るべきことを一か所にまとめ、開始時に自動で読ませる。

守られるルールと無視されるルール

ルールファイルを作ることと、そのルールが実際に守られることは別の問題です。違いは文にあります。

守られるルール	無視されるルール
「原本 data/ は読み取り専用、加工物は outputs/ に」	「データに気をつけて」
「結果の数値には評価セットの版と標本数（n）を併記」	「丁寧にやれ」
「外部への掲載（トラッカー・ウィキ・メッセンジャー）は下書き確認後」	「先週の実験結果はだいたいこんな感じだった」

原則は3つです。

• 検証可能な文で — 守れたか守れなかったかを判断できて初めてルールです。「気をつけて」は判断できません。
• 短く — ルールファイルは毎セッション全文が読まれます。長いほど毎回コストがかかります。Anthropicのドキュメントも簡潔に保つよう推奨しています。
• 一度きりの事実は除く — 「先週の実験結果」のような進捗状況はルールではなくノートに。ルールには常に守るべきことだけを残します。

グローバルなファイルにはすべての作業に共通するルールを、プロジェクトフォルダのファイルにはそのプロジェクトでだけ通用するルールを置きます。

ルールで収まらないもの — 習慣と事実

一つ、線引きがあります。「今後常にこういうときはこうしろ」のように、漏れなく実行されなければならない自動化は、ルールファイルよりも、プログラムが決まったタイミングで強制する仕組み（フック）で扱うほうが安全です。ルールは読まれなければ抜け落ちることがありますが、フックは常に動作するからです。この話は後の回で改めて扱います。

そして「前回、半日かけて見つけた落とし穴」のような一度きりの事実と教訓は、ルールではなくメモリの役割です。次回に続けて見ていきましょう — 一つのファイルに一つの事実。

ルールファイルをチーム標準として定めたいなら、私たちが複数のサービスを一つの体系で運用しながら使っているルールの枠組みを、お問い合わせからお分けできます。

---

「AIを記憶する同僚として使う方法」シリーズ

1. AIはなぜ昨日を忘れるのか — セッションの忘却とコンテキストコスト
2. ルールは一か所に — AIルールファイルの書き方（現在の記事）
3. 一つのファイルに一つの事実 — 自動メモリ
4. 次のセッションの自分へ — デイリーノートと引き継ぎ
5. チームの言葉へ昇格 — トラッカー・ウィキ・Git
6. 落とし穴と4週間の導入ロードマップ