Open Data Spaces（ODS）とは？分散データ管理の3本柱や成果物、EUとの違いを解説

Open Data Spaces（ODS）は、独立行政法人情報処理推進機構（IPA）が2026年4月1日に主要成果物を公開した、分散データマネジメントの技術コンセプトです。
米国発の dataspaces原著論文（Franklin/Halevy/Maierら 2005-2006）と Data Meshを統合し、OSI・DAD・IUCの3本柱と Double-Product Quanta Model（DPQM）を軸に、企業・組織・国境を横断したデータ流通を可能にする設計です。

欧州の International Data Spaces（IDSA）／Eclipse Data Spaces／Gaia-X等の取り組みとは出自が異なり、相互運用を目指す独立系譜として位置づけられます。

本記事では、ODSの定義と設計思想、3本柱と主要成果物、欧州系データスペースや Data Meshとの違い、ウラノス3事例、参入コスト構造、日本企業の導入判断までを、2026年7月時点の最新情報で体系的に解説します。

Open Data Spaces（ODS）とは？IPAが公開した分散データマネジメントの技術コンセプト

Open Data Spaces（ODS）とは、独立行政法人情報処理推進機構（IPA）が2026年4月1日に主要成果物を公開した、国や組織ごとの多様性を尊重するオープンでスケーラブルな分散データマネジメントの技術コンセプトです。

正式にはIPAデジタルアーキテクチャ・デザインセンター（DADC）が中立体として主導し、参照アーキテクチャ・プロトコル仕様・OSS実装・ガイドブックを一式で提供する「技術コンセプト＋実装群」という位置づけです。

ODSが解こうとしているのは、Epoch AI（2024）が「高品質なパブリックテキストデータの2026〜2032年枯渇可能性」を示す一方、企業内に推定16ZBのダークデータが眠ったまま活用されていないという非対称性です。

IPAはこの構造的ミスマッチを、米国発の dataspaces原著論文（Franklin/Halevy/Maier 2005-2006）と Data Meshの設計思想を統合することで解決しようとしています。

ODSの成り立ちと類似概念との切り分け

ODSは「日本発の分散データマネジメント」として登場していますが、IPA公式資料はODSが欧州系データスペースとは出自が異なる独立取り組みであることを明示しています。

• 米国系譜（Classical Dataspaces）：Franklin/Halevy/Maierら2005-2006の原論文で提唱された、異質なデータコレクションのマネジメント抽象化
  
  
• 欧州系譜（IDSA・Gaia-X・Eclipse Data Spaces）：Fraunhofer発の Industrial Data Space 以降、Connectorを中心にデータ主権を担保する分散共有
  
  
• ODS（IPA主導、2026-04公開）：米国 dataspaces原論文と Data Meshを統合、DPQMで意味と実データを同格化

ここでのポイントは、ODSはData Meshの日本版でも欧州データスペースの延長でもなく、米国の抽象化とData Meshのドメイン主導思想を組み合わせた独立取り組み、という点です。

各概念との詳細な比較は後段の「欧州データスペース・Data Meshとの違い」で扱い、本記事の以降はODSの内部構造・成果物・実装ケースに絞って解説します。

---

集約型から分散型へ — ODSが引いた設計の軸

ODSの技術コンセプトを理解するうえで最初に押さえるべきは、データの扱い方の「向き」が180度変わっている点です。

従来の集約型データ基盤が「まずデータを集める」ことを起点にしていたのに対し、ODSは事前の中央集約を避け、必要時にドメイン側から取得できる状態にすることを起点にしています。

IPAは「Why Open Dataspaces」設計思想ドキュメントで、このパラダイム転換を「Push and Ingestから Serving and Pullへ」と表現しています。

Push and Ingest型の限界

これまでの主流だったデータレイク・データウェアハウス方式では、各業務システムから中央基盤にデータを吸い上げる（Push and Ingest）ことが前提でした。しかし、このアプローチには構造的な限界があります。

• データ所有権が分散したままではガバナンスが破綻する
  組織横断・国境横断でデータを集めようとすると、GDPR等の法規制やベンダーロックインが同時多発的に発生する
  
  

• 意味情報が集約時に落ちる
  中央基盤で正規化されるほど、業務の文脈（この売上は何を意味するのか、この製品ロットはどの規格に準拠するのか）が薄まる
  
  

• スケール限界
  16ZBのダークデータをすべて中央に集める物理的コスト・時間が現実的でない

この限界に対して、Data Meshは「集めずに、ドメイン側でData Productとして提供する」という発想を持ち込みました。

ODSはこれをさらに一歩進めて、「Data Product」に加えて「Ontology Product」を並列に扱うDPQMを導入しています。

Double-Product Quanta Model（DPQM）が意味の分離を可能にする

DPQMは、ODSアーキテクチャの最小構成単位（quantum）を、Data ProductとOntology Productの2層で捉える設計です。

以下の表で、両者の役割を整理しました。

種別	世界仮説	扱う情報	特性
Ontology Product	Open World Assumption（開世界仮説）	概念・関係・制約などの意味情報	最終的整合性・スキーマ拡張可能
Data Product	Closed World Assumption（閉世界仮説）	具体的な事実データ・レコード	強整合性・スキーマ固定

この分離が何を可能にするかというと、意味情報を後から進化させても、実データを壊さずに済むという運用の柔軟性です。

DPQMではオントロジー側（Ontology Product）を独立に拡張・更新できるため、意味の変更を、データ構造の破壊ではなく再解釈として扱いやすくなります。業務ルールの変化にデータ基盤が引きずられない設計です。

DPQMの発想は、オントロジーやナレッジグラフを「企業の世界モデル」として位置づけるPalantirやMicrosoft Fabric IQの潮流とも重なります。

ただしODSは、意味と実データを「対等な二つのプロダクト」として扱う点で、単なるオントロジー中心設計とは異なります。

「集めない」ことを設計思想に据える意味

「Push and Ingestから Serving and Pullへ」の転換は、AIエージェントが企業内外のデータを跨いで動く時代に決定的な意味を持ちます。エージェントが「あるデータがどこにあり、どういう意味を持ち、誰の許可で使えるか」を実行時に解決できなければ、複数組織を横断した業務は自動化できません。

ODSは、この実行時の解決を可能にするために、次章で説明する3本柱（DAD／OSI／IUC）を設計しています。データを集めない代わりに、データ側にたどり着くための言語と契約を用意する、というのがODSの設計哲学の中核です。

---

ODSを支える3本柱 — OSI・DAD・IUC

ODSの技術的な骨格は、3つの柱で成り立っています。IPA「Why Open Dataspaces」の章立てに沿えば、柱1: OSI／柱2: DAD／柱3: IUCの順で、それぞれ意味の相互運用・存在と発見・信頼と権利関係を担う設計になっています。

以下の表で、3本柱の役割を整理しました。

略称	名称	役割
OSI	Ontology and Semantic Interoperability	データモデル（構造）と情報モデル（意味）を分離し、異なる組織のデータを意味的に繋げる
DAD	Data Addressability and Discoverability	ドメイン内部の識別子を維持したまま、Ontology Endpoint／Data Endpoint 経由で存在と発見を担保する
IUC	Identity and Usage Control	Identity／Authentication／Authorizationを分離し、権利関係の柔軟な選択肢を提供する

3つは疎結合な責務分担で、固定の処理順があるわけではありません。実装上は、OSIとDADが組み合わさって「意味的にヒットしたデータをどう解決するか」を扱い、IUCが「その利用が権利関係上許されるか」を判定する形になります。

OSI（Ontology and Semantic Interoperability）— 意味の相互運用

OSIは、データモデル（構造）と情報モデル（意味）を分離し、組織ごとに異なる意味体系をオントロジー製品として提供・接続するレイヤーです。

たとえば、A社の「顧客ID」とB社の「取引先コード」が実質的に同じ概念を指しているとき、それぞれのオントロジー側で対応関係を宣言することで、下層のデータ構造を変えずに意味的な接続が可能になります。

Dynamic Ontologyという言い方は、静的に運用されがちなオントロジーとは異なる運用特性を示唆しています。LLMがマッピング仮説を提示し、構造的な検証や Human-in-the-Loopを経て差分を縮めていく設計で、これが DPQMの「Ontology ProductはOWA（開世界仮説）」と対応します。

「Agentic AIが意味を自由に追加・再定義する」という強い自律性を持つわけではなく、あくまで人間の検証を挟みながら意味を進化させる設計です（OWLはあくまでオントロジー記述言語で、それ自体が固定的なわけではありません）。

DAD（Data Addressability and Discoverability）— 存在と発見の分離

DADは、「addressableでないデータは存在しないのと同じ」という考え方に基づき、ドメイン内部の識別子を維持したまま IRI（Internationalized Resource Identifier）で存在証明を行う設計です。

「すべてのデータに新しい識別子を付け直す」のではなく、既存のドメイン識別子はそのままにして、Ontology EndpointとData Endpointという独立したインターフェースを公開する構造になっています。

これにより、OSI 側で意味的にヒットした概念を Ontology Queryで解決し、対応する実データを Data Queryで参照する二段階のクエリが成立します（この2段階は DAD 内部での構造で、他の柱を跨ぐ処理順ではありません）。

IUC（Identity and Usage Control）— 信頼を設計対象にする

IUCは、Identity Proofing（身元確認）・Authentication（本人認証）・Authorization（認可）を明確に分離し、それぞれを異なる主体に委任できるインターフェースを提供します。

従来のアクセス制御は「認証されたユーザーは事前定義された権限を持つ」という前提でしたが、IUCは利用条件の合意そのものを契約レイヤーで扱える設計になっています。

たとえば「このデータは分析用途に限る」「加工結果を再配布しないこと」といった条件を、契約として明示的に扱うことが可能です。契約条件を技術的に自動強制するかは実装依存で、電子契約や紙運用など多様な実装手段を許容する設計になっています。

IPAはこれを「信頼を前提ではなく設計対象にする」と表現しています。データ提供者と利用者の権利義務の非対称性を、契約と技術の両輪で補正するのが IUCの役割です。

---

ODSの主要成果物 — ODS-RAM V2・ODP・Middleware

ODSが「技術コンセプト」に留まらず実装可能な設計として成立しているのは、2026年4月1日の成果物公開で参照アーキテクチャ・プロトコル仕様・参照実装・ガイドブックが一度に揃ったためです。公開場所は成果物の種類ごとに分かれています。

設計思想ドキュメント（Why Open Dataspaces）は IPA公式サイト、参照アーキテクチャ（ODS-RAM V2）・プロトコル（ODP v1）・ガイドブックは 公式GitBook（CC BY 4.0等）、Middleware・SDKはGitHub組織 open-dataspaces（各リポジトリ MIT License等）でそれぞれ公開されています。

いずれもオープンライセンスの成果物ですが、条件は成果物ごとに個別確認が必要です。

以下の表で、主要成果物と役割を整理しました。

成果物	種別	役割
Why Open Dataspaces	設計思想ドキュメント	ODSの背景・目的・パラダイム転換の説明
ODS-RAM V2	参照アーキテクチャ	4レイヤー・4パースペクティブでの構造モデル
ODP v1	プロトコル仕様	分散データ管理を成立させる技術契約群
Middleware	OSS実装	ODPを動くコードにした参照実装
SDK（Onboarding／Semantics）	開発キット	参加事業者が自ノードを立てるためのPython／Javaクライアント
事業者向け参入ガイドブック	ガイド	開発事業者向け・ユーザー事業者向けの判断書
技術者向け導入ガイドブック	ガイド	実装・運用の最小構成の考え方

この構成が示すのは、設計思想から動くコードまでを一気に降ろすことを意識している点です。

仕様書だけを出して実装は市場任せにする従来の技術白書型ではなく、Middlewareとしての参照実装まで揃えて「動く前提」で仕様が回るように設計されています。

ODS-RAM V2 — 4レイヤー・4パースペクティブのアーキテクチャ

ODS-RAM V2は、企業間・業界間・国境横断のデータ連携で発生する13の構造的課題に対応するために、4層の階層構造と4つのパースペクティブを組み合わせた参照アーキテクチャです。

前身にあたるウラノス・エコシステム・データスペーシズRAMホワイトペーパー（2025年2月28日版）からの改訂版で、ウラノス個別の色を薄めてグローバル利用可能な設計に一般化されました。

RAMは「設計図」で、次章のODPが「その設計図をシステム間通信に落とすための仕様書」という関係です。

ODP v1 — 相互運用性を成立させるプロトコル群

ODP（Open Data Spaces Protocols）は、レイヤー別に責務を分けた疎結合な技術契約のセットです。

L1〜L4は処理順ではなく、責務分担のラベルとして機能します。GitBook 公開時点の主要プロトコル群を整理すると次のようになります。

• 基本プロトコル
  Data Trust Assessment L1／Data Trustworthiness and Quality Assessment L1／Transaction L2／Identity and Trust L3／Metadata Exchange L4／Discovery and Search L4
  
  

• 共通機能
  Logging（Protocol）／Monitoring（Protocol）／Notifier（Protocol + Binding）
  
  

• 補完プロトコル
  Heuristic Contracting P1／Clearing and Payment P1（Protocol + Binding）

4層はそれぞれが独立した責務を持つレイヤーとして設計されており、ユースケースに応じて必要なレイヤーだけを組み合わせて利用できます。

「L1 → L2 → L3 → L4の順に契約を積み重ねる固定シーケンス」ではなく、たとえば信頼性評価と取引を並行で走らせる、認証だけを既存基盤に委任するといった構成も想定されています。

Clearing and PaymentがComplementary側にあることも見逃せません。決済プロトコルを分離することで、金銭のやり取りが伴わない研究連携・行政連携のケースでも同じプロトコルスタックを再利用できます。

Middleware・SDK — 参加事業者が「自ノードで動かせる」ための参照実装

参照実装のMiddlewareとSDKは、GitHub組織open-dataspacesで公開されています。

2026年4〜6月のリポジトリ更新履歴から確認できる主な構成は次のとおりです（L4 Discovery/SPARQL 系や SDK for Semantics など、公式リポジトリ一覧には別途拡張が進んでいます）。

• L2 Transaction層のWeb API（Java実装）
• L3 Identity Component（Java実装）
• SDK for Onboarding：Python/Javaクライアントライブラリ、Docker Compose、Helm Chart、Mockサーバー
• 共通機能：CF-Notifier（Python）
• 補完機能：DCS-Payment（Python）

この構成から読み取れるのは、事業者が「自ノードを立てて参加する」ためのハードルを可能な限り下げる意図です。

Docker ComposeとHelm Chartによりローカル環境でのPoCは着手しやすい構成ですが、商用運用に移行するには可用性設計・監視・障害復旧・オペレーション体制の整備が別途必要で、PoC構成のまま本番投入できるわけではありません。

---

欧州データスペース・Data Meshとの違い

ODSは米国 dataspaces原論文と Data Meshを統合した独立系譜で、欧州の IDSA／Eclipse Data Spaces／Gaia-X等とは出自が異なります。

ここでは実務目線での差分を、欧州側の実装・Data Mesh側の進化・ODSの立ち位置の3方向から整理します。

IDSA／Gaia-Xとの差 — 実装アプローチの違い

IDSA・Gaia-X・ODSの3系譜は、いずれも異なる組織間でデータを共有する目的は共通ですが、「参加事業者がどうやって接続するか」の実装アプローチが異なります。

• IDSA（IDS-RAM 4）
  参加組織が Connectorノードを立てて契約・データ交換を行うConnector中心の構成。
  
  Functional Layerでは有効な証明書によるIdentity Managementが必須要件として整理されており、多くの実装ではコンテナ管理技術を利用する。
  
  開発時などはコンテナ管理を省略できる場合もあるが、Connectorを他組織から到達可能にするため、組織のセキュリティ方針によってはファイアウォールポリシーの変更や DMZの構築が必要になる
  
  

• Gaia-X
  Data ConnectorやData Exchange Platform等の複数の実装形態を許容しており、参加形態はより柔軟。IDSAと一括りに「コネクター必須」で評価するのは正確ではない
  
  

• ODS
  IDSAと同一の Connector実装を前提に固定せず、IRIとOntology Endpoint／Data Endpointを中心とした構成で分散接続を成立させる設計を採用

Catena-Xの€23MのData Space Acceleratorが2026年に始動しているのは、SME層のデータスペース参加を後押しする目的で、公式にはコネクター負担のみが原因と断定されているわけではありません。

3系譜とも相互運用性を目指す点は共通ですが、参加事業者側の初期構築や運用モデルは、この実装アプローチの違いに応じて設計する必要があります。

DSSC Data Spaces Blueprint 3.0との位置関係

DSSCとBlueprint 3.0の位置づけ

Data Spaces Support Centre（DSSC）は、欧州のデータスペースを支援・調整する EU支援組織です。2026年2月10-11日にマドリードで開催されたData Spaces Symposium 2026のDay 2で、Data Spaces Blueprint 3.0を発表しました。

Blueprint 3.0はDSSC第1期（〜2026年）の集大成となる共通参照アーキテクチャ／ガイドラインで、正式な欧州標準ではなく参照文書として機能する位置づけです。

その後、2026年7月には DSSC第2期（2026〜2029年、EU Digital Europe Programme支援）も始動しており、既存 Blueprintの進化・実装フェーズへのシフトが進んでいます。

ODS-RAM V2との比較

DSSC Blueprint 3.0とODS-RAM V2は、どちらも「分散データ管理の参照アーキテクチャ／ガイドライン」を目指す点で共通していますが、以下の違いがあります。

観点	DSSC Blueprint 3.0	ODS-RAM V2
想定範囲	欧州の共有参照アーキテクチャ（Common European Data Spaces向け）	国と組織の多様性を尊重した設計、地域限定なし
中核構成	ビジネス・組織・技術の各ビルディングブロックを整備	DPQMベースの意味・データ二層モデル
運営主体	EU Digital Europe Programme支援のコンソーシアム（Gaia-X／IDSA／BDVA等の欧州データスペースコミュニティが連携）	IPAが中立的な設計統括、GitHubでOSS公開して参加開放
用途例	Catena-X／Manufacturing-X／Mobility Data Space等	ウラノス・エコシステム（自動車蓄電池・化学・ドローン）

独立系譜として並行発展、実装層では接続実証が進行

DSSC Blueprint 3.0も自身がデータスペース間の相互運用を対象としており、「域内は DSSC・域外は ODS」という二分は公式根拠がありません。

ODS-RAM V2とBlueprint 3.0の直接的な互換性・連携関係も、現時点では公式情報で確認できていないため、独立系譜として並行して発展している段階、と捉えるのが実情に近い理解です。

Data Meshとの継承関係 — Nextdata OSとの並走

Data Meshの提唱者であるZhamak Dehghaniは、Nextdata Technologiesから「Autonomous Data Products」というコンセプトと Nextdata OSを発表しています。

データバリューチェーン全体を「自律的なデータプロダクト」として封じ込め、開発から発見までを統合するプラットフォームです。

Nextdata OSは組織横断のデータ流通を目指す点で ODSと同じ問題領域を扱っており、セマンティックモデルやMCPを備えるなど意味層への踏み込みも進んでいます。
ただし、意味層の位置づけには設計思想の違いがあります。

• Nextdata OS：Data Productの自律性・封じ込めを軸に、セマンティックモデルをData Productに内包する統合プラットフォーム
• ODS：Data ProductとOntology Productを対等な2つのProduct Quantumとして独立分離し、意味層を個別に進化させる参照アーキテクチャ

IPA公式資料では、ODSはData Meshを補完し、組織横断時の意味・ガバナンスの相互運用をDPQM等で明示的に扱う「補完的なアーキテクチャパラダイム及び技術仕様」と位置づけられています。

Data Meshを旧世代と置き換える関係ではなく、Data Meshの4原則（Domain Ownership／Data as a Product／Self-Serve Data Platform／Federated Computational Governance）を承継しつつ、組織・国境を横断する際に露呈するGovernance ComplexityをDPQMと3本柱で埋める設計です。

Google Cloud Agentic Data Cloudとの違い — 参照アーキテクチャ vsマネージド製品群

Google CloudのAgentic Data Cloudもエージェント時代のデータ基盤という同じ論点を扱っており、Googleはオープンフォーマット・マルチクラウド（AWS／Azure／オンプレのデータも対象）・データを移動させない接続を公式に掲げています。

ODSとの違いは「ロックインの有無」ではなく、Google Cloud製品群を中核とするマネージド製品アーキテクチャと、ベンダー横断で共通言語を定義する参照アーキテクチャという性格の違いとして捉えるのが妥当です。

ODSがベンダー中立の共通言語を提供する一方、Agentic Data CloudはGoogle Cloudを主軸としたAIエージェント時代の統合基盤として位置づけられます。

---

ODSの実装ケース

ウラノス・エコシステム配下では、成熟度は異なりつつも、自動車・蓄電池／化学物質・資源循環／ドローン航路の3領域で並行して実装が進んでいます。

IPAは適合性検証や認証制度を提供しておらず、公式に「準拠」「適合」「認証」の表現は控えるよう案内している点にも留意が必要です。

自動車・蓄電池トレーサビリティ（ABtC × Catena-X 相互接続）

一般社団法人 自動車・蓄電池トレーサビリティ推進センター（ABtC）は、2024年5月から蓄電池CFP（カーボンフットプリント）データ連携のサービス提供を開始しています。

目的は、2024年から段階的に適用が進む EU電池規則（Battery Regulation）への対応で、対象電池の電池パスポートは 2027年 2月 18日から義務化されます。3事例の中では最も成熟度が高い実運用フェーズにあります。

2024年7月〜2025年1月にかけて、NTTデータグループが主導する形で、ウラノス配下のバッテリートレーサビリティプラットフォームとCatena-Xの相互接続実証（PoC）が実施され、2025年3月31日に成果が公表されました。

この実証は、IPAとCatena-Xが2024年4月23日に締結した相互運用性評価の覚書に基づくもので、認証方式・プロトコル・データモデルの差分を中間層で吸収する形で、双方のアーキテクチャに影響を与えずにデータ交換の実現可能性を確認した内容です。

したがって、「両アーキテクチャがそのまま噛み合った」わけではなく、「中間層による相互接続の実現可能性を確認した PoC」段階です。
公表資料では制度・運用面で扱うべき課題が複数あることが指摘されており、商用化に向けては継続的な取り組みが必要とされています。

化学物質・資源循環（CMP コンソーシアム）

CMP（製品含有化学物質・資源循環情報プラットフォーム）コンソーシアムは、2025年10月に発足した業界横断のデータ連携基盤で、電機・自動車業界の川上から川下まで576会員が参画しています（2026年7月時点）。

CMPは、単なる化学物質規制対応（RoHS・REACH等）にとどまらず、リサイクル材の含有率・純度・ソース、部品リユース情報といったサーキュラーエコノミー情報をサプライチェーン全体で共有することを目指しており、ウラノス・エコシステムの参照アーキテクチャを踏まえて設計が進んでいます。

NTTデータグループが化学物質情報トレーサビリティ管理システムの構築を開始しています。
経済産業省の CMP 構築スケジュールでは、2026年 3月末から大規模実証を開始し、2026年 9月に本番利用を開始する予定です。

CMP公式のアプリケーション事業者一覧では、Sotas・NEC・富士通の有償利用開始は 2026年 10月以降、dotDは2027年 4月以降と案内されています。

ドローン航路システム

3つ目の実装ケースは、経済産業省・NEDOのドローン航路プロジェクトです。

航路画定・航路予約・安全管理・離着陸場&機体管理・関係者通知の5機能をマイクロサービスアーキテクチャで構成し、UTMS（無人機運航管理）・SWIM（航空情報共有基盤）・DIPS（ドローン情報基盤）・SDSP（4次元時空間情報提供）との連携基盤としてウラノス・エコシステム由来のデータスペース設計を採用しています。

ISO 5491:2023 自体は電動貨物UAS向けType A（micro）バーティポートの構築要件を定めた規格で、ドローン航路システム全体や ODSの国際相互運用規格ではありません。

METIのドローンポート仕様書（附属書1）が、機械式離着陸場に関する要求事項として ISO 5491を参照しています。

ドローン航路プロジェクト自体は 3事例の中では先行実装・展開中のフェーズに位置します。

自動車（実運用）・化学（大規模実証フェーズ）・ドローン（先行実装展開中）の3領域で成熟度は異なりますが、性格の異なる産業で並行して実装が進んでいる事実は、ODSの汎用設計としての可能性を示唆します。

ただし「汎用性を証明した」と断定するには、各事例の商用化・継続運用の実績が積み上がるのを待つ必要があります。

---

ODSの参入コスト構造

ODSは仕様・OSS・ガイドブックがすべて無償公開されているため、ライセンス費用は発生しません。

しかし「無償だから安く始まる」わけではなく、実質コストは別のレイヤーに立ち上がります。ここでは、参入時に発生する費用構造を3層に分けて整理します。

直接コスト — OSS利用は無償、周辺インフラは自弁

ODS-RAM V2、ODP、各種ガイドブックはGitBook（CC BY 4.0等）、MiddlewareとSDKはGitHub組織open-dataspaces（MIT License等）で公開されています。
設計思想ドキュメント（Why Open Dataspaces）は IPA公式サイトから配布されており、成果物ごとに配布経路とライセンス条件が異なるため個別確認が必要です。

一方で、参照実装のMiddleware（L2 Transaction Web API・L3 Identity Component等）を実際に動かすには、KubernetesクラスタまたはDocker Compose環境が必要です。

参照実装レベルであればHelm Chartですぐに立ち上がりますが、本番運用ではノードの冗長化・監視・バックアップの標準的なインフラコストが乗ります。

間接コスト — オントロジー整備が主要要因の一つ

ODSの参入コストで主要要因の一つになり得るのが、自社ドメインの Ontology Productを設計・整備する工数です。DPQMの設計思想上、意味レイヤー（Ontology Product）が整っていなければ、他社のデータと繋げても意味的なマッピングができません。

オントロジー整備は「一度作って終わり」ではなく、業務ルールの変化に追随して更新し続ける必要があります。

費用感は対象範囲（何ドメイン・何エンティティを扱うか）、既存データ整備状況、社内で担うか外部委託かで大きく変動するため、公開されている一律の目安はなく、自社試算では想定ドメイン数・エンティティ数・人月単価をベースに個別に見積もりが必要です。

例えば、Palantir Foundry Ontologyはcompute-seconds ベースの従量課金、Microsoft Fabric IQ OntologyはCU 消費といったプラットフォーム側の運用課金は、オントロジー設計費とは別に発生する費目です。

DSSPハイブリッド（自前ノード＋外部Dataspace Service Providerの併用）で立ち上げれば、初期のオントロジー整備を段階的に進めながら参入できます。

認証・ID発行・ガバナンス設計

IUC（Identity and Usage Control）の運用には、ID発行者・信頼性評価者・監査者といった役割を担う主体が必要です。参加事業者は、これらのガバナンス役割を自社で担うか、外部サービスに委託するかを判断する必要があります。

IPAは中立的な設計統括を行っていますが、公式ページで「現時点では、認証制度や適合性検証の仕組みは整備されていません」と明示しており、IPA・NEDO 自身が ID 発行者・認証サービスとして具体的な運営体制を担うかは今後の公表を待つ段階です。

ODSを自社独自のデータスペースとして立ち上げる場合、ID発行と利用ポリシー管理は自前で設計する必要があります。
この設計コストは技術というより組織・法務レイヤーの費用になります。

---

##　日本企業がODSに乗るタイミングと詰まりポイント

「日本発の分散データマネジメント基盤」という響きに惹かれても、すべての企業がODSに乗るべきタイミングにいるわけではありません。

ここでは、AI総合研究所の支援現場で見えてきた検討軸を、ケース別に整理します。

いま検討すべき企業のシグナル

以下のシグナルが2つ以上当てはまる場合、ODSは検討フェーズに入る価値があります。

• 欧州事業を持ち、EU電池規則・CBAM等のデータ連携要請を受けている
  Catena-Xとの相互接続を検討する動線上でODSが選択肢になる
  
  

• 業界標準としてウラノス・エコシステム参画が現実的な選択肢になっている
  自動車・蓄電池・化学・電機系はABtC／CMPの動向を追う価値が高い
  
  

• 社内で複数の業務ドメインにわたるAIエージェントの本格運用を計画している
  Data Product×Ontology Productの分離が長期運用の土台になる
  
  

• 既存のData Mesh導入で「意味レイヤー不足」に突き当たっている
  DPQMがまさにこの課題への処方箋になる

逆に、社内単一ドメインでのRAG PoCで留めたい・国境横断のデータ流通が業務要件でない・オントロジー整備の運用体制を組む余力がない、といったケースでは、Microsoft Fabric IQ（Ontology機能は2026年7月時点でプレビュー段階）やFoundry IQ ナレッジベースなど、既存プラットフォーム機能で先行する方が現実的です。

実装で詰まりやすい3つの論点

ODS導入の相談で頻繁に出るのが、次の3つの論点です。いずれも設計段階で先に方針を決めておかないと、実装フェーズで手戻りが発生します。

• Ontology Productの粒度と所有者
  どのドメインをOntology Productの単位にするか、その責任者は誰か
  
  

• 既存データウェアハウスとの併存
  社内既存のDWH（Snowflake／Databricks／BigQuery等）をどう「Data Product化」するか
  
  

• IUCポリシーの法務レビュー
  利用条件を技術的に強制する設計にするなら、法務・情報セキュリティ部門との事前合意が要る

これらは技術論というより組織横断の意思決定を要するため、設計・実装の前にPoC計画とセットで論点整理をしておくことが実務的な進め方です。

実務観察 — 「先行取り組み」より「意味レイヤーの整備」から

ODSの登場を受けて「早く先行事例を作りたい」という相談が2026年6月以降増えていますが、支援現場で有効なのは順序を守ることです。

ウラノス3事例（ABtC／CMP／ドローン航路）が示すとおり、ODSは「既にドメイン側でデータ流通が必要になっている業界」で先に立ち上がっています。

逆に言えば、社内の業務要件として「複数組織を跨ぐデータ流通」がまだ具体化していない企業は、まずオントロジー整備やAIエージェント向けデータ基盤設計、AI-ready dataの品質要件整理から着手し、意味レイヤーが固まってからODSに乗る、という順序が現実的です。

「ODSに乗るか」という問いを、「自社の意味レイヤーが分散データ流通に耐える強度に整っているか」という問いに翻訳して考えると、判断がクリアになります。

---

ODSで整えたデータを業務Agentのアクションにつなげるなら

ODSはOSI・DAD・IUCの3本柱で分散データ流通の共通言語を提供する技術コンセプトです。

ただし意味層で整えたデータをカタログ化するだけでは、業務は動きません。データを業務アクション（申請・承認・レポート・通知）に変換し、実行ログ・権限・セキュリティを1つの基盤で統制する層が別途必要になります。

このレイヤーを担うのが、Teamsから呼び出せるエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、業務特化Agent群を1つのダッシュボードで統合管理し、ODSで整えたデータを業務アクションに変換する運用基盤として機能します。

• 意味層で整えたデータを業務アクションに変換
  DPQMのProduct Data Quantum × Product Meaning Quantumで整えたデータを、Teams上のAgentが自然言語で照会→報告→申請までワンストップで実行。「分析して終わり」から「アクションまで完遂」に橋渡しできます。
  
  
• 複数データスペースを横断したAgent実行
  記事で挙げたウラノス3事例のような組織横断データ流通を、Agentが業務プロセスに接続。IUC設計と組み合わせて、部門・企業をまたぐワークフローを実行できます。
  
  
• 構築基盤が違っても管理は1つ
  Copilot Studio・n8n・Microsoft Foundryなど複数の構築基盤で作ったAgentを1つのダッシュボードに集約。実行ログ・アクセス権限・セキュリティスキャンを一元管理します。
  
  
• データは100%自社Azureテナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、ODS的な分散データ設計から業務Agent基盤の統合まで一貫して支援します。AI Agent Hubのサービスページで、意味層と業務アクションの接続実装をご確認ください。

---

まとめ

本記事では、IPAが2026年4月1日に公開した Open Data Spaces（ODS）について、定義・パラダイム転換・3本柱・主要成果物・欧州との違い・ウラノス3事例・参入コスト・導入判断までを、2026年7月時点の最新情報で解説しました。要点を改めて整理します。

• ODSは 米国 dataspaces原論文（Franklin/Halevy/Maier 2005, 2006）と Data Meshを統合した独立系譜で、DPQMで意味と実データを同格に扱う分散データマネジメントの技術コンセプト
  
  

• 3本柱（OSI／DAD／IUC）が疎結合な責務分担で組み合わさり、DAD 内部の Ontology Query → Data Query 2段階クエリで参照・利用を成立させる設計
  
  

• 成果物は設計思想＝IPA公式サイト、参照アーキテクチャ・プロトコル・ガイド＝GitBook、Middleware・SDK＝GitHub組織 open-dataspacesと種類ごとに公開場所が分かれ、いずれもオープンライセンス（MIT・CC BY 4.0等）で提供
  
  

• IDSA／Eclipse Data Spaces／Gaia-X等の欧州系データスペースとは出自が異なる独立取り組み、DSSC Blueprint 3.0（第1期集大成／第2期は2026-07始動）とは相互運用性を重視するが直接互換性は未確認、Data Meshは補完（承継＋DPQM追加）、Nextdata OSとは意味レイヤーの扱いで差別化
  
  

• ウラノス3事例（ABtC×Catena-X／CMP／ドローン航路）は成熟度が異なりつつも並行実装、汎用設計としての可能性を示唆する段階
  
  

• 参入は仕様・成果物が無償公開だが、実質コストはオントロジー整備と IUC ガバナンス設計が主要要因の一つ

ODSに乗るか否かの判断は、「日本発の技術に対応するか」ではなく、「自社の意味レイヤーが分散データ流通に耐える強度に整っているか」を軸に置くと明確になります。ウラノス3事例のような具体的なデータ流通要件が既にある企業は先行検討の価値が高く、そうでなければ意味レイヤー整備から着手して段階的にODSに接続する順序が実務的です。