AGENTS.md vs Cursor Project Rules（.mdc）比較 — どちらを使い、どう共存させるか（2026年版）

CursorはProject Rulesを.cursor/rules/*.mdc形式で導入した。ファイル単位でのアクティベーション、条件付き読み込み、より細かいスコーピングが特徴で、.cursorrulesの進化版だ。AGENTS.mdは別の方向から登場したマルチツール標準で、Codex・Copilot・Gemini CLI等への移植性を提供する。

どちらのファイルも同じリポジトリに共存でき、重なり合う問題を解決する。「どちらが優れているか」という話ではなく、「それぞれが得意なこと」「苦手なこと」「両方を競合なしで動かす構成」を実例で整理する。

フォーマットと構文の比較

最も目立つ違いはファイル形式だ。

AGENTS.md はフロントマターなし、アクティベーションメタデータなし、特殊構文なしの純粋なMarkdown。構造はすべて慣習ベースで、見出しでセクションを整理し、ツールがその見出しを解析して指示を適用する。

# AGENTS.md

## コマンド
- インストール: pnpm install
- テスト: pnpm test:run
- Lint: pnpm lint

## コードスタイル
- TypeScript strictモード、any禁止
- デフォルトエクスポートより名前付きエクスポート
- letよりconstを優先

## 触ってはいけないもの
- `/migrations/`を直接変更禁止
- 認証ミドルウェアは`middleware/auth.ts`のみ——インライン化禁止

Cursor Project Rules は .mdc ファイル（YAMLフロントマター付きMarkdown）を使う。フロントマターがAGENTS.mdにはないアクティベーション動作を制御する。

---
description: フロントエンドのTypeScriptとReact規約
globs: ["src/**/*.tsx", "src/**/*.ts"]
alwaysApply: false
---

# フロントエンド規約

TypeScript strictモードを常に使う。anyは禁止。
Reactコンポーネントはデフォルトでサーバーコンポーネント。
UIコンポーネントは`@/components/ui/`からshadcn/uiを使う。

重要なフロントマターフィールド:

これが重要な機能差: Cursor Project Rulesはファイルコンテキストに基づく条件付きロードをサポートする。AGENTS.mdは常時オン。

スコーピングとアクティベーション

AGENTS.mdのスコーピングはファイルシステム階層で動作する。

• ルートのAGENTS.mdはリポジトリ全体に適用
• src/AGENTS.mdはsrc/以下に適用
• src/api/AGENTS.mdはsrc/api/以下に適用
• ネストされたファイルは親ファイルを継承し、より具体的なファイルが競合時に優先

動的なアクティベーションはない——AGENTS.mdはファイルツリーのどこで作業しているかに基づいてロードされる。

Cursor Project Rulesのスコーピングは2つのメカニズムで動作する。

1. globsアクティベーション — ルールのglobパターンにマッチするファイルを開くと、Cursorが自動的にそのルールをロードする。src/api/routes/users.tsを開くとglobs: ["src/api/**"]のルールが自動ロードされる。

2. alwaysApply: true — 開いているファイルに関わらず、全セッションでロードされる。

3. 手動呼び出し — alwaysApply: falseでglobもマッチしない場合でも、プロンプトで@ルール名と参照すれば直接ロードできる。

つまりCursor Project Rulesは、AGENTS.mdよりも大幅にコンテキスト固有にできる。200ルールのプロジェクトでも、編集中のファイルに関係する15ルールだけをロードできる。

実動作の比較一覧

トークンコストの現実

ここで比較が具体的になる。30個のCursor Project Rulesがあり平均300トークンなら、ルール全体で9,000トークンある。globアクティベーションによりsrc/api/users.ts編集セッションでは4つのマッチしたルール = 1,200トークンがロードされる。src/components/Button.tsx編集では3つの異なるルール = 900トークンだ。

AGENTS.mdでの相当実装は以下になる。 a) 1つの大きいAGENTS.md（9,000トークン、全セッションでロード） b) ディレクトリで整理した複数のAGENTS.mdファイル（各セッションでルート + 関連サブディレクトリをロード）

専門化されたルールが多いプロジェクトでは、Cursorのglobベースアクティベーションはトークン効率が明確に高い。クロスツール使用ではAGENTS.mdの階層構造が唯一の選択肢になる。

Cursorの各モードが実際に何を読むか

ここが混乱しやすいポイントだ。Cursorは複数のモードで設定読み込みが異なる。

• ChatとComposerモード: .cursorrules（廃止予定）と.cursor/rules/*.mdcを読む。AGENTS.mdは読まない。
• Agentモード: AGENTS.md と .cursor/rules/*.mdcの両方を読む。ルートの.cursorrulesは読まない。

つまり、Cursor Agent modeを使っていて.cursorrulesしかないと、ルールはサイレントに無視される。.cursor/rules/だけあればAgent modeでは機能する。AGENTS.mdがあればAgent modeで機能する。両方持つこともできる。

Cursor主体チームへの実用的な推奨: .cursor/rules/*.mdcを主要システムにする（Cursor全モードで機能、Agent modeも含む）。チームメンバーが他ツールを使う可能性があるならAGENTS.mdをマルチツール基盤として維持する。

両方を動かすデュアルスタック構成

多くの実際のチームは両方のフォーマットを使うことになる。重複と競合を避けた設計例:

project-root/
├── AGENTS.md                          # 基盤レイヤー: クロスツールルール
└── .cursor/
    └── rules/
        ├── foundation.mdc             # AGENTS.mdをミラー（alwaysApply: true）
        ├── typescript.mdc             # TSルール、globs: ["**/*.ts", "**/*.tsx"]
        ├── api.mdc                    # APIルール、globs: ["src/api/**"]
        ├── testing.mdc                # テストルール、globs: ["**/*.test.*", "**/*.spec.*"]
        └── migrations.mdc             # DBルール、globs: ["migrations/**", "src/db/**"]

AGENTS.md は共通基盤を保持する——コマンド、アーキテクチャ概要、ハード制約、技術スタック。非Cursorツールが読むもの。

.cursor/rules/*.mdc はCursor固有の専門化を保持する——開いているファイルに基づいてアクティベートするコンテキスト依存ルール、AGENTS.mdを肥大化させる例や説明、Cursor固有の設定。

AGENTS.mdからfoundation.mdcを自動生成するスクリプトで同期を保つことができる。

#!/bin/bash
# scripts/sync-cursor-rules.sh

cat > .cursor/rules/foundation.mdc << EOF
---
description: コアプロジェクトルール（AGENTS.mdから自動生成）
alwaysApply: true
---

$(cat AGENTS.md)
EOF
echo ".cursor/rules/foundation.mdc をAGENTS.mdから更新しました"

pre-commitフックに追加して同期を維持する:

# .git/hooks/pre-commit
#!/bin/bash
if git diff --cached --name-only | grep -q "^AGENTS.md$"; then
  bash scripts/sync-cursor-rules.sh
  git add .cursor/rules/foundation.mdc
fi

フォーマット間の変換

AGENTS.mdセクション → Cursor MDCファイル:

# AGENTS.mdのセクション（変換前）
## APIルール
- requireAuthミドルウェアで全エンドポイントにJWT認証が必要
- RFC 7807エラーフォーマットを返す
- シークレットをハードコードしない

---
description: APIレイヤールール — 認証、エラーハンドリング、セキュリティ
globs: ["src/api/**/*.ts", "src/routes/**/*.ts"]
alwaysApply: false
---

# APIレイヤールール

全エンドポイントに`middleware/auth.ts`の`requireAuth`ミドルウェアが必要。

エラーはRFC 7807 problem+json形式で返す:
\`\`\`ts
{ type: string; title: string; status: number; detail: string; }
\`\`\`

JWTシークレットやAPIキーをハードコードしない——環境変数を使う。

MDC版は冗長だが（フロントマターと詳細な説明がある）、APIファイルを編集する時だけロードされる。AGENTS.md版は簡潔だが常時オン。

Cursor MDCファイル → AGENTS.mdセクション:

フロントマターとCursor固有の構文を除去。ルール内容を最も本質的な形に蒸留する。該当するAGENTS.mdセクション見出しの下に追加する。

判断フロー

要約: Cursor MDCファイルはCursor内での深さとコンテキスト感度で勝る。AGENTS.mdは移植性とシンプルさで勝る。デュアルスタック構成はわずかなメンテナンスコストで両方のメリットを得られる。

関連記事

• .cursorrules vs .cursor/rules (MDC): 2026年にどちらを使うべきか
• .cursorrules から AGENTS.md への移行ガイド
• AGENTS.md vs CLAUDE.md 徹底比較