Vibe Codingとは、Specとの違い3つ

Vibe Coding とは何か。説明は人によって3通りくらいに分かれていて、私も最初はどれが本物か分からず止まっていました。

先に答えを置いておきます。

本物は1つだけで、2025年2月のAndrej Karpathyのツイートが原義です。残りはあとから拡張された意味で、原義とはズレが出てきています。ただ原義だけを守っても仕事では使えません。原義と、2026年の現場で「Vibe Coding でやろう」と言われたときの実態を、両方知る必要があります。チーム内で用語が揃っていないと、設計の話をしているのに相手は組織論の話をしている、みたいな事故が起きます。

この記事では、Vibe Coding と Spec Coding の境界を、計画・制約・検証の3観点で整理します。Claude Code のどのモードがどちらに相当するかも実装例で示します。

Vibe Coding の原義 — Karpathyの一文

まず原義を貼ります。2025年2月2日のKarpathyのツイートです。

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.

「コードが存在することすら忘れて、vibe (雰囲気) に身を委ねる」。ここが肝です。Karpathy は続けてCursor Composer + Sonnet の名前を挙げていて、LLMが十分賢くなったから人間はコードを読まずに結果だけ見て進められるようになった、という文脈でこの言葉を置いています。実はこの一文がバズって、Collins Dictionary の2025年単語大賞になりました。

私がこれを読んで最初に思ったこと。

「カーナビなしで”なんとなく南”に走るドライブみたいだな」。楽しいし、目的地に着くこともある。ただし、着かないこともある。

Spec Coding の輪郭 — Vibe の反対側

Spec Coding は Vibe の反対側に置かれる言葉です。要件定義書やテスト仕様を先に書き、AIにそれに従ってコードを書かせます。やっていることは昔からあるウォーターフォール的な手順で、新しいのは「仕様を書く相手がAIになった」という点だけです。別名としては Spec-Driven Development (SDD) もあって、GitHub の spec-kit ではこちらが使われています。要は、同じ中身に別名がついているだけと思っていい。

ここまでは「Vibe = 感覚、Spec = 仕様」で済みます。

問題は、2026年の現場でこの2つの境界がぼやけ始めていることです。

3観点で境界を引き直す

私が実務で区別に使っているのは次の3つです。順に見ていきます。

観点1: 計画 — どこまで書いてから走るか

Vibe は走りながら考えます。Spec は走る前に仕様を固めます。

Claude Code で言うと、Vibe は「このバグ直して」とだけ打って Enter を押す使い方です。Shift+Tab を押さず、auto-mode のまま突っ走ります。Spec は Plan Mode を使う使い方で、Shift+Tab で Plan Mode に入り、「JWTで認証を実装したい。既存のusersテーブルにtokenカラムは無い。計画を出して」と頼みます。計画が返ってきたら、人間が読んで修正指示を出し、合意が取れてから実装に進みます。この順序の反転が肝です。

ここで注意したい点がひとつ。

「Plan Mode = Spec Coding」ではありません。Plan Mode は Vibe の中に挟む計画ステップにも使えますし、計画を書いたあと詳細は雰囲気で任せるという中間ゾーンの使い方も普通です。

計画の粒度で見るほうが実態に合います。

• 粒度が粗い: 「ユーザー登録と認証」程度の指示 → Vibe
• 粒度が中くらい: 画面遷移・API エンドポイント・DBスキーマまで指定 → Vibe と Spec の中間
• 粒度が細かい: テスト仕様と受け入れ条件まで書く → Spec

私の体感では、1人で遊ぶときは粒度が粗く、本番に出すコードを書くときは細かくなる、という使い分けになります。

観点2: 制約 — どこまで仕組みで縛るか

Vibe は制約を最小にします。Spec は制約を仕組みに埋め込みます。ここで言う制約は、プロンプトではなく環境のことです。CLAUDE.md で「linter を必ず通して」と書いても、AIは忘れます。pre-commit hook で linter を強制すれば、忘れません。この差は小さく見えて、本番で効きます。

AGENTS.md に書くのと hook で縛るのは、「ほぼ常に」と「例外なく」の違いです。 — SmartScope

Spec Coding の場合、仕様と同時に検証の仕組みも用意します。テスト、型チェック、linter、CI、hook。これらが揃っていると、仕様から外れたコードは commit 自体がブロックされます。

Vibe Coding の場合、制約は人間の目視です。「書いて、動かして、違ったらまた書き直す」。制約が弱いので速いですが、本番で変なエッジケースを踏みます。

ここが私が1番こだわる境界です。制約の設計まで含めて考える流派は、2026年に ハーネスエンジニアリング と呼ばれ始めました。Spec Coding の次の層にあたります。

観点3: 検証 — 誰が「できた」を判定するか

Vibe は人間が判定します。Spec は仕組みが判定します。Vibe Coding で「できた」を決めるのは、画面を見ている自分です。想定どおりに動けば OK、違和感があれば書き直し。これはこれで速い。

Spec Coding で「できた」を決めるのは、テストと検証ジョブです。仕様に書いた受け入れ条件が通れば OK、通らなければ修正。人間は条件を書く側に回ります。両者とも「できた」を決めているのは誰か、を意識できていないと、振り返りで議論が噛み合いません。

2026年の現場では、Vibe と Spec を1日の中で切り替えて使うのが現実的だと感じています。朝イチの新機能プロトタイプは Vibe、昼過ぎのリファクタリングは Spec、夕方のバグ修正は Vibe、みたいに。

Agent Framework は Vibe でも Spec でもない

ここでよく混ぜられるのが Agent Framework です。LangChain、CrewAI、AutoGen、OpenAI Agents SDK。

Agent Framework は Vibe か Spec か、という2択に乗りません。別の軸にいます。Agent Framework が解いているのは、「エージェントが使える道具とオーケストレーション」です。計画の粒度や検証の仕組みは、Framework の外側で別に設計します。だから「LangChain を入れたから Spec Coding になった」という言い方は変で、両者は違うレイヤの話なのです。

• Vibe / Spec の軸は、人間とAIの合意形成のスタイル
• Agent Framework の軸は、AIが使うツールの定義方法
• ハーネスエンジニアリング の軸は、環境全体 (制約・ライフサイクル・フィードバック)

別軸として分けておけば勘違いが起きません。

Claude Code のどのモードがどちらか

Claude Code の実装から見ると、こう整理できます。

Boris Cherny (Claude Code 開発者) 本人は「80%のセッションを Plan Mode で始める」と言っています。計画→並列実行→合流、という流れです。

これは Vibe と Spec の中間ゾーンで、2026年の実務のスイートスポットだと私は感じています。モデルが賢くなるほどハーネスは薄くなっていく、という予測もあって、この境界はまた動きそうです。

まとめ — 「どっちで書いているか」を宣言する

Vibe Coding と Spec Coding は、どちらが優れているかの話ではありません。使い分けの軸です。

私が実務で意識している使い分けはこの3つでした。

• 計画: 走る前にどこまで決めるか
• 制約: 仕組みで何を縛るか
• 検証: 誰が「できた」を決めるか

同僚と話すときは「今これは Vibe で書くからレビューは画面見てね」とか「ここは Spec で書くから仕様書に目を通して」とか、宣言するといいです。相手が同じ言葉で返してくれると、無用な摩擦が消えます。

もう少し深く「エージェントが動く環境全体」を設計する話は、ハーネスエンジニアリング実践ガイド にまとめています。Vibe と Spec の外側にある、制約・ライフサイクル・フィードバックの層をどう組むかの話です。

面白くいきましょう。

---

参考

• Andrej Karpathy, Twitter (2025-02-02) “There’s a new kind of coding I call ‘vibe coding’…”
• Boris Cherny, “Inside Claude Code With Its Creator” — Y Combinator The Light Cone (2026-02)
• QubitTool, “Vibe Coding / Spec Coding / Harness Engineering” (2026)