基幹システム連携で発注側が渡す項目とは？必須・任意の見分け方と連携先ごとの違い

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

B2B EC-COLUMN

基幹システム連携で「渡す項目がわからない」ときの考え方

取引先から「連携用にデータをください」と言われ、自社の基幹システムで発注データの項目一覧を開いたところで手が止まる——欄はどれも社内では意味を持っていますが、そのまま渡してよいのか、足りないものがあるのかは一覧を眺めても決まりません。
渡す項目は、自社の基幹システムが実際に保持している項目と、連携先が求める仕様の、二つが重なったところに決まります。
業界標準の流通BMSは業務ごとにメッセージの構成が定められ、汎用フォーマットの中小企業共通EDIは項目数こそ多いものの最低限必要な項目は少数に絞られるなど、必須項目の固定度は連携先によって違います。
まず相手の仕様と自社が出せる項目を別々に書き出して並べ、ずれた部分を変換で埋めるのか、運用や取り決めで埋めるのかを判断していきます。

渡す項目は、自社だけでは決めきれない

項目の要否が決まらないのは、調べ方が悪いからではありません。
社内では当たり前に使っている欄でも、それを受け取った相手が何の処理に使うのかによって、必要かどうかが変わるからです。
発注データの一覧は自社の業務を映したものであって、相手の処理の都合までは映していません。

渡す項目は、二つの条件が重なったところに決まります。
一つは自社の基幹システムが実際に保持している項目、もう一つは連携先が求める仕様です。
自社に無いデータは渡せませんし、相手が使わない項目は渡しても処理されません。
この重なりがそのまま流せる範囲になり、ずれている部分が設定や運用の作業として残ります。
最初にやるべきことは項目を決めることではなく、この二つを別々に書き出して並べることです。

必須・任意はデータの階層ごとに定められている

もう一つ、先に押さえておくと読み違いが減るのが、発注データが平らな一覧ではないという点です。
家電製品協会のEDI標準化仕様では、受発注データが複数のレベルに分かれて構成され、レベルごとに必須・任意の区分が定められています²。
「発注データの必須項目は何か」という問いは、どのレベルの話なのかを決めないと答えが一つに定まりません。

担当する立場によって、同じ仕様書でも目に留まる箇所が変わります。
購買・調達側は項目の意味、つまりそのコードが何を指すのか、単価は税込か税抜か、数量の単位はケースかバラかを気にします。
情報システム側は形式、つまり桁数やコード体系、ファイルの区切り方を見ます。
仕様書の一つの欄はたいていその両方の情報を含んでいるため、どちらか片方の視点だけで読むと、テストの段階になってから解釈の食い違いが出てきます。

発注側基幹システムから渡す代表的な項目にはどのようなものがあるか

ファイルヘッダー・伝票ヘッダー・明細レコードという3つの階層

家電製品協会のEDI標準化仕様では、受発注データがファイルヘッダー・伝票ヘッダー・明細レコードの3階層で構成され、各項目に必須（○）・任意（△）の区分が定められています²。
階層が分かれているのは、情報の繰り返し方が違うためです。
ファイルヘッダーは送るファイル1本につき一度、伝票ヘッダーは発注伝票1枚につき一度、明細レコードは注文する商品の行数だけ繰り返します。

この分け方は、自社の基幹システムのテーブル構成と照らし合わせるときの手掛かりになります。
発注データを伝票と明細に分けて保持している基幹システムであれば、伝票ヘッダーと明細レコードはおおむね対応づけられます。
一方でファイルヘッダーは、送信という行為に伴って必要になる情報で、基幹システムの業務データとしては存在していないこともあります。
その場合は連携の仕組み側で付与することになり、基幹システムそのものの改修とは別の作業として切り分けられます。

商品コード・数量・発注企業コードなど代表的な項目

明細レコードでは、商品コード・数量・商品コード識別区分が必須項目、商品名や納品単価は任意項目として区分されています²。
商品名が任意なのは、受け取る側が商品コードから自社のマスタで名称を引けるためと読めます。
逆に商品コード識別区分が必須になっているのは、同じ桁数の数字が並んでいても、それがJANコードなのか取引先固有のコードなのかが分からないと、受け取った側が照合先を決められないからです。
必須になりやすいのは、相手がその1行を特定し、自社のデータに結びつけるために欠かせない項目だと整理できます。

どの企業からどの企業への発注かを示すコードは、1行ごとに変わる情報ではないため、明細ではなく上位の階層で持たれます。
伝票ヘッダーには、その伝票を識別し、どの取引の発注かを示す情報が入ります。
そして同じ仕様の中でも、発注Noのように条件によって必須かどうかが変わる項目があります²。
この点は必須・任意の見分け方そのものに関わるので、あらためて後の節で扱います。

なお、ここで挙げた項目名と必須・任意の区分は、家電製品業界向けの標準化仕様のものです²。
別の業界の規格では、項目名も必須・任意の線も同じとは限りません。
ただし、データを階層に分けたうえで階層ごとに必須・任意を定めるという構造の考え方は、ほかの規格の仕様書を読むときの下地になります。
最初に「これはどの階層の項目か」を確かめる癖をつけておくと、項目数が百を超える仕様書でも読み進める順番が決まります。

渡す項目は連携先（業界標準EDI・汎用EDI・個別プラットフォーム）によってどう変わるか

流通BMS：業務ごとに固定されたメッセージ構成

消費財流通業界で使われている流通BMSでは、やり取りが「発注データ」という一つの塊ではなく、業務ごとのメッセージという単位に分かれています。
基本形のVer1.0では、発注、出荷、受領、返品、請求、支払の6業務について8種の標準メッセージが策定されました¹。
発注側が渡す項目を考えるときは、まずどのメッセージを送る立場なのかが先に決まり、そのメッセージの構成に沿って項目が定まります。
個社の都合で項目を足したり省いたりする余地は、この形では大きくありません。

取引先の業態によって、使うメッセージの範囲も変わります。
百貨店業界の取引に必要な標準メッセージ26種が2010年に公開されており¹、基本形の8種だけでは取引が回らない領域があることが分かります。
同じ「流通BMSに対応する」でも、相手がどの業界向けの仕様を使っているかによって、準備すべき範囲は違ってきます。

さらに確認が要るのがバージョンです。
流通BMSの基本形は初版から複数回改定されており、軽減税率に対応したVer2.0など、バージョンごとに仕様が更新されています¹。
税率の扱いのように実際のデータの持ち方に関わる改定が含まれるため、「対応済み」という言葉だけでは足りません。
相手が使っているバージョンまで揃っていないと、項目の並びは合っていても値の解釈がずれます。

中小企業共通EDI：135項目中13項目が最低限必須

業種を限定しない汎用のフォーマットでは、必須の決まり方が違います。
中小企業共通EDIの注文メッセージは全135項目を定めていますが、業務アプリケーションに対応を求める最低限必要な項目は、注文書番号や注文書発行日など13項目に絞られています³。
135という数字は「用意されている箱の総数」、13は「無いとやり取りが成立しない箱」と読むと、両者の関係がつかみやすくなります。

この設計は、自社の基幹システムが保持している項目が少なくても着手できることを意味します。
ただし、必須が少ないことは決めることが少ないことと同じではありません。
最低限の13項目以外のどれを実際に使うかは、取引の実態に合わせて相手と取り決めることになります。
納期を明細ごとに持つのか伝票単位でよいのか、といった話がここで出てきます。

個別プラットフォーム：相手の仕様書が基準になる

取引先やプラットフォームが独自の形式を定めている場合、公開された共通の仕様がないため、判断の基準は相手が出す仕様書だけになります。
困るのは、必須・任意の区分が仕様書に明示されていなかったり、桁や形式がサンプルデータを見ないと読み取れなかったりする場合です。
項目名だけで意味を推測して埋めると、送信自体はエラーにならずに通り、相手側の登録内容がずれていたことが後から分かる、という形で表面化することがあります。

連携先ごとの違いを大づかみに並べると、次のようになります。
・業界標準EDI（流通BMS）：業務ごとにメッセージの構成が決まり、規格とバージョンで使う項目が定まる
・汎用EDI（中小企業共通EDI）：項目は多く用意されるが最低限必要な項目は絞られ、どの任意項目を使うかは取り決め次第
・個別プラットフォーム：共通の標準がないため、相手の仕様書とサンプルデータが基準になる

この三つは優劣ではなく、必須項目の決まり方の固定度が違うだけです。
流通BMSは消費財流通業界向け、中小企業共通EDIは業種を限定しない汎用フォーマットという前提の違いがあり、そもそも対象が重なりません¹³。
発注側として見ておくべきなのは、相手がどの型に当てはまるかで、自社に残る作業が「規格に合わせる」のか「相手と決める」のかに分かれる、という点です。

必須項目と任意項目はどう見分け、不足するとどうなるか

必須の線は、規格だけでなく取引条件でも動く

仕様書の必須・任意の欄は、どんな取引でも同じとは限りません。
家電製品協会の仕様では、伝票ヘッダーの発注Noは伝票単位で発注する場合のみ必須とされており、発注方法によって必須になる項目が変わります²。
つまり、自社が伝票単位で発注しているのか明細単位で発注しているのかを決めないと、同じ仕様書を見ても必須項目の一覧は確定しません。

見分けるときは、項目そのものをにらむより、その項目が相手のどの処理で使われるかを追うほうが早く片づきます。
受注登録で使うのか、納品書の印字に使うのか、請求照合の突き合わせに使うのか。
そのうえで、自社の取引条件でその処理が発生するかを見ます。
発生しない処理のための項目は任意にとどまり、発生する処理の入口になる項目は、表記にかかわらず実質的に必須として扱うことになります。

逆に、任意項目を余さず埋めれば安全というわけでもありません。
送った値は相手の処理に流れ込むため、たとえば任意の納品単価を埋めるなら、その値が自社の発注単価と常に一致している状態を保つ責任が発生します。
使われない項目を埋めるためにマスタを整備しても、確認の手間だけが増えます。
任意項目は「送れるか」ではなく「相手が使うか」で決めるほうが、後の運用が軽くなります。

欠けたときに困るのは、発注の先の業務

項目が足りないことの影響は、発注の場面だけでは終わりません。
流通BMSでは、受領メッセージや出荷梱包（出荷伝票）メッセージはすべて発注メッセージに対応しており、発注メッセージがなければこれらのメッセージは存在しない、という関係になっています⁵。
発注が起点になってその後のやり取りが組み立てられているため、発注の時点で紐づけの鍵になる項目が欠けたり値が揺れたりすると、受領や請求の突き合わせができなくなります。

実務で表面化しやすいのは、送信そのものは成功しているのに後工程で合わない、という形です。
発注番号の採番が伝票ごとではなく送信のたびに変わるような持ち方をしていると、相手から返ってくる受領や請求のデータを、こちらの発注データに結び戻せません。
項目が入っているかどうかだけでなく、一つの取引の間で同じ値が保たれるかまで見ておく必要があります。

そしてこの見分けは、発注側だけで完結しません。
EDIは1社だけが導入しても効果を得ることはできないため、導入を検討する企業だけでなく取引先企業の状況や環境を考慮しながら要否を判断する必要がある、と示されています³。
項目の粒度でも同じことが起きます。
こちらが任意と判断して送らなかった項目が、相手の受注処理では必須になっていた、というずれは、双方の仕様を突き合わせない限り見つかりません。

基幹システムが求められる項目形式に対応していない場合、発注側はどう対処するか

埋まらない理由を3つに分けると、対処が決まる

仕様書と自社データを並べると、埋まらない欄が必ず出てきます。
このとき、埋まらない理由をひとまとめに「対応できない」と扱わず、三つに分けると対処が決まります。
・形式が違う：データは保持しているが、コード体系や桁数、日付の書き方が相手の仕様と異なる
・データが無い：相手が求める情報を、自社の基幹システムがそもそも保持していない
・概念が無い：相手の項目に対応する業務上の区分が、自社の運用に存在しない

一つ目の形式違いは、変換で吸収する範囲です。
データ連携ツールの説明では、取引先コードや商品コードを自社コードへ対応づける変換ルールを取引先ごとに設定として持てるため、取引先の追加や形式変更にも設定の追加・修正で対応できるとされています⁴。
これは特定のツールについての説明ですが、考え方として大事なのは、取引先ごとの違いを基幹システム本体の改造ではなく、その外側の設定として持てる形にしておく点です。
取引先が増えるたびに基幹システムへ分岐を足していくと、後から一社の仕様が変わったときに影響範囲を読み切れなくなります。

ただし、変換で埋められる範囲は、使っている基幹システムや連携の仕組みによって変わります⁴。
また、変換は対応表があって初めて成り立ちます。
商品が追加されたときに対応表の更新が止まれば、変換の処理自体は動いていても、誤ったコードのまま送られます。
変換を入れて減るのは、送信のたびに人が読み替えて入力する手間であって、対応表を最新に保つ作業は運用として残ります。

二つ目の、データそのものが無い場合は、変換では作れません。
マスタに欄を用意するか、発注の入力時に登録する運用を足すかのどちらかになります。
ここで気をつけたいのは、基幹システムにデータが存在することと、それを連携用に取り出せる機能が用意されていることは別だという点です。
画面に表示されている情報でも、外部へ出す形で出力できるとは限らないため、保有の有無と出力の可否は分けて確認します。

三つ目の、概念が無い場合は、システムではなく取り決めの問題です。
相手の区分に自社の運用が対応していないなら、固定値を入れて運用するのか、当面は別の手段で伝えるのかを相手と決めることになります。
この三つのどれなのかを先に判別しておくと、情報システム側で片づく話と、購買側や取引先との合意が要る話を分けて進められます。

連携を始める前に発注側として何を確認・準備すべきか

規格・必須項目・自社データの順に照合する

着手前の確認には順番があります。
先に決まるのは相手側の条件で、そこが動かないと自社側の作業範囲も決まらないためです。

確認するのは、取引先が使う規格とそのバージョン、その規格で必須とされる項目、そして自社の基幹システムがその項目を出せるかどうかの三つです。
バージョンまで聞くのは、同じ規格名でも改定によって仕様が更新されているためです¹。
必須項目は一覧を受け取るだけで終わらせず、自社の発注方法によってどう変わるかまで見ます²。
自社側の照合では、項目の有無に加えて、その値がどの画面やテーブルに入っているかまで書き出しておくと、そのまま変換設定や運用変更の検討に進めます。

このとき手元に用意しておくと話が早いのが、実際の発注データのサンプルです。
項目定義書だけでは、コードの桁が実データで揃っているか、空欄がどれくらい出ているかまでは分かりません。
相手の仕様と並べるのは項目名ではなく実際の値だと考えておくと、テスト段階で見つかるはずのずれを前倒しで拾えます。

相手の準備状況も、自社の作業量を左右する

忘れやすいのが相手側の状況です。
EDIは1社だけが導入しても効果を得ることはできないため、導入を検討する企業だけでなく取引先企業の状況や環境を考慮しながら要否を判断する必要がある、と示されています³。
相手が標準規格をそのまま使えるのか、こちらの形式に合わせてもらえるのか、あるいは双方が変換を持つのかで、自社に残る作業量は変わります。

最後に、決まったことを「自社だけで決められること」と「相手との合意が要ること」に分けておきます。
コード体系の変換方法や出力の作り方は自社側で決められますが、どの任意項目を使うか、発注番号の採番をどう揃えるかは相手と決める話です。
この線引きができていれば、取引先とのやり取りを、答えの出ない相談ではなく確認事項の消し込みとして進められます。

連携先の仕様書は読み解けても、自社の基幹システムがどの項目をどの形式で実際に出せるかは、社内の資料を眺めるだけでは確認しきれないことがあります。

実際の発注データを見ながら、そのまま渡せる項目と、変換や運用の追加が要る項目を切り分けるところからご相談いただけます。無料相談で要件を整理する

要点の整理

軸	基準
渡す項目の決まり方	自社の基幹システムが保持する項目と、連携先が求める仕様の重なりで決まる
必須・任意の読み方	データの階層ごとに区分が定められ、発注方法などの取引条件でも入れ替わる
業界標準EDI（流通BMS）	業務ごとにメッセージ構成が固定。規格名だけでなくバージョンと使用メッセージの範囲まで確認する
汎用EDI（中小企業共通EDI）	全135項目に対し最低限必要な項目は13項目。必須が少ない分、任意項目の取り決めが残る
個別プラットフォーム	共通の標準がないため、相手の仕様書とサンプルデータが判断の基準になる
埋まらない欄の扱い	形式が違う／データが無い／概念が無い、に分けて変換・マスタ整備・取り決めへ振り分ける
着手前の確認	相手の規格とバージョン、必須項目、自社の出力可否に加え、取引先側の対応状況まで見る

必須項目の一覧を埋められても、そこから先の「どこまでを仕組みで吸収し、どこからを取引先と決めるか」は、自社のデータとやり取りの実態を並べないと判断しにくい部分が残ります。 現在の発注データの項目と取引先から示された仕様を突き合わせ、変換で埋まる欄、マスタや入力の整備が要る欄、取引先と取り決める欄に仕分けした状態まで整理できます。

よくある質問

EDI標準に対応していない取引先とは、どのように連携すればよいですか

標準規格に合わせられない相手とは、どの形式で何をやり取りするかを個別に決めることになります。
考え方は標準規格の場合と同じで、相手が注文を特定し商品を照合するために欠かせない情報が先に決まり、こちらの基幹システムからそれを出せるかを照合します。
自社側の出力の形を一つに保ったまま、相手ごとの形式の違いを変換の設定で吸収する方法もあります⁴。
ただしEDIは一方だけが導入しても効果を得にくいとされており³、相手が対応できる範囲を確認しないまま形式だけ決めると、結局どちらかに手作業が残ります。

流通BMSと中小企業共通EDIの両方に対応する必要はありますか

取引先がどちらを使っているかで決まります。
流通BMSは消費財流通業界向けの標準で、業務ごとのメッセージ構成が定められています¹。
中小企業共通EDIは業種を限定しない汎用のフォーマットで、注文メッセージの最低限必要な項目は13項目に絞られています³。
両方の取引先を持つなら双方への対応が必要になりますが、基幹システム側を二重に作り込むという意味ではありません。
自社の出力を一つに保ち、相手ごとの差を外側の変換で吸収できるかを先に検討する余地があります⁴。

基幹システムのマスタコードと取引先コードが異なる場合、どちらに合わせて変換するのが一般的ですか

どちらが一般的と言い切れる基準はありません。
判断材料になるのは、変換の対象がいくつあるかと、どちらが変わりやすいかです。
取引先が複数あるなら、相手ごとに自社コードを作り替えるより、自社コードを基準にして相手ごとの対応表を持つほうが、取引先の追加や形式変更に設定の追加・修正で対応しやすくなります⁴。
一方、相手の規格が業界標準で、そのコード体系が取引先全体で共通しているなら、自社マスタ側にそのコードを併せ持つ選択もあります。
いずれの場合も、対応表を誰がいつ更新するかを決めておかないと、運用の途中で合わなくなります。

個別プラットフォーム独自仕様の場合、必須項目の仕様書はどこで確認できますか

公開された共通仕様がないため、相手が提供する連携仕様書や接続用の資料を取り寄せるところが出発点になります。
仕様書に必須・任意の区分が明記されていないこともあるので、サンプルデータと、テスト環境へ実際に送ったときの挙動をあわせて確認すると、区分の読み違いを見つけやすくなります。
あわせて、項目の意味（どのコード体系を想定しているか、単価は税込か税抜か）を相手の担当に確かめておくと、形式は通るのに登録された中身がずれる、という状態を避けやすくなります。

取引先は流通BMSに対応済みと言っているのに、項目がかみ合わないのはなぜですか

バージョンの違いが原因になっていることがあります。
基本形は初版から複数回改定されており、軽減税率に対応したVer2.0など、バージョンごとに仕様が更新されています¹。
また百貨店業界向けには26種の標準メッセージが公開されており¹、業界向けの仕様を使っているかどうかでも、やり取りするメッセージの範囲が変わります。
規格名だけでなく、バージョンと実際に使うメッセージの範囲まで確認すると、かみ合わない箇所を特定しやすくなります。

1. 1　出典：流通BMS協議会（GS1 Japan）「流通ビジネスメッセージ標準（流通BMS）標準仕様」（2018年）
2. 2　出典：一般財団法人家電製品協会「EDI標準化仕様 第2章 受発注データ」
3. 3　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」
4. 4　出典：アステリア株式会社「EDI連携の方法とは｜基幹システムと自動でつなぐ手順と注意点」（2026年）
5. 5　出典：株式会社アイシーエヌシステム「流通BMSのデータ種類（メッセージ）解説」