「データカタログを入れたが、誰も見ていない」という相談を、年に何回も受けます。原因はだいたい3つに集約されます：(1) 自動更新が止まっている、(2) 検索結果が信用できない、(3) そもそも入り口が分かりづらい。今回は、この3つを潰す運用設計を共有します。
「使われない」3つのアンチパターン
解決策1：自動更新を死守する
DataHub にせよ Atlan にせよ、データソースの自動同期が「いつの間にか止まっていた」が頻発します。同期失敗をパイプライン障害と同じレベルで監視するのが必須。
監視のコツ
「カタログ最終同期から24時間経過」を Datadog で監視。ヘルスチェックURLを叩く運用にしておくと、ダウン時に自動アラートが上がります。
解決策2：description は「ビジネスルール」だけ書く
「customer_id: 顧客ID」のような自明な記述は、書く意味がないだけでなく、価値あるカラムが埋もれる原因になります。description には「ビジネスルール」「他カラムとの関係」「過去の落とし穴」を書きます。
| ❌ 書かない方が良い | ✅ 書くべき |
|---|---|
| customer_id: 顧客ID | customer_id: dim_customer.id とJOIN。退会者も保持 |
| amount: 金額 | amount: 税抜・JPY。返品分はマイナス値で記録 |
| status: ステータス | status: 'active'/'paused'/'canceled'。'paused'は支払いリトライ中 |
| created_at: 作成日時 | created_at: UTC、JST表示は +9h、月次区切りは JST 1日0時 |
解決策3：入り口を1つに統一する
「カタログのURLどこだっけ？」を撲滅するには、Slack の `/catalog` スラッシュコマンドや、社内ポータルのトップに常駐させるのが効きます。「データに迷ったらここ」を1個に絞り込みます。
で description を一括生成
プロンプト例（Claude Code）
この dbt プロジェクトの schema.yml に、ビジネスルール重視の description を全カラムに付けてください。
## ルール
- 自明な説明（"顧客ID"など）は書かない
- ビジネスルール（NULL扱い、enum値の意味、JOIN先）を優先
- 他カラムとの関係性を書く
- 知らないカラムは [TODO: 確認] と明記
- ソースのカラムから推測する場合は (推測) を末尾に
## 入力
@models/marts/finance/dim_customer.sql
@models/marts/finance/fct_orders.sql
@docs/business_glossary.md 想定される実行結果（例示）
## description 生成完了
### dim_customer (28カラム)
- 自動生成: 22カラム
- TODO 残: 6カラム（enum値の意味が不明）
- ビジネスルール記述例:
- `is_active`: subscription_canceled_at IS NULL AND payment_failed_count < 3 のとき true
- `signup_source`: 'organic'/'paid'/'referral'/'partner'。'partner' は B2B 経由のみ
- `ltv_jpy`: subscriptions の累計金額（税抜・返金除く）
### fct_orders (35カラム)
- 自動生成: 30カラム
- TODO 残: 5カラム
合計 schema.yml に 65個の description 追記。{{dbt|*}} docs generate で社内カタログに即反映可能。次回予告
EP.06 では、5年運用してきた集大成として、「チーム3人で回せる構成のために決めた7つのこと」をまとめます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。