SASmall AI System

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 が管理しています。つまり、特定のベンダーに縛られない書式です。

なぜこれが「資産」になるのか

モデルもツールも1年で入れ替わりますが、AGENTS.md はプレーンなMarkdownです。 Claude Code から Codex CLI に乗り換えても、そのまま読まれます。書いた時間が無駄になりにくい層です。

READMEとの違い

README は人間向けの入口です。プロジェクトの目的、スクリーンショット、貢献方法などが並びます。 一方 AGENTS.md には、人間には自明すぎて書かないこと、あるいは人間には細かすぎて邪魔になることを書きます。

内容READMEAGENTS.md
プロジェクトの概要・目的書く1行だけ
導入手順・スクリーンショット書く書かない
ビルド・テストの具体的なコマンド簡潔に確実に動く形で書く
命名規約・ファイル配置のルール省略しがち必ず書く
触ってはいけない場所書かない必ず書く
作業完了の条件書かない必ず書く

そのまま使える雛形

まずはこの形をコピーして、自社の内容に置き換えてください。すべてを埋める必要はありません。 「コマンド」と「触らないディレクトリ」の2つだけでも効果があります。

AGENTS.md
# プロジェクト名

一行でこのリポジトリが何かを書く。技術構成もここに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 ブランチに直接コミットしない。
- 既存のテストを、通すために書き換えない。
標準版。中規模以上のプロジェクト向け。

小さなプロジェクトなら、これくらい短くて構いません。むしろ短いほうが守られます。

AGENTS.md(最小版)
# 社内見積もりツール

Next.js + TypeScript。社内利用のみ。

## コマンド
- `npm run dev` / `npm run build` / `npm run lint`

## ルール
- `_private/` は読むだけ。編集しない。
- 変更後は必ず `npm run build` を通す。
- 金額計算のロジックは `lib/price.ts` に集約する。
最小版。まずここから始めて、ずれた点だけ足していく。

書くべき項目と、書き方の勘所

  1. 1

    リポジトリのルートに AGENTS.md を作る

    拡張子は .md、置き場所はプロジェクトの一番上。ファイル名はこの通りでないと自動で読まれません。

  2. 2

    まずコマンドだけ書く

    開発サーバーの起動、ビルド、テスト、Lint。この4つが書いてあるだけで、エージェントの試行錯誤がかなり減ります。

  3. 3

    触られたくない場所を書く

    顧客データ、過去の保管物、一時ファイル。「読むのはよいが変更しない」と明示します。事故の大半はここで防げます。

  4. 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行を超えていない(超えたら詳細は別ファイルに逃がす)

機密情報を書かない

AGENTS.md はリポジトリに入り、AIに読まれ、多くの場合そのままGitHubに公開されます。 APIキー、顧客名、内部URL、個人名は書かないでください。必要なら「認証情報は .env を参照」とだけ書きます。