開発者と読み解くAIの世界
AI駆動開発でモックを仕様にする ～自分たちのチームのAIは、いったい誰のために速いのか
実装半減の裏側、開発者は「ユーザーの代理人」になる
2026年8月20日 09:00
Googleは2026年4月、同社の新規コードの75％がAI生成になったと発表しました。2025年後半の時点では50％だったので、半年での伸びとしてはかなり急です。数字の定義は各社バラバラですが、AIが書くコードの総量がこれから増え続けることは疑いようがありません。
つまり、AIがコードを速く書くこと自体は、もう競争軸になりづらくなっています。だとすると、全員の実装速度が加速したこの1年で、成果も比例して上がってきたのでしょうか。
本稿では、まず「実装が速くなった分、成果につながっているのか」という問いに対する調査レポートを紹介します。その上で、成果を出すための手段のひとつとして、私たちAlgomaticがチーム開発で実践している「モックが仕様になる」開発手法を紹介します。先に開発手法による結果を述べると、当初6カ月を見込んでいた大規模開発が4か月に短縮されました。内訳として、実装フェーズは4カ月の見込みが2カ月と、実装をちょうど半分の期間にすることができました。
なぜ実装の差がつくのか
DORA（Google Cloud傘下の開発生産性研究プログラム）が2025年に公開したレポート「State of AI-assisted Software Development」は、約5,000人への調査と100時間超のインタビューから、次の主張を導いています。
AIは増幅器である。組織の強みも弱みも、等しく増幅する。
AI投資のリターンは、ツールそのものからではなく、その土台となる組織のシステムから生まれる、ということです。
このレポートには、特に目を引く発見があります。DORAはAI導入の成果を左右する7つの組織能力を特定しているのですが、そのうち6つは、強ければ効果が大きく、弱ければ小さくなる、という「効き方の差」にとどまります。方向はつねにプラスです。（プラス側についての詳細は上記レポートを参照いただければと思います）
ところがひとつだけ、弱いチームでは効果がマイナスに転じるものがあります。それが ユーザー中心のフォーカス です。
ユーザーフォーカスの強いチームがAIを導入すると、チームのパフォーマンスは向上します。これは想像通りです。しかし、ユーザーフォーカスの弱いチームがAIを導入すると、パフォーマンスはむしろ低下するという結果が出ています。効果が薄まるのではなく、逆方向への動きが加速する。優先順位がユーザーの課題に向いていないチームにとって、AIは「間違った方向へ、より速く進むためのエンジン」になってしまうわけです。
開発者は「ユーザーの代理人」になる
人間がすべてのコードを書いていた時代は、コードを書く過程そのものに、開発者の直感とユーザー理解が自然と染み込んでいました。コードを組んでいる最中に「これ、本当に使われるんだっけ？」とふと手が止まる。その摩擦が、粗いフィルターとして機能していたのだと思います。
AIがコードを書く今、そのフィルターは失われつつあります。だからこそ、開発者の役割そのものが変わっていく必要があります。DORAの表現を借りれば、開発者は「ユーザーの代理人（proxy for the user）」になります。ユーザーの行動や困りごと、望んでいる成果といった文脈をAIに渡し、生成の方向を調整し続ける責任を持つ、という意味です。
これを怠るとどうなるか。アウトプットの量で仕事を測る組織にAIを入れると、実際のユーザー課題を解決しない機能が高速に量産されます。ダッシュボードが開発速度とデプロイ頻度しか映していないなら、その時点でユーザーは見えなくなっている可能性が高いです。
問題は、この考え方を精神論で終わらせず、どうやって開発の仕組みに落とし込むかです。
実践:モックが仕様になる開発
私たちAlgomaticがやっていることはシンプルです。要件定義の段階で、エンジニアがPdMと一緒に、AIで動くモックアップ（以下モック）を作ります。ドキュメントで合意する代わりに、実際に触れるものを見ながら「これじゃない」「こっちの方が近い」を何度も往復して要件を定めていきます。
このときモックはフロントエンド、つまり画面側だけに絞ります。バックエンドまで作り込むと、確認のたびにデプロイや環境構築が必要になり、誰でもすぐに触れる状態を保てないからです。
AIで実装コストが大きく下がった今、仕様を文章で書きながら合意形成を進めるよりも、モックを触ってもらいながら合意形成をする方が速く、認識のズレも少ないと感じています。合意されたモックが事実上の仕様になり、そこから本番コードへ移設していきます。AnthropicのClaude Codeチームでも、PRD（Product Requirements Document／プロダクト要求仕様書）を書く代わりに動くプロトタイプを何十も作るやり方が採用されており、「動くものが仕様になる」という発想は、すでに実地で検証され始めています（参考）。
運用の勘所は3つ
1. コストは前半に「前払い」する
実際の数字に着目すると、要件定義にかける工数はこれまでの開発と比べて、むしろ増えました。エンジニアがプロダクトマネージャーと一緒にモックを作る分、単純にその時間が上乗せされるからです。 そのためこれは「とにかくそれっぽい画面を早く見せる」ための手法ではありません。要件定義という局所では工数を増やし、そのぶん設計以降の手戻りを減らして、本番リリースまでの開発コスト全体を最適化する取り組みです。
ここで参考になるのが、DORAの2024年レポートの推計です。AIの導入度が25％上がると、デリバリーのスループット（変更を本番に流す速さ）は1.5％、安定性は7.2％低下する。コーディングが速くなっても、検証や合意形成がその速さに追いつかなければ、増えた変更量は変更失敗やデプロイ後の手戻りとなって現れる、ということです。
モック駆動はこの構図への対処です。普段ならコーディングを始めてからでないと気づけない粗に、要件定義の段階で先に取り組む。後半で不安定性として現れるはずだったコストを、修正が一番安い前半で前払いしているわけです。
その効果が出るのが設計以降の工程です。冒頭で触れた通り、半年見込みの開発が4カ月に、実装フェーズは4カ月見込みが2カ月に短縮しました。モックが仕様として合意済みなので、フロントのコードは商用品質に整えるだけでよく、バックエンドもAIが仕様通りに新規で作ればよい。「動きの理解」にかかる時間がほとんど要らないのが、速さの理由です。
2. 評価基準は段階で切り替える
要件定義の序盤において、コード品質や本番想定の性能は、いっさい品質評価の対象として見ないようにします。「イメージが合っているか」だけを確認する理由は、最初から品質の観点を持ち込むと、作り込みすぎて往復が遅くなるからです。モックはそもそも使い捨て前提の存在なので、設計投資を意図的に省く判断に意味があります。
ただし、長く育てる本番コードは話が別です。方向性が固まってきた段階からは「このフロントを商用コードとして成立させられるか」という観点を加え、本番移設の入り口で「何を残し、何を捨てるか」を明示的に判断します。この観点を最後まで持ち込まないと、要件定義が終わった瞬間に、結局フロントを作り直すことになります。
3. ドキュメントは「合意の出力」として書く
モックの往復の中で交わされた「これじゃない」という判断は、放っておくと消えてしまいます。そのため私たちは、合意されたモックから逆算してドキュメントを起こします。書く時点で仕様が検証済みなので、推測や「あとで変わる前提の記述」が減り、ドキュメントは薄く正確になります。
このとき貯めるのは、要求が変わっても変わらない情報です。ドメイン情報（目的・目標・手段）、意思決定の記録（なぜ採用したか・なぜ却下したか）、顧客情報（KPIやステークホルダー）。これが本番移設時にAIへ渡すコンテキストになり、次の開発の土台として積み上がっていきます。
明日からチームに持ち帰るために
この実践を自分のチームで試していただけるなら、最初に確認しておきたいのは次の5点です。
- モックはフロントエンドのみに絞る
- 評価基準は途中で切り替える。最初は「イメージが合っているか」のみ、方向性が固まってからは「商用コードとして通用するか」を加える
- 却下した案も記録する。あとでドキュメントを書く際の一次情報になる
- 要件定義後はフロントを磨いて残し、バックエンドはAIに新規で作らせる
- ドキュメントは合意後に書く。先に書くと結局ドキュメント駆動に戻る
どれかひとつでも欠けると、結局フロントを作り直すことになるか、往復の記録が失われて、次のプロジェクトでも同じ迷いを繰り返すことになると思います。
開発のボトルネックは、実装から判断へ移りつつあります。AIはチームをどこへでも、これまでの何倍もの速さで連れて行ってくれます。だからこそ、最後に自分たちに問いたいのはこれです。
自分たちのチームのAIは、いったい誰のために速いのでしょうか。
著者プロフィール：坂本 一樹
ソフトバンク株式会社に新卒で入社し、携帯電話の大規模ネットワークに関わったのち、基地局管理システムのアーキテクチャ／インフラのリードを経験。その後、スタートアップやジョイントベンチャーを経験し、SaaS系システムや課金系システムのAIを含めたシステムアーキテクチャ構築から運用までプロダクト開発に従事。2024年10月に、生成AIの可能性に着目しAlgomaticに参画。 2026年6月よりVPoEとして、エンジニア組織全体とともに組織全体のAI駆動開発に注力。
・株式会社Algomatic：https://algomatic.jp/
