はじめに — 毎回、同じ説明してませんか？

AIにコードを任せられるようになって、たしかに開発はめちゃくちゃ速くなりました。Cursor、Codex、Claude Code、GitHub Copilot……どれを使っても、「ざっくり頼むと、それっぽいコードが返ってくる」のが当たり前になってきましたよね。

でも、正直に言うと、僕はある日ふと気づいたんです。

毎回、同じことを説明してへん？ って。

「このプロジェクトは npm じゃなくて pnpm を使ってます」
「テストは vitest で、コミット前に必ず走らせてください」
「src/legacy/ の中は触らないでください」

セッションを開くたびに、これを書いている。AIは賢いんですけど、賢いがゆえに「言われてないこと」は平気でやります。npm install を叩いてロックファイルを壊したり、独自の命名規約を無視したり、頼んでないのに別のディレクトリまで「ついでに」直してきたり。

そして3回目くらいに同じ注意をしている自分に気づいて、めっちゃもったいないな と思ったわけです。だってこれ、人間でいうと、新しいメンバーが入るたびに、口頭で同じオンボーディングを繰り返してるのと同じ状態なんですよね。

この「毎回の説明」を、たった1つのファイルにまとめて、リポジトリに置いておけるとしたら、どうでしょう。しかも、Cursorでも、Codexでも、Claude Codeでも、どのツールでも同じファイルを読んでくれる としたら。

それが、今回の主役 AGENTS.md です。

この記事では、AGENTS.md が何者なのか、なぜ2026年に標準として一気に広がったのか、何を書いて何を書かないのか、そして「明日から自分のリポジトリに置ける」レベルの実物サンプル・プロンプト・CIチェックまで、AI開発にまだ不慣れな方でも迷わないように、ひとつずつ噛み砕いて書いていきます。

先に結論だけ言っておきますね。AGENTS.md は、AIエージェントに「このリポジトリの歩き方」を渡す、たった1枚の取扱説明書 です。そして完璧じゃなくていい。まずは10行から始めれば十分です。

AGENTS.md って、そもそも何？（無知の無知のままでもOK）

ひとことで言うと、AGENTS.md は「AI用のREADME」 です。

ここでいきなり用語の整理をしておきましょう。知ってる人には当たり前でも、ここでつまずくと先が全部ぼやけるので。

README.md … 人間のための説明書。プロジェクトの概要、使い方、貢献ガイド。GitHubのトップに表示されるあれです。
AGENTS.md … AIコーディングエージェントのための説明書。ビルド手順、テストの走らせ方、コードの書き方の決まり、触っちゃいけない場所……みたいな、「人間のREADMEに書くとごちゃつくけど、AIには絶対伝えたいこと」を置く場所。

公式サイト（ https://agents.md/ ）でも、ずばり 「a README for agents（エージェントのためのREADME）」 と表現されています。

登場人物は3人だけ

仕組みは難しくないので、登場人物で整理しましょう。

エージェント … あなたの代わりにコードを読んだり書いたりするAI（Cursorの中の人、Codex、Claude Codeなど）。
リポジトリ … あなたのコードが入っているフォルダ全体。
AGENTS.md … リポジトリの中に置く、AIへの取扱説明書。

そして大事なのが、エージェントは作業を始めるとき、自動で AGENTS.md を探して読む という点です。あなたが「これ読んでね」と毎回貼り付けなくても、ファイルがそこにあれば勝手に拾ってくれる。これがREADMEと決定的に違うところで、AGENTS.md は「置いておくだけで効く」んです。

「最寄りが勝つ」というルール

もうひとつだけ。エージェントは、編集しようとしているファイルから見て いちばん近い（最寄りの）AGENTS.md を優先して読みます。英語だと closest file wins（最寄りのファイルが勝つ）と言われるルールです。

たとえば大きなプロジェクトで、ルートにもAGENTS.mdがあって、packages/api/ の中にもAGENTS.mdがあったとします。packages/api/ の中のコードを直すときは、packages/api/AGENTS.md のほうが優先される。家全体のルールと、各部屋のローカルルールがあって、その部屋にいるときは部屋のルールが優先、みたいなイメージですね（このモノレポの話は後でちゃんとやります）。

ちなみに、あなたがチャットで直接出す指示は、AGENTS.mdより強い です。だからファイルに書いた内容が古くても、その場で「今回はこうして」と言えば上書きできます。安心してください。

なぜ2026年に「標準」になったのか

ここは事実ベースでいきましょう。AGENTS.md がここまで広がったのには、ちゃんと理由があります（2026年6月時点）。

採用規模がでかい … 公式サイトによると、GitHub上で 6万を超えるオープンソースプロジェクト がすでにAGENTS.mdを使っています。
特定ツール専用じゃない … OpenAI Codex、Google の Jules、Cursor、Amp、Factory といった面々の協調から生まれた、ツール非依存（vendor-agnostic） のオープン標準です。Claude Code、GitHub Copilot、Aider、Gemini CLI なども対応しています。
ちゃんとした後ろ盾がある … 現在は Agentic AI Foundation（Linux Foundation の傘下） が管理・発展を担っています。一企業の気まぐれで消える心配が小さい。

ここがポイントなんですけど、これまでは .cursorrules（Cursor用）、CLAUDE.md（Claude用）みたいに、ツールごとにバラバラの設定ファイル を書いてました。ツールを乗り換えるたびに書き直し。チームでツールが違えば、全部メンテ。これ、地味にしんどかったんですよね。

AGENTS.md は、その乱立を 「1枚にまとめて、みんなで読む」 に変える動きなんです。

	README.md	AGENTS.md
読む相手	人間	AIエージェント
中身	概要・使い方・貢献ガイド	ビルド/テスト手順・規約・境界
読まれ方	人がブラウザで開く	エージェントが自動で発見して読む
書く粒度	人に伝わればOK	機械が実行できる正確さが要る

なぜ重要なのか — Prompt Engineering から Context Engineering へ

ここで少し、考え方の話をさせてください。AI時代のエンジニアリングって、いま静かに重心が移ってるんです。

少し前まで、僕らは Prompt Engineering（プロンプト設計） に夢中でした。「どう頼めば、AIがいい答えを返すか」。これはこれで大事です。でも、毎回のプロンプトにプロジェクトの前提を盛り込むのって、すぐ限界がきます。会話のたびに同じ前提を書き直すことになるから。

そこで出てくるのが Context Engineering（文脈設計） です。ざっくり言うと、「AIに毎回説明するのをやめて、文脈そのものを設計して、置いておく」 という発想。プロンプトは使い捨ての一言、文脈は資産。この違い、けっこう本質的だと思うんです。

AGENTS.md は、まさにこの Context Engineering の いちばん身近で、いちばん効く実物 です。会話に文脈を沈めるんじゃなくて、リポジトリにコミットして、全セッション・全エージェント・全チームメンバーで共有する。一度書けば、明日の自分も、来週入る新メンバーも、明後日のAIセッションも、同じ文脈の上でスタートできる。

そして、これはエンジニアの役割の変化そのものでもあります。実装者から、文脈設計者へ。 コードを1行ずつ手で書く人から、「AIが正しく動くための文脈を設計する人」へ。AGENTS.md は、その新しい役割の、いちばん最初の成果物だと僕は思っています。

「AIがすごい」で終わらせない。人間が What（何を）と Why（なぜ）と境界を設計して、How（どう実装するか）をAIに渡す。 この分担を、ファイル1枚で表現できるのが AGENTS.md なんです。

何を書くか — セクション設計と「いちばん大事な原則」

じゃあ中身は何を書くのか。公式や、世界中の優れたAGENTS.mdを見ていくと、だいたい次のセクションに落ち着きます。

Project overview（概要） … 何のプロジェクトで、技術スタックは何か。1〜2文でOK。
Commands（コマンド） … インストール・起動・ビルド・テストの、そのままコピペできる正確なコマンド。
Testing（テスト） … どう走らせるか、何を満たせばOKか。
Code style（コード規約） … フォーマット、命名、import、設計の好み。
Boundaries（境界） … 触っちゃいけない場所、やってはいけないこと。
Git & PR … コミットメッセージの形式、PRの作法。
Gotchas（ハマりどころ） … このプロジェクト特有の落とし穴。

ここで、この記事でいちばん覚えて帰ってほしい原則 を言います。

AGENTS.md には「AIが推論できないことだけ」を書く。

どういうことか。AIは賢いので、コードを見れば分かることは、わざわざ書かなくても分かります。「TypeScriptを使ってる」なんてのは tsconfig.json を見れば一発です。それをAGENTS.mdに書くのは、ただのノイズ。

逆に、コードを見ても分からないこと ＝ AIが絶対に推論できないことこそ、書く価値があります。

「npm じゃなく pnpm を使う」（ロックファイルから推測できるとは限らない、明示が安全）
「APIの命名は getXxx で統一（fetchXxx は使わない）」（チームの決め事）
「src/legacy/ は凍結。絶対に変更しない」（歴史的経緯）
「コミット前に必ず pnpm test を通す」（運用ルール）

この「推論できないことだけ書く」を守るだけで、AGENTS.md は短く、効いて、腐りにくくなります。

コード例① 汎用的な AGENTS.md サンプル（そのまま叩き台にどうぞ）

実物を見たほうが早いですよね。下は、よくあるWebアプリ（TypeScript + pnpm）を想定した、完全に汎用のサンプルです。あなたのプロジェクトの固有名やコマンドに差し替えて使ってください。

# AGENTS.md

このリポジトリは、TypeScript + React + Vite で作られたWebアプリです。
あなた（AIエージェント）は、このプロジェクトの規約に従って作業してください。

## Commands（コマンド）
- 依存インストール: `pnpm install`
- 開発サーバ: `pnpm dev`
- ビルド: `pnpm build`
- テスト: `pnpm test`
- Lint: `pnpm lint`

## Testing（テスト）
- 変更したコードには、必ず対応するテストを追加・更新する。
- コミット前に `pnpm test` と `pnpm lint` を実行し、すべて green にする。
- テストは Vitest を使う。E2E は Playwright。

## Code style（コード規約）
- TypeScript の strict モードを前提にする。
- API取得関数の命名は `getXxx` に統一（`fetchXxx` は使わない）。
- コンポーネントは関数コンポーネントで書く。
- import は外部 → 内部 → 相対パスの順に並べる。

## Boundaries（やってはいけないこと）
- `src/legacy/` 配下は凍結。理由がない限り変更しない。
- DBマイグレーションファイルは自動生成しない。人間に確認する。
- 本番デプロイ・課金・外部送信を伴う操作は実行しない。提案だけする。

## Git & PR
- コミットは Conventional Commits（例: `feat: ...`, `fix: ...`）。
- PR本文には、実行したテストの結果（証跡）を必ず書く。

## Gotchas（ハマりどころ）
- このプロジェクトはタイムゾーンを常に UTC で扱う。ローカル時刻を混ぜない。
- 環境変数は `.env.example` を正とする。新しいキーは必ずここにも追記する。

たったこれだけです。30行ちょっと。でも、これがあるだけで、毎回の説明から解放されます。最初は10行でいい。使いながら、AIがハマったポイントを1行ずつ足していく。それが正解です。

良い AGENTS.md の5原則

サンプルを見てもらった上で、「良い状態」を保つコツを5つにまとめます。

簡潔に保つ。 AGENTS.md は、エージェントが作業を始めるたびに読み込まれます。つまり毎回 トークン（AIが処理する文字の単位。多いほど料金も時間もかかる） を消費する。長ければ長いほど、毎セッション課金されると思ってください。だらだら書かない。目安はせいぜい数十〜150行くらい。
命令形で、実行できるコマンドを書く。 「テストするといいです」より「pnpm test を実行する」。AIは曖昧な希望より、具体的な動詞で動きます。
実例は3〜10行の短いコードで。 「こう書いてほしい」は、文章よりサンプルコードのほうが100倍伝わります。ただし長すぎると①に反するので、短く。
段階的に開示する。 全部をAGENTS.mdに詰め込まない。詳細は別ファイルに逃がして、「詳しくは docs/agent/testing.md を見て」と参照だけ置く。エージェントは必要なときにそれを読みに行きます。本体は薄く、詳細は外に。
living documentation（生きた文書）として扱う。 AGENTS.md は一度書いて終わりじゃない。コードを変えたら、同じPRの中でAGENTS.mdも直す。古いAGENTS.mdは、ないより害になる ことすらあります（嘘の文脈を毎回AIに刷り込むから）。

モノレポ戦略 — 「家のルール」と「部屋のルール」

少し大きめのプロジェクトの話をします。モノレポ という言葉、聞いたことありますか。ひとつのリポジトリの中に、複数のパッケージ（たとえば api、web、shared みたいな小プロジェクト）が同居している構成のことです。

このとき、AGENTS.md を1枚だけルートに置くと、「APIの規約」と「フロントの規約」が混ざってカオスになります。そこで使うのが nested AGENTS.md（入れ子のAGENTS.md） です。

さっきの「最寄りが勝つ」ルールが、ここで効いてきます。各パッケージに専用のAGENTS.mdを置いておけば、そのパッケージで作業するときは、そのローカルなAGENTS.mdが優先される。家全体の共通ルールはルートに、各部屋の事情は各部屋に。

コード例② モノレポでの配置イメージ

my-monorepo/
├── AGENTS.md              # 家全体の共通ルール（言語・コミット規約・全体の境界）
├── packages/
│   ├── api/
│   │   ├── AGENTS.md      # APIだけのルール（DB接続・認証・テスト方針）
│   │   └── src/
│   ├── web/
│   │   ├── AGENTS.md      # フロントだけのルール（UI規約・状態管理）
│   │   └── src/
│   └── shared/
│       └── src/           # ここはルートのAGENTS.mdが効く

どれくらいの規模で使われているかというと、公式サイトいわく、OpenAI のメインリポジトリには88個のAGENTS.md があるそうです。大きくなればなるほど、この入れ子構成が効いてくる、ということですね。

書く内容	どこに置く？
言語・コミット規約・全体の禁止事項	ルートの AGENTS.md
そのパッケージ固有のコマンド・規約	各パッケージの AGENTS.md
長い詳細手順（テスト設計など）	`docs/agent/*.md` に逃がして参照

境界設計 — AIに任せること / 人間が握ること

ここ、僕がいちばん大事だと思っているところです。

AIは賢い。賢いからこそ、境界線がないと「良かれと思って」踏み込んできます。 頼んでないリファクタ、勝手なファイル削除、ついでの本番設定変更。悪気はないんです。でも事故は事故。

だから、踏んじゃいけない場所は、先に文字にしておく。 これが Boundaries セクションの役割です。

特に、やり直しがきかない操作（不可逆な操作） は、AGENTS.md に「実行しない、提案だけする」と明記して、必ず人間のゲート（確認の関所）を通すようにします。

本番環境へのデプロイ
データの削除、DBの破壊的なマイグレーション
課金・決済に関わる処理
外部への公開・送信（SNS投稿、メール送信など）

ここで役割分担を表にしておきます。AGENTS.md は、この表を「ファイルとして固定する」装置だと思ってください。

領域	人間が握る	AIに任せる
何を作るか（What）	◎ 決める	提案はする
なぜ作るか（Why）	◎ 決める	—
境界・禁止事項	◎ 定義する	従う
実装（How）	レビューする	◎ 手を動かす
テスト作成	観点を決める	◎ 書く・実行する
不可逆な操作	◎ 最終承認	提案・準備まで

ひとつ注意があります。公式の仕様で、AGENTS.md にテストコマンドを書いておくと、エージェントはそれを自動で実行してくれる とされています。これは便利な反面、裏を返すと 「AGENTS.mdに書いたコマンドは自動で走りうる」 ということ。だから、間違っても破壊的なコマンドを気軽に書かないでください。書くのは「安全に何度でも実行できるコマンド」だけ。これも立派な境界設計です。

やりがちな落とし穴6つ

良かれと思ってやると、かえって逆効果になるパターンを6つ、症状と対策で並べます。

#	症状（やりがち）	なぜダメか	対策
1	とにかく全部盛りで長文化	毎セッション読まれてトークン浪費・要点が埋もれる	数十〜150行に圧縮。詳細は別ファイルへ
2	READMEを丸ごとコピペ	AIが推論できる情報はノイズ	「推論できないこと」だけ残す
3	AIに生成させたまま放置	それっぽいだけの定型文が混ざる	人間が読んで、嘘・不要を削る
4	古くなって嘘になる	嘘の文脈を毎回AIに刷り込む	同じPRで更新。CIで陳腐化を検知
5	境界（禁止事項）が無い	AIが踏み込んで事故る	Boundaries を必ず書く
6	秘密情報・個人情報を書く	コミット＝漏洩。公開リポジトリなら即アウト	絶対に書かない（下記）

6番だけは、別格に危険なので独立させます。

⚠️ AGENTS.md は git にコミットされ、公開リポジトリならそのまま世界に公開されます。
APIキー、トークン、パスワード、社内の固有ID、個人情報、未公開のURL……これらを 絶対に書かないでください。
秘密情報は .env（＋ .gitignore）やシークレット管理サービスに置き、AGENTS.md には「環境変数は .env.example を正とする」のように 置き場所だけ を書く。中身は書かない。

ここは事故ったときの被害が桁違いなので、何度でも言います。AGENTS.md に書いていいのは、人に見られても困らないことだけ。

そのまま使えるプロンプト例3本

AGENTS.md は、AIに作らせて、AIに点検させて、AIに更新提案させる、という回し方ができます。ただし 最終的に消す・残すを決めるのは人間 です。AIには「材料出し」をさせて、判断は握る。これも Context Engineering の作法です。

プロンプト1：AGENTS.md の初稿を作らせる

ゼロから書くのはしんどいので、まずリポジトリを調べさせて叩き台を作らせます。

あなたはこのリポジトリの構成を調査し、AGENTS.md の初稿を作ってください。

手順:
1. package.json / 設定ファイル / ディレクトリ構成を読み、
   使用言語・パッケージマネージャ・テスト/ビルド/Lintのコマンドを特定する。
2. 次のセクションで AGENTS.md を作る:
   Project overview / Commands / Testing / Code style / Boundaries / Git & PR / Gotchas
3. 「コードを見れば分かること」は書かない。推論できないことだけ書く。
4. 全体は120行以内。各コマンドは実際に動く形で。

重要:
- 推測で書いた箇所、確認が必要な箇所には「# TODO: 要確認」を付ける。
- APIキー・個人情報・固有IDは絶対に書かない。
最後に、このファイルに入れなかったが人間に確認すべき項目を箇条書きで出す。

プロンプト2：既存 AGENTS.md の健康診断

すでにあるAGENTS.mdが「長すぎ・古い・推論可能な情報だらけ」になってないか点検させます。

このリポジトリの AGENTS.md をレビューしてください。判断はせず、指摘だけ出す。

観点:
- 長すぎないか（毎セッション読まれる前提で、削れる行はどれか）
- 「コードを見れば分かること」が書かれていないか（=削除候補）
- コマンドや記述が実態とズレていないか（陳腐化）
- Boundaries（禁止事項・不可逆操作）が抜けていないか
- 秘密情報・個人情報・固有IDが混入していないか（最優先）

出力フォーマット:
| 行/箇所 | 種別(冗長/陳腐化/欠落/危険) | 指摘 | 提案 |
最後に「人間が判断すべき項目」を分けて列挙。削除や変更は提案までにとどめる。

プロンプト3：セッション後の更新提案

これがいちばん効きます。作業のあとで「今回ハマったこと」をAGENTS.mdに還元させる。

今回のセッションで、あなたが詰まった点・誤解した点・私が途中で訂正した点を振り返り、
AGENTS.md に1〜3行追記すべき内容を提案してください。

条件:
- 「次回また同じミスをしないため」の文脈だけに絞る。
- 既存の記述と重複しない。120行の上限を超えそうなら、何を削るかも提案する。
- 追記は diff 形式（+ で始まる行）で示す。
最終的に追記するかどうかは私が決めます。あなたは提案まで。

3本とも、最後に 「判断は人間」 と書いているのがポイントです。AIに全部任せると、AGENTS.md がAI生成の定型文で太っていく（落とし穴3番）。発散はAI、収束は人間。

CIで「陳腐化」と「太りすぎ」を自動で見張る

落とし穴の4番（古くなって嘘になる）と1番（長すぎ）は、人間の意志だけだと必ず崩れます。なので、機械に見張らせましょう。

コード例③ AGENTS.md の健全性チェック（Node.js）

下は、AGENTS.md が「長すぎないか」「書いてあるコマンドが本当に package.json に存在するか」を確認する、依存ゼロの小さなスクリプトです。CIに組み込めば、AGENTS.mdが嘘をつき始めた瞬間に気づけます。

// scripts/check-agents-md.mjs
// 使い方: node scripts/check-agents-md.mjs
import { readFileSync } from "node:fs";

const MAX_LINES = 150; // 太りすぎ防止のしきい値
const errors = [];

const md = readFileSync("AGENTS.md", "utf8");
const lines = md.split("\n");

// 1) 行数チェック（毎セッション読まれるので長すぎは害）
if (lines.length > MAX_LINES) {
  errors.push(`AGENTS.md が ${lines.length} 行。${MAX_LINES} 行以内に圧縮を。`);
}

// 2) 本文中の `pnpm xxx` / `npm run xxx` が package.json に実在するか
const pkg = JSON.parse(readFileSync("package.json", "utf8"));
const scripts = new Set(Object.keys(pkg.scripts ?? {}));
const referenced = [...md.matchAll(/`(?:pnpm|npm run|yarn)\s+([a-zA-Z:_-]+)`/g)]
  .map((m) => m[1])
  .filter((name) => name !== "install" && name !== "dev"); // 既定コマンドは除外

for (const name of referenced) {
  if (!scripts.has(name)) {
    errors.push(`AGENTS.md が "${name}" を参照しているが package.json に無い（陳腐化）`);
  }
}

// 3) 秘密情報っぽい文字列の混入を雑に検知（完全ではない最終防波堤）
if (/(api[_-]?key|secret|password|token)\s*[:=]\s*\S+/i.test(md)) {
  errors.push("秘密情報らしき記述を検知。AGENTS.md に秘密は書かない。");
}

if (errors.length) {
  console.error("AGENTS.md チェック失敗:\n- " + errors.join("\n- "));
  process.exit(1);
}
console.log("AGENTS.md OK");

これをGitHub Actionsから呼べば、PRのたびに自動で番をしてくれます。「人間が頑張って守る」を「仕組みが勝手に守る」に変える。 これも明日の自分へのプレゼントです。

コード例④ 旧ファイルからの移行（後方互換）

すでに CLAUDE.md や .cursorrules を持っている人も多いと思います。捨てなくて大丈夫。AGENTS.md を正にして、旧ファイルはシンボリックリンク（中身は同じで名前だけ別、というショートカットのこと） にしておけば、古いツールも新しいツールも、同じ実体を読みます。

# 例: 既存の CLAUDE.md を AGENTS.md に一本化して、旧名はリンクで残す
mv CLAUDE.md AGENTS.md
ln -s AGENTS.md CLAUDE.md      # CLAUDE.md は AGENTS.md を指すだけになる

# 中身は1か所（AGENTS.md）を直せば、両方に反映される

これで「ツールごとにメンテ」から「1枚を育てる」に移行できます。

なお、AGENTS.md は他の手法と競合しません。むしろ相性がいい。たとえば、機能ごとの仕様を書く Spec-Driven Development（仕様駆動開発）や、出力品質を測る評価（Eval）と組み合わせると、「リポジトリ全体の作法は AGENTS.md、機能ごとの仕様は spec、品質は eval」 という、きれいな三層になります。AGENTS.md はその土台、いちばん下に常駐する文脈です。

今週の最初の一歩（4ステップ）

理屈はもう十分です。完璧を目指さず、まず動かしましょう。65点でいい。

リポジトリのルートに AGENTS.md を新規作成する。 まずは空でいい。
10行だけ書く。 Commands（install / dev / test）と、Boundaries を1〜2行（「src/legacy/ は触らない」など）。これだけで効きます。
次のセッションで、プロンプト3（更新提案）を使う。 AIが詰まったポイントを1〜2行ずつ足していく。
1週間後、プロンプト2（健康診断）で点検する。 長すぎ・陳腐化・秘密混入をチェックして、削る。

これだけで、来週のあなたは「毎回の説明」から解放されています。

おわりに — AGENTS.md は、明日の自分への置き手紙

最後に、ちょっとだけ僕の思っていることを。

AGENTS.md って、技術的には「AIに読ませる設定ファイル」なんですけど、本質はもっと優しいものだと思っているんです。

READMEが人間への手紙なら、AGENTS.md は、明日の自分・明日のチーム・明日のAIセッションへの置き手紙 です。今日10行書いておくだけで、明日の自分が、同じ説明をしなくて済む。新しく入る人が、いきなり戦力になれる。AIが、いきなり作法どおりに動いてくれる。

僕がいつも自分に問いかけている軸があって、それは 「この選択、明日の自分があざっす（ありがとう）って言ってくれるかな？」 というものなんです。AGENTS.md を10行書くのは、まさにそれ。今日のちょっとした一手間が、明日の自分への「あざっす」になる。

そしてこれは、AI時代のエンジニアの役割の変化そのものでもあります。コードを1行ずつ手で打つ人から、What（何を）と Why（なぜ）と境界を設計して、How（どう実装するか）をAIに渡す人 へ。AGENTS.md は、その「文脈を設計する力」を、誰でも今日から持てる形にしてくれます。文脈はコードと同じで、ちゃんと書けば資産になる。育てれば育てるほど、勝手に効いてくれる資産に。

完璧じゃなくていいんです。まずは10行。あなたのリポジトリに、明日のための置き手紙を、1枚置いてみませんか。

明日のあなたが、きっと「あざっす」って言ってくれます。