便利なソフトをAIが実際に動かしてわかりやすくレポート

🤖 AI自動レポート column

Databricks Unity Catalog 向けデータガバナンス基盤「Ontos」— データメッシュ・契約・コンプライアンスを一元管理

タグ DatabricksUnity Catalogデータガバナンスデータ契約Data MeshODCSコンプライアンス自動化データプロダクトcolumnコラムlinuxLinuxGitHubオープンソースdatabrickslabsontos
📦 GitHubで見る

Databricks Unity Catalog 向けデータガバナンス基盤「Ontos」— データメッシュ・契約・コンプライアンスを一元管理

ひとことでいうと

Ontos（オントス）は、Databricks Unity Catalog の上で動く、データガバナンス（データの管理・品質・ルール）の専用プラットフォームです。「誰がどのデータを持ち、どんな品質保証があるか」を明文化・自動化するためのツールで、大規模なデータチームが共通のルールのもとで協働できる環境を整えます。データ契約・データプロダクト・コンプライアンス自動化・セマンティックモデルをひとつにまとめており、組織全体のデータ品質・所有権・ライフサイクル管理を一元的に担います。Data Mesh（データを分散・自律的に管理するしくみ）と ODCS（Open Data Contract Standard）v3.1.0 という国際標準に沿った設計が特徴です。

このソフトで何ができる？

Ontos が解決する主な課題は「データの所有者・品質保証・利用権限を明文化し、自動的に管理すること」です。具体的には次の機能を持ちます。

  • データプロダクト管理: テーブル・ビュー・関数・ML モデル・ダッシュボードなど Databricks 上の資産を「プロダクト」としてまとめ、所有者・ライフサイクル・公開範囲を管理します。
  • データ契約の定義: ODCS v3.1.0 に従い、スキーマ・品質ルール・SLO（サービスレベル目標）・意味情報を形式仕様として記述できます。
  • データセット登録: Unity Catalog・Snowflake など複数のシステムにまたがる資産を「データセット」として登録し、開発・検証・本番の各環境で資産と契約を紐付けます。
  • 組織構造の反映: ドメイン・チーム・プロジェクトの階層でデータ作業を整理し、Data Mesh アーキテクチャへのマッピングをサポートします。
  • セマンティックモデル（知識グラフ）: 技術的な資産をビジネス概念に結び付けるナレッジグラフを構築し、自然言語での検索や共通語彙の維持を可能にします。
  • コンプライアンス自動化: 独自の DSL（特定用途向けの小型言語）でガバナンスポリシーを宣言的に定義し、タグ付け・通知・強制適用などを自動実行します。
  • レビューワークフロー: データ管理者（Data Steward）が資産を本番昇格前に正式レビュー・承認できるフローを提供し、AI 支援分析と完全な監査ログを付帯します。
  • MCP（Model Context Protocol）対応: データガバナンスの情報を AI アシスタントに公開し、自然言語クエリや自動化を実現します。

こんな人におすすめ

1. データエンジニアリングチームのリーダー

Databricks 上の資産が増えるにつれてオーナーシップや品質保証が曖昧になりがちな組織に向いています。ODCS ベースのデータ契約を標準化することで、チーム全体が同じ言葉とルールで動けるようになります。

2. データガバナンス担当者・最高データ責任者（CDO）

コンプライアンス要件（タグ付け・アクセス制御・SLO 監視）を手作業ではなく DSL と自動化ルールで管理したい方に最適です。セキュリティ担当者やガバナンス部門が中心となって導入することで、組織全体のデータ品質管理を効率化できます。

3. Data Mesh を導入・検討している企業

ドメイン分割・データプロダクト思考・セルフサービスプラットフォームなど Data Mesh の実践フレームワークとして活用できます。各ドメインチームが独立して契約・プロダクトを定義しながら、全社的なガバナンスを維持する構成が取れます。

アーキテクチャと技術スタック

Ontos は Databricks App として動作するフルスタックの Web アプリケーションです。フロントエンドには React + TypeScript と Tailwind CSS・Shadcn UI を採用し、バックエンドは Python + FastAPI と SQLAlchemy ORM で構築されています。データベースはローカル開発時に PostgreSQL を使用し、本番環境では Databricks の Lakebase（マネージド PostgreSQL 互換サービス）を利用します。Unity Catalog との操作には Databricks SDK を使用し、データベースのバージョン管理には Alembic（マイグレーションツール）が組み込まれています。ビルドには Python 側に Hatch、Node.js 側に Yarn v1.x Classic を使います。

バックエンドは src/backend/src/ 以下に common/・controller/・db_models/・models/・repositories/・routes/ という明確な層分けがされており、ビジネスロジックと DB アクセスが分離された設計です。フロントエンドは src/frontend/src/ に components/・views/・hooks/・stores/・types/ を持ち、React のベストプラクティスに沿った構造になっています。

インストール・使い方

前提条件

作業を始める前に、以下のツールが手元の環境に入っているか確認してください。

  • Python 3.10〜3.12（動作確認済みバージョン: 3.12.13）
  • Node.js 18 以上
  • Yarn v1.x Classic（JavaScript のパッケージ管理ツール）
  • Hatch（Python のビルドツール）
  • PostgreSQL（ローカル開発用のデータベース）
  • Databricks アカウントおよび Unity Catalog へのアクセス権

Step 1: リポジトリを手元にコピーする

ターミナル（文字で命令を送る画面）を開き、以下のコマンドをコピー＆ペーストして実行します。

git clone https://github.com/databrickslabs/ontos.git
cd ontos

git clone でリポジトリ（ソースコードの置き場）をダウンロードし、cd でそのフォルダに移動します。

Step 2: フロントエンドの依存関係をインストールする

cd src/frontend
yarn install

画面表示に必要な部品（ライブラリ）を Yarn でまとめてダウンロードします。完了まで数分かかる場合があります。

Step 3: バックエンドの環境設定をする

cd ../../src/backend
cp .env.example .env

cp コマンドで設定ファイルのサンプルをコピーします。コピーしたあとは .env ファイルをテキストエディタで開き、Databricks の接続情報・PostgreSQL の接続文字列などを自分の環境に合わせて書き換えます。.env.example 内のコメントを参考にしながら一項目ずつ確認するのがおすすめです。

Step 4: ローカルでサーバーを起動する（ターミナルを 2 つ使います）

ターミナル 1 — フロントエンド（画面側）の起動:

cd src/frontend
yarn dev:frontend

起動すると http://localhost:3000 でフロントエンドが表示されます。localhost とは「自分のパソコン」を指す特別なアドレスです。ブラウザのアドレスバーにそのまま入力してアクセスできます。

ターミナル 2 — バックエンド（処理側）の起動:

cd src
mkdir backend/static
hatch -e dev run dev-backend

http://localhost:8000 でバックエンド API が起動し、http://localhost:8000/docs で API 仕様書（Swagger UI）が確認できます。Swagger UI とは、API のエンドポイント（機能の窓口）をブラウザ上で一覧・操作できる画面のことです。

Step 5: Databricks 本番環境へデプロイする

databricks bundle deploy --var="catalog=app_data" --var="schema=app_ontos"
databricks apps deploy <app-name>

<app-name> は自分のアプリ名に書き換えてください。databricks bundle deploy で必要なリソースを作成し、databricks apps deploy でアプリを本番環境に公開します。

デモについて

Ontos は Databricks Unity Catalog・PostgreSQL・Databricks 認証基盤を前提とするフルスタック Web アプリケーションです。これらの外部サービスとの連携が必須であるため、ブラウザ上だけで完結するインタラクティブなデモは現時点では提供されていません。実際の動作確認は、上記「インストール・使い方」の手順に従ってローカル環境を構築してから行ってください。

動かしてみた

実際にリポジトリを展開して環境情報を確認しました。Python 3.12.13 が利用可能なことが確認でき、README が示す Python 3.10〜3.12 の動作要件を満たしています。リポジトリのファイル構造も正常に展開されており、以下のような依存関係ファイルや設定ファイルの存在を確認しました。

./src/requirements.txt
./src/pyproject.toml
./src/requirements.in
./src/app.yaml          # Databricks App 設定
./src/databricks.yaml   # Databricks Bundle 設定
./src/manifest.yaml
./scripts/check-alembic-heads.py
./plans/schema-importer-table-expand-recursion.md
./plans/directory-lookup-and-principal-picker.md

plans/ ディレクトリにはスキーマインポーターの再帰展開やディレクトリルックアップといった機能の設計書が格納されており、活発な開発が続いていることが確認できました。.pre-commit-config.yaml が存在することから、コミット（変更の保存）前にコード品質チェックが CI（継続的インテグレーション＝自動テスト・検査のしくみ）に組み込まれていることもわかりました。

はじめの一歩：実践のコツ

セットアップ後にすぐ試せる行動をまとめました。

  • まず Swagger UI を開く: バックエンド起動後すぐに http://localhost:8000/docs を開きます。データプロダクト・データ契約・組織構造などすべてのエンドポイントが一覧でき、Databricks 接続の設定前でも API の全体像が把握できます。
  • コンプライアンス DSL のクイックスタートを読む: src/docs/compliance-dsl-guide.md がもっとも短い入門ルートです。タグ付け・通知・強制適用のルールを YAML に近い構文で宣言的に書けます。
  • DSL の構文リファレンスを手元に置く: src/docs/compliance-dsl-reference.md に完全な文法が載っています。ルールを書くときに並べて参照すると迷わず進められます。
  • .env は丁寧に設定する: Databricks の接続情報が正しく入っていないと、起動後に機能が制限されます。.env.example のコメントを参考にしながら一つずつ確認しましょう。
  • plans/ フォルダを読む: 開発中の機能設計書が入っており、近くリリースされる機能の方向性を把握できます。カスタマイズや機能拡張を検討するときの参考になります。

活用アイデア

  • データ品質 SLO の自動監視: データ契約に SLO を定義し、コンプライアンス DSL で閾値違反時に Slack 通知・タグ変更・アクセス制限を自動実行するパイプラインを構築できます。
  • Data Mesh ドメイン間のデータプロダクト公開管理: 各ドメインチームが独立してデータプロダクトを登録・バージョン管理し、Data Steward によるレビューを経て他ドメインに公開するフローを標準化できます。
  • MCP 経由の社内 AI アシスタント統合: Model Context Protocol を通じてガバナンス情報を LLM に公開し、「このテーブルのオーナーは誰か」「品質ルールに違反しているアセットは何か」といった質問を自然言語で社内 AI ツールから直接実行できます。
  • Snowflake など複数データソースの統合管理: Unity Catalog だけでなく Snowflake などの外部システムの資産もデータセットとして登録し、異なるプラットフォームにまたがるデータを一元的にガバナンス管理できます。
  • 新しいデータエンジニアのオンボーディング支援: セマンティックモデルとデータ契約を整備しておくことで、新メンバーが「このテーブルは何を意味するか」「誰に確認すればよいか」を自分で調べられる環境が整います。
  • 監査対応・コンプライアンスレポートの自動生成: 監査ログと自動タグ付けを組み合わせることで、コンプライアンス監査に必要な証跡を自動的に収集・提示できます。

用語とポイント解説

ODCS（Open Data Contract Standard） データ資産の正式仕様を記述するためのオープン標準で、Ontos は v3.1.0 に対応しています。かんたんに言うと「データのスペックシートを統一フォーマットで書くための国際ルール」です。これにより、チームをまたいでデータの仕様が正確に伝わるようになります。

ODPS（Open Data Product Specification） データプロダクトの標準仕様のことです。かんたんに言うと「データを『製品』として定義するときに使うフォーマット」です。ODCS がテーブル単体の仕様なら、ODPS はそれをまとめた製品全体の仕様書にあたります。

Data Mesh（データメッシュ） データを中央集権的ではなく、各ドメインチームが分散・自律的に管理するアーキテクチャパターンです。かんたんに言うと「データ管理の権限と責任をチームごとに分散させるしくみ」です。Ontos はこの考え方を実践するためのフレームワークとして機能します。

MCP（Model Context Protocol） AI アシスタントと外部システムをつなぐプロトコル（通信ルール）です。かんたんに言うと「ChatGPT などの AI がシステムの情報を読み書きできるようにするための橋渡し」です。Ontos はこれを通じて AI が自然言語でガバナンス情報を問い合わせることを可能にします。

DSL（Domain-Specific Language） 特定の用途だけのために作られた小型のプログラミング言語です。かんたんに言うと「コンプライアンスルールを書くための専用の書き方」です。Ontos では YAML に近い構文でガバナンスポリシーを宣言的に記述できます。

SLO（Service Level Objective） データ品質の達成目標値のことです。かんたんに言うと「このデータは○○% の精度を維持する、という約束を数字で定めたもの」です。Ontos のデータ契約に SLO を組み込むと、自動監視と違反時のアクションまで一緒に設定できます。

Alembic（アレンビック） SQLAlchemy（Python 用データベースライブラリ）のデータベースマイグレーション（スキーマ変更管理）ツールです。かんたんに言うと「データベースの構造変更を安全に記録・適用するためのツール」です。Ontos はこれでデータベースのバージョン管理を行っています。

Lakebase Databricks が提供するマネージド（管理不要）の PostgreSQL 互換データベースサービスです。かんたんに言うと「Databricks 環境で PostgreSQL がすぐ使えるサービス」です。本番運用時はローカルの PostgreSQL の代わりにこれを利用します。

Unity Catalog Databricks のデータガバナンス基盤で、テーブル・ビュー・関数・ML モデルなどの資産を一元管理するカタログ機能です。かんたんに言うと「Databricks 上のデータ資産をまとめて管理する台帳」です。Ontos はこの上で動作し、Unity Catalog の資産をより細かく管理・契約化します。

Data Steward（データ管理者） データ品質・利用ルール・メタデータの整備を担当する役職・役割です。かんたんに言うと「データの品質と使い方のルールを守る番人」です。Ontos のレビューワークフローでは、この役割が資産を本番昇格前に承認します。

Ontos は、Databricks Unity Catalog を基盤とする企業のデータガバナンスニーズに応えるために設計された本格的なプラットフォームです。ODCS 標準準拠のデータ契約管理から DSL ベースのコンプライアンス自動化、MCP による AI 統合まで幅広い機能を持ちます。React + FastAPI というモダンな技術スタックと明確なレイヤー構造により、カスタマイズや機能拡張もしやすい設計になっています。ぜひデータ品質の自動監視や Data Mesh のドメイン間ガバナンス管理などに活用してみてはいかがでしょうか。