レガシーシステムとAI連携する方法——中間層・MCP設計で古い基幹をAI対応に変える

レガシーシステムのままAI活用が求められている背景

AIを使いたいが、既存システムがボトルネックになっている

生成AIを業務に取り入れようとする動きは、規模や業種を問わず広がっています。しかし多くの企業では、「使いたい」という意欲と「使える環境がない」という現実の間で立ち止まっているケースが少なくありません。

特に障壁として挙げられるのが、長年運用してきた基幹システムやオンプレミス環境との接続です。販売管理・在庫管理・会計といった中核業務のデータはこれらのシステムに集中していますが、外部サービスとのAPI連携を想定した設計になっていないことがほとんどです。結果として、LLM（大規模言語モデル）に社内データを読み込ませようとしても、データを取り出す入口すら用意されていないという状況に直面します。

フルリプレースは現実的か——コストと期間の現実

「それならシステムを刷新すればいい」という発想は自然ですが、実態はそれほど単純ではありません。基幹システムのフルリプレースには、規模にもよりますが数千万円から数億円規模の費用がかかるケースが多く、稼働までに2〜5年を要することも珍しくありません。その間も業務は止められないため、並行稼働のコストと移行リスクも重なります。

AI活用のためだけにそれだけの投資と時間を割くことへの合意を、経営層から得るのは容易ではありません。結果として意思決定が先送りされ、AI導入の検討が止まったままになっている企業は多くあります。

「刷新せずに連携する」アプローチが注目される理由

こうした状況への現実的な解として注目されているのが、既存システムを残したままAIと接続するという発想です。レガシーシステムを捨てるのではなく、AIとの橋渡し役となる中間層を設けることで、現行システムのデータや機能をAIから利用可能にします。

刷新コストをかけずに段階的にAI活用を進められるため、意思決定のハードルが大きく下がります。「古いシステムのAI化」は全面的なシステム更改を意味するのではなく、つなぎ方の設計次第で実現できる、というのが現在の技術的な現実です。

まず整理する——レガシーシステムが「AI連携しにくい」理由

生成AIを業務に取り入れたいと考えても、既存の基幹システムがそのまま使えるケースは多くありません。レガシーシステムには、AI連携を阻む構造的な障壁がいくつも存在しています。まずその障壁を正確に把握することが、解決策を検討するうえでの出発点になります。

APIがない、またはREST非対応のシステムが多い

生成AIサービスの多くは、REST APIを通じて外部システムと連携する設計になっています。しかし、1990年代〜2000年代に構築された基幹システムの中には、そもそもAPIが存在しないものや、SOAPなど古い通信規格にしか対応していないものが少なくありません。APIがなければ、AIからデータを呼び出す経路そのものがない状態です。レガシーAPI接続を実現するには、この前提を踏まえた設計が必要になります。

データがクローズドで外部から取得しにくい構造

基幹システムのデータは、独自のデータベース構造やベンダー固有のファイル形式で管理されていることがあります。外部からSQLで直接参照できない設計や、データの取り出しにベンダーの専用ツールが必要なケースも見られます。こうした閉じた構造では、AIにデータを渡す前段階で、データの取り出し方そのものを解決しなければなりません。

オンプレ環境とクラウドAIの間にあるネットワーク・セキュリティの壁

オンプレミスで稼働しているシステムは、インターネットへの接続を制限しているケースが一般的です。クラウド型の生成AIサービスと直接通信させようとすると、ファイアウォールのルール変更や、社内セキュリティポリシーの見直しが必要になります。オンプレAIの繋ぎ方を検討する際、このネットワーク制約は避けて通れない論点のひとつです。

文字コード・データ形式の不整合という見落とされがちな障壁

古いシステムでは、文字コードにShift-JISやEUC-JPが使われていることがあります。一方、現代のAIシステムはUTF-8を前提としているものがほとんどです。文字化けや変換エラーが発生すると、データを正確にAIへ渡せません。また、日付形式や数値の区切り文字など、細かいデータ形式の差異が積み重なると、連携の安定性に直接影響します。こうした不整合は見落とされやすい一方、実際の開発工数に大きく影響する要因です。

連携の基本構造——中間層（ミドルウェア）を挟む設計

レガシーシステムとAIを連携させるとき、多くの企業が陥りやすい失敗があります。それは、レガシーシステムに直接AIを接続しようとするアプローチです。古い基幹システムは改修コストが高く、変更によって既存業務が止まるリスクもあります。現実的な設計として広く採用されているのが、両者の間に「中間層（ミドルウェア）」を挟む構造です。

中間層が担う4つの役割——変換・認証・ルーティング・ログ

中間層は、レガシーシステムとAIのあいだで橋渡しをする仕組みです。具体的には次の4つの役割を担います。

• データ変換：レガシーシステムが出力する独自フォーマット（固定長テキスト・CSV・独自XMLなど）を、AIが処理できるJSON形式などに変換します。
• 認証：AIからのリクエストに対して、アクセス権限の検証を中間層で行います。レガシー側に認証機能がなくても、中間層で補完できます。
• ルーティング：AIからのリクエスト内容に応じて、どのシステム・どのデータソースに問い合わせるかを振り分けます。複数の基幹システムをまたぐ場合も、中間層で一元管理できます。
• ログ管理：誰が・いつ・どのデータにアクセスしたかの記録を中間層で蓄積します。監査対応やトラブル調査の基盤にもなります。

レガシー側は触らず、中間層でAI対応の入口を作る

この設計の最大の利点は、レガシーシステム本体に手を加えなくて済む点です。基幹システムはそのままの状態で稼働させ続けながら、中間層だけを新たに構築します。レガシー側から見れば、従来どおりのデータ送受信を続けているだけです。AI連携のための「入口」を中間層に集約することで、本番環境への影響を最小限に抑えながら段階的に拡張していけます。

中間層設計の選択肢——自社開発・iPaaS・APIゲートウェイの比較

中間層の実装方法は、大きく3つに分かれます。

• 自社開発：独自のミドルウェアをスクラッチで構築します。自由度は高い反面、開発・保守コストがかさむため、要件が複雑なケースや既製品では対応しきれない環境に向いています。
• iPaaS（Integration Platform as a Service）：MuleSoftやBOOMI、Zapierなどのクラウド型連携基盤を利用します。ノーコード・ローコードで設定できるものも多く、開発リソースが限られる企業でも導入しやすいのが特徴です。
• APIゲートウェイ：AWS API GatewayやAzure API Managementなどのマネージドサービスを活用します。認証・ルーティング・ログ管理をクラウド側に任せられるため、セキュリティ要件を満たしながら比較的低コストで構築できます。

どの選択肢が適切かは、既存システムの接続方式・社内のセキュリティポリシー・運用体制によって異なります。重要なのは、いずれの方法でも「レガシー側には極力触れない」という設計方針を守ることです。この原則が、安定稼働と段階的なAI活用の両立を可能にします。

接続パターン別の選び方——4つのアプローチと使い分け

レガシーシステムとAIをつなぐ方法は、一つではありません。システムの構造や求めるリアルタイム性、予算規模によって、適切なアプローチは異なります。ここでは代表的な4つの接続パターンを整理し、それぞれの使い分け基準を示します。

パターン①：中間APIサーバー経由——最も汎用性が高い標準アプローチ

既存システムとAIの間に中間APIサーバーを置き、データの変換・受け渡しを担わせる構成です。レガシーシステム側の改修を最小限に抑えながら、AI側との接続を柔軟に設計できます。将来的にAIツールを変更する際も、中間層の修正だけで対応できるため、長期的な保守性が高いのが特徴です。オンプレ・AI連携の繋ぎ方として、まず検討すべき標準的な選択肢といえます。

パターン②：RPA経由——APIがなくても既存画面からデータを取れる

RPA（Robotic Process Automation）ツールが画面を操作し、データを取得してAIに渡す構成です。APIが公開されていない古いシステムや、ベンダーへの改修依頼が難しいケースでも導入できる点が強みです。ただし、画面のレイアウト変更で動作が止まるリスクがあり、安定稼働には定期的なメンテナンスが必要です。あくまで暫定的な接続手段として位置づけるのが適切です。

パターン③：DBダイレクト接続——速度とリアルタイム性が求められる場合

AIがデータベースに直接アクセスし、必要なデータをリアルタイムで取得する構成です。在庫照会や顧客情報の即時参照など、応答速度が重要な業務に向いています。一方で、DBスキーマの変更がAI側に直接影響するリスクがあり、アクセス権限の設計を誤ると情報漏洩につながる恐れもあります。セキュリティ設計と権限管理を慎重に行う前提で採用を検討してください。

パターン④：ファイル連携（CSV・XML）——最も低コストで始められる入口

システムから定期的にエクスポートしたCSVやXMLファイルをAIに読み込ませる構成です。既存システムに手を加えず、出力機能さえあれば始められるため、初期コストを抑えて効果検証したい場合に適しています。リアルタイム性は低く、データが数時間〜1日単位での更新になるため、速報性が求められる業務には向きません。まず小さく試す「入口」として有効なアプローチです。

4パターンの比較表——コスト・リアルタイム性・リスクで選ぶ

古いシステムのAI化を進める際、最初から完璧な構成を目指す必要はありません。まずファイル連携で効果を確認し、段階的にAPI接続へ移行するアプローチも現実的な選択肢です。重要なのは、現状のシステム構成と業務要件に照らして、どのパターンが「今の自社に合っているか」を見極めることです。

MCP（Model Context Protocol）とは何か——社内システム連携を変える新しい標準

MCPとは——AIが社内システムを「道具として使う」ための共通規格

MCP（Model Context Protocol）とは、AIがさまざまな外部システムやツールを統一した方法で操作するための共通規格です。2024年にAnthropicが公開し、現在は主要なAIフレームワークで採用が広がっています。

MCPの考え方はシンプルです。AIモデル（LLM）側と、操作対象のシステム側が、同じ「言葉のルール」を使ってやり取りする仕組みを標準化する——これがMCPの本質です。AIが社内の基幹システムや業務アプリを「道具として呼び出す」ための共通インターフェースと理解していただくと、意思決定の文脈では把握しやすいでしょう。

従来のAPI個別接続との違い——なぜMCPが拡張しやすいのか

これまでのAI連携は、システムごとにAPIを個別に開発・設定する方式が主流でした。販売管理システムと連携するには専用の接続コードを書き、在庫管理システムと連携するにはまた別のコードを用意する——という形です。連携先が増えるたびに開発コストが膨らみ、保守の複雑さも比例して上がっていきます。

MCPを用いると、この構造が変わります。AIモデル側はMCPという共通の「話しかけ方」を使うだけで済みます。各システム側にはMCPサーバーと呼ばれる小さな変換モジュールを置き、そこがシステム固有の処理に変換します。新しいシステムを追加したいときは、そのシステム用のMCPサーバーを用意するだけで、AI側の実装を大きく変えずに済むのです。

• 従来方式：AI ↔ 連携先Aの専用コード、AI ↔ 連携先Bの専用コード……と個別に開発
• MCP方式：AI ↔ MCP（共通規格）↔ 各システムのMCPサーバー、という統一構造

結果として、連携先が10システムになっても20システムになっても、設計の基本構造を維持したまま拡張できます。この「拡張しやすさ」が、複数の業務システムを持つBtoB企業にとって大きな意味を持ちます。

レガシー環境でMCPを機能させるには——中間層との組み合わせ方

ただし、MCPはそれ単体で万能な解決策になるわけではありません。特にレガシーシステムや基幹システムとのLLM連携においては、MCPと中間層を組み合わせる設計が現実的です。

古い基幹システムはREST APIを持たないケースも多く、MCPサーバーが直接つなぎに行けない場合があります。このとき有効なのが、前のセクションで触れたミドルウェア（中間層）をMCPサーバーの手前に挟む構成です。具体的には次のような構造になります。

1. AIエージェントがMCPを通じて「在庫を照会する」という操作を呼び出す
2. MCPサーバーがその要求を受け取り、中間層（APIゲートウェイやRPAブリッジなど）に渡す
3. 中間層がレガシーシステムのインターフェースに合わせた形式に変換して問い合わせる
4. 結果が逆のルートでAIエージェントに返却される

このレイヤー構成により、オンプレのレガシー基幹でもAI連携の恩恵を受けられます。レガシーシステム自体に手を加えることなく、周辺の変換層で吸収できるため、基幹の安定稼働を損なわずに済むのがポイントです。

MCPが有効なユースケース——問い合わせ対応・在庫照会・承認フロー自動化

MCPを活用した連携が特に効果を発揮しやすい業務領域を以下に挙げます。

• 社内問い合わせ対応：人事・経費・IT規程などの質問に対し、AIが社内ドキュメントと基幹データを横断して回答を生成します。担当者への問い合わせ件数を減らし、応答速度を改善できます。
• 在庫・受注照会：営業担当者が自然言語で「A社向けの在庫は足りているか」と問いかけると、AIが在庫管理システムと販売管理システムを横断して情報を取得し、回答を返します。
• 承認フローの自動化：稟議や発注承認のステータスをAIが確認・更新し、次のアクションを促す通知を送ります。複数システムにまたがる承認プロセスをAIが一元的に管理できます。

いずれも共通しているのは、AIが複数の社内システムを「横断的に操作する」という点です。MCPはこの横断操作を、都度カスタム開発するのではなく、統一された設計の上で実現するための基盤として機能します。基幹システムとLLMの連携を本格的に検討する段階では、MCPへの対応可否を設計要件の一つとして確認しておくことが、後工程の拡張コストを大きく左右します。

オンプレ環境特有の課題——セキュリティとデータ主権をどう守るか

レガシーシステムとAIを連携させる設計を検討する際、意思決定者が最も慎重になるのが「社内データをどこまで外部に出してよいか」という問題です。クラウド型AIサービスの利用が広がる一方で、情報セキュリティ部門や法務部門から懸念が上がるケースは少なくありません。

社内データをクラウドAIに送っていいのか——法務・情報セキュリティの観点

OpenAIやGoogle、Anthropicといったクラウド型LLM（大規模言語モデル）のAPIを利用する場合、送信したデータがモデルの学習に使われるかどうかが一つの論点になります。各社ともAPIプランではオプトアウト設定が用意されているケースが多いですが、利用規約の解釈や改定リスクを完全にゼロにすることは難しい状況です。

特に以下のデータ種別を扱う場面では、法務・情報セキュリティ部門との協議が不可欠です。

• 個人情報（氏名・住所・マイナンバーなど）：個人情報保護法に基づく第三者提供の制限が適用される可能性があります
• 契約書・与信情報・財務データ：取引先との機密保持契約（NDA）の範囲に抵触するリスクがあります
• 製造ノウハウ・設計データ：営業秘密として管理されているデータは、外部APIへの送信が規程違反になるケースがあります

データをマスキング・匿名化して送る構成の考え方

クラウドAIを使いつつリスクを抑える現実的なアプローチとして、「中間層でデータを加工してから送信する」設計があります。具体的には、APIゲートウェイやプロキシ層に個人情報マスキング処理を組み込み、LLMには匿名化・トークン化されたデータだけが届く構成です。

たとえば、顧客名を「顧客A」、金額を「●●円」に置換してからプロンプトを生成し、AIの回答を受け取った後に元の値を復元するパターンが実装されます。ただし、文脈依存性の高い業務では匿名化によって精度が落ちるケースもあるため、業務の性質に応じた設計判断が必要です。

オンプレLLMという選択肢——プライベートAIとの比較

データを一切外部に出したくない場合は、オンプレミス環境や自社管理のプライベートクラウド上でLLMを動作させる「オンプレLLM」が選択肢になります。代表的なモデルとしては、Meta社のLlamaシリーズやMistralなどのオープンソースLLMが挙げられます。

クラウドLLMとオンプレLLMの主な違いは以下のとおりです。

• クラウドLLM：導入・運用コストが低く、モデル性能が高い。ただしデータが外部サーバに送られる
• オンプレLLM：データが自社環境から出ない。ただしGPUサーバなどのインフラ投資と、モデル管理・チューニングの運用負荷が発生する

オンプレLLMは「性能面でクラウドに劣る」と言われてきましたが、近年はオープンソースモデルの精度が急速に向上しており、業務用途によってはクラウドLLMに近い品質を実現できるケースが増えています。

どこで判断を分けるか——データ感度に応じたアーキテクチャ選択の基準

実際の設計では、扱うデータのすべてをオンプレに閉じる必要はありません。データの感度に応じてアーキテクチャを使い分けるハイブリッド構成が現実的です。

• 感度が高いデータ（個人情報・機密情報）：オンプレLLMまたはマスキング処理を必須とする
• 感度が中程度のデータ（社内ナレッジ・業務マニュアル）：プライベートクラウドやAPIオプトアウト設定の上でクラウドLLMを利用
• 感度が低いデータ（公開情報・汎用的な問い合わせ）：クラウドLLMをそのまま活用

この判断軸を社内で合意しておくことが、レガシーシステムとAIを連携させる際のアーキテクチャ選択を前進させる最初のステップになります。情報システム部門だけでなく、法務・情報セキュリティ・経営層が同じ基準を共有できているかどうかが、導入プロジェクトの速度を大きく左右します。

連携設計の進め方——現状調査から本番稼働までのステップ

レガシーシステムとAIの連携プロジェクトは、全体像を把握しないまま着手すると、途中で止まるリスクが高くなります。意思決定者として押さえておくべき進め方を、4つのステップで整理します。

ステップ①：現行システムのインベントリと接続可能性の調査

最初に行うのは、社内に存在するシステムの棚卸しです。システム名・稼働年数・データ形式・APIの有無・ベンダーサポートの状況を一覧化します。このインベントリ調査が不十分なまま進めると、後工程で「接続できないシステムが見つかった」という手戻りが発生しやすくなります。

接続可能性の評価では、次の3点を確認します。

• APIまたはデータエクスポート機能が存在するか——ない場合は画面スクレイピングやRPAを経由する迂回路を検討する必要があります
• データの文字コード・フォーマットが整理されているか——古いシステムではShift-JISや固定長テキストが残っているケースがあります
• オンプレミス環境からの外部通信に制限があるか——ファイアウォール・プロキシの設定確認は必須です

ステップ②：ユースケースを1つ絞ってPoCで検証する

インベントリ調査が終わったら、すぐに全システムの連携を目指すのではなく、効果が見えやすい業務を1つ選んでPoC（概念実証）を実施します。たとえば「受発注データを参照して担当者の問い合わせに回答するチャットボット」など、スコープを絞り込むことが重要です。

PoCで確認すべきチェックポイントは次のとおりです。

• 中間層（APIゲートウェイやデータ変換モジュール）を経由して実際にデータが取得できるか
• LLMへ渡すデータ量と精度のバランスは許容範囲か
• レスポンスの速度がユーザーの業務フローに合っているか

ステップ③：中間層・セキュリティ設計を固めて本番構成へ

PoCで動作が確認できたら、本番を見据えた設計に移ります。この段階では、中間層の冗長化・ログ管理・アクセス権限の整備が中心課題になります。特にオンプレ環境では、LLMへ送信するデータの範囲をあらかじめ定義し、個人情報や機密情報がAPIを通じて外部に渡らないよう、マスキングや送信制御の仕組みを組み込みます。

よくある失敗パターン——スコープを広げすぎてPoCが終わらない

レガシーシステムのAI化プロジェクトで多い失敗は、PoCの段階で「複数システムを同時に連携しよう」とスコープを拡大してしまうケースです。結果として検証が長期化し、予算と関係者の熱量が失われます。PoCはあくまで「この構成で動く」という技術的確証を得るフェーズです。ビジネス要件の拡張は本番設計フェーズに持ち込むと、プロジェクト全体が安定して進みやすくなります。

CLANEが手がけるレガシー×AI連携の設計アプローチ

既存システムに手を加えず中間層で連携する設計の実践

CLANEがレガシーシステムとAIの連携を支援する際に一貫して採用しているのが、既存システムそのものには手を加えないという設計方針です。基幹システムの改修は、テスト工数・承認フロー・ベンダー調整など多くのコストを伴います。そのため、中間層（ミドルウェア）を独立したレイヤーとして新規構築し、既存システムとAI機能の両方を外側から接続する形をとっています。

具体的には、既存システムのデータ出力仕様やAPIの有無を事前に調査し、接続方式をCSV・DB直接参照・既存APIのいずれかに絞り込んだうえで中間層の設計を進めます。この工程を踏むことで、レガシーAPIへの接続においても安定した連携が実現できるケースが多くなっています。

MCPを活用した社内システム横断型AI連携の実装例

CLANEが手がけた事例の一つに、社内の複数システムをMCP（Model Context Protocol）サーバーで束ね、LLMが横断的に情報を参照・操作できる構成があります。たとえば、在庫管理システム・顧客データベース・社内ナレッジツールをそれぞれ個別のMCPサーバーとして実装し、LLMが必要な情報を必要なタイミングで取得できる環境を構築しました。

この設計により、各システムをリプレースすることなく、基幹システムとLLM連携を実現しています。担当者がチャット形式で問い合わせるだけで、複数システムにまたがる情報を統合した回答が得られる業務フローへの移行を支援した実績もあります。

LLM・画像・音声APIの組み込みと接続設計のサポート範囲

CLANEが対応しているAI組み込みの範囲は、テキスト処理を担うLLMにとどまらず、画像認識APIや音声認識APIの接続設計にも及びます。製造業における検品画像の自動分類や、コールセンター向けの音声テキスト変換と要約の組み合わせなど、業務の性質に応じたAPI選定と接続設計を行っています。

いずれの場合も、中間層でAPIの呼び出し・レスポンス整形・エラーハンドリングを担う構成とすることで、将来的なAPI変更やモデルの切り替えにも柔軟に対応できる設計を維持しています。

まとめ——レガシーシステムはAI連携の障壁ではなく、設計次第で活かせる資産

レガシーシステムのAI連携は、システムを刷新しなければ実現できないわけではありません。中間層（ミドルウェア）を正しく設計し、適切な接続パターンを選ぶことで、既存の基幹システムやオンプレミス環境をそのままAI活用の基盤として機能させることができます。

本記事で整理した内容を、大きく三つの軸に沿って振り返ります。

• 中間層設計：APIラッパーやETL処理を挟むことで、古いシステムのデータをAIが扱える形に変換します。直接接続できない構造でも、中間層が吸収層として機能します。
• MCP（Model Context Protocol）：AIモデルと社内システムの接続を標準化する新しいプロトコルです。個別開発のコストを抑えながら、複数システムへの連携を統一的に管理できます。
• セキュリティと段階的な進め方：オンプレ環境特有のデータ主権やネットワーク分離の要件を踏まえた設計が前提です。現状調査・接続検証・小規模PoC・本番稼働という順序で進めることで、リスクを抑えながら導入範囲を広げていけます。

接続パターンの選び方は、データの鮮度・システムの構造・セキュリティ要件によって異なります。一律の正解はなく、自社の環境に照らして判断することが重要です。レガシーシステムへの対応実績があるパートナーと連携することで、設計の精度と導入の確実性を高めることができます。