生成 AI 開発の進め方｜ PoC から技術選定・体制構築まで徹底解説
生成 AI を使ったシステムを作りたいが何から始めればいいかわからないという相談や、概念実証である PoC を始めたものの、そこから先に進む方法がわからないという相談は、IT 部門や DX 推進担当者から多く寄せられます。
生成 AI 開発は、従来のシステム開発とは大きく異なる進め方が求められます。要件が最初から固まらないことや、出力が確率的であること、そして継続的な改善が必要であるといった特性を理解せずに進めると、完成後も使われないシステムになりがちです。
本記事では、生成 AI 開発の全体フローである構想から PoC 、実装、運用までの流れをはじめ、 Amazon Bedrock や RAG といった技術選定、内製と外注の判断基準、開発コストの目安など、プロジェクトを立ち上げるために必要な知識を一通り解説します。
生成 AI 開発とは
生成 AI 開発とは、大規模言語モデルである LLM や画像生成モデルなどの生成 AI 技術を業務システムやサービスに組み込み、実運用できる形に仕上げるプロセスを指します。既製品の AI ツールをそのまま使う AI 活用とは異なり、自社の業務要件やデータ、セキュリティポリシーに合わせた独自システムを構築することが目的です。
生成 AI 開発で実現できること
生成 AI 開発で実現できる業務変革には、次のようなものがあります。
社内情報の検索と活用
膨大なマニュアルや議事録、社内規程などのドキュメントを生成 AI に読み込ませ、自然文で問い合わせると即座に回答が得られる社内 FAQ システムを構築できます。ベテラン社員の知見を組織全体で共有しやすくなります。
問い合わせ対応の自動化
製品仕様や手続き方法に関する問い合わせ対応をチャットボットが担い、オペレーターへのエスカレーション件数を削減します。24時間対応も可能となり、顧客満足度の向上と人的コスト削減が見込めます。
文書作成と要約の効率化
報告書のドラフト生成、会議議事録の要約、多言語翻訳など、テキストを扱う定型作業を自動化します。担当者が本来の業務に集中できる環境を作ります。
業務プロセス自動化と AI エージェント
情報収集、判断、実行を連続して行なう AI エージェントを構築することで、複数システムをまたぐ手続きを人の介在なしに処理できます。
こうした変革は業務効率化にとどまらず、人員の再配置や事業サイクルの短縮につながるケースもあります。
従来のシステム開発との違い
従来のシステム開発と比べると、生成 AI 開発には3つの大きな違いがあります。
要件が最初から固まらない
従来のシステム開発では、要件定義で入出力の仕様を明確に決めてから開発します。生成 AI システムでは、実際に動かしてみるまで回答品質の水準が見えないため、試作となるプロトタイプを先に作って要件を詰めるアプローチをとります。
出力が確率的で一定にならない
同じ入力でも出力が毎回微妙に変わる可能性があります。また、事実と異なる内容を正しいかのように出力するハルシネーションが発生するリスクも存在します。そのため、品質保証の考え方を変え、検索拡張生成である RAG を活用した情報源の限定や、人手による出力内容の検閲を運用フローに組み込むなどの対策をとります。
開発後の継続的な改善
生成 AI システムは、本番稼働後もユーザーのフィードバックを取り込みながら精度を改善し続ける運用を想定します。開発で完成とはならず、運用と改善のサイクルを回し続けることがシステムの価値を維持する条件になります。
こうした特性から、生成 AI 開発では構想、 PoC 、実装、運用のフェーズを段階的に踏む進め方が標準的です。
生成 AI 開発の全体フロー
生成 AI 開発は4つのフェーズで進みます。各フェーズの目的と主な作業内容を整理します。
構想フェーズ 目的と課題の明確化
構想フェーズでは生成 AI を使うべき課題かどうかの判断材料を集めます。課題が特定できていないまま開発に進むと、完成しても利用されないシステムになりがちです。
課題の言語化
まず解決したい業務課題の原因と解決策を言語化します。問い合わせ対応に時間がかかっているという課題であれば、担当者スキルのばらつきや情報の散在、夜間対応ができないなどの理由からなぜ時間がかかるのかを洗い出し、生成 AI でどの原因に対処するかを明確にします。
生成 AI の必要性の検討
課題が明確になったら、既製の生成 AI ツールである SaaS で代用できないか、または生成 AI 以外の手段である RPA や検索システムの改善などで解決できないかも検討します。開発コストをかけて自社システムを作る価値があるかを判断するステップです。
社内リソースの確認
開発に割けるエンジニアの人数と期間、予算、そして学習データとして使える社内データの有無と品質を確認します。データが整備されていない場合、データクレンジングや整備のコストが追加で発生します。
競合動向の確認
同業他社や先行事例がどのような生成 AI システムを構築しているかを把握しておくと、PoC の方向性を定めやすくなります。
PoC フェーズ 小規模検証で実現可能性を確かめる
PoC フェーズの目的は、本番導入すべきかの判断材料を集めることです。 PoC を成功させることではなく、続行や中止、再設計の根拠を得ることが本来の役割です。
評価基準の事前設計
PoC は成功したが本格展開に進まないという状態を防ぐには、開始前に次の 3 軸の評価基準を決めておきます。
- 事業価値 工数削減率、応答時間短縮、コスト削減額など定量的な指標
- 運用適合性 データ取得の難易度、現場担当者の操作負荷、既存システムとの連携可能性
- リスクとガバナンス 情報漏洩対策、ハルシネーション発生率、監査ログの取得可否
PoC の結果をこの3軸で評価し3軸とも基準を満たす場合は続行し、1軸以上が基準未達の場合は再設計または中止するといった判断フローを事前に設定しておくと、経営承認も得やすくなります。
PoC の主な作業内容
PoC フェーズでの具体的な作業は次の通りです。
- データの準備と前処理となるアノテーション、正規化、クレンジング
- 検証環境の構築。 Amazon Bedrock や SageMaker を利用するケースが多いです。
- プロトタイプの開発と精度の測定。ここでは単なる感覚的な評価ではなく、 RAG の評価フレームワークである Ragas の指標（Faithfulness、Response Relevancy、Context Precision）を用いて回答の正確性や関連性を定量的に評価します。
- 現場担当者を交えたユーザーテストとフィードバック収集
- 検証結果の文書化および継続、中止、再設計の判断
スモール PoC の期間感
PoC は1つの業務と1つの機能に絞って実施するスモール PoC が推奨されます。期間は2〜4週間程度を目安にし、結果をもとに次ステップを決める判断会議を設けます。スコープを広げすぎると期間とコストが膨らむ原因になります。
実装フェーズ 本番環境への展開
PoC で続行と判断できたら実装フェーズに移ります。プロトタイプを業務で実際に使えるシステムとして開発し展開するフェーズです。
システム開発の主な作業
- ユーザーインターフェースである UI の設計と開発
- バックエンド API の構築、 Amazon Bedrock や API Gateway との連携
- セキュリティ設定。AWS IAM によるアクセス権限管理や通信の暗号化を行ないます。
- 既存業務システムである ERP や CRM、チャットツールなどとの連携
- 単体テスト、統合テスト、セキュリティテストの実施
現場との共同検証プロセス
実装フェーズで見落とされがちなのが、業務担当者と開発チームによる共同検証です。開発者だけがテストしても、実際の業務で使われる問い合わせパターンや許容される回答範囲はカバーしきれません。現場の担当者に実際の業務を想定した質問を投げかけてもらい、回答精度のズレを早期に発見し修正するサイクルを実装フェーズ中に複数回行なうことが、リリース後の使われないシステムを防ぎます。
社内教育と利用促進
開発と並行して、利用部門への教育も進めます。生成 AI にはハルシネーションが起きる可能性があり、出力の確認が必要なことを事前に説明しておくことで、導入後の混乱を防げます。FAQ や利用ガイドラインの作成もこのフェーズで行ないます。
運用フェーズ 継続的な改善サイクル
生成 AI システムは本番稼働後も改善を続ける運用となります。運用フェーズでは以下のサイクルを回します。
精度の監視とフィードバック収集
ユーザーの役に立たなかった回答や誤情報が含まれていたというフィードバックを収集して分類し、精度改善の優先度をつけます。フィードバック収集の仕組みは UI 設計の段階から組み込んでおくとスムーズです。
モデルの更新とデータ拡充
ナレッジベースとなる社内文書や FAQ の更新、新たな業務パターンへの対応、ハルシネーションが発生しやすいパターンへのプロンプト改善などを定期的に実施します。
効果測定と投資対効果の算出
PoC 時に設定した工数削減率や応答時間、問い合わせ件数の変化などの評価指標を定期的に測定し、投資対効果を可視化します。経営層への継続的な投資承認を得るには、数値での効果報告を仕組みとして組み込むことが大切です。
生成 AI 開発の技術と手法
生成 AI 開発では、自社の目的やスキルレベル、予算に合ったサービスと手法の選定を行ないます。
Amazon Bedrock マネージドサービスで素早く開発する
Amazon Bedrock は、 AWS が提供する生成 AI のマネージドサービスです。 Claude や Llama、Amazon Nova などの複数の LLM を API 経由で利用でき、独自のモデル開発や GPU の調達と管理が不要です。
Amazon Bedrock の主な特徴
- 複数モデルの切り替え 用途に応じて Anthropic Claude や Amazon Nova など複数のモデルを API 呼び出しで使い分けられます。
- Amazon Bedrock Knowledge Bases 自社文書を取り込み、検索拡張生成で社内情報に基づく回答を実現します。
- Amazon Bedrock Guardrails 不適切な出力のフィルタリングやハルシネーション抑制のための安全制御機能です。
- Amazon Bedrock Agents 外部 API との連携や複数ステップの処理を自動化する AI エージェント機能です。
向いているケース
AI の専門知識が少ないチームでも PoC を数週間で開始できる点が大きな利点です。社内 FAQ 対応や文書要約、問い合わせ自動化など、汎用 LLM で対応できる業務であれば、 Amazon Bedrock を起点にした開発が費用対効果に優れています。
料金体系
Amazon Bedrock は従量課金で、生成および処理したトークン数に応じて費用が発生します。 PoC 段階では月額数万円程度から始められるケースが多く、利用規模に応じて段階的にコストが上昇します。
Amazon SageMaker 独自モデルを構築する
Amazon SageMaker は、機械学習モデルの構築と学習、評価、デプロイを一貫して管理できるサービスです。自社データで差別化した専門特化モデルを作りたい場合に選択します。
向いているケース
汎用 LLM では対応できない高度な業務特化型モデルが必要な場合や、自社独自のデータセットで精度を最大化したい場合に有効です。製造業の品質検査や医療分野の画像診断支援など、特定のドメインで高精度を求めるプロジェクトに適しています。
注意点
GPU を利用した大規模モデルの学習はコストが高く、機械学習の専門知識も求められます。学習期間も数週間から数ヶ月単位になることがあります。 Amazon Bedrock で代替できないかを先に確認してから選択する手順をとります。
比較まとめ
| 項目 | Amazon Bedrock | Amazon SageMaker |
|---|---|---|
| 主な用途 | 生成 AI 基盤とアプリ開発 | カスタムモデル構築と機械学習基盤運用 |
| 必要な専門知識 | 低（API 呼び出しで利用可） | 高（機械学習の知識） |
| 導入期間 | 短期（数週間） | 中長期（数ヶ月以上） |
| 初期コスト感 | 低から中（従量課金） | 高（GPU 学習コスト） |
RAG とファインチューニングの使い分け
自社データを生成 AI に取り込む方法として代表的な2つの手法である RAG とファインチューニングの違いを整理します。
RAG（検索拡張生成）
RAG は、ユーザーの質問に対して社内ドキュメントを検索し、関連情報をモデルの入力に付加してから回答させる手法です。 LLM 自体のパラメータを変更しないため、既存モデルをそのまま活用できます。
- メリット 導入コストが低く、情報の更新が容易であり、回答の根拠となる参照元ドキュメントを明示できます。
- デメリット 検索精度がシステム全体の精度に影響するため、文書の品質管理が求められます。
ファインチューニング
ファインチューニングは、特定のタスクやドメインに特化させるために、自社データでモデルのパラメータを再学習させる手法です。
- メリット 特定業務への回答精度が高くなり、推論コストを下げられる場合があります。
- デメリット 学習データの準備と前処理コストが大きく、データが古くなると再学習の手間がかかります。
判断基準
まずは RAG の導入を検討し、精度が不十分な場合や特定の出力スタイル、専門用語への対応が必要な場合にファインチューニングを検討するという流れが現実的です。
内製と外注の選択および体制構築
社内チームで進めるか外部パートナーに委ねるかは、プロジェクトの規模と社内スキル、予算に応じて判断します。
内製と外注それぞれのメリットと判断基準
外注のメリット
生成 AI 開発の専門知識と実績を持つエンジニアを活用できます。開発期間を短縮でき、 PoC から本番まで一貫したサポートを受けられます。また、社内エンジニアのリソースを他の業務と並行させながら開発を進められます。
外注のデメリット
委託費用がかかり、社内にノウハウが蓄積されにくく、長期的にはコストが高くなる可能性があります。外部パートナーへの依存度が高まる側面もあります。
内製のメリット
長期的なコストを抑えられます。自社業務への理解が深いため、精度の高いシステムを作りやすく、社内に AI 開発のノウハウが蓄積されます。
内製のデメリット
生成 AI 開発の経験がある人材の確保と育成に時間がかかり、開発スピードが遅くなりやすい傾向があります。
戦略的外注と段階的内製化が現実的な選択
最初は外注や共同開発で PoC および最小限の機能を持つ MVP を構築し、その過程で社内チームに技術を移転しながら内製化を進めるアプローチをとる企業が多く見られます。開発と育成を伴走してもらう形を取ることで、社内にノウハウを蓄積しながら開発を進められます。
開発プロジェクトの体制づくり
プロジェクトを進行させるには、次のような役割分担を設けます。
| 役割 | 主な担当 | 主な責務 |
|---|---|---|
| 企画と推進担当 | DX 推進部門や事業部門 | 業務要件の整理、評価指標の設定、関係者との調整 |
| 開発エンジニア | IT 部門や外部パートナー | システム設計、実装、テスト、インフラ構築 |
| 業務担当（現場） | 各事業部門 | データ提供、ユーザーテスト、フィードバック |
| セキュリティ担当 | 情報セキュリティ部門 | アクセス権限設計、データ管理ポリシー策定 |
データとセキュリティ体制の設計
機密情報や個人情報を扱う場合は、データの取り扱い設計をプロジェクト初期に固めます。 AWS Identity and Access Management （IAM）によるアクセス権限管理と、 AWS Key Management Service （KMS）による暗号化を組み合わせることでセキュリティを確保します。データの品質管理も同様です。古い情報や誤った情報が混入したまま学習させると回答品質が下がります。ナレッジベースとして使用するドキュメントのレビューや更新ルールは、運用段階まで見据えて設計しておきます。
段階的内製化のロードマップ
最初から完全内製を目指すだけでなく、次の3つのフェーズで段階的に進めると、リスクを抑えながら組織にノウハウを蓄積できます。
フェーズ 1 外注主導で PoC と MVP 構築
外部パートナーが主体となって PoC と MVP を構築します。この段階では社内チームは要件提供とフィードバックに注力し、外部から技術的な進め方を学びます。
フェーズ 2 共同開発と技術移転
社内エンジニアと外部パートナーが共同で開発を進めます。実装の詳細や設計判断の理由、運用手順をドキュメント化し、社内への技術移転を進めます。
フェーズ 3 内製チームで自律運用
社内チームが主体となって機能拡張や精度改善、障害対応を担います。外部パートナーはアドバイザリーやスポットサポートに切り替えます。
Generative AI Use Cases の活用
Amazon Bedrock に対応したオープンソースである Generative AI Use Cases を活用すると、 RAG チャットやドキュメント要約、画像生成などの機能を搭載した生成 AI システムを構築できます。ゼロから開発するより技術的な難易度が低く、内製化への移行もしやすい構成です。社内での生成 AI 活用事例を作りたい場合に有効な選択肢です。
開発コストと期間の目安
生成 AI 開発の費用はフェーズやスコープ、活用技術によって変動します。コスト感を把握したうえで予算計画を立てます。
フェーズ別の費用相場
構想と要件定義フェーズ
課題整理や要件のヒアリング、技術的な実現可能性の評価を外部パートナーに依頼した場合、40〜100万円程度が目安です。自社で行なえれば費用はかかりません。
PoC フェーズ
Amazon Bedrock を活用したスモール PoC の場合、クラウド利用料は月額数万円程度から始められます。外部パートナーへの委託費用を含めると100〜500万円程度が相場感です。期間の目安は1〜3 ヶ月です。
本番システム開発の実装フェーズ
スコープによって費用が大きく変わります。シンプルな社内 FAQ チャットボットであれば300〜500万円程度、複数システムと連携する高度なシステムでは 1,000万円以上になるケースもあります。期間は3〜6ヶ月が目安です。
運用と保守
月額20〜50万円程度が相場で、スコープにより変動します。クラウド利用料は利用量に応じて発生します。
| フェーズ | 期間の目安 | 費用の目安 |
|---|---|---|
| 要件定義と技術調査 | 1〜2 週間 | 0〜100 万円 |
| PoC | 1〜3 ヶ月 | 100〜500 万円 |
| 本番システム開発 | 3〜6 ヶ月 | 300〜1,000 万円以上 |
| 運用と保守（月額） | 継続 | 20〜50 万円とクラウド利用料 |
コスト最適化のポイント
サーバーレスアーキテクチャの活用
フロントエンドを Amazon S3 と Amazon CloudFront で静的ホスティングし、バックエンドを Amazon API Gateway と AWS Lambda のサーバーレス構成にすることで、常時稼働のサーバーを持たずに済みます。使った分だけ課金される従量課金制のため、 PoC 段階や利用が少ない時期のコストを抑えられます。また、利用量が増えても自動でスケールするため、サーバー増強の手間もかかりません。
スモール PoC でスコープを絞る
最初から広い機能をカバーしようとせず、1つの業務と1つの機能に特化して PoC を実施することで、コストと期間を圧縮できます。効果が確認できた業務から優先して本番展開するアプローチをとります。
マネージドサービスの最大活用
Amazon Bedrock や Amazon Bedrock Knowledge Bases、Amazon Bedrock Guardrails などのマネージドサービスを活用すると、インフラ構築やセキュリティパッチ適用、スケーリングといった運用作業をクラウドに委ねられます。開発チームをアプリケーションのロジックに集中させられるため、人件費の節約にもつながります。
CloudWatch によるコスト監視
Amazon CloudWatch を使って API 呼び出し数やトークン使用量、レスポンス時間を監視し、使われていない機能や非効率な処理を定期的に見直します。コスト異常を早期検知するアラームを設定しておくことで、想定外の費用増加を防ぎます。
AWS を活用した生成 AI 開発や Amazon Bedrock を使った生成 AI 基盤の構築については、 cloudpack までご相談ください。 PoC から本番環境の構築と運用まで、一貫してサポートします。