この記事の要点
- 生成AIは開発プロセスそのものを置き換えるのではなく、実装・テストコード・ドキュメントなど「アウトプット量が多い工程」を圧縮します
- 要件定義と意思決定はほぼ変わらず、生成物のレビュー・検証・AI向けの指示書整備は工数がむしろ増えます
- 品質担保は「AIセルフレビュー → 開発者レビュー → 発注側の受け入れ基準」の3層で設計します
- 発注側が確認すべきは「どの工程にAIを使うか」「生成物のレビュー体制」「知財・セキュリティの扱い」の3点です
生成AIを使った開発プロセスは速くて安い、という話を聞く機会が増えました。ただ、発注する側から見ると分からないことばかりです。要件定義から運用までのどこにAIが入るのか、AIが書いたコードの品質は誰が保証するのか、見積は本当に下がるのか。ここが分からないままだと、ベンダーの提案が妥当かどうかを判断できません。
この記事では、生成AIによって変わる工程と変わらない工程を切り分け、要件定義から運用保守までの工程別マップとして整理します。あわせて、品質を担保する3層レビューの考え方、ローコード開発との組み合わせが向く案件、見積の読み方とベンダーへの質問リストまでを、発注側の判断材料としてまとめました。
目次
生成AIで開発プロセスは何が変わる？従来との差分を3分類で整理
生成AIによる変化は「短縮される工程」「ほぼ変わらない工程」「むしろ増える工程」の3つに分かれます。ウォーターフォールやアジャイルという開発モデル自体が変わるわけではありません。変わるのは各工程内の作業スピードと、成果物の作り方です。ここを分けて理解しておくと、過剰な期待も過小評価も避けられます。
| 工程 | 従来 | 生成AI活用後 | 変化の方向 |
|---|---|---|---|
| 要件定義 | ヒアリングと社内合意形成 | 議事録要約・抜け漏れチェックの補助 | ほぼ変わらない |
| 設計 | 人が設計書を作成 | ドラフト生成→人が修正 | やや短縮 |
| 実装 | 人がコーディング | AI生成＋人が調整 | 大きく短縮 |
| テスト | 人がケース設計・実装 | ケースとテストコードの自動生成 | 短縮（合否判断は人） |
| レビュー・検証 | 人が人の成果物を確認 | 確認対象の量が増える | 増える |
| AI向けルール整備 | コーディング規約のみ | 指示書・コンテキスト資料の整備 | 新たに発生 |
| 運用保守 | 人が調査・対応 | ログ解析・原因推定の補助 | やや短縮 |
短縮される工程：実装・テストコード・ドキュメント作成
効果が出やすいのは、分量が多く定型に近い作業です。コード生成、テストコード作成、設計書や仕様書のドラフト作成、既存コードの解読。この4つは生成AIとの相性がよく、作業時間を大きく圧縮できます。
具体的には、登録・参照・更新・削除だけの画面をまとめて実装する、テスト観点を洗い出す、API仕様書をドラフト化する、担当者が退職して読めなくなったレガシーコードから仕様書を復元する、といった作業です。
ただし削減率は案件によって大きく違います。効きやすいのは、仕様が明確で、技術スタックが一般的（世の中に情報が多い）で、既存コードが読める状態にある場合。逆に、仕様が固まっていない、独自フレームワークで動いている、ドキュメントが残っていない現場では、AIに渡す前提情報を作る手間が先に立ちます。IPA「ソフトウェア開発分析データ集」では工程別の工数比率が実績値として公開されていますが※1、実装工程はプロジェクト全体の一部です。実装が半分になっても全体が半分になるわけではない、という算数は押さえておきたいところ。
ほぼ変わらない工程：要件定義・業務設計・意思決定
何を作るかを決める工程は、生成AIでは代替できません。業務課題の特定、優先順位づけ、関係部署との合意形成。ここが遅いプロジェクトは、生成AIを入れても速くなりません。
これは発注側にとって重い意味を持ちます。開発の待ち時間が短くなると、ボトルネックは社内のヒアリング日程や決裁のスピードに移ります。「現場の要望が出そろわない」「部門間で優先順位が決まらない」という状態は、AIでは解決できません。
AIが助けてくれるのは、議事録の要約、要件の構造化、抜け漏れチェック、たたき台の作成まで。判断そのものは人が担います。IPA「DX白書」でも、DX推進上の課題として人材や体制の問題が挙げられています※2。ツールより体制が先、という順序は変わりません。
むしろ増える工程：生成物のレビュー・検証・プロンプト/コンテキスト管理
生成AIを使うと成果物の量が増えます。その結果、レビュー・動作検証・セキュリティチェックの工数は増えます。開発は速くなりますが、レビューは速くなりません。ここが見落とされやすいポイントです。
増える作業は次のようなものです。
- 生成されたコードが設計意図に合っているかの確認
- 実在しないライブラリやAPIを使った出力（ハルシネーション由来）の検出
- ライセンスや権利関係の確認
- 脆弱性の混入チェック
- AIに渡す指示書・コーディングルールの整備と更新
- 既存システムの情報（コンテキスト）をAIに渡せる形で維持する作業
経済産業省・総務省「AI事業者ガイドライン」でも、AIの出力をそのまま用いず人が確認する体制の重要性が示されています※3。つまり、レビュー体制を持たない相手にAI活用を任せると、速さの代わりに手戻りを買うことになります。発注側が最初に確認すべきは、スピードではなくレビューの仕組みです。
※1 IPA「ソフトウェア開発分析データ集」リンク
※2 IPA「DX白書」リンク
※3 経済産業省・総務省「AI事業者ガイドライン」リンク
工程別マップ：要件定義から運用まで、生成AIはどこに入るのか
生成AIが入る場所を工程順に並べると、濃淡がはっきりします。要件定義は補助、設計はたたき台生成、実装が主戦場、テストは自動生成＋人の判断、運用保守は調査と監視の補助。この地図を持っておくと、ベンダー提案のどこが本命なのかを読み分けられます。
| 工程 | 適用度 | AIに任せられること | 人が必ずやること | 発注側の関与ポイント |
|---|---|---|---|---|
| 要件定義・企画 | 中 | 議事録要約、要求の構造化、抜け漏れチェック | 優先順位づけ、部門間の合意 | 業務実態との突き合わせ |
| 設計 | 中〜高 | DB・API・画面設計のドラフト、命名統一 | アーキテクチャ選定、非機能要件 | 既存システムの制約を伝える |
| 実装 | 高 | コード生成、リファクタリング、既存コード解析 | 設計整合とセキュリティのレビュー | 進め方とレビュー基準の確認 |
| テスト | 中〜高 | テストケース・テストコード生成、観点の洗い出し | 合否判断、業務観点の検証 | 受け入れテストの主体を担う |
| 運用保守 | 中 | ログ解析、原因推定、問い合わせの一次回答案 | 影響範囲の判断、恒久対策の決定 | 改修体制と費用の取り決め |
要件定義・企画フェーズでの使いどころ（適用度：中）
この工程でのAIの役割は、ヒアリング内容の要約、要求の構造化、ユースケースや画面一覧のたたき台生成、抜け漏れチェックまでです。決めるのは人です。現行業務フローの整理、非機能要件のチェックリスト作成、検討すべき論点の洗い出しあたりが実用的な使い道になります。
注意したいのは、たたき台の完成度が高く見えることです。もっともらしい画面一覧が出てくると、そのまま要件として通ってしまいます。発注側の確認事項として、AIが作ったたたき台を現場担当者と突き合わせる場を必ず設けてください。この一手間を省くと、後の受け入れテストで「業務が回らない」と判明します。
設計フェーズでの使いどころ（適用度：中〜高）
設計では、ER図やAPI定義のドラフト生成、設計書のフォーマット統一、レビュー観点の洗い出しに効果があります。一方で、アーキテクチャ選定や非機能要件の落とし込みは人の判断が必要です。可用性やデータ量の見通しは、業務の事情を知らないと決められません。
もう一つ重要なのが、AIは自社の既存システムや社内ルールを知らないという前提です。連携先の仕様、命名の慣習、承認フローの実態などを情報として渡さないと、現実に合わない設計が出てきます。発注側の確認事項は、既存資産の資料（テーブル定義、連携仕様、運用ルール）をどこまで提供する必要があるかを早い段階で確定させることです。
実装フェーズでの使いどころ（適用度：高／ローコード・AIコーディング支援）
実装は生成AIの効果が最も大きい工程です。AIコーディング支援ツールによるコード生成、リファクタリング、既存コードの解析。さらにローコード開発基盤と組み合わせれば、画面や業務フローを短期間で形にできます。定型画面の一括生成、テストデータ作成、古い言語からの移行支援なども現実的な用途です。
ただし、生成コードの品質はプロンプトの質と既存コードの整備度に左右されます。AIが書けば誰がやっても同じ品質になる、ということはありません。設計の妥当性を判断できる人がレビューに入るかどうかで結果は変わります。ローコードとの組み合わせについては後段で詳しく整理します。
テスト・運用保守フェーズでの使いどころ（適用度：中〜高）
テストではテストケースとテストコードの生成、網羅性のチェックに使えます。正常系と異常系の観点洗い出し、E2Eテストのシナリオ生成あたりが代表例。運用保守では、ログ解析、エラーメッセージからの原因推定、問い合わせへの一次回答案、ドキュメント更新が該当します。
人が必ずやるのは受け入れテストです。仕様書どおりに動くかではなく、その業務が実際に回るかの判断は発注側にしかできません。発注側の確認事項は、受け入れテストのシナリオを誰が何本作るかを契約前に決めておくこと。ここを曖昧にしたまま進むと、検収の場で揉めます。
生成AIが作った成果物の品質はどう担保する？3層レビューと受け入れ基準
生成AIの成果物は「①AI自身によるセルフレビュー ②開発者による人力レビュー ③発注側の受け入れ基準」の3層で品質を担保します。従来の人から人へのレビューとの違いは、生成物の量が増えるため、レビューを仕組み化・自動化しないと破綻する点です。層ごとに検出できる欠陥の種類が違う、という理解が出発点になります。
3層レビューの役割分担（AIセルフレビュー／開発者／発注側）
第1層はAIに別プロンプトでレビューさせ、静的解析ツールと自動テストで機械的にチェックする層。第2層は開発者が設計意図・セキュリティ・保守性を見る人力レビュー。第3層は発注側が業務要件を満たすかを判断する受け入れ確認です。それぞれ拾える欠陥が異なります。
| 層 | 担い手 | 見るもの | 検出できる欠陥 |
|---|---|---|---|
| ①セルフレビュー | AI＋静的解析・自動テスト | 構文、規約、明らかな不整合 | 規約違反、単純バグ、未使用コード |
| ②開発者レビュー | 人（エンジニア） | 設計整合、脆弱性、保守性 | 設計不整合、権限漏れ、実在しないAPIの利用 |
| ③受け入れ確認 | 発注側（業務部門） | 業務要件との一致 | 業務が回らない仕様、運用の不備 |
ここで押さえたいのは、AIの出力をAIにレビューさせるだけでは足りないことです。同じモデルは同じ前提で誤りますし、業務要件を知らないという弱点は共通しています。第1層は量をさばくための足切り、判断は第2層と第3層で行う、という設計が現実的です。
発注側が決めておくべき受け入れ基準とテストの考え方
発注側は「どのテストがどこまで通れば検収とするか」を着手前に決めてください。生成AI活用案件では、テストの範囲・受け入れシナリオ・性能要件を数値で握っておくと、あとの解釈違いが減ります。
合意しておきたい項目は次のとおりです。
- 受け入れテストシナリオの本数と、作成する責任者（発注側か開発側か）
- 自動テストの対象範囲と、どこまで自動化するか
- 性能要件（同時利用者数、応答時間、処理件数）の数値
- 不具合の切り分け基準と、報告から修正までの目安期間
- 瑕疵対応の期間と範囲
- 納品物にドキュメントとテストコードを含めるか
ポイントは、AIが書いたかどうかを不具合の切り分け条件にしないことです。「AI生成部分だから対象外」といった線引きを許すと、責任の所在が曖昧になります。成果物基準で合意する、という原則を崩さないでください。
セキュリティ・著作権・情報漏えいで確認すべき3点
確認すべきは、自社データが学習に使われない設定・契約になっているか、生成コードの権利帰属が明記されているか、生成コード特有の脆弱性チェック体制があるか、の3点です。いずれも契約書とヒアリングで確認できます。
- 学習利用：「当社が提供する仕様書やソースコードは、利用するAIサービスの学習に使われない設定・契約になっていますか？」
- 権利帰属：「生成されたコードを含む成果物の著作権および利用権は、納品時に当社へ帰属しますか？」
- 脆弱性：「生成コードに対して、どのツールとどの基準でセキュリティチェックを行いますか？」
顧客情報や従業員情報を含むデータを扱う場合は、個人情報保護法上の取り扱いにも整合を取る必要があります※4。実データを外部サービスに入力せず、マスキングやダミーデータで開発する方針にできるかも、あわせて確認しておくと安全です。社内の情報取扱規程やNDAとぶつかっていないかも、発注前にチェックしておきたい点。
※4 個人情報保護委員会「個人情報保護法」リンク
生成AI×ローコード開発はどんな案件に向く？判断軸と落とし穴
生成AIとローコード開発の組み合わせが向くのは、業務がある程度標準的で、画面とワークフローが中心、短期間で形にして改善したい案件です。逆に、複雑な業務ロジック、大量データ処理、厳しい性能要件がある領域には向きません。スピードが出る手法だからこそ、適用範囲の線引きが効きます。
向いている案件・向いていない案件の見分け方
判断軸は5つです。業務の標準度、処理の複雑さ、利用ユーザー数と性能要件、既存システムとの連携数、作った後に誰が直すか。この5つを自社の案件に当ててみると、向き不向きはかなり見えてきます。
| 判断軸 | 向く（◯） | 向かない（✕） |
|---|---|---|
| 業務の標準度 | 申請・承認・進捗管理など汎用的 | 自社固有の複雑な計算・判定が中核 |
| 処理の複雑さ | 入力・一覧・通知が中心 | 大量データのバッチ処理、独自アルゴリズム |
| ユーザー数・性能 | 数十〜数百人、応答速度の要求が緩い | 不特定多数向け、ミリ秒単位の要件 |
| 連携数 | 連携なし〜1〜2システム | 基幹を含む複数システムと双方向連携 |
| 改修の担い手 | 社内に触れる人がいる | 誰も引き取れない |
向く例は、社内申請、進捗管理、簡易な顧客管理、問い合わせ対応の仕組みなど。向かない例は、基幹システムの中核処理、大量データの夜間バッチ、独自ロジックが競争力そのものになっている領域です。
内製・外注のすみ分けはどう決める？
生成AIとローコードで内製できるのは、業務部門が自分たちで使う小規模ツールまでが目安です。他システムとの連携、社外公開、個人情報の取り扱い、継続的な運用が必要な領域は外注か、外部の支援を入れた体制が現実的です。
判断は3つの問いで整理できます。社内に運用を引き取れる人がいるか。止まったら業務に致命傷か。要件が固まっているか。運用担当が不在、または止まると業務が止まる仕組みを、片手間の内製で持つのはリスクが大きすぎます。
現実的な選択肢として、土台は外注で作り、その後の改善を内製で回すハイブリッドもあります。この形を選ぶなら、発注時点で決めておくことが2つ。設計書と運用手順書を納品物に含めること、そして引き継ぎの範囲（誰がどこまで触れる状態にするか）を契約に書くことです。ここを曖昧にすると、結局改修のたびに発注が必要になります。
内製と外注の線引き、一緒に整理します。hikeに相談する
よくある落とし穴：野良アプリ化・ライセンス費・作り直しコスト
典型的な落とし穴は3つです。管理されないアプリの乱立、ユーザー数に比例して膨らむプラットフォーム利用料、プラットフォーム制約による作り直し。どれも「作るのが速い」ことの裏返しとして起きます。
回避策は先に決めておくことに尽きます。作る前に管理台帳と承認フローを定める。費用は初期費用ではなく3年分のライセンス費を含めた総額で比較する。将来別の基盤へ移す可能性を考え、データがどんな構造で保持され、エクスポートできるかを確認する。中小企業庁「中小企業白書」でも、デジタル化の取り組みでは投資後の活用と体制整備が課題として取り上げられています※5。作った後の運用まで含めて見積もる姿勢が、結果的に安く済みます。
※5 中小企業庁「中小企業白書」リンク
発注側の進め方と見積・契約の見方（ベンダーへの質問リスト付き）
進め方は「小さく試す → 効果を測る → 広げる」の3ステップが基本です。見積については、生成AI活用で下がるのは実装やテストコード作成など一部の工程に限られます。要件定義・設計・レビュー・受け入れテスト・運用保守の費用はほとんど下がりません。この前提を持って見積書を読むと、妥当性の判断がしやすくなります。
PoCから本番導入までの進め方（3ステップ）
最初に課題と評価指標を決めた小規模なPoC（数週間程度）、次に業務に載せる本番開発、その後に運用と改善。この順で進めます。肝は、PoCの開始時点で「何が達成できたら本番に進むか」を決めておくことです。
- PoC（目安1〜2か月）：対象業務を1つに絞り、評価指標（処理時間、精度の許容水準、対象件数）を先に決める
- 本番開発（目安3〜6か月／規模により変動）：既存システム連携、権限管理、運用手順の整備まで含める
- 運用・改善：利用状況を見て改修する体制と費用枠を確保する
PoCで止まる案件には共通点があります。評価指標が曖昧で成功か失敗かを誰も判定できない。現場が使わない前提で作ってしまった。運用の担当が決まっていない。この3つはいずれも発注前に決められることです。技術ではなく段取りの問題として捉えてください。
生成AIを使えば開発費は安くなる？見積で下がる部分・下がらない部分
圧縮できるのは実装、テストコード作成、ドキュメント作成の工数です。要件定義、アーキテクチャ設計、レビュー、受け入れテスト、運用保守はほとんど下がりません。むしろレビュー工数は増える方向に働きます。
| 費用項目 | 生成AI活用の影響 |
|---|---|
| 要件定義・業務設計 | ほぼ下がらない |
| アーキテクチャ設計 | ほぼ下がらない |
| 実装 | 下がる余地が大きい |
| テストコード作成 | 下がる余地がある |
| レビュー・検証 | 増える可能性がある |
| 受け入れテスト支援 | ほぼ下がらない |
| AIツール利用料・API従量課金 | 新たに発生する |
見積書は工程別の内訳で見てください。「AI活用により全体3割減」といった総額だけの説明は、根拠が確認できません。どの工程の工数が何割減っているのか、レビュー工数が計上されているのか。この2点を聞けば、実態のある活用かどうかは判断できます。工程別の工数感を持っておきたい場合は、IPA「ソフトウェア開発分析データ集」の実績値が比較の目安になります※1。
もう一つ。AIツールの利用料やクラウドの従量課金は、初期費用ではなくランニングとして継続します。初期費用だけで比較せず、3年総額で並べるのが安全です。なお2026年時点では、中小企業向けにIT導入補助金などの支援制度が用意されています※6。対象要件や補助率は年度ごとに変わるため、必ず最新の公募要領で確認してください。
ベンダーに聞くべき質問リスト（そのまま使える7問）
必ず聞くべきは、開発プロセスのどこに生成AIを使うか、生成物のレビュー体制、学習利用と権利帰属の3点です。以下はそのまま使える7問と、回答の見方です。
- ①どの工程で生成AIを使いますか？／望ましい：工程名と用途を具体的に答える。要注意：「全工程で活用」だけで中身が出てこない
- ②生成コードのレビューは誰がどの基準で行いますか？／望ましい：担当者の役割と静的解析・自動テストの併用を説明できる。要注意：「AIがチェックします」で終わる
- ③当社の資料やコードはAIの学習に使われませんか？／望ましい：利用サービス名と設定・契約条件を提示できる。要注意：「大丈夫です」だけで根拠が出ない
- ④生成コードの著作権と権利帰属はどうなりますか？／望ましい：契約書の該当条項を示せる。要注意：口頭で「問題ありません」
- ⑤検収の合格基準は何ですか？／望ましい：テスト範囲と判定条件を文書化して提示する。要注意：「動作確認後に検収」のみ
- ⑥納品物にドキュメントとテストは含まれますか？／望ましい：納品物一覧が見積に明記されている。要注意：一式表記で内訳がない
- ⑦運用フェーズで誰が改修しますか？／望ましい：保守契約の範囲と費用、内製移行の可否を説明できる。要注意：運用の話が未定のまま
7問すべてに具体的な回答が返ってくるベンダーは、生成AIを業務プロセスとして運用できている可能性が高いといえます。逆に、速さと安さの話に終始する場合は、レビュー工数がどこに計上されているかを重ねて確認してください。
※1 IPA「ソフトウェア開発分析データ集」リンク
※6 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク
まとめ：生成AI時代の開発プロセスで発注側が押さえる3点
生成AIは開発モデルを変えるものではなく、工程内の作業のやり方を変えるものです。発注側として押さえるべき点を整理します。
- 変化は3分類で理解する：実装・テスト・ドキュメントは短縮、要件定義と意思決定はほぼ不変、レビューとルール整備は増加
- 自社が関与する工程を自覚する：工程マップ上で発注側が主役になるのは要件定義と受け入れテスト。ここを外部に丸投げすると必ず詰まります
- 品質は事前合意で担保する：3層レビューの役割分担と受け入れ基準を、着手前に文書で握る
- 見積は工程別に読む：下がるのは実装中心。ランニング費用を含めた3年総額で比較する
次の一歩は、自社の課題を1つに絞り、小さく試せる範囲を洗い出すことです。対象業務、扱うデータ、関わる人数、既存システムとの接点。この4つを紙1枚に書き出すだけで、内製で足りるのか外注が必要なのかの見当がつきます。
よくある質問
生成AIを使うなら、ウォーターフォールとアジャイルのどちらが向きますか？
要件が固まりきらない領域では、短い周期で作って確認するアジャイル寄りの進め方と相性がよいといえます。試作の作成コストが下がるため、見せて直す回数を増やしやすいからです。一方、要件と検収条件を事前に固める必要がある案件では、従来型の進め方のままAIを各工程に組み込む形も成立します。
生成AIが書いたコードの著作権は誰のものになりますか？
実務上は、成果物の権利帰属を契約書で明記して合意します。AIが生成した部分の著作物性については法的な論点が残っており、一律の結論が出ているわけではありません。だからこそ、納品物の利用権と帰属、第三者の権利を侵害しないことの表明を契約に書いておくのが安全です。
社内にエンジニアがいなくても生成AIで開発できますか？
試作レベルまでは可能です。ただし、権限管理、個人情報の取り扱い、障害時の復旧、他システム連携といった運用面の責任は残ります。業務が止まると困る仕組みを、専任者なしで運用するのは避けたほうが無難です。まずは止まっても業務に致命傷にならない範囲から始めるのが現実的な選択になります。
開発期間はどのくらい短縮できますか？
案件によって差が大きく、一律の数字は出せません。効果が出るのは実装やテストコード作成が中心で、要件定義や合意形成、受け入れテストの期間はほとんど変わりません。全体工程のうち実装の比重が大きい案件ほど短縮幅は大きく、逆に調整事項が多い案件では体感の差が小さくなります。
生成AIを活用しているベンダーかどうか、どう見分けますか？
工程別の使い方とレビュー体制を具体的に説明できるかで判断できます。「どの工程で、どのように使い、生成物を誰がどの基準で確認するか」を淀みなく答えられれば、業務に組み込めている可能性が高いといえます。速さと安さだけを訴える提案では、増えるレビュー工数の扱いを確認しておきたいところ。
PoCの費用感はどのくらいですか？
対象業務の広さ、扱うデータの整備状況、既存システムとの連携有無で幅が出るため、単一の金額では示せません。費用を抑える鍵は範囲を絞ることです。業務を1つ、連携をなし、利用者を数名に限定した検証にすれば、必要な工数はかなり小さくなります。逆に対象を広げると、要件整理だけで工数が膨らみます。
セキュリティ上、社内データを使った開発は避けるべきでしょうか？
避けるかどうかではなく、条件を整えるかどうかの問題です。学習利用をオフにできる法人向けサービスの利用、閉域構成、実データを使わずマスキングやダミーデータで開発する方針といった選択肢があります。個人情報や機密情報を社外サービスへ入力する際は、社内規程と個人情報保護法上の取り扱いに照らして事前に確認してください。