Microsoft のプリンシパルソフトウェアエンジニアによる Microsoft for Developers ブログのこの記事は、AI はソフトウェアのデリバリーを速くしたが成果を良くしたわけではなく、AI ネイティブな開発における本当の問題は、要件、設計、実装、検証を当初の意図に沿った状態に保つことだと論じる。記事の答えは 仕様駆動開発 である。構造化された仕様を人間と AI の双方にとって共有された信頼できる唯一の情報源（source of truth）とし、先にプロンプトを投げて後から足並みをそろえるのではなく、まずチームの足並みをそろえてから AI に実行を加速させる、というものだ。
記事はこの実践を、チームがガードレール、要件、制約、受け入れ基準、エッジケースを前もって定め、そのうえでその共有コンテキストから AI にコード、テスト、補助的な成果物を生成させるスペックファーストなアプローチとして定義する。そこでは仕様が、ビジネス上の意図をアーキテクチャ、実装、テスト、検証へと結び付ける結合組織の役割を果たす。記事はこれを実践に移すためのツールキットとして GitHub Spec Kit を紹介し、それを適用したチームから得られた教訓と 3 つの事例を報告している。
要点
- 記事が診断する失敗は「翻訳ロス」である。アイデアがステークホルダーのニーズからプロダクト要件へ、要件からアーキテクチャと設計へ、設計から実装へ、そして実装から検証とリリースへと移る過程で意味が失われることを指す。意図を保持する共有された成果物がなければ、引き継ぎのたびにそれが解釈のステップになってしまうと記事は述べ、AI はそうしたステップを加速できても、一度も解消されなかった曖昧さを正すことはできないとしている。
- プロンプトファーストのワークフローは単純なタスクには有効だが、スコープが広がるにつれて行き詰まるとされる。要件、制約、エッジケースがプロンプトの中にしか存在しないと、永続的な信頼できる情報源のないまま出力だけが速く出てくることになり、記事はこれをアーキテクチャのドリフト、コードのドリフト、一貫性のない実装、レビューの困難化、手戻りに結び付けている。
- 記事がこの実践の利点として挙げるのは、曖昧さと手戻りの減少、プロダクト・エンジニアリング・テストの間の足並みの改善、AI が構造化されたコンテキストに基づいて生成することによる実装の高速化、そして検証が当初の意図に立ち返ることによるデリバリーの予測可能性の向上である。
- この実践は労力のかけどころを変える ―― 意図の明確化と計画により多くを費やし、下流の手戻りで失う分は減る ―― とともに、役割も変えると記事は述べる。プロダクトマネージャーはシナリオと制約の定義に関わり、アーキテクトは計画モデルを形づくり、エンジニアは AI を使って実装を加速し、受け入れ基準が最初から明示されているためテストはより早い段階へ移る。
- 記事は GitHub Spec Kit を、Microsoft が作成したとするオープンソースのツールキットとして説明し、そのライフサイクルを 7 つのステップとして示している。Constitution（原則、標準、ガードレール）、Specify（要件、シナリオ、受け入れ基準）、Clarify（曖昧さ、依存関係、エッジケース）、Plan（アーキテクチャ、フロー、制約）、Tasks（実装可能な単位）、Implement（AI がコードとテストを生成・改良する）、Validate（出力が仕様に合致しているかを確認する）である。
- この実践を適用して得られた教訓として記事が報告するのは、足並みをそろえることは単なるツールの選択ではなくチームの習慣であること、良い仕様は構造だけでなく意図、制約、受け入れ基準を捉えるものであること、計画は実装の品質に不釣り合いなほど大きな影響を与えること、早い段階で明確さを高めるとたいていデリバリー全体の時間が短くなること、そしてすべての変更にライフサイクル全体が必要なわけではないこと、である。記事はこれを「仕様の品質 = 出力の品質」と要約している。
- 3 つの事例はいずれも名前の伏せられた社内プロジェクトである。繰り返し行われていたオンボーディングのフローをパラメータ化された仕様として取り込み、新しい資産タイプのオンボーディングを 2〜3 週間から数日に短縮したと報告するブラウンフィールドのチーム、共有された仕様と計画を用いて大規模な分散プラットフォームで PM、アーキテクト、エンジニアの足並みをそろえたグリーンフィールドのチーム、そしてカスタムプロンプトと品質ゲートのスクリプトに支えられながら、複数のエージェントを使って React と TypeScript のプロトタイプから実際に動くプロダクトへと移行したブラウンフィールドのチームである。
- 導入に向けては 4 ステップのプレイブックを提案している。足並みの問題が目に見えている 1 つの機能で試行し、軽量な仕様を形式化し、そこから実装の成果物を生成して反復し、その後に洗練して規模を広げる、というものだ。そして、プロセスを軽量に保つこと、仕様を生きた成果物として扱うこと、初期段階で仕様を作り込みすぎないことを勧めている。
背景
この記事は、Microsoft のエンジニアが、記事自身が Microsoft によるものとするツールキットについて書いたものであり、事例は計測された比較ではなく名前の伏せられたプロジェクトから報告された成果である。記事が示す唯一の数値であるオンボーディング時間も、統制された結果としてではなく、導入前後の比較として述べられている。
記事はこの時期を AI 支援のタスクから AI ネイティブなワークフローへの移行として位置付けており、そこでは制約要因はもはやコードをどれだけ速く生成できるかではなく、意図をどれだけ明確に捉え、共有し、検証できるかにあると論じている。