OpenAIのCursorモデル供給停止、影響5%と回避策3つで読む依存リスク

この記事のまとめ

OpenAIは、SpaceXによるCursorの買収を受けて、Cursorへのモデル供給を終える意向を通知しました。提案された停止日は2026年11月12日で、Cursor側はOpenAIモデルが利用の約5%だと説明しています。押さえておきたいポイントは3つです。

OpenAIは8月28日にSpaceXへ契約終了の意向を伝え、提案している停止日は2026年11月12日です。移行の期間中、Cursorには今後のモデルを提供しないとしています。
OpenAIモデルはCursorの利用トラフィックの約5%で、ClaudeやGemini、Grokといった選択肢が残ります。ただし自前のAPIキーではCursor Tabや背景で動くエージェントなど一部の機能は使えません。
回避策は、自分のAPIキーの持ち込み、Codex拡張への切り替え、Amazon BedrockやAzureなどのAIゲートウェイ経由の3つです。

Cursor供給停止の基本情報

通知内容と停止予定日

停止予定日は2026年11月12日と提案されています。確定した最終日ではなく、あくまで提案という位置づけです。

OpenAIはSpaceXに対して、CursorへOpenAIモデルを提供する契約を終える意向を通知しました。提案している停止日は2026年11月12日です。開発者がCursor経由で同社のモデルを使える期間をできるだけ長くするため、契約で決められた最長の通知期間を取ったと説明しています（参照*1）。

終了の対象になるのは、CursorがOpenAIのモデルへ直接つなぐ形の提供です。買収されたのはCursorの親会社であるAnysphereで、OpenAIはマスク氏が持つ企業との過去の紛争を挙げ、SpaceXが利用規約を守ると確信できないと述べました。Cursor側は、OpenAIモデルが占める利用は全体の約5%にすぎず、混乱はあっても事業の存続を脅かすものではないという見方を示しています（参照*2）。つまり今回の話は、Cursor自体が使えなくなるのではなく、OpenAIモデルへの経路が閉じるという範囲の出来事です。

この点は重要です。停止日はOpenAIが提案している日付であり、確定した最終日ではありません。対象が直接の提供に限られる以上、Cursorという道具そのものが使えなくなる話ではなく、OpenAIモデルへの経路が閉じるという話です。慌てて別のエディタへ乗り換える前に、自分たちの開発フローで実際にOpenAIのモデルをどれだけ使っているかを棚卸しすることが先決でしょう。

停止理由と契約条項

停止理由は、利用規約が守られるかどうかへの不信です。

公表した説明では、マスク氏の企業が契約に違反した経験を踏まえると、SpaceXが利用規約の範囲で自社の技術を使うとは確信できないとしています（参照*3）。

通知が出たのは8月28日で、SpaceXがCursorの親会社Anysphereを買収した同じ月の出来事でした。理由として挙がったのは、マスク氏によるTwitter買収のあとに契約条件が破られたこと、そしてxAIがOpenAIの利用規約に違反したとマスク氏が宣誓のうえ認めたことです。OpenAIは、支配権変更条項が認める最大限の通知期間を設ける一方、移行の期間中はCursorに今後のモデルを提供しないとしています（参照*4）。

支配権変更条項は、会社の持ち主が変わったときに契約を解除できる限定的な仕組みです。ここで挙がった違反の話はOpenAI側の主張と報道に基づく内容で、裁判所が下した判断ではありません。条文の細かい中身は公開されていないため、解除の条件をどこまで広く読めるかは外からは分かりません。

SpaceX買収と対立の経緯

600億ドル買収と提携内容

供給停止の前段には、SpaceXによるCursorの買収があります。

SpaceXは、AIのスタートアップであるCursorを600億ドルで買収する計画を進めました。同社は4月の時点で、Cursorを買収する権利、または協力関係を結ぶために100億ドルを支払う権利があると説明していました。

規制当局への提出書類では、取引が第3四半期に完了すればCursorが完全子会社になるとしています（参照*5）。この600億ドルは会社の評価に基づく買収規模で、現金の支払額として示された数字ではありません。

SpaceXは2026年4月19日にCursorとコンピュート契約を結びました。CursorはAIを前提とした統合開発環境を開発・運営しており、大規模言語モデルを組み込む独自の仕組み（model harness）を通じたエージェントを使って、コードを書く、直す、見直す、整えるといった作業を支えます。さらに2025年には、ソフトウェア開発向けに学習させた自社の大規模言語モデルComposerを公開しました（参照*6）。

買収の前から計算資源の契約があり、自社のモデルも持っていたという流れは、供給が止まったあとにどこまで自前でまかなえるかを読むときの前提になります。

MuskとOpenAIの対立構図

今回の打ち切りは、当事者の反応と過去の似た事例を並べると見え方が変わります。私が注目したのは、マスク氏とOpenAIの対立が、純粋な技術上の問題ではなく、人間関係と会社間の紛争として顕在化しているという構図です。

Cursorへのアクセス停止について、マスク氏は「まったく気にしていない」と述べました。一方で、Cursorを使う顧客にとっては小さくない問題です。

近く公開される予定の最先端モデル（frontier model）Astraを含め、OpenAIのモデルがCursorから使えなくなるためです（参照*3）。OpenAIとマスク氏の距離は、供給停止の理由として持ち出された過去の紛争にも表れています。

似た構図は以前にもありました。OpenAIがWindsurfの買収を計画した際、Anthropicは2025年にWindsurfからClaudeモデルへのアクセスを制限しています。この買収計画はのちに破談となりました（参照*7）。

当事者も時期も違うため同じ出来事として扱うことはできません。しかし、買収をきっかけにモデルの供給が絞られる展開は今回が初めてではない、という事実は重く受け止めるべきです。私が企業のAI活用を支援する中でも、「特定のモデルやツールに依存しすぎている」という課題はよく出てきます。開発の道具を選ぶときは、機能の使い勝手だけでなく、その道具が誰と組み、誰に買われる可能性があるかという点も判断の材料になる時代です。

影響範囲と5%の読み方

トラフィック5%と代替モデル

影響の大きさを測る手がかりが、約5%という数字です。

CursorのCEOであるマイケル・トルエル氏によると、OpenAIのモデルが担っているのは同社の利用トラフィックの約5%です。Cursorの利用ではSonnet 3.5以降Claudeの比重が大きく、AnthropicはCursor内のClaude向けに計算資源の提供を増やすと公に表明しました（参照*8）。

残る選択肢も具体的です。CursorはClaudeのFableやOpus、Sonnet、Gemini 3.1 Pro、Gemini 3.7 Flash、そしてGrokといったモデルも提供しています（参照*2）。

約5%はCursor全体をならした数字であり、チームごとの依存度とは別ものです。特定の作業でOpenAIのモデルを指定して使っているなら、その部分が受ける影響は全体の比率より大きくなります。私がコンサルティングの現場で見てきた経験から言うと、「平均で5%」という数字は、ある部署にとっては0%、別の部署にとっては50%という内訳を隠していることが多いです。

自分たちの状況を見るときは、全体の割合ではなく、作業ごとにどのモデルを指定しているかが手がかりになります。

自前キーで動かない機能

自分のAPIキーを持ち込めばすべて元通り、とはいきません。

OpenAIのサポート案内によると、顧客のAPIキーでは動かせない機能があります。具体的には、Cursor Tabと入力補完、モデルを自動選択する仕組み（Autoルーティング）、CloudおよびBackground Agents、Automations、Cursor CLI、CursorのAPIとSDKです。これらはCursorが自ら提供したり振り分けたりするモデルに依存しています（参照*9）。

裏を返すと、画面上のやり取りが中心のチャットは自前キーでも続けやすく、Cursor側が裏で管理するエージェントの機能ほど置き換えが難しくなります。たとえば自動で最適なモデルを選ぶAutoルーティングが使えないと、モデルの指定は手作業に寄ります。エージェント機能を使った自動化ワークフローを組んでいるチームほど、影響の見積もりは慎重に行う必要があります。

移行の重さは機能ごとに差が出るため、日常的に使っている機能から切り分けて見る形になります。

ここで挙げた範囲は案内が出た時点の内容で、今後の仕様まで固定するものではありません。

通常のモデル廃止との違い

同じ使えなくなるでも、今回は通常のモデル廃止とは種類が違います。

提供元の都合でモデルが引退する場合には、事前の案内が運用として決まっています。Anthropicは、廃止予定のモデルを実際に動かしている顧客へ通知し、一般に公開されたモデルについては廃止の少なくとも60日前に知らせるとしています（参照*10）。これは別の会社の一般的な運用ルールであり、今回の供給停止を説明するものではありません。

今回の打ち切りは、モデルが古くなったからではなく、契約と会社の持ち主が変わったことを理由にしています。前者は後継のモデルへ乗り換えれば対応できますが、後者は供給元そのものが外れるため、別の会社のモデルや別の経路を用意する話になります。リスクを分けて考えると、モデル単位の入れ替えと、供給元単位の入れ替えという二段構えで備えられます。生成AIを業務に組み込むなら、この二種類のリスクを最初から切り分けて設計しておくべきでしょう。

回避策3つと選び方

自前APIキーの持ち込み

回避策の1つ目は、自分のAPIキーをCursorに持ち込む方法です。

この方法では、手元でのチャットやエージェントへの指示に、自分で契約したOpenAIのキーを使います。使える範囲は、Cursorが自前で振り分けている機能を除いた部分にとどまります。

キーの扱いには前提条件が付きます。Whartonの案内は、APIキーを安全に保管すること、公開リポジトリに埋め込まないこと、不要になったら無効化することを求めています（参照*11）。

自分のキーを軸に、複数の提供元を切り替える仕組みもあります。llmswapは、利用者自身のキーでルーティングを管理し、周辺のアプリやワークフローを書き換えないままモデルを入れ替えられる仕組みで、OpenAI、Anthropic、Gemini、Groq、xAIなどに対応します（参照*12）。

キーを個人任せにすると、誰がどのキーでどれだけ使ったかが見えにくくなります。持ち込みを選ぶなら、保管の場所と失効の手順をチームで決めておく形が現実的です。私が企業への導入支援で繰り返し見てきたのは、「とりあえずAPIキーを配った」で終わり、管理が形骸化するパターンです。使い始めるより、ルールを決めるほうが実は難しい。

Codex拡張への切り替え

2つ目は、CodexのIDE拡張へ切り替える方法です。

OpenAIとCursorの契約は2026年11月12日の終了が提案されており、その後はCursorから既定でOpenAIのモデルが提供されなくなります。開発者がOpenAIのモデルを使い続ける道は3つあり、自分のAPIキーを持ち込む方法、ChatGPTのサブスクリプションかAPIキーでCodexのIDE拡張を使う方法、Amazon BedrockやAzureのようなAIゲートウェイ経由でつなぐ方法です（参照*8）。

Codexの拡張は、Cursorの中でOpenAIのモデルを呼ぶのではなく、OpenAIが用意した経路に寄せる選び方になります。すでにChatGPTを契約しているなら、キーを新たに用意せずに始められる点が実務上の違いです。

編集環境を乗り換える判断は、これまでの作業の流れを組み直す手間を伴います。どの作業をどの道具で行うかの線引きを決め直すことになり、補完やレビューの手順をどこまで保てるかが切り替えの負担を左右します。「ツールを変える」という話は、表面上は設定の変更ですが、実態は開発ワークフロー全体の再設計です。この手間を過小評価しないことが重要です。

AIゲートウェイ経由の接続

3つ目は、AIゲートウェイを経由してモデルを受け取る方法です。

ゲートウェイは、モデルへの接続を1か所にまとめる中継地点です。Databricksの案内では、Cursorを開いてSettings、Cursor Settings、Models、API Keysと進み、Override OpenAI Base URLを有効にしたうえで、ワークスペースのURLに続けて/ai-gateway/cursor/v1を指定します（参照*13）。

設定の作業そのものは、つなぎ先のURLとキーを差し替える形に近いものです。中継地点を挟むと、利用量の制限や使用状況の記録、誰がどのモデルを使えるかという権限の管理を、会社側の仕組みでまとめて扱えます。個人ごとにキーを配る場合と比べ、統制の窓口が1つになります。

一方で、使えるモデルや承認の範囲は、ゲートウェイを提供する側の方針に左右されます。ここまでの3つの経路は、いずれもこれまでと同じ使い心地をそのまま保証するものではありません。どの回避策も「完全な代替」ではなく「次善策」として理解しておくことが、現実的な移行計画につながります。

移行手順と依存リスク管理

利用状況の棚卸しと回帰テスト

移行の第一歩は、いまの使い方を洗い出すことです。

エディタの座席数ではなく、ワークフローごとにモデルの利用状況を一覧にします。記録する項目は、選んでいるモデル、ルーティングの設定、エージェントの機能、リポジトリの権限、データの置き場所の条件、請求の経路です。Cursorの現在のドキュメントによると、モデルの選択肢にはOpenAI、Anthropic、Google、そしてCursor自身のモデルが含まれ、Autoルーターは提供元をまたいで選びます（参照*9）。

一覧ができたら、実際の作業を使って代替のモデルを小さく試す進め方が取れます。公開されている性能比較の点数だけでは、自分たちのコードや手順で同じ結果になるかまでは分かりません。私自身も、ChatGPT、Claude、Geminiなどに同じタスクを与えて比較検証を繰り返してきましたが、ベンチマークの数字と実務での使い勝手は必ずしも一致しません。

日々の修正や見直しの作業をそのまま流し、出力の質と手戻りの量を並べて比べる形になります。組織の規模や統制の水準によって、省ける工程と足すべき工程は変わります。

認証情報と設定ファイルの保護

自前キーの運用に切り替えると、守るべきものが増えます。

クラウドセキュリティアライアンスの研究ノートは、Miasmaと呼ばれる攻撃が57個のnpmパッケージを286以上の悪意あるバージョンにわたって侵害し、73個のマイクロソフトのGitHubリポジトリへ広がったとまとめています。この攻撃は、Claude Code、Cursor、Gemini CLI、VS Codeの設定にバックドアのファイルを置き、対象のプロジェクトをそれらの道具で開いたときに動く仕組みでした（参照*14）。対象は特定の期間に確認されたパッケージです。

HiddenLayerの2026年AI脅威ランドスケープ報告書は、2026年3月にITとセキュリティの責任者250人へ調査し、76%の組織が組織で把握していないAI利用（shadow AI）を確実または可能性の高い問題として挙げ、前年から15ポイント増えたと報告しました（参照*15）。

移行の場面で回避策を個人任せにすると、把握されていない使い方が増えます。キーの保管場所とAIツールの設定ファイルを、同じ管理の対象としてそろえる形が取れます。

供給停止を前提とした設計

今回の件を一時的なトラブルとして処理するより、次の供給停止を前提に設計を考える機会として捉えるべきです。

他社の基盤モデルの上に製品を作る場合、供給元が自社の持ち主をどう見るかが、そのまま製品の計画に効いてきます。会社の持ち主が変わったことで、中心にある依存関係が終わることもあります（参照*4）。

モデルへのアクセスは部品の調達と同じ扱いになります。用意しておく要素は3つです。

別の提供元へ切り替えられる代替の経路
供給が止まったときに機能を落としながら動かし続ける縮退の動き
契約の通知や条件の変更を見張る仕組み

ただし、複数のモデルを並行して使う形は、費用も品質のばらつきも運用の手間も増やします。どこまで備えを厚くするかは、止まったときの損失と釣り合う範囲で決める判断になります。「全部に備える」のではなく、「止まったとき最も困る部分に絞って備える」という優先順位をつけることが、現実的なリスク管理の出発点です。

おわりに

今回の供給停止は、OpenAIがSpaceXへ通知した契約終了の話で、提案された停止日は2026年11月12日です。Cursor側の説明ではOpenAIのモデルは利用の約5%で、ClaudeやGemini、Grokといった選択肢が残ります。ただし自前のキーでは動かない機能があるため、影響の大きさは全体の比率だけでは測れません。私が今回の件で一番伝えたいのは、「5%だから大丈夫」と安心するのではなく、自分たちのワークフローで実際に何%がOpenAIのモデルに依存しているかを確認することです。

回避策は、自分のAPIキーの持ち込み、Codex拡張への切り替え、AIゲートウェイ経由の接続の3つです。どれを選ぶかは、必要な機能と、キーや権限をどこまで会社側で管理したいかで変わります。モデルの供給を「差し替えが起こりうる依存関係」として最初から設計に織り込む。その発想が、今後も繰り返されるであろう同種の変化への備えになります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））