データ基盤の障害で最も多い原因の1つが、上流の変更です。列名が変わった、区分が増えた、値の意味が変わった。こちらは何もしていないのに壊れます。
この回は ── 渡す側と受け取る側の取り決め ── を扱います。理想論ではなく、実際に運用できる形で整理します。
1. なぜ壊れるのか
上流が悪意で変えるわけではありません。下流の存在を知らない、あるいは影響が分からないことが原因です。
| 上流の視点 | 下流で起きること |
|---|---|
| 使っていない列を消した | 下流では使っていた |
| 列名を分かりやすくした | 参照が壊れる |
| 区分を細かくした | 知らない値が流れてくる |
| 不要になった項目を空にした | 欠損率が急上昇 |
| 性能のために型を変えた | 変換に失敗する |
どれも上流にとっては改善です。だから止められません。必要なのは、変更を防ぐことではなく、影響を把握できるようにすることです。
上流を責めても解決しません。誰が使っているかを上流が把握していないのが実情です。レガシー再生の現場 EP.07 で扱ったとおり、連携先の一覧は、たいてい存在しません。
2. 何を取り決めるか
全項目を取り決めると維持できません。壊れたときの影響が大きい項目に絞ります。
| 取り決める対象 | 優先度 | 理由 |
|---|---|---|
| 下流で必須の列 | 最優先 | 無くなると処理が止まる |
| 結合に使う列 | 最優先 | 無くなると突き合わせ不能 |
| 型と単位 | 高い | 変わると値が狂う（前処理 EP.21） |
| 区分の取りうる値 | 高い | 増えると後段が誤動作 |
| 件数の目安 | 中 | 急変が異常の兆候 |
| 使っていない列 | 不要 | 取り決める意味がない |
最下行が重要です。使っていない列まで取り決めると、維持できなくなります。上流が自由に変えられる範囲を残しておくほうが、取り決め自体が守られやすくなります。
3. 取り決めをコードで書く
文書として持つと腐ります。コードとして書き、検査に使うのが実務的です。
# contracts/orders.ymlsource: raw.ordersowner: 販売システム担当updated: 2026-09-01
# 下流で必須の列。無くなったら処理を止めるrequired_columns: - name: order_id type: string unique: true nullable: false note: 結合に使用。形式が変わると突き合わせ不能 - name: order_date type: date nullable: false - name: amount type: integer unit: JPY # 単位を明示（前処理 EP.21） min: 0 nullable: false - name: status type: string allowed: [pending, paid, cancelled, returned] nullable: false note: 値を増やす場合は事前連絡が必要
# 件数の目安（大きく外れたら異常を疑う）row_count: daily_min: 5000 daily_max: 30000
# 変更のときの取り決めchange_policy: add_column: 連絡不要 add_allowed_value: 事前連絡が必要 rename_column: 事前連絡と移行期間が必要 drop_column: 事前連絡と移行期間が必要 change_type: 事前連絡と移行期間が必要`change_policy` を明示しているのが要点です。 ── 構造の変化 ── には種類があり、列の追加は安全ですが、削除と型変更は下流を壊します。種類ごとに扱いを決めておくと、上流も判断しやすくなります。
この定義は、そのまま検査に使えます。前処理の現場 EP.22 で扱った品質検査の仕様として読み込めば、取り決めと検査が同じ1つのファイルになります。
4. 上流と結べない場合
現実には、上流が社外だったり、依頼できる関係になかったりします。その場合でも、できることがあります。
- 1こちらの想定を明文化する — 取り決めがなくても、想定は書ける
- 2検査を入れて、変化を検知する — 事前連絡がなくても気づける
- 3変化したときの対処手順を決めておく — 誰が判断し、どう直すか
- 4影響範囲を把握しておく — その列を使っている処理の一覧
- 5代替の取得経路があるか確認 — 別の方法で得られないか
1番目と2番目だけでも価値があります。「変わったことに、その日のうちに気づける」というだけで、発覚が数週間後になるのとは対処の難易度がまったく違います。数週間経つと、その間に出した数字がすべて疑わしくなります。遡って訂正する範囲が、時間とともに広がっていきます。
4番目も重要です。変わったときに、どこまで影響するかがすぐ分かる状態にしておく。EP.15 でも扱いましたが、依存関係の把握は、こういう場面で効いてきます。
5. 検知したあとの動き
検知しても、その後の動きが決まっていないと止まります。あらかじめ決めておきます。
| 変化の種類 | 対応 | 止めるか |
|---|---|---|
| 必須列が消えた | 即座に止める | 止める |
| 型が変わった | 変換を確認 | 止める |
| 知らない区分値 | 内容を確認して追加 | 警告 |
| 列が追加された | 使うか判断 | 通す |
| 件数が大きく変動 | 原因を確認 | 止める（誤りの可能性） |
止めるか通すかを、種類ごとに決めておくのが要点です。EP.22（前処理）でも書きましたが、全部を止めると無視されるようになります。列の追加のような安全な変更は通してください。
そして、止めたときの連絡先と手順を決めておく。「止まったが誰も気づかない」という状態が最悪です。
6. 自分が上流になるとき
最後に、視点を変えます。自分たちが上流になる場面もあります。他部門や社外にデータを渡す立場です。
- 誰が使っているかを把握する — 参照の記録から
- 変更の前に連絡する — 種類に応じて
- 移行期間を設ける — 新旧を並行して提供
- 取りうる値を増やすときも連絡する — 減らすときだけではない
- 使われていない項目を確認してから消す — 記録で判断
4番目は レガシー再生の現場 EP.07 でも扱いました。値を増やす変更も、相手を壊します。「知らない値なら例外を投げる」という実装は珍しくありません。
そして、下流にされて困ることは、上流としてもしない。これが最も単純な原則です。この連載で扱ってきた「壊れないデータ基盤」は、自分の管轄の中だけでは完結しません。 という言葉が指すのも、自分の持ち場を超えて、データの流れ全体に責任を持つという姿勢です。
上流は悪意ではなく、下流を知らないから変える。目的は防ぐことではなく、早く気づくこと。取り決めは影響の大きい項目に絞る（使っていない列は対象外）。変更の種類ごとに扱いを決める（追加は安全、削除と型変更は危険）。取り決めを結べなくても、想定の明文化と検知だけで価値がある。そして自分が上流のときも、同じ配慮をしてください。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。