Cursor を組織導入している開発責任者・情シスが、まず決めたいのは「誰の、どの作業を、いつまでに切り替えるか」です。OpenAI モデルの提供停止について、2026 年 11 月 12 日という期日が報じられています。ただし、現時点では提案日として扱う必要があります。
本記事は 2026 年 9 月 21 日時点の確認に基づき、依存度、BYOK の可否、移行先の料金プール、管理者の制御という 4 つの判断を整理します。個人利用者向けの代替モデル選びは扱いません。後半の工程表は、自社の担当者と完了条件を決めるための運用提案です。
Cursor への OpenAI モデル提供停止で、確認できたこと・できていないこと
11 月 12 日は、報道経由で確認した提案日
OpenAI 側の声明ページとヘルプセンターは、今回の調査では HTTP 403 により本文を取得できませんでした。停止方針と理由は、一次情報を直接確認した事実とは分け、報道経由で扱います。
CIO の 2026 年 8 月 31 日の記事は、OpenAI の声明から「with a proposed shutoff date of November 12, 2026」と引用しています。意味は「提案された停止日は 2026 年 11 月 12 日」です。Cursor は 2026 年 8 月 14 日付の公式ブログで SpaceX による買収の完了を伝えています。CIO の同記事によると、OpenAI は SpaceX が利用規約に沿って技術を使うと確信できないことを理由に挙げています。
報道の対象は OpenAI モデルを Cursor に提供する契約です。Cursor 本体の終了を伝えるものではありません。9 月 21 日時点の確認では、提案日の変更も確定も裏づけられていません。
Cursor 側の案内を待たず、影響調査を始める
9 月 21 日時点で確認した Cursor の changelog と 公式ブログには、今回の提供停止に関する案内が見当たりません。Models & Pricingは引き続き OpenAI を対応プロバイダーに挙げ、GPT-5.6 Luna・Sol・Terra も料金表に掲載しています。
現在の掲載は、11 月 12 日以降の提供を保証するものではありません。告知時期が分からない以上、Cursor の案内が出てから依存調査や社内審査を始めると、移行が期日に間に合わないおそれがあります。公式案内の確認と、自社で実施できる棚卸しを並行させましょう。
以下の機能・設定の説明は Cursor 公式資料に基づきます。停止後の未公表の挙動を、現在の仕様から推測して補うことはしません。
決めること 1 — 自社の OpenAI モデル依存度をどう測るか
Messages Sent をモデル別に絞る
Cursor の Usage Analytics は Teams・Enterprise で利用できます。Messages Sent は利用者が送ったメッセージ数を示し、モードや使用モデルによる絞り込みに対応しています。管理者は次の順で確認してください。
- Web Dashboard の Analytics を開き、対象の利用者・期間を指定する
- Messages Sent を OpenAI の使用モデルで絞り、利用件数を確認する
- 同じ利用者・期間・モードの全モデルの件数と比較する
- チャート右下から表示中のデータを CSV に出力し、確認日と集計条件を添えて保存する
- 利用者に用途を確認し、モデル名と業務、設定の管理者を対応づける
たとえば、集計対象の OpenAI モデルの件数を同条件の全モデルの件数で割れば、メッセージ数ベースの依存割合を計算できます。これは本記事が提案する集計方法であり、Cursor が提供する専用の依存度指標ではありません。利用回数が少なくても重要な作業が含まれるため、件数だけでは影響の有無を判断できません。
計測対象と期間の制約を先に確認する
公式資料では、計測対象はクライアントバージョン 1.5 以上を使う利用者に限られます。フィルターには利用者は最大 10 人、期間は連続 90 日という制約があります。全社員の全期間を一度に選べる前提では、調査計画を立てられません。
利用者を分けて抽出する場合は、期間とタイムゾーンをそろえ、同じ利用者を重複集計しないようにします。計測対象外の端末があると、表示件数だけでは実際の利用を把握できません。バージョンと未計測の利用者も調査表へ記録しましょう。Enterprise では Admin API・Analytics API を使った取得も選択肢です。公式の分析資料から API の利用条件を確認できます。
依存が一部の作業に限られるなら、その作業の検証を優先します。特定チームに集中していれば当該チームで先行検証し、広く利用されていれば共通の切り替え手順と部門ごとの確認担当を用意してください。いずれも調査の完了条件は、利用件数の集計と、影響を受ける作業・担当者の特定です。
決めること 2 — BYOK を許可するか
チャットモデル限定で、Tab 補完は対象外
BYOK は、自社で用意した API キーを Cursor に設定する方法です。公式ヘルプでは、対象をチャットモデルに限定し、Tab 補完は引き続き Cursor の組み込みモデルを使うと説明しています。OpenAI については標準的な非推論チャットモデルが対象です。
具体的な対象モデル名の一覧は示されていないため、利用者のモデルピッカーで確認してください。自前キーを設定すれば従来の GPT 利用をすべて置き換えられる、という判断はできません。現在の BYOK 仕様は、停止後の利用を保証するものでもありません。
組織プランでは Cursor 側の料金も残る
Teams・Enterprise では、自前キーで送るリクエストも Cursor Token Rate の対象です。入力・出力・キャッシュを含む 100 万トークンあたり 0.25 米ドルの公表単価が適用され、Other Models の利用枠から差し引かれます。モデル提供元が請求するモデル利用料とは別の費目で、同じモデル利用料の二重請求という意味ではありません。
個人向けの Pro・Pro+・Ultra では BYOK のリクエストは付属利用枠を消費しません。この個人プランの説明は、組織の予算には当てはまりません。条件の出典は BYOK の課金説明です。税の扱いと請求総額は自社の契約・請求画面で別途確認します。
Cursor の Zero Data Retention は適用されない
BYOK では Cursor の Zero Data Retention (ZDR) ポリシーが適用されず、データの取り扱いは選択した提供元のプライバシーポリシーに従います。公式ヘルプの ZDR の説明は、ZDR に依存するチームには組み込みモデルを使うよう案内しています。
Cursor の ZDR を根拠に導入審査を通した組織では、BYOK の許可によって審査の前提が変わります。情シス・セキュリティ担当が、送信するデータと提供元の保持条件を確認してから可否を決めてください。
FIXITキーを入れ替えるだけなら、前の社内審査でいいんじゃないの？
Tsumiki公式ヘルプを読むと、BYOK だけ ZDR の外なんです。僕なら審査の前提から見直します。
判断記録には、許可・不許可・条件つき許可のいずれかを残します。条件つきなら、対象者、送信可能なデータ、対象モデル、キーの管理者と利用期限まで定めましょう。技術面は開発責任者、データ取り扱いは情シス・セキュリティ、支出は予算責任者が確認する、という分担を提案します。承認経路は自社の規程に合わせてください。
決めること 3 — 移行先でどの料金プールを使うか
GPT からの移行で変わる利用枠
Models & Pricingでは、Cursor Models と Other Models のプールを分けています。現在の GPT 利用を基準にすると、移行先による違いは次のとおりです。
| 現在の利用からの変更 | 移行先で使うプール | 予算で確認すること |
|---|---|---|
| GPT から Claude・Gemini などへ変更 | Other Models のまま | 移行先の API 単価と、同じ作業に使うトークン数 |
| GPT から Grok 4.6・4.5、Composer 2.5 へ変更 | Cursor Models へ変更 | 付属利用量と、自社プランでの消費の条件 |
| 組み込みの GPT から自前キーへ変更 | 組織プランでは Cursor Token Rate が Other Models の利用枠を消費 | Cursor 側の費目と、提供元からのモデル利用料を合算 |
公式資料は、Cursor Models の付属利用量が大きいと説明しています。ただし、プールを変更すれば総費用が下がると断定はできません。同じ作業でもモデルによりトークン数や再試行の回数が異なるため、移行前の実績と移行先の検証結果を比較してください。日常の予算管理は Cursor のコスト管理で扱っています。
モデル指定と、実際の作業をセットで検証する
開発者はルールファイル、プロンプト、個人設定、社内手順書、自動化のどこかで OpenAI モデルを固定指定していないか確認します。指定を見つけたら、表示名だけでなく実際の識別子と設定の管理者を記録してください。
移行先では同じリポジトリ・依頼文・対象ファイルを使い、テストの成否、修正の必要箇所、所要時間、利用量を残します。必要な品質と許容時間は検証前に決めましょう。候補選びの一般的な観点は Cursor のモデル選択を、ツール自体の変更を検討する場合は Claude Code・Cursor・GitHub Copilot の比較を参照できます。
決めること 4 — 管理者として何を強制するか
Enterprise の許可リストと BYOK 禁止
Enterprise は Team Settings → Models でモデルの利用許可と自前 API キーの禁止を制御できます。モデル制御の利用には営業窓口への問い合わせが案内されています。設定の根拠は Model and Integration Managementです。
組織内のグループは Organization → Groups → 対象グループ → Models でモデルの許可だけを設定します。BYOK の禁止は Team Settings → Models にのみ置かれています。管理画面で変更した後は、実際の利用者アカウントで、許可したモデルを選択できること、禁止した経路を利用できないことを確かめてください。
チームとグループは、許可範囲の和集合になる
チームと Organization Groups のモデル設定は、最も寛容な設定を採る和集合で合成されます。チーム側で広く許可しておき、グループ側だけを厳しくしても、意図した制限にはなりません。公式資料は、最も厳しい既定をチーム側に置くよう案内しています。
たとえば、一部のグループだけに例外モデルを認める場合は、チーム側の既定を必要な範囲に絞り、そのグループへ例外を追加します。所属グループの許可も含め、利用者に最終的に何が許可されるかを確認しましょう。
Auto-review を無効にする組み合わせに注意する
Auto-review のバックグラウンド分類器は Claude 4.5 Haiku または GPT-5.4 Mini を使います。両方をブロックすると、IDE の Auto-review が無効になります。GPT 系の制限だけで必ず無効になる、という意味ではありません。Claude 側の既存の制限と合わせて確認してください。公式のモデル管理資料に、この無効化条件が記載されています。
これは管理者によるブロックの仕様であり、提供停止当日の挙動を説明する情報ではありません。
Teams では合意・周知と設定確認を用意する
本記事で紹介した許可リストと BYOK 禁止は Enterprise の機能です。Teams の運用では、利用モデル、BYOK の可否、例外申請先を文書化し、利用者が設定を確認した記録を残します。周知だけでは禁止を技術的に強制できないため、強制が必要な組織は Enterprise の利用条件を問い合わせましょう。
11 月 12 日までの段取りを、担当と完了条件で決める
次の表は公式の移行日程ではなく、本記事が提案する社内計画の例です。11 月 12 日を準備の基準日とし、自社の調査・審査に必要な期間を見積もって日付を調整してください。
| 社内期限の例 | 担当 | 作業 | 完了条件 |
|---|---|---|---|
| 9 月末 | 開発責任者・管理者 | 利用データの抽出と用途の確認 | 未計測の利用者も記録し、対象作業と担当者を特定した |
| 10 月前半 | 情シス・セキュリティ・予算責任者 | BYOK の可否と条件を判断 | データ保持・費用の条件を確認し、承認結果を文書化した |
| 10 月後半 | 開発者・開発責任者 | 代替モデルで代表作業を検証 | 品質・時間・利用量を記録し、移行先を決定した |
| 11 月上旬 | 管理者・設定の管理者 | 許可設定と固定指定を変更 | 利用者の画面と必要な機能で変更結果を確認した |
| 11 月 12 日より前 | 開発責任者・手順書の管理者 | 最終確認と利用者への案内 | 未完了作業を解消し、問い合わせ先と切り替え手順を共有した |
完了判定を「設定変更済み」だけにすると、利用者が代替モデルを選べない場合や、必要な作業が完了しない場合を見落とします。GitHub Copilot のモデル廃止への対応でも、管理者のポリシー確認、開発者の固定指定の変更、代表作業の検証を分けています。同じ確認項目を自社の移行台帳にも取り入れてください。
提案日を再確認する担当も決める
公式案内の確認担当を 1 人決め、少なくとも週次と社内切り替え前に、Cursor の changelog・ブログ・Models & Pricing を確認します。OpenAI 側の声明・ヘルプを取得できるようになった場合も、日付と対象範囲を照合してください。
社内告知は、たとえば「9 月 21 日時点では 11 月 12 日が停止予定日として提案されています。当社は 11 月上旬に切り替えを完了する計画です」と書けます。ベンダーの提案日と自社の完了目標を別々に示すことで、日程が変更された場合も更新する箇所を特定できます。
次のモデル変更でも使える記録を残す
今回の調査で作った、利用者・用途・モデル指定・承認条件・検証結果の対応表は、次のモデル変更にも再利用できます。代替モデルの名前だけでなく、確認日と選定理由を残してください。
恒常的な組織運用は Cursor を組織標準にするロードマップで整理しています。まずは今回の影響範囲を特定し、期日前に必要な作業を終えられる担当体制を決めましょう。
AI 駆動開発のクリエイティブスタジオ FIXIT では、利用ルールやガバナンスを含む AI 開発ツール導入支援を提供しています。モデル移行の確認手順や、BYOK を含む組織の利用方針を整理したい場合はご相談ください。