既存システムやBIにAI機能を組み込むには｜追加開発の進め方と注意点

生成AIの活用を考えるとき、新しいAIツールを導入するのではなく、すでに社内で使っている業務システムやBIツールにAI機能を追加したい、という相談が増えています。利用者は使い慣れた画面のまま作業でき、データもすでにシステムの中にあるため、新規にツールを入れるより定着しやすいという利点があります。

一方で、既存システムへのAI機能の追加は、新規開発とは違う難しさがあります。既存のデータ構造や権限の仕組みに合わせる必要があり、AIの応答時間や費用、誤った回答への対処といった、従来のシステム開発にはなかった論点も加わります。「APIをつなぐだけ」と考えて始めると、権限の扱いや精度の問題で手戻りが起きがちです。

また、AIで何ができるかが先に立ち、利用者が本当に困っている作業が置き去りになることもあります。追加開発の成否は、技術よりも「どの作業のどの手間を減らすのか」を最初に言葉にできるかどうかで大きく変わります。

この記事では、既存システムやBIにAI機能を組み込む代表的な型、着手前に確認すべきこと、要望の整理からリリースまでの進め方、技術的な注意点、外注と内製の判断基準を解説します。

既存システムにAIを組み込む代表的な型

既存システムへのAI機能の追加は、何をAIに任せるかによって、いくつかの型に分けられます。型によって必要な開発の範囲と、注意すべき点が変わります。

型	機能の例	向いている場面	主な注意点
文章の要約・分類・抽出	問い合わせ内容の自動分類、日報の要約、書類からの項目抽出	人が文章を読んで仕分けや転記をしている作業	誤分類時の扱い、処理件数に応じた費用
自然な言葉での問い合わせ	BIで「先月の地域別売上を見せて」と入力するとグラフや表を出す	集計の操作が難しく、使いこなせる人が限られているBI	集計の誤り、利用者の権限外のデータへのアクセス
社内文書を根拠にした回答	マニュアルや規程を検索して回答するヘルプ機能	同じ問い合わせが担当者に繰り返し届く業務	文書の鮮度、根拠がない場合の回答
分析結果の解説	ダッシュボードの数値の変化を文章で説明する、注目すべき点を示す	数字は出ているが解釈に時間がかかる、経営層向けの報告	もっともらしいが根拠のない解釈が混ざること
予測・異常検知	需要予測、売上の異常値の検知	過去データが十分に蓄積されている業務	学習データの整備、予測の精度評価

このうち、生成AIのAPIを使う型は、比較的短期間で試作できるのが特徴です。一方、予測や異常検知のように自社データで機械学習モデルを作る型は、データの整備と精度の検証に時間がかかります。最初に取り組むなら、効果が分かりやすく、誤りの影響を人の確認で抑えられる型から始めるのが現実的です。

BIへの自然言語での問い合わせは要望の多い機能ですが、集計の誤りに気づきにくいという弱点があります。生成AIに集計処理を作らせる場合、作られた集計条件を画面に表示して利用者が確認できるようにする、よく使う集計はあらかじめ定義したものから選ばせる、といった工夫が必要です。

どの型を選ぶか迷う場合は、利用者の作業を観察して「読む」「探す」「まとめる」「判断する」のどこに時間がかかっているかを見ると整理しやすくなります。読む作業や探す作業に時間がかかっているなら、要約や社内文書の検索が効果を出しやすく、まとめる作業なら分析結果の解説、判断そのものに時間がかかっているなら、まず判断の材料をそろえる仕組みから検討するのが順当です。判断そのものをAIに任せる設計は、誤りの影響が大きいため、最初の取り組みとしては避けた方が無難です。

着手前に確認しておくこと

開発会社に相談する前に、社内で確認しておくと話が早く進む項目があります。

確認項目	確認する内容
対象の作業	誰が、どの画面で、どの作業に、どれくらいの時間をかけているか
データの所在	AIが参照すべきデータや文書がどこにあり、どの形式で取り出せるか
既存システムの改修余地	ソースコードや設計資料があるか、改修できる開発会社がいるか、外部から呼べるAPIがあるか
権限	利用者ごとに見られるデータが決まっているか、それをAI機能でも守る必要があるか
外部送信の可否	個人情報や機密情報を外部のAIサービスに送ってよいか、社内規程や契約上の制約はあるか
予算の考え方	開発費とは別に、AIの利用料（従量課金）を毎月負担できるか

外部送信の可否は、早い段階で社内の判断を得ておきたい項目です。主要なAIサービスでは、API経由で送ったデータの扱いが公開されています。2026年10月時点で、OpenAIはAPIに送信されたデータを、利用者が明示的に共有を選ばない限りモデルの学習や改善に使わないとしており、Anthropicも法人向け製品やAPIの入出力を、既定ではモデルの学習に使わないと説明しています。GoogleのGemini APIは、料金表で無料枠の内容は製品の改善に使われ、有料枠では使われないと記載しています。

ただし、学習に使われないことと、データが外部に送られないことは別の話です。不正利用の監視のために一定期間保存される場合もあり、たとえばOpenAIは不正利用監視のログを既定で最大30日間保持するとしています。各社の規約や設定は変わることがあるため、採用するサービスの最新の規約を確認し、社内の情報管理ルールと照らし合わせてください。

既存システムの改修余地も重要です。ソースコードが手元になく、元の開発会社とも連絡が取れない場合は、既存システムを直接改修するのではなく、データを外部に取り出して別の画面でAI機能を提供する方法を検討することになります。

参考：Data controls in the OpenAI platform／OpenAI

参考：Is my data used for model training?／Anthropic

要望の整理からリリースまでの進め方

既存システムへのAI機能の追加は、最初から完成形を作り込むのではなく、段階を分けて進めるのが基本です。運営中のBIツールにAI機能を追加したスキロジーの事例でも、要望の仕様化、PoCとモックアップによる検証、実装、リリースという段階を踏み、全体で約7ヶ月をかけました。

段階	主な作業	次に進む判断基準
要望の仕様化	利用者の作業と困りごとを整理し、AI機能で何をどこまで行うかを決める	対象の作業、入力と出力、成功の基準が言葉で書けている
PoC・モックアップ	実際のデータで精度や応答時間を確かめ、画面の試作で使い勝手を確認する	業務で使える精度が出る見込みがあり、利用者が使い方を理解できる
実装	既存システムとの連携、権限制御、エラー処理、ログ、費用の上限設定を作り込む	評価用の質問やデータで基準を満たし、異常時の動作が確認できている
リリース・改善	一部の利用者から公開し、利用状況と誤りを見ながら改善する	利用者からの報告が落ち着き、費用が想定の範囲に収まっている

この中で最も重要なのは、最初の要望の仕様化です。「AIで分析を楽にしたい」という要望のままでは、作るものが決まりません。「営業部長が毎週月曜に地域別の売上を確認する際、前週との差が大きい地域とその理由の候補を、3行程度の文章で示す」のように、誰が、いつ、何を受け取るのかまで具体化することで、PoCで何を確かめればよいかが決まります。

PoCでは、試作の段階から実際の業務データを使うことが大切です。サンプルデータでは精度が高く見えても、実データでは表記の揺れや欠損で精度が落ちることがよくあります。また、画面のモックアップを利用者に触ってもらうと、AIの回答をどこに表示するか、どの程度の長さなら読まれるかといった、仕様書だけでは見えない論点が早い段階で出てきます。

PoCの結果、期待した精度が出ないこともあります。その場合に無理に実装へ進むのではなく、対象を絞る、人の確認工程を入れる、別の型に切り替えるといった判断ができるよう、段階ごとに区切って契約しておくと、発注側のリスクを抑えられます。

組み込み時の技術的な注意点

既存システムにAI機能を組み込む際には、AI単体の試作では見えなかった問題が出てきます。発注側としても、次の点が設計に含まれているかを確認しておくと安心です。

• 権限の引き継ぎ。AI機能が参照するデータは、操作している利用者の権限の範囲に限定する
• 応答時間への配慮。生成に数秒以上かかることを前提に、処理中の表示や、文章を少しずつ表示する仕組みを用意する
• 失敗時の動作。AIサービスの障害や時間切れの際に、既存の機能まで止まらないようにする
• 費用の上限。利用者ごと、機能ごとの呼び出し回数や、月の利用額に上限やアラートを設ける
• ログの記録。入力、出力、参照したデータを記録し、誤答の調査や費用の分析に使えるようにする
• モデルの更新への備え。使用するモデルを明示的に指定し、提供終了や切り替えの際に評価をやり直せるようにする

特に権限の問題は、既存システムならではの注意点です。たとえばBIツールで部署ごとに閲覧できるデータを分けているのに、AI機能がデータベース全体を検索できる設計になっていると、AIへの質問を通じて本来見られないデータが見えてしまいます。AI機能の内部でも、既存システムと同じ権限制御を通す設計にする必要があります。

また、外部の文書やデータに含まれた指示文によって、AIが意図しない動作をさせられる「プロンプトインジェクション」への備えも必要です。AIに渡すデータの範囲を限定する、AIが実行できる操作を参照系に絞る、更新系の操作には人の承認を挟むといった設計で、影響を小さくできます。

費用の面では、AI機能の追加にかかるお金は、開発時の費用と、運用中に毎月かかる利用料に分かれます。利用料は生成AIのAPIの従量課金が中心で、利用者数と1回あたりに送る情報量に比例して増えます。BIへの問い合わせ機能のように、テーブルの定義や過去の会話を毎回モデルに渡す設計では、質問が短くても1回あたりの費用が大きくなりがちです。実装の段階で、渡す情報を必要な範囲に絞る、同じ定義情報はキャッシュの仕組みを使う、即時性が不要な処理はまとめて夜間に処理する、といった工夫を設計に含めておくと、利用が広がっても費用を管理しやすくなります。

リリース後に利用者が増えてから費用の問題に気づくと、設計の変更が必要になり手戻りが大きくなります。PoCの段階で1回あたりの費用を実測し、想定利用者数を掛けた月額の試算を出しておくことをおすすめします。

外注するか内製するかの判断基準

生成AIのAPIは公開されている情報も多く、社内のエンジニアで試作することも可能です。どこまでを内製し、どこからを外部に依頼するかは、社内の体制と既存システムの状態によって変わります。

状況	おすすめの進め方
社内に既存システムを改修できるエンジニアがいる	試作は内製で進め、精度評価や設計の見直しなど、経験が必要な部分だけ外部の支援を受ける
既存システムを外部の開発会社が保守している	保守している会社に改修範囲を確認したうえで、AI機能の設計に強い会社と役割を分担するか、保守会社に一括で依頼する
社内にエンジニアがいない	要望の仕様化から運用改善までを一貫して支援できる会社に依頼し、評価用の質問や正解の作成は社内の業務担当者が担う
ソースコードや設計資料がない	既存システムの改修ではなく、データを取り出して別の仕組みでAI機能を提供する案も含めて検討する

どの進め方を選ぶ場合でも、業務の知識を持つ担当者の関与は欠かせません。AI機能が業務に合っているかを判断できるのは、実際にその業務を行っている人だけです。開発を外部に依頼する場合でも、要望の仕様化と評価の段階には、業務担当者が定期的に参加できる体制を用意してください。

明日からできることは、AI機能を追加したいシステムについて、利用者が時間をかけている作業を3つ挙げ、それぞれ「誰が、いつ、何を入力し、何を受け取りたいか」を書き出すことです。この整理があれば、開発会社との最初の打ち合わせで、具体的な実現方法と概算の費用を話し合えます。

まとめ

既存システムやBIへのAI機能の追加は、利用者が慣れた画面で使え、データもすでにそろっているという利点があります。一方で、権限、応答時間、費用、誤りへの対処といった、従来の開発にはなかった論点を設計に含める必要があります。

進め方は、要望の仕様化、PoCとモックアップ、実装、リリースと改善という段階に分け、段階ごとに次へ進むかを判断するのが安全です。特に最初の仕様化で、誰が何を受け取るのかを具体的にしておくことが、その後の手戻りを防ぎます。

外部送信するデータの扱いは各社の規約で確認し、社内の情報管理ルールと照らし合わせておきましょう。そのうえで、社内の体制と既存システムの状態に合わせて内製と外注の範囲を決めれば、無理なくAI機能を業務に取り入れられます。