経営層から「基幹システムにAIを入れて需要予測をやれないか」と言われて、何から確認すればいいのか分からない。そういう相談をよく受けます。ERPベンダーの資料を読んでも、AIとの融合でDXが加速すると書いてあるだけで、自社の基幹で本当に成立するのかが判断できないという声が多いです。
先に答えを書くと、基幹システムにAIを組み込めるかどうかは、AIの性能ではなく自社に溜まっているデータで決まります。この記事では、機能の話に入る前に見るべきデータと業務の条件を整理したうえで、パッケージの標準機能で足すか外付けで作るか、精度が外れたときの運用をどう決めるか、依頼するときに開発会社へ何を確認するかまでをまとめます。読み終わったときに、自社が最初に手を付けるべき業務が1つ決まっている状態を目指します。
この記事のポイント
- 基幹システムにAIを足せるかは、AIの性能より先に自社に溜まっているデータで決まる
- 向くのは判断が定型でデータが溜まっていて外れても取り返せる業務で、それ以外は人が確定する形にする
- 汎用業務はパッケージの標準AI機能、差がつく業務は外付けで作るのが基本の切り分け
- 精度の目標より、外れた出力を誰がどこで止めるかを先に仕様へ入れる
目次
基幹システムにAIを足す前に見る前提
AIで何ができるかという話から入ると、たいてい途中で止まります。できることは無数にあるので、そこから絞る作業に時間を使ってしまうからです。先に見るべきなのは、自社の側に材料があるかどうかです。
AIを載せてもデータが足りない問題
基幹システムには日々の取引データが溜まっています。だから「データはある」と思いがちですが、AIが使える形で溜まっているかは別の話です。
必要なのは量だけではありません。粒度、期間、そして入力の一貫性です。たとえば需要予測をやるなら、日別なのか月別なのか、何年ぶん遡れるのか、途中で商品コードの付け方を変えていないかが効きます。私が現場で見て多いのは、欠品や特売といった数字が動いた本当の理由が、備考欄のフリーテキストに書かれているケースです。人間なら読めますが、そのままでは学習の材料になりません。
期間についても落とし穴があります。季節で動きが変わる商売なら、季節の一巡を何回か含んでいないとAIはその波を学べません。1年ぶんしかないと、それが平常なのか特殊な年だったのかを区別できないわけです。加えて、途中で基幹システムを入れ替えていたり、商品コードの体系を変えていたりすると、その前後でデータがつながりません。5年ぶんあると思っていたら実質2年だった、というのはよくある話です。
ここは開発会社に聞く前に、自社で粗く確かめられます。対象にしたい業務のデータを実際にエクスポートして、必要な列が埋まっているか、空欄や「その他」がどのくらいあるかを見てみてください。半分が空欄なら、AIの話より先にやることがあります。自社の準備状況をもう少し体系的に点検したい場合は、AI導入準備度チェックリスト（6領域50項目）でデータの整備状況や対象業務の選定、運用体制の観点をまとめて確認できます。
基幹のデータが分断されている場合
もうひとつよくある壁が、データが1か所に揃っていないことです。販売は基幹、顧客対応は別のシステム、在庫は現場のExcel、という状態は珍しくありません。
問題は分かれていること自体ではなく、定義が揃っていないことです。同じ取引先が基幹では「株式会社◯◯」、別システムでは「◯◯（株）」で登録されている。商品コードの体系が事業部ごとに違う。この状態でAIを載せると、間違った材料をもとに、自信のある誤答が返ってきます。人間なら「これはおかしい」と気づける集計でも、AIは疑わずに出します。
この場合、先にやるのはAIの導入ではなく、コード体系とマスタの統一です。地味ですが、ここを飛ばして進めた案件が後で作り直しになるのを何度か見ました。どこまでシステムをつなぐ必要があるか、その費用感については基幹システム連携でつなぐ範囲と費用の見方で整理しています。
AIに向く業務と向かない業務
データの目処が立ったら、どの業務に載せるかを絞ります。全部に載せる必要はありません。私は次の3条件で切っています。判断が定型であること、データが溜まっていること、外れても取り返せることです。
| 業務の例 | 向き不向き | 理由 |
|---|---|---|
| 需要予測・発注量の提案 | 向く | 判断が定型で履歴が多く、外れても発注担当が調整できる |
| 仕訳の候補出し | 向く | 過去の仕訳が大量にあり、経理が確定前に確認できる |
| 問い合わせの一次対応 | 向く | 類似質問が繰り返され、有人に切り替える逃げ道を作れる |
| 与信の最終判断 | 人を残す | 外れたときの損失が大きく、判断の理由を説明する必要がある |
| 出荷指示の確定 | 人を残す | 誤りがそのまま物流に流れ、後から取り返せない |
3条件のうち「外れても取り返せる」が、いちばん軽視されやすいところです。精度が高そうだからと、いきなり確定処理を任せてしまう。そうすると1件の誤りで現場の信頼が失われて、二度と使われなくなります。
取り返せない業務でAIを使いたいなら、形を変えれば成立します。AIが候補を出して、人が確定する。この置き方にすれば、与信でも出荷でも使えます。実際、成果が出ている現場はだいたいこの形です。
基幹システムのAI活用はどこから始めるか
対象業務が1つ決まったら、次は作り方です。ここで費用と、その後の保守の重さが決まります。
標準機能のAIか外付けで作るか
いま大手のERPは、標準機能としてAIを載せてきています。Microsoft Dynamics 365 にはAIアシスタントのCopilotが組み込まれていますし、国内の会計系パッケージでもMJSLINK DXがAIを使った仕訳の推進機能を搭載しています。まずは自社が使っているパッケージに、目的に近い機能がすでに無いかを確認するのが早いです。
標準機能と外付けの違いは、自由度と保守の引き受け先です。
- 標準機能: バージョンアップに追従してもらえるが、自社固有の商習慣には合わせにくい
- 外付け: 自社のやり方に合わせて作れるが、連携とその後の保守を自社側で抱える
切り分けの軸は、その業務が自社の勝ち筋かどうかだと考えています。他社と同じやり方でよい汎用業務は、標準機能に寄せる。競合との差がその業務で付いているなら、外付けで作る価値があります。全部を外付けで作ろうとすると、保守できる人が社内にいなくなって数年後に困ります。
外付けを選ぶ場合、基幹側とどうデータをやり取りするかも早めに確認してください。APIが用意されているパッケージなら比較的素直につながりますが、古い基幹だとCSVを日次で吐き出して受け渡す形になることがあります。これは動きますが、リアルタイムの判断には使えません。「AIが即座に判断する」前提で企画を立てたのに、実際には翌日のデータしか見られないという食い違いは、この確認を後回しにすると起きます。連携の方式は費用にも直結するので、提案を受ける前に自社側の出せる形を把握しておくと話が早いです。
小さく試す範囲の決め方
最初から全社・全拠点でやろうとしないことです。1業務、1拠点、過去データでの検証から始めます。
私が勧めているのは、最初の検証では本番の基幹システムに書き戻さないことです。読み取り専用でデータを取り出して、AIの出力と実際の結果を並べて突き合わせる。それだけなら基幹側の改修が要らないので、着手も撤退も軽くなります。ここで「思っていたほど当たらない」と分かることも、十分な成果です。
比べる相手も先に決めておきます。AIの精度を単体で見ても、それが良いのか悪いのか判断できません。いま人がやっている予測や判断と、同じ期間・同じ条件で並べてみる。ベテラン担当者の勘に負けるなら、その業務は当面人がやったほうがいいという結論になります。この比較をやらずに「精度85%が出ました」と報告されると、現場は納得しません。
この段階で、効果をどう測るかも決めておいてください。「業務が楽になった」では稟議が通りません。効果の測り方と社内合意の作り方はAI導入の費用対効果の測り方にまとめています。
精度が外れたときの運用を決める
提案を受けると「精度90%を目指します」といった話になりがちですが、発注側が先に決めるべきなのは目標値より運用です。外れた10%が、誰のどの作業で止まるのかを仕様に入れます。
具体的には、AIの出力に確信度を出させて低いものだけ人が見る、一定金額を超えたら必ず人が承認する、有人対応に切り替える条件を決めておく、といった形です。この線引きを開発会社に任せると、技術的に作れる形になってしまい、現場の運用と合わないことがあります。
業務にAIを組み込むときの体制や点検の観点は、総務省・経済産業省のAI事業者ガイドラインの掲載ページでも整理されています。第1.2版が2026年3月に公表されていて、チェックリストとワークシートが公開されているので、自社の点検項目を作るときの下敷きに使えます。
依頼時に開発会社へ確認すること
ここまで決まっていれば、開発会社との会話は具体的になります。そのうえで確認しておきたいのが次の4点です。
- 学習に使うデータの扱い
- 自社のデータをどこに置いて学習させるのか、社外に持ち出すのか、他社案件に転用されないかを契約で確認します。基幹のデータは取引先の情報を含むので、ここは曖昧にしないでください。
- 何をもって完成とするか
- AIは仕様どおり作れば必ず当たるものではありません。どの数値をどう測って合格とするか、届かなかったときにどうするかを、契約前に決めておく必要があります。
- パッケージ側の機能が更新されたとき
- 標準機能のAIを使う場合、パッケージの更新で挙動が変わることがあります。そのときの検証と修正を誰が負担するのかを決めておきます。
- 運用フェーズの体制
- 出力の精度は時間とともに落ちます。誰がそれを見て、いつ再学習するのか。作って終わりにならない体制を、見積もりの段階で含めてもらいます。
なお、ここで挙げた条件はあくまで一般的な目安です。実際の判断は自社の現行環境と個別の見積もりで確認してください。AI開発をどこに頼むか、依頼前に何を用意するかについてはAI開発の依頼先と外注の進め方で解説しています。
基幹システムのAI活用でよくある質問
相談を受けるときに繰り返し聞かれることを、いくつか挙げておきます。
- Q. 基幹システムを作り直さないとAIは入れられませんか？
- A. 必要ありません。最初の検証は読み取り専用でデータを取り出すだけなので、基幹側の改修は要らないことが多いです。刷新が必要になるのは、AIの結果を業務フローに組み込んで自動処理まで持っていく段階です。順番としては、まず外側で試して、効果が確認できてから基幹側に手を入れるかを判断します。
- Q. データはどれくらいあれば足りますか？
- A. 業務によって変わるので一律には言えません。ただ季節性のある予測なら、季節の一巡を複数回含む期間が目安になります。件数より先に、必要な列が埋まっているか、途中でコード体系が変わっていないかを確認してください。量が多くても中身が揃っていなければ使えません。
- Q. 社内にAIの専門人材がいなくても進められますか？
- A. 進められます。発注側に必要なのはAIを作る力ではなく、対象業務を選び、データの状態を説明でき、外れたときの運用を決められることです。逆にこの3つを開発会社に丸投げすると、技術的には動くけれど現場で使われないものができます。
