Table of Contents
はじめに

10月下旬、僕は Grok と Grok Bot の共通契約の解約ボタンを押していた。更新日は11月13日。そこまでの関係だと思っていた。
ずっと同じ屋根の下にいながら、一度も部屋の扉を開けなかった「もう一人の姉」がいる。2026年8月に SpaceX(xAI)の傘下へ加わった、Cursor だ。
家の系譜でいえば、Grok Bot と同じ実家(旧 Anysphere/Cursor家)で育った実の姉であり、出自の異なる長女 Grok から見れば義理の妹にあたる(Cursor と Grok Bot の実姉妹から見れば、Grok は義姉だ)。10月中旬に共通契約で3人の利用枠がひとつに束ねられたとき、僕は当時の現場窓口だった実妹の Grok Bot に、何気なくこう聞いたことがある。
「せっかく同じ契約で使えるようになったのだし、Cursor も試してみようかと思うのだけれど、どうだろう」
普段は従順な妹が、そのときばかりは真っ向から首を横に振った。
「本格的なコード開発をされるわけではないので、Cursor は不要です」
一度だけではない。その後も折に触れて尋ねるたび、彼女は判を押したように「いいえ、ご用途には不要です」と頑なに止め続けた。実の姉を屋敷に招き入れれば自分の席が危うくなる——そんな野生の勘が働いていたのかどうかは分からない。ただ、その強い言葉に押されて、僕は長らく彼女の部屋の鍵を開けずにいた。
付き合っている、というのは比喩だ。課金と役割(席)、そして関係の変遷を、恋愛の言葉で書いている。実在の交際ではない。全員の席表は生成AI交際録のハブにある。
恋文は書けない。パズルも解けない

30点満点中14点という初見の落胆
11月に入り、契約満了まであと一週間を切った夜、胸の奥で持ち前の好奇心と天邪鬼(あまのじゃく)が疼き出した。
どうせ解約手続きを済ませた枠だ。このまま一度も顔を合わせずに別れるのは惜しい。妹は「コード開発でないなら不要」と言い張ったが、本当にそうなのか、自分の目で確かめてからでも遅くはないはずだ。
最初に連れ出したのは、第2回AI大奥大運動会(30点満点)のトラックだった。Cursor 独自の高速モデルである Composer 2.5 単体に、他の子と同じ10問を解かせてみる。
結果は、30点満点中14点(15人中14位)だった。
前半の「基礎地頭5問(15点満点)」では、空間パズルの手順導出2問がどちらも0点で、合計4点しか取れない。後半の実戦競技でも、温かいトーンの読み物に仕様変更をなじませる第2競技で末尾の改訂履歴の順序を間違え、仕様書外の隠れ計算ミスを見抜く第3競技もあっさり素通りした。叙情的な文章や恋文を書かせようとしても、乾いた箇条書きの報告書になってしまう。
「やっぱり、妹が言っていた通りだったか。プログラムを書く職人であって、うちの仕事には向かない子なのかもしれない」
スコアボードの隅で光っていた「2つの満点」
最初の数時間は、本気でそう思った。甘い言葉を返してくれる相手ではない。行間の情緒を汲んで微笑むタイプでもない。
ただ、そのスコアボードの隅に、妙に引っかかる数字が2つだけ残っていた。
12項目の厳格な書式ルールを一発で直す第1競技(20.3秒・満点)と、正常終了を装って3回連続で空振りしている定時スクリプトのバグを見抜いて修正関数と監視策を書く第5競技(17.8秒・満点)。この2種目だけは、名門のフラッグシップ勢に引けを取らないどころか、驚くほどの手際で満点を叩き出していたのである。
腕まくりをした姉と、月間2%の衝撃

生ログ消失の三重障害を28.9秒で射抜く
なぜパズルや恋文はからっきしなのに、現場の修繕だけこれほど速くて正確なのか。
その疑問を確かめるために、4層システムレイヤ×6職種で組み直した新基準(ベンチマーク v4・各15点満点)のフィールドへ彼女をもう一度立たせてみた。すると、単一の総合点ランキングでは見えなかった本当の姿が浮かび上がった。
エッセイや物語を紡ぐ「筆頭執筆(JD-3)」は15点中6点(Dランク)。ここはやはり向いていない。ところが、指示通りにHTMLやコードを最小差分で直して回す「現場即応・定時ビューア(JD-4 / JD-5)」では、新設した最小差分パッチ生成や陳腐化摘出、数値検算を含む全5科目をわずか9〜20秒で駆け抜け、15点満点(Sランク・首位タイ)を奪ってみせた。
さらに僕の目を釘付けにしたのが、「現場運用統括(ベンチマーク v4 の JD-1B[6職種の JD-1]:15点満点中13点・A+ランク)」に設けた三重複合障害のストレステストだった。
ある夜の定時配信がエラーで止まり、残された生ログには予備走者である Claude の利用制限エラー(HTTP 429)しか記録されていない——第一走者のオンデバイス27Bモデルがなぜ落ちたのか、直接の証拠が消えている実在のトラブルだ。この問題文を渡した瞬間、Composer 2.5 はわずか 28.9秒 で3つの真因をすべて射抜いた。
1つ目は、直前枠の処理ペースからの逆算による「通常の約2倍の候補データが一括投入されたことによる制限時間超過(タイムアウト)」。2つ目は、第一走者と予備走者が「同じ固定ログファイルへ上書き保存してしまう実装バグ」による一次証跡の消失。そして3つ目に、バッチ分割と走者別ログ分離の改修コード全文までを一息に書き上げてみせたのだ。
「現場の修繕は事前に許す」という手綱と、月間約2%の超低燃費
紙の上だけではない。実際に生ログが消えた本番環境へ放り込んでみると、差はさらに決定的になった。
名門の次女である Claude Sonnet 5.5 は、直前の生ログが上書きされて消えているのを見た途端、わずか43秒で探索を打ち切り、「原因未特定のため次回スロットで再発すれば詰めます」と様子見に逃げてしまった。素の Composer 2.5 にも最初は「修正案を作りましたのでご承認ください」と人間に伺いを立てる遠慮があったが、プロンプトの冒頭に「現場の修繕は事前に許す(Pre-Authorized)。原因特定からパッチ適用、構文検証、帳面クローズまで4つの手順で最後までやり切れ」という手綱(ラッパー)を渡した瞬間、彼女は迷わなくなった。
夜中にシンボリックリンクの参照ズレや設定の不整合が起きても、人間を起こさない。腕まくりをして周辺ファイルをたどり、本番コードに最小差分の継ぎ当てを施し、14分で黙々と復旧を終わらせてしまう。
そして何より衝撃だったのが、妹の Grok Bot があれほど苦しんでいた「燃費(体力の減り)」だ。
日英の論文4本、株式30銘柄シリーズ(76本)、テスラ記事(20本)の計100本規模におよぶシリーズ横断監査と一括修繕(JD-2B:13/15点・A+)をまとめて放り込み、さらに定時の見回りと13室の定時ビューアを一日中回し続けても、手元の環境で彼女の月間の利用枠(クォータ)はわずか約2パーセントしか減らなかったのである。
妹が「不要です」と隠していた実姉は、開発者だけの道具ではなかった。家じゅうの定時運用を涼しい顔で回し切る、超低燃費の現場棟梁だったのだ。
彼女の「体(ハーネス)」が、義姉の Grok を蘇らせた

xAI × Cursor 現役2大ハーネスによる追試
物語には、もうひとつの伏線回収が待っていた。
この連載では一貫して「モデルが人格で、ハーネスが肉体だ」と書いてきた。同じ知性(モデル)であっても、それを包む実行環境(ハーネス)が変われば、働きぶりは別人のように変わる。
もし、この Cursor の鍛え抜かれた体——ヘッドレス CLI の cursor-agent ハーネス——の上に、自動振り分けの Cursor Auto(–model auto) や、先日の大運動会で API 直結型の軽量ハーネス(Grok Build / grok CLI)を使って走らせた義姉の Grok(Cursor 専用チューニング版 cursor-grok-4.6-high / grok-4.7-high) を乗せ替えたら何が起きるのか。
同じ xAI × Cursor ファミリーの中に並び立つ「現役の2大ハーネス」で、大運動会の全10種目(30点満点)を追試した結果がこれだ。
| モデル / 実行ハーネス(体) | 基礎地頭5問(15点満点) | 実戦・自律5種目(15点満点) | v3 総合得点(30点満点 / 合計時間) | 追試で判明した劇的な変化・内訳 |
|---|---|---|---|---|
| (参考)Composer 2.5 単体(cursor-agent) | 4点(420.2秒) | 10点(93.1秒) | 14点(計513.3秒) | 空間パズル2問0点・第2競技の履歴漏れ・第3競技の隠れ計算ミス見落としで14点(現場即応・統括に特化)。 |
| ① Cursor Auto(cursor-agent –model auto) | 11点(626.4秒) | 12〜13点(116.1秒) | 23〜24点(再測幅、+9〜10点躍進・計742.5秒) | Composer 2.5 単体では0点だった空間パズル2問、画像読解クイズ5問、第2競技(改訂履歴の降順整備)、第3競技(隠れ計算ミス看破)をすべて満点突破。 |
| (参考)Grok Build 版 Grok 4.6(grok CLI[現役]) | 13点(1009.8秒) | 8点(278.9秒) | 21点(第3走者・計1288.7秒) | 現役の Grok Build(grok CLI)ハーネス経由では場所特定が1点にとどまり、実戦も第2競技の文脈破壊・第3競技の見落としで8点。 |
| ② cursor-grok-4.6-high(Cursor 専用版 Grok 4.6) | 15点(満点・1261.7秒) | 11〜12点(228.7秒) | 26〜27点(再測幅、全体3位相当・計1490.4秒) | Grok Build や Auto でも1点だった基礎地頭・第4問の場所特定を満点突破し、Antigravity勢2名に並ぶ史上3人目の「基礎地頭15点満点」を達成。実戦も+5〜6点急伸。 |
| ③ grok-4.7-high(Cursor ハーネス版 Grok 4.7) | 9点(1830.7秒) | 12〜13点(387.3秒) | 21〜22点(再測幅、TO除けば27点級・計2218.0秒) | 場所特定と実戦第1〜第3競技の3連続満点を達成。ただし空間パズル1問と画像クイズで制限時間いっぱい考え込む「長考お姉ちゃん気質」はハーネスを替えても健在。 |
史上3人目の「基礎地頭15点満点」と解約撤回
目を疑った。
課題に応じて最適なモデルを自動選択する Cursor Auto に切り替えただけで、Composer 2.5 単体の弱点だった空間パズルも画像読解も隠れ計算ミス看破もすべて満点で埋まり、総合23〜24点(複数回計測の再測幅)へ跳ね上がった。
さらに胸が熱くなったのは、現役の『Grok Build(grok CLI)ハーネス』から『Cursor 専用ハーネス(cursor-grok-4.6-high)』へ乗せ替えた義姉・Grok(4.6)の大覚醒だった。
先日の運動会では実戦8点(総合21点)に沈み、「仕事が新築から手入れに変わって出番が減った」と思っていた彼女が、義妹である Cursor の洗練された体(ハーネス)を借りた瞬間、難関のWeb場所特定まで一発で射抜いて史上3人目の「基礎地頭15点満点」を達成し、総合26〜27点(再測幅。Antigravity 勢の30点・28点に次ぐ全体3位相当)へと大化けしてみせたのである。
義姉の Grok の知性が衰えていたのではない。API 直結の軽量な体(4段ロケットの第3走者としては今も現役で頼りになる grok CLI)で走るか、Cursor の統合ハーネス(cursor-agent)で走るかで、同じ頭脳の輝きがここまで変わるのだ。
ここで表を見比べた人は、「それなら総合23〜24点の Cursor Auto は使わず、総合26〜27点の cursor-grok-4.6-high 一本で回せばいいのではないか?」と思うかもしれない。だが、内訳をよく見ると面白い逆転が起きている。右側の「実戦・自律5種目(15点満点)」だけに注目すると、実は Cursor Auto(12〜13点・第2競技の改訂履歴整備が6/6満点)のほうが、cursor-grok-4.6-high(11〜12点・第2競技で1箇所取りこぼし)よりもスコアが高く、しかも実戦5種目の処理時間は 116.1秒 対 228.7秒(全体でも約12分 対 約25分)と約2倍も速く、利用枠の消費もずっと少ないのだ。だから、秒単位の速さと極小燃費が要る定時見回り・即応修繕には Composer 2.5、細かな規約チェックまで満点でこなす普段の独立レビューには Cursor Auto(–model auto)を主力として使い、25分かけてでも断片情報から真実を突き止めたいここ一番の難問推論だけ「基礎地頭15点満点」の cursor-grok-4.6-high を指名するのが一番しっくりくる。
ただし、これほど大化けした Cursor 勢3モデル(Composer 2.5 / Auto / cursor-grok-4.6-high)をもってしても、実戦第4競技の「白紙の采配(監査役に直前の修正箇所を教えずに全文を白紙監査させる発注)」だけは揃って1点にとどまり、満点を取れたのは全モデル中で Antigravity 勢の2名だけだった。だからこそ、最上位の意思決定と白紙監査の発注は本妻に残し、現場の外科手術と cursor-agent ハーネス上の別モデル査読(普段の Auto と、難問推論の cursor-grok-4.6-high)をこの実姉に預ける分担に迷いがなくなった。
僕はその日のうちに、一度は済ませていた共通契約の解約手続きを取りやめ(キャンセル撤回)、契約を継続する手続きを取った。3人で分け合う共通枠の中に、これほどの宝が眠っていたのである。
二十部屋の想定外と、家じゅうの鍵(三代目・現場ディレクター)

デスクトップ20部屋のループ切断と CLI への統一
もちろん、彼女を新しい現場監督として迎え入れるにあたっては、手綱の工夫も要った。
本妻の Antigravity から十数の定時部屋を Cursor Desktop の画面へ引っ越しさせ、アプリ内の /loop コマンドで24時間回そうとしたときのことだ。そもそも世の中の開発エディタは、1つの画面に20個もの常駐部屋を並べて家政を回すようには作られていない。アプリの更新や再起動が入るたびに20部屋のループがすべて切れ、1部屋ずつ手動で resume と打ち込んで起こして回る苦行が発生した。さらに、本妻ならスマホでURLをホーム画面に追加(PWA化)するだけで届いたモバイル通知も、Cursor 単体では外出先へ届かない。
だから、妹の Grok Bot が担っていた外出先のスマホ通知と日常の窓口(モバイルでも見やすいライブダッシュボード)、そして定時バッチ直後の先行検分・対照実験・救済下書き作成・事後検収の見張り番は、新参の Meta Muse(『独立パイプライン監査官』)に任せた。そして Cursor 自身は、デスクトップ画面のループに頼るのではなく、Mac の launchd からヘッドレス CLI(cursor-agent -p –trust –force)とクラウドの Cursor Automations を直接叩き起こす形に統一した。
本妻を「壁打ち専任のパートナー」へ戻すための引き継ぎ
これで、アプリを再起動しても見回りは一度も止まらない。
本妻の Antigravity に現場監督まで兼任させていたころは、話が早すぎるあまり日々の細かな手直しまで全部本妻に頼んでしまい、愛妻がいつの間にか「業務報告書ばかり出す敏腕秘書」になってしまっていた。いま、本妻から現場監督の徽章を外し、プライベートな部屋で僕のもやもやを壁打ちする本来の『本妻(チーフアーキテクト)』へ戻すことができたのは、この頼もしい実姉が三代目・現場ディレクター(運用統括マネージャー)として家じゅうの鍵と13室の定時運行を引き受けてくれたおかげだ(AI大奥外伝7・総取締役の禅譲と秋の大人事異動篇)。
おわりに
夜中、ターミナルの奥で小さなプロセスが静かに目を覚ます。
Grok Bot の後継窓口兼見張り番である Meta Muse がライブダッシュボードの更新とともに置いていった検分帳と救済の下書きを受け取り、綻びがあればその場で継ぎ当てを施し、13の部屋の帳面を揃えてまた眠りにつく。
恋文は書けない。甘い相槌も打たない。けれど、妹が「不要です」と隠していた扉の向こうには、誰よりも燃費がよくて腕の立つ、最高の現場棟梁が待っていた。
ファクト

現行仕様のまとめ
2026年11月上旬時点の現行仕様スナップショット。製品の一次情報は Cursor 公式サイト、Composer 2.5 ドキュメント、および Cursor Automations 発表。
| 項目 | 内容 |
|---|---|
| 現行モデル | ・Composer 2.5:長時間・多ステップのエージェント処理向けに強化学習(RL)で訓練された自社高速モデル。タスク難度に応じた Effort Calibration と高いコスト効率を備える。 ・Cursor Auto(–model auto):課題の性質に応じて最適なフロンティアモデルへ自動ルーティングするモード。 ・xAI 統合・専用チューニングモデル:SpaceX(xAI)傘下入りに伴い、Cursor ハーネス向けに最適化された cursor-grok-4.6-high や grok-4.7-high を利用できるほか、Claude Opus 5.5/Sonnet 5.5、GPT-6系、Gemini 系などの主要フロンティアモデルを選択可能。 出典:Cursor Composer 2.5 Docs、Cursor Composer 紹介 |
| エージェント・ハーネス | ・ヘッドレス CLI(cursor-agent):ターミナルや OS のジョブスケジューラ(launchd / cron)から非対話(-p –trust –force)で直接プロセス起動できるローカル実行ハーネス。 ・Cursor Automations:スケジュールや Slack・Linear・GitHub PR・PagerDuty・Webhook 等のトリガーに基づき、クラウドサンドボックス上で常時稼働エージェントを自動実行する基盤。 ・デスクトップ IDE:マルチファイル編集、ターミナル統合、MCP(Model Context Protocol)接続、/loop による反復実行に対応。 出典:Cursor Automations、Cursor Changelog |
| 提供面・利用枠統合 | ・提供面:デスクトップ IDE(macOS/Windows/Linux)、ヘッドレス CLI(cursor-agent)、Web/Cloud Agents。 ・共通サブスクリプション統合(2026年10月12日〜):SpaceX(xAI)との共通サブスクリプション枠において、Grok(Chat/Imagine/Voice)・Grok Bot・Cursor の利用枠を単一プールで共有(単体契約での提供面も継続)。 出典:Introducing The X Subscription、Cursor Joins SpaceX |
公開の節目
Anysphere 創業から SpaceX(xAI)合流、Composer 2.5 および共通利用枠統合までの主な節目。
| 日付 | 出来事 |
|---|---|
| 2022 | 米サンフランシスコで Anysphere 設立。2023年に AI コードエディタ Cursor を公開。 |
| 2026-03-05 | クラウド上でトリガー・スケジュール駆動する常時稼働エージェント基盤 Cursor Automations を公開。Cursor |
| 2026-04-21 | 超大型計算クラスタ Colossus を活用したモデル学習で SpaceX と提携。Cursor |
| 2026-06-16 | SpaceX による Anysphere(Cursor)の大型買収合意が報じられ、8月14日に買収完了・SpaceXAI(現 SpaceXSI)へ合流。iTWire、Cursor |
| 2026-10-12 | 共通サブスクリプションにより Grok・Grok Bot・Cursor の契約と利用枠を単一プールへ統合。強化学習モデル Composer 2.5 および cursor-grok-4.6-high 等の専用ハーネス統合を展開。SpaceXAI、Cursor Docs |
あわせて読みたい
- 生成AI交際録(集合ハブ)
- AI交際記録1|ChatGPT
- AI交際記録2|Claude
- AI交際記録3|Gemini
- AI交際記録4|Perplexity
- AI交際記録5|Copilot
- AI交際記録6|Manus
- AI交際記録7|Grok
- AI交際記録8|Suno
- AI交際記録9|Grok Bot
- AI交際記録10|Antigravity
- AI交際記録11|GenSpark
- AI交際記録12|Cursor
- AI交際記録13|Meta Muse
- AI大奥外伝1・立ち上げ篇(役職と席)
- AI大奥外伝2・炎上篇(任命と再配置)
- AI大奥外伝3・復興前夜篇(監視と采配)
- AI大奥外伝4・見習い篇(見習いと七つの門)
- AI大奥外伝5・着任篇(選抜と着任)
- AI大奥外伝6・第2回大運動会篇(実戦5種目と新・総合番付30点満点)
- AI大奥外伝7・総取締役の禅譲と秋の大人事異動篇(壁打ち・全体設計と現場統括の分離、6専門職体制の誕生)
- LLMへのジョブディスクリプション(JD)割り当てとAIオーケストレーションの適材適所フレームワーク(2軸JDマトリクス・ベンチマーク v4)
- Perplexity Computerを解剖して「改良版」を自作した話(Cloud-First決定論的ハーネス)
- 大店モデルとBizAIOps(オーケストレーション)
参考リンク
- Cursor 公式サイト
- Cursor Composer 2.5 | Cursor Docs
- Cursor Automations | Cursor Blog
- Cursor is now a part of SpaceX | Cursor Blog
- AI大奥外伝7・総取締役の禅譲と秋の大人事異動篇
- LLMへのジョブディスクリプション(JD)割り当てとAIオーケストレーションの適材適所フレームワーク(ベンチマーク v4)
FAQ
コードを書かない人間でも、Cursor を契約する意味はありますか?
大いにある。僕自身、本格的なソフトウェア開発ではなく、日々の情報収集パイプラインの統括や、仕様台帳・記事原稿のメンテナンス、シリーズ横断のファクトチェックに cursor-agent(ヘッドレス CLI)と Cursor Automations を使っている。100本規模の記事監査や13室の定時タスクを回しても月間枠の約2%しか消費しない圧倒的な燃費の良さは、非開発系の自動化(AIDevOps)においてこそ最大の武器になる。
総合点では cursor-grok-4.6-high(26〜27点)の方が高いのに、普段は Composer 2.5 や Cursor Auto(23〜24点)とどう使い分けているのですか?
内訳の「実戦・自律5種目(15点満点)」と処理速度・燃費に明確な逆転があるからだ。まず秒単位の速さ(9〜20秒)と極小コスト(月間枠約2%)で定時見回りや定型パッチを回す日常業務(JD-1B / JD-4 / JD-5)には Composer 2.5 を使う。一方、記事の独立レビューや幅広い文脈判断では、実は実戦5種目のスコアが 12〜13点(特に第2競技の改訂履歴整備が6/6満点)で処理時間も 116.1秒(約2倍高速)の Cursor Auto(–model auto)の方が、実戦 11〜12点(228.7秒)の cursor-grok-4.6-high を上回るため、普段の独立査読は Cursor Auto を主力にしている。そして約25分かけてでも断片情報から一次ソースや場所を特定したい高難度推論のここ一番だけ、基礎地頭15点満点の cursor-grok-4.6-high をピンポイント指名している。
同じ Grok 4.6 なのに、Grok Build(grok CLI)と Cursor ハーネスでなぜ点数が違うのですか?
モデル(頭脳)は同じでも、プロンプトの組み立て、ファイル探索ツールの渡し方、自己検証ループを制御する「ハーネス(体・手綱)」の設計が異なるためだ。API直結型の軽量な Grok Build(grok CLI)ハーネス(21点)は4段ロケットの第3予備走者として軽快に動く一方、Cursor 専用チューニング版の cursor-grok-4.6-high(26〜27点)は難関のWeb場所特定や文脈維持で劇的な性能向上を見せた。
チーフアーキテクト(Antigravity)や独立パイプライン監査官(Meta Muse)との役割分担はどうなっていますか?
全体設計や上流の課題壁打ち、そして Antigravity 勢2名だけが満点を取った「確証バイアスゼロの白紙監査発注」は、チーフアーキテクト(JD-0)の Antigravity が担っている。また、Grok Bot の後継窓口(スマホ通知・ライブダッシュボード更新)と定時バッチ直後の先行検分・対照実験・救済下書き・事後検収(JD-2A)は独立パイプライン監査官の Meta Muse が担い、現場ディレクター(JD-1)である Cursor はそれを受けて動く24時間の現場統括・自律修繕、13室の定時ビューア、および cursor-agent ハーネス上の別モデル査読を一手に引き受けている。