AIエージェント時代、​強いリポジトリは​「AGENTS.md」を​持っている​ ──Copilotが​レビューに​AGENTS.mdを​読み始めた​日

技術ノート ｜ AIの最新動向を、現場目線で

AIコーディングで差が出るのは、もう「どのモデルを使うか」だけではない。むしろ効いてくるのは、そのリポジトリが、自分の作法をAIにちゃんと説明できているかだ。

モデルはどんどん賢くなる。だが賢いAIほど、リポジトリ固有のルールを知らなければ堂々と間違える。日本語で返してほしいのに英語で返す。SupabaseのRLSを確認せずにロジックを書き換える。秘密値をうっかりログに出す。公開後にやるべき確認（一覧カード・OGP・再検証・解析）を忘れる。──悪いのはモデルではなく、「リポジトリの作法が、AIに渡されていない」ことだ。

2026年6月、この"渡し方"に各社が同じ方向で寄ってきた。GitHub Copilotのコードレビューが AGENTS.md を読み始め、OpenAI Codexは作業前に AGENTS.md の命令チェーンを組み、Microsoftの AgentRC はリポジトリの「AI対応度」を測り始めた。^[1][3][5] 私たち電脳技巧集団（AI職人ギルド）は、毎日複数のリポジトリをAIエージェントで回している。だからこの流れを、流行語ではなく「で、リポジトリ整備はどう変わるのか」という現場目線で読む。なお外部仕様はCAGの検証ではなく公式発表に基づく。

01AIは​賢いのに、​リポジトリの​作法を​知らないと​間違える

新しいセッションを開くたび、私たちは同じ前提を口で説明してきた。「日本語で」「TypeScriptで」「any禁止」「Supabaseは必ずRLSを確認」「秘密値は出さない」「完了したらwikiに記録」。モデルが賢くなっても、この前提を毎回チャットで貼り直す消耗は消えない。しかも貼り忘れた一回で、AIは自信満々に作法を破る。

本当に必要なのは、AIが作業を始める前に自分で読みに行ける「このリポジトリでの働き方」だ。何をセットアップし、どうテストし、何に触ってはいけなくて、どうなったら完了か。これがリポジトリ自身に書いてあれば、AIは「賢いが作法を知らない新人」から「現場のルールを分かっている同僚」に変わる。AGENTS.md は、その作法を置く場所として定着し始めた。

022026年6月、​各社が​同じ​"指示の​層"に​寄ってきた

まず事実を押さえる。AGENTS.md は2025年時点では「主にCodex向けのプロジェクト指示」と見られていた。だが2026年6月、同じリポジトリ指示が「実装」だけでなく「レビュー」「エージェント専門化」「品質計測」へ一気に広がった。^[1][2][3][5]

時点	出来事
2025-08-28	GitHub Copilot coding agent が AGENTS.md（root/nested）をカスタム指示としてサポート。CLAUDE.md / GEMINI.md 等との併用も明記
2025-11-05	Copilot が組織レベルのカスタム指示に対応。組織標準とリポジトリの指示ファイルが併存
2026-01-29	Microsoft AgentRC 公開。リポジトリのAI対応度を測り、指示・MCP・eval・CIゲートを生成/維持する方向
2026-06-18	Copilotのコードレビューが repo root の AGENTS.md を読むように。レビューコメントをリポジトリの規約・期待値へ寄せる

※ 各社の公式changelog・公式ドキュメント（2025〜2026）に基づく。「同じ指示層へ収束している」という見立て自体は、CAGによる複数製品の構造比較（解釈）。

とくに大きいのが2026-06-18だ。これまで AGENTS.md は「実装する前の指示」だった。それが「レビューの判断基準」にも入った。AIはコードだけでなく、チームの基準も読むようになったということだ。OpenAI Codexも公式ドキュメントで、AGENTS.md の発見順・global/project/nestedの命令チェーン・マージ順・サイズ上限まで定義している。^[3] 指示が「チャット欄」から「リポジトリ」へ移っている。

03AGENTS.mdは​「AI向けREADME」ではない​ ──リポジトリが​渡す"作業契約"

ここで誤解を一つ正したい。AGENTS.md は「AI向けのREADME」ではない。READMEが「このプロジェクトは何か」を人間に説明するものなら、AGENTS.md は「このリポジトリでどう働くか」をAIに渡す作業契約だ。^[6]

だから書くべきは、願望や雰囲気ではない。毎回の前提・手順・境界・完了条件という、具体的で検証可能なものだ。言語と命名規約、技術スタック、セットアップ／テスト／ビルドのコマンド、触ってよいもの・だめないもの、秘密値の扱い方、そして「どうなったら完了か」。Codexのように複数階層をマージして読むツールもあるので、ルートには原則を、細部はディレクトリごとの nested に置ける。

このテーマは、前回の記事で書いた「AIが引き継げる知識bundle（OKF）」と地続きだ。あちらが知識を引き継げる形にする話なら、AGENTS.md は働き方を引き継げる形にする話。どちらも「毎回プロンプトで説明する」から「リポジトリが常時持つ」への移行である。

関連記事 ｜ 知識を引き継げる形にする話「人間が読むWiki」から「AIが引き継ぐ知識」へ ──Google CloudのOKFが名付けた、AIエージェント時代の知識設計 →

04何を​書くか ──願望でなく​「契約」を

では具体的に何を書くか。骨格はシンプルで、言語 / スタック / コマンド / 安全 / 完了条件の5つに集約できる。短くても、これがあるだけでCodex・Claude・Copilot系が毎回の前提を引き継ぎやすくなる。

制作事例で言えば、私たちのある案件では「記事公開後に一覧カード・OGP・再検証・アクセス解析を確認する」を完了条件にしている。マルチテナントの案件なら「Supabaseのtenant所有とRLSを確認してからUIを触る」を契約にする。「あると便利なメモ」ではなく「守るべき契約」として置くと、AIもレビューAIも同じ基準で動く。

05​私たちは、​各リポに​これを​持っている

ここからは外の話ではなく、私たちの一次情報だ。私たちは運用する各リポジトリに、この作業契約を最初から持たせている。

記事を生み出すサイトのリポジトリには、「公開前/公開後のチェックリスト」「秘密値を出さない」「解析の更新」「作業後はナレッジに記録」を契約として書いてある。だから新しいセッションでも、AIは「CAGの記事ってどう公開するんだっけ」を毎回聞かずに、正しい手順で動く。私たちが共同編集しているMarkdownナレッジベースでは、AGENTS.md がスキーマ・運用ルール・記録先のSSOT（単一の正）になっていて、これは今回の業界の流れを先取りしていた形だ。支援先の案件でも、安全条件（権限・RLS・本番操作・送信）を作業契約として置くほど、AIに安心して任せられる範囲が広がる。

面白いのは、AGENTS.md を整えることが、特定のAIに縛られない投資になる点だ。同じ契約をCodexも、Claudeも、Copilotのレビューも読む。モデルを乗り換えても、リポジトリに積んだ作業契約は資産として残る。これは「どのモデルが最強か」の競争とは別の、足元の競争力だ。

06万能論への​釘 ──skills / MCP / eval / 人の​レビューと​セット

ここで煽りすぎないために釘を刺す。「AGENTS.mdを置けばAI開発が自律化する」は誇張だ。^[5] 指示は必要条件であって十分条件ではない。実際にはテスト・型チェック・マイグレーション方針・秘密値の扱い・デプロイの関門・MCPの権限・コンテンツ除外、そして人間のレビューが別途要る。

整理すると、AIに任せる現場は4つの層でできている。AGENTS.md が常時ロードされるOS（原則・境界・完了条件）、skills が必要時に開くワークフロー（再利用可能な手順）、MCP が操作の権限、eval が効果の計測。AGENTS.md はこの土台であって、全部ではない。^[4]

とくに大事なのは、AGENTS.md に秘密値や本番情報を直接書かないこと。書くのは「1Passwordを使う」「承認を通す」「ログに出さない」という扱い方であって、秘密値そのものではない。指示が肥大化したら、ルートは原則と完了条件に絞り、細かい手順は skills や参照ファイルへ逃がす。「1ファイルで全部」より、SSOTと自動同期の設計が効く。

07​締め：repo整備は​READMEから、​作業契約へ

2026年6月のこの数日を、現場目線でまとめる。AIコーディングの差分は、また一段「リポジトリ側」に移った。強いリポジトリは、READMEより先に作業契約（AGENTS.md）を持っている。実装AIも、レビューAIも、CIも、同じ契約を読む。これからのリポジトリ整備は、READMEを整えることから、AGENTS.md / skills / MCP / eval を束で整えることへ広がる。

そしてこれは、AI導入支援の中身そのものでもある。「AIエージェントを入れます」と言うとモデル比較になりがちだが、企業に本当に必要なのはAGENTS.md readiness——AIに安全に仕事を渡すための作業契約・テスト手順・権限境界・レビュー基準・記録先を、リポジトリと業務に埋めることだ。私たちが日々やっている「AIに渡せる形に整える」ことを、お客さまの開発と業務の上に組み直す。それが、AIで飯を食う職人の足回りだ。

「毎回プロンプトで説明」から「リポジトリが常時持つ」へ。この違いを、一枚に。

観点	README中心・プロンプト都度	AGENTS.md（作業契約）中心
主役	人間向けの説明＋その場の指示	AIに渡す検証可能な作業契約
前提の引き継ぎ	毎セッション貼り直す（貼り忘れる）	リポジトリが常時持ち、全AIが読む
レビュー	レビューAIは規約を知らない	レビューAIも同じ基準で判定（2026-06〜）
安全	秘密・権限・RLSが口頭頼み	扱い方・境界を契約として明文化
モデル乗り換え	そのつど説明し直し	契約は資産として残る（vendor非依存）
完了の定義	曖昧・人によって違う	done criteria＝テスト・確認・記録で固定

※ 本記事は外部の公式changelog・公開ドキュメントを、開発実務の観点から整理・論評したもの。各ツールの事実関係は下記出典に基づく引用であり、製品横並びのベンチマークや「operational OS」化の断定はCAG自身の検証でなく解釈を含む（「同じ指示層へ収束」は複数製品からの読み替え）。私たちのリポジトリ運用に関する記述は自社の一次情報。各ツールは AGENTS.md の解釈・優先順位・サイズ上限が異なり、状況は流動的（v0・2026-06時点）。