既存の販売管理・ERPを変えずにAIを導入できる？｜転記・照合・通知から始める進め方

販売管理とExcel、ERPと現場の台帳のあいだで、人が転記と突き合わせを続けている。全面刷新は避けたい——この状態からAIを使い始められるかは、既存システムに手を入れられるかどうかではなく、そこからデータを外に出せるかと、処理の結果をどこまで書き戻すかの2点で決まります。読み取って知らせるだけなら、既存システムのプログラムを1行も変えずに始められます。

この記事では、次の3点を整理します。

1. 1全面刷新・既存システムへの機能追加・外部連携の選び分け
2. 2API・CSV・画面しかない場合まで含めた、現行環境の確認項目
3. 3読み取りと通知から始める最小構成と、書き戻しの承認・権限・記録の設計

既存の販売管理・ERPを変えずにAIを導入できる？#

多くの場合できます。ここで言う「変えずに導入する」とは、既存システムのプログラム・テーブル定義・画面に手を入れず、データを取り出す経路と、取り出した先に置く処理だけを新しく作ることです。既存システムから見れば、外から接続してくる利用者が1つ増えるだけの状態です。読み取りだけにとどめるか、結果を既存システムへ書き戻すところまで行うかは、この枠の中で選びます。

この進め方が現実的なのは、いまのAIが実際に効果を出している領域が、外側に足せる処理とほぼ重なっているからです。IPAが2026年7月に公表した「DX動向2026」（2025年度調査、回収数1,799社）では、AI導入で何らかの効果があったと回答した企業のうち、効果の内容として「業務が効率化したり迅速化した」を挙げた割合が91.6%と最も高く、「企画提案等の品質や速さが向上した」が48.9%、「売上や利益が向上した」は3.9%でした。また、AIを導入・試験利用・検討している企業に用途を尋ねた結果では、「文書・音声の要約・翻訳・校正」82.5%、「文書・レポートの作成（社内・社外）」80.5%、「情報検索・収集・分析・レポーティング」77.0%が上位で、「生産・物流・サービス提供の計画支援」は6.0%にとどまります（出典：DX動向2026｜独立行政法人情報処理推進機構（IPA））。読む、まとめる、文書にする。実際に使われているのはこの範囲で、いずれも既存システムの内部を書き換えずに成立します。

「古いシステムだから刷新から」とは限らない#

刷新の必要性は、システムの年式では決まりません。経済産業省・デジタル庁・IPAが事務局を務めるレガシーシステムモダン化委員会の総括レポートは、レガシーシステムを「運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷、高コスト構造の原因となっているシステム」と定義し、その要因を2つの観点で整理しています。

• 技術観点 — 技術の老朽化、システムの肥大化・複雑化、システムのブラックボックス化
• 経営観点 — IT投資がされていない、古い制度としがらみ

そのうえで同レポートは「現行システムが、メインフレーム等の古い技術や開発手法で構築されたシステムであっても、開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作りであれば、レガシーシステムではないと言える」としています（出典：DXの現在地とレガシーシステム脱却に向けて（レガシーシステムモダン化委員会総括レポート）｜経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室）。

分かれ目は、データ連携ができるかと仕様が明確かです。この2つが満たされているなら、20年動いている販売管理システムでも外側にAIを足せます。逆に、保守が切れる、障害時に原因が特定できない、仕様を知る人が社内にいないという状態なら、連携より先に刷新の検討が必要です。移行の進め方は基幹システム（レガシー）刷新の進め方で解説しています。

データが整っていないから始められない、は順番が逆#

同じ「DX動向2026」では、AI利活用に向けた学習データの整備状況が「整備しておりAIに活用している」7.0%、「整備しているが十分ではない」28.4%、「必要性は認識しているができていない」27.6%と分かれています（同出典）。整えきってから始めた企業は、ごく少数です。転記・照合・通知に必要なのは全社のデータ整備ではなく、1つの業務で使う数項目——たとえば得意先コード、商品コード、数量、金額、日付——が揃っていれば動きます。

全面刷新・機能追加・外部連携は何で選び分ける？#

3つの選択肢は、着手までの期間・既存業務への影響・必要な社内体制・やめたいときの戻し方・向く場面の5つの軸で比べると違いがはっきりします。

どれから試すのが安全か#

外部連携です。3つのうち、やめたときに既存システムを元の状態のまま残せるのはこれだけだからです。読み取りと通知にとどめているあいだは、連携を止めれば失うのは作った連携だけで済みます（書き戻しまで進めた場合は、すでに書き込んだデータの扱いを別に決める必要があります）。

同じ「DX動向2026」では、AI導入・運用上の課題として「専門人材が不足している」が50.1%、「生成AIの効果やリスクに関する理解が不足している」が45.8%、「適切な利用を管理するためのルールや基準の作成が難しい」が39.7%と挙がっています（同出典）。人材・知見・ルールのいずれも不足しているなかで、全部門の調整を伴う選択肢から始めるのは現実的ではない、というのが開発を担う側から見た判断です。

ただし外部連携で解けない課題もあります。既存システムの内側で動かなければ意味がない処理——登録時の入力チェック、画面の必須項目の追加、帳票の様式変更——は機能追加の領域です。保守が終了する、事業の前提が変わって業務そのものを作り替えるという場面では、連携でしのぐほど後の移行が重くなります。この場合は全面刷新を正面から検討すべきで、外部連携はその判断を先延ばしする道具にはなりません。

始める前に、現行環境の何を確認する？#

確認は4つの工程に分けて進めます。どの工程で止まるかによって、作れる範囲が決まります。

1. 1どこにデータがあるかを特定する — 画面の裏にあるのが本体か、別システムの転記先かを確かめる
2. 2どの経路で外に出せるかを調べる — API・ファイル出力・データベース接続・画面のどれが使えるかを確認する
3. 3出した形がそのまま使えるかを確かめる — コードの一意性、更新のタイミング、表記のゆれを点検する
4. 4書き戻しをどこで止めるかを決める — 読み取りまでにするか、既存システムへの書き戻しまで行うかを先に決める

データを外に出す経路は4つ#

• APIがある — 認証方式、呼び出し回数の上限、取得できる項目の範囲を先に確認する
• CSV・定型ファイルを出力できる — 現実にはこれが最も多い。出力が即時か夜間バッチ後か、列構成が変わる可能性を確認する
• データベースに読み取り専用で接続できる — 項目は自由に取れるがテーブル定義の変更に弱い。保守ベンダーの許諾と参照範囲を書面で確認する
• 画面と帳票しかない — 画面操作の自動化や帳票PDFの読み取りで対応する。画面の変更で止まるため、更新頻度の低い画面に限る

ベンダー製パッケージでは、APIやデータベース接続の可否が契約と保守条件で決まります。「技術的にはできるが保守の対象外になる」という回答もあるため、技術確認と契約確認は同時に進めてください。

出せたとして、そのまま使える形か#

取り出せることと、使える形であることは別です。次の項目を実データのサンプルで確かめてください。

とくに廃番コードの再利用は見落としやすく、照合が静かに狂います。3年前の得意先コードが別の得意先に振り直されていると、過去データとの突き合わせだけが誤り、当月分は正しいという紛らわしい状態になります。

経路がない、コードが一意でない、取消の表し方が統一されていない。このいずれかが解決しないまま連携を作ると、「動いているが結果が信用できない」仕組みになります。人は不自然な数字に気づきますが、仕組みは気づかないまま通知を出し続けます。

読み取りと通知だけで始める最小構成とは？#

既存システムからデータを取り出し、別の情報と突き合わせ、合わないものだけを人に知らせる。ここで止める構成です。既存システムへの書き込みが一切ないため、設計で決めることが大幅に減ります。

人が転記と照合を担っている状態は、次のようになります。

• 担当者が気づいて動く — 起点が人の記憶と手順書に依存する
• 全件を順に突き合わせる — 合っている件にも同じ手間がかかる
• 気づくのは月末や締め後 — 原因をさかのぼる範囲が広くなる
• 判断の経緯が個人に閉じる — 個人のメモに残り、組織では追えない

読み取りと通知だけの最小構成を入れた後は、次のようになります。

• 決めた時刻に自動で動く — 担当者の不在で止まらない
• 合わない件だけが残る — 人が見るのは差異が出た件に絞られる
• 発生の翌日までに分かる — さかのぼる範囲が1日分で済む
• 通知と対応が記録に残る — いつ何を知らせ、誰が対応したかが追える

部品は4つです。取り出し（読み取り専用の権限で既存システムから読む）、突き合わせ（別システム・ファイル・書面と対応づける）、判定（決めた条件で差異を抽出する）、知らせ（差異の一覧と元データまでたどれる情報を渡す）。

たとえば受注の転記確認から始める場合#

卸売業で、取引先からのメール・PDFの注文を担当者が販売管理システムに手入力しているケースを考えます。最小構成では、販売管理システムの受注データを読み取り専用で取得し、受信した注文書の内容と、得意先コード・商品コード・数量・単価・納期の5項目で突き合わせ、合わない件だけを翌営業日の朝に担当者へ渡します。

登録は従来どおり担当者が行い、仕組みが行うのは「入れ忘れと入れ違いを見つけること」だけです。それでも、全件を目視で見比べる作業はなくなります。注文書の読み取りそのものの自動化は、ここが安定してから次の段階として検討します。どこからAIを使うかの見極め方は業務自動化の進め方でも整理しています。

転記・照合・異常通知で、AIと通常のプログラムをどう分ける？#

分担の原則は1つです。同じ入力に対して同じ結果が返らなければならない処理は、通常のプログラムで書く。 AIは、入力のゆらぎを吸収する工程と、結果を人に説明する工程に使います。

「この2件は同じ取引である」「この差異は許容範囲である」と決めるのは通常のプログラムの仕事です。後から同じ条件で検算したときに同じ答えが出る必要があり（再現性）、なぜその判定になったかを条件の形で示せる必要があり（説明責任）、許容範囲を1か所の数値で変えられる必要がある（変更の容易さ）からです。

AIが有効なのはその手前です。「株式会社A商事」「（株）A商事」「A商事」を同じ取引先の候補として並べる、注文書の自由記述欄から納期の指定を抜き出す、差異の内容を担当者が読んで分かる日本語にまとめる。いずれも最終的な判断は、人か決定的なルールが引き受けます。

書き戻しはどこまで任せる？#

任せ方は4段階あります。自動実行は到達点ではありません。 選ぶ基準は業務の重要度ではなく、「間違えたときに取り消せるか」です。

発注の確定、請求の確定、在庫の引当のように取り消しに手間がかかる処理は、件数が多くても「承認後に実行」までにとどめます。逆に社内の確認用タスクの起票のように、間違えても消せば済む処理は自動実行にしてかまいません。業務ごとに個別に悩むのではなく、取り消せるかどうかという1つの基準で振り分けると、議論は短く済みます。

書き戻しを作るなら、次の3つを設計段階で決めてください。

• 承認の置き場所 — 誰が何を見て承認するかを決め、承認画面には元データと変更後の内容を並べます。「まとめて承認」を入れた時点で承認は形式になるため、許すのは金額影響のない処理に限ります。
• 権限と記録 — 接続情報は対象のテーブルと操作だけを許す専用のものにし、管理者権限を流用しません。いつ・何を・どの承認にもとづいて書いたかを、既存システムの外側にも記録します。
• 止め方と戻し方 — 連携を止めるスイッチと、その判断を誰がするかを決めます。処理済みの印をどちら側に持つかを決めて二重実行を防ぎ、再実行しても同じ結果になる作りにします。

進め方で失敗しないために何を決めておく？#

着手の前に、対象業務の選定基準と、やめる条件を決めておきます。小さく始められる構成だからこそ、やめる判断が先送りになりがちです。向かないのは、次の場合です。

• 対象業務の件数が少ない — 月に数件では作る手間と保守の負担を回収できない。件数と1件あたりの所要時間を掛けて、月あたりの工数を先に数える
• 判断基準が人によって違う — 「この差異は問題ない」の線引きが担当者ごとに違う業務では、条件を書けない
• 経路が画面しかなく、その画面もよく変わる — 画面の変更ごとに連携が止まる
• 既存システムの保守終了が近い — 連携を作っても作り直しになる

見極めに使う指標は4つです。導入前に、同じ指標を手作業の状態で数えておきます。後から比べられなくなるのが最も多い失敗です。

• 確認工数 — 対象業務の件数 × 1件あたりの所要時間。月単位で記録する
• 誤検出の割合 — 通知した件のうち、確認したら対応不要だった件の割合
• 見落としの件数 — 通知されなかったが、後から差異が判明した件数
• 未解決の差異件数 — 通知され、まだ対応が終わっていない件数の推移

誤検出の割合は条件を厳しくすれば下がりますが、見落としが増えます。片方だけを改善目標にすると、もう片方が静かに悪化するため、必ず一緒に見てください。検証期間は締めの周期より長く取り、月次の締めがある業務なら2か月以上を見ます。PoCで止まらせない進め方は生成AI導入の進め方で解説しています。

まとめ#

既存の販売管理・ERPを刷新しないままAIを使えるかは、システムの年式ではなく次の点で決まります。

• 分かれ目は「データ連携ができるか」と「仕様が明確か」の2つ
• 選択肢は全面刷新・既存システムへの機能追加・外部連携の3つ。やめたときに既存システムを元のまま残せるのは外部連携だけなので、ここから試す。既存システムの内側で動く処理は機能追加、保守終了や事業の前提が変わる場面は全面刷新で、外部連携はその判断を先延ばしする道具ではない
• 経路・コードの一意性・取消の表し方のいずれかが解決しないうちは、その先を作らない
• 最小構成は取り出し・突き合わせ・判定・知らせの4部品。既存システムへの書き込みを持たない
• 金額と可否の判定は通常のプログラムで書く。AIは入力のゆらぎの吸収と結果の説明に使う
• 書き戻しの段階は「取り消せるか」で選ぶ。自動実行は到達点ではない
• 導入前に確認工数・誤検出・見落とし・未解決件数を手作業の状態で数えておく

まず、対象にしたい業務のデータが実際に取り出せるかを確かめるところから始めてください。そこが通れば、残りは設計の問題です。

よくある質問（FAQ）#

Q. 既存システムのベンダーに依頼しないと、外部連携は作れませんか？

A. 取り出す経路が確保できれば、別の開発会社でも作れます。ただしデータベースへの直接接続やAPIの利用が保守条件に触れる場合があるため、着手前に既存ベンダーへ可否を確認してください。確認の結果、ファイル出力に限定するという結論になることもあります。

Q. APIがないパッケージでも大丈夫でしょうか？

A. CSVなどのファイル出力があれば進められます。出力が即時ではなく夜間バッチ後になる場合は、照合の基準時刻をそれに合わせます。ファイル出力もない場合は画面操作の自動化や帳票の読み取りで対応しますが、画面の変更で止まるため更新頻度の低い画面に限って使ってください。

Q. 既存システムへの機能追加と外部連携は、どちらが安く済みますか？

A. 対象の処理が既存システムの内側で動く必要があるかどうかで決まります。登録時の入力チェックや帳票の様式変更は機能追加でしか実現できません。既存の画面と手順を変えずに済む転記・照合・通知であれば、外部連携のほうが影響範囲が狭く、やめるときの費用も小さくなります。

Q. 全面刷新を選ぶべきなのはどんなときですか？

A. 保守が終了する、障害時に原因が特定できない、仕様を知る担当者が社内にいない、事業の前提が変わって業務そのものを作り替える——このいずれかに当たる場合です。この状態で外部連携を重ねると、後の移行が重くなります。

Q. AIに書き込みまで任せても問題ありませんか？

A. 間違えたときに取り消せる処理であれば、自動実行にしてかまいません。発注・請求の確定や在庫の引当のように取り消しに手間がかかる処理は、件数が多くても人の承認を経る設計にとどめてください。判断基準は業務の重要度ではなく、取り消せるかどうかです。

Q. どれくらいの期間で始められますか？

A. 対象を1業務に絞り、データの取り出し経路が確保できている前提であれば、数週間から数か月の範囲が目安です。期間を押し上げるのは開発そのものではなく、取り出し経路の確認、コードの整理、承認の決め方の調整です。

既存システムを変えないAI導入のご相談#

弊社（株式会社TryWith）は、システム受託開発とAIソリューション開発、既存システムを残したままの業務改善を手がけています。いまお使いの販売管理・ERPから何がどう取り出せるか、転記と照合のどこまでを仕組みに任せられるか、書き戻しの承認をどこに置くかを、開発を担う立場から整理してご提案します。刷新すべきか連携でしのげるかの見極めだけのご相談も承ります。

お問い合わせはこちら