OpenAIがSpaceX傘下のCursorへのモデル提供を11月12日に終了、Qwen3.8 27BがMac Studio M3 UltraでQ4_K_M 14tokens/s・1bit 27tokens/sを実測、脆弱性パッチの噂から10分で自動プローブが到達ほか2件

今日の3行

• OpenAIがSpaceX傘下のCursorへのモデル提供を2026年11月12日に終了すると通知し、Musk企業による契約違反を理由にAstraを含む将来モデルの提供停止を明言しました。Cursor依存を5%と公表する一方で約4年の協業を尊重すると述べており、CursorでOpenAIモデルを使うSaaSは3か月以内に代替モデルとフォールバック設計へ切り替える必要があります。
• Qwen3.8 27BがMac Studio M3 UltraでQ4_K_M 17GBで約14tokens/s、1bit 6.7GBで27tokens/sを実測し、前世代qwen3.6:27bの28.6tokens/sに対し出力トークンが約1/3のため壁時計は互角と示されました。32GBでQ4、16GBでQ2が動作するRAM要件が具体値で示され、262,144トークンのネイティブコンテキストとApache 2.0で自前運用する採算判断を今日から下せます。
• OCaml cohttpのパッチ議論から約10分でpercent-encoded traversalへの自動プローブが到達し、DeepSeek V4 Proが1分以内にexploitを生成したと報告されました。rcloneで10年20件だった開示が先月だけで40件に急増しており、公開リポジトリでの議論が即攻撃に直結する前提で非公開パッチと即時リリースの運用へ切り替える必要があります。

深掘り: OpenAIがSpaceX傘下のCursorへのモデル提供を2026年11月12日に終了へ — Musk企業による契約違反とAstra提供停止を理由に明言

要点 OpenAIはSpaceXに対して、CursorへOpenAIモデルを提供する契約を終了する意向を通知し、提案される停止日を2026年11月12日としています。契約で定められた最大の予告期間を与えることで、開発者がCursor経由でOpenAIモデルへアクセスできる時間を最大化する措置だと説明しています。この決定は非常に困難だったとして、モデルを開発者に広く提供したいと考えていることを強調しています。理由として、Elon Musk氏の企業が契約に違反してきた経験から、SpaceXがOpenAIの技術を同社の利用規約内で使うことに確信を持てないことを挙げています。具体的には、Musk氏がTwitter（現在はSpaceXの一部）を買収した後に同社がOpenAIとの契約条件に違反し（他の多くの契約と同様）、今年初めにはMusk氏自身が宣誓下でxAI（現在もSpaceXの一部）がOpenAIの利用規約（xAI自身の規約と類似）に違反したことを認めたとしています。OpenAIは、大規模パートナーであるSpaceXとの協業では、利用規約の遵守と大規模な安全性（safety at scale）を確保するために通常カスタム契約に依存すると説明し、Cursorとのカスタム契約には支配権変更（change of control）後に限られた期間内で解約できる条項があるとしています。AI能力の進展に伴い、次期モデルAstraが規約に沿って使われることを確保する新たなレベルの説明責任があるとして、将来モデルをCursorに提供せず、解約を最後に可能な日付まで保持するという判断をしたとしています。Cursorとは約4年間協業し、チームとプロダクト、開発者コミュニティへの貢献に大きな敬意を示しつつ、最も影響を受けるのはCursorでOpenAIモデルに依存する開発者であるとして、移行を全力で支援する用意があると述べています。

なぜ重要か Cursor経由でOpenAIモデルを使っているSaaS開発者にとって、2026年11月12日にその経路が停止し、Astraを含む将来モデルが提供されないことが明言された点が重要です。個人開発でSaaSを作るエンジニアは、コーディングエージェントの基盤モデルを1社の提供判断に依存させている場合、支配権変更という自社では制御できない要因で供給が止まるリスクを今回の事例で具体的に認識できます。OpenAIが「非常に困難な決定」でありながら、契約違反の経験を根拠に規約遵守への確信が持てないことを理由に踏み切ったと説明しているため、技術的な性能や価格ではなく、契約と安全性の運用を理由に供給が止まるパターンを前提に設計する必要があることが示されています。大規模パートナーではカスタム契約で安全性を確保するという説明は、今後Astraのような次世代モデルでは利用規約の適用がより厳格になる可能性を示唆します。最も影響を受けるのは開発者であるとして移行支援を表明していますが、具体的な支援内容は示されていないため、支援を待つ姿勢ではなく、停止日までに自前で代替モデルとフォールバック設計を確保する判断が求められます。

仕組み 仕組みは、カスタム契約と支配権変更時の解約条項、そして将来モデル提供の停止という3点で説明されています。1つ目は、大規模パートナー向けのカスタム契約です。OpenAIはSpaceXのような大規模パートナーと協業する場合、利用規約の遵守と大規模な安全性を確保するために通常の利用規約に加えてカスタム契約に依存すると説明しています。このカスタム契約がCursorとの間にも存在することが前提になっています。2つ目は、支配権変更後の限られた解約期間です。Cursorとのカスタム契約は、支配権変更後に限られた時間枠内でのみ解約できるとされ、今回の決定はその時間枠の中で、解約を最後に可能な日付である2026年11月12日まで保持する形で実行されています。契約上の最大予告期間を与えるという表現は、この時間枠の中で開発者への影響を最小化するための措置として説明されています。3つ目は、将来モデルの提供停止です。AI能力の進展に伴い、次期モデルAstraが規約に沿って使われることを確保する新たなレベルの説明責任があるとして、OpenAIはCursorに対して将来モデルを提供しないことを同時に決定しています。理由付けの核として、Musk氏がTwitter買収後にOpenAIとの契約条件に違反したこと、今年初めに宣誓下でxAIによる利用規約違反が認められたことが挙げられ、これらを根拠にSpaceXが技術を利用規約内で使うという確信が持てないと判断したと説明されています。結果として、現在のモデル提供は2026年11月12日まで最大限延長しつつ、Astraを含む将来の提供は行わないという線引きになっています。

導入するなら

• 現在のCursorワークフローで、どのタスクがOpenAIモデルに依存しているかを棚卸しします。Cursor経由の呼び出しをOpenAI APIの直接呼び出しや他の提供経路に置き換えた場合に、同一のプロンプトとコンテキストで動作するかを、停止日である2026年11月12日を期限として検証します。
• Astraを含む将来モデルがCursor経由では提供されないことを前提に、モデル選定を固定しない設計にします。1つのモデルや1つの経路に依存せず、複数モデルへの切り替えとフォールバックをコードレベルで用意し、Cursor以外の経路でもOpenAIモデルを利用できる構成を検討します。
• 契約と安全性を理由に供給が止まるパターンを前提に、利用規約の遵守と安全性の観点で自社SaaSの依存関係を点検します。大規模な利用を想定する場合は、カスタム契約や利用規約の変更が供給に影響することを織り込み、単一プロバイダへの依存度を下げる構成を検討します。
• OpenAIが開発者への移行支援を「全力で支援する用意がある」と述べているため、原典で示される後続の案内を一次情報で追い、具体的な移行支援が提示された場合に即時に対応できるようにします。Cursorとの約4年の協業に敬意を示す記述は、Cursor自体のプロダクト価値を否定するものではないため、Cursorを使い続ける場合でもモデル経路の変更で継続できるかを切り分けて判断します。

原典 Our decision on Cursor following its acquisition by SpaceX

2. Qwen3.8 27BをMac Studio M3 Ultraで実測 — Q4_K_M 17GBで約14tokens/s、1bit 6.7GBで27tokens/sとRAM要件を公開

要点 Qwen3.8-27Bは27.3Bパラメータのdenseモデルで、hybrid attention設計（GGUF上のアーキテクチャタグはqwen35）、画像と動画理解を含むmultimodal、262,144トークンのネイティブコンテキスト、Apache 2.0で提供されています。公式モデルカードではSWE-bench Proで61.7、GPQA Diamondで89.2と記載されています。著者は過去10日間、Mac StudioでRSSフィードの朝刊ダイジェスト化やスキャンしたPDFのリネーム・整理などの日常的な要約タスクをバックグラウンドアシスタントとして任せ、これまでで初めて放置しても信頼できるローカルモデルと評価しています。実測はMac Studio M3 Ultra（256GB unified memory）で、ollama run –verboseを用い、同一プロンプト・同一マシンでモデルごとに5回のtimed generationを実施し、200〜500語程度の技術的プロンプトで平均を取っています。両モデルともOllamaのデフォルトQ4_K_M quantでディスク上は約17GBです。結果は次のとおりです。Qwen3.8 27B（Q4_K_M, 17GB）はOllama経由で約14tokens/s（5回平均14.0 tok/s）、前世代qwen3.6:27bは同条件で約28.6tokens/sです。プロンプト処理は93.1 tok/s対95.0 tok/sでほぼ互角です。回答あたりのトークン数はqwen3.6が1,950〜3,340に対し、Qwen3.8は890〜1,090と約1/3で、例として2,058トークンを28.6 tok/sで生成すると72秒、955トークンを14.2 tok/sで生成すると67秒と、トークン単価では半速ですが壁時計では互角と示されています。実行時のばらつきはqwen3.6が28.5〜28.8で安定する一方、Qwen3.8は13.2〜15.4と幅があります。生成中はApple SiliconのMetal経由でGPUで実行され、macmonの計測でGPUは100%・63.95W、CPUは6W、Statsアプリでは60GPUコアが100%でシステム全体は291Wに達します。1bit quant（6.7GB）はllama.cppでプロンプト処理309 tok/s、生成27.2 tok/s（約27tokens/s）とQ4の約2倍で8GB未満のRAMで動作します。事実想起は良好でCanberraが首都であることとSydney-Melbourne間の妥協という背景を正確に答えますが、bashワンライナーを求めると動作するコマンドを生成した後に400トークンにわたり代替案を巡回し最終回答にコミットできないと示されています。RAM要件は32GBでQ4が快適に動作し、16GBでQ2が動作するとされ、quantごとのRAMテーブルが示されています。動作には過去数週間のllama.cppが必要で、古いビルドはunknown model architecture: ’qwen35’で失敗します。

なぜ重要か 32GBなら17GBのQ4が常用でき、16GBでもQ2で動作するという具体値が、ローカル運用の可否判断を可能にする点が重要です。生成速度はQ4_K_Mで約14tokens/sと前世代の28.6tokens/sの半分ですが、出力トークンが約1/3になるため壁時計では互角と示され、APIコストを避けて常駐の要約用途に回す採算判断が今日から下せます。1bit 6.7GBで27tokens/sという数値は8GB未満で動作する選択肢を示しますが、事実は正しくても回答にコミットできないという制約が明記されており、用途の切り分けが必要であることが示されています。

実践で使える点

• 手元のMacで試す場合は、OllamaのQ4_K_M（約17GB）を32GB以上のマシンで実行し、16GB環境ではQ2 quantを選択します。llama.cppを使う場合は過去数週間以内のビルドを用い、qwen35アーキテクチャに対応していることを確認します。
• RSSダイジェストやPDF整理のような日常的な要約タスクを常駐させる用途では、出力トークンが約1/3で壁時計が互角という特性を踏まえ、API呼び出しをローカルに置き換えた際のレイテンシとコストを実データで比較します。
• 1bit 6.7GBのquantを軽量用途で試す場合は、factual recallは維持される一方でbashワンライナーのような確定回答が必要なタスクでは400トークンにわたる逡巡が生じると報告されているため、確定出力が必要なワークフローではQ4を選択します。

原典 Run Qwen3.8 27B locally: real numbers from my Mac Studio

3. 脆弱性パッチの噂だけで10分後に自動プローブが到達 — コーディングエージェントがexploit発見を自動化

要点 Anil Madhavapeddy氏（Cambridge大学のcomputer science教授、OCaml compilerのコアメンテナ）が、OCamlプロジェクトのセキュリティ問題について、パッチが議論のために共有されてから数分以内にexploitの試行が見られたと報告しています。通常は数日かけて対応し1〜2週間以内のリリースが合理的とされる中、約10分でpercent-encoded traversal sequencesへのプローブが観測され、自動化されたwatcherが公開リポジトリを監視していることが示されたとしています。Modern coding agentsが非常に効果的になり、わずかなヒントだけで脆弱性を発見できるようになっており、Anil氏自身が自身のエージェントで実証し、Claude Fableがタスクを拒否した際にはDeepSeek V4 Proに切り替えて成功したと報告されています。Anil氏はこの発見速度が既存のオープンソースのembargo practicesと両立しないと指摘し、issueがこれほど速くexploitになり得るならコミュニティを安全に保つための新たなプロセスが必要だとしています。rcloneメンテナのNick Craig-Wood氏はHacker Newsのコメントで同様の問題を確認しており、rcloneプロジェクトでは最初の10年間でGitHub経由のセキュリティ開示が約20件だったのに対し、先月だけで40件以上に対応し、その対応にはAIツールによるトリアージとfix案作成を活用しても多大な時間がかかったとしています。ヒット率は約75%が何らか対応が必要な内容だったとしています。GitHubのCVE付与は以前は2〜3日だったものが現在は3〜4週間かかるため、CVE-PENDINGと記載してポイントリリースを出さざるを得ないとしています。

なぜ重要か 公開リポジトリでのパッチ議論が約10分で自動プローブに直結する速度で監視される現状が具体的に示されています。わずかなヒントからcoding agentがexploitを発見できることがAnil氏自身の実証で示され、従来のembargoを前提とした運用が両立しないと指摘されています。rcloneの事例では10年で約20件だった開示が先月だけで40件以上に急増し、約75%が対応を要する内容だったこと、CVE付与が2〜3日から3〜4週間に延びCVE-PENDINGでのリリースを余儀なくされていることが示されており、個人開発でSaaSを運用する場合も公開での議論や通常のリリースサイクルを前提にした依存管理では間に合わないリスクが明らかになっています。

実践で使える点

• セキュリティに関するパッチや議論を公開リポジトリで共有する際は、約10分でpercent-encoded traversalへのプローブが到達し得ることを前提に、非公開での共有とfix準備を優先し、従来の数日〜1〜2週間というembargo期間を前提にした運用を見直します。
• rcloneの事例のように開示が急増しCVE付与が3〜4週間かかる状況を踏まえ、CVE-PENDINGでのリリースも含めた即時対応のフローを用意し、AIツールによるトリアージとfix案作成をレビュー体制に組み込みます。
• わずかなヒントからcoding agentが脆弱性を発見できることを踏まえ、自身のSaaSの公開リポジトリや依存先の変更が公開された際の監視とパッチ適用を遅延させないアップデート運用を整えます。

原典 Just a rumour of a bug is enough to find a security exploit these days

4. Codex 0.151.0でMCPのgrace periodと拡張によるツール結果書き換えを追加 — 権限プロファイルとサンドボックスの不具合も修正

要点 Codex 0.151.0がリリースされました。新機能として、optionalなMCPサーバからツールを発見する際のgrace periodを設定できるようになりました（#41199）。拡張機能が、MCPツールの結果がモデルに到達する前に検査・置換できるようになりました（#41202）。プラグインカタログはリポジトリごとの設定を統合し、無効なproject marketplaceを報告しつつ有効なプラグインを隠さなくなりました（#41208）。バグ修正として、復元されたpermission profileをTUIターン間で保持し、/cdがサンドボックス制限を弱めることを防止しました（#41192）。モデル切り替えやフォールバック時にも、ツールの可用性とreasoning effortが正しく保たれるよう修正されています（#41195）。

なぜ重要か 任意のMCPサーバの起動レースによる失敗を抑えられる点が重要です。grace periodによりoptionalなMCPサーバのツール発見が安定し、拡張側でモデル到達前にツール出力を検査・置換できるため、自前のガードやログ整形を挟むワークフローを安全に組めます。permission profileとサンドボックス、モデル切り替え時の不具合修正も含まれており、日常的にCodexを運用する際の信頼性が向上します。

実践で使える点

• optionalなMCPサーバを利用している場合は、grace periodの設定を有効にして起動直後のツール発見失敗を抑えます。
• 拡張機能でMCPツール結果の検査・置換を活用し、モデルに渡す前に不要な出力を除去したり、ガード処理やログ整形を挟んだりするワークフローを検討します。
• /cdでのサンドボックス弱体化やモデル切り替え時のツール可用性に関する修正が含まれているため、最新版へ更新して権限周りの挙動を確認します。

原典 0.151.0

5. LLMの長期記憶をプログラム解析として再設計 — DatalogエンジンLemmalogで前提崩壊時の依存結論を自動無効化

要点 過去数か月にわたりLLMエージェントを脆弱性調査で使ってきた中で、数時間にわたる調査になるとモデルが確立した事実を見失い、既に棄却した手法を再提案したり、誤りと判明した前提に基づく推論を続けたり、もはや有効でない観測から自信を持って推論を続ける問題が示されています。LLMに何かが間違っていると伝えても、それに依存する信念を止めるとは限らないとしています。既存のmemory手法は古い会話や観測を保存しembeddingして関連する断片を再取得する方式で、一定の効果はあるものの、筆者は「何を言ったかを覚える」のではなく「現在何が分かっているかを維持したい」としています。例として、attacker controls object_a、object_a points to object_b、object_b is a kernel object から attacker can control a kernel object を導出できる一方で、2時間後にLLDBで object_a が object_b を指していないと判明すると、memoryには object_a points to object_b と attacker can control object_b と object_a does not actually point to object_b が混在し、取得した部分集合からLLMに正しさの判断を委ねることになると説明しています。これをプログラム解析と同じ構造と捉え、事実と規則から新たな事実を導出し、fixed pointを計算し、入力factが変われば影響を受けた結果だけを更新する手法に着想を得て、LLMの状態を毎回再構築させるのではなく維持すればよいのではないかと考え、LLM向けのDatalogエンジンを書いたとしています。Datalogは手続きではなくfactsとrulesを記述する宣言的な論理プログラミング言語で、controls(attacker, object_a).、points_to(object_a, object_b).、kernel_object(object_b). と、controls_kernel_object(Attacker) :- controls(Attacker, ObjectA), points_to(ObjectA, ObjectB), kernel_object(ObjectB). の規則で controls_kernel_object(attacker) を導出する例が示されています。points_to が誤りだった場合に、どの結論がその観測に依存しているかを正確に追跡して自動で無効化できる点が、古い情報をすべてpromptに入れてLLMに期待するより優れているとしています。Lemmalogでは役割を分離し、LLMが「LLDB shows that the freed object is later reused as the destination of the write.」のような自然言語・ソースコード・デバッガ出力を freed(object_a) や reused_as(object_a, write_target) のような構造化されたfactsへ変換するファジーな部分を担い、facts→rules→derived facts の決定論的な導出はデータベースが担うとしています。LLMは自然言語やコード、デバッガ出力の解釈が得意であり、一度構造化された後はモデルが繰り返し結論を導く必要はなくデータベースが担えるとしています。削除は追加より複雑で、a.、b.、c :- a.、c :- b. の例ではcが2つの独立した根拠を持つため、aだけを削除してもbが残ればcは残り、aとbの両方を削除したときのみcが消える必要があることが示されています。脆弱性調査では candidate_3_is_exploitable が別の独立した経路で支持されることがあるため、事実がどのように導出されたかを追跡してサポートを更新する必要があるとしています。この仕組みの副産物として、なぜ何かが真であるかを問えることが挙げられています。数時間エージェントを回して candidate_3_is_exploitable に到達した際に、attacker_controls_pointer（observation_41由来）と pointer_reaches_target（observation_57とrule_12由来）に依存するprovenanceの木で説明できる例が示され、observation_41が誤りならその結論が無効になり得ることをデータベースが自動で除去できるとしています。もともとはincremental evaluationを正しく行うために必要だったものの、AIエージェントが何を信じているかを問える点が有用であり、「we already established that this pointer is attacker-controlled」と自信を持って誤る失敗モードに対し、Lemmalogに結論が存在すればprovenanceを問え、存在しなければ維持された状態に含まれないことで検証できるとしています。ただし抽出時のhallucination自体は防げない旨も触れられています。

なぜ重要か 数時間の調査で前提が崩れたときに依存する結論まで自動で無効化でき、幻覚による堂々巡りを防げる点が重要です。埋め込み検索で関連断片を再取得してLLMに判断させる方式では、矛盾する観測が混在したまま正しさの判断をモデルに委ねることになり、長時間の推論で確立した事実が失われやすいことが示されています。Lemmalogのようにファジーな抽出をLLMに、決定論的な導出と真理維持をデータベースに分離するパターンは、脆弱性調査だけでなく長時間エージェントを回すSaaS開発のワークフローにもそのまま転用できるとしており、個人開発でSaaSを作るエンジニアが長時間の調査や複雑なコードベースの探索をエージェントに任せる際の信頼性を高める実装パターンとして判断材料になります。

実践で使える点

• LLMに全状態の再構築を毎回任せず、LLMは自然言語・ソースコード・デバッガ出力の解釈とfactsへの変換に限定し、facts→rules→derived facts の導出と無効化はDatalog側で維持する分離を検討します。
• 結論が複数の独立した根拠で支持されるケースを想定し、a、b、c :- a、c :- b の例のように片方の根拠が崩れても他方が残れば結論を維持し、すべての根拠が崩れたときのみ除去するサポート追跡をルール設計に組み込みます。
• provenanceの問い合わせを活用し、「we already established that this pointer is attacker-controlled」のような誤った確信が生じた際に、Lemmalog上にprovenanceが存在するかどうかで維持された状態に含まれているかを検証する運用を入れます。抽出時のhallucination自体は防げない点に留意します。

原典 I accidentally turned LLM memory into program analysis