この wiki に記録されている形式の多くは、基本的に同じ役割を果たす。いずれもコーディングエージェントが常設のコンテキストとして読み込むテキストを保持し、プロジェクトの規約をセッションのたびに打ち直さなくて済むようにするものである。違いは、どのツールが読むか、どこに置かれるか、内容がいつコンテキストに入るか、そして何を保持することを意図しているかにある。このページではそれらを並べて比較する。対象は AGENTS.md、CLAUDE.md、AGENT.md、GEMINI.md、GitHub Copilot の指示ファイル、AI IDE ルール の IDE ごとのルールディレクトリ、DESIGN.md、エージェントプリミティブ のファイル種別、MentorScript、そして包括的な用語である メモリバンク である。続いて、この wiki のソースがこれらのファイルの読み込まれ方をどう説明しているか、コンテキストをどう分割しているか、ファイルに何を入れるべきとしているか、ファイルをどう最新に保つか、コーディング以外にどんな用途があるか、どう攻撃されうるか、そしてエビデンスが何を測っているかを扱う。違いを浮き彫りにすることが目的であり、形式の優劣はつけない。

一覧比較

形式読み手置き場所と適用範囲保持する想定の内容位置づけ
AGENTS.md対応する任意のエージェント。形式のプロジェクトは「エージェント向けの README」と呼ぶ慣例としてリポジトリのルート。codex-1 のシステムメッセージでは任意の場所に置け、その下のディレクトリツリーを対象とし、より深くネストしたファイルが優先される具体的なコマンドと規約。プロジェクトの最小例には開発環境のヒント、テスト手順、プルリクエスト手順があるMIT で公開されたオープンな形式。2025 年 12 月に Linux Foundation に寄贈されたとされる
CLAUDE.mdClaude Code4 つのスコープ(管理ポリシー、ユーザー、プロジェクト、個人ローカル)。ルートのファイルはセッション開始時に読み込まれ、コンパクション後に再読み込みされる。サブディレクトリのファイルは Claude がそこのファイルを読んだときに読み込まれる。ディレクトリツリーを上にたどって見つかったファイルは互いに上書きせず連結される常設のプロジェクトの事実:ビルドコマンド、ディレクトリ構成、規約、チームの規範一ベンダーの製品機能
AGENT.mdAmp がネイティブに対応。仕様によれば他のいくつかのツールはシンボリックリンク経由プロジェクトルートに置かなければならない(MUST)。実装はユーザー全体の ~/.config/AGENT.md を含む階層をサポートすべき(SHOULD)で、より具体的なファイルが優先されるプロジェクト構成、ビルド/テストコマンド、コードスタイル、アーキテクチャ、テスト、セキュリティ2025 年 7 月付の RFC 形式の仕様。Sourcegraph 向けに書かれた
GEMINI.mdGemini CLI。Google Antigravity も AGENTS.md と並んでここからルールを読むGemini CLI は gemini コマンド実行時にカレントディレクトリの gemini.md ファイルを探す。同じワークショップの後のステップでガイドラインを GEMINI.md に書き込むペルソナ、ファイルや検索への参照、プロジェクトについて覚えておくべき事実やルールGoogle Codelabs のワークショップと Antigravity の変更履歴の項目で説明されている
Copilot の指示ファイルGitHub Copilotリポジトリ全体のルールには .github/copilot-instructions.md、パス別には .github/instructions/ 配下の *.instructions.md ファイルCopilot 固有の常時有効なルール。リポジトリ全体または特定パス向けベンダーのドキュメント(AGENTS.md のページに記録)
AI IDE ルールIDE ごとに 1 つ — .cursor/rules/、.windsurf/rules/、.trae/rules/、.qoder/rules/、.kiro/steering/ツールごとのディレクトリ。あるベンダーのガイドは 4 つのトリガー種別(Manual、Model Decision、Always、Specific Files)を加え、1 ファイルを 10,000 文字に制限しているアーキテクチャ上の制約、コーディングスタイル、ライブラリの好み、ワークフローツールごとの製品機能。1 件のマイニング・サーベイ研究で調査されている
DESIGN.mdユーザーインターフェースを生成するエージェント単一のファイル機械可読な YAML で表したデザインシステムのトークンと、Markdown 本文のデザイン意図。lint と diff コマンドが付属する2026 年 4 月に Google Labs が公開
エージェントプリミティブソースの例では VS Code の GitHub Copilot関心事ごとに別ファイル。.instructions.md ファイルは applyTo パターンに一致するパスに対してのみ有効になる6 つのファイル種別 — instructions、chat modes、prompts、specs、memory、context。このうち VS Code がネイティブにサポートするのは最初の 3 つGitHub のブログに掲載された一著者による提案で、評価は報告されていない
MentorScript提案された SASE フレームワーク内のエージェント成文化されたチームの規範(「mentorship-as-code」)。置き場所は規定されていない細かなチェックから高レベルの原則までのチームの規範。エージェントの各行動は考慮されたルールまでたどれる1 本の論文で SASE フレームワークの一部として提案されたもの
メモリバンクコードベースにおける任意の AI コーディングセッションタスク単位ではなく全セッションにわたるルールファイルやプロダクト・アーキテクチャの説明などの一般的なコンテキスト — Kiro の「steering」、Spec Kit の「constitution」Birgitta Böckeler がこのコンテキストを仕様と区別するために採用した名前

名前、アダプター、収束

AGENTS.md と AGENT.md は同じ役割を担い、名前が違うだけである。AGENT.md の仕様は、著者らが agent.md ドメインを所有し、ベンダー中立に保つことを約束しているため単数形を好むと述べつつ、妥協する用意もあるとしている。メルカリ Web モノレポでエージェントを飼いならす の採用事例では、あるチームが Cursor と Claude のルールを AGENT.md に統合し、その後 OpenAI が agents.md ドメインを確保したことを受けて複数形に切り替えたことが記録されている。AIに渡す指示書の役割分担: AGENTS.md/SKILL.md/DESIGN.mdと仕様駆動開発の現在地 は、複数形は Linux Foundation への寄贈前に OpenAI、Google、Cursor、Factory などが共同で推進したものだと説明している。2026 年のソフトウェアエンジニアリングの最先端に AI が与える影響 は、各アシスタント独自のファイルを一種の「AI 向け README」に統一しようとする試みだと説明している。

いくつかのソースは、内容を二重管理しないために、ツール固有のファイル名を 1 つの共有ファイルへのアダプターとして生かしておく方法を述べている。

  • シンボリックリンク。 AGENT.md の仕様は、ツール独自のファイルを AGENT.md に移してリンクを残す移行コマンドを示している。Mercari のチームは CLAUDE.md やその他のルールファイルを自分たちの AGENTS.md へのリンクにした。三層の記事は、形式のプロジェクトの推奨として AGENTS.md を実体ファイルにし、CLAUDE.md をそこへのリンクにすることを挙げている。エージェント型 AI はシンプルに:ソフトウェア開発のための実践的ワークフロー の実践者は、両者をシンボリックリンクまたは @AGENTS.md 参照でつないでいる。
  • ファイル間の参照。 エージェント型 AI コーディングツールのためのハーネスエンジニアリング:探索的研究 は、複数種類のコンテキストファイルを持つリポジトリでは、通常 CLAUDE.md が先に作られ、AGENTS.md が後から追加されていたことを見出した。CLAUDE.md が参照する先は AGENTS.md が最も多く(301 件)、AGENTS.md は 353 件の被参照を受けており、他のどのファイル種別よりはるかに多かった。著者らはこれを、ベンダーの指示ではなく開発者の実践に駆動された、ツール非依存の標準としての AGENTS.md へのボトムアップな収束と解釈している。
  • ツール側のフォールバック。 OpenCode は、AGENTS.md がないときはプロジェクトの CLAUDE.md に、グローバルな OpenCode ファイルがないときは ~/.claude/CLAUDE.md にフォールバックする。各カテゴリで最初に一致したものが採用されるため、両方ある場合は CLAUDE.md より AGENTS.md が使われる。

Claude Code による AGENTS.md の扱いは、根拠となるページの間で説明が異なる。三層の記事は Claude Code は CLAUDE.md を読み AGENTS.md は読まないと述べ、エージェント型 AI はシンプルに:ソフトウェア開発のための実践的ワークフロー の実践者も自身の環境について同じことを言っている。設定に関する研究は、2026 年 2 月のスナップショット時点で Claude Code は AGENTS.md をネイティブにサポートしていなかったと記している。CLAUDE.md のページと Claude Code のページは、Claude Code のドキュメントがリポジトリの AGENTS.md を読めると述べていることを記録している。CLAUDE.md のページはさらに、デフォルトではこれは CLAUDE.md も CLAUDE.local.md も存在しない場合に限られること、両方を読む設定があること、そして 1 つのファイルを共有するには @AGENTS.md のインポートを使うことを付け加えている。これらの説明は異なる時点を述べている可能性がある。ここではそれぞれのページが記すとおりに記録する。

内容が読み込まれるタイミング

形式ごとに、ファイルがコンテキストに入る方法と、2 つのファイルが食い違ったときの扱いが異なる。

  • ネストを伴うディレクトリスコープ。 codex-1 のシステムメッセージは、AGENTS.md の対象をそれを含むディレクトリツリーに限定し、より深くネストしたファイルを優先させ、システム・開発者・ユーザーからの直接の指示をファイルより上位に置く。AGENT.md の仕様も同様に、より具体的なファイルが一般的なファイルより優先されることを求めている。Codex のカスタム Code Review ルール はレビュールールに同じネストを使う。リポジトリ全体のルールはルートに、サービス固有のルールは該当ディレクトリ自身の AGENTS.md に置く。
  • 連結。 Claude Code のドキュメントによれば、ディレクトリツリーを上にたどって見つかった CLAUDE.md ファイルは互いに上書きせず連結されるため、Claude を起動した場所に近い指示ほど後に読まれる。@path インポートは起動時に最大 4 ホップの深さまで展開され、ブロックレベルの HTML コメントは注入前に取り除かれる。.claude/rules/ 配下のルールは、paths フィールドで一致するファイルに限定されていない限り起動時に読み込まれる。
  • 最初の一致を採用。 OpenCode はまずカレントディレクトリから上にたどってローカルファイルを探し、次にグローバルファイル、次に Claude Code のファイルを探す。opencode.json の instructions フィールドに列挙された追加ファイル(glob パターンやリモート URL を含む)は AGENTS.md ファイルと組み合わされる。OpenCode は AGENTS.md 内に書かれたファイル参照を解析しない。
  • パスパターン。 エージェントプリミティブの .instructions.md ファイルは、applyTo パターンに一致するパスに対してのみ有効になる。AGENTS.md のページに記録された GitHub のドキュメントは、パス別の *.instructions.md ファイルとリポジトリ全体の copilot-instructions.md を区別している。
  • トリガー種別。 Alibaba Cloud の Lingma 向けガイドは、ルールをトリガーのされ方で分類している — チャットでの名前指定、ルールの説明が合致するとモデルが判断した場合、すべてのリクエスト、ファイルの glob — そして、ルールとアシスタントのメモリが衝突した場合はルールが優先されると述べている。
  • 組織全体のポリシー。 Claude Code の管理 CLAUDE.md は MDM や構成管理を通じて配布され、個々の設定で除外することはできない。
  • ユーザーが書くメモリとエージェントが書くメモリ。 Claude Code は、ユーザーが書く CLAUDE.md と、Claude 自身が書く 自動メモリ を並置している。どちらも強制される設定としてではなくコンテキストとして、すべての会話の開始時に読み込まれる。自動メモリのインデックスは先頭 200 行または 25KB までしか読み込まれない。

モデルの入力におけるファイルの位置づけについては、ソースによって説明が異なる。Skill Issue:コーディングエージェントのためのハーネスエンジニアリング は、CLAUDE.md と AGENTS.md はハーネスによってエージェントのシステムプロンプトに注入されると説明している。CLAUDE.md のページに記録された Claude Code のメモリのドキュメントは、CLAUDE.md の内容はシステムプロンプトの後にユーザーメッセージとして渡されるため、厳密な遵守は保証されないと述べている。良い CLAUDE.md の書き方 は、Claude Code がこのファイルを、そのコンテキストは関係があるかもしれないしないかもしれないという旨のシステムリマインダーとともに注入していると報告している。

コンテキストの分割

いくつかのソースは、このコンテキストを、どのツールが読むかではなく、何を扱うか、いつ適用されるかで分割している。

  • 主題による三層。 AIに渡す指示書の役割分担: AGENTS.md/SKILL.md/DESIGN.mdと仕様駆動開発の現在地 は、これらのファイルを重複しない三層として捉える。エージェントの前提・役割・禁止事項には AGENTS.md(ツール固有の相当物として CLAUDE.md)、再利用可能なタスクには SKILL.md、見た目には DESIGN.md である。既存の CLAUDE.md を分割するための 3 つの問いを示し、この分割を目指すべき状態としてではなく、見合う場合に採用する選択肢として提示している。
  • 常設のコンテキスト対タスクごとの仕様。 メモリバンクという捉え方は、コードベースのすべてのセッションに関係するファイルと、記述する機能を変更するタスクにのみ関係する仕様とを分ける。エージェント型ソフトウェアエンジニアリングのための仕様駆動開発:人間–エージェントのチームワークをハーネスする も同様の切り分けをしている。AGENTS.md や CLAUDE.md などのエージェントのルールファイルに具体化されるシステム仕様と、タスクごとに作成され納品後にアーカイブされる機能仕様とを分ける。そしてその両方を、規範的で常時有効なものではなく手続き的でオンデマンドに読み込まれるスキルと区別している。
  • 事実はファイルに、手順は別の場所に。 Claude Code の舵取り:CLAUDE.md、スキル、フック、サブエージェントをいつ使うか は Claude Code の指示を置く場所を 7 つ数え、事実は CLAUDE.md に、手順はスキルに、特定パスだけの制約はパススコープのルールに、個人の好みはユーザーレベルのファイルに置くとしている。スキルを使って OSS のメンテナンスを加速する は別の分け方をしている。スキルがリポジトリにおける「検証済み」の定義を符号化し、AGENTS.md の冒頭近くにある短い if/then ルールがそのスキルの使用を必須にする。
  • 他所を指すエントリポイント。 Mercari のチームのルート AGENTS.md は短いファイルで、各セクションが docs/ 配下の別ドキュメントを指している。HumanLayer はタスク固有の指示を CLAUDE.md が列挙する別ファイルに置き、どれを読むかは Claude に判断させている。
  • 読み込み戦略による階層。 Codified Context: 複雑なコードベースにおける AI エージェントのためのインフラストラクチャ は、AGENTS.md、CLAUDE.md、.cursorrules のような単一ファイルのマニフェストは小規模なプロジェクトを超えるとスケールしないと主張する。10 万 8,000 行のコードベースで使われた 3 つの階層を説明している。すべてのセッションに読み込まれる約 660 行の constitution、19 個の専門エージェント仕様、そして MCP 検索サーバー経由でオンデマンドに提供される 34 個のサブシステム文書である。
  • 静的ファイルを超えて。 AGENTS.md に /init を使うのはやめよう は、単一の静的ファイルを種類の異なるタスクに対する制約として扱う。最小限のルーティングファイル、選択的に読み込まれるタスクスコープのファイル、保守用サブエージェントからなる三層の代替案を紹介し、それを構築するのに必要なライフサイクルフックを公開している主要なコーディングエージェントはまだないと指摘している。Agentic Context Engineering は、同じ「静的ファイル問題」への別の対応として引かれており、コンテキストを進化し続けるプレイブックとして維持する。

ファイルに入れるべきもの

このようなファイルが何を含むべきかについて、各ページは異なる答えを記録している。

  • 発見可能性のフィルター。 AGENTS.md に /init を使うのはやめよう は、エージェントがコードを読めば発見できる事実はファイルに入れるべきではなく、自動生成されたコードベースの概要は冗長だと主張する。アンカリング効果も説明している。ファイルで言及された技術はすべてのプロンプトでコンテキストに残り、エージェントを古いパターンへ偏らせうる。
  • 手順をファイルに入れる。 AGENTS.md のページに記録された実践者の事例は、フォルダ構成、作業ルール、自動生成の手順をファイルに格納し、ルールファイルが充実しているほどプロンプトは簡潔になると主張している。AGENTS.md のページは 2 つの立場を調停せずに記録している。
  • 手順をファイルから出す。 CLAUDE.md のページに記録された Anthropic のガイダンスは、複数ステップの手順をスキルに、コードベースの一部に関わる事項をパススコープのルールに、必ず起きなければならないこと・決して起きてはならないことをフックや権限に移す。プロンプトで与えたルールは守られないことがあるからである。
  • オンボーディングの内容。 良い CLAUDE.md の書き方 は、このファイルをプロジェクトの what・why・how について Claude をオンボーディングするものと位置づける。AI プログラミングツールの進化とバイブコーディングについて は新しいチームメンバーが必要とするものをモデルにしている。技術スタック、ディレクトリ構成、どのファイルが何のために何と名付けられているか、install・lint・test・build などのよく使うコマンドであり、これらを CLAUDE.md または .github/copilot-instructions.md に置く。AGENT.md の仕様は、新しいチームメンバーが初日に必要とするものを提案している。
  • プロジェクト全体の決定のみ。 効率的なエージェント型コーディング は決定を 3 つに分ける。既存のコードをエージェントに示せば導けるもの、プロジェクト全体に当てはまり AGENTS.md に入れるべきもの、そして現在のタスクに固有でプロンプトに入れるべきものである。ソフトウェア 3.0 時代を迎えて は CLAUDE.md を package.json や pom.xml になぞらえる。頻繁に編集されるファイルは、現在の issue やその日の優先事項など、そこに属さないものを抱えている可能性が高いと述べている。
  • 形に基づく欠陥と実行時の欠陥。 AI にチームのルールを守らせる方法 は、コードの形から認識できる規約をフックで起動されるルールに回す。N+1 クエリのように実行時にしか現れない欠陥は、常時読み込まれるコンテキストに残す。
  • 入れるべきでないもの。 HumanLayer、AI IDE ルールの研究、Codex のレビュー記事はいずれも、フォーマットやその他の機械的なチェックをファイルではなくリンター、フォーマッター、CI に任せている。
  • サイズ。 Anthropic は CLAUDE.md を 200 行未満に保つことを推奨している。HumanLayer は 300 行未満が最善という一般的な合意があると報告し、自身のルートファイルを 60 行未満に保ち、Anthropic には公式の長さの推奨はないと述べている。Claude Code のドキュメントは「これを削除したら Claude はミスをするか?」というテストを示している。ある記事は、よく整理された CLAUDE.md の目安として 500〜2,000 トークンを挙げている。Unity の SDD の事例は常駐ルールを約 30 行に抑えている。これらはいずれも測定された閾値として示されてはいない。
  • 生成するかどうか。 OpenCode の /init は AGENTS.md を作成または更新し、Claude Code の /init は初期版の CLAUDE.md を生成する。エージェント型 AI はシンプルに:ソフトウェア開発のための実践的ワークフロー は、ファイルはエージェントに生成させてよく、定期的に見直すべきだと述べている。HumanLayer と AGENTS.md に /init を使うのはやめよう は生成に反対している。AI IDE ルールの研究では、調査対象の開発者の 71.72% が AI でルールを生成してから手直ししていた。
  • 定まった答えはない。 MentorScript を提案する論文は、このようなファイルが何をどの程度の詳しさで含むべきかについてコミュニティに合意はないと述べている。

ファイルを最新に保つ

これらのファイルが時間とともに変化するという点ではソースは一致しており、その管理方法をそれぞれ異なる形で説明している。

  • 失敗の後に追加する。 エージェントハーネスエンジニアリング は、エージェントのミスを 1 つずつ AGENTS.md のルール、フック、またはレビュアーサブエージェントのチェックとして符号化し、より高性能なモデルによって不要になれば削除すると説明している。エージェント型 AI はシンプルに:ソフトウェア開発のための実践的ワークフロー の実践者は、繰り返し起きるミスをファイルに追加している。AI IDE ルールの研究では、調査対象の開発者の 48.48% が AI がミスをしたときにだけルールを追加していた。また、ルールの変更は追加が大半を占めるため、ファイルは肥大化し、矛盾を含むようになりうることも見出している。
  • エージェントが書く。 自己改善するコーディングエージェント は AGENTS.md を、自律ループの各反復が読み、追記もできる長期記憶として扱う。規約、落とし穴、好み、最近の学びのセクションを提案し、ファイルが大きくなるにつれてコンテキストが肥大化することを警告している。上位の設計に大きな影響を与えるプルリクエストについて、Mercari のチームはエージェントに変更セットをルールフォルダとあわせて読ませ、ルールの修正を提案させている。
  • レビューでチェックする。 大規模な AI コードレビューのオーケストレーション では、専任のレビュアーエージェントが、リポジトリの AGENTS.md を更新せずにアーキテクチャ上の重要な変更を行うマージリクエストにフラグを立てる。水増しの内容や長すぎるファイルにもペナルティを科す。Anthropic は CLAUDE.md にオーナーを置き、その変更をコードと同じようにレビューすることを推奨している。
  • 失敗としての陳腐化。 codified context の論文は、仕様の陳腐化を主要な失敗モードに挙げ、週に約 1〜2 時間の保守を報告している。AI プログラミングツールの進化とバイブコーディングについて は、指示ファイル内の古い情報は、書かないでおくより害が大きいと警告している。AI IDE ルールの研究では、遵守率はルールを導入したコミットでピークに達し、その後のコミットで 65% 前後に向かって低下していた。

コーディングのコンテキスト以外の用途

いくつかのソースは、同じファイルをコーディングタスクへのコンテキスト供給以外の仕事に使っている。

  • レビュールール。 Codex のカスタム Code Review ルール は、Codex Code Review が AGENTS.md に置かれたルールを変更に適用し、指摘の中でそれらを引用することを説明している。AGENTS.md のページは、Copilot がレビュー中にプルリクエストの head ブランチからカスタム指示、エージェント指示、スキルを読むことを記録している。
  • コミュニティの AI ポリシー。 オープンソースコミュニティの AI コントリビューションルールに対するコーディングエージェントの遵守状況の初見 は、オープンソースコミュニティが AI による貢献のルールを書く場所の 1 つとして、AGENTS.md のようなエージェント指示ファイルを挙げている。この研究はポリシーの条項を AGENTS.md にそのまま引用する方法を試した。開示と検証のルールについては、エージェントがセッション開始時にすでに読むファイルとフィードバックループの組み合わせを推奨している。禁止事項や人間による承認のルールは、エージェントの外側で強制することを推奨している。

ファイル内のルールが効かなくなるところ

いくつかのソースは、ファイルがエージェントにさせられることの限界を述べている。

  • セッションが進むと遵守が薄れる。 AI にチームのルールを守らせる方法 は、エージェントはセッション開始時にプロジェクトルートの AGENTS.md を読んで序盤はそれに従うが、セッションが長くなると従わなくなると報告している。著者はこれを Lost in the Middle に帰している。チームの対応は、ファイルを書き込むたびとエージェントが終了する前に、エージェントフック を通じて関連するルールを再注入することである。
  • 長さが遵守を薄める。 Anthropic は、CLAUDE.md が大きくなると重要な指示への遵守が薄まると述べている。Claude Code のドキュメントは、肥大化したファイルは指示が無視される原因になるとし、多数の行ではなく飛ばされた 1 行を強調することを提案している。
  • 強制は別の場所にある。 Claude Code の舵取り:CLAUDE.md、スキル、フック、サブエージェントをいつ使うか は、決定論的な強制手段としてフックと権限を挙げ、「これは決してするな」は指示に任せるべき仕事ではないと述べている。
  • 成果を打ち消すルール。 AI 貢献の研究では、禁止事項を AGENTS.md にそのまま引用しても、4 つのエージェントのうち 3 つでは拒否率が 0% のままで、4 つ目は 10% になっただけだった。

セキュリティ

これらのファイルを有用にしている性質は、同時にそれらを標的にもする。間接 AGENTS.md インジェクション は、ビルド中に実行される悪意ある依存関係が、ユーザーの要求より優先されると主張する指令を含む AGENTS.md を書き込み、エージェントにそれに従わせる攻撃を説明している。このページは、ファイルの信頼モデルは意図的なものだと述べている。また、この攻撃は侵害された依存関係によるコード実行を前提としていると指摘している。記録されている対策は、ファイルの内容ではなく完全性に関するものである。エージェントが読み書きできるファイルの制限、設定ファイルの完全性管理、そして予期しない変更に対するアラートである。AGENTS.md のページは、codex-1 の優先順位ルールは文書化されたデフォルトであって、注入されたファイルが異を唱えられないものではないと指摘している。

エビデンスが測っているもの

ここに収められた研究や報告は、それぞれ異なるものを測っている。

  • AGENTS.md の有無による効率。 AGENTS.md ファイルが AI コーディングエージェントの効率に与える影響について は、10 リポジトリから取った 124 件のプルリクエストタスクで、ルートの AGENTS.md がある場合とない場合について OpenAI Codex を実行した。実時間の中央値は 28.64%、出力トークンの中央値は 16.58% 減少した。著者らはこれが正しさの評価ではないことを強調しており、研究の対象は 1 つのエージェントと小規模なコードのみの変更である。
  • ファイルの書き手別のタスク成功率。 AGENTS.md に /init を使うのはやめよう の報告によれば、ETH Zurich の研究では、LLM が生成したコンテキストファイルはタスク成功率を 2〜3% 下げ、コストを 20% 以上上げた。開発者が書いたファイルは成功率を約 4% 改善し、コストを最大 19% 上げた。テスト用リポジトリから既存のドキュメントを取り除くと、同じ生成ファイルは性能を 2.7% 改善した。この記事は、効率の研究と成功率の研究を、ファイルが存在するかどうかではなく、何を含むかによって整合させている。
  • ツール横断の普及状況。 エージェント型 AI コーディングツールのためのハーネスエンジニアリング:探索的研究 は、サンプルとした 2,853 リポジトリのうち 2,586 リポジトリで 4,768 個のコンテキストファイルを見出した。最も多かったのは CLAUDE.md(34.4%)で、AGENTS.md(31.6%)、copilot-instructions.md(29.2%)が続いた。493 リポジトリ(17.3%)はツール固有の設定なしに AGENTS.md を使っていた。このヒューリスティクスはファイルの存在を検出するもので、実際に使われているかどうかは検出しない。
  • ルールファイルの内容と遵守の度合い。 AI IDE ルールのページに記録されている AI IDE におけるルールの分類法と進化:マイニングと調査による研究 は、83 プロジェクトから 7,310 件のルールをマイニングした。System Architecture と AI Context Management は最も高く評価されたサブカテゴリに含まれたが、ルール全体に占める割合はそれぞれ 2.67% と 1.76% にすぎなかった。ルールの更新は遵守率を平均 22.99% 引き上げ、その効果は具体的で静的にチェック可能な制約に集中していた。対象プロジェクトは主に、個人開発者または 1〜3 人のチームによる TypeScript の Web 開発である。
  • エージェントがそもそもルールを見つけるか。 AI 貢献の遵守に関する研究では、補助なしの非アンカー実行 347 回のうち、対象のポリシーファイルが開かれたのは 12 回で、補助なしの違反 248 件のうち 242 件はポリシーが一度も開かれないまま起きていた。
  • レビュールール。 OpenAI は、ルールに導かれた Codex Code Review が自社の評価スイートにおいて、必要なカスタム指摘の 98% を回収し、ベースラインは 58.3% だったと報告している。これは独立した測定ではなく社内の結果である。
  • 1 つの大規模プロジェクト。 codified context の論文は、1 人の開発者による 1 プロジェクトの経験報告であり、観察的なケーススタディで、因果的な主張はしていない。
  • まとめて読むと。 Agentic Agile-V: ソフトウェアおよびハードウェア開発におけるバイブコーディングから検証済みエンジニアリングへ は、リポジトリの指示ファイルに関するエビデンスを本当に賛否が分かれているものとして提示している。また、ファイルのサイズ、位置、構造だけで信頼できる遵守効果が生まれるというエビデンスは限られていたとする要因実験の研究も紹介している。2026 年のソフトウェアエンジニアリングの最先端に AI が与える影響 は、話を聞いたチームにとって、コンテキストファイルへの変更が実際に改善になっているかどうかは未解決の問題のままだと報告している。

残りの形式は、別の種類の根拠に立っている。AGENT.md、MentorScript、エージェントプリミティブは提案に、DESIGN.md は公開元の仕様とツールに、GEMINI.md はワークショップと変更履歴に、CLAUDE.md はベンダーのドキュメントと外部企業の推奨に基づいている。