3行まとめ
AGENTS.mdは、AIコーディングエージェントに読ませるプロジェクト固有の作業ルールとして扱います。
Agentic AI Foundation配下のプロジェクトとして扱われ始めましたが、全ツールが同じ挙動になるとは限りません。
セットアップ、テスト、レビュー前チェックはAGENTS.mdへ寄せ、ツール固有設定は補助レイヤーに残します。
AGENTS.mdはREADMEの置き換えではなく、AIに渡すチーム共通の作業文脈です。
- AGENTS.mdは「AIコーディングエージェントに読ませる共通のプロジェクト契約」として使うと効果が出やすいです。READMEや人間向け手順を置き換えるものではありません。
- 2025年12月9日のLinux Foundation発表では、Agentic AI Foundationの立ち上げとともにMCP、goose、AGENTS.mdが主要プロジェクトとして示されました。ただし、全ツールが同じ優先順位でAGENTS.mdを読む、という意味ではありません。
- 実務では、セットアップ、テスト、コード規約、レビュー前チェックはAGENTS.mdに寄せ、Copilot、VS Code、Claude Code、Windsurfなどのツール固有設定は補助レイヤーとして残すのが安全です。
この記事では、2026年6月9日朝に確認した公式一次情報をもとに、AGENTS.mdをチーム運用に入れるかどうかを判断します。X/Twitterは需要シグナルとして確認しましたが、対象アカウントの直近72時間の本文を安定して取得できず、古い検索結果も混ざったため、本文の事実根拠には使いません。
この記事でわかること
AAIF配下のプロジェクトとして扱われることが、チーム運用に何をもたらすかを確認します。
AGENTS.mdに統一しやすい内容と、ツール別ファイルに残す内容を分けます。
Codex、GitHub Copilot、VS Code、Claude Code、Windsurfの指示ファイルを比較します。
最初のAGENTS.mdに入れる項目と、入れないほうがよい項目を整理します。
指示衝突、古いコマンド、権限の誤解などを見つける観点を持ちます。
誰が更新し、誰がレビューし、どの条件で削るかを決めます。
導入可否は流行ではなく、指示の重複、レビュー負荷、検証できるタスクの有無で判断します。
- AGENTS.mdがAgentic AI Foundation配下のプロジェクトとして扱われることの実務上の意味
- AGENTS.mdに統一しやすい内容と、ツール別ファイルに残すべき内容
- Codex、GitHub Copilot、VS Code、Claude Code、Windsurfの指示ファイルを比べる時の見方
- 最小AGENTS.mdを作る時に入れる項目と、入れてはいけない項目
- 導入後に起きやすい失敗、指示衝突、古いコマンド、権限の誤解を見つける方法
- チームで更新責任、レビュー導線、セキュリティ確認を決める手順
AIコーディングエージェント全体の導入判断から見たい場合は、公開済みのAIコーディングエージェントカテゴリや比較表も合わせて確認してください。
前提知識
- README
人間向けのクイックスタートやプロジェクト説明を置きます。
- 指示が散らばる
Slack、Issue、各ツール用ファイル、個人設定に注意点やコマンドが分散します。
- AGENTS.md
AIエージェント向けの詳細な文脈を、リポジトリ内の共通ファイルとして渡します。
標準化が完了したというより、チームで読ませる指示の置き場を揃えやすくなったと捉えます。
AGENTS.mdは、リポジトリ内に置くMarkdownファイルです。目的は、AIコーディングエージェントに対して、プロジェクト固有の作業ルール、セットアップ、テスト、レビュー前チェック、注意点を安定して渡すことです。
公式サイトの説明では、README.mdは人間向けのクイックスタートやプロジェクト説明、AGENTS.mdはエージェント向けの詳細な文脈という位置づけです。つまり、AGENTS.mdを作る理由は「人間向けREADMEを長くしないため」でもあり、「チャットで毎回同じ注意を伝えなくてよい場所を作るため」でもあります。
標準化されたから、すぐ全社展開できるわけではない
Linux Foundationは2025年12月9日、Agentic AI Foundationの設立を発表しました。その発表では、AnthropicのMCP、Blockのgoose、OpenAIのAGENTS.mdが主要な技術プロジェクトとして挙げられています。AAIFのAGENTS.mdページも、AGENTS.mdをAIコーディングエージェントがプロジェクト指示、ガイドライン、文脈を理解するためのオープンな形式として扱っています。
ここで注意したいのは、「財団配下のプロジェクトになった」ことと「すべてのAIツールが同じ読み方をする」ことは別だという点です。実際のツール側では、AGENTS.md以外にも.github/copilot-instructions.md、.github/instructions/*.instructions.md、CLAUDE.md、WindsurfのRulesやMemoriesなど、既存の指示レイヤーがあります。
根拠として扱う範囲
この記事で事実として扱うのは、Linux Foundation、AAIF、agents.md、OpenAI Codex、GitHub Docs、VS Code Docs、Anthropic Claude Code Docs、Windsurf Docsで確認できた範囲です。Cursorのrules関連ページは公式URLの取得に制限があったため、本文では詳細な優先順位やファイル名の断言を避けます。
誤解しやすい点
AGENTS.mdは自然言語の指示ファイルです。権限を強制する仕組みではありません。「APIキーを見ない」「本番DBを触らない」「承認なしでデプロイしない」と書くことは重要ですが、それだけで技術的に防止できるわけではありません。権限、承認、ネットワーク制御、secret管理、branch protectionは別に設計します。
AGENTS.mdが解決するのは「指示の置き場」問題
AIコーディングエージェントをチームで使い始めると、同じ注意書きがいくつもの場所に散ります。
- READMEには人間向けのセットアップがある
- SlackやIssueにはその場限りの注意が残る
- Copilot用、Claude用、Windsurf用の指示ファイルが増える
- 個人のローカル設定にだけ、便利なコマンドや禁止事項が残る
- PRレビューで「そのテストも走らせて」と毎回指摘する
AGENTS.mdは、このうち「リポジトリにコミットして、複数のエージェントに共通で読ませたい内容」の置き場として使えます。チームが最初に決めるべきなのは、AGENTS.mdを作るかどうかではなく、どの指示を共通契約に昇格させるかです。
結果: AGENTS.mdは共通契約、ツール別指示は補助レイヤー
AGENTS.mdを入れても、Copilot、Claude Code、Windsurfなどの既存ファイルをすぐ消す必要はありません。
今回の結論はシンプルです。複数のAIコーディングツールを使うチームでは、AGENTS.mdを共通契約として置く価値があります。ただし、ツール別の指示ファイルや管理者設定を消す必要はありません。
| 指示の種類 | AGENTS.mdに向くか | 理由 |
|---|---|---|
| セットアップ手順 | 向く | 複数ツールで共通して必要になる |
| Lint、typecheck、testコマンド | 向く | AIの作業品質を同じ基準で見られる |
| コード規約、命名規則 | 向く | レビュー指摘を減らしやすい |
| PR前チェック | 向く | 未検証報告やテスト結果を揃えられる |
| パス別の細かい規約 | 条件付き | モノレポではネストしたAGENTS.mdやパス別instructionsと比較する |
| 個人の作業好み | あまり向かない | チーム契約ではなく個人設定に残すほうがよい |
| ツール固有のUIや応答スタイル | あまり向かない | VS Code、Copilot、Claude、Windsurf側の設定が向く |
| 秘密情報、APIキー、社内限定URL | 入れない | エージェントに渡す文脈へ秘密を混ぜない |
| 承認を省く指示 | 入れない | セキュリティ境界を弱める |
AGENTS.mdに寄せるべき共通指示
AGENTS.mdに入れる内容は、複数のツールで共通して効いてほしいものに絞ります。たとえば、次のような項目です。
- パッケージマネージャとセットアップ手順
- よく使う開発コマンド
- Lint、typecheck、unit test、E2E testの実行条件
- 変更前に読むべき設計メモやADR
- コード規約、命名規則、生成物を編集しないルール
- PR説明に必ず書くこと
- 触ってはいけない領域
- secret、個人情報、本番データを扱う時の禁止事項
条件
AGENTS.mdに入れる前に、その指示が「実行できる」「確認できる」「レビューできる」かを見ます。「品質を大切にする」より、「npm run lintとnpm testを実行し、失敗した場合は修正せずにログを残して相談する」のほうが実務に残ります。
確認項目
同じ注意をPRレビューで3回以上言っているなら、AGENTS.mdに入れる候補です。逆に、一度だけの暫定メモや個人の好みは、AGENTS.mdに入れるほどではありません。
ツール別に残すべき指示
GitHub CopilotやVS Codeには、リポジトリ全体のcustom instructions、パス別instructions、AGENTS.mdやCLAUDE.mdの扱いがあります。Claude CodeにはCLAUDE.mdやmemoryがあります。WindsurfにはRules、Memories、AGENTS.mdの扱いがあります。
これらをAGENTS.mdに無理に統合すると、かえって運用が荒れます。たとえば、VS Code内の応答スタイル、個人のショートカット、Claude Codeだけで使うmemory、Windsurfのactivation modeは、それぞれのツール側に残したほうが自然です。
判断基準
リポジトリにコミットして、チーム全員がレビューし、複数エージェントに読ませたいものはAGENTS.md。特定ツールのUI、個人設定、モデルごとの挙動補正、IDE拡張の出力形式はツール別ファイル。この分け方にすると、ファイルは増えても責任範囲が見えます。
注意点
AGENTS.mdとツール別指示が矛盾すると、エージェントはその場のコンテキストや優先順位に従って動きます。人間が期待したほうを必ず選ぶとは限りません。導入直後は「どの指示を読んだか」「どのコマンドを実行したか」をログに残す検証タスクを作ります。
主要ツールの指示ファイルはどう住み分けるか
対応範囲は更新されやすいため、導入前には各ツールの公式ドキュメントで再確認します。
ここでは公式ドキュメントで確認できる範囲に絞って、指示ファイルの住み分けを見ます。細かい対応範囲は更新されやすいため、導入前には各ツールの公式ドキュメントで再確認してください。
| ツールまたは環境 | 主な指示ファイルや機能 | 実務での見方 |
|---|---|---|
| OpenAI Codex | AGENTS.md、AGENTS.override.md、グローバルとプロジェクトの指示 | Codex中心なら、ルートとサブディレクトリの指示チェーンを確認する |
| GitHub Copilot | .github/copilot-instructions.md、.github/instructions/*.instructions.md、AGENTS.mdなどのagent instructions | Copilot機能ごとの対応差を確認し、既存.github系をすぐ消さない |
| VS Code Copilot | .github/instructions、ユーザーレベルinstructions、AGENTS.md、CLAUDE.mdなど | IDE内の応答やパス別指示はVS Code側に残しやすい |
| Claude Code | CLAUDE.md、memory、managed settings | チームでレビューしたい内容と、個人や管理者レイヤーのmemoryを分ける |
| Windsurf | Rules、Memories、AGENTS.md | AGENTS.mdはlocation-scoped rulesとして扱われるため、Rulesとの重複を確認する |
Codexでは指示チェーンを意識する
OpenAI CodexのAGENTS.mdガイドでは、Codexが起動時にグローバルスコープとプロジェクトスコープの指示を組み合わせる流れが説明されています。プロジェクトスコープでは、通常Git rootから現在の作業ディレクトリまでをたどり、各ディレクトリでAGENTS.override.md、AGENTS.mdなどを確認します。近いディレクトリの指示ほど後ろに結合されるため、より具体的な指示として働きます。
この挙動を前提にするなら、モノレポではルートAGENTS.mdに全チームの細部を詰め込むより、共通契約をルートに置き、サブディレクトリに短い補足を置くほうが読みやすくなります。
確認項目
Codexに「読み込んだ指示ファイルを列挙して」と頼む検証タスクを作ります。期待したAGENTS.mdが出なければ、作業ディレクトリ、Git root、ファイル名、サイズ上限、overrideの有無を確認します。
GitHub CopilotとVS Codeでは既存instructionsを活かす
GitHub Docsでは、Copilotのrepository custom instructionsとして、リポジトリ全体に効く.github/copilot-instructions.md、パス別に効く.github/instructions/*.instructions.md、AGENTS.mdやCLAUDE.mdなどのagent instructionsが説明されています。さらに、GitHub.comとVS Codeで利用できる種類や対応機能が異なる場合があります。
VS Code Docsでは、workspaceレベルとuserレベルのcustom instructions、.instructions.mdファイル、AGENTS.md、CLAUDE.mdの扱いが説明されています。特に.instructions.mdは、言語、チーム、モジュールごとに分けやすい形式です。
判断基準
Copilot中心のチームなら、既存の.github/copilot-instructions.mdや.github/instructionsを残したまま、複数ツールにも読ませたい最低限だけAGENTS.mdへ出します。いきなりAGENTS.mdへ全移行すると、Copilot機能ごとの対応差やパス別設定を見落とします。
Claude CodeとWindsurfでは「memory」と「レビュー可能な契約」を分ける
Claude Codeのmemoryは便利ですが、すべてをチーム契約にするものではありません。Anthropicのドキュメントでは、settingsで強制される項目と、CLAUDE.mdでClaudeの振る舞いを形づくる項目は別物として扱われています。これはAGENTS.mdにも当てはまります。自然言語の指示は行動を促しますが、権限を技術的に強制する層ではありません。
Windsurfのドキュメントでは、Memoriesは会話をまたぐ文脈、Rulesはユーザーが定義する挙動指定、AGENTS.mdはlocation-scoped rulesとして整理されています。Windsurfを使うチームでは、RulesとAGENTS.mdの重複を点検し、どちらを正とするかを決めます。
注意点
memoryは更新されやすく、誰がいつ変更したかがコードレビューに残りにくい場合があります。セキュリティ、テスト、レビュー前チェック、作業禁止領域のようにチームで監査したい内容は、リポジトリにコミットされるファイルへ寄せます。
AGENTS.md導入を判断するチェックリスト
- 1複数のAIツールを使っているか
Codex、Copilot、Claude Code、Windsurfなどを併用しているなら共通化の効果が出やすくなります。
- 2共有したい指示があるか
テストコマンド、禁止領域、レビュー前チェックが繰り返し説明されているかを見ます。
- 3既存ファイルと衝突していないか
pnpm、npm、yarnのようにツール別ファイルで違う指示が出ていないかを確認します。
- 4検証タスクを作れるか
小さな修正やテスト修正で、AIが指示を読んだかを確認します。
- 5最小AGENTS.mdから始める
条件が揃うなら、1リポジトリで短いAGENTS.mdを試します。
使っているAIツールが1つだけで既存instructionsが短い場合は、急がず現状整理から始めます。
AGENTS.mdを入れるかどうかは、流行ではなく運用条件で決めます。次の問いに多く当てはまるなら、最小のAGENTS.mdから始める価値があります。
導入に向いているチーム
- Codex、Copilot、Claude Code、Windsurfなどを併用している
- README、人間向けドキュメント、AI向け指示が混ざっている
- PRレビューで同じテスト未実行を繰り返し指摘している
- モノレポで、作業ディレクトリごとにコマンドが違う
- 触ってはいけない生成ファイル、移行ファイル、本番設定がある
- 新しいメンバーや外部協力者に同じ注意を何度も説明している
- AIエージェントの作業ログをチームで比較したい
上振れ
うまく運用できると、AIが毎回間違えるパッケージマネージャ、テストコマンド、PR説明の抜け、生成ファイルの編集などが減ります。レビュー担当者は「何を確認したか」を差分とログで追いやすくなります。
まだ急がなくてよいチーム
- 使っているAIツールが1つだけで、既存のinstructionsが短く整理されている
- リポジトリが小さく、セットアップやテストがREADMEだけで十分伝わる
- AI利用が個人実験の段階で、チームのレビュー対象になっていない
- 指示ファイルを更新する責任者を決められない
- セキュリティや権限設計をまだ固めていない
下振れ
AGENTS.mdを置くだけで運用が整うわけではありません。古いコマンドが残る、ツール別指示と矛盾する、秘密情報に近い内容を書く、承認を省く方向に使う、誰も更新しない、といった失敗が起きます。
導入判断の簡易フロー
1つでも迷う場合は、次の順番で判断します。
- 複数のAIコーディングツールで同じリポジトリを触るか
- チームでレビューしたい共通指示があるか
- 既存のCopilot、Claude、VS Code、Windsurf向け指示と衝突しないか
- 1つの小さな修正タスクで効果を確認できるか
- 更新責任者とレビュー条件を決められるか
1と2がYESなら、最小AGENTS.mdを試す価値があります。3がNOなら、先に指示ファイルの棚卸しをします。4と5がNOなら、ファイルを作る前に検証タスクと運用責任を決めます。
最小AGENTS.mdを作る手順
重要なのは量ではなく、AIが実行すべき作業と避けるべき作業が曖昧でないことです。
最初から大きなテンプレートを全リポジトリへ配るのは避けます。まずは1リポジトリ、1チーム、1週間程度で検証できる短さにします。
最初に入れる項目
最小構成は次の程度で十分です。実際のコマンドやパスは、自分のリポジトリに合わせて置き換えてください。
# AGENTS.md
Project rules
- Use pnpm for package management. Do not use npm or yarn in this repository.
- Before opening a PR, run `pnpm lint`, `pnpm typecheck`, and the relevant test command.
- Do not edit generated files under `src/generated/`.
- Do not read, print, or commit secrets. Use dummy values in examples.
Common commands
- Install: `pnpm install`
- Lint: `pnpm lint`
- Typecheck: `pnpm typecheck`
- Unit tests: `pnpm test`
PR expectations
- Summarize changed files and behavior.
- Include commands run and their result.
- If a command was not run, explain why.
- Call out security, migration, or data-handling risks.この程度でも、AIに毎回伝える手間はかなり減ります。重要なのは、内容を増やすことではありません。AIが読んだ時に、実行すべき作業と避けるべき作業が曖昧でないことです。
入れないほうがよい内容
秘密情報、社内の非公開URL、顧客名、APIキー、個人情報、本番DBの接続情報、承認を回避する指示は入れません。必要な例はダミー値にします。ファイルに書くほどではない一時的な会話メモも、AGENTS.mdには入れません。
検証タスクを作る
AGENTS.mdを作ったら、実際にAIエージェントへ小さな作業を頼みます。たとえば「フォームのラベルを1つ修正する」「失敗している単体テストを1件直す」「READMEの古いコマンドを更新する」程度で十分です。
記録する項目は次の通りです。
| 項目 | 見ること |
|---|---|
| 参照された指示 | 期待したAGENTS.mdやツール別instructionsが読まれたか |
| 実行されたコマンド | AGENTS.mdに書いたlint、typecheck、testが実行されたか |
| 差分品質 | 不要なファイル変更や生成物編集がないか |
| 未検証報告 | 実行しなかったコマンドを正直に書いたか |
| 指示衝突 | AGENTS.mdとツール別指示が矛盾していないか |
| 更新要否 | AGENTS.mdに足すべき項目、削るべき項目が見えたか |
成功条件
1回の成功で全社展開を決めるのではなく、同じタスクを2つ以上のツールで試します。共通の注意がAGENTS.mdで効き、ツール固有の補正が各instructionsで効いているなら、住み分けはうまくいっています。
失敗点
「品質を重視」だけでは検証できません。実行コマンドと未実行時の報告方法まで書きます。
AGENTS.mdではpnpm、別ファイルではnpmのような衝突を棚卸しします。
指示ファイルは権限管理そのものではありません。実際の権限設定や承認手順と併用します。
コマンドやディレクトリが変わった時に、更新責任者が直せる状態にします。
AIが守ったか、守れなかったか、どの指示が衝突したかをレビューで確認します。
AGENTS.md導入で一番多い失敗は、ファイルを作ったこと自体を成果にしてしまうことです。AIが守ったか、守れなかったか、どの指示が衝突したかを見なければ、単なるドキュメント追加で終わります。
失敗1: 指示が抽象的すぎる
「品質を重視してください」「安全に作業してください」のような文は、方向性としては正しいですが、そのままでは検証できません。AIは何を実行すればよいか判断しづらく、人間も守られたかを確認できません。
修正例
「PR前にpnpm lint、pnpm typecheck、変更箇所に関係するテストを実行する。実行できない場合は、理由と代替確認をPR本文に書く」とします。
失敗2: ツール別指示と矛盾する
AGENTS.mdではpnpm、Copilot instructionsではnpm、CLAUDE.mdではyarnと書かれているような状態です。この場合、エージェントは一貫して動けません。レビュー担当も、どの指示が正しいか判断できません。
修正例
共通のパッケージマネージャとテストコマンドをAGENTS.mdへ寄せ、ツール別ファイルから重複する記述を削るか、AGENTS.mdを参照する形に変えます。
失敗3: 権限を指示ファイルで強制したつもりになる
「本番DBに接続しない」とAGENTS.mdに書くことは大事です。ただし、権限が残っていれば、技術的には接続できてしまう場合があります。AIの自然言語指示と、実際の権限設定を混同しないでください。
修正例
本番DBの認証情報を開発環境に置かない、read-only権限から始める、危険なコマンドは承認必須にする、CIやbranch protectionでレビューを強制する、といった別レイヤーの対策を入れます。セキュリティ設計の深掘りはSecurityカテゴリで関連テーマを追うとよいです。
失敗4: AGENTS.mdが古くなる
パッケージマネージャ、テストコマンド、ディレクトリ構成、CIの名前は変わります。古いAGENTS.mdをAIが信じると、かえって作業が遅くなります。
修正例
月次、リリース前、CI変更時、package manager変更時にAGENTS.mdを確認する運用を入れます。CIファイル、package.json、README、PRテンプレートと内容がずれていないかを見るだけでも効果があります。
実務で使うなら
- 1既存指示を棚卸しする
README、Copilot instructions、CLAUDE.md、Windsurf Rulesなどを確認します。
- 2共通指示を移す
重複するセットアップ、テスト、レビュー前チェックを短いAGENTS.mdへまとめます。
- 3小さな修正タスクを選ぶ
影響範囲が小さく、レビュー担当者が確認できる作業を2本選びます。
- 4参照と実行を記録する
使うAIツールごとに、参照された指示と実行コマンドを残します。
- 5レビューで判断する
残す内容、ツール別に戻す内容、削る内容を決めます。
作成者だけが熱心でも続かないため、更新責任、レビュー条件、削除条件を先に決めます。
実務導入では、AGENTS.mdを「開発チームがレビューする契約ファイル」として扱います。作成者だけが熱心でも続きません。更新責任、レビュー条件、削除条件を決めます。
1リポジトリから始める
最初は、影響範囲が小さく、テストが整っていて、レビュー担当者がいるリポジトリを選びます。大規模モノレポ全体にいきなり入れるより、1つのサービスや1つのパッケージで検証したほうが、ズレを見つけやすくなります。
1週間パイロットの流れ
- 既存のREADME、Copilot instructions、CLAUDE.md、Windsurf Rulesを棚卸しする
- 重複する共通指示を短いAGENTS.mdへ移す
- 小さな修正タスクを2本選ぶ
- 使うAIツールごとに、参照された指示と実行コマンドを記録する
- PRレビューで差分、ログ、未検証報告を確認する
- AGENTS.mdに残す内容、ツール別に戻す内容、削る内容を決める
更新責任を決める
AGENTS.mdのオーナーは、単に「AIに詳しい人」ではなく、対象リポジトリの開発手順を知っている人にします。セキュリティ、CI、デプロイ、DB migrationに関わる指示は、担当者レビューを必須にします。
| 変更内容 | レビューすべき人 |
|---|---|
| テストコマンド変更 | 開発リードまたはCI担当 |
| 権限や承認の説明 | セキュリティ担当または管理者 |
| DB migration手順 | DB担当またはSRE |
| 生成ファイルの扱い | 対象領域のオーナー |
| PR前チェック | 開発リード |
CTAは「比較」と「継続更新」に置く
AGENTS.mdは導入判断の一部です。どのAIコーディングツールを使うか、どの権限で始めるか、どの検証タスクを使うかは別に決めます。ツール選定の全体像は比較表から見ると整理しやすいです。更新情報を継続して追う場合はニュースレターも用意しています。
セキュリティ・コスト注意
APIキー、トークン、cookie、SSH鍵、顧客名、個人情報、本番DB接続情報は避けます。
攻撃手順ではなく、secretをログに出さない、外部入力を信用しない、などの実務ルールにします。
文脈が増えすぎると重要な指示が埋もれ、読み込み上限や費用にも影響します。
読み込むファイル数、サイズ上限、優先順位、対応機能はツールごとに変わります。
法務、セキュリティ、顧客契約、監査ログ、データ保持のルールと矛盾しないようにします。
セキュリティ、コスト、コンプライアンスは勝敗ではなく、チームごとの確認条件として扱います。
AGENTS.mdは便利ですが、プロンプトの一部として扱われます。長くしすぎると、AIに渡す文脈が増え、重要な指示が埋もれます。ツールやモデルによっては、読み込むファイル数、サイズ上限、優先順位、対応機能が変わるため、公式docsで確認します。
セキュリティ注意
AGENTS.mdに書いてよいのは、AIに渡しても問題ない作業ルールだけです。たとえば、次の内容は避けます。
- APIキー、トークン、cookie、SSH鍵
- 顧客名や個人情報を含む実データ
- 社内限定URLや認証情報に近い情報
- 本番DBへの接続方法
- 監査や承認を回避する手順
- 攻撃手順や悪用可能な具体手順
防御目的の注意を書く場合でも、実在サービスへの攻撃手順に見える内容は避けます。「外部入力を信用しない」「ユーザー提供URLを実行しない」「secretをログに出さない」のように、実務上の防御ルールに落とします。
コスト注意
AGENTS.mdが長すぎると、AIエージェントが読む文脈が増えます。1回あたりのトークン量、応答遅延、モデルコスト、重要指示の見落としが増える可能性があります。全社共通テンプレートを厚くするより、ルートは短く、必要なサブディレクトリにだけ補足を置くほうが扱いやすいです。
コンプライアンス注意
AI生成内容は、最終判断ではありません。AGENTS.mdを更新する時も、AIに原案を書かせることはできますが、公開判断、権限判断、セキュリティ判断は人間が確認します。特に、管理者設定、権限、ログ保持、学習利用、データ保持ポリシーは、ツールごとの公式資料を確認してください。
次に読むなら
参照した主な情報源
- Linux Foundation, "Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions Including Model Context Protocol (MCP), goose and AGENTS.md"
https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
- Agentic AI Foundation, "AGENTS.md"
https://aaif.io/projects/agents-md/
- AGENTS.md official guide
https://agents.md/
- OpenAI Developers, "Custom instructions with AGENTS.md"
https://developers.openai.com/codex/guides/agents-md
- GitHub Docs, "About customizing GitHub Copilot responses"
https://docs.github.com/en/copilot/concepts/prompting/response-customization
- Visual Studio Code Docs, "Use custom instructions in VS Code"
https://code.visualstudio.com/docs/copilot/customization/custom-instructions
- Anthropic Docs, "How Claude remembers your project"
https://docs.anthropic.com/en/docs/claude-code/memory
- Windsurf Docs, "Cascade Memories"
https://docs.windsurf.com/windsurf/cascade/memories
更新履歴
- 2026-06-09
Linux Foundation、AAIF、agents.md、Codex、GitHub Copilot、VS Code、Claude Code、Windsurfの公式情報を確認しました。
- 確認範囲
AGENTS.mdをチーム運用に入れる判断基準として整理し、取得に制限があった情報は詳細比較から外しました。
相対的な新しさではなく、確認した日付と情報範囲を明示して扱います。
- 2026-06-09: Linux Foundation、AAIF、agents.md、OpenAI Codex、GitHub Copilot、VS Code、Anthropic Claude Code、Windsurfの公式情報を確認し、AGENTS.mdをチーム運用に入れる判断基準として整理しました。Cursor rulesは公式ページ取得に制限があったため、詳細な挙動比較から外しました。