AIを導入しただけでは、開発は安定しません。コード生成が速くても、目的や制約が曖昧なら、手戻りも同じ速さで増えるからです。
フィールフロウがAI仕様駆動開発を標準にした理由は、AIにたくさん書かせるためではありません。人が決めること、AIに任せること、完了を証明する方法を、着手前から一つの流れにするためです。
結論：AI仕様駆動開発は「実装前後」を標準化する
要点：仕様をAIへの入力として使い、テスト、レビュー、運用確認、学習まで同じ仕様につなげます。
AI仕様駆動開発では、自然言語の依頼をそのままコード生成へ渡しません。まず「誰の、どんな課題を、どの条件で解決し、何をもって完了とするか」をIssueと文書へ固定します。AIはその範囲で調査、実装、テスト案、レビューを支援し、人は目的、優先順位、受け入れ、安全上の判断を担います。
完成の判定も「コードができた」では終わりません。テスト結果、レビュー記録、デプロイ先の応答など、仕様に対応した証拠を確認します。つまり標準化する対象はコーディングではなく、判断から運用までの開発システム全体です。
7文書をAIと人の共通コンテキストにする
要点：最初から大量の文書を作らず、目的、設計、実装、品質、運用を担う7文書から始めます。
フィールフロウの公開リポジトリでは、最小構成を次の7文書と定義しています。
MASTER.md— 文書全体の案内役PROJECT.md— ビジョンと要件ARCHITECTURE.md— システム設計DOMAIN.md— ビジネスルールPATTERNS.md— 実装パターンTESTING.md— テスト戦略DEPLOYMENT.md— 運用手順
7という数に絶対的な意味があるわけではありません。重要なのは、AIが探す場所と、人が更新する正本を先に決めることです。プロジェクトが成長すれば文書は増やしますが、同じ説明を複数箇所へ散らさないことを優先します。
図1：公開リポジトリの7文書と10ステップを、入力・実行・学習の一つの循環として整理。
導入前後で変わったのは、速さより判断の置き場所
要点：レビューで初めて仕様を議論する状態から、着手前に判断し、後工程では証拠を確認する状態へ移しました。
公開しているAI駆動Git Workflowは、従来の6ステップを組み替え、実装、テスト、セルフレビュー、後処理、知見化までを10ステップとして明示しています。
| 観点 | 標準化前に起きやすかったこと | 標準化後の置き場所 |
|---|---|---|
| 目的と範囲 | 会話や担当者の記憶に残る | Issueのユーザーストーリーと受け入れ条件 |
| 設計判断 | 実装中にAIが推測する | 7文書とIssueの制約を参照する |
| 品質確認 | PRレビューで不足に気づく | PR前にテストとセルフレビューを通す |
| 完了判定 | マージを完了と見なす | デプロイ先や公開面まで読み返す |
| 学び | 個人のメモで終わる | マージ後にACEとして次の仕様へ戻す |
この変更で、すべての手戻りが消えたとは考えていません。変わったのは、問題が起きたときに「プロンプトが悪かった」で終わらず、Issue、文書、テスト、運用手順のどこを直すか追跡できるようになったことです。
公開研究も「AIだけでは成果が決まらない」と示している
要点：AI支援の効果は一様ではなく、タスク、経験、対象システム、組織の開発能力によって変わります。
Microsoft Researchの3件の無作為化比較試験は、4,867人の開発者を統合すると、AIコード補完を利用できる群で完了タスク数が26.08%増えたと報告しました。特に経験の浅い開発者ほど採用率と効果が大きい傾向でした。ただし、測ったのは完了タスク数であり、あらゆる現場の品質やリードタイムを同じ割合で改善するという結果ではありません。
一方、METRの無作為化比較試験では、対象リポジトリに平均5年関わる16人が246件の実タスクへ取り組み、2025年前半のAIツールを使える条件では完了時間が19%長くなりました。成熟した大規模リポジトリに詳しい開発者という限定条件であり、現在の全ツールへ一般化はできません。
DORA 2025は、約5,000人の技術専門家への調査と100時間超の定性データから、AIを組織の強みと弱みを増幅する存在と整理しています。これらは同じ指標の比較ではありませんが、ツール導入だけを成果とせず、仕様、品質ゲート、フィードバック経路を一緒に設計する必要性を示します。
最初の一歩は、小さなIssueを6観点で書くこと
要点：全社標準を一度に作らず、実案件1件で「曖昧さを残さず着手できるか」を試します。
最初は、半日から数日で終わる変更を一つ選びます。そのIssueへ、What、How、Where、Constraint、Format、Testの6観点と、ユーザーストーリーの「なぜ」を書きます。空欄があれば、AIに推測させず人が決めます。
次に、7文書のうち今回参照する箇所を結び、実装後は受け入れ条件に対応するテストと実環境の証拠を残します。最後に、迷った点を文書へ戻します。この1周で、追加すべき標準と不要な手続きを自社の事実から判断できます。
残る課題：文書を増やすことが目的にならないようにする
要点：更新されない仕様はAIの精度を下げるため、文書数より正本と更新責任を管理します。
運用を重くしすぎると、文書と実装がずれます。軽微な変更と高リスクな変更へ同じレビュー量を課さず、影響に応じて検証を変える必要があります。また、生成結果の正しさ、セキュリティ、顧客要件の受け入れは人の責任です。AI仕様駆動開発は無人化ではなく、判断と証拠を見える場所へ移す方法です。
FAQ
要点：導入時によく出る疑問を、運用上の判断に絞って整理します。
Q. 7文書を最初から完成させる必要がありますか？
要点：必要最小限から始め、実案件で不足が分かった箇所を育てます。
見出しだけの文書を7つ作ることが目的ではありません。AIと人が参照する正本を決め、現在の判断を短く書くことから始めます。
Q. AIが仕様書も書くなら、人は何を決めますか？
要点：目的、優先順位、制約、受け入れ、安全上の最終判断は人が担います。
AIは論点整理や下書きを支援できますが、不足情報を事実として埋めてはいけません。決められない項目は未確認として止めます。
Q. 効果は開発速度だけで測ればよいですか？
要点：速度に加え、手戻り、欠陥、レビュー負荷、リリース後の不具合を同じ期間で見ます。
コード量やタスク数だけでは、品質低下や作業の細分化を見落とします。導入前後で同じ定義の指標を取り、タスクの種類も記録します。
Q. どのAI開発ツールで使えますか？
要点：特定ツールより、参照する仕様と完了条件を明示できることが重要です。
公開テンプレートはClaude Code、GitHub Copilot、Cursorなどを想定していますが、同じ考え方は別のAIエージェントでも使えます。
まとめ
要点：AI仕様駆動開発は、AIの出力速度を、組織が受け入れられる品質へ変換する運用標準です。
フィールフロウが標準にしたのは、AIが常に速いからではありません。効果が条件によって変わるからこそ、入力となる仕様、途中の品質ゲート、最後の実環境確認、次回へ戻す学びを一つの流れにしました。
最初の一歩は、ツールを増やすことではありません。小さなIssueを一つ選び、「何を、なぜ、どの条件で、どう確かめるか」を書き切ることです。
参考資料・データソース
要点：自社手法は公開リポジトリ、外部の効果は原論文・公式研究ページで確認しました。
- FEEL-FLOW「AI Spec-Driven Development」 — コア7文書、導入方法、公開テンプレート。確認日：2026年8月31日。
- FEEL-FLOW「AI駆動 Git Workflow」 — 10ステップとIssueの6観点。確認日：2026年8月31日。
- Cui, Z. et al. “The Effects of Generative AI on High-Skilled Work,” Microsoft Research, 2025 — 3件の無作為化比較試験、開発者4,867人。確認日：2026年8月31日。
- Becker, J. et al. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, 2025 — 開発者16人、実タスク246件の無作為化比較試験。確認日：2026年8月31日。
- DORA “2025 State of AI-assisted Software Development Report” — 約5,000人の調査と100時間超の定性データ。確認日：2026年8月31日。