基幹システム連携の項目一覧｜設計手順と注意点

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

B2B EC-COLUMN

基幹システム連携と連携項目の基礎

基幹システム連携とは、販売管理や会計などの基幹業務システムと、BtoB ECサイトとの間でデータをやり取りする仕組みを指します。設計で先に決めるべきものは、つなぐ方式ではなく、どの項目をどちらが持ち、どちらへ渡すのかという項目の一覧です。項目が固まらないまま方式だけを選ぶと、要件定義書が書き上がらず、見積もりの前提も揺れます。項目ごとに決める事柄は、項目名・データ型・桁数・必須か任意か・更新の契機の5つに整理できます。

電話・FAX・メールで受けた注文を担当者が販売管理システムへ打ち直す運用では、同じデータを2回入力することになります。入力の回数が増えるほど、数量や単価の取り違えが混ざり込む余地も広がるでしょう。BtoB ECを導入する目的が転記の削減であれば、削減できる転記の対象を項目の単位で洗い出す作業が出発点になります。ここを飛ばすと、画面はできたのに裏側は手作業のまま、という状態が残ります。

連携項目を先に決める理由は、後戻りの費用が工程の後半ほど跳ね上がるためです。項目の抜けは、結合の段階ではなく運用の開始後に見つかることがあります。そのときの回避策は、担当者が画面から手で補う運用になりがちです。手作業の追加は、導入で削るはずだった作業を別の形で復活させてしまいます。削減の効果を数字で示せなくなる点も、避けたい結末でしょう。

BtoB ECと基幹システムでは、項目ごとに正となる持ち主を1つに定めます。得意先の与信限度や請求の締め日は基幹側が正、注文の入力履歴や見積もりの依頼はEC側が正、といった具合です。両方で更新できる項目を残すと、どちらの値が新しいのかを人が判断する場面が生まれます。正の持ち主を一覧に書き込むだけで、更新の向きと反映の順序が決まっていきます。

項目の粒度は、伝票の見出しと明細行のどちらに属するかまで分けて書きます。受注日や納期は見出し、商品コードや数量は明細行に属します。同じ数量という呼び名でも、受注数量・出荷数量・引当数量は別の項目です。名前が似ている項目を1つにまとめると、出荷の一部だけが完了した取引で値が合わなくなります。呼び名の重なりは、設計の初期に切り分けておくと後の検証が楽になります。

法令や業界の標準が定める項目は、自社の都合で削れません。税に関する公的な案内では、適格請求書へ記載する事項として6項目が挙げられています¹。2025年の同じ案内では、税率ごとに区分した消費税額等の端数処理を、1つの適格請求書につき税率ごとに1回とする扱いも示されています¹。電子取引のデータを保存する場面では、取引年月日・取引金額・取引先という3つの記録項目で検索できる状態が挙げられています²。あわせて挙げられている検索の機能は3つの要件に整理され、そのうち範囲を指定した検索が求められるのは日付と金額の2種類です²。自由に決められる項目と、外から決まっている項目を切り分けることが、要件定義の最初の分岐点になります。

連携項目の全体像とマスタ系・伝票系の分け方

連携項目は、マスタ系と伝票系に大きく分けると整理しやすくなります。マスタ系は得意先・商品・価格のように、あらかじめ登録しておき、変更があったときだけ更新する項目です。伝票系は受注・出荷・在庫のように、取引の発生ごとに増え、状態が移り変わる項目です。さらに請求・入金・与信を精算系として独立させると、締めの周期で動く項目をまとめて扱えます。マスタ系と精算系は基幹からECへ渡す向きが基本で、伝票系は双方向のやり取りになります。

マスタ系の項目は、更新の頻度が低い代わりに、誤った値が広い範囲へ波及します。得意先マスタの請求先を1件取り違えると、その得意先の全注文の請求先が変わってしまいます。全件を毎晩入れ替える全量連携と、変更のあった分だけ送る差分連携のどちらを採るかは、件数と更新の頻度で決めます。差分連携を採る場合は、更新日時の項目と削除の扱いを先に決めておく必要があります。

伝票系の項目には、始まりと終わりのある状態の移り変わりが伴います。受注は登録・確定・引当済み・出荷済み・締め済みと状態を変え、状態ごとに書き換えてよい項目が変わります。出荷の後に単価を変えられる設計にすると、請求と売上が食い違う余地を残します。状態の一覧と、状態ごとの更新可否を項目単位で書き出す作業が、伝票系の設計の中心です。取消や返品のように、状態を戻す動きも同じ表へ書き込んでおきます。

精算系の項目は、締めの周期に合わせて動きます。請求の締め日、支払の条件、与信の限度額は得意先マスタ側に持ちますが、実際の請求額や入金の消込は伝票側で動きます。マスタ側の条件が変わったとき、締め処理の途中の伝票へどう反映するかは、設計で決めておく事柄です。ここを曖昧にすると、月をまたぐ取引で条件の新旧が混ざります。条件の適用期間を項目として持たせる方法が、実務では取り回しやすくなるでしょう。

キー項目は、連携の全体を貫く背骨に当たります。得意先コードと商品コードが両方のシステムで同じ体系であれば、変換の処理は不要です。体系が違う場合は、対応表を持つか、片方のコードをもう片方に項目として保持するかを選びます。対応表を持つ運用では、新しいコードが登録されたときの追加の手順まで決めておきます。追加が漏れると、その得意先や商品の取引だけが連携から落ちます。

商品を識別するコードには、業界で共通の体系も使えます。標準の商品識別コードには13桁と14桁の形式があり、事業者を表すコードは9桁または7桁で構成されます⁴。2026年時点では短縮の形式として8桁の体系も定められており、集合包装向けの14桁は単品の13桁より1桁多い構成です⁴。自社のコードと標準のコードを併記できる項目を用意しておくと、取引先ごとの要求に応じやすくなります。桁数の決め方は後から変えにくいため、区分の設計と同じ段階で確定させておきます。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

業務プロセス別に見る主要な連携項目

業務プロセスごとに見ると、連携項目は得意先マスタ、商品・価格マスタ、受注・出荷・在庫、請求・入金・与信の4つのかたまりに収まります。この順に決めていくと、前のかたまりで確定した項目が次のかたまりのキーになります。得意先が決まらなければ価格が決まらず、価格が決まらなければ受注の金額が決まりません。項目の一覧を作る順序としても、この並びが扱いやすい形です。かたまりごとに担当部門が異なる点も、この分け方が実務に合う理由といえます。

得意先マスタでは、得意先コード、名称、請求先コード、締め日、支払の条件、与信の限度額、配送先が中心の項目になります。BtoB ECでは、ここに購買担当者のログイン用の識別子と権限の区分が加わります。1つの得意先に複数の購買担当者がぶら下がる形が一般的で、担当者ごとに閲覧できる商品や価格が変わる場合もあります。基幹側に担当者の概念がないときは、EC側だけが持つ項目として一覧に明記します。

商品・価格マスタでは、商品コード、品名、規格、入数、単位、標準の単価、税の区分が基本の項目です。BtoB特有の項目として、得意先別の単価、数量帯ごとの単価、適用の開始日と終了日が加わります。価格の項目は行数が膨らみやすく、得意先の数と商品の数の掛け合わせで件数が決まります。全量の連携では時間が足りなくなる場面もあり、差分の設計が効いてきます。単価を持たない商品や、都度見積もりの商品の扱いも、この段階で決めておきます。

受注・出荷・在庫では、見出しと明細行で項目が分かれます。あるERP製品の受注APIの公開仕様を見ると、受注の見出しと明細が別の集合として定義されています⁶。2026年時点で公開されているこの仕様はバージョン2.0として整理され、見出しの側で確かめられる主要な項目は、識別子から税込の合計までの8項目です⁶。見出しには識別子、受注番号、受注日、得意先番号、通貨コード、税抜の合計、税額、税込の合計が並びます。項目にはそれぞれ型が対応づけられ、識別子は一意な文字列、日付は日付型、金額は数値型として扱われます。型の情報を無視して文字列でやり取りすると、桁あふれや丸めの差が後から表面化します。

在庫の項目は、実在庫、引当済み、引当可能の3つを分けて持ちます。EC側に表示するのは引当可能の数量で、実在庫をそのまま出すと二重の受注が発生します。在庫の連携は頻度が高く、全項目を送らずに商品コードと数量だけを短い間隔で更新する設計も採れます。倉庫が複数ある場合は、拠点コードを含めるかどうかで項目の数が変わります。表示のための丸めや、在庫僅少とする閾値をどちら側で判定するかも決めておきます。

請求・入金・与信では、締め処理の結果として作られる項目が中心になります。請求書の番号、請求の対象期間、税率ごとに区分した対価の額、税率ごとの消費税額、入金の消込の状態が並びます。税率ごとの区分は、標準の税率と軽減の税率の2区分で集計する形が公的な案内に示されています¹。2025年の案内では、標準の10%と軽減の8%という2つの税率ごとに、対価の額と消費税額等をそれぞれ区分する扱いが挙げられています¹。EC側で請求書を表示する場合、この区分をそのまま持ち込めるかを早い段階で確かめておきます。

法令と業界標準が定める必須項目

連携項目の中には、自社の判断で削れないものがあります。請求に関する記載事項、電子取引のデータを保存するときの検索の要件、商品を識別するコードの桁数は、外部の定めに沿って設計します。これらは要件定義の交渉の対象にならないため、先に固定してから残りを設計すると手戻りが減ります。個別の適用の可否は税務の専門家に確認する前提で、原典に書かれた範囲を項目の一覧へ写します。どの項目が外から決まっているかに印を付けておくと、後の議論が短くなります。

税に関する公的な案内では、適格請求書に記載する事項として6項目が挙げられています¹。内訳は、交付する事業者の名称と登録番号、取引の年月日、取引の内容です。続いて、税率ごとに区分して合計した対価の額と適用した税率、税率ごとに区分した消費税額等、交付を受ける事業者の名称が並びます。6項目のうち税率に関わるものは2項目で、対価の額と消費税額等をそれぞれ税率ごとに分けます。2025年の案内では、小売業などが交付できる簡易な様式について記載事項が5項目とされ、交付を受ける事業者の名称の1項目が不要になる扱いが示されています¹。軽減の税率が対象になる取引では、その旨を取引の内容に含める扱いが示されています。項目の数を自社の都合で丸めず、原典の列挙のまま一覧へ写します。

登録番号は、EC側の得意先マスタにも保持するかどうかが論点になります。登録番号は、2025年の案内が挙げる6項目のうちの1項目として位置づけられています¹。請求書を発行するのが基幹側であれば、EC側は表示のために持つだけで足りる場合もあります。EC側で請求書の控えを閲覧させるなら、登録番号と税率ごとの金額を項目として受け取る設計が要ります。どちらの設計でも、税率の区分は10%と8%の2区分で集計できる形にしておきます。

電子取引のデータを保存する場面では、検索の機能が求められます。通達の解説では、取引年月日その他の日付、取引金額、取引先という記録項目で検索できることが挙げられています²。あわせて、日付または金額の範囲を指定した検索と、2以上の任意の記録項目を組み合わせた検索も挙げられています。2026年時点で挙げられている検索の要件は3つに整理され、範囲を指定できることが求められる項目は日付と金額の2種類です²。EC側に注文の履歴を残す場合、この3つの記録項目を検索の条件として持てるかを確かめておきます。

商品を識別するコードには、業界で共通に使える体系があります。標準の商品識別コードは13桁と14桁の形式を持ち、事業者を表すコードは9桁または7桁で構成されます⁴。13桁の内訳は、事業者を表す9桁のコードに商品を表す3桁と検査用の1桁を続けた形で、事業者のコードが7桁の体系では商品を表す部分が5桁になります⁴。集合包装の単位に14桁の形式を使う運用では、単品の13桁とあわせて両方を項目として保持する場面が出てきます。桁数を固定長で扱う設計では、前に付く0が落ちない型を選びます。数値型で受け取ると先頭の0が消えるため、文字列型で持つ設計が無難でしょう。

取引先との間で使うメッセージにも、標準の仕様が整備されています。流通の分野で整備された標準の仕様は、2018年に基本形の2.0版が公開されています³。2018年に公開された基本形の2.0版は、2026年度の時点でも参照される標準で、公開から8年が経過しています³。標準に沿ったメッセージを使う場合、項目名や桁数は標準の側で決まっており、自社の項目をそこへ合わせる作業が発生します。標準に無い項目を自社で追加したいときの扱いも、取引先との取り決めの対象になります。

連携方式による項目設計の違い

連携の方式が変わると、同じ項目でも定義の書き方が変わります。ファイル連携では桁数と並び順が定義の中心になり、API連携では項目名とデータ型が中心になります。EDI・ミドルウェアを挟む場合は、双方の定義に加えて変換の規則が第三の定義として増えます。方式を先に決めてから項目を書くのではなく、項目の性質から方式を選ぶ順序が扱いやすい形です。1つの案件で3つの方式が混在する場面もあり、方式ごとに定義書を分けて持ちます。

ファイル連携では、区切り文字を使う形式と固定長の形式で設計が分かれます。固定長では項目ごとに桁数を決め、足りない分を空白や0で埋める規則まで書き込みます。標準の商品識別コードを固定長で持つ場合は、13桁と14桁のどちらへそろえるかで1桁分の差が生じます⁴。文字コードの選び方で1文字が占める長さが変わるため、桁数の定義は文字数と長さのどちらで数えるかを明示します。全角の文字が混ざる項目では、この取り違えが桁あふれの原因になります。改行の扱いと、項目の中に区切り文字が現れた場合の逃がし方も決めておきます。

API連携では、項目名とデータ型が仕様書の中心に置かれます。あるERP製品の受注APIの公開仕様では、識別子、受注番号、受注日、得意先番号、通貨コード、金額の各項目に型が対応づけられています⁶。2026年時点のこの公開仕様はバージョン2.0として提供され、金額の項目は税抜の合計・税額・税込の合計の3つに分かれています⁶。値が無い状態を空文字で表すのか、値なしとして表すのかは、型の定義に沿って決めます。桁数の上限は型の定義に含まれない場合があり、受け側の項目の長さと突き合わせる作業が別に要ります。

EDI・ミドルウェアを挟む設計では、変換の規則そのものが管理の対象になります。標準のメッセージに合わせる場合、自社の項目名と標準の項目名の対応表が必要です³。対応表の相手側となるのは、2018年に基本形の2.0版が公開された標準の仕様です³。コードの読み替え、単位の換算、日付の書式の変換は、規則として1か所にまとめておきます。変換の規則を個々のプログラムへ散らすと、改定のたびに探し回る作業が発生します。取引先ごとに規則が枝分かれする点も、早い段階で見込んでおきます。

どの方式でも、送り直したときの扱いを項目の設計に織り込みます。同じ受注を2回受け取ったときに重複を作らないためには、送り側で採番した一意の番号を項目として持たせます。エラーの内容を返す項目も、方式を問わず用意しておきたいところです。エラーの理由が項目の単位まで分かる形であれば、原因の切り分けが早く済みます。再送の履歴を残す項目があると、締めの後の調査でも役に立つでしょう。

方式の選択は、項目の数と更新の頻度から逆算できます。件数が多く1日1回で足りるマスタ系はファイル連携、即時性が要る在庫はAPI連携、取引先との取り決めがある伝票はEDIという分け方が1つの目安です。同じ案件でも項目のかたまりごとに方式が変わるため、一覧には方式の列を設けます。方式の列があると、後から追加する項目をどこへ載せるかも判断しやすくなります。

連携項目の設計手順とチェック観点

連携項目の設計は、項目の棚卸し、項目マッピング表の作成、検証と突合という三段階で進みます。棚卸しでは現行帳票と画面項目から使われている項目を集め、項目マッピング表ではデータ型と桁数、変換規則を決めます。検証と突合では、件数の突合と例外取引の確認まで進めて初めて完了と見なせます。前の段階の結果が次の段階の入力になるため、順序を入れ替えると戻り作業が増えます。

項目の棚卸しは、現行帳票を並べるところから始めます。注文書、注文請書、納品書、請求書、出荷指示書に印字されている項目を1つずつ書き出します。次に画面項目を確認し、帳票には出ないが入力されている項目を拾います。表計算で管理している台帳や、担当者が個人で持っているメモの項目も、この段階で表に載せます。帳票と画面の両方から集めておくと、後の工程で見つかる抜けが減ります。

項目マッピング表は、1行1項目で作ります。列には、業務の区分、EC側の項目名、基幹側の項目名、データ型と桁数、必須か任意か、変換規則、更新の契機の7つを置きます。片側にしか存在しない項目は、空欄のまま残さず、既定値を入れるのか受け取らないのかを書き込みます。この表がそのまま検証の観点の一覧になるため、後の工程の作業量を左右します。

変換規則の欄には、コードの読み替えと書式の変換をまとめて書きます。日付を8桁の数字で持つ側と、区切り記号付きで持つ側があれば、どちらに合わせるかを決めます。数量の単位が箱と本で異なる場合は、入数を使った換算の式まで書き込みます。式が複数の項目にまたがるときは、計算に使う項目を明記しておくと実装の解釈が割れません。丸めの方向と小数の桁数も、金額に関わる項目では欠かせません。

検証と突合では、本番に近い件数のデータで結果を比べます。件数の突合では、送った件数と受け取った件数、登録された件数の3つを並べて確かめます。金額の合計を突き合わせると、丸めや税の計算の差が数字として現れます。2025年の案内が示す10%と8%という2つの税率ごとに合計を分けて比べると、差の出た区分を絞り込めます¹。差が出た項目だけを追いかければよいため、全件を目で見る作業を避けられます。例外取引の確認は、正常な取引が通ったあとに別の回として組みます。

この一連の作業には、業務の知識と技術の知識の両方が要ります。帳票と業務の流れを読み解く力、データ型と文字コードを扱う力、取引先との取り決めを整理する力が同時に求められます。デジタル化の取り組みを毎年調べた公的な調査でも、社内のデータ利活用と人材の確保は継続的な論点として扱われています⁵。この調査は1年ごとに更新され、2025年の版までが公開されています⁵。社内の担当者が通常の業務と兼務する体制では、棚卸しの段階で止まりやすくなります。外部へ委ねる範囲を決めるときは、項目の判断は自社、変換と実装は外部という分け方が1つの目安になるでしょう。

連携項目でつまずきやすい点と回避策

連携項目でつまずく箇所は、桁数と文字種の不一致、コードの重複と改番、更新のタイミングの漏れ、例外取引の扱いの4つに集まります。いずれも設計の段階では見えにくく、本番に近いデータを流した段階で表面化します。回避の道筋は、不一致の検出、変換規則の追加、再連携と再突合という順序で進めることです。原因を1つずつ消してから次へ進むと、直したはずの箇所が戻る事態を避けられます。

桁数の不一致は、名称や住所のような長さの決まらない項目で起きます。基幹側の桁数がEC側より短ければ、EC側で入力された値が切り詰められます。切り詰めは処理としては成功するため、エラーの一覧には現れません。商品識別コードのように長さが外から決まる項目では、13桁と14桁の2つの形式のどちらを上限とするかを先に決めます⁴。全角と半角、機種依存の文字、外字の扱いも同じ性質を持ち、文字が別の記号に変わったまま流れていきます。取り込みの結果を桁数の上限で絞り込むと、切り詰めの発生を後から見つけられます。

コードの重複は、得意先の統廃合や商品の後継品への切り替えで起きます。旧のコードと新のコードが並存する期間には、同じ相手や同じ商品が2つの姿で存在します。EC側の注文履歴が旧のコードのまま残ると、集計の結果が2つに割れます。標準の体系を併記する運用では、単品の13桁と集合包装の14桁のどちらで登録したかも履歴へ残します⁴。改番の履歴を保持する項目を用意し、旧と新の対応を残す設計にしておくと、後からの名寄せが可能になります。使い終わったコードを再利用する運用は、履歴の追跡を難しくします。

更新のタイミングの設計漏れは、価格と在庫で目立ちます。価格の適用期間が変わったとき、締めの途中にある受注へ新旧のどちらを当てるかを決めておきます。決めていないと、担当者の判断に委ねられます。差分連携では、更新の判定に使う日時の項目が更新されない経路が残っていないかを確かめます。削除された行を送らない設計では、消えたはずの得意先や商品がEC側に残り続けます。

例外取引と手修正のデータは、項目の設計から漏れやすい領域です。返品、値引、直送、代金引換、分割の納品は、通常の受注と項目の構成が異なります。値引や返品を伝票として残す場合も、税率ごとに区分した対価の額と消費税額等の2項目は、2025年の案内が挙げる6項目に含まれる事柄として扱われます¹。基幹側で担当者が直接書き換えた伝票が、EC側の履歴と食い違う場面も生じます。例外の種類を一覧にし、それぞれについて連携の対象とするかどうかを決めておくと、運用の開始後の判断が早くなります。

不一致の検出は、道具の力を借りると短く済みます。両側の件数と合計、項目ごとの最大長、コードの一致率を並べる仕組みを作ると、目で追う作業が減ります。電子取引のデータを残す側では、3つの記録項目と、日付と金額の2種類による範囲の指定を検証の観点に加えておきます²。変換規則の追加を1か所へ集め、再連携と再突合を同じ条件で繰り返せる状態にしておくと、改修のたびの確認が軽くなります。自社で抱える範囲と外部へ委ねる範囲は、この検証の仕組みまで含めて決めておきたいところです。

よくある質問

連携項目の一覧は、どの段階までに固めておくとよいですか

ベンダーへ見積もりを依頼する前に、項目名と正の持ち主までを固めておくと精度が上がります。データ型と桁数、変換規則は要件定義の中で詰めても間に合いますが、項目の数と区分が動くと工数の前提が変わります。区分ごとの件数と更新の頻度を添えると、方式の提案も具体的になります。

マスタの連携は全量と差分のどちらを選ぶとよいですか

件数、更新の頻度、連携に使える時間帯の3点で決まります。件数が少なく夜間に余裕があれば全量が扱いやすく、削除の反映も自然に済みます。件数が膨らむ価格のような項目では差分が現実的ですが、更新日時の項目と削除の記録を持つ設計が前提になります。両方を併用し、週に1回だけ全量で突き合わせる運用も採れます。

取引先ごとに項目の要求が違う場合、どう受け止めればよいですか

自社の標準の項目一覧を1つ持ち、取引先ごとの差は変換の層で吸収する形が扱いやすくなります。標準のメッセージを使う場面では、項目名や桁数が標準の側で決まっており、自社の項目をそこへ対応づけます³。取引先ごとに本体の項目を増やすと、改定のたびに全体へ影響が及びます。

税に関わる項目は、EC側にどこまで持たせるとよいですか

請求書の発行を基幹側で完結させるなら、EC側は表示に要る項目だけで足りる場合もあります。EC側で控えを閲覧させるなら、登録番号、税率ごとに区分した対価の額、税率ごとの消費税額を受け取る設計が要ります¹。個別の適用の可否は税務の専門家に確認する前提で進めてください。

連携項目の設計を外部へ委ねる場合、自社に残す判断は何ですか

項目の正の持ち主と、例外取引を連携の対象にするかどうかの判断は自社に残します。この2点は業務の取り決めそのもので、外部からは決められません。変換の実装、桁数と文字コードの調整、検証の仕組みづくりは外部へ委ねやすい範囲です。役割の線を項目マッピング表の列として明示しておくと、後の議論が短くなります。

1. 1　出典：国税庁「タックスアンサー No.6625 適格請求書等の記載事項」（2025）　経路
2. 2　出典：国税庁「電子帳簿保存法取扱通達解説（趣旨説明）Ⅱ 適用要件【検索機能の確保】」　経路
3. 3　出典：一般財団法人流通システム開発センター／流通BMS協議会「流通BMS標準仕様」（2018）　経路
4. 4　出典：一般財団法人流通システム開発センター「GTINとは（GTIN 商品識別コード）」　経路
5. 5　出典：独立行政法人情報処理推進機構「DX動向2025」（2025）　経路
6. 6　出典：Microsoft「Dynamics 365 Business Central API リファレンス salesOrder resource type」（2026）　経路