「先月の売上、システムAとBで数字が違うんですが」——月末の締めで経理からそう指摘され、そこから半日かけて原因を追う。連携そのものはエラーも出さず、毎日正常に動いていたはずなのに。運用が続くほど、相手システムの仕様変更や例外的なデータ、処理の一部失敗によって、ずれは静かに忍び込みます。そして多くの場合、それが発覚するのは締めや棚卸、あるいは顧客からの指摘の場です。そうなる前に気づくための仕組みが、データの突合（照合）です。なお、リリース前の検証手順はデータ連携のテスト（検証）の方法で解説しているため、本記事は運用中に継続して行う突合の設計と自動化に絞ります。
目次
テストで正しく動くことを確認しても、運用が始まればデータは変化し続けるため、突合は継続的に必要になります。 連携は一度作れば終わりではありません。相手システムがバージョンアップして項目が増える、これまで来なかった値が来る、夜間の処理が一部だけ失敗する——こうした変化は日常的に起こります。突合の仕組みがなければ、これらに気づくのは誰かが困ったときです。逆に、日次で小さく確認できていれば、原因の特定も対応も容易になります。まずは、突合が果たす役割を整理しておきましょう。
連携がエラーなく完了していても、中身が正しいとは限りません。たとえば抽出条件に「前日分」と書くべきところを「当日分」にしていれば、対象がないまま0件で正常終了します。処理は成功、しかしデータは届いていません。この「静かな失敗」を検出できるのは、結果の数字を突き合わせる作業だけです。エラー監視だけでは不十分、という認識が突合の出発点になります。実際、連携が「正常終了」と記録されているのに数字が合わないという報告は、現場では珍しくありません。
差異に気づくのが翌日なら、確認すべき範囲は前日分だけです。一方、1か月後に気づけば、1か月分のデータを遡って調べることになります。しかもその間に誤ったデータをもとに業務が進んでいれば、影響範囲はさらに広がります。突合の価値は、この「気づくまでの時間」を短くすることにあります。監視の目的は完璧な防止ではなく、早期の発見だと捉えると設計しやすくなります。
突合と言っても、全データを1件ずつ比較する必要はありません。むしろ全件比較は処理も重く、運用として続きません。目的に応じて粒度を選び、軽い方法から段階的に精度を上げるのが実務的です。代表的な4つの方法を整理します。
| 方法 | 見るもの | 向く場面 |
|---|---|---|
| 件数の照合 | 連携元と連携先のレコード件数 | 日次の基本チェック。取りこぼしの検出 |
| 合計値の照合 | 金額・数量などの合計 | 数字の正しさが業務に直結する場合 |
| キー単位の照合 | 伝票番号などのキーの有無 | どのレコードが欠けたかを特定したい場合 |
| 差分の照合 | 項目値の不一致 | 更新が正しく反映されているかの確認 |
もっとも手軽で効果が大きいのが件数の照合です。連携元から100件出したのに連携先に98件しかなければ、その時点で異常が分かります。日次で件数だけ比べる仕組みなら、短期間で構築できます。まずここから始め、必要に応じて粒度を上げていくのが実務的です。件数という単純な指標でも、取りこぼしの大半は検出できます。
件数が合っていても、値が違えば業務上は問題です。金額や数量のように積み上げて意味を持つ項目は、合計値を突き合わせます。ただし合計値だけを見ていると、プラスとマイナスの誤りが打ち消し合って一致してしまうことがあります。たとえばA社の請求を1万円多く、B社を1万円少なく取り込んでいれば、合計は完全に一致します。合計が合ったからと安心せず、件数と併せて見るのが安全です。会計や在庫のように数字の正確さが要求される領域では、この照合が欠かせません。小数の丸めや通貨単位の扱いで微差が出る場合は、許容範囲を決めておきます。
件数や合計にずれが出たら、どのレコードが原因かを特定します。伝票番号や明細番号といったキーを両側で並べ、片方にしかないものを抽出します。ここまで自動化できていれば、原因調査の時間は大幅に短縮できます。差異の一覧が自動で出てくる状態が理想です。担当者は原因の調査から始められ、どこが欠けたかを探す作業から解放されます。
やり方が決まったら、運用に載せるための設計をします。突合の仕組みが続かなくなる最大の原因は、技術的な問題ではなく「通知が多すぎて見なくなる」ことです。ここを曖昧にすると、せっかく作った仕組みが形骸化します。次の3点を決めておきましょう。いずれも技術的な設定ではなく、業務側との合意が必要な項目です。
日次・週次・月次のどれで回すかは、業務の締めと影響の大きさで決めます。金額が動く連携は日次、参照系のデータは週次でも足りることがあります。頻度が高いほど早く気づけますが、確認の手間も増えるため、自動化とセットで考えます。締めのタイミングの直前に一度回す設計も有効です。締め後に差異が判明すると修正の手間が跳ね上がるため、その前に確認できる価値は大きいです。
タイミングのずれで一時的に数字が違うのは正常な場合もあります。「常に完全一致」を条件にすると、正常な差異でも通知が飛び、やがて誰も見なくなります。どこまでを許容し、どこからを異常とみなすかを決めておくことが、運用を続ける条件です。この線引きは業務部門と合意しておきます。「1件でも違えば異常」なのか「合計が0.1%以内なら許容」なのかは、業務の性質によって変わります。
差異が出たとき、どちらの数字を正しいとみなすかを事前に決めます。基準がなければ、毎回「どちらが合っているのか」から議論が始まります。多くの場合、データが最初に発生するシステムが基準になります。ここを決めておけば、修正の方向も自動的に定まります。基準側のシステムを文書に明記しておくと、担当者が変わっても運用が揺れません。
検知した後どうするかまで設計しないと、通知が溜まるだけになります。差異の性質によって、人が判断すべきものと自動で処理できるものが分かれます。対応の型を3つに分けて決めておきましょう。すべてを人が見る前提にすると、件数が増えたときに回らなくなります。
差異の内容と対象を通知し、担当者が原因を確認して対応します。通知には「何と何がどれだけ違うか」「対象のキー」を含めると、確認が速くなります。宛先と対応の責任者を決めておくことも重要です。誰の担当か曖昧な通知は放置されます。宛先はグループアドレスだけにせず、一次対応者を決めておくのが確実です。
処理の失敗による取りこぼしのように、原因が明確なものは自動での再実行を組み込めます。ただし、同じ処理を二度流しても壊れない作り（重複防止）が前提です。自動修正の範囲は、影響が読める範囲に限定するのが安全です。判断が必要なものは人に回し、自動処理の対象は明文化しておきます。
差異の発生を記録しておくと、特定の取引先や商品、曜日に偏っているといった傾向が見えてきます。個別対応の繰り返しから、根本原因の解消へ進めるのはこの記録があるからです。突合は検知だけでなく、改善のためのデータ収集でもあります。
最後に、実際に自動化する手順を示します。突合は「全経路を完璧に」を目指すと着手できません。影響の大きい経路から、軽い方法で始めて広げるのが定石です。2つのステップに分けて進めます。
影響の大きい1つの連携経路を選び、件数の照合と通知だけを自動化します。ここで「異常時だけ知らせる」形が作れれば、日常の確認作業がなくなります。効果が実感できれば、次の経路へ広げる判断もしやすくなります。最初の1本を作ることが最大の山です。2本目以降は同じ型を流用できるため、構築の負担は大きく下がります。
件数照合が回り始めたら、金額の合計、さらに差異明細の抽出へ広げます。粒度を上げるほど原因特定は速くなりますが、設計の手間も増えます。業務の重要度に応じて、どこまでやるかを判断しましょう。すべての経路を最高精度にする必要はありません。金額が動く連携は厚く、参照系は件数だけ、という使い分けが現実的です。
データ連携について詳しく学ぶ（無料ダウンロード）
システム間の突合と通知は、データ連携基盤「ASTERIA Warp」（累計10,000社超）を使えばプログラミングなしで組み立てられます。100種類以上のアダプターで基幹システム・SaaS・DB・ファイルからデータを取得し、件数や合計値の比較、キー単位の差分抽出、差異が出たときの通知までをフローとして構築できます。スケジュール実行で日次の自動突合が組め、差異一覧をファイルやメールで出力する処理も設定で用意できます。実際にマックス株式会社は検収データと請求データの突合を自動化し、工数を最大90%削減しました（ある取引先では8時間かかっていた作業が50分に短縮）。まずは1経路の件数照合から試してみてください。
Q. テストをしたのに、運用中も突合が必要なのですか？
A. 必要です。運用が始まればデータは変化し続けます。相手システムの仕様変更や想定外の値、処理の一部失敗はテストでは想定できません。エラーなく完了しても中身が正しいとは限らないため、数字の突き合わせが要ります。
Q. 何を突き合わせればよいですか？
A. まず件数の照合から始めます。連携元と連携先のレコード件数を比べるだけで、取りこぼしを検出できます。金額や数量のように積み上げて意味を持つ項目は合計値でも照合し、ずれが出たらキー単位で欠けた明細を特定します。
Q. 通知が多すぎて見なくなりそうです。
A. 許容差の設計が鍵です。タイミングのずれによる正常な差異まで通知すると、やがて誰も見なくなります。どこまでを許容し、どこからを異常とするかを業務部門と合意し、異常時のみ通知する形にしてください。
Q. 差異が出たら自動で直してよいですか？
A. 処理の失敗による取りこぼしのように原因が明確なものは、自動での再実行を組み込めます。ただし同じ処理を二度流しても壊れない作り（重複防止）が前提です。判断が必要なものは人に回し、自動修正は影響が読める範囲に限定します。
連携をリリースした後も、相手システムの変更や例外データ、処理の失敗によって数字は少しずつずれます。エラー監視だけでは「静かな失敗」を検出できないため、運用中の突合が必要です。まず件数の照合から始め、金額は合計値で、原因特定はキー単位で。設計では頻度・許容差・どちらを正とするかを決め、差異が出たときは通知・限定的な自動再処理・記録による傾向把握で対応します。突合の自動化には、データ連携基盤「ASTERIA Warp」も活用できます。
▼ 件数照合と差異通知を、まず1経路で試す ASTERIA Warpは全機能を試せる無料体験版をご用意。件数照合や差異通知の自動化も、サーバー準備不要ですぐに体験できます。 |
PM・SE・マーケティングなど多彩なバックグラウンドを持つ「データ連携」のプロフェッショナルが、専門領域を超えたチームワークで「データ活用」や「業務の自動化・効率化」をテーマにノウハウやWarp活用法などのお役立ち情報を発信していきます。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
