既存業務システムと生成AIをつなぐとき詰まりやすい7つのポイント
生成AIを既存の基幹システムや業務システムと連携させるPoCで、実際に手が止まりやすい箇所を7つに整理しました。データ取得、権限、応答時間、監査ログなどの具体と、向かないケースも正直に解説します。
「生成AIのPoCはうまくいったのに、既存システムとつなぐ段階になって進まなくなった」——私たちが受託開発の相談を受けるとき、かなりの割合でこの状態から話が始まります。
この記事は、社内の販売管理システム・基幹システム・グループウェアなどに生成AIを組み込もうとしている情報システム部門の担当者や、その予算判断をする経営層に向けて書いています。技術的な実装手順ではなく、「どこで手が止まるのか」「止まる前に何を確認しておくべきか」を実務ベースで整理します。
なぜPoCと本番連携の間に段差があるのか
PoCの多くは、手元にコピーしたExcelやPDFをAIに読ませて「それらしい回答が出るか」を確認する形で行われます。この段階では、データは静的で、利用者は担当者本人だけ、失敗しても業務に影響しません。
一方、既存システムとの連携では、データが毎日更新され、利用者は部署をまたぎ、出力がそのまま誰かの意思決定材料になります。検証すべき論点がまったく別物になるため、PoCの成功がそのまま本番の見通しにならないのです。
以下、私たちが実際にプロジェクトの中で時間を取られやすい箇所を挙げます。
詰まりやすい7つのポイント
1. そもそもデータを外に取り出す手段がない
最初の関門はここです。パッケージ製品や長年運用されてきた社内システムには、外部連携用のAPIが用意されていないことが珍しくありません。あってもマスタ参照だけで、明細データは取れないケースもあります。
代替案としては、夜間バッチでのCSV出力、DBの参照専用ユーザーを発行してもらう、帳票出力を経由する、といった方法が現実解になります。ただしベンダー保守契約の範囲でDB直接参照が認められているかは必ず確認が必要です。ここを確認せずに設計を進めると、後から作り直しになります。
2. マスタの表記ゆれとコード体系
生成AIは曖昧な表現を扱えますが、それは「システム上どのレコードを指すか」を確定できることとは別問題です。
例えば見積作成の支援をしようとしたとき、営業担当が「A社の東京支店向け、いつもの単価で」と入力したとします。人間なら分かりますが、システム側では取引先マスタに「株式会社A」「A(株)」「A社東京」が別レコードで存在していて、どれが正なのか特定できない。こうしたマスタの汚れは、AI導入で初めて表面化することが多いです。
対策としては、AIに特定させるのではなく、候補を提示して人が選ぶUIにする。あるいは連携範囲を絞ってその範囲のマスタだけ先に整備する。全社マスタ整備を前提条件にすると、プロジェクトが数年単位で止まります。
3. 権限制御が設計から抜け落ちる
社内文書を検索して回答するRAG構成でよく起きます。既存の文書管理システムにはフォルダ単位のアクセス権が設定されているのに、AIが参照するベクトルデータベースに取り込む際、その権限情報が引き継がれない。結果として、人事評価資料や未公開の経営資料に一般社員がAI経由でアクセスできてしまう構成になりかねません。
検索時に利用者の権限でフィルタする仕組みを、最初の設計段階で入れておく必要があります。後付けは非常に面倒です。
4. 応答時間と既存UIの前提のズレ
既存の業務システムは、ボタンを押したら1秒以内に画面が返ってくる前提で作られていることが多いはずです。一方、生成AIは処理内容によって数秒から数十秒かかります。長文生成や複数回の検索を挟む処理ならさらに伸びます。
既存画面に同期処理として組み込むと、タイムアウトするか、利用者が「固まった」と感じて連打します。非同期処理にして「処理中」を明示する、結果を通知やメールで受け取る、といった設計変更が必要になり、これは既存システム側の改修を伴います。工数見積もりで抜けやすい部分です。
5. 出力の受け取り先と承認フローが決まっていない
「AIが下書きを作る」までは決まっているのに、その下書きがどこに保存され、誰が確認し、誰の責任で確定するのかが決まっていない。この状態でリリースすると、現場は結局使わなくなります。
私たちは、AIの出力を既存システムに直接書き戻すのではなく、いったん中間テーブルや専用の下書き領域に置き、人が確認して確定操作をしたときに初めて本番データに反映する構成を推奨しています。監査上も説明しやすくなります。
6. ログと監査対応
何を入力し、どのデータを参照し、何が出力されたか。この記録が残っていないと、後から「なぜこの回答になったのか」を追えません。金融・医療・製造など、記録保持が求められる業界では特に重要です。
ログには個人情報や機密情報が含まれるため、保存期間とアクセス権限も併せて決める必要があります。
7. モデル更新による出力変化
APIで提供されるモデルは更新されます。同じプロンプトでも、以前と出力の形式や傾向が変わることがあります。出力をそのまま後続処理でパースしている場合、ある日突然エラーになる可能性があります。
モデルのバージョンを固定できる場合は固定し、出力形式の検証処理を入れ、代表的な入力パターンでの回帰テストを定期実行する。地味ですが、運用フェーズで効いてきます。
向かないケースも正直に書きます
すべての業務が生成AI連携に向くわけではありません。私たちが「今回は見送りましょう」と伝えることもあります。
- 人の確認を挟まずに基幹データを更新する処理：会計仕訳の自動確定など、誤りが直接損害になる領域は現時点では慎重であるべきです。
- 1秒以内の応答が業務要件の処理：コールセンターの通話中リアルタイム表示などは、実現できても要件を満たせない場合があります。
- 入力元が紙やスキャン画像しかない業務：OCRの精度検証が別プロジェクトになり、想定の数倍の工数がかかります。
- 月に数十件しか発生しない業務：構築・運用コストに対して効果が見合わないことが多いです。
進め方の現実的な順序
私たちが実務で取っている順序は、おおむね次の通りです。
- 参照のみ（読み取り専用）の連携から始める。書き込みは後回しにする。
- 対象業務を1つ、対象部署を1つに絞る。マスタ整備もその範囲だけ行う。
- 出力は必ず人の確認を経由させる。自動化率を上げるのは運用データが溜まってから。
- ログと権限を初期設計に含める。後付けしない。
この順序なら、途中で止まっても部分的に価値が残ります。逆に、全社横断・書き込みあり・完全自動を最初から狙うと、要件定義だけで半年経つことがあります。
検討前に確認しておくと早い3項目
最後に、私たちに相談いただく前でも社内で確認できることを挙げておきます。
- 対象システムに外部連携APIがあるか、なければDB参照が保守契約上可能か
- 対象データに個人情報・機密情報が含まれるか、含まれる場合の利用ポリシー
- 出力を最終確認する担当者と、その承認プロセス
この3点が固まっていると、初回の打ち合わせで具体的な構成案まで踏み込めます。逆にここが曖昧なまま開発を始めると、実装途中で前提が変わり、手戻りが発生します。
既存システムとの連携は、生成AIそのものの性能よりも、周辺の設計で成否が分かれる領域です。派手さはありませんが、ここを丁寧に詰めることが結果的にいちばん近道だと私たちは考えています。