注目
Vibe Coding SDD SpecKit ワークフロー ベストプラクティス
SDD x VibeCoding：構造と直感の出会い
仕様駆動開発とVibe Codingを組み合わせ、両方の長所を活かす方法を探る：創造的自由と体系的な実装。
2026年1月19日 • 20 min read • 著者：Claude World
自然言語でビジョンを説明しながら、仕様駆動開発の厳密さで実装できるとしたら？
これが Vibe Coding と SDD（仕様駆動開発）を組み合わせる約束です。
二つの極端
純粋な Vibe Coding
あなた：「タスク管理アプリを作って。雰囲気はミニマルで
禅風、紙のノートのような感じで。」
Claude：[アプリを作成]
あなた：「サブタスクを追加して」
Claude：[サブタスクを追加]
あなた：「実は、無限にネストできるようにして」
Claude：[無限ネストにリファクタリング]
あなた：「あと期限も... タグも... それと...」結果： 開始は速いが、スコープが膨らむ。ドキュメントなし。メンテナンスが困難。6ヶ月後、なぜそうなっているのか誰も覚えていない。
純粋な SDD
あなた：/speckit-specify タスク管理機能
[5ページの仕様書を作成]
[12個の曖昧な点を明確化]
[技術計画を作成]
[20個のタスクを定義]
[やっとコーディング開始]結果： 厳密で追跡可能だが、事前の投資が大きい。時にはアイデアを探求したいだけで、論文を書きたいわけではない。
スイートスポット：VibeSDD
VibeSDD は、vibe codingの創造的自由とSDDの構造的厳密さを組み合わせます：
┌─────────────────────────────────────────────────────┐
│ VibeSDD フロー │
│ │
│ ┌──────────┐ │
│ │ VIBE │ 自然言語で自由に説明 │
│ │ 入力 │ 「Xが欲しい、Yのような感じで」 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 仕様 │ Claudeが仕様形式に構造化 │
│ │ 捕捉 │ あなたがレビューして洗練 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ VIBE │ vibe言語で仕様をイテレート │
│ │ 洗練 │ 「これをもっと、あれを少なく」 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ SDD │ 構造化された実装 │
│ │ 実行 │ 完全な追跡可能性 │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────┘なぜこれが機能するのか
Vibe Coding は意図を捉える
「Notionみたいだけどもっとシンプルに」と言うと、以下を伝えています：
- メンタルモデル（ブロック、柔軟性）
- 美学（クリーン、モダン）
- ユーザー体験（速い、直感的）
- 複雑さのレベル（シンプル = 機能が少ない）
これは正式に仕様を書くと何ページもかかる貴重な情報です。
SDD はガードレールを提供
仕様は以下を防ぎます：
- スコープクリープ（「もう一つ追加して…」）
- 忘れられた要件（「待って、それ必要だった？」）
- 実装のずれ（「そういう意味じゃなかった」）
- ドキュメント負債（「これどうやって動くんだっけ？」）
組み合わせ：創造的厳密さ
| Vibe Coding | + | SDD | = | VibeSDD |
|---|---|---|---|---|
| 素早い探求 | 構造化された出力 | 迅速な仕様化 | ||
| 直感的な入力 | 明確な要件 | ビジョンから仕様へ | ||
| イテレーション向き | 追跡可能な変更 | 制御された進化 |
VibeSDD ワークフロー
フェーズ 1：Vibe 仕様化
正式な仕様を書く代わりに、ビジョンを説明：
## The Vibe
「フリーランサー向けの経費トラッカーを作りたい。
企業の会計ツールではなく、個人の財務日記のような
感じにしたい。
重要な感覚：
- 経費追加が速い（5秒以内）
- カテゴリ分けが気持ちいい（スワイプかな？）
- 月次概要が分かりやすい（圧倒されない）
- お金のデータを扱っても信頼できる感じ
イメージ：Things 3のようにミニマル、Notionのように
カラフル、でもお金用。」Claude がこれを仕様構造に捕捉：
# 仕様：フリーランサー向け経費トラッカー
## 概要
フリーランサー向けの個人経費トラッキングアプリ。
スピード、シンプルさ、日記のような体験を重視。
## ユーザーストーリー
- フリーランサーとして、経費を素早く追加したい、
ワークフローを中断しないように
- フリーランサーとして、月の支出を明確に見たい、
予算管理ができるように
- フリーランサーとして、カテゴリ分けを自然に
感じたい、実際に使うように
## UX 要件
- 経費入力：< 5秒
- インタラクションスタイル：ジェスチャーフレンドリー（スワイプでカテゴリ分け）
- 視覚的密度：低（余白を活かす）
- データ表示：月次フォーカス、トランザクションベースではない
## デザイン参考
- Things 3：ミニマリズム、余白、繊細なアニメーション
- Notion：カラフルなアクセント、遊び心がありつつ幼稚ではない
- 強調：「帳簿」ではなく「日記」
## [要明確化]
- 通貨サポート：単一か複数か？
- データ保存：ローカルファーストかクラウド同期か？
- エクスポート形式：PDF？CSV？会計ソフト？フェーズ 2：Vibe 洗練
vibe言語で仕様をイテレート：
あなた：「カテゴリのセクションが企業っぽすぎる。
税金申告じゃなくて、気分を選ぶような感じにして。」
Claude：仕様を更新...
## カテゴリシステム
- 気分ベースのカテゴリ分け：「仕事系」「生活のこと」
「クリエイティブワーク」「退屈な用事」
- カテゴリごとにカスタム絵文字
- アイコンではなく色分け
- 階層なし—フラットでシンプルあなた：「月次概要について—チャートは要らない。
実際に見るものが欲しい。ダッシュボードじゃなくて、
月のレビューのような感じで。」
Claude：仕様を更新...
## 月次概要
- 物語形式：「2026年3月：あなたは...を使いました」
- 先月からの驚くべき変化をハイライト
- パーセンテージではなく、平易な言葉でトレンドを表示
- 20個の指標ではなく、月に1つの「インサイト」フェーズ 3：実装前の Vibe チェック
コーディング前に、vibe チェック：
あなた：「仕様を読み返して。まだしっくりくる？」
Claude：これが私たちが作ろうとしているものの本質です...
「フリーランサー向けの個人経費日記。
素早く追加（< 5秒）、カテゴリ分けが気持ちいい
（気分ベース、ジェスチャーフレンドリー）、
企業のダッシュボードではなく月次の物語を提供。
Things 3 meets Notion のような感じ、でもお金用。」
あなたのビジョンと合っていますか？合っていなければ調整。合っていれば続行。
フェーズ 4：構造化された実装
Claude が完全な SDD の厳密さで実装：
/speckit-implement SPEC-001
Claude:
→ 仕様から技術計画を作成
→ 追跡可能なタスクに分解
→ 仕様への参照付きで実装
→ ドキュメントを維持コードは仕様を参照：
/**
* クイック経費入力コンポーネント
*
* @spec SPEC-001
* @requirement "経費入力 < 5秒"
* @ux "素早く経費追加、ワークフローを中断しない"
*/
export function QuickExpenseInput() {
// UX要件に従ってスピード最適化
// ...
}VibeSDD 実践例
例：習慣トラッカーを作る
従来のアプローチ：
/speckit-specify 習慣トラッキング機能
[30分かけて正式な要件を作成]VibeSDD アプローチ：
あなた：「日を逃しても嫌な気分にならない習慣トラッカーが
欲しい。ほとんどの習慣アプリは罰を与えるような感じ。
これは自分を大切にすることを優しく思い出させてくれる
友達のような感じにしたい。
インスピレーション：Headspaceの穏やかな雰囲気、でも習慣用。
絶対にStreaksの攻撃的な連続カウントではない。」Claude が捕捉：
# 仕様：思いやりのある習慣トラッカー
## コア哲学
罰を与えないトラッキング。日を逃すのは想定内でOK。
連続記録ではなくパターンに注目。
## UX 原則
- 途切れたチェーンや失われた連続記録なし
- 赤いXや失敗インジケーターなし
- 「逃した日」ではなく「試みた日」を表示
- どんな小さな進歩も祝う
## ビジュアル言語
- 柔らかい色、丸みを帯びた形
- 自然のメタファー（成長、季節）
- 言葉：「休息日」であって「スキップした日」ではない
- ホームページに数字なし—vibeだけ
## アンチ要件（避けるべきこと）
- 連続カウンター禁止
- 罰を与えるゲーミフィケーション禁止
- 比較機能禁止
- 恥をかかせる通知禁止洗練する：
あなた：「『数字なし』について—それでも進捗は
何らかの形で見たい。ただし攻撃的じゃなく。」
Claude：仕様を更新...
## 進捗の可視化
- ソフトなグラデーションのヒートマップ（鮮明な二値ではない）
- 「季節」ビュー：春と冬はどう見える？
- オプションの統計、デフォルトは非表示
- 言葉：「X日連続」ではなく「X回参加しました」そして完全な追跡可能性で実装。
VibeSDD プロンプティングガイド
VibeSDD プロジェクトを始める
## ハイVibe 仕様スターター
「[もの]を作りたい、[参考]のような感じで。
重要な感覚は[感情]。対象は[オーディエンス]。」
「[インスピレーションA] meets [インスピレーションB]、
でも[特定の側面]に注力。」
「ほとんどの[カテゴリ]アプリは[ネガティブ]な感じ。
これは代わりに[ポジティブ]な感じにしたい。」仕様を洗練する
## Vibe 洗練フレーズ
「このセクションは[形容詞]すぎる感じ。もっと[形容詞]にして。」
「これを使うところを想像すると、[感情]を感じる。代わりに[感情]を感じたい。」
「[セクション]のトーンは[参考]に合わせるべき。」
「これは『何』を捉えているけど『なぜ』がない。なぜは[理由]。」アラインメントを確認
## Vibe チェック質問
「仕様を3文で要約して。まだ響く？」
「これが存在したら、使うのが楽しみ？なぜ/なぜでない？」
「これを使っているとき、ユーザーは何で微笑む？」
「6ヶ月後、これの何が違和感になる？」VibeSDD を使うタイミング
最適なケース
| シナリオ | なぜ VibeSDD が有効か |
|---|---|
| 新製品の探求 | 最初にvibe、洗練、それから正しく構築 |
| UX重視の機能 | 仕様に感覚を捕捉 |
| 創業者主導のプロジェクト | 魂を失わずにビジョンから実行へ |
| リデザイン | 機能だけでなく望む感覚を捕捉 |
あまり理想的でないケース
| シナリオ | より良いアプローチ |
|---|---|
| 純粋なインフラ | 従来の SDD |
| API 統合 | 標準的な仕様 |
| コンプライアンス機能 | 正式な要件 |
| バグ修正 | そのまま直す |
よくある間違い
間違い 1：Vibe したけど捕捉しなかった
❌ 悪い：
セッション 1：「Notionみたいな感じにして」
セッション 2：「なぜNotionみたいじゃないの？」✅ 良い：
セッション 1：「Notionみたいな感じにして」 → 仕様に捕捉
セッション 2：[仕様を読む] Notionライクな感じの実装を継続常に vibes を仕様に捕捉する。 Vibes は薄れる；仕様は残る。
間違い 2：Vibes を過度に仕様化
❌ 悪い：
「ボタンは正確に44px、背景 #3B82F6、
ボーダー半径4px、フォント 'Inter'
14px ウェイト 500...」✅ 良い：
「ボタンはフレンドリーでクリックしたくなる感じに。
企業っぽくなく、おもちゃっぽくなく。ちょうど良い感じ。」感覚を仕様化する、ピクセルではなく。 Claude は CSS を知っている。
間違い 3：Vibe チェックをスキップ
❌ 悪い：
[仕様を書く] → [すぐ実装]✅ 良い：
[仕様を書く] → [読み返す] → [しっくりくるか感じる] → [実装]常に一旦止まって vibe-check する。 今の5分が後の数時間を節約する。
VibeSDD チートシート
## VibeSDD クイックリファレンス
### 機能を始める
1. vibe を説明（2-3段落、感覚と参考）
2. Claude に仕様として構造化させる
3. しっくりこないセクションをvibe-洗練
4. 仕様全体をvibe-check
5. 追跡可能性付きでSDD実装
### Vibe 語彙
- 感覚：穏やか、エネルギッシュ、遊び心、真剣、信頼できる
- 比較：「Xみたいだけど Y」、「X meets Y」
- 否定：「Xとは違う」、「Yの感じを避ける」
- 方向：もっと/少なく、シンプルに/リッチに、暖かく/冷たく
### Vibe する仕様セクション
- ユーザーストーリー → 「...と感じる人として」
- UX 要件 → 「...と感じるべき」
- デザイン参考 → 「X meets Y みたいに」
- アンチ要件 → 「...ではない」
### 品質チェック
- これを使うのが楽しみか？
- 魂を一文で説明できるか？
- 仕様を読んでその感覚を得られるか？Skills & Agents で VibeSDD を実装
コミュニティパターン注意： 以下のスキルとエージェントは Claude Bootstrap Kit からのもので、コミュニティが開発した Claude Code の拡張です。Anthropic の公式機能ではありません。
VibeSDD は単なるコンセプトではありません—Claude Code のカスタムスキルとエージェントを使って今日から実行できるワークフローです。
VibeSDD スキルパイプライン
┌─────────────────────────────────────────────────────────────────┐
│ VibeSDD スキルパイプライン │
│ │
│ VIBE 入力 構造化キャプチャ 実装 │
│ ───────── ──────────────── ──── │
│ │
│ 自然言語の → /spec-writer → /tech-planner │
│ vibe (仕様にキャプチャ) (アーキテクチャ) │
│ │ │ │
│ ▼ ▼ │
│ /spec-clarifier /task-decomposer │
│ ([?]を解決) (タスク分解) │
│ │ │ │
│ ▼ ▼ │
│ specification- /speckit-implement │
│ validator agent (TDD 実行) │
│ (品質チェック) │
│ │
└─────────────────────────────────────────────────────────────────┘フェーズ 1：Vibe → 仕様
/spec-writer を使って vibe を構造化された仕様に変換：
あなた：「フリーランサー向けの経費トラッカーを作りたい。
企業の会計ツールではなく、個人の財務日記のような感じに。
素早く追加、カテゴリ分けが気持ちよく、ミニマルだけど信頼できる。」
/spec-writer フリーランサー向け経費トラッカーspec-writer スキル：
- vibe をユーザーストーリーに構造化
- 受け入れ基準を抽出
- 感覚から UX 要件を特定
- 曖昧な点を
[要明確化]でマーク - 純粋な製品を維持—まだ技術的な詳細なし
フェーズ 2：Vibes を明確化
/spec-clarifier で [要明確化] マーカーを解決：
/spec-clarifier SPEC-001spec-clarifier スキル：
- すべての曖昧なセクションをスキャン
- オプション付きの構造化された質問を生成
AskUserQuestionでインタラクティブな決定- 選択で仕様を更新
- 決定理由を文書化
インタラクション例：
Claude：明確化が必要な項目が3つ見つかりました：
1. 通貨サポート？
a) 単一通貨（シンプル）[推奨]
b) 複数通貨（複雑）
あなたの vibe は「ミニマル」—単一通貨がより適合します。
2. データ保存？
a) ローカルファースト（プライベート、オフライン）
b) クラウド同期（どこからでもアクセス）
あなたの vibe は「信頼できる」—どちらがより信頼できると感じますか？
あなた：単一通貨、そしてローカルファーストがお金のデータにはより信頼できる感じ。
Claude：[決定と理由で仕様を更新]フェーズ 3：Vibe-Spec を検証
specification-validator エージェントで品質を確保：
Claude は Task ツールと specification-validator エージェントを使用バリデーターがチェック：
- 構造の完全性（必要なセクションすべて）
- SDD コンプライアンス（早すぎる技術的詳細なし）
- 明確さスコア（残りの
[要明確化]数） - Vibe の一貫性（元の感覚とまだ一致するか？）
スコアリング：
- 90-100：優秀、実装準備完了
- 75-89：良好、軽微な洗練が必要
- 60-74：要改善、セクション不足
- <60：失敗、根本的な問題
フェーズ 4：技術計画
仕様が検証されたら、/tech-planner を使用：
/tech-planner SPEC-001tech-planner スキル：
- 仕様を徹底的に分析
- 既存のコードベースアーキテクチャを探索
- 2-3 の実装アプローチを生成
- トレードオフを評価（複雑さ、パフォーマンス、リスク）
- 詳細な技術計画を出力
vibe は保持される：
# 技術計画：経費トラッカー
## アーキテクチャ決定
仕様が強調する「素早い」(< 5秒) と
「信頼できる」(ローカルファースト) に基づき、推奨：
- **アプローチ A：SQLite + React Native** ✓ 推奨
- 「ミニマル」vibe に適合（シンプルなスタック）
- ローカルファーストアーキテクチャで「素早い」をサポート
- デバイス上の暗号化で「信頼できる」を実現フェーズ 5：タスク分解
/task-decomposer で計画を実行可能なタスクに分解：
/task-decomposer SPEC-001task-decomposer スキル：
- 依存関係付きのサイズ別タスクを作成
- 各タスクを仕様要件にリンク
- 相対的な複雑さを見積もり
- TodoWrite 互換のタスクリストを生成
出力：
## 実装タスク
| ID | タスク | 仕様参照 | サイズ |
|----|--------|----------|--------|
| T1 | SQLite スキーマ作成 | UX-001 | S |
| T2 | 経費入力コンポーネント構築 | UX-002 | M |
| T3 | スワイプカテゴリ分け実装 | UX-003 | M |
| T4 | 月次物語ビュー作成 | UX-004 | L |
| T5 | ソフトグラデーションヒートマップ追加 | UX-005 | S |フェーズ 6：TDD 実装
/speckit-implement で完全な追跡可能性で実行：
/speckit-implement SPEC-001speckit-implement スキル：
- 厳密な Red-Green-Refactor TDD サイクルに従う
- すべてのコードファイルで仕様を参照
- 9条憲法コンプライアンスをチェック
- 実装レポートを生成
憲法コンプライアンス（9原則）：
- Library-First - 再利用可能なロジックをライブラリに
- CLI Interface - CLI で機能にアクセス可能
- Test-First - 実装の前にテスト
- Research-Driven - 証拠に基づく決定
- Specification Consistency - 仕様と完全に一致
- Simplicity - 最もシンプルな解決策を選択
- Anti-Abstraction - 早すぎる抽象化なし
- Minimal Scope - 仕様されたものだけ
- Integration-First - 統合テストを優先
完全な VibeSDD コマンドシーケンス
# 1. vibe を仕様に変換
/spec-writer "あなたの vibe 説明"
# 2. インタラクティブに曖昧さを明確化
/spec-clarifier SPEC-001
# 3. 仕様の品質を検証
# (自動トリガーまたは specification-validator エージェントを使用)
# 4. 技術計画を作成
/tech-planner SPEC-001
# 5. タスクに分解
/task-decomposer SPEC-001
# 6. TDD で実装
/speckit-implement SPEC-001
# または完全なパイプラインを実行：
/speckit "あなたの vibe 説明"複雑な Vibes のエージェントオーケストレーション
複雑な機能には、複数のエージェントを並行して使用：
Terminal 1: spec-writer エージェント
→ vibe を仕様にキャプチャ
Terminal 2: tech-planner エージェント
→ アーキテクチャオプションを探索
Terminal 3: specification-validator エージェント
→ SDD コンプライアンスを検証
Terminal 4: implementer エージェント
→ 完全な追跡可能性で実行マルチ CLI 委任：
大規模コンテキスト分析 → Gemini CLI（1M トークン）
一括コードフォーマット → Codex CLI（効率性）
インタラクティブな決定 → Claude CLI（会話）VibeSDD 用の CLAUDE.md 設定
プロジェクトの CLAUDE.md に追加：
## VibeSDD ワークフロー
### Vibe キャプチャ
- 新機能には必ず /spec-writer を使用
- 仕様に vibe を明示的にマーク："Vibe: [説明]"
- デザイン参考とアンチパターンを含める
### 仕様基準
- 純粋な製品仕様（tech-planner まで技術的詳細なし）
- すべての曖昧さを [要明確化] でマーク
- 実装前に必ず vibe-check
### 実装ルール
- 憲法コンプライアンス必須
- すべての新機能に TDD
- コードコメントで仕様を参照哲学：なぜ VibeSDD が重要か
ソフトウェア開発には常に緊張関係がありました：
アーティストは自由に表現し創造したい。 エンジニアは正しくメンテナブルに構築したい。
VibeSDD は以下を認識することでこれを解決します：
-
Vibes も要件である。「Xと感じるべき」は「Yをすべき」と同じくらい有効。
-
構造は創造性を増幅する。 仕様は制約ではない；創造的なコミットメント。
-
AI がギャップを橋渡しする。 Claude は感覚を正式な仕様に翻訳できる。
結果：正しく動作し、かつ正しく感じるソフトウェア。
重要なポイント
- Vibe coding は意図を捕捉する—正式な仕様がよく見逃すもの
- SDD はガードレールを提供する—vibe coding に欠けているもの
- VibeSDD = 創造的自由 + 体系的厳密さ
- 常に vibes を仕様に捕捉する
- 実装前に vibe-check する
感覚から始める。厳密さで終える。魂のあるソフトウェアを作る。