◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 取り込めないのか、取り込めても数字が合わないのかを入口に、弾かれた行と元伝票を照合して形式差と意味差を切り分ける
- 形式差は対応表の変換ルールと例外で機械的に吸収し、意味差は変換を書く前に業務側で定義を合意する
- 互いにデータを渡し合うシステムが増えるほど共通形式が有利になるが、拠点が本社にだけ送る構成にはその数え方がそのまま当てはまらない
- 拠点側を触れない場合は、受け側で拠点を判別し、拠点ごとの変換で共通の形式にそろえる構成がとれる
- 対応表の持ち主と版管理、変換できないデータの隔離と発生箇所の記録、再処理時の二重取り込みの防止を運用で決めておく
目次
拠点Aのデータが取り込めない・数字が合わないときは、形式差と意味差のどちらかを切り分ける
拠点Aから届いた出荷データが本社の基幹システムに取り込めない。
取り込めても、拠点の報告と本社の集計が合わない。
基幹システム連携でこうした項目差異が出たら、まず日付・桁・コード値の書き方が違う「形式差」か、単位・粒度・計上の時点が違う「意味差」かに分けると、手の付け方が決まります。
形式差は、項目対応表に変換ルールを書けば機械的に吸収できます。
意味差は、変換を書く前に業務側で定義をそろえる必要があります。
変換の置き場所は、データを渡し合うシステムの数と拠点側を改修できるかで選びます。
最後に、対応表の持ち主と、変換に失敗したデータの再処理手順まで決めておきます。
取り込めない場合と、取り込めても合わない場合の見分け方
本社で拠点のデータを受け取ったときの困りごとは、たいてい二つの形で現れます。
一つは、取り込み処理そのものが止まる場合です。
桁があふれた、日付として読めない、必須の項目が空になっている、本社のマスタに無いコードが来た、といった理由で、本社側の受け口がその行を読めずに弾きます。
どのファイルのどの行・どの項目で止まったかがエラーとして残るので、手掛かりは比較的はっきりしています。
もう一つは、取り込みは通るのに、拠点が報告してきた数字と本社の集計が合わない場合です。
受け口から見れば正しい形のデータなので、エラーは出ません。
月次の集計表を拠点の帳票と突き合わせた段階で、初めて差に気づくことになります。
この場合は、拠点と本社で同じ名前の項目に違う意味の数を入れている可能性を疑います。
前者は形式の違い、後者は意味の違いから起きることが多いものの、症状だけで原因は決まりません。
たとえば本社のマスタに無い品目コードが届いてエラーになったとき、桁の付け方が違うだけなら形式の問題です。
しかし、拠点Aが本社より粗い単位で品目を管理していて、本社には存在しないまとめ方のコードを送っているのなら、問題は意味の側にあります。
症状は入口の目安にとどめ、実際に弾かれた行と拠点側の元の伝票を並べて、何がどう違うのかを確かめてから分類します。
こうした違いが生まれること自体は、珍しいことではありません。
企業内の連携の設計パターンをまとめた Enterprise Integration Patterns（以下EIP）は、アプリケーションごとに独自のデータモデルがあることを前提にし、同じ顧客でも会計システムと顧客管理システムでは持つ属性が異なる例を挙げています2。
そのうえで、形式の違うシステム同士は、間に形式を変換する部品（Translator）を置いてつなぐと説明しています2。
拠点ごとに別の基幹システムや別のバージョンを使っていれば、同じ「出荷」や「得意先」でも項目の持ち方がずれるのは自然なことです。
問題は違いがあることより、その違いをどこで、どの規則で埋めるかが決まっていないことにあります。
形式差（桁数・日付形式・文字コード・コード値）
形式差とは、指している事柄は同じで、書き方だけが違う状態です。
拠点Aと本社の間で起きやすいものを、仮の例で挙げます。
- 桁数：拠点Aの品目コードは本社より短く、頭を0で埋めないと本社のコードと一致しない
- 日付形式：拠点Aは「YYYY/MM/DD」、本社は区切りなしの「YYYYMMDD」で受け取る
- 文字コード：拠点AのCSVはShift_JIS、本社の受け口はUTF-8を前提にしている
- コード値：得意先区分を、拠点Aは英字、本社は数字で表している
- 項目の並びや名前：同じ数量が、拠点Aでは「出荷数」、本社では「数量」という名前で別の位置にある
コード値の違いについては、データ管理製品のドキュメントに分かりやすい例があります。
Collibra の解説では、顧客管理システムが国を英字2文字、基幹システム（ERP）が英字3文字のコードで表している場合に、同じ国を指す値どうしをクロスウォーク（コード値の対応表）で結び付けます6。
さらに、顧客管理システム側が値の頭に「CC-」を付けるといった例外も、対応表に書き残せるとしています6。
特定製品の画面操作に沿った説明ですが、同じ情報に別の値が付いている状態をどう記録するかという考え方は、拠点間の連携にもそのまま使えます。
形式差に共通するのは、拠点Aのある値が本社のどの値に当たるかが一意に決まり、規則として書き下せることです。
規則が書ければ、あとは変換処理がその通りに値を書き換えるだけなので、人が毎回判断する必要はありません。
次の節で作る対応表は、主にこの規則を一行ずつ残すためのものです。
意味差（コードの粒度・単位・計上タイミング）は定義合意が先
意味差は、項目名も形式もそろっているように見えるのに、中身の定義が違う状態です。
ここで挙げる三つは、拠点間の連携で問題になりやすい違いを本記事で整理したもので、いずれも仮の例です。
- コードの粒度：拠点Aは部材を一つのコードでまとめて管理し、本社は色やサイズごとに別のコードを持っている
- 単位：拠点Aはケース単位で出荷数を記録し、本社は個数で集計している
- 計上のタイミング：拠点Aは出荷した時点で売上に計上し、本社は得意先の検収を受けた時点で計上している
これらが変換だけでは解けないのは、変換の規則を書く時点で業務上の判断が要るからです。
拠点Aの部材コード一つを、本社の色別コードのどれに振り分けるのかは、データのどこにも書かれていません。
ケースを個数に直すには入数が必要ですが、入数が品目ごと・時期ごとに変わるなら、どの入数を使うかを誰かが決めなければなりません。
出荷基準と検収基準の違いは、月末をまたぐ取引があればその月の数字のずれとして現れますが、どちらにそろえるかは会計の方針の問題です。
ここで連携の担当者が「とりあえずこう変換しておく」と規則を書いてしまうと、業務の定義を担当者が黙って決めたことになります。
数字がずれたときに、それが変換の誤りなのか、定義の選び方の結果なのかを、後から誰も説明できなくなります。
意味差が見つかったら、変換を書く前に、拠点Aと本社の業務担当が定義をそろえるか、少なくともどちらの定義で集計するかを決めます。
その決定を規則として対応表に書き込む、という順にしておけば、規則の背後にある判断を後からたどれます。
▼ 図の内容を文字で読む
- 取り込みエラーが出る
- 主な原因は形式差（桁・日付形式・文字コード）
- マスタに無いコードは、粒度の違い（意味差）から来ることもある
- 取り込めるが数字が合わない
- 主な原因は意味差（単位・粒度・計上の時点）
- エラーが出ないため、集計の突き合わせで初めて気づく
- 形式差
- 対応表に変換ルールと例外を書けば機械的に吸収できる
- 意味差
- 変換を書く前に業務側で定義を合意する
- 合意した結果を対応表の規則にする
項目対応表（マッピング）に書く内容と作る順序
1行に書く項目（項目・型・桁・必須・変換ルール・例外）
前の節で切り分けた違いを、一つずつ記録していくのが項目対応表（マッピング表）です。
拠点Aが送ってくる項目と本社が受け取る項目を一行で対にし、その行に変換の規則と理由を残します。
列の構成に決まった形はありませんが、後から差異の理由をたどれるようにするには、次の列を持たせることを提案します。
- 送り側（拠点A）の項目名と、受け側（本社）の項目名
- 型と桁（文字か数値か、何桁までか）
- 必須かどうか（拠点A側で空になりうるか）
- 差異の種類（形式差・意味差・違いなし）
- 変換ルール（どう書き換えるか）
- 例外（規則に当てはまらない値と、その扱い）
- 確認者と、意味差の場合は合意した相手
差異の種類の列を置くのは、意味差の行を後から見分けられるようにするためです。
形式差の行は、規則が正しければ動き続けます。
意味差の行は、業務の定義が変われば規則も変わります。
拠点Aが計上基準を見直したとき、どの行を見直せばよいかを、この列から探せます。
確認者の欄も同じ理由で、規則の背後にある判断を誰に聞けばよいかを残しておくためのものです。
Collibra の解説でも、コード値の対応ごとに変換ロジックの説明を書ける欄が用意されています6。
同じ製品を使う必要はありませんが、値の対応だけでなく、なぜその対応なのかを同じ場所に残すという考え方は、表計算ソフトで対応表を作る場合にも取り入れられます。
コード値の対応と例外の書き方
項目の対応表とは別に、コード値を持つ項目ごとに、値どうしの対応表を作ります。
得意先区分や品目コードのように取りうる値が多い項目を、項目対応表の一つのセルに書き込むと、後で読めなくなるからです。
作る順序は、Collibra のクロスウォーク作成の手順が参考になります。
同製品では、対応させる二つのコード一覧をそれぞれ取り込み、クロスウォークを作成し、どちらが送り側（source）でどちらが受け側（target）かを関連づけてから、値ごとの対応を付けていきます6。
これは同製品の画面上の手順ですが、拠点Aの値の一覧と本社の値の一覧を先にそろえ、向きを決めてから一つずつ対にするという順序は、どの道具で作る場合にも当てはまります。
一覧を先にそろえておけば、どちらか一方にしか無い値が、対応付けの途中で浮かび上がります。
その「片方にしか無い値」と、規則に当てはまらない値が、例外として書き残すべきものです。
書き方で迷いやすいのは、次のような場合です。
- 拠点Aの一つの値が、本社の複数の値に当たる：前の節の意味差にあたるため、業務側で決めた振り分けの規則か、本社側で粗い分類にまとめて受ける方針を書く
- 拠点Aの複数の値が、本社の一つの値にまとまる：変換はできるが、本社側で元の区別が消えることを書き添える
- 拠点Aにしかない値：エラーにして止めるのか、既定の値に置き換えるのかを決めて書く
- 特定の値にだけ付く接頭辞や旧コード：「CC-」の例のように、どの値にどんな加工が要るかを書く
このうち、拠点Aにしかない値を既定の値で受ける運用には注意が要ります。
取り込みは止まらなくなりますが、本来は振り分けを決めるべき意味差が「その他」の中に埋もれ、集計が合わない原因を後から追えなくなります。
どちらを選ぶにしても、選んだ理由を例外の欄に残しておくと、数字が合わなくなったときにその行へたどり着けます。
サンプルデータでの検証
対応表ができたら、拠点Aの実データで試します。
架空のテストデータには、規則を書いた人が想定した値しか入っていないので、想定外の値や例外が見つかりにくいからです。
月末の締めや返品、訂正伝票のように、通常の取引とは項目の埋まり方が違う伝票が含まれる期間を選ぶと、例外が表に出やすくなります。
確かめることは二つです。
まず、すべての行が本社の受け口で弾かれずに取り込めるか。
次に、取り込んだ結果を本社で集計し、拠点Aの帳票と同じ数字になるか。
前者で弾かれた行は形式差の規則の漏れ、後者の不一致は意味差の見落としを疑う、という前の節の見分け方がここでも使えます。
原因が分かったら対応表に戻って行を直し、同じデータでもう一度試す、という往復を差が無くなるまで続けます。
複数の拠点の対応表を作るときは、届いたデータがどの拠点の形式かを、変換の前に判別できることも確かめておきます。
EIP の Normalizer の説明では、形式の判別に、XML ならルート要素、CSV なら項目の数、ファイルならファイル名や置かれたフォルダを使えるとしています3。
拠点Aと拠点Bが同じ項目数のCSVを送ってくるなら、項目数では区別できないので、ファイル名か置き場所で拠点を見分ける取り決めが必要になります。
その判別方法も、対応表の冒頭に拠点ごとの前提として書いておくと、次の節で扱う受け側の振り分けを作るときに迷いません。
▼ 図の内容を文字で読む
- 送り側と受け側の項目を洗い出す
- コード値の一覧をそろえて対応づける
- 例外と片方にしか無い値の扱いを書く
- 拠点の実データで取り込みと集計を照合する
- 弾かれた行・合わない数字を形式差と意味差に分けて表へ戻す
変換は拠点側・連携基盤・受け側のどこに置くか：拠点数で変わる変換部品の数
直接変換と共通形式の変換本数の違い（2・3・6システム）
対応表ができたら、その規則をどこで実行するかを決めます。
置き場所の候補は、拠点側で本社の形式に直してから送る、間の連携基盤で直す、本社の受け側で直す、の三つです。
まず考えたいのは、つなぐシステムが増えたときに変換の部品がいくつ要るかです。
EIP の Canonical Data Model は、どのアプリケーションも所有しない共通の形式を決め、各アプリケーションはその形式で入出力するという構成です1。
EIP は、共通形式を挟む場合と、相手ごとに直接変換する場合の変換部品の数を比べています。
2つのシステムなら直接変換は2本で済むのに対し、共通形式を挟むと各システムの出入りで4本になります。
3つのシステムでは、どちらも6本で並びます。
6つのシステムになると、直接変換は30本、共通形式なら12本です1。
直接変換はシステムの組み合わせの数だけ増え、共通形式はシステム1つにつき出入りの2本ずつしか増えないため、数が増えるほど差が開きます。
EIP 自身も、参加するアプリケーションが少ないうちは共通形式が複雑すぎるように見えると述べています1。
ただし、この数え方には前提があります。
EIP が数えているのは、システム同士が互いにデータを渡し合う構成です。
拠点が本社にだけデータを送る構成では、拠点同士の変換は要らないので、この比較はそのまま当てはまりません。
その場合は本社の受け取る形式が事実上の共通形式の役目を果たし、拠点ごとに本社の形式へ直す変換を一つずつ用意する形になります。
本社とは別に共通形式を設けても、変換の本数が減るとは限りません。
共通形式を挟む意味が出てくるのは、同じ拠点データを本社の基幹システムだけでなく会計や物流など複数の受け手へ渡すようになった場合や、拠点同士でもデータをやり取りするようになった場合です。
受け手が増えるほど、EIP が数えた構成に近づいていきます。
また、共通形式はどのシステムも所有しない形式なので、本社の基幹システムを入れ替えるときに拠点側の変換まで作り直さずに済む余地を残せる、という見方もできます。
いまの構成が本社への一方向の集約なのか、受け手が増える見込みがあるのかを先に整理しておくと、共通形式を作るかどうかを判断しやすくなります。
拠点側を改修できるか・変更頻度で見る補助軸
変換の本数は置き場所を考える出発点ですが、実際には本数以外の事情で置き場所が決まることも少なくありません。
ここからは原典で確かめた基準ではなく、本記事としての判断軸を二つ挙げます。
一つ目は、拠点側のシステムを改修できるかどうかです。
拠点Aの基幹システムが子会社の予算で動いている、保守を外部の会社に任せていて出力の形式を変えるには改修の発注が要る、といった事情があると、拠点側で本社の形式に直してから送ってもらう案は取りにくくなります。
その場合、変換は連携基盤か本社の受け側に置き、拠点Aにはいまの形式のまま出力してもらうことになります。
反対に、拠点側で出力の形式を調整できるなら、拠点の事情を一番よく知る拠点の担当者が変換を受け持つ選択肢も出てきます。
二つ目は、どちらの形式がよく変わるかです。
本社の受け口の項目がたびたび見直される状況で変換を各拠点に置いていると、本社の変更のたびに全拠点へ改修を頼むことになります。
逆に、拠点ごとの業務の見直しで拠点側の出力がたびたび変わるなら、変換を本社側に集めた場合、拠点の変更をすべて本社の担当者が追いかけることになります。
どちらを選んでも変更の負担は消えず、誰が受け止めるかが変わります。
その負担を受け止められる側、そして変更をきちんと伝えてもらえる連絡の経路がある側に、変換を置くのが現実的です。
形式ごとの変換を受け側に集める振り分け構成
拠点側を触れない場合に、受け側でどう組み立てるかの手本になるのが EIP の Normalizer です。
同じ意味で形式だけが異なるメッセージを受け取り、まず振り分け（ルーター）で形式を判別し、形式ごとに用意した変換部品へ送って、最後に共通の形式にそろえます3。
拠点A用・拠点B用の変換をそれぞれ用意し、入口で拠点を見分けて振り分ければ、本社の取り込み処理は共通の一種類の形式だけを扱えばよくなります。
この構成の利点は、変換がすべて受け側の一か所に集まり、本社の担当者が全拠点の規則を同じ場所で見渡せることです。
新しい拠点が加わっても、その拠点用の変換部品と判別の規則を足すだけで、既存の拠点の変換には手を入れずに済みます。
一方で、前提になるのは、入口で形式を判別する規則を作れることです3。
前の節で触れたように、ファイル名や置き場所で拠点を見分ける取り決めが崩れると、振り分けの段階で誤った変換に送られてしまいます。
また、拠点側が出力の形式を予告なく変えた場合、本社が気づくのは取り込みに失敗した時点です。
この弱点は、最後の節で扱う変更の連絡の手順と、失敗データの扱いで補います。
▼ 図の内容を文字で読む
- システム同士が互いにデータを渡し合う構成
- 直接変換はシステムの組み合わせごとに増える
- 共通形式はシステム1つにつき出入りの2本ずつ増える
- 6システムでは直接変換30本に対し共通形式12本
- 拠点が本社にだけ送る構成
- 本社の受け取る形式が事実上の共通形式になる
- 拠点ごとに本社形式への変換を1本ずつ用意する
- 別に共通形式を設けても本数は減りにくい
- 拠点データの受け手が増えた構成
- 本社の基幹システムに加え会計や物流へも渡す
- 互いに渡し合う構成に近づき、共通形式の利点が出やすい
出典：Enterprise Integration Patterns「Canonical Data Model」。変換本数はシステム同士が互いにデータを渡し合う構成での数え方。本社への一方向の集約と受け手が増えた構成の整理は本記事の分析
共通定義に統一する項目と、変換で吸収し続ける項目の線引き
共通形式が少数の拠点では重くなる理由
置き場所が決まると、次に迷うのが、どこまでを共通の定義にそろえ、どこからを変換で吸収し続けるかです。
共通定義に寄せれば変換の規則は減りますが、拠点の業務やシステムの側に変更を求めることになります。
変換で吸収すれば拠点はいまのまま動けますが、規則は拠点ごとに増え続けます。
EIP は、参加するアプリケーションが少ないうちは共通形式が複雑すぎるように見えると述べています1。
2つのシステムでは直接変換より変換部品が増える、という数の問題がまずあります。
加えて、本記事の見方として、どのシステムも所有しない形式を決めるには、つながるすべての側がその定義を受け入れる必要があります。
拠点が二つ三つの段階で、まだ見えていない将来の受け手まで想定した共通定義を作ろうとすると、合意の手間が変換を書く手間を上回りやすくなります。
共通形式の定義そのものを誰が持ち、誰が変更を承認するかという、新しい管理の仕事も生まれます。
標準化は相手の対応が前提になる限界
共通定義には、もう一つ限界があります。
定義を決めても、送り手と受け手の双方がその定義で動けるようになるまで、効果が出ないことです。
参考になるのが、企業間の振込データに関する中小企業庁の解説です。
全銀EDI（振込に取引の明細を添えて送る仕組み）で売掛金の消込を効率化するには、支払う側と受け取る側の双方が導入していることが前提で、受け取る側が導入していなければ従来どおり手作業での消込になるとしています7。
これは企業間の振込と消込の話で、2019年の取材にもとづく記事のため、現在の普及状況を示すものでもありません。
ここで借りたいのは、標準をそろえる効果は相手の対応を前提にする、という一点だけです。
拠点間の連携に置き換えると、本社が共通定義を決めても、拠点Aがその定義で出力できるようになるまで、本社は拠点Aの旧形式を変換し続けることになります。
一部の拠点だけが共通定義に移った段階では、本社は共通定義のデータと旧形式のデータの両方を受け取る期間を抱えます。
共通定義への移行を拠点ごとの改修の時期と合わせて計画しないと、変換の規則がかえって増える時期が生まれる点は見込んでおく必要があります。
統一する項目・吸収する項目の判断基準（提案）
では、どの項目を共通定義にそろえ、どの項目を変換で吸収し続けるか。
原典で確かめた基準があるわけではないので、ここまでの整理をもとにした提案として示します。
共通定義にそろえる候補は、次のような項目です。
- 全拠点で意味が同じで、書き方だけが違う項目（日付、得意先区分の表し方など）
- 本社の集計の軸になり、拠点が増えても同じ意味で使い続ける項目
- 拠点側の出力を調整できる見込みがある項目
反対に、変換で吸収し続けるほうがよいのは、次のような項目です。
- 拠点ごとに意味が違い、業務上その違いに理由がある項目（拠点固有の作業区分など）
- 拠点の業務に深く結び付き、変えると現場の運用まで変える必要がある項目
- 本社では集計に使わず、参照のために受け取るだけの項目
迷いやすいのは、品目コードの粒度のように、意味が違うのに本社の集計には欠かせない項目です。
この場合、拠点Aの細かさに本社を合わせるのでも、本社の細かさを拠点Aに強いるのでもなく、両方が対応できる粗さの分類を共通定義として決める方法があります。
本社の色別コードを拠点Aの部材コードから振り分けることはできなくても、両方を同じ品目分類にまとめることはできる場合があります。
共通定義の側を粗い分類にしておけば、拠点Aの一つの値が本社の複数の値に当たるという振り分けの問題がなくなり、拠点ごとの細かいコードは拠点側の値として別に残せます。
どの粗さなら集計に使えるかは本社の集計の目的によって変わるため、ここは業務の担当者と一緒に決める部分です。
線引きは一度決めて終わりではありません。
拠点が増えて、同じような吸収の規則が拠点ごとに繰り返し書かれるようになったら、その項目は共通定義へ寄せる候補です。
逆に、共通定義にしたのに拠点ごとの例外が増え続ける項目は、実は意味が拠点ごとに違っていた可能性があります。
拠点追加・仕様変更でも崩れない対応表の管理と、エラー時の確認
対応表の持ち主と変更手順（提案）
対応表は作った時点が一番正しく、その後は拠点のシステム更新、本社のマスタ変更、新しい拠点の追加のたびに実態とずれていきます。
ずれを放置しないために、対応表の持ち主を一人または一つの担当部署に決め、変更はその持ち主を通す、という約束を先に作っておくことを提案します。
本社で受け取る側が全拠点の規則を見渡せる位置にいるなら、本社の連携担当が持ち主になるのが自然です。
変更の手順は、たとえば次の流れが考えられます。
- 拠点の担当者、または本社の担当者が、項目や値の変更を持ち主に伝える
- 持ち主が、その変更が形式差か意味差かを判定する
- 意味差なら、拠点と本社の業務担当で定義を合意する
- 対応表の該当行を更新して版を上げ、変更前の内容・理由・承認者を残す
- 拠点の実データで取り込みと集計を試し、適用する時期を拠点と本社の双方に伝える
版を上げて変更前の内容を残しておくのは、数字が合わなくなったとき、いつからどの規則で変換していたかを確かめるためです。
過去の月の集計を見直す場面では、いまの規則ではなく、その月に使っていた規則で見なければ差の理由を説明できません。
新しい拠点を加えるときも、既存の拠点の対応表を写して差分だけを埋める形にすると、本社の受け取る項目は共通のまま、拠点ごとの違いだけが行として増えていきます。
変換に失敗したデータの隔離と再処理
対応表をどれだけ丁寧に作っても、想定していない値は届きます。
拠点Aの担当者が新しい得意先区分を追加した、訂正伝票の一部の項目が空のまま送られた、といった場合です。
そのとき、ファイル全体の取り込みを止めるのか、変換できないデータだけを外して残りを進めるのかを、あらかじめ決めておく必要があります。
EIP の Invalid Message Channel は、受け手が処理できないメッセージを専用のチャネルへ移し、正常なやり取りの邪魔にならないようにする考え方です4。
移されたメッセージは、エラーを扱う側が受け取って中身を調べられます4。
拠点の連携に当てはめると、拠点Aの一部が変換できなくても、ほかのデータや拠点Bの取り込みは進め、変換できなかった分は本流と分けた置き場（隔離先）に移しておく形になります。
隔離先にたまったデータを持ち主が確認し、原因が対応表の漏れなら規則を直し、拠点側の入力の誤りなら拠点の担当者に訂正を頼みます。
ただし、どの単位で隔離するかはデータの性質によります。
一つの伝票が見出しと明細の複数行に分かれているのに、明細の一行だけを外して残りを取り込むと、本社では金額の合わない伝票ができてしまいます。
行単位で外すのか、伝票単位でまとめて隔離するのか、ファイル単位で止めるのかは、業務上の意味のまとまりに合わせて決めます。
再処理では、二重に取り込まないことにも注意が要ります。
一部がすでに取り込まれたファイルを、訂正後に丸ごと送り直すと、取り込み済みのデータが重複して登録されるおそれがあります。
拠点側の伝票番号などで取り込み済みかを見分けられるようにするなど、同じデータを二度処理しても結果が変わらない作りを、設計の段階で考慮しておきます。
具体的な方法は、使っている連携基盤や本社の基幹システムの取り込みの仕様によって変わります。
エラーの発生箇所を記録する
隔離したデータを調べるとき、どこで失敗したかが分からないと、原因の切り分けに時間がかかります。
EIP の Invalid Message Channel の説明は隔離するという考え方までで、エラーの情報として何を添えるかは示していません4。
実装の例として参考になるのが、オープンソースの連携フレームワーク Apache Camel のデッドレターチャネル（処理できなかったメッセージの送り先）の仕様です。
Camel のデッドレターチャネルは、処理に失敗したメッセージを、再配信をすべて試したあとで、ファイルやデータベース、ログなどの隔離先へ移します5。
再配信は既定では無効になっています5。
あわせて、どのエンドポイント（送り先）やどのルート（処理の流れ）で失敗したかを、メッセージに付随する情報として記録します5。
これは Camel の既定の動きであり、ほかの連携基盤が同じように振る舞うとは限りません。
自社で使っている基盤では、失敗時の再試行の有無と隔離先、記録される情報がどう設定されているかを確かめておく必要があります。
拠点の連携で記録しておきたいのは、どの拠点のどのファイルの何行目で、どの項目に、対応表のどの規則を当てたときに失敗したか、という情報です。
ここまで残っていれば、持ち主は対応表の該当行をすぐに開けますし、拠点の担当者にも、どの伝票のどの項目を見ればよいかを具体的に返せます。
また、再試行が意味を持つのは、通信が一時的に途切れたような失敗です。
日付の形式が違う、対応表に無いコードが来た、という変換の失敗は何度試しても同じ結果になるため、再試行を待たずに隔離し、対応表か元データを直してから再処理する流れにしておくと、隔離先を見る担当者の手間が減ります。
▼ 図の内容を文字で読む
- 拠点の担当
- 指摘された伝票と項目を訂正して再送する
- 拠点側の出力の変更を事前に持ち主へ伝える
- 変換処理（連携基盤または本社側）
- 変換できないデータを本流から外して隔離先へ移す
- 拠点・ファイル・行・項目・当てた規則を記録する
- 隔離先
- 本流の取り込みを止めずに失敗分を保管する
- 原因を直したあと、二重取り込みを避けて再処理へ戻す
- 対応表の持ち主（本社）
- 形式差の漏れなら規則を直して版を上げる
- 意味差なら業務側と定義を合意する
- 入力の誤りなら拠点の担当へ返す
形式差と意味差の切り分けや変換の置き場所は、拠点ごとの実データと本社の取り込みの仕様を突き合わせないと決めきれず、社内だけでは判断が止まりやすい部分です。
拠点から届いたデータと本社の受け口の項目を見ながら、どの違いが変換で吸収でき、どれに業務側の合意が要るか、変換をどこに置くかを確かめられます。無料相談で要件を整理する
変換をどこに置くか：三つの置き場所の特徴
拠点側システムを改修できるか、変換をどこで一元管理し、変更の負担を誰が受け止めるかで置き場所の特徴を並べた。
- 拠点側で本社の形式に直して送る：拠点の事情に詳しい担当者が変換を持てるが、拠点ごとの改修が要り、本社の形式が変わると全拠点へ影響が広がる
- 連携基盤で変換する：全拠点の変換を一か所で管理できるが、基盤の担当者と対応表の持ち主の役割をそろえておく必要がある
- 本社の受け側で変換する：拠点のシステムを触らずに始められるが、拠点の形式変更に気づくのが取り込みに失敗した時点になる
拠点データを本社以外の受け手にも渡す、拠点同士でもやり取りする構成に広がったら、共通形式を挟む案を検討し直す。
要点の整理
| 取り込めない・合わない | 症状は目安にとどめ、弾かれた行と元伝票を照合して形式差か意味差かに分ける |
|---|---|
| 形式差 | 対応表に変換ルールと例外を書いて機械的に吸収する |
| 意味差 | 変換を書く前に業務側で定義を合意し、その結果を規則にする |
| 変換の置き場所 | 互いに渡し合うシステムが増えるほど共通形式が有利。本社への一方向の集約にはその数え方がそのまま当てはまらない |
| 拠点側を触れない | 受け側で拠点を判別し、拠点ごとの変換で共通の形式にそろえる |
| 統一か吸収か | 全拠点で意味が同じ集計の軸は統一、拠点固有の意味を持つ項目は吸収、粒度違いは粗い分類で共通化 |
| 運用 | 対応表の持ち主と版管理、失敗データの隔離と発生箇所の記録、二重取り込みの防止 |
拠点の追加や基幹システムの更新を控えている場合、対応表の持ち主や失敗データの扱いを決めないまま広げると、集計のずれの原因を後から追えなくなります。 いまの連携の構成と対応表をもとに、共通定義へ寄せる項目と変換で吸収する項目の線引き、隔離と再処理の流れに抜けがないかを確かめられます。
よくある質問
拠点が2〜3つだけでも共通形式を作るべきですか。
必ずしも作る必要はありません。
EIP の数え方では、2つのシステムなら共通形式のほうが変換部品が多く、3つで同じ本数になり、それより増えると共通形式が有利になります1。
EIP 自身も、少数のアプリケーションでは共通形式が複雑すぎるように見えると述べています1。
また、拠点が本社にだけ送る構成なら、本社の受け取る形式が事実上の共通形式になります。
同じ拠点データを会計や物流など別の受け手にも渡す見込みが出てきた段階で、共通形式を検討するのが無理のない順序です。
拠点側のシステムを触れない場合、変換はどこに置けばよいですか。
連携基盤か本社の受け側に置きます。
EIP の Normalizer のように、入口で拠点ごとの形式を判別し、拠点ごとの変換を通して共通の形式にそろえる構成がとれます3。
判別にはファイル名や置き場所、CSVの項目数などを使えるため3、拠点とその取り決めを決めておきます。
拠点が形式を変えると取り込み時点まで気づけないので、変更の事前連絡の手順もあわせて決めておくと安心です。
コードの粒度が拠点ごとに違うとき、対応表はどう書けばよいですか。
拠点の一つの値が本社の複数の値に当たる場合は、機械的には変換できません。
業務側で振り分けの規則を合意してその規則を書くか、両方が対応できる粗い分類を共通定義として決め、そこへ対応づける方法があります。
どちらを選んだかと理由を例外の欄に残し、拠点ごとの細かいコードは拠点側の値として別に残しておくと、後から集計の差をたどれます。
対応表の変更は誰が承認し、どう履歴を残せばよいですか。
本記事の提案としては、対応表の持ち主を一人または一つの担当部署に決め、変更はすべてその持ち主を通します。
形式差の変更は持ち主の判断で直せますが、意味差にかかわる変更は拠点と本社の業務担当の合意を経ます。
更新のたびに版を上げ、変更前の内容・理由・承認者を残しておくと、過去の月の集計をその月に使っていた規則で見直せます。
変換エラーのデータを再処理するとき、二重登録はどう防げばよいですか。
一部がすでに取り込まれたファイルを丸ごと送り直すと、取り込み済みのデータが重複するおそれがあります。
拠点側の伝票番号などで取り込み済みかを見分けられるようにし、同じデータを二度処理しても結果が変わらない作りを設計段階で考えておきます。
隔離と再処理の単位を伝票ごとにそろえておくと、見出しと明細の一部だけが二重になる事態も避けやすくなります。
具体的な方法は、使っている連携基盤や本社の基幹システムの取り込みの仕様によって変わります。
- 1 出典：Enterprise Integration Patterns（Gregor Hohpe・Bobby Woolf）「Canonical Data Model」（2026）
- 2 出典：Enterprise Integration Patterns（Gregor Hohpe・Bobby Woolf）「Message Translator」（2026）
- 3 出典：Enterprise Integration Patterns（Gregor Hohpe・Bobby Woolf）「Normalizer」（2026）
- 4 出典：Enterprise Integration Patterns（Gregor Hohpe・Bobby Woolf）「Invalid Message Channel」（2026）
- 5 出典：Apache Camel プロジェクト「Dead Letter Channel」（2026）
- 6 出典：Collibra「Map code values and crosswalks」（2026）
- 7 出典：中小企業庁（ミラサポplus）「金融EDIの導入で、経理業務を効率化する！」（2020）
画像の出典元
- Focused employee in an office setting using a computer and headset.／Photo by Jep Gambardella on Pexels
