---
title: "OpenMetadataとは？データカタログOSSの構成・導入手順・2.0移行と採用判断を解説【2026年版】"
url: "https://www.issoh.co.jp/tech/details/16132/"
published: 2026-08-04
updated: 2026-09-27
categories: ["データ分析・BI"]
publisher: "株式会社一創"
---

# OpenMetadataとは？データカタログOSSの構成・導入手順・2.0移行と採用判断を解説【2026年版】

OpenMetadataは、データ発見・系譜追跡・品質テスト・ガバナンスを1つのデータモデルとREST APIに束ねたApache-2.0のオープンソース製品です。この記事では、5つのコンポーネントで構成される内部構造、Dockerで2.0.2を起動してログインするまでの手順、YAMLと`metadata ingest`でPostgreSQLのメタデータを取り込む実装、Pythonクライアントでの確認方法、1.13系から2.0系へ上げるときの破壊的変更、そしてDataHubと並べたときの採用条件までを、コピーして動かせるコード付きで整理します。版番号と数値は2026年9月26日時点の公式ドキュメントとGitHubの実測値です。

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

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

接続先が3〜5系統に収まり、BIツールのデータソース一覧と用語集シートで運用が回っている規模なら、この製品は過剰投資になります。以降では、まず構成を理解し、次に検証環境で実際に動かし、最後に運用と選定の判断へ進む順で分解します。

## OpenMetadataとは何か：データカタログOSSとしての位置づけと機能範囲

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

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

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

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

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

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

[公式のハイレベル設計ドキュメント](https://docs.open-metadata.org/v2.0.x/main-concepts/high-level-design)は、サービング層とストレージ層を分離し、内部データモデルを知らなくてもRESTで操作できることを狙いに挙げています。

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

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

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

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

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

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

## Dockerで2.0.2を起動してUIへログインするまでの検証環境構築手順

ここからは手を動かします。まず手元のマシンで全コンポーネントを立ち上げ、UIへログインするところまでが検証の範囲です。手順は[公式のローカルDockerデプロイ手順](https://docs.open-metadata.org/v2.0.x/quick-start/local-docker-deployment)に沿っています。

### メモリ6GiB・4vCPUとDocker 20.10以上を確保する事前準備

公式のローカル手順はDockerへメモリ6 GiB以上と4 vCPU以上を割り当てることを前提とし、Docker本体は20.10.0以上、Docker Composeはv2.1.1以上を必要とします。Docker Desktopを使っている場合は、設定画面のリソース割り当てを先に引き上げてください。既定値のままだとElasticsearchが起動途中で落ち、原因が分かりにくいエラーで止まります。バージョンは次のコマンドで確かめられます。

```
docker --version
docker compose version
```

ポートに空きがあるかどうかも、起動前の確認事項です。2.0.2のcompose定義では、UIとAPIが`8585`と`8586`、同梱のAirflowが`8080`、Elasticsearchが`9200`と`9300`、MySQLが`3306`を公開しています。手元でMySQLやAirflowを別に動かしている開発機では、ここが衝突の起点になります。

### docker-compose.ymlを取得して2.0.2のコンテナ群を起動する手順

リリースごとに配布されるcomposeファイルを取得し、イメージのタグを環境変数で固定してから起動します。タグを明示しておくと、あとで検証環境と本番の版がずれる事故を防げます。

```
mkdir openmetadata-docker && cd openmetadata-docker
curl -sL -o docker-compose.yml https://github.com/open-metadata/OpenMetadata/releases/download/2.0.2-release/docker-compose.yml

export OPENMETADATA_DB_IMAGE=docker.getcollate.io/openmetadata/db:2.0.2
export OPENMETADATA_SERVER_IMAGE=docker.getcollate.io/openmetadata/server:2.0.2
export OPENMETADATA_INGESTION_IMAGE=docker.getcollate.io/openmetadata/ingestion:2.0.2
docker compose -f docker-compose.yml up --detach

docker compose ps
```

起動すると、mysql、elasticsearch、スキーマを作る`execute-migrate-all`、openmetadata-server、ingestionの5サービスが並びます。`execute-migrate-all`はマイグレーションを終えると停止する一度きりのコンテナなので、終了状態で残っていても異常ではありません。PostgreSQLで動かしたい場合は、同じリリースに置かれた`docker-compose-postgres.yml`を取得して同じ手順を踏みます。

### 8585番ポートでUIへログインし初回の接続先を登録する手順

ブラウザで`http://localhost:8585`を開き、初期アカウントの`admin@open-metadata.org`とパスワード`admin`でログインします。同梱Airflowの画面は`http://localhost:8080`で、こちらも初期値は`admin`と`admin`です。この初期パスワードは検証環境専用と割り切り、共有サーバへ置く前に必ず認証方式を差し替えてください。

1. 設定画面からサービスを追加し、接続先の種類を選ぶ
2. ホスト・ポート・認証情報を入れて接続テストを通す
3. メタデータ取り込みのエージェントを作り、まず手動で1回実行する
4. テーブル一覧が出たら、スケジュールを夜間に設定する
5. 対象を絞ってからプロファイラを追加する

取り込みは段階的に足す設計です。プロファイラは対象テーブルへ統計クエリを流すので、いきなり全社の本番ウェアハウスに向けると課金と負荷が跳ねます。2.0系ではプロファイラの既定が全行走査から動的サンプリングへ変わったため負荷は下がりましたが、対象を絞る原則は変わりません。

## YAMLとmetadata ingestでPostgreSQLのメタデータを取り込む手順

UIからの登録は手軽な一方、設定がサーバの中にしか残りません。本番を見据えるなら、取り込み設定をYAMLにしてリポジトリで管理し、CIや外部のスケジューラから実行する形が扱いやすくなります。ここではPostgreSQLを例に、[公式の外部実行手順](https://docs.open-metadata.org/v2.0.x/connectors/database/postgres/yaml)を最小構成でなぞります。

### openmetadata-ingestionのインストールとボット用JWTの取得方法

取り込み基盤はPythonパッケージとして配布され、接続先ごとの依存はextrasで足します。サーバ側と同じ版に揃えるため、版を指定して入れてください。

```
python -m venv .venv
source .venv/bin/activate
pip install "openmetadata-ingestion[postgres]~=2.0.2.0"
metadata --help
```

APIへの認証には、UIの設定画面にあるボット一覧から取り込み用ボット（ingestion-bot）のJWTトークンを取得して使います。人のアカウントのトークンを流用すると、退職や権限変更で取り込みが止まるうえ、変更履歴に誰の操作か区別できない記録が残るためです。トークンはYAMLへ直書きせず、環境変数やシークレット管理から渡してください。

### 取り込みYAMLを書いてmetadata ingestで実行する手順

設定は「どこから読むか」の`source`、「どこへ書くか」の`sink`、「どのサーバへ認証するか」の`workflowConfig`の3ブロックでできています。次の内容を`postgres.yaml`として保存します。

```
source:
  type: postgres
  serviceName: local_postgres
  serviceConnection:
    config:
      type: PostgreSQL
      username: om_reader
      authType:
        password: change-me
      hostPort: localhost:5432
      database: app
      ingestAllDatabases: true
  sourceConfig:
    config:
      type: DatabaseMetadata
      markDeletedTables: true
      includeTables: true
      includeViews: true
sink:
  type: metadata-rest
  config: {}
workflowConfig:
  loggerLevel: INFO
  openMetadataServerConfig:
    hostPort: "http://localhost:8585/api"
    authProvider: openmetadata
    securityConfig:
      jwtToken: "${OM_JWT_TOKEN}"
    storeServiceConnection: true
```

```
export OM_JWT_TOKEN="ingestion-botのJWTをここに貼る"
metadata ingest -c postgres.yaml
```

`markDeletedTables`を有効にしておくと、接続先から消えたテーブルがカタログ上でも削除扱いになり、存在しない表の説明文が残り続ける状態を防げます。接続用のデータベースユーザーは読み取り専用で作り、カタログ用途にだけ権限を絞ってください。`storeServiceConnection`は既定で有効で、接続情報は暗号化してサーバへ保存されます。認証情報をサーバに持たせたくない構成なら無効にし、実行側で毎回渡す運用に切り替えます。

### Pythonクライアントで取り込み結果のテーブルを取得して確かめる手順

取り込みが終わったら、UIで目視するだけでなくAPIで確認する癖を付けておくと、後の自動化がそのまま組めます。[公式のPython SDKドキュメント](https://docs.open-metadata.org/v2.0.x/sdk/python)の接続方法に沿って、取り込んだテーブルを名前で引いてみます。

```
import os
from metadata.ingestion.ometa.ometa_api import OpenMetadata
from metadata.generated.schema.entity.services.connections.metadata.openMetadataConnection import (
    OpenMetadataConnection, AuthProvider,
)
from metadata.generated.schema.security.client.openMetadataJWTClientConfig import (
    OpenMetadataJWTClientConfig,
)
from metadata.generated.schema.entity.data.table import Table

server_config = OpenMetadataConnection(
    hostPort="http://localhost:8585/api",
    authProvider=AuthProvider.openmetadata,
    securityConfig=OpenMetadataJWTClientConfig(jwtToken=os.environ["OM_JWT_TOKEN"]),
)
metadata = OpenMetadata(server_config)
print(metadata.health_check())

# 完全修飾名は「サービス名.データベース名.スキーマ名.テーブル名」
table = metadata.get_by_name(entity=Table, fqn="local_postgres.app.public.orders")
print(table.name.root if table else "not found")
```

SDKを入れていない環境からは、REST APIを直接叩いても同じことが確かめられます。

```
curl -s -H "Authorization: Bearer ${OM_JWT_TOKEN}" \
  "http://localhost:8585/api/v1/tables?limit=5" | python -m json.tool
```

ここまで通れば、所有者やタグの一括投入、説明文の同期といった定型作業を同じクライアントで組めます。テーブル名の指定に使う完全修飾名は、サービス名から始まる点に注意してください。YAMLの`serviceName`を後から変えると別サービス扱いになり、説明文やタグが引き継がれません。

## 10カテゴリ100本のコネクタとリネージ補完を組み合わせる取り込み設計

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

### Database・Dashboard・Pipeline中心の10カテゴリの内訳と偏り

[公式ドキュメントのコネクタ一覧](https://docs.open-metadata.org/v2.0.x/connectors)を2026年9月26日に数えると、10カテゴリで100本でした。分布には明確な偏りがあります。

| カテゴリ      | 本数 | 代表的な接続先               |
| --------- | -- | --------------------- |
| Database  | 51 | Snowflake・BigQuery    |
| Dashboard | 18 | Tableau・PowerBI       |
| Pipeline  | 14 | Airflow・dbt Cloud     |
| Messaging | 4  | Kafka・Kinesis         |
| Drive     | 3  | Google Drive・SFTP     |
| Metadata  | 3  | Apache Atlas・Amundsen |
| ML Model  | 2  | MLflow・SageMaker      |
| Storage   | 2  | Amazon S3・GCS         |
| 検索エンジン    | 2  | Elasticsearch         |
| API       | 1  | REST                  |

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

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

リネージはSQLの解析だけでは必ず穴が空きます。ビュー定義の外側でPythonが書いた中間テーブルや、ツール間をまたぐ受け渡しは追跡が切れるためです。Pipelineカテゴリの14コネクタには[Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説](https://www.issoh.co.jp/tech/details/1441/)で扱ったAirflowのほか、dbt Cloud、Fivetran、Dagster、Apache NiFi、OpenLineageが含まれ、これらから取り込むタスク依存関係で穴を埋められます。特にdbtは、生成物のマニフェストを読ませることでモデル間の依存とテスト定義を丸ごと持ち込める仕組みです。dbt自体の役割やCoreとCloudの違いは[dbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方【2026年版】](https://www.issoh.co.jp/column/details/16548/)で整理しています。逆に変換処理がストアドプロシージャに閉じている環境では、この補完手段が使えず系譜の精度が落ちます。

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

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

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

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

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

検査を本格的にコードで書きたい場合は専用ツールとの併用が現実解です。[Great Expectationsとは？GX Core 1.xの部品構成・実装手順と採用判断を解説](https://www.issoh.co.jp/tech/details/16126/)で扱ったGX Coreは、検査そのものの表現力とパイプラインへの組み込みやすさで優位に立ちます。判断軸は単純にできます。検査ロジックがSQLとUI設定で書き切れる範囲ならOpenMetadataだけで完結させ、Pythonでの条件記述やCI組み込みが要るならGX Coreを走らせて結果をOpenMetadataへ集約する。なお[2.0.0のリリースノート](https://github.com/open-metadata/OpenMetadata/releases/tag/2.0.0-release)では、Great Expectations 0.x系の連携サポートが削除され、1.3系への移行を先に済ませるよう求めています。両方でテストを二重管理する構成だけは避けてください。定義が食い違ったとき、どちらが正なのか誰も判断できなくなります。

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

検知より前に壊さない仕組みを置く発想も取り込まれています。1.13系の後半ではデータ契約とガバナンスワークフローの修正が続き、2.0系ではガバナンスの受付フォームを独自に定義できるCustom Intake Formsと、既存の分類体系をOWLファイルから読み込む機能が加わりました。契約の考え方そのものは[データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説](https://www.issoh.co.jp/tech/details/16109/)で整理しています。実務的な組み方は、守る対象を下流のBIや機械学習が直接読む数テーブルに絞り、違反検知をガバナンスワークフローに載せて、承認者を通さないとタグや所有者を変えられない状態にすることです。全テーブルへ契約を敷こうとすると定義作業だけで数か月が溶けます。

## 1.13系から2.0系へ上げる前に確かめる破壊的変更と版の選び方

バージョン選定を曖昧にしたまま導入すると、半年後の更新で身動きが取れなくなります。旧版の本記事では「2.0はリリース候補のため本番投入を待つ」と書きましたが、状況は変わりました。

### 2026年9月時点の2.0系と1.13系のリリース間隔の実測データ

GitHubのリリース一覧を2026年9月26日に確認した並びは次のとおりです。

| 公開日        | 版         | 系列       |
| ---------- | --------- | -------- |
| 2026年7月30日 | 2.0.0-rc1 | 2.0系の候補版 |
| 2026年8月13日 | 2.0.0-rc2 | 2.0系の候補版 |
| 2026年8月21日 | 1.13.4    | 1.13系    |
| 2026年8月24日 | 2.0.0     | 2.0系の正式版 |
| 2026年9月2日  | 2.0.1     | 2.0系     |
| 2026年9月3日  | 1.13.5    | 1.13系    |
| 2026年9月11日 | 1.13.6    | 1.13系    |
| 2026年9月16日 | 2.0.2     | 2.0系     |

読み取るべきは2点です。2.0系は正式版の公開から3週間で2本のパッチが出ており、まだ修正が続く段階にあること。そして1.13系も並行して保守されていることです。これから新規に構築するなら2.0系のパッチ版で始め、公式ドキュメントも2.0系が既定の表示になっています。すでに1.13系で本番を運用しているなら、急いで上げる必要はありません。2.0系のパッチが落ち着くのを待ちつつ、検証環境で移行を1度通しておく計画が安全です。いずれの場合も特定のパッチで固定し、検証環境で月次確認しつつ四半期ごとに本番を上げる運用を基本にしてください。

### 1.13系から2.0系へ移行するときに設定を直す5つの箇所と作業内容

2.0.0のリリースノートは破壊的変更と移行作業を一覧で示しています。保存済みの設定は自動移行されるものが多い一方、外部に持っているYAMLやカスタムイメージは手で直す必要があります。

1. 意味検索の埋め込み設定：従来の自然言語検索の設定ブロック配下から新設の`llmConfiguration.embeddings`へ移す。移さないと意味検索が警告なく止まる
2. Databricks Pipelineの認証：外部YAMLの`token`を`authType`の下へ移す
3. 取り込みイメージ：Python 3.12ベースに変わったため、独自イメージを作り直し、`cp310`のバイナリwheelを外す（1.13.4から上げる場合は対応済み）
4. Great Expectations：0.x系から1.3系へ先に移行する
5. Knowledge Center：Context CenterのArticlesへ自動移行されるが、社内Wikiなどに貼った旧URLは切れる

影響が見えにくいのは1番目です。2.0系では埋め込み設定が独立したブロックになり、有効化スイッチも分かれました。

```
llmConfiguration:
  enabled: ${LLM_ENABLED:-false}
  provider: ${LLM_PROVIDER:-bedrock}
  embeddings:
    provider: ${EMBEDDING_PROVIDER:-bedrock}
    maxConcurrentRequests: ${MAX_CONCURRENT_EMBEDDING_REQUESTS:-10}
```

既定値は`enabled`が`false`なので、`LLM_ENABLED=true`と`LLM_PROVIDER`の両方を設定しない限り、埋め込みは動きません。アップグレード後に意味検索の結果が返らなくなったら、まずここを疑ってください。

### 2.0系のMCPサーバでAIアシスタントからカタログを引く使い方

2.0系ではMCPサーバが既定で有効になり、MCP対応のAIアシスタントやIDEから独自連携を書かずにカタログを問い合わせられます。MCPという規格の仕組みは[MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説](https://www.issoh.co.jp/tech/details/5736/)で解説しています。読み取り系のツールは結果とともに`nextCursor`を返すようになり、次の呼び出しで`cursor`を渡すと、同時書き込みがあっても取りこぼしのないページングが可能です。従来の`from`と`size`による指定も引き続き使えます。便利な反面、既定で有効という点は運用上の論点になります。AIからどのボット権限でカタログを読ませるかを決めないまま公開すると、本来見せない列の説明文やタグまで回答に混ざるおそれがあるため、権限設計を先に済ませてから接続してください。

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

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

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

2026年9月26日時点のGitHub実測値を並べます。OpenMetadataはスター15,334、フォーク2,410で、リポジトリ作成は2021年8月。[DataHubのリポジトリ](https://github.com/datahub-project/datahub)は作成が2015年11月でスター12,761、フォーク3,700です。ライセンスはどちらもApache-2.0です。DataHub側の構成や取り込み実装は[DataHubとは？OSSメタデータ基盤の構成・取り込み実装と採用判断を解説](https://www.issoh.co.jp/tech/details/16128/)で個別に扱いました。後発が星数で先行している点はこの5年の関心の移り方を映しますが、フォーク数ではDataHubが上回り、歴史の長さは実運用事例と改造の厚みでもあります。数値だけで優劣を決めず、次の設計思想の差で判断してください。

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

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

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

採用してよいのは次の条件が揃うときです。接続対象がDatabaseカテゴリ中心で10系統以上あること、カタログを維持する担当が最低1名決まっていること、品質テストまで同じ画面で見たい要求があること。2.0系からは、社内のAIアシスタントにデータの意味を答えさせたい要求も、採用を後押しする条件に加わります。

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

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

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

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

本番ではエンティティ格納のデータベースと検索インデックスを分離してください。前者はカタログの実体そのもので、失えば説明文もタグも消えます。後者はインデックスであり、原理的には再構築が可能です。この性質の違いが運用設計を分けます。バックアップはMySQLまたはPostgreSQL側に厚く取り、Elasticsearch側は再インデックス手順を確認しておけば足ります。2.0.2のcompose定義はElasticsearch 9.3系を同梱しているので、マネージドの検索サービスへ寄せる場合は対応版を合わせてください。APIサーバは横に増やせる一方でデータベースが単一障害点になりやすいため、マネージドのデータベースサービスへ寄せる構成が扱いやすいでしょう。もう1点、2.0.0のリリースノートは、同梱Airflowを内部の実行基盤として使う方式を2.1で非推奨にし、1.12で導入されたKubernetesネイティブの実行基盤へ移す方針を示しています。これから本番を組むなら、取り込みの実行をどこで回すかはKubernetes側を前提に設計しておくと、次の移行が軽くなります。

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

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

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

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

## よくある質問

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

### OpenMetadataは無料で使えますか？

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

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

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

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

2026年9月時点で新規に構築するなら、2.0系のパッチ版（9月16日公開の2.0.2など）を選び、その版で固定する運用をおすすめします。2.0.0は8月24日に正式公開されました。すでに1.13系で運用している場合は、1.13系も保守が続いているため急ぐ必要はなく、破壊的変更の一覧を検証環境で確かめてから計画的に上げてください。どちらの系列もパッチが数日から数週間の間隔で出るため、常に最新へ追随するより四半期ごとに本番を上げる計画のほうが安定します。

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

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

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

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

## 関連記事

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

---

出典: [OpenMetadataとは？データカタログOSSの構成・導入手順・2.0移行と採用判断を解説【2026年版】](<https://www.issoh.co.jp/tech/details/16132/>)（株式会社一創）