LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

ECサイトでは在庫ありと表示されていたのに、倉庫には一つも残っていなかった。注文の合計金額が、基幹システムに取り込んだあとの売上と合わない——。ECと基幹システムをつなぐ現場では、こうしたずれがよく起こります。EC基幹連携とは、ECサイトやモールで受けた注文、会員、在庫の情報と、販売管理・在庫管理・会計といった基幹システムのデータを、システム連携でやり取りできるようにすることを指します。

連携の処理そのものは、業務委託エンジニアに作ってもらえます。ただ、ずれが起きたときに誰が直すのかを決めずに頼むと、処理は動いているのに数字が合わない状態が続きます。本記事では、EC基幹連携を業務委託エンジニアに頼むマネージャーに向けて、内閣府の「データ連携基盤を通して提供されるデータの品質管理ガイドブック」の考え方を手がかりに、データの持ち主の決め方、変換を任せたときの責任、渡す前に確かめる品質、在庫の鮮度など、頼む前に決めておくことを整理します。

EC基幹連携とは

EC基幹連携でやり取りするデータは、向きが一つではありません。注文の番号や明細、金額はECサイトから基幹システムへ流れます。一方で、在庫数や商品の価格は基幹システムからECサイトへ流れ、出荷の実績や送り状の番号は基幹システムや倉庫の仕組みからECサイトへ戻ります。

こうした連携を整理する手がかりになるのが、内閣府地方創生推進事務局が2023年9月に公表した「データ連携基盤を通して提供されるデータの品質管理ガイドブック」です。スーパーシティやスマートシティのデータ連携基盤を対象に書かれた資料で、データを作って渡す「データ提供者」、データを仲介する「データ連携基盤の整備主体」、受け取って使う「データ利用者」の3者に分けて、それぞれの役割を示しています。^*1

EC基幹連携に当てはめると、受注ならECサイトやモールが提供者で、基幹システムが利用者です。在庫数なら向きが逆になり、基幹システムが提供者になります。業務委託エンジニアに作ってもらうのは、多くの場合その間をつなぐ連携の処理です。自治体向けの資料ですが、誰が何に責任を持つかを分けて考える枠組みとして使えます。

データごとに持ち主を決める

ガイドブックは、提供するデータの品質に責任を負うのはデータ提供者で、サービスの内容に責任を負うのはデータ利用者だと整理しています。^*1 EC基幹連携に置き換えると、データの種類ごとに、どちらのシステムの値を正とするか、つまり持ち主を先に決めておくということです。

ずれが起きやすいのは、両方のシステムで書き換えられるデータです。たとえば価格をECの管理画面でも基幹システムでも変えられる状態にしておくと、どちらの値が新しいのか分からなくなります。片方を持ち主にして、もう片方では読むだけにしておきます。

この表を作るのは頼む側です。どの部署がどの値を管理しているかは業務の決まりなので、業務委託エンジニアには決められません。表があれば、エンジニアは処理の向きと上書きの規則を組めます。

変換を任せると責任も移る

ガイドブックは、データを仲介する主体が、提供者から受け取ったデータを変換や加工したうえで利用者に渡す場合、その主体を「データ提供者として取り扱うことが適切」としています。^*1 EC基幹連携では、ECの商品番号を基幹システムの品番に置き換える、税込みの金額を税抜きに直す、モールごとに違う書式を一つにそろえるといった処理がこれに当たります。変換した部分のずれは、連携の処理の側で見るべき問題になります。

ただし、変換が入ると、どこで値が変わったのかが分かりにくくなります。ガイドブックはその対策として、追跡可能性と原本性の2つを挙げています。追跡可能性については、やり取りされるデータのアクセスログやシステムログを取って保管すること、データに更新の履歴を残すことを例に挙げています。原本性については、提供者が持つデータと受け取った側のデータとで符号（パリティビット）が一致するかを確かめ、改ざんがないかを検証する例を示しています。^*1

実務に置き換えると、受け取った元のデータを手を加えずに残しておくこと、変換の前と後を注文番号で対応づけて記録すること、送った側と受け取った側で件数と合計金額を突き合わせることの3つになります。業務委託エンジニアに頼むときは、連携の処理と一緒にこの3つも作ってもらう範囲に入れておきます。

渡す前に確かめる3つの品質

ガイドブックは、データ品質の国際規格ISO/IEC 25012が定める15の品質特性のうち、正確性・完全性・一貫性の3つを、どの使い方でも一定以上の品質が求められる「基礎的品質特性」としています。それ以外の12は、使い方によって求める水準が変わる「付加的品質特性」です。^*1

ガイドブックは、この3つが確かめられていないデータが渡されると、受け取る側で本来は要らなかったデータの整理や内容の精査が必要になり、苦情などにつながるおそれがあるとしています。^*1 EC基幹連携でいえば、ECの側で確かめずに基幹システムへ流すと、経理や倉庫の担当者が取り込みのたびに手で直すことになります。

業務委託エンジニアには、この3つを取り込みのときに機械で確かめる処理と、はじいた注文を一覧にして担当者に知らせる仕組みを頼みます。どの誤りではじき、どの誤りなら通して後で直すかの線引きは、頼む側が決めます。

在庫は鮮度の約束を決める

在庫のずれは、値が誤っていることより、値が古いことで起こりやすいものです。基幹システムで在庫を引き当ててからECサイトの表示に反映されるまでの間に注文が入ると、在庫のない商品が売れてしまいます。ガイドブックの品質特性では、これは最新性に当たり、更新の期間や最終更新日が示されているかを見るとしています。データの更新頻度を年・月・週・日あたりの回数で書く欄もあります。^*1

デジタル庁が2025年6月20日に公表した「データガバナンス・ガイドライン」も、元のデータが古いと期待した成果が得られないおそれがあるとして、データを生成する主体は「そのデータに必要な精度に合わせた時刻を付す」としています。^*2 在庫数に基幹システムで数えた時刻を付けて送れば、ECサイトの側でどのくらい古い値かを判断できます。

決めておくことは3つです。在庫を何分おきに送るか、注文が入ったときは都度送るか、残りが少ない商品は早めに販売を止めるかです。3つ目は売り逃しとの兼ね合いになるので、業務の側で判断します。ガイドブックも、提示された品質を満たさないデータへの改善要求の例として、5分単位のはずが10分単位のデータしかない場合を挙げています。^*1 鮮度の約束を数字で書いておけば、遅れたときに何が約束と違うのかを具体的に伝えられます。

コードと文字をそろえる

ガイドブックは、複数のデータを統合するときに、データ項目の対応づけ、精度や単位の確認、コードの変換などを正確に行う必要があるとしています。^*1 EC基幹連携では、モールごとの商品番号と基幹システムの品番、配送方法の名前と基幹システムの区分コード、税込みと税抜きの金額がこれに当たります。対応表を誰が持ち、商品を追加したときに誰が更新するかまで決めておかないと、新商品の注文だけが取り込めないことになります。

データを作る段階での工夫も書かれています。選択肢がある項目は自由記述ではなく、コードの入力やプルダウンからの選択にすると誤ったデータが入りにくくなり、コードは独自に作らず既存の体系を使うと他のデータとの連携もしやすくなる、という内容です。^*1 ECの注文画面で配送の希望や支払い方法を自由入力にしていると、基幹システムの区分に置き換えられない注文が残ります。

文字も見落としやすい点です。ガイドブックは付加的品質特性のアクセシビリティとして、環境依存文字などを使っていないことが示されているかを挙げ、データに使っている文字コードを記入する欄も設けています。^*1 住所や氏名に旧字体や機種依存の文字が入っていると、基幹システムの側で文字化けし、送り状を印刷できないことがあります。置き換えられない文字が来たときに処理を止めるのか、置き換えて担当者に知らせるのかを決めて、業務委託エンジニアに伝えます。

顧客データに触れる範囲

ECの受注データには、氏名や住所、電話番号といった個人情報が含まれます。個人情報保護法第25条は「個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。」と定めています。^*3 業務委託エンジニアに本番のデータを使った調査を頼む場合に、どのような監督が要るかは、契約の内容に照らして社内の担当部署や専門家に確かめます。

実務では、作業ごとに触れる範囲を分けておくと決めやすくなります。開発や検証は氏名や住所を別の値に置き換えたデータで行い、本番で件数が合わない原因を調べるときは、社内の担当者が操作する画面を一緒に見てもらう形にする、といった分け方です。どの作業で本番のデータに触れるかを、頼む前に書き出しておきます。

外部に委託するときに確認しておきたい点

業務委託エンジニアに任せやすいのは、取り込み・変換・送信の処理、3つの品質を確かめる検査、ログと突き合わせの仕組み、送れなかったデータを送り直す仕組みです。社内に残すのは、データの持ち主の表、在庫の鮮度の約束、どの誤りではじくかの基準、顧客データの扱いです。ガイドブックは、関係者の間で責任の範囲や免責の事項を合意し、契約や規約で明確に定めることを挙げています。^*1 変換の部分の品質を誰が見るかも、契約の段階で書いておきます。

人を選ぶときは、販売管理や在庫管理のデータの構造を知っているか、モールの受注データを扱ったことがあるかを確かめます。面談では、過去に件数が合わなかったときにどこから原因を探したかを聞いておくと、判断の材料になります。

APIの呼び出し方や返し方の決まりはシステム連携のAPI設計・開発、業務委託エンジニアに渡す決まりで扱っています。

取引先とのEDIの切り替えは業務委託エンジニアに頼むEDI連携にまとめました。

連携の作業量を依頼書にどう書くかは業務委託エンジニアへのシステム連携の依頼書に書く3つの点で整理しています。

まとめ：EC基幹連携で先に決めておきたい3つの点

EC基幹連携を業務委託エンジニアに頼むうえで、先に決めておきたい点は3つに整理できます。第一に、受注・在庫数・商品の情報などデータの種類ごとに、どちらのシステムの値を正とするかを決めること。第二に、連携の処理で変換する部分は作る側が品質を見ることにして、元のデータの保管と件数・金額の突き合わせも一緒に頼むこと。第三に、在庫を送る間隔と、いつ数えた値かを示す時刻を約束として書いておくことです。この3点を踏まえておけば、「処理は動いているのに、どこでずれたのか誰にも分からない」という事態を避けやすくなります。システム連携に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：内閣府地方創生推進事務局「データ連携基盤を通して提供されるデータの品質管理ガイドブック」（2023年9月、PDF）（https://www.chisou.go.jp/tiiki/kokusentoc/supercity/pdf/supercity_230926_guidebook_honsi.pdf）。出典：内閣府地方創生推進事務局。1.2 想定の読者、2.3 3者のステークホルダーの役割、2.4 責任分界点に関する基本的な考え方（追跡可能性・原本性）、3.1.1 データの品質管理規程と規程の浸透、表4-1 データの品質特性と分類、4.1.1(2) 基礎的品質特性の評価、表4-4 メタデータ項目、5.1 改善要求の例、6.1 データ設計、6.4 データ統合を参照（確認日2026年10月7日）（2026年10月確認）
2. *2　参考：デジタル庁「データガバナンス・ガイドライン」（2025年6月20日、PDF）（https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/71bf19c2-f804-488e-ab32-e7a044dcac58/b1757d6f/20250620_news_data-governance-guideline_01.pdf）。出典：デジタル庁。2. データセキュリティの 2-3 望ましい方向性（データの最新性と時刻の付与）を参照（確認日2026年10月7日）（2026年10月確認）
3. *3　参考：e-Gov法令検索「個人情報の保護に関する法律」（平成十五年法律第五十七号）（https://laws.e-gov.go.jp/law/415AC0000000057）。出典：デジタル庁 e-Gov法令検索。第25条（委託先の監督）を参照（確認日2026年10月7日）（2026年10月確認）

Tweet