エージェント駆動開発とは何か — バイブコーディングの「次」を整理する
# エージェント駆動開発とは何か — バイブコーディングの「次」を整理する
2024年にバイブコーディングが注目されてから、AI開発の手法をめぐる言葉が増えた。「AI駆動開発」「エージェント駆動開発」「仕様駆動開発」——それぞれが何を指し、どこが違うのか。混乱している人も多いだろう。
ここで取り上げるのは、エージェント駆動開発（Agent-Driven Development / ADE） だ。バイブコーディングや従来のAI駆動開発と何が違うのかを整理しつつ、ADEを実践するうえで欠かせない「仕様設計の考え方」にも触れ ていく。
バイブコーディングとAI駆動開発の違いから始める
エージェント駆動開発を理解するには、まず隣接する概念との違いを押さえておく必要がある。
バイブコーディング（Vibe Coding） は、Andrej Karpathyが2025年に提唱した概念だ。「コードの細部にこだわるのをやめ、AIに対して自分のイメージや意図を自由に伝え、出てきたコードをほぼそのまま使う」スタイルを指す。感覚（vibe）に従ってプロトタイプを爆速で作るには向いている。反面、複雑な業務ロジックや品質が求められる本番システムでは、後から保守しにくいコードが積み重なる問題がある。
AI駆動開発（AI-Driven Development） は、バイブコーディングより広い概念だ。AIをコード生成だけでなく、テスト・レビュー・ドキュメント生成など開発プロセス全体に組み込むアプローチを指す。CopilotやCursor、Claude Codeを使って「人間が設計し、AIが実装を補助する」形が多い。
そしてエージェント駆動開発（ADE） は、一段上の自律性を前提にしている。
エージェント駆動開発とは何か
ADEの本質は「AIエージェントにタスクを委任して、人間は意思決定に集中する」点にある。
従来のAI駆動開発では、人間が設計し、AIが補助する。ADEでは、人間が目標と制約を定義し、AIエージェントが計画から実装まで一連の工程を自律的に実行する。
具体的には次のような場面でADEが使われる:
- 仕様書を渡すと、エージェントがAPIエンドポイント・データモデル・テストコードを一括生成する
- バグレポートを入力すると、エージェントがコードを調査し、修正案を作成・テストまで完結させる
- 要件の変更が入ると、エージェントが影響範囲を分析し、変更箇所の一覧と修正コードを提示する
バイブコーディングと比較すると、ADEは明示的な仕様（コンテキスト）の質に結果が大きく依存するという特徴がある。
「任せる」ためには「伝える」が先にある
ここが多くのチームが見落としがちな点だ。
バイブコーディングは「雰囲気でAIに伝える」スタイルでも一定機能する。プロトタイプなら、多少の意図のズレは許容範囲だ。しかしエージェントに本番開発を任せるなら、曖昧な指示では意図通りの結果が返ってこない。
私たちが実際のプロジェクトで感じたのは、「AIエージェントへの委任の質は、仕様設計の質に比例する」ということだ。
たとえば「ユーザー認証機能を作って」という指示は、バイブコーディングならそのまま投げても動くコードが出る。しかしADEで使うには、次のような情報が必要になる:
- どの認証方式を使うか（JWT? セッション? OAuth?）
- トークンの有効期限と更新ポリシー
- エラーハンドリングのパターン（レート制限、ロックアウト）
- 既存の認証基盤との統合要件
これは「詳細なドキュメントを書け」という話ではない。エージェントが判断できる粒度の情報を渡す、それだけだ。
ADEにおける仕様設計の変化
ADEを実践すると、従来の仕様書の書き方では足りないことに気づく。
従来のウォーターフォール型の仕様書は「人間のプログラマーが読む」ことを前提に設計されている。文章の行間を読んだり、過去の経緯を汲んだり、前提を補完したりできる人間を想定したフォーマットだ。
AIエージェントはそこが違う。行間を読む能力は劣るが、構造化された情報を大量に処理する能力は高い。つまり、ADEに最適化された仕様は「人間が読みやすい仕様書」ではなく、「AIが判断しやすい構造化された仕様」 になる。
具体的には:
- ゴールと制約の明示: 「何を達成したいか」と「やってはいけないこと」を冒頭に書く
- 依存関係の構造化: 機能間の依存関係をグラフ的に整理する
- エッジケースの列挙: 例外的なパターンを箇条書きで網羅する
- 判断基準の記述: 複数の選択肢があるとき、どちらを選ぶかの基準を書く
これを「仕様駆動開発（SDD）」と呼ぶこともある。ADEとSDDは密接に関連している。SDDが「AIが理解できる仕様を設計する方法論」であり、ADEが「その仕様をもとにAIエージェントに開発を委任する実践スタイル」だ。
ADEへの移行で起きる現場の変化
ADEを取り入れたチームで共通して起きる変化がある。
エンジニアの役割がシフトする。 コードを書く時間が減り、代わりに「何を作るか・なぜ作るか」を明確にする時間が増える。実装者からアーキテクトへ、という変化だ。これをポジティブに受け取るエンジニアもいれば、「自分の仕事がなくなる」と感じるエンジニアもいる。
レビューの焦点が変わる。 「コードが正しいか」から「仕様が正しいか」へ移る。AIが書いたコードのレビューより、そのコードを生み出した仕様のレビューの方が重要になる。
上流工程の重要性が増す。 要件定義・設計フェーズのアウトプット品質が、最終的な成果物の品質を決める。ここへの投資を惜しむと、後工程でAIへの再指示や手戻りが増える。
バイブコーディングとADEを使い分ける
どちらが優れているかではなく、用途に応じた使い分けが現実的だ。
| 場面 | 向いているアプローチ |
|---|---|
| アイデアの素早い検証 | バイブコーディング |
| PoC・プロトタイプ作成 | バイブコーディング |
| 本番システムの機能開発 | ADE（仕様ベース） |
| 長期保守が必要なコードベース | ADE（仕様ベース） |
| チーム開発・引き継ぎあり | ADE（仕様ベース） |
バイブコーディングで作ったプロトタイプを、本番展開する段階でADEに切り替える、という流れも有効だ。最初は雰囲気でつくり、形が見えてきたら仕様を整備してエージェントに委任する。
まとめ
エージェント駆動開発（ADE）は、AIエージェントの自律性を前提にした開発スタイルだ。バイブコーディングのような「雰囲気で伝える」アプローチとは違い、AIが判断できる質の仕様を設計することが成功のカギになる。
「AIに任せたら思った通りにならない」という経験をしたことがあるなら、それは多くの場合、AIの問題ではなく仕様設計の問題だ。ADEを実践するチームは、上流工程——要件定義・仕様設計——への投資を増やし、その分だけ実装工程の自動化率を上げている。
AIエージェントに「仕事を任せる」技術は、実はAIではなく人間側に求められるものが多い。何を・なぜ・どこまで作るかを明確にする力が、ADEの時代に最も価値を持つスキルになるだろう。
Atsumellでは、エージェント駆動開発を実践するための要件定義・仕様設計のご支援をしています。 AI開発の上流工程でお困りの方は、お気軽にお問い合わせください。
