既存システムを変えずにAIを活用する方法

問題提起：AIの前に立ちはだかる「入れ替え」の壁

AI活用を検討し始めると、多くの現場が同じ壁にぶつかります。「今のシステムでは対応できないから、まず基幹システムを刷新しないといけないのではないか」という懸念です。

この懸念があると、AIの検討そのものが止まってしまいます。システムの入れ替えは大きな決断です。稼働中の業務を止めるわけにはいかず、移行には慎重な準備が要ります。結果として、「AIは魅力的だが、うちにはまだ早い」という結論に落ち着いてしまう。こうしたケースは少なくありません。

しかし、ここには一つの思い込みがあります。それは、「AIを使うには、システムそのものを作り替えなければならない」という前提です。この前提を外すと、選択肢は大きく広がります。

なぜ起きるのか：システムが「業務の中心」だと考えられているから

なぜ「入れ替え」が前提になってしまうのでしょうか。それは、基幹システムが業務の中心にあり、すべてがそこに組み込まれている、という捉え方が根強いからです。

たしかに基幹システムは、受発注、在庫、請求といった中核業務を支える大切な仕組みです。しかし、現場の負担が大きいのは、多くの場合その「中心」ではなく「周辺」にあります。

• 届いた注文書を読み取ってシステムへ入力する作業
• 書類を照合する作業
• 複数の情報を突き合わせる作業

こうした業務は、基幹システムの外側で、人手によって行われていることが多いのです。つまり、改善したい負荷の多くは、システムそのものではなく、システムへ情報を届けるまでの「手前の工程」に集中しています。ここに目を向ければ、基幹システムを変えなくても、その手前の工程をAIで支えることで、現場は十分に楽になり得るのです。

「入れ替え」が前提になるのは、負荷の在りかを、システムの内側だと思い込んでいるからだと言えます。これは、第1話で見た「残業は量ではなく判断の問題」という話とも重なります。

現場では何が起きているのか

実際の現場を見てみましょう。

基幹システムは安定して動いていて、登録さえすれば正しく処理されます。問題は、その「登録するまで」にあります。FAXやメールで届いた注文を人が読み取り、内容を確認し、システムへ手入力する。この手前の工程に、毎日多くの時間が費やされています。

たとえば、注文書がFAXやPDFで届き、担当者が内容を確認し、商品コードを照合してからExcelや販売管理システムへ入力し、不明点を取引先へ確認する流れです。この場合、基幹システムそのものを入れ替えるより、読み取り後の確認や商品コード照合、入力データの整形といった「入力前工程」を改善した方が、早く効果につながることがあります。受注経路ごとの負担は「FAX・メール・WEB注文が混在する受注業務の改善方法」で詳しく整理しています。

また、部門ごとに別々のシステムやExcelを使っていて、その間を人がつないでいることもあります。ある画面で確認した情報を、別の画面へ転記する。システム同士が直接つながっていないため、人が橋渡し役になっているのです。

こうした現場では、「システムは動いているのに、業務は楽にならない」という状態が続きます。そして、この状態を「システムが古いせいだ」と捉えてしまうと、話は一気に大がかりな入れ替えへ向かってしまう。けれども実際に困っているのは、システムそのものではなく、その周りの人手による作業なのです。特に帳票を扱う現場では「OCRで読み取った後に確認・転記が残る理由」まで見なければ、業務全体の改善にはつながりません。

改善するための考え方

ここで有効なのが、「変える」のではなく「つなぐ」という考え方です。

既存の基幹システムはそのまま活かします。そのうえで、負荷の高い手前の工程にAIを配置し、整えたデータを既存システムへ渡す。あるいは、つながっていないシステムの間をAIが橋渡しする。基幹システムの内部には手を入れず、その入り口や出口の部分でAIが働く。これがシステム連携によるAI活用の基本的な考え方です。

ここでも、役割ごとに支援する「AIエージェント」の発想が活きてきます。

• 読み取り：書類や画面の情報を取り出す
• 照合：既存データと突き合わせて整合を確認する
• 確認：判断に迷う部分を人へ渡す
• 受け渡し：確定した情報を、既存システムが受け取れる形にして届ける

複数のシステムや情報源の間に立ち、状況に応じてこれらを担う。既存システムを尊重しながら、その周りを賢くつないでいく。この積み重ねが、製造業DX・卸売業DX・建設業DXのいずれにおいても、無理のない現場改善につながります。

この発想の利点は、業務を止めずに始められることです。中核の仕組みは今まで通り動かしながら、周辺の負荷だけを段階的に軽くしていく。うまくいかなければ、その部分だけ見直せばよく、全体を巻き込むリスクを負いません。

既存システムとAIは、どうやって連携するのか

既存システムとAIの連携方法は一つではありません。AIや中間処理で整えたデータを、基幹システムが安全に受け取れる形で渡します。代表的な方法を、現場運用の観点から整理します。

CSV連携

既存システムがCSV取込に対応している場合、AIや中間処理で確認・整形したデータをCSVファイルにし、所定の手順で取り込みます。現在の運用を大きく変えずに始めやすいケースがありますが、項目順や文字コード、重複取込の防止などを事前に確認します。

API連携

既存システムにAPIが用意されている場合、処理結果をリアルタイムまたは準リアルタイムで受け渡せます。利用できる項目、更新権限、処理件数、失敗時の戻し方など、既存システム側の仕様確認が必要です。

SFTP／ファイル連携

決められた場所へファイルを配置し、別のシステムが取得する方式です。業務システム間の定期連携で使われていることも多く、送受信の時刻、ファイル名、暗号化、再送や処理結果の確認方法を運用として定めます。

データベース連携

既存データベースと直接、または中間層を介して連携する方法です。参照範囲や更新対象を限定し、権限、監査、バックアップ、保守責任を明確にする必要があります。安全性と保守性を確保できる構成かを慎重に判断します。

中間システムを介した連携

AI処理と基幹システムの間に中間層を置き、データ変換、マスター照合、人の承認、監査ログ、エラー処理を担わせます。AIの結果をそのまま正本へ登録せず、業務ルールと人の確認を挟めるため、例外が多い現場でも段階的に連携しやすくなります。

APIが常に最適で、CSVが古いということではありません。どの方法が適切かは、既存システム側の受け口、現在の運用、安全性、保守性、必要な更新頻度によって決まります。まずは仕様と業務フローを確認し、現場が無理なく続けられる方法を選ぶことが大切です。

実践ポイント

既存システムを変えずにAIを活用するなら、次の点を意識すると進めやすくなります。

1. 課題を「内側」と「周辺」に分ける：負荷の多くが周辺にあるなら、そこから着手するほうが、費用も影響範囲も小さく済みます。
2. データの受け口を確認する：多くのシステムは、決まった形式でデータを取り込む口を持っています。その口に合わせてAI側が整えれば、システム本体に手を加えずに連携できます。
3. 小さく始めて、確かめながら広げる：最も負荷の高い一つの業務から取り組み、効果を確認してから次へ進む。つながりを一本ずつ増やしていきます。

Excelが現場の確認や調整に役立っているなら、一律に廃止する必要はありません。「Excelを残したまま業務DXを進める考え方」のように、残す役割と、システムへつなぐ工程を分けて考えます。

なぜスペリオルが、こうして一貫して「既存システムを活かす」立場を取るのか。その背景にある考え方は、第4話「スペリオルは『現場業務AI自動化パートナー』として何をする会社なのか」で詳しくお伝えしています。

既存システムを残す方が向いているケース

既存システムを残す選択は、単に刷新を避けるためのものではありません。現在の中核機能を正しく評価し、改善すべき範囲を分ける判断です。次の条件が多く当てはまる場合は、全面刷新より周辺工程の改善やシステム連携が向いている可能性があります。

• 基幹システム自体は安定稼働し、会計・在庫・請求などの主要機能に大きな不満がない
• 課題が入力・確認・照合・転記など、基幹システムの手前や周辺に集中している
• 全面刷新の費用やデータ移行のリスクを抑えたい
• 現場業務を一気に変えず、段階的にAI活用と業務改善を進めたい

一方で、保守切れやセキュリティ上の問題、重大な性能不足がある場合、必要なデータを取得する手段がない場合、システムが現在の業務そのものに適合していない場合は、単純な連携より刷新を検討すべきこともあります。「残す」ことを結論にせず、業務への適合性、リスク、移行負担を比較して判断します。

まとめ

AIを活用するために、基幹システムを必ずしも入れ替える必要はありません。現場の負荷の多くは、システムの内側ではなく、その手前や周辺の人手による作業に集中しているからです。

「変える」のではなく「つなぐ」。既存システムを活かしたまま、負荷の高い工程にAIを配置し、CSV連携やAPI連携など適切なシステム連携で橋渡しをする。この発想に立てば、業務を止めることなく、小さく始めて着実に広げていけます。

大がかりな刷新を待つのではなく、今ある仕組みを尊重しながら現場を軽くしていく。それが、現実的で持続する現場改善の進め方です。