昨日まで正常だったパイプラインが、今朝は空になっている
社内ソースであれば、このようなことはあまり起こりません。スキーマを変更するには調整があり、カラムを削除する前には予告があり、問題が起きれば責任を負う担当者がいます。しかし、競合他社の価格、レビュー、市場データのように外部Webから取り込むソースは異なります。
ある日、対象サイトがレビュー領域をReactに刷新し、価格表示の位置を移し、ログインしなければ見えていた項目を隠します。予告なしに。その瞬間、昨日まで正常に動いていたパース処理が空の値を返し、dbtモデルがそのまま通過させ、ダッシュボードには昨日のデータが欠損として残ります。現場は「なぜデータが合わないのか」と尋ね、データチームは深夜にパーサーを修正します。
本稿では、この状況がなぜ繰り返されるのか、そして破損を前提にどのように責任を設計するのかを、データ契約（Data Contract）の観点から整理します。
なぜWebだけが繰り返し壊れるのか
データ契約とは、ソースとコンシューマーの間で「このデータはこのような形・意味・周期で提供される」ことを明示する約束です。単なるスキーマ定義ではなく、変更が発生した際に誰が何をいつ行うかまで含む約束です。
社内システムでは、この契約が組織の規範として機能します。ソースチームがスキーマを変更するには通知し、カラムを削除する前にはdeprecation期間を設け、壊れたときには修正責任者が組織図の中にいます。重要なのは、ソースが協力可能な主体であることです。対話ができ、スケジュールを調整でき、責任を問うことができます。
外部Webデータが難しい理由は、この前提が崩れるからです。対象サイトは私たちの契約の当事者ではありません。パイプラインの事情を考慮してくれるわけでもなく、通知もなく、ロールバックを依頼することもできません。さらに、Web画面はそもそもパイプライン入力として作られたものではありません。人が見るために作られた画面をデータとして逆解析する構造であるため、次の性質が契約を揺るがします。
- 予告なしの改修: マーケティングリニューアル・フレームワークの変更により、DOM構造やレンダリング方式（SSR→CSR）が一夜にして変わります。
- A/Bテストと条件別画面: 同じURLでもアクセスのたびに異なる画面が返され、地域・ログイン・会員ランク・デバイスによって表示項目が変わります。どの条件で取得したデータかを併せて記録しなければ、同じフィールドでも値の意味が静かに変わります。
- アンチボット・ブロックによる部分欠損: ブロック・CAPTCHA・レートリミットがかかると、データがまったく取得できなくなるのではなく、一部だけが欠けます。「正常に見える縮小されたデータ」となり、下流が静かに誤った集計を行います。
共通しているのは、スキーマが安定しているという社内ソースの前提が、外部Webでは成り立たないことです。したがって、外部Webのデータ契約は「壊れない」ことではなく、壊れることを前提として、検知・修正・再収集を誰が責任を持って行うかを扱う必要があります。
小さな改修がなぜ組織全体の問題になるのか
一つのサイトの小さな改修は下流へ波及します。パースルールと実際のDOMがずれると、収集段階でフィールドが欠損したり値が変形したりし、それがロードテーブルで検出されないままdbt変換へ進み、静かなNULL伝播と誤った集計を生み出し、最終的にはダッシュボードの欠損と誤った意思決定につながります。
影響範囲を広げる要因は二つあります。第一に、静かな失敗です。パース処理が例外を投げて停止するなら、むしろましです。危険なのは、空文字列やNULLを正常値のように返し、下流がそのまま通過させるケースです。パイプラインは緑色のままなのに、数値だけが間違います。第二に、フィールド契約を広く取りすぎた場合です。収集したすべてのフィールドを下流モデルやダッシュボードがそのまま参照すると、サイトが一つの要素を変えただけでも、それに依存するすべての成果物が一緒に揺らぎます。
バッファ設計 — 壊れても下流を壊さないために
外部Webの不安定性をなくすことはできません。代わりに、その不安定性が下流へ波及しないよう、間にバッファ層を設けます。
rawの保存。 収集した原本（HTMLスナップショット、元のレスポンス、OCR前の画像など）を、パース結果とは別に保存します。パースが誤っていたことが判明したとき、原本が残っていれば再収集せずに再パースで過去データを復旧できます。原本を捨てると、パースバグがそのまま永続的なデータ損失になります。rawの保存は、再収集・監査・リネージの共通基盤です。
フィールド契約の最小化。 下流が依存するフィールドを核心的なものだけに絞って契約します。サイトが頻繁に変更する付随要素は契約に含めず、rawにのみ残します。契約された主要フィールドは、型・必須可否・値の範囲を検証し、違反時には下流へ流しません。契約が狭いほど、改修の影響範囲も狭くなります。
変更検知。 「パース処理が例外を投げたか」だけを見ていると、静かな失敗を見逃します。そのため、結果そのものの形を監視します。レコード数が通常比で急変していないか、主要フィールドの欠損率が急に上がっていないか、値の分布が正常範囲を外れていないか（価格が0、または異常に高い）を確認し、一つでも該当すればデータチームのチャネルへ通知します。人が改修を発見する前に、データの形の変化から先に捉えることが目的です。
このバッファの上で、私たちがデータチームと連携する方法は次のとおりです。スキーマは最初にデータチームとともに定義します。どのフィールドを主要契約とするか、各フィールドの型・NULL許容・意味を揃え、その契約をdbt・ダッシュボードの下流が参照するようにします。変更が必要になっても、一方的にスキーマを差し替えることはしません。変更を事前通知し、deprecation期間を設け、その期間中は旧・新バージョンを並行提供して下流が移行する時間を確保した後、旧バージョンを廃止します。これにより、サイトが変わっても下流は予告された期間内に移行すればよく、改修がそのままダッシュボードの欠損に直結しません。
破損を前提とした責任設計
技術的なバッファだけでは不十分です。実際に業務を崩壊させるのは、壊れたときに誰が修正するのかが契約にない状況です。そのため、データ契約にはスキーマだけでなく、検知・修正・再収集のオーナーも併せて記載される必要があります。
| 所有権 | 契約に明記すること |
|---|---|
| 検知 | 異常シグナルを誰が運用し、どのチャネルへ通知し、復旧目標時間をいつまでとするか。検知の主体はコンシューマーではなく、収集を運用する側 |
| 修正 | サイト改修によりパーサーが壊れたとき、ルールを修理する責任は誰にあるか。委託している場合は委託先 |
| 再収集(backfill) | 破損期間の欠損を埋め戻す標準手順があるか |
修正責任を委託先に置くことが、委託の核心的な価値です。ブロック対応・サイト変更の追跡・パーサー修理といった継続的な保守を、データチームのDAG運用担当者が抱え込まないようにし、データチームはロード・モデリング・活用に集中します。
再収集は例外ではなく、標準手順として扱います。期間・条件を指定して埋め戻しますが、同じキーに何度ロードしても重複が蓄積しないよう冪等ロードを前提とし、ウォーターマーク・増分カーソルによって埋め戻す区間だけを正確に埋めます。さらに、ロード後の検証（DQ）・監査・リネージにすぐ利用できるメタデータも併せて提供します。収集時刻・収集条件（地域・ログイン）は値の意味を解釈する根拠となり、ソースURL・収集周期はカタログ・リネージ登録に使われ、レコード数・欠損/異常フラグは自動検証ゲートに入ります。また、ロードが完全に終了したことを下流が判断できるよう完了マーカー(manifest/_SUCCESS)を残し、オーケストレーションが部分ロードの上で変換を実行してしまう事故を防ぎます。そうして初めて、監査時の「この数値はどこから来たのか」という問いに答えられます。
要するに、外部Webのデータ契約は「壊れない」という約束ではなく、壊れたときに検知・修正・再収集を誰が責任を持って行い、いつまでに復旧するかという約束です。この所有権が契約に記載されてこそ、外部Webソースを社内で適切に管理されたソースシステムのように扱えます。
まとめ
外部Webデータが繰り返し壊れる根本的な理由は、社内ソースとは異なり、ソースが協力可能な契約当事者ではないためです。予告なしの改修、A/Bテスト、条件別画面が、スキーマ安定性という前提を崩します。したがって、外部Webのデータ契約は「壊れない」ことではなく、壊れることを前提に、検知・修正・再収集の所有者を明示する契約でなければなりません。
ハッシュスクレイパーは、この方法でデータチームと連携します。スキーマをともに定義し、変更は事前通知・バージョン並行提供で移行し、再収集は冪等ロード・ウォーターマークに基づく標準手順で処理し、カタログ・リネージ・DQにすぐ利用できるメタデータと完了マーカーを併せて提供します。開発・保守・ブロック対応・収集監視は月額委託に含まれるため、DAG運用担当者が外部収集の保守に疲弊することはありません。規模の面でも、ある規制機関の大規模オンラインモニタリングを定期パイプラインとして委託運用してきた経験があります。
外部Webの収集・保守は委託し、適切に管理されたソースシステムのように扱う。そしてデータチームはロード・モデリング・活用に集中すること — これが、サイト改修の時代に外部データをダッシュボードへ安定的に載せるための現実的な道筋です。
あわせて読みたい記事
- クロールデータが意思決定になるまで
- Excelで受け取るデータ vs ダッシュボードで見るデータ — 納品形式が変えるもの
- 部門ごとに別々にクローリングする会社 — 重複投資を終わらせる全社データ収集ガバナンス
今すぐ始める
現在パイプラインに接続されている外部Webソースについて、一度の改修でダッシュボードが空にならないためにどのような契約が必要か、私たちが一緒に点検します。スキーマ定義から変更通知・再収集の責任・提供仕様まで、データチームのパイプラインに合わせて設計します。
