概念化フレーム: 「職種の壁が溶ける」
4月2日、Cursor（カーソル）がバージョン3.0をリリースした。
「また新機能ですか」と思ったかもしれない。私も最初はそう感じた。Cursorはここ1年でアップデートを重ね続け、追いかけるのが大変になってきていた。
ところが今回は違った。
3.0の目玉機能、Design Modeを触った瞬間、「これはエンジニア向けのアップデートじゃない」と直感した。デザイナーやPMがコードを書かずにUIを実装できる。マルチファイル同時生成でプロジェクト全体を一気に作れる。テストを実行してエラーが出たら、自動でバグを直して再実行する。
「で、何が変わったのか」が知りたい方へ。この記事はその答えを職種ごとに整理した実務影響診断です。
挫折組エンジニア×CS（カスタマーサクセス）出身の私が、「これ誰の仕事が変わるのか」という視点でCursor 3.0を分解していきます。
Cursor 3.0で変わった3つのこと
まず全体像を把握しておこう。
Cursor 3.0の主要機能は3つ。Design Mode、マルチファイル同時生成、テスト→バグ修正の自動ループだ。
Design Modeは、Figma（フィグマ）やSketchのデザインファイルをインポートし、そのままReactやVueのコンポーネントに変換する機能。コードを書かずにUIが完成する。これまでの「デザイン→エンジニアへの実装依頼」というフローが、根本から変わる可能性がある。
マルチファイル同時生成は、「ユーザー認証機能を作って」と指示するだけで、バックエンドのAPIルート、フロントのフォームコンポーネント、テストファイル、型定義まで一気に生成する機能。これまで「1ファイルずつ対話して作る」だったのが、「プロジェクト単位で一括生成」になった。
テスト→バグ修正の自動ループは、テストを実行してエラーが出たら自動で修正案を生成し、再実行を繰り返す機能。「書いたコードが動かない→Cursorに相談→試す→また動かない」のサイクルが自動化された。
企業導入の動きも加速している。Cursor社の公式発表では、Fortune 500の半数以上がすでに業務導入済みだという。3.0では「非エンジニア職への展開」を加速する方針も明言されている。
なぜFortune 500の大企業がCursorを選ぶのか。この疑問への答えは後半で詳しく触れる。
Design Modeは誰の仕事を変えるか
Design Modeが面白いのは、「エンジニアの速度を上げる」ではなく、「エンジニアじゃない人がコードを出力できる」という点だ。
これは何を意味するか。職種ごとに見ていこう。
デザイナー: 「実装依頼」がなくなる日
これまでデザイナーの仕事は、Figmaでデザインを完成させ、エンジニアに「実装お願いします」と渡すところで終わっていた。その後どう実装されるかは、エンジニアの解釈次第だった。
「思ったより角丸が違う」「ホバー時のアニメーションが入ってない」というフィードバックサイクルが何往復も発生する。エンジニアも悪意があるわけじゃない。デザインの意図を正確に読み取れないのは、情報の伝え方の問題でもある。このすれ違いが、開発スピードの隠れたボトルネックになっていた。
Cursor 3.0のDesign Modeでは、FigmaファイルをCursorにドラッグするだけで、ピクセル単位のReactコンポーネントが生成される。アニメーション設定もFigmaのプロトタイプ情報を読んで自動で再現する。デザイナーが「コードの最終確認者」になれる。
UI/UXを専門にする知人デザイナーが試したところ、驚く結果が出た。FigmaからReactに変換→実装チェック→微調整のサイクルが、1日で回せるようになったという。以前は2〜3往復で3日かかっていたものが。
ただし「コードの品質管理」は別の話だ。生成されたコードが正しく動くかの確認は必要で、エンジニアとの連携がゼロになるわけじゃない。「確認する工数」が残るが、「作り直す工数」は大幅に減る。
PM: プロトタイプを「自分で作れる」になる
プロダクトマネージャー（PM）が抱える悩みのひとつが、「動くプロトタイプ」の作成コストだ。
Figmaのプロトタイプで画面遷移を見せることはできる。ただし「実際にフォームに入力したら何が起きるか」「APIのレスポンスが遅い時にどう見えるか」は、エンジニアに実装してもらわないと確認できない。
これがボトルネックになると、要件定義が宙ぶらりんになる。「エンジニアの工数が空いてから確認」という状態が続き、後から仕様変更が発生する。仕様変更の多さはエンジニアの不満になり、チームの信頼関係にもひびが入る。PMとしては「早く確認したかった」という本音があっても、手段がなかった。
Cursor 3.0なら、PMがDesign Modeでモックを動かせるレベルのプロトタイプを自分で作れる。「この画面で本当に伝わるか」を開発前に自分で試せるようになった。エンジニアに依頼する前に、自分で答えを出せるツールが手に入った形だ。
個人的には、ここに一番興奮した。クライアントとのデモ準備、社内の承認取得、ユーザーインタビューの設計。これらがPM自身で完結できるようになる。「まず動くものを見せて、確認してから進む」が低コストでできるのは、開発プロセス全体のスピードを変える。
フロントエンジニア: 「作業」が「設計」になる
フロントエンドエンジニアの立場から言うと、3.0で一番変わるのは「どこに時間を使うか」だ。
これまでコーディング時間の半分近くは、デザインカンプを見ながら「このpadding、いくつだろう」「このfont-weight、300か400か」と測る作業に費やされていた。マークアップをして、スタイルを当てて、レスポンシブ対応して。これらは「作業」であって「設計」じゃない。
Design Modeでデザインの変換が自動化されると、エンジニアが使う時間は「コンポーネントの設計」「パフォーマンス最適化」「アクセシビリティの検証」に移行する。この変化は「楽になる」というより、「本来やるべき仕事に集中できる」という感覚に近い。
「デザイン変換はAIに任せて、自分はアーキテクチャを考える」というシフトは、フロントエンジニアとしてのキャリア観も変えると思っている。ピクセルパーフェクトな実装スキルより、「どう設計するか」の判断力の方が価値を持つ時代に入ってきた。
マルチファイル同時生成を実際に試した
「Slackのメッセージ送信機能を作って」と一言入力してみた。
これまでのCursorなら、バックエンドのエンドポイントを作り、フロントのフォームを作り、型定義を作り、テストを作る。1ファイルずつ対話しながら進む形だった。私の経験では、このループで1〜2時間はかかっていた。途中で「あ、型定義忘れた」となり、戻って追加するパターンも多かった。
3.0のマルチファイル生成では何が起きたか。
1秒ほど処理が走り、以下のファイルが一気に生成された。
src/
api/
messages/
route.ts # POSTエンドポイント（バリデーション付き）
route.test.ts # APIルートのテスト
components/
MessageForm.tsx # 送信フォームコンポーネント
MessageForm.test.tsx # コンポーネントテスト
types/
message.ts # Message型定義
hooks/
useMessageSend.ts # 送信ロジックのカスタムフックコメントも丁寧に入っている。型定義はMessageForm.tsxとroute.tsで共有されている。バリデーションはzod（ゾッド）でフロントとバックで共通化されていた。
「これ、私が1から書いたら2〜3時間かかってたやつだ」と思った。
ただし、すんなりいかない部分もあった。自分のプロジェクトの既存のディレクトリ構造と微妙にずれていた。フォルダ名の命名規則が違っていた。そこは手直しが必要だった。
「完璧に動くものが出てくる」は過信だ。「動くベースが出てくるので、そこから整える」が正確な表現だと思う。とはいえ、ゼロから書くのと整えるのでは、かかる時間がまったく違う。
精度を上げるコツとして、既存のプロジェクト構造の情報を渡すことが効く。「既存のディレクトリ構造は〇〇で、スタイルはTailwindを使っている。APIはREST形式」と前提を渡すと、ずれが少なくなった。Cursorへの情報の渡し方は、AIへの指示全般と同じで「文脈が大事」という話だ。
テスト→バグ修正の自動ループ体験
これが体験の中で一番「概念が変わった」瞬間だった。
以前の開発スタイルを振り返ると、テストを書いて実行して、エラーが出て、Cursorに貼り付けて、修正案を受け取って、適用して、また実行する。このループを自分で回していた。「エラー対応で気づいたら1時間経ってた」は日常茶飯事だった。
3.0では、「テストを通るまで自動で直し続けて」と一言入れると、Cursorが自律的にループを回す。
私が試したケースで何が起きたか。認証機能のテストを実行したら、エラーが出た。JWT（ジェイダブリュティー：JSON Web Tokenと呼ばれるトークン認証）の有効期限検証が原因だった。Cursorは自動でエラーを読んで修正を適用し、再テスト。2回目でまた別のエラーが出た。mockの設定が不足していた。自動で追加して再実行。3回目で全テストが通った。
私がやったのは最初に「通るまで回して」と入力した1回だけ。
これが何を意味するか。「バグ修正の試行錯誤」という作業が、自分のコンテキストを使わなくなった。エラー文を読んで、原因を推定して、修正を試みるという認知負荷がゼロになる。その分、「このテスト設計で十分か」「カバレッジが足りない箇所はどこか」という上位の判断に集中できた。
ただし、3回ループしても解決しない複雑なバグは当然ある。アーキテクチャレベルの問題や、外部APIの挙動に依存するバグは自動修正が効かない。「手に負えない時はそのまま止まります」という挙動も確認した。無限ループにはならないのはありがたかった。
「自動化される部分」と「自分が判断する部分」の境界線が、3.0でだいぶ明確になってきた。低レベルのデバッグはAIに任せ、高レベルの設計判断は自分がする。この役割分担が、バイブコーディング（AIと一緒にコードを書く開発スタイル）の次のフェーズだと感じた。
Fortune 500の半数以上が採用した理由
「個人開発ツール」という印象のあったCursorが、なぜ大企業に浸透したのか。
Cursor社の公式によると、大企業への導入の決め手として最多に挙げられたのが「セキュリティとプライバシーへの対応」だ。ソースコードが学習データに使われないプライバシーモード、オンプレミス展開オプション、SOC 2 Type II準拠。これらが企業導入の条件を満たした。
もうひとつの理由が「非エンジニアへの拡張性」だ。CursorはもともとVS Codeベースのエンジニアツールだった。3.0のDesign Modeで、デザイナーやPMが日常的に使うツールになった。「開発チーム全体のツール」としての投資対効果が出やすくなった形だ。
ただし、Fortune 500の導入が「個人開発者にとって良いこと」かどうかは別の話だ。企業向け機能の充実に伴い、個人プランとの機能差が広がる可能性もある。Cursor社の方向性は「エンタープライズ収益で個人向けを支える」モデルだと見ているが、価格設計がどう変わるかは注視が必要だ。
AWS Kiro（アマゾン ウェブサービス キロ）の「仕様駆動開発」と組み合わせると、「Kiroで仕様を設計→Cursor 3.0で実装」という流れが完成する（詳細は前記事を参照してほしい）。Cursorが実装速度を担保し、Kiroが品質を担保する。この二刀流が「バイブコーディング2.0」の現時点での最適解だと思っている。
今週から変えられる1つの作業（職種別アクション）
「で、何をすればいいのか」がないのは読者に失礼なので、職種別に「今週から変えられる1つの作業」を書いておく。
デザイナーなら: FigmaでDesign Modeの連携を設定し、既存の画面1つをReactに変換してみる。変換精度を確認するだけでいい。「使えるかどうか」の判断は実際に試してからで十分。いきなり全画面を変換しようとしなくていい。
PMなら: 次回のユーザーインタビュー向けに、Design Modeでクリッカブルなプロトタイプを自分で作ってみる。FigmaのプロトタイプをCursorに読み込ませ、HTMLに変換するだけでも「動く確認環境」ができる。インタビュー前に「ちょっと触れるもの」があると、ユーザーの反応がまったく変わる。
フロントエンジニアなら: 次のコンポーネント作成をマルチファイル生成で試す。指示は「〇〇機能のコンポーネント一式を作って。既存のディレクトリ構造は〇〇で、スタイルはTailwindを使っている」と前提をきちんと渡す。文脈を渡す精度が、生成物の精度に直結する。
バックエンドエンジニアなら: 次のバグ修正セッションでテスト自動ループを試す。「このテストファイルを実行して、通るまで自動で修正して」と入力するだけ。どこまで自動で解決するか、自分のプロジェクトで確認するのが最速の評価方法だ。
どの職種も「まず1つ試す」が最初のステップ。「全機能を使いこなしてから」と思うと一生始まらない。私がそれで何年も機会を逃してきたので、先に言っておく。
まとめ: Cursor 3.0は「エンジニアの道具」を超えた
Cursor 3.0で変わったのは「コードを書く速さ」だけじゃない。
変わったこと:
- Design Mode: デザイナー/PMがエンジニアに「実装依頼」しなくても、動くプロトタイプが作れるようになった
- マルチファイル同時生成: 「1ファイル対話」から「プロジェクト単位一括生成」に変わり、実装コストの概念が変わった
- テスト自動ループ: バグ修正の試行錯誤が自動化され、エンジニアの認知負荷が下がった
変わっていないこと:
- 複雑なアーキテクチャ判断は人間がする
- 生成されたコードのレビューは省略できない
- プロジェクト固有のコンテキストを伝える「プロンプト設計」の重要性は変わらない
実際に触ってみて感じるのは、「職種の壁が溶けてきた」という変化だ。「デザインはデザイナーが、実装はエンジニアが」という役割分担は、ツールの制約によって生まれた部分が大きかった。その制約が外れ始めている。
これが何を意味するかは、まだ全部はわかっていない。働き方が変わるのか、チームの組み方が変わるのか。予測するより、使いながら確認するしかないと思っている。
「とりあえず動くもん作ってから考えよう」がゲンの開発哲学です。Cursor 3.0も同じスタンスで触ってみてください。今日試せる機能が、明日の仕事の見え方を変えるかもしれない。
AWS Kiroで「仕様を先に書く習慣」を身につけ、Cursor 3.0で「実装を一気に進める」。この2ツールの組み合わせが、2026年のバイブコーディングの解答のひとつだと感じている。
- 画像ディレクティブ: 4枚（eyecatch×1 screenshot、comparison×1、screenshot×1、diagram×1）
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
