「先週の売上ダッシュボード、数字がおかしくないですか」。営業部長からそう連絡が来て、初めてデータ基盤の異常に気づく。データ基盤を運用している方なら、一度は経験があるのではないでしょうか。
調べてみると、原因は連携元システムの列名変更だったり、夜間に自動実行される集計処理が静かに失敗していたことだったりします。厄介なのは、データを運ぶ処理（パイプライン）がエラーで停止してくれないケースです。処理は成功扱いで終わり、中身だけが空だったり古かったりする。この状態は、誰かが数字を見て違和感を持つまで発見されません。
この、気づけないという問題に正面から取り組むのがデータオブザーバビリティです。データ品質の監視を、人の目視から仕組みに移す考え方だと言い換えてもいいと思います。
データオブザーバビリティ（data observability）とは、データ基盤を流れるデータが期待どおりの状態で届いているかを継続的に把握する仕組みです。日本語では「データ可観測性」と訳されることもあります。
もともとはサーバーやアプリケーションの運用で使われてきた考え方です。CPU使用率やエラー率を常時監視して、障害の予兆を掴む。あの発想をデータそのものに当てはめた、と考えるとわかりやすいはずです。
サーバー監視との違いは、見る対象です。サーバーは動いているかどうかを見ます。ところがデータ基盤では、処理が正常終了しても中身だけ壊れていることがあります。処理の成功と失敗だけを見ていても、データの異常は捕まえられません。
だからこそ、データそのものの状態を見に行く必要があります。件数、更新時刻、列の構成、値の分布。見るべきものは決まっています。データの健康診断にあたるこれらの項目を、自動で継続的に測ります。
データの流れそのものをどう設計するかは、データパイプラインとは？設計の3軸と運用の要点を図解で解説で扱っています。この記事は、その流れを流れたあとのデータをどう見張るかに絞ります。
何を見ればデータの健康状態がわかるのか。実務では次の5つの観点に整理されることが多く、5つの柱（Five Pillars）と呼ばれます。
図の5つを、具体例つきで補足します。
最初の4つは異常に気づくための観点、リネージは気づいたあとに動くための観点です。この違いを押さえておくと、導入の順番を迷わなくなります。
この5分類はMonte Carloが提唱したもので、多くのベンダーがほぼそのまま踏襲しています。分布の代わりに品質を独立した柱に立てる整理もありますが、細かな名称より、鮮度・量・構造・中身・つながりの5面を押さえておけば実務では困りません。
なぜ今、この仕組みが注目されているのか。やや古い調査ですが、データ専門職200人を対象にした2023年3月の調査（Monte Carlo / Wakefield Research）に、状況を端的に示す数字があります。
冒頭の営業部長から指摘される場面は、例外どころか多数派だということです。データ基盤を作った側が最後に知る構図では、現場のデータへの信頼は積み上がりません。
規模の問題もあります。監視ツールのMonte Carloが、自社が監視する1,100万件超のテーブルから集計した数字（2026年公開）では、データ品質の異常はテーブル10件あたり年1件の頻度で起きています。2020年と2023年の計測では15件あたり1件だったので、1テーブルあたりの発生率が5割ほど上がった計算です。
原因の内訳も参考になります。同じ集計では、データを運ぶ処理（パイプライン）の実行失敗が26.2%、実データ側の自然な変動が20.0%、取り込みの不具合が16.6%、基盤の不安定が15.2%、過去分の再取り込み（バックフィル）など意図的な変更が14.2%、スキーマ変更が7.8%でした。
読み取れることが2つあります。1つは、取り込みの不具合と基盤の不安定だけで3割強を占めること。コードレビューを厳しくしても防げない種類の異常が、確実に存在します。
もう1つが、実データの変動と意図的な変更を足した約34%は、そもそも障害ではないという点です。月末に件数が増えた、こちらの都合でバックフィルした。監視はこれらも異常として鳴らします。後述するアラート疲れの根っこは、ここにあります。
導入も進んでいます。2026年のGartner Market Guideが引用する2025年の調査（State of AI-Ready Data Survey）では、データ活用とAIの責任者のうち53%がデータオブザーバビリティツールを導入済み、43%が18か月以内の導入を予定と回答しています。ただし調査の回答者は大企業に寄っているため、中堅企業の実感とは差があるはずです。生成AIの活用が本格化するほど、入力になるデータの信頼性が問われます。この流れは、AI時代のデータ基盤とは？生成AIに使えるデータの条件で整理した論点とも重なります。
すでにdbtを使っているなら、「テスト機能があるのに、別の仕組みが要るのか」と思われるかもしれません。実務での答えは、役割が違うので両方使うです。
dbtのテストは、書いた人が想定できる異常を検出します。主キーが重複していないか、NULLが混ざっていないか、値が想定の選択肢の中に収まっているか。図の左側です。これらは「起きるとしたらこう壊れるはずだ」という仮説を、コードとして書き下ろしたものです。
問題は、想定の外側です。取り込み件数が普段の3割に減った、連携元が列を1つ増やした、売上の分布が先月と明らかに違う。どこからを異常と呼ぶかを事前に決めきれないため、テストとして書き下ろせません。書けないものは、どれだけテストを増やしても検出できません。
もう1つの違いが、判定の基準です。dbtのテストは人が決めた閾値で合否を出します。データオブザーバビリティは過去の傾向を学習し、普段とどれだけずれているかで判定します。前者は基準を書ける異常に強く、後者は基準を決めきれない揺らぎに強い。
なお、dbtでも鮮度は見られます。dbt test は単独で実行できるコマンドですし、dbt source freshness を使えば連携元テーブルの更新遅れを閾値付きで検出できます。問題はツールの機能ではなく、これらが変換ジョブに同梱されたまま運用されがちなことです。ジョブごと止まった日は、監視も一緒に止まります。
| dbtのテスト | データオブザーバビリティ | |
|---|---|---|
| 検出する対象 | 想定できる異常（既知） | 想定していなかった変化（未知） |
| 判定の基準 | 人が決めた閾値 | 過去の傾向から自動で学習 |
| 実行のきっかけ | 変換ジョブに同梱されることが多い（単独実行も可能） | 変換とは独立したスケジュール |
| 得意なこと | 業務ルールの担保 | 鮮度・件数・構造の異変の検知 |
| 苦手なこと | 基準を決めきれない揺らぎ | 業務的に正しいかどうかの判断 |
順番としては、dbtのテストで業務ルールを固めてから、取りこぼす範囲を監視で埋めるのが素直です。dbtのテスト自体の書き方は、dbtとは？データ変換をコード管理するツールの仕組みを解説でも触れています。
ツールは大きく3層に分かれます。判断材料になるのは、監視したいテーブル数と、割ける運用工数です。
| 層 | 代表的なツール | 費用の目安 | 向いているケース |
|---|---|---|---|
| 無料で使える | Elementary、Great Expectations、Soda Core（※） | ライセンス費は無料 | dbt中心の構成。エンジニアが自前で回せる |
| 中堅向け商用 | Metaplane（現Datadog傘下）、Bigeye | 月数千ドル規模 | 監視対象が数百テーブル。設定に時間をかけたくない |
| エンタープライズ向け | Monte Carlo、Anomalo、Acceldata | 年数万ドル規模から | 複数のDWH・監査要件あり・専任チームがいる |
※ Soda Coreは2024年にライセンスがElastic License 2.0へ変更され、無償で使えますがOSI基準のオープンソースではなくなりました。商用製品に組み込む場合は条件を確認してください。
商用ツールはいずれも公開価格を持たず、テーブル数や監視の粒度で見積もりが決まります。上の金額は第三者の比較情報から拾った幅なので、実額は必ず見積もりで確認してください。
日本の中堅企業でまず現実的なのは、dbtを使っているならElementaryです。dbtのプロジェクトに組み込む形で導入でき、鮮度と量の異常検知、実行結果のレポートまでを追加費用なしで賄えます。dbtを使っていない場合は、DWHが自動で持っている管理情報（テーブルの更新時刻や行数）を定期的に取得し、閾値と比べるだけの自作の監視から始めても十分に機能します。
いきなり商用ツールの検討から入ると、費用の議論で止まりがちです。まず自前で2つの観点を回してみて、運用の負荷が見えてから商用を検討する。この順番のほうが、社内の合意も得やすいと感じています。
導入でつまずく企業の多くが、最初から全テーブルを対象にしようとします。データ基盤には数百から数千のテーブルがあり、全部を監視すればアラートが日に何十件も飛びます。結果、誰も見なくなります。
現場で機能しているのは、次の順番です。
3番目を飛ばさないことが、うまくいくかどうかの分かれ目です。監視の仕組みだけ先に作り、当番も手順も決めないまま運用に入ったチームを何度か見てきました。例外なく、3か月ほどで誰もアラートを開かなくなりました。
技術より運用設計のほうが難しい、というのがこの領域の実感です。データ基盤の運用体制そのものについては、データ基盤構築でよくある失敗パターンと回避策も参考になるはずです。
3つ、繰り返し起きるパターンがあります。
1つ目がアラート疲れです。閾値を厳しくしすぎると、業務上は問題ない変動でも通知が飛びます。月末に件数が増えるのは正常なのに異常として鳴る、といった具合です。曜日や月末の周期を織り込むか、通知を「即時対応」と「日次でまとめて確認」の2段階に分けると落ち着きます。
2つ目が監視のしすぎです。全テーブルに全観点を掛けると、監視対象が数千件になります。DWH（データウェアハウス。分析用にデータをためる基盤）への問い合わせが増えて、BigQueryやSnowflakeの利用料が跳ねることもあります。監視のコストが、防ぎたい損失を上回っては本末転倒です。コスト側の勘所は、BigQueryのコスト最適化：料金の仕組みと削減の実践手法でも整理しています。
3つ目がデータの持ち主が決まっていないことです。異常を検知しても、そのテーブルの正しい姿を判断できる人がいなければ対応は止まります。テーブルごとに業務側の責任者を1人決めておく。地味ですが、これが決まっているかどうかで復旧までの時間がまるで変わります。
いずれも技術的な問題ではありません。データオブザーバビリティは、ツールを入れれば完成するものではなく、データマネジメントの運用ルールとセットで初めて機能します。
要点を整理します。
データ基盤は、作って終わりではなく壊れ続けるものだと考えています。壊れることを前提に、壊れたときに最初に気づけるかどうか。そこが、現場に信頼されるデータ基盤との分かれ目ではないでしょうか。
株式会社Evastでは、データ品質の管理から運用ルールの策定、組織への定着までを一貫して支援しています。
いま動いているデータ基盤の運用診断からでも構いません。自社に合った進め方を知りたい方は、データ活用の無料診断もご利用ください。
DXに取り組む日本企業は約8割、しかし成果を実感できているのは6割弱（IPA「DX動向2025」）。効率化止まりから抜け出せない理由は、デジタル化とDXの混同、データを資産として管理する仕組みの欠如にあります。デジタル化とDXの違い、データ駆動型経営のサイクル、DMBOKに沿った4活動、現場で頻発する3つの失敗パターン、棚卸しから始める3ステップまで整理します。経営層・DX推進担当者向け。
データ基盤構築は、作っても「使われない」「途中で頓挫する」失敗が後を絶ちません。目的・体制・データ・運用の4カテゴリでよくある失敗パターンと注意点を整理し、なぜ起きるのか・どう防ぐのかを実務目線で解説します。内製と外注の判断、PoC疲れの回避、対象データの棚卸し、頓挫した場合の立て直しまでカバーし、発注前にそのまま使えるチェックリストつき。これからデータ基盤を発注するマネージャーが、契約前に立ち止まって確認するための実務記事です。
データ基盤を内製で作るか、外注するか。発注の分かれ道になるこの判断を、発注の現場目線で整理します。外注と内製それぞれのメリット・デメリット、スピード・ノウハウ・採用・コストという判断軸、データ人材の採用が難しい現実、そして設計は外注・運用は内製に寄せるハイブリッドの役割分担まで解説。どちらで進めるか迷っているマネージャー向けの実務記事です。
主要なオーケストレーションツール3つの違いと選び方が分かります。Airflow（業界標準・大規模向け）、Dagster（データ資産中心・dbt親和性）、Prefect（シンプル・スモールスタート）の設計思想を4軸で比較し、チーム規模や技術スタックに応じた選定基準を現場経験から解説します。
