AGENTS.md
AGENTS.md の書き方
AIコーディングエージェントに毎回同じ説明をしていませんか。AGENTS.md は、その説明をプロジェクトに常駐させるための1枚です。何を書き、何を書かないかを、貼って使える雛形つきで整理します。
はじめて ・ 読了目安 約8分
AGENTS.md とは
AGENTS.md は、AIコーディングエージェント向けの指示を書く公開フォーマットです。中身はただのMarkdownで、 決まった見出しはありません。エージェントはこのファイルを読み込み、そこに書かれたルールを前提として作業します。
もともと OpenAI Codex、Amp、Google の Jules、Cursor、Factory といった複数の開発元が同じ問題に別々の ファイル名で対応していたものを、共通の名前に揃えたのが始まりです。現在は Linux Foundation 傘下の Agentic AI Foundation が管理しています。つまり、特定のベンダーに縛られない書式です。
なぜこれが「資産」になるのか
READMEとの違い
README は人間向けの入口です。プロジェクトの目的、スクリーンショット、貢献方法などが並びます。 一方 AGENTS.md には、人間には自明すぎて書かないこと、あるいは人間には細かすぎて邪魔になることを書きます。
| 内容 | README | AGENTS.md |
|---|---|---|
| プロジェクトの概要・目的 | 書く | 1行だけ |
| 導入手順・スクリーンショット | 書く | 書かない |
| ビルド・テストの具体的なコマンド | 簡潔に | 確実に動く形で書く |
| 命名規約・ファイル配置のルール | 省略しがち | 必ず書く |
| 触ってはいけない場所 | 書かない | 必ず書く |
| 作業完了の条件 | 書かない | 必ず書く |
そのまま使える雛形
まずはこの形をコピーして、自社の内容に置き換えてください。すべてを埋める必要はありません。 「コマンド」と「触らないディレクトリ」の2つだけでも効果があります。
# プロジェクト名
一行でこのリポジトリが何かを書く。技術構成もここに1行で。
例: Next.js 16 (App Router) + React 19 + Tailwind の社内向け業務ツール。
## コマンド
- `npm run dev` — 開発サーバー起動
- `npm run build` — 本番ビルド(PR前に必ず通す)
- `npm run lint` — ESLint
- `npm test -- <path>` — 単体テスト(全体実行は時間がかかるので範囲を指定する)
## ディレクトリ規約
- `app/` — 画面とAPIルート
- `components/` — 共有UI(1ファイル1コンポーネント)
- `lib/` — 副作用のないユーティリティ
- `data/` — 表示用の静的データ
## 触らないディレクトリ(読取のみ)
- `_private/` — 非公開データ
- `_archive/` — 過去の保管物
- `.tmp/` — 一時ファイル
指示がない限り、上記の編集・削除・移動をしない。
## コーディング規約
- TypeScript。関数コンポーネントのみ。
- 既存ファイルの命名・記法に合わせる。新しい書き方を持ち込まない。
- 新規依存の追加は、既存で実現できないと確認してからにする。
- コメントは「なぜ」を書く。「何をしているか」はコードで示す。
## 完了の条件
- `npm run build` と `npm run lint` が通ること。
- 変更したファイルだけをコミットすること。
- コミットメッセージは日本語、1行目は50文字以内。
## やってはいけないこと
- `.env` および認証情報をコミットしない。
- main ブランチに直接コミットしない。
- 既存のテストを、通すために書き換えない。
小さなプロジェクトなら、これくらい短くて構いません。むしろ短いほうが守られます。
# 社内見積もりツール
Next.js + TypeScript。社内利用のみ。
## コマンド
- `npm run dev` / `npm run build` / `npm run lint`
## ルール
- `_private/` は読むだけ。編集しない。
- 変更後は必ず `npm run build` を通す。
- 金額計算のロジックは `lib/price.ts` に集約する。
書くべき項目と、書き方の勘所
- 1
リポジトリのルートに AGENTS.md を作る
拡張子は .md、置き場所はプロジェクトの一番上。ファイル名はこの通りでないと自動で読まれません。
- 2
まずコマンドだけ書く
開発サーバーの起動、ビルド、テスト、Lint。この4つが書いてあるだけで、エージェントの試行錯誤がかなり減ります。
- 3
触られたくない場所を書く
顧客データ、過去の保管物、一時ファイル。「読むのはよいが変更しない」と明示します。事故の大半はここで防げます。
- 4
実際に作業させて、ずれた点を追記する
最初から完璧を目指さないこと。想定と違う動きをしたときに一行足す、を繰り返すのが一番速く育ちます。
「動くコマンド」を書くこと
複数配置と優先順位
エージェントは、作業対象のファイルから見て一番近い AGENTS.md を読みます。 つまりモノレポでは、ルートに全体共通のルールを置き、各パッケージ配下に個別のルールを置く形が取れます。
repo/
├─ AGENTS.md # 全体共通(コミット規約、禁止事項)
├─ apps/
│ ├─ web/
│ │ └─ AGENTS.md # フロント固有(Tailwind規約、コンポーネント方針)
│ └─ api/
│ └─ AGENTS.md # API固有(マイグレーション手順、認証の扱い)
└─ packages/
└─ ui/
└─ AGENTS.md # 共有UI固有(破壊的変更の禁止など)子ファイルには差分だけ
やりがちな失敗
やりがちな失敗
会社の理念や事業説明を長々と書いてしまう。
こうする
AGENTS.md は作業指示書です。背景説明は1〜2行に留め、判断に使うルールだけを書きます。
やりがちな失敗
「きれいなコードを書いてください」のような曖昧な指示。
こうする
「1ファイル1コンポーネント」「新しい依存は追加前に確認」のように、守れたか判定できる形にします。
やりがちな失敗
記述が古くなり、実際のコマンドと食い違う。
こうする
書いた内容は実際に動く状態に保ちます。動かない手順が書いてあると、エージェントはそれを信じて失敗します。
やりがちな失敗
禁止事項ばかりを並べて、やってほしいことが書かれていない。
こうする
「完了の条件」を書きます。何が終わりかが分かると、余計な作業や不足がなくなります。
やりがちな失敗
README にコピーして二重管理になる。
こうする
READMEは人向け、AGENTS.mdはAI向けと役割を分けます。重複させると必ず片方が古くなります。
やりがちな失敗
巨大なモノレポにルートの1枚だけ置く。
こうする
サブプロジェクトごとに置きます。エージェントは対象ファイルに一番近いものを読みます。
公開前チェックリスト
- ファイル名は AGENTS.md、置き場所はプロジェクトのルートか各サブプロジェクトの直下
- 起動・ビルド・テスト・Lint のコマンドが実際に動く状態で書かれている
- 触ってはいけないディレクトリが明示されている
- 完了の条件(ビルドが通る、指定ファイルのみ変更など)が書かれている
- 曖昧な形容詞ではなく、判定できる形の規約になっている
- 全体で200行を超えていない(超えたら詳細は別ファイルに逃がす)
機密情報を書かない
Next
続けて読む
Skill(SKILL.md)の作り方
「毎回同じ説明をしている作業」を手順ファイルとして資産化する方法。frontmatter の書き方と段階的読み込みの考え方を扱います。
Sub Agentサブエージェントの設計
調査・レビュー・生成を別文脈に切り出して任せる設計。どこまで自動化し、どこで人が止めるかの線引きを決めます。
MCPMCP で社内システムにつなぐ
2026-07-28 版仕様を前提に、AIツールから社内データへ安全につなぐ手順と、やってはいけない構成を整理します。
Prompt実務プロンプトの型
コツ集ではなく、業務で再利用できる4つの型。案内文・議事録・項目抽出・仕分けの実例で示します。