私たちがクライアントの実務を見ていて感じるのは、社内の業務と社外との業務を別々に考えることには限界があるということです。注文を受け、材料を調達し、生産し、出荷し、請求する一連の流れは、顧客、自社、仕入先、物流会社の間を何度も行き来します。実際のプロセスに、会社の境界はあまり関係ありません。

例えば自動車業界では、こうした企業間連携を長年EDIで処理してきました。通常の注文や納入指示、出荷通知のように、事前に定義できる大量の取引を安定して処理する仕組みとして、EDIは今でも非常に優れています。

難しいのは例外処理です。「昨日の注文をキャンセルしてほしい」「数量を変更したい」「今回だけ別の場所へ納入してほしい」。人間同士であれば、メールや電話で事情を説明すれば理解できます。しかし機械同士で処理するには、「キャンセル」「変更」「例外納入」といったケースをあらかじめ定義し、データ項目や処理ロジックまで作らなければなりません。例外は無限にあります。すべてをコード化しようとするとシステムは複雑になり、結局、例外取引はメールや電話へ戻ってきます。

もう一つの問題は証拠です。メールや電話での変更は、誰が依頼し、誰が承認したのかが十分に記録されないことがあります。受注の変更は、売上計上や在庫評価に直結します。J-SOX対応や会計監査の場面で、変更の経緯の説明に苦労した経験をお持ちの方も多いのではないでしょうか。

メールやPDFの注文書をAIで読み取り、受注データを登録する仕組みはすでに実用化されています。SAPも非構造データからの受注登録機能を提供しています。しかし、その対象の多くは新規注文です。手間がかかるのは、キャンセルや変更といった例外の方です。ここにAIの次の役割があるのではないかと、私たちは考えています。

次の一歩は、人間が自然な言葉で伝えた例外を、AIが「処理可能な変更要求」に変換することです。例えば顧客から「注文12345の残り500個をキャンセルしてください」というメールが届いたとします。AIが直接ERPの注文データを変更するのではなく、

「対象：注文12345」

「依頼内容：残数量500個のキャンセル」

「依頼者：A社○○氏」

「元の指示：このメール」

「処理：担当者承認待ち」

という形に整理します。

担当者が画面で原文とAIの解釈を確認し、承認した後に初めてシステムのデータを変更する。その際、元のメール、AIがどう解釈したか、誰が承認したか、変更前後の内容を一つの履歴として残します。

これは従来のEDIとは少し違います。すべての例外を事前にコード化するのではなく、AIを人間の柔軟なコミュニケーションと、システムが必要とする構造化データの間の翻訳者として使う考え方です。もちろん、AIの解釈が間違う可能性もあります。したがって、重要な変更について人の承認を残すことは欠かせません。Deloitteの2026年の調査でも、AIエージェントについて成熟した管理体制を持つ企業は21%にとどまりました。人の承認ポイント、処理の監視、操作履歴の整備が課題とされています。

この考え方が企業間取引の新しい標準になるかは、まだ分かりません。

ただ、一つはっきりしていることがあります。企業間業務で難しいのは、通常取引そのものではありません。通常取引から外れた瞬間に、人と機械の間に断絶が生じる点です。AIがその断絶を埋め、人間の柔軟性を残したまま、処理可能な情報と証拠を作れるのであれば、その効果は社内プロセスの自動化に劣らないと私たちは見ています。

始め方は難しくありません。まずは例外の多い取引先や品目を一つ選び、変更依頼のメールをAIで整理し、承認と履歴の流れを試してみることをお勧めします。「例外をすべてコード化する」という従来の自動化とは違う道が見えてくるはずです。

‍