AI駆動開発でモックを仕様にする — 実装半減の裏側

こんにちは。Algomatic VPoEの坂本(ikki0006)です!

Googleは2026年4月、新規コードの75%がAI生成になったと発表しました。2025年後半は50%だったので、半年でのこの伸びはかなり急です。Microsoftも2025年時点で、リポジトリ内コードの20〜30%が「ソフトウェアによって書かれている」とCEOのNadella氏が語っています。

もちろん、各社の数字の定義はバラバラです。補完の受け入れ数なのか、エージェントが生成した分なのか、承認済みのものだけを数えているのか。なので厳密な横比較にはあまり意味がありません。それでも、方向性としてAIが書くコードの総量が増えていくことは疑いようがないと思っています。その中でAIがコードを速く書くこと自体は、もう競争軸にはなりにくくなってきました。

だとすると、全員が速くなったはずのこの1年で、なぜ成果の出るチームと出ないチームに分かれるのでしょうか。

今回は、AI駆動開発の成果を分けるのは「速さ」ではなく「ユーザー課題を解けるかどうか」だったというDORAの記事と、それを踏まえて私たちAlgomaticで実践している「モックが仕様になる開発」について書きます。

この問いに対して、DORA（Google Cloud傘下の開発生産性研究プログラム）の2025年レポート「State of AI-assisted Software Development」がひとつの答えを出しています。約5,000人への調査と100時間超の定性インタビューから導かれた記事の主張は、次のようなものです。

AIは増幅器(アンプリファイア)である。組織の強みも弱みも、等しく増幅する。

AI投資のリターンは、ツールそのものからではなく、その土台となる組織のシステムから生まれるということです。

実際、データにはやや奇妙な非対称が見られます。DORAの調査とは別に、Faros AIが1万人超の開発者テレメトリを分析したレポートによると、個人活動レベルではPRマージ数が98%増えているのに、組織のデリバリー指標はほぼ横ばいなのです。個人の速度向上が、チームの境界のどこかで霧散してしまっている、と読めます。

この主張を裏付ける証拠として、レポートの中でもとくに目を引くものがあります。DORAが特定した7つのケイパビリティのうち、唯一「符号が反転する」ものです。他の6つのケイパビリティは、強さに応じてAI導入の効果が大きくなったり小さくなったりするだけで、方向自体はつねにプラスです。ところがこの一つだけは、ケイパビリティが強いチームでは効果がプラスに、弱いチームでは効果がマイナスに転じます。

それが、ユーザー中心のフォーカスです。

ユーザーフォーカスが強いチームがAIを導入すると、チーム性能は向上します。ここまでは想像どおりです。ですが、ユーザーフォーカスが弱いチームがAIを導入すると、チーム性能はむしろ低下するという結果が出ています。効果が薄まるのではなく、逆方向への動きが加速する、という点が重要だと思っています。優先順位がユーザーのニーズに向いていないチームにとって、AIは「間違った方向へ、より速く進むためのエンジン」になってしまうのではないでしょうか。

開発者は「ユーザーの代理人」になる

なぜこういうことが起きるのか、少し考えてみます。

人間がすべての行を書いていた時代は、コードを書く過程そのものに、開発者の直感とユーザー理解が自然と染み込んでいました。コードを組んでいる最中に「これ、本当に使われるんだっけ」とふと手が止まる。その摩擦が、粗いフィルターとして機能していたのだと思います。

AIが書く今、そのフィルターは失われつつあります。だから、開発者の役割そのものが変わっていく必要があるというのが私の理解です。DORAの表現を借りれば、開発者は「ユーザーの代理人(proxy for the user)」になります。ユーザーの行動やペインポイント、望んでいる成果といった文脈をAIに渡し、生成の方向を継続的に調整し続ける責任を持つ、という意味です。

この動きは、DORAだけが言っている話ではないと思っています。PalantirやOpenAIなどが採用してきたForward Deployed Engineer(FDE)というロールも、エンジニアが顧客の現場に入り込み、要件そのものを汲み取りながらシステムを作っていくという点で、根っこは同じ発想です。「ユーザーの代理人」化は、AI時代特有の新しい要請というよりも、一部の企業がすでに制度化していた働き方が、AIの普及によって一般的なエンジニアの役割にまで広がってきた、と見たほうが近い気がしています。

これを怠るとどうなるか。アウトプットの量で仕事を測るフィーチャーファクトリー的な組織にAIを入れると、実際のユーザー課題を解決しない機能が高速に量産されてしまいます。活動量は高いのにインパクトが低い自動化、と言い換えてもいいかもしれません。ダッシュボードがベロシティとデプロイ頻度しか映していないなら、その時点でユーザーは見えなくなっている可能性が高いです。

ここで問題になるのは、「ユーザーの代理人」という考え方を精神論で終わらせず、どうやって開発の仕組みに落とし込むかだと思います。

Algomaticでの実践:モックが仕様になる開発

海外でも近い実践は出始めています。たとえばAnthropicのClaude Codeチームでは、PRDを書く代わりに、機能を出荷する前に何十もの動くプロトタイプを作るやり方が採られています。Claude Codeの作者であるBoris Cherny氏は、静的なモックやFigma、あるいはPRD(プロダクト要求仕様書)から始めていたら出荷できなかっただろうと語っています。動くものが仕様になるという発想は、すでに実地で検証され始めているわけです。ここでは、私たちAlgomaticで実際に回している開発のかたちを書きます。

やっていることはシンプルで、要件定義の段階で、エンジニアがPdMと一緒に、AIで動くモックを作ります。このときモックはフロントエンドだけに絞ります。バックエンドまで作り込むと、確認のたびにデプロイや環境構築が必要になってしまうので、フロントだけで完結させることで、誰でもすぐに触って確認できる状態を保っています。ドキュメントで合意する代わりに、実際に触れるものを見ながら「これじゃない」「こっちの方が近い」を何度も往復するわけです。AIによって実装コストがかなり下がった今、仕様を文章で書き切るより、モックを触ってもらいながら合意形成をする方が速いですし、認識のズレも少ないと感じています。合意されたモックが事実上の仕様になり、そこから本番コードへ移設していきます。

実際の数字で言うと、要件定義にかける工数はむしろ増えました。エンジニアがPdMと一緒にモックを作る分、単純にその分の時間が乗るからです。なので、これは「とにかく早くなる」取り組みではありません。ただ、普段ならコーディングを始めてからでないと気づけないような粗や、価値検証が必要な部分に、要件定義の段階でいち早く取り組めるのが強みだと感じています。その分、後半での手戻りが発生しにくくなるので、トータルで見ると実質的には早くなっていると言えます。

はっきり早くなるのは、設計以降の工程です。当初は半年を見込んでいた大規模開発が、実際には4ヶ月まで縮みました。とくに縮んだのは実装のフェーズで、4ヶ月かかると見ていたところが2ヶ月、ちょうど半分になっています。モックが仕様として合意済みなので、フロントのコードは商用品質に整えるだけでよく、バックエンドもAIが仕様どおりに新規で作ればよいので、動きの理解にかかる時間がほとんどかからないのが早さの理由です。

振り返ってみると、このやり方には、AI時代の開発規律がいくつか含まれています。

ひとつは、仕様が最上位に来るという点です。ただし、仕様を確定する手段が、スペック駆動開発の教科書とは逆転しています。「仕様書を書いてからAIに渡す」のではなく、「AIと一緒に作ったモックが仕様になる」という手段です。仕様を実装より先に確定させるという順番自体は変わっていません。仕様を書くコスト自体が下がったわけではなく、実装コストが下がった結果として、仕様を確定する一番速い手段が「動くものを触ってみる」になった、ということだと理解しています。

もうひとつは、判断そのものが資産になるという点です。モックの往復の中でPdMとエンジニアが交わした「これじゃない」という判断は、放っておくとそのまま消えてしまいます。だから、合意されたモックから逆算してドキュメントを起こすようにしています。ここでも順序が逆で、ドキュメントは実装の入力ではなく、合意の出力として書かれる、というイメージです。書く時点ですでに仕様が検証済みなので、推測や「あとで変わる前提の記述」が減り、ドキュメント自体は薄く、正確なものになります。そしてそれが本番移設時にAIへ渡すコンテキストになり、次の開発の土台としてそのまま積み上がっていきます。社内文脈の整備が、専任のプロジェクトとしてではなく、開発フローの副産物として自然に回っている感覚です。

ここでひとつ工夫しているのが、モックの評価基準を段階によって変えることです。要件定義の最初のうちは、モックがコード品質や本番想定のパフォーマンスを満たしているかは見ません。あくまで「イメージが合っているか」だけを確認します。ただし、方向性が固まってきた段階からは、「このフロントを本当に商用コードとして成立させられるか」という観点を加えます。最初からこの観点を持ち込むと作り込みすぎて往復が遅くなりますし、逆に最後まで持ち込まないと、要件定義が終わった瞬間に結局フロントを作り直すことになってしまいます。要件定義が終わったタイミングで、フロントのコードを商用品質に整え、バックエンドはAIに新規で作ってもらう、という切り分けにしています。ここまで含めて、はじめてこのフローはうまく機能すると考えています。

明日からチームに持ち帰るとしたら

この実践をもし自分のチームに持ち帰りたいと思っていただけるなら、最初に確認しておきたいのは次の5点です。

• モックはフロントエンドのみに絞る。

• 評価基準は途中で切り替える。最初は「イメージが合っているか」のみ、方向性が固まってからは「商用コードとして通用するか」を加える。

• 却下した案も記録する。あとでドキュメントを書く際の一次情報になる。

• 要件定義後はフロントを磨いて残し、バックエンドはAIに新規で作らせる。

• ドキュメントは合意後に書く。先に書くと結局ドキュメント駆動に戻る。

どれかひとつでも欠けると、結局フロントを作り直すことになるか、往復の記録が失われて、次のプロジェクトでも同じ迷いを繰り返すことになると思います。

ボトルネックは、実装から判断へ移りつつあるというのが、ここまで書いてきた実感です。AIはチームをどこへでも、これまでの何倍もの速さで連れて行ってくれます。だからこそ、最後に自分たちに問いたいのはこれです。

自分たちのチームのAIは、いったい誰のために速いのでしょうか。

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では、「AI時代の企業OSを作る」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

参考リンク

• Googleの75%の出典 — Sundar Pichai氏によるCloud Next 2026(2026年4月22日)に合わせたブログ投稿。「新規コードの75%がAI生成・エンジニア承認済み、昨秋の50%から上昇」。報道: https://www.fastcompany.com/91531519/google-ceo-says-75-of-the-companys-code-is-ai-generated

• Microsoftの20〜30%の出典 — Meta LlamaCon(2025年4月29日)でのNadella氏とZuckerberg氏の対談。「リポジトリ内のコードの20〜30%はソフトウェアによって書かれている」。報道: https://www.cnbc.com/2025/04/29/satya-nadella-says-as-much-as-30percent-of-microsoft-code-is-written-by-ai.html

• DORA 2025 State of AI-assisted Software Development(日本語版あり): https://cloud.google.com/dora

• DORA AI Capabilities Model(7つのケイパビリティ詳細): https://dora.dev/ai/capabilities-model/report/

• Farosによる1万人超の開発者テレメトリ分析(個人のタスク完了21%増・PRマージ98%増、組織指標は横ばい): https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025

• incident.io — Claude CodeとGit Worktreesによる並列開発: https://incident.io/thedebrief/shipping-with-claude-code-and-worktrees

• Claude Codeチームの開発実態(1機能につき10以上のプロトタイプ): https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built

• Boris Cherny氏(Claude Code作者)のインタビュー — 「PRDはプロトタイプに置き換わった」の出典: https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny