この記事は何か？
本記事は、筆者のバイブコーディングの失敗経験とその改善方法を紹介するものです。
本記事は筆者の2025年7月頃の体験を基にしています。
目次
はじめに
筆者は2025年7月に生成AI活用を前提とする新規プロジェクトへアサインされたことをきっかけに、生成AI（Claude）を使い始めました。
それまで生成AIを活用した経験がほとんどなかったため、まずは生成AIに慣れることを目的に小規模なアプリで「バイブコーディング」を試してみることにしました。
最初の失敗
最初は「タイマーアプリを作って」といった抽象的な指示を出していましたが、期待した結果は得られず、以下の問題に直面しました。
技術スタックが統一されない
新しくアプリを作るたびに、AIが選択する実装言語が毎回変わる問題が発生しました。
- 1回目のアプリ開発: React
- 2回目のアプリ開発: JavaScript
- 3回目のアプリ開発: Python
その結果、手元に実行環境がない言語で実装されてしまい、動作確認ができないケースが発生しました。
機能の不一致
指示した内容と実装された機能の間に差異が生じました。
- 必要な機能が実装されていない
- 要求していない機能が追加される
例えば、シンプルな3分タイマーを開発しようと思ってタイマー作成をAIに依頼したところ、なぜか時刻設定機能が追加されました。さらにその機能は見た目上存在するだけで、実際は動作しない機能でした。
修正の困難さ
機能の追加や修正を依頼すると、新たな問題が発生しました。
- 意図と異なる修正が行われる
- 既存機能が破壊される
- 同じ修正を複数回依頼する必要がある
これらの経験から、開発を始める前に要件を確定させることの重要性を実感しました。
開発アプローチを改善する
失敗体験を踏まえ、バイブコーディングのプロセスを見直しました。
ステップ1: 要件ヒアリング
まず、AIとの壁打ちを通じて要件を明確にしました。この段階で確定させる項目は以下としました。
- アプリケーションの目的
- 技術スタック
- 機能要件
- 画面構成とUI要素
- ユーザー操作フロー
特に技術スタックについては、HTML/CSS/JavaScriptに固定することにしました。この選択には以下の理由があります。
- ブラウザのみで実行可能で環境構築が不要
- 即座に動作確認できる
- 外部ライブラリを使わない構成にした
ステップ2: 要件定義書作成
ヒアリングで明確にした内容を基に、マークダウン形式の要件定義書をAIに作成させました。この要件定義書を次の実装フェーズにおける指示書としました。
要件定義書の構成は以下の通りです。
# 要件定義書
## 1. プロジェクト概要
- アプリケーション名
- 目的
- 対象ユーザー
## 2. 技術スタック
- 技術スタック
- HTML5
- CSS3
- JavaScript(ES6+)
- 単一HTMLファイルで完結（フロントエンドのみで完結）
## 3. 機能要件
- 主要機能一覧
- 各機能の詳細仕様
- 入出力データ形式
## 4. 画面設計
- 画面レイアウト構成
- 画面遷移
## 5. 操作フロー
- 操作フロー
- エラーハンドリング
ステップ3: 実装
要件定義書を基に、AIへアプリケーション開発を指示しました。
要件定義を行うことで、以下の改善が確認できました。
要求が明確になる
AIとの壁打ちの過程で自分が本当に求めているものが明確になりました。
必要な機能が正確に実装される
自分が欲しかった機能が正確に実装されるようになりました。また、不要な機能が追加されることもなくなりました。
アプリの作り直しが容易になった
要件定義書があるため、それをAIに再入力することでアプリケーション全体を一から再生成できるようになりました。これにより、要件定義書を修正してアプリケーションを作り直すことで仕様変更に対応でき、対応時間が大幅に短縮されました。
まとめ
今回は小規模アプリでバイブコーディングを試しましたが、「何を作るか」を明確にすることが最も重要でした。
ソフトウェア開発における要件定義の重要性はAIを使ったバイブコーディングでも変わらないことを実感しました。