2026年のSonarの調査によると、開発者の88%が「AIが生成したコードが技術的負債を増大させている」と回答しています。一方、仕様駆動開発（spec-driven development）の支持者は、規律ある仕様策定のステップを踏むことで、この乖離を食い止めることができると主張しています。

なぜこの問題が重要なのか

人間が曖昧なチケットを受け取った場合、不明点を解消するための質問を投げかけます。対照的に、AIエージェントは空欄を「おそらくこうだろう」という推測で埋め、一見もっともらしく見えるコードを提出してしまいます。この「正解であるかのような錯覚」は高くつきます。同じSonarの調査では、回答者の半数以上が「基本的なチェックはパスしているが、微細な欠陥が隠れているコード」を目にしたことがあると報告しています。これらの欠陥は技術的負債として蓄積され、後のリファクタリングを余儀なくさせ、機能提供を遅らせ、メンテナンス予算を膨らませることになります。

仕様駆動開発とはどのようなものか

仕様駆動開発（SDD）は、現在のプロセスを逆転させます。AIモデルに対して短いユーザーストーリーをプロンプトとして与えるのではなく、チームはコードと同じバージョン管理システム内で管理される、詳細かつエージェントが実行可能な仕様を作成します。仕様は「信頼できる唯一の情報源（single source of truth）」となり、意図、エッジケース、パフォーマンスへの期待値、およびAIモデルが遵守すべき制約事項を記録します。

このプロセスは人間の設計作業に取って代わるものではなく、それをコード化するものです。決定事項を開発者の記憶から具体的なドキュメントへと移すことで、人間と将来のAIエージェントの両方が、なぜそのコードが特定の挙動を示すのかを追跡できるようになります。仕様の作成には事前の労力が必要ですが、曖昧なAIの出力に対して後からデバッグを行うコストは、それよりもはるかに高くなります。

ワークフローの変化

プロダクトバックログ – 項目は簡潔に保ち、意図とハイレベルな受入条件のみを記述します。このリストは引き続き優先順位付けの指針となります。

スプリントプランニング – チームは全体目標を議論し、スプリントゴールに合意しますが、仕様が準備できるまでは詳細な実装には着手しません。

スプリント期間中 – タスクを担当する人は、正確でマシンリーダブル（機械判読可能）な仕様を作成します。仕様には、入力形式、期待される出力、エラーハンドリング、および非機能要件を記載します。仕様はバージョン管理されているため、レビュアーはコードと同様にコメント、修正提案、承認を行うことができます。

完成の定義 (Definition of Done) – クオリティゲートに「仕様のレビューおよび承認済み」を追加します。仕様が実装と同じレビュー基準をパスしない限り、コードは完了とはみなされません。

カンバンへの適応 – 「仕様作成済み (Spec Drafted)」と「仕様承認済み (Spec Approved)」という2つの新しい列を追加します。ワークアイテムは、バックログ → スプリントゴール → 仕様作成済み → 仕様承認済み → 進行中 → 完了 という流れで進みます。この視覚的な変更により、これまで不可視であった調整ステップが明確になります。

仕様の遵守を強制する既存のツール

GitHub Spec KitやAWS Kiroなどのプラットフォームは、AIによるコード生成を開始する前に要件ドキュメントを必須とするゲートを追加しています。これらはAIモデルに取って代わるものではなく、文字通りに解釈するエージェントを人間の意図に合わせるためのものです。仕様を前提条件とすることで、これらのツールは既存のCI/CDパイプラインを壊すことなく、この転換を自動化します。

予想される反発

批判的な意見としては、仕様を書くことは、すでにスピード感のあるアジャイルのケイデンスに摩擦を生じさせるとの声があります。これに対する反論は、「仕様の作成に費やす時間は、曖昧なプロンプトから生成されたAIコードのデバッグに後から費やす時間に比べれば、通常はごくわずかである」というものです。

また、要件の進化に伴って仕様が古くなってしまうのではないかという懸念もあります。これについては、バージョン管理との統合が解決策となります。仕様への変更はすべて新しいコミットとして作成され、レビューがトリガーされ、チームに関連するコードの再評価を強制します。実際、仕様をコードのように扱うことで、ドキュメントを常に最新の状態に保つことができます。

今後の注目点

導入はまだ初期段階ですが、その勢いは感じられます。AIコード生成器の能力が向上するにつれ、正確でマシンリーダブルな「意図」の必要性は高まる一方でしょう。

結論: 曖昧なプロンプトを、具体的でレビュー済みの仕様に変換することは、追加のステップのように感じられるかもしれません。しかし、それは「推測」を「責任ある決定」へと変えるものなのです。