この記事の要点
- 生成AIはソフトウェア開発の全工程に入りますが、効果が大きいのは実装・テスト・ドキュメント・調査など「正解を機械的に検証できる工程」です
- 要件定義とアーキテクチャ判断は今も人の仕事。ここを外注先に丸投げすると、動くけれど使えないシステムになります
- 品質はAIの賢さではなく「検証の仕組み」で決まります。レビュー体制・自動テスト・CI・静的解析・ライセンス確認・受け入れ基準の6点を確認してください
- 費用削減は工程に偏ります。全体では数割程度に収まることが多く、削減分が要件定義やレビューに移るケースもあります
- 発注側がやるべきは、工程ごとの切り分けと、ベンダーへの確認事項の整理。この2つで提案の良し悪しを判断できます
生成AIによるソフトウェア開発の話題は増えましたが、発注する側から見ると「結局どこまで任せられるのか」がいちばん分かりません。コードが書けることは知っている。でも、そのコードを誰が保証するのか。安くなると言われても、何割減るのか。この記事では、工程ごとのAIと人の切り分け、品質担保の具体策、見積書の見方までを、発注判断に使える形で整理します。読み終えたときに、自社案件のどこにAIを使えるか、ベンダー提案をどの軸で評価するかが手元に残るはずです。
目次
生成AIはソフトウェア開発のどの工程に入るのか？
生成AIは企画から運用保守まで全工程に入りますが、効果の大きさは工程で大きく異なります。もっとも効くのは実装・テスト・ドキュメント・調査といった、出力が正しいかを機械的に確認できる工程。要件定義や設計判断では、人の意思決定を補助する使い方にとどまります。
| 工程 | 生成AIの効果 | 主な使いどころ |
|---|---|---|
| 企画・要件定義 | 中 | 要件案の洗い出し、資料要約、業務フローの叩き台 |
| 設計 | 中 | 設計書の下書き、選択肢の比較整理 |
| 実装（コード生成） | 大 | 定型実装、API連携、リファクタリング |
| テスト | 大 | テストコード生成、異常系ケースの洗い出し |
| ドキュメント | 大 | 仕様書・運用手順書の生成、既存コードからの逆生成 |
| 運用・保守 | 大〜中 | ログ解析、影響調査、既存コードの読解支援 |
| プロジェクト管理・調整 | 小 | 議事録整理程度。意思決定は代替されない |
工程ごとに何割の工数がかかるかは、規模別・業種別の実績値としてIPAが公開しています※1。自社案件の工数配分をこうした公開データと突き合わせると、AIで削れる部分が全体のどれくらいを占めるのかが見えてきます。
企画・要件定義で生成AIができること／できないこと
できるのは、要件の洗い出し案づくり、既存資料の要約、業務フローの叩き台作成、類似機能の調査です。できないのは、自社にとって何が正解かの意思決定と、業務固有の例外ルールの発見。この線引きが、発注前の準備品質を決めます。
たとえば業務ヒアリングのメモを渡して機能一覧のドラフトを作らせる、要件漏れのチェックリストを出させる。この使い方は現場でも効きます。抜けがちな「権限管理」「締め処理」「例外時の差し戻し」といった観点を、素早く洗い出せるからです。
一方で、月末だけ手作業で調整している運用、特定の取引先にだけ適用している例外価格、前任者が残した既存システムの非公開仕様。こうした情報は学習データのどこにもありません。AIに聞いても出てこない領域が、要件定義でもっとも危ない部分です。ここを埋めるのは、発注側の担当者の記憶と、現場へのヒアリングだけ。
設計・実装（コード生成）はどこまで任せられるか
仕様が明確で影響範囲が局所的なコードは、実用レベルで任せられます。データの登録・参照・更新・削除といった定型処理、画面の定型実装、API連携、既存コードの整理、データ移行の下書きなど。逆にアーキテクチャ選定や性能・可用性のトレードオフ判断は人が担います。
コーディング支援ツールには大きく2つの型があります。エディタ上で次の数行を提案する補完型と、指示を与えると複数ファイルをまたいで自律的に書き換えるエージェント型。後者は生成量が一気に増えますが、その分レビュー対象も増えます。生成量とレビュー工数はトレードオフの関係にあり、「AIが8割書いたので8割安くなる」とはなりません。
もう一つ見落とされがちなのが、設計の一貫性です。AIは目の前の指示に忠実なので、同じような処理を別々の書き方で作ってしまうことがあります。数か月後に保守しづらいコードが積み上がる原因になるため、命名規則や共通部品の方針は人が先に決めておく必要があります。
テスト・コードレビュー・ドキュメント作成での活用
テストコードの自動生成、境界値や異常系ケースの洗い出し、コードレビューの一次チェック、仕様書や運用手順書の作成。この領域は費用対効果がもっとも高い部類です。理由は単純で、正解を機械的に検証できる、あるいは既存の成果物という正解データが手元にあるためです。
実務でよくあるのは、テストケースの網羅率の底上げ。人が書くと正常系に偏りがちですが、「この関数の異常系を列挙して」と指示すれば、想定外の入力パターンが並びます。もう一つは、レガシーコードから仕様書を逆生成する使い方。ドキュメントが残っていないシステムの改修前調査で効きます。
ただし、テストの合否基準そのものを決めるのは人の仕事です。何をもって受け入れとするか、どのケースは落ちても許容するか。この基準がないままテストだけ増やしても、品質は上がりません。
運用・保守フェーズでの生成AI活用
障害ログの一次解析、問い合わせ対応の下書き、改修時の影響範囲調査、既存コードの読解支援。運用フェーズは効果が見えやすい領域です。とくに、作った担当者がすでにいないシステムの読解では、調査時間の短縮につながります。
中小企業でよくあるのが、10年以上前に外注して作ったシステムを、仕様書もないまま使い続けているケース。改修を頼もうにも、ベンダー側の調査工数が読めないため見積が高くなります。ここに生成AIによるコード読解と仕様書の逆生成を挟むと、調査部分の工数を圧縮できる余地があります。保守費の見直しを検討しているなら、まず調査工程から相談してみる価値はあるでしょう。
※1 IPA「ソフトウェア開発分析データ集」リンク
人がやる工程と生成AIに任せる工程はどう切り分ける？
切り分けの基準は工程名ではありません。①出力の正しさを機械的に検証できるか ②定型・反復の作業か ③間違えたときの影響範囲が局所的か。この3条件が揃うほどAIに任せてよく、1つでも欠けるなら人の判断が必須になります。
AIに任せてよい作業を見分ける3つの条件
3条件はそれぞれ判定質問に置き換えられます。検証可能性は「出力が正しいかテストや実行で自動確認できるか」。定型性は「同じ形の作業が繰り返し発生するか」。影響範囲は「間違っても他機能や本番データを壊さないか」。3つすべてYESなら、任せて問題ありません。
3条件を満たす例が、テストコードの生成、定型画面の実装、ログ集計スクリプト、コード整形。実行すれば正しさが分かり、何度も発生し、壊れても局所で止まります。
満たさない例が、本番データベースの移行スクリプト、決済・請求ロジック、権限制御まわり。移行スクリプトは一度実行すると戻せず、検証も本番相当のデータがないとできません。決済ロジックは仕様の解釈が業務ごとに違い、間違えると金銭事故に直結。この3条件は、ベンダーの提案書を読むときの物差しにもなります。影響範囲の広い部分まで「AIで効率化」と書かれていたら、そこはレビュー体制を掘り下げて聞く箇所です。
生成AI時代でも人が担う4つの領域
生成AIに移譲できないのは、何を作るかの意思決定、業務ドメイン知識と例外ルールの反映、アーキテクチャと非機能要件のトレードオフ判断、成果物に対する最終責任とリスク判断の4つです。AIは目的を与えられなければ最適化できず、責任の主体にもなれません。
何を作るかの意思決定とは、機能の優先順位づけと投資判断のこと。「この機能は初期リリースに入れる／入れない」を決めるのは、業務と予算を知っている発注側です。業務ドメイン知識も同様で、例外ルールを言語化できるのは現場の人だけ。
アーキテクチャと非機能要件は、正解が一つに定まらない領域です。同時利用者数、応答速度、障害時にどこまで止まってよいか。これらは業務要件とコストの綱引きで決まります。そして最終責任。AI事業者ガイドラインでも、AIの出力を人が確認し、リスクを管理する体制の重要性が示されています※2。発注側が自社で持つべき役割は、要件の合意と受け入れ判断。この2つだけは外部に預けられません。
工程別 AI／人 切り分け早見表
各工程で、AIに任せる範囲と人が担う範囲、そして任せる際に前提となる条件を整理しました。自社案件を当てはめて、どこが空欄のまま進もうとしているかを確認してください。
| 工程 | AIの担当範囲 | 人の担当範囲 | 任せる際の前提条件 |
|---|---|---|---|
| 要件定義 | 要件案の列挙、抜け漏れチェック、資料要約 | 優先順位の決定、例外ルールの提示、合意形成 | 現場ヒアリングの内容が言語化されていること |
| 基本設計 | 設計書の下書き、選択肢の比較整理 | アーキテクチャ選定、非機能要件の決定 | 制約条件（予算・既存環境）が明示されていること |
| 詳細設計 | 画面・項目定義の展開、命名の統一案 | 業務ロジックの妥当性確認 | 共通部品と命名規則が先に決まっていること |
| 実装 | 定型処理、API連携、リファクタリング | 設計意図との整合確認、複雑ロジックの実装 | 仕様が文書化され、影響範囲が局所的なこと |
| 単体テスト | テストコード生成、異常系の洗い出し | 合否基準の設定、テスト観点の承認 | 自動テストが実行できる環境があること |
| 結合テスト | テストデータ生成、手順書作成 | 連携先との調整、障害切り分け | 連携先の仕様が確定していること |
| 受入テスト | チェックリスト案の作成 | 業務観点での合否判断（発注側の役割） | 受け入れ基準が発注時に合意済みであること |
| ドキュメント | 仕様書・手順書の生成、既存コードからの逆生成 | 内容の正誤確認、公開範囲の判断 | 最終確認者が決まっていること |
| 運用・保守 | ログ解析、影響調査、問い合わせ回答の下書き | 障害対応の判断、顧客への回答責任 | 本番データを外部サービスに入れない運用 |
この表の使い方はシンプルです。ベンダー提案を横に置き、AI担当の列に寄りすぎていないか、人の担当列に置くべき項目が誰の作業になっているかを照らし合わせます。とくに受入テストの行。ここが「ベンダー側で実施」となっている提案は、発注側の判断が抜け落ちる危険があります。
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
生成AIが書いたコードの品質はどう担保するのか？
品質はAIの性能ではなく、生成物を検証する仕組みで決まります。人によるコードレビュー、自動テストの整備、CIでの継続検証、静的解析・脆弱性スキャン、ライセンスと権利の確認、受け入れ基準の事前合意。この6点が揃っているかを確認すれば、発注側でも品質リスクを判断できます。
生成コードで起こりやすい品質リスク（ハルシネーション・脆弱性・ライセンス）
主なリスクは4つ。存在しないライブラリや関数を使うハルシネーション、入力検証漏れや権限チェック漏れといったセキュリティ脆弱性、学習データ由来のライセンス・著作権リスク、そして一見動くのに保守しにくい冗長コードです。
なぜ起きるのか。生成AIは「正しい答え」ではなく「もっともらしい続き」を出力する仕組みだからです。存在しそうな関数名を自信を持って書きますし、セキュリティ対策のコードは書かなくても動くため省略されがち。ライセンスについても、生成物がどの学習データに由来するかを利用者側から追跡することはできません。
発注側にどう跳ね返るか。脆弱性は情報漏えいのリスクとして、冗長コードは数年後の改修費として返ってきます。ライセンス問題は法務対応のコスト。初期費用が安くても、保守フェーズで回収されるなら意味がありません。
品質を担保する6つの仕組み（レビュー・自動テスト・CI・受入基準）
仕組みは6つあり、それぞれ発注側から見た「証拠」が存在します。証拠を出せるかどうかが、ベンダー選定の実質的な判定材料です。
- 人による最終レビュー：生成量に比例してレビュー体制を厚くする。証拠はレビュー記録（プルリクエストの承認履歴）
- 自動テストの整備：カバレッジの目標値を事前に決める。証拠はテスト結果レポート
- CI/CDでの継続検証：コード変更のたびに自動でテストが走る。証拠はビルド履歴
- 静的解析・脆弱性スキャン：コードの品質と既知の脆弱性を機械的に検出。証拠はスキャン結果
- 依存関係の管理（SBOM）：使用ライブラリとそのライセンスを一覧化。証拠は部品表
- 受け入れ基準の文書化：何をもって完成とするかを発注時点で合意。証拠は要件定義書・検収条件
原則は一つ。AI生成分も人が書いたコードと同じ品質基準に揃えることです。「AIが書いた部分だから」という理由で基準を下げるベンダーは避けてください。逆に、AI活用を掲げながらこの仕組みを整えている会社は、生成量が増えても品質が落ちにくい構造になっています。
発注側が契約・成果物で確認すべきチェックリスト
契約段階で確認すべきは、生成AIの利用範囲の明示、自社データが学習に使われない構成か、成果物の権利帰属、契約不適合責任の範囲、レビューとテストの実施体制の5点です。どれも提案書・見積書・契約書のいずれかに書かれているべき項目。
- 生成AIをどの工程で使うか（提案書の体制・進め方の欄）
- 使用するツールと、入力データが学習に使われない設定か（提案書またはセキュリティ確認書）
- 成果物の著作権と利用許諾の帰属（契約書の知的財産条項）
- 第三者の権利を侵害した場合の対応（契約書の保証・責任条項）
- 契約不適合責任の期間と範囲（契約書）
- レビュー担当者と自動テストの方針（見積書の工数内訳）
- ソースコードと設計書の納品範囲（契約書の成果物一覧）
- 秘密保持の対象に、プロンプト入力内容が含まれるか（NDA）
自社側の運用も決めておく必要があります。社内資料や個人情報をそのままプロンプトに入れないルール、入れる場合の匿名化。個人データを外部サービスに渡す場面では、個人情報保護法上の取り扱い（委託先の監督や第三者提供の整理）を確認しておくと安全です※3。
※3 個人情報保護委員会「個人情報保護法」リンク
生成AI活用で開発費用と期間はどれだけ変わる？
削減できるのは主に実装・テスト・ドキュメントの工数です。ただしプロジェクト全体で見ると、削減幅は数割程度に収まるケースが多くなります。要件定義や仕様調整、レビューの工数は減らず、生成量が増えれば逆に増えることもあるためです。全体が半額になる前提で予算を組むと、後半で破綻します。
コスト削減が効く工程・効かない工程
効くのは定型実装、テストコード、ドキュメント、既存コードの調査。効かないのは要件定義・業務ヒアリング、外部システム連携の調整、非機能要件の設計、プロジェクト管理です。
| 工程 | 削減余地 | 理由 |
|---|---|---|
| 要件定義・ヒアリング | 小 | 人と人の合意形成が中心。時間は圧縮できない |
| 設計 | 小〜中 | 下書きは作れるが判断は人が行う |
| 定型実装 | 大 | 仕様が明確で検証しやすい |
| テストコード作成 | 大 | 正解を機械的に確認できる |
| 外部連携の調整 | 小 | 相手方の都合と仕様確認に依存する |
| ドキュメント | 大 | 既存成果物という正解データがある |
| レビュー・品質保証 | 増える場合あり | 生成量に比例して確認対象が増える |
| プロジェクト管理 | 小 | 調整と意思決定は代替されない |
因果はシンプルです。削減余地は「仕様がどれだけ固まっているか」に比例します。仕様が曖昧なまま生成させると、作り直しが発生し、かえって工数が膨らみます。逆に言えば、発注側が仕様を説明できる案件ほど、AI活用の恩恵を受けやすいということです。工程ごとの工数比率は公開データで確認できますので※1、削減対象の工程が全体の何割を占めるかを事前に把握しておくと、期待値のズレを防げます。
AI活用前提の見積書で見るべき3つのポイント
見るべきは、AI活用でどの工程を何割削減した見積なのか内訳が示されているか、削減した工数がレビュー・テストに再配分されているか、生成AIのAPI利用料やツール利用料が誰の負担かの3点です。
内訳のない一式見積は比較できません。「AI活用により従来比◯％減」とだけ書かれていたら、どの工程で減ったのかを聞いてください。次に、レビュー工数。ここが薄い、あるいは項目ごと消えている見積は要注意です。安いのではなく、品質確認の工程を抜いている可能性があります。
ベンダーに投げる質問文としては、次の3つが使えます。「AI活用で削減した工数は、どの工程からどの工程へ移していますか」「レビューは誰が、どの粒度で行いますか」「生成AIの利用料は御社負担ですか、当方の実費精算ですか」。回答が曖昧なら、そこが後で追加費用になる箇所です。
自社でやるか外注するかの判断基準
分水嶺は、社内にコードをレビューできる人材がいるかどうかです。いなければ生成AIツールを導入しても品質の良し悪しを判断できず、手戻りコストのほうが大きくなります。IPAのDX白書でも、デジタル人材の不足は継続的な課題として挙げられています※4。
判断軸は4つ。レビューできる人材の有無、扱うデータの機密度、一度作って終わりか継続改善したいか、失敗しても業務が止まらない案件か。人材がいて機密度が低く、継続改善したい小規模ツールなら内製が向きます。逆に、基幹業務や個人情報を扱う部分は外注のほうが安全です。
現実的なのはハイブリッドでしょう。社内向けの小さなツールは生成AIを使って内製で試し、基幹に関わる部分と品質保証の設計は外部に任せる。内製の経験があると、外注時の要件説明も具体的になります。
どこまで内製できるか、工程単位で整理します。hikeに相談する
※1 IPA「ソフトウェア開発分析データ集」リンク
※4 IPA「DX白書」リンク
生成AIを使ったソフトウェア開発は何から始めればいい？
最初の案件は、業務が止まっても致命的でない、仕様を自社で説明できる、成果を数値で測れる、の3条件で選びます。進め方は、小さく作って評価する→社内ルールを整える→対象を広げる、の順。いきなり基幹システムから入ると、失敗の原因が特定できません。
最初に着手すべき案件の選び方
向いているのは、社内向けの小規模な業務ツール、Excelで回している集計業務の置き換え、社内問い合わせ対応の効率化、既存システムの周辺機能です。共通するのは、失敗しても業務が止まらず、仕様を自社の言葉で説明できること。
1件目に選ばないほうがよいのは、基幹システムの刷新と、決済や個人情報を扱う機能です。理由は失敗コストの大きさとレビュー負荷の高さ。検証と承認に時間がかかり、AI活用の効果測定どころではなくなります。
効果測定の指標は、着手前に3つだけ決めておけば十分です。作業にかかっていた工数（時間）、依頼から完了までのリードタイム、手作業に起因するエラーや差し戻しの件数。この3つを着手前後で比べれば、次の投資判断の材料になります。
開発ベンダーに必ず聞くべき5つの質問
比較検討の場では、生成AIをどの工程にどのツールで使うか、生成コードのレビュー体制とテスト方針、入力データが学習に使われない構成か、成果物の権利と瑕疵対応の範囲、引き継ぎと内製化支援の可否。この5つを揃って聞くと、提案の厚みの差がはっきり出ます。
| 質問 | 望ましい回答 | 警戒すべき回答 |
|---|---|---|
| どの工程にどのツールを使うか | 工程ごとに用途と範囲を具体的に説明できる | 「最新のAIを活用しています」だけで内訳がない |
| レビュー体制とテスト方針 | 担当者・粒度・自動テストの基準を提示できる | 「経験者が確認します」で仕組みの説明がない |
| 入力データの学習利用 | 法人向け設定や閉域構成など具体的に回答 | 「大丈夫です」のみで根拠を示さない |
| 権利と瑕疵対応 | 契約書の条項を示して説明できる | AI生成分は責任範囲外だと後出しする |
| 引き継ぎ・内製化支援 | ソースと設計書の納品範囲を明示できる | ソースコードの開示に消極的 |
社内で先に決めておく利用ルールと体制
着手前に決めるのは4点。使用を許可するツール、プロンプトに入れてよい情報の範囲、生成物の最終確認者、問題が起きたときの報告先です。分厚い規程は要りません。A4一枚で十分機能します。
情報システム部門がない会社では、経営者・業務担当・外部ベンダーの3者で最小ルールを作るのが現実的でしょう。とくに「顧客名や個人情報を含む資料はそのまま入力しない」の一行は、最初に入れておいてください。AI事業者ガイドラインでも、利用にあたってのリスク管理と体制整備の考え方が整理されています※2。
費用面では、業務システムの導入に使える公的支援制度もあります。2026年時点ではIT導入補助金などの枠組みが運用されていますが※5、対象要件や補助率は年度ごとに変わるため、最新の公募要領で必ず確認してください。
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
※5 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク
まとめ：生成AI時代の発注側に必要な判断軸
生成AIによるソフトウェア開発を発注する側として、押さえておくべき点を整理します。
- 効果は工程で偏る。実装・テスト・ドキュメント・調査で大きく、要件定義と設計判断では補助にとどまる
- 切り分けの基準は3条件。検証可能性・定型性・影響範囲の局所性が揃うほど任せてよい
- 品質はAIの賢さではなく仕組みで担保する。レビュー・自動テスト・CI・スキャン・ライセンス確認・受け入れ基準の有無を見る
- 費用削減は全体で数割程度に収まることが多く、削減分がレビューや要件定義に移る場合もある
- 小さな案件で基準を作ってから広げる。1件目に基幹システムを選ばない
次の一手は2つ。手元の案件を切り分け早見表に当てはめて、人が担うべき部分が誰の作業になっているかを確認する。あるいは、検討中のベンダーに5つの質問を投げて回答を並べる。この2つだけでも、判断の解像度は大きく変わります。工程の切り分けと品質担保の設計は、案件の性質によって最適解が変わる部分です。自社だけで線を引きにくいときは、外部の視点を挟んで整理する方法もあります。
よくある質問
生成AIだけでシステムは完成しますか？
動くものは作れます。ただし本番運用に必要な非機能要件（性能・可用性・セキュリティ）、例外処理、長期の保守性は人の設計が前提です。試作段階まではAI中心で進められても、業務で使い続ける段階では設計とレビューの人手が必要になります。
生成AIが書いたコードの著作権は誰のものになりますか？
実務では、契約書で成果物の権利帰属を明記して対応します。あわせて、第三者の権利を侵害した場合の責任分担と、ベンダー側のライセンス確認フローを確認してください。「AI生成分は責任範囲外」とする契約になっていないかが要点です。
社内にエンジニアがいなくても発注できますか？
発注は可能です。ただし業務要件を説明できる担当者と、成果物を受け入れ判断する責任者は社内に必要です。この2つの役割が空いていると、仕様の解釈違いが後半で表面化し、追加費用の原因になります。
ノーコード・ローコードと生成AI開発はどう違いますか？
ノーコードはツールの機能範囲内で作る方式で、範囲外のカスタマイズが難しい代わりに保守は軽くなります。生成AI開発はコードを持つため自由度が高い一方、保守の主体を自社かベンダーかで決める必要があります。カスタマイズ範囲と保守体制の2軸で比べてください。
既存システムの改修にも使えますか？
レガシーコードの読解と仕様書の逆生成は、効果が出やすい領域です。仕様書が残っていないシステムでは、改修前の調査工数が見積を押し上げます。その調査部分から適用すると、費用と期間の両面で余地が生まれやすくなります。
情報漏えいが心配です。社内データを入れても大丈夫ですか？
入力内容が学習に使われない法人向け設定や閉域構成を選ぶのが前提です。加えて、プロンプトに入れてよい情報の範囲を社内ルールで決めてください。個人情報を含む場合は、委託先の監督など個人情報保護法上の取り扱いも確認が必要です。
導入効果はどう測ればいいですか？
工数（作業時間）、リードタイム（依頼から完了まで）、不具合や差し戻しの件数。この3指標を着手前に測っておき、導入後に同じ条件で比較します。金額換算は後からできるので、まずは時間と件数を記録することから始めるのが現実的です。