本動画は、コーディングエージェント向けの新しい標準フォーマット「agents.md」について解説したものである。従来、各コーディングエージェントが独自のルールファイル形式を採用していたため、開発者は複数のエージェント間でファイルを使い回すことができず、混乱が生じていた。この問題を解決するため、OpenAI、AMP code、Google Jules、Cursor、Factoryなどの企業が協力してagents.mdという統一標準を策定した。この標準により、プロジェクトのセットアップ方法、テスト手順、コーディングスタイル、セキュリティ要件などを一つのMarkdownファイルで管理できるようになり、開発者の負担が大幅に軽減されることが期待される。
ついに実現！コーディングエージェントの統一標準
コーディングエージェント用の指示ファイルやルールファイルを扱う時の混乱について話そうや。今日では、すべてのコーディングエージェントが独自のルールセットやルール形式を持ってきとるんや。そやから基本的に君のコードリポジトリが指示ファイルの引き出しみたいになってまうんやけど、残念なことにこれらは一つのコーディングエージェントから別のコーディングエージェントには全然使い回しできへんのや。
でも、ついに解決策が出てきたと思うんや。それが今回の動画で話すことなんや。現在の現状はこのツイートでうまく表現されとるわ。これはもう狂気の沙汰やで。我々は一体何をしとるんや？
いろんなコーディングIDEを見てみると、それぞれが独自の方法でこれらのルールや指示ファイルを定義しとるんや。命名規則も違うし、配置場所も違う。そしてMCPの発明がこの混乱をさらに悪化させとると思うわ。
解決策の登場
ほんじゃあ解決策は何やねん？今日、複数の異なる企業からコーディングエージェント用の指示とルールを定義するためにagents.mdを使用することに合意したという発表があったんや。これは開発者にとって素晴らしいニュースやと思うで。なぜなら、もうファイル形式が何やったか、どこにファイルを保存するかを異なるコーディングエージェントごとに覚える必要がなくなるからや。我々のほとんどが複数の異なるコーディングエージェントを使って作業しとるからな。
うまくいけば標準化されて、もっと簡単になるはずや。でも、この取り組みから抜けとる会社もあることに気づくやろう。それについては動画の後半で話すわ。
ほんじゃあこれは一体何やねん？これは2万以上のオープンソースプロジェクトで使われとる、コーディングエージェントをガイドするためのシンプルなオープン形式なんや。
彼らがこの数字を出した方法は、単純にGitHubでagents.mdを検索したんやと思うわ。たくさんの異なるプロジェクトがagents.mdを使とるのが見れるやろ。やから自然な選択なんや。そして良いことに、これらのコーディングエージェントが標準形式に従うことになるんや。
我々はすでにいくつかの例を見とるで。例えば、モデルコンテキストプロトコル。これはAnthropicによって作られて、本当に業界標準になったんや。別の例ではllm.txtがあるな。これはLLM用のrobots.txtの代替みたいなもんや。ウェブクローラー用にはすべてのウェブサイトでrobot.txtがあったんやけど、今はLLMがウェブクローリングする時用にllm.txtを含めることが推奨されとるんや。
agents.mdとは何か
ほんじゃあagents.mdとは一体何やねん？ここで彼らが言うとるのは、READMEは人間のためにデザインされたもんやということや。これはプロジェクトのクイックスタートガイドを提供してくれるんや。プロジェクトに何が含まれとるか、どうやって貢献するかなどをな。
一方、agents.mdは特別にコーディングエージェントにコンテキストを提供するためにデザインされとるんや。これにはプロジェクトのビルド方法、どんなタイプのテストを実行するか、エージェントに従ってほしい特定のコーディング形式があるか、エージェントに注目してほしい特定のセキュリティ懸念があるかなどのステップが含まれるんや。
これはエージェントに明確で予測可能な指示を提供する方法なんや。やからREADMEとは別にしとるんやな。目標は既存のREADMEとドキュメントを補完するエージェント専用のガイドラインを持つことや。
彼らは言うとる。「別の独自ファイルを導入するのではなく、誰でも使える名前と形式を選んだ。コーディングエージェントを構築または使用していて、これが役立つと思うなら、自由に採用してくれ」とな。
現在の企業リストを見ると、OpenAI、AMP code、GoogleのJules、Cursor、Factory、Rodeocodeがあるんや。大きく欠けとるのがあって、それはAnthropicや。Claude codeはまだclaude.mdに従っとるんやけど、願わくば同じ標準に従ってくれることを期待しとるわ。そうすれば開発者にとって楽になるからな。でも時間が教えてくれるやろう。
構造はどうなってるのか
ほんじゃあこれはどう構造化されるべきなんや？ここに例のファイルがあるで。まず環境のセットアップ方法について詳細な指示を提供するんや。例えば、ここでは異なるパッケージのインストール方法やな。たぶんPythonプロジェクトを実行しとるなら、仮想環境をセットアップしたい。そこですべての要件をインストールする方法、それからプロジェクトのテスト方法についての具体的な指示や。
Cursorで作業したことがあるなら、これらのことをCursorルールに入れたいと思うやろう。Claude codeで作業したことがあるなら、claude.mdファイルに入れたいと思うはずや。でも今度は少なくともいくつかのコーディングエージェントが従う標準形式ができるんや。これは良いニュースやし、願わくばコミュニティに幅広く採用されることを期待しとるわ。
agents.mdの使用方法
ほんじゃあ彼らはagents.mdの使用方法について話を続けとるわ。リポジトリのルートにagents.mdファイルを作成するんや。ほとんどのコーディングエージェントは、丁寧に頼めば手伝ってくれるで。AGIが来とるから、すごく丁寧にお願いするのを忘れんといてや。
重要なのは、意味のあるものを作ることや。そこに物をただ詰め込むんじゃなくて、すごくクリーンに保って、コーディングエージェントがプロジェクトをセットアップしたりコードに変更を加えたりする時に実際に有用で役立つコンテキストだけを提供したいんや。
含めたいのは、プロジェクト概要、ビルドとテストコマンド、コードスタイルガイドライン、テスト指示、セキュリティ問題がある場合はそれも含めるんや。特にバイブコーディングをやっとるなら、エージェントシステムでアプリケーションを構築する時にセキュリティについて絶対考えなあかんで。
それから追加の指示も加えることができるんや。コミットメッセージやプルリクエストガイドライン、セキュリティの落とし穴、大きなデータベース、データセット、デプロイメントステップ、新しいチームメイトに教えるようなことは何でもここに書くんや。
大きなモノレポがある場合、つまり非常に大きなコードベースがある場合は、サブプロジェクト用にネストしたagents.mdファイルを使いたいんや。各パッケージ内に別のagents.mdを配置するんや。エージェントは自動的にディレクトリ内の最も近いファイルを読むから、最も近いのが優先される。すべてのサブプロジェクトが専用の指示を提供できるんや。
Claude codeで作業したことがあるなら、非常に似た構造に従っとることが分かるやろう。ルートディレクトリにclaude.mdファイルを持てるし、フォルダ内に独自のものを持てるし、サブフォルダ内に独自の特定の指示セットを作ることもできるんや。全く同じ形式に従っとるのを見るのは良いことや。やからclaude.mdをagents.mdに置き換えることも可能やし、その逆もできるんや。
ここに混乱した巨大なプロジェクトの例があるで。彼らが言うには、これを書いとる時点でメインのOpenAIリポジトリには88個のagents.mdファイルがあるそうや。これはちょっと狂っとるな。やからエージェントがこのプロジェクトで作業しとるなら、どのサブコンポーネントで作業しとるかによって、その特定のagents.mdファイルを選ばなあかんのや。正直、これらのコーディングエージェントがかわいそうに感じる時があるわ。
よくある質問
それから彼らはよくある質問のセクションを持っとるんや。必須フィールドはあるんか？agents.mdはただの標準Markdownや。好きな見出しを使えばええんや。エージェントは君が提供するテキストをそのまま解析するから、フォーマットについては全く心配する必要がないんや。agents.mdファイルにある指示セットが何かということだけや。
これらのファイルで指示が競合する場合はどうなるんか？彼らが言うには、編集されるファイルに最も近いagents.mdが勝つんや。明示的なユーザーチャットプロンプトは何でも上書きするんや。やから異なるファイルで競合する指示があっても、編集されとる現在のファイルの近接性に応じて、見つけることができる最も近い指示の一つを選ぶんや。
エージェントはagents.mdにあるテストコマンドを自動的に実行するんか？ここで彼らが言うには、はい。リストアップすれば、エージェントは関連するプログラム的チェックを実行しようとして、タスクを完了する前に失敗を修正するんや。
これは特に大きなコードベースで作業しとる場合に非常に重要や。テスト駆動開発をやりたいし、個人的な経験では、これがたぶんコーディングエージェントの最高の使用例やと思うわ。コードのテストケースを書いてもらって、それらを実行してもらいたいんや。
これらは生きた文書として想定されとるんや。プロジェクトを通して進歩するにつれて、プロジェクトの状態に基づいてそれらを更新し続けたいんや。
既存のドキュメントをagents.mdに移行するにはどうしたらええんか？彼らは既存のファイルをagents.mdにリネームして、適切な場所に配置することを推奨しとるわ。やからClaude codeでclaude.mdを持っとって、それをCursorで使いたいなら、agents.mdにリネームするだけでええんや。そしたらCursorがそこから拾ってくれるはずや。
agents.mdをコーディングエージェントで使う方法についてフォローアップ動画を作るかもしれんわ。他の指示ファイルを使っとるなら、これに置き換えてコーディングエージェントを更新すれば、拾ってくれるはずや。でも興味があるかどうか教えてくれや。
関わっとる企業とプロジェクト
ほんじゃあ関わっとる企業やプロジェクトを簡単に見てみよう。それと、動画の新しい形式を試しとるから、どう思うか教えてくれや。
まずOpenAI CodeXや。正直、しばらく試してへんのや。新しいGPT-4oでもう一度チェックしてみる価値があるかもしれんな。ここ数週間は主にClaude codeを使っとるわ。
次はAMP codeや。Xで結構聞いたことがあって、正直ウェブサイトは本当に良く見えるわ。オープンソースプロジェクトではないんやけど、価格設定はCursorみたいなのと比べて絶対に良いし、もっと透明やと思うわ。
次はFactory AIや。これは新しいやつやな。あまり知らんのや。誰か知っとる人おる？全然聞いたことがないと思うわ。
GoogleのJulesについてはすでに知っとるな。興味深いことに、Gemini CLIはリストに載ってへん。少なくともメインウェブサイトには載ってへんな。Gemini CLIはGemini.mdを使っとるんや。やからGemini CLIチームがagents.mdを代わりに使うことを決めるかどうか見るのは興味深いやろうな。
それからオープンソースプロジェクトのRodeocodeがあるで。やからClientみたいなオープンソースプロジェクトが同じ形式を採用する可能性は大きいと思うわ。
今はまだ非常に初期段階やな。採用された標準の良い例はMCPやけど、うまくいかなかった異なる企業によって提案された標準の他の例もあるんや。やからどうなるか見てみようや。でも君の考えを教えてくれや。これについてどう思うか、自分のコーディングエージェントでどう使うかをな。
とにかく、今回の動画はこれで終わりや。この動画が役に立ったと思ってくれたら嬉しいわ。見てくれてありがとう。いつものように、次の動画で会おうな。
コメント