データカタログ3回失敗して分かった、ようやく「使われる」ようになった話
Collibra・Alation・OpenMetadataを本番導入してきた経験から、ツール選定より運用設計が9割だと気づいた。3回失敗した現場エンジニアが2026年時点の現実を正直に書きます。
データカタログ、3回目の導入でやっと「使われるもの」になった
うちのチームがデータカタログを最初に導入しようとしたのは2023年の話で、その時はCollibraを半導入のまま放置して終わった。2024年にAlationで再挑戦してそれも半年で形骸化。2026年になってOpenMetadataをベースにリアーキテクチャしたら、ようやく「ちゃんと使われるカタログ」になってきた。
3回失敗して分かったことは、ツールの選定ミスより運用設計の失敗のほうが圧倒的に多いという現実だった。データ品質管理のアプローチについてはデータ品質管理2026年版で別途まとめているので合わせて読んでほしいけど、今回はカタログ導入固有の話を正直に書いていく。
2026年のデータカタログ主要ツール比較
正直まだ全部を完全に検証できてるわけじゃないけど、実際に触った範囲でまとめると以下の通り。Collibraは「機能的には最強」という評判を体感できる一方で、とにかく重い。カスタマイズの自由度は高いんだけど、その分セットアップに3ヶ月かかるし、専任担当者が実質必要になる。
| ツール | 形態 | AI統合 | Lineage | 価格感 | 日本語対応 | 向いてる規模 |
|---|---|---|---|---|---|---|
| Collibra | SaaS/On-prem | ◎ (AI Governance) | ◎ | 高い（要見積） | △ | 大企業 |
| Alation | SaaS | ○ (Alation AI) | ○ | 中〜高 | △ | 中〜大企業 |
| OpenMetadata | OSS/SaaS | ○ (AI Assistant) | ◎ | 低〜中 | △ | スタートアップ〜中企業 |
| Atlan | SaaS | ◎ (AI全面統合) | ○ | 中〜高 | × | 中〜大企業 |
| DataHub (LinkedIn OSS) | OSS | △ | ◎ | 低（運用コストあり） | × | 技術力高いチーム |
| Select Star | SaaS | ○ | ○ | 低〜中 | × | dbt/BIヘビーユーザー |
データカタログ完全ガイド2026でも触れているが、2026年時点でのCollibraはAI Governanceモジュールが本格化していて、LLMによる自動メタデータ生成・品質スコアリングが実用レベルになってきた。見積が出た時の金額には思考停止したけど、機能の完成度は正直すごい。
うちが最終的にOpenMetadata + 自前パイプラインを選んだ理由
最終的な構成はこうなっている。
flowchart TB
subgraph Sources["データソース"]
BQ[BigQuery]
RDS[Aurora PostgreSQL]
S3[S3 / Iceberg]
Kafka[Kafka Topics]
end
subgraph Ingestion["メタデータ収集層"]
Connector[OpenMetadata Connectors]
dbt[dbt Metadata]
Airflow[Airflow DAG Lineage]
end
subgraph Catalog["OpenMetadata Core"]
API[REST API / GraphQL]
Search[Elasticsearch 検索]
Lineage[Lineage Graph]
Classify[AI分類エンジン]
end
subgraph Consumers["利用者"]
DE[データエンジニア]
DS[データサイエンティスト]
Analyst[アナリスト]
Gov[ガバナンス担当]
end
Sources --> Connector
dbt --> Connector
Airflow --> Connector
Connector --> API
API --> Search
API --> Lineage
API --> Classify
Search --> DE
Search --> DS
Search --> Analyst
Lineage --> GovOpenMetadataを選んだ理由は正直シンプルで、Lineage機能が他より圧倒的に充実していたからだ。BigQuery・Airflow・dbtのLineageをシームレスにつなげられるのは、うちのパイプライン構成と相性が良かった。dbt Core 2.0移行後1年の運用でもやったけど、dbtのモデル間の依存関係をカタログ側で可視化できるようになったのはかなりでかかった。
もう一つの理由はコスト。Collibraの見積が出た時に、チームの人件費より高いレベルの金額が来て思考停止した。OSSベースならインフラコストだけで済む。ただし、運用コストは別の話で後述する。
実際の接続設定
dbtとの連携はこんな感じで設定する。
# openmetadata.yaml（dbt Connector設定）
source:
type: dbt
serviceName: dbt_production
serviceConnection:
config:
type: Dbt
dbtConfigSource:
dbtConfigType: cloud
dbtCloudUrl: https://cloud.getdbt.com
dbtCloudAuthToken: ${DBT_CLOUD_TOKEN}
dbtCloudAccountId: "123456"
dbtCloudJobId: "789012"
sourceConfig:
config:
type: DBTMetadata
dbtUpdateDescriptions: true
includeTags: true
dbtClassificationName: dbt_tags
workflowConfig:
loggerLevel: INFO
openMetadataServerConfig:
hostPort: https://your-openmetadata-instance.com/api
authProvider: openmetadata
securityConfig:
jwtToken: ${OM_JWT_TOKEN}BigQueryとの接続はこう。
# metadata_ingestion.py
from metadata.workflow.metadata import MetadataWorkflow
import json
BIGQUERY_CONFIG = {
"source": {
"type": "bigquery",
"serviceName": "bigquery_production",
"serviceConnection": {
"config": {
"type": "BigQuery",
"credentials": {
"gcpConfig": {
"type": "service_account",
"projectId": "your-project-id",
"privateKeyId": "${BQ_PRIVATE_KEY_ID}",
"privateKey": "${BQ_PRIVATE_KEY}",
"clientEmail": "${BQ_CLIENT_EMAIL}",
}
},
"taxonomyProjectID": ["your-project-id"],
"usageLocation": "us",
}
},
"sourceConfig": {
"config": {
"type": "DatabaseMetadata",
"markDeletedTables": True,
"includeTables": True,
"includeViews": True,
"includeTags": True,
"tableFilterPattern": {
"excludes": ["_bqt_.*", ".*_temp_.*"] # 一時テーブルを除外
},
}
},
},
"sink": {"type": "metadata-rest", "config": {}},
"workflowConfig": {
"openMetadataServerConfig": {
"hostPort": "https://your-openmetadata-instance.com/api",
"authProvider": "openmetadata",
"securityConfig": {"jwtToken": "${OM_JWT_TOKEN}"},
}
},
}
def run_ingestion():
workflow = MetadataWorkflow.create(BIGQUERY_CONFIG)
workflow.execute()
workflow.raise_from_status()
workflow.print_status()
workflow.stop()
if __name__ == "__main__":
run_ingestion()これをAirflowのDAGから呼び出して、毎日夜中に回している。最初はJobとして設定してたんだけど、Airflowとの統合のほうが依存関係の管理がしやすかった。
導入して3ヶ月、本当に困ったこと3つ
1. メタデータの「最初の1000テーブル」問題
インジェストしたはいいけど、説明文が空のテーブルが1000個並んでる状態になった。誰も使わない。これが最初の地獄だった。
2026年になってAI自動生成が実用的になったので、OpenMetadataのAI Assistantでカラム名・テーブル名からの自動説明生成を有効化した。精度は正直60〜70%ぐらいで、特にコードネームがついてるテーブルは全然ダメだった。ただ、「完全な手動入力」より「AIが書いたドラフトを人間がレビューして修正」のほうが圧倒的に消化できる量が増えた。
2. Lineageが嘘をつく
dbt・Airflow・BigQueryのLineageを繋いだはいいんだけど、手動で書いたSQLや、Pythonスクリプトで直接BigQueryにインサートしてるパイプラインが抜け漏れる。
これは正直解決しきれていなくて、今は「カタログ外のパイプラインはカスタムメタデータとして手動登録」というルールにした。地味に運用コストがかかってる部分で、ここは好みが分かれるかもしれない。完全自動じゃないと維持できないチームは、Collibraのほうが自動化のカバレッジが高いので向いてると思う。
3. 誰がオーナーか問題
テーブルに「オーナー」を設定しようとしたら、半分ぐらいのテーブルは誰が担当か不明確だった。このガバナンス問題はツールで解決できないやつで、チームの会議で「新しいテーブルを作ったら必ずカタログにオーナーを登録する」というルールを決めて、PRレビューのチェックリストに追加した。
6ヶ月かけてようやく81%まで来た。100%は無理だと思ってるけど、80%超えたあたりから「カタログ引けば大体わかる」という状態になったのは確か。
xychart-beta
title "導入から6ヶ月のメタデータカバレッジ推移"
x-axis ["導入時", "1ヶ月", "2ヶ月", "3ヶ月", "4ヶ月", "5ヶ月", "6ヶ月"]
y-axis "カバレッジ (%)" 0 --> 100
line [12, 28, 41, 55, 63, 72, 81]
bar [12, 28, 41, 55, 63, 72, 81]AI統合で2026年に変わったこと
個人的に一番感動したのが自然言語でのデータ探索だ。「先週の売上に関連するテーブルを教えて」って聞いたら、関連するテーブルのリストと、それぞれの使われ方の概要が出てくる。最初は懐疑的だったけど、意外と精度が高くて、新しいメンバーがオンボーディングする時の時間が体感で半分ぐらいになった。これは地味にでかい。
OpenMetadataのAI Assistantは2026年2月のリリース（v1.5系）から安定してきたんだけど、コンテキスト理解がまだ浅い部分があって、業界固有のビジネス用語が絡む質問は的外れな回答が返ってくることもある。そのへんはドメイン辞書を手動でメンテするしかないのが現状で、「全部AIに任せられる」とはまだ言えない。
CollibraのAI Governanceは、データの機密性スコアリングと、GDPR・個人情報保護法対応の自動タグ付けが秀逸だった。うちはSOC2対応をやっていた時期があって（SOC2 Type II取得後の地獄に書いた）、あのフェーズでCollibraがあったら相当楽だったと思う。
LLMによる自動ドキュメント生成を試した結果
# openmetadata_ai_enrichment.py
import openai
from metadata.generated.schema.entity.data.table import Table
from metadata.ingestion.ometa.ometa_api import OpenMetadata
from metadata.generated.schema.security.client.openMetadataJWTClientConfig import (
OpenMetadataJWTClientConfig,
)
from metadata.generated.schema.entity.services.connections.metadata.openMetadataConnection import (
OpenMetadataConnection,
)
client = openai.OpenAI(api_key="${OPENAI_API_KEY}")
def generate_table_description(table_name: str, columns: list[dict]) -> str:
column_info = "\n".join(
[f"- {col['name']} ({col['dataType']}): {col.get('description', '不明')}"
for col in columns[:20]] # 最初の20カラムのみ
)
prompt = f"""以下はデータウェアハウスのテーブル情報です。
ビジネスアナリストが理解できるような簡潔な説明文を日本語で150字以内で生成してください。
テーブル名: {table_name}
カラム情報:
{column_info}
説明文のみを出力してください。"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
max_tokens=200,
temperature=0.3,
)
return response.choices[0].message.content.strip()
def enrich_empty_tables(om_client: OpenMetadata, limit: int = 100):
"""説明が空のテーブルにAI生成の説明を付与する"""
tables = om_client.list_entities(
entity=Table,
limit=limit,
fields=["columns", "description"]
)
enriched_count = 0
for table in tables.entities:
if table.description is None or str(table.description.root) == "":
columns = [
{"name": col.name.root, "dataType": str(col.dataType.value),
"description": str(col.description.root) if col.description else ""}
for col in (table.columns or [])
]
if not columns:
continue
description = generate_table_description(
table.name.root, columns
)
# 自動生成フラグをタグとして付与
table.description = description
om_client.patch_entity(
entity_type=Table,
entity_id=table.id,
original=table,
updated=table
)
enriched_count += 1
print(f"✓ {table.name.root}: {description[:50]}...")
print(f"\n{enriched_count}件のテーブルを更新しました")これを週1回Airflowで回している。AIが生成した説明には ai_generated タグを付けて、人間がレビューした後は verified タグに変える運用にした。地味に便利で、「ドラフトがある状態」と「何もない状態」では、人間のレビュー速度が全然違う。
運用して分かった、データカタログが「死ぬ」パターン
3回失敗してるので、死に方のパターンは熟知している。
パターン1: データエンジニアだけが使うカタログ
アナリストやビジネス側の人が使わないと、結局「エンジニアがメンテするだけで誰も見ない」状態になる。うちは導入時に「BIツールの新しいダッシュボードを作るときは必ずカタログでデータソースを確認する」というプロセスを義務付けた。MetabaseとSupersetの比較でも書いたけど、BIツールとカタログの連携を強制的に作るのが効く。
パターン2: スキーマ変更に追従できない
テーブルのスキーマが変わってもカタログが更新されず、情報が古いままになる。これはインジェストの自動化で対応できるけど、完全に自動化できないのがLineageとオーナー情報だ。スキーマ変更のPRに「カタログ更新確認」のチェックを入れるのが現実的な対策。
パターン3: 「検索しても出てこない」体験
最初の1〜2ヶ月が一番危険で、メタデータが薄い状態だと検索しても関係ないものが出てきて「使えないツール」という印象になる。最初の3ヶ月は重要テーブル100個に絞って丁寧にメタデータを育てることを優先した。
3プロジェクト分の経験をベースに形骸化の原因を振り返ると、こんな内訳になった。ツール選定が原因で失敗したのはたった10%で、残り90%はプロセスと品質の問題だった。これは声を大にして言いたい。
pie title データカタログが形骸化した原因（N=3プロジェクト経験ベース）
"メタデータ品質の低さ" : 35
"使う動機付けの欠如" : 30
"運用プロセスの未整備" : 25
"ツール選定ミス" : 10まとめ
3回の失敗から学んだことを正直に整理すると、結局のところ「いいツールを選ぶ」より「使われ続ける設計をする」ほうがはるかに難しい。以下が個人的に外してはいけないと思うポイントだ。
- ツール選定の前に「誰が何のために使うか」を決める：Collibraは大企業のガバナンスチームが主体の場合に強い。エンジニア主体ならOpenMetadata・DataHubがコスパ高い。
- 最初の3ヶ月は「重要テーブル100個」だけに集中する：全テーブルを同時にやろうとすると全部中途半端になる。
- AI自動生成はドラフト作成ツールとして使う：2026年時点では精度60〜70%。レビューフローとセットで設計する。
- カタログを「使わざるを得ない」プロセスに埋め込む：BIダッシュボード作成、PR承認、オンボーディングなどの既存フローに強制的に組み込む。
- Lineageは完全自動化できないと割り切る：手動登録のルールと、それをモニタリングする仕組みの両方が必要。
まだデータカタログを入れていないチームは、まずDataHubかOpenMetadataをローカル環境で動かして、自分たちのBigQuery・Redshiftと繋いでみるのが早い。DockerComposeで5分で立ち上がるので、「まず触ってみる」コストが低いのがOSSの強みだ。皆さんのチームはどんな構成で運用してますか？Xで教えてもらえると嬉しい。