LASSIC Media らしくメディア
生成AIのシステム開発活用｜工程別の使いどころと外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 生成AIは要件定義・設計・コーディング・テスト・保守の各工程で活用でき、工程ごとに期待効果と留意点が異なる
- 公的データでは企業の生成AI利用は広がりつつあるが、ソフトウェア開発工程への適用はまだ伸びしろが大きい
- 外注・委託で進める場合は、目的・対象工程の明確化から始め、委託先の実績・セキュリティ体制・契約条件で選ぶことが成果につながる
目次
生成AIのシステム開発活用とは｜結論と全体像
生成AIのシステム開発活用とは、要件定義・設計・コーディング・レビュー・テストといった開発工程に生成AIを組み込み、ドキュメント作成やコード生成、テスト設計などを効率化する取り組みである。IPA（情報処理推進機構）によれば、対話型AIを用いた要件定義支援・議事録管理・コード生成・ペアプログラミング・コードレビュー・テストデータ作成が代表的な活用工程として挙げられている*2。総務省「令和7年版 情報通信白書」では企業における生成AIの積極的・実験的利用率が49.7%に達しており*1、開発現場への適用も広がりつつある。
開発工程への生成AI適用が注目される背景には、ITシステムの複雑化と開発スピードへの要求がある。要件定義フェーズでは対話型AIが議事録をリアルタイムに整理し、抜け漏れを指摘する役割を担う。コーディングフェーズでは GitHub Copilot（ギットハブ コパイロット：コード補完・生成を行うAIツール）に代表されるコード生成AIがルーティン実装の速度を高める。テストフェーズでは、テストケースやテストデータの自動生成によって手戻りを減らせる。
一方、全工程への一括導入は現実的でなく、どの工程から始めるかを自社の課題・リソースに照らして決めることが成果につながる。外注・委託を選ぶ場合も、工程ごとの期待効果と留意点を把握したうえで委託範囲を定めることが前提となる。
開発工程別の活用パターン（比較表）
IPAが公表する「AIを用いたソフトウェア開発」では、対話型AIの活用が有効な工程として要件定義・設計・コーディング・レビュー・テスト・ドキュメント管理が示されている*2。以下の比較表はIPA工程区分に基づき、各工程の活用例・期待効果・留意点を整理したものである。
| 工程 | 活用例 | 期待効果 | 留意点 |
|---|---|---|---|
| 要件定義 | 対話型AIによる要件整理・議事録の自動生成・抜け漏れチェック | 会議後の文書化時間を短縮し、関係者間の認識ズレを早期に検出できる | AIが出した要件案はビジネスロジックを理解した担当者が確認する運用にする。機密情報の入力には社内ポリシーに準じたAIツールを使う |
| 設計 | 仕様書・設計ドキュメントのドラフト生成、設計レビュー観点の列挙 | ドキュメント作成の初期工数を削減し、設計漏れの指摘を受けやすくなる | AIが生成した設計案は既存アーキテクチャとの整合性をアーキテクトが検証する必要がある |
| コーディング | コード補完・関数生成・ボイラープレート（定型コード）の自動化、ペアプログラミング支援 | ルーティン実装の速度向上と、コーディング規約への準拠チェックを並行して行える | 生成コードにはバグ・セキュリティホールが含まれる場合があり、コードレビューを省略できない。ライセンスに関するリスクも確認が必要 |
| レビュー | コードレビューのコメント生成、品質チェックポイントの提示 | レビュアーの見落としを補助し、品質基準の標準化を支援できる | AIレビューはあくまで補助であり、業務ロジックの正確性はシニアエンジニアが判断する |
| テスト | テストケース・テストデータの自動生成、テストシナリオの網羅性向上 | テスト設計工数を削減し、エッジケースの見落としを減らせる | AIが生成したテストケースが実際の業務フローを網羅しているかを確認する必要がある |
| ドキュメント・保守 | API仕様書・変更履歴の自動生成、障害ログの原因分析支援 | ドキュメント陳腐化を防ぎ、属人的な障害対応を減らせる | 生成されたドキュメントに誤りが含まれる場合があり、リリース前の最終確認が必要 |
この表からわかるように、どの工程においても「AIが生成した成果物を人間が確認する」というプロセスは省略できない。生成AIを活用することで工数削減や品質向上の機会は生まれるが、AIの出力をそのまま本番環境に適用するには十分な検証体制が前提となる。
内製でこの検証体制を整えるには、AIツールの選定・セキュリティポリシーの策定・エンジニアへのトレーニングという複数の準備が必要となる。これらを自社で用意できない場合、外注・委託を選択する合理性がある。
公的データで見る生成AI活用の実態
総務省「令和7年版 情報通信白書」によれば、生成AIを積極的または実験的に利用する企業の割合は49.7%（前年42.7%）に達している*1。用途別では営業・マーケティングが55.2%、事務作業が47.3%と上位に並ぶ。システム開発工程への適用は用途別内訳として個別に公開されていないが、IPA公表のアンケート（2025年）ではソフトウェア開発用途の生成AI利用率は17.0%であり、情報収集・要約（46.1%）や文書作成（43.1%）と比べて低い水準にある*3。
この数字は「開発工程への生成AI適用はまだ普及途上である」ことを示しており、裏を返せば先行して取り組む企業が競争優位を得られる余地があることを意味する。
課題として、同白書では「適切な利用方法が不明確」「セキュリティリスク」「コスト増」が上位に挙げられている*1。特にシステム開発工程では、ソースコードや設計情報という機密性の高いデータをAIに入力するリスクへの対処が不可欠であり、利用方針の策定やツール選定に専門知識が求められる。
IPA「DX動向2025」でも、AI活用推進における人材・スキル不足が課題として継続的に挙げられている*4。AI活用の知見を持つエンジニアは市場に絶対数が少なく、採用には相応のリードタイムを要する。自社でAI活用エンジニアを育成する場合は計画的な投資が必要であり、即効性を求める場合は外部パートナーへの委託が現実的な選択肢となる。
生成AI活用のシステム開発を外注・委託で進める手順
外注・委託でシステム開発の生成AI活用を進める際は、以下の4ステップが起点となる。準備不足のまま委託先を選ぶと、要件の認識ズレや成果物の品質不足が後から発覚しやすい。
ステップ1：目的と対象工程を明確にしてから委託範囲を決める
「生成AIを使いたい」という動機だけでは委託仕様を定義できない。まず「どの工程の何をAIで効率化するか」を言語化することが起点となる。コーディング速度の向上なのか、テスト工数の削減なのか、要件定義の品質向上なのかによって、委託先に求める技術スタックも変わる。
対象工程を1〜2工程に絞り込んでからPoC（概念実証）を設計する方が、全工程への一括適用よりもリスクを制御しやすい。総務省白書が指摘する「適切な利用方法が不明確」という課題*1は、この工程絞り込みのステップを踏むことで対処できる。
ステップ2：委託先の実績・セキュリティ体制・品質保証体制で選定する
生成AI活用開発の委託先を選ぶ際に確認すべき軸は以下の3点である。
- AI活用開発の実績：コード生成・テスト自動化など対象工程での納品実績があるか。具体的な技術スタック（GitHub Copilot、Amazon CodeWhisperer等）の経験があるか
- セキュリティ体制：AIツールへの入力データの取り扱いポリシー、機密情報の分類ルール、ISMS（情報セキュリティマネジメントシステム）等の認証取得状況
- 品質保証体制：AIが生成した成果物に対するレビュープロセス、テスト自動化の範囲、品質基準の定義と測定方法
元請（プライムベンダー）として受注し、設計から品質保証まで一貫して担うパートナーを選ぶことで、工程間の引き継ぎロスや責任の曖昧化を防げる。複数ベンダーへの分散発注は管理コストが増大するため、生成AI活用の初期フェーズでは避けることが多い。
ステップ3：契約・成果物権利・データ取扱いを事前に取り決める
生成AI活用開発では、契約時に以下の3点を明確にしておく必要がある。確認しないまま委託を進めると、完成物の権利帰属やデータ漏洩リスクが事後に問題化する。
- 成果物の知的財産権：AIが生成したコード・ドキュメントの著作権帰属、ライセンス確認の責任分担
- 入力データの取扱い：委託先が使用するAIサービスへの学習データ利用禁止条件、データの保持・削除ポリシー
- 品質基準と検収条件：AIを活用して生成された成果物に対する検収基準、バグ修正・再作業の責任範囲
これらを曖昧にしたまま委託を開始すると、完了後に「生成AIのハルシネーション（事実と異なる出力を生成する現象）によるバグ」の責任所在が不明確になるリスクがある。
ステップ4：PoCから始めて段階的に対象工程を広げる
初回の外注は全工程ではなく、特定の機能・工程を対象とした小規模PoCから始めることを推奨する。PoCで委託先の技術力・コミュニケーション品質・セキュリティ対応を確認してから本格フェーズへ移行することで、後戻りコストを最小化できる。
内製でこれらのPoC設計・管理・評価を行うには、AIエンジニアリングの知識・プロジェクトマネジメントの経験・AIツールの選定基準という複数の専門知識が必要となる。これらを自社で確保できない場合、委託先に設計から評価まで一貫して任せる方がリスクを抑えられる。
まとめ：工程から絞り込み、外注は目的・体制・契約で選ぶ
本稿では生成AIのシステム開発活用について、工程別パターン・公的データに基づく実態・外注委託の進め方の3点を整理した。要点を3つに集約すると次の通りである。第一に、生成AIは要件定義・設計・コーディング・テスト・保守の各工程で活用でき、工程ごとに期待効果と留意点が異なるため、対象工程を絞り込むことが成果につながる。第二に、IPAアンケートではソフトウェア開発用途の生成AI利用率は17.0%*3と広がりつつあるが普及途上であり、先行取り組みが競争優位につながる時期にある。第三に、外注・委託で進める場合は目的と対象工程の明確化を起点に、委託先の実績・セキュリティ・品質保証体制と契約条件の3軸で選定し、PoCから段階的に拡大することがリスク最小化につながる。
よくある質問
生成AIのシステム開発活用はどの工程から始めるのが現実的か
コーディング工程から始めるのが導入しやすい。GitHub Copilotに代表されるコード補完ツールはエンジニア個人の端末で試用でき、効果の測定も行いやすい。IPAが整理する活用工程の中でも、コード生成・ペアプログラミングは導入障壁が低く、成果が出やすい工程として挙げられている*2。要件定義や設計工程への展開は、コーディングでの活用実績を積んでから検討することで段階的にリスクを管理できる。
生成AIを使った開発の品質・セキュリティ上のリスクは何か
主なリスクは3点ある。第一に、AIが生成したコードにバグやセキュリティホールが含まれる可能性（ハルシネーション）であり、レビュー工程の省略は禁物である。第二に、ソースコードや設計情報という機密性の高いデータをAIサービスに送信することによる情報漏洩リスクがある。第三に、生成コードのライセンス問題である。総務省「令和7年版 情報通信白書」でも「セキュリティリスク」が生成AI利用の課題の上位に挙げられており*1、社内ポリシーの整備と委託先の情報管理体制の確認が対策となる。
生成AI活用のシステム開発は内製と外注のどちらが有利か
目的と現在の社内リソースによって異なる。内製は知見が社内に蓄積される反面、AIエンジニアの採用・育成には相応のリードタイムを要する。IPA「DX動向2025」ではAI活用を推進できる人材不足が課題として継続して示されており*4、短期間で成果を求める場合は外注が現実的である。外注の場合は委託範囲・契約条件・データ取扱いを事前に取り決めることで、内製と遜色ない品質を確保できる。
生成AI活用の開発委託にかかる費用感の目安はあるか
公的機関・業界団体が公表した標準的な費用相場は現時点では存在しない。費用はPoC規模・対象工程数・チーム構成・AI利用ツールのライセンス費用によって大きく異なる。費用見積もりを正確に得るには、委託先に対象工程と期待成果物を明示したRFP（提案依頼書）を提示し、複数社から提案を取り寄せて比較することを推奨する。
生成AIを活用した開発の成果物（コード・ドキュメント）の権利は誰に帰属するか
現行の日本著作権法では、AIが生成した成果物の著作権帰属については明確な判例・ガイドラインが整備途上にある。委託契約においては「AIが生成した成果物を含む全納品物の権利は発注者に帰属する」と明記することが現時点では実務上の対処策である。また、委託先が利用するAIツールのサービス規約（学習データへの利用可否等）も確認する必要がある。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：総務省「令和7年版 情報通信白書 第1部第1章第2節 企業におけるAI利用」（2025年）
- *2 出典：IPA（情報処理推進機構）「AIを用いたソフトウェア開発」（2025年）
- *3 出典：IPA（情報処理推進機構）「AIを用いたソフトウェア開発」（2025年）内AIアンケート（生成AIのソフトウェア開発用途利用率17.0%）
- *4 出典：IPA（情報処理推進機構）「DX動向2025」（2025年）
