コンテンツにスキップ

データメッシュの権限整理 — 参考になる OSS リポジトリの地図

作成日: 2026-09-22 出典 / きっかけ: 「データメッシュの権限整理で参考になる GitHub リポジトリはあるか」の壁打ち。候補を列挙したうえで全リポジトリを GitHub 上で実在・規模確認した 関連: cloudflare_os_アーキテクチャ_整理（観測ログと Gatekeeper）10x_data_contracts_データマネジメント_整理（国内のデータ契約実践）ai_ガバナンス_誰がnoと言えるか_整理 aiエージェント時代のデータ基盤論争_意味層は要るか_整理 ai_agent_identity_標準化2026

0. 要点（3行）

  • 「データメッシュの権限整理」そのものを実装した決定版リポジトリは存在しない。探すならルールの決め方（組織・ポリシー）とルールの効かせ方（実装）の2軸に割って、4レイヤ（ポリシー / データ契約 / カタログ・リネージ / 権限エンジン）で当たるのが早い
  • 効くのは絶対値ではなくレイヤ間の分業。ポリシーは人間が文書で合意し、データ契約でデータプロダクトに貼り付け、リネージで「誰が何を読んだか」を記録し、最後に権限エンジンが実行時に判定する。1つのツールで全部やろうとすると必ず破綻する
  • 最小構成は datamesh-governance（型）→ ODCS（宣言）→ OpenLineage（観測）→ OpenFGA（判定） の4点。カタログ（OpenMetadata / DataHub）は3番目を製品として一気に埋める選択肢

1. なぜ「決め方」と「効かせ方」を分けるのか

データメッシュの連携型ガバナンス（federated computational governance）は、中央が全部決めるのでも各ドメインが勝手にやるのでもなく、「グローバルに決めるルール」と「ドメインが決めるルール」を線引きしたうえで、決まったルールをプラットフォームが自動で効かせるという構造を取る。

したがって権限整理は、次の2つが別の成果物になる。

成果物 誰が作るか 形式
ルールの決め方 ポリシー文書・運営モデル・決定記録 ガバナンス会議（ドメイン代表＋プラットフォーム＋法務/セキュリティ） Markdown・ADR
ルールの効かせ方 データ契約・アクセス判定・監査ログ プラットフォームチーム YAML・コード

この2つを混ぜると「ポリシーを書いたが誰も守らない」か「実装はあるが根拠が説明できない」のどちらかになる。以下のリポジトリはこの2軸のどこを埋めるかで並べている。

2. レイヤ別カタログ（全リポジトリ 2026-09-22 時点で実在確認済み）

レイヤ リポジトリ ★ ライセンス 何を埋めるか
① ポリシーの決め方 datamesh-governance/datamesh-governance.com 21 MIT 運営モデル＋グローバルポリシーの実例集
① ポリシーの決め方 agile-lab-dev/governance-decision-record 13 Apache-2.0 ポリシーを ADR 方式で起案→承認→発効させる型
② データ契約 bitol-io/open-data-contract-standard 1.1k Apache-2.0 ODCS。データプロダクトの所有者・ロール・利用条件を YAML で宣言
② データ契約 datacontract/datacontract-cli 1.1k — ODCS の lint / test / import / export（25形式超）
③ カタログ・リネージ OpenLineage/OpenLineage 2.7k Apache-2.0 「どのジョブがどのデータを読み書きしたか」の標準
③ カタログ・リネージ open-metadata/OpenMetadata 15.3k Apache-2.0 カタログ＋列レベルリネージ＋ロール/ポリシー＋PII タグ
③ カタログ・リネージ datahub-project/datahub 12.7k Apache-2.0 同上。LinkedIn 発、2020年 OSS 化
③ カタログ・リネージ unitycatalog/unitycatalog 3.5k Apache-2.0 Delta / Iceberg / Hudi 横断。テーブル・ファイル・関数・AI モデルまで一元管理
④ 権限エンジン openfga/openfga 5.8k Apache-2.0 Zanzibar 系 ReBAC。関係（辺）で権限を持つ
④ 権限エンジン authzed/spicedb 7.1k Apache-2.0 同上。認可「データベース」としての色が濃い
④ 権限エンジン open-policy-agent/opa 12.3k Apache-2.0 Rego で属性ベースのルールを書いて判定。CNCF Graduated（2021-02）
④ 権限エンジン cedar-policy/cedar 1.7k Apache-2.0 RBAC/ABAC。スキーマ検証と自動推論による形式検証が売り
（元ネタ） cloudflare/cloudflare-os 10k Apache-2.0 エージェントの観測ログを権限判定に使う実装例

★ は 2026-09-22 時点の GitHub スター数。スター数は規模感の目安であり品質の証明ではない。

3. ① ポリシーの決め方 — 文書と決定記録

3-1. datamesh-governance

一番直接的に参考になる。連携型ガバナンスを運用するための指針・運営モデル・グローバルポリシー例をコミュニティで集めたリポジトリで、ディレクトリ構成がそのまま目次になっている。

datamesh-governance.com/
├── operating-model/        ← メンバー、協業モード、意思決定プロセス、コミュニケーションチャネル
├── policies/               ← データプロダクト定義、相互運用性、分離、発見可能性、
│                              品質、ドキュメント、アクセス制御、プライバシー、セキュリティ
├── architecture-decisions/ ← AWS S3 / BigQuery / Databricks などの技術選定記録
└── diagrams/

権限まわりで見るべきは policies/ のアクセス制御・プライバシー・セキュリティ、体制設計で見るべきは operating-model/（ドメイン代表＋プラットフォームチーム＋必要に応じて法務・コンプライアンス・セキュリティの専門家、という構成）。法務・HR・経理を巻き込む体制の叩き台として、ゼロから書くより速い。

規模は小さい（★21）が、ポリシーを何項目立てるか・各項目に何を書くかの粒度が分かるだけで価値がある。

3-2. governance-decision-record（GDR）

ADR（アーキテクチャ決定記録）のガバナンス版。「ポリシーを文書で終わらせずコードにする」運用の型を提供する。

  • ポリシーにライフサイクル状態を持たせる: DRAFT → APPROVED / REJECTED
  • ポリシー間の履歴関係を持たせる: NEW / AMENDS（改訂）/ SUPERCEDES（置換）/ DEPRECATED
  • GDR テンプレート＋実装例＋CUE 言語による検証ファイルをセットで用意してから発効させる

つまり「ポリシーの起案を Git の issue と merge request で回す」ワークフローそのものがテンプレート化されている。ポリシーに承認ゲートと版管理を付けるという発想は、権限整理を組織として回すうえで一番効く部分。

4. ② データ契約 — 権限・利用条件をデータに貼り付ける

データ契約は、スキーマ・品質・利用条件をデータプロダクトごとに宣言する仕組み。ポリシー（全社ルール）とアクセス判定（実行時）の間をつなぐ。

ODCS（Open Data Contract Standard）

  • Bitol（Linux Foundation AI & Data 傘下）が主導。現行 v3.2.0、公式メディアタイプは application/odcs+yaml;version=3.2.0
  • Roles セクションがあり、ロールごとのアクセス定義を書ける。「このテーブルは人事ドメイン所有、閲覧は○○ロールのみ」を YAML で持てる

Data Contract Specification との関係（前回「要確認」としていた点）

確認できた: 別仕様だった Data Contract Specification（DCS）は、ODCS v3.1.0 のリリースをもって deprecated となり、単一の業界標準を ODCS に寄せる方針が明言されている。datacontract-cli と Entropy Data での DCS サポートは 2026年末まで。新規に書くなら ODCS 一択で、DCS を使っている場合は移行期限が今年末という理解でよい。

datacontract-cli

ODCS の lint / test / import / export を行う CLI＋Python ライブラリ。Avro・JSONSchema・Protobuf・RDF など25形式以上の相互変換に対応。CI に組み込んで「契約を満たさないデータプロダクトはマージさせない」を作るのがここ。

国内の実践例は 10x_data_contracts_データマネジメント_整理 を参照（10X が datacontract-cli に貢献した事例）。

5. ③ カタログ・リネージ — 「誰が何を読んだか」の土台

OpenLineage

ジョブがどのデータを読み書きしたかを記録する標準（LF AI & Data の卒業プロジェクト、★2.7k）。コア概念は4つだけ。

Job ───has many──> Run ───reads──> Dataset (input)
 │                  │
 │                  └──writes─> Dataset (output)
 │
 └── Facets: コアエンティティに付く原子的なメタデータ片（拡張ポイント）

エージェント実行を1つの Job として扱えば、そのまま乗る。「エージェントが観測したリソースを記録する」仕組みを自前で作るなら、独自スキーマを起こすよりここに乗るのが素直。Facets が拡張ポイントなので、エージェント固有の情報（どのプロンプト起点か、どのモデルか）は Facet として足せる。

カタログ製品（OpenMetadata / DataHub / Unity Catalog）

OpenMetadata DataHub Unity Catalog
★ 15.3k 12.7k 3.5k
出自 — LinkedIn（2020 OSS 化） Databricks 発 → LF AI & Data
ロール/ポリシー ◯（authn/authz、roles、policies、SSO、bot/user トークン） ◯（ポリシー管理・アクセス制御） ◯（統一ガバナンス）
リネージ ◯ 列レベル。OpenLineage 対応、影響分析あり ◯ 列レベル。GraphQL API 記載なし（要確認）
分類・PII タグ ◯ classifications / tags ◯ tags / terms / domains —
その他 130超のコネクタ、MCP 認証対応 — Delta / Iceberg / Hudi 横断、AI モデルも資産として扱う

データのオーナーと分類タグ（PII・機密など）を管理する中心をどこに置くかの選択。OpenMetadata は OpenLineage 対応と MCP 認証を明記しているので、エージェント前提なら相性がよい。Unity Catalog はフォーマット横断とAIモデルまで含む資産管理が強みで、リネージ機能の有無は README からは読み取れなかった（要確認）。

6. ④ 権限エンジン — 実際に判定する部分

2系統ある。どちらか一方ではなく、両方を役割分担で使うのが普通。

ReBAC 系（関係で持つ）: OpenFGA / SpiceDB

Google の Zanzibar 論文（2019、Google+ / Calendar / Drive / YouTube の認可システム）に着想を得た関係ベース認可。スキーマを定義し、関係データを書き込み、「ユーザー X はリソース Z に対してアクション Y を実行できるか」を判定する。

「どうやってアクセス権を得たかを辺として持つ権限グラフ」はまさにこのモデル。成果物の共有権限や、「この成果物はこのデータから作られた」という関係の表現に向く。

user:ken ──member──> team:data-platform ──viewer──> dataset:hr_salary
                                                         │
artifact:report_42 ──derived_from──────────────────────┘

→ report_42 を誰かに共有する時、derived_from を辿って
   「相手が hr_salary の viewer か」を突き合わせる

OpenFGA（★5.8k）と SpiceDB（★7.1k）はほぼ同じモデル。SpiceDB は「認可データベース」として一貫性保証を前面に出す色が濃い。

ポリシー言語系（属性で判定）: OPA / Cedar

  • OPA（★12.3k、CNCF Graduated 2021-02）: Rego で書く汎用ポリシーエンジン。スタック全体に横断適用できるのが売り。「PII タグ付きデータは人事ロール以外に返さない」のような属性ベースのルール向き
  • Cedar（★1.7k）: RBAC/ABAC 対応。スキーマに対するポリシー検証と、symbolic compiler による具体的な反例つきの形式検証（自動推論）が特徴。ポリシーが増えた後に「このルールは到達不能」「この2つは矛盾する」を機械的に検出したいならこちら
使い分け 向くエンジン
「誰がどう権限を得たか」を辿りたい（共有・派生・グループ階層） OpenFGA / SpiceDB
「データの属性（PII タグ・機密度）で弾きたい」 OPA / Cedar
ポリシー自体の矛盾・到達不能を検証したい Cedar
インフラ・K8s・API ゲートウェイまで一気通貫でポリシーを効かせたい OPA

7. 元ネタ: Cloudflare OS の「観測ログ→権限判定」

今回の壁打ちの起点。Cloudflare が2026年8月に OSS 化したエージェントワークスペース（★10k / fork 1.2k、Apache-2.0）。権限整理の文脈で見るべき点は次の通り。

  • Gatekeeper: ユーザーとエージェントを外部サービスにつなぐ「ドライバ」に相当するレイヤ。Cloudflare Workers 上で Gatekeeper ごとに別 Worker として実装される
  • 観測ログ（observation log）: エージェントが観測したリソースをすべて記録し、その記録はエージェントとその成果物に紐づいたまま残る。他の人がワークスペースを開く・エージェントと対話する・成果物を見ようとしたとき、Gatekeeper がその人の当該リソースへのアクセス権を検証する
  • ケイパビリティ的な絞り込み: 「1リポジトリだけに限定」「issue は読めるがソースは読めない」「特定フィールドをマスク」「レート制限」「マージ前に承認必須」といった粒度で絞れる
  • 観測が書き込みを制約する: 機微データを読んだ事実が、その後の「特定の宛先への書き込み」「新しい共同編集者の招待」「他エージェントへの引き渡し」「外部への送信」を禁止する判断材料になる
  • Observer ID は overseer が observer レコードを作るときに生成する不透明なランダム文字列で、Gatekeeper には安定ハンドルとして渡る。verifier は observer 自身の GatekeeperUser（本人が選んだ接続済みアカウント）から mint された Fetcher

読むべきは docs/observers.md と Gatekeeper の設計ガイド、実装例としては packages/gatekeeper-github/。

アーキテクチャ全体（認証・認可・ゲートウェイ・実行分離・監査の5観点）は cloudflare_os_アーキテクチャ_整理 に既出。本ノートは権限グラフとデータガバナンスの接続にだけ焦点を当てている。

8. 最小構成案 — 4点セット

全部入れる必要はない。次の構成で今回の論点はほぼカバーできる。

 [決め方]                              [効かせ方]

 datamesh-governance                   OpenLineage
 ＋ GDR                                「エージェントが読んだデータ」を
 部門ごとのデータ分類とオーナーを決める   Job/Run/Dataset として記録
        │                                     │
        │ 文書で合意したルールを                │ 観測した事実を
        ↓ データに貼り付ける                    ↓ 判定材料にする
        │                                     │
      ODCS ─────────────────────────> OpenFGA
  データプロダクトごとに                 成果物の共有相手が
  所有者と利用条件を YAML で宣言          元データの権限を持つか突き合わせる
手順 使うもの 成果物
1. ポリシーの型を決める datamesh-governance の policies/ を下敷きに 部門ごとのデータ分類とオーナー一覧
2. 起案フローを決める GDR のテンプレート DRAFT→APPROVED の承認ゲート
3. データを宣言する ODCS ＋ datacontract-cli データプロダクトごとの契約 YAML、CI での lint
4. 観測を記録する OpenLineage エージェント実行＝Job としての read/write ログ
5. 共有時に判定する OpenFGA 共有相手 × 元データ権限の突き合わせ

カタログ製品（OpenMetadata / DataHub）を入れるなら手順 3〜4 を製品で一気に埋める形になる。その場合は ODCS を捨てるのではなく、カタログを SoT にして契約 YAML を生成するか、契約 YAML を SoT にしてカタログへ同期するかの向きを先に決める（両方向に書けると必ず壊れる）。

9. まとめ — 状況 → 推奨アプローチ

状況 推奨
そもそもポリシーの項目立てが分からない datamesh-governance の policies/ をコピーして自社版に削る
ポリシーは書いたが誰も守らない GDR で承認ゲートと版管理を付け、CUE 等で検証可能にする
データの所有者と利用条件が口伝 ODCS で宣言し、datacontract-cli を CI に入れる
DCS（旧仕様）を使っている 2026年末までに ODCS へ移行（CLI サポート期限）
「誰が何を読んだか」が残っていない OpenLineage。エージェント実行を Job として乗せる
カタログをゼロから作りたくない OpenMetadata（OpenLineage 対応・MCP 認証あり）か DataHub
共有・派生の連鎖で権限を追いたい OpenFGA / SpiceDB（ReBAC）
PII タグなど属性で機械的に弾きたい OPA（Rego）か Cedar
ポリシーの矛盾・到達不能を検証したい Cedar（symbolic compiler・反例つき）
エージェント前提の実装例が見たい cloudflare-os の docs/observers.md

この地図の使い方: 4レイヤのうち今どこが空白かを先に特定する。空白を埋める順番は ① → ② → ③ → ④ が基本で、逆順（権限エンジンから入る）は「何を守るのか」が決まっていないため必ず作り直しになる。

なお、リポジトリの活動状況（最終コミット・メンテ状況）は変わりやすい。本ノートの★数は 2026-09-22 時点の値であり、採用候補にする前に一次情報を再確認すること。

参考リンク

ポリシーの決め方

  • datamesh-governance: https://github.com/datamesh-governance/datamesh-governance.com
  • governance-decision-record: https://github.com/agile-lab-dev/governance-decision-record

データ契約

  • Open Data Contract Standard (ODCS): https://github.com/bitol-io/open-data-contract-standard
  • ODCS ドキュメント: https://bitol-io.github.io/open-data-contract-standard/
  • datacontract-cli: https://github.com/datacontract/datacontract-cli
  • Data Contract CLI の ODCS 解説（DCS deprecated の記述）: https://docs.datacontract.com/open-data-contract-standard
  • Data Contract Specification（deprecated）: https://github.com/datacontract/datacontract-specification

カタログ・リネージ

  • OpenLineage: https://github.com/OpenLineage/OpenLineage
  • OpenMetadata: https://github.com/open-metadata/OpenMetadata
  • DataHub: https://github.com/datahub-project/datahub
  • Unity Catalog: https://github.com/unitycatalog/unitycatalog

権限エンジン

  • OpenFGA: https://github.com/openfga/openfga
  • SpiceDB: https://github.com/authzed/spicedb
  • OPA: https://github.com/open-policy-agent/opa
  • Cedar: https://github.com/cedar-policy/cedar

元ネタ

  • Cloudflare OS: https://github.com/cloudflare/cloudflare-os
  • Cloudflare OS — observers ドキュメント: https://github.com/cloudflare/cloudflare-os/blob/main/docs/observers.md
  • Cloudflare OS — gatekeeper-github 実装例: https://github.com/cloudflare/cloudflare-os/tree/main/packages/gatekeeper-github
  • Cloudflare Blog «Cloudflare OS: an open platform for agents, apps, and work»: https://blog.cloudflare.com/cloudflare-os/

作成: 2026-09-22 ／ 最終更新: 2026-09-22