vibe coding とは何だったのか
2025 年に Andrej Karpathy が「vibe coding」という言葉を投げ、AI コーディング界隈で大きな話題になりました。「コードを 1 行ずつ書くのではなく、欲しい振る舞いを自然言語で伝えて、AI が出してくる結果を 雰囲気で受け入れる」という新しいスタイルです。
このキーワードは現在 (2026 年 5 月) も月間検索 14,800 件規模で、いまだに「vibe coding は本当に実務で使えるのか？」という疑問が解消されないまま、検索され続けています。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、複数のクライアントワークで vibe coding スタイルを 2 ヶ月 本気で運用しました。本記事はその結論を、できる限り定量的にまとめたものです。なお、vibe coding と、テスト先行で品質を担保する AI 駆動開発との違いは AI 駆動開発とは で整理しています。
2 ヶ月運用の前提条件
公正な比較のため、運用の前提を明示します。
| 項目 | 設定 |
|---|---|
| 対象案件数 | 4 件 (SaaS MVP × 2、業務システム刷新 × 1、社内ツール × 1) |
| エンジニア体制 | 各案件 1〜2 名、計 5 名 |
| 使用ツール | Claude Code (CLI / IDE 拡張) + Cursor |
| 比較対象 | 同じチームが 2 ヶ月前に AI なしで実施した直近 4 案件の平均値 |
| vibe coding の定義 | 「テスト先行なし・人間が JSON を直接編集することなく、自然言語で AI に指示する開発スタイル」 |
「テスト先行 × AI 実装」(=AI 駆動 TDD) は別の手法として比較対象にしました。詳しくは AI 駆動 TDD の記事 を参照。
計測した 5 つの指標
vibe coding の効果を数字で検証するため、以下を計測しました。
flowchart LR
A["1. リリースリードタイム"]
B["2. 1 ストーリー実装時間"]
C["3. PR レビュー時間"]
D["4. 本番障害 P1 件数"]
E["5. エンジニア満足度"]
A --> B --> C --> D --> E1. リリースリードタイム
| 指標 | 従来手法 | vibe coding |
|---|---|---|
| commit → 本番デプロイ 中央値 | 8 日 | 3 日 |
| commit → 本番デプロイ 90 percentile | 21 日 | 9 日 |
ほぼ半分以下に短縮。 ただし、リードタイムの短縮は「実装が速くなった」というよりも、後述するように「実装が小粒になり、ブロック要因が分散した」効果が大きいことが分かりました。
2. 1 ストーリー実装時間
| 指標 | 従来手法 | vibe coding |
|---|---|---|
| 1 ストーリーあたり 中央値 | 6 時間 | 2.5 時間 |
ストーリー単体での速度はおおむね 2.4 倍。雛形を AI に書かせてから人間が調整する流れが、純粋なボトムアップ実装より速いのは明確です。
3. PR レビュー時間
| 指標 | 従来手法 | vibe coding |
|---|---|---|
| PR 中央サイズ (LOC) | 450 | 180 |
| レビュアー所要時間 中央値 | 45 分 | 18 分 |
PR が小さくなり、レビュー時間も短縮。これは vibe coding の 副作用として 起きた変化です。AI に依頼して出てきた結果が一発で完璧でないため、「小さく出して人間がレビューして直す」を高速で回す結果、PR が自然に小粒になりました。
4. 本番障害 P1 件数
| 指標 | 従来手法 | vibe coding |
|---|---|---|
| リリース 4 週間後の P1 件数 | 平均 1.8 件/プロジェクト | 2.4 件/プロジェクト |
| P2 件数 | 平均 4.2 件 | 6.8 件 |
ここが本記事の 最も重要な結論: 障害件数が増えました。とくに P2 (中度) のバグが 1.6 倍。「雰囲気で受け入れる」の弱点が直接出ています。
5. エンジニア満足度
| 指標 | 従来手法 | vibe coding |
|---|---|---|
| プロジェクト終了アンケート 10 段階 | 7.2 | 8.4 |
満足度は上がっています。とくに「単純作業から解放された」「考えるべきことに集中できた」というコメントが多数。一方、「品質に不安を感じることが増えた」というネガティブな声も併存しています。
まとめると、結論はこうです
vibe coding は 生産性とエンジニア体験を確かに上げる けれど、品質を維持するためのガードレール無しではそのまま使えない。
「vibe coding は使えるか？」への答え:
「テスト・人間レビュー・観測性の 3 つを揃えた上での vibe coding は最強。それなしの素朴な vibe coding は本番投入に耐えない。」
vibe coding でやってよかったこと 3 つ
1. プロトタイプ・スパイクは全て vibe coding
「動くか確認したい」「データ構造のたたき台が欲しい」フェーズは、テストを書かずに vibe coding で爆速で進められます。出来上がった結果を見て、本番化の判断材料にする使い方が最適。
2. ドキュメント・README・運用 Runbook の初稿
ドキュメントは雰囲気で書ける領域なので、vibe coding と相性が完璧です。AI に書かせて、人間が業務固有部分を補強する流れで、1 日かかっていた Runbook が 1 時間で完成しました。
3. リファクタリングの「叩き台」生成
「この関数を綺麗にして」「この型を細かく分けて」と AI に指示すると、複数の候補が出てきます。人間はその中から「これがいいね」と選ぶだけ。詳しくは AI 駆動 TDD の記事 で紹介した手法と組み合わせると効果的です。
vibe coding で失敗したこと 3 つ
1. テスト先行を怠ったドメイン実装
「テスト書くより先に動くやつ書こう」と vibe coding で進めたドメイン実装が、本番カットオーバー後に P1 障害 3 件 を起こしました。AI 生成コードは見た目が綺麗で「動いている」ように見えるため、テストなしで通すと境界値・例外系の漏れが残ります。
2. ライブラリ選定を AI に任せきり
「ベストプラクティスで」と AI に頼んだら、メンテナンスが止まったライブラリを引っ張ってきたケースが複数。「選定理由を 1 行で説明させる」 ルールを後から追加することで防げました。
3. 「動くから OK」で品質チェックを飛ばす
vibe coding で「動くやつ」が出てきた瞬間に満足してしまい、レビュー・テスト・ドキュメント化を後回しにする心理的バイアスが強かったです。「動いた瞬間が、最も危険なタイミング」 と認識する文化づくりが必須。
結論：「ガードレール vibe coding」を提案します
純粋な vibe coding は本番投入に耐えませんが、以下のガードレールを併用すると、生産性 × 品質の両立 が現実的に達成できます。
flowchart LR
V["vibe coding<br/>(自然言語で AI に依頼)"]
T["テスト先行<br/>(人間が受け入れ基準を書く)"]
R["人間レビュー<br/>(出力を必ず人間が確認)"]
O["観測性<br/>(本番後の異常を即検知)"]
V -.-> T
V -.-> R
V -.-> O
T --> P["本番投入"]
R --> P
O --> Pこのガードレールを揃えると、上述の指標は以下のように変化します (FIXIT 内の 3 案件で実測):
| 指標 | 純粋 vibe coding | ガードレール vibe coding |
|---|---|---|
| リリースリードタイム 中央値 | 3 日 | 3 日 (維持) |
| 1 ストーリー実装時間 | 2.5 時間 | 3 時間 (テスト先行分プラス) |
| 本番 P1 件数 | 2.4 件 | 0.8 件 (従来手法 1.8 件より低い) |
P1 障害件数を 従来手法より低く 抑えながら、リリースリードタイムは 3 日を維持できる、というのが FIXIT の現状ベストエフォートです。
チームへの導入手順
vibe coding をチームに展開するなら、以下のステップが現実的です。
- 個人試用 (1〜2 週間) として、サイドプロジェクトで肌感を掴む
- 小規模プロジェクト (2〜4 週間) として、失敗してもダメージが小さい範囲で運用する
- ガードレール整備 (2〜3 週間) として、テスト先行・PR テンプレート・観測性を揃える
- 本番案件へ適用し、ガードレール込みで小さな機能から段階展開する
- 上述の 5 指標を月次で計測し、KPI をモニタリングする
このフローは Claude Code を実務に導入する完全ガイド の 5 段階ロードマップと並走させると効果的です。
よくある質問
Q. vibe coding と AI ペアプログラミングの違いは？
A. ニュアンスの違いです。AI ペアプログラミングは「人間と AI が一緒にコードを書く」全般を指し、vibe coding はその中でも 「自然言語で意図を伝えて AI に任せる」 スタイル。AI ペアプログラミングの一形態が vibe coding、と捉えるのが現実的です。
Q. テストすら書かずに本番投入したことはありますか？
A. プロトタイプ専用の社内ツールでは経験あります。ただし、外部顧客に提供する本番案件で「テスト無し vibe coding 100% で完成」は経験ありません。FIXIT 内のルールとして禁止しています。
Q. ChatGPT や Gemini でも vibe coding はできますか？
A. できますが、コードベース全体のコンテキストを保持する力が Claude Code / Cursor とは大きく違います。スパイクやプロトタイプには ChatGPT、本格的なコーディングには Claude Code / Cursor、というのが現実的な棲み分けです。
Q. 学習コストはどのくらいですか？
A. プロンプトの作法に慣れるのに 1〜2 週間、ガードレール整備込みでチーム導入まで 1〜2 ヶ月が目安です。AI 駆動開発の組織導入については Claude Code 導入完全ガイド を参照ください。
関連リソース
- AI 駆動開発の全体像は AI 駆動開発とは で解説
- AI 駆動 TDD の手法は AI 駆動 TDD の記事 で深掘り
- Claude Code の組織導入は Claude Code 導入完全ガイド を参照
- Cursor のチーム導入は Cursor チーム導入ガイド を参照
- AI 駆動開発のご相談は お問い合わせ から