LLM時代の新常識「仕様書駆動開発」：AIに仕様書を書かせ、人間はレビューに徹する

エンジニア AI 開発

はじめに：バイブコーディングの理想と現実

「バイブコーディング（Vibe Coding）」という言葉が注目されています。開発者が「こんな感じで」と曖昧に伝えるだけで、AIが意図を汲み取って魔法のようにコードを生成してくれる—そんな夢のような開発スタイルへの期待が高まったのです。

しかし、現実はもっと複雑でした。多くの開発者が報告するように、AIに「バイブス」で指示を出した結果、生まれたのは手戻りの山です。

  • 過剰な設計: シンプルな機能のはずが、エンタープライズ級の複雑なコードが返ってくる。（典型例：5行で済むはずの処理が150行のクラス設計に）
  • 文脈の欠如: プロジェクトの制約や既存のコードベースを無視した、的外れな提案。（例：React使用プロジェクトにVue.jsコードを提案）
  • 終わらないレビュー: 生成されたコードのレビューに、自分で書く以上の時間がかかることが多い。

問題の根源は単純です。AIは文脈を理解せず、ただ優秀なパターンジェネレーターに過ぎません。プロジェクトの成功を約束するパートナーではなく、確率的に応答を返すだけの存在なのです。この認識のズレこそが、手戻りやフラストレーションを生み出します。

しかし、だからといってLLMが無力というわけではありません。問題は使い方にあるのです。本記事では、その答えとして、LLM時代の開発における新しいベストプラクティスを提案します。それは、AIに要件定義、設計、作業計画といった上流工程のドキュメントを「書かせ」、人間はそれを「レビュー」し、より本質的な意思決定に集中するという、新たな協業モデルです。

では、なぜ「バイブス」での指示が失敗するのか、そしてどうすれば効果的にLLMと協業できるのか、具体的に見ていきましょう。

なぜ「バイブス」で指示すると失敗するのか：LLMの本質を理解する

LLMとの協業を成功させるためには、まずLLMの本質を正しく理解する必要があります。多くの開発者が「バイブコーディング」で挫折する根本原因は、LLMの動作原理に対する誤解にあるのです。

LLMは「統計的なパターン認識システム」である

人間のような「理解」や「創造」は、LLMには不可能です。膨大なテキストデータから学習した統計的パターンに基づいて、「与えられた文脈に対して、最も確率の高い次の文字列」を予測しているだけです。

人間の期待: 「こんな感じの機能が欲しい」→ AIが文脈を理解し、最適解を提案
LLMの現実: 「こんな感じの機能が欲しい」→ 訓練データの類似パターンから、統計的に最頻出の回答を生成

この根本的な違いこそが、以下のような問題を引き起こします：

  • 過剰設計: LLMは「企業向けシステム」というキーワードに反応し、訓練データに多く含まれる「エンタープライズパターン」（依存性注入、抽象化レイヤー、設定ファイル等）を自動的に組み込む
  • 文脈無視: あなたのプロジェクトが「シンプルなプロトタイプ」であることを理解できず、常に「本格的な本番システム」として回答する
  • 一貫性の欠如: 同じ質問でも、その時々の確率的サンプリングにより、異なる設計思想の回答を返す

具体例：「ユーザー管理機能」を依頼した場合の典型的な失敗パターン

🧑‍💻 開発者の曖昧な指示:

「ユーザーの作成・更新・削除ができる機能を作って」

🤖 LLMの典型的な回答（過剰設計）:

// 不必要に複雑なレイヤード・アーキテクチャ
interface UserRepository {
  create(user: CreateUserDTO): Promise<User>;
  findById(id: UserId): Promise<User | null>;
  // ... 20行のインターフェース定義
}

class UserService {
  constructor(
    private userRepo: UserRepository,
    private validator: UserValidator,
    private eventBus: EventBus,  // 不要な複雑さ
    private logger: Logger       // 不要な複雑さ
  ) {}
  // ... 100行のビジネスロジック
}

@Controller('/api/users')
class UserController {
  // ... さらに50行のコントローラー
}

🧐 開発者が本当に欲しかったもの（シンプルな実装）:

// シンプルで十分なCRUD
export const users = []; // インメモリで十分

export function createUser(name: string, email: string) {
  const user = { id: Date.now(), name, email };
  users.push(user);
  return user;
}

export function deleteUser(id: number) {
  const index = users.findIndex(u => u.id === id);
  if (index >= 0) users.splice(index, 1);
}

なぜこの問題が起きるのか：「訓練データバイアス」の影響

LLMの訓練データには、以下のようなバイアスが存在します：

  1. 「ベストプラクティス」の過剰表現: GitHub上のオープンソースプロジェクトや技術ブログには、本番環境対応のコードが多く、シンプルなプロトタイプコードは相対的に少ない
  2. 「完璧主義」の文化: 技術記事では「拡張性」「保守性」「テスタビリティ」が重視され、「今すぐ動けばいい」という実用的なアプローチは軽視されがち
  3. 「教育的コード」の影響: チュートリアルやサンプルコードは、学習目的で意図的に多くのパターンを盛り込んでいる

そのため、LLMはいつも「教科書通りの模範回答」を作ってしまいます。 あなたの状況（締切、チームサイズ、技術的制約）なんて全く考えてくれません。

本当の解決策は、LLMに「コードを直接書いてもらう」のではなく、「仕様書を書いてもらって、人間がレビューする」という段階的なアプローチです。

この課題を解決するために注目されているのが、LLMを活用した仕様書駆動開発というアプローチです。従来の失敗パターンは「バイブス」を「コード」に直接変換しようとすることでした。しかし、LLMを活用すれば、「バイブス」→「仕様」→「コード」という2段階プロセスが可能になります：

❌ 従来のバイブコーディング:
「なんとなくこんな感じ」 → 🤖 → 💻 複雑で使えないコード

✅ LLMを活用した仕様書駆動開発:
「なんとなくこんな感じ」 → 🤖 → 📋 構造化された仕様 → 🧐 人間レビュー → 🤖 → 💻 意図通りのコード

この新しいアプローチは、バイブコーディングの直感性とアジャイルの柔軟性、そして従来の仕様書駆動開発の明確性を統合したものです。

では、この新しいアプローチが実際にどう機能するのか、具体的な例で見てみましょう。

LLMを活用した仕様書駆動開発の理論的背景

なぜこの新しいやり方が効果的なのか、まずはソフトウェア開発手法がどう変わってきたかを振り返ってみましょう。

なぜ従来の仕様書駆動開発は行き詰まったのか

多くの開発者が経験したように、従来のソフトウェア開発では「仕様書駆動開発」が主流でした。しかし、この手法には重大な課題がありました。ドキュメント作成の負荷が非常に高い、変更への対応が困難、そして仕様と実装の乖離が発生するという問題です。

2000年代以降、こうした問題への反省からアジャイル開発が広まりました。「動作するソフトウェア」を重視し、「包括的なドキュメント」よりも「個人間の対話」を優先しました。しかし、アジャイル開発にも新たな課題が発生しました。知識の属人化、技術的負債の蓄積、大規模チームでのスケーラビリティ限界といった問題です。

こうして開発の歴史は、「重すぎる文書化」と「軽すぎる文書化」の間で振り子のように揺れ動いてきました。LLMの登場により、この長年の対立を解決する新たな道筋が見えてきました。

LLM時代の新しい仕様書駆動開発

LLMの登場により、従来の仕様書駆動開発の「重いドキュメント作成」という最大の障壁が取り除かれました。これにより、アジャイルの柔軟性と仕様書駆動の明確性を同時に実現できるようになったのです。

LLM時代の開発フロー:
💬 バイブスの対話 → 🤖 AI仕様書生成 → 🧐 人間レビュー → 💻 AI実装 → 🔄 高速反復

従来仕様書駆動の強みを活かし、弱みを克服

要素 従来の仕様書駆動 アジャイル 🚀 LLM時代の新アプローチ
ドキュメント作成 ❌ 重い負担 ❌ 軽視されがち ✅ AIが瞬時に生成
変更への対応 ❌ 硬直的 ✅ 柔軟 ✅ 仕様の高速再生成
知識の共有 ✅ 明文化される ❌ 属人化しがち ✅ バージョン管理された仕様
実装の一貫性 ✅ 設計統一 ❌ ばらつきがち ✅ 仕様に基づく統一実装
開発速度 ❌ 遅い ✅ 速い ✅ AI支援で超高速

実践例：「バイブス」から「仕様」への変換

🧑‍💻 開発者のバイブス（多くの人が経験する典型例）:

「ユーザーがアップロードした画像を、いい感じにリサイズして保存したい。でも、あまり複雑にはしたくない。今度の金曜日にデモがあるから、とりあえず動けばOK。」

🤖 AIによる仕様書への変換:

# 機能仕様: 画像リサイズ機能

## 目的
ユーザーアップロード画像の自動リサイズによる、ストレージ使用量の最適化

## 機能要件
- アップロード時に自動で3サイズ生成（thumbnail: 150px, medium: 800px, original）
- 対応形式: JPEG, PNG, WebP
- リサイズ処理は非同期で実行

## 非機能要件
- シンプルさ優先：既存ライブラリ（sharp）を使用
- 複雑な設定は避け、固定サイズでの処理

🧐 人間のレビューと調整（現実的な制約を考慮）:

「originalは不要。thumbnailとmediumの2サイズで十分。WebPは対応しなくても良い。というかJPEGとPNGだけで十分。今回はMVPだし。」

このプロセスにより、曖昧な「いい感じに」という要求が、明確で実装可能な仕様へと変換されます。

ここまでで、従来のアプローチの限界とLLM時代の新しい可能性をご理解いただけたと思います。では、実際にこの「仕様書駆動開発」がどのように機能するのか、具体的な例を通して見ていきましょう。

次章では、多くの開発現場で必要になる「管理者向けのユーザーデータCSVエクスポート機能」を題材に、AIとの協業による開発プロセスの全体像を、ステップバイステップで詳しく解説します。

ケーススタディ：AIとの協業による実装例

ここでは「管理者向けの、ユーザーデータCSVエクスポート機能」を実装するシナリオを通して、AIとの協業ワークフローを具体的に見ていきましょう。

ステップ1：人間が「目的」を定義する

すべての始まりは、人間による「なぜ作るのか」の定義です。

  • 🧑‍💻 人間の指示 (Prompt):

    「管理者向けに、システムに登録されている全ユーザーの情報をCSVファイルとしてダウンロードできる機能が必要です。これは、マーケティングチームがオフラインで分析するために使います。」

ステップ2：AIが「要件定義書.md」を起草し、人間がレビューする

  • 🧑‍💻 人間の指示 (Prompt):

    「先の目的を基に、要件定義書のドラフトを作成し、その内容を requirements-v1.md というファイルに出力してください。」

  • 🤖 AIの出力 (File Created: requirements-v1.md):

    #### 1. 機能概要
管理者ユーザーが、全ユーザーのデータをCSV形式でエクスポートできる機能。
#### 2. 出力項目
- `userId`, `userName`, `email`, `createdAt`, `lastLoginAt`

  • 🧐 人間のレビュー (Review):

    レビューコメント: 「lastLoginAtは不要。代わりにstatusを追加。また、個人情報保護の観点から、この操作は必ず監査ログに記録するという非機能要件を追記し、requirements-v2.mdとして更新してください。」

  • 🤖 AIの出力 (File Created: requirements-v2.md):

    #### 2. 出力項目
- `userId`, `userName`, `email`, `createdAt`, `status`
#### 3. 非機能要件
- **監査**: 本機能の実行は、必ず監査ログに記録されること。

→ これで、バージョン管理されたMarkdownファイルとして、要求仕様が確定しました。

ステップ3：AIが「設計書.md」を起草し、人間がレビューする

  • 🧑‍💻 人間の指示 (Prompt):

    「requirements-v2.mdの内容に基づき、技術設計書のドラフトを作成し、design-v1.mdとして出力してください。」

  • 🤖 AIの出力 (File Created: design-v1.md):

    **APIエンドポイント**: `GET /api/v1/users/export`
**処理フロー**: 全ユーザー情報をDBから取得し、CSVに変換して同期的にレスポンスする。

  • 🧐 人間のレビュー (Review):

    レビューコメント: 「スケーラビリティに致命的な問題あり。このままではユーザー増でサーバーが停止します。非同期処理に変更し、バックグラウンドでファイルを生成、完了後に通知する方式に設計を根本から変更し、design-v2.mdとして更新してください。」

  • 🤖 AIの出力 (File Created: design-v2.md):

    #### 1. 処理方式
非同期バックグラウンド処理方式
#### 2. APIエンドポイント
- `POST /api/v1/users/export/jobs`: CSVエクスポートジョブを開始
- `GET /api/v1/users/export/jobs/{jobId}`: ジョブのステータスを確認

→ これで、設計に関する重要な意思決定が、バージョン管理されたMarkdownファイルとして記録されました。

ステップ4：AIが「タスク仕様書.md」を生成し、人間がレビューする

  • 🧑‍💻 人間の指示 (Prompt):

    「design-v2.mdに基づき、実装タスクをリストアップし、plan.mdとして出力してください。各タスクには、task-spec-*.md形式のファイル名を割り当てること。」

  • 🤖 AIの出力 (File Created: plan.md):

    1.  `task-spec-01-api-endpoint.md`: ジョブ受付APIの実装
2.  `task-spec-02-background-worker.md`: 非同期Workerの実装
3.  `task-spec-03-csv-generator.md`: CSV生成ロジックの実装

  • 🧐 人間のレビューと指示 (Review & Prompt):

    「計画を承認します。では最初のタスクについて、task-spec-01-api-endpoint.md として、詳細な仕様を生成してください。」

  • 🤖 AIの出力 (File Created: task-spec-01-api-endpoint.md):

    # タスク仕様: ジョブ受付APIの実装
## エンドポイント
`POST /api/v1/users/export/jobs`
## 正常系レスポンス (202 Accepted)
`{ "jobId": "uuid-goes-here" }`
## 異常系レスポンス (403 Forbidden)
ユーザーが管理者権限を持たない場合に返す。

→ これで、実装のゴールとなる、具体的で曖昧さのない「マイクロ仕様書」が、独立したMDファイルとして完成しました。

ステップ5：AIが「タスク仕様書.md」に基づき、コーディングとテストを行う

  • 🧑‍💻 人間の指示 (Prompt):

    「task-spec-01-api-endpoint.mdの内容を完全に満たすように、テストコードと実装コードを生成してください。TDD（テスト駆動開発）のアプローチに従うこと。」

  • 🤖 AIの自律的アクション (TDD Cycle):

    1. テスト作成: task-spec-01-api-endpoint.mdを読み込み、まず管理者権限がない場合に403 Forbiddenが返ることを検証するテストケースを作成。
    2. テスト失敗: テストを実行し、実装がまだないため失敗することを確認。
    3. 実装作成: このテストをパスするための最小限のコード（認証ミドルウェアの呼び出しとエンドポイントの骨格）を実装。
    4. テスト成功: 再度テストを実行し、成功することを確認。
    5. リファクタリング: 上記のサイクルを正常系の202 Acceptedレスポンスについても繰り返し、最後にコード全体のリファクタリングを行う。

  • 🤖 AIの出力 (Generated Code):

    // src/routes/user-export.ts
import { Router, Request, Response } from 'express';
import { authMiddleware } from '../middleware/auth';
import { JobQueue } from '../services/job-queue';

const router = Router();

router.post(
  '/api/v1/users/export/jobs',
  authMiddleware.isAdmin, // 403 Forbiddenを処理
  async (req: Request, res: Response) => {
    const jobId = await JobQueue.add('csv-export');
    // 202 Acceptedを処理
    res.status(202).json({ jobId });
  }
);

export { router as userExportRouter };

  • 🧐 人間の最終レビュー (Final Code Review):

    レビューコメント: 「承認します。task-spec-01-api-endpoint.mdの要求事項はすべて満たされています。命名規則もプロジェクトの慣習通り。マージして、次のtask-spec-02に進みましょう。」

→ 人間は、事前に合意した仕様書と照らし合わせるだけの、極めて効率的なコードレビューが実現できました。

この5つのステップを通じて、曖昧な「バイブス」から始まった要求が、段階的に明確化され、最終的に期待通りのコードとして実現されました。重要なのは、各段階で人間が適切な判断とレビューを行い、AIの生成物を品質の高いものへと導いたことです。

では、なぜこのアプローチが従来の「バイブコーディング」よりも優れているのでしょうか。その理由を詳しく見てみましょう。

よくある失敗パターンと回避策

まず、このアプローチを実践する際によく陥る失敗パターンを理解しておくことが重要です：

❌ 失敗パターン1: 仕様書レビューを軽視する - 「AIが作った仕様書だから大丈夫だろう」と思い、十分な検討をせずに次のステップに進む - 回避策: 各仕様書を実際に「声に出して読む」「他の人に説明する」ことで、理解の甘さを発見

❌ 失敗パターン2: 完璧主義に陥る - 最初の仕様書で全ての詳細を決めようとして、無限にレビューを繰り返す - 回避策: 「十分な確度で次に進む」ルールを決め、詳細は実装段階で調整

❌ 失敗パターン3: AIに期待しすぎる - 「AIがすべて理解してくれるはず」と思い、文脈や制約の説明を省略する - 回避策: 毎回「AIは初見の人」だと思って、必要な情報を丁寧に伝える

注意：このアプローチが適さない場面

このLLMを活用した仕様書駆動開発は強力な手法ですが、すべての開発作業に適用すべきではありません。以下のような場面では、従来の直接的なアプローチの方が効率的です：

❌ このアプローチが過剰な場面: - 使い捨てスクリプト: データ変換やワンタイム処理など、再利用されない短期的なコード - 探索的プロトタイピング: アイデアの検証段階で、仕様が固まっていない試行錯誤のフェーズ - 緊急のホットフィックス: 障害対応など、即座にコードを修正する必要がある場合 - 5-10行程度の単純な機能: 設定値の変更やシンプルなユーティリティ関数

⚡ こんな時は直接コーディングが適切: 「ログファイルのタイムスタンプを日本時間に変換するスクリプトが今すぐ欲しい」 → 仕様書を作る時間があれば直接実装した方が早い

このアプローチは、チームで共有され、長期的に保守される中規模以上の機能開発で真価を発揮します。適用の判断基準は「将来、他の人（または未来の自分）がこのコードを理解・変更する可能性があるか？」です。

なぜこのモデルが優れているのか：開発者の役割変革

このアプローチが単なる「バイブコーディング」よりも優れているのには、明確な理由があります。そしてそれは、開発者の役割そのものの進化と密接に関連しています。

3つの劇的な改善効果

  • 手戻りの大幅な削減: コード実装後の仕様変更は、時間とコストの両面で大きな負担となります。一方、仕様書段階での修正は比較的軽微で済みます。上流工程で適切なレビューを行うことで、下流での大規模な修正を回避できます。

  • スケーラビリティと一貫性の向上: AIが生成する標準化されたドキュメントは、チーム全体の「一元化された信頼性の高い情報源」となります。これにより、チーム内の認識齟齬が解消され、新しいメンバー（人間であれAIであれ）のオンボーディングが円滑に行えます。

  • 開発者のリソースを高付加価値業務に集約: ドキュメント作成業務から解放されることで、開発者は技術選定、設計レビュー、将来のリスク評価といった、より高度で戦略的な業務にリソースを集中できます。

「実装者」から「設計者」への必然的な進化

この新しい協業モデルは、私たち開発者にマインドセットの変革を求めます。

これまでの開発者の価値が、いかに速く品質の高いコードを「書けるか」にあったとすれば、これからの価値は、的確な要求の定義、AIの生成物の「レビュー」、プロジェクト全体の「設計」にシフトしていきます。

手を動かす「実装者」から、全体を俯瞰し意思決定を行う「設計者」へ。これは、AI時代における開発者の必然的なキャリア進化の方向性です。

この変化は決して「開発者の仕事が奪われる」ことを意味しません。実は、これは開発者にとって大きなチャンスです。私たちはより高次元の、より人間らしい仕事に集中できるようになるのです。

将来への展望：仕様書駆動開発が実現する高度なコンテキスト・エンジニアリング

現在の仕様書駆動開発は重要な第一歩ですが、実はこのアプローチ自体が、将来のさらなる進化への基盤を作っています。その鍵となるのが「文脈設計」という考え方です。

仕様書駆動開発がコンテキスト・エンジニアリングの基盤となる理由：

  • 仕様書は構造化された文脈情報として蓄積される
  • 過去の設計決定や要件が明文化され、追跡可能になる
  • AIが理解しやすい形式で知識が整理される

現在、MCP（Model Context Protocol）——Anthropicがオープンソースとして公開した、LLMとローカルリソースを安全に接続するための標準プロトコル——により、LLMがローカルファイルやデータベースにアクセスできるようになっています。将来的には、この技術がさらに進化し、Jira、GitHub、Slack、Google Drive、SharePointなど、チームが日常的に使用する多様なツールと統合されることが期待されます。

具体的には、以下のような統合が実現される可能性があります：

  • Jiraのチケット履歴から過去の要件変更を自動参照
  • GitHubのPRコメントから設計議論の文脈を把握
  • Slackの技術的な意思決定の会話を文脈として活用
  • Google DriveやSharePointの設計文書を横断的に検索・参照

これが実現されれば、蓄積された仕様書と組織の知識ベース全体がAIの高品質なコンテキストとなり、プロジェクト固有の文脈を深く理解した、より精密で一貫性のある出力が可能になると期待されています。

つまり、今から仕様書駆動開発を実践することは、将来のAI協業の質を飛躍的に向上させる「投資」でもあるのです。

今から準備できること：

  • ADR（Architecture Decision Records）の作成習慣
  • コードコメントでの「なぜ」の記録
  • チーム内暗黙知の文書化

こうした技術の実現を待つのではなく、今から知識管理とドキュメンテーションのスキルを向上させることが重要です。優れた文脈情報の整備は、現在の開発効率向上にも直結します。

まとめ：LLM時代の開発者に求められる本質的なスキル

LLMとの協業において重要な気づきは、人間の判断が不要になるどころか、より高度で本質的な判断が求められるということです。

  • AIが得意なこと: ドキュメント作成、計画立案、パターンに基づくコード生成、定型作業
  • 人間がやるべきこと: 目的設定、要件のレビューと承認、設計のレビューと承認、トレードオフの判断、そして最終的な意思決定

LLM時代の開発者に求められる本質的なスキルとは、コードを書く速さではありません。本記事で紹介した仕様書駆動開発を実践し、AIの生成物をいかに的確にレビューし、プロジェクトを成功へと導くかという、高度な判断力と設計能力なのです。

技術は進歩し続けますが、人間の洞察力、判断力、そして創造性の価値は決して失われることはありません。LLMという強力なパートナーを得た今こそ、私たち開発者は本来の力を発揮する時なのです。

今日から始める3つの具体的なアクション

この記事を読んだ後、すぐに実践できる具体的なステップをご紹介します：

1. まず小さく始める

  • 次回のタスクで、いきなりコードを依頼せず「要件定義書を作って」から始める
  • 生成された仕様書を必ず声に出して読み、「これで本当に実装できるか？」を自問

2. テンプレートを作る

  • よく使う仕様書の形式（要件定義、設計書、タスク仕様）をMarkdownテンプレート化
  • チーム内で「AI仕様書レビューのチェックリスト」を作成・共有

3. チーム文化に定着させる

  • 新機能開発時に「仕様書ファーストルール」を導入
  • コードレビューではなく「仕様書レビュー会」を定期開催し、知見を蓄積

さいごに

LLMは、あなたのプロジェクトの締め切りも、ユーザーの顔も、積み上がった技術的負債も知りません。それを知っているのは、あなただけです。

しかし、だからこそ価値があるのです。AIが持たない「文脈」「判断」「責任」こそが、私たち人間の不可欠な価値なのです。

その人間ならではの知識を羅針盤として、AIに「書かせる」べきことと、人間が「レビュー」すべきことを見極め、この強力なパートナーを賢く乗りこなしていきましょう！

免責事項

Copyright © 2025 GMO Aozora Net Bank, Ltd. All Rights Reserved.