生成AIとシステム開発の関係には、2つの意味があります。
ひとつは、生成AIを道具として使い、開発作業を効率化することです。もうひとつは、生成AIを機能として組み込んだシステムを開発することを指します。後者は、社内文書の検索や問い合わせ対応などで導入が進んでいます。ただし、生成AIを組み込む場合、通常のシステム開発とは進め方や見積もりの考え方が異なります。
本記事では、生成AIを組み込んだシステムの開発手順や技術の選択肢、必要な体制について解説します。導入を検討している事業部門や情報システム部門の方は、企画を具体化する際の参考にしてください。
目次
閉じる
生成AIとシステム開発の2つの関係
「生成AIとシステム開発」という言葉は、文脈によって指す内容が変わります。意味を混同したまま検討を進めると、社内での議論がかみ合わなくなる可能性があります。
| 意味 | 何をするか | 主な検討事項 |
| 生成AIを使って開発する | コード生成やテスト作成に生成AIを使い、開発を効率化する | ツール選定、レビュー体制、品質の担保 |
| 生成AIを組み込んで開発する | 生成AIを機能として搭載したシステムを作る | 精度の検証、データの整備、運用コスト |
前者については、「バイブコーディングとは?仕組み・主要ツール・始め方をわかりやすく解説」や「AI駆動開発(AIDD)とは?システム開発のプロセス変革と導入ロードマップ」で詳しく紹介しています。
本記事で扱うのは、後者の「生成AIを機能として組み込んだシステムの開発」です。代表的な用途には、社内向けの検索システムや問い合わせ対応の自動化があります。
生成AIは、同じ質問に常に同じ内容を返すとは限りません。そのため、あらかじめ決めた仕様どおりに動くかだけでなく、回答の精度が実用水準に届くかを確かめながら開発する必要があります。このように、試作と評価を繰り返しながら進める点が、従来のシステム開発との大きな違いです。
開発費用シミュレーター
3ステップで概算費用をすぐに確認できます
① 開発の種類
② 規模・機能数の目安
③ 希望納期・チーム規模
概算費用(税抜)
¥30万〜
目安レンジ:¥24万〜¥40万
※本シミュレーターは概算の目安です。実際の費用はヒアリング後にご提示します。
生成AIを組み込んだシステム開発で実現できること
生成AIを組み込んだシステムはこれまで人が文章や画像を確認し、判断していた作業の効率化に役立ちます。代表的な用途は、次のとおりです。
- 社内文書を検索する
- 問い合わせへ回答する
- 文書を要約・作成する
- 必要な情報を抽出する
- 内容を分類・振り分ける
たとえば社内文書の検索では、規程やマニュアルを参照し利用者の質問へ根拠を示しながら回答するなど、これまで人事部が担当していた業務を代替できます。
また、問い合わせ対応では、よくある質問への一次回答を生成AIに任せ、複雑な案件だけを担当者へ引き継ぐ仕組みを作れます。議事録の要約や報告書の下書き、定型文書の作成にも活用できるでしょう。
さらに請求書や申込書から必要な項目を読み取り、既存システムへ登録する用途もあります。問い合わせや不具合報告の内容を判断し、担当部署ごとに振り分けることも可能です。
これらの用途に共通するのは、文章や画像など、決まった形をもたないデータを扱う点です。
一方、数値の集計や条件が明確な判定は、従来のシステムのほうが速く正確に処理できる場合があります。
生成AIを使うこと自体を目的にせず、解決したい課題が生成AIに適しているかを企画段階で確認してください。
生成AIシステム開発の進め方
生成AIを組み込んだシステムでは回答の精度が実用水準に届くかを確かめながら、段階的に開発を進める必要があります。
開発の流れは、次の4段階です。
- 構想で課題を絞る
- PoCで精度を測る
- 本番環境へ実装する
- 運用しながら改善する
構想フェーズで解く課題を絞る
構想フェーズでは、生成AIで解決する課題を1つに絞ります。最初から用途を広げすぎると、評価基準が定まら図、どの状態になれば成功なのかを関係者が判断できなくなるためです。
まずは、次の内容を整理してください。
- 対象業務を決める
- 利用者を明確にする
- 現在の工数を把握する
- 実用の基準を決める
- 誤回答への対応を決める
特に重要なのが、どの水準に届けば実用とみなすかという合格ラインです。
回答の正確さをどの程度求めるのか、間違いが起きた際にどう検知するのかを事前に決めます。合格ラインを関係者間で共有しておけば、後のフェーズで議論が空転する事態を防げます。
PoCで実現可能性と精度を確かめる
PoC(小規模な実証実験)は、生成AIシステム開発において重要なフェーズです。限られたデータと利用者で試作し、構想フェーズで決めた合格ラインに届くかを確認します。
この際に精度が不足している場合は、その原因の特定が必要です。よくあるう主な原因には、次のようなものがあります。
- データが不足している
- 文書が古くなっている
- 文書の形式が不統一
- 指示の内容が不明確
- 課題自体がAIに不向き
生成AIの精度は、モデルの性能だけで決まるわけではありません。回答に使うデータの質や量、与える指示の内容にも大きく左右されます。社内文書を対象にする場合は、文書が最新の状態になっているか、形式が揃っているかを確認してください。必要な情報が文書に記載されているかも重要です。
データ整備に想定以上の時間がかかると分かった場合は、本番実装へ進む前に計画を見直しましょう。
本番実装で運用に耐える形にする
本番実装では、PoCで検証した仕組みを日常業務で利用できる形へ整えます。
試作段階では問題にならなかった課題が利用者が増えることで明らかになることもあるので、本番実装では主に以下の項目を作り込んでいきましょう。
- 応答時間を安定させる
- 同時アクセスへ対応する
- 利用権限を設定する
- 既存システムと連携する
- 障害時の対応を決める
たとえば、社内文書の検索システムでは、利用者の権限に応じて参照できる情報を分けなければなりません。さらに既存の業務システムと連携する場合は、連携するデータや処理の範囲も確定させます。
あわせて必要なのが、AIの回答が間違っても業務が止まらない設計です。回答の根拠となった文書を併記する、確信をもてない場合は人へ引き継ぐなど、誤回答に備えた仕組みを用意してください。生成AIの回答だけで重要な判断を完結させず、利用者が内容を確認できる設計にすることが重要です。
運用フェーズで精度を改善し続ける
生成AIシステムは、公開すれば完成するわけではありません。実際に利用するスタッフは開発側が想定していなかった表現や条件で生成AIシステムを使うため、実際に使い始めてからシステムの弱点が明らかになることがあります。
そのため、運用開始後の改善に備え、回答履歴や利用者の評価を収集する仕組みを最初から組み込んでください。改善の材料になるのは、うまく答えられなかった質問です。原因に応じて、次のような対応をおこないます。
- 参照文書を追加する
- 古い文書を更新する
- AIへの指示を調整する
- 回答の対象を限定する
- 検索方法を見直す
回答に失敗した事例を集めて修正を繰り返すことで、実際の業務に合ったシステムへ改善できます。
また、生成AIの利用料やインフラ費用は、利用量に応じて増える場合があります。運用開始時には、想定する利用回数と費用の関係も確認しておきましょう。
生成AIシステム開発で押さえる技術の選択肢
生成AIを組み込んだシステムでは、求める機能や精度によって選ぶ技術が変わります。
代表的な選択肢は、次の3つです。
| 手法 | 何をするか | 向いている場面 | 手間とコスト |
| プロンプト設計 | AIへの指示文を工夫する | 一般知識で回答できる用途 | 小 |
| RAG | 社内文書を検索して回答に使う | 社内情報を根拠に回答する用途 | 中 |
| ファインチューニング | 自社データで追加学習する | 独自の文体や分類方法を覚えさせる用途 | 大 |
プロンプト設計とは、生成AIへ与える指示の内容や形式を調整する方法です。比較的少ない手間で始められますが、AIがもっていない社内情報まで回答させることはできません。
RAG(社内文書などを検索し、その内容を回答に使う仕組み)は、自社の情報に基づく回答が必要な場合に適しています。文書を追加すれば回答できる範囲を広げられ、内容を更新してもモデルを学習し直す必要がありません。
ファインチューニングは、自社で用意したデータを使ってモデルを追加学習させる方法です。特定の出力形式や文体、分類方法を覚えさせたい場合に向いています。
社内情報を根拠に回答させたい場合は、まずRAGを検討する方法が現実的です。
多くの案件では、プロンプト設計とRAGを組み合わせることで、必要な機能を実現できます。
一方、ファインチューニングには、学習用データを準備する手間がかかります。モデルの変更に伴って再調整が必要になる可能性もあるため、目的と費用を明確にしたうえで選んでください。
生成AIシステム開発の体制と進め方の判断
生成AIシステムを内製するか外部へ委託するかは、社内の人材やデータの状況によって判断が変わります。
開発には、主に次の3つの役割が必要です。
- 業務側の担当者
- システム開発の担当者
- データ整備の担当者
業務側の担当者は、解決する課題や合格ラインを決め、生成AIの回答が業務上正しいかを評価する役割です。
次にシステム開発の担当者は、生成AIをシステムへ組み込み、既存の業務システムとの連携や利用画面を整えます。
データ整備の担当者は、回答に使う文書やデータを収集し、内容や形式を揃えます。
このうち、外部へ任せやすいのはシステム開発の部分です。課題の設定や回答の評価、社内データの整備まで外部へ丸投げすると、業務に合った精度へ改善しにくくなります。
なお、外部へ委託する場合も業務内容を理解し、回答を評価できる担当者を社内に置いてください。
生成AIシステム開発に関するよくある質問
生成AIシステムの導入を検討している方から寄せられる質問をまとめました。
- 通常の開発との違いは?
- 開発期間はどのくらい?
- RAGと追加学習の違いは?
- 誤回答のリスク対策は?
- 内製と外注の選び方は?
生成AIを組み込んだシステム開発は、通常のシステム開発と何が違いますか
生成AIシステムでは仕様どおりに機能するかだけでなく、回答の精度が実用水準に届くかを検証する必要があります。そのため、本番実装の前にPoCをおこない、限られた範囲で精度や実現可能性を確認する方法が基本です。
あらかじめ合格ラインを決め、試作と評価を繰り返しながら開発を進める点が大きな違いです。要件を確定してから一度に作り込むのではなく、検証結果を踏まえて対象範囲や設計を調整します。
どのくらいの期間で開発できますか
開発期間は、用途やデータの整備状況によって大きく異なります。そのため、一律の期間を示すことはできません。特に時間がかかりやすいのが、回答に使う社内文書やデータを整理する作業です。文書が古い場合や形式が統一されていない場合は、システムを作る前に整備が必要になります。
まずは期間を区切ってPoCを実施し、必要な精度へ届くかを確認してください。その結果をもとに、本番実装の範囲や期間を見積もる方法が現実的です。
RAGとファインチューニングはどちらを選ぶべきですか
社内情報を根拠に回答させたい場合は、RAGから検討してください。RAGでは、社内文書を検索し、関連する内容を生成AIへ渡して回答させます。文書を追加すれば回答できる範囲が広がり、情報を更新してもモデルを学習し直す必要がありません。
一方、ファインチューニングは、特定の文体や出力形式、分類方法を覚えさせたい場合に向いています。
知識を追加したい場合はRAG、出力の傾向を調整したい場合はファインチューニングが基本です。ただし、必要な技術は用途によって変わるため、PoCで精度と費用を比較して判断してください。
回答が間違っていた場合のリスクはどう抑えますか
生成AIによる誤回答を完全になくすことは困難です。ただし、システムの設計や運用方法によってリスクを抑えられます。
主な対策は、次のとおりです。
- 回答の根拠を表示する
- 人への引き継ぎを設ける
- 利用範囲を限定する
- 重要な判断を任せない
- 回答履歴を記録する
回答の根拠となった文書を併記すれば、利用者が内容を確認できます。回答できない場合や確信をもてない場合に、人へ引き継ぐ仕組みも必要です。
また、利用者に生成AIの回答であることを明示し、重要な判断では人が確認する運用を定めてください。
内製と外注はどちらが向いていますか
内製と外注は、役割ごとに分けて判断してください。システムの実装は、外部の開発会社へ委託できます。一方、解決する課題の設定や回答の評価には、自社の業務知識が必要です。
外部へ委託する場合も、業務上の正しさを判断できる担当者を社内に置く必要があります。
社内に開発人材がいても、生成AIに関する経験が不足している場合は、PoCだけを外部へ委託する方法もあります。社内の人材やデータの状況に応じて、担当範囲を決めてください。
まとめ
生成AIとシステム開発の関係には、生成AIを使って開発を効率化する場合と、生成AIを機能として組み込んだシステムを作る場合があります。
生成AIを組み込む場合は、仕様どおりに動くかだけでなく、回答の精度が実用水準に届くかを確認しなければなりません。
まずは構想フェーズで課題と合格ラインを決め、PoCで精度や実現可能性を検証します。その後、本番環境へ実装し、利用履歴をもとに改善を続ける流れが基本です。
また、生成AIの精度はモデルの性能だけで決まるものではなく、回答に使う文書やデータの内容、AIへ与える指示にも大きく左右されます。開発期間を見積もる際は、データの整理にかかる時間も考慮してください。
このような複雑なシステム開発にハードルを抱えている方は、ぜひ外部パートナーの利用も検討してみましょう。
ブライセンでは、システム開発やオフショア開発に関する相談を受け付けています。生成AIシステムの企画やPoCの進め方から相談したい方は、ブライセンへお問い合わせください。
