AI駆動開発の実践例
AI駆動開発における要件定義と実践 ～ソフトウェアを仕様のマスタとして「解決すべき課題」を見極める
［第2回］プロトタイプが変える要件定義
2026年9月10日 09:00
AI駆動開発によって変わるのは、コードを書く工程だけではありません。「何を作るか」を決める要件定義の進め方も変わり始めています。
従来は、ドキュメントやデザインツールで仕様や画面イメージを固めてから、ソフトウェアを開発するのが一般的でした。しかし、静止した画面や文章だけでは、本当に業務上の課題を解決できるのか、期待する業務の流れを実現できるのかまで十分に確認するのは困難です。
私たちAlgomaticでは、AIを使って早い段階から動くプロトタイプを作り、顧客と確認しながら要件を決める方法を実践しています。要件をすべて固めてから開発するのではなく、まず動かし、そこから必要な仕様を発見していく進め方です。
この実践は、文書ではなく動くプロトタイプを中心に据える点で異なります。要件定義と実装を分離せず、相互に更新しながら具体化する方向性は共通しています。
要件定義は「固めてから作る」から「作りながら確かめる」へ
大規模な開発では、最初にデザインツールで大まかな画面を作ります。ただし、この段階で細かな仕様まで決めるわけではありません。
画面を通じて、本当に変えるべき業務は何か、解くべき課題は何かを見極めた上で、社内のAI開発基盤を使って実際に操作できるプロトタイプを作ります。
顧客、PM、プロダクトデザイナーがプロトタイプを操作し、ユーザー・顧客からのフィードバックを反映しながら修正を重ねます。要望がまだ十分に整理されていない場合には、AIに複数の解決策を提示させ、その中から課題に対して有効なものを選ぶこともあります。
規模が小さい開発では、画面を先に作らず、要望などのテキスト情報からAIに解決策とプロトタイプを提示させる進め方も可能です。開発規模に応じて入り口は変わりますが、文章だけで議論を終わらせず、動くものを使って仕様を具体化する点は変わりません。
2025年のDORAレポートも、AIを有効に活用する前提として、明確な課題へ向ける「ユーザー中心」の考え方を挙げています。さらに、高品質な社内開発基盤とAI活用の成果との関連も指摘しています［1］。重要なのは、AIツールの導入だけでなく、解くべき課題を明確にし、試行錯誤を支える開発環境を整えることです。
動かすことで、実務上の抜けが見えてくる
静止した画面を見ているだけでは問題がなさそうでも、実際に操作すると不都合が見つかることがあります。
業務の順序に合っていない、必要な情報を確認できない、例外的なケースを扱えない。こうした実務上の問題は、画面の遷移や操作の流れを確かめて初めて明らかになります。仕様として成立していても、現場で継続的に利用できるとは限りません。
動くプロトタイプがあれば、顧客は完成後の利用場面を想像するだけでなく、その場で体験できます。「この項目も必要です」という機能単位の要望に加えて、「そもそも、この業務の進め方を変えるべきではないか」という議論も早い段階で可能になります。
実装コストが下がったことで、プロトタイプは完成品を説明するための見本から、課題と要件を発見するための道具へと役割を変えました。
仕様のマスタが文書からソフトウェアへ移る
従来は、仕様書やデザインを正として、エンジニアがそれをソフトウェアへ変換していました。この方法では文書と実装の間に解釈の差が生まれ、開発中に仕様が変われば、両者が一致しなくなることもあります。
私たちの進め方では、検証したプロトタイプを仕様確認の基準にします。仕様書、項目定義書、テスト仕様書などは、プロトタイプで確かめた内容をもとに整備します。
さらに、プロトタイプのフロントエンドを捨てず、そのまま本番開発へ発展させます。そのため、要件定義が終わった後に同じ画面を一から作り直す必要がありません。
この方法により、従来は約4カ月かかっていた要件定義を、約2カ月で完了できた事例もあります。要件定義そのものが短くなるだけでなく、そこで作った成果物を本番でも利用するため、後続の開発期間も短縮できます。
実装とドキュメントを切り離さない考え方は、AIエージェントを前提とした開発でも重要になっています。OpenAIの社内開発事例では、プロダクト仕様、設計文書、生成されたスキーマ、実行計画などをリポジトリ内へ集約し、そこを知識の基準としています。さらに、文書が実際のコードから取り残されないよう、CIや専用のチェックによって整合性を検証しています［2］。
私たちの実践では、動くプロトタイプが中心です。一方、OpenAIの事例では、コードと同じ場所で管理された文書群が中心となります。方法は異なりますが、実装から離れた場所に静的な仕様書を置くのではなく、ソフトウェアと仕様を更新可能な形で結びつける点は共通しています。
チーム全体の解像度がそろう
要件定義の進め方を変えると、参加するメンバーも変わります。
従来の上流工程ではPMやデザイナーを中心に進められ、エンジニアは仕様が決まってから参加することも少なくありませんでした。プロトタイプを中心に進める場合は、エンジニアも早い段階から要件や設計の議論に関わります。
PM、プロダクトデザイナー、エンジニアが同じソフトウェアを見ながら話せば、抽象的な言葉だけで認識を合わせる必要はありません。実装上の制約も早期に共有され、チーム全体が高い解像度で課題と仕様を理解できるようになります。
会話の量と質が高まることで、少人数でもプロトタイプの開発と検証を進めやすくなります。AIは単に実装を代行するだけでなく、異なる役割を持つメンバーが同じ対象について話すための土台にもなるのです。
作る力から、選ぶ力へ
一方で、プロトタイプを速く作れるようになると、新しい課題も生まれます。
顧客からの要望や改善案をすぐに形にできるため、検討対象は急速に増えます。しかし、実装できることと、実装すべきことは同じではありません。
現在は、プロトタイプを通じて高めた解像度をもとに、PMが解くべき課題に対して有効な案を選んでいます。大きな要望を扱う場合は、単に機能を追加するのではなく、PMとプロダクトデザイナーがプロダクトのコンセプトや基本的な考え方まで立ち戻って検討します。
AIによって選択肢を作るコストが下がっても、それがそのまま価値や品質につながるわけではありません。人間に問われるのは、選択肢を増やす能力よりも、何を選び、何を作らないかを判断する能力です。
だからこそ、従来以上に重要になるのが、ユーザーや事業、業務にとって「解決すべき問い・課題」を見極めることです。作る速度が上がるほど、出発点となる問いを誤った場合、その誤りも速く具体化されます。AIを使って何を作るかを考える前に、誰のどのような課題を解くのかを問い続けなければなりません。
まとめ
AI駆動開発における要件定義は、ドキュメントを精緻に作ってから実装する工程から、動くプロトタイプを通じて要件を発見する工程へ変わり始めています。
デザインツールやドキュメントが不要になるわけではありません。その役割は、完成形を事前に定義することから、課題を見極め、プロトタイプから得た結果を記録することへ移ります。
ソフトウェアを仕様のマスタとして、顧客とチームが実際に動かしながら判断すれば、実務上の課題を早期に発見できます。その結果、要件定義だけでなく、後続の開発も短縮できます。
一方、作れるものが増えるほど、何を作るべきかという判断は難しくなります。AI駆動開発で人間に求められるのは、詳細な仕様を最初から書き切ることではありません。動くものから学び、課題に立ち戻り、必要なものを選び続ける役割へと重心が移っています。
AIによって実装の制約が小さくなるなか、あらゆるシステム開発が「何を作るか」だけでなく、「どの課題を解き、どのような価値を届けるか」に焦点を置いた開発プロセスへ転換する時代を迎えています。
参考文献
著者プロフィール：久保田 有紀
2014年にAGC株式会社に入社後、情報システム部門において基幹システムや社内クラウド環境の構築、エンジニアリングチームの組成に尽力。その後、2018年よりatama plus株式会社にてカスタマーサクセスを経験したのち、プロダクトマネージャー（PdM）としてパーソナライズされた学習レコメンド機能の開発を主導。2021年からはworksideに参画し、採用支援CRMの新規立ち上げから事業拡大まで、PdMおよび事業企画の両面を経験。2025年7月にAlgomaticへ加わり、現在はクライアント企業とともに生成AIを軸とした業務プロセスの刷新や新プロダクトの創出に従事している。
・株式会社Algomatic：https://algomatic.jp/
