この記事のゴール
Claude Code向けに作った Tsumiki（AITDD）ルールを、Cursor上のGPT-5でも自動で守らせる。
.claude/commands/*.mdを **Project Rules（.cursor/rules/*.mdc）**に移植し、ディレクトリ/ファイルに応じて自動適用させる。
前提
リポジトリには
./.claude/commands/*.mdで多数のルール文書が存在Cursor を使用（GPT-5を選択可能）
りゅうじさんの標準スタック：Node.js／モノレポ（想定）
なぜ「Project Rules」に移すのか
常時・自動で効かせられる（「読む」だけでなく守らせる状態に）
ディレクトリごとに globs で対象範囲を制御（APIだけ、UIだけ、など）
ルールの粒度を保てば、GPT-5の遵守率が高い（1枚物はNG）
導入手順（クイックスタート）
1) ディレクトリを用意
mkdir -p .cursor/rules
2) 変換指針
拡張子を
.md→.mdcに変更（MDC: Cursorのルール形式）各ファイルの先頭に Frontmatter を付与（description, globs, alwaysApply など）
1ファイル＝1目的（例：
spec-rules.mdc/tdd-rules.mdc/api-style.mdc）
3) 自動移行スクリプト（Node.js）
.claude/commands/*.md を読み、先頭H1を説明に吸収・MDCへ一括変換します。
（変換後、globs はプロジェクト構成に合わせて個別調整推奨）
// migrate-claude-to-cursor-rules.mjs
import { promises as fs } from 'fs';
import path from 'path';
const SRC = '.claude/commands';
const DEST = '.cursor/rules';
async function main() {
await fs.mkdir(DEST, { recursive: true });
const files = (await fs.readdir(SRC)).filter(f => f.endsWith('.md'));
for (const f of files) {
const srcPath = path.join(SRC, f);
const raw = await fs.readFile(srcPath, 'utf8');
const firstHeading = (raw.match(/^#\s+(.+)$/m) || [,'Tsumiki Rule'])[1].trim();
const body = raw.replace(/^#\s+.+\n/, ''); // 先頭H1を本文から除去
const frontmatter = `---\ndescription: ${firstHeading}\nglobs:\n - "**"\nalwaysApply: false\n---\n`;
const out = frontmatter + body + '\n';
const base = path.basename(f, '.md');
const destPath = path.join(DEST, `${base}.mdc`);
await fs.writeFile(destPath, out, 'utf8');
console.log(`migrated: ${srcPath} -> ${destPath}`);
}
console.log('Done. Adjust each rule’s globs and scopes in Cursor > Rules.');
}
main().catch(e => { console.error(e); process.exit(1); });
ヒント：まずは全件
**（全体適用）で移行 → 動作確認 → 徐々にglobsを絞るのが安全。
4) 代表ルールの雛形（MDC）
以下は API（apps/api/）に触れた時だけ**自動適用するTDDルール例。
---
description: TsumikiのTDDルール（API層）
globs:
- "apps/api/**"
alwaysApply: false
---
# 目的
- 仕様は先に Tsumiki コマンドで固定する（spec first）
- 実装は「failing test → fix → refactor」の順に徹底
- I/Oは zod でスキーマ化し、snapshotを残す
# 実行順
1. 仕様化：`tsumiki spec:api:create ...` でユースケースを明文化
2. テスト生成：`tsumiki test:api:init ...` で失敗テスト作成
3. 実装：最小実装でテストをgreen化
4. リファクタ：重複削減・命名整理・副作用排除
5. ドキュ生成：`tsumiki docs:api:update` で仕様と入出力を同期
# 守るべき規約（抜粋）
- バリデーションは `zod`。schemaは `schema/` 配下で共通化
- コントローラからDB直アクセス禁止。必ず usecase 経由
- 例外メッセージはユーザー起点の文言。技術語はdetailsへ
5) globs 設計のコツ（モノレポ想定）
apps/web/**：フロント専用ルール（UI文言ガイド、アクセシビリティ、状態管理規約）apps/api/**：APIルール（TDD、入出力、エラーハンドリング、ロギング）packages/*/**：共有ライブラリ（公開APIの安易な破壊変更を禁止、semver運用）**/*.test.ts：テスト記述規約（命名、Arrange-Act-Assert、snapshot方針）
6) alwaysApply の使い分け
true：常時添付（小さく普遍的な「チーム行動規範」向き）false：自動添付（globs命中時） or 手動添付（@rule名）
→ Tsumikiの詳細ルールは基本こちらでOK
運用フロー（実務での回し方）
-
初期移行
スクリプトで全件MDC化 → プロジェクトを再読み込み
Cursorサイドバーの Rules パネルで「どのルールがAttachされているか」を確認
-
計画的に分割
1ファイルが大きい場合は分割（目的ごとに300〜500行目安）
「仕様/TDD/命名/レビュー/ドキュ生成」を別ファイルに
-
適用範囲を絞る
誤爆が多いルールは
globsを絞る or 手動添付運用へ切替
-
レビュー基準の同期
PRテンプレートに「適用ルール名」を明記
例：
This change complies with: spec-rules, tdd-rules, api-style
-
ドキュと実装の二重化を避ける
「出力テンプレ・サンプル・CLIの実行例」をルール内に内包
参照ファイルは
@docs/xxx.mdのように置き、更新を一箇所に寄せる
チェックリスト（導入完了判定）
.cursor/rules/*.mdcが存在し、対象ファイルを開くと自動添付される主要領域（web/api/packages）ごとに専用ルールが分割されている
ルールには手順・根拠・禁止事項・OK/NG例が含まれる
PRテンプレートに準拠確認項目がある
ルール改定時に**影響範囲（globs）**が把握できる
つまずきポイントと対策
ルールが長すぎる → 分割。要点は冒頭に「目的・守るべき3箇条」
衝突する記述 → スコープ別に分ける（UIとAPIで別ファイル）
モデルが守らない → 指示を箇条書き＋具体例にし、「禁止表現」も明記
適用漏れ/誤爆 → RulesパネルでAttach状況を確認。
globsを調整Docsとの重複 → 「規範＝Rules」「参考情報＝Docs」に役割を分離
よくある質問（FAQ）
Q. .mdc 内で別ファイルを参照したい
A. 本文中に @docs/xxx.md のように参照パスを記しておくと、補助文書として読ませやすいです（命名は任意、実体はリポジトリ内に置くのが一番確実）。
Q. すべてのルールを常時適用したい
A. まずは避けてください。対象外コードにも効いて精度が落ちるため、globs で絞るか、手動添付にしましょう。
Q. ルール更新の運用は？
A. ルールもPRで変更。理由・影響範囲・例をセットでレビュー。変更履歴は CHANGELOG_RULES.md を用意すると可視化が楽です。
まとめ
Tsumikiの原則を「規範（Rules）」として定着させると、GPT-5 × Cursorでも再現性の高いアウトプットになる。
成功の鍵は 小粒・対象限定・具体例。最初は広く当てて、運用しながらglobsを締める。
「仕様→テスト→実装→ドキュ」の一連のフローをルールで縫い合わせると、チーム内外で結果がブレにくい。