技術の進化は早いもので、愛用しているAIエディタ「Cursor」に、また何やら凄そうな機能が追加されていました。
最近、Cursorのアップデート情報や開発者コミュニティで見かけるようになった 「Subagents」 という言葉。
「エージェントの中にさらにエージェントがいるの？」と気になって、その正体と、セットで語られることが多い 「AGENTS.md」 について徹底的に深掘りして調べてみました。
「あれ、アップデートしたのにSubagentsなんてボタン、どこにもなくない？」と思った方もご安心を（実は私もそうでした）。
今回は、その隠れた場所と、実はCursor発ではない「AGENTS.md」の意外な出自についても解説します。
結論から言うと、これ、「指示待ちAI」を「自律して動く同僚」に変える神アップデート です。
「Subagents」は、頼れる特化型のアシスタント
これまで、CursorのAI（Composer）に何かを依頼すると、今のチャットの流れの中で一生懸命考えてくれていました。
しかし、大規模な修正や複雑な調査を頼むと、チャット履歴が長くなりすぎてAIが混乱したり、レスポンスが重くなったりすることもしばしば。
そこで登場したのが 「Subagents」 です。
Subagentsは「どこ」にいるのか？（UIのナゾ）
実はSubagentsは、単独のボタンとして存在するわけではありません。
主な出現場所とトリガーは以下の通りです：
- Composer（Ctrl + I）の「Agent Mode」内: プロ版などで使用可能な「Agent Mode」で複雑なタスクを依頼した際、メインのAIが「これは分担が必要だ」と判断したときに、内部的に（あるいはバックグラウンドで）起動されます。
.cursor/agents/フォルダ: プロジェクト内にこのフォルダを作り、Markdownファイルを置くことで、特定の役割を持ったSubagentを「定義」することができます。
つまり、Subagentsは「使う・使わない」を設定するツールというより、AIがより賢く動くための 「仕組み（アーキテクチャ）」 そのものなのです。
サブエージェントが独立して動くことで、メインのコンテキスト（記憶力）を節約でき、より正確で高速なやり取りが可能になります。
「AGENTS.md」はAIのためのプロジェクト憲法
さらに深掘りして驚いたのが、この 「AGENTS.md」 という規格です。
実はこれ、Cursorが独自に作ったものではありません。OpenAI、Google、Anthropicのエンジニア、そしてCursorなどのチームが共同で策定を進めている「オープンな標準規格」 なのです。
なぜ今、AGENTS.md なのか？
人間が読むための README.md がOSSの標準になったように、AIエージェントがコードを書く時代には「AI専用の指示書」が必要だという背景から生まれました。
2024年末ごろから提唱され始め、2025年、2026年と急速に普及しています。今やGitHub上の数万件ものリポジトリが、この AGENTS.md を採用し始めています。
README.md との違い
| 特徴 | README.md | AGENTS.md |
|---|---|---|
| 主な対象 | 人間（開発者） | AIエージェント |
| 内容 | ビジョン、環境構築手順 | コーディング規約、テストルール |
| 場所 | プロジェクトのトップ | 各プロジェクト/ディレクトリ |
【実践】Python API開発でAIに「教育」してみた
私のブログでもよく扱う PythonでのAPI開発 を例に、AGENTS.md でどんな教育ができるか見てみましょう。
例えば、FastAPIなどを使ったプロジェクトで以下のようなルールを AGENTS.md に追加しておきます。
# Python API プロジェクト規範
## コーディング・規則
- 常に Python 3.12 基準のシンタックスを使用すること。
- スキーマ定義には `Pydantic v2` を使用し、フィールドには必ず `Field(description=...)` を含めること。
- Endpointsの戻り値は常に `ResponseModel` でラップすること。
## 設計方針
- 非同期処理（async/await）をネイティブにサポートするライブラリを優先すること。
- データベース操作は `SQLAlchemy 2.0` (Async) を使用し、Repositoryパターンを適用すること。
## テスト
- テストは `pytest-asyncio` を使用し、カバレッジ80%以上を目指す構成にすること。こうすることで、Subagents に「新しいユーザー登録用のAPIエンドポイントを作成して」と頼むだけで、AIは勝手にスキーマ規約を守り、ドキュメント用の説明文を入れ、リポジトリ層との連携も正しく実装してくれるようになります。
応用編：自作Subagentの定義とMonorepo対応
さらに使い込みたい方向けに、もう一歩踏み込んだ活用法をご紹介します。
自作Subagentの作り方
.cursor/agents/reviewer.md のようなファイルを作成し、冒頭にYAML形式のメタデータを記述することで、独自の役割を持ったSubagentを作成できます。
---
name: code-reviewer
description: セキュリティとパフォーマンスに特化したコードレビューを担当
---
あなたはセキュリティ専門のコードレビュアーです。
以下の観点でコードをチェックし、問題があれば修正案を提示してください：
1. SQLインジェクション等の脆弱性がないか
2. Pydanticスキーマのバリデーションが十分か
3. 無駄なDBクエリ（N+1問題）が発生していないかこのように定義しておくと、メインのComposerがリファクタリングを行う際に、この code-reviewer を呼び出して意見を求める、といった AI同士のコラボレーション が始まります。
Monorepo（複数プロジェクト）への対応
AGENTS.md の面白い特徴として、「ディレクトリごとに置ける」 という点があります。
ルートにある AGENTS.md は全体ルールを、各サービスディレクトリ（例: /auth-service/AGENTS.md）にはそのサービス専用のルールを書くことで、AIは現在作業している場所に最も近いルールを優先して読み取ってくれます。
実際に使ってみて感じた「同僚感」
正直、これまではAIに「指示を出して直させる」という、どこか「道具」を使っている感覚が強かったです。
しかし、Subagents と AGENTS.md を使いこなすと、「優秀なエンジニアに、プロジェクト独自のルールを伝えて任せる」 という感覚に近くなります。
細かい指示を飛ばさなくても、裏側で「自分で考え、ルールを守り、結果だけを報告してくれる」姿は、まさに 「同僚」 そのものでした。
もちろん、AIが間違えることもありますが、その時はルール（AGENTS.md）を更新すればいいだけです。「一度言えば二度と間違えない同僚」なんて、最高だと思いませんか？
最後に
最新の AI エージェント機能は、単なるコード生成を超えて「開発プロセスの自律化」という新しいフェーズに入った気がします。
設定が少し面倒に感じるかもしれませんが、一度 AGENTS.md を作成してしまえば、その後の開発体験（DevX）は劇的に向上します。
特に、私のブログを読んでくださっているような「技術を道具として使いこなしたい」エンジニアの皆さんにとって、これ以上の武器はないはずです。
皆さんのプロジェクトでも、まずは小さな型定義のルールから AGENTS.md に書いてみて、Subagents の「自律性」を体験してみてはいかがでしょうか。
以上です。
コメントを残す