Web受発注システムを入れても残る業務の二重入力：原因の切り分けと、連携方式・取引先への依頼の選び方

◆監修・編集責任者　小園 将隆　2026年11月4日

B2B EC-COLUMN

Web受発注の後に注文を打ち直してしまうのは、どこで流れが切れているからか

Web受発注システムを入れたのに、届いた注文を販売管理や出荷・請求の画面へもう一度打ち込んでいる。
この業務の二重入力は、システムの性能だけが原因ではありません。
注文データが社内システムの読める形で渡らない切れ目と、取引先ごとにばらばらな入口から生じています。
減らす手段は、社内システムとのAPI連携、CSVなどのファイル取込、共通標準に対応したEDIの三つに分けて考えられます。
どれを選べるかは取引先の協力が得られるかで変わります。
まず自社の切れ目を特定し、協力を得にくい段階では自社側で完結する方法から始めるのが現実的です。

注文を受けてから請求までの、打ち直しが起きやすい4か所

受注担当者の作業でいえば、打ち直しは「注文を見る画面」と「登録する画面」が別々になっている所で生じます。
Web受発注システムの管理画面で注文を開き、品番・数量・納期・届け先を読み取って、販売管理の受注入力画面へ同じ内容を打ち込みます。
この転記が一度で済めばまだよいのですが、受注のあとにも、出荷や請求のために別のシステムへ同じ注文の情報を渡す場面が続きます。

注文の受信から請求までをたどると、打ち直しが起きやすいのは次の4か所です。

• 受注登録：Web受発注や電話・FAXで届いた注文を、販売管理へ受注として入力する所
• 出荷指示：受注データを在庫・出荷の仕組みへ渡し、引当や出荷指示を作る所
• 請求：出荷した数量と単価を、請求書や会計へ反映する所
• 変更の反映：取引先からの訂正や納期変更を、登録済みの受注に反映し直す所

このうち、Web受発注の導入で直接変わるのは、注文が電子データとして届くという入口の部分です。
受信した注文が販売管理へ自動で渡らなければ、受注登録の打ち直しは残ります。
販売管理と出荷・請求の間がすでにつながっている会社なら、受注登録の1か所を解消すれば後ろの工程まで手入力が減ります。
そこもつながっていなければ、同じ注文を何度も打つことになります。
受注登録で品番や数量を誤ると、その誤りは出荷と請求へそのまま引き継がれます。
そのため、最初の転記がいちばん影響の大きい切れ目です。

切れ目が生じる原因は、大きく三つに分けられます。
一つ目は、注文がそもそも電話・FAX・メールで届くことです。
中小企業庁のデータ連携基盤の計画を伝えた2021年の報道でも、受発注が電話・FAX・メール中心で効率が低いことが課題に挙げられていました³。
二つ目は、取引先ごとに注文の入口が違うことです。
三つ目は、注文がデータで届いても項目やコードが社内システムと合わず、読み替えて入力していることです。
どれが当てはまるかで、効く手段が変わります。

取引先ごとに入口が違う「多画面」の状態

二つ目の原因は、受注側が複数の取引先を抱えるほど目立ちます。
たとえば、ある取引先は自社のWeb受発注に入力してくれる一方で、別の取引先は先方が指定するWeb画面に注文を掲載し、さらに別の取引先はFAXで送ってくる、という状態を考えてみてください。
担当者は三つの入口を順に確かめ、それぞれの注文を販売管理へ打ち込むことになります。
自社のWeb受発注を入れても、そこへ入力してくれない取引先の分については、入口が一つ増えただけになりかねません。

共通EDIサービスの提供元である日本IBMは、取引先ごとに異なる仕組みでデータを扱うために複数の画面を切り替えて受注処理を行う状態を「多画面問題」と呼び、中小・中堅企業で起きやすいと説明しています²。
これは提供元の見方です。
ただ、2021年の報道でも、取引する業界や企業ごとにシステムを立ち上げる手間が課題に挙げられていました³。
画面ごとに表示項目や品番の書き方が違うと、担当者は転記のたびに読み替えをしなければならず、入力ミスの入り込む余地が増えます。

押さえておきたいのは、多画面の状態は自社のシステムだけを入れ替えても解消しないという点です。
入口を減らすには、取引先に入力先や送り方を変えてもらうか、複数の入口から届く注文を一か所に集める仕組みが要ります。
どちらも取引先との関係が絡むため、取引先の協力をどこまで得られるかという判断につながっていきます。

自社の切れ目を確かめる3つの問い

自社の切れ目は、次の三つの問いに答えると見えてきます。

1. 注文はどの形で手元に届くか（画面に表示されるだけか、CSVなどのファイルとして出力できるか、紙やFAXか）
2. 打ち直している先の販売管理などに、外部のデータを取り込む機能があるか（ファイルの取込画面や、システム同士をつなぐ接続口があるか）
3. 注文の入口は取引先ごとに何種類あり、それぞれ月に何件くらいの注文が来ているか

1つ目の答えが「ファイルで出せる」で、2つ目が「取込機能がある」なら、自社の中だけで受注登録の打ち込みを減らせる見込みがあります。
1つ目が「画面表示だけ」や「FAX」なら、データとして受け取る形に変える必要があり、取引先側の入力方法に話が及びます。
3つ目の答えは、どの入口から手を付けるかの順番を決める材料になります。
件数の多い入口から自動化すれば、同じ準備の手間でも打ち直しの減る量が大きくなるからです。

▼ 図の内容を文字で読む

1. 注文の入口
   • 電話・FAX・メールで届く
   • 取引先ごとに入口が違う
   • 項目やコードが社内システムと合わない
2. 受注登録
   • 販売管理へ手で打ち込む
3. 出荷指示
   • 受注登録の誤りがそのまま引き継がれる
4. 請求
   • 受注登録の誤りがそのまま引き継がれる

API連携・ファイル取込・共通EDIの違いと、それぞれが必要とする条件

基幹とつなぐ2つの方法：直接連携と間接連携

注文データを社内システムへ渡す方法は、つなぎ方で二つに分けて考えると分かりやすくなります。
一つは、システム同士をAPI（ソフトウェアどうしがデータをやり取りするための接続口）で直接つなぐ方法です。
もう一つは、CSV（項目をカンマで区切って並べた表形式のファイル）などのファイルを介して、一方が出力したデータをもう一方が取り込む方法です。
日本IBMの共通EDIサービスでも、基幹システムとの連携はAPIによる直接連携か、CSVファイルなどによる間接連携で行えると説明されています²。
これは同サービスの仕様で、ほかの製品がどちらに対応しているかは製品ごとに異なります。
ただ、自社の仕組みを見直すときも「直接つなぐか、ファイルを介すか」の二つで考えると、必要な準備の違いを整理しやすくなります。

API連携では、製品の作りに応じて、注文が入るたびに、または決めた間隔で、Web受発注から販売管理へ受注データが渡ります。
担当者が画面を見て打ち込む作業はなくなります。
一方で、取引先コードや品番を社内のコードに対応させる設定と、受け渡しが止まったときに気付ける仕組みは必要です。
双方のシステムに外部とつなぐ口が用意されていることが前提で、販売管理側に口がなければ、開発や改修の相談になります。

ファイル取込は、Web受発注から注文をファイルとして出力し、販売管理の取込画面で読み込む使い方です。
出力と取込の操作は人が行うため手作業はゼロにはなりません。
それでも、品番・数量・納期を一件ずつ打つ作業は、ファイルを選んで取り込む作業に置き換わります。
最初に、Web受発注の出力項目と販売管理の取込項目の並びや書式を突き合わせる必要があります。
ここが合わないと、取込の前にファイルを手で直すという新しい作業が生まれてしまいます。

取引データを社内の業務システムや会計システムと連携させれば再入力や転記作業の削減につながる、という考え方は、中小企業共通EDIの狙いとしても示されています⁴。
ただし、どのくらい減るかは示されておらず、連携の範囲と例外の多さで変わります。

共通フォーマットに変換するプロバイダー方式

APIもファイル取込も、届いた注文を自社のシステムへどう渡すかという話でした。
これに対して、取引先ごとに形式がばらばらという入口の問題そのものに手を入れるのが、共通の形式へ変換するEDIプロバイダーを使う方式です。
EDI（電子データ交換）とは、企業間で注文などの取引データを決まった形式でやり取りする仕組みを指します。

中小企業共通EDIでは、国連CEFACT（貿易手続きの標準化を進める国連の組織）の共通辞書に準拠して、取引先ごとに異なっていたEDIのデータ形式を共通化しています¹。
受注側と発注側がそれぞれ対応プロバイダーと契約すると、プロバイダーがデータを変換します¹。
相手ごとに形式を合わせる手間を、プロバイダーの変換が肩代わりする形です。
この説明は2018年時点のものです。

2018年時点の標準仕様書では、注文メッセージについて、プロバイダーには全135項目への対応を、販売管理などの業務アプリケーションには最低限必要な13項目への対応を求めていました¹。
標準の形式で注文が届いても、自社の業務アプリケーションがどの項目まで受け取れるかによって、画面で補う情報が残るかどうかが変わります。
普段の受注登録で入力している項目と、使う予定の製品が取り込める項目を並べて見比べると、自動化できる範囲が具体的になります。

比較表：減らせる入力・必要な前提・取引先側の対応

ここまでの三つの方式を、減らせる入力、必要な前提、取引先側の対応という観点で並べると次のようになります。
費用や所要期間は製品と社内システムの条件で大きく変わるため、ここでは比べていません。

表で判断が分かれるのは、取引先側の対応の欄です。
自社が運用するWeb受発注と販売管理をつなぐAPI連携やファイル取込は、取引先の入力方法を変えずに自社の中で進められます。
共通EDIは取引先も対応プロバイダーと契約しなければ使えず、自社の準備だけでは始まりません。
ところが効く範囲を見ると、関係は逆になります。
自社内の連携は自社のWeb受発注に入ってくる注文にしか効かず、取引先指定の画面やFAXから届く注文は対象外です。
多画面の状態に手が届くのは、取引先も含めて形式をそろえる共通EDIの側です。

運用ルール変更でできること

システムの接続を変えなくても、運用の決め方で打ち直しの負担を軽くできる部分があります。
たとえば、FAXや電話で注文してくる取引先のうち、すでに自社のWeb受発注のアカウントを持っている所に入力をお願いする方法があります。
注文書の書式を自社指定のものにそろえてもらう、受注登録を誰がいつ行うかを決めて二重登録を防ぐ、といった整え方もあります。

ただ、運用ルールの変更は、転記そのものをなくすものではありません。
減るのは、入口の数、読み取りにくい注文書を判読する手間、誰が登録したか分からないことによる確認です。
手入力の件数を減らす本筋は前の三つの方式です。
運用ルールはその手前で入口を絞り、連携の効果が出やすい状態を作る役割と考えると位置付けやすくなります。

▼ 図の内容を文字で読む

• API連携
  • 取引先の入力方法は変わらない
  • 効くのは自社のWeb受発注に入る注文
• ファイル取込
  • 取引先の入力方法は変わらない
  • 効くのは自社のWeb受発注に入る注文
  • 出力と取込の操作は人が行う
• 共通EDI
  • 取引先も対応プロバイダーとの契約が必要
  • 形式の違いと複数画面の状態に手が届く

取引先数・注文形式・自社システムの条件で、どこから着手するか

取引先の協力が得にくいとき

手段を選ぶうえで最初の分かれ道になるのは、取引先に入力方法や送り方を変えてもらえるかどうかです。
ミラサポplusの解説は、共通EDIについて「1社だけが導入しても効果を得ることはできません」と述べ、導入の要否は取引先の状況を踏まえて判断し、取引先と共通の認識を持つことが重要だとしています¹。
2021年の報道でも、既存の中小企業共通EDIは取引先も導入しないと運用できない点が課題とされていました³。

このため、取引先の協力を得にくい段階では、自社側で完結する方法から始めるのが筋の通った順序だと考えます。
具体的には、自社のWeb受発注に入ってくる注文を、ファイル取込かAPI連携で販売管理へ渡し、受注登録の打ち込みを先に減らします。
取引先に何も頼まずに進められ、4か所の切れ目のうち、最も影響の大きい受注登録に手が届くからです。
この順序は原典に書かれた方針ではなく、共通EDIの前提条件と自社内の連携方法を照らし合わせて導いた編集部の提案です。

取引先指定のWeb画面から注文を受けている分は、その画面に注文をファイルで出力する機能があるかを見ます。
出力できれば、自社のWeb受発注と同じように取込の対象にできる可能性があります。
ただし画面ごとに出力の形式が違えば、取込の設定も画面の数だけ必要になります。
注文件数の少ない入口まで一度に対応しようとすると設定の手間が先行するため、3つ目の問いで数えた件数の多い入口から順に広げると、手間と効果の釣り合いを取りやすくなります。

取引先が協力してくれるとき

取引先の協力が得られるなら、選択肢は広がります。
FAXや電話で注文している取引先に自社のWeb受発注へ入力してもらえれば、入口が一つにまとまります。
そうなれば、先に作った販売管理への連携が、その取引先の注文にも効くようになります。
取引先自身が別の会社と共通EDIでやり取りしている、あるいは導入を検討しているなら、双方で対応プロバイダーを使う方式も候補に入ります。

共通EDIを使う場合、日本IBMの説明でも、取引先の理解と協力がサービス導入の前提とされています²。
どちらか一方が対応しただけでは注文が標準の形式で届かないため、取引先との話し合いでは、相手にとっての利点まで含めて検討することになります。
協力が得られる取引先から順に標準の方式を足し、得られない取引先は自社側の取込で受けるという二本立てにすれば、取引先の事情に合わせながら打ち直しを減らしていけます。

国のデータ連携基盤をどう見るか

国の動きも、着手の時期を考える材料になります。
2021年の報道によると、中小企業庁は中小企業の電子受発注を進めるためのデータ連携基盤を計画し、2022年中の運用開始を目指していました³。
同じ報道では、電子受発注システムの導入率を当時の約2割から、2023年をめどに約5割へ引き上げる目標が示されています³。

この約5割はあくまで目標で、達成したかどうかや、基盤がその後どの形で提供されているかは、この報道からは分かりません。
計画の行方を待って自社の着手を先送りするより、社内システムに取込の口を整えておくほうが、のちに標準の方式を足す場合の準備にもなります。
中小企業共通EDIについては、ITコーディネータ協会（ITCA）の発表として、2026年10月にウラノス・エコシステムの先導プロジェクトに選定されたことが報じられています⁴。
ITCAは支援人材や関係団体と連携し、普及拡大や業種横断のデータ連携の実証・検討に取り組む方針を示しています⁴。
ただし、これは今後の方針であり、取引先とどう運用するかや導入効果までは示されていません。

▼ 図の内容を文字で読む

• 協力を得にくい取引先
  • 自社のWeb受発注の注文をファイル取込かAPI連携で渡す
  • 取引先には何も頼まずに進める
• 協力が得られる取引先
  • FAXや電話の取引先に自社のWeb受発注へ入力してもらう
  • 双方で対応プロバイダーを使う方式も候補にする
• 取引先指定のWeb画面から受ける分
  • 注文をファイルで出力できるかを確かめる
  • 件数の多い入口から順に広げる

連携しても残る例外(単価・納期変更、欠品、訂正注文)の扱い方

例外を種類別に洗い出す

連携が動き始めても、すべての注文が同じ流れで処理できるわけではありません。
単価の変更、納期の変更、在庫が足りず一部しか出荷できない欠品、数量の修正や取消といった訂正注文は、登録済みの受注を書き換える作業を伴います。
これらが連携の外で電話やメールにより伝えられると、担当者は再び画面を開いて手で直すことになり、例外の分だけ二重入力が戻ってきます。

例外の扱いは製品や取引先との取り決めで変わるため、まず自社の実態を数えることから始めるのがよいと考えます。
直近1か月分の注文から変更や訂正があったものを拾い出し、単価・納期・欠品・訂正の種類ごとに件数を数えます。
あわせて、その変更がWeb受発注上の修正だったのか、電話・メール・FAXだったのかという経路も記録しておくと、次の振り分けに使えます。
これは編集部が提案する手順で、期間は取引量に合わせて調整してください。

連携データで受けるものと担当者が確認するものを分ける

数えた例外は、連携データで受けるものと、担当者が確認してから反映するものに分けます。
取引先が同じ入口で修正を送ることができ、自社のシステムがそれを登録済み受注の変更として取り込めるなら、データで受ける側に置けます。
出荷済みの注文の訂正や、単価の合意が必要な変更のように、反映の前に判断が要るものは、担当者の確認を挟む側に置くのが自然です。

迷いやすいのは、訂正や取消を連携データとして扱えるかどうかが製品によって違う点です。
新規の注文は取り込めても、訂正が別の新しい注文として登録されてしまう作りもあり得ます。
導入前に提供元へ、訂正・取消・欠品の連絡をどう受け渡すかを、自社で数えた例外を具体例にして尋ねておくと判断しやすくなります。
件数の多い例外がデータで受けられないと分かれば、その種類だけは連絡手段を一本に決めて担当者が処理する運用にし、手入力の範囲を限定できます。

取引先に入力方法の変更を頼むとき、何を決めて伝えるか

依頼前に決める項目

取引先に入力方法の変更をお願いするとき、相手が気にするのは、何のための変更で、自分たちの仕事がどう変わるのかという点です。
共通EDIでは取引先と共通の認識を持つことが重要とされ¹、提供元も取引先の理解と協力を前提に挙げています²。
依頼文には、自社の手入力を減らして注文の取り違えを防ぎたいという目的と、相手側で増える作業と減る作業を並べて書くと、相手が判断しやすくなります。

依頼の前に社内で決めておきたいのは次の項目です。

• 対象にする注文の種類：通常の発注だけか、急ぎの注文や訂正も含めるか
• 開始日：いつの注文から新しい方法で受けるか
• 旧方式との並行期間：FAXや電話での注文をいつまで受け付けるか
• 例外時の連絡手段：訂正・欠品・納期変更をどの経路で伝え合うか

このうち並行期間と例外時の連絡手段は、決めずに始めると混乱を招きやすい項目です。
並行期間が曖昧だと、同じ注文がWeb受発注とFAXの両方で届き、二重に受注登録してしまうおそれがあります。
例外の連絡手段が決まっていないと、担当者の確認を挟むと決めた例外がどこから届くのか分からなくなります。
並行期間の長さに決まった目安はないため、取引先の注文頻度を見て、新しい方法で何度か注文を受けられる期間を取るのが一つの考え方です。
これらは編集部の提案で、取引先との関係に合わせて調整してください。

相談できる公的窓口

取引先との調整を自社だけで進めにくいときは、公的な相談先も使えます。
ミラサポplusの解説によると、ITコーディネータ協会が運営事務局を務めるつなぐITコンソーシアムが、無料で相談を受け付け、取引先企業との調整、対応する製品・提供者の紹介、運用までを支援するとされています¹。
この記載は2018年時点のものなので、現在の受付状況や支援の範囲は、相談の前に窓口で確かめてください。

相談するときは、3つの問いへの答え、つまり注文がどの形で届くか、社内システムに取込機能があるか、入口ごとの件数を手元にまとめておくと話が具体的になります。
例外の種類別の件数も添えておけば、どの取引先とどこまでデータでやり取りできそうかを、相談先と同じ材料で検討できます。

二重入力が減ったかを、入力工数・誤入力・手戻りで確かめる

導入前の基準の取り方

連携を入れたあとに「楽になった気がする」で終わらせないためには、導入前に基準となる数字を取っておく必要があります。
公的に定められた測り方はないため、ここで示すのは編集部の提案です。
数えるのは、注文1件あたりの再入力にかかる時間、誤入力の件数、確認のやり直しが発生した件数の三つです。

期間は1週間程度の短い区切りで構いません。
担当者に、受注登録・出荷指示・請求への転記それぞれにかかった時間と処理した注文件数を簡単な表に記録してもらい、合計時間を件数で割って1件あたりの時間を出します。
誤入力は、出荷や請求の段階で見つかった品番・数量・単価の誤りを、どの工程の転記で起きたかとあわせて数えます。
手戻りは、取引先への問い合わせや社内での再確認が必要になった件数です。
月末の締めなど、注文の量や中身が普段と違う週を基準にすると比較がゆがむため、平常の週を選ぶほうが比べやすくなります。

導入後の比べ方

導入後は、連携が安定してから同じ長さの期間で、同じ記録表を使って数えます。
注文件数は週によって変わるので、合計時間ではなく1件あたりの時間で比べます。
入口ごとに分けて集計しておくと、連携した入口では時間が減ったのにFAXの入口は変わっていない、といった違いが見えてきます。

減らなかった項目は、次に手を付ける場所を示しています。
誤入力が減っても手戻りが減らないなら、例外の連絡が連携の外から来ている可能性があり、例外の振り分けを見直す材料になります。
一度の比較で終えず、数える、手を入れる、また数えるという繰り返しで、残った打ち直しを一つずつ減らしていきます。
一般的な削減率と比べるのではなく、自社の基準からの変化で判断するのが、この測り方の要点です。

▼ 図の内容を文字で読む

1. 平常の1週間で基準を数える
   • 1件あたりの再入力時間
   • 誤入力の件数
   • 手戻りの件数
2. 連携や運用を変える
3. 同じ期間と同じ記録表で数え直す
4. 入口ごとに1件あたりで比べる
5. 減らなかった項目を次の対象に決める

注文の届き方と社内システムの取込方法は会社ごとに違い、どの切れ目から手を付けるかは、自社の画面と注文を見ないと決めにくいためです。

今の注文の入口と打ち直している社内システムをもとに、自社側で完結する連携から始められるか、取引先への依頼が要るかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
打ち直しの場所	受注登録・出荷指示・請求・変更の反映のどこで転記しているか
自社内で完結できるか	注文をファイルで出せるか、社内システムに取込機能や接続口があるか
取引先の協力	得にくければ自社側の取込から、得られれば入力先の集約や共通EDIを検討
例外	種類別に数え、データで受けるものと担当者が確認するものに分ける
効果の確かめ方	導入前後の同じ長さの期間で、1件あたりの再入力時間・誤入力・手戻りを比べる

取引先への依頼や例外の扱いは、相手との関係や取引量で決め方が変わり、一般的な考え方だけでは詰めきれないためです。 依頼前に決める項目や並行期間の取り方、導入前後の測り方を、自社の取引先の構成に当てはめて確かめられます。

よくある質問

CSV取込とAPI連携は、どんな場合にどちらを選ぶのか

自社のWeb受発注と販売管理の双方に外部とつなぐ接続口があり、注文が入るたびに自動で渡したいならAPI連携が候補になります。
販売管理に取込画面はあるが接続口がない場合や、まず小さく始めたい場合はCSV取込が候補です。
CSV取込は出力と取込の操作が人に残りますが、項目の対応を決めれば一件ずつ打つ作業を減らせます。
どちらも、出力項目と取込項目の突き合わせが最初の作業になる点は共通です。

取引先が電話・FAXのままのとき、二重入力はどう減らせるのか

FAXや電話で注文を受ける限り、どこかで人が読み取って入力する作業は残ります。
根本的に減らすには、その取引先に自社のWeb受発注へ入力してもらうなど、入口を変えてもらう相談が必要です。
すぐには難しい場合でも、注文書の書式を自社指定のものにそろえてもらえば、読み取りの手間と誤読を減らせます。

中小企業共通EDIは取引先が導入していないと使えないのか

受注側と発注側の双方が対応プロバイダーと契約する仕組みのため、取引先が対応していなければ、その取引先との注文には使えません¹。
ミラサポplusの解説も、1社だけが導入しても効果は得られないとしています¹。
取引先の状況を確かめ、対応できる取引先から使い始めることになります。

訂正注文や欠品が出たとき、連携後も手作業が残るのはなぜか

訂正や欠品は、登録済みの受注を書き換える作業で、新規の注文を取り込むのとは別の扱いが要るからです。
訂正をデータで受け渡せるかは製品によって違い、電話やメールで連絡が来れば、その分は手で直すことになります。
導入前に提供元へ扱い方を尋ね、データで受けられない例外は連絡手段を一本に決めておくと、手入力の範囲を限定できます。

つなぐITコンソーシアムには導入前でも相談できるのか

2018年時点の記載では、無料の相談に加えて、対応する製品・提供者の紹介や取引先企業との調整も支援内容に含まれています¹。
製品選びの段階から相談を受ける内容と読めますが、現在の受付状況や支援の範囲は窓口で確かめてください。

1. 1　出典：ミラサポplus「中小企業共通EDIの解説」（2018年）
2. 2　出典：日本IBM「中小企業共通EDIサービスのご紹介」（2026年閲覧）
3. 3　出典：日刊工業新聞社（ニュースイッチ）「中小企業庁が中小企業の電子受発注実現へ開発する「データ連携基盤」の全容」（2021年）
4. 4　出典：LogiToday「中小企業共通EDIがウラノス・エコシステムの先導プロジェクトに選定」（2026年）