AI駆動開発で要件定義はどう変わったか。
こんにちは。主にXにてAI駆動開発について発信している熊井悠です！
現在はAIスタートアップ企業のCEO兼CTOをしています！
僕は前職であるSIer、ITコンサルティング企業で上流工程に関わる機会が多くありました。
そのため、生成AIが登場したとき、真っ先に「これは要件定義・上流工程の領域を大きく変えるのではないか」と感じ、すぐに社内で検証を始めました。
この記事では、およそ3年間にわたる要件定義 × 生成AIの取り組みを、時系列で振り返ります。結論から言うと、3年かけてたどり着いた答えは、少し意外なものでした。
この記事について
- SIer / コンサル出身の僕が、2023年から取り組んできた「要件定義 × 生成AI」の変遷をまとめた記録です
- 各フェーズで「何を試し、何を学んだか」を時系列で追います
- これから AI要件定義に取り組む方のヒントになればうれしいです
3年間の歩み（全体像）
まず、この記事でたどる道のりのマッピングです。
後半に行くに従い、開発工程全体の話もやや出てきます。
| 時期 | 取り組み | 得られた学び |
|---|---|---|
| 2023.7 | テキストからフロー図を自動生成する実験 | 事前情報（用語集・前提）の整理が精度を決める |
| 2023.10 | Cursor × Markdown で要件定義 | コードベースこそ最良のコンテキスト |
| 2024.3 | Cursor・ChatGPT を社内一部導入 | ノウハウは「展開」より「蓄積」から |
| 2024.9 | 要件定義に AI をフル活用 | 単発プロンプトから「仕組み」へ |
| 2025.8 | 骨格はコード、要件はプロンプトに | 骨格をコードに、要件をプロンプトに分離 |
| 2025.11 | 「0日導入」を構築 | 要件定義は「文書作成」から「スコープ設計」へ |
| 2025.12 | 「GEAR.indigo」を事業譲受 → Biz 化 | 自社ノウハウ × 譲受プロダクトの掛け合わせ |
| 2026.5 | BYOK で無料配布（要件定義の民主化） | ツールのコストを「決断」の障壁にしない |
メール・Slack からフロー図自動生成を検証（2023.7）
最初に取り組んだのは、およそ3年前になります。メールやSlackなどのテキスト情報をもとに、OpenAI API（主に gpt-3.5）を利用して、業務要件定義における業務フローを生成するプログラムを、社内で実証実験として作っていました。
図：当時の構成イメージ（社内資料）
結果として、雑談や関係のない会話を含めて丁寧に判別することができず、事前に用語集・登場人物・ある程度の業務仮説を定義してから生成することで、何とかそれっぽいフロー図を作ることができました。
実は今でも事前情報の意義を重要視しているのは、この経験があるからです。定性的な情報であってもコンテキストに含めるようにするだけで、生成の精度は格段に変わります。
ここでの学び
用語集・前提事項の羅列が重要（後の Rule の概念につながる）
Cursor を利用した Markdown 形式での要件定義（2023.10）
2023年10月頃には Cursor が登場していたこともあり利用を開始しました。モデルはgpt-3.5が中心でしたが、参考となるコンテキスト（用語集・要件情報）をコードから取得することで、エンハンス時の要件ドキュメント生成は格段にやりやすくなりました。
図：当時の社内展開資料（一部社外公開）
また当時は Amazon Bedrock が登場したこともあり、業務利用を含めてかなり可能性が見え始めた時期でもありました。
図：当時の社内展開資料（一部社外公開）
この当時に意識していたのは、「コードベース」を適切に取得してMarkdownに必要な情報を羅列することです。これにより、追加要件が発生したときのドキュメント生成を非常にしやすい状態を作ることができました。
ここでの学び
コードベースを利用することが重要（後のコードインデックスにつながる）
Cursor・ChatGPT を社内一部導入（2024.3）
ここまでの取り組みで生成AIの可能性が感じられたので、2024年の春頃には一部チームで導入を開始しました。
一方で、「チャットベース型AI利用 ＋ コンテキストを正しく整理して渡す」という部分を組織化する試行錯誤の最中でもあったため、全社展開までは至らず、一部での利用という形を取りました。
やはり当時は AIに対して懐疑的な意見も多く、全社導入までは踏み切らずに慎重に進めていました。
図：当時の取り組みの振り返り資料
当時はその後になって造語するのですが、プロジェクトの情報を全てMarkdownかコードで表現しようと「Project as Code」と呼んでひたすら蓄積を進めました。このプロジェクト情報をコードで一元管理するという手法が後ほどご紹介する「コードベースからの逆引き生成」による要件定義の基盤となっています。
ここでの学び
- まずはエバンジェリスト役のメンバーを中心に活用ノウハウを貯める
- ノウハウを展開するより、貯める方向（コード化）を進めた
要件定義にて AI フル活用を開始する（2024.9）
2024年9月、これまで貯めてきたノウハウを土台に、要件定義の全工程でAIを本格活用するフェーズに入りました。主に3つのアプローチを並行して進めています。
1つ目は、コードベースからの逆引き生成によるドキュメント化です。既存のコードを起点に、仕様や業務フローのドキュメントを生成します。人手で書き起こすよりも速く、実装との乖離も起きにくくなります。
2つ目は、UI生成AIを活用したモック作成から要件定義ドキュメントへの展開です。v0などで先にモックを作って認識をすり合わせ、そこから要件を固めます。動くものを見せることで、顧客との認識ズレを早期に潰せます。
3つ目が、GEAR.indigoを活用したプリセールス段階での要件定義です。商談の段階から要件定義を回し始めることで、受注前に要件の解像度を一気に高められます。
ここでの学び
単発のプロンプトではなく、コンテキスト・コードベース・ノウハウを統合して「仕組み」として要件定義に組み込むことが生産性向上のポイント
コードを中心に考える。「骨格はコードコンテキスト、要件はプロンプト」（2025.8）
2024年からの実践を重ねる中で、次に向き合ったのは「開発そのものをどう進めるか」という型づくりでした。個々の工程で AIを使えるようになったその先で、要件定義から実装までをチーム全体で安定して回す方法論を固める段階に入ったのです。
特にAI要件定義を組織に根付かせるにあたり「誰でも同じアウトプットを得るには？」という問いに答える必要があったからです。
この過程で確立したのが、「骨格はコードコンテキスト、要件はプロンプト」 という考え方です。
何もない状態から自然言語の指示だけで開発する完全なVibe Codingよりも、スケルトンコード（基盤コード）を土台にした方が、生成されるコードの品質も、メンバーの学習効率も安定します。
骨格は既存のコードから読み取らせ、要件はプロンプトで渡す。ここまでの学びが、ひとつの形に結実しました。
図：AI駆動アジャイルの説明
開発プロセス自体も、僕が「AI駆動アジャイル」と呼ぶハイブリッド型に進化しました。段階的な進め方はアジャイル、個々の開発は設計偏重の高速ウォーターフォール。要件・仕様が曖昧なままコード生成をしてしまうことでの手戻りリスクを最小にするため、要件定義・設計フェーズを厚くするのが要点です。
ここでの学び
骨格をコードに持たせることで要件に集中できるフローを整える。
「0日導入」できあがったシステムから要件定義を始める（2025.11）
さらに踏み込んだのが 「0日導入」 という方法論です。プロジェクト開始時に基盤コードをテスト環境にデプロイし、「すでに動いているシステム」を前提に顧客と要件定義・設計を行うアプローチです。
ドキュメントは基盤コード前提の雛形を差分修正するだけ。
定例会では、できる限り実際に動くものを見せながら認識をすり合わせます。要件定義は「スコープ（Issue）を切る」作業として捉え直し、開発が1時間以内で完結する粒度まで分解します。この粒度のスコープ切りは、可能ならビジネス側の人間が担う方が望ましいと考えています。
図：0日導入の説明
重要なのは、要件定義の主役が「ドキュメントを書くこと」から「正しいスコープを切ること」へ移った点です。AIが開発を高速化すればするほど、上流の「何を、どの粒度で作るか」を定義する力がボトルネックになります。
ここでの学び
AI で開発が速くなるほど、ボトルネックは上流へ移る。要件定義は「文書作成」ではなく「スコープ設計」へと役割が変わる
「GEAR.indigo」との出会い（2025.12）
要件定義のノウハウを3年かけて磨く中で、私たちは一つのプロダクトに出会いました。上でも触れましたが、AI駆動の要件定義ツール 「GEAR.indigo」 です。当初はユーザーとして利用を始め、その効果を間近で体感していました。ここまで語った方法論がソリューションとして全て詰まっているプロダクトでした。
図：GEAR.indigoの画面（当時）
そして2025年12月、私たちはこのGEAR.indigo事業を、開発元であるStellaps社より譲り受けました。仕組みを強化したい、もっと多くの方にこの感動を届けたい。そういった意思決定でした。
さらに、自社が3年かけて磨いた要件定義のノウハウと、譲り受けたプロダクト。この2つを掛け合わせ、要件定義・設計フェーズを加速する 「GEAR.indigo Biz」 へと育てています。コンセプトはシンプルで、「会議メモを貼るだけ。要件と設計が、勝手に前に進む」。
図：GEAR.indigo Bizの画面
3年前、雑談混じりのテキストからフロー図を生成しようと手作業で苦戦したあの実験。そこで掴んだ「事前情報が要」「コードベースが要」という学びは、いまGEAR.indigo Bizを磨き込む土台として、地続きで生きています。
実は開発プロセスをClaude Codeを中心にするようになった今も、要件定義・基本設計における情報の整理および合意形成プロセスまでClaudeで実現するのはやや難しいです。
それはMarkdownの可視性や承認プロセス（指示履歴）の可視化など、従来型のウォーターフォールプロセスに合わない点もあるからです。そうした背景からGEAR.indigo Bizにその辺りのエッセンスを全て盛り込んでおります。
図：現在の開発フロー図
そして、要件定義 AI を「無料で配る」という決断（2026.5）
2026年、私たちはGEAR.indigo Bizを BYOK（Bring Your Own Key／利用者が自分の API キーを持ち込む方式）とすることで、利用料は無料という形で公開しました。社内には「せっかく作ったプロダクトを、なぜタダにするのか」という反対もありました。それでも、無料にしました。
理由は、要件定義という工程の意味そのものが変わったからです。AIが整理と文書化を高速にこなす今、人間に残るのは 「何を作るかを決めること」。要件定義は「整理する工程」から 「決断する工程」 へと変わりました。そしてこの決断は、もはや一部の専門家だけのものではありません。事業部門の担当者も、経営者も、社内SEも、全員が「何を作るか」を定義する場面に立たされています。
要件定義・設計は、民主化されなければならない工程になった。
ならば、その民主化を阻む障壁は、すべて取り除くべきだ。
月額課金という入口の障壁を残したまま「民主化」を語るのは、矛盾します。AIのAPI利用料はユーザー自身がコントロールできる。
ならば、その上に乗せるプラットフォーム利用料はゼロにする。言っていることと、やっていることを一致させる。 それが BYOK という選択でした。
ツールは、空気であるべきです。コストもロックインも意識させず、ユーザーが「何を作るか」の決断だけに没頭できる状態をつくる。3年かけてたどり着いた答えが、仕組みやノウハウを頑張って提供するのではなく、それらは過去の議論として、「本来の価値創造に向き合う土壌をつくる」ということでした。
ここでの学び（＝この記事の結論）
- 生成AIがやるべきは「ドキュメントを生成すること」ではなく、「正しいコンテキストを集め、正しいスコープを切る仕組みを作ること」だった。
- 要件定義は「整理する工程」から「決断する工程」へと変わった。
まとめ／3年間で見えてきたこと
振り返ると、各フェーズの学びは一本の線でつながっていました。
- 事前情報（コンテキスト）がすべての起点：雑談混じりのテキストから精度を出すには、用語集・前提・業務仮説の整理が不可欠だった（後の Rule の概念）
- コードベースこそ最良のコンテキスト：人手で情報を書き起こすより、既存のコードから逆引きする方が速く正確だった（後のコードインデックス、そして「骨格はコードコンテキスト」へ）
- ノウハウは展開より蓄積から：懐疑的な空気の中では、エバンジェリスト中心にプロンプト集として貯めることが効いた
- AIが速いほど、ボトルネックは上流へ：開発が高速化した結果、要件定義は「文書作成」から「スコープ設計」へと役割を変えた
生成AIを「魔法の箱」として期待するのではなく、いかに正しいコンテキストを渡し、正しいスコープを切る仕組みを作るか。
しかし、その仕組みを議論するフェーズはとうに終わりました。今は「何をつくるか」に没頭することが重要です。3年間の実証を通じて、ここに尽きると感じています。
以上となります。もっと詳細に語ろうと意気込んで書いたのですが思った以上に書くことが多くかなり端折ってしまいました。もし気になること、詳しく知りたいことがあればぜひ教えてください！
ここまで読んでいただき、ありがとうございました。少しでも参考になれば嬉しいです！
GEAR.indigo Biz は BYOK で無料で使えます
「会議メモを貼るだけ。要件と設計が、勝手に前に進む。」——本記事で書いた「ツールを忘れて、決断に集中する」状態を、ぜひ手元で体験してみてください。