システム間のデータ連携で品質が崩れる4つのパターン——API・ETL連携で何が起きるか

システム間のデータ連携（API・ETL・バッチ）は、データが複数のシステムにまたがる業務環境では避けられません。しかし連携の設計が不十分だと、データは移動する過程で壊れる・欠ける・ズレるという形で劣化します。その結果として現場に現れるのは「BIの数字が前日で止まっている」「同じ受注が二重に計上されている」「集計が合わない」といった事象です。本記事では、連携でデータ品質が崩れるパターン、それを防ぐ設計の考え方、そして問題に早く気づくためのチェックを解説します。

データ連携で品質が劣化する4つのパターン

• パターン①：項目定義の変更（スキーマ変更）——送信側システムのAPIの応答形式や、データベースの項目定義が変更されたとき、変更内容と受信側の実装によって、処理がエラーで止まるか、エラーにならないまま一部の項目だけ取り込まれなくなります。厄介なのは後者で、現場では、ある日を境にBIの特定の項目が空欄になる形で現れます。「変更の事前通知がない」「テストが不十分」が根本原因です
• パターン②：タイミングのズレ——夜間の一括処理（バッチ処理）が終わる前に後続の集計が走り、不完全なデータで集計されます。日次の一括処理が深夜に失敗して、翌朝のBIに前日分が反映されないケースも典型例です。数字そのものは表示されるため、誤りに気づきにくいのが厄介な点です
• パターン③：データ型と文字コード（文字エンコーディング）の不整合——送信側が文字列として送った数値を、受信側が数値として受け取ろうとしてエラーになります。文字コード（UTF-8／Shift-JIS）の不一致で日本語が文字化けすることもあります。取引先名が読めない文字列になり、名寄せや宛名印刷で使えなくなります
• パターン④：重複処理——通信が失敗したときの再送や、一括処理の再実行の際に、同じデータを複数回処理してしまう設計になっていると、重複レコードが生まれます。同じデータを2回送っても結果が1回分になる設計（べき等性）が確保されていないと起こります。売上が二重に計上され、実績が過大に見えます

この4つに共通するのは、いずれも「システムはエラーを出していないのに、数字だけが間違っている」状態を生むことです。だからこそ、連携が成功したかどうかだけでなく、渡ったデータが正しいかどうかを確認する設計が必要になります。部門をまたいだ分析でデータを繋ぐ設計そのものについては部門をまたいだ分析ができない原因はデータのサイロ化で扱っています。

品質劣化を防ぐデータ連携の設計原則

• 変更管理とバージョン管理：API仕様は変わるものだという前提で、バージョンを分けて管理し（v1／v2など）、変更を事前に通知する仕組みを整えます。受信側は、知らない項目が増えても無視して処理を続けられる設計にしておきます
• エラー処理と通知：連携エラーが起きたとき、処理が黙って止まるのではなく「記録を残して担当者に通知する」設計にします。再送の仕組みと、再送しても二重にならないかどうかもあわせて設計します
• データ整合性の検証：連携が終わったあとに「送信件数と受信件数が一致するか」「金額の合計が一致するか」を自動で照合します。実装が軽いうえ検知範囲が広く、最初に入れる価値が高いチェックです
• 連携ログの保持：連携の実行記録（日時・件数・エラー有無）を一定期間残し、問題が起きたときに原因をたどれるようにします

その都度データを受け渡す連携（リアルタイム連携）の品質管理

夜間の一括処理が中心だった連携から、APIを使ってその都度データを受け渡す連携が増えるにつれ、品質管理の方法も変わります。一括処理なら「終わってから結果を確認する」ことができますが、常時データが流れてくる方式ではそれができません。データが流れてくるその場で処理する仕組み（ストリーム処理）の中に、品質チェックを組み込む必要があります。またデータを順番待ちの列に一度ためてから渡す仕組み（メッセージキュー。KafkaやAmazon SQSなど）を使う場合は、列にデータが滞留していないか・処理が遅れていないかを常時監視することが基本になります。

この方式で特に注意が必要なのが、処理に失敗したデータが自動で退避される保管場所（Dead Letter Queue、以下DLQ）の管理です。処理できなかったデータはDLQに送られますが、DLQを定期的に確認していなければ「処理されなかったデータが誰にも気づかれないまま溜まっていた」という状態になります。業務画面にエラーが表示されるわけではないため、BIの数字が少しずつ実態からズレていきます。DLQに入ったこと自体は監視できるので、次の設定を用意しておくかどうかで差がつきます。DLQにデータが入ったときに通知を出す設定と、溜まったデータを定期的に確認して再処理する運用ルールを決めておくことが要になります。

データパイプラインの品質テスト設計

連携の品質問題は「起きてから気づく」よりも「変更した時点で自動的に検出する」ほうが被害が小さくなります。そのために有効なのが、変更をリリースする前に自動でテストが走る仕組み（CI/CDパイプライン）に、データ品質のテストを組み込む設計です。データの変換処理や集計処理に手を入れたとき、自動テストが「変更前と変更後で出力が期待どおりか」を確認します。この用途に対応した専門ツール（dbt tests、Great Expectations など）もあります。

テストは「件数が想定どおりか」「必須項目の空欄（NULL）が想定の割合を超えていないか」「参照先が存在するかの確認（参照整合性）」「上位の集計値と内訳の合計が一致するか」といった代表的なチェックから始めるのが実務的です。最初から網羅を目指すと続かないため、業務影響の大きい箇所から段階的に増やすのが現実的です。

問題に早く気づくための4つのチェック

ここまでは「なぜ壊れるか」と「壊れないためにどう設計するか」を扱いました。それでも問題は起きるため、最後に「起きたときに早く気づく」ためのチェックを整理します。前半の4パターンと対応しており、どのチェックがどの問題を捕まえるのかを押さえておくと、監視設計の漏れを防げます。

• 件数の照合：送信元と受信先の件数が一致しているかを自動で突き合わせます。一括処理の途中断・通信エラー・二重取り込みを捕まえられます（パターン②④に対応）。ただし100件送って100件届いていれば、その中の特定の項目がすべて空でも一致と判定されます。件数だけでは項目単位の欠落を検知できないため、下記の空欄率の監視と組み合わせます
• 型変換の失敗の検出：文字列として保存されていた数値や日付を別システムへ渡すとき、変換に失敗して空欄や不正な値に化けることがあります。変換できなかった件数を記録しておくと検知できます。システム刷新後の移行時期に多く発生します（パターン③に対応）。あわせて受信側で主キーの重複がないかを確認しておくと、重複処理（パターン④）を件数照合より確実に特定できます
• 必須項目の空欄率の監視：上流の必須項目が空欄になると、テーブルの結合（JOIN）が成立せず、後続のデータも連鎖的に空になります。空欄率が一定の割合を超えたら通知する設定にしておくと、連鎖する前に気づけます。件数が一致していても起きる項目単位の欠落を捕まえられるため、パターン①の実質的な受け皿になります
• 項目定義の変更の検知：上流システムで項目名が変わったり項目が廃止されたりしたことが下流に伝わらず、エラーも出ないまま値が欠けることがあります。4つの中で最も気づきにくいため、項目定義を変更する際に「このデータを受け取る下流システムへの影響は何か」を確認する手順を業務プロセスに組み込みます（パターン①に対応）

まとめ

本記事では、データ連携で品質が崩れる代表的なパターンを「項目定義の変更・タイミングのズレ・型と文字コードの不整合・重複処理」の4つに整理しました。防ぐ側の設計は、変更管理・エラー通知・整合性の照合・ログ保持の4点が基本になります。そのうえで、件数の照合・型変換の失敗の検出・必須項目の空欄率の監視・項目定義の変更の検知を用意しておくと、問題が起きても早い段階で気づけます。連携の品質設計は一度作れば終わりではなく、連携先のシステムが変わるたびに見直しが必要です。システムを変更するときに「このデータを受け取る下流システムへの影響は何か」を必ず確認するルールを持っている組織ほど、BIやAIに供給されるデータが安定し、現場の数字への信頼も保たれます。データパイプラインの品質設計についてはBFT Insightにご相談ください。