Cursor AIとバイブコーディング入門：非エンジニアがMVPを作る方法

目次

• まとめ：Cursorについて知っておくべきこと
• バイブコーディングとは何か（そして何ではないか）

  • バイブコーディングとリーンスタートアップ：作るのは少なく、検証は先に
• Cursorをうまく使うための設定

  • AIとの作業方法
  • コンテキスト管理：最も効果の大きいスキル
• プロジェクトのルール：AGENTS.mdと .cursor/rules

  • .cursor/rules/ の .mdc ルール
  • AGENTS.md：プロジェクト全体のルール
  • 良い指示を書くための3つの鉄則
• 実践例：アイデアから本番稼働のMVPまで

  • ステップ1：1枚のPRDを書く
  • ステップ2：土台を作る
  • ステップ3：サービスをつなぐ
  • ステップ4：デバッグ、バージョン管理、公開
• 誰も教えてくれないリスク
• 2026年のCursorの料金：10月の変更

  • コストの考え方
• ラテンアメリカで起業する人にとって本当に変わること
• 最初のプロンプトを書く前に

Cursor AIは、AIエージェントを組み込んだコードエディタです。作りたいものを自然な言葉で説明すると、エージェントがコードを書き、編集し、修正してくれます。これをバイブコーディング（1行ずつ書く代わりに、会話でAIを導く開発スタイル）と組み合わせれば、技術者ではない創業者でも、アイデアから本番稼働のMVPまで数か月ではなく数日でたどり着けます。

ただし注意点があります。難しいのはもう文法ではありません。何を頼むか、AIに正しいコンテキストをどう渡すか、そして出てきたものをどうレビューするかです。このガイドでは、考え方、スパゲッティコードを防ぐ設定、ステップごとの実践例、2026年10月のプラン変更後のCursorの料金、そしてほとんど語られないリスクを解説します。

まとめ：Cursorについて知っておくべきこと

概念	内容	何に役立つか
エージェント（Composer 2搭載）	メインのモード。1つの指示から計画を立て、複数のファイルを編集する。Composer 2はCursor独自のモデル。	手でコードを書かずに画面、ロジック、設定を作る。
インライン編集（Cmd/Ctrl + K）	選択したコードやコマンドへのピンポイントな変更。	ファイルの他の部分に触れずにコンポーネントを調整する。
プロジェクトのルール	.cursor/rules/ 内の .mdc ファイルと、ルートの AGENTS.md。	毎回のセッションで、スタック、デザイン、禁止事項をAIに守らせる。
コンテキスト（@メンションと .cursorignore）	エージェントに読ませるファイルやドキュメント、無視させるものを指定する。	幻覚（ハルシネーション）を減らし、使用量を抑え、回答を正確にする。
2026年のプラン	Free、Plus（月8ドル）、Premium（30ドル）、Super（100ドル）、Ultra（200ドル）。	プロジェクトの段階と必要なモデルに合わせて選ぶ。

バイブコーディングとは何か（そして何ではないか）

バイブコーディングという言葉を広めたのは、OpenAIの共同創業者で元テスラAI部門ディレクターのアンドレイ・カルパシーです。2025年初めに、モデルに話しかけ、変更を受け入れ、コードの存在をほとんど忘れてしまう、「ノリに身を任せる」プログラミングのやり方として紹介しました。

技術者ではない創業者にとって役立つのは、もう少し規律のある考え方です。決定的なスキルが、文法から要件を整理する力に変わるということです。どんな課題を誰のために解決するのか、各画面で何が起きるのか、どんなデータを保存するのかをはっきり説明できれば、それをコードに翻訳する作業はAIが担います。

これによって、具体的に3つのことが変わります。

• 最初のバージョンのコスト。 かつては数か月かかる開発会社の見積もりだったものが、今は月額のサブスクリプションと自分の時間で済むこともあります。ただし、自分の時間にもコストがあり、それは小さくありません。
• 仮説を検証するスピード。 プロトタイプを数日で実ユーザーの前に出せます。アイデアに価値があるかを知るために、まさに必要なことです。
• あなたの役割。 「コードを書く人」から、プロダクトとアーキテクチャを担う立場に近づきます。何を、どの順番で、どの品質基準で作るかを決めるのはあなたです。

バイブコーディングではないもの：何も理解せずに作る方法ではありません。純粋なバイブコーディングは週末のプロトタイプには向いています。しかし、ユーザー、決済、個人情報を扱うものなら、自分で書かなくても、どう組み立てられているかは理解しておく必要があります。

バイブコーディングとリーンスタートアップ：作るのは少なく、検証は先に

起業が失敗するよくある理由の一つは、検証していない思い込みの上にプロダクトを作ってしまうことです。バイブコーディングはそれを解決しませんが、修正を安くしてくれます。MVPに数か月ではなく数日しかかからなければ、資金を燃やし尽くさずにリリース、計測、方向転換ができます。

順番は今でも大切です。まず仮説、それからコードです。Cursorを開く前に、1週間でアイデアを検証すること、そしてビジネスモデルをビジネスモデルキャンバスに落とし込むことをおすすめします。誰がなぜお金を払うのかがわからなければ、AIは誰も欲しがらないものを速く作る手助けをするだけです。

Cursorをうまく使うための設定

CursorはVS Codeのフォークです。見た目は同じで、拡張機能やショートカットもそのまま使えますが、エディタの中心にAIがあります。VS Codeを使ったことがなくても、慣れるのに半日もかかりません。

AIとの作業方法

1. エージェント。 最もよく使うモードです。タスクを渡すと（「3つのプランがある料金ページを追加して」）、エージェントはプロジェクトを読み、計画を提案し、複数のファイルを編集し、ターミナルでコマンドを実行することもできます。変更ごとに承認を求めるか、直接適用させるかを選べます。最初のうちは、変更を1つずつ承認しましょう。
2. 計画モード・質問モード。 大きな変更の前に、ファイルに触れずに分析と提案だけをさせます。「ユーザー登録の流れを説明して」「サブスクリプションを追加するにはどのファイルを変える必要がある？」といった使い方です。自分のプロジェクトを理解する一番の方法です。
3. インライン編集（Cmd/Ctrl + K）。 ブロックを選択して、具体的な変更を頼みます。ファイルの他の部分を危険にさらさずに手直ししたいときに最適です。
4. AI付きターミナル。 やりたいこと（「依存関係をインストールしてマイグレーションを実行して」）を説明すると、コマンドが返ってきます。実行前に内容を読みましょう。特に削除や上書きを伴う場合は必須です。

モデルについては、Cursor独自のモデルであるComposer 2（2026年3月リリース、コード編集が速く安い）と、ClaudeやGPTなどのサードパーティ製モデルを、プランに応じて選べます。モデルファミリーの違いを知りたい方は、2026年のClaudeモデルのガイドをどうぞ。

コンテキスト管理：最も効果の大きいスキル

モデルには限られたコンテキストウィンドウがあります。会話中に記憶できる範囲のことです。無関係なファイルで埋めると、モデルは混乱し、コードに存在しないものを作り出します。逆に情報が少なすぎると、推測で動きます。

ちょうどいいコンテキストの渡し方：

• @メンション。 @ で読むべきものを正確に指定します。特定のファイル、フォルダ（たとえば /components）、ライブラリの公式ドキュメントなどです。プロジェクト全体を勝手に探させるよりずっと良い結果になります。
• 短く、タスクごとの会話。 1つの機能につき1つの会話。セッションが長くなって矛盾し始めたら、新しい会話を開いて要点をまとめましょう。
• .cursorignore。 ルートに置くファイルで、.gitignore と同じ書式です。重いファイル、ローカルデータ、ログ、秘密情報を含むファイルをAIに読ませないようにします。使用量を節約でき、APIキーが会話に紛れ込むリスクも下がります。
• 初日からGitHub。 プロジェクトをリポジトリにつなぎましょう。AIが何かを壊したとき（必ず起きます）に戻れる履歴ができ、コードがツールではなくあなたのものであることも保証されます。

プロジェクトのルール：AGENTS.mdと .cursor/rules

ルールがないと、AIは即興で動きます。ライブラリを混ぜ、ファイルごとにスタイルを変え、すでに直したミスを繰り返します。ルールは、エージェントが毎回のセッションで読む永続的な指示なので、同じことを何度も言う必要がなくなります。

.cursor/rules/ の .mdc ルール

Cursor独自の形式は、.cursor/rules/ 内の .mdc ファイルです。それぞれにヘッダーがあり、いつ適用するかを決めます。常に適用（alwaysApply: true）、特定のファイルを扱うときだけ（globs）、または description をもとにエージェントが関連すると判断したときです。以前の単一ファイル .cursorrules は旧形式の扱いになりました。

例：.cursor/rules/frontend.mdc

---
description: フロントエンドのコンポーネントとスタイルの基準
globs: "src/components/**/*.tsx"
alwaysApply: false
---

# フロントエンド

1. ReactのファンクションコンポーネントとTailwind CSSを使う。インラインスタイルは使わない。
2. UIコンポーネントは、新しく作る前にまずshadcn/uiのものを使う。
3. ローカルの状態はReactのフックで、データの変更はServer Actionsで行う。
4. ブラウザで実行されるコードに、APIキーやトークンを絶対に置かない。

1つ注意点があります。ルールに globs を指定するなら、通常は alwaysApply: false にして、そのファイルを扱うときだけ有効にします。両方を指定すると、ルールは常に適用され、globs は意味がなくなります。

AGENTS.md：プロジェクト全体のルール

AGENTS.md は、リポジトリのルートに置く普通のMarkdownファイルです。ヘッダーも条件もなく、書いた内容はすべて適用されます。オープンな標準なので、Claude CodeやCodexなど他のエージェントも読み込みます。明日ツールを乗り換えても、ルールはそのまま持っていけます。

	.mdc ルール	AGENTS.md
置き場所	.cursor/rules/*.mdc	プロジェクトのルート（必要ならサブフォルダにも）
適用タイミング	ヘッダー次第：常に、ファイル単位、関連性で判断	常に、すべて
読むもの	Cursorのみ	Cursorと対応する他のエージェント
用途	コードの特定部分だけのルール	プロジェクトの概要、スタック、テスト方法、禁止事項

うまくいく分け方は、AGENTS.md に全体像（アプリの目的、スタック、コマンド、全体に共通するルール）を書き、.mdc には特定のフォルダやファイル種別にだけ当てはまるルールを書くことです。

良い指示を書くための3つの鉄則

1. 願望ではなく具体的な事実を。 「きれいなコードを書いて」ではモデルに何も伝わりません。「ユーザーテーブルは public.profiles で、user_id で関連づけられている」なら伝わります。モデルに、架空の構成ではなく実際のアーキテクチャの上で作業させられます。
2. 禁止事項を明示する。 やってはいけないことを書きましょう。「確認なしに新しいライブラリを入れない」「インラインスタイルを使わない」「適用済みのマイグレーションを変更しない」。明確な禁止事項は、あいまいな推奨よりも多くのミスを防ぎます。
3. 結論から答えさせる。 まずコードやコマンドを出させ、説明は必要なら後に。時間と使用量の節約になります。

さらに一歩進めて、コードの前に仕様を書きたいなら、仕様駆動開発（Spec-Driven Development）がまさにその規律をエージェントに応用したものです。

実践例：アイデアから本番稼働のMVPまで

流れはいつも同じです。仕様 → 土台 → 連携 → 公開。変わるのは、各段階にどれだけ時間をかけるかです。

ステップ1：1枚のPRDを書く

コードを1行でも頼む前に、要件定義書（PRD）をプロジェクト内の PRD.md に書きます。長くする必要はありません。どんな課題を誰のために解決するのか、バージョン1で何をするのか、そしてとても重要なこととして、まだ何をしないのかを書きます。

計測するイベントも含めましょう。最初に決めておかないと、後でプロダクトがうまくいっているのか判断できません。SaaSの基本リストは次のとおりです。

• signed_up：登録した。
• onboarding_completed：初期フローを完了した。
• created_first_project：プロダクトから最初の本当の価値を得た。
• invited_teammate：誰かを招待した。
• hit_plan_limit：無料プランの上限に達した。
• subscription_started：支払いを始めた。
• payment_failed：決済が失敗した。
• cancelled：解約した。

PRDができれば、エージェントには毎回のタスクで @PRD.md として参照できる「唯一の正解」ができます。

ステップ2：土台を作る

とても一般的で、ドキュメントが充実し、モデルが熟知しているスタックです。

• Next.js（本番向けのReactフレームワーク）
• Tailwind CSS（ユーティリティクラスによるスタイリング）
• shadcn/ui（プロジェクトにコピーして使う、アクセシブルなUIコンポーネント）

モデルがよく知っているかどうかは小さな話ではありません。スタックが有名であるほど、AIの作り話は減ります。

エージェントへのプロンプト例：

@PRD.md を読んで。App Router、TypeScript、Tailwind CSS、shadcn/uiを使ったNext.jsプロジェクトを、コードは /src 内に置き、メインレイアウトにナビゲーションバーを入れる形で初期化する計画を提案して。私が計画を承認するまで何も実行しないで。

最後の一文が重要です。計画が先、実行は後。計画のレビューは2分で済みますが、間違って作られた20個のファイルを元に戻すには半日かかります。

ステップ3：サービスをつなぐ

1セッションに1つの連携。それぞれテストしてから次に進みます。

• 認証。 すでにSupabaseを使っているならSupabase Auth、GoogleやGitHubでの登録・ログインをほぼ完成した形で使いたいならClerk。
• データベース。 Supabase（マネージドPostgreSQL）。すべてのテーブルで行レベルセキュリティ（RLS）を有効にし、各テーブルにどんなポリシーがあるかエージェントに説明させましょう。RLSのないテーブルは、誰でも読める状態になりかねません。
• 決済。 自分の国で使えるならStripe。ラテンアメリカならMercado Pagoなど現地の決済サービスも検討を。決済の確定はサーバー側のWebhookで行い、ブラウザだけで済ませてはいけません。
• トランザクションメール。 ウェルカムメールや通知には、ResendやSendGridのようなサービスを。

ステップ4：デバッグ、バージョン管理、公開

• エラー。 何かが失敗したら、エラー全文をエージェントのチャットに貼り、修正の前に原因を説明させましょう。「直して」とだけ頼むと、症状だけを取り繕う傾向があります。
• こまめなコミット。 動く変更ができるたびにコミット。それがあなたの「元に戻す」ボタンです。
• 公開。 GitHubのリポジトリをVercel（または好きなプラットフォーム）につなぎます。メインブランチへの変更は自動で公開され、HTTPSと独自ドメインも使えます。シンプルなアプリをもっと安く動かしたいなら、Cloudflareに無料でデプロイする方法もあります。

誰も教えてくれないリスク

バイブコーディングは参入障壁を下げますが、問題をなくすわけではありません。見えにくくするだけです。よくあるものは次のとおりです。

• セキュリティ。 ブラウザに露出したAPIキー、権限設定のないテーブル、保護されていない管理画面のルート。コードは「動く」ので、誰もレビューしません。実ユーザーが来る前に、エージェントに明示的なセキュリティ監査を頼み、決済や個人情報を扱うなら人によるレビューも受けましょう。詳しくはビジネスでAIを使うときのセキュリティとプライバシーのガイドをどうぞ。
• 技術的負債。 その場しのぎの修正は積み重なります。新しい変更のたびに2つのものが壊れるなら、立ち止まってエージェントに構成の整理を提案させるタイミングです。
• 1つのツールへの依存。 だからこそGitHubと AGENTS.md が大切です。Cursorが値上げしたり条件を変えたりしても（実際につい最近ありました）、別のエージェントで作業を続けられます。代替ツールは2026年に使う価値のあるIDEとコーディングエージェントで比較しました。
• 見えないコスト。 エージェントが「これを直して、あれを壊す」のループに入ると、AIのクレジットはすぐに減ります。使用量は毎週確認しましょう。

2026年のCursorの料金：10月の変更

2026年10月12日以降、Cursorは新規のサブスクリプションを、GrokやXと共有のパッケージ The X Subscription の中で販売しています。Pro（20ドル）とPro+（60ドル）は新規顧客には提供されなくなりましたが、既存の契約者はそのまま維持できます。

プラン	月額	含まれる使用量	向いている人
Free	0ドル	制限あり、Cursorのモデル	ツールを試し、流れを覚える。
Plus	8ドル	週ごとの基本使用量。固定設定のCursorとGrokのモデルのみ。Auto、クラウドエージェント、サードパーティモデルは使えない。	最小予算でのシンプルなプロトタイプ。
Premium	30ドル	Plusの4倍の使用量。クラウドエージェント、Bugbot、サードパーティモデル（Claude、GPT）は前払いクレジットからAPI価格で別途課金。	本気でMVPを作る創業者。旧Proに相当。
Super	100ドル	Plusの15倍の使用量と、ピーク時間帯の優先アクセス。	ヘビーユース、または複数プロジェクトの同時進行。旧Pro+に相当。
Ultra	200ドル	Plusの50倍の使用量と、新モデルへの先行アクセス。	チームや大規模なコードベース。

年額プランはそれぞれ80ドル、300ドル、1,000ドル、2,000ドルです。価格は税抜きです（出典：Cursorヘルプセンター）。

コストの考え方

• 使用量は「リクエスト数」では数えなくなりました。 各プランには毎週リセットされる使用枠があり、使い切ったら追加購入できます。Cursorは各枠がドル換算でいくらかを公開していないので、足りるかどうかを知る唯一の方法は、最初の数週間で自分の使用量を測ることです。
• サードパーティのモデルは別料金です。 Premium以上では、ClaudeやGPTの利用分が前払いクレジットからAPI価格で差し引かれます。作業の大部分はComposer 2で行い、高いモデルは難しい場面、つまりアーキテクチャ、安いモデルでは解決できないバグ、セキュリティレビューのために取っておきましょう。
• すでにProやPro+を契約しているなら、切り替える前によく考えて。 新しいサブスクリプションに移ると以前のプランは解約され、元には戻せません。
• 置き換えるものと比べましょう。 Premiumにモデルの利用料を加えても、月額コストは外部の開発を時間単位で依頼する場合のごく一部であることが多いです。ただし自分の時間も計算に入れてください。AIで自作するMVPは、お金の面では安くても、時間の面では安くありません。

CursorをChatGPT、Claude、Geminiのサブスクリプションやオープンなモデルと比べたい方は、2026年のAIの実際の料金をご覧ください。1つのプロバイダーへの依存が気になるなら、opencodeのようなエージェントからローカルモデルを使うこともできます。

ラテンアメリカで起業する人にとって本当に変わること

長年、この地域でデジタルプロダクトを立ち上げるには、開発費のための資金調達か、技術系の共同創業者を見つけることが必要でした。バイブコーディングはその必要性を永遠になくすわけではありませんが、最初のバージョンについてはなくしてくれます。今は、自分の時間とサブスクリプションと規律があれば、実ユーザーに届けられます。

競争優位はもう、文法を暗記することにはありません。どんな課題を解決するのかを明確にし、それを証明するための最小限を作り、ユーザーの行動を計測し、改善を続けながら資金を守ることにあります。コードを書くことはもうボトルネックではありません。何を作るかを決めることが、今のボトルネックです。

最初のプロンプトを書く前に

エディタを開く前に、数字とビジネスモデルを固めましょう。

1. 利益率計算ツールで、インフラとAIサブスクリプションのコストを見積もり、ビジネスが成り立つにはプランをいくらで売る必要があるかを確認しましょう。
2. インタラクティブなビジネスモデルキャンバスでモデルを組み立て、作ることに時間とお金を投じる前に、顧客は誰で、いくら請求するのかをはっきりさせましょう。