AI時代のスペック駆動開発：出力契約で迷走を止める¶

結論: 出力契約（毎回同じ形で出る出力）を先に固定し、受入基準で合否判定できる状態を作れば、AI協働開発は止まりにくくなる。

AIに実装を委ねるほど、進捗が「見えないまま止まる」現象が起きやすくなります。原因は能力不足ではなく、途中で判定できる成果の設計が欠けていることにあります。この記事では、一般化した原則として「出力契約」「可視化」「受入」の三点から、止まりにくい進め方を示します。

この記事の対象者

AIと協働で新規プロジェクトを進めたいが
途中で方向性が曖昧になりやすい人

この記事のポイント¶

進捗が止まる構造的な原因を言語化できる
出力契約を中心にした再開可能な運用を設計できる
仕様・設計・受入の役割分担を整理できる

止まる原因は「構造」にある¶

中間成果が設計されていない¶

ゴールと現在地だけがあり、途中で評価できる成果がありません。結果として、何を終わらせれば次に進めるのかが不明になります。

可視化より基盤が先行する¶

基盤づくりを先に進めると、目に見える成果が出るまでが長くなります。出力が見えない期間が続くと、前進の手応えが失われます。

合否判定がない¶

固定入力と期待出力が無いと、正しいかどうかの判断ができません。判断の基準がないまま進むと、レビューが止まり、改善も止まります。

止まりやすさは能力ではなく設計の問題

途中で確認できる成果がないと、AIも人も判断できずに詰まります。

再開を可能にする三つの原則¶

原則1：出力契約を固定する¶

まず固定すべきはロジックではなく、==毎回同じ形で出る出力==です。項目名や欄の意味を決め、後から入れ替え可能な部分は仮説として扱います。

最小の出力契約は「毎回同じ欄が出る」ことに尽きます。下のような短いテンプレで十分です。

{
  "as_of": "YYYY-MM-DD",
  "decision": "Proceed|Caution|Pause",
  "summary": "...",
  "reasons": ["...", "...", "..."],
  "proposal": "...",
  "confidence": 0.0,
  "data_health": {"freshness_hours": 0, "missing": []},
  "version": "brief.v1"
}

原則2：レビュー対象を「出力」に移す¶

レビューできるのはコードではなく、見える出力です。変更単位は「画面の一欄を埋める」くらいまで小さくし、差分の比較だけで判断できるようにします。

受入の最小セットは、固定入力・期待出力・差分判定の3点です。例えば以下の粒度で十分です。

入力: fixtures/input_case_01.json
期待出力: expected/output_case_01.json
判定: 差分が出たら、差分理由を出力の理由欄に必ず残す

成功判定の具体例

- "decision": "Proceed"
+ "decision": "Caution"

レビューコメント例: 「confidence が 0.6 未満に下がったため Caution へ変更。reasons欄に根拠を追記済み」

原則3：タスクは「空欄」単位で管理する¶

機能単位ではなく、出力の空欄を埋める順でタスクを並べます。何を次にやるかが常に明確になり、迷走が減ります。

短いサイクルで進めるロードマップ¶

出力の見た目を先に手で作り、正解の形を揃える
画面に表示できる最低限の項目から埋める
データの健全性を先に可視化し、欠損時の挙動を決める
指標を1つずつ増やし、理由文の型を整える
判定と提案を段階的に結び、変化を抑える

出力契約を変更したあとの戻し方

version 欄（例: brief.v1 → brief.v2）をインクリメントし、旧フォーマットの期待出力ファイルは expected/v1/ に退避しておく。差分が大きすぎたら旧バージョンへロールバックして再検討する。

AIへの依頼例¶

依頼文は短くて構いませんが、成果物・非ゴール・変更禁止を明示すると迷走が減ります。

【目的】日次レポートの decision 欄を自動判定する
【成果物】fixtures/input_01.json → expected/output_01.json と一致する出力
【非ゴール】UI実装、データ取得処理
【変更禁止】JSON項目名、version欄の形式
【受入】diff が空なら合格、差分があれば reasons 欄に理由を追記

失敗パターンと回避の要点¶

大きすぎる仕様は分解し、変更単位を小さくする
基盤先行より可視化先行で、手応えを短くする
合否判定を先に作り、出力差分で判断する
正解が曖昧な領域は、仮説と検証の運用に切り替える

まとめ¶

AI時代のスペック駆動開発は、仕様を厚くすることではなく、出力契約と受入を厚くすることが鍵です。目に見える成果を細かく積み上げ、判断できる形に揃えることで、迷走しにくい開発が実現します。次に作るときは、まず「毎回出る一枚」を決めるところから始めてください。