基幹システム連携の項目差異を変換で吸収する手順：対応表・変換方法・置き場所・変換できない項目の扱い

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

B2B EC-COLUMN

取込エラーや値のずれは、項目のどの違いから起きるのか

基幹システムから出した受注データを連携先へ流したら、取込エラーで止まった。
あるいは取り込めたのに、得意先名の末尾だけが欠けていた。
こうしたずれの原因は、送る側と受け取る側で項目の名称・型・桁・コード値・必須・粒度のどこが違うかに分けると探せます。
差異を項目ごとに対応表へ書き出し、差異の種類ごとに変換方法を決めます。
変換は2つのシステムの間で翻訳だけを担う場所に集め、業務ルールは持たせません。
置き場所は、改修できるシステムと保守を担う人で選びます。
変換できない行は止めるか除外して記録するかを先に決め、ルールを変えたら境界値で確かめます。

ツールが検出する3つの非互換（型・列数・キー）

連携データの不具合は、症状で2つに分かれます。
取込そのものが失敗して止まるものと、取り込めたのに値が意図と違っているものです。
前者は連携の仕組みがエラーとして知らせてくれます。
後者は、出荷伝票や画面を見た誰かが気づくまで残ります。
どちらの症状かで疑うべき差異が変わるため、最初にここを分けておくと、項目一覧のどこを見ればよいかが絞れます。

取込が止まるほうの症状では、どんな違いを失敗として扱うかが連携ツールの仕様で決まっています。
たとえばAzure Data Factoryのコピーアクティビティでは、表形式データのコピーで検出・スキップ・ログ記録の対象になる非互換は3種類です。
データの読み出し元（ソース）と書き込み先（シンク）で型が合わないもの、列数が合わないもの、主キーに違反するものです²。
このうち主キー違反は、SQL Server、Azure SQL Database、Azure Cosmos DBへ書き込む場合が対象とされています²。

ここからは、ひとつの仮例を通して考えます。
販売管理システム（基幹）から出した受注データを、出荷を担う倉庫管理システムへ取り込む連携です。
実在の事例ではなく、説明のための設定です。
この仮例では、数量の欄に「未定」という文字が入っていて数値型の項目へ入らない場合が、型の非互換に当たります。
販売管理側で備考列が追加され、出力ファイルの列数が受け取り側の想定と食い違えば、列数の不一致です。
同じ受注番号の行が再送で二度届き、受け取り側の主キーとぶつかれば、キー違反になります。

ただし、この3分類はあくまでこの製品の仕様です。
別の連携基盤や自作のスクリプトでは、同じ違いが別の名前のエラーになることも、エラーにならずに通ってしまうこともあります。
それでも、取込が止まったときに最初に疑う観点としては、型・列数・キーの3点が使えます。

名称・桁・コード値・必須・粒度の違いを見分ける観点

やっかいなのは、もう一方の「取り込めたのに値が違う」症状です。
ツールが失敗として扱う違いは一部にすぎません。
それ以外の差異は、受け取り側の仕様によってエラーになることもあれば、黙って通ることもあります。
自社の項目一覧と連携先の取込仕様を並べるときは、型と列数に加えて、名称・桁・コード値・必須・粒度の5つの観点で違いを拾うと漏れが減ります。
この5つは製品が定めた分類ではなく、項目の差異を整理するための見方です。

名称の違いは、同じ意味の項目が別の名前で定義されている状態です。
販売管理では得意先名、倉庫管理ではcustomer_nameというように、意味が同じでも機械は別の項目として扱います。
桁の違いは、受け取り側の項目が短いときに問題になります。
仮例では倉庫管理の得意先名の桁が販売管理より短いため、長い社名は設定によってはエラーにならず、末尾だけ欠けて届くおそれがあります。

コード値の違いは、同じ配送区分を両システムが別のコードで表している状態です。
型も桁も合っているので取込は通りやすいのに、送った値が受け取り側では別の意味になったり、マスタに無い値として後工程で弾かれたりします。
必須の違いは、販売管理では任意入力の電話番号が、倉庫管理では必須になっているような状態です。
空のまま届いた行は、受け取り側の入力チェックで止まります。

粒度の違いは、ひとつの情報をどこまで細かく分けて持つかの差です。
販売管理は住所を1項目で持ち、倉庫管理は都道府県・市区町村・番地に分けて持つ、というのが典型です。
受注1件の中に明細を複数抱える形と、明細1行ごとに1レコードとする形の違いも粒度の差にあたります。
どちらも、名前を読み替えるだけでは埋まりません。

列名で対応づけるか、位置で対応づけるか

名称の違いがどこまで問題になるかは、ツールが項目をどう結びつけるかで決まります。
Azure Data Factoryのコピーアクティビティでは、既定のマッピングはソースとシンクの列を列名で対応づけ、大文字と小文字も区別します¹。
販売管理の出力がTOKUISAKI_NM、倉庫管理の項目がcustomer_nameであれば、意味が同じでも自動では結びつきません。
Order_NoとORDER_NOのように見た目がほぼ同じ名前でも、別の列として扱われます。

一方、ヘッダー行のないテキストファイルには列名がありません。
そのため明示的なマッピングが必要になり、列は序数（何番目の列か）で指定します¹。
位置で対応づける連携では名称の違いは問題になりませんが、送る側で列が1つ増えたり順番が入れ替わったりすると、それ以降の列がすべてずれて入ります。
列名で結ぶか位置で結ぶかによって、壊れ方が違うということです。

どちらの場合も、項目同士の対応は人が決めて書き残す必要があります。
2つのテーブルの項目を対応付ける作業や処理はデータマッピングと呼ばれ、システム間のデータ受け渡しや新旧システムの移行で行われます⁵。
次に作る項目対応表は、このデータマッピングを、変換のルールまで含めて1か所に書き留めるためのものです。

項目対応表に何を書けば、変換ルールが決められるか

明示的マッピングが持つ属性

対応表にどんな列が要るかを考えるときは、ツールが変換を実行するために何を指定させているかが手がかりになります。
Azure Data Factoryの明示的マッピングでは、列ごとに、ソースとシンクの名前、列の序数、階層データの位置を示すJSONパス、型、日時の書式などを指定できます¹。
列名を変えて書き込むことも、ソースの一部の列だけをコピーすることもできます¹。

裏返すと、これらが決まっていなければ変換は実装できません。
対応表に項目名しか書かれていなければ、受注日をどの書式で読むのか、明細のどの階層を取り出すのかを、実装する人がその場で推測することになります。
推測で埋めた部分は対応表に戻ってきません。
そのため後でずれが出たとき、どれが決めたルールで、どれが実装者の判断だったのかを追えなくなります。

対応づけの可否は、表形式と階層構造の組み合わせによっても変わります。
たとえば表形式から階層構造へ書き込む場合、オブジェクトの中にある配列への書き込みには対応していません¹。
受け取り側がJSONのような入れ子の形を求める連携では、対応表を書く段階でその形がツールで作れるかを見ておくと、手戻りが減ります。

対応表の列構成の案

対応表の様式に公的な決まりがあるわけではないので、ここからは提案です。
ツールが求める属性を土台にして、差異の判断と、変換できなかったときの扱いまでを1行で読めるようにします。

列は、送る側の項目名（位置で結ぶ場合は列の番号）、送る側の型と桁、受け取る側の項目名、受け取る側の型・桁・必須の有無、コード体系の有無、差異の種類、変換方式、変換できない場合の扱い、の順に並べると扱いやすいでしょう。
差異の種類の列には、前の節で見た名称・型・桁・コード値・必須・粒度のどれに当たるかを書きます。
複数に当たる項目は、すべて書いておきます。

この中で見落とされやすいのが、変換できない場合の扱いの列です。
設計の段階でここが空欄のままだと、本番で変換できない行が出たときに、取込を止めるのか、その行だけ除いて進めるのかを、障害対応のさなかに決めることになります。
業務への影響を知っている人と落ち着いて相談できるのは設計の段階です。
だからこそ、扱いを先に書き込んでおく意味があります。

あわせて、その行を誰が決めたかを残す列もあると、変更のときに相談する相手が分かります。
差異の種類と扱いの判断は、あとで変換ルールを見直すときの根拠になります。

仮例：受注データの項目対応表

仮例の受注データで対応表を作ると、次のようになります。
説明のために列を一部へ絞っており、項目名やコードも架空のものです。

表にすると、変換で埋まる差異と、変換では埋まらず運用の決めごとが要る差異とが分かれて見えてきます。
受注番号や受注日は、名前の読み替えや書式の指定で機械的に変換できます。
一方で電話番号の行は、変換方式が「補わない」になっています。
空の電話番号に何かの値を入れて通すのは、形の変換ではなく、どの番号を正とするかという判断だからです。
この区別は、変換をどこに置くかを決める段階でもう一度効いてきます。

差異の種類ごとに、どの変換方法を使うか

型・書式の変換と、切り詰めの既定値に注意

対応表の変換方式の列を埋めるには、差異の種類ごとに使える方法を知っておく必要があります。
まずは型と書式です。
Azure Data Factoryのコピーアクティビティでは、ソースの型は中間の型を経てシンクの型へ変換され、変換できる組み合わせは表で示されています¹。
どの型からどの型へでも変えられるわけではありません。
対応表で型の違う行が出たら、その組み合わせが表にあるかを見ます。

日付と文字列のあいだの変換では、書式を指定します¹。
仮例の受注日は、販売管理がyyyyMMdd形式の文字列で出し、倉庫管理は日付型で受け取ります。
書式を指定しておかないと、年月日の区切りを読み違えて別の日付になったり、日付として読めずに失敗したりするおそれがあります。
書式を対応表の型の列に書いておけば、実装と照らし合わせられます。

注意したいのは、型を変換する際に値の切り詰めを許可する設定（allowDataTruncation）の既定値がtrueになっていることです¹。
既定のまま使うと、受け取り側に入りきらない値がエラーにならず、欠けた形で書き込まれる可能性があります。
仮例の得意先名のように、末尾が欠けると別の得意先と区別がつかなくなる項目では、黙って欠けるより止まるほうが安全です。
設定を確かめたうえで、桁を超える値を変換の前に判定し、該当する行を保留へ回す流れを対応表に書いておきます。
そうすれば、切り詰めが起きたかどうかを後から探す必要がなくなります。

なお、この型変換の仕組みは表形式データ同士のコピーが対象で、階層構造のソースやシンクにはシステム定義の型変換は行われません¹。
他の連携基盤や自作のスクリプトでは、切り詰めや型変換の既定の動きが異なることがあります。
使っている仕組みの既定値も、同じ観点で確かめておく必要があります。

式で値を加工する

名前の読み替えや型の変換だけでは足りない差異には、式で値を作り直す方法があります。
Azure Data Factoryのマッピングデータフローにある派生列変換では、式によって新しい列を作ったり、既存の列を別の値で上書きしたりできます⁴。
例として、Rating列を整数に変換した値で置き換える使い方が示されています⁴。

仮例では、前後の空白を取り除いてから得意先名の長さを判定する、複数の項目をつないで受け取り側の1項目にする、といった加工がこの方法に当たります。
住所を都道府県・市区町村・番地に分ける処理も式で書けますが、住所の書き方は人によって揺れるため、どんな住所でも正しく分けられるとは限りません。
分けきれない値が出る前提で、分割に失敗した行の扱いを対応表に決めておくことになります。

式で使える関数は製品ごとに異なります。
そのため対応表には、実装の式そのものより、何をどう加工するかを言葉で書いておくほうが役立ちます。
連携の仕組みを替えることになっても、対応表はそのまま使えます。

1対多・階層構造を行へ展開する

粒度の違いのうち、受注1件に明細が複数ぶら下がる形を明細1行ごとのレコードに直す処理もあります。
Azure Data Factoryでは、階層的なソースにある配列をcollectionReferenceで指定すると、配列の要素ごとに行へ展開して表形式のシンクへ書き出せます¹。
仮例なら、受注の中の明細配列を展開し、受注番号や受注日を各明細行に繰り返して載せる形になります。

ただし、展開できるのは単一の配列だけです¹。
受注の中に明細の配列と、たとえば同梱物の配列が並んでいる場合、1回の展開では両方を行にできません。
このときは明細と同梱物を別々の処理で取り出すなど、対応表の段階で分け方を決めておきます。
配列が空だったときの動きにも設定があり、これは変換できない行の扱いとして後の節で取り上げます。

コード変換の対応表を別に持つ考え方

コード値の違いは、型も桁も合っているため、ツールの変換設定では埋まりません。
送る側のコードと受け取る側のコードを並べた読み替え表が必要です。
ここからは公式資料に基づく話ではなく、運用上の提案です。

読み替え表は、項目対応表の中に書き込むより、別の表として持つほうが扱いやすくなります。
項目の構成が変わるのは連携の改修のときくらいですが、配送区分のようなコードは、業務側で区分が増えるたびに追加が要るからです。
読み替えを変換の式の中に直接書いてしまうと、コードを1つ足すたびに変換処理の変更とリリースが必要になります。
誰がいつどのコードを足したのかも追いにくくなります。

別表にするなら、送る側のコード、受け取る側のコード、使い始めと使い終わりの時期、追加を決めた人を列に持たせます。
表の中身はコードの意味を決めている業務側が管理し、表を読み込む仕組みは連携の担当者が保守する、という分担が考えられます。
こう分けておけば、新しい区分を追加するとき、業務側は表を更新するだけで済み、連携の担当者は変換処理に手を入れずに済みます。

変換は基幹側・連携先側・中間のどこに置くか

意味の違う2システムの間に翻訳層を置く考え方

変換方法が決まったら、その処理をどこに置くかを決めます。
販売管理の出力処理に組み込むか、倉庫管理の取込処理に持たせるか、2つのあいだに専用の処理を置くかです。

設計の考え方として参考になるのが、腐敗防止レイヤーと呼ばれるパターンです。
意味づけの異なる2つのシステムのあいだに変換を担う層（ファサードやアダプター）を置き、どちらのシステムも相手の都合に合わせて作り変えずに済むようにします³。
この層は、アプリケーションの中の部品としても、独立したサービスとしても作れます³。
販売管理の設計を倉庫管理の項目に寄せる、あるいはその逆をすると、片方を入れ替えるときに両方を直すことになります。
変換を層に集めておけば、直す場所が1か所にまとまります。

一方で、このパターンは重要な意味の違いがない場合には向かないとされています³。
項目名の読み替えだけで済む連携なら、専用の層を設けず、ツールのマッピング設定で足りる場面もあるということです。
また、移行を段階的に進める場面での利用が想定されており、層を恒久的に残すのか、移行が終わったら廃止するのかも検討事項に挙げられています³。
販売管理の入れ替えを控えているなら、新しい基幹へ移ったあとに層をどうするかまで決めておくと、作った変換処理が宙に浮きません。

置き場所を選ぶ5つの比較軸

腐敗防止レイヤーの考慮事項としては、層を挟むことによる遅延の増加、層そのものの管理と保守、スケーリング、そして監視やリリースといった運用の流れへの組み込みが挙げられています³。
これを基幹システム連携の置き場所選びに当てはめると、変更頻度、保守の担い手、基幹・連携先の改修可否、遅延の許容、変換層の運用・監視の置き場所の5つで比べられます。
次の表は、この5つの軸を基幹側・連携先側・中間の3つに同じ形で当てた整理です。
公式資料が示す比較ではなく、どれが標準というものでもありません。
自社の条件によって、どの軸を重く見るかが変わります。

判断が分かれやすいのは、改修可否と保守の担い手です。
販売管理がパッケージで出力処理を改修できない、あるいは改修のたびに提供元への依頼が要るなら、基幹側に変換を置く選択肢はほぼなくなります。
倉庫管理側に取込時の変換機能があれば連携先側に置けますが、その設定を誰が保守するのかは、倉庫管理の提供者との契約や運用の分担を見て確かめる必要があります。

中間に置く場合は、どちらのシステムも改修できなくても成り立つ代わりに、変換層という新しい持ち物が増えます。
誰がその層の障害に対応し、誰が対応表や読み替え表の変更を反映するのかが決まらないまま作ると、変換層は動いているのに誰も中身を説明できない状態になりがちです。
読み替え表の更新が頻繁な連携ほど、変換層だけを直してリリースできる利点が効いてきます。
ただしそれは、保守の担い手が決まっていてこその利点です。

翻訳に集中させ、業務ルールを置かない

どこに置く場合でも守りたいのが、変換の層には翻訳の処理だけを置き、業務ルールやオーケストレーション（複数の処理の呼び出し順の制御）は置かない、という線引きです³。

仮例で考えると、受注日の書式を変える、配送区分のコードを読み替える、明細を行に展開する、といった処理は形を変えるだけの翻訳です。
これに対して、電話番号が空なら得意先マスタの代表番号で補う、在庫の少ない商品は配送区分を変える、といった処理は、どの値を正とするかを決める業務の判断です。
こうした判断を変換の中に入れると、業務のルールが変わったときに、販売管理でも倉庫管理でもなく変換処理を直さなければならなくなります。
しかも、そのルールが変換処理の中にあることを業務側の人は知らないので、見直しの対象から漏れやすくなります。

対応表の電話番号の行を「補わない」としたのは、この線引きに沿った扱いです。
補うべきかどうかは業務側で決めます。
決まったなら、販売管理側で入力を必須にする、受注の段階で確かめるなど、本来その判断を持つ場所で対応します。

1対1で対応しない項目、欠損、未登録コードはどう扱うか

止めるか、除外して記録するか

対応表と変換を整えても、変換できない行は出ます。
想定外の文字が入った数量、桁を超える社名、読み替え表に無い配送区分などです。
このとき取れる動きは、取込全体を止めるか、その行だけを除いて残りを進めるかの2つに大きく分かれます。

Azure Data Factoryのコピーアクティビティでは、enableSkipIncompatibleRowという設定でこれを選びます。
既定値はFalseで、互換性のない行があるとコピーは失敗して止まります²。
Trueにすると、互換性のない行をスキップして残りの行のコピーを続けます²。
スキップした行は、行の内容と、型変換できない値やキーの重複といった理由を含めてCSVのログに残せます。
実行後の出力では、スキップした行数を確認できます²。
ログの保存先はBlob StorageまたはADLS Gen2です²。

ここで忘れてはいけないのは、スキップされた行は受け取り側に入らないということです。
仮例であれば、スキップされた受注はその日の出荷指示に載りません。
除外して進める設定を選ぶなら、ログを誰が見て、除外された受注をどう直して流し直すかという再処理の手順が要ります。
元の件数が、取り込んだ件数と除外した件数の合計と合っているかを照らし合わせる手順も欠かせません。
その手順がないままスキップを有効にすると、取込は毎回成功しているのに受注だけが静かに減っていく状態になります。

反対に、1行でも欠けると業務が成り立たないデータでは、止めるほうが合っています。
どちらを選ぶかは、行ごとに独立したデータかどうかで考えると判断しやすくなります。
受注同士は独立しているので、1件を除いて残りを出荷する考え方が取れます。
しかし1つの受注の明細の一部だけが欠けると、品物が足りないまま出荷されかねません。
同じ連携の中でも、受注単位では除外、明細の欠けは受注ごと止める、というように対応表の扱いの列で分けて決めておけます。

スキップが使えない構成

スキップの設定には、適用されない構成があります。
SQLのシンクからストアドプロシージャを呼び出す構成、upsert（既存の行は更新し、無い行は追加する書き込み方）でSQLのシンクへ書き込む構成、Amazon Redshift Unloadを使う構成では、この機能は使えません²。
受注の訂正を同じ受注番号で上書きしたい連携ではupsertを選ぶことが考えられますが、その場合は書き込みの段階で不正な行を除く仕組みに頼れません。

このようなときは、書き込みの前に変換の段階で値を検査し、問題のある行を保留側へ振り分けておく必要があります。
桁の判定や読み替え表との照合を書き込みの前に済ませておけば、どの書き込み方を選んでも、変換できない行の扱いを同じルールで運用できます。

もう一つ気をつけたいのが、配列が空のときの動きです。
階層から表形式へ展開する際、コレクション参照にした配列が空ならレコード全体をスキップする設定があります¹。
仮例で明細が空の受注が届いた場合、この設定を使うと、その受注は行として現れないまま落ちます。
明細のない受注はそもそも異常なので確かめたい、というのが業務側の考えなら、黙って落とすより保留へ回す流れのほうが合います。

欠損・未登録コードの保留と再処理

欠けた値やマスタに無いコードには、止めるか除外するかに加えて、保留にして後で流し直すという扱いも取れます。
ここからは公式資料にある機能ではなく、運用の提案です。

保留は、変換できなかった行を理由とともに別の置き場へ移しておく仕組みです。
仮例で読み替え表に無い配送区分が届いたら、その受注を保留に入れ、理由として未登録の区分コードとその値を記録します。
業務側が読み替え表に区分を追加したら、保留から取り出して変換をやり直し、倉庫管理へ流します。
除外との違いは、直して戻す道筋があらかじめ用意されている点です。

既定値で埋めて通す方法もありますが、意味を持つ項目には慎重になるべきです。
未登録の配送区分を一律に通常便として通すと、冷蔵が必要な商品が常温で出荷されるおそれがあります。
しかも受け取り側から見ると、誤りの痕跡が残りません。
既定値を使うのは、空でも業務上の意味が変わらないと業務側が合意した項目に限る、と決めておくと判断がぶれにくくなります。

保留の増え方にも注意が要ります。
同じ未登録コードの行がまとまって届いたら、個々の受注の入力ミスではなく、販売管理側で区分が追加されたのに読み替え表の更新が漏れている可能性を疑います。
その場合は保留にため続けるより、連携を止めて読み替え表を直すほうが、後の再処理がまとまって済みます。
保留を使う場合も、元の件数が取り込んだ件数・保留の件数・除外の件数の合計と一致するかを毎回照らし合わせておけば、どこにも入らずに消えた行がないことを確かめられます。

変換ルールをどう管理し、変更時や本番前にどう検証するか

対応表のバージョン管理とマッピングのパラメーター化

連携が動き始めてからも、対応表や読み替え表は変わり続けます。
販売管理で項目が増える、倉庫管理の取込仕様が改訂される、配送区分が追加される、といったたびに、どこかの行が書き換わります。
そこで提案したいのが、対応表と読み替え表に版を付け、どの版がいつから本番で使われているかを記録しておくことです。
障害が起きたとき、その時点の版を見れば、どのルールで変換されたかを確かめられます。

Azure Data Factoryでは、マッピングをパイプラインのパラメーターとして外から渡せます¹。
マッピングの定義を処理本体と分けて持てるので、対応表の版とマッピング定義の版を揃えて管理しやすくなります。

設定の既定値にも、版の管理で拾っておきたい落とし穴があります。
型変換の設定（typeConversion）は下位互換性のため既定値がfalseです。
2020年6月下旬以降に画面から新規作成したコピーアクティビティでは既定で有効になり、コードで作成する場合は明示的にtrueにする必要があります¹。
つまり同じ対応表に基づくマッピングでも、検証環境は画面で作り、本番はコードで作った、という違いだけで変換の結果が変わりえます。
対応表の変更を反映するときは、マッピングの中身だけでなく、こうした設定値が環境ごとに揃っているかも差分として見ておきます。

境界値の試験データ

変更を本番へ出す前の試験で、ふつうの受注データだけを流しても、差異の扱いが正しいかどうかは分かりません。
対応表の各行が想定している境目の値を、意図して試験データに入れておく必要があります。
以下は試験データの作り方の提案です。

仮例であれば、得意先名は受け取り側の桁ちょうどの値と、それを1文字超える値を用意します。
電話番号は空の値と空白だけの値、配送区分は読み替え表にあるコードと無いコード、受注日は想定どおりの書式と違う書式の値を入れます。
明細は、1行だけの受注、複数行の受注、明細が空の受注を揃え、受注番号が重複する行も加えます。

要になるのは、試験データの1行ごとに期待する結果を先に書いておくことです。
期待する結果は、対応表の変換できない場合の扱いの列からそのまま決まります。
桁を超える得意先名は保留に入り、桁ちょうどの値は欠けずに入る、というように対応表と試験結果を突き合わせれば、ルールどおりに実装されたかを行ごとに確かめられます。
試験の途中で、対応表に扱いが書かれていない行が見つかることもあります。
それは試験の失敗ではなく、設計の決め残しです。

ログと件数照合で本番前に確かめる

腐敗防止レイヤーのパターンでは、変換の失敗を診断できるよう、相関ID（一連の処理を通して同じデータを追うための識別子）や構造化ログといった可観測性を計画することが挙げられています³。
変換の層を、監視・リリース・構成のプロセスへどう組み込むかを検討することも挙げられています³。
仮例であれば受注番号を相関IDのように扱い、販売管理の出力、変換、保留、倉庫管理への取込の各段階のログに同じ番号を残します。
そうすれば、1件の受注がどこで止まったかを追えます。

本番前の確認は、試験データを流したあとの件数から始めます。
流した件数が、取り込まれた件数と保留・除外された件数の合計と一致するかを見ます。
合わなければ、どこかで行が消えています。
Azure Data Factoryでスキップを有効にしているなら、実行後の出力に出るスキップ行数と、ログに記録された行の内容と理由を、試験データで想定した行と突き合わせます²。
件数が合っていても、保留に入るはずの行が取り込まれていれば、切り詰めや既定値での補完が黙って起きている疑いがあります。

こうした確認は、問題が起きないことを保証するものではありません。
ただ、対応表・試験データ・ログの3つが同じ版のルールでつながっていれば、ずれが出たときに、ルールの誤りなのか、実装の誤りなのか、想定していなかったデータなのかを切り分ける手間が減ります。

項目一覧と連携先の取込仕様を並べても、どの差異を変換で吸収し、どれを業務側の決めごとに回すかは、自社の業務とシステムの事情を踏まえて話し合うほうが早く決まります。

手元の項目一覧と連携先の仕様をもとに、差異の種類の切り分けと、変換できない行を止めるか保留にするかの考え方を一緒に確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
差異の洗い出し	名称・型・桁・コード値・必須・粒度の観点で、項目ごとに対応表へ書く
対応表の列	ツールが求める属性に、差異の種類・変換方式・変換できない場合の扱いを足す
変換方法	型と日付は書式指定、値の加工は式、1対多は行への展開、コードは別の読み替え表
切り詰め	既定値を確かめ、識別に使う項目は変換前に長さを判定して保留へ回す
置き場所	変更頻度・保守の担い手・改修可否・遅延の許容・運用と監視の置き場所で比べる
変換層の責務	形の翻訳だけを置き、値の正否を決める業務ルールは置かない
変換できない行	止める・除外して記録・保留のどれかを先に決め、毎回件数を照合する
変更時の確認	版の更新、設定値の差分、境界値の試験、件数とログの照合

変換の置き場所や保守の分担は、改修できる範囲や提供者との役割分担によって答えが変わり、一般的な考え方だけでは決めきれないことがあります。 現在の連携の構成を伺いながら、変換を基幹側・連携先側・中間のどこに置くと保守と運用の負担がどう変わるかを、比較の軸に沿って整理できます。

よくある質問

項目名が違うだけなら、連携ツールの自動対応（列名一致）で足りますか。

名前が違う時点で、自動対応では結びつかないと考えたほうが安全です。
たとえばAzure Data Factoryのコピーアクティビティでは、既定のマッピングは列名で対応づけ、大文字と小文字も区別します¹。
名前が違う項目は、明示的なマッピングで読み替えを指定します。
また、名前の違いだけに見えても、型・桁・コード値・必須・粒度まで同じとは限りません。
対応表の他の観点も確かめたうえで、本当に名前の読み替えだけで済むと分かれば、専用の変換層を設けずツールの設定で足りる場面もあります³。

桁数が受け取り側のほうが短い項目は、切り詰めてもよいですか。どう検知しますか。

項目の役割で決めます。
得意先名のように、末尾が欠けると他と区別がつかなくなる項目は、切り詰めずに保留へ回すほうが安全です。
Azure Data Factoryでは型変換時の切り詰めを許可する設定（allowDataTruncation）の既定値がtrueなので¹、まず設定を確かめます。
検知は、変換の前に値の長さを判定し、桁を超える行を理由付きで振り分ける形にします。
本番前には、桁ちょうどの値と1文字超える値を試験データに入れて動きを確かめます。

コード体系が違う場合、対応表は誰がどこで持つのがよいですか。

公式の決まりはないため提案になりますが、項目対応表とは別の読み替え表として持つ形が扱いやすくなります。
表の中身はコードの意味を決めている業務側が管理し、表を読み込む仕組みは連携の担当者が保守する、という分担です。
読み替えを変換処理の式に直接書くと、区分が増えるたびに処理の変更とリリースが必要になります。
別表にして版と使い始めの時期を残しておけば、追加の経緯も追えます。

1つの項目を連携先の複数項目に分けるとき、元データが欠けていたらどうしますか。

変換の中で値を補わず、保留に回して元データを直すのが基本です。
欠けた部分を推測で埋めるのは、どの値を正とするかという業務の判断であり、変換の層に置くべきではないとされる業務ルールに当たります³。
住所の分割のように、元データがそろっていても機械的に分けきれない値が出ることもあります。
分割できなかった行をどう扱うかは、対応表の変換できない場合の扱いの列で先に決めておきます。

基幹システムを改修できない場合、変換はどこに置けますか。

連携先側の取込処理か、2つのシステムの中間に置くことになります。
中間の変換層はアプリケーションの部品としても独立したサービスとしても作れ、どちらのシステムも改修せずに成り立ちます³。
その代わり、遅延が加わり、層そのものの管理と保守が増えます³。
連携先側に置く場合も中間に置く場合も、誰が変換を保守し、障害に対応するのかを決めてから作ることが前提です。

連携先のマスタに未登録のコードが来たとき、止めますか、保留にしますか。

単発の未登録コードなら保留にし、業務側が読み替え表やマスタに追加したあとで流し直す形が取れます。
同じ未登録コードがまとまって届いたら、基幹側で区分が追加されたのに読み替え表の更新が漏れている可能性が高いので、連携を止めて表を直すほうが再処理がまとまります。
どちらの場合も、既定値で埋めて通すと誤りの痕跡が残らないため、意味を持つ項目では避けたほうが無難です。

変換ルールを変更したとき、本番前に何を確かめればよいですか。

まず、対応表と読み替え表の版を上げ、変更点を記録します。
次に、マッピングの中身に加えて設定値が環境ごとに揃っているかを見ます。
Azure Data FactoryのtypeConversionのように、作成方法や時期で既定値が変わる設定があるためです¹。
そのうえで境界値の試験データを流し、期待結果と比べます。
最後に、元の件数と取込・保留・除外の合計を照合し、スキップ行数とログの理由を想定と突き合わせます²。

1. 1　出典：Microsoft「コピー アクティビティでのスキーマとデータ型のマッピング（Azure Data Factory & Azure Synapse）」（2026年）
2. 2　出典：Microsoft「コピー アクティビティのフォールト トレランス（Azure Data Factory & Azure Synapse）」（2026年）
3. 3　出典：Microsoft「腐敗防止レイヤー パターン（Azure Architecture Center）」（2026年）
4. 4　出典：Microsoft「マッピングデータフローの派生カラム変換（Azure Data Factory & Azure Synapse）」（2026年）
5. 5　出典：NTTデータ バリュー・エンジニア「データマッピング（用語解説）」（2026年）