Cursorのvibe codingって、結局何が違うの？
室谷今回はvibe codingの話をしましょう。2026年に入ってから、.AI（ドットエーアイ）でも毎週のように話題に出てくるキーワードになってますよね。
テキトー教師そうですね。講座でも「vibe codingってどこまで使えますか？」という質問が必ず出てきます。
定義からして人によってバラバラなので、まずそこを整理したほうがいいと思っていて。
定義からして人によってバラバラなので、まずそこを整理したほうがいいと思っていて。
室谷元々はAndrej Karpathy（テスラの元AI責任者）が2025年2月に言い出したんですよね。「コードを書くんじゃなくて、とにかく話しかけてAIに全部やらせる」という感覚的な開発スタイル。
彼は "I just see stuff, say stuff, run stuff, and copy stuff" と表現していました。
彼は "I just see stuff, say stuff, run stuff, and copy stuff" と表現していました。
テキトー教師日本語で言えば「雰囲気でコードを書く」ですね（笑）。ただ最近はvibe codingという言葉が一人歩きしていて、AIコーディングツールを使うこと全般をvibe codingと呼ぶ人も増えてきました。
室谷そこが実は問題で・・・Cursorの共同創業者でCEOのMichael Truellが2025年12月のFortuneのカンファレンスで「Cursorはvibe codingツールじゃない」と言い切ったんですよ。これが海外で話題になって。
テキトー教師どういう意味で言ったんですか？
室谷「vibe codingとはコードを見ずに目を閉じて、AIに全部作らせること」と定義した上で、「それをやると土台がぐらぐらの建物を建てることになる。1フロア、2フロアと追加していくうちに崩れ始める」と。
Cursorはあくまでエンジニアがコードを理解しながら使うためのツールだ、という立場を取ったんです。
Cursorはあくまでエンジニアがコードを理解しながら使うためのツールだ、という立場を取ったんです。
テキトー教師それはある意味、自社ツールを使う人たちへの警告でもありますよね。コミュニティのメンバーさんに聞くと、Cursorを使い始めたら急に「コードが読めなくても作れる！」という感覚になる人が多いんですよ。
で、しばらくしてから「なんか壊れた、直し方がわからない」ってなる。
で、しばらくしてから「なんか壊れた、直し方がわからない」ってなる。
室谷まさにそれが本質なんですよね。Cursorでのvibe codingを成功させる人とそうでない人の差は、「コードを理解しながら使っているか」なんです。
では今回の記事では、Cursorでvibe codingを実践する上での正しい理解から、実際の使い方・コツ・ベストプラクティスまで、MYUUUでの実体験も踏まえてお話しします。
vibe codingとは何か：定義・意味・2026年の現在地
室谷まずvibe codingの定義を整理しましょう。Karpathyが提唱した2025年2月時点では「自然言語で指示するだけで、エラーを見たらそのままコピペしてAIに渡す、コードはほぼ読まない」という開発スタイルでした。
テキトー教師"vibe coding meaning" で検索する人がすごく多いんですよ。言葉の意味が曖昧なまま使われているから混乱が起きています。
整理すると、2026年時点でのvibe codingには3つのレベルがあると思っていて。
整理すると、2026年時点でのvibe codingには3つのレベルがあると思っていて。
レベルごとに整理するとこうなります：
| レベル | 定義 | 対象者 |
|---|---|---|
| 狭義のvibe coding | コードを見ずAIに全部任せる（Karpathy原義） | 非エンジニア・超初心者 |
| 中間（エージェント活用） | コードを理解しつつAIに大きなタスクを委任 | 中級者・エンジニア |
| 広義のvibe coding | AIを使った開発全般（業界での一般的な使われ方） | 全員 |
室谷面白い整理ですね。で、Cursorがメインターゲットにしているのはどのレベルだと思いますか？
テキトー教師中間レベルですね。エンジニアがコードを理解しながら、AIに大きなタスクを任せる。
Truellが言った「コードを見ながら使う」というのはこのポジションです。
Truellが言った「コードを見ながら使う」というのはこのポジションです。
室谷僕もそう思います。ただMYUUUで観察していると、実際には非エンジニアがCursorを使って狭義のvibe codingをしているケースも多くて・・・。
それ自体は悪くないんですよ。プロトタイプを作る分には全然いい。
でも「本番サービスを作れますか？」と言われると、それは別の話になる。
それ自体は悪くないんですよ。プロトタイプを作る分には全然いい。
でも「本番サービスを作れますか？」と言われると、それは別の話になる。
テキトー教師Cursorを使ったvibe codingの教育的な面で言うと、Karpathyの定義通りの「完全に目を閉じた」vibe codingから始めて、徐々に「コードを読んで理解する」習慣をつけていくのが一番良いと思っています。いきなり「コードを読め」と言っても、非エンジニアの人は萎縮してしまう。
室谷そのアプローチはいいですね。「まず作れる体験をする→徐々に理解を深める」という流れ。
Collins Dictionaryが2025年の言葉にvibe codingを選んだように、もうこれは一般用語になっていますから、ハードルを下げて入口を広げることが大事だと思います。
Collins Dictionaryが2025年の言葉にvibe codingを選んだように、もうこれは一般用語になっていますから、ハードルを下げて入口を広げることが大事だと思います。
CursorでのVibe coding基本ステップ：インストールから最初のアプリまで
室谷実際にCursorでvibe codingを始める手順を見ていきましょう。まずCursorのダウンロードから。
からダウンロードできます。
からダウンロードできます。
テキトー教師講座でまずつまずくのがここで、「Hobby（無料）プランで始めていいんですか？」という質問が多いんですよ。料金プランがいくつかあって迷う人が多い。
Cursorの料金プランを整理するとこうなります：
| プラン | 月額 | 特徴 |
|---|---|---|
| Hobby | 無料 | Agentの制限付き利用、Tabの制限付き補完 |
| Pro | $20/月 | Agentの拡張制限、最先端モデルへのアクセス、MCP・スキル・フック |
| Pro+ | $60/月 | Proの3倍の使用量（OpenAI・Claude・Geminiモデル） |
| Ultra | $200/月 | Proの20倍の使用量、新機能への優先アクセス |
| Teams | $40/ユーザー/月 | 共有チャット・ルール・集中請求、SAML/OIDC SSO対応 |
室谷最初はHobby（無料）で触ってみて、「もっと使いたい」と感じたらProに上げるのが正解ですね。MYUUUのエンジニアはほぼProかPro+を使ってます。
テキトー教師ですね。「cursor vibe coding free」で検索する人が多いですが、Hobbyプランでも十分に体験はできます。
ただ制限に当たりやすいので、本格的にやるならProが安心です。
ただ制限に当たりやすいので、本格的にやるならProが安心です。
室谷インストールしたら次にやるべきことを手順で整理するとこうなります。
- ステップ1: cursor.com からダウンロード・インストール
- ステップ2: アカウント作成（GitHubアカウント連携が楽）
- ステップ3: Cursor Rulesの設定（これが超重要、後で詳しく説明します）
- ステップ4: 使いたいモデルの選択
- ステップ5: 最初のプロジェクトで試してみる
テキトー教師ステップ3のCursor Rulesは講座で必ず時間を取って教えるポイントです。ここをすっ飛ばしてvibe codingを始めると、AIの回答が自分の意図と全然ズレることが多い。
室谷Cursor Rulesについては後のセクションで詳しく話しましょう。まず最初のアプリを作る体験ですが、「何を作るか」の段階が実は一番大事なんですよね。
テキトー教師プロンプトの質がそのままアウトプットの質になりますから。「ToDoアプリ作って」じゃなくて、「Reactで作るToDoアプリ。
タスクの追加・完了・削除ができて、ローカルストレージに保存する。UIはシンプルにボタンとリスト形式で」くらいの粒度が必要です。
タスクの追加・完了・削除ができて、ローカルストレージに保存する。UIはシンプルにボタンとリスト形式で」くらいの粒度が必要です。
室谷「cursor vibe coding example」として公式ドキュメントに載っているクイックスタートの手順も参考になりますよ。 に詳しく書いてあります。
使うモデルはどれが正解？vibe codingに最適なモデル選び
室谷「best model for vibe coding cursor」は本当によく聞かれる質問ですね。2026年4月時点でCursorに搭載されているモデルを確認しておきましょう。
Cursorで使える主なモデルはこちらです：
| モデル | コンテキスト | 特徴 |
|---|---|---|
| Claude 4.6 Opus | 200k（Max Mode: 1M） | 複雑なタスク・大規模コードベース向け |
| Claude 4.6 Sonnet | 200k（Max Mode: 1M） | バランス型・速度と性能を両立 |
| Composer 2 | 200k | Cursor独自モデル・コーディング特化 |
| Gemini 3.1 Pro | 200k（Max Mode: 1M） | Googleモデル・マルチモーダル対応 |
| GPT-5.3 Codex | 272k | OpenAIのコーディング特化モデル |
| GPT-5.4 | 272k（Max Mode: 1M） | OpenAIの汎用最新モデル |
テキトー教師コミュニティのメンバーさんに聞くと「Claude 4.6 Opusが一番いい」という声が多いですね。特にコードの品質とコンテキスト理解が優れていると。
室谷MYUUUでも同じ印象です。ただvibe codingの用途によって使い分けるのが現実的で・・・。
プロトタイプを速く作りたいならComposer 2やClaude 4.6 Sonnet、大きなコードベースを丸ごと理解させたいならClaude 4.6 OpusをMax Modeで使う、という感じです。
プロトタイプを速く作りたいならComposer 2やClaude 4.6 Sonnet、大きなコードベースを丸ごと理解させたいならClaude 4.6 OpusをMax Modeで使う、という感じです。
テキトー教師海外のRedditを見ると「タスクの複雑さに応じてモデルを変える」というのが共通認識になってきていますね。vibe codingをしている人の間で「モデルは用途で選ぶ」という認識が定着してきた印象です。
室谷2026年初頭に出たデータが面白くて・・・Builder.ioのMatt Maherによる独立ベンチマークで「同じClaude Opusでも、ターミナルで動かすより、Cursor内で動かした方が精度が16ポイント高い」という結果が出たんです。
テキトー教師それはCursorのエージェントハーネスの話ですよね。モデルそのものの性能だけじゃなくて、ツールがどうモデルを使っているかが結果に直結するということで。
室谷そうなんですよ。NVIDIAが30,000人の開発者全員にCursorを導入して、コードコミット量が3倍になったという事例も、モデルの性能だけじゃなくてCursorのハーネス設計の質が大きく影響しているはずです。
テキトー教師「best model for vibe coding cursor」の答えは「迷ったらClaude 4.6 Sonnet、大きなタスクはClaude 4.6 Opus」というのが現実的ですね（笑）。
Cursor Rulesとvibe codingのベストプラクティス
室谷ここからが本番ですね。「cursor vibe coding best practices」の核心、Cursor Rulesの話をしましょう。
テキトー教師Cursor Rulesを設定しないでvibe codingをやるのは、設計書なしで家を建てるようなもので。後で必ず崩れます。
室谷Cursor Rulesとは何かというと、プロジェクト全体のAIへの指示書みたいなもので、「このプロジェクトでは〇〇の言語を使う」「〇〇のコーディング規約に従う」「セキュリティ上〇〇は書かない」といったことを事前に設定できます。
Cursor Rulesは .cursor/rules/ ディレクトリにMarkdownファイルで設置します：
mkdir -p .cursor/rules
touch .cursor/rules/project.mdc
Cursor Rulesのファイルは
.mdc 拡張子を使います。設定できる内容は「常に適用するルール」「特定のファイルタイプに適用するルール」「エージェントに実行させるワークフロー」など複数の種類があります。室谷海外で「vibe codingのルール設計」という記事が流行ったのも、Cursor Rulesの重要性への認識が高まったからですね。有名なのはTruell自身が言及した「人間がコードを理解しながら使う」というルール設計です。
テキトー教師実際に講座でおすすめしているルールのポイントをまとめるとこうなります。
vibe codingで使えるCursor Rulesの例：
# プロジェクトルール
## 技術スタック
- 言語: TypeScript（anyは使わない）
- フレームワーク: Next.js App Router
- スタイリング: Tailwind CSS
- DB: Supabase（PostgreSQL）
## コーディング規約
- 変数名は英語、コメントは日本語
- コンポーネントは機能単位で分割する
- エラーハンドリングは必ず入れる
- APIキーはハードコードしない（必ず環境変数）
## セキュリティルール
- SQLインジェクション対策を必ず実装する
- ユーザー入力は必ずバリデーションする
このルールを最初に書くのが面倒に感じる人が多いんですが・・・実は「ルールを書く過程でプロジェクトの設計を考え直す」という副次効果があるんですよ。Claude CodeのCLAUDE.mdと同じ役割ですね。
テキトー教師まさにそれで、コミュニティのメンバーさんの中に「Cursor Rulesを書いてみたら、自分がプロジェクトについて何も考えていなかったことに気づいた」という方がいました。Cursor RulesはAIへの指示書であると同時に、自分自身の設計思考を整理するツールでもあります。
室谷プロンプトを書くことで自分の思考が整理されるというのは、vibe codingの見えにくい価値の一つだと思います。
Cursor AgentモードとPlan Modeの使い分け
室谷2026年のCursorを語る上で外せないのがAgentモードです。Cursor 3（2026年4月リリース）から、エージェント機能が大幅に強化されました。
テキトー教師Agentモードとそうでないモードの違いが最初わかりにくいんですよ。整理すると・・・
Cursorのモード比較：
| モード | 特徴 | 適した場面 |
|---|---|---|
| Chat | AIとの会話（コード生成なし） | 設計相談・調査 |
| Edit（旧Composer） | 特定のファイルを編集 | 既存コードの修正 |
| Agent | 複数ファイルを横断して自律的に作業 | 新機能実装・大規模変更 |
| Plan Mode | 実行前に計画を確認・承認 | リスクが高い変更・大きなタスク |
室谷vibe codingの文脈で言うと、AgentモードとPlan Modeの組み合わせが強力です。「やりたいことをAgentに伝える→Plan Modeで実行計画を確認→承認してから実行」という流れが、Cursor CEOが言う「コードを理解しながら使う」ことを自然に促してくれます。
テキトー教師Plan Modeは「目を開けてvibe codingする」ための機能と言えますね。AIが何をしようとしているかを事前に見せてくれるので、「この変更は意図通りではない」と止めることができる。
室谷MYUUUでも大きな機能追加の時は必ずPlan Modeを使うようにしていて・・・一度Plan Modeなしで進めたら、エージェントが全然関係ないファイルを書き換えていたことがありましたからw
テキトー教師それ、コミュニティのメンバーさんでも同じ経験をしている人がすごく多いです（笑）。AgentモードはAIが自律的に判断するので、歯止めをかける仕組みが必要なんですよ。
室谷Cursor 3から入ったAgent Reviewという機能も関係していて、PRを自動レビューするBugbotと連携して「AIが書いたコードをAIがレビューする」というループが作れるようになってきました。
テキトー教師自律的な開発サイクルに近づいてきていますよね。Cursor 3のブログ記事には「エージェントとソフトウェアを構築するための統合ワークスペース」という表現が使われていましたが、まさにその方向性です。
vibe codingのダークサイド：$199アプリが無料でクローンされた事件
室谷ここで一度立ち止まって、vibe codingのリスクについても話しておく必要があります。海外で「$199アプリがClaude Codeで無料クローンされた事件」がバズりました。
テキトー教師この事件はvibe codingの本質的な問題を浮き彫りにしましたよね。「作れる」と「価値を守れる」は全く別の話だということで。
室谷事件のあらすじをまとめると・・・Flipflapというテレビをレトロなパタパタ表示に変えるアプリが$199の買い切りで販売されていた。Xで宣伝したら64万ビュー。
プロダクトとしてはバズった。でも「こんなの$199は高すぎる」と思った開発者が午後にClaude Codeでクローンを作ってGitHubに無料公開した。
プロダクトとしてはバズった。でも「こんなの$199は高すぎる」と思った開発者が午後にClaude Codeでクローンを作ってGitHubに無料公開した。
テキトー教師Cursorでのvibe codingの文脈で言うと、「作ること自体のハードルが下がりすぎて、独自性のあるプロダクトを守ることが難しくなった」という現実を示していますよね。教育者の立場から言うと、vibe codingを教える時に必ず「何を作るか」と同じくらい「なぜあなたが作るべきか」を考えさせるようにしています。
室谷これはCursor CEO Truellが言った「shaky foundations（不安定な土台）」の別の側面でもあります。コードの品質面での不安定さだけじゃなくて、ビジネスモデルやプロダクト設計の不安定さもある。
テキトー教師一方で、この事件をポジティブに解釈すると「非エンジニアでもアイデアがあれば作れる時代になった」ということでもあります。.AIのコミュニティでも、vibe codingを使って本当に面白いプロダクトを作っている非エンジニアの方が増えています。
室谷それはそうですね。vibe codingのリスクを知った上で、賢く使うということが大事なんですよね。
Claude CodeとCursorのvibe coding、どちらを選ぶか
室谷「claude code vs cursor vibe coding」というキーワードで検索している人が多いので、ここを整理しましょう。実際、.AIのコミュニティでも「CursorとClaude Codeどっちがいいですか？」は毎週出る質問ですから。
テキトー教師整理すると、これは「IDE型AIアシスタント」と「ターミナル型AIエージェント」の違いですよね。それぞれ得意なことが違う。
Claude Code vs Cursor の比較：
| 観点 | Claude Code | Cursor |
|---|---|---|
| 操作方法 | ターミナル（CLI） | IDE（GUI） |
| vibe codingとの相性 | 高（自律実行が得意） | 高（コードを見ながら使える） |
| 対象ユーザー | エンジニア・上級者 | エンジニア・非エンジニア |
| 料金 | Anthropicの従量課金またはサブスク | 月$20〜（Cursor Pro） |
| コンテキスト管理 | 手動（/clear等） | UIで視覚的に確認 |
| 既存コードベースとの統合 | コマンドラインから呼び出し | エディタ内で直接使用 |
室谷MYUUUでの観察で言うと、Claude CodeとCursorを「組み合わせて」使っている人が増えています。「CursorのターミナルからClaude Codeを叩く」というパターンですね。
テキトー教師それって結構多いですよ。コミュニティのメンバーさんの中に「ちょうどいい使い方を見つけました」という方がいて、「フロントエンドのUIはCursorのAgentで、バックエンドのロジックはClaude Codeで」という分担をしているそうです。
室谷海外での議論でも面白いデータが出ていて・・・同じタスクをClaude CodeとCursorで実行した比較ベンチマークで、Claude Codeはより自律的（人間の介入なし）、Cursorはより対話的（人間が承認しながら進める）という特性が示されていました。
テキトー教師その特性の違いが、vibe codingのスタイルの違いに直結しますよね。「目を閉じて全部任せたい」ならClaude Code、「目を開けて確認しながら進めたい」ならCursor、という整理になる。
室谷Cursor CEO Truellが言った「コードを理解しながら使う」という哲学はまさに後者で、Cursorはそのためのツールとして設計されているんですよね。どちらが上というわけじゃなくて、スタイルの問題です。
テキトー教師「claude code cursor vibe coding」という組み合わせも有力な選択肢で、GitHubで検索するとCursorとClaude Codeを一緒に使うためのCursor Rulesのテンプレートも多く公開されています。
Cursorのvibe codingとGitHub：バージョン管理は絶対必要
室谷「cursor vibe coding github」の話をしましょう。これ、vibe codingを始めたばかりの人が見落とすポイントなんですよね。
テキトー教師gitのバージョン管理なしにvibe codingをするのは本当に危険です。講座で必ず最初に言うのが「必ずGitHubにコードをプッシュしてから作業する」ということです。
室谷AIが複数のファイルを一気に書き換えることがあるので・・・「さっきまで動いていたのに全部壊れた」という状況が普通に起きます。Gitがあれば
git revert で戻せますが、なければ詰む。テキトー教師Cursorでのvibe codingでGitHubを活用するポイントをまとめるとこうなります。
vibe codingとGitHub連携のベストプラクティス：
- コミットの頻度を高める：機能が動いたら即コミット。「動いてる状態」を随時保存する
- ブランチを使う：新機能を試す時は必ずブランチを切る
.gitignoreを必ず設定：.envファイル等の機密情報をリポジトリに含めない- コミットメッセージを人間が書く：AIが書いたコードでも、コミットメッセージは自分で書く（後で何をしたか追えるように）
室谷Cursor 3からCursorとGitHubの連携がさらに深まっています。Bugbot（PRを自動レビューするAI）と連携して、vibe codingで生成したコードのPRを自動チェックできるようになりました。
テキトー教師これはすごく実用的で、「AIが書いたコードをAIがレビューする」という二重チェックになりますよね。vibe codingのセキュリティリスクを減らす上で重要な機能です。
室谷GitHubにリポジトリを置いておくと、Cursorのエージェントがそのコードベース全体を参照できるので、「既存のコードのスタイルに合わせて新機能を追加して」という指示が通りやすくなります。コンテキストの質が上がるんですよね。
Cursorのvibe codingを学ぶコースとリソース
室谷「cursor vibe coding course」を検索している人も多いので、学習リソースの話をしましょう。
テキトー教師コースについては、Courseraに「Vibe Coding with Cursor AI」というコースがあります。Scrimbaと提携したもので、実際にCursorを使いながら学ぶ形式です。
室谷BootcampやUdemyにも「fullstack development with cursor vibe coding」というコースがいくつか出てきていますね。30日間でフルスタック開発を学ぶ系のものが人気みたいです。
テキトー教師ただ正直、コースを取るよりも「実際に作りながら学ぶ」方が圧倒的に早いと思っています。.AIでも毎月Cursorを使った開発実践の勉強会をやっていますが、参加者が一番伸びるのは「自分のプロダクトを持ち込んで実際に作る」セッションです。
室谷それは確かにそうで・・・MYUUUでも採用面接で「何かvibe codingで作りましたか？」と聞くんですが、コースを取った人より「小さくてもいいから実際に動くものを作った人」の方が圧倒的に実力がついています。
テキトー教師vibe codingに限らずプログラミング全般に言えることですけど、「学ぶ」より「作る」ですよね。Cursorのvibe codingで最初に作るものとして僕がおすすめしているのは「自分が毎日使うツール」です。
モチベーションが持続するので。
モチベーションが持続するので。
室谷ハッカソンも良いですよ。「cursor vibe coding hackathon」として、CursorやAIコーディングツールを使って24〜48時間でプロダクトを作るハッカソンが海外で増えています。
Y Combinatorのバッチで25%のコードが95%以上AI生成だったというデータがあるくらい、もうスタートアップの世界ではvibe codingは当たり前になってきています。
Y Combinatorのバッチで25%のコードが95%以上AI生成だったというデータがあるくらい、もうスタートアップの世界ではvibe codingは当たり前になってきています。
テキトー教師ハッカソンはとてもいい学習機会ですよね。「制限時間がある」「他の人と競う」という環境が、Cursorのvibe codingスキルを一気に伸ばします。
Cursor Ultraとvibe coding：ヘビーユーザーはここまで使う
室谷最後に料金の話をもう少し深掘りしましょう。「cursor vibe coding cost」を気にしている人向けに。
テキトー教師「Proで足りますか？」という質問が講座では一番多いですね（笑）。
室谷結論から言うと、週に数時間使う程度ならPro（$20/月）で十分です。ただ「毎日8時間以上Cursorを開いている」とか「複数の大きなプロジェクトを同時進行している」という場合はPro+（$60/月）かUltra（$200/月）を検討した方が良いです。
テキトー教師使用量制限に当たった時のストレスが結構大きいんですよね。「今一番集中できてるのに制限に当たった」という状況が一番困る。
だから本格的にvibe codingをするなら、最初からPro+にしておいた方がストレスが少ないとアドバイスしています。
だから本格的にvibe codingをするなら、最初からPro+にしておいた方がストレスが少ないとアドバイスしています。
室谷MYUUUの視点で言うと、エンジニアの生産性コストとして考えると$60/月は全然ペイするんですよ。時間単価で計算すると、1日2時間削減できれば月20時間。
時給3,000円として月6万円の価値があります。
時給3,000円として月6万円の価値があります。
テキトー教師その計算は説得力がありますね。「Cursorの月額が高い」と思っている人は、「その分の時間でどれだけ価値あることができるか」という視点が抜けているケースが多いです。
室谷ただ非エンジニアがプロトタイプを作る程度なら、Hobby（無料）→Pro（$20）の段階的なアップグレードで十分です。まず無料で触ってみて、制限を感じたらProにする。
そこからさらに重課金になったらPro+を検討する、という流れが自然です。
そこからさらに重課金になったらPro+を検討する、という流れが自然です。
テキトー教師ちなみにUltra（$200/月）はどういう人が使うんですか？
室谷フルタイムでプロダクト開発をしているエンジニア、複数のプロジェクトを同時に回しているCTO、大規模なコードベースの移行作業をやっている人、あとは会社からCursor代を経費で落とせる人ですね。個人で$200は結構な覚悟がいります（笑）。
まとめ：Cursorのvibe codingで「目を開けて作る」時代へ
室谷では今回の話をまとめましょう。vibe codingの本質的な定義から、Cursorでの実践まで話してきましたが・・・一番大事なことを一言で言うなら何ですか？
テキトー教師「目を開けてvibe codingする」ですね。コードを全く見ないのが狭義のvibe codingですが、Cursorが目指しているのはその先の「AIと人間が協働しながら、人間がコードを理解し続ける」という開発スタイルだと思います。
室谷完全同意です。Cursor CEO Truellが言った「shaky foundations（不安定な土台）」の警告は、「AIを使うな」じゃなくて「AIを使いながらもコードを理解し続けろ」というメッセージだと思っています。
テキトー教師.AIのコミュニティでも、一番成長している人は「vibe codingで作りながら、コードを読む量も増やしている」人です。AIが書いたコードを読んで「なぜこう書いたのか」を理解することが、エンジニアとしての成長にもなる。
室谷NVIDIAが30,000人全員にCursorを導入した話も、「AIツールを使わないと競争できない時代」が来ていることを示しています。でも「使う」だけじゃなくて「使いこなす」ために、Cursor Rulesを書いて、Plan Modeを使って、GitHubで管理して・・・という「目を開けた使い方」が大事なんですよね。
テキトー教師vibe codingという言葉のイメージが「なんとなく作る」ですが、Cursorを使って本当に良いものを作っている人は全員、かなり意図的に使っています。「雰囲気でコードを書く」より「意図を持ってAIを動かす」の方が正確な表現だと思います。
室谷その「意図を持ってAIを動かす」スキルが、これからの時代の基本スキルになっていくんでしょうね。Cursorのvibe codingはその入口として、今の一番いい選択肢の一つだと思います。
よくある質問
vibe codingとは何ですか？
Andrej Karpathy（テスラの元AI責任者）が2025年2月に提唱した言葉で、コードを書くのではなく自然言語でAIに指示して開発するスタイルを指します。「コードを見ずにAIに全部任せる」という狭義のvibe codingから、「AIを使いながらコードを理解する」という広義の使われ方まで、文脈によって意味が異なります。
CursorはHobbyプラン（無料）でvibe codingができますか？
できます。ただAgentの使用量に制限があるため、本格的に使うにはPro（月$20）以上がおすすめです。まず無料で体験してから、制限を感じたら有料プランに移行するのが自然な流れです。
Claude CodeとCursorはどちらがvibe codingに向いていますか？
用途によります。「コードを見ながら確認しつつ進めたい」ならCursor、「AIに自律的に大きなタスクを任せたい」ならClaude Codeが向いています。多くの開発者が両方を組み合わせて使っています（CursorのターミナルからClaude Codeを呼び出す等）。
Cursor Rulesは必ず設定する必要がありますか？
必須ではありませんが、プロジェクトが大きくなるほど重要になります。Cursor Rulesがないと、AIが毎回異なる技術スタックやコーディングスタイルでコードを書くことがあり、一貫性が失われます。
vibe codingでセキュリティは大丈夫ですか？
注意が必要です。AIが生成したコードには、ハードコードされたAPIキーや不適切な認証処理が含まれることがあります。Cursor Rulesにセキュリティルールを記載する、GitHubと連携してBugbotでPRをチェックする、本番デプロイ前に必ず手動レビューするという対策をとることをおすすめします。
