vibe coding とは？原義と実務用法の違い・AIのコードを受け入れる判定手順

vibe coding（バイブコーディング）とは、AIが生成したコードの差分を読まずに受け入れながら開発を進めるスタイルのことです。提唱者が2025年2月2日のX投稿で使った原義は、「差分をもう読まない」ことそのものを指していました。

ところが、この語は広まる過程で意味が広がりました。Collins Dictionaryが2025年11月6日にWord of the Year 2025として選んだときの定義は「自然言語で促されたAIによるコード記述」で、差分を読むかどうかには触れていません。原義・辞書の定義・現場での使われ方の3つは、いま別のものを指しています。

そのため実務者にとっての本当の問いは「vibe codingとは何か」ではなく、「AIが書いたコードを、どこまで読まずに受け入れてよいか」になります。本記事はこの問いに、その場で実行できる4つのゲートで答えます。掲載しているコマンドと出力はすべて、筆者の手元（macOS／Node.js v23.9.0／npm 10.9.2／git 2.50.1、2026年8月2日実行）で合格・不合格の両方向を実行して確認したものです。

vibe coding とは何か — 原義と辞書の定義はずれている

vibe codingという語には、少なくとも3つの層があります。提唱者の原義、辞書に載った定義、そして現場で実際にそう呼ばれているもの。この3つを混ぜたまま議論すると話がかみ合いません。順に切り分けます。

原典 — 2025年2月2日のX投稿に書かれていたこと

提唱者はAndrej Karpathy（アンドレイ・カーパシー）氏。2025年2月2日のX投稿が初出です。X公式のoEmbed APIとInternet Archiveのスナップショットの両方で本文冒頭を照合したところ（2026年8月2日確認）、次の文言で始まっていました。

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. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good.

（訳）vibe codingと呼ぶ新しい種類のコーディングがある。完全に雰囲気に身を委ね、指数関数的な進歩を受け入れ、コードが存在することすら忘れる。LLM（たとえばSonnetを載せたCursor Composer）が良くなりすぎたので可能になった。

この投稿はXのlong postで、公式APIから逐語で取得できるのは冒頭280字までです。以降の部分は一次ソースとして取得できなかったため、ここからは学術論文が引用している形での二次引用として示します。Sarkar & Drososの論文 Vibe coding: programming through conversation with artificial intelligence（arXiv:2506.23253）の参考文献に、次の文言が収録されています。

I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy-paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension … It’s not too bad for throwaway weekend projects, but still quite amusing.

（訳）私はいつも「Accept All」を押す、差分はもう読まない。エラーメッセージが出たらコメントなしでそのまま貼り付ける、たいていそれで直る。コードは自分の理解を超えて育っていく……捨ててよい週末プロジェクトならそれほど悪くはない、まあ愉快ではあるが。

つまり原義は「感覚的な言葉で指示すること」ではありません。差分を読まず、常にAccept Allを押すこと。それ自体がvibe codingです。そして原文には最初から「捨ててよい週末プロジェクトなら（throwaway weekend projects）」という適用範囲の但し書きが入っています。この但し書きが、後述する4ゲートの出発点になります。

辞書の定義 — Collinsが2025年の言葉に選んだときの意味

Collins Dictionaryは2025年11月6日、Word of the Year 2025にvibe codingを選出しました。Collins公式ブログに載った定義は次のとおりです（2026年8月2日確認）。

the use of artificial intelligence prompted by natural language to write computer code

（訳）自然言語で促された人工知能を使ってコンピュータのコードを書くこと。

差分を読むかどうかには一切触れていません。原義より明らかに広く、ほぼ「AIにコードを書かせること」全般を指す定義になっています。同じ年のショートリストにはaura farming、taskmasking、broligarchy、biohacking、HENRY、micro-retirements、coolcations、glaze、clankerが並んでいました。辞書が言葉を採録するときは、提唱者の意図ではなく実際の使われ方を写し取ります。この時点で、原義とのずれは確定していたことになります。

実証研究が観測した「現場のvibe coding」

研究側も追いついています。前掲のSarkar & Drososの論文（arXiv:2506.23253、2025年6月29日投稿）は、約8.5時間のvibe codingセッション動画を分析した実証研究です。結論部分から引用します（2026年8月2日確認）。

vibe coding does not eliminate the need for programming expertise but rather redistributes it toward context management, rapid code evaluation, and decisions about when to transition between AI-driven and manual manipulation of code.

（訳）vibe codingはプログラミングの専門知識を不要にするのではなく、文脈管理・コードの高速な評価・AI主導と手作業をいつ切り替えるかの判断へと、その知識を再配分する。

同じ論文は、AIへの信頼は「一括受け入れ（blanket acceptance）ではなく反復的な検証を通じて」築かれるとも書いています。つまり原義の「全部Accept」は、観測された現場の実態とは一致していません。それでも語だけは残り、Collinsの広い定義とともに定着した、というのがいまの状況です。

3つの定義を1枚で見る

「vibe codingをやっています」と言う人が3つのどれを指しているかは、この表のどの行かを聞けば1回で確定します。

提唱者本人が1年後に書いたこと

提唱者自身も、2026年2月4日の投稿でこの語を振り返っています。X公式oEmbedで確認できた冒頭は次のとおりです（2026年8月2日確認）。

A lot of people quote tweeted this as 1 year anniversary of vibe coding. Some retrospective – I’ve had a Twitter account for 17 years now (omg) and I still can’t predict my tweet engagement basically at all. This was a shower of thoughts throwaway tweet that I just fired off

（訳）多くの人がvibe codingの1周年としてこれを引用した。少し振り返ると——Twitterのアカウントを持って17年になるが、いまだに自分のツイートの反応をほとんど予測できない。これは思いつきを垂れ流しただけの、放り投げたツイートだった。

この投稿も280字を超える部分は逐語で取得できなかったため、本記事は続きの内容には踏み込みません。ここで確認できるのは、提唱者本人が原典を「思いつきの放り投げ」と位置づけているという一点です。用語の定義を提唱者の言葉だけに求めるのは、もともと無理があるということでもあります。だからこそ、定義の議論ではなく適用範囲の判定に話を移します。

「読まずに受け入れてよい」場面と、そうでない場面

原義のvibe codingを、そのまま業務のコードに適用するのは危険です。しかし逆に「全部読め」と言ってしまえば、それはもうvibe codingではありません。やるかやらないかではなく、どこで線を引くかが実務上の問題です。

線引きの起点は、原文にすでに書かれていました。throwaway weekend projects（捨ててよい週末プロジェクト）。第一の判定軸は「そのコードを捨てるかどうか」です。ここから実務向けに4つの条件へ展開します。

判断を分ける4つの条件

1つ目がYesなら、原義のvibe codingをそのまま使って問題ありません。1つ目がNoで、2〜4のどれか1つでもYesなら、そのコードは「読まずに受け入れる」対象から外れます。

ただし「差分を読む」と言われても、何をどう見れば合格なのかが分からないと手が止まります。次章以降の4ゲートは、その「読み方」を機械が判定できる部分と、人間にしか判定できない部分に分解したものです。

vibe coding を実際にやってみる（最小手順）

ここでは特定のツールに依存しない最小手順を示します。製品名は1年で変わりますが、この3手順は変わりません。

手順1 — 捨ててよい場所を用意する

失っても困らない空のディレクトリを作り、Git管理下に置きます。Gitに入れる理由は2つ。あとで差分を見るためと、まずかったら丸ごと捨てるためです。

mkdir vibe-sandbox
cd vibe-sandbox
git init
git commit --allow-empty -m "empty baseline"

最初に空のコミットを作っておくと、AIが何を足したのかが常に差分として見えます。これがゲート2とゲート4の前提になります。なお git commit が「識別情報が設定されていない」と言って止まる場合は、先に git config user.name と git config user.email を設定してください。

手順2 — 小さい単位で指示を出す

一度に頼む範囲を、1ファイル・1機能に絞ります。範囲が大きいほど差分が膨らみ、あとで通すゲート4が重くなるためです。

× 「ECサイトを作って」
○ 「商品一覧を表示するHTMLとCSSを作って。カードレイアウトで、ホバー時に影をつけて」

指示の書き方そのものは本記事の担当外です。渡すべき要素を体系的に整理したものは AIに渡すプロンプトの5つの基本要素 にまとめてあります。

手順3 — 受け入れる前に4ゲートを通す

AIが出力しても、まだ受け入れません。次章の4ゲートを通してから受け入れます。ここまでが1サイクルで、あとはこれを繰り返すだけです。

【検証】AIのコードを読まずに受け入れてよいかを4ゲートで判定する

4ゲートは「読まずに受け入れてよいか」の足切りです。ゲート1〜3は機械が判定するので誰がやっても同じ結果になります。ゲート4だけが人間の仕事で、ここが基礎知識の差がそのまま出る場所です。

検証環境は macOS（darwin 25.5.0）／Node.js v23.9.0／npm 10.9.2／git 2.50.1、実行日は2026年8月2日です。以下のコマンドと出力は、すべて合格側と不合格側の両方を実際に走らせて確認しています。

ゲート1 — 構文が通るか

AIは出力を途中で切ることがあります。まず構文だけを機械に見せます。実行するのは言語に応じた1行です。

node --check path/to/file.js   # JavaScript
npx tsc --noEmit               # TypeScript
php -l path/to/file.php        # PHP

実際に構文エラーのあるファイルを通すと、次のように出ます（実測出力）。

$ node --check bad.js; echo "exit=$?"
/path/to/bad.js:2
if (a { console.log(a) }
      ^

SyntaxError: Unexpected token '{'
    at wrapSafe (node:internal/modules/cjs/loader:1666:18)
    at checkSyntax (node:internal/main/check_syntax:76:3)

Node.js v23.9.0
exit=1

ゲート2 — 差分に秘密情報が混ざっていないか

AIは、会話の中で見せた鍵をコードに書き戻すことがあります。また、例示用のダミーキーを本物が入るべき場所に埋めることもあります。ファイル全体ではなく、これから足す差分だけを走査します。

git add -A
git diff --cached -U0 -- '*.js' \
  | grep -E '^\+[^+]' \
  | grep -vE 'process\.env' \
  | grep -nEi '(api[_-]?key|secret|passwd|password|token|credential)[[:space:]]*[:=]|sk-[A-Za-z0-9_-]{16,}|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}|-----BEGIN [A-Z ]*PRIVATE KEY'

3種類の鍵と、2つの安全な環境変数参照を含むファイルをステージして通した実測結果です。

3:+const KEY = "sk-live-abcdef1234567890";
4:+const AWS = "AKIAIOSFODNN7EXAMPLE";
5:+const GH  = "ghp_1234567890abcdefghijABCDEFGHIJ1234";
exit=0

同じファイルにあった const pw = process.env.PASSWORD; と const ok = process.env.API_KEY; は環境変数の参照なので、正しく無視されています。秘密情報を含まない差分で走らせた場合は出力なし・終了コード 1 になることも確認済みです。

注意したいのは、思いつきで書いたパターンだと結果が逆になることです。次の素朴なパターンを、まったく同じ差分に通してみます。

git diff --cached -U0 -- '*.js' \
  | grep -nEi '^\+.*(api[_-]?key|secret|password|token|sk-[a-z0-9]{8,})'

実測結果です。

13:+++ b/secret.js
18:+const pw  = process.env.PASSWORD;
19:+const ok  = process.env.API_KEY;

diffのヘッダー行と、安全な環境変数の参照だけを拾い、本命の3つの鍵をすべて取り逃がしています。sk-[a-z0-9]{8,} が sk-live- のハイフンで切れるためです。上のパターンで ^\+[^+] を先に噛ませているのはヘッダー行を落とすため、grep -vE 'process\.env' を挟んでいるのは安全な参照を除くためです。秘密情報スキャンは「動いたように見えるが検出していない」が最悪の失敗なので、自作パターンは必ず、検出されるべき値と検出されてはいけない値の両方で試してください。

ゲート3 — 依存に既知の高危険度脆弱性がないか

AIは学習時点で一般的だったバージョンを指定しがちです。パッケージを足す指示を出した直後は、必ずここを通します。

npm audit --audit-level=high

不合格例として、意図的に古い minimist@0.0.8 を入れたプロジェクトで実行した実測出力です。

# npm audit report

minimist  <=0.2.3
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-vh95-rmgr-6w4m
fix available via `npm audit fix --force`
Will install minimist@1.2.8, which is a breaking change
node_modules/minimist

1 critical severity vulnerability

このとき終了コードは 1 です。同じプロジェクトで minimist@1.2.8 に上げ直すと found 0 vulnerabilities・終了コード 0 になることも確認しました。

ゲート4 — 差分の全行を自分の言葉で説明できるか

唯一の人力ゲートです。まず差分の規模を見て、それから中身を見ます。

git diff --cached --stat
git diff --cached

ゲート1〜3は誰がやっても同じ結果になりますが、ゲート4だけは読み手の基礎知識の量でそのまま結果が変わります。ここが「基礎知識があると何が違うのか」の正体です。

外れたときの分岐

4ゲートは品質保証ではない

ここは必ず押さえてください。4ゲートが全部通っても、そのコードが仕様どおりに動く保証にはなりません。4ゲートが判定しているのは「読まずに受け入れてよいか」であって「正しいか」ではありません。構文が通り、鍵が漏れず、依存が安全で、全行を説明できても、仕様を取り違えていれば普通に間違ったものが出来上がります。仕様どおりかどうかは、実際に動かして確かめるしかありません。

なお、ゲート4を通しやすくする実務的な近道もあります。動くコードを土台としてAIに渡し、その改造を頼むやり方です。土台を自分が理解していれば、差分の説明はそのぶん軽くなります。具体的なやり方は 動くコードを渡してAIにCSSアニメーションを作らせる手順 で扱っています。

ツールの選び方 — 製品名でなくタイプで選ぶ

vibe codingのツール紹介は、書いた瞬間から古くなります。製品名・価格・ショートカットは1年で変わるためです。ここではタイプで整理し、代表例は「2026年8月時点ではこれ」と割り切って添えます。

3つのタイプと、4ゲートとの相性

Claude Codeは公式ドキュメントで「agentic coding tool（コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携するツール）」と定義されており、ターミナル・IDE拡張・デスクトップアプリ・Webの複数の場所で動きます（Claude Code 公式Overview／2026年8月2日確認）。コマンドや設定ファイルの詳細は Claude Codeのコマンド一覧と実践ガイド にまとめています。

GitHub Copilotには無料プラン（Copilot Free）があります。有料はProが月額10 USドル、Pro+が39 USドル、Maxが100 USドル、組織向けのBusinessが1シート19 USドル、Enterpriseが39 USドルです（GitHub公式のプラン比較／2026年8月2日確認）。また現在のCopilotはOpenAI製モデル専用ではなく、Claude Opus 5・Claude Sonnet 5・Gemini 3.1 Pro などが選べるマルチベンダー構成です。「OpenAIとの共同開発だからOpenAIのモデルを使う製品」という理解は、現在は正確ではありません。

エディタ側の環境をどう整えるかは AI時代に残すべきVSCode拡張機能 で扱っています。AIが肩代わりする拡張機能と、残す価値のある拡張機能の切り分けです。

製品名で覚えると1年で古くなる（実例3つ）

「タイプで選ぶ」と言い切るのは、実際にこれだけ動いているからです。いずれも2026年8月2日に一次ソースで確認しました。

3つ目について補足すると、npmパッケージ自体は生きています（npmレジストリで確認：latest 2.1.220 / stable 2.1.212、非推奨フラグなし、2026年7月25日更新）。動かないわけではありませんが、公式が案内している導線ではありません。「1年前の記事に書いてあったコマンド」は、動いても最善とは限らないという典型例です。

Cursorのショートカットも同様です。Cmd+K は Inline Edit を開く、Tab は補完を受け入れる、で現行どおりですが、Cmd+L は「チャットを開く」専用キーではありません。公式のKeyboard Shortcutsでは、General欄でサイドパネルのトグル（モードにバインドされていない場合）、Code Selection欄で選択範囲を新しいチャットに追加と定義されています（Cursor公式 Keyboard Shortcuts／2026年8月2日確認）。

基礎知識があると何が変わるのか — ゲート4の正体

「基礎知識があるとAIへの指示の解像度が上がる」とよく言われます。間違ってはいませんが、これは測れません。測れない基準は行動を変えないので、4ゲートに置き換えます。

変わるのは「ゲート4を通せる差分の量」

ゲート1〜3は機械が判定するので、知識量に関係なく同じ結果が出ます。基礎知識の有無で変わるのは、ゲート4を通せる差分の量と速度だけです。

前掲の実証研究も同じ方向を指しています。vibe codingは専門知識を不要にするのではなく、文脈管理・コードの高速な評価・切り替え判断へ再配分する、という結論でした。読む量が減るのではなく、読む対象が変わるということです。

何を埋めればゲート4を通せるようになるか

ゲート4は「差分を1行ずつ説明できるか」なので、必要なのは網羅的な知識ではなく、目の前のコードを読み解ける最低限です。Web制作の文脈であれば、次の3つを順に埋めるのが最短になります。

• マークアップの意味が読める（要素の選び方・入れ子の妥当性）→ HTMLの基礎を練習問題で固める
• スタイルの効き方が読める（セレクタの優先度・レイアウトの仕組み）→ CSS実装テクニック集
• 処理の流れが読める（変数・条件分岐・非同期）→ JavaScript学習ガイド

学習の順番そのものを組み立てたい場合は AI時代のコーディング学習法 を参照してください。ツールの使い分けを含めたロードマップ側の担当です。

まとめると、vibe codingで成果を出せる人は「ノリで試して、知識で判断する」サイクルを回せる人です。ノリで試す部分は原義のまま、知識で判断する部分が4ゲートにあたります。

よくある質問（FAQ）

Q. vibe codingとは何ですか？

vibe codingの原義は、AIが生成したコードの差分を読まずに受け入れながら開発を進めるスタイルです。Andrej Karpathy氏が2025年2月2日のX投稿で提唱しました。原文のうち学術論文（arXiv:2506.23253）が引用している部分には「I “Accept All” always, I don’t read the diffs anymore（いつもAccept Allを押す、差分はもう読まない）」とあります。一方でCollins Dictionaryは2025年11月6日、この語をWord of the Year 2025に選び「the use of artificial intelligence prompted by natural language to write computer code（自然言語で促されたAIによるコード記述）」と、より広く定義しました。原義と辞書の定義がずれている点が、この語をめぐる混乱の原因です。

Q. vibe codingと従来のAI補完コーディングは何が違うのですか？

違いは「差分を読むかどうか」の一点です。AIの出力を読んで採否を判断しているなら、それはAI支援コーディングであって、原義のvibe codingではありません。逆に差分を読まず全部受け入れているなら、使っているツールが補完型でもターミナル型でも原義のvibe codingです。ツールの種類ではなく、受け入れ方の違いで分かれます。

Q. vibe codingは初心者でもできますか？

できます。ただし成果物を残すなら、本文で示した4ゲート（構文が通るか／差分に秘密情報がないか／依存に高危険度の脆弱性がないか／差分の全行を説明できるか）を通してください。ゲート1〜3はコマンド1行で機械が判定するので知識は要りませんが、ゲート4だけは基礎知識がないと通りません。基礎がない段階では、用途を「今日中に捨てるコード」に限定するのが安全です。

Q. AIが書いたコードをそのまま本番環境に出しても大丈夫ですか？

推奨しません。4ゲートが全部通っても、それは「読まずに受け入れてよいか」の判定であって、仕様どおりに動く保証ではありません。秘密情報に触れる・自分以外が保守する・インターネットに公開される、のいずれかに該当する場合は差分を読み、そのうえで実際に動かして仕様を確認してください。GitHubも利用規約で「You are responsible for reviewing, testing, and validating any Output before use（出力を使う前にレビュー・テスト・検証する責任は利用者にある）」と明記しています。

Q. vibe codingにおすすめのツールはどれですか？

製品名でなくタイプで選んでください。ターミナル型（代表例：Claude Code）、エディタ統合型（Cursor）、補完型（GitHub Copilot）の3つです。製品名で覚えると1年で古くなります。実例として、以前よく紹介されていたWindsurfは2026年8月2日時点でDevin Desktopに改称済みで、公式FAQに「Devin Desktop is the new name for Windsurf.」と書かれています。まず無料で試すなら、GitHub Copilotの無料プラン（Copilot Free）やCursorの無料プラン（Hobby）から始めるとよいでしょう。

Q. AIが同じ間違いを繰り返すときはどうすればいいですか？

指示の言い回しではなく、渡している前提が足りていない可能性が高いです。使っている言語やフレームワークのバージョン、既存コードの規約、動かす環境、してほしくないことの4点が抜けていないか確認してください。プロンプトに含めるべき要素の整理は AIコーディングのプロンプト基本 にまとめています。それでも直らない場合は、会話を続けずに新しいセッションで作り直すほうが早いことが多いです。

Q. vibe codingで作ったコードの著作権や商用利用はどうなりますか？

使っているツールの利用規約に従います。2026年8月2日時点で確認したところ、GitHubは利用規約のAI関連セクションで「GitHub does not claim ownership of your Input or Output（入力・出力の所有権を主張しない）」とし、Anthropicの消費者向け利用規約（2025年10月8日発効）は「we assign to you all of our right, title, and interest—if any—in Outputs（出力に対する当社の権利があれば、すべて利用者に譲渡する）」としています。ただしGitHubは同時に「出力が学習データに似た内容や第三者の著作権・オープンソースライセンスの対象を含む可能性がある」とも書いており、権利侵害がないことまでは保証されません。商用利用の前に、自分が使っているツールの規約を必ず自分で確認してください。

まとめ

• vibe codingの原義は「差分を読まず、常にAccept Allを押す」こと（2025年2月2日のX投稿）
• Collins Dictionaryの定義は「自然言語で促されたAIによるコード記述」で、原義より広い（2025年11月6日）
• 原文には最初から「捨ててよい週末プロジェクトなら」という適用範囲の但し書きが入っている
• 受け入れ判定は4ゲート（構文／秘密情報／脆弱性／全行を説明できるか）
• ゲート1〜3は機械、ゲート4だけが人間。ここが基礎知識の差の正体
• 4ゲートは足切りであって品質保証ではない。仕様どおりかは動かして確かめる

AI時代のWeb制作全体の見取り図は AI時代のWeb制作完全ガイド にまとめています。本記事の4ゲートは、その中の「AIの出力をどこまで信じるか」を担当する部分です。

本記事で参照した一次ソース（すべて2026年8月2日取得）

• vibe coding の原典となったX投稿（2025-02-02）／続きの逐語は arXiv:2506.23253 経由の二次引用
• 提唱者による1年後の振り返り投稿（2026-02-04）
• Collins Word of the Year 2025（2025-11-06）
• Claude Code 公式Overview（定義・インストール方法）
• Cursor 公式 Keyboard Shortcuts／Models & Pricing（Composer 2.5の記述）
• GitHub Copilot のプラン一覧・対応モデル／GitHub 利用規約（AI機能の条項）
• Devin Desktop 公式（Windsurf からの改称）
• Anthropic 消費者向け利用規約（2025-10-08発効・出力の権利）