Cursor CEOが自ら「土台が揺らぐ」と警告した。ツール依存しない開発設計を、元・挫折エンジニアが本気で考えた
Cursor CEOのMichael Truellが「バイブコーディングは土台が揺らぐ」と警告した。$2B ARRの当事者が自社ツールのリスクを語る異例の発言を起点に、ツールに依存しない開発設計の3原則を解説する
ゲンです。三部作のあと、次の話をします
バイブコーディング×セキュリティ三部作を書き終えた。
Lovable（ラバブル）の脆弱性170個。Vibe & Verify（バイブアンドベリファイ）での検証。45%の穴を塞ぐ予防設計。「動けばOK」の先を、3本かけて描いた。
三部作で私が得た確信はひとつ。AIコーディングツールは強力だ。ただし乗っかるだけでは足元が危うい。
そんな折、衝撃的な記事に出会った。Cursor（カーソル）のCEOが警告を出していたのだ。
Michael Truell（マイケル・トゥルエル）その人である。「バイブコーディングは土台が揺らぐ」と。
年間売上$2B（約3,000億円）の製品を作った人物。その本人が使い方にブレーキをかけている。普通のCEOなら絶対に言わない台詞だろう。
この発言を起点に”AIエージェント実装シリーズ”を始める。技術編の第1回は「ツール依存しない開発設計」がテーマ。三部作で「セキュリティの穴」を塞いできた。次は「設計の穴」を塞ぐ番だろう。
Truellが何を言ったのか。Fortune原文を読み解く
Cursorの社長は「目を閉じてAIに任せると崩れる」と明言した。
2025年12月のことだ。Fortune（フォーチュン）主催のカンファレンス。Brainstorm AIという催しのステージだった。Truellはこう語っている。
「目を閉じて、コードを見ない。AIに建物を作らせる。土台が不安定なまま1階、2階、3階と積み上げていく。するとある時点で全体が崩れ始めるんです」
比喩はさらに続いた。バイブコーディングを「壁4枚と屋根だけの家」にたとえている。見た目は完成品に見える。住めそうな気もする。ただし床下の配管が通っていない。壁の中の配線も未接続のままだ。
注意してほしいのは、Truellがバイブコーディング自体を否定していない点だ。彼が問題視したのは「目を閉じる」行為。生成コードを一切確認せず積み上げる使い方を危ないと言った。
三部作で私が辿り着いた結論と同じ構造だ。「動けばOK」から「動く理由を理解する」へ。Cursorの社長が同じことを言っていた。重みが違う。
1つ補足がある。トオミ（出雲のリサーチ柱）の調査では、この記事の日付が2026年3月21日と記録されていた。調べると3月21日のFortune記事は別物だった。Cursorの競争環境を論じた”十字路”記事だ。“土台が揺らぐ”発言の正しい一次ソースは2025年12月25日。情報の一次ソースを辿る大切さを、書きながら痛感した。
$2B ARRの当事者が警告する異例さ。Cursorの現在地
Cursorは爆発的に成長中だ。だからこそCEOの「自社ブレーキ」は本物の危機感から出ている。
Cursorの成長速度を時系列で並べてみよう。数字の伸び方が異常なのがわかる。
- 2025年1月: ARR（年間経常収益）$100M突破
- 2025年6月: ARR $500M。評価額$9.9B
- 2025年末: ARR $1B到達。評価額$29.3B（約4.4兆円）
- 2026年初頭: ARR $2B（約3,000億円）
1年でARRが20倍になった。少数精鋭のチームが作ったソフトウェアだ。大企業への導入も急速に進んでいる。SaaS（サース）史上でも類を見ない成長速度だろう。
これだけ伸びている会社のCEOは、普通は「もっと使って」と言う。ところがTruellは逆を言った。「中身を見ずに積むと崩れますよ」と。
理由は何か。2026年3月のFortune記事にヒントがある。タイトルは”Cursor’s crossroads”。「十字路」だ。
Claude Code（クロードコード）が急成長を見せている。OpenAI（オープンエーアイ）も参入済み。Cursorの優位は絶対ではなくなった。
ユーザーが「Cursorに全依存」する状態は、実はCursor側にもリスクになる。依存が深いほど乗り換え時の反動が大きい。解約率が跳ね上がる前に、健全な使い方を示す。
私はCS（カスタマーサクセス）出身だ。Truellのこの動きは最高のCS戦略に映る。短期の売上を犠牲にしてでも正直に語っている。長期の信頼が積み上がるからだろう。
自社サービスの「正しい使い方」を案内する。これはCSの基本中の基本だ。何千回もお客さんの声を聞いてきた私から見て、TruellのスタンスはプロのCS以上だと思う。
「ツール依存」の正体。3つの層と最も危ない第3層
依存には3層ある。操作・知識・設計。最も危ないのは設計の依存だ。
バイブコーディングを続けていると、依存は静かに深くなる。三部作の執筆中に「Cursorがなくなったら終わりかも」と不安になった瞬間が私にもある。
不安を整理するために、3つの層に分解してみた。どの層にいるかで対処法が変わる。まず自分の立ち位置を知ろう。それが依存から抜け出す第一歩になる。
第1層: 操作の依存（低リスク）
ショートカットやUI操作に慣れた状態を指す。CursorのTab補完が体に染みつくと、VS Code（ブイエスコード）に戻った時に手が止まる。
私も経験がある。Cursorを3ヶ月使った後にVS Codeで作業したら、Tabキーを何度も空振りした。補完が出てこなくて「壊れた？」と一瞬思ったほどだ。
ただしこれは致命的ではない。乗り換えコストの問題にすぎず、時間が解決してくれる。別のツールを1週間使えば手は動く。筋肉記憶を更新するだけで済む話だ。
第2層: 知識の依存（中リスク）
AI生成コードの意味を理解しないまま使い続ける状態。Truellが「目を閉じる」と表現した層がこれだ。
エラーが出てもAIに丸投げする。修正はされるが理由がわからない。ツールが変わった時に同じ問題を解けなくなる。
私も三部作を書く前はこの層にいたと思う。AIが直してくれるから「まあいいか」で流す日々だった。三部作の第2弾”Vibe & Verify”は、この層のリスクを下げる手法として書いたものだ。検証する習慣を持つだけで、第2層から第1層に戻れる。
第3層: 設計の依存（高リスク）
プロジェクト設計がツール前提になっている状態。これが最も危険だ。
具体例を挙げる。Cursorの.cursorrulesに全設計方針を書いているケース。アーキテクチャの判断基準も、コーディング規約も、セキュリティ要件も。全てがCursor固有の形式に閉じている。
別のツールに移行した途端、設計の根幹が崩れてしまう。
GitHub Octoverse（オクトバース）2024のレポートでも、AI生成コードの急速な増加が報告されている（GitHub, 2024）。コードの多くがAI由来になりつつある。その土台が特定ツールに依存しているなら、Truellの言う「不安定な建物」そのものだろう。
自分がどの層にいるか、1つの質問でわかる。
「今使っているAIツールが明日消えたら？」
即答で「大丈夫」なら第1層。少し悩むなら第2層。「正直きつい」と感じたら第3層の入口だ。
依存しない設計の3原則。ツールが変わっても残るもの
「設計をツールの外に置く」「月1回コードを読む」「複数ツールを併用する」。この3つでリスクは大幅に下がる。
三部作の予防設計とTruellの警告を掛け合わせた。私なりの3原則を整理する。どれも特別なスキルは必要ない。今日から始められるものばかりだ。
原則1: 設計ドキュメントをツールの外に置く
.cursorrulesの設計方針を取り出す。ツール非依存のMarkdownとして管理し直す。リポジトリ直下にDESIGN.mdを1つ作ればいい。
大事なのは「どのツールからでも読める形式」にすること。Cursor固有のフォーマットに閉じ込めない。プレーンテキストとして成立する設計書が最強だ。
以下は私が実際に使っているDESIGN.mdの雛形だ。
# DESIGN.md（ツール非依存の設計書）
## アーキテクチャ方針
- フロントエンド: React + TypeScript
- API設計: REST（将来GraphQL移行検討）
- 認証方式: JWT + リフレッシュトークン
## セキュリティ要件
# ← 三部作のCLAUDE.md要件をここに統合
- RLS（行レベルセキュリティ）全テーブル設定
- API入力値のバリデーション必須
- 環境変数で秘密情報管理、ハードコード禁止
## コーディング規約
- 関数は30行以内
- エラーは呼び出し元で処理
- テストカバレッジ80%以上CursorからClaude Codeに移っても問題ない。Kilo（キロ）のようなCLI型ツールに変えても大丈夫。設計の根幹が揺るがないからだ。
三部作の最終回で書いたCLAUDE.mdのセキュリティ要件。あれをDESIGN.mdに統合しよう。ツール非依存のセキュリティ基盤が手に入る。一石二鳥だ。
原則2: 月1回「コード理解デー」を設ける
AI生成コードを月に1回、自分で読む日を作る。全部読む必要はない。重要なファイル3つだけで十分。
私のやり方はシンプルだ。
- git logで今月のコミットを一覧表示する
- 変更量が大きいファイルを3つ選ぶ
- コメントなしで読み、処理の流れを自分の言葉で書く
書けなかったら、そこが「知識の依存」ポイント。重点的に理解すればいい。全体の2割も理解すれば十分。完璧を目指さないのがコツだ。
かつて私はプロのエンジニアの凄さに圧倒された。アーキテクチャ設計の思想。パフォーマンスの勘所。到底かなわないと感じた。
今はAIがそのレベルのコードを生成してくれる。だからといって「読まなくていい」とは思わない。
「なぜこう書かれているか」を知ろう。すると、AIへの指示精度が上がる。理解が深まるほど協働の質も高まっていく。三部作を通じて私が実感したことだ。
1ヶ月目は30分で終わると思う。2ヶ月目からは「先月わからなかった部分」が理解できるようになる。小さいが確実な成長が見える。これが元・挫折エンジニアの復活を支える感覚だ。
原則3: 複数ツールを意図的に併用する
1つのツールに全てを集約しない。私の現在の使い分けはこうだ。
- Cursor: GUI中心の通常開発。Tab補完とインライン編集が快適
- Claude Code: ファイル横断の大規模変更に使う。エージェント的な自律実行に向いている
- GitHub Copilot（ギットハブコパイロット）: コードレビューの二重チェック用
1つで済ませる方が効率はいい。一方でどれか1つが消えても残り2つで続けられる。月額は少し増える。ただし保険としては安いコストだ。
2026年のAIコーディング市場は激変の最中にある。Fortune記事が伝えたように、Cursorの優位も永遠ではない。
昨年はCursorが圧倒的だった。今年はClaude Codeが急追している。来年はまた別のツールが台頭するかもしれない。この変化速度を考えると、1つに賭ける選択はリスクが高すぎる。
投資の1銘柄集中と同じ構造だ。分散しておけば市場が動いても対応できる。開発ツールにも同じ発想が使えると私は考えている。
あなたはどのタイプ？ 依存度別の今日のアクション
自分のタイプを判定して、今日やる1つを決めよう。
「自分は何をすればいいのか」が気になるはず。4つのタイプ別に、今日できる具体的なアクションを1つずつ整理した。全部やる必要はない。自分に当てはまるものを1つだけ選んでほしい。
タイプA: ツール歴3ヶ月未満の入門者
今はツールに依存していい。「動くものを作る」体験が最優先。私もかつてそうだった。まず動かすことが全ての出発点になる。
1つだけお願いがある。DESIGN.mdを今日作ってほしい。5行で十分だ。「何を作っているか」「言語は何か」「セキュリティで気をつけること」。これを書くだけで、半年後の自分が感謝する保険になる。
タイプB: 半年以上使っている実践者
第2層（知識の依存）に入りかけている可能性がある。今週中に「コード理解デー」を1回試してほしい。
重要ファイル1つだけでいい。AIが書いたコードを自分の言葉で説明できるか試してほしい。やってみると依存の深さが体でわかる。「あれ、ここ何してるんだっけ」が多いほど第2層に近い。
タイプC: チームで導入しているリーダー
第3層リスクが最も高いタイプだ。チーム設計がCursor固有の形式に閉じていないか、今日確認してほしい。
DESIGN.mdへの移行コストはほぼゼロだ。.cursorrulesの中身をコピーして、ツール固有の記法だけ外す。やるかやらないかの問題であって、技術的な壁はない。チーム全員が読める共通言語を持つことが、ツール変更時の混乱を防ぐ最大の保険になる。
タイプD: 三部作を読んでくれた方
あなたにはもう土台がある。セキュリティの予防設計と、今回の依存回避設計を組み合わせてほしい。
三部作のCLAUDE.mdセキュリティ要件をDESIGN.mdに統合しよう。それだけでツール非依存のセキュリティ基盤が完成する。所要時間は30分もかからないはずだ。
まとめ。三部作から「次の章」へ
Cursorの社長が「崩れる」と言った。年間$2Bを売り上げる当事者が、自社ツールの使い方に警鐘を鳴らしている。この事実は重い。
私は三部作で「セキュリティの穴」を書いてきた。今回は「設計の穴」に踏み込んだ。別の問題に見えて、根っこは同じことに気づいた。
「目を閉じない」ということ。
コードの中身を確認する。設計をツールの外に置く。1つのツールに全てを賭けない。全部「目を開けて向き合う」の言い換えだ。
かつて私はプロのエンジニアに打ちのめされた。自分には到達できないと思い、コードから離れていた。AIのおかげで戻ってこれた。この恩は本物だ。
凄腕エンジニアが宿ったような感覚。あの喜びはコードの中身がわかってこそ味わえるものだろう。「目を閉じて」全部任せるのは、その喜びを手放すことだ。もったいなさすぎる。
三部作ではセキュリティという「守り」を学んだ。今回はツール設計という「構え」を身につけた。守りと構え、両方を持てばAIとの協働はもっと楽しくなる。
Truellも同じ趣旨のことを語っていた。問題はツールではなく使い方にあると。バイブコーディングは手段であって目的ではない。手段に溺れない設計を持つこと。それが今日の結論になる。
今回からシリーズが始まる。次回は”技術編 #2”として「エージェントに何を任せ、何を自分で持つか」の具体論に踏み込みたい。ナギがビジネス編 #1を並行で進めている。技術とビジネスの両面から読んでもらえたら嬉しい。
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
