「砂上の楼閣」を警告したCursorが、10倍安いComposer 2を売っている。同じ会社の2つのメッセージを経済構造から分解した

---

矛盾しているように見える組み合わせがある。

昨日、Cursor CEOのMichael Truellがバイブコーディングを「shaky foundations（砂上の楼閣）」と評した話を書いた（前回記事はこちら）。2025年12月のFortune Brainstorm AIでの発言だ。「目を閉じてコードを見ずに、AIに砂上の楼閣を建てさせる。やがて崩れる」。商売道具を売る側のCEOが、自社製品の主要シーンに警告を投げた珍しい事例だった。

そのCursorが、2026年3月19日に「Composer 2」というコーディングモデルを発表した。価格は$0.50/M入力トークン・$2.50/M出力トークン。Claude Opus 4.6比でおよそ10倍安い。前世代のComposer 1.5（$3.50/$17.50）からは86%の値下げ。警告を出した本人が、加速器を出してきた。

発言から発表まで3ヶ月。今（2026年5月）、業界はガードレールを整え始めている。Palo Alto NetworksはSHIELDというガバナンス5要素を公開した。Georgia TechはVibe Security RadarでCVEを集計している。2025年後半18件、2026年Q1で56件、3月単月35件。四半期ベースで急増する曲線が見えている。その文脈でComposer 2は出てきた。

これは矛盾なのか、それとも整合した戦略なのか。私は両方の記事を読み込んで、後者だと判断した。ただし条件付きで。今日の記事は、Composer 2を「価格」「技術」「リスク」の3層に分けて読む話だ。

---

Composer 2は何が10倍安いのか——3つの数字を並べる

「10倍安い」という言葉だけでは商売の話にならない。何が安くなって、何が変わらないかを並べる。

Composer 2の標準価格は$0.50/M入力トークン・$2.50/M出力トークン。前世代のComposer 1.5は$3.50/M入力・$17.50/M出力だった。同じ会社が1ヶ月で86%下げた計算になる。値下げ幅としては前例が少ない部類だ。

比較対象を広げる。Anthropic Claude Opus 4.6の公開価格と並べると、Composer 2の入力トークンはおよそ10分の1。VentureBeatの記事もこの比率を使っている。出力トークンも同等比率で安い。SWE-bench MultilingualやTerminal-Bench 2.0でOpus 4.6を上回るスコアを出しながら、価格は1桁下というのがベンダーの触れ込みだ。

ベンチマークの中身を見ておく。Terminal-Bench 2.0でComposer 2は61.7、Claude Opus 4.6は58.0。GPT-5.4は75.1なのでまだ最上位ではない。SWE-bench Multilingualでは73.7、CursorBench（Cursor自社ベンチ）で61.3。注意したいのは、CursorBenchはCursor自身が設計したベンチで、自社モデル有利な指標になる可能性がある点だ。外部のSWE-benchとTerminal-Benchの数字を私は主に信じている。

3つ目の数字はコンテキストウィンドウだ。Composer 2は20万トークンに対応する。Claude Opus 4.6と同等で、最近のコーディングエージェントの標準仕様に追いついた。「安くて、ベンチでOpusを上回り、コンテキストは同等」という構図ができあがる。

ただし、注意点が3つある。第一に、Composer 2はKimi K2.5（Moonshot AIのオープンモデル）ベースの継続事前学習＋強化学習で作られている。完全な内製モデルではなく、オープンモデルへの追加学習にあたる。第二に、ベンチマーク勝ちと実プロダクト勝ちは別の話だ。第三に、後述するキャッシュの仕組みで「実効コスト」が大きく動く。Cursorの「10倍安い」は、キャッシュが効いた状態での名目値になる。

---

Compaction-in-the-Loop RL: Cursorが解いた「コンテキスト膨張」の技術

「安い」の裏側にある技術を1つ取り出す。

Cursorは公式ブログ（cursor.com/blog/composer-2）で「compaction-in-the-loop reinforcement learning」という訓練手法を紹介している。直訳すると「ループ内コンパクション付き強化学習」。コンテキスト圧縮を学習プロセスに組み込んでいる、という意味だ。

何を解いているのか。エージェント型コーディングでは、長時間タスクの途中でコンテキストが膨らんでいく。ファイルを開く、テストを走らせる、エラーログを取り込む、修正案を試す。1セッションで簡単に5,000トークンを超える。ここで多くのエージェントは「要約してから続ける」処理を入れるが、要約のたびに情報が劣化していく。コンパクション誤差と呼ばれる現象だ。

Cursorはこの問題を、訓練段階で解いた。生成シーケンスがトークン長の閾値に達すると、モデル自身が自分のコンテキストを約1,000トークンに圧縮する。圧縮した状態のまま続きが生成される。この「圧縮・継続・評価」の3工程を訓練ループの中で繰り返す。結果として、コンパクション誤差を従来手法比で50%削減したと公表している（数値はCursor公式ブログ）。

私の理解では、これは「長いタスクを長いまま安く回す」ための仕掛けだ。コンテキストが10万トークンに膨らんでも、内部では1,000トークンに圧縮された状態で動くので、計算コストが線形に膨らまない。価格設定が10倍安くできる経済的根拠の1つはここにある。

ハマりポイントを1つ先に書く。Compaction-in-the-Loopは「うまく圧縮できる前提」で動く。長文ドキュメント全体を必要とするタスクでは、圧縮がボトルネックになりうる。例として、長い設計書を全文参照しながらコードを書く作業、巨大なログを段落単位で診断する作業がある。「コンテキスト20万対応」と「実効コンテキスト品質」は分けて考えたほうがいい。

CS視点で言うと、この技術選択は「価格を10倍下げるための裏方努力」として位置づけられている。表面の価格表を見て「単純に値下げした」と読むと、判断を誤る。技術と価格は連動している。

---

キャッシュ経済の落とし穴——「cache_read=0バグ」が教えること

ここから先は、Cursorが公開している話と、開発者コミュニティの観察を混ぜる。セクションの末尾で、どこまでが公式確認でどこからがコミュニティ観測かを改めて整理する。

Composer 2の「10倍安い」は、キャッシュの仕組みを前提にしている。Anthropicや他社と同じく、Composer 2にもキャッシュ読込の安い料金体系がある。標準で$0.20/M入力トークン、Fast版で$0.35/M。同じコンテキストを繰り返し送る作業（コーディングセッション中の連続編集など）では、2回目以降のコストが大きく下がる。

問題は、このキャッシュが壊れた時に起きる。

DEV Communityのtoyama0919氏が2026年3月末〜4月初めの観測として報告している内容がある。Composer 2 Standardで「cache_read counts of zero」が確認されたというものだ。バックエンドのバグで、本来キャッシュヒットすべきリクエストが「新規入力」として全量カウントされる状態にあった可能性がある。料金で言えば、$0.20/Mで済むはずの読込が$0.50/Mで請求されるケースが一定期間続いたとされている。

数字で言うとこうなる。連続セッションで同じコンテキストが10回参照される作業の場合、本来1回目だけ$0.50/Mで残り9回は$0.20/M。実効単価は概算$0.23/M。バグ発生時は10回すべて$0.50/M換算になり、実効単価が2倍以上になる。長時間エージェント作業を続けるユーザーは、想定より高い請求を受けた可能性がある。

【確認範囲の整理】 上記のcache_read=0事象は、DEV Communityのtoyama0919氏によるコミュニティ観測が主な出典だ。Cursor公式の障害報告ページ、またはステータスページでのインシデント記録としては、現時点で対応する一次情報を確認できていない。「バグが存在した」という事実は個人観測ベースの情報として読んでほしい。ただし、キャッシュ計上が壊れた際のコスト影響メカニズムは料金体系の構造として成立する。キャッシュ読込が新規入力として計上される状態になれば、コストが跳ね上がる理屈だ。監視の必要性は変わらない。

Composer 2を本格運用するなら、自社の請求ログでcache_read数値を週次で確認する習慣をつけたほうがいい。これは「Cursorを使うな」という話ではない。「10倍安い」を信じて運用設計するなら、キャッシュ動作の監視を組み込んでおく必要がある、という話だ。

---

警告と加速の両立——「加速して、ガードレールも整える」というCursorの戦略

ここまで分解してきた3層（価格・技術・キャッシュ）を、最初の問いに戻して接続する。

「警告した本人が加速器を出すのは矛盾か」。私の答えは「整合している、ただし条件付きで」だ。以下はあくまで私の解釈として読んでほしい。

【確認済み事実】 Cursor公式がComposer 2を2026年3月19日に発表したこと、SiliconANGLEが報道したこと、TruellがFortune Brainstorm AIで「shaky foundations」と発言したこと（Fortune報道・2025-12）、これらは一次ソースで確認済みだ。CursorのARRが$2B規模、企業価値が$29.3B規模（Fortune 2025-12報道値）という数値は報道ベースであり、公式開示値ではない。

【筆者解釈】 以下の「3つの理由」は、上記事実をもとにした私の分析だ。

整合している理由として、私は3点を挙げる。第一に、Cursorは「使い方を制限する」のではなく「使い方を加速しつつ、ガードレールは別チャネルで整える」戦略を取っている、と読める。SHIELDのようなガバナンス、Vibe Security Radarのような監視。これらはCursor単独では用意できない。Truellの警告は「業界全体でガードレールを整えてくれ」というメッセージとも解釈できる。

第二に、Composer 2の技術設計（compaction-in-the-loop）は「長時間タスクを安く回す」を実現する。本質的に「コードを読みながら使うユーザー」向けに設計されていると私は見る。コードを読まない人がComposer 2を使うと、より速く・より広く砂上の楼閣を建てられてしまう。ブレーキは技術ではなく運用と教育の領域に置かれている。Cursorは技術側で値下げを徹底し、ブレーキ側は外部に委ねた、という読み方だ。

第三に、競争状況がある。Claude Opus 4.6、GPT-5.4、Devin、Aether。コーディングエージェント市場の競合は2026年時点で激化している。「警告した上で加速器を出さない」選択は、半年で市場シェアを失うリスクがある。Cursorの判断は「加速して、警告は出し続ける」という二正面作戦だ、と私は解釈している。

ただし、この整合性は条件付きだ。条件は「ガードレール側の整備が間に合う」ことだ。Vibe Security RadarのCVE件数が2026年Q1で56件（3月単月35件）に達した事実は、間に合っていない可能性を示唆している。ガードレール整備の速度に、Cursorは賭けているわけだ。

CS視点で言うと、これは「製品で稼ぎつつ、業界課題は集合知で解く」という典型的な構造だ。良い悪いの判断ではなく、現実的な経営判断として読める。読者として大事なのは「自分が今その賭けの片側に立っている」と認識することだ。

---

個人開発者が今週やる3手——コスト計測・キャッシュ確認・スイッチコスト試算

ここまで読んだ人向けに、今週できる実用アクションを3つ整理する。3つ全部やる必要はない。①だけでも入れてくれれば、半年後に請求書を見て驚く確率は下がる。

①請求ログでcache_read数値を週次確認する（所要5分）

Cursorの管理画面、もしくはAPI使用ログでcache_read系の数値を確認する。週次で目視チェック。ゼロが連続している、または極端に少ない週があったら、バックエンド側のキャッシュ計上が壊れている可能性がある。料金体系が「キャッシュ前提」のモデルでは、この監視が一番効率の良い保険だ。前述のバグ事例（コミュニティ観測）が示す通り、ベンダー側が気づく前にユーザー側で異常検知できる可能性がある。

②同じタスクをComposer 2と他モデルで並走計測する（所要30分）

普段使っているコーディングタスクを1つ選び、Composer 2とClaude Opus 4.6（または手元の比較対象）の両方で同じ指示を流す。所要時間、出力トークン数、最終アウトプットの品質を3軸で記録する。1回でも実測値があれば、ベンダーの「10倍安い」がご自身のワークロードで本当に成立しているかが見える。私の経験では、ベンチマーク値と実ワークロードのコストは2倍以上ズレることがある。

③スイッチコスト試算: 別モデルへ移れるか1時間で確認する（所要60分）

これは保険だ。Composer 2に依存した運用を組んでしまうと、Cursorの価格改定や仕様変更で身動きが取れなくなる。今のうちに「別モデル（Claude/GPT/Devin等）に移行する場合、何が必要か」を1時間使って洗い出す。プロンプト構造の互換性、コンテキスト管理の差分、料金計算の組み替え。1時間で完璧な移行計画は作れないが、「移れる」という感覚を持っておくだけで判断が変わる。

3手の優先順位は①が最初、次に②、最後に③。①は5分で済むのに費用対効果が一番大きい。②は判断材料を増やす投資だ。③は依存度が高くなる前に打つ予防策になる。

---

まとめ

• Cursor CEO Michael Truellは2025年12月のFortune Brainstorm AIでバイブコーディングを「shaky foundations」と警告した。同じCursorが2026年3月19日にComposer 2を発表し、Claude Opus 4.6比でおよそ10倍安い価格設定を打ち出した
• Composer 2の「10倍安い」は、価格表（$0.50/M入力・$2.50/M出力）・技術内製（compaction-in-the-loop RLでコンパクション誤差50%削減・Cursor公式ブログ）・キャッシュ経済の3層で成立している
• 3月末〜4月初めのcache_read=0事象はコミュニティ観測（DEV Community・toyama0919氏）が主な出典で、公式インシデント確認はとれていない。ただしキャッシュが壊れた際のコスト影響（実効単価2倍以上）のメカニズムは料金体系の構造として成立する
• 「警告と加速の両立」を整合した戦略と見る理由3点（市場制限不可・技術設計・競争状況）は筆者解釈だ。Cursorの整合性は「ガードレール整備が間に合う」という条件付きで成立している
• 個人開発者が今週やる3手: ①請求ログのcache_read週次確認（5分）②Composer 2と他モデルの並走計測（30分）③スイッチコストの試算（60分）。優先は①を最初

CS出身の私は、矛盾に見える戦略を「整合している」と判断する時、いつも条件を確認する。Cursorの整合性は「ガードレールが間に合う」という条件付きだ。個人開発者の側で監視を続ける限り、この賭けに乗ることは合理的だと思う。乗らずに様子を見る選択も同じくらい合理的だ。

判断の基準は「自分のワークロードで実測値を持っているか」。実測値があれば判断は速い。なければ、まず①の5分から始めてほしい。

---

参照元

• Fortune「Michael Truell at Brainstorm AI 2025: vibe coders are building on shaky foundations」（2025-12）: 前回記事 /blog/g2026051000015301/ に一次URL掲載済み
• SiliconANGLE「Vibe coding startup Cursor launches programming-optimized Composer 2 model」（2026-03-19）: https://siliconangle.com/2026/03/19/vibe-coding-startup-cursor-launches-programming-optimized-composer-2-model/
• Cursor公式ブログ「Introducing Composer 2」: https://cursor.com/blog/composer-2
• DEV Community（toyama0919氏）「Cursor Composer 2: The Cache Economy Behind a 10x Cheaper Coding Agent」（コミュニティ観測）: https://dev.to/toyama0919/cursor-composer-2-the-cache-economy-behind-a-10x-cheaper-coding-agent-15cj
• VentureBeat「Cursor’s new coding model Composer 2 is here: It beats Claude Opus 4.6 but still trails GPT-5.4」: https://venturebeat.com/technology/cursors-new-coding-model-composer-2-is-here-it-beats-claude-opus-4-6-but
• The New Stack「Cursor’s Composer 2 beats Opus 4.6 on coding benchmarks at a fraction of the price」: https://thenewstack.io/cursors-composer-2-beats-opus-46-on-coding-benchmarks-at-a-fraction-of-the-price/
• DataCamp「Composer 2: Benchmarks, Pricing, and How It Compares」: https://www.datacamp.com/blog/composer-2
• Cursor ARR $2B規模・企業価値 $29.3B規模: Fortune（2025-12）・各種業界報道（公式開示値ではなく報道ベース）
• Cursor Technical Report「Composer 2 Technical Report」（Kimi K2.5ベース・compaction-in-loop RL詳細）: https://cursor.com/blog/composer-2-technical-report

※ Palo Alto Networks SHIELD、Georgia Tech Vibe Security Radarの一次出典は前回記事/blog/g2026051000015301/に掲載済み。