基幹システム連携で項目が合わない原因と対処法｜差異の洗い出しから吸収先の決め方まで

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

B2B EC-COLUMN

連携する基幹システム同士で項目が合わないとは何が起きているのか

販売管理から会計へ売上データを渡す連携で、送信側の「取引先コード」を受信側の「得意先コード」に対応させたところまでは進んだのに、桁数が違う、片方では必須なのにもう片方は空でも通る、明細単位と伝票単位で粒度が合わない。
項目定義書を横に並べた時点で、この種の食い違いはほぼ必ず出てきます。
ここで決められるのは、どの差異をどこで吸収するかという設計判断です。
差異は名称・型・必須/任意・コード体系・粒度の五つに分けて整理でき、双方の定義書を突き合わせたマッピング表で洗い出せます。
名称違いは対応付けだけ、粒度や必須/任意の違いは変換ロジックと業務ルールの調整、コード体系の違いは変換テーブルで対処し、その処理を送信側・受信側・連携基盤のどこに置くかを、基盤の有無と改修できる範囲から決めていきます。

基幹システムの連携では、送信側が自システムのテーブルから連携用のデータを切り出して渡し、受信側がそれを自分の項目へ取り込みます。
この二つの作業の間に挟まっているのが、項目の差異です。
販売管理から会計へ売上を渡す、人事給与から会計へ仕訳を渡す、受注から在庫へ引当情報を渡す、どの組み合わせでも、送信側のレイアウトと受信側の受け入れ項目を並べた瞬間に、きれいに一対一で埋まらない行が残ります。

それぞれの基幹システムは、別の時期に、別の業務部門の要件で作られています。
会計側の取引先は支払や請求の相手として登録され、販売管理側の得意先は納品先や与信の単位で登録されている、といった具合です。
自システムの中だけで見れば、どちらの定義も間違っていません。
不整合が表に出るのは、その二つを一本の線でつないだときだけです。

やっかいなのは、食い違いが必ずエラーとして現れるとは限らない点です。
型も桁数も通り、必須チェックも抜けて、値だけが業務上の意味と違うまま登録されることがあります。
送信側の単体テストは仕様どおりのデータが出ていることしか見ませんし、受信側の単体テストは受け入れフォーマットどおりの入力しか流しません。
結合テストや本番の月次締めで数字が合わないところまで来て、ようやく項目の対応付けを疑う、という順番になりがちです。

社内の情報システム部門であれば両側のマスタ定義に手が届きますが、SIer側の担当であれば、見えているのは相手システムの外部仕様書だけということもあります。
見える範囲は違っても、最初にやることは同じで、噛み合っていない箇所を感覚ではなく型で分解することです。
型に分けると、設計者だけで閉じられるものと、業務側の判断を仰がないと決められないものが分かれます。

項目の差異には5つの型がある(名称・型・必須任意・コード体系・粒度)

項目が合わない、とひとことで言っても中身は同じではありません。
設計者が何を決めなければならないかを基準に分けると、名称・型・必須/任意・コード体系・粒度の五つになります。
この分け方が役に立つのは、型ごとに「誰が決めれば終わるか」が違うからです。

名称の違い

同じものを別の名前で呼んでいるだけ、というのが一番軽い差異です。
送信側の「取引先コード」が受信側では「得意先CD」になっている、送信側の「伝票日付」が受信側では「計上日」になっている、といった対応がこれにあたります。
対応関係を一覧に書けば、それで終わります。

注意が要るのはむしろ逆で、同じ名前なのに指しているものが違う場合です。
双方に「単価」という項目があっても、片方が税抜でもう片方が税込かもしれません。
「数量」が受注数なのか出荷数なのか、返品を差し引いた後なのかも、名前だけでは分かりません。
名称が一致していると目視の突き合わせでは素通りしやすく、そのまま値が入って、後から差額として出てきます。

型の違い

桁数、データ型、書式の違いです。
受注番号が送信側では数値、受信側では文字列でゼロ埋め13桁、金額が送信側は小数第二位まで、受信側は整数、日付が8桁の数字と区切り記号入りの文字列、といった食い違いが該当します。

書式を合わせること自体は機械的ですが、情報が落ちる方向の変換だけは業務の判断が要ります。
桁数が足りない側へ渡すとき、あふれた分を切り捨てるのか、エラーにして止めるのかを決めなければなりません。
小数を丸めるなら、切り捨て・切り上げ・四捨五入のどれを選ぶかで合計金額が一円ずれます。
一件では無視できる差でも、明細を集計して伝票金額と照合する処理では、合計が合わない原因になります。

必須・任意の違い

送信側では任意で、受信側では必須という組み合わせが、稼働後に一番よく火を噴きます。
ふだんは埋まっている項目なので、テストデータでも本番の大半のデータでも通ってしまい、たまたま空のレコードが流れた日にだけ落ちるからです。
逆に送信側が必須で受信側が任意なら、データは取り込まれますが、受信側の業務では使われないまま残ります。

必須と任意の線引きは、システムの都合というより、その連携で何を取り決めたかで決まります。
企業間の受発注を標準化した中小企業共通EDI標準仕様書では、注文メッセージとして全135項目が定められる一方で、業務アプリケーション側に対応を求める最低限必要な項目は注文書番号や注文書発行日など13項目とされています¹。
項目として定義されていることと、必ず値が入っていることは別だ、という関係がはっきり出ている例です。
これは企業間の共通仕様として整理された数であり、社内の基幹システム同士の連携で同じ項目数や同じ必須範囲になるという意味ではありません。
それでも、自分たちの連携仕様でも「定義した項目」と「必ず埋まる項目」を別の欄で管理する必要がある点は変わりません。

コード体系の違い

得意先コード、部門コード、商品コード、税区分、単位、支払条件。
コードで持っている項目は、値の体系そのものが違います。
販売管理の得意先コードと会計の取引先コードが別採番になっていれば、桁数や型を合わせても意味は通りません。

体系が違うだけなら対応表で済みますが、一対一で対応しない場合に設計が要ります。
販売管理の複数の得意先が会計では一つの取引先にまとまっている、逆に会計側が支払サイト別に分かれている、といった対応です。
まとめる方向は変換できますが、まとめた後から元のどれだったかは復元できません。
さらに、どちらかにしか存在しない値の扱いも決める必要があります。
新しい得意先が販売管理に登録されたとき、会計側のマスタと対応表が更新されるまでのタイムラグで、連携が止まるのか、対応先が見つからないまま取り込まれるのかが分かれます。

粒度の違い

同じ情報でも、どの単位で持っているかが違う場合です。
送信側は明細単位で持っているが、受信側は伝票単位でしか受け取れない。
送信側は取引ごとに出すが、受信側は日次の集計で受ける。
受注単位と出荷単位、売上単位と入金単位のずれも、同じ種類の差異です。

粗くする方向、つまり集約は計算できますが、集約した時点で落ちた情報は戻りません。
細かくする方向は、按分のルールを決めないと処理そのものが書けません。
伝票単位の値引きを明細に割り付けるなら、金額比で按分するのか数量比なのか、端数はどの行に寄せるのかを決める必要があります。
これはシステム側で勝手に決められる話ではなく、経理や営業の担当者に確認して初めて固まります。

差異を放置すると連携先で何が起きるか

差異が残ったまま連携を動かすと、現れ方は大きく三つに分かれます。
どの程度の頻度で起きるかを示す統計はここでは示せないので、起こり方の仕組みとして整理します。

一つ目はデータの欠落です。
受信側が受け取れない項目を送信側で落としたまま渡している、桁があふれた分を切り捨てている、コード変換で対応先が見つからず空のまま登録している。
どれもエラーにはならず、レコードは正常に取り込まれます。
足りないことに気づくのは、その項目を使う後工程、つまり月次の集計や請求書の出力、部門別の実績まで進んでからになります。

二つ目は二重登録です。
受信側が既存データの更新か新規登録かを判断するキーと、送信側が一意と考えているキーがずれていると起きます。
送信側では伝票番号だけで一意でも、受信側が会社コードと伝票番号の組み合わせで判定していれば、別会社の同じ番号は別レコードとして増えます。
再送やリカバリのときにも同じことが起こり、同じ売上が二回計上されます。

三つ目は処理エラーです。
必須項目が空、型変換に失敗、コードがマスタに存在しない、といった理由で連携が止まります。
止まれば業務は待たされますが、三つの中では一番ましな状態です。
誤った値が静かに積み上がる前に手を打てるからです。
そのため設計の判断としては、黙って欠落させるくらいならエラーで止める、という選び方が有効な場面があります。
どちらにするかは、その項目が後工程の金額や帳票に影響するかどうかで分けると整理しやすくなります。

差異をどう洗い出すか(定義書突合とマッピング表の作成)

差異を型で理解したら、次は自分の連携で実際にどこが食い違っているかを一覧にします。
データマッピングの進め方としては、データソースの特定、データフィールドのマッピング、データ変換ルールの定義という三つの段階で整理されています³。
これは一般的な進め方の整理で、個別の連携基盤に固有の書式を指すものではありませんが、作業の順番を決める土台としては使えます。

最初のデータソースの特定は、どのシステムのどのテーブルやファイルから、どのタイミングで出すかを決める作業です。
ここが曖昧なまま項目の話を始めると、後から「そのデータは受注テーブルではなく出荷テーブルから取る」と分かった時点で、マッピングをやり直すことになります。

次のフィールドのマッピングが中心の作業です。
送信側と受信側それぞれの項目名、データ型、桁数、必須か任意か、コード体系の有無を一つの表に並べます。
ここまでは、双方の項目定義書から転記できます。

ただ、定義書の突き合わせだけでは足りません。
定義上は任意でも実際には常に値が入っている項目、定義上は15桁でも実データは8桁しか使われていない項目、定義書には残っているが運用では使われなくなった項目があります。
各項目のサンプル値と、実データで空欄が出るかどうかを表に足しておくと、机上では見えない差異が浮かびます。
とくに必須/任意の差異は、この実データの確認をしたかどうかで、稼働後に落ちる確率が変わります。

三つ目の変換ルールの定義で、対応付けだけでは埋まらない行に処理を書きます。
この段階になると、変換ルール欄が埋まらない行が必ず残ります。
埋まらない理由は二つで、技術的に決まらないのではなく、業務上どうするかが決まっていないか、相手側の仕様が確認できていないかのどちらかです。
この二つは追いかける相手が違うので、表の中で分けておくと進みやすくなります。

マッピング表は、作った後に読まれる資料でもあります。
稼働後に値がおかしいという問い合わせが来たとき、最初に開くのがこの表です。
誰がその変換ルールを決めたか、いつ決めたかを列に残しておくと、仕様どおりなのか不具合なのかの判断が早くなります。

差異の種類ごとにどう対処するか

洗い出した差異は、型によって解き方の重さが違います。
表の上では同じ一行でも、設計者だけで閉じるものと、業務側に確認しないと閉じないものがあります。

名称違い:単純なマッピング

名前が違うだけの項目は、マッピング表に対応関係を書けば終わります。
変換ロジックも要りません。
作業としては軽いので、ここに時間をかけないこと自体が大事です。

確かめておくのは、先に触れた同名別義のほうです。
対応付けを書く前に、両側の項目定義の説明文、つまり何を表す値でいつ更新されるかまで読み、名前ではなく意味で一致していることを確認します。
金額と数量と日付に関わる項目は、ここで一度立ち止まる価値があります。

粒度・必須任意の違い:変換ロジックと業務ルールの調整

粒度と必須/任意の差異は、プログラムを書く前に決めることがあります。
集約するなら、どのキーでまとめ、まとめた後に何を代表値にするかを決めます。
分割するなら、按分の基準と端数処理を決めます。
受信側で必須なのに送信側で空になりうる項目なら、固定値を入れるのか、送信側の入力を必須に変えるのか、そのレコードは連携対象から外すのかを選びます。

どれも変換処理として実装はできますが、選ぶこと自体はシステムの判断ではありません。
空の得意先コードに「その他」を入れて取り込めば連携は通りますが、その売上は会計側で誰の売上でもなくなります。
連携基盤を使えばデータを変換する機能そのものは用意されています²が、何を埋めるのが業務として正しいかまでは決めてくれません。
ここは業務部門に持って行く論点として切り出し、決まった内容をマッピング表に書き戻すのが現実的です。

送信側の入力を必須に変える案は、連携のためにデータを打つ人の手順が増える選択でもあります。
入力画面を変えるのか、既存データの遡り修正が要るのかまで含めて話すと、業務側も判断しやすくなります。
逆に、固定値で埋める案を選ぶなら、その固定値が入ったレコードを後から抽出できる状態にしておくと、実態が分かったときに直せます。

コード体系の違い:変換テーブル

コード体系の違いは、変換ロジックでは書けません。
「送信側のこの値は受信側のこの値」という対応をデータとして持つ、変換テーブルが必要になります。
プログラムに直接書き込むと、マスタが増えるたびに改修になるので、テーブルとして外に出しておくほうが扱いやすくなります。

変換テーブルを作ると、今度はそのテーブルの運用が仕事として残ります。
新しい得意先や部門が登録されたとき、誰が対応行を追加するのか。
追加が間に合わなかったときに、連携をエラーで止めるのか、暫定コードで取り込んで後から直すのか。
後者を選ぶなら、暫定で取り込んだレコードに印を付けておかないと、直す対象が分からなくなります。

この運用まで決めておくと、稼働後に連携が落ちたと連絡が来たときの切り分けが短くなります。
プログラムの不具合ではなく対応表に行がないだけ、というケースをその場で判別できるからです。

差異を吸収する処理は送信側・受信側・連携基盤のどこで担うべきか

差異ごとの対処が決まったら、その変換処理をどこに置くかが残ります。
選べる場所は、送信側のアプリケーション、受信側のアプリケーション、その間に置く連携基盤の三つです。

EAIのような連携基盤は、各システムから受け取ったデータを変換する機能を持ち、形式やプロトコルの異なるシステム同士をつなげられるようにするものです²。
すでに基盤を導入しているなら、変換を基盤側に集めるのが素直な選択になります。
送信側は自分のフォーマットのまま出し、受信側は自分の受け入れ形式で受ける形にできるので、連携先が増えても各システムの中身を触らずに済みます。
変換の定義が一箇所にまとまるため、値がおかしいときに見る場所も一つになります。

ただし、基盤に集めれば設計が要らなくなるわけではありません。
コード変換テーブルの保守も、按分ルールの変更も、置き場所が基盤に移るだけで仕事としては残ります。
基盤の設定を触れる人が限られていると、業務ルールが変わるたびにそこで待ちが発生することもあります。
基盤を持っていることと、変換の判断が済んでいることは別です。

連携基盤を導入していない場合は、送信側か受信側のどちらかで吸収することになります。
送信側に寄せると、受信側は自分の形式のデータだけを受け取れば済みますが、送信先が増えるほど送信側のプログラムに相手ごとの分岐が溜まります。
受信側に寄せると、送信側は一つの形式で出し続けられますが、受信側が送信元ごとの取り込み処理を抱えます。

どちらに寄せるかは、機能の優劣ではなく条件で決まります。
まず、変換ルールを決める業務知識がどちら側にあるかが手がかりになります。
按分やコード対応を決めるのが受信側の業務部門なら、変換も受信側にあるほうが、ルール変更のときに話が短く済みます。
次に、改修できる範囲です。
パッケージで受信側に手を入れられない、あるいはSIerとして自社の担当範囲が送信側だけ、という制約があれば、置き場所はその時点でほぼ決まります。
最後に相手の数です。
一対一の連携なら送信側に書いても破綻しませんが、同じデータを将来別システムにも渡す見込みがあるなら、送信側に個別変換を積むのは避けたほうが後が楽になります。

もう一つ、差異そのものを減らす道もあります。
コード体系の違いであれば、変換テーブルを持ち続ける代わりに、どちらかのマスタを他方に合わせて統一するという判断です。
マスタの移行と過去データの扱いが伴うので軽い作業ではありませんが、連携先が増えるたびに対応表が増えていく構造からは抜けられます。
連携を作るたびに同じコードの変換を書いている、という心当たりがあるなら、検討に載せる価値があります。

置き場所が決まれば、マッピング表の変換ルール欄はそのまま実装の指示書になります。

差異の型と対処の見当はついても、自分の連携で変換をどこに置くかは、既存システムの改修余地や連携先の増え方といった手元の条件に左右されます。社内だけで条件を並べ切れないときは、同じ設計判断を扱ってきた相手と一度整理すると、抜けている論点が見えます。

現行の項目定義とマッピングの途中経過を見ながら、業務側に確認すべき差異と設計側で閉じられる差異の切り分けを確かめられます。無料相談で要件を整理する

変換処理の置き場所を決める前に確認すること

置き場所の判断が変わる条件ごとに並べたもので、優先順位ではありません

• 変換ルールを決める業務知識が、送信側と受信側のどちらにあるか

• 送信側・受信側それぞれ、自分たちで改修できる範囲はどこまでか

• 同じデータを渡す相手が、今後増える見込みがあるか

• コード変換テーブルを更新する担当と、更新が間に合わなかったときの扱いが決まっているか

• 値が想定と違ったとき、変換前と変換後のデータをどこで確認できるか

• 連携基盤がある場合、その設定を変更できる人が業務ルールの変更に追随できるか

連携基盤を導入していない場合は、上の二つを先に確かめると置き場所が絞れます

要点の整理

軸	基準
差異の型	名称・型・必須/任意・コード体系・粒度のどれかに分けてから対処を決める
設計で閉じるか	名称と型は設計者だけで決まる。必須/任意と粒度は業務側の確認が要る
コード体系	ロジックではなく変換テーブルで持ち、未登録値の扱いと更新担当まで決める
洗い出し	定義書の突合に加え、サンプル値と実データで空欄が出るかを表に足す
吸収先	基盤があれば集約。無ければ業務知識の所在・改修できる範囲・連携先の増え方で選ぶ

稼働後に値の食い違いが出たとき、どの変換が効いたのかを追える状態になっているかどうかで、調査にかかる手間が変わります。 既存の連携で変換ルールがどこに散っているかを洗い出し、テーブル化やパラメータ化で保守が軽くなる箇所を確認できます。

よくある質問

項目のマッピング表は送信側・受信側のどちらが作成すべきか

どちらが作るかより、両側の項目定義が一つの表に載っていることと、変換ルールを誰が決めたかが書かれていることのほうが効きます。
進め方としては、受信側が必要とする項目を起点に枠を作り、送信側が出せる値と条件を埋めていく形が動きやすくなります。
受信側が使わない項目まで議論せずに済むためです。
SIerとして片側だけを担当している場合は、自分の側の項目名・型・桁・必須/任意・サンプル値を先に埋め切って渡すと、相手側の確認作業が具体的になり、戻ってくる回答も曖昧になりにくくなります。

コード体系の変換テーブルは連携先が増えるたびに作り直す必要があるか

作り直す必要はありませんが、放っておくと増え続けます。
自社のコードを軸に置き、相手先ごとの対応値を行として足していける構造にしておけば、連携先が増えたときの作業は行の追加で済みます。
ただし、一対一で対応しない場合や、相手側にしか存在しない値の扱いは相手ごとに事情が違うので、そこだけは個別に決めることになります。
同じコードの対応表を何本も抱える状態が続くようなら、テーブルを増やし続けるか、マスタ側を統一して差異そのものを減らすかを比べる時期だと考えられます。

必須/任意の違いでエラーになった場合、どちら側のシステムで原因調査すべきか

順番としては、まず受信側でどの項目が必須違反になったかを特定し、次に送信側でその項目が空になった条件を追います。
受信側のエラーは何が足りないかしか教えてくれず、なぜ空だったかは送信側のデータの作られ方にあるためです。
そのうえで、空になったのが例外的な入力なのか、その業務パターンでは常に空なのかを見分けます。
前者ならデータの修正で済みますが、後者は変換ルールの決め直し、つまり既定値を置くか送信側で必須にするかの再判断になります。
マッピング表に必須/任意の欄と実データのサンプル値が残っていれば、設計時の想定と実態のどちらがずれていたかもその場で分かります。

EAI/ETLなどの連携基盤を導入していない場合、項目差異の吸収はどう進めればよいか

洗い出しの手順自体は変わりません。
データソースを特定し、項目を突き合わせ、変換ルールを定義するところまでは同じで、違うのは定義したルールの置き場所だけです。
基盤がなければ、送信側か受信側のプログラムに実装することになります。
その際、変換ルールをコードに直書きせず、コードの対応は変換テーブル、按分の基準や既定値はパラメータとして外に出しておくと、業務ルールが変わったときの改修が小さく収まります。
基盤の導入は、連携の本数が増えて同じ変換を複数箇所に書いている状態になってから比べても遅くはありません。

1. 1　出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！（中小企業共通EDI標準仕様書の解説）」（2018年）
2. 2　出典：株式会社データ・アプリケーション「EAIとは？ETLとの違いやツール導入のメリットも解説！」（2024年）
3. 3　出典：INCUDATA「データマッピング表とは？役割・作成方法・活用例をふまえて詳しく解説！」（2024年）