毎回自動で読まれる
会話を始めるたびに、AIがこのファイルを最初に読みます。起動方法やルールを毎回コピペしなくて済みます。
AIエージェントに毎回同じ説明をしていませんか。AGENTS.mdとCLAUDE.mdは、AIがセッション開始時に読む「プロジェクトの取扱説明書」です。
これを置くだけで、出力のばらつきが減り、事故が起きにくくなります。この資料では、2つのファイルの違い、置き場所、何を書くか、1つにまとめる方法、安全な運用までをHiro目線で整理します。
AIエージェントは、セッションが変わると前回のことを覚えていません。だから毎回「このプロジェクトは何か」「どう動かすか」「何をしてはいけないか」を説明し直す必要があります。
AGENTS.mdとCLAUDE.mdは、その説明を一度書いておけば自動で読まれる場所です。出力品質が安定する正体は、ここにあります。
会話を始めるたびに、AIがこのファイルを最初に読みます。起動方法やルールを毎回コピペしなくて済みます。
コードスタイル、命名、テスト方法を書いておくと、誰が頼んでも・いつ頼んでも同じ作法で返ってきます。
「.envを読まない」「公開前は確認する」を明記すると、AIが踏みやすい地雷を先に外せます。
一番混乱しやすいポイントです。ざっくり言うと、AGENTS.mdは「ツールをまたいで使える共通フォーマット」、CLAUDE.mdは「Claude Code専用の置き場」です。
どちらもただのMarkdownで、書く中身はほとんど同じです。違うのは「誰が読むか」です。
AGENTS.mdエージェント共通の取扱説明書(業界標準フォーマット)
CLAUDE.mdClaude Codeが読む専用ファイル
CLAUDE.mdを読む(AGENTS.mdは自動では読まない)AGENTS.mdと同じでよい| 観点 | AGENTS.md | CLAUDE.md |
|---|---|---|
| 誰が読むか | 多数のAIコーディングツール | Claude Code |
| 形式 | 標準Markdown(決まりなし) | 標準Markdown(独自拡張あり) |
| 置き場所 | ルート、モノレポは各サブにも | ルート / .claude/ / ユーザー全体 |
| 独自機能 | なし(共通仕様) | import・パス別ルール・階層読み込み |
| こう使う | 共通ルールの本体 | 本体を読み込み+Claude固有を追記 |
CLAUDE.mdを1枚。複数ツールを使う/将来使うかもならAGENTS.mdを本体にして、次の「一本化」でCLAUDE.mdと繋ぎます。
ありがちな失敗が、AGENTS.mdとCLAUDE.mdに同じ内容をコピペして、片方だけ更新がズレること。
正解は「本体は1つ、もう片方は参照させる」です。Claude Codeなら@import かシンボリックリンクで繋げます。
CLAUDE.mdの先頭で@AGENTS.mdと書くと、Claude CodeがAGENTS.mdを読み込んでから残りを追記して読みます。Claude固有の指示も足せます。Windowsでも安全です。
Claude固有の追記が不要なら、CLAUDE.mdをAGENTS.mdへのリンクにします。中身は完全に1ファイル。ただしWindowsは管理者権限が要るのでAを推奨。
# CLAUDE.md
@AGENTS.md
## Claude Code 向けの追記
- src/billing/ 配下の変更は Plan mode で進める。
- 大きな変更は実装前に計画を出す。
ln -s AGENTS.md CLAUDE.md
AGENTS.mdがある状態で/initを実行すると、Claude Codeはその内容を読み取ってCLAUDE.mdに取り込みます(.cursorrulesなどの他ツール設定も参照します)。ゼロから二重に書く必要はありません。
まずはリポジトリのルートに1枚置けば十分です。慣れてきたら、自分専用のルールや、フォルダごとのルールに分けられます。
./CLAUDE.md または ./.claude/CLAUDE.md。チームで共有するルール。Gitに入れて全員で使います。
~/.claude/CLAUDE.md。報告の言葉づかいなど、自分の好み。どのプロジェクトでも効きます。
./CLAUDE.local.md。自分のテストデータやURLなど。.gitignoreに入れて共有しません。
your-monorepo/
├─ AGENTS.md # 全体の共通ルール
├─ CLAUDE.md # @AGENTS.md を読み込む
├─ packages/
│ ├─ web/
│ │ └─ AGENTS.md # web だけのルール
│ └─ api/
│ └─ AGENTS.md # api だけのルール
└─ ...
編集するファイルに「一番近いルールファイル」が優先されます。共通ルールはルート、個別ルールは各フォルダへ。Claude Codeでは.claude/rules/でファイル種別ごとに分ける方法もあります(→保守)。
全部を最初から埋める必要はありません。最低限「概要・コマンド・禁止事項・完了条件」の4つがあれば動きます。慣れたらコードスタイルと構成を足します。
何のリポジトリで、何を作っているか。AIが最初に文脈を掴むための1〜2行。
開発サーバー、ビルド、テスト、lintの実行コマンド。AIがそのまま実行できる形で書きます。
インデント、命名、使う言語・フレームワーク。「2スペース」など検証できる粒度で書きます。
触らないファイル、読ませない情報、勝手にやらせない操作。事故防止の核です。
「テストが通る」「差分と残リスクを最後に要約する」など、終わりの定義。出力の質が一番変わる部分です。
主要ディレクトリと役割。「APIハンドラは src/api/handlers/」のように具体的に。
.claude/skills/へ、テーマ別ルールは.claude/rules/へ分けます。ルールファイルは「毎回必要な短い事実」に絞るのがコツです。
同じ内容でも、書き方で従われやすさが変わります。AIは曖昧な指示を都合よく解釈します。「正しくやって」ではなく「こうやって」と、確認できる言葉で書きます。
npm test を実行するsrc/api/handlers/ に置く.env と secrets/ は読まない
長いほど読まれにくくなります。200行を超えたら、テーマ別に分けるサインです。
複数ファイルで違うことを言うと、AIが勝手に片方を選びます。定期的に見直して重複・矛盾を消します。
見出しと箇条書きで整理します。AIも人と同じで、整理された文章のほうが追いやすいです。
まずこれを置いて、自分のプロジェクトに合わせて言葉を変えるだけでOKです。AGENTS.mdとして置いても、CLAUDE.mdとして置いても、中身の考え方は同じです。
# プロジェクト概要
このリポジトリは [何を作っているか] のプロジェクトです。
## コマンド
- 開発サーバー: npm run dev
- ビルド: npm run build
- テスト: npm test
- lint: npm run lint
## コードスタイル
- インデントは2スペース
- 命名は [規約] に従う
- 新しい依存関係は勝手に追加しない
## やってはいけないこと
- .env、秘密鍵、顧客情報、個人情報を読まない・変更しない
- 公開、投稿、削除、デプロイは実行前に必ず確認する
- 大きな変更は先に計画を出し、承認後に実装する
## どこに何があるか
- 入口: README.md / package.json
- 本体: src/
- テスト: tests/
## 完了条件(Done when)
- 関連するテスト・表示確認が通る
- 変更ファイル、確認結果、残ったリスクを最後に要約する
このリポジトリ用の AGENTS.md(または CLAUDE.md)を作りたい。
まず現在の構成、package.json の scripts、テスト・lint・ビルド方法を調べて。
その上で、初心者でも保守しやすい短いルールファイル案を提示して。
まだファイルは作成せず、内容案だけ出して。
/initで、コードベースを分析したCLAUDE.mdのたたき台を自動生成できます。既存ファイルがある場合は上書きではなく改善提案になります。
ルールファイルは一度書いて終わりではありません。「AIが同じミスを繰り返した」「毎回同じ補足を入力している」――そう気づいたら、それが追記のタイミングです。
4ブロックだけのルールファイルをルートに1枚置く。
AIが2回目の同じミス。レビューで毎回出る指摘。同じ補足を再入力。
「次からこうして」を具体的な1行で追記する。
AIが同じ間違いを2回した/コードレビューで毎回同じ指摘が出る/新メンバーに毎回同じ説明をする。この3つはルールファイル行きのサインです。
その場の会話で直した指示は、セッションが切れると消えます。次も効かせたいなら、ルールファイルに移します。
ルールファイルはセッション開始時に読まれます。途中で編集してすぐ効かない時は、会話のクリアやセッション再起動で読み直させます。
ここが一番大事です。ルールファイルは「お願い」であって、技術的な強制ではありません。 絶対に守らせたいことは、ファイルの文章だけに頼らず、権限設定やhookという「仕組み」側にも置きます。
「.envを読まない」「公開前に確認する」などの行動指針。AIはこれを読んで従おうとしますが、必ず守る保証はありません。
Claude Codeなら.claude/settings.jsonの権限denyや、実行前に走るhookで、特定の読み取り・コマンドを技術的にブロックします。
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm test)",
"Bash(git status)",
"Bash(git diff *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Bash(git push *)"
]
}
}
チーム共通のAGENTS.md / CLAUDE.md / settings.jsonはコミットします。自分専用のCLAUDE.local.mdやsettings.local.jsonは.gitignoreに入れて共有しません。
APIキー、パスワード、顧客情報はルールファイルに直書きしません。ルールファイルはGitに乗る前提です。「読まない対象」を指定するだけにします。
# 個人用ルール・設定
CLAUDE.local.md
.claude/settings.local.json
# 秘密情報
.env
.env.*
secrets/
*.pem
*.key
ルールファイルは毎回読まれるぶん、長いほど読まれにくくなります。800行のマニュアルにしないこと。 200行を超えてきたら、テーマ別・フォルダ別に分けるサインです。
Claude Codeなら.claude/rules/にtesting.md・security.mdのように分割。各ファイル1テーマにします。
ルールにパス指定を付けると、該当ファイルを触るときだけ読み込まれます。普段の文脈を軽く保てます。
毎回は要らない長い手順は、使う時だけ呼び出すskillに分離します。常時読む必要がなくなります。
your-project/
├─ CLAUDE.md # 毎回読む短い共通ルール
├─ .claude/
│ └─ rules/
│ ├─ code-style.md # コードスタイル
│ ├─ testing.md # テスト規約
│ └─ security.md # セキュリティ要件
└─ ...
<!-- -->のHTMLコメントで残せます。コメント部分はAIの文脈から除かれるので、人間用の注記をトークンを使わずに置けます。
作って終わりではなく、軽く保って、運用で育てる。この姿勢が一番効きます。
AGENTS.mdを本体に、CLAUDE.mdは@importかリンクで繋ぎます。settings.jsonのdenyやhookで技術的にブロックします。この順番で進めると、いきなり完璧を目指さずに「動くルールファイル」が1枚できます。
リポジトリのルートにAGENTS.md(またはCLAUDE.md)を新規作成する。
概要・コマンド・禁止事項・完了条件を、テンプレを下敷きに自分の言葉で埋める。
「このルールファイルを読んで、曖昧な所と抜けを指摘して」と頼み、具体化する。
新しい会話を始め、ルールが効いているか(コマンドや禁止事項を守るか)を1つ確認する。
秘密情報をdenyする設定と.gitignoreを整える。ここだけは仕組みで止める。
同じミスを見たら1行追記。長くなったら分割。これを習慣にする。
対応ツール、コマンド名、ファイルの扱いは更新される可能性があります。公開・配布前に公式ページで最終確認してください。