LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

データ品質とデータオブザーバビリティとは——監視対象と目的の違い

データ品質・データオブザーバビリティ（データ監視）の導入とは、データパイプラインを流れるデータの鮮度・網羅性・正確性を継続的に点検し、異常が起きた時点で検知・通知できる仕組みを構築する取り組みを指します。データマネジメントの知識体系を整備する国際的な非営利団体DAMA Internationalは、データ品質を「データが利用目的に適合している度合い」と位置づけています^*1。オブザーバビリティを提供するMonte Carlo社は、データオブザーバビリティを「組織のデータの健全性を理解する能力」と定義しています^*2。

なぜ今、データ品質と監視がセットで語られるのか

データ基盤には日々、複数のシステムやAPIから多様な形式のデータが流れ込みます。連携元の仕様変更・欠損・重複が発生すると、それに気づかないまま集計やAIモデルの入力に使われ、誤った意思決定につながるおそれがあります。

データ品質は「どの基準を満たすべきか」という定義の話であり、データオブザーバビリティは「その基準が崩れていないかをどう継続的に把握するか」という運用の話です。両者は対になる概念であり、片方だけを整えても効果は限定的です。

マスタデータ管理やデータガバナンスとの役割分担

マスタデータ管理（MDM）は顧客・商品などの基準データそのものを一元化・統合する取り組みです。データガバナンスはデータの管理方針・責任体制を定める取り組みです。これに対し本記事が扱うデータ品質監視は、パイプラインを流れるデータの鮮度・網羅性・正確性を継続的に点検し、異常の発生を検知する取り組みを指します。基準データの統合や方針整備が済んでいても、日々の流通データが壊れていないかを監視する仕組みは別途必要です。

データ品質を測る6つの観点——完全性・正確性・一貫性・鮮度・妥当性・一意性

データ品質を評価する際の観点（ディメンション）は、データマネジメントの実務で広く参照されています。DAMA Internationalが編纂するデータマネジメント知識体系「DMBOK」では、データ品質を複数の側面から捉える考え方が示されています^*1。実務でよく用いられる代表的な6観点は以下の通りです。

観点は独立ではなく相互に影響する

この6観点は互いに独立しているわけではありません。たとえば連携元システムの仕様変更で必須項目が欠落すると、完全性が崩れるだけでなく、既存の集計ロジックとの一貫性も損なわれます。1つの異常が複数の観点にまたがって影響することが多いため、観点ごとに個別のチェックを持つだけでなく、パイプライン全体を通して継続的に状態を把握する仕組みが必要になります。この「継続的な把握」を担うのが、次章で説明するデータオブザーバビリティです。

データオブザーバビリティの5本柱——フレッシュネス・ボリューム・スキーマ・分布・リネージ

データオブザーバビリティという言葉を提唱したMonte Carlo社は、2019年に公開した定義の中で、監視すべき対象を5つの柱として整理しています^*2。

1. フレッシュネス（Freshness）：テーブルがどの程度最新の状態か、更新の頻度が想定どおりかを確認します。
2. ボリューム（Volume）：データテーブルの完全性、データソースの健全性を件数の変化から確認します。
3. 品質（Quality）：NULL値の割合や値の一意性など、データそのものの状態を確認します。
4. スキーマ（Schema）：テーブルの構造（列名・型・構成）に変更が起きていないかを確認します。
5. リネージ（Lineage）：あるテーブルの異常が、どの上流・下流のテーブルに影響するかを追跡します。

フレッシュネス・ボリューム・スキーマの3つは、データが「いつ・どれだけ・どんな構造で」届いているかを機械的に検知できる対象です。品質はデータの内容そのものの状態を指し、前章の6観点と重なる部分です。リネージは異常が起きた際に影響範囲を特定するための系統情報であり、単体の監視対象ではなく他の4本柱を横断して原因を追跡する役割を担います。

ETLパイプラインのどこに監視を組み込むか

データオブザーバビリティは、抽出・変換・格納（ETL/ELT）のパイプライン全体に組み込みます。抽出直後の生データに対してボリュームとスキーマを確認し、変換後のテーブルに対して品質とフレッシュネスを確認する構成が一般的です。異常が発生した際は、リネージ情報をたどることで「どのダッシュボードやAIモデルまで影響が及ぶか」を特定できます。

テストと監視の違い——dbt testと異常検知は何を分担するのか

データ品質を扱う際、「テスト」と「監視」という2つの言葉が使われますが、両者は役割が異なります。データ変換ツールdbtの公式ドキュメントは、データテストを「モデルや他のリソースについて行う主張（assertion）」と定義しています^*3。具体的には、あるカラムに重複がないかを主張するテストは、実際に重複を検索するSQLクエリとして実行され、結果として返る行が0件であればテストは合格します^*3。

dbtにはあらかじめ組み込まれた汎用テスト（unique・not_null・accepted_values・relationships）があり、モデル定義のYAMLファイルにカラムごとの検証ルールとして宣言できます^*3。これらは「事前に定義した既知の基準」を検証する仕組みです。

テストが検知できるのは「既知の異常」まで

テストは、開発者が事前に想定したルールに違反していないかを検証する仕組みです。想定していなかった種類の異常、たとえば連携元システムが予告なく仕様変更した場合や、特定の地域だけデータが欠落し始めた場合など、事前にルール化していない事象は検知できません。

これに対しデータオブザーバビリティは、統計的な傾向から自動的に正常範囲を学習し、その範囲から外れた場合にアラートを出す仕組みです。Monte Carlo社は、データテストだけでは検知できない問題領域が相当な割合残るとし、テストとオブザーバビリティは同じ「信頼できるデータ」という目標を、異なる方法で達成する補完的な手法だと位置づけています^*4。テストが得意とするのは「知っている異常」の検証であり、オブザーバビリティが得意とするのは「知らない異常」の検知です。

両方を併用する設計が現実的

実務では、テストと監視のどちらか一方を選ぶのではなく、両方を段階的に組み合わせる設計が現実的です。まず重要なテーブルの主要カラムにdbt test等でルールベースの検証を組み、次に異常検知型の監視を導入して未知のリスクに備える、という順序が無理のない進め方です。

導入ステップと運用体制——誰が異常に対応するのか

データ品質・データオブザーバビリティの導入は、ツールを入れるだけでは機能しません。以下のステップで、対象範囲の絞り込みから運用体制の設計まで順に進める必要があります。

ステップ1：監視対象テーブルの優先順位付け

全社の全テーブルを一度に監視対象にすることは現実的ではありません。経営指標や顧客への提供サービスに直結する重要テーブルから優先的に対象を選びます。上流のマスタや基幹連携データほど、異常が下流の広範囲に伝播しやすいため優先度が高くなります。

ステップ2：品質基準とアラート閾値の定義

前章の6観点をもとに、テーブルごとに「何を満たせば正常か」を定義します。フレッシュネスであれば「通常は1時間ごとに更新される」、ボリュームであれば「通常の件数変動幅」といった基準を明文化し、アラートを出す閾値をチームで合意します。

ステップ3：ツール導入とアラート経路の設計

dbt testのようなルールベース検証と、異常検知型の監視ツールを組み合わせて導入します。アラートは検知して終わりではなく、担当者に届き対応につながる経路として設計する必要があります。通知先が曖昧だと、アラートが発生しても誰も対応せず放置される事態が起こります。

誰が運用するか——専門知識と工数の壁

導入後の運用には、データパイプラインの構造を理解した担当者に加えて、アラートの妥当性を判断できるスキルが必要です。アラートが多すぎると担当者が疲弊し重要な異常も見過ごされる「アラート疲れ」が起こり得ます。一方でアラートを絞りすぎると検知漏れにつながります。この閾値調整には、データ基盤の構造理解とオブザーバビリティ運用の両方の知見が求められ、専任の担当者を置けない体制では継続的な調整が滞りがちです。

外注の委託範囲と発注準備——内製で難しい部分をどう切り出すか

データ品質監視の内製が難しい理由は、パイプライン構築の知識だけでなく、品質基準の設計・監視ツールの運用・アラート対応フローの整備という複数分野の知見を同時に必要とする点にあります。専門知識が不足したまま導入すると、アラートが機能しない、あるいは誤検知が多発して現場が対応を止めてしまうといった事態につながりかねません。

外注に委託できる範囲

外部の開発パートナーには、主に以下の業務を委託できます。

• 既存パイプラインの調査と、監視対象テーブルの優先順位付け支援
• 品質基準・アラート閾値の設計とdbt test等の実装
• 監視ツールの選定・導入・既存基盤への組み込み
• 導入後の異常対応フロー・通知経路の設計支援

一方で、どのテーブルが経営上重要かという業務優先度の判断や、検知した異常に対して実際にどう対応するかの最終判断は、発注側の業務理解が前提となるため、委託先に全面的に任せることは難しい領域です。

発注前に準備しておくこと

発注時の要件定義を明確にするため、以下を事前に整理しておくと外部パートナーとの合意形成がスムーズになります。

• 現在使用しているデータ基盤・ETLツールの構成（クラウド・オンプレの別、使用製品）
• 監視の優先対象としたいテーブル・データソースの候補
• 過去に発生したデータ異常のトラブル事例（あれば具体的に）
• アラート受信後に対応する担当部署・担当者の想定

これらが未整理のまま発注すると、委託先が要件を推測して設計することになり、実態に合わない監視基準ができてしまうおそれがあります。発注前の整理が、導入後の運用負荷を左右します。

まとめ——データ品質監視を外注で進める3つの判断軸

本稿では、データ品質の6観点とデータオブザーバビリティの5本柱、テストと監視の役割の違い、導入ステップと外注範囲を整理しました。要点を3つに集約すると次の通りです。第一に、データ品質は「何を満たすべきか」の定義であり、データオブザーバビリティは「その定義が崩れていないか」を継続的に把握する運用です。第二に、テストは既知の基準を検証する仕組みであり、監視は未知の異常を検知する仕組みであるため、両方を段階的に組み合わせる設計が現実的です。第三に、内製が難しい部分は品質基準の設計・ツール運用・アラート対応フローの整備であり、業務優先度の判断や異常対応の最終判断は発注側に残る領域として整理しておく必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：DAMA International「DAMA-DMBOK: Data Management Body of Knowledge」（データマネジメント知識体系の公式解説ページ、https://www.dama.org/cpages/body-of-knowledge）
2. *2　出典：Monte Carlo Data「What Is Data Observability? 5 Key Pillars To Know」（2019年公表・2026年更新版、https://montecarlo.ai/blog-what-is-data-observability）
3. *3　出典：dbt Labs「About data tests」dbt公式ドキュメント（https://docs.getdbt.com/docs/build/data-tests）
4. *4　出典：Monte Carlo Data「Data Observability Vs Data Testing: Everything You Need To Know」（https://montecarlo.ai/blog-data-observability-vs-data-testing-everything-you-need-to-know/）

Tweet