Vibe coding とは——Karpathy 発祥の新興語を、業務で実践する現役の生成AIエンジニアが日本語で整理しました

「Vibe coding」という言葉を見かけて、AI に丸投げするだけの軽いノリの話なのか、それとも本気の開発手法なのか、判断がつかず迷っていませんか。実際、ラッコキーワードの実測（2026 年 6 月時点）でも「Vibe coding」は月 14,800 人が同じ問いで検索しており、12 ヶ月で +328% 伸びている、2026 年でいちばん勢いのある新興語のひとつです。私自身、Vibe coding を独立した開発スタイルとして業務開発で日常的に実践しています。

結論から言うと、Vibe coding は「細かく書かず、感覚で AI に書かせて、人間はレビューと方向づけに回る」新しいコーディングスタイルで、合う場面では確かに速い一方、人間レビューを外すと崩れます。本記事では Karpathy 発祥の整理（出典付き）、従来コーディングとの違い 5 軸、Claude / Cursor での実践、5 ステップの始め方、落とし穴 5 個まで、業務で実践する現役の生成AIエンジニア視点で噛み砕きます。

とりあえず最短で 1 回体験したい方は セクション 6「5 ステップで始める Vibe coding」から、概念だけ先に掴みたい方は セクション 2 からどうぞ。

01 — 結論：Vibe coding は「感覚で AI に書かせ、人間はレビューと方向づけに回る」コーディングスタイル

📖 この章で使う用語

  • Vibe coding：細かい実装を AI に任せ、人間は「何を作るか」と「出てきたものの良し悪し」に集中する開発スタイル。料理で、レシピの 1 手順ずつではなく「今日は和風のさっぱりしたものを」と方向だけ伝えて、調理は任せるイメージ。
  • AI コーディング：コードを書く・読む・直すすべての場面で AI を相棒にする総称。Vibe coding はその中の「スタイル」のひとつ。
  • レビューと方向づけ：人間側の主作業。出てきたものの良し悪しを判断し（レビュー）、進む向きを決める（方向づけ）こと。

まず結論から書きます。Vibe coding は、細かい実装を AI に任せ、人間は「何を作るか」と「出てきたものの良し悪し」に集中する開発スタイルです。「AI に丸投げして遊ぶこと」でも、「魔法のように誰でもアプリが作れる方法」でもありません。

3 行で覚えるなら、こうなります。

  1. 指示は粗く、目的ベースで渡す（「ログイン機能を足して」のように、1 行ずつ書かない）
  2. 実装は AI が書く（細かいコードは人間が手で打たない）
  3. 人間はレビューと方向づけに回る（出てきたものを読んで判断し、向きを直す）

この記事は、私が業務開発で実際に毎日やっていることを土台にしています。私は Vibe coding を独立した開発スタイルとして業務で実践しており、Claude Code・Cursor・GitHub Copilot を日常的に業務で使っています。一方で、「Vibe coding」という言葉そのものの由来や、SNS で飛び交っている議論の細部については、公式の情報や出典で確認した範囲でお伝えします。ここは私の体験談ではなく、調べた事実として書き分けます。

なぜわざわざ書き分けるかというと、新しい言葉ほど、勢いだけが先行して中身が曖昧になりがちだからです。営業時代に流行りのトークスクリプトを鵜呑みにして失敗した経験から、私は「自分が手を動かして確かめたこと」と「人から聞いた話」を分けて扱う癖がついています。本記事でも、私の実感と、出典で確認した事実は、はっきり分けてお伝えします。

なお、AI コーディングツール全体の地図（コードを補ってくれる系・対話する系・自分で動く系の 3 つの違いや、ツール 8 個の比較表）は、親記事の AI コーディングとは何かを 3 レイヤーで整理した記事にまとめています。本記事は「Vibe coding という スタイル」に集中します。AI に書かせるコーディング全般の俯瞰が先に欲しい方は、そちらを先に読んでいただくと迷いません。

最後に、最初に 2 つだけ前提を置かせてください。1 つ目は、本記事は「Vibe coding をやれば誰でもエンジニアになれる」とは言わないこと。合う人・合うチームには大きな武器ですが、個人差もコードの文化の違いもあります。2 つ目は、人間のレビューは外せないということ。AI が書いたコードを「動いたから OK」で本番に乗せるのは、後で必ずしっぺ返しが来ます。この 2 つは記事全体を通して何度も戻ってくる軸です。

02 — Vibe coding とは——Andrej Karpathy 発祥（2025-02）の整理と日本語での意味

📖 この章で使う用語

  • Andrej Karpathy（アンドレイ・カパシー）：OpenAI の創設メンバーで、元 Tesla の AI 部門責任者。「Vibe coding」という語を広めた人物として知られています（公開情報）。
  • vibe（バイブ）：英語で「雰囲気・ノリ・感覚」。“vibe coding” は「ノリ・感覚でコードする」をつなげた合成語です。
  • バズワード：流行で一気に広まった言葉。中身が曖昧なまま使われがち、という注意の文脈で出てきます。

Vibe coding という言葉の出どころから整理します。ここは私の体験談ではなく、公式・出典で確認した範囲の話です。

02-1 Karpathy 発祥の整理（出典・取得日付き）

「Vibe coding」という表現は、AI 研究者の Andrej Karpathy が 2025 年 2 月に X（旧 Twitter）へ投稿したことで一気に広まった、というのが公開情報で確認できる経緯です。彼の投稿の趣旨は、おおまかに言えば「雰囲気に身を委ね、コードの存在すら忘れて作る」というものでした。

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” 出典: Andrej Karpathy の X 投稿｜X (旧 Twitter)（取得：2026-06-02）

ここで注意したいのは、Karpathy 自身がこの語を「厳密な開発手法」として定義したわけではない点です。あくまで彼個人の体験から出た言葉で、その後コミュニティの中で意味が広がっていきました。だからこそ、人によって「Vibe coding とは何か」の説明が微妙にずれます。「AI に丸投げすること」と説明する人もいれば、「人間がレビューと方向づけに集中する開発スタイル」と説明する人もいる。本記事は後者の立場、つまり実務で使えるスタイルとしての Vibe coding を中心に書いています。概念の細かい歴史や、SNS 上での賛否の流れまでは、私が体験として語れる範囲を超えるので、ここでは「出どころはここ」という事実だけ押さえておきます。

ちなみに、この語は 2025 年に英語圏で大きく話題になり、Merriam-Webster などの辞書系メディアでも取り上げられるほど認知が広がりました。

“Vibe coding” was added to its watch list of trending words. 出典: Vibe Coding｜Merriam-Webster Words We’re Watching（取得：2026-06-02）

02-2 “vibe” ＋ “coding” の語をほどく

言葉の作りはシンプルです。“vibe”（雰囲気・ノリ・感覚）と “coding”（コードを書くこと）をくっつけただけ。直訳すると「感覚でコードを書く」です。

営業時代の私に置き換えると、商談の台本を 1 文字ずつ用意するのではなく、「今日はこの相手に、こういう空気感で、この方向に話を持っていきたい」と方向だけ決めて、あとは現場の流れで言葉を組み立てる感覚に近いです。Vibe coding の “vibe” は、ちょうどその「方向だけ決めて、細部は流れに任せる」のニュアンスだと考えると腑に落ちます。

注意したいのは、“vibe” という軽い響きにつられて「中身も軽い」と受け取らないことです。方向を決めるのは、実はそれなりに頭を使う作業です。営業でも、「なんとなくの空気感」で動いているように見えるベテランほど、実は相手の状況を読み込んで方向を定めています。Vibe coding の “vibe” も、これと同じで、軽いノリの裏に「目的をはっきりさせる」という地味な仕事が隠れています。

02-3 実務での意味＝「目的ベースで任せ、感覚で判断する」

ここからは、私が業務で実際にやっている解釈です。実務での Vibe coding は、自然言語で目的を伝え、コードの細部は AI に委ね、出てきたものの良し悪しを感覚的に判断しながら進める進め方を指します。

大事なのは、「流行語としての Vibe coding」と「実務で使える開発スタイルとしての Vibe coding」には温度差がある、ということです。前者は「AI に丸投げで何でもできる」という勢いのある言い方になりがちですが、後者は、目的設定とレビューという人間側の仕事がむしろ重くなります。バズワードとして軽く受け取ると、後で「思ったより人間がやることが多い」と感じるはずです。

具体的に書くと、私の業務での Vibe coding は、おおまかに次の 3 段の往復で進みます。

  1. 目的を渡す：「こういうものが欲しい」を自然な日本語で AI に伝える
  2. 出力を読む：AI が書いてきたコードを読み込み、意図どおりか・危ない箇所はないかを判断する
  3. 方向で直す：気になる箇所を「ここをこうしたい」と方向だけ伝えて、書き直してもらう

この 1 → 2 → 3 を何度か回して、納得できる形に寄せていきます。1 行ずつ手で書く従来のやり方と比べると、2 番（読む）と 3 番（方向づけ）に重心が移っているのが分かると思います。

私の場合、Vibe coding を「ラクをするため」ではなく「自分が判断と設計に集中する時間を増やすため」のスタイルとして使っています。手を動かす部分を AI に渡すことで、空いた頭を「これは本当に作るべきか」「この設計でいいか」に回す。これが私の実務での Vibe coding の中身です。営業時代に、書類作成や移動に取られていた時間を、お客様との対話に振り向けたいと思っていたのと、構造はよく似ています。

03 — 従来のコーディングとの違い 5 軸——指示の粒度・レビュー姿勢・設計主導権・速度・学習曲線

📖 この章で使う用語

  • 指示の粒度：AI への指示の細かさ。「1 行ずつ」か「目的だけ」か。
  • 設計主導権：「何をどう作るか」の方針を握る主体。Vibe coding でも人間が握り続ける必要があります。
  • 学習曲線：スキルが身につくまでの伸び方のカーブ。横軸が時間、縦軸が習熟度のイメージ。

従来のコーディングと Vibe coding は、どこが違うのか。私が業務で実感している違いを 5 つの軸で並べます。先に一言でまとめると、「人間が手を動かす作業」が減って、「人間が判断する作業」が増える、という移り変わりです。

03-1 指示の粒度

従来のコーディングは、人間が 1 行ずつコードを書きます。変数名も、条件分岐も、ループの中身も、全部自分の手で決める世界です。

Vibe coding は、指示の粒度が粗くなります。「ユーザー登録のフォームを作って、メール形式のバリデーションも入れて」のように、目的と要件を渡すだけ。あとの細部は AI が埋めます。営業の指示出しでいえば、「この資料の 3 ページ目の 2 行目をこう直して」ではなく「この提案、もっと相手の不安に寄り添うトーンに」と方向で渡す感覚に近いです。

ここで未経験の方が誤解しやすいのは、「粗く渡す＝適当でいい」ではない、という点です。粗く渡すからこそ、「何が欲しいか」をはっきりさせる力が要ります。目的が曖昧なまま渡すと、AI も曖昧なものを返してきます。逆に、目的さえ明確なら、実装の細部を知らなくても進められる。これが、未経験から始める人にとっての Vibe coding の入りやすさでもあります。

03-2 レビュー姿勢

従来は、自分が書いたものを自分で点検します。書いた本人なので、どこに何があるかは頭に入っています。

Vibe coding では、レビューが主作業になります。自分が書いていないコードを読み込み、意図どおりか、危ない箇所はないかを判断する側に回ります。私の感覚では、ここが一番大きな変化です。「書く人」から「読んで判断する人」へ役割が移る。営業時代に、自分が話すより、相手の話を聞いて意図を汲み取るほうが結果的に効いた経験があるのですが、それと似た構図だと感じています。

03-3 設計の主導権

ここが Vibe coding で最も注意したい軸です。従来は、人間が設計を握っているのが当たり前でした。

Vibe coding でも、設計判断は人間が握り続ける必要があります。実装を任せても、「何を、どういう構造で作るか」を手放してはいけません。ここを AI に丸ごと任せ続けると、後で「なぜこの作りになっているのか誰も説明できない」状態になります。これは セクション 7 で詳しく扱う「設計の暗黒化」という落とし穴に直結します。

03-4 速度の実感（メタ宣言）

速度については、正直に書きます。「Vibe coding は絶対に速い」とは申し上げません。

立ち上がりは確かに速いです。ゼロから機能の骨格を作るところまでは、手で書くより明らかに速いと感じます。ただ、レビューと手戻りまで含めた実効の速度は場面次第です。よく分かっている小さな機能なら速い。逆に、設計が固まっていない複雑なものを Vibe coding で進めると、AI が出してきたものを直す往復で、かえって時間がかかることもあります。「速いと言われているから万能」ではなく、「立ち上がりは速いが、レビュー込みの実効速度は場面で変わる」が私の実感です。

03-5 学習曲線の変化

従来は、文法を覚え、実装力を積み上げていく学習曲線でした。書けば書くほど上達する、分かりやすい世界です。

Vibe coding では、必要なスキルの中身が変わります。「コードを読む力」「方向づける力」「出てきたものの良し悪しを判断する力」が、新しく必須のスキルになります。手で書く力がゼロでいいわけではありませんが、それ以上に「読んで判断する力」が効いてきます。未経験の方にとっては、ここはむしろ朗報かもしれません。営業や事務で培った「相手の意図を読む」「成果物の出来を見極める」感覚が、そのまま活きる場面があるからです。

ただし、ここで正直に注意点も書いておきます。「読んで判断する力」は、コードをまったく知らない状態では身につきません。Vibe coding で学習を始めるとしても、出てきたコードを「これは何をしているのか」と理解しようとする姿勢は欠かせません。「書かせて満足」で終わると、判断する力が育たず、結局どこかで止まります。この点は セクション 7 の「スキル劣化感」とも地続きの話です。

03-6 5 軸まとめ表

5 軸を 1 枚の表にまとめます。

軸従来のコーディングVibe coding私の業務実感
指示の粒度1 行ずつ自分で書く目的・要件を粗く渡す「何を」に集中できるようになった
レビュー姿勢自分が書いたものを点検AI 出力を読み込む側に回るレビューが主作業になった
設計の主導権人間が握る人間が握り続ける必要があるここを手放すと後で崩れる
速度一定立ち上がりは速い／実効は場面次第「絶対速い」とは言えない
学習曲線文法・実装力を積む読む・方向づける・判断する力営業の「意図を読む」感覚が活きる

04 — Vibe coding を Claude / Cursor で実践する——2 大ツールでの感覚

📖 この章で使う用語

  • Claude Code：ターミナル（文字で命令する画面）で動くエージェント型の AI。フォルダ単位でコードを書き換えてくれます。
  • Cursor（カーソル）：AI 機能を内蔵した総合エディタ。Agent モード／Tab 補完／Cmd+K といった機能を持ちます。
  • CLAUDE.md / Cursor Rules：AI に「このプロジェクトの作法・文体・方針」を渡す設定ファイル。Vibe coding の「方向づけ」を仕込んでおく場所です。
  • Agent モード：目的を伝えると、AI が複数のファイルを自分で書き換えていくモード。

ここからは、私が業務で常用している Claude Code と Cursor で、Vibe coding が実際にどう成立するかをお伝えします。ツールのスペック比較はここではしません（それは親記事の AI コーディングの 3 レイヤー整理へ）。あくまで「Vibe coding スタイルとして使うときの感覚」に絞ります。

04-1 Claude Code での Vibe coding ループ

Claude Code はターミナルで動くタイプです。私の典型的な使い方は、こうです。

  1. 日本語で目的を渡す（例：「このフォルダにある CSV を読み込んで、月別の集計を出す関数を足して」）
  2. Claude Code がファイルを書き換える
  3. 出てきた差分（変わった箇所）を読む
  4. 気になる箇所を「ここをこうしたい」と方向で指示し直す

この「目的を渡す → 差分を読む → 方向で直す」の往復が、Claude Code での Vibe coding ループです。私が業務で気をつけているのは、3 番目の「差分を読む」を飛ばさないことです。Claude Code は気持ちよく書いてくれるので、つい「動いたから次へ」と進みたくなります。でも、ここで差分を読む一手間が、後の事故を防ぎます。

# Claude Code を起動して、目的だけ渡す（細かい実装は指定しない）
claude

# プロンプト例（細部を書かず、目的と要件だけ）
> sales.csv を読み込んで、月ごとの売上合計を返す関数を utils.py に足して。
> 金額が空のときは 0 として扱って。

ここで効くのが、CLAUDE.md というファイルです。プロジェクトのルートに置いておくと、Claude Code が毎回それを読んで作法を守ってくれます。Vibe coding の「方向づけ」を、毎回口で言う代わりに、ファイルに書いておくイメージです。

# CLAUDE.md（プロジェクトの作法を AI に渡しておくファイル）

## コーディング方針
- 関数には日本語のコメントで「何をするか」を 1 行入れる
- 例外処理は握りつぶさず、必ずログに残す
- 新しい外部ライブラリを足すときは、先に理由を一言説明してから

## やってほしくないこと
- 既存のテストを勝手に消さない
- 秘密鍵・パスワードをコードに直書きしない

この「方向づけをファイルに仕込む」やり方は、私が業務で実際にやっている工夫です。毎回同じ注意を口で言わずに済むので、レビューがだいぶラクになりました。

04-2 Cursor での Vibe coding ループ

Cursor は、AI 機能を内蔵したエディタです。Claude Code がターミナル中心なのに対して、Cursor は普通のエディタの中で AI が動くので、コードを見ながら進めたい人に向いています。私が Vibe coding として使うときは、主に 3 つの機能を使い分けます。

  • Agent モード：目的ベースで「このファイルに〇〇機能を足して」と指示すると、複数ファイルを横断して書き換えてくれます。Vibe coding の主役です。
  • Tab 補完：書いている途中で続きを予測してくれます。流れを止めずに済むので、思考のリズムが切れません。
  • Cmd+K：選択した部分だけを「ここをこう直して」と部分的に書き換えられます。
# Cursor の Agent モードへの指示例（目的ベース）

このプロジェクトに、お問い合わせフォームの送信処理を足してください。
- 入力チェック（必須項目・メール形式）も入れて
- 送信後は「ありがとうございました」を表示
- エラー時は理由を画面に出す

Cursor にも「方向づけ」を仕込む場所があります。Cursor Rules という設定で、文体や方針を渡しておけます。これも Vibe coding の方向づけを毎回口で言わずに済ませる仕組みで、私は CLAUDE.md と同じ発想で使っています。

私の感覚では、Claude Code と Cursor は「どちらか一方」ではなく、場面で行き来するものです。新しい機能の骨格をまるごと作るときは Claude Code でフォルダ単位に任せ、細かく見ながら育てたいときは Cursor に切り替える。Vibe coding は道具を固定するものではなく、「目的を渡して、出力を読んで、方向で直す」というスタイルそのものなので、その回し方ができればツールはまたいで構いません。

04-3 GitHub Copilot の立ち位置

GitHub Copilot も業務で使っていますが、Vibe coding の「主役」というより、流れを支える脇役という温度感です。Copilot は、書いている途中で続きを補完してくれる「補完中心」のツールです。目的を渡してフォルダ単位で任せる、という Vibe coding の中心的な動きとは少し性格が違います。

私の使い分けでいうと、「目的ベースで丸ごと書かせたい」ときは Claude Code か Cursor の Agent モード、「自分で書きながら手が速くなりたい」ときは Copilot、という感じです。どちらが上ということではなく、Vibe coding として主に回すのは前者の 2 つ、という整理です。

04-4 ツール選びは「3 レイヤーのどこを主に使うか」

どのツールを選ぶかは、結局「AI コーディングの 3 つのレイヤー（補ってくれる系・対話する系・自分で動く系）のうち、自分はどこを主に使いたいか」で決まります。この全体地図は本記事の射程を超えるので、AI コーディングを 3 レイヤーで整理した親記事に譲ります。Claude Code 単体の詳しい使い方はClaude Code の使い方をまとめた記事、Cursor 単体はCursor の使い方記事で深掘りしています。

05 — Vibe coding とツール選び——「合うツール」を Vibe coding 視点で見る

📖 この章で使う用語

  • Bolt.new / v0（ボルト・ドットニュー／ブイゼロ）：自然言語でアプリや画面を丸ごと生成する Web 型のツール（公開情報からの紹介）。Vibe coding の象徴的な存在として名前が挙がります。
  • Aider（エイダー）：ターミナルで動く OSS（無料で公開されているソフト）の AI コーディングツール（公開情報からの紹介）。
  • Devin（デビン）：タスクを渡すと自律的に進める「AI エンジニア」型のツール（公開情報からの紹介）。

「結局、どのツールで Vibe coding をすればいいの？」という疑問に答えます。ただし、SERP でよく見る「おすすめツール 10 選」のような羅列はしません。ここでは 「Vibe coding スタイルに向くか」 という角度に絞って整理します。スペックの細かい比較表は、繰り返しになりますが親記事の AI コーディング整理へどうぞ。

05-1 Vibe coding に向く 3 ツール（業務で使っているもの）

私が業務で日常的に使っていて、Vibe coding の主戦場になっているのは、次の 3 つです。ここは私自身が毎日触っている範囲の話です。

  • Claude Code：目的を渡してフォルダ単位で書かせる、という Vibe coding の典型ループに一番フィットします。ターミナルに慣れている人向け。
  • Cursor：エディタの中で目的ベースの指示と部分修正を行き来できます。コードを見ながら進めたい人向け。
  • GitHub Copilot：補完中心で、書く流れを支える役。Vibe coding の主役というより、土台を支える存在。

この 3 つの中でどれが一番、という話ではなく、「目的を渡して書かせ、出力を読んで方向づける」というスタイルが回せるのがこの 3 つ、という整理です。

ざっくり、どんな人に向くかを並べると、こうなります。

ツール主な性格Vibe coding でこう向く
Claude Codeターミナルで動くエージェント型目的を渡してフォルダ単位で書かせる、本格的なループ向き
CursorAI 内蔵のエディタコードを見ながら目的指示と部分修正を行き来したい人向き
GitHub Copilot補完中心自分で書きながら手を速くしたい場面の土台

私の使い分けでいうと、新しい機能をまるごと作ってもらいたいときは Claude Code、既存のコードを見ながら少しずつ育てたいときは Cursor、自分でガリガリ書く日は Copilot を効かせておく、という感じです。

05-2 公開情報から整理するツール群（Aider / Bolt.new / v0 / Devin）

ここからは、私が業務の本番では使っておらず、手元で触った範囲と公式情報からの紹介になります。Vibe coding の文脈でよく名前が挙がるツール群です。

  • Bolt.new / v0：自然言語で「こういうアプリ・こういう画面が欲しい」と伝えると、丸ごと生成してくれる Web 型のツールです。コードを書かずにブラウザだけで形にできるため、Vibe coding の象徴的な存在として語られます。
  • Aider：ターミナルで動く OSS の AI コーディングツールです。Git と連携して差分を扱うのが特徴とされています。
  • Devin：タスクを渡すと自律的に作業を進める「AI エンジニア」型として知られています。

これらは「自然言語で丸ごと生成」という Vibe coding の極端な形を体現しているので、概念を掴む上では知っておくと役立ちます。ただ、私が業務の本番でガッツリ使い込んだわけではないので、ここでは「こういうものがある」という紹介にとどめます。詳しい使用感は、それぞれの公式情報を確認してください。

出典: v0 by Vercel｜Vercel 公式（取得：2026-06-02） 出典: Aider｜公式サイト（取得：2026-06-02）

05-3 「おすすめは？」への誠実な答え方

最後に、「結局おすすめはどれ？」への私の答えです。「絶対これ」とは申し上げません。 これは逃げではなく、Vibe coding はツールより「自分の業務スタイル」に左右されるからです。

判断軸はシンプルで、「自分が普段どこで作業しているか」から逆算するのが現実的です。ターミナルで作業することが多いなら Claude Code、エディタ中心なら Cursor、まずはブラウザだけで何か形にしてみたいなら Bolt.new や v0 のような Web 型から、という具合です。私の場合は、業務でターミナルもエディタも使うので、Claude Code と Cursor を場面で使い分けています。

06 — 5 ステップで始める Vibe coding——初心者向け 30 分マイルストーン（やり方）

📖 この章で使う用語

  • Hobby プラン：Cursor の無料プラン。お金をかけずに試せます。
  • 無料クレジット：新しくアカウントを作ると配られる「使える金額分」のクーポンのようなもの。

「読むだけでなく、今日 1 回やってみたい」という方へ。未経験〜初級者が 30 分で Vibe coding を 1 回体験する最小手順を 5 ステップで書きます。完璧を目指さず、「感覚で AI に任せて、出てきたものを読む」という往復を 1 周することがゴールです。

06-1 5 ステップ一覧

ステップ内容所要時間
Step1Claude.ai か ChatGPT 無料版で「〇〇するコードを作って」と目的だけ伝える5 分
Step2Cursor の無料プランを入れて、Agent モードで目的ベース指示10 分
Step3出てきたコードを「読む」（分からない箇所は AI に聞く）5 分
Step4気に入らない箇所を「ここをこうしたい」と感覚で指示し直す5 分
Step5動かして確認、人間レビュー（「動いた＝OK」にしない）5 分

06-2 各ステップ詳説

Step1（5 分）：目的だけ伝える。 まずは無料のチャットで足慣らしです。Claude.ai か ChatGPT 無料版を開いて、目的だけ伝えます。細かい実装は指定しないのがコツです。これが Vibe coding の入口の感覚です。

# チャットへの最初のプロンプト例（目的だけ、実装は書かない）

Python で、指定したフォルダの中にある画像ファイル（jpg / png）の
枚数を数えて表示するコードを作ってください。
画像が 1 枚もないときは「画像はありませんでした」と出して。

ここで「for 文を使って」「os ライブラリで」などの実装指定をあえて書かないのがポイントです。「何が欲しいか」だけ伝えて、書き方は AI に委ねる。これが Vibe coding の感覚の出発点です。対話型 AI の最初の触り方はChatGPT の始め方をまとめた記事も参考にしてください。

Step2（10 分）：エディタで目的ベース指示。 次に Cursor を入れます。無料の Hobby プランで十分です。新しいフォルダを開いて、Agent モードで「このフォルダに、簡単な ToDo リストを作る HTML を作って」のように目的を渡します。Cursor の詳しい操作はCursor の使い方記事にあります。

Step3（5 分）：出てきたコードを「読む」。 ここが Vibe coding でいちばん大事な練習です。出てきたコードを、分からないなりに眺めてみます。理解できない箇所があったら、そのまま AI に聞きます。

# 分からない箇所を AI に聞くときのプロンプト例

さっき作ってもらったコードの 5 行目、これは何をしているか
プログラミング初心者にも分かるように、日本語で説明してください。

「これ何してる？日本語で」と気軽に聞けるのが、AI を相棒にする Vibe coding の良いところです。これが「方向づける力」の第一歩になります。

Step4（5 分）：感覚で指示し直す。 「ボタンの色を変えたい」「文言をもう少し優しくしたい」など、気に入らない箇所を感覚で伝えます。細かいコードは書かず、「ここをこうしたい」と方向だけ渡すのがポイントです。

# 感覚で方向だけ渡す指示の例（細かいコードは書かない）

完了ボタンの色を、もう少し落ち着いた青にして。
あと、削除ボタンは押し間違えが怖いので、押したときに
「本当に消しますか？」と一度確認が出るようにして。

Step5（5 分）：動かして、人間レビュー。 最後に動かして確認します。ここで大事なのは、「動いた＝OK」にしないこと。「動くけど、この作りで大丈夫か？」と一度立ち止まる癖を、最初の日からつけておきます。これは セクション 7 で扱う落とし穴を防ぐ、いちばん効く習慣です。

06-3 「動いた＝OK にしない」を最初の日から

繰り返しになりますが、初日から身につけてほしいのは「動いた＝OK にしない」という姿勢です。AI が書いたコードは、たいてい「とりあえず動く」状態にはなります。でも、動くことと「正しく・安全に・後で読める」ことは別物です。営業時代、「契約が取れた＝成功」ではなく「その後も続く関係になったか」で本当の成果を測っていたのと、同じ感覚です。動いたあとに一拍置いて読む。この一手間が、Vibe coding を長く続けられるかどうかを分けます。

07 — Vibe coding の落とし穴 5 個——設計の暗黒化・引き継ぎ困難・セキュリティ盲点・コスト爆発・スキル劣化感

📖 この章で使う用語

  • 設計の暗黒化：「なぜこの作りになっているのか」を、誰も説明できなくなった状態。
  • 引き継ぎ困難：自分でも説明できないコードが増え、他人や未来の自分に渡せなくなること。
  • 従量課金：使った分だけ請求される料金体系（AI の API 利用が代表例）。タクシーのメーターのイメージで、コスト爆発の背景になります。

Vibe coding は便利ですが、油断すると刺さる落とし穴があります。ここは私自身が業務で「ヒヤッとした」実感をベースに、5 つを「症状 → なぜ起きる → 対処」の順で書きます。AI コーディングに慣れてくると「なんだか疲れる」と感じる場面が出てくるのですが、その正体の多くがここにあります。

先に全体像を表にします。共通して効く対処は、結局「人間が読むこと」と「設計を握り続けること」に集約されます。

落とし穴ひとことで言うと効く対処
設計の暗黒化なぜこの作りか誰も説明できない設計判断は人間が握る
引き継ぎ困難自分でも説明できないコードが溜まる「読む力」を維持する
セキュリティ盲点脆弱性・機密漏れを見落とす人間レビュー＋ガイドライン
コスト爆発従量課金・上限に当たるセッション・差分サイズの管理
スキル劣化感自分で書けるか不安になるAI なしで書く時間を残す

07-1 設計の暗黒化

症状：機能は増えていくのに、「なぜこの構造なのか」を誰も説明できなくなる。 なぜ起きる：実装だけでなく設計判断まで AI に任せ続けると、人間の頭の中に「全体の地図」が残らなくなるからです。 対処：セクション 3 で書いたとおり、設計の主導権だけは人間が握り続けることです。私は「何を、どういう構造で作るか」は自分で決めてから、実装を AI に渡すようにしています。ここを手放した瞬間に暗黒化が始まります。

07-2 引き継ぎ困難

症状：自分でも中身を説明できないコードが溜まり、チームの他の人や、半年後の自分に渡せなくなる。 なぜ起きる：「動いたから次へ」を繰り返すと、読まずに通したコードが積み上がるからです。 対処：「書く力」は AI に委ねても、「読む力」は自分で維持することです。私は、AI が書いたコードでも、後で人に説明できる状態かを基準にレビューしています。読んで理解できないものは、理解できるまで AI に聞くか、書き直してもらう。地味ですが、これが一番効きます。

07-3 セキュリティの盲点

症状：感覚で通したコードに、脆弱性や、機密情報の入力ミスが紛れ込む。 なぜ起きる：「動くこと」だけを見ていると、安全性のチェックが抜け落ちるからです。AI も、明示的に頼まない限りセキュリティを最優先にはしてくれません。 対処：人間レビューと、チームのガイドラインです。これは セクション 10 で詳しく扱いますが、特に機密情報を AI に入力しない運用と、生成されたコードの脆弱性チェックは外せません。レビューの具体的なやり方はAI コードレビューの記事にまとめています。

07-4 コスト爆発

症状：気づいたら API の従量課金やサブスクの上限に当たっている。 なぜ起きる：Agent モードで AI を回し続けると、その分だけ料金が積み上がるからです。タクシーのメーターと同じで、走らせ続ければ上がります。 対処：セッション時間や、一度に扱う差分のサイズを管理することです。私は「大きな変更を一気に投げない」「区切りごとに止めて読む」を意識しています。これは結果的にレビューもしやすくなるので、一石二鳥です。

07-5 スキル劣化感

症状：「自分は、もう AI なしでコードを書けるんだっけ？」という不安が出てくる。 なぜ起きる：手を動かす部分を委ね続けると、書く感覚が鈍る 気がする からです。 対処：ここは正直に書きます。「書く力」は委ねても問題ない場面が増えてきました。ただ、「読む・設計する・判断する力」は意識的に維持する必要があります。私の場合、たまに「AI なしで書く時間」をあえて作って、感覚を鈍らせないようにしています。スキル劣化への不安は、AI コーディングに慣れてきた人ほど感じやすいものです。この「疲れる」感覚との付き合い方はAI コーディングの記事でも触れています。

08 — チームで Vibe coding を導入する——ペアプロ活用とレビューゲートの設計

📖 この章で使う用語

  • ペアプロ（ペアプログラミング）：2 人 1 組で開発する手法。1 人が運転（手を動かす）、1 人が助手席（確認・方向づけ）の役割。
  • レビューゲート：本流のコードに混ぜる前に、必ず人間が確認する関門。空港の保安検査のイメージ。
  • CI（継続的インテグレーション）：変更のたびに、自動でビルド・テスト・チェックを回す仕組み。

Vibe coding を個人技で終わらせず、チームの開発文化に上げるときの設計について書きます。ここは、私が社内で AI 活用を推進してきた経験の射程です。結論を先に言うと、Vibe coding はチームでやるなら「レビューの仕組み化」とセットでないと崩れます。

08-1 ペアプロとの相性

Vibe coding は、ペアプロと相性が良いです。理由は、Vibe coding ではレビューが主作業になるからです。

具体的には、1 人が目的を口頭で渡して AI に書かせる役、もう 1 人が出てきた出力を読んで判断する役、という分担ができます。従来のペアプロは「書く人」と「見る人」でしたが、Vibe coding のペアプロは「方向づける人」と「読む人」になります。2 人の目で AI 出力を見るので、後述の落とし穴も拾いやすくなります。

08-2 レビューゲートの設計

チームで一番大事なのは、レビューゲートです。AI が書いた差分は、必ず人間レビューと CI を通してからマージする、というルールを明文化します。

「Vibe coding だから速い、だから確認も省く」は最悪の組み合わせです。速く書ける分、確認はむしろ手厚くする。私が推進するときは、「人間が手を引いてはいけない箇所」を先にチームで決めておきます。たとえば、お金の計算に関わる箇所、個人情報を扱う箇所、外部にデータを送る箇所などは、AI が書いても必ず人間が読んでから通す、と線引きしておく。こうしておくと、「どこまで AI に任せていいか」でチームが迷わなくなります。レビューゲートを CI（自動チェックの仕組み）に組み込むやり方は、Claude Code Action を使った CI 連携の記事で具体的に書いています。

08-3 方向づけのチーム共有

セクション 4 で書いた CLAUDE.md や Cursor Rules は、個人の手元に置くだけでなく、リポジトリにコミットしてチーム全員で共有するのがおすすめです。

理由は、属人化を防ぐためです。「あの人の手元設定だけ良い感じ」では、チーム全体の品質が揃いません。方向づけのファイルをチームの共有物にしておくと、誰が Vibe coding しても、同じ作法・同じ方針で AI が動きます。私が業務で実感したのは、「方向づけをチームで共有しない」と、せっかくの工夫が一人の中で閉じてしまう、ということでした。

08-4 コード文化差への配慮

最後に、正直なところを書きます。Vibe coding の許容度は、チームや組織によって違います。

新しいものを積極的に取り入れる文化のチームもあれば、慎重に進める文化のチームもあります。どちらが正しいということはありません。絶対の正解はないので、自分のチームの文化に合わせて、導入のペースとルールを調整するのが現実的です。私の場合も、いきなり全面導入ではなく、レビューゲートを固めてから少しずつ範囲を広げる、という進め方を取りました。

推進する側として実感したのは、「最初の小さな成功体験」を一緒に作ると、チームの納得感がまるで違う、ということです。いきなり大きな機能で試すのではなく、誰かが困っている小さな作業を Vibe coding で片付けてみせる。「これなら使えそう」という手応えが 1 つあると、慎重派のメンバーも自分のペースで試し始めてくれます。営業時代に、新しいやり方を上から押し付けるより、まず一人の成功例を見せたほうが広がりが早かったのと、同じ感覚です。

09 — Vibe coding を、職種別にどう活かせるか（非エンジニアのユースケース 5 本）

📖 この章で使う用語

  • Markdown（マークダウン）：見出しや箇条書きを記号で書く、軽い文章フォーマット。メモアプリでよく使われます。
  • 叩き台：完成前の下書き・ドラフト。「まずこれを土台に直していこう」という最初の形。

「Vibe coding はエンジニアの話でしょう？」と思った方へ。Vibe coding の核は「目的を伝えれば細部は AI が書く／作る、人間はレビューと方向づけに回る」というスタイルです。これは、コードを書かない人の日常業務にもそのまま届きます。ここでは 5 つの職種で、Before / After / 所要時間 / 最初の壁の 4 点を具体的に書きます。

09-1 営業職：提案資料の叩き台を目的ベースで生成する

Before：商談メモを見ながら、提案資料を 1 から組み立てるのに 1 時間以上かかる。 After：商談メモを AI に渡し、「この相手の不安に寄り添う提案の骨子を作って」と目的だけ伝えると、叩き台が数分で出てくる。中身を読んで方向づけし、自分の言葉に直す。 所要時間：初回は AI に慣れるのに 30 分、以降は資料 1 本あたり 15 分程度。 最初の壁：「目的を言葉にする」こと。営業時代の私なら、ここは得意分野だったと思います。相手の意図を読む癖が、そのまま「AI への目的の渡し方」に活きます。

09-2 事務職：定型レポートを「こうしたい」と感覚で指示する

Before：毎月の定型レポートを、Excel を手で操作して 30 分かけて作る。 After：「この CSV を、部署ごとの合計が分かる表にまとめて」と感覚で指示すると、整形の手順を AI が組んでくれる。細部は AI に任せ、出てきたものを確認する。 所要時間：初回セットアップ 30 分、以降は月 5〜10 分。 最初の壁：最初は「どう頼めば伝わるか」が分からないこと。1 回うまくいくと、頼み方のコツが掴めます。

09-3 個人事業主：業務マニュアルやテンプレを目的ベースで作る

Before：請求書テンプレや業務マニュアルを、毎回ゼロから作る・調べる。 After：「フリーランス向けの請求書テンプレを Markdown で作って」と目的を渡し、出てきたものをレビューして自分の業務に合わせて整える。 所要時間：1 本あたり 20〜30 分。 最初の壁：出てきたものを「鵜呑みにしない」こと。特に金額や契約に関わる部分は、必ず自分で確認する習慣が要ります。

09-4 副業ライター：記事の構成やリライトを「方向だけ渡す」

Before：記事の構成を考え、リライトを 1 文ずつ手で直すのに時間がかかる。 After：「この記事を、初心者向けにもっと噛み砕いて」と方向だけ渡し、出てきた案を読んで取捨選択する。 所要時間：記事 1 本あたり、構成で 15 分、リライトで 20 分程度。 最初の壁：AI の文章をそのまま使うと、どこか平板になりがちなこと。「方向づけ」と「自分の言葉での仕上げ」をセットにするのがコツです。実は、この bon-bon-tools の記事作りでも、私は構成と方向づけを自分で握り、細部の組み立てを AI と往復する、Vibe coding 的なやり方を取り入れています。

09-5 エンジニア志望（未経験）：Vibe coding を「学習法」として使う

Before：参考書を読んでも、コードがなぜそう動くのか掴めず、手が止まる。 After：「ToDo アプリを作りたい」と目的を伝えて AI に書かせ、出てきたコードを「これは何をしている？」と聞きながら読んで学ぶ。 所要時間：1 日 30 分でも、毎日続けると効きます。 最初の壁：「書かせて満足」してしまうこと。Vibe coding を学習に使うときは、「読む力」を意識的に育てるのが肝心です。出力をただ眺めるのではなく、説明できるまで理解する。営業から未経験でエンジニアを目指した道のりは未経験エンジニア転職の記事にも書いています。

10 — Vibe coding のリスクと注意——人間レビュー必須・個人差・コード文化差・著作権/機密の三段安全網

📖 この章で使う用語

  • YMYL：読者の人生・お金・健康に関わる領域。断定を避けるべきテーマ、という意味で使います。
  • OSS ライセンス：オープンソースのコードを使うときに守る条件（MIT / Apache / GPL など）。
  • 著作権：作品を作った人の権利。AI が生成したコードの扱いは、今も議論が続いています。

Vibe coding を安全に続けるための注意をまとめます。ここは特に慎重に書きます。先に三段の安全網を置きます。

10-1 三段安全網のメタ宣言

  1. 「Vibe coding で誰でもエンジニアになれる／絶対これが安全」とは言いません。 個人差もコードの文化の違いもあり、断定はできません。
  2. 最終判断は、社内の法務・コンプライアンス部門、必要に応じて弁護士など専門家に委ねてください。 本記事は判断の材料を提供するもので、判断そのものを代わりにするものではありません。
  3. 公式の利用規約・ライセンスは、必ず最新版をご自身で確認してください。 AI ツールの規約は変わりやすいので、この記事の情報も「2026 年 6 月時点」のものとしてお読みください。

10-2 人間レビューは外せない

繰り返しになりますが、感覚で通したコードを「動いた＝OK」で本番に乗せてはいけません。セクション 7 の落とし穴と、セクション 8 のレビューゲートで書いたとおり、人間のレビューは Vibe coding の前提です。速く書ける分、確認は手厚く。これが Vibe coding を事故なく続ける一番のコツです。

10-3 個人差・コード文化差

Vibe coding には、合う人・合わない人、合うチーム・合わないチームがあります。「みんながやっているから」ではなく、自分や自分のチームに合うかを見極めるのが先です。私の周囲でも、Vibe coding を快適に使う人もいれば、自分で書くほうが落ち着くという人もいます。どちらも正解です。

10-4 著作権・機密・脆弱性

3 点、押さえておきたいことがあります。1 つ目は著作権で、AI が生成したコードの扱いは法的にも議論の最中です。商用で使うものは、特に慎重に確認してください。2 つ目は機密情報で、社外秘のコードやデータを AI に入力しない運用が基本です。組織として安全に使いたい場合は、AWS Bedrock や Google Cloud の Vertex AI 経由で、データが学習に使われない構成を選ぶ、という選択肢もあります。3 つ目は脆弱性で、AI 生成コードにセキュリティ上の穴がないか、レビューで必ず確認します。

10-5 スキル劣化への組織対応

セクション 7 のスキル劣化感に、組織としてどう向き合うか。私のおすすめは、チームとして「AI なしで書く時間」を意図的に残すことです。全部を Vibe coding に寄せるのではなく、たまに自分の手で書く機会を作る。これは、チームの「読む力・設計する力」を維持するための投資だと考えています。

11 — よくある質問（FAQ）

Q1: Vibe coding とは何ですか？

A. 「細かく書かず、感覚で AI に書かせて、人間はレビューと方向づけに回る」コーディングスタイルです。2025 年 2 月に Andrej Karpathy が X で言及したことで広まった語とされています（公開情報）。詳しくは セクション 2 をどうぞ。

Q2: Vibe coding で誰でもエンジニアになれますか？

A. 「絶対なれる」とは申し上げません。個人差もコードの文化の違いもあります。「書く力」を AI に委ねても、「読む・設計する・判断する力」は自分で育てる必要があり、人間のレビューも外せません。詳しくは セクション 7 と セクション 10 を参照してください。

Q3: Vibe coding はどのツールでやればいいですか？

A. 「絶対これ」とは申し上げません。私が業務で使っているのは Claude Code / Cursor / GitHub Copilot です。Bolt.new / v0 などは公開情報からの紹介になります。自分が普段どこで作業しているかから逆算するのが現実的です。セクション 5 で整理しています。

Q4: Vibe coding と従来のコーディングは何が違いますか？

A. 指示の粒度・レビュー姿勢・設計主導権・速度・学習曲線の 5 軸で違います。特に「設計の主導権だけは人間が握り続ける」のがコツです。セクション 3 で 5 軸を表にまとめています。

Q5: Vibe coding の危険・落とし穴は？

A. 設計の暗黒化・引き継ぎ困難・セキュリティ盲点・コスト爆発・スキル劣化感の 5 つが代表です。人間レビューと「読む力」の維持が、対処の軸になります。セクション 7 で詳しく扱っています。

関連記事

出典

訂正・お問い合わせ

本記事の内容に誤り・古い情報・追加情報のご提案などありましたら、send@bon-bon-tools.com までご一報ください。事実誤認は速やかに訂正し、訂正履歴を本セクション末尾に追記する運用です。なお、Vibe coding および AI コーディングツールに関する公式情報（Anthropic / OpenAI / Google / GitHub / Cursor / Vercel 等の利用規約・料金・モデル仕様等）は、必ず各社の公式ドキュメントをご確認の上、AI 生成コードの商用利用・著作権・機密の扱いの最終判断は、社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

新しい記事のお知らせを受け取る → 登録（準備中）