発注者がモックまで作る時代──AIが外注の「擦り合わせコスト」を溶かす

2026年、ある事業会社の開発責任者が、開発ベンダーとの進め方を全面的に刷新した。

それまでのやり方はこうだ。要求をWordの仕様書に落とし、ベンダーに渡す。ベンダーが読み解き、見積もり、質問が返ってくる。認識のズレが発覚し、また書き直す。この往復で何週間も溶ける。

彼がやめたのは、その「Wordを投げる」工程そのものだった。自分でモックアップを組み、要件をMarkdownファイルにまとめ、動く形ごとベンダーに渡す。「人が運用する部分」と「AIが駆動する部分」の切り分けは、向こうから提案させる。発注者が完成イメージを先に作るから、擦り合わせがほぼ消える。

なぜ「上流で確定させる」が効くのか

ソフトウェア開発のコストは、後工程ほど跳ね上がる。

NIST（米国立標準技術研究所）の2002年の調査は、ソフトウェアの欠陥が米国経済に年間約595億ドル（当時のGDPの約0.6%）の損失を与えていると算出した。注目すべきはその内訳だ。NISTは「エラーの半分以上が、開発の下流工程や納品後まで発見されない」と指摘し、より早い段階で欠陥を見つける仕組みがあれば約220億ドルが削減できるとした。

つまり、損失の源泉は「上流で決まりきっていないこと」だ。要求が曖昧なまま下流へ流れ、コードになり、テストになり、本番になってから「これじゃない」が露見する。その時点で直すと高くつく。

どれくらい高くつくか。IBM Systems Sciences Institute がよく引かれる目安を出している。設計段階で直すコストを1とすると、実装で6.5倍、テストで15倍、リリース後では60〜100倍。この具体的な数字には学術的な裏付けが薄いという批判もある（The Register が2021年に出典の不在を指摘した）。だが「遅く見つかった欠陥ほど高い」という方向性そのものは、NISTの調査でも、12,000件超のプロジェクトを分析した Capers Jones の研究でも、現場の実感でも一致している。

発注者がモックとMarkdownを先に作るのは、この曲線の一番安い左端で要求を固める行為だ。Wordの仕様書では「読み手の解釈」という余地が残る。動くモックには解釈の余地がない。見たままが仕様になる。

AIが「発注者がモックを作る」を現実にした

ここが2026年の新しさだ。

かつてモックアップを作るのはエンジニアの仕事だった。発注者が自分で動く試作を組むなど、コスト的にありえなかった。だからWordで妥協していた。

いまは違う。発注者本人が、AIコーディングツールに指示してモックを組み、要件をMarkdownで整える。エンジニアを介さず、完成イメージを「動く形」で持てる。だからベンダーに渡すものが、紙の仕様書から実物の試作へと変わった。

この事業会社の責任者が言った言葉が核心を突いている。「学んだからこそ『やれ』と言えるようになった」。発注側が作り方を理解しているから、ベンダーに対して的確な要求が出せる。丸投げではなく、土台を作って渡す。主導権が発注者に戻る。

結論

AIによって発注者自身がモックアップと要件Markdownを先に作れるようになった結果、ソフトウェア外注の主戦場は「仕様書の往復」から「上流で完成イメージを固めて渡すこと」へ移り、NISTが年間約595億ドルと見積もった欠陥コストの最も大きな源泉である“下流での手戻り”そのものを発注側から断てる時代になった。

---

出典

• NIST（米国立標準技術研究所）, “The Economic Impacts of Inadequate Infrastructure for Software Testing” (2002): ソフト欠陥の損失 年間約595億ドル（GDP約0.6%）、半数以上が下流／納品後に発覚、早期発見で約220億ドル削減可能。 https://www.nist.gov/
• IBM Systems Sciences Institute（1981, 内部資料）: 欠陥修正コスト 設計1：実装6.5：テスト15：リリース後60〜100倍（ただし出典の信頼性には批判あり）。
• The Register (2021-07-22): 「バグは本番で100倍高い」の元研究は存在しない可能性を指摘。 https://www.theregister.com/2021/07/22/bugs_expense_bs/
• Capers Jones: 12,000件超のソフトプロジェクト分析。後工程ほど欠陥修正コストが増大する傾向を支持。
• 一次素材: ある事業会社の開発責任者による「開発ベンダーとの進め方を全面刷新」事例（固有名詞は匿名化）。