はじめに
バイブコーディングって皆さんご存知でしょうか？「こういうのが欲しい」と"雰囲気"でAIに伝えて、コードを生成させる開発スタイルです。
私も以前の記事「連載：ノリとAIで創る！バイブコーディングの実践ガイド」で、その魅力と実践方法について語りました。正直、めちゃくちゃ楽しいんです！Cursorでざくざくと機能が実装されていく爽快感は、一度味わうとやめられません🎯
でも、自分で実践しててあれなんですが、「くそ、またやり直しだ〜〜〜」なんてケースありますよね？
結構ざっくりとした依頼を出すと思い切りやらかしますよね・・・・
特に、CursorだけでなくClaude Codeを使い始めてから、この感覚が強くなりました。
「うーん。要約は日本語でやってほしいなあ。」
こんなタメ口のプロンプトでコードが修正されるのは、Cursorでのペアプロなら確かに便利。
でも、Claude Codeで「このGitHubのissue読んでもらって開発してもらう」みたいな、より大きな粒度の作業を依頼するようになると、バイブコーディングでは対応できないケースが増えてきたんです。
例えば：
- 「issue #23の機能を実装して」→ 仕様が曖昧だと迷走する
- 「PRのレビューコメント対応して」→ 文脈理解が必要
- 「この設計ドキュメント読んで実装して」→ 長文の理解と実装の整合性
もちろんある程度はCLAUDE.md等で制御しているので暴走することは稀なのですが、複雑なプロジェクトになると「あれ？この機能って何のために作ったんだっけ？」「このアーキテクチャで本当に良かったのかな？」とか勝手にライブラリのアップデートしてたりとか、色々迷子になることも...
さてさて、そんな悩みを解決するヒントをくれたのが、YouTubeで見たにゃんたのAIチャンネル様のKIROのデモ動画でした。
この動画を見て「これだ！」と思ったのが、Amazonが開発したKIROというAI IDEが実践する「スペック開発（仕様駆動開発）」のアプローチ。バイブコーディングの"ノリ"を活かしつつ、しっかりとした設計を残せる...まさに私が求めていたものでした。
でも、KIROはまだ一般公開されていない...＆動画を見る限りプレビュー版で結構バギーっぽい。。。🥲
「じゃあ、KIROの中身も結局Claudeなんだし、Claude Codeで同じことできるんじゃない？」
そう思い立って、KIROのスペックドリブン開発アプローチをClaude Codeのカスタムコマンドとして実装してみました。
バイブのグラデーションから見た課題
私の前回の記事でも触れたように、バイブコーディングには以下のようなグラデーションがあります：
| タイプ | 特徴 | 適したケース |
|---|---|---|
| ラディカル型 | AIの生成物をそのまま受け入れ、コードレビューも最低限 | プロトタイプ開発、個人開発 |
| 協働型 | AIをアシスタントとして活用し、出力をレビュー＆調整 | チーム開発、中規模プロジェクト |
| 保守型 | 一部の定型処理に限定してAIを活用 | 大規模プロジェクト、既存システムの保守 |
私は主に「協働型」で開発していますが、それでも課題を感じることがあります。
バイブコーディングとスペックドリブン開発の本質的な違い
実は、バイブコーディングとスペックドリブン開発には、開発スタイルの根本的な違いがあります。
🎸 バイブコーディング = ペアプログラミング感覚
Cursorでバイブコーディングをしていると、まるで優秀な同僚とペアプロしている感覚なんです。
私「このメールの本文をOpenAIに投げて翻訳と要約を...」
Cursor「なるほど、こんな感じですか？」（コード生成）
私「うーん。要約は日本語でやってほしいなあ。」
Cursor「了解です！」（即座に修正）
リアルタイムで対話しながら、その場その場で調整していく。これがバイブの醍醐味です。
📋 スペックドリブン開発 = ジュニアエンジニアへの指示書
一方、スペックドリブン開発はジュニアエンジニアに仕様書を渡して開発してもらうイメージです。
私「株価分析アプリを作りたい」
AI「承知しました。まず要件を整理します」→ requirement.md
AI「設計はこうしましょう」→ design.md
AI「タスクはこの順番で」→ tasks.md
私「OK、この仕様書通りに進めて」
エージェント型AIツールとの相性
ここが重要なポイントなんですが、Claude Codeのようなエージェント型のツールには、実はバイブコーディングは不向きなんです(あくまでもCursorでの対話式のコーディングスタイルと比べてです)。
なぜなら：
- エージェントは「自律的に作業を進める」のが得意
- でもバイブは「リアルタイムの対話」が前提
- 結果、作業が大きすぎた場合に指示が曖昧だとユーザーの意図にはずれて迷走しがち
私も最初、Claude Codeでバイブコーディングを試みましたが、「え、そっちに行っちゃうの？」みたいなことが頻発しました😅
一方、スペックドリブン開発なら：
- 明確な仕様書があるから自律的に動ける
- 迷ったときの判断基準が明確
- 後から「なぜこうなった？」を追跡可能
スペックドリブン開発：バイブの進化形
そこで出会ったのが、AmazonのKIROが提唱するスペックドリブン開発です。
従来のバイブコーディング：
👨💻「このメールの本文をOpenAIに投げて翻訳と要約を...」
🤖「はい、作ります！」（即座にコード生成）
👨💻「うーん。要約は日本語でやってほしいなあ。」（後から修正）
スペックドリブン開発：
👨💻「メール翻訳・要約サービスを作りたい」
🤖「まず要件を整理しましょう」→ requirement.md
🤖「次に設計を決めましょう」→ design.md
🤖「実装タスクを定義します」→ tasks.md
👨💻「この設計でOK！」
🤖「では実装を始めます」
要は、バイブコーディングの「即興性」と従来の「計画性」のいいとこ取りなのです！
スペックドリブン開発のフロー
この流れの良いところは：
- 段階的な具体化: 曖昧なアイデアから具体的なタスクまで段階的に落とし込める
- 各段階でのレビュー: 各mdファイルを確認してから次に進める
- トレーサビリティ: なぜこの設計になったかを後から追跡可能
Claude Codeでの実装
「これ、Claude Codeでもできるんじゃない？」
そう思い立って、KIROのアプローチをClaude Codeのカスタムコマンドとして実装してみました。
作成したカスタムコマンド
3つのカスタムコマンドを作成しました：
-
/spec-init- 要件定義書の生成 -
/spec-design- 技術設計書の生成 -
/spec-tasks- 実装タスクリストの生成
ディレクトリ構造
your-project/
├── .claude/
│ └── commands/
│ ├── spec-init.md # バイブから要件へ
│ ├── spec-design.md # 要件から設計へ
│ └── spec-tasks.md # 設計からタスクへ
└── .specs/
└── [feature-name]/
├── requirement.md # 日英併記の要件書
├── design.md # バージョン明記の設計書
└── tasks.md # 具体的なタスクリスト
ポイントは、各機能やアプリごとに独立したディレクトリで管理すること。「企画倒れに終わった機能」も記録として残るので、後から「なんでこの設計にしたんだっけ？」を振り返れます。
実際に使ってみた
例1: 株価分析アプリ（バイブ→Spec）
まずは、バイブっぽく始めてみます：
/spec-init 株価分析アプリ作って
たったこれだけで、以下のようなrequirement.mdが生成されました（長いですが、これが全自動で生成されるのがポイント！）：
生成されたrequirement.md（クリックで展開）
--------------------------------------------------------------------------------
# Project Requirements: Stock Analysis Application / プロジェクト要件: 株価分析アプリケーション
## 1. Overview / 概要
This document outlines the functional and high-level structural requirements for a Python application designed to analyze stock prices. The application aims to provide users with tools to fetch, visualize, and identify trends in stock market data for informed investment decisions.
本文書は、株価を分析するために設計されたPythonアプリケーションの機能的および高レベルの構造的要件を概説します。このアプリケーションは、ユーザーに株式市場データの取得、視覚化、トレンドの特定を行うツールを提供し、情報に基づいた投資判断を支援することを目的としています。
## 2. Functional Requirements / 機能要件
### 2.1. Stock Price Data Retrieval / 株価データ取得
- **Description / 説明**:
- The application must retrieve real-time and historical stock price data for specified companies
- アプリケーションは指定された企業のリアルタイムおよび過去の株価データを取得する必要があります
- **Acceptance Criteria / 受け入れ基準**:
- Support multiple stock symbols input (e.g., "AAPL", "GOOGL", "7203.T")
- 複数の株式シンボル入力をサポート（例：「AAPL」、「GOOGL」、「7203.T」）
- Fetch OHLCV data (Open, High, Low, Close, Volume) with timestamps
- タイムスタンプ付きのOHLCVデータ（始値、高値、安値、終値、出来高）を取得
- Handle API rate limits and network errors gracefully
- APIレート制限とネットワークエラーを適切に処理
- Cache frequently accessed data for performance
- パフォーマンス向上のため頻繁にアクセスされるデータをキャッシュ
### 2.2. Interactive Visualization / インタラクティブな可視化
- **Description / 説明**:
- Provide interactive charts for comprehensive stock analysis
- 包括的な株式分析のためのインタラクティブチャートを提供
- **Acceptance Criteria / 受け入れ基準**:
- Display candlestick charts with zoom and pan capabilities
- ズームとパン機能付きのローソク足チャートを表示
- Show volume bars below price charts
- 価格チャートの下に出来高バーを表示
- Support multiple timeframes (1D, 1W, 1M, 3M, 6M, 1Y, 5Y)
- 複数の時間枠をサポート（1日、1週間、1ヶ月、3ヶ月、6ヶ月、1年、5年）
- Overlay technical indicators on charts
- チャート上にテクニカル指標をオーバーレイ
### 2.3. Technical Analysis Tools / テクニカル分析ツール
- **Description / 説明**:
- Implement comprehensive technical analysis indicators
- 包括的なテクニカル分析指標を実装
- **Acceptance Criteria / 受け入れ基準**:
- Moving Averages: SMA (20, 50, 200), EMA
- 移動平均：SMA（20、50、200日）、EMA
- Momentum indicators: RSI, MACD, Stochastic
- モメンタム指標：RSI、MACD、ストキャスティクス
- Volatility indicators: Bollinger Bands, ATR
- ボラティリティ指標：ボリンジャーバンド、ATR
- Pattern recognition: Support/Resistance levels
- パターン認識：サポート/レジスタンスレベル
### 2.4. Portfolio Analysis / ポートフォリオ分析
- **Description / 説明**:
- Enable users to track and analyze multiple stocks as a portfolio
- ユーザーが複数の株式をポートフォリオとして追跡・分析できるようにする
- **Acceptance Criteria / 受け入れ基準**:
- Add/remove stocks to personal watchlist
- 個人のウォッチリストに株式を追加/削除
- Calculate portfolio performance metrics
- ポートフォリオのパフォーマンス指標を計算
- Show correlation matrix between holdings
- 保有銘柄間の相関行列を表示
- Risk analysis (beta, standard deviation)
- リスク分析（ベータ、標準偏差）
### 2.5. Export and Reporting / エクスポートとレポート
- **Description / 説明**:
- Generate professional analysis reports
- プロフェッショナルな分析レポートを生成
- **Acceptance Criteria / 受け入れ基準**:
- Export charts as high-resolution PNG/PDF
- チャートを高解像度のPNG/PDFとしてエクスポート
- Generate analysis reports in Markdown/HTML
- Markdown/HTML形式で分析レポートを生成
- Export data to CSV/Excel for further analysis
- さらなる分析のためCSV/Excelにデータをエクスポート
- Include technical indicator values in exports
- エクスポートにテクニカル指標値を含める
## 3. Technical Architecture / 技術アーキテクチャ
- **Programming Language / プログラミング言語**: Python 3.9+
- **Data Source / データソース**:
- Primary: yfinance for free market data
- 主要: 無料市場データ用のyfinance
- Alternative: Alpha Vantage API for extended features
- 代替: 拡張機能用のAlpha Vantage API
- **Core Libraries / コアライブラリ**:
- pandas: Data manipulation and analysis
- pandas: データ操作と分析
- plotly: Interactive visualizations
- plotly: インタラクティブな可視化
- ta-lib/pandas-ta: Technical indicators
- ta-lib/pandas-ta: テクニカル指標
- streamlit: Web-based UI
- streamlit: WebベースのUI
- **Data Storage / データストレージ**:
- SQLite for local data caching
- ローカルデータキャッシュ用のSQLite
- JSON for user preferences and watchlists
- ユーザー設定とウォッチリスト用のJSON
## 4. Non-Functional Requirements / 非機能要件
### 4.1. Performance / パフォーマンス
- Chart rendering < 2 seconds for 1 year of daily data
- 1年分の日次データのチャートレンダリング < 2秒
- Support concurrent analysis of up to 10 stocks
- 最大10銘柄の同時分析をサポート
- Cache hit rate > 80% for frequently accessed data
- 頻繁にアクセスされるデータのキャッシュヒット率 > 80%
### 4.2. Usability / 使いやすさ
- Intuitive UI with minimal learning curve
- 学習曲線が最小限の直感的なUI
- Bilingual support (Japanese/English) throughout
- 全体を通じた二言語サポート（日本語/英語）
- Responsive design for various screen sizes
- 様々な画面サイズに対応するレスポンシブデザイン
- Keyboard shortcuts for power users
- パワーユーザー向けのキーボードショートカット
### 4.3. Reliability / 信頼性
- 99.9% uptime for local application
- ローカルアプリケーションの稼働率99.9%
- Graceful degradation when external APIs fail
- 外部API障害時の優雅な機能低下
- Data validation to prevent incorrect analysis
- 不正確な分析を防ぐデータ検証
- Automatic recovery from transient errors
- 一時的エラーからの自動回復
## 5. Future Enhancements / 将来の拡張機能
- Machine learning price predictions / 機械学習による価格予測
- Social sentiment analysis integration / ソーシャルセンチメント分析の統合
- Real-time alerts and notifications / リアルタイムアラートと通知
- Mobile application version / モバイルアプリケーション版
- Integration with trading platforms / 取引プラットフォームとの統合
## 6. Revision History / 改訂履歴
- **[2024-12-XX]**: Initial generation by spec-init command / spec-initコマンドによる初期生成
- Generated from prompt: "株価分析アプリを作りたい"
- プロンプト「株価分析アプリを作りたい」から生成
--------------------------------------------------------------------------------
「株価分析アプリ作って」という乱暴な一文から、これだけ詳細な要件書が生成されるんです！バイブコーディングだと「とりあえず動くコード」で終わりがちですが、これならなぜこの機能が必要かが明文化されています。
例2: 技術選定の透明性
次に/spec-design stock-analysisを実行すると、こちらも詳細な設計書が生成されます：
生成されたdesign.md（抜粋）
## 2. Architecture Overview / アーキテクチャ概要
### 2.1 Technology Stack / 技術スタック
Detailed technology choices with specific versions:
- **Language / 言語**:
- Primary: Python 3.9.16
- Type Checking: mypy 1.7.0
- **Framework / フレームワーク**:
- Web UI: Streamlit 1.28.2
- API (future): FastAPI 0.104.1
- Testing: pytest 7.4.3, pytest-cov 4.1.0
- **Core Libraries / コアライブラリ**:
- Data Fetching: yfinance 0.2.32 (Yahoo Finance API wrapper)
- Data Analysis: pandas 2.1.3, numpy 1.26.2
- Technical Indicators: ta-lib 0.4.28, pandas-ta 0.3.14b
- Visualization: plotly 5.18.0 (interactive charts)
- Database: SQLAlchemy 2.0.23 (ORM)
- **Development Tools / 開発ツール**:
- Package Manager: pip 23.3.1
- Code Formatter: black 23.11.0
- Linter: flake8 6.1.0, pylint 3.0.2
- Type Checker: mypy 1.7.0
- Pre-commit: pre-commit 3.5.0
### 2.2 System Architecture Diagram / システムアーキテクチャ図
┌─────────────────────────────────────────────────────────────────┐
│ Presentation Layer │
│ Streamlit Web Application │
│ ┌────────────┐ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Dashboard │ │ Chart Viewer │ │ Portfolio │ │ Reports │ │
│ │ View │ │ Component │ │ Manager │ │ Generator │ │
│ └────────────┘ └──────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Service Layer │
│ ┌────────────┐ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Market │ │ Technical │ │ Portfolio │ │ Export │ │
│ │ Data │ │ Analysis │ │ Analysis │ │ Service │ │
│ │ Service │ │ Service │ │ Service │ │ │ │
│ └────────────┘ └──────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────────────────┘
## 10. Version Compatibility Notes / バージョン互換性メモ
### 10.1 Critical Dependencies / 重要な依存関係
- **Python 3.9+**: Required for type hints and modern async features
- **ta-lib**: Requires system-level installation (brew install ta-lib on macOS)
- **yfinance**: May break with Yahoo Finance API changes (monitor releases)
### 10.2 Version Constraints / バージョン制約
pandas>=2.0.0,<3.0.0 # Major API changes expected in 3.0
streamlit>=1.28.0 # Minimum for st.fragment support
plotly>=5.0.0 # Required for subplot features
SQLAlchemy>=2.0.0 # New query syntax
「なんでこのライブラリ？」「インストール時の注意点は？」という疑問が解消されます。特にta-libのシステムレベルインストールとか、バイブだと後でハマるところを事前に教えてくれるんです😅
例3: 実装タスクの具体化
そして/spec-tasks stock-analysisを実行すると、実装タスクが生成されます：
生成されたtasks.md（抜粋）
# Project Tasks: Stock Analysis Application / プロジェクトタスク: 株価分析アプリケーション
## 2. Task Timeline / タスクタイムライン
Week 1-2: Environment Setup & Infrastructure
Week 3-4: Data Layer Implementation
Week 5-6: Service Layer Development
Week 7-8: UI Implementation
Week 9-10: Integration & Testing
Week 11-12: Documentation & Deployment
## 3. Detailed Tasks / 詳細タスク
### Phase 1: Environment Setup / フェーズ1: 環境構築
#### Task 1.1: Initialize Python Project
**ID**: TASK-001
**Time**: 2 hours / 2時間
**Dependencies**: None
**Description**: Set up the project structure and virtual environment
```bash
mkdir stock-analysis-app && cd stock-analysis-app
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
mkdir -p src/{app,data,services,models,utils} tests/{unit,integration} docs
touch src/__init__.py requirements.txt README.md .env.example
Task 1.2: Install Core Dependencies
ID: TASK-002
Time: 1 hour / 1時間
Dependencies: TASK-001
Description: Install required Python packages
pip install streamlit pandas yfinance plotly ta-lib
pip install pytest pytest-cov black flake8 mypy
pip freeze > requirements.txt
Phase 3: Data Layer Implementation / フェーズ3: データ層実装
Task 3.2: Implement Cache Manager
ID: TASK-008
Time: 4 hours / 4時間
Dependencies: TASK-004, TASK-007
Description: Build caching system with SQLite backend
File: src/data/cache_manager.py
# Implement cache CRUD operations
# Add TTL management
# Create cache key generation
# Handle serialization/deserialization
Phase 6: Integration & Testing / フェーズ6: 統合とテスト
Task 6.1: Write Unit Tests for Data Layer
ID: TASK-020
Time: 6 hours / 6時間
Dependencies: TASK-007 through TASK-010
Description: Create comprehensive unit tests
Files: tests/unit/test_data_*.py
# Test cache manager operations
# Mock API responses
# Verify error handling
# Check data transformations
4. Task Summary / タスクサマリー
Total Tasks: 27
Estimated Time: ~120 hours / ~120時間
Critical Path: TASK-001 → TASK-007 → TASK-009 → TASK-011 → TASK-015
27個のタスク、約120時間の作業見積もり、具体的なコマンドやコード例まで！
バイブコーディングだと「なんとなく作り始めて、なんとなく完成」ですが、これなら：
- 何から始めればいいか明確
- 依存関係が可視化されている
- 時間見積もりで進捗管理できる
私の英語メルマガ翻訳サービスも、最初からこれがあれば3回も作り直さなくて済んだかも...🥲
バイブとSpecの使い分け
🎸 バイブが向いている場面
- プロトタイプ開発: 「とりあえず動くもの」が欲しい時
- 個人の趣味開発: 自分だけが使うツール
- 実験的な機能: アイデアの検証段階
📋 スペックドリブンが向いている場面
- チーム開発: 設計意図の共有が必要
- 長期保守が必要: 「なぜこうなった？」を残したい
- 複雑な機能: アーキテクチャの選択肢を比較検討
まとめると、バイブコーディングは「コーダー」として、スペックドリブンは「プロダクトディレクター」として振る舞う時に使い分けるイメージです。
カスタムコマンドの実装ポイント
1. バイブからでも始められる設計
# クイックモード（バイブ風）
/spec-init 株価分析アプリ作って
# 対話モード（詳細ヒアリング）
/spec-init interactive
ここがポイントなんですが、どちらのモードでも同じクオリティの仕様書が生成されるんです！
🎸 ポン出しモード（バイブ風）
「株価分析アプリ作って」という乱暴な一文でも：
- 一般的な株価分析アプリに必要な機能を推測
- リアルタイムデータ取得、テクニカル分析、ポートフォリオ管理などを自動で要件化
- 適切な技術スタック（yfinance、pandas、plotly等）を提案
💬 壁打ちモード（対話形式）
interactiveを使えば：
- 「どんなユーザー向けですか？」
- 「リアルタイム性は重要ですか？」
- 「どの程度の規模を想定していますか？」
といった感じで、AIが壁打ち相手になってくれます。
私は気分によって使い分けてます。「とりあえず叩き台が欲しい」時はポン出し、「じっくり考えたい」時は壁打ちモード。バイブコーディングに慣れた人でも抵抗なく使えるはずです😊
2. 既存プロジェクトの理解から始まる設計
実は、/spec-designと/spec-tasksコマンドには、KIROのデモを見て「これは絶対必要！」と思った機能を実装しました。
# spec-designの動作
!find . -name "package.json" -o -name "requirements.txt" | head -5
!ls -la src/ 2>/dev/null || ls -la app/ 2>/dev/null
# spec-tasksの動作
!test -f Makefile && cat Makefile | grep -E "^(test|build|install):"
!test -f package.json && cat package.json | jq '.scripts'
既存のディレクトリ構造を走破してから仕様を作るんです。
これの何がすごいかって：
- 新規プロジェクト: ゼロから最適な構造を提案
- 既存プロジェクト: 現在の構造を理解して、それに合わせた設計を生成
- バイブで作った雑なコード: 後から構造を整理する提案も可能
例えば、私の英語メルマガ翻訳サービスは最初バイブで「えいや！」と作ったので、ディレクトリ構造がめちゃくちゃでした😅
でも、/spec-designを実行したら：
- 既存のファイル配置を認識
- 現在のpackage.jsonから使用ライブラリを把握
- それを踏まえた上で、より良い設計を提案
バイブで作り始めたプロジェクトにも、後から「設計の地図」を与えられるんです。
3. 履歴の可視化
.specs/
├── stock-analysis-app/ # 完成したアプリ
├── email-translation-service/ # 進行中
└── user-auth-system/ # 企画倒れ...でも記録は残る
「企画倒れに終わった機能」も削除せずに残すことで、「なぜダメだったか」を後から振り返れます。私の英語メルマガ翻訳サービスも、最初の設計から3回作り直してますが、全部記録に残ってます😅
導入方法
# リポジトリをクローン
git clone https://github.com/keitasunaga/claude-spec-driven.git
# プロジェクトにコピー
cp -r claude-spec-driven/.claude /path/to/your/project/
バイブコーディングは本当に「卒業」すべき？
正直なところ、バイブコーディングを完全に捨てる必要はないと思います。
私の開発スタイルは今こんな感じです：
- 最初はバイブ: 「こんな感じのやつ作って」でプロトタイプ
- 煮詰まったらSpec: 要件を整理して設計を見直し
- 実装は協働型バイブ: AIと対話しながらコーディング
- 次の機能はSpec-first: 学んだことを活かして計画的に
要は、「ノリ」と「計画」のハイブリッドです。
ポイント
- バイブの「速さ」は捨てない
- Specの「明確さ」を取り入れる
- プロジェクトの段階に応じて使い分ける
実際の効果
私の英語メルマガ翻訳サービスで試した結果：
Before（純粋なバイブ）
- 開発速度: ★★★★★
- コード品質: ★★☆☆☆
- 保守性: ★☆☆☆☆
- チーム共有: ★☆☆☆☆
After（スペックドリブン + バイブ）
- 開発速度: ★★★★☆（少し遅くなったけど）
- コード品質: ★★★★☆
- 保守性: ★★★★★
- チーム共有: ★★★★★
開発速度は若干落ちましたが、「なぜこの設計？」に即答できるようになったのは大きいです。
エージェント型AIならではのメリット
実は、スペックドリブン開発には、エージェント型のClaude Codeだからこそ光る大きなメリットがあります。
🍽️ 「会議中に開発が進む」という新体験
私が最も驚いたのはこれです。スペックドリブン開発なら、業務の粒度を大きく作業を依頼できるんです。
私「/spec-tasks実行して、Phase 1のタスクを全部やっておいて」
Claude Code「承知しました。環境構築から依存関係のインストールまで進めます」
（会議に行く）
（1時間後）
Claude Code「Phase 1完了しました。テストも通っています」
お昼ごはん食べてる間に「データ層の実装を進めておいて」とか、会議中に「UIコンポーネントを作っておいて」とか。
これ、バイブコーディングだと無理なんですよね。なぜなら：
- バイブは「対話しながら」が前提
- 細かい指示や修正が必要
- 結果的に張り付いてないといけない
でもスペックドリブンなら、明確な設計書があるから自律的に作業を進められる。まさにジュニアエンジニアに「この仕様書通りに作っておいて」と頼む感覚です。
📋 仕様書と実装の整合性チェックが楽
もう一つ嬉しいのが、できたアウトプットをmdファイルと照合しながら開発できること。
requirement.md「ユーザー認証機能が必要」
→ 実装確認「auth.jsあるか？✓」
design.md「JWTトークンで認証」
→ 実装確認「JWTライブラリ使ってるか？✓」
tasks.md「TASK-005: 認証ミドルウェアの実装」
→ 実装確認「middleware/auth.jsあるか？✓」
バイブコーディングだと「あれ、この機能って実装したっけ？」「この設計でよかったんだっけ？」となりがちですが、スペックドリブンなら常に答え合わせができるんです。
私の英語メルマガ翻訳サービスも、今では：
- 朝：仕様を確認してタスクを振る
- 昼：会議や他の作業
- 夕方：実装結果を仕様書と照合してレビュー
という感じで、マネージャー的な働き方ができるようになりました。コードに張り付かなくていいって、本当に楽です😊
まとめ
バイブコーディングの「コードの存在すら忘れろ。バイブに身を委ねよ。」は確かに爽快です。
でも、複雑なプロジェクトになると「身を委ねすぎて迷子」になることも...😅
スペックドリブン開発は、バイブの良さを活かしつつ、「迷子にならない地図」を提供してくれます。
ともあれ、AIとの開発がより構造化され、かつ楽しいものになったのは確かでしょう。皆さんも、バイブとSpecのいいとこ取りで、快適なAI協働開発を楽しんでください！
参考リンク
- 連載：ノリとAIで創る！バイブコーディングの実践ガイド
- KIROのデモ動画 - にゃんたのAIチャンネル
NONENTROPY JAPAN株式会社は、Blockchain、IPFS、DID/VC、生成AIなどを活用し、Web3時代の信頼を支える技術を開発しています！技術情報を中心に投稿します！
Discussion