AIシリーズ面接14：Vibe CodingとSpec Codingの違いは？
これはほとんどのプログラマーが直面する問題です。Vibe Coding と Spec Coding は、大規模言語モデル（LLM）を活用したプログラミングにおける2つの全く異なる作業パラダイムです。その核心的な違いは、AIに与える「入力」が曖昧な感覚なのか、正確な仕様なのかという点にあります。
一、料理を例にVibe CodingとSpec Codingの違いを簡単に説明
- Vibe Coding = 友達に「辛いものが食べたい」と言い、友達が感覚で料理を作り、一口食べて「もう少し塩辛くして」と言い、さらに塩を加える。味は驚くほど良いかもしれないが、別の友達が作ると全く異なるものになる。
- Spec Coding = レシピを書く：「郷県豆瓣醬20g、牛肉スライス150g、セリ50g、強火で2分炒め、火を止める前に砂糖3gを加える」。異なる料理人でもレシピ通りに作れば、味はほぼ一致する。
二、それぞれの定義
| 次元 | Vibe Coding | Spec Coding |
|---|---|---|
| 別名 | 感覚駆動プログラミング、即興プロンプト | 仕様駆動プログラミング、ドキュメント優先 |
| 入力形式 | 「見た目が良くて、テクノロジー感のあるログインページを作って」 | 「ログインページにはメールアドレス/パスワード入力欄、ログイン状態保持チェックボックス、送信ボタンを含む；フロントエンドはReact + Tailwindを使用；フォームバリデーションルール：メール形式、パスワード長≥8；失敗時は赤色のエラーメッセージを表示……” |
| AIの使い方 | 対話型、反復型：大まかな方向性を与える → 出力を見る → 微調整 | 工学的：詳細なPRD/技術仕様を先に書く → AIが仕様に基づいてコードを生成 |
| 人間の関与度 | 低：AIの創造性に依存し、人間は「感覚が合っているか」だけを判断 | 高：人間が設計/アーキテクチャを先に行い、AIは主に実行を担当 |
| 典型的なシナリオ | 迅速なプロトタイピング、個人用ツール、UI探索、クリエイティブなコーディング | プロダクションシステム、チームコラボレーション、保守性/テスト容易性が必要なコード |
三、ワークフローの比較
Vibe Codingの流れ
- 曖昧なアイデア：「クローラーを書いて、知乎のホットリストを取得したい」
- 最初のプロンプトを書く：直接AIにコードを生成させる。
- 実行 → エラー → エラーを貼り付けてAIに修正させる。
- UIがダサいと感じる → 「そのボタンを少し丸くして、背景をグラデーションブルーに変更して」 → AIが修正。
- 機能不足 → 「CSVに保存する機能を追加して」 → AIが追加。
- 3～5を繰り返し、「まあまあかな」と感じるまで続ける。
Spec Codingの流れ
- 仕様書を作成：入力/出力、データ構造、エラーハンドリング、パフォーマンス要件、非機能要件（ログ、レート制限など）を明確にする。
- 仕様をタスクに分割：例：タスク1:
fetch_hot_topics()関数を実装、specのAPIシグネチャに従う。 - 各タスクをAIに実装させる：プロンプトに関数シグネチャ、コメント、テストケースの期待値を含める。
- 人間がレビューと検証：仕様に準拠しているか確認し、単体テストを実行。
- 統合と回帰テスト。
四、メリットとデメリットの比較
| 特性 | Vibe Coding | Spec Coding |
|---|---|---|
| 習得速度 | 非常に速い、数分でプロトタイプができる | 遅い、ドキュメント作成とタスク分割が必要 |
| コード品質 | 低い（冗長、一貫性なし、隠れたバグの可能性） | 高い（可読性、テスト容易性、アーキテクチャ適合） |
| 保守性 | 悪い、後の開発者が「なぜこう書いたのか」理解できない | 良い、仕様がドキュメントとして機能 |
| LLM依存度 | 非常に高い、モデルを変えると出力がまったく変わる可能性 | 中程度、仕様が明確であれば異なるモデルでも同様の構造を生成できる |
| デバッグの難しさ | 難しい、コードのロジックの出所が不明 | 簡単、specに沿って項目ごとにチェック可能 |
| チームコラボレーションへの適合性 | ほぼ不可能 | 可能（specがコミュニケーションの契約となる） |
| 出力の確実性 | 低い、対話ごとに結果が変動 | 高い、同じspecで安定した出力が得られる |
五、実際の使用におけるアドバイス
「仕事では、Vibe CodingとSpec Codingのどちらかを選ぶのではなく、混合して使用し、適切な場面で適切な方法を選びます：
- 探索段階（技術選定やUIスタイルが決まっていない場合）では、Vibe Codingを使って素早くさまざまな案を検証します。例えば、「Tailwindでカードコンポーネントを書いて見た目を確認しよう」など。
- 案が決まったら、すぐにSpec Codingに切り替えます：成功したプロトタイプを逆方向に整理し、明確な仕様（入出力、境界条件、エラーハンドリング）にまとめ、AIまたは人間が厳密にspecに従ってプロダクションコードを書き直します。
純粋なVibeモードは、一度きりのスクリプトや内部ツールにのみ適しています；長期間保守し、複数人が使用するシステムには、Spec Codingが必須要件です。」
评论
暂无已展示的评论。
发表评论（匿名）