# 生成AI×システム開発｜発注側が知るべき開発プロセスの変化と新しい選び方
生成AIでシステム開発は「作り方」が変わった
「生成AIを使ってシステムを作りたい」という相談が増えています。ただ、多くの発注担当者が見落としているのは、生成AIを組み込むとシステム開発の進め方そのものが変わるという点です。
従来のシステム開発は、要件を固めて設計し、プログラムを書いて納品する流れでした。完成品を検収して、動けばプロジェクト完了。この常識が、生成AI開発では通用しません。
なぜか。生成AIは「正解が事前に確定しない」性質を持つからです。同じ質問をしても回答が毎回変わる。精度は開発後のチューニングで大きく上下する。つまり、納品時点で完成品とは言い切れないのが生成AI開発の本質です。
本記事では、AI駆動開発の基本概念を踏まえたうえで、発注側が具体的に何を変えるべきかを整理します。概念の理解ではなく、発注の実務にフォーカスした内容です。
従来の開発プロセスとの比較
まず、開発プロセスの違いを表で押さえましょう。
比較項目 | ウォーターフォール型 | アジャイル型 | 生成AI駆動型 |
|---|---|---|---|
要件の決め方 | 最初に全量を確定 | 優先順位をつけて段階的に | 仮説ベースで小さく検証 |
開発の進め方 | 設計→実装→テスト→納品 | 2週間単位で反復 | 試作→評価→調整を高速反復 |
品質の判定基準 | 仕様通りに動くか | ユーザーが使えるか | 回答精度・業務適合率 |
納品物の位置づけ | 完成品 | 動くソフトウェア | 改善し続ける前提のシステム |
費用の構造 | 一括見積もり | 月額＋スプリント単位 | 段階発注＋従量の利用料 |
完了の定義 | 検収完了 | リリースごとに判断 | 精度目標の達成＋運用安定 |
大きな違いは3つあります。要件が仮説からスタートすること、品質が「精度」で測られること、そして納品後も改善が続くこと。この3点を理解していないと、発注の仕方を間違えます。
生成AI開発の費用感
生成AI開発の費用は、従来型と比べて「初期は安く、運用で継続的にかかる」構造になりやすいです。
MVP段階のコスト削減効果
生成AIを活用した開発では、コード生成やテスト自動化によって初期の試作コストが下がるケースが増えています。従来なら3か月かかった試作が、1〜2週間で動くプロトタイプとして出てくることも珍しくありません。
ただし「安くなる」の内訳には注意が必要です。
- 下がるもの：コーディング工数、定型的なUI構築、テストコード作成
- 変わらないもの：業務ヒアリング、要件整理、セキュリティ設計
- 新たに発生するもの：精度評価、チューニング、LLM利用料（月額従量課金）
費用の全体像は生成AI開発の費用ガイドで詳しく解説しています。見積書の読み方もカバーしているので、発注前に確認してください。
運用フェーズの注意点
見落とされがちなのが、本番運用後に毎月かかるLLMの利用料です。利用者数と質問回数に比例して増えるため、「開発費は安かったのに運用費が想定外に膨らむ」パターンが頻発しています。見積もり段階で月額の試算を出してもらうことが必須です。
発注者が変えるべき3つの思考
1. 一括見積もり → 段階発注
「全部でいくら？」と聞きたい気持ちは分かります。しかし、生成AI開発で最初から全体費用を確定させるのは、双方にとってリスクが高い。検証フェーズで「この方向性では業務に合わない」と分かることも普通にあるからです。
正しい進め方は、検証（50万〜200万円）→ 試作（200万〜500万円）→ 本番化（500万〜1,500万円）のように、フェーズごとに発注して、各段階の終了時に「次に進むか」を判断する形。AI時代の開発フローで、段階的な進め方の全体像を解説しています。
2. 完成品納品 → MVP反復
「完成品を納品してください」ではなく、「まず最小限の動くものを見せてください」と依頼する。触ってみて初めて「これは使える」「ここが足りない」が分かるのが生成AI開発の特徴です。
MVP（最小限の動くもの）を1〜2週間で作り、現場のフィードバックを反映して改善していく。この反復を前提にした契約形態を選ぶことが、失敗回避の鍵になります。
3. 人月見積もり → 成果物ベース
「エンジニア3人×3か月＝9人月」という見積もりは、生成AI開発には合いません。AIツールを使えば1人で3人月分のコードを書ける場面もあれば、精度チューニングに予想外の時間がかかる場面もある。
人月ではなく、「検証レポート一式」「精度80%以上の動くプロトタイプ」「本番運用可能なシステム」のように、成果物と達成基準で定義する方が合理的です。
生成AI開発で失敗する発注パターン
実際に起きている失敗パターンを整理します。
パターン1：要件を全部固めてから発注する
200ページのRFPを書いて一括発注するやり方。生成AIの精度は触ってみないと分からないため、紙の上の要件が実装段階で半分以上ひっくり返る。結果、追加費用と納期遅延が発生します。
パターン2：検証で満足して本番化しない
「すごい、ChatGPTっぽいものが動いた！」で予算を使い切り、本番化の費用が残っていないケース。検証と本番は別プロジェクトと考え、最初から段階予算を確保しておく必要があります。
パターン3：精度の基準を決めずにスタートする
「使ってみて良さそうなら採用」という曖昧な基準で走り出すと、終了判定ができません。「回答の正解率80%以上」「不適切な回答がゼロ」のように、数値で測れる基準を検証前に合意しておくことが不可欠です。
パターン4：開発会社にすべて丸投げする
生成AIが業務で使えるかどうかを判断できるのは、業務を知っている発注者側だけ。「お任せで」と丸投げすると、技術的には動くけれど業務では使えないシステムが出来上がります。要件定義の進め方を参考に、発注者側も積極的にプロセスに関与してください。
開発企業の選び方
生成AIの開発企業を選ぶとき、ホームページの「AI実績あり」だけで判断するのは危険です。以下の観点で比較してください。
確認すべき5つの観点
- 検証で終わった案件と本番化した案件の比率：本番運用まで進めた実績があるかどうかが最大の分岐点
- 精度の測り方を最初に提案してくるか：「プロンプトを工夫すれば精度は上がります」だけの会社は避ける
- 段階発注に対応できるか：一括契約しか提示しない会社は、生成AI開発の進め方を理解していない可能性が高い
- 運用フェーズの費用を具体的に説明できるか：LLM利用料の試算、月次の改善作業の範囲と費用が明確かどうか
- 複数のLLMを比較検討した経験があるか：「ChatGPTしか使ったことがない」では、御社に最適な選択ができない
見積もり比較チェックリストと合わせて使うと、提案書の評価がしやすくなります。
Beekleのゼロスタート（MVP開発・PoC開発・プロトタイプ開発）なら、1〜2週間で動くプロトタイプを作り、「本当に業務で使えるか」を実際に触って確認してから本格開発に進めます。AI導入の第一歩として、まずはお気軽にご相談ください。
よくある質問（FAQ）
Q. 生成AIを使ったシステム開発の期間はどれくらいですか？
A. 検証フェーズは1〜2週間、試作は1〜2か月、本番化まで含めると3〜6か月が目安です。従来型より試作段階は短縮されますが、精度のチューニングや業務適合の確認に時間がかかるため、全体の期間が劇的に短くなるわけではありません。段階的な進め方の詳細はAI時代の開発フローで解説しています。
Q. 生成AI開発の費用は従来のシステム開発より安くなりますか？
A. MVP（試作品）の段階では、コード生成の効率化によって従来の3分の1〜半額程度に抑えられるケースがあります。一方で、LLMの月額利用料やチューニング費用が新たに発生するため、3年間のトータルコストで比べると大きな差が出ないことも。フェーズ別の費用目安は生成AI開発の費用ガイドにまとめています。
Q. 社内に技術者がいなくても生成AI開発は発注できますか？
A. 技術者がいなくても発注は可能です。ただし、発注者側には「業務のどこに課題があるか」「どうなれば成功か」を整理する役割が求められます。技術の判断は開発会社に任せ、業務要件と評価基準の策定に注力するのが効果的な分担。要件定義の進め方を参考に、発注者の関わり方を事前に決めておくと進行がスムーズです。
Q. 開発途中で生成AIのモデルが変わったらどうなりますか？
A. 生成AIの世界ではモデルの更新や廃止が頻繁に起こります。良い開発会社は、特定モデルに依存しない設計（モデルの差し替えが容易な構造）を最初から組み込んでいます。見積もり段階で「使用モデルが廃止された場合の移行費用」について確認しておくと安心です。見積もり比較チェックリストにも関連項目があります。
Q. 生成AI開発の発注で最低限準備すべきものは何ですか？
A. 最低限必要なのは3つ。(1) 解決したい業務課題の具体的な説明、(2) 現在の業務フローの概要、(3) 成功と判断する基準（定量的なもの）。200ページのRFPは不要で、むしろ検証フェーズを通じて要件を固めていく進め方が適しています。発注書類の書き方はRFPの書き方ガイドを参照してください。
Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。