『売上はどのテーブルか』『customer_idは会員だけか』『この列は更新されているか』を知るために、詳しい人へ毎回Slackで質問する。用語集を作ってもテーブルへつながらず、データ辞書があっても事業上の意味が分からない。これは道具の役割が混ざっている状態です。
結論として、データカタログはデータ資産を探して理解する入口、ビジネス用語集は組織で使う言葉の意味を揃える場所、データ辞書はテーブルや列の技術仕様を記す場所です。三つは競合せず、同じ重要指標から相互リンクすると、検索と理解と実装が一つにつながります。
最初に結論
カタログは『どんなデータがどこにあり、誰が管理し、どう流れるか』、用語集は『純売上やアクティブ顧客とは何を意味するか』、辞書は『orders.net_salesの型・NULL・値域は何か』を扱います。まず重要KPIを一つ選び、用語→計算→列→所有者をつないでください。
この記事のポイント
- ・カタログは資産の発見、用語集は事業意味の統一、辞書は列レベルの技術仕様を担う
- ・データリネージは取得元から変換・レポートまでの流れと影響範囲を示す
- ・最初は表計算でもよく、重要な指標・テーブル・所有者・更新日をつなぐ
- ・自動収集できる技術情報と、人が合意する業務定義を分けて運用する
対象：指標定義やテーブル探索に時間がかかる事業担当者、分析担当者、データガバナンス責任者
1. 3つの違いを一枚で理解する
IBMやAWSはデータカタログを、組織のデータ資産に関するメタデータを集め、検索・理解・利用を助ける仕組みとして説明しています。カタログは図書館の蔵書検索に近く、テーブル、ファイル、ダッシュボード、所有者、分類、品質、リネージなどを横断して、利用者を必要な資産へ案内します。
ビジネス用語集は『純売上』『新規顧客』など人が使う概念を、対象、計算、除外、例、責任者とともに定義します。データ辞書はtable名、column名、型、NULL可否、許可値、更新方法など、実装へ近い仕様を記します。同じ情報を三か所へ複製せず、役割ごとに正を決めてリンクします。
| 仕組み | 主な質問 | 管理単位 | 主な利用者 |
|---|---|---|---|
| データカタログ | 何がどこにあり、信頼して使えるか | テーブル、ファイル、レポート、モデル | 全利用者 |
| ビジネス用語集 | この言葉は組織で何を意味するか | KPI、業務概念、分類 | 事業・経営・分析 |
| データ辞書 | このテーブル・列の仕様は何か | スキーマ、列、型、値 | 分析・開発・運用 |
| データリネージ | どこから来て、変更はどこへ影響するか | 資産間の流れ・依存関係 | 分析・開発・監査 |
2. データカタログは発見と信頼の入口
良いカタログは資産名を一覧にするだけではありません。説明、所有者、機密分類、最終更新、利用例、品質状態、上流・下流、アクセス方法を示し、利用者が『このテーブルを使ってよいか』を判断できるようにします。Microsoft PurviewやGoogle Cloud Dataplexなどは、技術メタデータの収集や検索、分類、リネージを支援します。
しかし自動スキャンで分かるのは、列名、型、更新時刻、参照関係などが中心です。返品を含める純売上を経営会議で使うべきか、誰が承認した定義かは人が決めます。利用回数が多いから正しい資産とも限りません。推薦や品質表示には、対象期間と根拠を添えます。
- 検索：名前、説明、タグ、事業領域から必要な資産を見つける
- 理解：例、粒度、更新、品質、所有者から用途を判断する
- 信頼：認証済み資産、警告、変更履歴、利用条件を示す
- アクセス：申請方法と権限範囲へ案内する
- 影響確認：上流・下流のリネージで変更先を把握する
3. 「純売上」を3つの場所でどう表すか
用語集では、純売上を『確定した商品売上から値引きと返品を差し引いた金額』などと定義し、税、送料、取消、計上日、通貨、利用場面、承認者を記します。誰が読んでも事業上の意味と境界が分かることが目的です。計算式が変わる場合は適用日と旧定義を残します。
辞書では、analytics.fct_orders.net_salesという列、数値型、通貨、NULL可否、計算元、更新頻度を記します。カタログのfct_ordersページは、用語集の純売上へリンクし、所有者、品質状態、上流のShopify注文・返金、下流の経営ダッシュボードを示します。この接続があると、言葉だけ、列だけ、一覧だけになるのを防げます。
| 場所 | 純売上について書く内容 |
|---|---|
| 用語集 | 事業定義、計算の考え方、含む・除く、利用場面、承認者 |
| データ辞書 | 物理列、型、NULL、単位、変換式、更新、例示値 |
| データカタログ | 資産の説明、所有者、品質、権限、用語・リネージへのリンク |
| リネージ | Shopify注文・返金→変換SQL→純売上列→ダッシュボードの流れ |
4. 表計算から始める最小項目
資産が少ないうちは、検索できる共有スプレッドシートやリポジトリ内の文書で始められます。重要なのは高機能な画面ではなく、情報の正と更新責任が一つに決まっていることです。用語と資産を同じ表へ混ぜる場合も、種別列を設け、事業定義と技術仕様を区別します。
最小でも、名前、種別、説明、所有者、利用目的、元データ、更新頻度、機密区分、品質状態、最終確認日、関連リンクを持たせます。列辞書にはテーブル、列、型、NULL、例、定義、許可値を追加します。説明のない列を機械的に大量登録するより、よく使う20資産を利用者が理解できる状態にします。
- 共通：名前、説明、種別、所有者、利用目的、最終確認日
- 資産：保存場所、粒度、更新頻度、機密区分、品質、アクセス方法
- 用語：事業定義、計算、含む・除く、例、承認者、適用日
- 列：テーブル、物理名、型、NULL、単位、許可値、例示値
- 接続：関連用語、上流、下流、利用中のダッシュボード
5. 使われるカタログを作る6つの手順
全資産の棚卸しから始めると、説明を書く作業だけが膨らみます。まず利用者が毎週探すもの、数字が合わず困るもの、変更影響が大きいものを選びます。Slackの質問、会議の数値差、障害記録を集めると、優先する用語と資産が見つかります。
公開後は検索ログや質問を見て、見つからなかった言葉、説明不足、古い所有者を直します。更新を専門チームだけへ集中させず、業務用語は事業オーナー、スキーマは技術オーナーが責任を持ちます。変更時にカタログ更新を完了条件へ含めると、別作業として忘れにくくなります。
- 利用者の質問を集める：頻出検索、Slack質問、数値不一致、変更事故を確認する。
- 重要用語と資産を選ぶ：経営KPIと、その計算に必要なテーブルから始める。
- 役割を分けて記述する：用語集、辞書、カタログの正を決め、相互リンクする。
- 所有者と確認日を付ける：意味・技術・アクセスの責任と見直し期限を明示する。
- 業務導線へ埋め込む：BI、SQLレビュー、アクセス申請から定義へ移動できるようにする。
- 検索失敗から改善する：見つからない語、古い説明、重複資産を定期的に直す。
6. BigQuery・dbtから自動化できる情報
BigQueryなどからproject、dataset、table、column、型、更新時刻を収集し、dbtからモデル説明、列説明、テスト、依存関係を取り込めます。人が同じ情報を手入力する量を減らし、実際のスキーマとのずれを検知できます。リネージもSQL解析や実行履歴から生成できる範囲があります。
自動化には限界があります。動的SQL、表計算への手動出力、SaaS内部の変換、口頭で決めた業務定義は追えないことがあります。自動取得した日付と信頼範囲を明示し、重要な流れは利用者が確認します。『自動収集済み』と『事業オーナーが認証済み』を別の状態で表示すると誤信を減らせます。
7. AI時代に用語と辞書が重要になる理由
AIが自然言語からSQLを作るとき、同名の売上列が複数あれば誤ったテーブルを選ぶ可能性があります。認証済み資産、用語と列の対応、粒度、更新時刻、機密区分、利用例を機械が参照できれば、候補を絞り、回答に根拠を添えやすくなります。カタログはAIのためだけでなく、人とAIが同じ意味を使う土台になります。
ただしカタログがあってもAI回答は自動で正しくなりません。古い定義、誤ったリネージ、権限を無視した検索があれば危険です。質問者の権限内だけを検索し、使用したテーブル、期間、定義、更新時刻を回答に表示し、重要判断は元データと人が検証します。
8. 専用ツールを検討するタイミング
資産が少なく更新者も限られるなら、表計算、Markdown、dbt docsで十分な場合があります。専用ツールの価値が高まるのは、複数クラウドやSaaSを横断する、数百以上の資産を検索する、機密分類やアクセス申請が必要、変更影響を自動追跡したい、監査履歴を残したいときです。
選定では登録できる項目数より、既存システムとの接続、検索品質、権限継承、API、用語と物理資産のリンク、リネージの精度、更新ワークフロー、データの持ち出しを確認します。自社の代表的な三つの質問を使って試験し、利用者が自力で正しい資産へ到達できるかで評価します。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- What is a Data Catalog? — IBM（最終確認：2026-08-07）：データカタログの定義、メタデータ、発見・ガバナンス用途を参照。
- What is a Data Catalog? — Amazon Web Services（最終確認：2026-08-07）：カタログの構成要素と利用目的を参照。
- Microsoft Purview Unified Catalog — Microsoft Learn（最終確認：2026-08-07）：カタログ、データプロダクト、検索・ガバナンス機能を参照。
- Manage glossary terms — Microsoft Learn（最終確認：2026-08-07）：ビジネス用語と資産を関連付ける考え方を参照。
- Dataplex Universal Catalog overview — Google Cloud（最終確認：2026-08-07）：メタデータ収集、検索、リネージ、品質の連携を参照。
よくある質問
データカタログとデータベースは何が違いますか？
データベースはデータ本体を保存・処理します。カタログはデータ本体ではなく、どこにあり、何を意味し、誰が管理し、どう使えるかというメタデータを検索・理解する入口です。
用語集とデータ辞書は一つの表でもよいですか？
小規模なら一つの表でも構いません。ただし種別と責任者を分け、事業用語の意味と物理列の仕様を混同しないでください。規模が増えたら別管理してリンクできます。
カタログを作ればAIが正しいSQLを書けますか？
成功率を上げる材料にはなりますが保証はできません。定義の鮮度、権限、粒度、品質状態を提供し、生成されたSQLの対象・処理量・結果を人が検証する必要があります。
まとめと次の一歩
カタログ、用語集、辞書は別々の台帳ではなく、データを見つける入口、事業上の意味、実装上の仕様をつなぐ三層です。人が合意する定義と自動取得できる技術情報を分けて更新すれば、詳しい人への質問と誤った列の再利用を同時に減らせます。