こちらは ドワンゴ Advent Calendar 2025 14日目の記事です。
- メタデータとデータカタログ
- ドワンゴにおける旧来のデータカタログシステムとその課題
- データカタログシステムの導入にあたっての主要な要件
- OSSをホスティングする落とし穴
- スタートアップとの協働
- まとめ
データマネジメント部の塚本です。
皆さんは、データカタログというものをご存知でしょうか？
メタデータとデータカタログ
データカタログは、分析に使用するデータのメタデータ自体、もしくは、そのメタデータを管理するためのシステムのことをいいます。
メタデータとは、データの付属情報です。
例えば、「28」というデータがあったとします。「28」自体はれっきとしたデータですが、それ単体では「28」が何を意味しているのかわかりません。「28は、年齢を意味します。」「このデータは、2025-04-01に更新されました。」というような付属情報が得られて初めてデータ分析が可能な状態になります。
『データマネジメント知識体系ガイド (DAMA-DMBOK) 第二版』によると、メタデータには、以下の3種類があります。
- ビジネスメタデータ
- テクニカルメタデータ
- オペレーショナルメタデータ
ビジネスメタデータは、ビジネスユーザーがデータを理解し、活用できるようにするための情報です。
- データセット、テーブルおよびカラムの定義と説明
- 業務ルール、変換ルール、計算方法および導出方法
- データのセキュリティ/プライバシーレベル
- データ利用上の注意
などが該当します。
テクニカルメタデータは、データがどのように構造化され、保存されているかという技術的な詳細に関する情報です。
- データベース名、テーブル名、カラム名
- データ型
- データCRUD
などが該当します。
最後に、オペレーショナルメタデータは、データの処理とアクセスの詳細に関する情報です。
- データベースおよびテーブルの最終更新日時、作成日時
- データ処理ジョブの実行ログ
- データのサイズの増減や利用パターン
などが該当します。
これらのメタデータは、企業におけるデータ活用を促進し、DataOpsを実現するために欠かせない情報です。このため、メタデータを適切に管理できる仕組みが必要になります。その仕組みが、データカタログということになります。
データカタログは、主に、
- ドキュメントシステムに記述する（例：Excel）
- 内製システムを構築する（例：ANA のデータカタログ「Moana」）
- OSSをホスティングする（例：OpenMetadata）
- DWHに付属するサービスを利用する（例：Snowflake Horizon カタログ）
- SaaSを導入する（例：Alation）
ような実現パターンがあります。
ドワンゴにおける旧来のデータカタログシステムとその課題
ドワンゴにおいては、ドキュメントシステム（Confluence、GROWI.cloud）に記述する形でデータカタログシステムを実現していました。これはこれで機能していましたが、以下のような問題がありました。
- メタデータを手入力している
- メタデータを構造的に管理できていない
- グループ共用のドキュメントシステムがない
メタデータを手入力している
テクニカルメタデータやオペレーショナルメタデータの中には、DWHやデータオーケストレーションシステム（例：Apache Airflow、dbt）から機械的に取得可能なものが多々あります。実際に、データカタログシステムの多くは、機械的に取得可能なメタデータを自動的に収集する機能を提供しています。
しかし、ドキュメントシステムに記述する形だと、メタデータを人力でコピペしたり、メタデータの正しさを目視検査するケースが発生します。データカタログを整備するために手間が発生しており、（人間は必ずミスをするので、）メタデータの品質担保も難しいという問題がありました。
メタデータを構造的に管理できていない
ドキュメントシステムに、フリーテキストでメタデータを記述する場合、セマンティクスを一意に判別することが難しくなります。仮に、ドキュメントテンプレートを作っていたとしても、コーナーケースへの対応や作業担当者の違いによって、すべてのドキュメントについて機械的に扱える程、同等な形式・内容になりません。
こうなってしまうと、ある特定のメタデータを一括編集しようと思ってもできません。例えば、あるデータ群のデータオーナーを一括で変更できなかったり、あるカラムの仕様変更を一括で修正できなかったりします。
それ以外にも、セマンティクスを一意に判別することが難しくなるということは、人間は勿論のこと、AIがメタデータを理解することが難しくなり、折角、メタデータ管理を行っているのにも関わらず、AI-Readyなデータを整備できないことにもなってしまいます。
グループ共用のドキュメントシステムがない
これは、弊グループ固有の問題ですが、私達のチームは、KADOKAWAグループの様々な企業・事業に対してサービスを提供しています。そうした場合、①すべてのユーザーにとってアクセス可能なドキュメントシステムが必要になる、②データ/アナリティクスエンジニアの作業が楽になるようドキュメントシステムは極力集約されていて欲しい、という必要が生まれますが、グループ内には、そのニーズを満たすドキュメントシステムがない状況でした。
このため、私達のチームはユーザー向けに自前でドキュメントシステムや認証システムを整備しなければなりませんでした。（※ この辺りの話は、以下で話されています。）
ただ、グループ共用のドキュメントシステムを用意できたとしても、前述の通り、メタデータを構造的に管理できていないため、過去のドキュメントシステム（Confluence）上のメタデータを移行するのは完全な人力となり、費用対効果の観点から、最終的にデータ移行を行わず、二つのドキュメントシステムを使い分ける形に落ち着いてしまっていました。
データカタログシステムの導入にあたっての主要な要件
こうした問題を解決すべく、ドキュメントシステムに記述する形でなく、専用システムを導入する形でのデータカタログ整備に移ることしました。
データカタログを導入するにあたっての主要な要件としては、
- 複数のDWHを横断してメタデータを管理できる
- データカタログ整備自体に大きなコストをかけない
がありました。（※ 厳密には勿論、他にも沢山の要件があります。）
複数のDWHを横断してメタデータを管理できる
弊グループでは、歴史的経緯により、複数のCloud DWH（Snowflake、Amazon Redshift、Google BigQuery）が並列で稼働しています。
データカタログを整備するからには、どのシステムに、どんなデータが、誰に、どのような形で使われているのかを横断的に把握したいです。
したがって、DWHに付属するサービス（Snowflake Horizon カタログ、Amazon DataZone、Dataplex Universal Catalogなど）は採用できず、全てのCloud DWHへのコネクタを有するサードパーティー製のデータカタログシステムを利用する必要がありました。
データカタログ整備自体に大きなコストをかけない
他方で、サードパーティー製のデータカタログシステムを導入すると、新たなコストが発生します。
データ活用を促進するためには、メタデータ管理は欠かせませんが、メタデータ管理自体はビジネス価値を生み出しません。データ活用自体ですら、ビジネス価値を定量的に測ることが難しいのに、データカタログ整備の価値を定量化することは至難の業です。
サードパーティー製のデータカタログシステムは様々ありますが、最低でも年間数千万円かかるのが一般的です。しかも、大抵の利用ケースでは、最低価格で収まることはなく、さらに高くなります。
データ活用のコアシステムであるCloud DWHですら⚫️⚫️⚫️⚫️円/年なのにも関わらず、データカタログシステムだけでその⚫️分の1に相当するコストが上乗せされるということは、経営層に敬遠されますし、私自身も自信を持って投資対効果を説明できませんでした。
OSSをホスティングする落とし穴
というわけで、最初は、OSSのデータカタログシステムであるOpenMetadataをセルフホスティングことで解決しようとしました。
結論としては、失敗しました。OpenMetadata自体は、多種多様なコネクタをサポートしており、単純なメタデータ管理の機能だけでなく、データ品質管理の機能も有しており、多機能なソフトウェアでした。機能面だけで見れば、全く問題ありませんでした。しかし、コストに関して落とし穴がありました。
公式の案内に従って素直にAWS上にホスティングすると、LayerX社が以下の記事で紹介しているように、それなりのインフラコストがかかってしまいます。
LayerX社は、データカタログシステムを担当する内製エンジニアにインフラ構成を見直してもらうことで、この問題に対応しています。
Amazon OpenSearch ServiceからAmazon ECS上のOpenSearchに変更したことで、金銭的なコストは大幅に下がりました。一方で、マネージドサービスから自前ホスティングに変更したことで運用コストが上がっています。
しかし、弊社は、（担当者の離職などもあり、）OpenMetadataのセルフホスティングに常時アサインできる内製エンジニアがいない状況でした。こうなると、インフラ構成を試行錯誤したり、運用でカバーするだけでもキャッシュアウトが発生してしまいます。
加えて、OpenMetadata（データカタログシステム一般）は、バージョンアップが頻繁にあるプロダクトであるため、弊社固有の構成を作り込めば作り込むほど、バージョンアップに追従するためにも、その都度外注費が必要になり、キャッシュアウトが発生してしまいます。
じゃあ、内製エンジニアをアサインできるように（採用など）すればいいという話にもなりますが、データパイプラインの構築・運用にアサインする人が十分いると言えない中で、データカタログのインフラ管理のためだけにエンジニアを張り付かせるということは許容できませんでした。
メタデータ管理のための内製人材を増やすならまだいいですが、メタデータ管理のためのシステムのインフラを管理するために内製人材を増やすのは、元の問題を解決できていないと言えました。
スタートアップとの協働
最終的に、現在はデータカタログシステム（タヅナ）を販売するスタートアップと協働するという道を模索しています。内製する場合と比較して自由度は落ちますが、コストを抑制しながらデータカタロシステムに特化した専門家と一緒に仕事をすることができるため、今の所は上手くいっているように感じています。
この取り組み自体は現在進行形ですので、まとまった成果が出た時点で、事例として紹介したいと思いますが、タヅナの魅力は、
- メタデータを構造的に管理でき、一括編集ができること
- 仕様と実体の両方を扱えること
にあります。
メタデータを構造的に管理でき、一括編集ができること
メタデータを構造的に管理すること自体は、ほとんどデータカタログ製品でできますが、大抵の製品は編集機能が貧弱です。
- スキーマ情報を自動抽出できる
- テーブルやカラムの説明文を記述できる
- タグ付けできる
くらいの機能のものが一般的な認識です。生成AI技術の流行により、「テーブルやカラムの説明文を生成AIが自動的に作成してくれますよ。」みたいなことを売りにしたプロダクトが増えていますが、ビジネスメタデータは、ドメイン知識をもった人しか、正確な情報を記述できないので、合っているかもわからない情報を生成AIに量産されるよりは、ドメイン知識を持った人がいかに素早くメタデータを編集できるかの方が本質的に重要だと感じています。
特に、データマネジメントが体系的に行えるようになるほど、①テーブルを横断して共通のカラム定義が整備されたり、②ユーザーフレンドリーな形にテーブル・カラム定義がアップデートされたりするので、メタデータが全てテーブル > カラム単位で独立しており、一括編集もできない状態ならば、一度書いたメタデータが放置され、徐々にメタデータの品質が劣化していくこととなります。（実際に、弊社のConfluenceで実現したデータカタログもそうなっていました。）
仕様と実体の両方を扱えること
弊社では、ELTやデータマートに関するアプリケーションを実装する際には、事前に仕様書を作成します。したがって、DWHやデータオーケストレーションシステムにデータが入る前に既にスキーマ定義を手動で記入していることがあります。また、データソースシステムのDBダンプを受け入れる際には、データソースシステムのERDを参考に作業を進める場合もあります。
しかし、データカタログシステムの多くは、DWHやデータオーケストレーションシステムにデータが入った後からデータカタログ整備することを前提に作られています。ドキュメントシステムで記述する形であれば、そういった制約はないのですが、専用のデータカタログシステムを導入すると、仕様と実体をそれぞれどう使い分けるかが問題になります。システム設計時に作成する仕様書（例：UML）と実稼働しているコードの整合を、どれだけ維持する労力を払うのかと同じ話が、メタデータ管理においても発生するというわけです。
この問題について、タヅナでもまだ完全な解決策はない状態ですが、ベンダー側と議論しながらメタデータ管理を進められるだけでも安心感があります。
まとめ
まだ、データカタログ整備を進めている最中なので、歯切れのいい結論には至っていませんが、この記事では、私達のデータカタログ整備に関する紆余曲折について紹介してきました。
生成AIの活況により、サードパーティー製のデータカタログシステムが乱立しているように見えます。すべての製品に触れたわけではないですが、一長一短があるから、まだ市場が寡占状態に至っていないのではないかと思っています。
メタデータ管理に銀の弾丸はありませんが、今後のデータマネジメントにおける主要な要素の一つになるのは間違いないと思っていますので、企業の垣根を超えて、今後も情報を共有していければと思っています。
新卒採用を積極的に行っております。採用HPも是非ご覧くださいhttps://recruit.dwango.co.jp/job-introduction-engineer/データ基盤・機械学習エンジニア向け説明会も実施予定ですhttps://dwango.snar.jp/jobboard/detail.aspx?id=3aslQ2Y0Mgr1RlLh-Nn7LQ
