データ不整合の原因と対策を体系的に整理する
データ不整合は「たまたま起きる事故」ではありません。同時更新・分散処理・キャッシュ・非同期など、現代のシステム構造と密接に結びついた、再現性のある失敗です。
本記事では、データ不整合の典型パターン、設計・実装上の原因、よくある失敗例、検知と修復（Write Repair／Async Repair）、そして防止のチェックリストまでを一連の流れで整理し、「不整合は防げるもの」と「前提にして設計するもの」を切り分ける視点を提供します。
データ不整合とは何か
「不整合」とは、期待する正しい状態と、実際に保存されている状態のズレです。
例えば、注文が成功しているなら在庫が減り、決済が記録され、購入履歴にも表示される――これが整った状態です。これらのどこかが欠けている、あるいは関連テーブルや他システムとの対応関係が崩れている状態が、不整合です。
症状はさまざまです。
- 画面表示が正しくない
- 集計が合わない
- 二重請求が起きる
- 在庫がマイナスになる
- 同じ操作が二重反映される
特徴は、エラーとして表に出ないことです。成功レスポンスでも裏では失敗している、あるいは失敗レスポンスでも一部は書き込まれている、といった食い違いが起こり得ます。
影響はユーザー体験の悪化にとどまりません。返金対応や調査工数の増加、法務・会計上のリスク、さらには指標が信用できなくなることによる意思決定の誤りにまで波及します。
さらに厄介なのは、不整合が別の処理の前提を壊し、後続の不整合を連鎖させることです。だからこそ、早期に被害拡大の防止し、影響範囲を閉じ込める設計と運用が重要になります。
不整合が起きる典型パターン
不整合は、ある程度パターン化できます。現象を分類できれば、原因仮説と対策の当たりを早く付けられます。
まず確認すべきは、「何がズレているのか」です。
- 単一レコードか、集計か
- 片側だけ欠けているのか
- 古い値が見えているのか
- 二重になっているのか
典型パターンは、次の5つに集約できます。
1. 同時更新・競合（レースコンディション）
共有データに複数のリクエストが同時に更新をかけると、上書きや取りこぼしが起きます。
典型は「現在値を読んで計算し、更新する」という処理が並列に走るケースです。後勝ちで前の更新が消えます。
発生条件は、ロックや楽観ロックによる競合検知がないことです。分散環境では同時性が増え、単体テストでは見えにくくなります。
対策は、適切な分離レベルや行ロック、楽観ロック、キューによる直列化などです。さらに「同時に起きても正しい結果に収束する」冪等設計に寄せると、事故の根が小さくなります。
2. 部分更新・更新漏れ（undefined／NULL混入）
複数フィールド更新の途中失敗や、部分更新仕様による意図しない上書きが原因になります。実務で多いのは、更新オブジェクトにundefinedやNULLが混入し、ストレージ側でエラーになるケースです。失敗が握りつぶされると、成功に見える不整合になります。
対策は、未指定とNULLの意味を明確化すること。入力を正規化し、DB側ではNOT NULLやCHECK制約で止めます。部分更新は便利ですが、更新契約が曖昧だと温床になります。
3. 複数システム間の同期ズレ
複数のデータベースや外部SaaSが絡むと、「片方だけ成功」は避けられません。さらに再試行が二重処理を生むことがあります。分散システムではズレを前提に設計する必要があります。
対策の基本は冪等性と状態遷移の可視化です。Idempotency Key、ステートマシン、Sagaなどで「どこまで進んだか」を記録し、途中から再開できるようにします。
4. キャッシュとDBの不整合
キャッシュ優先読み取りと無効化漏れが原因になります。TTL頼みの設計では、古い値が残る前提になります。
対策は、キャッシュを最終的な正としない設計にすること、更新経路を一本化すること、無効化漏れを検知するメトリクスを持つことです。
5. 非同期処理・イベント駆動のズレ
遅延、順序逆転、重複配送は避けられません。
Exactly onceの保証は基盤だけでは完結せず、アプリケーション側での冪等設計が不可欠です。冪等処理、重複検知、キー単位の順序保証が基本です。
不整合を生む設計・実装上の原因
不整合はデータだけの問題に見えて、根は設計・実装の前提ミスやガード不足であることが多いです。原因を層ごとに分解して、再発防止に直結する打ち手へ落とします。
同じ不整合でも、どこで防ぐべきだったかを分解すると、入力境界、アプリケーションロジック、DB制約、トランザクション境界、外部連携の責務分担に行き着きます。復旧対応だけで終わらせず、どの層で止めるのが最も安く確実かを考えるのがディレクションの要点です。
現場では「バリデーションはフロントでやっているから大丈夫」「アプリでチェックしているから制約はいらない」という判断が事故の入り口になりがちです。入力は多経路（管理画面、バッチ、外部連携）になり、アプリのチェックは抜けやすく、仕様変更で崩れます。
再発防止の基本は、防御線を多層にすることです。境界での検証、DBでの制約、トランザクションと冪等性、監視と修復というように、すり抜けても次で止まる作りにします。
バリデーション不足（入力・更新・境界）
バリデーション不足は、間違ったデータが入り続けること以上に、「あるべき更新が行われない」「状態遷移が破られる」ことを招きます。特にAPI境界やサービス境界、バッチ境界など、データがシステムに入る入口ごとに検証の粒度が揃っていないと、不整合は簡単に再発します。
部分更新では、未指定、undefined、NULL、空文字、0などの意味が混ざると危険です。未指定は変更しない、NULLは消す、というように契約を明文化し、それに沿って入力を正規化します。型がある言語でも、Partialのような表現はundefined混入を許しやすいので、更新用DTOを分ける、サーバ側でundefinedを除去してから保存するなどの対策が効果的です。
ドメイン不変条件もバリデーションの対象です。例えば在庫は0未満にならない、注文は支払い前に発送状態にならない、といった制約は画面だけでは守れません。状態遷移をサーバ側で厳密にし、例外ルートも含めてどこで不変条件を保証するかを決める必要があります。
▼APIについてもっと詳しく知りたい
⇒ API｜用語集
制約不足（主キー・外部キー・ユニーク・NOT NULL）
DB制約が弱い環境では、入ってはいけないデータが静かに蓄積され、問題が顕在化したときには修復コストが大きく膨らみます。アプリケーションのチェックは仕様変更や例外処理の追加で簡単に抜け道が生まれるため、DBは「最後の砦」として振る舞う設計が望まれます。
代表的な打ち手は次の通りです。
- ユニーク制約で重複生成を物理的に防ぐ
- 外部キーで参照整合性を強制する
- NOT NULLやCHECK制約で欠損や範囲外値を防止する
特にユニーク制約は冪等性設計の基礎となり、リトライや多重リクエストが発生しても二重登録を構造的に防げる点で重要です。
一方で、制約を後付けする場合は既存データに違反があると適用できないため、段階的なクレンジング計画とあわせて設計的な強化を進める必要があります。
制約は単なるDB設定ではなく、業務ルールを永続層に固定化する意思決定である、と捉えると位置づけが明確になります。
トランザクション不備（分散トランザクション含む）
単一DBであっても、トランザクション境界が曖昧であれば途中コミットや分割更新が発生し、片方だけが更新された状態が静かに残ります。
複数テーブルを更新する処理では、「どこまでを原子的に扱うべきか」を設計段階で定義し、例外発生時に確実にロールバックされる実装になっているかを確認する必要があります。
複数サービスや複数DBをまたぐ場合には、一般的な分散トランザクションを採用することが難しいケースも多いため、
- Saga
- ステートマシン設計
- TCC
といった補償型の設計を採用し、失敗を前提に整合性を回復できる構造を持たせます。
ここで鍵になるのがリトライ設計と冪等性であり、リトライ可能なエラーと不可能なエラーを分類したうえで、リクエスト単位の一意キーにより重複処理を吸収できる設計を行って初めて、トランザクションの弱さを補完できます。
データ不整合の検知と修復（Write Repair／Async Repair）
不整合をゼロにできない前提では、早く見つけて安全に直す仕組みが重要です。同期的に直すWrite Repairと、後追いで直すAsync Repairを使い分けます。
検知の基本は、期待する不変条件を機械的にチェックできる形に落とすことです。例えば参照が必ず存在する、合計値が明細の和と一致する、状態遷移がルール通りである、といった条件をクエリやバッチで検査できるようにします。監視としては、整合性チェックの件数、修復件数、同一キーのリトライ回数、重複作成の疑いなどをメトリクス化すると、障害の兆候が早く見えます。
Write Repairは、書き込み処理の流れの中で不整合を作らない、またはその場で直すやり方です。代表はリトライですが、リトライ可能なエラーを見極め、冪等性キーやユニーク制約で多重処理を防ぎながら行う必要があります。状態管理（処理IDと現在状態）を持つと、途中まで進んだ処理を安全に再開でき、結果としてWrite Repairの成功率が上がります。
Async Repairは、通常処理と独立して後から突合と修復を行うやり方です。定期バッチでDB間を照合して不足分を補う、終了状態になっていない処理を再実行して完了させる、といった形になります。注意点は、バッチ自体も少なくとも一回実行や多重起動の可能性があるため、修復処理も冪等であること、そして本処理と競合して上書きしないようロックや状態確認を入れることです。
実践チェックリスト
設計レビュー・実装・運用の各フェーズで抜けが出ないように、原因パターンと対策をチェック項目に落として再利用可能な形にします。チェックリストは一度作って終わりではなく、障害のたびに項目を追加して進化させると効果が出ます。
設計
- 強整合が必要な領域を定義しているか
- Single Source of Truthが明確か
実装
- 同時更新対策はあるか
- 更新契約は明確か
- 冪等性キーを設計しているか
- トランザクション境界は適切か
運用
- 定期整合性チェックを実施しているか
- 修復ジョブは冪等か
- 不整合時の隔離手順があるか
データ連携基盤で整合性リスクを抑えるという考え方
ここまで見てきたように、データ不整合の多くは「複数システム間の連携」や「非同期処理」「再試行」「更新順序のズレ」といった、分散処理特有の構造から生まれます。個別のアプリケーション側で対策を積み重ねることも重要ですが、データ連携そのものを制御できる基盤を持つことで、不整合の発生確率や影響範囲を大きく抑えることができます。
例えば、HULFT Square のようなデータ連携基盤を利用すると、API連携・ファイル連携・イベント処理などを統合的に管理できるため、システムごとにバラバラだった連携ロジックを一元化できます。処理の状態管理や再実行、エラーハンドリング、スケジュール制御などを共通の仕組みとして扱えるため、「どこまで処理が進んだのか分からない」「途中で失敗しても気づかない」といった運用上のリスクを減らすことが可能です。
特に、複数システム間でデータを受け渡す業務では、処理フローを可視化し、失敗時の再実行や補完処理を設計できることが、整合性を維持するうえで重要になります。データ連携基盤を活用することで、各システムに分散していた連携ロジックを整理し、処理の状態や実行履歴を追跡できる構造を作ることができます。
結果として、アプリケーションごとに個別対策を積み重ねるのではなく、連携レイヤーで整合性リスクをコントロールする設計が可能になります。
▼データ連携 / データ連携基盤についてもっと詳しく知りたい
⇒ データ連携 / データ連携基盤｜用語集
まとめ
データ不整合は偶発的な事故ではなく、同時更新や分散処理、非同期連携といった構造から必然的に生まれる再現性のある問題である以上、ゼロを目指すのではなく「どこで止めるか」「どこで回収するか」をあらかじめ設計に組み込む姿勢こそが、実務的で持続可能な向き合い方になります。
ぜひこの記事を参考に、「絶対にズレてはいけないデータは何か」「それはどの層で守られているか」「すり抜けた場合にどこで検知し修復できるか」という三つの問いに具体的に答えられるかを確認し、曖昧な境界があればそこに防御線を一段追加することから着手してみてください。
整合性は注意力ではなく構造で守るものだという前提に立ち、一箇所でも責任境界を明確にするだけで、次の不整合は確実に小さくできます。
記事を書いた人
