AIエージェントと業務システムの連携をするための4つの方法

「うちのシステムにAIエージェントを乗せたい」という状況は、この半年で目に見えて増えました。多くは経営者かバックオフィスの責任者からで、ChatGPT を業務で触ったことがある程度の方が、自社の販売管理や生産管理にもAIをつなげられないかと考え始めている、という温度感です。

世の中の記事は「AIエージェントは業務を自律的にこなす」と書きますが、その「業務」のデータがどこにあって、AIからどう触らせるのか、という実装の足元はあまり語られません。

受託開発と保守の引き取りでレガシー環境を触る側から見ると、AIエージェントを業務システムにつなぐ手段は4つに集約されます。それぞれが向く業務システムと古い基幹システムで詰まる場所には共通したパターンがあります。

AIエージェントと業務システム連携とは何か

AIエージェントとは、LLM（大規模言語モデル）を頭脳に据え、与えられた目的に対して自律的に複数のステップを実行するソフトウェアの総称です。チャットで返事を返すだけの生成AIと異なり、外部ツールを呼び出してデータを取りに行ったり、システムに書き込んだりする「手」を持っている点が違いと捉えています。

業務システム連携とは、その「手」を自社のシステム――販売管理・生産管理・会計・CRM・グループウェアなど――に届かせる工程を指します。たとえば「先月の売上を取引先別に集計し、上位5社に対する未回収を抽出してメールの下書きを作る」といった指示を受けたとき、AIエージェントが販売管理から取引データを引いて、会計から入金状況を突き合わせ、メーラーで下書きを作る、という流れが連携の中身に当たります。

ここで重要なのは、AIエージェントが賢くなれば連携が解決する、というわけではない点でしょう。販売管理からデータを引くには、どこかに「引ける口」が要ります。引ける口があっても、認証・権限の制御は欠かせません。引いたデータが古ければ、AIの判断もずれます。AIエージェントの精度より、つなぎ先の業務システムの状態のほうが、結果に効いてきます。中小企業のAI活用事例では、この「つなぎ先」が整っている領域から成果が出ていることが見えます。

なぜいま「業務システムにつなぎたい」という相談が増えているのか

きっかけはいくつか重なっています。一つは、2024年から各社が「AIエージェント」という言葉で製品を出し始めたことです。Salesforce は2024年9月にエージェント基盤「Agentforce」を発表し（出典: Salesforce「Agentforce: Create and Deploy AI Agents」）、国内でも大塚商会が中小向けに「たよれーるビジネスAIエージェント」を提供するなど、SaaS 側からの露出が一気に増えました。社長が経済誌で目にして、社内に降りてくる、という流れができています。

もう一つは、ChatGPT を1〜2年触った経営者の方々が、「個人の作業は速くなったが、会社の業務には届いていない」と感じ始めたことです。議事録や下書きの効率化は実感できる。一方で、見積もりや受注処理など、データが業務システムに入っている領域では、AIを呼び出すたびに人が画面を行き来していて、思ったほど楽になっていない。この差を埋める手段として、業務システムとの連携が話題に上がるようになりました。

相談の入口は、ほぼ毎回「うちのシステムは古いんですが、つながりますか」です。世の中の AIエージェント記事は、最新の SaaS を前提に書かれているものが大半で、20年前の基幹システムや、社内サーバーで動いている VB6 製の販売管理が想定読者に入っていません。読者層の差が、AI連携の検討で詰まる場所を生んでいます。

業務システムにつなぐ4つの方法

AIエージェントから業務システムに触る手段は、突き詰めると4つに集約されます。それぞれ得意・不得意がはっきり分かれます。

API で叩く（公式の口がある場合）

API（Application Programming Interface）は、システムが外部からの呼び出しを受けるための公式の口です。REST／GraphQL／SOAP などの形式があり、認証・権限・速度のいずれにおいても、4つの中で一番きれいに収まります。MCP（Model Context Protocol）のように、AIエージェントから外部システムを呼び出すための標準規格も整い始めており、Anthropic が2024年11月にオープンソースとして公開しました（出典: Anthropic「Introducing the Model Context Protocol」）。新しい SaaS であれば、ほぼ APIが用意されています。

問題は、自社の業務システムに API がない場合です。10〜20年前に作られた業務システムには、外部から叩く口が用意されていないものが多くあります。後付けでAPIゲートウェイ越しに薄いAPI層を立てるという設計も選択肢ですが、設計工数がかかるため、「とりあえずAIをつなぎたい」というスピード感とは折り合いがつきにくい場面もあります。

RPA で画面を動かす

RPA（Robotic Process Automation）は、人間が画面を操作する代わりに、ロボットが画面操作を再生して業務を進める手法です。APIがない業務システムでも、「画面に入って、ボタンを押して、結果を取る」までを自動化できます。AIエージェントから RPAを呼び出して結果を返してもらう構成は、レガシー基幹を持つ会社ではよく選ばれます。

弱点は壊れやすさです。画面のレイアウトが変わると動かなくなる。ボタンのIDが変わると止まる。RPAは画面という不安定な接面に依存しているため、業務システム側のアップデートと運用のメンテナンスが切り離せません。パーソルプロセス＆テクノロジーの解説（最終確認時点）でも、RPAは保守の負荷が継続する手段として位置づけられています（出典: パーソルプロセス＆テクノロジー「RPAとは」）。AIエージェント＋RPAは強力ですが、壊れた時の止血まで含めて設計する必要があります。

スクレイピングで吸い出す

スクレイピングは、画面の HTML を解析してデータを取り出す手法です。APIがなく、RPAも設計上難しい場合の最終手段として登場します。クラウド型の業務サービスで、契約上 APIアクセスを開いていないものを、ブラウザ越しに読み取るような場面で使われます。

注意点は、対象側の利用規約と、画面構造の変更耐性の二つです。規約で禁止されている場合は当然使えませんし、画面の DOM 構造が変わるたびに修正が要ります。AIエージェントの裏側でスクレイピングが動いていることを利用部門が知らないまま運用すると、ある日突然データが取れなくなる、ということが起こりやすい構成です。

中間DB に写して、そこを触る

4つ目は、業務システムから定期的にデータを別の場所（中間DB／データレイク）にコピーし、AIエージェントはその中間DBだけを触る方式です。本体に直接アクセスさせないため、業務システム側の負荷や障害リスクを切り離せます。読み取り中心の用途（集計・問い合わせ・要約）に向いており、書き戻しが要る場合は別途 API か RPAで戻す構成になります。

中間DB方式は、APIの整備が難しい古いシステムを、AIエージェントの世界に持ち込む落としどころとして選ばれることが増えています。リアルタイム性が落ちる点と、データ同期の設計（差分連携・整合性）に手間がかかる点が、引き受けるべきトレードオフです。

古い基幹システムで現実に詰まる場所

4手段だけ並べると、「APIがあれば API、なければ RPAか中間DB」という判断軸で済みそうに見えます。実際の相談の場では、手段を選ぶ手前で詰まることのほうが多いと感じます。

一つ目は、業務システムの「どこに何のデータがあるか」が誰も把握していないケースです。販売管理と称しているが、一部の取引が別の Excel に入っていて、システム上の数字と現場の数字が合わない。AIに集計させても、現場の数字と合わないので使いものにならない。中身を把握する作業から始めないと、つなぎ先が定義できないのです。

二つ目は、仕様書もソースコードも残っておらず、外から触る口を作る判断ができないケースです。中身が読めない以上、APIを足すにせよ、DBから直接データを抜くにせよ、何を壊すか分からないまま手を入れることになります。この段階で「やっぱり一度システムを整えてから」という結論になるご相談は少なくありません。仕様書がない側の向き合い方は仕様書のない業務システムの直し方に書きました。

三つ目は、認証・権限の設計がそもそも存在しないケースです。社内では「全員管理者」で運用してきた業務システムに、AIエージェントが外部から触れる経路を開けると、権限の概念ごと設計し直さなければ事故になります。「AIに営業データだけ見せたい」と思っても、見せ分ける器がシステムに無いと実現できません。

四つ目は、ベンダーロックインです。今のベンダーしか触れない状態のまま、AI連携だけを別の会社に頼もうとすると、APIの追加にも DBアクセスにも「うちでは対応できません」という返事になりがちです。ベンダーロックインは経済産業省が2018年9月に公表した DXレポートでも構造的な課題として指摘されてきたテーマで（出典: 経済産業省「DXレポート～ITシステム『2025年の崖』克服とDXの本格的な展開～」）、AI連携の登場でこの問題がさらに表に出てきた印象です。継承後のレガシーシステム保守を整える話と地続きの論点でもあります。

弊社の引き取り案件でも、「AIをつなぐ前提で、まず業務システム側を触れる状態に戻す」というご依頼が増えてきました。こうした「触れる状態に戻す」段階を、弊社では システムレスキュー として引き取っています（実働ベースの保守）。AIエージェント連携は、つなぎ先の業務システムが触れることが前提の話で、触れない状態のまま AIだけ載せても、現場で動かない――この順序を踏み外さないことが、結局いちばん大事だと感じます。

4手段を選ぶときの判断軸

API・RPA・スクレイピング・中間DBのどれを採るかは、技術の好みではなく業務側の条件で決まります。相談の場では最初に、次の5つの問いを順に確認しています。

書き戻しが必要か — AIエージェントが「読むだけ」で済むのか、「書き込み・更新」まで頼むのか。書き戻しが要るなら、API か RPAになり、中間DBだけでは足りません。
リアルタイム性がどこまで要るか — 直近1分の数字が必要なのか、日次の集計で足りるのか。中間DBは前者には向きません。
対象システムに APIがあるか — あるならまず API。なければ後付けか、RPA・スクレイピング・中間DBの検討に進みます。
触れる人がいるか — 業務システム側を改修・連携できる体制が、社内かベンダーにあるか。誰も触れない状態なら、AI連携の手前で保守の引き取りが先になります。
失敗時の影響範囲はどこまでか — AIが誤った値を書き戻したとき、業務にどこまで波及するか。影響が大きいほど、人の確認を挟む設計にする必要があります。

この5つに答えが出ると、4手段のうち取りうるものは1〜2に絞れます。多くの場合、「APIをまず1つだけ足して、書き戻しはせず、読み取りに絞る」「RPAは画面が安定している管理画面に限定して、業務全体には広げない」のような、保守的な落としどころに着地します。

逆に、5つに答えが出ないまま「とりあえずPoC」を始めると、PoCのための環境構築だけで数か月を溶かす形になりがちです。AIエージェントの導入は、選定の手前で業務とシステムの棚卸しを済ませておくと、コストも期間も大きく変わります。

つないだあとに残る運用責任は誰が持つか

AIエージェント連携の話題が盛り上がる一方で、運用責任の議論はまだ薄い、と感じています。連携を作って動かしたあとに残る責任は、おおむね4つに分かれます。

AI側の振る舞い — モデルの更新・プロンプトの変更・ハルシネーション（事実でない出力）への対応。
連携層（API／RPA／スクレイピング／中間DB） — 壊れたときの止血、業務システム側のアップデートへの追従。
業務システム本体 — 認証・権限・データ整合性の維持、本体側の改修との折り合い。
業務側の運用ルール — AIに任せる範囲、人が確認する範囲、ログの残し方。

このうち、AI側だけ AIベンダー、連携層は別の会社、業務システム本体はまた別の会社、と分かれている状態で運用を始めると、何か起きたときに切り分けの会議だけで時間が溶けます。とくに業務システム本体の保守が手薄なまま AI連携を載せると、本体の不具合と AIの不具合の区別がつかなくなり、結局誰も直さないまま放置される、という事態に陥ります。

理想は、業務システム本体を継続的に触れる体制を先に整えてから、その上に AI連携を載せていく順序です。保守体制を見直したり別の会社に引き継いだりする手前の整理は保守の引き継ぎ方に書きました。AIエージェントを長く運用に乗せたい場合、業務システム側の手入れと、AI側の運用ルールをセットで設計しておくことが、結果的にコストも障害対応の時間も抑えます。

まとめ

AIエージェントと業務システムの連携は、AIの性能ではなく、つなぎ先のシステムの状態と、運用責任の置き方で結果が決まります。手段は API・RPA・スクレイピング・中間DBの4つに整理でき、選ぶときの判断軸は本文の通りです。古い基幹システムでは、選ぶ手前で「中身が把握できない」「触れる人がいない」という壁に当たることが多く、AIをつなぐ前に業務システム側を触れる状態に戻す工程が要ります。

中小企業の経営者・情シスのご担当者からよくいただくのは、「AIに乗り遅れたくないが、自社のシステムが古くて何をどこから手を付ければよいか分からない」というお声です。AI内製の現実と並べて見ても、内製の前段として業務システム側の現状把握とつなぎ先の手入れを整えておくほうが、結果的にコストも期間も読みやすくなります。

「動いてはいるが、もう中身を触れない」状態の業務システムを引き取り、AIをつなぐ準備までを行う相談を受け付けています。

システムレスキュー

仕様書もソースコードも残っていない、保守先が見つからない業務システムを引き取ります。実働ベースの保守で、AI連携を見据えたシステム側の整備にもご相談いただけます。

/service/system-rescue/

ご相談窓口

自社の業務システムにAIエージェントをつなぎたいが、どこから手を付けるか迷われている方へ。現状の把握と、取りうる選択肢の整理からお手伝いします。

/contact/