データ基盤を作って2年目、データエンジニアのSlackには毎日のように質問が届きます。「orders_summaryって、どのテーブルから作っているんですか」「customer_statusの3って何の意味ですか」「このダッシュボードの数字、信じていいんですか」。1件は5分で答えられても、週に15件来れば半日が消えます。そこへ情シスから「監査で、個人情報がどのテーブルに入っているか一覧を出してほしい」と依頼が来ました。経営企画には、カタログ製品の見積もりが届いています。年額は書いてありますが、入れたら質問が減るのかどうかは誰にも説明できません。

データカタログは、テーブルの意味、作った人、元になったデータ、使われ方を、誰でも引ける場所にまとめる道具です。うまくいけば、Slackで聞かれていた質問の多くが検索で片づきます。選ぶ製品は、いま届いている質問の種類と、カタログを運用できる人数で決まります。

状況別の早見表：運用できる人数で当たりをつける

あなたの状況最初に検討するもの選んだあとで困りやすいこと
カタログを運用する人を置けない。業務部門の人にも使ってほしいAtlan（商用のSaaS）料金は公開されておらず、規模が広がると年額が上がる
Kubernetesを運用できるデータ基盤の担当がいて、数千テーブル以上の規模DataHub（オープンソース。商用版はDataHub Cloud）Kafka・Elasticsearch・データベースなど、動かす部品が多い
オープンソースで始めたいが、運用の部品は少なくしたい。品質チェックも1か所で見たいOpenMetadata（商用版はCollate）版の更新が速く、計画的なアップグレードが要る
dbtで作ったテーブルしか使っていないdbt docsで足りるか先に試すdbt以外のテーブルやダッシュボードは載らない
質問がほとんど来ていないまだ入れない誰も書き込まないカタログが残る

最後の2行を飛ばさないでください。よく起きる失敗です。困りごとが小さいうちにカタログを入れると、説明が空欄のまま半年が過ぎ、「カタログは使えない」という評判だけが残ります。

入れる前に、届いている質問を2週間数える

カタログで減らせる質問と、減らせない質問があります。製品を比べる前に、Slackや問い合わせ窓口に届いた質問を2週間分集めて、種類ごとに数えます。冒頭の会社なら、次のようになります。

質問の種類2週間の件数カタログで減らせるかそのために載せるもの
このテーブル・列は何を意味するか12件減らせるテーブルと列の説明、用語集
誰に聞けばいいか6件減らせるテーブルごとの持ち主
この数字は信じていいか5件一部減らせる品質テストの結果、最終更新の時刻
これを変えたらどこに響くか4件減らせる元データから下流のダッシュボードまでのつながり（リネージ）
個人情報はどこにあるか3件減らせる個人情報のタグ
この分析をしてほしい6件減らせない（分析の依頼なので、カタログの対象外）

数えてみると、36件のうち25件はカタログで減らせ、一部減らせる5件を含めると30件になります。しかも上位の「意味」と「持ち主」は、製品を入れただけでは減りません。説明と持ち主を誰かが書いて初めて減ります。ここが本番です。

質問への回答に、年いくら払っているか

稟議のために、いまの手間を金額にしておきます。時間の数字は説明のための仮定です。

項目仮定年間の時間
Slackの質問への回答週15件 × 1件20分 × 48週240時間
監査向けの個人情報の一覧づくり年2回 × 1回40時間80時間
合計320時間

データエンジニアの年収を700万円とすると、会社が負担する総コストはその約3倍の2,100万円です。年1,900時間で割ると時給は約11,000円で、320時間なら年約350万円になります。カタログで質問が半分になれば、年約175万円分の時間が基盤の改善に戻ります。この見込みと、製品の年額、運用にかかる人の時間を並べて判断します。

Atlanは、運用を任せて業務部門にも使わせたいときに選ぶ

Atlanは商用のSaaSです。公式ドキュメントによると、顧客ごとに専用の環境（シングルテナント）をAWS・Azure・GCPのいずれかに用意する形で提供され、本体はAtlanが運用するクラウドの上に置かれます。ただし、データソースに接続する部分を自社の環境で動かすSelf-Deployed Runtimeがあり、接続に使う認証情報を自社の外に出さない構成が取れます。情シスから「データベースのパスワードを外部のSaaSに預けたくない」と言われたときの答えになります。

料金は公式サイトに載っておらず、営業との相談で決まります。運用する人を置かずに済む代わりに、年額で払う形です。

Atlanを選んでも、説明を書く人は社内に要ります。業務部門にも書き込んでもらうなら、用語集の項目ごとに持ち主を決め、「月に1回、自分の担当の説明を見直す」ところまで業務に組み込みます。

DataHubは、規模が大きく、運用できる人がいるときに選ぶ

DataHubはLinkedInで生まれたオープンソースのカタログで、LinkedInなどの本番環境で1,000万件以上のデータ資産を扱った実績があると公式ドキュメントに書かれています。商用版はDataHub Cloudです。

自社で動かす場合、公式のKubernetes向けの手順では、本体の前にElasticsearch、データベース（MySQL・PostgreSQL・MariaDB）、Kafkaを用意します。Neo4jは任意です。部品が多いぶん、運用には慣れた人が要ります。片手間では回りません。

メタデータの取り込みは、取り込み元と送り先をYAMLに書いて実行します。

# snowflake_recipe.yml
source:
  type: snowflake
  config:
    account_id: "my_account"
    warehouse: "COMPUTE_WH"
    username: "${SNOWFLAKE_USER}"
    password: "${SNOWFLAKE_PASSWORD}"
    role: "DATAHUB_READER"

sink:
  type: datahub-rest
  config:
    server: "http://localhost:8080"
datahub ingest -c snowflake_recipe.yml

画面からも取り込みを設定できます。列単位のリネージも扱えるので、「customer_idの定義を変えたら、どのダッシュボードに響くか」を列の単位でたどれます。取り込みに使うロールは、メタデータを読むだけの権限に絞ったものを用意します。構成の詳細と運用の勘どころはDataHubとはにまとめています。

OpenMetadataは、部品を少なくして品質も1か所で見たいときに選ぶ

OpenMetadataはオープンソースのカタログで、商用のマネージド版はCollateです。カタログに加えて、データ品質のテストも同じ画面で定義して実行できます。たとえば「テーブルの行数が一定の範囲に収まっているか」を見る tableRowCountToBeBetween のようなテストが用意されています。dbtのテストや専用の品質ツールと併用するか、OpenMetadataの中で済ませるかは設計で決めます。品質ツールの選び方はデータ品質ツールの選び方を参照してください。

自社で動かす場合の部品は、データベース（MySQL 8.0.42以上かPostgreSQL 15以上）と、検索エンジン（Elasticsearch 9系かOpenSearch 3系）です。取り込みの実行には、公式の最低要件ではAirflowを置く構成が示されています。DataHubの手順と比べるとKafkaが要らないので、運用する部品は少なく済みます。ただし版の更新が速く、版ごとに必要な部品のバージョンが変わるため、アップグレードの手順を毎回確かめます（数字は2026-10-17時点の公式ドキュメントで確認）。

dbt docsで足りるかを、先に確かめる

dbtで作ったテーブルしか使っていないなら、dbt docsでテーブルと列の説明、テスト、リネージを見られます。カタログ製品が必要になるのは、次のどれかに当てはまったときです。

当てはまることdbt docsで足りない理由
SaaSから取り込んだ生テーブルや、dbt以外で作ったテーブルも使っているdbt docsにはdbtのモデルしか載らない
BIのダッシュボードまでリネージをたどりたいダッシュボードはdbtの外にある
個人情報の場所を、監査向けに一覧で出したいタグを横断して管理し、一覧を出す機能が要る
業務部門の人にも検索してほしいdbt docsはエンジニア向けの画面

冒頭の会社は、BIのダッシュボードと個人情報の一覧の2つに当てはまります。カタログを入れる理由として、稟議にはこの2つを書きます。

最初の3か月は、よく使われる30テーブルに絞る

時期やること終わったと言える目安
1か月目質問を2週間数え、よく使われるテーブルを30個選ぶ。テーブルごとに持ち主を決める30テーブル全部に持ち主の名前がある
2か月目選んだ製品にメタデータを自動で取り込み、30テーブルの説明を持ち主が書く説明の空欄が0になる
3か月目Slackで質問が来たら、カタログのリンクで答えるよう決める同じ質問が2回来なくなる
4か月目以降個人情報のタグ、品質テストの結果、BIのリネージを順に足す監査向けの一覧をカタログから出せる

3か月目の「リンクで答える」が定着の分かれ目です。地味ですが効きます。答える人がSlackで丁寧に説明し続けると、聞く人はカタログを開く理由がありません。全社のデータ活用をどう進めるかは、データ活用推進でも扱っています。

よくある質問（FAQ）

データカタログを入れれば、テーブルの説明は自動で埋まりますか?

テーブル名、列名、型、リネージ、更新時刻などは自動で取り込めます。しかし「この列の3は休眠顧客を意味する」のような業務の意味は、誰かが書かない限り埋まりません。テーブルごとに持ち主を決め、説明を書く時間を業務として割り当てます。

dbtのdescriptionを書いていれば、カタログは要りませんか?

dbtで作ったテーブルしか使っていないなら、dbt docsで足りることがあります。SaaSから取り込んだ生テーブル、dbt以外で作ったテーブル、BIのダッシュボードまで含めて探したい、個人情報の一覧を出したい、といった必要が出たときに、カタログ製品を検討します。dbtのdescriptionは、どのカタログでも取り込めるので無駄になりません。

オープンソース版を自社で動かすには、何人くらい必要ですか?

人数より、Kubernetesと周辺の部品を運用した経験があるかで決まります。DataHubはElasticsearch・データベース・Kafkaを、OpenMetadataはデータベースと検索エンジンを動かします。どちらも版の更新に追従する作業が定常的に発生するので、1人に任せきりにせず、少なくとも2人が手順を分かる状態にします。

個人情報の管理は、カタログだけでできますか?

カタログで扱えるのは、個人情報がどのテーブル・列にあるかを把握し、一覧にするところまでです。実際に見られる人を絞るのは、DWH側の権限設定やマスキングの機能で行います。カタログで場所を把握し、DWHで見られる人を絞る、と役割を分けます。

AtlanとオープンソースのDataHub・OpenMetadataで迷ったら、どう決めますか?

カタログを運用する人を置けるかで決めます。置けないならAtlan、置けるならDataHubかOpenMetadataです。迷ったら、自社のよく使う30テーブルで2〜3週間の試用を並べ、「持ち主が説明を書くまでにどれだけ手間がかかったか」と「Slackの質問が減ったか」を比べます。画面の見た目より、この2つのほうが導入後の差になります。

出典

Slackに届く質問を2週間数えて、カタログで減らせる分と減らせない分を切り分けるところから、壁打ちにどうぞ。初回相談（30分・無料）で一緒に整理できます。