基幹システムのAI化を検討している方へ

基幹システムにAIを入れたい、と考えている情シス・DX推進の方に向けて書いています。

前提が1つ変わりました。**基幹業務の自動化は、外から作って足すものから、ERPに最初から載っているものへ移りつつあります。**日本オラクルが2026年7月30日に開いた説明会の内容が、その現在地を示しています（クラウドWatch 2026年8月3日）。

自社にとって何が変わるのか、逆に何が変わらないのかを整理します。

説明されたのは3つの層

紹介されたのは、エージェント型アプリケーション、それを作る開発基盤、そして本番運用のための統制です。

エージェント型アプリケーションはすでに22本が提供済みで、今回「在庫プランニング・コマンドセンター」「生産準備ワークスペース」「サプライヤー資格ワークスペース」「カンバン管理ワークスペース」の4本が追加されました。デモとして示されたのは、主力製品の生産能力が需要に足りないというアラートに対し、AIエージェントが生産・営業・財務・人事の論点を並べ、段階導入の提案や自動化計画の前倒し検討まで指示するというものです。

開発基盤が「Oracle AI Agent Studio」で、ノーコードとプロコードの両方を用意しています。統制側では、ポリシーモデルによる決定論的な制御、プロンプトインジェクション対策、権限の継承、監査証跡、本番前のテストとシミュレーションが挙げられました。

これらはAIエージェントに何をどこまで任せるかで整理した設計論点と、ほぼ同じ並びです。個別開発で毎回設計していたものが、製品側の標準機能に降りてきています。

見落としやすいのは「単一データモデル」という前提

説明の中で一番重要だったのは、機能の数ではありませんでした。

部門をまたいでAIエージェントが回答できる理由について、日本オラクルの担当者はこう説明しています。会計・財務、営業、購買、在庫・SCMといった異なる部門の業務が、単一のデータモデルで同じ場所で動いている。他社ERPは業務ごとにシステムとデータが分かれているので、そこが強みになる、と。

これは製品の強みの説明ですが、**裏返すと前提条件の宣言でもあります。**部門横断のエージェントが成立するのは、部門横断のデータが1つのモデルに載っている場合です。

日本の企業の基幹システムは、複数ベンダー・複数世代に分かれていることのほうが多いのが実情です。会計は1つ、生産管理は別、販売は3つ目、そのすき間をExcelと部門システムが埋めている。この状態で「ERPにエージェントが載った」というニュースを自社に当てはめると、期待と現実がずれます。

先に確認するのは機能一覧ではなく、自社のデータがどこにどう分かれているかです。

1000と7000の差

もう1つ、数字の対比が出ていました。組み込み済みのエージェントが1000以上、顧客自身がデプロイしたエージェントが7000以上です。

標準で載っている数より、各社が自分で立てた数のほうが多い。標準の外側に、まだそれだけの業務が残っているということです。

なお、この7000が「顧客が独自に開発したもの」なのか「標準のものを有効化したもの」なのかは説明されていません。原文は「デプロイした」であって「開発した」ではないので、そこは断定せずに読みます。

標準の外に残るもの

ERPの中が標準で自動化されるほど、発注側の仕事は外へ移ります。残るのは、おおむね次の3つです。

1つ目は、ERPの外に出ている業務です。部門固有の業務、現場の紙とExcel、他社SaaS、生産設備や検査装置から出るデータ。ERPの単一データモデルに載っていないものは、標準のエージェントからは見えません。

2つ目は、つなぎ目の設計です。エージェントが出した判断を、どのシステムのどの項目へ書き戻すのか。止まったとき誰のどの画面に出すのか。ここは製品の外側なので、各社が決めることになります。

3つ目は、止める権限の設計です。ガードレールや監査証跡が製品側に用意されても、「どの操作を人間の承認にするか」の線引きは業務側の判断です。この線引きは現場で量産する路線と基幹へ組み込む路線で必要な体制が変わります。

ERPのAIエージェント提案を受けたときの5つの確認

  • 自社のデータは単一モデルに載っていますか: 部門横断の自動化は、部門横断のデータが前提です。基幹が複数に分かれているなら、まず統合の範囲を決める話になります
  • 標準エージェントで足りる業務はどれですか: 提供済みの本数ではなく、自社の業務名で対応表を作らせます。足りない業務がどこに残るかが、そのまま個別開発の範囲です
  • 書き戻し先と通知先は決まっていますか: エージェントの判断を、どのシステムのどの項目へ返し、異常時に誰の画面へ出すか。ここが未定のまま導入すると台帳が二重になります
  • どの操作に人間の承認を挟みますか: 製品側のガードレールとは別に、業務としての停止権を誰が持つかを決めます
  • ERPの外にある業務は誰の責任範囲ですか: 提案の対象範囲が製品の中で閉じているのか、外側の接続まで含むのか。契約前に線を引きます

ERPベンダーやSIerとの商談、提案評価シートにそのまま転記して使えます

現場メモ

私たちはERPそのものを入れ替える提案をしません。この手の発表を歓迎しているのも、ポジショントークではなく実務上の理由があります。

案件で実際に多いのは、基幹の中が遅いのではなく、基幹の外に出た業務が全体の判断を止めているケースです。承認が紙で回っている、現場の実績がExcelに溜まってから月次でまとめて入る、部門システムの数字と基幹の数字が合わない。この状態で基幹の中だけ速くしても、待ち時間の総量は変わりません。

基幹の中がベンダー標準で自動化されていくと、外に残った業務の遅さがかえって目立つようになります。私たちの仕事はそこへ寄っていくだろうと見ています。だから見積もりでも「ERPを速くします」ではなく、どの業務がERPの外にあり、そこをどうつなぐかから書いています。

発注側の仕事はどこへ移るか

業務自動化の価格には30万円という下限が公表され、基幹業務の自動化はERPの標準機能に入り始めました。パッケージで済む範囲は、確実に広がっています。

だからといって個別開発が要らなくなるわけではありません。**要らなくなるのは、標準で用意されたものを作り直す仕事です。**残るのは、標準の外に出ている業務を特定し、つなぎ目を設計し、止める権限を決める仕事のほうです。

自社の基幹システムのどこまでが標準で足り、どこから外側の設計が要るのかを整理したい段階でしたら、お問い合わせからご相談ください。製品選定ではなく、業務がどこに分かれて残っているかの棚卸しから入ります。