Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why Open Dataspacesのまとめ

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

Why Open Dataspacesのまとめ

Avatar for shibuiwilliam

shibuiwilliam

April 19, 2026

More Decks by shibuiwilliam

Other Decks in Technology

Transcript

  1. I N T E R N A L S T

    U D Y S E S S I O N Why Open Dataspaces 設計思想とアーキテクチャパラダイム Leveraging distributed data management for inter-organization and global interoperability April 2026 KEY WORDS: dataspaces, data mesh, ontology, semantic layer, usage control, Agentic AI, DDD
  2. A B O U T 本書の目的と位置づけ Open Data Spaces (ODS)

    とは 国や組織ごとの多様性を尊重する、オープンでスケーラブルな 分散データマネジメントの技術コンセプトの名称。 IPA デジタルアーキテクチャ・デザインセンター (DADC) が技術的な設計統括を行う。 Open Dataspaces(一般技術名称) データスペース原著論文 (2005) とデータメッシュ (2019) を源流とす る、新世代の分散データマネジメント技術の総称 ODS(固有名称) 上記パラダイムを具体化するIPA主導の技術コンセプト。International Data Spaces / Eclipse Data Spaces とは出自・設計指針が異なる 出典: IPA『Why Open Dataspaces』pp.4, 9 (CC BY 4.0) Why Open Dataspaces|社内勉強会 2 / 32
  3. A G E N D A 本日のアジェンダ 1 イントロ データ枯渇とダークデータ

    AI時代のデータ戦略 2 パラダイム変遷 集約→分散 Push&Ingest → Serving&Pull 3 データメッシュ 組織内・部門間 4原則とその限界 4 Classical Dataspaces 組織間・国境間 2005年原著論文の思想 5 Open Dataspaces 設計指針と3つの柱 DAD / OSI / IUC 6 DPQM AQの最小単位 Data & Ontology Product 7 3つの柱(詳細) OSI / DAD / IUC 半分以上のボリューム 8 サービスモデル 実装パターン 分散 / 連邦 / HSM Why Open Dataspaces|社内勉強会 3 / 32
  4. 1 . イ ン ト ロ ダク シ ョ ン

    2026年「データ枯渇元年」 Agentic AI時代、学習データの供給制約が顕在化 2026 データ枯渇元年 特に高品質データは 2026〜2032 年に枯渇する可能性 AIの性能を決める3変数(Scaling Laws) モデル規模 パラメータ数 計算能力 半導体・電力・通信の激戦区 学習データ量 供給制約が社会的に未認識 ⚠ 出典: Epoch AI (2024) “Will We Run Out of Data?” Why Open Dataspaces|社内勉強会 4 / 32
  5. 1 . イ ン ト ロ ダク シ ョ ン

    リアルデータ vs 合成データ データ枯渇への補完供給源は2つ。両者は優劣ではなく相互補完 リアルデータ Real Data ✓ 特徴 実世界の観測・取引データ (業務データ/設計図/IoTセンシング 等) ⚠ 課題 プライバシー・営業秘密により 取得と共有の障壁が高い 合成データ Synthetic Data ✓ 特徴 モデル・統計手法による人工生成。 供給総量を拡大しやすい ⚠ 課題 再帰利用で多様性喪失 = モデル崩壊リスク → リアルデータの供給は必須 最適戦略: リアルデータを保持しつつ両者を組み合わせ、再帰汚染を最小化するデータ戦略の設計 Why Open Dataspaces|社内勉強会 5 / 32
  6. 1 . イ ン ト ロ ダク シ ョ ン

    リアルデータにおけるダークデータの比率 世界の年間リアルデータ総量 (2025) 175 ZB / 年 消費者由来: 71 ZB エンタープライズ由来: 104 ZB 複製除去後の有効量: 17.5 ZB うち ダークデータ: 約 16 ZB 出典: NEDO (2025) ダークデータとは インターネット非公開のまま企業内に留まっているリアルデータ。潜在的な 学習・推論資源としての価値を持つが、そのままでは利用に供せないケース が多い。 利用を阻む2つの構造的要因 01 偏りと品質汚染 そのまま使うと学習・推論の精度を下げる要素を含むことが多い 02 文脈フィルタリング必須 ビジネス上の目的・文脈に即したキュレーションが利用の前提 Why Open Dataspaces|社内勉強会 6 / 32
  7. 1 . イ ン ト ロ ダク シ ョ ン

    GIGO とドメインコンテクスト 量ではなく「品質」が最大の障壁。品質は組織の自律的責任単位 = ドメインに依存する Garbage-In, Garbage-Out (GIGO): 利用目的と整合性のないデータを大量に取り込めば、むしろ利用結果の精度や汎用性を損なう。 さらに価値を生まないランニングコストが財務を圧迫する。 Agentic AI時代の検討論点 論 点 1 コンテクスト付与 ダークデータにどのようにドメインコンテク ストを与えるか 論 点 2 経営資本化 コンテクストを付与したデータを、将来 キャッシュフローを生む経営資本として機能 させるか 論 点 3 分散管理 企業・国境を横断して分散するデータとコン テクストを、どのようにマネジメントすべき か 結論: コンテクストこそドメイン固有の財産。データを「プロダクト」として提供・制御することが企業価値を定義する時代 Why Open Dataspaces|社内勉強会 7 / 32
  8. 2 . パ ラ ダイム 変 遷 集約から分散へ: データマネジメントの変遷 ビッグデータ

    3Vs を乗り越え、現在は Complexity の時代 Hadoop/HDFS、Amazon S3 など大規模ストレージ NoSQL (MongoDB, Cassandra)、JSON、ETL Kafka、Flink、Spark などスト リーム処理 散逸・分断・異質なまま存在す るダークデータへの対応 Complexityは技術的のみならず、産業・ビジネス・社会的・組織的・法制度的な多面的側面を持つ Why Open Dataspaces|社内勉強会 8 / 32
  9. 2 . パ ラ ダイム 変 遷 データマネジメントシステム世代変遷 Complexity に抗う

    4 世代。だが全てが「集約 (Push and Ingest)」パラダイムの延長 第 0 世 代 DBMS 古典的関係型。スキーマ固 定・SQL 対象: BI中心 第 1 世 代 Data Warehouse 構造化データの集約と分析最 適化 対象: BI/DI 第 2 世 代 Data Lake 半・非構造データを低コスト で蓄積 対象: BI/DI/ML 第 3 世 代 Data Lakehouse DWHとDLの統合。AI/ML親 和性が拡大 対象: AI-native Time to Value (TtV) は改善したが、Aggregation中心のパラダイムから脱却できていない Why Open Dataspaces|社内勉強会 9 / 32
  10. 2 . パ ラ ダイム 変 遷 Push and Ingest

    パラダイムの限界 シンプル組織では機能するが、ドメインが多様な組織ではスケーラビリティの壁に衝突 Push and Ingest (従来) すべてを一箇所に集約・保存・処理 ✕ 中央集権型データ基盤の最適化を徹底 ✕ Biz / Dev / Ops ✕ の分業が前提 加工過程でコンテクストが失われる ✕ 利用者は意味・制約・条件をコードから推測 ✕ Serving and Pull (データメッシュ) ✓ データは生み出したドメインが保持 ✓ ドメインオーナーがプロダクトとして提供 ✓ Biz / Dev / Ops の融合が最適解 ✓ コンテクストはドメイン単位で保持される ✓ 分散 × 社会技術的アプローチ Zhamak Dehghani (2019, 2022) によるパラダイムシフトの提唱 Why Open Dataspaces|社内勉強会 10 / 32
  11. 3 . デ ー タ メ ッ シ ュ データメッシュの

    4 原則 01 Domain Ownership ドメインオーナー自身がデータを所有・責任を持 つ 02 Data as a Product オペレーションの副産物ではなく、明示的に設 計・提供される商品として扱う 03 Self-Serve Data Platform ドメインが自律的に運用できるセルフサービス型 のプラットフォーム 04 Federated Computational Governance 連邦型の計算可能なガバナンスによる横断的な秩 序 従来の中央集権型アーキテクチャに対する重要な転換点 Why Open Dataspaces|社内勉強会 11 / 32
  12. 3 . デ ー タ メ ッ シ ュ データメッシュの限界:

    Governance Complexity 組織内の部門間連携を暗黙の前提とするため、組織境界を越えると課題が顕在化 W h e r e t o g e t 所在と同一性の問題 例: OEM契約先の製造実績はどこで取得可能か? 「6AX-10K Industrial Robot」と「Robot 10kg Standard Model」は同一機体か? W h a t t o m e a n 意味の問題 例: 広報チームの Alice は本当に広報部門所属か? 「高度」は標高なのか対地高度なのか? W h o a n d H o w t o u s e 利用条件の問題 例: アクセス者 (Agentic AI) はどの会社の運用か? このストリーミングデータは単位時間あたりいく らか? BI以外の二次利用は? スケーリングに伴う Governance Complexity の問題 — 組織・国境を横断するとガバナンスコストは爆発する Why Open Dataspaces|社内勉強会 12 / 32
  13. 4 . C l a s s i c a

    l D a t a s p a c e s 米国での「データスペース」誕生の背景 2005年、UC Berkeley の Franklin ら DBMS を補完する「新たな抽象化」として提唱 原 著 論 文 Franklin, Halevy, Maier (2005) “From databases to dataspaces: a new abstraction for information management” 扱う対象 = HCoD Heterogeneous Collection of the Data 組織に分断された異質なデータコレクション データスペースの特徴 参加者 (participant) と関係 (relationships) で定義される 参加者は RDB / XML / 文書DB / ウェブサービス 等のデータソース 構造化・半構造・非構造データいずれも参加可能 2以上の参加者のいかなる関係性もモデリング可能 ネスト構造・重複構造でも存在しうる アクセスルールは異なる性質のスペース間で共有 中央集権的 Push and Ingest と明確に異なるアプローチ。個々のソースの上に「空間 (spaces)」を定立 Why Open Dataspaces|社内勉強会 13 / 32
  14. 4 . C l a s s i c a

    l D a t a s p a c e s Open Dataspaces の理論的な源流 2つの源流を継承し、組織・国境横断の Governance Complexity に応える Classical Dataspaces (2005, 米国) HCoD に対する抽象化概念。DBMS の補完として「空間」を定立 Data Mesh (2019, Dehghani) Serving and Pull のパラダイム。DDDベース・4原則による分散 Open Dataspaces 部門間 → 組織間 → 国境間のデータマネジメント DFFT (Data Free Flow with Trust, 2019 G20大阪) の理念を技術的に具体化 Inter-Department → Inter-Organization 継承: Serving and Pull 型 + Domain-Driven Design + 4原則 Why Open Dataspaces|社内勉強会 14 / 32
  15. 5 . O p e n D a t a

    s p a c e s 3 つの柱 — 秩序と緩やかな規律 組織横断 × Agentic AIを前提に、3つの柱で透過的な SSOT と価値還元メカニズムを実現 W h e r e t o g e t DAD Data Addressability & Discoverability データの「存在」と「同一性」を保証し、関係性 を提供する緩やかな検索機構 W h a t t o m e a n OSI Ontology and Semantic Interoperability データモデルから情報モデルを分離し、推測では なく知識でデータを扱う W h o & H o w t o u s e IUC Identity and Usage Control Trust by Design の思想で、認証・認可・利用条 件を柔軟に設計 プロトコルは疎結合・後方互換を設計段階でビルトイン。Minimal Yet Viable な段階導入を重視 Why Open Dataspaces|社内勉強会 15 / 32
  16. 5 . O p e n D a t a

    s p a c e s 設計指針 — 3 つの根幹原則 01 ベンダーロックインの回避 マルチクラウド・クラウドレス動作を前提とし、特定企業のサービス・商品に依存しないベンダーフリー設計 02 制度的ロックインの回避 特定法域の制度的・規制的要件を技術仕様から明示的に分離。グローバル適応可能な設計とローカライゼーション 03 プロダクトライクでサービス志向の設計 解くべき課題はマーケットにある。Make Money, Save Money に資するか。PMF を目指したアジャイル検証 注: ここでいう「Open」はデータをインターネット公開することではなく、3つのロックインからの開放を意味する Why Open Dataspaces|社内勉強会 16 / 32
  17. 6 . D P Q M アーキテクチャ最小単位 — Double-Product Quanta

    Model データメッシュの AQ (Data Product) に Ontology Product を加え、表裏一体の構成単位とする データメッシュ Single-Product AQ Data Product 意味と構造が同一スキーマに混在 → 意味の変更 = スキーマ破壊 An Open Dataspace = 2以上の AQ からなる Architectural Quantum (AQM) Why Open Dataspaces|社内勉強会 17 / 32
  18. 6 . D P Q M OWA と CWA の二層構造

    — 選択的な厳格性 DPQMの強さ=均質な完全性強制ではなく、システム全体の開放性を維持しつつ選択的に厳格化 OWA Open World Assumption(開世界仮説) 「真と判断できないことは、偽ではないとみなす」 適用: Ontology Product • ドメインオーナーの自己宣言を積極的に包摂 • 発展途上の不完全な記述も排除しない • 結果整合性 (Eventual Consistency) • 静的検索に親和性 (例: 航空の航路情報) CWA Closed World Assumption(閉世界仮説) 「真と判断できないことは、偽であるとみなす」 適用: Data Product(選択的) • 信頼性・完全性・一貫性の明示的保証が必要な領域 • 強い一貫性 (Strong Consistency) • 動的変動データの同期が必要 (例: 運航管理) • Data Trust の検証可能インターフェース 集合論の束縛からの解放 — 現実世界を有限集合として事前定義することは不可能 Why Open Dataspaces|社内勉強会 18 / 32
  19. 6 . D P Q M 基本用語と機能レイヤー AQ と AQM

    の関係 製造企業 (生産) Data + Ontology Product 卸売業 (物品) Data + Ontology Product Wholesale Distribution Dataspace (AQM) 多元的・重層的な集合関係を含む総体 = Open Dataspaces AQ の機能レイヤー (4層) L4 Semantic / Ontology Layer 意味・制約・推論 L3 Identity Layer 実在性・認証・認可 L2 Transaction Management マルチモーダル抽象化・通信 L1 API Gateway Layer 疎結合なエントリポイント Identity/認証・認可は L3 に集約 — 信頼は横断的パースペクティブとして分離 前提 (Assumption): ①自己宣言的提供 ②不完全性で排除しない ③利用者は明示的保証を求める Why Open Dataspaces|社内勉強会 19 / 32
  20. 柱 1 : O S I データモデルから情報モデルを分離する 最も原始的でスケーラビリティの枷となる問題 = 意味

    (semantics) データモデル Data Product Role: Reflecting Reality 観測された事実としての要素を格納。 DBMSのスキーマ・テーブル相当。 効率的な保存・取得・更新が重視される。 一度記録された事実は原則として過去に遡って変更されない。 情報モデル Ontology Product Role: Knowledge Unit 事実をどのように解釈・関連付け・制約・操作するかの意味を表現。 分類・同一性・前提条件・禁止事項といった意味論的な構造を担う。 運用の変化に応じて更新され、時間を遡って再解釈されうる。 意味の進化を、データ構造の破壊ではなく「再解釈」として扱うための DPQM の強み Why Open Dataspaces|社内勉強会 20 / 32
  21. 柱 1 : O S I 実装レイヤー — RDF /

    RDFS / OWL Semantic Web 技術スタックにより、知識単位として分散的に拡張可能な構造を提供 AQ Data Product Ontology Product レベル Data Model Information Model(狭義) Semantics Ontology 表現 Multi-Modal Raw Data RDF / RDF* RDF Schema OWL 目的 Reflecting Reality Knowledge Unit Vocabulary & Structure Validation & Reasoning RDF / RDF* — Subject–Predicate–Object のグラフモデル。意味未確定でも関係を保持して分散拡張 RDFS — 語彙 (vocabulary) と構造 (structure) を与える基礎層 OWL — 妥当性・排他性等の制約を定義。推論器により意味推論と意味的矛盾検出を実現 『A Little Semantics Goes a Long Way』 Why Open Dataspaces|社内勉強会 21 / 32
  22. 柱 1 : O S I Semantic Gap と Dynamic

    Ontology 推測 (Guess) から知識 (Knowledge) へ — LLM × Ontology の相補性 例 : 航 空 の 「 高 度 」 MSL (Mean Sea Level / 平均海面基準の標高) vs AGL (Above Ground Level / 対地高度) 同一概念として誤統合 → 負債の蓄積 → 運航管理インシデント Semantic Gap 特定ドメインの自己定義から生じる意味的差異。Ontologyが明示制約 (例: 高度は必ず一つの基準に属する / MSL≠AGL) → 論理的不整合と してエラー返却 Ontological Gap Ontology同士のギャップ。Vocabulary/単位変換/同一性判断。労働集 約的なクロスウォーク → LLM補完でスケール化 Dynamic Ontology: LLMが対応関係の仮説を提示し、Ontology構造で検証・制約。Human-in-the-loopで補助輪を段階的に外す Why Open Dataspaces|社内勉強会 22 / 32
  23. 柱 2 : D A D Addressability — 「存在」と「同一性」の保証 Addressability

    を欠いたデータは「存在しないのと同義」 2つの独立エンドポイント Ontology Endpoint 意味・構造へのエントリポイント。IRI でグローバル一意 Data Endpoint 実データソースへのエントリポイント Webの名前解決概念に依拠した、AQがOpen Dataspacesに現れるための唯一の 存在証明の接点 同一性の保証 — IRI International Resource Identifier Manufacturer: “6AX-10K Industrial Robot” Wholesale: “Robot 10kg Standard Model” Logistics: “Pallet#12345 / SKU-ROB-10KG-JP” ↓ IRI で結ぶ グローバルでユニークな識別子 — ドメイン固有の内部識別子は温存 後付けで「同一の実体について話している」と合意できる手段を提供 Why Open Dataspaces|社内勉強会 23 / 32
  24. 柱 2 : D A D Discoverability — 2 段階クエリ

    完全な答えを返す検索機構ではなく、関係性を提供する緩やかな検索機構 S T E P 1 Ontology Query 任意のキーワードに対して Best Effort Result (= データカタログ) を提示 ✓ 意味のグラフを返す ✓ 完全性は保証しない ✓ OWA に親和 S T E P 2 Data Query Best Effort Result のグラフをベースに、紐づく Data Endpoint へアクセス ✓ 完全性が要求される領域 ✓ 選択的 CWA / Data Trust ✓ SLOに基づく品質アセスメント 動的ビューワーとしてのデータカタログ: CKAN型の静的リポジトリではなく、クエリ依存で都度 Best Effort Result として生成される Why Open Dataspaces|社内勉強会 24 / 32
  25. 柱 2 : D A D 分散カタログと Discovery Service 都度の全対全クエリは非効率。Web検索エンジンをモデルにしたインデキシング

    / クローリング Distributed Catalog 分散カタログ • ディスカバリ結果のローカルキャッシュ • インデックス / 横断クローリング • 計算量とランニングコスト最適化 • 各ドメインが自律的に参照可能 Discovery Service ディスカバリーサービス • 分散カタログや最初の Ontology Endpoint を 発見するための仲介機能の総称 • 利用者が Open Dataspaces をより効率的に 探索可能にする • Ontology Product 自体にも IUC が適用 (企業秘密に該当する場合もあるため) 補論: Data Trust = 完全性についての保証とリネージュの検証可能インターフェース (ODS Data Trust Assessment Protocol) Why Open Dataspaces|社内勉強会 25 / 32
  26. 柱 3 : I U C Trust by Design —

    アイデンティティの分解 「認証された主体」と「信頼してよい主体」を同一視しない — 信頼は設計対象 1 実在性の検証 Identity Proofing Q: 現実世界のどの個人・組織に対応するか? どの法人に雇用・運用され、どの契約に紐づく立場 で、それはいつまで有効か 2 認証 Authentication Q: 主体は主張するアイデンティティの所有者 か? アカウント、証明書、API Key など 3 認可 Authorization Q: この資源に対して、今、この操作をしてよい か? 設備A稼働ログは閲覧可、設備B制御APIは不可 など 組織の流動性により成立しない3つの暗黙前提: ① 組織境界の固定 ② 主体の同一性の自明 ③ 認証できた主体 = 信頼してよい主体 Why Open Dataspaces|社内勉強会 26 / 32
  27. 柱 3 : I U C アクセス制御 — Graph-to-Graph Control

    ゼロトラスト前提。PEP/PDP モデルで ReBAC + Ontology グラフを組み合わせる ゼロトラスト: PEP / PDP モデル PEP Policy Enforcement Endpoint APIゲートウェイ / クエリサーバーに配置。リクエストが通過する地点 PDP Policy Decision Endpoint ドメインごとに配置。アクセス可否を一元判断。監査・説明責任を集約 Graph-to-Graph Control ReBAC (Relationship-Based Access Control) + Ontology の 2つのグラフを連携 Ontology = 意味的な境界を定義 (どこまでが同一の資源・同一のコンテクストか) アクセスポリシーグラフ = 主体-資源の関係 (所属・契約・委任・属性) から許可を導出 PDP は確率的推測ではなく、関係の評価 / 導出 (infer) を行う Alice が人間/クローラー/Agentic AI であっても、同じグラフで推論可能 注: RBAC / ABAC 等、他のポリシー言語採用を否定するものではない。AuthZEN の標準化動向も進行中 Why Open Dataspaces|社内勉強会 27 / 32
  28. 柱 3 : I U C 利用制御 — 非対称性の補正 アクセス制御を拡張した権利・義務的概念。Classical

    Dataspaces には存在しなかった後付け概念 Usage Control = “the specification and enforcement of restrictions regulating what must(not) happen to data” (Steinbuss et al. 2021) ① 権利義務関係の非対称性 一度アクセス許可した相手に対し、用途・条件を制御する術が なければ、資源を無配慮に提供し続けることになる ② 価格決定権の非対称性 補正なき市場原理では、価格決定権は実質的にデータ利用者が 握ることになり、市場の失敗を招く可能性 利用制御の技術的手段の多様性 — 単一プロトコルで硬直化させない Contract Negotiation データ契約による交換・交渉 ブロックチェーン秘密計算 BI/DI領域 (例: カーボンフットプリント) Data Clean Room AI領域での差分プライバシー学習 Machine Unlearning 先端研究中の忘却技術 市場からの要件由来ではなく、制度要件由来の技術的手段を強制することは、適合コストを強いることになる Why Open Dataspaces|社内勉強会 28 / 32
  29. 柱 3 : I U C 補論: 電子契約 / 精算・課金

    (オプショナル) ODS Protocols の一部として、サードパーティ接続を想定したインターフェースのみ提供 O P T I O N A L Heuristic Contracting Protocol 電子契約行為 (e-Contracting) 締結結果を PDP に反映するところまでが所掌範囲。独自の契約交渉手順は含 まず、既存の電子契約サービスと接続。 機械完結にこだわらず、法務部などの Human-in-the-loop コールバックも許 容。 O P T I O N A L Clearing and Payment Protocol 精算・課金 / 決済行為 Data Product 利用に際したエンドポイントを提供。契約行為と同様、第三者 サービスとの接続が前提。 データマーケットプレイスといった高度なサービスの基盤となる。 Common Functionality: トランザクションの横断的なログ・モニタリングとしてイベント検知・アラート・通知を実現 Why Open Dataspaces|社内勉強会 29 / 32
  30. 8 . サ ー ビ スモ デル 実装パターン — 分散型

    / 連邦型 / HSM D i s t r i b u t e d 分散型サービスモデル ドメインオーナー自身が Self-Serve Data Platform を構築し、DPQM に基づいて Data Product / Ontology Product を提供 デジタル財源のある大企業向け F e d e r a t e d 連邦型サービスモデル ソフトウェアスタックを DSSP (Dataspace Service Provider) が代理提供。ドメイン オーナーはProduct提供に責任を持つ 中小企業やリソース制約下でも導入可能 H S M Hybrid Service Model 分散型 × 連邦型の混成。ドメインオーナー自 身と DSSP 仲介の両経路でオンボード 実例: 車載蓄電池CFP (OEM+Tier1+Tier2) DSSP (Dataspace Service Provider) = Classical Dataspaces 由来。仲介者 (Intermediaries) として Open Dataspaces の裾野を拡大する重要プレイヤー Why Open Dataspaces|社内勉強会 30 / 32
  31. S U M M A RY まとめ — Open Dataspaces

    の本質 Open Dataspaces は、国や組織ごとの多様性を尊重する、オープンでスケーラブルな分散データマネジメント技術 『データに飲み込まれる世界』における、企業の最も本質的な生存戦略 1 3つの柱 DAD / OSI / IUC — 秩序と緩やかな 規律 2 DPQM Data × Ontology Product の表裏一 体設計 3 OWA基調 選択的な厳格性で CWA を内包 4 段階導入 Minimal Yet Viable + 疎結合プロトコ ル 5 3ロックイン回避 ベンダー / 制度 / 硬直的設計 6 Agentic AI対応 推測から知識へ, Dynamic Ontology コンテクストこそドメイン固有の財産 — データを「プロダクト」として提供・制御することが企業価値を定義する Why Open Dataspaces|社内勉強会 31 / 32
  32. R E F E R E N C E S

    参考文献・さらなる学習リソース 主要参考文献 • Franklin, Halevy, Maier (2005) “From databases to dataspaces” • Halevy, Franklin, Maier (2006) “Principles of Dataspace Systems” • Dehghani Z. (2019) “How to Move Beyond a Monolithic Data Lake…” • Dehghani Z. (2022) Data Mesh (O’Reilly) • Otto B. et al. (2016) Industrial Data Space Whitepaper (Fraunhofer) • Steinbuss S. et al. (2021) Usage Control in IDS • Epoch AI (2024) “Will We Run Out of Data?” • NEDO (2025) Data Spaces Market Size Study • METI / IPA (2025) Ouranos Ecosystem Dataspaces RAM Whitepaper 次に読むべきドキュメント ODS-RAM Reference Architecture Model — 具体的な設計物 ODS Protocols 各プロトコル技術仕様 (Trust / Usage / Contracting 等) ODS Middleware 参照実装 OSS ソースコード Contact: IPA デジタルアーキテクチャ・デザインセンター [email protected] “伽藍とバザールの理念を胸に、全世界のOSSコミュニティの力を信じて前進させる” — 津田通隆 Why Open Dataspaces|社内勉強会 32 / 32