Windsurf Rules vs Cursor Rules vs AGENTS.md：設定ファイル徹底比較（2026年版）

主要なAIコーディングツールはそれぞれ独自のルールファイル形式を持つ。WindsurfはCascade向けにglobal_rules.mdとワークスペースルールを使う。Cursorには.cursorrules（旧形式）と新しいMDC形式がある。そしてAGENTS.mdは、WindsurfやCursorを含む多くのツールが読み込むクロスツール標準だ。

どのファイルが何をするのか、ツール間を移行するときにどう対応するか——この記事ではその疑問に答える。

3つ全てが解決しようとしている問題

AIコーディングアシスタントはデフォルトでステートレスだ。毎チャットセッションはゼロからスタートし、プロジェクトのコーディング規約、テストの進め方、エラー処理のパターン、チームの命名規則——何も覚えていない。

ルールファイルはこの問題を解決する。セッション開始時にAIのコンテキストに永続的な指示を注入し、毎回同じ土台から作業できるようにする。コードベースの憲法のようなものだ。

3つの形式はどれも同じ問題を解いているが、スコープ・ポータビリティ・起動制御の精度が異なる。

クイック比較表

Windsurf Rules：global_rules.mdとワークスペースルール

ファイルの置き場所

Windsurfのルールは3つのスコープに分かれている。

グローバルルールは~/.codeium/windsurf/memories/global_rules.mdに置く。開くプロジェクトを問わず全てに適用される。コメントスタイルの好みや言語設定など、個人的な設定を書く場所だ。上限は6,000字。

ワークスペースルールはプロジェクト内の.windsurf/rules/*.mdに置く。YAMLフロントマター付きのMarkdownファイルで、バージョン管理してチームと共有できる。1ファイルあたり6,000字、全ルールの合計で12,000字という上限がある。

エンタープライズ/システムルールはOSレベルのディレクトリ（macOSなら/Library/Application Support/Windsurf/rules/）にデプロイし、組織全体に強制適用する。

4種類の起動モード

Windsurfのルールシステムの核心はここにある。各ワークスペースルールファイルのフロントマターで適用タイミングを宣言する。

---
trigger: always_on
description: "プロジェクトの基本コーディング規約"
---

- TypeScript strict modeを使用
- 関数コンポーネントにnamed exportを使用
- テストはソースファイルの隣に置く

triggerフィールドに指定できる4つの値：

• always_on — 全メッセージのシステムプロンプトにルール全文を注入する。最重要・普遍的な規約に使う。
• model_decision — 最初はdescriptionだけがコンテキストに入る。Cascadeが関連性を判断して必要なときだけフル内容を読み込む。DBマイグレーションガイドラインのような、場面を選ぶルールに向いている。
• glob — 指定したファイルパターンにマッチするファイルを編集中のときだけ起動する。
• manual — Cascadeのインプットに@ルール名とメンションしたときだけ読み込まれる。参照用ドキュメントをオンデマンドで提供したい場合に使う。

旧形式の.windsurfrules

Wave 8以前のWindsurfはプロジェクトルートに単一の.windsurfrulesファイルを使っていた。今もサポートされているが、起動モードがない——全ルールが常時アクティブになる。新規プロジェクトでは.windsurf/rules/ディレクトリ方式を使うべきだ。既存の.windsurfrulesがあるなら、コンテンツを分割して適切なtriggerを設定する移行は難しくない。

Windsurfルールの限界

Windsurfのルールには、CLAUDE.mdの@importに相当する仕組みがない——外部ファイルを参照することができない。また12,000字の合計上限は、複雑な規約を持つ大規模プロジェクトには厳しい。model_decisionモードを活用して上限に引っかからないよう工夫が必要だ。

Cursor Rules：.cursorrulesからMDCへ

旧形式の.cursorrules

元々Cursorはプロジェクトルートの単一.cursorrulesファイルを使っていた。プレーンMarkdownでフロントマターなし、常時アクティブ。今もほぼ動作するが、Cursorは公式に非推奨としている。さらに重要なのは、.cursorrulesはAgentモードで無視されるという点だ。本格的な使い方はAgentモードに移行しているため、この旧形式は実質的に使い物にならなくなりつつある。

MDC形式（.cursor/rules/）

現在の標準はMDC（Markdown Components）形式——.cursor/rules/内の.mdcファイルだ。各ルールはYAMLフロントマターで起動タイミングを制御する。

---
description: APIルートの規約
globs: ["src/api/**/*.ts", "src/handlers/**/*.ts"]
alwaysApply: false
---

全APIハンドラーの必須要件：
- Zodスキーマで入力バリデーション
- ApiErrorクラスで標準化したエラーレスポンス
- 5xxエラーはリクエストコンテキストと一緒にログ

4種類の起動タイプ：

• Always Apply（alwaysApply: true）— 全チャットセッションにルールを注入。WindsurfのalwaysOnに相当。
• Apply Intelligently — Cursorのエージェントがdescriptionフィールドをもとに関連性を評価して適用するか判断。Windsurfのmodel_decisionに相当。
• Apply to Specific Files（globsパターン）— パターンにマッチするファイルがコンテキストに入ったときに起動。Windsurfのglobモードに相当。
• Apply Manually — ルールファイル名を@メンションしたときだけ読み込まれる。

Cursorは1ルールあたり500行以内を推奨し、複雑なガイダンスは複数の小さなファイルに分割することを勧めている。ドキュメントに明示的な文字数制限はないが、ルールが長すぎるとエージェントのパフォーマンスが下がる。

ユーザーレベルのルール

Cursorは~/.cursor/rules/にユーザーレベルのルールも持てる。全プロジェクトに適用される個人用ルール——Windsurfのglobal_rules.mdと同じ役割だ。

CursorにおけるAGENTS.md

CursorはネイティブルールシステムとともにAGENTS.mdもサポートするようになった。Cursorのドキュメントではこれを「シンプルな代替手段」と位置づけている。AGENTS.mdと.cursor/rules/ファイルが両方あれば、Cursorは両方を読む。

AGENTS.md：クロスツール標準

AGENTS.mdは他の2つと根本的に違う点がある——ネイティブオーナーがいない。Linux Foundation傘下のAgentic AI Foundationが管理するオープンスタンダードで、あらゆるAIコーディングツールで動くように設計されている。

検索アルゴリズム

複数のツールで共通の検索ロジックが使われる：

1. プロジェクトルート（またはGitルート）から編集対象ファイルに向かって深い階層に歩いていく。
2. 各ディレクトリレベルでAGENTS.override.md→AGENTS.mdの順に探す。
3. 見つかった全ファイルをルートから下に向かって結合し、深い階層のファイルが後に来る（つまり競合時に優先される）。

Codex限定でグローバルスコープ（~/.codex/AGENTS.md）も存在する。

ディレクトリスコープ

AGENTS.mdがシンプルなグローバル設定に対して持つ強みは、ディレクトリレベルのスコープ制御だ。モノレポでの例：

my-repo/
  AGENTS.md              # プロジェクト全体のルール
  services/
    payments/
      AGENTS.md          # 決済サービス固有のルール（グローバルに追記）
    auth/
      AGENTS.override.md # 認証サービスのルール（このスコープでグローバルを上書き）

services/payments/内のファイルを編集するエージェントは、ルートとpaymentsの両方を読む。services/auth/内のファイルを編集するエージェントはauthのoverrideだけを読む。CLAUDE.mdのパススコープルールよりは粗いが、よりポータブルだ。

サイズ制限

Codexは全ロードされたAGENTS.mdファイルの合計32KiB制限を強制する。~/.codex/config.tomlで変更できる：

project_doc_max_bytes = 65536

AGENTS.mdをサポートする他のツール（Windsurf、Cursor、GitHub Copilot、Gemini CLIなど）はCodexの設定には従わず、それぞれ独自の内部制限を持つ。

起動モードがない理由

AGENTS.mdにはフロントマターも起動制御もglobパターンもない。スコープ内のファイルがある限り、全ての指示が常時適用される。これはポータビリティのための意図的な設計だ——カスタムメタデータを解釈しなくても、どんなツールでもパースできる最小公倍数の形式。

細かい起動制御が必要なら、AGENTS.mdは適していない。普遍的なプロジェクトルールに使い、ニュアンスのある制御はネイティブツールの設定に任せる——それが正しい使い方だ。

機能比較マトリックス

マイグレーションガイド

.cursorrulesからCursor MDCへ

今最も多い移行パターン。.cursorrulesは非推奨でAgentモードで無視される。

1. プロジェクトルートに.cursor/rules/ディレクトリを作成する。
2. .cursorrulesのコンテンツを関心ごとに分割する（コードスタイル、テスト、アーキテクチャなど）。
3. 各ファイルにYAMLフロントマターを追加する。コアルールはalwaysApply: trueから始め、徐々に調整する。
4. .cursorrulesは削除するか、他のツール用に残す（Cursorのエージェントモードはどちらにせよ無視する）。

# 移行前（.cursorrules — 一枚岩のファイル）
You are an expert TypeScript developer.
Use strict mode. Write functional components.
Test everything with Vitest. No any types.

# 移行後（.cursor/rules/typescript.mdc）
---
description: TypeScriptとReactの規約
alwaysApply: true
---
- strict mode必須。`any`型禁止
- 関数コンポーネント、named export使用
- import順序：React → 外部パッケージ → ローカル

# 移行後（.cursor/rules/testing.mdc）
---
description: Vitestによるテスト規約
globs: ["**/*.test.ts", "**/*.spec.ts"]
alwaysApply: false
---
- テストはVitest使用
- ソースファイルの隣に置く
- 複数ケースのロジックにはテーブル駆動テスト

.windsurfrulesからWindsurfルールディレクトリへ

WindsurfのOld形式.windsurfrulesは動作するが、起動制御ができない。

1. プロジェクトルートに.windsurf/rules/を作成する。
2. .windsurfrulesのコンテンツを関心ごとに分割する。
3. 適切なtriggerモードを持つフロントマターを追加する。常時必要なもの：trigger: always_on。文脈依存のルール：trigger: model_decisionかtrigger: globを検討する。
4. チームメンバーがまだWindsurfを更新していない場合、後方互換のために.windsurfrulesは残しておく。

Windsurfルールからカーソルメッセージへ

両方のフォーマットはほぼ同じ——YAMLフロントマターと類似した起動コンセプト。主な変換対応：

.mdファイルをコピーして.mdcにリネームし、フロントマターを変換すれば完了。ルール本文（指示の内容）は変更不要。

既存ルールを崩さずにAGENTS.mdを追加する

WindsurfかCursorのルールがあって、クロスツールポータビリティのためにAGENTS.mdを追加したい場合：

1. 既存の設定から普遍的なルールを抽出する——コードスタイル、アーキテクチャパターン、テスト要件、プロジェクト構造。どんなAIツールでも意味をなす内容だ。
2. それをプロジェクトルートのAGENTS.mdに置く。
3. WindsurfやCursorの設定で普遍的なルールの記述を最小化するか、そのまま残す（@import AGENTS.mdというような構文はこれらのツールにはない——ある程度の重複は許容する）。
4. グロブ起動、個人的な設定、Windsurf/Cursor固有のフォーマットなどツール固有のルールはネイティブ形式に残す。

結果：CopilotやGemini CLIを使うコントリビューターはAGENTS.mdのベースラインを得られ、WindsurfとCursorのユーザーはそれに加えて細かい起動制御の恩恵を受けられる。

どれを選ぶべきか

Windsurfルールを選ぶのは、WindsurfがメインツールでリッチなネイティブExperienceが欲しい場合。4種類の起動モード——特にmodel_decisionとglob——が精密なコンテキスト制御を可能にする。グローバル/ワークスペースの分離もクリーンだ。12,000字の合計上限は複雑なプロジェクトには厳しいが、ルールを整理すれば対処できる。

Cursor MDCを選ぶのは、CursorがメインでAgentモードを使う場合。.cursor/rules/システムはWindsurfに似ているが、厳密な文字数制限がない。.cursorrulesからはすぐに移行すべきだ——非推奨でAgentモードでは無視される。

AGENTS.mdを選ぶのは、ポータビリティを重視する場合。Windsurf、Cursor、GitHub Copilot、Gemini CLI、OpenAI Codex、Aider、Zed、Warpなど10以上のツールで動く。チームがさまざまなツールを使う場合、またはオープンソースプロジェクトを管理している場合、AGENTS.mdはエディタの選択肢を共有することなく全員にベースラインを提供する。

両方使うのは、広いリーチと精密な制御を両立したい場合だ。現実的なパターン：

project/
  AGENTS.md              # 普遍的なルール——どのツールでも動く
  .windsurf/
    rules/
      core.md            # Windsurf固有：起動チューニング
      testing.md         # テストファイルにglobスコープ
  .cursor/
    rules/
      core.mdc           # Cursor固有：同じ内容、MDC形式

メンテナンスコストは増えるが、コントリビューターがさまざまなツールを使い、それぞれに良い体験を提供したいプロジェクトでは正しい選択だ。

まだ始めたばかりなら：まずAGENTS.mdを書こう。普遍的なルールをしっかり作る。ネイティブ設定は、その機能が明確な価値を生む場合にだけ重ねていく——複雑なモノレポのglobスコープ、大きなルールセットのmodel_decision、個人の好みを反映するグローバルルール。

FAQ

Windsurf Rules・Cursor Rules・AGENTS.md、どれを最初に書くべき？

AGENTS.md から始める のが2026年の正解。AGENTS.md は Windsurf / Cursor / Claude Code / Codex CLI / Gemini CLI など主要ツールが自動検出する標準形式で、1ファイル書けば全ツールで最低限の動作が揃う。あとから「Cursor 固有の MDC スコープが必要」「Windsurf の global_rules.md が欲しい」と判明したら、その時点でツール固有ファイルを追加する。

.cursorrules（旧形式）と .cursor/rules/ MDC（新形式）はどっちを使う？

新規プロジェクトは MDC（.cursor/rules/）一択。Cursor 公式ドキュメントが新規ユーザーに案内するのも MDC。.cursorrules も後方互換で動くが、alwaysApply / globs / description などのメタデータ制御は MDC 専用。レガシー .cursorrules を持つ既存プロジェクトは、Cursor が両方読むのでまずは並行運用、徐々に MDC に移行が無理ない。

Windsurf Rules には Cursor の globs 相当機能ある？

ない。Windsurf Rules は globs によるファイルスコープ指定をサポートしていない（2026年5月時点）。同等の機能が欲しい場合は、ワークスペースルール内で「src/api/ 配下の TypeScript ファイルでは…」のように自然言語で記述する必要がある。glob による厳密なスコープが要件なら Cursor MDC + .cursor/rules/。

AGENTS.md を Cursor で動かすには設定変更が必要？

不要。Cursor は標準で AGENTS.md を自動検出して読み込む（プロジェクトルート + ネストしたサブディレクトリも）。Cursor 内部では Rules メニューに AGENTS.md が「Project Rules」として表示される。設定で無効化したい場合は Cursor Settings → Rules で agents.md を toggle off。

1つのプロジェクトで3ファイル全部置くと、どう優先順位がつく？

ツール側の優先順位ロジックに従う：(1) Windsurf は .windsurf/rules > .windsurfrules > AGENTS.md の順、(2) Cursor は .cursor/rules/ > .cursorrules > AGENTS.md の順、(3) Claude Code は CLAUDE.md > AGENTS.md（CLAUDE.md から @AGENTS.md import 推奨）。3ファイル全部置く運用は管理コスト高いので、AGENTS.md を真実の源にしてツール固有ファイルは差分だけ書くのが現実解。

Windsurf の global_rules.md は他ツールで読まれる？

読まれない。global_rules.md は Windsurf Cascade 固有のグローバル設定で、Cursor / Claude Code / Codex CLI は無視する。マシン全体に効かせたい一般ルール（言語設定、出力フォーマット）は、各ツールの user-level 設定で個別に書く必要がある（Cursor の User Rules、Claude Code の ~/.claude/CLAUDE.md など）。

モノレポで frontend/ backend/ infra/ を別ルールにしたい

3ツールで対応法が異なる：Windsurf は .windsurf/rules/<dir>/rules.md でネスト配置、Cursor は .cursor/rules/<rule>.mdc の globs: フィールドで globs: frontend/**/*.tsx、AGENTS.md は frontend/AGENTS.md / backend/AGENTS.md のネスト配置（ディレクトリツリー walk）。AGENTS.md のネストが最もシンプル で、ツール間で挙動が揃いやすい。

.windsurfrules（旧形式）はまだ使える？

使えるが非推奨。Windsurf 公式は .windsurf/rules/ ディレクトリ形式を推奨している。旧形式は単一ファイル制約 + 起動モード設定不可で、新形式の model_decision / always_on / glob モード分けが活かせない。既存プロジェクトは並行運用→徐々に移行。新規は .windsurf/rules/ のみ。

関連記事

• AGENTS.md vs CLAUDE.md: 違いと使い分け — AGENTS.mdとClaude Codeネイティブ形式の比較
• 2026年版 AIコーディングルール ベスト20 — 実際のオープンソースプロジェクトからキュレートした事例集
• AGENTS.mdルールギャラリー — 参考にできる実際のAGENTS.mdファイル
• Cursorルールギャラリー — 実際の.cursorrulesとMDCファイル