こんにちは！IDCフロンティア 運用システム部の北條です。
最近、AIを使ったコーディングエージェントが当たり前の時代になりました。しかし、「AIに指示を出しても、思っていたものと違うコードが出てくる」「複雑な機能をお願いするとAIが迷子になる」といった経験はありませんか？
今回は、そんなAIコーディングの課題を解決し、開発体験を次のレベルへと引き上げる「仕様駆動開発（Specification-Driven Development: SDD）」について、GitHub CopilotとAIコーディング向けフレームワークである「OpenSpec（GitHubリポジトリ）（Fission-AI）」の組み合わせをご紹介します。
仕様駆動開発（SDD）とは
一般的に仕様駆動開発（SDD）とは、プログラムを書く前に仕様書（OpenAPI/Swaggerなど）を定義し、それを「正（Single Source of Truth：信頼できる唯一の情報源）」として開発を進める手法を指します。
近年では、これに加えて「AIに対する要件（仕様）をドキュメント化して合意してからコードを書かせる」という、AI時代の新しいSDDも注目されています。
なぜ仕様駆動開発なのか？
ソフトウェア開発において、「事前に仕様や設計をしっかり行ってから実装する」、あるいは「実装後にチームのために丁寧にドキュメントを残す」という文化は、システムの品質を担保し、保守性を高めるために非常に重要です。
では、なぜ今、AIコーディングの文脈で「仕様駆動開発（SDD）」という言葉が改めて強調されているのでしょうか？
AIとの開発における「コンテキスト問題」
私たち人間同士の開発であれば、別のツールにある仕様書を読んだり、口頭で補足したりすることで文脈（コンテキスト）を共有できます。しかし、AIアシスタント（LLM）は「与えられたコンテキストがすべて」です。
チャット欄だけで「この機能を作って」と指示を重ねていくと、AIはすぐに過去の要件を忘れ、コードの整合性が崩れてしまいます。AIに精度の高いコードを書かせるためには、「AIが常に参照できる場所に、過去の経緯と明確なゴール（仕様）を置いておくこと」が絶対条件になります。
「人間が書く」から「AIに生成させ、人間がレビューする」へ
ここでOpenSpecのようなSDDツールが真価を発揮します。 従来の仕様作成やドキュメント残しを否定するのではなく、その重労働をAIの力で自動化・効率化しようというのがSDDの核心です。
- 仕様の「自動生成（ドラフト）」 人間がゼロから仕様書をタイピングする必要はありません。「こんな機能が欲しい」とAIに伝えると、AI自身が「自分が実装するために必要な仕様やタスクリスト」をMarkdownとして自動で書き出してくれます。
- 人間は「レビューと承認」に集中 私たちは、AIが生成した仕様（提案内容、設計、ステップバイステップのタスク）をサッと読み、「ここはこう直して」と指示するだけです。人間とAIの間で「これを作ろう」という合意が取れてからコードを書き始めます。
- 常に最新のドキュメントが残る 実装が終わった後、「コードは動くけどドキュメントがない（または古い）」という状況に悩まされることはもうありません。合意した仕様書やタスクリストがプロジェクトの履歴としてそのまま残るため、「開発を進めること＝ドキュメントが整理されること」になります。
つまり、AI時代の新しいSDDとは、「これまで私たちが大切にしてきた『仕様やドキュメント』の価値をそのままに、作成のプロセスだけをAIに任せて劇的にショートカットする」という、極めて合理的でエンジニアに優しいアプローチなのです。
※画像はNano bananaで生成
バイブコーディング（Vibe Coding）の限界
現在主流になりつつあるのが、チャットでAIとやり取りしながら、その場の情報でコードを生成していく「バイブコーディング（Vibe Coding）」です。
スピード感があり手軽な反面、以下のような大きな弱点があります。
- コンテキストの喪失: 要件や仕様がチャットの履歴（コンテキスト）に埋もれてしまい、AIが過去の指示を忘れたり、矛盾したコードを書いたりする。
- 予測不能な結果: 「仕様」という明確なゴールがないままコードを書き始めるため、AIの出力が安定せず、手戻りが多くなる。
※画像はNano bananaで生成
他のSDDツール・開発手法との比較表
仕様をベースにAIと開発を進めるツールにはいくつかのアプローチがあります。以下は代表的なツールや手法の比較です。
| 比較ポイント | 🌟 OpenSpec | GitHub Spec Kit | cc-sdd | バイブコーディング (ツールなし) |
|---|---|---|---|---|
| ツールの重さ・導入 | 軽量 (提案→実装のシンプル構成) | 軽量 (Python等のセットアップ) | 厳格 (4フェーズの明確な承認制) | なし（チャットのみ） |
| 開発プロセスの柔軟性 | 高い (反復・後戻りが自由) | 低い (ウォーターフォール的) | 中 (各フェーズで承認の壁がある) | 自由だが計画性なし |
| 既存プロジェクトへの適応 | ◎ 非常に得意 (変更履歴を綺麗に管理) | △ (新規立ち上げ向き) | 〇 (Steering機能でルールを記憶) | △ (文脈が壊れやすい) |
| 日本語対応 | 〇 (プロンプトで対応可能) | 〇 | ◎ (国産ツールで自然な日本語) | AIの性能次第 |
| ターゲット層・用途 | 個人〜既存の複雑なプロジェクト | ０からの開発、厳格な仕様が求められる大規模開発 | 手戻りを絶対に防ぎたいチーム開発 | 単体の軽微な実装、スクリプト |
OpenSpecの選定理由
OpenSpecは、ガチガチのフェーズゲート（承認の壁）を設けず、必要に応じていつでも仕様やタスクを修正できる身軽さを持っています。さらに、既存の複雑なプロジェクトに後から導入して、変更履歴をスマートに管理できる点も、日々の運用において大きなメリットになります。 「バイブコーディングのスピード感」と「仕様ベースの安全性」を、最も心地よいバランスで両立しているのがOpenSpecなのです。これが、OpenSpecをチーム内で選定した最大の理由です。 選定するツールに正解はない為、チームごとにその時の状況で求める機能を満たす仕様駆動開発ツールを選ぶことが重要だと思います。
「OpenSpec」を利用する具体的なメリット
1. 並行開発の加速
OpenSpecを使ってAPIの仕様（エンドポイントやスキーマなど）をAIと素早く定義すれば、即座にモックサーバーを構築できます。バックエンドの実装完了を待たずして、フロントエンド側は開発を進められます。
2. ドキュメントの自動生成
OpenSpecは機能の提案時に proposal.md（要件）、specs/（仕様）、design.md（技術的アプローチ）といったファイルを自動生成します。READMEなどと合わせてプロジェクト内に最新の仕様が常にファイルとして残り、チーム全員が確認できます。
3. バリデーションの自動化
AIに生成させた正確な仕様（OpenAPIのYAML等）をベースにすることで、Prismなどのツールを活用し、「仕様に沿わないリクエストを自動で弾く」仕組みが容易に作れます。
4. クライアントコードの自動生成
確立された仕様を元に、TypeScriptの型定義やAPIクライアントを自動生成することで、フロントエンドの型安全な開発が可能になります。
5. テストコードの自動生成
OpenSpecが生成する tasks.md（実装タスクのリスト）にテスト要件を含めることで、Copilotが仕様に100%準拠したテストケースを自動で生成し、動作確認が非常に容易になります。
6. 精度の向上（資産としての仕様書）
OpenSpecには実装完了後に仕様を蓄積する機能があります。開発を重ねるごとにプロジェクトの仕様書が蓄積・アップデートされ、AIのドメイン知識（コンテキスト）が洗練されていくため、後続のコード生成精度が飛躍的に高まります。
7. バイブコーディングとの違い（「指示」から「合意と実行」へ）
通常、AIコーディングはチャットで「〇〇を作って」「次に〇〇して」と一つ一つ指示（命令）を出しますが、要件がチャット履歴に埋もれてしまい、AIの挙動が不安定になりがちです。 OpenSpecを使うと、「事前に仕様（Markdown）を生成して人間とAIで合意し、その後一気に実装タスクを走らせる」という運用に変わります。これにより、手戻りが極めて少ない一貫した開発が実現します。
実践：構築方法や実装までの流れ
実際にFission-AIのOpenSpecとGitHub Copilotを使った開発の流れを見てみましょう。
Step 1: 導入
まずはnpmでOpenSpecをグローバルインストールし、プロジェクトで初期化します。
※node.js バージョン20以上であらかじめ準備が必要です。
実行コマンド npm install -g @fission-ai/openspec@latest cd your-project openspec init
カーソルを移動させて、GitHub Copilotを選択し、enterを実行。
VSCode Chatでopsxが指定出来るようになります。
指示書を日本語で記載していきたい場合はopenspec/config.yamlに日本語化を指定するコンテキストを追加します。
Step 2: 仕様の提案（Propose） GitHub Copilotのチャット（または連携ツール）で、以下のコマンドを使って作りたい機能（APIなど）を伝えます。 サンプルで簡単な計算機ツールを作っていきます。
すると、AIが openspec/changes/simple-calculayor/ ディレクトリに以下のファイルを作成します。
proposal.md(目的と概要)specs/(APIなどの詳細な要件)design.md(技術的な実装方針)tasks.md(実装するチェックリスト)
Step 3: レビューとモック化
生成されたファイルを人間がレビューし、必要であれば修正します。ここでアプリケーションの仕様を確定させます。
※今回のサンプルは対象外ですが、API仕様(OpenAPI)等をここで確定させます。
※アプリケーションのフロントエンドとバックエンドで担当が分かれている場合でも、片方をモック化して並行開発することも容易にできます。
Step 4: 実装の適用（Apply） 仕様に合意したら、実装を指示します。
GitHub Copilotは tasks.md にリストアップされた項目（バックエンドの処理、テストコードの作成など）を、仕様書という「正」の情報を参照しながら自動で実装していきます。
タスクが完了したら、動作を確認。
問題なく実装されました。
Step 5: アーカイブと仕様の蓄積（Archive） 実装とテストが完了したら、以下のコマンドで変更をアーカイブします。
機能ごとのフォルダが履歴としてアーカイブされ、プロジェクトのメインの仕様（コンテキスト）が最新状態にアップデートされます。
次の開発時には、AIがこの蓄積された最新仕様を読んでくれるようになります。
アーカイブした履歴をGitHubのリポジトリに管理してチームメンバーと共有出来ます。
まとめ：AIとの協働をスマートにするために
AIコーディングの進化により、私たちソフトウェアエンジニアの役割は「コードをタイプすること」から「AIに正しい仕様（意図）を伝えること」へとシフトしています。
しかし、単にチャット欄にプロンプトを打ち込むだけの「バイブコーディング」では、小規模なスクリプトなら良くても、本格的なアプリケーション開発ではすぐに限界を迎えます。チャット履歴が長くなるにつれてAIは文脈を見失い、プロンプトの微調整に時間を奪われる本末転倒な事態に陥ってしまいます。
仕様駆動開発（SDD）ツールは、人間とAIの間に「仕様（Spec）」という共通言語の橋を架けてくれます。
従来のような重苦しい仕様書を人間が手書きする必要はありません。AIが提案（Proposal）やタスクリスト（Tasks）のドラフトを作成し、人間はそれをレビューして微修正するだけです。合意が取れた「明確なタスクリスト」に沿ってAIが実装を行うため、出力結果が極めて予測しやすくなり、バグや手戻りが劇的に減少します。
また、特定の企業のエコシステムやIDEに依存しないオープンな設計を持つツールを選ぶことも大きなポイントです。自分が使い慣れたエディタや、その時々で最も優秀なAIモデルを自由に組み合わせながら、一貫したワークフローを維持できます。個人開発のプロトタイピングから、エンタープライズの巨大な既存コードベースの改修まで、あらゆる規模にフィットする柔軟性が重要になります。
「AIのスピード感を活かしつつ、エンジニアリングの確実性を担保したい」 そう考えるすべての開発者にとって、モダンなSDDツールは現在のAI開発エコシステムの中で最も理にかなった選択肢です。AI任せの予測不能な開発から卒業し、仕様ベースのスマートなAI協働開発へステップアップしたい方は、ぜひ今日からSDDツールをプロジェクトに組み込んでみてください！（本記事で紹介したOpenSpecは手軽に始められるため非常におすすめです）
最後にワンポイントですが、LLM(Claude,Gemini,GPT等)を利用する際、プロンプトや仕様の記述を英語にした方が推論の精度が上がる傾向にあります。とはいえ、チームの共通言語やドメインの複雑さに合わせて、日本語と英語を柔軟に使い分けながら運用していくことが成功の秘訣だと思います。
IDCフロンティアでは、こうしたモダンな開発手法を積極的に取り入れ、より高品質でスピーディなサービス提供を目指しています。ぜひ皆様の現場でも、OpenSpec等のツールを使った「次世代の仕様駆動開発」にチャレンジしてみてください！
