OpenMetadataとは？データカタログOSSの構成・実装手順と採用判断を解説【2026年版】

OpenMetadataは、データ発見・系譜追跡・品質テスト・ガバナンスを1つのデータモデルとREST APIに束ねたApache-2.0のオープンソース製品です。この記事では、5つのコンポーネントで構成される内部構造、JSON Schemaを単一の真実源に据えたデータモデル、70を超えるコネクタでメタデータを取り込む実装手順、安定版1.13系と2.0.0-rc1のどちらを選ぶかの判断、そしてDataHubと並べたときの採用条件までを実装者の目線で整理します。

まとめ：OpenMetadata採用可否を分ける3つの判断材料

導入可否は、機能一覧の広さではなく次の3点で決まります。第一に、JSON Schemaを起点にJava・Python・TypeScriptの型が生成される設計のため、自社固有のエンティティやカスタム属性を足す拡張コストが事前に読めること。第二に、Dockerでの最小起動でもメモリ6 GiB・4 vCPUを要求する常駐システムであり、データベースと検索インデックスまで面倒を見る担当者を置けるかどうか。第三に、1.13系のパッチが数日から数週間の間隔で流れ続けている以上、バージョンを固定したうえで更新計画を持てるかどうかです。

接続先が3〜5系統に収まり、BIツールのデータソース一覧と用語集シートで運用が回っている規模なら、この製品は過剰投資になります。以降では3つの判断材料を構成・実装・運用の順に分解します。

OpenMetadataの位置づけとデータカタログとしての機能範囲

最初に、この製品が何を担い、何を担わないのかを押さえます。

Uber発の設計思想とApache 2.0で公開されたOSSの成り立ち

リポジトリが作られたのは2021年8月で、Uberの社内データ基盤づくりに携わった技術者たちが立ち上げた経緯を持ちます。ライセンスはApache-2.0、主要言語はTypeScript、直近のプッシュは2026年8月4日と開発は止まっていません。公式リポジトリは自らを「The Open Context Layer for Data and AI」と説明し、人間の分析者だけでなくAIアシスタントやエージェントへデータの文脈を渡す層として位置づけ直しています。この出自は実装にも表れました。あとから機能を足したのではなく、最初にメタデータの標準仕様を決めてからコードを生成する順序で作られたため、仕様の外側で拡張する余地は意図的に狭く設計されています。

データ発見からリネージ・品質・ガバナンスまで1製品で担う守備範囲

1つのメタデータストアに載る対象は、テーブルやカラムだけではありません。ダッシュボード、パイプライン、メッセージングのトピック、MLモデル、ストレージ上のコンテナまで同じエンティティモデルの上に置かれます。だから「このダッシュボードの数字はどのテーブル由来で、そのテーブルはどのパイプラインが書き込んでいるか」を、ツールを行き来せず1本のAPIで辿れました。担当領域は横断検索によるデータ発見、リネージ、品質検証、ガバナンス、説明文やスレッドでの協働の5つです。データカタログという枠組み自体の目的や導入判断はデータカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説で扱っています。

JSON Schema起点のアーキテクチャと5コンポーネントの役割

公式のハイレベル設計は、サービング層とストレージ層を分離し、内部データモデルを知らなくてもRESTで操作できることを狙いに挙げています。

API・UI・取り込み基盤・エンティティ格納・検索の5層構成

中心にあるAPIサーバはJettyの上で動くJava実装で、すべての通信がここを通ります。エンティティと関係性の実体はリレーショナルデータベースに保存され、UIの検索はElasticsearchが受け持つ形です。

• API：Jetty上のJava。エンティティ操作の唯一の入口
• UI：TypeScript。検索と説明文の編集が主戦場
• 取り込み基盤：Python。コネクタとワークフローの実行体
• エンティティ格納：MySQLまたはPostgreSQL
• 検索：Elasticsearchのインデックス

この分離があるため、UIを使わずAPIだけで所有者やタグを一括投入する運用も成立します。初期整備を手作業に頼らず既存の台帳スプレッドシートから流し込める点は、立ち上げ工数に直結しました。

JSON Schemaが単一真実源として支える型生成と版管理の実装

メタデータの語彙はJSON Schemaで定義され、そこからAPI用のJavaクラス、取り込み基盤用のPythonクラス、UI用のTypeScript型が生成される仕組みです。だから独自エンティティやカスタム属性はスキーマを直せば3層へ一貫して伝わる反面、スキーマを迂回してデータベースを直接いじる拡張はバージョン更新で壊れる前提になります。エンティティ同士の結びつきはentity_relationshipテーブルに分離格納され、変更履歴はchange_eventテーブルが受け持ちます。「このカラムの説明文を最後に書き換えたのは誰でいつか」を後追いできる状態は、カタログの内容を巡って利用部門と認識が食い違ったときに効きました。

70超のコネクタとメタデータ取り込みワークフローの実装手順と設計

この製品の価値はコネクタの数そのものではなく、取り込みワークフローをどう組んで回し続けるかで決まります。

Database・Dashboard・Pipeline中心の9カテゴリの内訳

公式ドキュメントが列挙するコネクタは70超、カテゴリは9つです。分布には明確な偏りがあります。

Databaseに5割超が集中している事実は選定時に効きます。データウェアハウスとRDBが対象の中心なら候補はほぼ揃う一方、SaaS系の業務システムを直接カタログ化したい要件では既存コネクタが届かず自作が要りました。Metadataカテゴリに他カタログ製品からの移行口がある点も、乗り換え検討では見落とせません。

Dockerで6GiB・4vCPUを確保する初期セットアップの手順

公式のローカル手順はDockerへメモリ6 GiB以上と4 vCPU以上を割り当てることを前提とし、Docker本体は20.10.0以上、Docker Composeはv2.1.1以上を必要とします。

1. Dockerの割り当てをメモリ6 GiB・4 vCPU以上に変更する
2. Dockerとdocker composeのバージョン要件を満たす
3. 公式の構成ファイルを取得してコンテナ群を起動する
4. 使用ポートの空きを確認する
5. UIにログインして接続先を1件登録し取り込みを回す

ポートは事前確認をおすすめします。UIが8585と8586、同梱のAirflowが8080、Elasticsearchが9200と9300、MySQLが3306を使うためです。取り込み自体は段階的に足す設計で、まずメタデータ取り込みだけを夜間に回し、対象を絞ってからプロファイラを追加してください。プロファイラは対象テーブルへ統計クエリを流すので、いきなり全社の本番ウェアハウスに向けると課金と負荷が跳ねます。

dbtやAirflowと連携してリネージを補完する取り込み構成

リネージはSQLの解析だけでは必ず穴が空きます。ビュー定義の外側でPythonが書いた中間テーブルや、ツール間をまたぐ受け渡しは追跡が切れるためです。Pipelineカテゴリの13コネクタにはApache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説で扱ったAirflowのほか、dbt Cloud、Fivetran、Dagster、Apache NiFiが含まれ、これらから取り込むタスク依存関係で穴を埋められます。特にdbtなら生成物のマニフェストを読ませることで、モデル間の依存とテスト定義を丸ごと持ち込めました。逆に変換処理がストアドプロシージャに閉じている環境では、この補完手段が使えず系譜の精度が落ちます。

データ品質テストとインシデント管理を組み込む運用設計の勘所と限界

この製品はカタログにとどまらず品質検証と観測の機能を内側に持ちます。専用ツールと守備範囲が重なるので、線引きを決めてから入れてください。

ノーコードのテスト定義と通知設計で検知から解決まで回す運用手順

品質機能の中心はテストスイートとテストケースで、カラムのNULL率や値域、行数の変動といった検査をコードなしでUI上に定義できます。実行は取り込みワークフローの一部としてスケジュールされ、プロファイラで先に分布や欠損率を取っておけば、どこへ検査を置くべきかが数字で見えました。落ちたあとを設計しないと失敗履歴だけが溜まるため、インシデント管理で担当者へ割り当て、通知の粒度を先に決めてください。即時通知にするテストと日次サマリで足りるテストを分けないと通知が飽和し、数週間で誰も見なくなります。

Great Expectationsとの守備範囲の違いと併用する判断軸

検査を本格的にコードで書きたい場合は専用ツールとの併用が現実解です。Great Expectationsとは？GX Core 1.xの部品構成・実装手順と採用判断を解説で扱ったGX Coreは、検査そのものの表現力とパイプラインへの組み込みやすさで優位に立ちます。判断軸は単純にできます。検査ロジックがSQLとUI設定で書き切れる範囲ならOpenMetadataだけで完結させ、Pythonでの条件記述やCI組み込みが要るならGX Coreを走らせて結果をOpenMetadataへ集約する。両方でテストを二重管理する構成だけは避けてください。定義が食い違ったとき、どちらが正なのか誰も判断できなくなります。

データ契約とガバナンスワークフローでスキーマ破壊を防ぐ運用手順

検知より前に壊さない仕組みを置く発想も取り込まれています。2026年7月31日公開の1.13.3では、データ契約とガバナンスワークフローの修正、アラート配信の修正、Snowflakeの外部キー反映の修正が入りました。契約の考え方そのものはデータ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説で整理しています。実務的な組み方は、守る対象を下流のBIや機械学習が直接読む数テーブルに絞り、違反検知をガバナンスワークフローに載せて、承認者を通さないとタグや所有者を変えられない状態にすることです。全テーブルへ契約を敷こうとすると定義作業だけで数か月が溶けます。

1.13系と2.0リリース候補の差分とバージョン選定の判断基準

バージョン選定を曖昧にしたまま導入すると、半年後の更新で身動きが取れなくなります。

2026年8月時点の安定版1.13系とリリース間隔の実測データ

GitHubのリリース一覧を2026年8月4日に確認したところ、直近の並びは1.13.1が6月27日、1.12.13が7月6日、1.12.14が7月28日、1.13.2が7月29日、1.13.3が7月31日でした。安定版の最新は1.13系です。読み取るべきは間隔の短さと、1.12系が並行保守されている事実の2点になります。7月末の5日間に3本のパッチが出ている以上、最新版へ追随し続ける運用は現実的ではありません。1.13系のあるパッチで固定し、検証環境で月次確認しつつ四半期ごとに本番を上げる計画のほうが現場は回りました。

2.0.0-rc1の位置づけと本番投入を待つべき条件の切り分け

2026年7月30日には2.0.0-rc1がプレリリースとして公開されています。リリース候補であり正式版ではないため、検証環境で移行の当たりを付ける対象であって本番のカタログを載せる対象ではありません。本番投入の条件は先に決めておきましょう。正式版が出ていること、自社が使っているコネクタが2.0系で動作確認されていること、1.13系からの移行手順が公式に示されていること。この3つが揃うまでは1.13系で運用します。メジャー更新はデータモデルの変更を伴う可能性があり、拙速な移行は取り込み設定の作り直しに直結しました。

DataHubとの比較で決めるOpenMetadata採用条件と見送り基準

OSSのメタデータ基盤を選ぶとき、実務でほぼ必ず並ぶのがDataHubです。ここは玉虫色にせず、条件を付けて言い切ります。

スター数と開発開始時期から読み取る両OSSの成熟度と方向性の違い

2026年8月4日時点のGitHub実測値を並べます。OpenMetadataはスター14,634、フォーク2,275、オープンissue975で、リポジトリ作成は2021年8月。DataHubは作成が2015年11月でスター12,441。ライセンスはどちらもApache-2.0です。DataHub側の構成や取り込み実装はDataHubとは？OSSメタデータ基盤の構成・取り込み実装と採用判断を解説で個別に扱いました。後発が星数で先行している点はこの5年の関心の移り方を映しますが、歴史の長さは実運用事例の厚みでもあります。数値だけで優劣を決めず、次の設計思想の差で判断してください。

モデルの拡張性と運用負荷で分かれる2製品の設計思想と実装の差

OpenMetadataは仕様を1本に絞り、その上へ機能を積む方向を選びました。単一の真実源があるので標準の枠内に収まる要件では設定量が少なく、品質やガバナンスも同じ製品内にあるため外部ツールを繋ぐ手間が減ります。DataHubは、メタデータモデルを自分たちで拡張していく前提が強い設計です。独自の資産種別や属性を大量に定義したい組織には自由度が効きますが、その自由度を設計しきる人員が要ります。標準的なデータウェアハウスとBIの構成を素早くカタログ化したいなら、OpenMetadataのほうが到達は早い。ここは断言できる差です。

OpenMetadataを採用してよい条件と見送るべき3つの場面

採用してよいのは次の条件が揃うときです。接続対象がDatabaseカテゴリ中心で10系統以上あること、カタログを維持する担当が最低1名決まっていること、品質テストまで同じ画面で見たい要求があること。

見送るべき場面は3つあります。第一に、接続先が3〜5系統でBIのデータソース一覧と用語集シートで足りている規模。ここへ常駐システムを足す意味はありません。第二に、独自のメタデータモデルを深く定義したい要件が先にある場合。標準スキーマへ合わせる作業が摩擦になり続けます。第三に、メモリ6 GiB・4 vCPU級の常駐環境を用意できず担当も置けない状況。取り込みが止まった瞬間に情報が古くなり、誰も信用しないカタログが残るだけでした。

自社運用で必要になるインフラ要件と初期構築コストの見積もり手順

実際に社内へ載せる場合の要件を具体化します。検証用のDocker構成と本番構成では、考えるべきことが変わります。

本番構成で見るMySQLとElasticsearchの分離運用の指針

本番ではエンティティ格納のデータベースと検索インデックスを分離してください。前者はカタログの実体そのもので、失えば説明文もタグも消えます。後者はインデックスであり、原理的には再構築が可能です。この性質の違いが運用設計を分けました。バックアップはMySQLまたはPostgreSQL側に厚く取り、Elasticsearch側は再インデックス手順を確認しておけば足ります。APIサーバは横に増やせる一方でデータベースが単一障害点になりやすいため、マネージドのデータベースサービスへ寄せる構成が扱いやすいでしょう。

レイクハウス基盤に載せる場合のメタデータ同期の設計と落とし穴

データレイクハウス構成の上でカタログを運用するときは、テーブル形式側が持つメタデータとの二重管理に注意が要ります。落とし穴は、スキーマの正がどちらにあるか決めないまま両方を編集してしまう状態です。テーブル形式のプロパティに書いたコメントとカタログのUIで書いた説明文が食い違い、取り込みのたびに上書き合戦になります。技術的なスキーマ情報はテーブル形式側を正とし、業務的な意味づけとタグをカタログ側の担当範囲にする。この境界を最初に文書化しておけば、後の混乱は減りました。

内製と外部委託で変わる立ち上げ工数と運用体制のコスト見積もり方

立ち上げ工数の内訳は、製品のインストールよりも「何をカタログに載せ、誰が説明文を書くか」の合意形成に寄ります。技術面は環境構築と最初のコネクタ接続までなら数日規模で、重いのはその後の対象データソースの棚卸し、所有者の割り当て、用語集の初版づくりです。社内に基盤エンジニアがいるなら内製で立ち上げ、運用のルール作りだけ外部の知見を借りる形が費用対効果に優れます。基盤側の人員が薄いなら、環境構築から取り込み設計、品質テストの初期セットまでを一括で外部へ任せ、運用を引き継ぐ進め方が現実的でしょう。一創ではデータ分析基盤構築・MLOps構築支援として、データカタログを含む基盤の設計・構築から運用移管までを請け負っています。

よくある質問

導入検討でよく挙がる質問を、実装と運用の観点でまとめます。

OpenMetadataは無料で使えますか？

OSS版のライセンスはApache-2.0で、無料で利用できます。ソースコードの改変や商用利用も許諾されています。ただし無償なのはソフトウェアだけで、稼働させるサーバ、データベース、検索インデックスのインフラ費用と運用担当の人件費は自社負担です。Dockerの最小構成でもメモリ6 GiB・4 vCPUを前提とするため、常時稼働のコストは事前に見積もってください。

OpenMetadataとDataHubはどちらを選ぶべきですか？

標準的なデータウェアハウスとBIの構成を短期間でカタログ化したいならOpenMetadata、独自のメタデータモデルを深く定義したい要件が先にあるならDataHubが向きます。前者はJSON Schemaという単一の仕様に寄せた設計で立ち上げが速く、品質テストとガバナンスまで同じ製品内で完結しました。標準スキーマの枠に収まらない要件が多い組織なら、拡張の自由度が高い後者のほうが摩擦は少なくなります。

どのバージョンを本番で使えばよいですか？

2026年8月時点では安定版の1.13系を選び、特定のパッチバージョンで固定する運用をおすすめします。2026年7月30日に2.0.0-rc1が公開されていますが、リリース候補であり本番向けではありません。1.13系はパッチが数日から数週間の間隔で出ているため、常に最新へ追随するのではなく、検証環境で月次確認しつつ四半期ごとに本番を上げる計画のほうが安定します。

コネクタが用意されていないデータソースはどうしますか？

取り込み基盤はPythonで書かれており、独自コネクタを実装する余地があります。ただし作る前に、REST APIでエンティティを直接登録する方法で足りないか確認してください。対象が数十テーブル規模で更新頻度も低いなら、既存台帳からAPIで流し込むスクリプトのほうが保守は軽くなります。継続的な自動取り込みが要る場合に限り、コネクタ実装を検討する順序が妥当です。

リネージはどこまで自動で取得できますか？

データウェアハウスのクエリ履歴やビュー定義を解析できる接続先では、テーブル間から列単位までかなりの範囲が自動で埋まります。一方、ストアドプロシージャ内の処理やツールをまたぐ受け渡しは追跡が切れました。この穴は、PipelineカテゴリのコネクタでdbtやAirflowのタスク依存を取り込んで補完するのが定石です。それでも残る部分は手動での系譜登録が必要になると考えてください。

関連記事

• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説：カタログを載せる土台となる基盤構成の選び方をまとめています
• スキーマレジストリとは？互換性モードとスキーマ進化の実装・採用判断を解説：スキーマ変更を上流で止める仕組みとカタログとの役割分担が分かります
• リバースETLとは？同期モードと差分検出の仕組み・API制約から実装判断を解説：カタログで把握したデータを業務システムへ戻す経路の設計に触れています