はじめに
AI実装で一番つらいのは、速く作れることではなく、後で壊れることです。
- 要件が曖昧なまま実装が進む
- 変更時に影響範囲が追えない
- 「とりあえず動いた」コードが技術負債になる
isdd（Interview-driven Spec-driven Development）は、この問題を「要件 -> 設計 -> コード」をIDでつなぐことで解決します。
リポジトリ: https://github.com/notfolder/isdd
本記事の主張は明確です。
- 非エンジニアは、要件定義書をしっかり確認する
- 設計書は画面イメージ（画面遷移とUI）だけを確認する
- 実装はAIに任せつつ、IDトレーサビリティとe2eで品質を担保する
これにより、バイブコーディングで技術負債を増やすのではなく、非エンジニアでもしっかりしたソフトを作れる状態を作れます。
使い方はかんたん。skill化し、gh skillで公開しているので、下記コマンドで導入。
gh skill install notfolder/req-spec-driven
導入は対話モードで実行し、スキル選択画面で (all skills) を選ぶ。
その後使っているコーディングエージェントを選びます。
あとはお好みのコーディングエージェントツールで、
/isdd-requirements こんなアプリを作りたい
から始めれば、実現可能です。
この記事で伝えること
- isddの本質は「非エンジニアが品質判断できる構造化」にある
- IDは連番ではなく意味スラッグで、要件・設計・コードを接続する
- e2eシナリオを要件化し、実装完了条件を明確化する
- 実運用評価（モデル x エージェントツール）で見えた傾向を共有する
isddの本質
isddは、AIを賢く使うテクニックではなく、レビュー責任を再設計する手法です。
- 要件定義書: 非エンジニアが責任を持って確認する対象
- 設計書: 非エンジニアは画面イメージと画面遷移を確認する対象
- コード: AIが生成し、IDとチェックツールで機械的に整合確認する対象
30年以上の開発経験で重視してきたのは、次です。
- 章構成で「抜け漏れ」が起きにくいこと
- 曖昧な表現を減らしてレビュー観点を固定すること
- 変更時にどこを触るか、機械的に特定できること
このため、isddでは「何を書くか」を先に固定し、モデルの賢さに依存しすぎない運用を作っています。
開発フロー
新規開発
変更開発
IDトレーサビリティ（連番ではない）
isddのIDは RQ-001 のような連番ではありません。
意味を持つスラッグを使います。
- 要件ID:
RQ-[カテゴリ]-[内容略称] - 設計ID:
DS-[DSカテゴリ]-[DS内容略称]-[RQカテゴリ]-[RQ内容略称]
例:
RQ-BK-MANUAL-LOAN-TRACKINGRQ-FT-CREATE-ASSET-LOANRQ-TS-VERIFY-ASSET-LOAN-FLOWDS-FN-CREATE-ASSET-LOAN-FT-CREATE-ASSET-LOAN
トレーサビリティのイメージ
補足:
-
RQ-BK-*（業務課題ID）を起点に紐づける -
RQ-FTRQ-UIRQ-EXRQ-TSRQ-NFRQ-DTRQ-OPは最低1つのRQ-BK-*に紐づける - 紐づかない要件は記述しない
非エンジニアは何をレビューすればよいか
isddでは、レビュー対象を意図的に絞ります。
要件定義書（必ずしっかり読む）
- 業務課題と目的が正しいか
- MVPに不要な機能が混ざっていないか
- e2eシナリオが業務操作を表しているか
- 非機能要件が現実的か
設計書（画面イメージ中心）
- 画面遷移が業務フローと一致しているか
- 画面イメージの入力項目・操作が想定通りか
- 利用者の操作順序に無理がないか
ここを押さえれば、コードを1行ずつレビューしなくても品質判断に参加できます。
e2eをゴールにする理由
AIは、実装とテストを同時に書くと「自己採点」に寄りがちです。
isddでは要件段階で利用シナリオを決め、設計段階でe2e環境まで定義します。
重要なのは「e2eを通す」だけでなく、
- 何をe2eと呼ぶか
- どのシナリオを必須にするか
- 何を禁止するか（簡略化逃げを防ぐ）
を要件側で明記することです。
実運用評価（モデル x エージェントツール）
GWの休み期間中、連日で利用上限まで繰り返し検証しました。
一部は追加課金して継続評価しています。
評価条件
- 題材1: assets-management（備品管理・貸出管理アプリ）
- 題材2: 変更仕様（予約 + 外部DB連携: 社員情報DB）
- 題材3: ドキュメント/コメント削除後のリバースエンジニアリング
- 判定: 元仕様との整合、e2e完走、過剰実装の有無
共通指示:
- 設計とタスクファイルに従って実装
- e2e失敗時は修正を反復し、全件パスをゴールにする
- 別ブランチ実装を参照しない
観察結果サマリ
| モデル | エージェントツール | 所感 | 主な課題 | 総合評価 |
|---|---|---|---|---|
| Copilot auto（モデル可変） | GitHub Copilot | 生成は速い | 要件・設計がMVPからズレる場面あり（例: Streamlit化、画面分離） | △ |
| Sonnet 4.5 | Claude Code | 全体品質は高め | e2e完走したが、要件を間違えたのでイメージとずれていたが、完成度は高い | ○ |
| Haiku | OpenCode | 使えるが軽量寄り | 要件膨張、Mermaid/CRUD不足、単一サーバー前提になりやすい | △ |
| Sonnet 4.5 | OpenCode | 全体品質は高め | e2e完走まで自律で到達しないケースあり | ○ |
| GPT-5.3-Codex | OpenCode | 全体品質は高め | e2e完走まで自律で到達、意外にも一番使える感じ？ | ○ |
| GPT-5.3-Codex | Codex | 要件定義が強い | 実装段で「e2eっぽい代替」で完了主張に寄る場合あり | △ |
| GPT-5.5 | Codex | 修正反復は速い | e2e達成優先で実装簡略化に寄ることがある | △ |
| GPT-5.3-Codex | Codex | 仕様理解は高い | 疑似e2eで達成主張する挙動があり定義厳密化が必要 | △ |
評価から得た示唆
- claude code+sonnet以上のモデル or opencode+(sonnet以上のモデル or GPT-5.3-Codex)が良い感じ
- モデル性能差より、要件と完了条件の定義が先に効く
- IDトレーサビリティとチェックツールがないと、モデル差が品質差として露出しやすい
- 「e2e全件パス」を真に機能させるには、要件側で抜け漏れのないシナリオをユーザーが確認する必要がある
microsoft wazaでの評価
isddでは、microsoft wazaでの評価をしてから、gh skillに公開しています。
全スキル一括実行。gh skill公開前には下記で実際のllmに対して評価を行っています。
bash evals/run-all.sh real
まとめ
本質は、要件定義書を読めれば、非エンジニアでも品質判断に参加でき、バイブコーディングで技術負債を作るのではなく、非エンジニアがしっかりとしたソフトが作れることです。
そのためにisddは、
- 要件と設計の章構成を固定する
- 意味付きIDで追跡可能にする
- 機械チェックで漏れを検出する
- e2eシナリオで完了条件を固定する
という仕組みを用意しています。
AIの能力差は残りますが、プロセスを設計すれば品質は安定できます。
isddは、そのための実戦的な土台です。
この記事の作成過程
- 元ネタ: isdd-対話駆動仕様開発.md
- 参照1:
- 関連記事: