バイブコーディングでは、自然言語で大まかな要望を伝え、AIコーディングエージェントが生成したコードを試しながら完成形に近づけていく。GitHubは、こうした方法は素早く試作品を作る場合には有効だとする一方、本格的なアプリケーション開発や既存コードベースを扱う場合には信頼性の面で課題があると指摘する。

　例えば、生成されたコードがコンパイルできない、要求の一部しか満たしていない、選ばれた技術スタックやアーキテクチャが開発者の意図と異なるといったことが起こり得る。GitHubによると、その背景にはAIコーディングエージェントを検索エンジンのように扱い、曖昧な指示だけで期待通りの成果を求めてしまう問題がある。AIコーディングエージェントはパターン認識を得意とする。一方、何を求められているのかを正確に理解するには、曖昧さの少ない指示が必要だ。

　例えばAIコーディングエージェントに「アプリケーションに写真共有機能を追加して」とだけ指示した場合、AIコーディングエージェントはは明示されていない多数の条件を推測しなければならない。どのようなユーザー体験にするのか、既存システムとどう連携するのか、どのような制約を守るのか。AIコーディングエージェントは不足した情報を補いながら実装を進めるが、その推測が企業側の意図と一致するとは限らない。

　そこでGitHubが重視するのが、AIコーディングエージェントにコードを書かせる前に「何を作りたいのか」を仕様として明確にすることだ。

コードを書く前に「仕様」をAIと共有する

　仕様駆動開発では、最初に仕様を定義し、それをAIコーディングエージェントがコードを生成、テスト、検証する際の基準として利用する。GitHubは仕様を、開発前に作成してそのまま保管する静的な文書ではなく、プロジェクトの進行に合わせて更新する「生きた成果物」と位置付ける。

　開発を進める中で要求が変われば仕様を更新する。内容が複雑になればより細かく整理する。判断に迷った場合も、まず仕様に立ち返る。つまり、コードそのものではなく、「何を実現しようとしているのか」を開発の共通基準にする考え方だ。

　Spec Kitでは、この仕様を中心に、実装計画やチェックリスト、作業項目を作成する。人間が全てのコードを書くのではなく、開発者が方向性を示し、AIコーディングエージェントが成果物の作成を担うことを想定している。

AIコーディングを4つの工程に分ける

　Spec Kitを使った仕様駆動開発は、「Specify」「Plan」「Tasks」「Implement」の4段階で進む。それぞれに明確な役割があり、現在の工程を確認してから次へ進むことがポイントだ。

Specify

　ここでは、使用するプログラミング言語や技術スタックを決めるのではなく、「何を作るのか」「なぜ作るのか」を整理する。誰が利用するのか、どのような課題を解決するのか、ユーザーがどのように操作するのか、どのような状態を成功とみなすのかといった要件を人間が示す。それを基に、AIコーディングエージェントが詳細な仕様を生成する。

Plan

　利用する技術スタックやアーキテクチャ、既存システムとの連携条件、コンプライアンス要件、性能目標などをAIコーディングエージェントに与え、技術的な実装計画を作成させる。企業で利用する場合、自社が標準化している技術やアーキテクチャのルールをここに反映させることもできる。

　社内の設計ルールや技術標準をAIコーディングエージェントが参照できるようにすれば、それらを踏まえた実装計画をAIコーディングエージェントが作成することもできる。

Tasks

　仕様と実装計画を具体的な作業単位に分解するのがTasksだ。例えば「認証機能を作る」といった大きな作業の中の、「メールアドレスの形式を検証するユーザー登録用エンドポイントを作成する」といった、個別に実装してテストできる単位まで作業を細分化する。

　作業を小さくすることで、AIコーディングエージェントが一度に大きな機能を作って方向性を誤るのではなく、個々の作業について結果を確認しながら進めやすくなる。

Implement

　AIコーディングエージェントが各タスクを実装する。AIコーディングエージェントには、仕様によって「何を作るか」、計画によって「どのように作るか」、タスクによって「今何を実装するか」が与えられている。そのため、人間は数千行に及ぶコードをまとめて確認するのではなく、特定の要求に対応した変更単位でレビューできる。

AIに任せても「人間の確認」はなくならない

　仕様駆動開発は、AIコーディングエージェントに開発作業を丸投げする仕組みではない。では、人間は何をすればいいのか。GitHubは、人間の役割として「steer」（方向を示す）だけでなく、「verify」（検証する）ことを挙げる。AIコーディングエージェントが作った仕様は本当に実現したい内容になっているのか。実装計画は現実の制約を考慮しているのか。抜けている要件や例外的なケースはないのか。各段階で人間が確認し、必要に応じて修正してから次に進む。

　AIコーディングエージェントが仕様や計画、コードを生成し、人間がそれらの妥当性を確認するという役割分担だ。

既存システムやレガシー刷新にも使える

　GitHubは、仕様駆動開発が特に有効な場面として3つを挙げている。

　1つ目は、新しいシステムをゼロから構築する場合だ。すぐにコードを書き始めるのではなく、あらかじめ仕様と計画を作ることで、AIコーディングエージェントが一般的なパターンに基づく無難なシステムではなく、開発者が意図したものを作りやすくする。

　2つ目は、既存システムへの機能追加だ。複雑なコードベースに新機能を追加するときは、その機能が既存システムとどう連携するのかを仕様で明確にする。さらに既存のアーキテクチャ上の制約を計画に反映することで、新しいコードを既存環境に合わせやすくする。

　3つ目は、レガシーシステムのモダナイゼーションだ。古いシステムでは、「なぜこの処理になっているのか」と開発当初の意図が分からなくなっている場合がある。仕様駆動開発では、残すべき業務ロジックを改めて仕様として整理し、新しいアーキテクチャを計画した上で、AIコーディングエージェントにシステムを再構築させる方法を想定している。

AI時代は「コード」より「意図」が重要になる

　GitHubは、AIを使ったソフトウェア開発を通じて、「コードが正解」という考え方から「意図が正解」という考え方へ移っていくとみている。

　従来は実際に動くコードがシステムの状態を表す中心的な存在だった。だがAIが仕様からコードを生成できるようになれば、「何を作るべきか」を表した仕様そのものが開発の基準になる。

　要求を変更したい場合は仕様を更新し、それに合わせて実装計画やタスクを作り直し、AIにコードを変更させることもできる。GitHubは、AIによって仕様が実際のコードにつながる「実行可能なもの」になったことが、この変化の背景にあると説明する。

　AIコーディングの導入では、どのAIモデルを使うか、どのツールなら多くのコードを書けるかに目が向きやすい。

　しかし、バイブコーディングから業務システムの開発へ利用範囲を広げるのであれば、それだけでは足りない。「AIに何を作らせるのか」「どのルールを守らせるのか」「何をもって正しい実装と判断するのか」を、AIが理解できる形で定義する必要がある。

　AIにコードを書く作業を任せるほど、人間には仕様を明確にし、AIが作った成果物がその仕様を満たしているかを検証する役割が求められることになりそうだ。

　なおSpec Kitは、「GitHub Copilot」のほか、「Claude Code」「Gemini CLI」などのコーディングエージェントに対応する。

本稿は、GitHubが2026年9月2日に公開したSpec-driven development with AI: Get started with a new open source toolkitを基に作成しました。