AI開発のSDD（仕様駆動開発）とLoop Engineering：仕様から検証までを閉じる

AIコーディングは、画面の試作、定型的なAPI、テストのたたき台などを短時間で作れます。一方、コードが生成されたことと、利用者の要望を満たして安全に運用できることは別です。

指示が曖昧な場合、AIは不足した条件を推測して実装します。正常系は動いても、権限、例外処理、既存データとの互換性、監視、復旧手順が抜けることがあります。修正を重ねるほど、最初の目的と現在のコードが離れていく場合もあります。

AI開発では、コードを書く作業よりも、正解を定義し、検証結果を受けて次の行動を決める作業の比重が高くなります。SDDとLoop Engineeringは、この部分を曖昧にしないための組み合わせです。

バイブコーディング（vibe coding）は、詳細な仕様を決めずに自然言語の指示と生成結果の確認を繰り返し、雰囲気（vibe）で開発を進めるスタイルを指す呼び方です。2025年に広まった言葉で、試作品や個人用ツールを短時間で形にする用途では有効に機能します。

両者は対立する手法ではなく、対象の危険度で使い分けます。壊れても困らない試作はバイブコーディングで速度を優先し、本番運用するコードや他者のデータを扱う変更はSDDとLoop Engineeringの手順に載せます。判断基準は「そのコードが壊れたとき、誰かが困るか」です。

SDDはSpec-Driven DevelopmentまたはSpecification-Driven Developmentの略称で、日本語では仕様駆動開発と呼ばれます。

SDDでは、仕様を一度作って保管するのではなく、実装を生み、完成を判定するための基準として管理します。GitHub Spec Kitは、Spec → Plan → Tasks → Implementという流れを提示しています。仕様には製品の目的と利用者の振る舞いを記載し、技術方式は計画へ、作業単位はタスクへ分けます。

すべての開発で詳細な仕様書を作る必要はありません。小さな修正なら数行の受け入れ条件でも十分です。変更の危険度と影響範囲に合わせて、仕様の粒度を選びます。

AIエージェントへ実装を依頼する前に、少なくとも次の5項目を揃えます。文章量よりも、完了判定に使える具体性を優先します。

Loop Engineeringは、AIエージェントへ一度指示して結果を待つのではなく、目標、現在の状態、利用できる道具、検証、修正、停止を一つの反復として設計する考え方です。2026年時点では用語や範囲が完全に標準化されているわけではありませんが、OpenAIはエージェント中心の開発について、意図を明確にし、テスト、検証、レビュー、フィードバック、復旧を開発環境へ組み込む方法を紹介しています。

ループを長く回すこと自体が目的ではありません。現在の状態を観測し、次の変更を小さく選び、同じ条件で再検証できることが重要です。テストを削除する、判定基準を緩める、対象外の箇所まで変更するといった近道は、あらかじめ禁止事項として定めます。

SDDとLoop Engineeringは競合する方法ではありません。SDDだけでは、仕様を作っても検証結果を受けた修正が人の都度指示に依存します。Loop Engineeringだけでは、反復の判定基準が弱く、動いてはいるが目的と違う状態へ進む可能性があります。

仕様が目標地点を示し、ループが現在地との差を減らします。どちらもコードより上位にある「開発の制御」に関する設計です。

一つの機能を完成させる場合、次の順序で進めます。日程ではなく、各段階の出口条件で管理します。

反復を自動化しても、すべての判断をAIへ渡す必要はありません。影響が大きい操作は、実行前に人が対象、差分、復旧方法を確認します。

最初から複数エージェントや完全自動化を導入する必要はありません。既存チームの開発手順へ、次の順で追加します。