Rulesync：Claude Code、Codex、Cursorのルールをひとつのソースで管理する

要点

Rulesyncは、リポジトリのルールを .rulesync/ というひとつのディレクトリにまとめ、そこから各AIエージェントが読むネイティブファイルを生成するCLIです。同じプロジェクトで複数のエージェントを使い、CLAUDE.md、AGENTS.md、.cursor/rules がそれぞれ違うことを言っている状態の維持に疲れた人のためのツールです。公式ドキュメントが掲げる約束は「Author rules once, generate everywhere」で、生成されたファイルはrulesyncをインストールしていなくても動作し続けます。転換点は考え方にあります。導入すると、CLAUDE.md は書き込む場所ではなくなり、コンパイル済みファイルと同じくビルドの出力になります。これでずれは解消しますが、新しいリスクが生まれます。手書きのルールの上から generate を実行してしまうリスクです。安全な道は、何かを生成する前に、既存のものをインポートすることです。

1. 問題はエージェントが多いことではなく、ソースが多いこと

クライアントにシステムやストアを納品する人が、エージェントを1つしか使わないことはまれです。ターミナルではClaude Code、別のタブではCodex CLI、差分のレビューにはCursor、サーバーではOpenCode。それぞれがデフォルトで別のファイルを読みます。

Claude Codeは、./CLAUDE.md または ./.claude/CLAUDE.md をプロジェクトの指示として読み込みます。Cursorは .cursor/rules の .mdc ファイルを読み、このフォルダに置かれた .md はルールシステムに無視されます。description、globs、alwaysApply を宣言するfrontmatterがないためです。OpenCodeはルートの AGENTS.md を読み、opencode.json の instructions フィールドに列挙した追加ファイルも受け付けます。Codexは設定を ~/.codex/config.toml に保存し、.codex/config.toml によるプロジェクトごとの上書きを受け付けますが、これは信頼済みとしてマークされたプロジェクトでしか読み込まれません。

4つの場所、4つの形式。実際には、スタックの標準は CLAUDE.md に、ブランチの規約は .cursor/rules に、デプロイの手順は AGENTS.md にあり、誰も触ってはいけないフォルダはどこにも書かれていない、という状態になります。エージェントが半分のコンテキストで作業すれば、そのツケを払うのはクライアントのコードです。

AGENTS.md で混乱の一部は減りました。6万以上のオープンソースプロジェクトで使われているオープンな形式で、優先順位も単純です。編集中のファイルに最も近いものが優先されます。しかし .cursor/rules や、MCP、フック、権限の設定はカバーしていません。

2. rulesyncがすること（と、rulesyncではないもの）

rulesyncは方向を逆にします。あなたは .rulesync/ に書き、コマンドを実行すると、rulesyncが各ツールのネイティブファイルを書き出します。公式のREADMEは、統一されたルールファイルから複数のAIツールの設定を生成するNode.js製のCLIと説明しており、rules、commands、MCP、subagents、skillsに対応しています。ライセンスはMITです。

rulesyncではないもの3つ：

• MCPではありません。MCPはエージェントを外部ツールにつなぐプロトコルで、すでに専用の記事があります：Claude CodeとCursorのMCP。rulesyncは、各ツールのMCP設定ファイルを単一のソースから書き出すだけです。
• ランタイムではありません。実行してファイルを書き、終了します。
• 動作の保証ではありません。同期するのはコンテキストのテキストです。これはセクション8で扱います。

利点が見えるのは、コミットの規約を変える日です。4つのファイルを編集して1つ忘れる代わりに、.rulesync/rules/ の1つを編集してgenerateを実行します。

3. インストールし、generateの前にimportを実行する

公式ドキュメントには3つの方法が載っています。npmのグローバルインストール、Homebrewのtap、単一バイナリです。最も手っ取り早いのはnpmです。

npm install -g rulesync
rulesync --version

Homebrewのtapはリポジトリ自体の中にあり、homebrew- のプレフィックスがないため、brew tap <nome> <url> という2引数の形式が必要です。先にtapせずに使う省略形は動きません。npmでは、パッケージに来歴証明が付いており、npm audit signatures で検証できます。

ここからがリポジトリを守る部分です。プロジェクトにすでに手書きの CLAUDE.md や .cursorrules があるなら、最初に rulesync generate を実行しないでください。generateは .rulesync/ からネイティブファイルを書き出すので、.rulesync/ が空のままだと、手書きの内容が上書きされるおそれがあります。先にインポートします。

rulesync init
rulesync import --targets claudecode
rulesync import --targets cursor

init はサンプルファイル入りの .rulesync/ と rulesync.jsonc を作成し、ドキュメントによれば既存のファイルは決して上書きしません。生成される rulesync.jsonc には、最初から targets として codexcli、claudecode、opencode が入っています。import はgenerateの逆を行います。既存の CLAUDE.md、.cursorrules、.github/copilot-instructions.md を読み、その内容を .rulesync/ に書き込みます。

インポートのあとは、何よりも先に、何が入ったかを確認します。

git status
git diff --stat

インポートされた内容が期待より少なければ、生成する前に .rulesync/rules/ で手作業で補います。

4. 最初のルール：frontmatter付きのMarkdown

rulesyncのルールは、.rulesync/rules/ に置くYAML frontmatter付きのMarkdownファイルです。最初に重要なキーは4つ、root、targets、description、globs です。ルートのルール（root: true）は各ツールのメインファイルになり、それ以外は各ツールが想定する場所にモジュール化されたファイルとして出力されます。

---
root: true
targets: ["*"]
description: "Convenções do repositório"
globs: ["**/*"]
---

frontmatterの下には、普通のMarkdownで本文を書きます。新しい開発者に初日に繰り返し伝えることを書いてください。

• 使ってよいスタックと、固定されているもの（フレームワークのバージョン、パッケージマネージャー、npm ではなく pnpm なのか）。
• コミットとブランチの規約。形容詞ではなく例として書く。
• 触ってはいけないフォルダ：ビルド用、vendor用、別のプロセスが生成するファイル用。
• デプロイの手順と、その前に実行する検証コマンド。

書き方のアドバイスは各ドキュメントで一貫しています。曖昧な指示より具体的な指示のほうがうまく働きます。Claude Codeは、長いファイルはコンテキストを消費して遵守率を下げるため、CLAUDE.md 1つあたり200行未満を推奨しています。Cursorは、ルールを500行未満に保ち、大きなルールは組み合わせ可能な複数のルールに分けるよう推奨しています。

コードの一部にだけ適用するルールには globs を使います。globs: ["src/api/**/*.ts"] を持つルールは、各ターゲットが持つ仕組みに変換されます。Claude Codeでは paths、Cursorの .mdc では globs、その他のツールではそれぞれ独自のfrontmatterです。

静かに壊れるCursorの細部

Cursorでは、alwaysApply: true と globs を同時に使うと意味が衝突します。公式ドキュメントによれば、このフラグが有効なときglobsは無視されますが、バージョンによっては、常に適用する代わりにglobでルールを分類してしまうものがあります。rulesyncは変換時にこれを処理しますが、挙動は知っておいてください。「ルールはあるのにエージェントが無視する」のよくある原因です。

5. 複数のターゲットに一度に生成する

コマンドは generate で、どこに書き出すかを決めるのは --targets です。値はリテラルで、名前を間違えると実行が失敗します。以下は確認日に公式リファレンスで照合した値です。

出典：Rulesync、Supported ToolsとFile Formatsのページ、2026年9月22日確認。全リストは40ツールを超え、頻繁に変わります。スクリプトに固定する前に、リファレンスで値を確認してください。

rulesync generate --targets claudecode,codexcli,cursor --features rules
rulesync generate --targets "*" --features "*"

1行目は3つのターゲットに対してルールだけを生成します。2行目は設定済みのすべてのターゲットにすべてを生成します。1行目から始めてください。--features は rules、commands、subagents、skills、mcp、hooks、permissions、checks を受け付けます。手で調整した .codex/config.toml を permissions が書き換えていたことを差分で知る羽目にならないよう、1つずつ有効にしましょう。

ファイルを書き出す前に、リハーサルができます。

rulesync generate --dry-run --targets claudecode --features rules
rulesync generate --check --targets "*" --features "*"

--dry-run は何も触らずに、何が変わるかを表示します。--check も同じことをし、ファイルが最新でなければ終了コード1で終わります。これがCIで使う方法です。

ターゲットの順番は見た目以上に重要

複数のツールが同じ AGENTS.md を読みます。Codex CLI、OpenCode、Antigravity CLI、Grok CLI、Warpなどです。複数ターゲットでgenerateすると、複数のターゲットが同じパスにそれぞれ独自の意味で書き込みます。rulesyncは、あるターゲットが書いたばかりのファイルを別のターゲットが消さないよう、すべてのターゲットが書き終えてから孤立ファイルの掃除を行います。それでも、生成したら AGENTS.md を開いて読んでください。思い込みは禁物です。

6. git diffで確認し、生成物をリポジトリに入れるか決める

最初のgenerateのあと、意味のある確認は差分です。

git diff --stat
git diff CLAUDE.md AGENTS.md
git diff .cursor/rules/

探すのは3つです。消えた内容（インポートされなかった手書きの CLAUDE.md の段落）、重複した内容（AGENTS.md とルートのルールの両方から来た同じ指示）、そして予期しないファイル（--features "*" で permissions が有効になったために現れた .codex/config.toml など）です。

次はバージョン管理の判断で、選択肢は2つです。

生成物をバージョン管理する のはチーム向けの道です。クローンした人は何もインストールせずに動くルールを受け取れ、ドキュメントの約束とも一致します。代償は、プルリクエストごとに差分がうるさくなることと、生成物が気づかぬうちに古くならないよう、CIで rulesync generate --check を実行する義務です。

バージョン管理しない なら、リポジトリはきれいに保てます。gitに入るのは .rulesync/ だけで、generate はセットアップの手順になります。専用のコマンドがあります。

rulesync gitignore --targets claudecode,cursor

代償は、クローンしてセットアップを実行しなかった人がルールなしで作業することです。ドキュメントに記載された注意点として、opencode.json、.claude/settings.json、.codex/config.toml、.vscode/settings.json といった共有ファイルは、あなた自身の設定も書き込むため、意図的に .gitignore に入れられません。

クライアントのプロジェクトなら、バージョン管理するのが正しい選択になりがちです。リポジトリは次に引き継ぐ人の手元で動かなければならず、次に引き継ぐ人はセットアップのドキュメントを読まないからです。

7. ツールを慌てずにアップデートする

ページを確認した2026年9月22日時点の最新バージョンは、2026年9月21日公開の17.0.0です。Codex CLIに固有の互換性のない変更が含まれています。ask または deny とマークされた edit と write のルールが、deny ではなく read を生成するようになりました。Codexにはパスごとの書き込み承認の状態がないため、allow 以外の2つのアクションは、警告付きで読み取りのみを許可し書き込みを許可しない形になります。リリースノートは、以前の出力に依存していた場合は再生成された .codex/config.toml を見直すよう求めています。

これがこのツールの動き方を要約しています。ほぼ毎日リリースされるほど動きが速く、各エージェントが自分の側で変えたことに追随します。リスクには2つの習慣で対処できます。常に最新版をインストールするのではなくプロジェクトでバージョンを固定すること、そしてアップデートのたびに rulesync generate --dry-run を実行することです。

8. 正直な限界：ルールはコンテキストをそろえるが、モデルに強制はしない

ここはほとんどのチュートリアルが触れない部分で、各ツールの公式ドキュメントははっきり書いている部分です。

Claude Codeは率直です。メモリの指示は強制的な設定ではなくコンテキストとして扱われ、CLAUDE.md の内容はシステムプロンプトのあとにユーザーメッセージとして渡されます。とくに指示が曖昧だったり別の指示と矛盾したりする場合、厳密に守られる保証はありません。常に有効でなければならないものについて、同じページが推奨するのは PreToolUse フックで、これはモデルの判断に関係なく実行されます。Cursorもチームのルールについて同様の注意をしています。AIによるガイダンスを唯一のセキュリティ管理にすべきではない、と。

運用上の結論として、作業を2つの層に分けます。

• コンテキストの層：命名規則、スタイル、アーキテクチャ、どこに何があるか。これはルールに書き、rulesyncが重複を解消します。
• 強制の層：決して起きてはならないこと。これはフック、権限（Claude Codeの permissions.deny、Codexの sandbox_mode と承認ポリシー）、テスト、CIのルールに置きます。

指示が「テストを実行せずにデプロイしない」なら、それはファイルのルールではなく、フックかパイプラインのステップです。「新しいエンドポイントは src/api/handlers/ に置く」なら、それはまさにルールで、ひとつの場所にまとめる価値があります。rulesyncはソース間のずれを解消します。モデルが従うかどうかは解決しませんし、解決するとも約束していません。

よくある質問

CLAUDE.mdを別のものに置き換える必要がありますか？

いいえ。CLAUDE.md は存在し続け、Claude Codeに読まれ続けます。変わるのは誰が書くかです。あなたは .rulesync/rules/ を編集し、generate が CLAUDE.md を書き直します。チームの誰かが CLAUDE.md を直接編集すると、その編集は次のgenerateで消えます。先頭に生成ファイルであることを知らせるコメントを入れておくとよいでしょう。

1つのツールだけで使えますか？

使えますし、移行期間としては理にかなっています。--targets claudecode だけで実行しても、大きなルールを別々のファイルに整理して保つのに役立ちます。ただ、エージェントを1つしか使わないなら、得られるものは小さいです。このツールは複数のターゲットのために作られています。

何か月も前から .cursor/rules にあるルールはどうすれば？

最初のgenerateの前に rulesync import --targets cursor を実行し、.rulesync/ に何が入ったかを git diff で確認してから生成してください。インポートですべてが入らなければ、先に手作業で補います。

これで各ツールでのMCP設定は不要になりますか？

一部は。mcp 機能を有効にすると、単一のソースから各ツールのMCP設定を書き出します。やってくれないのは手間のかかる部分です。サーバーの選定、認証情報の扱い、起動しないサーバーの診断です。それはClaude CodeとCursorのMCPのテーマです。

エージェントが単独で動くVPSでも使う価値はありますか？

なおさらあります。そこでは誰もその場でエージェントを正せないからです。ただし、ファイルのルールはあくまでコンテキストです。監視がない環境で守ってくれるのはテキストではなく、権限とフックです。サーバーでエージェントを動かすことについては：VPSで24時間動かすClaude Code。

まとめ

Rulesyncは退屈なツールで、それが褒め言葉です。手作業でできないことは何もしません。ただ、4つのファイルが静かに食い違い始めるのを防ぎます。効果が出るのは、複数のエージェントと複数の人が関わるリポジトリです。ツールはMITライセンスで、インストールしなくても生成結果は動き続けるので、コストは低く抑えられます。本当に変わるのは規律です。ルールは .rulesync/ に書き、ネイティブファイルは成果物とし、generateのたびに git diff で確認する。そして常に有効でなければならないものは、どのルールにも入れず、フック、権限、テストに置きます。

エージェントにあなたのERP、ストア、データベースを読ませたいなら、それはオーダーメイドの連携（MCP、Webhook、キュー）です。システムの内容と自動化したいことを oailton.dev/ja/contato からお知らせください。