MemoryLake
すべての記事に戻る
News2026年8月31日·12 分で読了

OpenAIがCursorに対し、モデルの提供終了日を2026年11月12日に設定 — モデル切り替えのコストと、移行に伴うコストとは (2026)

8月28日、OpenAIはある日付を含む短い投稿を公開しました。「本日、当社はSpaceXに対し、CursorへのOpenAIモデルの提供に関する契約を終了する意向を通知しました。提供終了予定日は2026年11月12日です。」

それ以来、書かれた記事のほとんどはビジネスに関するものでした。誰が誰を買収したか、どの訴訟が引用されているか、それがモデル市場にとって何を意味するか。そうした報道も結構ですが、この記事ではそれらについては扱いません。

現場のデベロッパーが実際に抱く疑問は、もっと狭く、より実用的なものです。使っているエディタから、これまで使っていたモデルが消えてしまった場合、そのエディタに教えてきたすべてのことはどうなるのでしょうか? 自分が書いたルール、スコープ指定された .mdc ファイル、誰かがダッシュボードから強制適用したチームの標準、いつか整理しようと思っているチャット履歴などです。

その答えはきれいに2つに分かれます。何かを決断する前に、この分岐点を知おく価値があります。セットアップの半分は、どのモデルが回答するかに依存しません。Cursor自身のドキュメントにも、そのことが一言で明記されています。もう半分はCursorに特化して紐づいており、移行する場合にコストが発生するのはこちら側です。

関連する2つの記事で、その仕組みの一部をカバーしています。CodexのインポーターがCursorのインストール環境から何を抽出できるかについては「what Codex can import from Cursor and Claude」を、ルール変換そのものについては「how to migrate your Cursor rules to Codex」を参照してください。この記事は、それらの移行作業を行う前段階の意思決定に関するものです。

両社が実際に公開した内容

OpenAIの通知

OpenAIの投稿は4つの段落から構成されています。重要な一文は、上記で引用したものです。その理由は率直に述べられています。「イーロン・マスク氏の企業が契約に違反してきたこれまでの経験に基づき、SpaceXが当社の利用規約の範囲内で当社の技術を使用するという確信が持てないため、この選択を行いました。」その仕組みは契約上のものです。「Cursorとのカスタム契約により、支配権の変更後に契約を解除できる限定的な期間が与えられています。」

この投稿における2つの詳細は、デベロッパーにとってその理由よりも重要です。

1つ目は、通知期間が意図的に長く設定されていることです。「デベロッパーがCursorを通じて当社のモデルへのアクセスを維持できる時間を最大化するため、契約で定められた最大の通知期間を設けています。」11月中旬まで猶予があるのは、偶然ではなく意図された設計です。

2つ目は見落としがちですが、即座に効果を発揮するものです。OpenAIは、「Cursorに将来のモデルを提供しない一方で、契約解除を可能な限り遅い日付に留める」ことを決定したと書いています。提供終了は11月ですが、新しいモデルの凍結は「今」始まっています。

OpenAIはまた、これが誰に影響を与えるかも名指ししています。「この決定によって最も影響を受けるのは、CursorでOpenAIモデルに依存しているデベロッパーの皆様であることを私たちは認識しています。」

Cursor側の記録

Cursorは8月14日に独自のメモを公開しました。「Cursorは正式にSpaceXに買収されました。」同社のドキュメントには現在、GPT-5.6 Sol、Terra、Lunaの専用モデルページのほか、Claude Sonnet 5、Opus 5、Fable 5、Gemini 3.1 Proおよび3.7 Flash、Grok 4.6および4.5、そしてCursor Composer 2.5が掲載されています。つまり、今週の時点では、まだ何も削除されていません。

どちらの投稿にも書かれていないこと

Cursorは「独自のAPIキーを追加して、好みのAIモデルをCursorで使用する」という、いわゆる「Bring-Your-Own-Key(キーの持ち込み)」の経路をドキュメント化していますが、同じページに2つの制限が記載されています。OpenAIの場合、対象となるのは「標準的な非推論チャットモデル」であり、「カスタムAPIキーはチャットモデルでのみ機能します。タブ補完は引き続きCursorの組み込みモデルを使用します」とあります。契約終了後にこの経路がどうなるかについては、両社の投稿とも触れておらず、ここで推測することはしません。もしこれを当てにしている場合、現時点での率直な答えは、ドキュメント化はされているものの、組み込みモデルよりも適用範囲が狭く、その将来は明記されていないということです。

セットアップに関して変わること、変わらないこと

この問題の大部分を決定づける一文があります。それはCursor自身のルールに関するドキュメントからの引用です。

> 「大規模言語モデルは、補完(completion)間で記憶を保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」

さらにこう続きます。「適用されると、ルールの内容はモデルのコンテキストの先頭に含まれます。」

これをアーキテクチャに関する記述として捉えてください。実際その通りだからです。あなたがCursorに教えたことは、モデル内には一切存在しません。 それらは、Cursorがプロンプトとして組み立てるファイルや設定の中に存在します。そのプロンプトを受け取るモデルを切り替えても、組み立てられる内容は変わりません。

したがって、モデルの変更後も、作業を一切行うことなく完全に存続するものは以下の通りです。

  • .cursor/rules 内の .mdc ファイルとしての Project Rules(プロジェクトルール)。これには alwaysApplyglobsdescription のフロントマター、およびこれら3つのフィールドに基づいて構築された4つのアクティベーション動作が含まれます。
  • サブディレクトリ内のネストされたファイルを含む AGENTS.md。Cursorはこれらを親ディレクトリと結合し、「より具体的な指示が優先される」ようにします。
  • Cursorのダッシュボードで作成された Team Rules(チームルール)。ドキュメントに記載されている優先順位は「Team Rules → Project Rules → User Rules」であり、「適用可能なすべてのルールがマージされ、ガイダンスが競合する場合は、より早いソースが優先される」と注記されています。
  • User Rules(ユーザールール)、GitHubから .cursor/rules/imported/<repoName> にインポートされたリモートルール、およびドキュメントに記載されている4つのスキルディレクトリ内のスキル。

一方で、モデルではなくCursor自体に紐づいているものは以下の通りで、これらは別のリストになります。

  • 強制適用メカニズムとしてのTeam Rules。 「Enforce this rule(このルールを強制する)」とマークされたルールは、「すべてのチームメンバーに必須であり、カスタマイズで無効にすることはできません。」このプロパティはCursorのダッシュボード機能です。これを保持するファイルは存在しません。
  • スコープ指定言語としての .mdc フロントマター。 4つのタイプは他のツールの概念と完全には一致しないため、変換には実際の作業が発生します。
  • チャット履歴と保存されたプラン。 これらは単一のアプリケーションのローカルな成果物です。
  • チームのメンバーが学んだものの、書き残さなかったすべてのこと。 これはリストの中で最大の項目であり、誰も棚卸ししていないものです。

人々が誤解しがちなこと

「Cursorをやめなければならない。」 今回の件だけでそう判断する必要はありません。Cursorのドキュメントに記載されているモデルリストには、引き続きAnthropic、Google、xAI、そして独自のComposerモデルが含まれています。Cursorを使用する理由がエディタ、エージェント、またはチームルールレイヤーであった場合、プロンプトに回答するプロバイダーがどこであるかによって影響を受けることはありません。OpenAIの投稿が特定しているのは、具体的には「OpenAIモデルに依存しているデベロッパー」であり、これは実際のグループですが、全体の一部にすぎません。

「モデルが変わっても、ルールは同じように動作する。」 ルールは同じように配信されますが、それは同じ動作を保証するものではありません。ルールは自然言語(散文)であり、自然言語はモデルによって受け取り方が異なります。以前のモデルが緩やかに従っていたルールを、新しいモデルが文字通りに解釈して従うようになると、出力が変わる可能性があります。これはセットアップの欠陥ではありませんが、モデル変更後の1週間は、差分をより注意深く確認すべき期間であることを意味します。

「キーの持ち込み(Bring-your-own-key)があるから、大した問題ではない。」 それを当てにする前に、上記のCursor自身の制限を読んでください。また、そのページには「独自のAPIキーを使用する場合、Cursorのデータ不保持(Zero Data Retention)ポリシーは適用されません」、「すべてのリクエストは、最終的なプロンプト構築のためにCursorのサーバーを経由してルーティングされます」とも記載されています。これらは障害(ブロッカー)ではありませんが、セキュリティチームがすでに懸念を示している可能性のあるトレードオフです。

「Codexがすべてをインポートしてくれる。」 Codexのインポーターは非常に優れており、移行元としてCursorをリストアップしています。また、移行対象となるものも具体的に示されています。指示ファイル、settings.json、スキル、プラグイン、プロジェクトフォルダ、過去30日間のチャット、MCP設定、フック、スラッシュコマンド、サブエージェントなどです。ただし、その表の記憶(memory)の行に記載されている内容に注意してください。「Claude Codeからのプロジェクトの記憶(Project memories from Claude Code)」とあります。特定されたソースは1つだけです。インポーターが、あなたのチームが決定した内容とその理由まで移行できるとはどこにも書かれていません。

解決策:モデルに依存しない半分をエディタの完全に外側に保持する

ここで得られる教訓は、「別のベンダーを選べ」ということではありません。誰も予期していなかった方向から2ヶ月半の通知期間が突きつけられたこと、そしてセットアップの中でポータブル(移植可能)だった部分は「ファイル」だったからこそポータブルであったのに対し、痛みを伴う部分は「単一の製品の内部」に存在していた部分だったということです。

ルールはすでにこの原則に従っています。それらはリポジトリ内のファイルであるため、モデルの切り替えコストはゼロになります。しかし、知識レイヤーは通常そうなっていません。決定事項、修正内容、標準の背後にある理由などは、チャット履歴や個人の頭の中、あるいはその時にた伴い開いていたツールの中に散逸しています。

MemoryLake は、特定のツールに依存しない外部の記憶レイヤーです。そのため、今期使っているツールからも、来期使うツールからも、その記憶を読み取ることができます。セットアップは3つのステップで完了します。

ステップ 1: APIキーを作成する

サインインしてAPIキーを作成します。接続するすべてのツールで共通の認証情報を1つ使用します。

コンテキストをモデルから独立して保持するためのMemoryLake APIキーの作成
コンテキストをモデルから独立して保持するためのMemoryLake APIキーの作成

ステップ 2: 最初の記憶をアップロードする

1つの項目につき1つの主張を含む、短いエントリを作成します。ソースとなる素材は、現在ルールの中に暗黙的に含まれている「理由」です。

モデルの切り替えコストをゼロにするために、決定事項と制約をMemoryLakeに書き込む
モデルの切り替えコストをゼロにするために、決定事項と制約をMemoryLakeに書き込む

理由を伴う決定事項。 あなたの .mdc ファイルには「マイグレーションは追加のみ(additive-only)とする」と書かれているかもしれません。しかし、その「なぜ」はどこにも書かれていません。その理由をここに書き留めておくことで、新しいメンバーが読むたびにルールが元に戻されてしまうのを防ぐことができます。

定着した修正内容。 チームが試して却下したアプローチと、何がうまくいかなかったか。これは、どのルール形式にも入力フィールドが存在しないカテゴリです。

コード以外の業務上のコンテキスト。 どのサービスを誰が所有しているか、今期は何が凍結されているか、どの締め切りが変更されたか。

外部へのポインタ。 ダッシュボード、ランブック、課題トラッカーなど、エージェントがリポジトリを読み込むだけでは見つけられない情報です。

ステップ 3: AIとエージェントを接続する

使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能であり、CursorはMCPサーバーをサポートしているため、同じ記憶を今すぐCursorで利用できます。Codex、Claude Code、Cline、OpenClawも同様に接続でき、その他のツールもAPIを介して同じ記憶を読み取ることができます。接続方法が変わっても、記憶そのものは変わらない、それが重要なポイントです。

Cursor、Codex、その他のエディタを1つの共有記憶レイヤーに接続する
Cursor、Codex、その他のエディタを1つの共有記憶レイヤーに接続する

3つの率直な制限事項があります。これはあなたの .mdc ファイルやTeam Rulesを移行するものではありません。 これらはCursor固有のものであり、記憶レイヤーがそれらを変換することはありません。契約を延長したり、モデルを復元したりするものでもありません。 この記事の内容によって、11月にCursorで利用可能なモデルが変わることはありません。そして、記憶はコンテキストであり、強制力ではありません。 常に遵守されるべき事項は、ビルドを失敗させるチェックプロセスに組み込むべきです。この点は、Cursor自身のドキュメントでも強制ルールについて次のように指摘されています。「AIによるガイダンスを唯一のセキュリティ管理策にすべきではありません。」

実務においてこれがもたらす変化

モデルの変更が重大なイベントではなくなります。 ルールは、あなたが所有するファイルからプロンプトの生成時に組み立てられます。どのモデルが回答するにしても、組み立てられる内容は同じです。

コストのかかる半分が可視化されます。 チャット履歴がまだ残っているうちに、チャット履歴の中にしか存在しなかった情報が何であるかに気づくことができます。

チームの標準がその理由とともに保持されます。 ルールはファイルとして移行し、理由は記憶として移行します。どちらも次のツールへと引き継がれます。

11月12日のような締め切りは、移行プロジェクトではなく、単なるカレンダーの予定になります。 設定でモデルを切り替えるのは数クリックで済みます。エディタを切り替えるのは一大プロジェクトです。どちらが本当に必要なのかを理解することが、意思決定のすべてです。

モデルが変更される際のベストプラクティス

何かを決める前に、「どのモデルか」と「どのツールか」を切り離して考えてください。 これらは異なるコストであり、今回のニュースが強制しているのはそのうちの片方だけです。

おもちゃのリポジトリではなく、実際の業務で代替モデルをテストしてください。 あるモデルの緩い解釈をすり抜けていたルールも、別のモデルの文字通りの解釈に対応するためには、より厳密に書き直す必要があるかもしれません。

強制適用されているTeam Rulesを今すぐ監査してください。 これらはファイルとして表現されていない項目であり、他のツールに移行した際には、警告なしに失われます。

インポーターを信頼する前に、インポーターの対応表を読んでください。 Codexは移行対象となるものを明記しています。そこに記載されていないものは、あなたが手動で移行する必要があります。

ルールのファイルに「理由」を書きすぎないようにしてください。 ルールはモデルのコンテキストの先頭に挿入され、コンテキスト容量を圧迫します。一般的な構成については「what coding agents actually read」を参照してください。

締め切りにアーキテクチャを決めさせないでください。 2ヶ月半という期間は、計画的に動くには十分な時間です。同時に、不要なツールの変更を3回も繰り返してしまうのにも十分な時間です。

チームが今週学んだことを書き留めてください。 モデルの移行期には、これまで誰もドキュメント化していなかった暗黙のルールが表面化します。これは一度きりの機会であり、すぐに過ぎ去ってしまいます。

結論

OpenAIの投稿は、日付とその理由を示しています。契約で認められている最大の通知期間を設けた2026年11月12日の提供終了予定日と、それまでの間、Cursorに将来のモデルを提供しないという内容です。Cursor側の記録は、この条項を誘発した買収の事実を認めており、ドキュメントには依然としてAnthropic、Google、xAI、およびComposerの選択肢を含むモデルリストが掲載されています。

ほとんどのCursorユーザーにとって、これは単なる設定の変更にすぎません。Cursorのドキュメントには、モデルは補完間で記憶を保持せず、コンテキストを永続化させるのはルールであると明記されています。つまり、あなたの .cursor/rules、ネストされた AGENTS.md ファイル、およびTeam Rulesは、誰がプロンプトに回答するかに影響されません。もし特にOpenAIモデルが必要な場合は、本格的な意思決定を迫られることになります。移行できないもののリストはシンプルです。.mdc のスコープ指定言語や強制適用されたTeam Rulesは移行できず、チャット履歴や保存されたプランも移行できません。移行先のインポーターは、移行できるものを正確に明記しています。

無料で移行できるのはファイルとして保持していたものであり、失われるのは会話として保持していたものです。これこそが、両社以外の誰も読んだことのなかった契約書から突然突きつけられた提供終了日という出来事から得られる、実際の教訓です。そしてこれこそが、「why long context isn't memory」が形を変えて何度も繰り返される同じ議論である理由です。

よくある質問

OpenAIのモデルがオフになると、Cursorのルールは失われますか?

いいえ。Cursorのドキュメントには、「大規模言語モデルは補完間で記憶を保持しない」こと、および「ルールはプロンプトレベルで永続的かつ再利用可能なコンテキストを提供する」こと、そしてルールの内容は「モデルのコンテキストの先頭に含まれる」ことが記載されています。あなたの .cursor/rules.mdc ファイル、AGENTS.md ファイル、User Rules、およびTeam Rulesはすべて、モデルが処理を行う前にCursorによって組み立てられます。そのプロンプトを受け取るモデルを変更しても、これらに影響はありません。

OpenAIは具体的に何を発表したのですか?

SpaceXに対し、「CursorへのOpenAIモデルの提供に関する契約を終了する意向を通知し、提供終了予定日を2026年11月12日とした」こと、これが「契約で定められた最大の通知期間」であること、そしてそれまでの間、「Cursorに将来のモデルを提供しない一方で」契約解除を可能な限り遅い日付に留めることを発表しました。表明された理由は、「SpaceXが当社の利用規約の範囲内で当社の技術を使用するという確信が持てないため」としています。

独自のAPIキーを使用して、CursorでOpenAIモデルを使い続けることはできますか?

Cursorは、OpenAI、Anthropic、Google、Azure OpenAI、およびAWS Bedrock向けの「キーの持ち込み(Bring-Your-Own-Key)」の経路をドキュメント化していますが、OpenAIについては2つの制限が記載されています。対象となるのは「標準的な非推論チャットモデル」であり、「カスタムAPIキーはチャットモデルでのみ機能します。タブ補完は引き続きCursorの組み込みモデルを使用します」とあります。OpenAIの投稿でも、Cursorが公開しているドキュメントでも、契約終了後にこの経路がどうなるかについては言及されていないため、その将来は保証されているわけではなく、未確定であると捉えてください。

これにより、何人のデベロッパーが影響を受けますか?

具体的な数値は引用しません。OpenAIの投稿には数値は記載されておらず、「この決定によって最も影響を受けるのは、CursorでOpenAIモデルに依存しているデベロッパーの皆様である」とだけ書かれています。報道で飛び交っている数値はサードパーティによるものであり、互いに一致していません。意思決定のために数値が必要な場合、本当に重要なのは、あなたのチームの中でその特定のグループに属している人数だけです。

Codexに移行する場合、実際に何が引き継がれますか?

Codexのインポートフローでは、デスクトップアプリとCLIの両方でCursorがサポート対象の移行元としてリストされており、ドキュメントの表には指示ファイル、settings.json、スキル、プラグイン、既存のプロジェクトフォルダ、過去30日間のチャット、MCPサーバー設定、フック、スラッシュコマンド、サブエージェントが記載されています。CLIは「過去30日間のチャットを最大50件インポート」します。その表の記憶(memory)の行には、1つのソースとして「Claude Codeからのプロジェクトの記憶(Project memories from Claude Code)」が挙げられています。段階的なルール変換については、「how to migrate your Cursor rules to Codex」で解説しています。

今すぐツールを切り替えるべきですか、それとも待つべきですか?

どちらの投稿もツールの変更を強制するものではなく、急いで移行しようとすると、結果的に移行作業を0回ではなく3回も行う羽目になりかねません。合理的な手順としては、まずチーム内にCursorではなくOpenAIモデルに本当に依存しているメンバーがいるかどうかを確認します。もしいる場合は、11月よりかなり前の段階で、実際の業務で代替手段をテストします。そしてその合間に、現在はチャットスレッドの中にしか存在しない標準や理由を書き留めておきます。避けるべき失敗パターンは、「why Cursor forgets your project rules」で説明されている、静かに進行する問題です。つまり、移行した後に、エージェントをガイドしていた情報の半分がどこにも書き残されていなかったことに気づくという事態です。