Open Data Spaces: Agentic AI時代の分散データマネジメント

2026/08/26 開催
OpenID Summit Tokyo 2026 Special Edition 発表資料

Open Data Spaces
Agentic AI時代の分散データマネジメント

独立行政法人情報処理推進機構 デジタルアーキテクチャ・デザインセンター 情報分析官
Open Data Spaces Chief Architect（最高設計責任者）
津田 通隆

Transcript

1. OpenID Summit Tokyo 2026 Special Edition Agentic AI時代の分散データマネジメント 独立行政法人情報処理推進機構 デジタルアーキテクチャ・デザインセンター Open Data Spaces Chief Architect 津田通隆 本資料の無断転載及び複製、AI学習等を禁じます. お問い合わせ: dadc-info@ipa.go.jp
2. Open Data Spacesとは何か？ Agentic AI時代に必要な、ドメイン・産業を横断するコンテキストレ イヤーの技術パラダイムを提供することが目的 概要 設計指針 RegulationAgnostic Vendor-Agnostic 国や組織ごとの多様性を尊重 する、オープンでスケーラブ ルな分散データマネジメント の技術コンセプト Product-like & Service-Oriented 公開済のアーティファクト 設計思想とアーキテ クチャパラダイム ODS リファレンス アーキテクチャ モデル (ODS-RAM) Ready for Ready for Ready for Ready for New Paradigm Onboarding Interoperability Go-To-Market ODS Protocols (OSP) ODS Middleware and SDKs (OSS)
3. OpenDataSpacesは、高市政権 日本成長戦略（戦略17分野データプ ラットフォーム）や人工知能基本計画等に明示的に記載 日本成長戦略 人工知能基本計画
4. なぜ、Agentic AIの社内導入は成果が出ないのか？ 問題はモデルではなく、現場の文脈と信頼不足。 AIパイロットの状況 原因 グローバルで300億〜400億ドル投資しているが… 95% 1 の企業向けAIパイロットは、測定可能な損 益（P&L）へのインパクトを生んでいない。 1: MIT (2025) GenAI Divide • ボトルネックはモデルではない。 • AIエージェントが、各ドメイン固有の適 切なビジネスコンテキストを見つけられ ず、理解できず、さらにそれに基づいて 信頼して行動させることもできないから。
5. AIモデルがコモディティ化する中で、 現場特有の文脈（Domain Context）への需要シフトが起きつつある Data for Foundation Model 事前学習の データマネジメント 大量の学習データが必要 Data for Agents 事後学習の データマネジメント ドメイン固有のコンテキストが必要
6. 年間のデータ量は2025年時点で175ZBに到達し、全体の60%をエン タープライズデータが占めている 年間のデータ量（世界中で創出・取得・複製・消費される年間のデータ量、エンタープライズデータも含む） 2010-25年(予測値ベース); ゼタバイト(ZB) 175 消費者データ エンタープライズデータ 凡例 138 +27% 71 (40%) 109 86 57 46 67 37 53 42 5 6 8 2010 11 12 10 13 13 7 6 14 16 20 8 8 10 10 15 16 26 13 30 24 33 81 20 16 17 22 29 13 17 18 19 20 37 21 48 22 出典：国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）「ウラノス・エコシステムの実現のためのデータ連携システム構築・実証事業」調査資料※をもとに発表者作成 ※The Digitization of the World From Edge to Core – IDC 104 (60%) 62 23 24 25
7. AIが学習対象とし得る17.5ZBのユニークデータのうち約92%(16ZB)の データが現時点で活用できていないと推定 グローバルデータスフィア全体のデータ量 2025年(予測値ベース); ゼタバイト(ZB) ユニークデータ 公開データ 消費者 データ 40% エンター プライズ データ 60% 10% 非構造 非構造 構造/非構造 半構造 エンタメ画像 ／動画データ 非エンタメ画 像／動画デー タ プロダクティ ビティデータ 組み込み データ 27% 26% 27% 20% 複製データ 非構造 非構造 構造/非構造 半構造 エンタメ画像 ／動画データ 非エンタメ画 像／動画デー タ プロダクティ ビティデータ 組み込みデー タ 枯渇するデータ 0.51 ZB 0.08 ZB 0.08 ZB 0.08 ZB 4.53 ZB 0.65 ZB 0.65 ZB 0.65 ZB 10% 制限付き・ 非公開データ 複製データのため、 本質的な価値はない 90% 公開データ 枯渇するデータ 0.04 ZB 0.36 ZB 0.38 ZB 0.27 ZB 0.36 ZB 3.22 ZB 3.37 ZB 2.37 ZB 10% 制限付き・ 非公開データ 90% 90% 出典：国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）「ウラノス・エコシステムの実現のためのデータ連携システム構築・実証事業」調査資料※をもとに発表者作成。 ※The Digitization of the World From Edge to Core – IDCをもとに推計。
8. 本編導入: データとAIの市場を理解するための問い Is SaaS Dead? SaaSは本質的には何を売っていて、それは、どのようにAIに影響されるのか？
9. 仮説：「SLAを売る」というマネージドサービスの本質は不変の価値。 変わったのは、「何のSLAを、誰に、どこで、どう売るか」 Agentic AI時代以前 Agentic AI時代以後 何のSLAを “機能”が24/7 365動くこと ビジネスの“成果” （アクションを伴うアウトカム） 誰に 対 人間 対 エージェント どこで GUIの操作画面 コールされるAPI どのように シート課金（人間の頭数）に重心 従量課金（トランザクション数） に重心
10. Agentic AI時代以前 : 「融通の利かないアルゴリズム」が駆動する人 間依存のアプリケーションの世界 SaaS＝（人間が利用することを前提に） 正常に機能することSLAとして売る 人間 （環境を観測 して入力） GUI SoR ビジネス環境 ビジネスロ ジック 人間 （環境にアク ション）
11. Agentic AI時代以後: 「融通の利くアルゴリズム」が駆動するエー ジェンティック（代理人的）なアプリケーションの世界 SaaS＝（AgentにCallされることを念頭に） ビジネスの成果をSLAとして売る 人間（介入または監視） HITL/HOTL エージェント （環境を観測 して推論・入 力） ビジネスロジック SoR ビジネス環境 エージェント （環境にアク ション）
12. Agentic AI時代の本格到来でビジネスロジックとSoRの役割が変化 B: 役割の変化 A: 概要 C: 新技術トレンドの喚起 人間中心 エージェント中心 ビジネス ロジック 業務ドメイン特有の オペレーション、意 味解釈、アクション のルールを定める オペレーションの固 定化（FTS）を前提 に、環境に干渉しな い静的なアルゴリズ ムとして表現 オペレーションの変 化を前提に、環境に 干渉する動的なアル ゴリズムとして表現 例: セマンティックレイ ヤー、オントロジー SoR ビジネス環境のス テート（状態）を管 理する 全社で「集約」して アルゴリズムに一様 な形式で「入力」す る ドメインごとに「提 供」してアルゴリズ ムが「参照」する 例: データメッシュ （データプロダクト）
13. 「コンテキストレイヤー」の必要性は、エージェント時代で変化した ドメイン固有のビジネスロジックとSoRの統合需要から生まれている コンテキストレイヤーの4要件（仮） １ ステート （状態） 2 対応関係 推論対象としてのビジネス環境の ステート（＝データ） 人間（介入または監視） 4 HITL/HOTL 意味と業務 知識 ステートの意味解釈のための符号 表と論理的な制約 行為 ドメインオペレーションに基づく アクションとその条件 意思決定と ガバナンス アクションに対する意思決定と エージェントのガバナンス 3 エージェント （環境を観測し て推論・入力） 2 ビジネスロジック １ SoR 4 ビジネス環境 3 エージェント （環境にアク ション）
14. Big Data is Dead: 21世紀以降のデータマネジメントにおける技術テーマの変遷 例 2004~06 ~2009 ~2012 ~NOW Volume Variety Velocity Complexity 大量のデータ 多様性のあるデータ 非同期で流れるデータ データに関連する複雑性 ・・・？
15. データメッシュは中央集権型のデータ基盤が持つ3つの失敗に対する方法論であ り、その最小単位が「データプロダクト」 中央集権型の3つの失敗モード 1 中央チームがボトルネックになる データメッシュの4つの原則 1 データは、それを一番よく知っている業務部門が持つ 全社の要求が1チームに集中し、待ち行列ができる 2 2 業務を知らない人がパイプラインを書く 3 セルフサーブ型のデータ基盤 各部門がゼロから作らずに済む共通の土台を中央が用意する 提供側に品質責任の動機がない 集めるほど、誰も中身に責任を持たない状態になる データをプロダクトとして扱う 社内利用者を顧客と見て、ポリシーと品質保証を付けて提供する 変換の過程で、データの意味が落ちていく 3 ドメイン・オーナーシップ 4 フェデレーテッドな計算ガバナンス ルールは全社で決め、実行は各ドメインで自動的に効かせる 集めれば集めるほど、 誰も中身に責任を持たないデータスワンプができる データプロダクト（Data Product）: 独立して配備でき、発見 でき、ポリシー付きで使えるデータの最小単位 ＝マイクロサービス/ドメイン駆動開発（DDD）のデータ版
16. 分散データマネジメントアーキテクチャData Meshによる「Serve and Pull」へのパラダイムシフト（2019年提唱） Centralized Architecture From Aggregation Decentralized Architecture To Distribution AI/ML Centralized Big Data Platforms T T BI (DWH, DL, DLH) T T DI etc. T T Data as a Product
17. データマネジメントシステムのアーキテクチャ世代変遷: 「Push and Ingest」パラダイムでの最適化 Data Warehouse 第一世代 Data Lake 第二世代 Data Lakehouse 第三世代 E T E E L T E AI/ML L BI L T L E L T E T DI L L E T E T L E T L AI/ML T BI BI DI DI etc. etc. etc. データ種類 構造化データ 構造化、半構造、非構造データ 構造化、半構造、非構造データ 利用用途 BI/DI AI （ETL→DWH経由でBI/DI） AI/BI/DI
18. 参考: Data Mesh Data Meshの4原則
19. しかし、2019年以降、データメッシュは一度頓挫。問題は組織だけではなく、 ドメインごとに形式と道具が割れてしまう技術基盤の不在にもあった。 顕在的な理由：組織の壁 • 全社のドメインマップを描こうとして 分析麻痺に陥る • 既存の部署に「今日からあなたがオーナーです」 と看板を付け替えるが、オーナーシップはない • ガバナンスを、組織間の交渉として 設計してしまう 潜在的な理由：技術の壁 各ドメインが自前でデータを持つと、2019年の技術で分散したの は責任ではなく、形式と道具のサイロだった。渡すたびにコピーが 増え、「どれが正か」が分からなくなる。 マーケティング 営業 Airflow + Parquet スクリプト + CSV 財務 分析チーム SQL Server ノートブック内で完結 ・・・ 18〜24ヶ月の文化的抵抗のあと、放置された カタログだけが残る 第3の原則「セルフサーブ・データ基盤」が、当時は技術 的に成立していなかった
20. オープンテーブルフォーマットとRESTカタログにより技術要素が揃い、データ を動かさずに提供する「データプロダクト」が現実的な手段になりつつある 対象 データレイクハウスの構成要素 技術課題 解決策 インフラ 列志向のファイルフォーマット データ構造の制約／ スケーラビリティと コスト コンピュートとストレー ジの分離 ストレージ形式の 占有 データインスタンスとク エリエンジンの分離 メタデータとクレ デンシャルの占有 データプレーンとコント ロールプレーンの分離 データの複製／意 味の乖離 データ提供と利用の分離 Apache Parquet (or Apahce Arvo) ＋ オブジェクトストレージ エンジン オープンテーブルフォーマット Apache Iceberg ／ Delta Lake (or Apache Hudi) +クエリエンジン（Apache Spark／Trino 等） テナント オープンRESTカタログ（＋Credential vending） Apache Polaris／Unity Catalog ドメイン データ／メタデータのオープン共有プロトコル （INCUBATING） OpenSharing／Apache Ossie データを動かさずに、複数のエンジンから、そして複数のドメインから同じテーブルを読める。複製コストと「どれが正か」の問題が消える。
21. Open Data SpacesはAgentic Industryの実現を目指す： Inter-Departmentから、Inter-Organizationへ Open Data Spaces To Inter-Organization Data Mesh From Inter-Department Data User Data User BizDevOps BizDevOps Distribution Department Sales Department Wholesale Company Logistics Company BizDevOps Production Department Manufacturer
22. 企業内部門横断を前提としたData Meshの課題： 企業・国境を横断を前提としたときの、ガバナンスとオープン標準 Where to Get: What to Mean: Who and How to Use: ⚫ そもそも、どこにデータがあるの か？（例: OEM契約をした会社の 製造部門の実績データはどこで取 得できるのか？） ⚫ そのデータは何を意味するか？ （例: 政府広報チームのAliceは、 広報部門に所属しているのか？） ⚫ データにアクセスしようとしてい るのは誰か？（例: このAI Agent （Client App）は、どの会社が運 用しているのか？その運用会社は、 存在していて、信用に足るか？） ⚫ そのデータは、このデータと同一 のものを指し示しているか？（例: Manufacturerの「6AX-10K Industrial Robot」のデータと、 Wholesaleが命名した「Robot 10kg Standard Model」のデータ は同じものか？） ⚫ そのデータの意味は、このデータ の意味と整合しているか？（例: このフィールドの「高度」は標高 を表すのか、それとも対地高を表 すのか？） ⚫ 誰がそのデータにアクセスできる のか？（例: 取引先の航空会社が 委託した会社の人事部門は、この データを閲覧できるか？） ⚫ そのデータはどう使わなければな らないか？（例: このストリーミ ングデータは、単位時間あたりど の程度の価格か？BI目的以外の二 次利用はできるのか？）
23. Open Dataspacesは、横断的な分散型データマネジメントに秩序と 規律を与えることを目的とする Where to Get: What to Mean: Who and How to Use: Data Addressability and Discoverability（DAD） Ontology and Semantic Interoperability（OSI） Identity and Usage Control （IUC） 分散型Data Managementにおける「ドメイン、企業横断の透過的なSSOT」と 「データ提供者が対価を得るメカニズム」を実現
24. 参考｜Open Dataspacesの理論的な源流 Open Dataspaces 2024-2026 Dehghani. 2019-2022 Franklin et al. Halevy et al. 2005-2006
25. クロスボーダーな分散データマネジメントの理論的な前提 前提（Assumptions） 解決策としてのアーキテクチャ 1. データ提供者は、データを自 己宣言的に提供する 2. データ提供者は、不完全又は 発展途上の記述を提供するが、 その不完全性をもって排除す べきではない 3. データ利用者は、信頼性や完 全性、一貫性に関する明示的 な保証を求める “Double Product Quanta Model” (the “DPQM”)
26. Open Dataspacesのアーキテクチャの構成単位 Double-Product Quanta Model（DPQM） アプリケーション （Agentic AI） ドメインオーナー 対応関係 Domain 3 行為 2 意味と業務 知識 Open World Assumption (OWA) -> Eventual Consistency Ontology Product ①SPARQL GET Semantic & Ontological Interoperability １ ステート Ontology Endpoint ②GET Close World Assumption (CWA) -> Strong Consistency Data Trust & Trustworthiness (Multi-Modal) Data Endpoint Data Product Apps
27. Semantic Interoperability: 「意味の変更」による構造の破壊 DB API ETL sql json python # GET /v1/machines/{id}/status CREATE TABLE machine_status ( … is_abnormal BOOLEAN NOT NULL ); # GET /v1/machines/{id}/status return { "machine_id": mid, "vib_mm_s": 7.1, "is_abnormal": True } # v1: On the premises that is_abnormal row exists in CSV/Parquet df = read_table("machine_status")[["ts"," machine_id","vib_mm_s","is_abnormal" ]] df.to_parquet("status.parquet") ALTER TABLE machine_status DROP COLUMN is_abnormal, ADD COLUMN abnormal JSONB NOT NULL; -{"vibration":true,"temperature":fals e,...} return { "machine_id": mid, "sensors": {"vibration": {"mm_s": 7.1}}, "abnormal": {"vibration": True} # <- is_abnormal is now the nest } # v2: is_abnormal disappears and now abnormal is JSON df = read_table("machine_status") # Existing ETL breaks, logic needed to iterate nests df["is_abnormal"] = df["abnormal"].apply(lambda x: x.get("vibration", False)) df[["ts","machine_id","vib_mm_s","is _abnormal"]].to_parquet("status.parq uet")
28. 情報モデル（意味）とデータモデル（状態の構造）の分離 Data Provider Data Provider (Data Product Server) (Ontology Product Server) turtle # Company A { "altitude_m": 120.0, "datum": "AGL" } @prefix ex: <http:example.org/> Decouple Information Model ex: AltitudeObservation a owl: Class. ex: AltitudeDatum a owl: Class. #Accept only one datum ex: datum a owl: Objectproperty, owl: FunctionalProperty . # Company B { "altitude": 120.0, "unit" : "meter", "datum" : "MSL" } ex:AGL a ex:AltitudeDatum . ex:MSL a ex:AltitudeDatum . #Differentiate AGL and MSL ex:AGL owl:differentFrom ex:MSL. ETL Data User record id altitude type 1 120.0 AGL 2 120.0 MSL “Bugs” in Application json "@context" :{…}, "@id:": "ex:XXX", "@type": "AltitudeObservation", … T Data User Inconsistent ontology ex:AGL is different from ex:MSL. Error in Ontology Information Model Data Model json
29. Dynamic Ontology: ドメイン駆動の自己定義（ビジネスロジック、 アクションと条件）を推論エンジンの性質で相互に接続検証する LLMとオントロジーの相補性と再帰性 Infer by Pattern ダイナミックオントロジー Domain A Recursive Feedback AI LLMs Constrain & Verify Ontology Domain B
30. Discoverability: ダイナミックオントロジーとIRIにより、インター ネットのような探索可能性を実現する From Non-Addressable To Discoverable Company A Domain 1 Domain 2 Domain 3 ・・・ Domain N Apps Company N Company B Company N Company B Company A Domain 1 Domain 2 Discovery Service keyword Apps Domain 3 ・・・ Domain N Discovery Service keyword
31. Identity and Usage Control: Ontology ProductとData Productの間に2つのレイヤー（Identity, Transction）を導入 AQ (DPQM) L1~L4 4 L4 Semantic Layer Ontology Product L2~L4 意思決定と ガバナンス L3 Identity Layer L2 Transaction Layer L1 Data Layer Data Product L1~L3
32. Access Control: ゼロトラストアーキテクチャの採用（PDPとPEPの分離） Domain Ontology Product Server Reference Implementation Examples in ODS Middleware Ontology Endpoint Query Server API Gateway PEP PEP Policy Engine PDP ODS-RAM L3 (Authentication) w/ ODS-RAM L3 (Authorization: PDP) w/ ODS-RAM L2 （PEP） Query Server API Gateway PEP PEP See details at Open Data Spaces Protocols (Gitbook) & Open Data Spaces Middleware (GitHub) (Multi-Modal) Data Endpoint Data Product Server
33. Usage Control: 選択的共有の契約行為と清算決済はあくまで補助的な ツールとして、3rd パーティーの接続I/Fを提供 Data Provider 3rd-party Apps Example ODS Heuristic Contracting Protocol Access denied eContract Apps Optional redirects Optional No Yes PEP Optional: e-Contracting? status: 200 3rd-party Apps ODS Clearing and Payment Protocol Data User PDP Data Provider Apps Data User Example Save as a log Payment Apps redirects No Yes TX Optional: Need to charge? Log charges Apps
34. アーティファクト Reference Architecture Model (Gitbook) Open Data Spaces Protocols (Gitbook) OSS Middleware (GitHub)
35. 公式ランディングページ （IPAより４月に成果物をオープンソースで公開）
36. データを資産に、 日本をソフト ウェアサービス で勝てる国に ―国際市場進出モデルの実現 写真：発表者撮影
37. THANK YOU! Unauthorized reproduction, redistribution, or use of this material for AI training is strictly prohibited. Contact: dadc-info@ipa.go.jp