実際に移行できるもの
ルールの内容はそのまま移行されます。 両方のツールとも、プレーンな Markdown の指示を受け取り、それをモデルに提示します。Cursor はその仕組みを明確に説明しています。「大規模言語モデルは、補完（completion）間でメモリを保持しません。ルールはプロンプトレベルで、永続的かつ再利用可能なコンテキストを提供します」また「適用されると、ルールの内容はモデルコンテキストの先頭に含まれます」。opencode の枠組みもほぼ同じで、AGENTS.md は「特定のプロジェクトに合わせて動作をカスタマイズするために、LLM のコンテキストに含まれる指示」を保持し、ドキュメントでもこの概念は「Cursor のルールに似ている」と述べられています。
ルートの AGENTS.md は作業なしで移行できます。 すでに Cursor の AGENTS.md オプション（Cursor が .cursor/rules の「シンプルな代替手段」と位置づけているもの）を使用していた場合、opencode はそれを直接読み込みます。opencode におけるプロジェクトルートのルールは、「このディレクトリまたはそのサブディレクトリで作業している場合にのみ適用」されます。
glob さえ正しければ、.mdc ルールファイルはファイルとしてそのまま移行できます。 opencode の instructions 配列はファイルパスと glob パターンを受け取るため、ファイルは .cursor/rules/ 内の元の場所にそのまま置いておくことができます。ファイルを移動するのではなく、そこを指し示すだけです。これは書き直すよりもはるかに優れており、すべてを1つのファイルにフラット化するのではなく、この方法で移行を行うべき理由でもあります。
フロントマター（Frontmatter）は移行されません。 これが最も大きな損失です。Cursor の4つのルールタイプは、Always Apply（常に適用）、Apply Intelligently（説明に基づいて Agent が関連性があると判断したときに適用）、「特定のファイルに適用」（ファイルが指定されたパターンに一致するときに適用）、および Apply Manually（チャットで @メンションされたときに適用）です。これらは3つのフロントマターフィールドの相互作用によって決まります。alwaysApply: false で globs が指定されている場合、ルールは「一致するファイルがコンテキスト内にあるときに自動的に添付」されます。alwaysApply: false で description があり globs がない場合、「Agent は説明を読み、関連性がある場合にルールを取り込みます」。どちらもない場合は、「チャットでルールを @ メンションしたときにのみ含まれます」。
opencode には、これらに対応するドキュメント化された機能はありません。ドキュメントには「すべての指示ファイルは AGENTS.md ファイルと結合される」と記載されています。かつて src/components/** を触ったときにのみ適用されていたルールが、今ではすべてのリクエストで適用されるようになります。滅多に必要としない移行チェックリストだからと手動に設定していたルールも同様です。エラーなどで派手に壊れることはありません。ただ、プロンプトが非常に大きくなり、焦点が絞れなくなるだけです。これは、エージェントが指示ファイルを無視する理由で説明した失敗パターンそのものです。
ルール内の @file 参照は移行されません。 Cursor のルールはインラインで他のファイルを参照できます。たとえば、末尾に @migration-template.sql とあるルールは、そのテンプレートを取り込みます。opencode のドキュメントは明確です。「opencode は AGENTS.md 内のファイル参照を自動的にパースしません」。サポートされている2つの回避策は、参照されているファイルを自分で instructions にリストアップするか、エージェントにそれらを読むように明示的な文章で指示することです。
チームルール（Team Rules）は移行されません。 Cursor のチームルールは、Team プランおよび Enterprise プランの Cursor ダッシュボードから管理され、他のルールタイプよりも「優先」され、「カスタマイズで無効化できない」ようにマークできます。これは組織的な管理インターフェースであり、ファイルではありません。それらのルールが何であれ、コミットされたファイルとして再表現する必要があります。これは、同じ方法での強制力が失われることも意味します。
Cursor にあって opencode にないもの、およびその逆。 Cursor のドキュメント化された永続化メカニズムは、4つの形式のルールです。Cursor のドキュメントインデックスを検索しても、自己書き込み型のメモリストアに関するヒットはないため、正確に言えば、それに対応するドキュメント化された機能は存在しません。opencode のドキュメント化されたメカニズムは、AGENTS.md ファイル、instructions 配列、および /init コマンドです。どちらのツールも、作業中に学んだことを蓄積するストアについてはドキュメント化していません。これこそが、このガイドが繰り返し立ち戻る3つ目のカテゴリです。
手動移行の手順
ステップ 1: glob を修正し、その上で /init を実行する
まず、プロジェクトの opencode.json にある instructions 配列から始めます。ドキュメントの例では .md が使用されていますが、実際のルールは .mdc であり、Cursor は .cursor/rules/frontend/components.mdc のようなサブディレクトリもサポートしています。したがって、設定すべきパターンは .cursor/rules/**/*.mdc であり、これによりネストされたルールフォルダもキャッチできます。Cursor が無視していたものの、opencode に読み込ませたいプレーンな Markdown ドキュメントがそこにある場合は、リストに .md も残しておいてください。これは珍しいケースですが、Cursor がそれらのファイルをドロップするのに対し、opencode はドロップしないため、実際にあり得るケースです。
Cursor ルールが @ で参照していたファイルを追加します。これらの参照は追跡されなくなるためです。@migration-template.sql を指すルールがあった場合、そのテンプレートを instructions に含めるか、文章で明示的に指定する必要があります。
次に、/init を実行します。これは多くの人がスキップしがちですが、非常に効果的なステップです。opencode の /init は「リポジトリ内の重要なファイルをスキャンし、コードベースから回答が得られない場合はいくつかの的を絞った質問をし、プロジェクト固有の簡潔なガイダンスを含む AGENTS.md を作成または更新」します。また、Cursor や Copilot ルールなどの「既存の指示ソースへの参照」を明示的に考慮します。重要なのは、この実行が破壊的ではない点です。「すでに AGENTS.md が存在する場合、/init はそれを盲目的に置き換えるのではなく、その場で改善します」。instructions を設定した後に実行することで、ゼロから作り直すのではなく、既存の資産を活かすことができます。
作成する前に知っておくべき優先順位のルールが1つあります。opencode は「現在のディレクトリから上に遡ってローカルファイル（AGENTS.md、CLAUDE.md）を解決」し、グローバルファイルは ~/.config/opencode/AGENTS.md で解決します。そして、「各カテゴリで最初に一致したファイルが優先されます。たとえば、AGENTS.md と CLAUDE.md の両方がある場合、AGENTS.md のみが使用されます」。リポジトリが CLAUDE.md で動作していた場合、AGENTS.md を作成すると CLAUDE.md は無効になります。同じパターンがグローバルにも適用され、~/.config/opencode/AGENTS.md は ~/.claude/CLAUDE.md よりも優先されます。
ステップ 2: 各無条件ルールにどれだけのコストがかかるかを判断する
次に、先ほど指定した .mdc ファイルに目を通し、フロントマターのみを読み取ります。それらを3つの山に分類してください。
alwaysApply: true のルールは無料（追加コストなし）です。これらは Cursor でも無条件であり、opencode でも無条件です。何もする必要はありません。
globs が指定されたルールは、ファイルタイプやディレクトリにスコープが限定されていました。opencode では、これらは常にオンになります。5行程度の TypeScript 規約のような短いルールであれば、それで問題なく、フラット化するのが正しい判断です。長いルールの場合は、2つの現実的な選択肢があります。すべてのリクエストでコストを支払う価値のある部分だけに削るか、instructions から除外して、その領域で作業するときに意図的に読み込むかです。条件付き動作を維持する3つ目の選択肢は存在しません。そうではないふりをして放置すると、指示ファイルのサイズは静かに3倍に膨れ上がることになります。
description があり globs がないルールは、最も興味深い山です。なぜなら、Cursor はその説明を検索シグナルとして使用していたからです（「Agent は説明を読み、関連性がある場合にルールを取り込む」という動作）。この仕組みは opencode には存在しません。維持できるのは 意図 です。説明テキストをルールの最初の行に残しておくことで、結合されたプロンプトを人間がスキャンしたときに、それが何のためのものかを確認できるようにします。そして、そのルールが本当にルールなのか、それとも「学んだ事実」なのかを検討してください。多くの場合、後者です。つまり、それは instructions ではなく、次のセクションに配置すべきものです。
どちらのフィールドもないルールは、手動の @ メンション専用でした。これらは通常、チェックリストやテンプレートです。これらは instructions から完全に除外し、必要なときにパスで参照してください。opencode のドキュメントでも、外部ファイルに対してまさにこのパターンを推奨しています。最初から読み込むのではなく、条件が適用されたときにファイルを読み込むようエージェントに指示します。
Cursor 自身のベストプラクティスのアドバイスを引き継ぐ価値があります。「ルールは500行未満に抑える」、「大きなルールは複数の構成可能なルールに分割する」、「内容をコピーするのではなくファイルを参照する。これによりルールを短く保ち、コードの変更に伴ってルールが古くなるのを防ぐ」。これら3つは、Cursor よりも opencode において重要になります。なぜなら、余分な情報を吸収してくれる条件付きレイヤーが存在しないからです。条件付き動作を一切失いたくない場合は、スコープの仕組みが異なる移行先を扱った Cursor ルールから Codex への移行 や、別の移行先を扱った Cursor から Claude Code への移行 を参照してください。
より良い方法：発見された事実をルールから完全に排除する
フロントマターの山を整理していると、通常、不都合な事実に直面します。.cursor/rules の内容のかなりの部分が、ルールではなく「歴史（経緯）」であるということです。「照合にバッチエンドポイントを使用しないでください。1万行を超えるとタイムアウトします」。「認証トークンは第1四半期までレガシーサービスによって発行されるため、ここにスコープを追加しないでください」。これらは、誰かが苦労して学んだ事実であり、ツールが提供する唯一の永続的な場所に保管されていたものです。
どちらのツールにおいても、ルールはそれらを格納するコンテナとしては不適切です。Cursor 自身も述べているように、ルールは「プロンプトレベルで、永続的かつ再利用可能なコンテキスト」であり、毎回再送信されます。7月に学んだ事実は、プロンプトレベルの設定ではありません。それは知識であり、制限なく蓄積され、作成されるものではなく発見されるものです。
MemoryLake は、その半分の情報を格納する場所です。両方のツールの外部に位置し、チームの働き方ではなく、チームが確立した決定事項を保持します。そして、現在使用しているクライアントから MCP または API 経由で読み取ることができます。この移行における実質的な効果は、instructions 配列を十分に短く保てるため、条件付き動作が失われても痛手にならない点にあります。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。1つのキーですべての環境をカバーできます。重要なのは、知識が特定のエディタに依存すべきではないということです。
ステップ 2: 最初のメモリをアップロードする
プロジェクトの確立された決定事項がすでに記載されているドキュメント、画像、ファイルに加えて、先ほど規約ではなく歴史（経緯）として特定したルールファイルを投入します。何度も説明するのにうんざりしていることから始めましょう。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに MCP または API 経由でアクセスを許可します。opencode のセッションにおいて、これにより確立された事実は、結合された指示プロンプトを永続的に占有するのではなく、オンデマンドで取得可能になります。
実務における変化
instructions 配列を小さく保つことができるため、条件付き動作が失われても問題なくなります。Cursor の条件付きレイヤーが存在したのは、ルールディレクトリが肥大化するためでした。肥大化する部分を別の場所に逃がせば、フラットな配列でも十分に機能します。
チームルールが移行の障害にならなくなります。Cursor のダッシュボードにあった組織的なコンテンツはきれいに分割されます。強制力のある規約はコミットされたファイルになり、確立された決定事項は、ツールやプランの枠を超えてすべてのチームメンバーのエージェントが読み取るメモリになります。
再度の移行コストが安くなります。opencode の instructions 配列や Cursor の .mdc フロントマターは、いずれもツール固有のフォーマットです。MCP 経由でアクセスできるストアはそうではないため、次の移行は知識の監査ではなく、単なる設定の変更になります。
そして、そもそも人々がルールを書くきっかけとなる特定の不満（同じことを2回指摘される、あるいはエージェントにリポジトリ内のファイルの配置場所を再学習させるなど）が、適切なレイヤーで解決されます。それは決してルールの問題ではありませんでした。プロンプトで解決しようとしていたメモリ（記憶）の問題だったのです。
Cursor から opencode への移行後のベストプラクティス
glob が何かにマッチしたか確認する。 instructions を設定した後、読み込まれたガイダンスを要約するよう opencode に依頼してください。Cursor のルールが反映されていない場合は、まず拡張子を確認してください。
/init は設定前ではなく、設定後に実行する。 既存の AGENTS.md をその場で改善するため、実際のセットアップを認識させてください。
1つのディレクトリにつき、指示ファイルの拠点は1つにする。 同じ場所にある AGENTS.md は CLAUDE.md を無効化するため、アクティブに見えるデッドファイルを残すのではなく、どちらか一方を選択して他方を削除してください。
リモート指示の URL に注意する。 opencode は URL から指示を読み込むことができ、「リモート指示は5秒のタイムアウトで取得」されます。これにより、共有のチームルールファイルが可能になりますが、セッションがホストの稼働状況に依存することにもなります。
コンテンツを貼り付けることで @ 参照を再現しない。 ファイルを instructions に追加するか、文章で指定してください。コピーを貼り付けると内容が古くなるため、Cursor 自身のガイダンスでも警告されています。
フラット化する前に歴史（経緯）を移動する。 条件付きルールをフラット化して安全なのは、そのルールが実際に規約である場合のみです。苦労話のように読めるものはすべて、メモリレイヤーに属します。
結論
この移行を率静に総括すると、opencode の instructions 配列は、すでに作成したルールファイルを再利用できる（書き直す必要がない）という点で、本当に優れたアイデアです。しかし、公開されているサンプルでは警告されていない、ドキュメント上の2つのギャップがあります。1つは、気づけば些細なことです。Cursor は .cursor/rules 内のプレーンな Markdown を無視するため、ルールはすべて .mdc であり、glob は .md ではなく .mdc にする必要があります。もう1つは構造的な問題です。instructions は提供されたすべてを結合するため、Cursor の「常に適用 / インテリジェントに適用 / ファイルごと / 手動」という区別が、すべて「常にオン」に崩れてしまいます。
どちらも対処可能です。特に2つ目については、ルールディレクトリを埋め尽くしていたものの多くが、そもそもルールであるべきではなかったからです。glob を正しく指定し、その上で /init を実行し、フロントマターを「無料（追加コストなし）」、「高コスト」、「オンデマンド」に分類し、蓄積された歴史をどちらのツールにも依存しないレイヤーに移動します。残るのは、このリポジトリでの作業方法を示す短い指示ファイルだけです。それこそが、ルールシステムが本来得意としていたことのすべてです。