3. レイヤ 「レイヤ（Layers） 」はDPQMを機能目的に応じて論理的な階層に分離するものである。ODS-RAMは、「①データ（Data） 」、「②トランザクション（Transaction） 」、「③アイデンティティ（Identity） 」、「④セマンティクス（Semantics） 」の4つのレイヤで構成される。
ODS-RAMにおいて、それぞれのレイヤは互いに独立しており、疎結合する形で一連の分散データマネジメントに係る機能を果たす 。 つまり、ODS-RAMのレイヤは分離可能性を有しており、ODS-RAMを採用する者は、それぞれのドメインが有する性質・特性に応じて、必要となる階層数を選択的に決定することができる 。 例えば、ある横断的なドメインにおけるデータの宛先及び意味が明白な場合、Ontology as a Product、つまりL4～L2で構成されるセットの実装を省略して、L3～L1でまずはData as a Productを先行実装しても構わない。
ODS-RAMはそれぞれのドメイン及びユースケースに応じた柔軟性を重視しており、後方互換性の担保により、必要に応じた事後的なオプトインを許容することで、成熟度に応じた選択肢を提供する 。以下では、4つのレイヤそれぞれの機能について詳細を記載する。
3.1 データレイヤ（L1） 「データレイヤ 」（以下、L1という。）はデータに係る「利用制御（Usage Control） 」の問題、「データ改竄（Data Tampering） 」の問題及び「データ品質（Data Quality） 」の問題を解決するレイヤであり、CWA（Closed World Assumption）の挙動を選択的に採用する。
L1は、データ提供者のデータ利用制御及びデータの完全性・品質を担保したデータの取り扱いについての機能を要求する：
データ提供者が行使する利用制御については、データ共有契約等に定める範疇において、自己決定の機会が提供され、その行使が適切に反映されなければならない。
それぞれのデータの完全性及び品質特性の項目は対象とするドメインごとに多様であり、一律の水準を設けるのではなく、データの特性に応じた完全性や品質が担保されることを想定する。従って、データの完全性及び品質そのものについては規定せず、その評価・算定方法及び結果についてのみ、データ利用者が参照可能な形で提供されなければならない。
「トランザクションレイヤ 」（以下、L2という。）は「形態（Modal） 」の問題、「要求（Query） 」の問題及び「手段（Protocol） 」の問題を解決するレイヤである。 L2は、データの形態（構造、半構造、非構造等）を問わず、また要求や手段（同期、非同期等）にも非依存の方式によって、データの提供者と利用者のトランザクションプロセスを制御できなければならない。
「アイデンティティレイヤ 」（以下、L3という。）は、「認証（Authentication） 」の問題及び「認可（Authorization） 」の問題を解決するレイヤである。
L3は、「クレデンシャル（Credential） 」を検証可能な形で提供することによる、必要な水準の認証及び認可を要求する：
データ提供者及び利用者の実在性の検証と認証により、必要水準の信頼性を確保しなければならない。
データ提供者が自己決定するデータの保存・利用条件・粒度に基づくアクセス制御を行うことで、必要水準の機密性を確保しなければならない。
「セマンティクスレイヤ 」（以下、L4という。）は「宛先（Addressability） 」の問題及び「意味（Semantics） 」の問題を解決するレイヤであり、OWA（Open World Assumption）の挙動を採用する。 L4は、「メタデータ（Metadata） 」をアクセス可能な形で提供することによる、セマンティクス及びオントロジーの相互運用性を要求する：
宛先に関するメタデータはデータまたはサービスにアクセスするために提供されなければならない。
意味に関するメタデータは、データまたはサービスを利用するために必要な情報（入力/出力データ）の意味に関してユニークかつアクセス可能な形式で定義付けされなければならない。
1. はじめに 本章では、ODS-RAMの目的と位置づけ、想定読者、スコープを説明する。
1.1 本書の目的と位置づけ 「Open Data Spaces（ODS） 」は、国や組織ごとの多様性を尊重する、オープンでスケーラブルな分散データマネジメントの技術コンセプトの名称である。 また、本書で利用する一般名称としての「Open Dataspaces」は、米国のデータスペース原著論文（Franklin et al., 2005; Halevy et al., 2006）及びデータメッシュ（Dehghani, 2019; Dehghani 2022）を中核として、民間企業・団体と連携した研究開発・商用水準での検証を経ながら設計された新世代の分散データマネジメント技術及びそれを構成する概念を指す。
本書は、Open Dataspaces技術の利用者に向けた、相互運用性を確保するための階層構造モデルをはじめとした技術的なパラダイムを示す「参照文書（リファレンスアーキテクチャモデル）」である。Open Dataspacesは、分散型アーキテクチャとして掲げる3つの柱を実現するため「（1）ベンダーロックインの回避 」、「（2）制度的ロックインの回避 」、「（3）プロダクトライクでサービス志向の設計 」を根幹となる設計指針としている：
ベンダーロックインの回避 ：マルチクラウド、クラウドレスでの動作を前提とし、特定企業のサービス・商品に依存しないベンダーフリーな設計を採用する。
制度的ロックインの回避 ：特定法域の制度的・規制的要件を技術仕様から明示的に分離し、様々な制度・規制下でのローカライゼーションが可能となるように設計を行う。Open Dataspacesはグローバルで適応可能なアーキテクチャパラダイムと技術仕様を提供する。
プロダクトライクでサービス志向の設計 ：解くべき課題、そして、機能要求は常にマーケットにある。本質的なニーズは、法制度や規制、特定のベンダーのプロダクトやシステムにはない。ただし、マーケットを構成するユーザーが答えを教えてくれるわけではない。設計者は、マーケットが潜在的に求める革新から逆算しながら、アジャイルな検証を通じてProduct Market Fit（PMF）を目指していかなければならない。硬直的な技術仕様は陳腐化し、マーケットから拒絶される。Open Dataspacesは、Make Money, Save Moneyに資するか、という観点を非常に重視する。
本書は、「信頼性あるデータの自由な流通（Data Free Flow with Trust） 」*1（以下、「DFFT」という。）の実現に向けた横断的な「相互運用性（Interoperability） 」を担保し、分散データマネジメントにおける共通のリファレンスモデルとなることを目指すものである。
本書の主要読者は、国内外における幅広い産業を対象に、データマネジメントやAIに関わる技術の採用・導入、企画を検討する技術者を想定している：
Open Dataspaces技術の導入を担う企業のアーキテクト、技術責任者
Open Dataspaces技術を活用した分散データマネジメントサービスを実装しようとするソフトウェア企業、その技術部門のアーキテクト、技術責任者
Open Dataspaces技術に触れてみたい開発者、学術関係者、学生など なお、読者はデータマネジメントに関する技術・事業開発の基礎知識を有していることが望ましい。
また、本書は、企業・業界・国境を横断した分散データマネジメント技術の採用に関して、アーキテクチャを新規に設計又は既存のアーキテクチャの評価を実施する際のメタアーキテクチャとして参照されることを想定する。
本書は、分散データマネジメントのための技術的なアプローチを対象とし、リファレンスアーキテクチャモデルとして以下の項目を取り扱う：
In Scope:
Out of Scope:
ODS-RAMは、すべてのデータマネジメントを包含するリファレンスアーキテクチャではなく、従って、すべてのプロジェクトが本書を参照する必要はない。また、本書は以下のようなテーマについても扱わない：
アーキテクチャ設計時の基本原則や産業要件（コンテクストカタログ）
特定製品・特定ベンダーが提供するサービスに関する対応や実務
法制度に関する対応や、法務やガバナンスに関する実務
表1 参照先
脚注 *1 2019年のスイス・ジュネーブで開催された世界経済フォーラム年次総会（ダボス会議）で提唱され、2019年6月のG20大阪サミットにおいて各国首脳からの支持を得て首脳宣言に盛り込まれた。Digital Agency. Overview of DFFT.
技術仕様の解説やOSS（オープンソースソフトウェア）の導入手順、SDK（ソフトウェア開発キット）の利用方法
ODS 事業者向け参入ガイドブック（開発事業者向け）
ソフトウェアやデータ関連サービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理
ODS 事業者向け参入ガイドブック（ユーザー事業者向け）
データマネジメントやAIサービスを利用または自社で実装する立場にある事業者の実務者・経営企画担当者が、データスペース事業への参入を検討する際に、参入の是非・自社が担い得る役割・初期投資の置き方を判断するための視点を整理
Open Dataspaces技術を採用・導入またはサービス提供する立場にある技術者を対象に、その技術的な全体像と基礎を理解し、設計・実装・運用に着手するための考え方と最小構成を整理
Whitepaper: ウラノス・エコシステム・データスペーシズ リファレンスアーキテクチャモデル
2025年2月に公開されたホワイトペーパーで、設計初期段階の問題定義や基本原則、設計時のインプットとなる産業要件（コンテクストカタログ）、コンポーネントの構成を提示
4つのレイヤと4つのパースペクティブで構成されるアーキテクチャ構造
各レイヤ・パースペクティブにおけるプロトコルの要件
Why Open Dataspaces: 設計思想とアーキテクチャパラダイム. （以下、「Design Philosophy」）
組織・企業・国境を横断した新たな分散データマネジメントの技術パラダイムであるODSの設計思想/アーキテクチャパラダイムの解説文書
ODS-RAMをもとに分散データマネジメントを実現する機能を提供し、Open Dataspacesの相互運用性を担保する一連の技術的な取り決め
第4章 ODS-RAMの構成とサービス参画構造 4.1 ODS-RAMにおける主体と関与形態 分散データマネジメントにおいては、ドメインオーナーであるデータ提供者に対して、どの機能・責務を補完的に担い得るかという観点でステークホルダーを整理することが重要である。 ODS-RAM では、相互運用性を、特定技術や製品ではなく「プロトコルの組み合わせ」として定義している。ファンダメンタルプロトコル は、すべてのOpen Dataspacesで共通に成立すべき最低限の枠組みを示し、コンプリメンタリプロトコル は、用途や成熟度に応じて採用される拡張領域を示す。 これを踏まえて、機能別に役割を整理すると、大まかには表3のように示すことができる。
表 3 ODSにおけるサービス主体種別
データスペース事業への参入を事業として成立させるためには、どの実装領域を担えるかだけでなく、それを継続的に提供できるサービスとしてどう切り出すかを明確にする必要がある。 Open Dataspacesでは、すべての機能を単一の事業者が提供する必要はない。
以下に、ODS-RAMにおける運用モデル（分散型・連邦型・ハイブリッド、表4）と2つのサービス提供形態を整理する：
表 4 ODS-RAMにおける運用モデル
ODS Protocolsで定められる技術要素（データディスカバリー、セマンティクス・オントロジー管理、アイデンティティ管理、アクセスおよび利用制御、トランザクションマネジメント、証跡管理等）をソフトウェアとして実装し、その運用をサービスとして担う形態である。
これらの機能は、大企業などであれば分散型サービスモデルとして、独自でのデプロイが可能であるが、中小企業など、独自に実装が難しい企業も多く存在する。 連邦型サービスモデルや、ハイブリッドサービスモデルの場合、これらの機能はマネージドサービスとして提供されることが想定され、開発事業者にとってはソフトウェアプロダクトとして事業化し得る領域となるだろう。
近年のソフトウェア産業では、ソフトウェア機能そのものではなく、サービスの提供プロセスをソフトウェアとして実装し提供するモデルが注目されており、これを「Service as Software（SaS） 」と呼ぶことがある。 SaSでは、ユーザーは単にアプリケーションを操作するのではなく、ソフトウェアを通じて提供されるサービス成果を利用する。従来は人手によって提供されていたサービス業務が、ソフトウェアや自動化技術によって提供される形態である。
Open Dataspacesの文脈では、この考え方は特にデータサービスにおいて重要となる。データの整備、意味付与、更新、利用条件管理などを継続的なサービスとして提供することにより、データそのものがサービス機能の一部として提供される。 例えば、
アナログ情報のデータモデル化及びパイプラインの構築
業界ドメインデータへのコンテクスト付与（オントロジー設計）
データのAI-Ready化 などが挙げられる。 これらは、データ提供者自身が、データマネジメント自体に課題を抱えている場合は、Biz/Dev/Ops（事業、開発、運用）チームの組織的な分断により、投資対効果（ROI）に対して効果的なデータ整備が行えていない場合などに事業化し得る領域となるだろう。
データスペース事業への参入判断は、「新技術への対応」や「標準化への追随」だけでは成立しない。 事業会社・開発事業者が投資判断を行う上では、参入によって収益構造がどう変わるのか、そしてなぜ継続的な事業として成立し得るのか、つまり、「Make Money、Save Money」の基準が明確である必要がある。 その意味で、Open Dataspacesがもたらす本質的な変化は、個別連携（1対1）の積み上げでは到達できない N対N の接続構造が、一定の規律と相互運用性によって現実の選択肢になる点にある。 この構造変化は、開発事業者にとって 「受託中心」から「継続収益中心」への転換を成立させる土台となるだろう。
セマンティクス・オントロジー、アイデンティティ・トラスト、トランザクションマネジメントなど、ODS-RAMに位置付けられた中核的な機能を、ソフトウェア又はサービスとして提供する主体。本書では、開発事業者が実装・提供し得る代表的な関与形態として扱う。
データスペースコンプリメンタリサービス（Dataspace Complementary Services）を提供する主体
ディスカバリー、契約、精算・決済など、Open Dataspacesの利用や拡張を補完する機能を提供する主体。本書では、中核的な機能を前提として付加価値を提供する関与形態として整理する。
インダストリーサービス（Industry Services）を提供する主体
Open Dataspacesを通じて取得したデータを活用し、特定の業界・業務領域におけるアプリケーションやサービスを提供する主体。本書では、Open Dataspaces技術を「手段」として活用する立場として扱う。
ソフトウェア事業者がマネージドサービスとして機能を提供
4.3.2 データを中心としたサービスのソフトウェア提供 4.3.3 事業継続性を支える経済的インセンティブ 第1章 はじめに 1.1 本書の目的 「ODS 事業者向け参入ガイドブック（ユーザー事業者向け）（本書） 」は、個別仕様や実装手順を解説する技術書や手順書ではなく、参入判断に必要な概念理解と検討視点を提供することに主眼を置く。 参入判断に当たっては、実際の参照実装ソフトウェアを用いて標準仕様でできることを確認しながら理解することが重要であり、「ODS技術者向け導入ガイドブック」において具体例とともに扱うことを想定している。従って、本書は、その前段階として、Open Dataspacesの全体像をユーザー事業者の視点で理解し、どこに事業機会があり、どこから先は実装ガイドや参照実装で確認すべきかを切り分けることを目的としている。
1.2 想定読者 本書でいう「ユーザー事業者」とは、データマネジメントやAIサービスの利用に関わる事業者(民間、公的セクター)を幅広く含む以下のペルソナである：
外部データの活用（調達・品質管理・AI分析等）を検討している事業者の経営企画・デジタル推進担当
自社が保有するデータを外部に提供・連携することの是非を検討しているデータ管理担当・事業企画担当
複数の取引先・サプライチェーンパートナーとのデータ連携を改善したいシステム部門・調達部門担当
BI/DI分析・AIサービスの導入を検討している情報システム部門・業務改革担当
データスペース関連のマネージドサービス・アプリケーションの利用（ユーザー事業者として参入）を検討している新規事業担当
本書では、ユーザー事業者がデータスペース事業への参入可否を判断するために必要な内容に焦点を当てる。判断に直接関係しない詳細な専門領域については扱わない。
ユーザー事業者の立場から想定される参入の軸と検討ポイント
特定製品・特定ベンダーが提供するサービスに関する対応や実務
法制度に関する対応や、法務やガバナンスに関する実務
参照すべき関連ドキュメントは表1のとおりである。
表 1 参照先
本書は、ユーザー事業者がデータスペース事業への参入を検討するために必要な理解を、段階的に深められるよう構成している。各章で下記の内容を取り上げているので、読み進めて頂きたい。
第2章 ：AI時代の産業構造転換とデータマネジメントの戦略的価値
第4章 ：Open Dataspacesへの参画構造
技術仕様の解説やOSS（オープンソースソフトウェア）の導入手順、SDK（ソフトウェア開発キット）の利用方法
ODS-RAMをもとに分散データマネジメントを実現する機能を提供し、Open Dataspacesの相互運用性を担保する一連の技術的な取り決め
ODS 事業者向け参入ガイドブック（開発事業者向け）
ソフトウェアやデータ関連サービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理
Open Dataspaces技術を採用・導入またはサービス提供する立場にある技術者を対象に、その技術的な全体像と基礎を理解し、設計・実装・運用に着手する
第5章 ：ODS導入検討のプロセス
第8章 ：本書のまとめとユーザー事業者へのメッセージ
Why Open Dataspaces: 設計思想とアーキテクチャパラダイム. （以下、「Design Philosophy」）
組織・企業・国境を横断した新たな分散データマネジメントの技術パラダイムであるODSの設計思想/アーキテクチャパラダイムの解説文書
Open Data Spacesリファレンスアーキテクチャモデル（以下、「ODS-RAM」）
企業・業界・国境を横断した分散データマネジメントのためのリファレンスアーキテクチャ。技術パラダイムや階層構造モデル、プロトコルの関係性などにより構成される参照文書
第4章 Open Dataspacesへの参画構造 4.1 参加形態の選択：分散型・連邦型 ODS-RAMには「分散型サービスモデル 」（自社がODS Protocolsを直接実装・運用）と「連邦型サービスモデル 」（マネージドサービス事業者を介して参加）の2つの実装パターンがある。 「分散型」と「連邦型」のハイブリッドである「ハイブリッド型」含め、それぞれの概要を表4に示す。 ユーザー事業者にとっては参入初期において連邦型が参入障壁を下げやすい。なお、連邦型においてもデータとオントロジーはデータ提供者が責任を持ち利用制御を行うことが前提である。
表 4 ODSへの参加形態
Open Dataspacesは中央集権型のプラットフォームではなく、ドメインオーナーを中心に複数の主体がそれぞれの役割を分担する分散型のアーキテクチャパラダイムである。 参入・導入を検討する際には、「どの主体になるか」ではなく「どの機能・責務を担うか」という観点から自社の立ち位置を把握することが重要である(表5)。
表 5 Open Dataspacesにおけるユーザー事業者の種別
Open Dataspacesへの参加は画一的にすべての要件に従うものではなく、自社の成熟度に応じた段階的導入が現実的かつ有効である。 表6に段階的な導入のレベルを示す。
表 6 段階的な導入のレベル
Open Dataspacesの参画促進は「抽象的な仕組み論」からではなく、実際のユースケースに即して進めることが成功の鍵である。 参画を段階的に進めるためには、自らが利害関係を持つユースケースにおいて最小限必要な機能・制度から整備することが現実的かつ有効である。
ユースケース選定の起点として以下の問いが有効である：
自社が「データを出す側」か「データを使う側」か（あるいは両方か）
現在、個別API連携やCSVでの連携に費やしているコスト・手間はどの程度か（Save Moneyの観点）
Open Dataspacesを通じて得られるデータが、自社のAI活用・BI/DIにどう貢献するか（Make Moneyの観点）
次章では、これらの問いへの答えを整理するための参入検討プロセスを体系化する。
第3章 Open Dataspacesとは何か Open Dataspacesは、企業内データ基盤の延長でも、単一企業が支配する共有プラットフォームでもない。 重要なのは、「すべてのデータをどこか一か所に集める（Push and Ingest） 」ことではなく、「分散したまま、どこにあり、何を意味し、誰がどう使えるかを扱えるようにする（Serving and Pull） 」ことである。
分散データマネジメントの手法としては、すでに米国などで「Data Mesh（データメッシュ） 」といったアプローチが注目されており、その導入企業も増加している。しかし、Data Meshは「企業組織内に散らばったデータを、どう分散したままマネジメントするか」が焦点であり、企業や国境を横断するデータマネジメントについては、対応できていない。Open Dataspacesは、このギャップを埋めるためのアプローチである。
企業を横断するデータマネジメントには様々な課題があるが、Open Dataspacesは主に以下3点の課題に対処するための解決策を提供する：
Where to getの問題 ：データの存在・同一性・探索可能性を扱う。（例：そのデータは、そもそもどこにあるのか？そのデータは、このデータと同一のものを指し示しているのか？）
第6章 ODS Protocolsを実装するサービス構築の基本的考え方 本章は、第4章で整理したOpen Dataspacesにおけるサービス提供の構造、ならびに第5章で整理した参入パターンを前提として、ODS Protocols実装のマネージドサービス及びデータを中心としたサービスのソフトウェアを提供する主体が、技術的な実装に着手する際に押さえておくべき基本的な考え方を整理するものである。
サービスの構築フェーズに進むにあたり、開発事業者は次の観点を整理しておく必要がある：
自社が担う関与形態（Fundamental/Complementary/Industry、またはその組み合わせ）
プロトコルによる規律領域と設計の裁量がある領域との切り分け
第5章 開発事業者の参入戦略 Open Dataspaces技術を活用したサービスは、単に新しい技術やプロトコル仕様への対応そのものを目的とするものではない。 まず何よりも、分散データマネジメントにより事業としてどのような価値が生まれ得るのかに着目する必要がある。
個社のGTM戦略は、どの課題に関与するか、どの機能範囲を担うか、どこまで価値提供に踏み込むかといった選択の組み合わせとして定めていく必要がある。 本節では、参入形態を組み立てるためのGTM戦略における4つの整理軸を示していく。
第一の整理軸は、「理想的な顧客像（ICP：Ideal Customer Profile） 」の設定である。 大まかには、データ提供者・データ利用者・仲介者（マネージドサービスやサードパーティアプリケーションの提供者）の3つに集約される。同じ機能でも、どのようなICPを設定するかで、価値の言語化・価格設計・責任境界が変わる。
第二の整理軸は、ICPが抱える課題（ペイン）の解像度の高い特定である(表5)。「Where to getの問題（DAD）」「What to meanの問題（OSI）」「Who and How to useの問題（IUC）」のどのペインにソリューションを提供するかを選択し、GTM戦略とプライシングモデルを決定する。関与範囲の取り方によって、専門特化型の参入や包括的な参入など、必要となるGTMモーションが変化する。 また、フェーズという観点で顧客課題を整理することも有効である：
表 5 導入フェーズごとの顧客の課題
Open Dataspaces対応アプリ・マネージドサービスをユーザーとして導入する
Open Dataspaces対応BIツール・DIツール・AIサービス・在庫管理サービスの利用
マネージドサービス事業者が提供する基盤機能（Identity and Trust、Metadata Exchange等）を利用して参加する
外部事業者のODP実装を利用してOpen Dataspacesにオンボードする
1〜2件の分散データマネジメントユースケースを試行
複数Open Dataspace・業界プロファイルへの横展開
Open Dataspacesを事業上の競争優位として活用
自社環境でODS Middlewareを運用し直接接続する
技術力・運用リソースがあり、ソフトウェアとそのオペレーションを完全に自社保持したい場合
マネージドサービス事業者の提供基盤を利用して参加する
初期コストを抑えつつ早期参入したい場合、技術リソースが限定的な場合
コア機能は自社運用、補完機能は外部サービスを活用する
自社が保有するデータ及び意味（オントロジー）をProductとして外部に提供し、利用条件を自社で管理する
製品データ・センサーデータ・購買データの条件付き外部提供
外部のデータを条件付きで取得し、業務・分析・AIに活用する
サプライチェーンデータの取得、外部APIとの連携活用
Open Dataspaces未参画。情報収集フェーズ
本書を読んでいる段階。課題・ユースケースの言語化を開始
Open Dataspacesの概念・利点を理解し社内議論を開始
4.2 Open Dataspacesにおけるユーザー事業者の立ち位置 参照実装OSS（ODS Middleware）活用と自社開発部分の切り分け
非機能要求と運用設計の基本観点を含めたサービス構築スコープの明確化
「ODS Protocols（ODP）」は、参加者間の相互運用性を成立させるために必要な役割分担や手続き、主体間のやり取りの構造を定義するものである。「どのような振る舞いが求められるか」という外形的な枠組みを示す一方で、具体的な技術スタック・内部コンポーネントの構成までを固定するものではない。
重要なのは、「プロトコルが示すのは外部との整合が必要な振る舞いであり、内部構成までを固定するものではない」という理解である。この切り分けを明確にすることで、外部との相互運用性を確保しながら、自社の差別化領域に開発リソースを集中させることが可能となる。
プロトコルを実装するための基本的なコンポーネントについては、ODSの開発コミュニティが擁する参照実装OSS（ODS Middleware）を活用することで、実装負荷を軽減しつつ相互運用性を確保しやすくなる。
一方で、業務固有のロジック、運用を支援する管理機能、分析や可視化などの付加価値領域は、自社の強みを活かした実装対象となる。OSSをマネージドサービスとして提供する際には、どの部分をOSSに依存し、どの部分を自社の責任範囲として保持するかというSLAを明確に設計する必要がある。 また、プロトコルやOSSの更新に追随できるよう、マイクロサービスアーキテクチャを採用することが設計指針として示されている。
サービス提供では、非機能要求と運用設計が重要な位置を占める。可用性や拡張性は分散データマネジメントの継続性に直結する。また、監査性や可観測性も重要であり、データのトランザクション履歴やプロセスを追跡可能な形で記録し、必要に応じて参照できることは、ガバナンスやトラストを技術的に支える基盤となる。セキュリティについてはOpen Dataspaces固有の要件に加え、通信の暗号化や鍵管理、脆弱性対応といった一般的な標準との整合を前提とする。
サービスの構築において開発事業者が特に意識すべき要点は、次の三点に整理できる：
プロトコルによって規律される領域と、自社裁量で設計できる領域を混同しないこと
ODS Middleware活用と独自実装の境界を明確にし、更新追随や交換可能性を意識した構造とすること
非機能要求と運用設計を、実装の後工程ではなく初期段階から構築スコープに含めること これらの観点は、Design Philosophyに示された設計指針3原則（①ベンダーロックインの回避、②制度的ロックインの回避、③Product-likeなサービス志向の設計）とも対応する。
本章で整理した観点は、次章で扱う導入ステージ別の検討や実践に直結する基盤となるものである。
6.3 プロトコルによる規律領域と設計の裁量がある領域との切り分け 6.4 オープンソース利用と自社開発部分の切り分け 接続までの負荷 ：誰と、どの条件で、どの方式で接続できるかが事前に分からず、接続ごとに仕様調整・確認・運用設計が発生する。連携先の増加に伴い、調整コストが累積する。
データを使える状態にする負荷 ：データを取得できても、意味・前提・品質が分からず、業務・分析・AI に安心して利用できない。特に外部データほど不確実性が高い。
運用の信頼・遵守・セキュリティの担保 ：利用条件が守られているか、来歴を追えるか、相手をどこまで信頼できるかが曖昧で、本格活用に踏み切れない。
第三の整理軸は、ODS-RAMにおける機能範囲のどの部分をソフトウェアとして担うかである。 プロトコルに近いほど運用責任が大きくなる一方、アプリケーションサイドではドメイン知識や業務理解が差別化要因となる。
最後の軸は、どこまでを自社の提供責務（SLA）として引き受けるかである。 プロトコルを実装した機能提供までか、運用・監視・更新対応まで含めたマネージドサービスとするか、利用設計や改善支援まで支援するか、によってGTMモーションが変わる。
本節では、前節で整理した参入パターンの考え方を具体化するため、代表的な3つの事業例を示す：
データディスカバリー、セマンティクス管理、アイデンティティ管理、利用制御など、ODS Protocolsで定義される機能をソフトウェアとして実装し、データ利用者や提供者に対し、それらをマネージドサービス（あるいは、自社運用のためのオンボーディング支援サービス）として提供する参入形態。 ファンダメンタルプロトコルのみをマネージドサービスとして提供するパターンや、コンプリメンタリプロトコルをサードパーティアプリケーションとして提供するパターン、それらの組み合わせなどが想定される。
データモデリング、意味付与、更新管理などを含め、データそのものの整備に必要となる工数に対するサービスをソフトウェアとしてデータ提供者に対して提供する形態。
Open Dataspacesを通じて取得した外部データを活用し、特定業界向けのAIやBI、DIアプリケーションをデータ利用者にサードパーティサービスとして提供する形態。
本節では、開発事業者が実際に参入の是非を判断するための現実的な材料を整理する。 ここで示す内容は精緻な事業計画を立てるためのものではなく、「この参入は自社にとって現実的か」「どの程度の体制・リソースが必要か」を見極めるための目安である。
参入パターンによって、必要となる投資規模や実装の難易度は大きく異なる。以下は一般的に想定でき得る傾向であり、個別条件によって前後し得る点に留意されたい。
プロトコル実装のマネージドサービス : 仕様や標準規格への理解と実装対応が前提。単一コンポーネントのPoCはエンジニア数名・数ヶ月程度から着手可能なケースもあるが、本格展開には専門チームを前提とした中長期投資が必要となる。
データを中心としたサービスのソフトウェア提供 : 顧客単位での段階的着手がしやすい。提供データの品質保証・責任分界・契約モデルの整理といった非技術的要素の抽象化がスケーリングを左右する。
インダストリーサービスとしてのアプリケーション : Open Dataspaces技術の実装負荷自体は相対的に低いが、顧客価値の設計と成果責任の比重が高くなる。
技術的な運用を確認するPoCに加え、参入判断においては「ビジネスとして意味があるか」を検証する視点が不可欠である。 コスト削減効果・価値創出効果によるROI、リードタイム、データドリブンアプローチの有用性について、自社なりの仮説と数値感を持てるかどうかが、本格参入に進むか否かを判断する一つの目安となる。
次章では、これらの参入戦略を前提として、ODS Protocolsを実装する際の基本的な考え方を整理する。
また、参入判断においては、技術的な成立性だけでなく、ビジネス価値の仮説検証が重要となる。 次章では、これらの参入戦略を前提として、Open Dataspaces技術を実装する際の基本的な考え方を整理する。
例2 データを中心としたサービスのソフトウェア提供 例3 インダストリーサービスとしてのアプリケーション 5.4.2 ビジネス価値の仮説検証（PoV（Prrof of Value）） What to meanの問題 ：データの意味、語彙、意味的整合性を扱う。（例：そのデータは、何を意味しているのか？そのデータの意味は、このデータの意味と整合しているか？）
Who and How to useの問題 ：主体の信頼、アクセス、利用条件を扱う。（例：データにアクセスしようとしているのは誰か？誰がそのデータにアクセスできるのか？そのデータはどう使わなければならないか？）
これらはそれぞれ、「（1）DAD（Data Addressability and Discoverability） 」、「（2）OSI（Ontology and Semantic Interoperability） 」、「（3）IUC（Identity and Usage Control) 」の3本柱として整理されている。この3本柱の技術的詳細・設計原則・アーキテクチャへの影響については、Design PhilosophyおよびODS-RAMに体系化されている。
本書では各柱の役割とユーザー事業者の参入余地との対応関係を整理するに留める。
従来のデータマネジメントは、自社内にデータを集約して管理・分析する発想と、必要な相手ごとに個別接続を行う発想の2つに依拠してきた。Open Dataspacesは、「集約」でも「個別調整」でもなく、分散したまま存在・意味・利用条件を扱うという別のアプローチを取る。 従来のデータマネジメントとの比較を表2に示す。より詳細な比較については、Design Philosophyを参照されたい。
データ提供企業が外部提供をためらう理由は、単に情報漏洩リスクだけではない。 「そのデータが何を意味するかを外部に正しく伝えられない」「他社のデータと同一視されて誤用される」「利用条件を運用に落とし込みにくい」といった問題が重なっていた。 Open Dataspacesでは、データの存在や識別の問題、データの意味や語彙の問題、アクセスや利用条件の問題を分離して扱える。この分離により、データ提供企業は、自社の内部システムや内部識別子をそのまま統一することなく、必要な範囲・条件で外部提供を設計しやすくなる。
Open Dataspacesは、探索可能性、意味の整理、主体と利用条件の整理を分けて扱うことで、外部データ取得後の「意味の解釈・整合・利用条件確認」にかかる実務負荷を下げる。これにより、利用企業は外部データをBI/DI分析、業務アプリケーション、AI活用に組み込みやすくなる。
ユーザー事業者にとってのOpen Dataspaces参入余地は、例えば表3のように整理できる。これは業界・用途に依らない汎用的なビジネスモデルの視点である。
表 3 Open Dataspacesへの参入パターン
なお、Open DataspacesではN:N接続構造が一定の規律と相互運用性によって現実の選択肢となる。1:1の個別連携では到達できない規模の事業価値がOpen Dataspaces参入の本質的な動機となる。
最後に、AI産業とOpen Dataspaces市場の関係性を整理する。AI活用、とりわけ業務データを前提とした分析やAgentic AIの利用においては、単に大量のデータがあることよりも、「データの文脈、意味、利用条件、更新性」を継続的に扱えることの方が重要になる。 Design Philosophyにおいても、AI時代において固有のコンテクストはデータの本質であり、ドメインオーナーがそれを明示的に意味（オントロジー）として与えることの重要性が示されている。 Open Dataspaces技術は、こうした課題に対し、エンドポイントの検索可能性、セマンティックスやオントロジー、アイデンティティと利用制御の技術的基盤を提供する。
これにより、例えば以下のような効果が期待できるであろう：
データ間の関係性や文脈を前提とした推論や解釈を行いやすくなる
データの出所や更新性を踏まえたAIパイプラインを構成しやすくなる
個別調整だけに依存せず、外部データをAI活用に組み込みやすくなる
次章では、この前提の上で、ユーザー事業者がどのような立ち位置を取り得るのかを、参画構造の観点から整理する。
3.3 Open Dataspacesが提供する価値 3.4 Open Dataspacesで実現できるビジネスモデル例 3.5 AIとOpen Dataspacesの関係性 第2章 AI時代の産業構造転換とデータマネジメントの戦略的価値 2.1 日本の産業構造：ハード中心の強みと変化の兆し 日本の産業は長らく、自動車、精密機械、家電などの製造業を中心に、品質・信頼性・量産技術といったハードウェアの強みを基盤として競争力を築いてきた。これらは現在においても日本経済を支える重要な要素である。
一方で、価値の形成構造は近年大きく変化している。製造時点の性能や品質だけでなく、運用段階での機能更新や外部サービスとの連携を通じて、継続的に価値が生み出される構造が一般化しつつある。こうした変化は自動車産業に限らず、多くの分野で観測されており、データやソフトウェアを活用した運用・サービスが価値競争の中心となりつつある。
2.2 世界的構造変化とプラットフォーム競争の現実 検索、OS、SNS、EC、クラウドといったデジタル領域では、利用者とデータの集積を基盤とするプラットフォーム型ビジネスが競争優位を確立してきた。利用者が増えるほどデータが蓄積され、そのデータを基にサービス改善が進み、さらに利用者が増えるというネットワーク効果が働くためである。
一方で、本書が対象とする産業データ連携の領域では、消費者向けプラットフォームとは異なる性質が支配的となる。企業間で扱われるデータは、契約条件、責任分界、機密性、規制対応といった前提を伴い、単一主体による集中的な管理や囲い込みが必ずしも合理的とはならない。国立研究開発法人 新エネルギー・産業技術総合開発機構（NEDO）の調査*1によれば、このような産業データに係るアプリケーションおよびミドルウェアを中心とするデジタル関連市場は今後も拡大が見込まれており、2040年時点では国内で約30兆円規模、グローバルでは約200兆円規模に達すると予測されている。
2.3 「データはあるのに使えない」構造的問題とデータアクセス能力 AI活用を含む価値創出では、「どのデータを保有しているか」以上に、必要なデータへ適切な条件でアクセスできるか（データアクセス能力）が競争力を左右する。しかし多くの企業では外部データ活用が十分に進んでいない。背景は個社の努力不足ではなく、構造的な要因にある。データ連携が進まない構造的課題の詳細はDesign Philosophyに体系化されている。本書では、これらの課題が存在するという前提のもとで議論を進める。
次章では、Open Dataspacesが従来のデータマネジメント体系とどのように異なるのかを整理し、ユーザー事業者が理解すべき機能構造について確認していく。
脚注
*1 NEDO. (2025). データスペース市場規模調査及びインパクトモデリング・シナリオ分析 調査報告書.
参考文献 独立行政法人情報処理推進機構. (2026). Open Data Spaces Reference Architecture Model.
Dehghani Z. (2019). How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.
Dehghani Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O’Relily Media.
Franklin M, Havely A, Mayer D. (2005). From databases to dataspaces: a new abstraction for information management.
Halevy A, Franklin M, Mayer D. (2006). Principle of dataspace systems.
NEDO. (2025). "データスペース市場規模調査及びインパクトモデリング・シナリオ分析 調査報告書". [https://www.nedo.go.jp/content/800039315.pdf]
独立行政法人情報処理推進機構, 経済産業省.(2025). Whitepaper: ウラノス・エコシステム・データスペーシズ リファレンスアーキテクチャモデル (ODS-RAM).
Tsuda M. (2026). Why Open Dataspaces: 設計思想とアーキテクチャパラダイム. 独立行政法人情報処理推進機構.
第7章 導入ステージ別の進め方 7.1 導入ステージ別整理の考え方 本章では、Open Dataspacesのサービス導入を「検討・実証・展開（GTM）」の3ステージに分け、各ステージで何を確認し、どこまで整理すべきかを示唆する。 表6に導入ステージ別の検討・実施内容を示す。
表 6 導入ステージ別の検討・実施内容
これらは厳密に分離された工程ではなく、事業環境やユースケースに応じて往復しながら進むこともある。 重要なのは、各ステージで整理すべき観点を明確にし、技術と事業の成立性の双方を段階的に確認していくことである。
検討ステージは、第5章で整理した参入パターンを前提として、実際の構築スコープに落とし込むフェーズである。 「何を作り、何を作らないか」を具体化することが目的となる。
実証ステージでは、最小構成（MVP）で「技術・事業・運用が成立するか」を確認する。 目的は完成度を上げることではなく、外部と整合が必要な領域と自社の任意領域が分離された設計で、運用まで含めて回る見通しを得ることである。
GTMステージは、実証ステージで確認した成立性を前提として、ミドルウェアを継続的に提供・運用可能なプロダクトへと移行する段階である。 標準仕様の更新、運用要件の変化、対象データスペースや業界の拡張に耐えられる構造を備えているかが問われる。
ODS開発者コミュニティが提供するOSSは、複数の運用環境で再利用されることを前提としたプロダクトである。本節では、検討・実証・展開のいずれのステージでも共通して意識すべき設計上の注意点を整理する。ミドルウェア開発において特に重要となる注意点は次の通りである：
運用要件を内部構造に固定しない（資格情報形式・ログ要件等はOpen Dataspaceごとに異なるため設定や外部連携として扱う）
共通処理と任意機能を混在させない（相互認証・転送プロセスなど必須処理と、契約処理・仲介機能など任意処理は分離）
複数モーダルのデータ転送方式を前提とすること（API・ストリーミング・バルク転送等）
次章では、本書全体を通じて整理してきた内容を踏まえ、データスペース関連事業参入を検討する開発事業者にとっての考え方を総括する。
第6章 ODS導入企画のプロセス 本章では、ユーザー事業者がOpen Dataspacesを導入する規格プロセスを整理する。 「(1)プロジェクト体制の編成とアーキテクチャ設計 」「(2)実装方針の選択 」「(3)データ取扱の規約 」「(4)データの信頼性の確保 」の4ステップで進める。
6.1 プロジェクト企画と体制の編成 Open Dataspaces導入プロジェクトを立ち上げるにあたり、まず以下を整理する。
導入の目的・目標の明確化（5.1節の課題特定を出発点とする）
社内の関係者（データ管理部門・IT部門・事業部門・法務）の特定と合意形成
外部の関係者（連携先企業・マネージドサービス事業者・開発事業者）の特定
参入パターン（分散型・連邦型・ハイブリッド）の決定（5.2節参照）
主な成果物：
プロジェクト企画書 ：課題の背景・ビジネス上の位置づけ・システム構成方針・法務／コンプライアンス・業務プロセスの定義
役割・責務分担表 ：自社が担う領域とマネージドサービス／開発事業者が担う領域の切り分け
Open Dataspacesの実装パターンとしては、自社開発（パターンA）とサービス利用（パターンB）に大別される。いずれを選択するかの判断材料を提示すべく、以下にそれぞれにつき説明する。
技術リソースがあり、自社でODSプロトコルを実装・運用したい場合のアプローチ。
ODS-RAMを参照した実装であることを確認しながら開発を進める
SDKと参照実装ソフトウェア（ODS Middleware）を活用しつつ、業務固有ロジックは自社開発
ODS Protocols（ODP）を実装した接続・API仕様書・運用手順書
技術者向けの導入手順については「Open Data Spaces技術者向け導入ガイドブック」を参照のこと
自社でODS Protocolsを実装・運用する技術リソースが限定的な場合、またはPoC段階で参入コストを最小化したい場合は、開発事業者（マネージドサービス事業者）が提供するサービスを利用する連邦型モデルが現実的な選択肢となる。
マネージドサービス選定の際は以下の5観点を確認する：
相互運用性 ：ODPが実装・サポートされており、他のプロダクト等と相互運用性があるか
SLA・サポート体制 ：障害対応・プロトコル更新追随・運用支援の体制が自社の要件に合致するか
データ利用制御 ：連邦型においても、自社データとオントロジーの管理・利用制御は自社で制御できるか（データをサービス事業者に集約しない設計か）
Open Dataspacesによる分散データマネジメントでは、信頼できる技術基盤と、それを裏付ける法的なコンプライアンスの両輪が必要である。以下の観点を考慮しながらデータ取扱の規約を整理する。
データ共有契約 ：経済産業省が提供する「データ連携のためのモデル規約」等を参照し、「Open Dataspacesのマネージドサービス事業者」「データ提供者」「データ利用者」三者の役割と権利義務関係を整理する。自社のユースケースに合わせてカスタマイズすることが有効なアプローチ。
利用条件・禁止事項の明文化 ：データ提供者は利用目的・利用期間・二次利用や第三者提供の可否といった利用条件を設定する。知的財産権の帰属・利用条件も事前に契約で明確化すること。
契約締結 ・履行のトレーサビリティ：デジタル契約やスマートコントラクトの活用により、契約締結・履行のトレーサビリティを確保する。
主体やデータの信頼性を確保するためには、認証スキーム(表9)と来歴管理の整理が必要である。
表 9 認証スキーム
来歴管理にあたっては、以下のプロセスで段階的に整理することが有効である：
データ処理フローの可視化：自社が提供・取得するデータの流れ、関与する主体、データが変換・加工される箇所を図示する
リスクの洗い出し：各データ受け渡しポイントにおける主なリスク（情報漏洩・誤用・利用条件違反等）を特定する
認証スキームの選択：自己宣言・相互認証・第三者認証のどの組み合わせが適切かを、コスト・ユースケースの重要度に応じて判断する
来歴管理の実装方針を決定：アクセス・操作・契約・評価の各履歴をどの粒度で記録し後から検証可能にするかを設計する
第5章 ODS導入検討のプロセス 本章では、ユーザー事業者がデータスペース事業への参入可否を判断するための検討プロセスを整理する。 「①自社の課題・ユースケースの特定」「②参入パターンの選択」「③成立性の検証」「④参入の是非判断」の4ステップで進める。
5.1 ステップ1：自社の課題・ユースケースの特定 参入検討は「Open Dataspacesという技術対応」ではなく「自社の事業課題の解決」を起点とすることが重要である。
特に、データマネジメントの世界では「Garbage-in, Garbage-out」と呼ばれるように、目的なくデータを大量に集めても、ランニングコストが消費されるだけで、ROIは悪化する一方である。 このような 「データを集めれば何かいいことが起きる 」という幻想から決別し、課題解決という目的から逆算された必要なデータを収集すること が、プロジェクト成功の鍵を握るだろう。
その際に設定すべき論点として、例えば、表7のような問いで課題を具体化していく必要がある。
表 7 自社の課題を特定する問い
ユーザー事業者の参入戦略は以下の4軸の組み合わせとして整理することができる。これらの軸は独立したものではなく、組み合わせによって参入形態が具体化される。
データ提供者・データ利用者・両方の組み合わせのいずれかを選択する。同じ機能でもどの役割で参入するかで、価値の言語化・責任境界が変わる。
「Where to getの問題（DAD）」「What to meanの問題（OSI）」「Who and How to useの問題（IUC）」のどれが自社の最大のペインかを特定する。
分散型（自社でプロトコルを実装・運用）か連邦型（マネージドサービスを利用）か。初期段階では連邦型が参入コストを下げやすい。
データ提供の範囲・利用条件・SLAを自社で設計するか、マネージドサービスの枠内に収めるかを決定する。
技術的な運用を確認するPoC（Proof of Concept）に加え、「ビジネスとして意味があるか」を検証するPoV（Proof of Value）が不可欠である。 成立性検証のためのステップを表8に示す。
表 8 成立性検証のためのステップ
以下の問いに自社なりの仮説と数値感を持てるかどうかが、本格参入に進むか否かの一つの目安となる。
現在の個別連携コストに対して、Open Dataspaces参入後のコスト削減（Save Money）はどの程度見込めるか
外部データ活用によって生まれる新たな収益・競争優位（Make Money）はどの程度か
参入に必要な初期投資（人的リソース・技術投資・外部サービス利用費）は事業計画上許容できるか
競合他社がデータスペース事業に参入した場合の競争上のリスクはあるか
次章では、参入を決断した後の導入企画プロセスを整理する。
第7章 導入ステージ別の進め方 本章では、ユーザー事業者がデータスペース事業を実際に立ち上げる際の導入ステージを「(1)検討 」、「(2)実証 」、「(3)展開（GTM, Go-to-Market） 」の3段階で整理する(表10)。 各ステージは直線的に進むものではなく、実証結果や外部環境の変化を踏まえながら反復的に進める。
表 10 Open Dataspacesの導入ステージ
第8章 おわりに 本書は、ユーザー事業者がデータスペース関連事業への参入を検討するにあたり、参入の是非・自社が担い得る役割・初期投資の置き方を判断するための視点を整理することを目的として書かれた。
第2章 では産業構造の変化とOpen Dataspacesが求められる背景を整理した。
第3章 ではOpen Dataspacesの基本概念と3本柱（DAD・OSI・IUC）の意義を示し、ユーザー事業者が参入できる4つの参入パターンを整理した。
第8章 おわりに ― AI 時代の分散データマネジメントがもたらす新しい産業像 本書が扱ってきた内容は、Open Dataspacesという新たな分散データマネジメントパラダイムを理解するための概念整理にとどまらず、開発事業者がどのように関連事業に参入し、どの領域で価値を発揮できるかを実務的に整理することであった。
第2章では産業構造の変化とOpen Dataspacesが求められる背景を整理し、第3章でODSの基本概念と3本柱（DAD・OSI・IUC）の意義を示した。 第4章では役割構造とサービスモデルを示し、第5章では参入戦略の4つの整理軸と参入パターンを整理した。 第6章では構築フェーズに向けた考え方を整理し、第7章では検討・実証・展開（GTM）というステージ別の進め方を提示した。 本書が示したのは「万能なアーキテクチャ」でも「唯一の正解」でもない。開発事業者が直面しやすい迷いどころを体系的に整理し、判断のための土台を提供することに焦点を置いた。
Open Dataspacesという言葉は大規模な国家的基盤のような印象を与えがちであるが、実際には個別の主体間の接続や個別PoCの積み重ねによって形成される。 そのため、開発事業者が取り組むべき最初のステップは、自社の強みを反映した小さな構成要素を安定的に提供することである。 インターネットがそうであったように、Open Dataspacesでは「大きなものに参加する」のではなく、各社の小さな成果が集まって大きな構造が形成されるものである。
本書を通じて繰り返し示したのは、「どこまで作るか」以上に「どこまで作らないか」を明確にする重要性である。 運営主体が担う領域、ODS Middlewareが担う領域、他社が補完する領域、自社が実装する領域、将来追加する領域を分け、それぞれの境界を明確にすることが参入の成功を左右する。
第7章で示したように、Open Dataspaces導入は段階的に進む。 自社アセットの棚卸し、担当するビルディングブロックの決定、最小構成PoCの設計と評価など、初期の取り組みはすべて参入行為である。たとえ小規模であっても、PoCの成功はOpen Dataspacesにおける信頼形成の第一歩であり、次の展開につながる実績となる。
AIの高度化により、データへのアクセス、品質、意味的整合性がこれまで以上に重要となった。大量のデータよりも、適切に取り扱われたデータへの継続的アクセスが価値の源泉となる。 Open Dataspacesはその前提を実現するための仕組みである。開発事業者は、データが安全に移動するための技術基盤の整備、意味的整合性や品質を支える仲介機能の提供、利用条件や契約の制約を技術的に反映する仕組みの実装、Open Dataspacesを利用するアプリケーションの開発、という役割を担う。
自社内部スキーマで管理し、意味と構造が一体化しやすい
構造から意味（セマンティクス・オントロジー）を分離して扱う（OSI）
アイデンティティ、アクセス、利用条件を明示的に扱う（IUC）
複数事業者とデータを相互交換し、サプライチェーン・品質管理・トレーサビリティを実現する
業務効率化・リスク低減（Save）／業界標準への準拠・ブランド価値向上（Make）
ODP対応のマネージドサービスやアプリケーションをユーザーとして利用する
ICPとビジネスモデルの策定、参入パターンの選択、提供機能の特定
開発環境での動作検証、相互運用性の検証、価値仮説（バリュープロポジション）と運用負荷の検証、ビジネスモデルの検証
プロダクト設計、SLAとプライシングモデルの策定、GTMモーションとKPIの決定、本番環境でのサービス提供
7.2 検討ステージ：参入可否と構築スコープの整理 段階的な移行可能性 ：連邦型から分散型へ将来移行する際の交換可能性・ベンダー依存度
プライシングモデル ：利用者数・データ量・機能に応じた料金体系が自社の事業計画と整合するか
保証と責任 ：データ提供者は提供するデータが第三者の権利を侵害しておらず適法に取得されたものであることを保証する一方、データの「正確性」や「完全性」については保証しない（as-is提供）とするのが通例。
外部認証機関による認証。業界標準・規制対応が必要な場合や、より高いトラスト要件が求められる場合に検討する
利用ルールに従うことを自社で宣言する。参入初期・PoC段階に適用しやすい
相手の信頼レベルを評価・確認する。連携先との合意に基づき設定する
パターンA）ODS SDK（ソフトウェア開発キット）とOSSを活用した自社開発
そもそも、ビジネス・オペ―レーション上の何の課題を解決するために、データを連携するのか？
現在のビジネスモデルが直面する脅威と機会、個別組織・個社単位で個別最適化はされているが全社・サプライチェーン単位で見ると最適化されていないオペレーション、データサイロ
今、外部データとの連携において何が障害となっているか？
個別API連携の調整コスト、データ品質の不透明性、利用条件の整合困難
新規収益源、パートナーシップ強化、業界標準への準拠
AI活用・BI/DIに必要なのに使えていないデータは何か？
サプライチェーン上流データ、外部統計・市場データ、リアルタイム環境データ等
現在の個別連携で積み上がっているコスト・手間はいくらか？
PoC 最小構成（MVP）でデータ連携が技術的に成立するか。
ODS SDKやマネージドサービスでPoC環境を構築し確認する
コスト削減効果・価値創出効果によるROI。リードタイムの改善。外部データのAI活用上の有用性
5.2 ステップ2：参入パターンの選択（4軸で整理） （2）優先するペインへの対処：どの課題をOpen Dataspacesで解決するか （4）責務範囲（SLA）：どこまでを自社の責任として引き受けるか 第4章
ではOpen Dataspacesにおける参加者の役割と自社の立ち位置を整理し、
第5章
では参入判断の4ステッププロセスを示した。
第6章 では導入企画のプロセスを、第7章 では検討・実証・展開（GTM）の3ステージを整理した。
本書が示したのは「万能なアーキテクチャ」でも「唯一の正解」でもない。 ユーザー事業者が直面しやすい迷いどころを体系的に整理し、判断のための土台を提供することに焦点を置いた。
本書を通じて繰り返し示したのは、「どこまでやるか」以上に「どこまでやらないか」を明確にする重要性である。 自社が担う領域・マネージドサービスが担う領域・連携先が担う領域・将来追加する領域を分け、それぞれの境界を明確にすることが、過大な初期投資を避け継続的な参入を可能にする。
開発事業者とは異なり、ユーザー事業者にとっての参入の第一歩は、Open Dataspaces対応のマネージドサービスやアプリケーションを「使う」ことから始まる場合が多い。 技術実装以前に、「データを提供するとはどのような行為か」「どのような条件や責任が伴うのか」を理解することが重要な前提となる。
Open Dataspacesは複雑に見えるが、本質は接続・調整・補完というシンプルな営みの集合である。ユーザー事業者が最初の一歩を踏み出すために必要なのは次の3点である：
初期段階で全てを自社実装しようとせず、マネージドサービスを活用して小さく進めること
連携先との接続を通じて学習し、段階的に参入範囲を拡大すること
本書が、みなさんの検討や準備を支える一助となり、Open Dataspacesを活用した新たなデータ連携・データ活用の可能性を見いだす契機となれば幸いである。
8.2 「どこまでやらないか」を決めることが参入の成功を左右する 8.3 ユーザー事業者としての参入は「使う」ことから始まる Open Dataspacesは複雑に見えるが、本質は提供・利用というシンプルな営みの集合である。開発事業者が最初の一歩を踏み出すために必要なのは次の三点である：
初期段階で全てを実装しようとせず、小さく進めること
他主体との接続を通じて学習し、段階的に拡張すること
本書で示した考え方やステップは、迷いを減らし、最初の接続や初期PoCを現実的に進めるための支援を目的としている。Open Dataspacesは、誰かが一括して構築する巨大基盤ではなく、参加する主体の取り組みが積み重なって形成されるエコシステムである。 本書が、みなさんの検討や準備を支える一助となり、Open Dataspaces活用の可能性を見いだす契機となれば幸いである。
8.2 Open Dataspacesは接続の積み重ねである 第5章のプロセスに基づく課題特定・参入パターン選択・PoC範囲の定義
マネージドサービスまたはSDKによるPoC環境構築・技術/事業/運用成立性の検証
本番環境への移行・SLAとプライシングの確定・KPIの継続運用
第5章で整理した参入パターンを前提として、「何をするか・何をしないか」を構築スコープとして具体化するフェーズ。 本フェーズにおいて考慮すべき観点を表11に示す。
最小構成（MVP）で「技術・事業・運用が成立するか」を確認する。 完成度を上げることが目的ではなく、外部と整合が必要な領域と自社の任意領域が分離された設計で、運用まで含めて回る見通しを得ることが目的である。 本フェーズにおいて考慮すべき観点を表12に示す。
実証ステージで確認した成立性を前提として本番環境へ移行する。 単発のPoCの成功ではなく、標準仕様の更新・運用要件の変化・連携先の拡張に耐えられる構造を備えているかが問われる。 本フェーズにおいて考慮すべき観点を表13に示す。
導入可否の判断を支援する実施チェックリストを表14に示す。
7.1 検討ステージ：参入可否と構築スコープの整理 7.3 展開ステージ（GTM）：本実装と持続運用への移行 参考文献 独立行政法人情報処理推進機構. (2026). Open Data Spaces Reference Architecture Model.
Dehghani Z. (2019). How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.
Dehghani Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O’Reily Media.
Franklin M, Havely A, Mayer D. (2005). From databases to dataspaces: a new abstraction for information management.
Halevy A, Franklin M, Mayer D. (2006). Principle of dataspace systems.
NEDO. (2025). "データスペース市場規模調査及びインパクトモデリング・シナリオ分析 調査報告書". [https://www.nedo.go.jp/content/800039315.pdf]
独立行政法人情報処理推進機構, 経済産業省.(2025). Whitepaper: ウラノス・エコシステム・データスペーシズ リファレンスアーキテクチャモデル (ODS-RAM).
Tsuda M. (2026). Why Open Dataspaces: 設計思想とアーキテクチャパラダイム. 独立行政法人情報処理推進機構.
第2章 ODS-RAM、ODS Protocolsの把握 本章では、Open Dataspacesの参照アーキテクチャモデルである「ODS-RAM（Open Data Spaces Reference Architecture Model）」で示される指針を前提として、Open Dataspaces技術を実装する立場の読者が「何を実装すべきか」を整理する。
Open Dataspacesは、単にデータを共有・公開するための仕組みではなく、複数の企業・組織に分散するデータを「信頼を保ったまま」マネジメントできることを目的としている。 Open Dataspacesでは、特に以下A～Eの要素が重視される。設計思想の詳細は、Design Philosophyを参照されたい。
Open Dataspacesでは、データが特定の主体に集約的にマネジメントされることを前提としない。データは各企業・組織のドメインの管理下に留まり、必要な範囲・条件のもとProduct（商品）として提供される。特定の主体への集中管理は前提としない。（参照：Design Philosophy第3章、第4章）
Open Dataspacesでは、「データの構造・値（データモデル）」と「データの意味（情報モデル）」を明示的に分離し、ドメイン由来のコンテクスト（文脈）をオントロジーで制約することで、データ利用者の推論を可能にする。（参照：Design Philosophy第5章）
Open Dataspacesでは、データとオントロジーのエンドポイントをグローバルで識別可能、探索可能な形で設計・公開する。（参照：Design Philosophy第6章）
Open Dataspacesでは、「誰がデータにアクセスできるか」「その相手を信頼できるか」「どの条件でデータを提供・利用できるか」「この取引が正しく行われたと言えるか」を設計対象とする。信頼・セキュリティ・権利義務関係の非対称性を明示的に扱う。（参照：Design Philosophy第7章）
Open Dataspacesでは、異なる企業・組織・法域を横断した接続を実現するため、依拠すべきプロトコルが「ODS Protocols（ODP）」として規定されている。特定ベンダ・製品・法制度体系に依存しない設計が原則。（参照：Design Philosophy 第3章）
Open Data Spaces 技術者向け導入ガイドブック 「Open Data Spaces（ODS）」は、国や組織ごとの多様性を尊重する、オープンでスケーラブルな分散データマネジメントの技術コンセプトの名称である。 また、本書で利用する一般名称としての「Open Dataspaces」は、米国のデータスペース原著論文（Franklin et al., 2005; Halevy et al., 2006）及びデータメッシュ（Dehghani, 2019; Dehghani 2022）を中核として、民間企業・団体と連携した研究開発・商用水準での検証を経ながら設計された新世代の分散データマネジメント技術及びそれを構成する概念を指す。
本書は、ODSを参照しながら、実際にOpen Dataspaces技術を実装・提供する事業者・技術者を対象に、最初の構築・運用に着手するための考え方と最小構成を整理することを目的とする。
続きを読む：
Open Data Spaces 技術者向け導入ガイドブックの著作権は、IPA、METI、NEDOに帰属します。なお、本ガイドブックは、NEDO「ウラノス・エコシステムの実現のためのデータ連携システム構築・実証事業」における成果を基にIPAにて編纂・取り纏めたものです。
本ドキュメント（Open Data Spaces 技術者向け導入ガイドブック）は、Creative Commons Attribution 4.0 International (CC BY 4.0) の下で提供されます。
ライセンス全文:
第3章 システム構成例 本章では、ODSのアーキテクチャを実装するパターンとして、代表的な2つのサービスモデルとシステム構成例を示す。
分散型サービスモデル ：ドメインオーナー自身がSelf-Serve Data Platformを構築し、DPQMに基づくData/Ontology Productを提供するという方式
連邦型サービスモデル ：DPQMを構成する基本的なソフトウェアスタックをマネージドサービス事業者に代理で提供してもらいながら、ドメインオーナーとして、Data/Ontology Productの提供に責任を持つという方式
分散データマネジメントをどのようなサービスモデルで実装するかは、「どの機能を、どの主体が、どの範囲で提供するか」によって構成が変わる。
分散型サービスモデルでのシステム構成例を図1に示す。
第1章 はじめに 「ODS技術者向け導入ガイドブック（本書） 」は、ODSを採用・導入またはサービス提供する立場にある技術者を対象に、その技術的な全体像と基礎を理解し、設計・実装・運用に着手するための最初の指針を示すことを目的とする。
ODSは、企業や組織を横断してドメイン駆動でデータを共有・制御・利用するためのオープンなアーキテクチャパラダイムであり、単なるシステム構築だけではなく、技術・コンプライアンス・ビジネスを念頭に置いた導入が必要である。そのため、企業には「どの技術を使うか」以前に、何を実装し、どこまでを担い、どこからを他者に委ねるのかという判断が不可欠となる。本書 は、個別仕様や実装手順を解説する技術書や手順書ではなく、実装判断に必要な概念理解と検討視点を提供することに主眼を置く。
従って、本書は、ODSの全体像を導入またはサービス提供する企業の視点で理解し、Open Dataspaces技術の採用に向けた「設計と実装に踏み出すための入口」となることを目的としている。
本書でいう「技術者 」とは、データマネジメントやAIに関わる技術の採用・導入、企画を検討する幅広いペルソナである：
ODSの導入を担う事業者のアーキテクト、技術責任者
データ提供先・利用先・マネージドサービス提供事業者との責務分界を整理する
Save Money / Make MoneyのKPIを定義し、PoV時の価値仮説を本番環境で継続検証する
SDK or マネージドサービスでPoC環境が構築・動作確認できているか？
価値仮説と数値感を持てているか？（Save Money / Make Moneyの仮試算）
データ利用規約・参加条件・責任分界が整備または合意されているか？
認証スキーム（自己宣言・相互認証・第三者認証）の選択と来歴管理方針が決定しているか？
本番稼働に向けた社内体制（担当者・予算・更新対応プロセス）が確立しているか？
Open Dataspacesは、ドメインオーナー自身がSelf-Serve Data Platformを構築し、DPQMに基づくData/Ontology Productを提供するという方式である「分散型サービスモデル 」と、DPQMを構成する基本的なソフトウェアスタックをDSSP（Dataspace Service Provider）である仲介者（Intermediary）に代理で提供してもらいながら、ドメインオーナーとして、Data/Ontology Productの提供に責任を持つ方式である「連邦型サービスモデル 」の２つの実装パターンを想定する。
なお、連邦型サービスモデルにおいても、データ及びオントロジーはあくまでデータ提供者が責任を持ち、その利用制御を行うことを前提とする。
本節では、ODS-RAMを構成する要素を、ODPの整理に基づいて「ファンダメンタルプロトコル 」「コンプリメンタリプロトコル 」に分類し、それぞれが何を成立させるための機能かを概要として示す。
ファンダメンタルプロトコルは、Open Dataspacesを実現するための主要な機能を提供するための取り決め。対応するレイヤ・パースペクティブの機能を実現するために採用しなければならないプロトコルであり、下記のものがある。
共通機能(Common Functionalities)
Versioning ：仕様・設定・コンポーネントの変更を管理し、参加者間で同じ前提のもと相互運用性を維持するための機能
Logging ：通信ログ、サービスログ、処理ログの3つのカテゴリに基づき、システムの通信状況、各サービスの処理結果、全体の監視・運用状況を包括的に記録・分析可能とする機能
Monitoring ：システムのログから実行環境やサービスの稼働状況を把握し、システムの健全性やパフォーマンスを継続的に監視・管理する機能
Notifier ：データトランザクションに関する更新・受領状況を、データ提供者と利用者間で共有するための情報通知機能
Usage Control ：データ提供者が提供範囲・保存／利用条件・責任境界を自己決定できる状態を成立させるインターフェース機能（Usage Controlそのものの機能は含まない）
Data Trust Assessment ：データの完全性／非改竄性の評価・算定を成立させるインターフェース機能（完全性／非改竄性の評価・算定そのものの機能は含まない）
Data Trustworthiness and Quality Assessment ：データ品質／信頼性の評価・算定を成立させるインターフェース機能（品質／信頼性の評価・算定そのものの機能は含まない）
Transaction ：エンドポイントとプロセス制御、データ転送を担い、各レイヤの結節点としてトランザクションを成立させる機能
Identity and Trust ：参加主体を識別し、正当な主体同士、かつ正当なリソースへの権限でのみデータ交換が成立する信頼の前提を提供する機能
Metadata Exchange ：データの所在や意味に関するメタデータを連携し、分散環境でのデータ発見性と意味判断を成立させる機能
Discovery and Search ：メタデータをもとにした探索・検索の高度化機能
コンプリメンタリプロトコルは、Open Dataspacesを実現するための補完的な機能を提供するための取り決め。対応するレイヤ・パースペクティブの機能を実現するために、必要に応じて採用してもよいプロトコルであり、下記のものがある。
Heuristic Contracting ：サードパーティの電子契約アプリケーションを通じて利用条件・契約条件の定義・合意形成を支援するインターフェース機能（契約そのものの機能は含まない）
Clearing and Payment ：サードパーティの電子決済アプリケーションを通じてデータ取引の実績を記録・照合して精算・課金／決済するインターフェース機能（精算・課金／決済そのものの機能は含まない）
A. 分散データマネジメント（Distributed Data Management） B. セマンティクスとオントロジー（Semantics and Ontology） C. データの特定可能性と探索可能性（Data Addressability and Discoverability） D. アイデンティティと利用制御（Identity and Usage Control） E. 相互運用性（Interoperability） 2.3.1 ファンダメンタルプロトコル(Fundamental Protocols) 2.3.2 コンプリメンタリプロトコル(Complementary Protocols) 分散型サービスモデルでは、データ提供者・データ利用者の双方が、分散データマネジメントを成立させるために必要な機能をそれぞれ保持する。
典型的には、以下の要素が参加者（データ提供者・データ利用者）側に配置される。機能詳細は、ODPを併せて参照いただきたい。
Identity and Trust、Credential Service
Transaction（コントロールプレーンオーケストレータ、データプレーンモジュール）
Heuristic Contracting、Clearing and Payment（オプション）
連邦型サービスモデルでのシステム構成例を図2に示す。
連邦型サービスモデルでは、ODS Middlewareがデータ提供者側にDSSPとして配置される。DSSPは、参加者が個別に整備するには負担が大きい領域を補い、参加者が「データを提供・利用する」ことに集中できる状態を作ることができる。
ODS-RAMにおいて、それぞれのレイヤは互いに独立しており、疎結合する形で一連の分散データマネジメントに係る機能を果たす。そのため、ドメインが有する性質・特性に応じて、必要となるレイヤ数を選択的に決定することができる。 例えば:
ある横断的なドメインにおけるデータの宛先及び意味が明白な場合、Ontology Product（L4～L2で構成されるセットの実装）を省略して、L3～L1でまずはData Productを先行実装しても構わない。
上記の連邦型サービスモデルの構成で言えば、L3：Identity and Trust、Credential Service、L2：Transactionの実装と、L1：Data Store、インダストリサービスを先行実装しても良い。
ODPの実装においては、Save Money, Make Money を基調とする市場の要求に応じて、オプトインできることに配慮した、必要最小限（Minimal Yet Viable）な設計を重視 している。これを実現するため、プロトコルは疎結合に構成され、後方互換性を設計段階でビルトインしている。 本章で示した２つのサービスモデルを構成するコンポーネントは、市場の特性や成熟度に応じて選択され、段階的に導入、拡張していくものと考えていただきたい。
第4章 は、ODS SDK for Onboardingが提供するデプロイ定義ファイルを使って、参加者同士でのデータ交換を実施できる最小構成の構築手順を示す。構築の対象は、L3、L2、L1、Logging、Clearing and Payment（オプション）である。
第5章 は、ODS SDK for Semanticが提供する、SAMMによるセマンティック定義（Aspect Modelファイル、WebサービスAPI定義ファイル、インスタンスファイル）の作成方法と、Discovery Serviceへの登録方法、SDKの使い方と環境構築手順を示す。
ODSを活用した分散データマネジメントサービスを実装しようとするソフトウェア企業、その技術部門のアーキテクト、技術責任者
ODSの技術に触れてみたい開発者、学術関係者、学生など
本書では、技術者がODSの採用・導入に着手するために必要な内容に焦点を当てる。高度な設計や運用を含む詳細な専門領域については扱わない。
技術仕様の解説やOSS（オープンソースソフトウェア）の導入手順、SDK（ソフトウェア開発キット）の利用方法
特定製品・特定ベンダーが提供するサービスに関する対応や実務
法制度に関する対応や、法務やガバナンスに関する実務
本書は、事業者の実務者がODSの採用・導入に着手するために必要な理解を、段階的に深められるよう構成している。各章で下記の内容を取り上げているので、読み進めて頂きたい。
第2章 ：ODS-RAM（Open Data Spaces Reference Architecture Model）と、ODS Protocols、主要コンポーネントの位置づけを把握する
第3章 ：代表的なシステム構成例を通じて、実装・運用のイメージを持つ
第4章 ：デプロイと初期設定の手順を通じて、SDKを触り始めるための入口を掴み、運用開始に向けた初期設定と基本手順を理解する（Data as a Product編）
第5章 ：デプロイと初期設定の手順を通じて、SDKを触り始めるための入口を掴み、運用開始に向けた初期設定と基本手順を理解する（Ontology as a Product編）
Open Data Spaces Reference Architecture Model (ODS-RAM) 2. アーキテクチャ Architectural Quanta（AQ）とは、分散データマネジメントにおけるアーキテクチャの最小の構成単位である。Open Dataspacesでは、データメッシュのAQであるData Productの相互運用性の問題を解決するため、Data Productと表裏一体の関係性である「Ontology Product」という概念を新たに導入し、Data ProductとOntology Productを併せて構成単位のAQとする 。Open Dataspacesにおいて導入されたこのAQのパラダイムをDouble-Product Quanta Model （DPQM ）と呼称している（図1）。
Double-Product Quanta Model（DPQM） 図 1 Double-Product Quanta Model（DPQM）
ODS-RAMは、アーキテクチャの最小単位として定義されたDPQMを機能別に分割した4つのレイヤ、4つのパースペクティブで構成される ：
図 2 DPQMとレイヤ、パースペクティブの関係性
4. パースペクティブ 「パースペクティブ（Perspectives） 」はOpen Dataspacesにおいて横断的な機能を果たす論理的な視点である。ODS-RAMは、「①サービス（Service） 」、「②ガバナンス（Governance） 」、「③セキュリティ（Security） 」、「④トラスト（Trust） 」の4つのパースペクティブで構成される。
ODS-RAMにおいて、それぞれのパースペクティブは互いに連関しており、一連の分散データマネジメントのすべての局面で影響を及ぼすものである 。
サービスパースペクティブは機能及びオペレーションを包含するテクニカルな領域と、ビジネス領域を橋渡しするパースペクティブである。
Open Dataspacesのアーキテクチャを実装する最もオーソドックスな方法は、（1）ドメインオーナー自身がSelf-Serve Data Platformを構築し、DPQMに基づくData/Ontology Productを提供するという方式 （「分散型サービスモデル」と呼称 ）である。しかし、これは大きなデジタル財源を持ち、自前で環境構築と運用を賄える大企業などで成立する話である。例えば、中小企業はドメインオーナーとして、規律準拠のための機能を自身で提供する企業体力がないことが多く、導入上の課題を抱えている。
そこで、（2）DPQMを構成する基本的なソフトウェアスタックをマネージドサービス事業者に代理で提供してもらいながら、ドメインオーナーとして、Data/Ontology Productの提供に責任を持つ、という方式 （「連邦型サービスモデル」と呼称 ）も想定した。Open Dataspacesでは、このコア技術のマネージドサービスを提供する仲介事業を、Classical Dataspacesで利用されていた用語に擬えて、「
第4章 システム構築・運用構築手順（Data as a Product編） 本章では、ODS SDK for Onboarding（以下SDK）が提供するデプロイ定義ファイルを使って、参加者同士でのデータ交換を実施できる最小構成のシステム構築・運用構築手順を示す。
本章で構築するシステム構成は図3の通りである。四角形がコンポーネントもしくはサービス、矢印はそれらの間の依存関係を表す。
図 3 SDKが提供するシステム構成
なお、本SDKではRDBMSとしてPostgreSQL、認証システムとしてKeycloak、ReBAC認可システムとしてOpenFGAを用いる。 また以降では、アイデンティティコンポーネント・Web API転送モジュールを、それぞれ単にL3・L2と呼称する場合がある。
SDKでは、各サービス用のデプロイ定義ファイルを集約したファイルを提供しており、これを用いてすべてのサービスを一括で起動・停止することができる。 以下に Docker Compose 版の使用方法を示す。
SDKのリポジトリをローカルに clone する。
Clone してきたディレクトリ内に移動し、L2、L3、精算・課金／決済サービスのリポジトリを clone する。
リポジトリのトップレベルに配置されている docker-compose.yml ファイルを使って Docker Compose を実行し、すべてのサービスを起動する。
ODS-RAMをもとに分散データマネジメントを実現する機能を提供し、Open Dataspacesの相互運用性を担保する一連の技術的な取り決め
ODS 事業者向け参入ガイドブック（開発事業者向け）
ソフトウェアやデータ関連サービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理
ODS 事業者向け参入ガイドブック（ユーザー事業者向け）
データマネジメントやAIサービスを利用または自社で実装する立場にある事業者の実務者・経営企画担当者が、データスペース事業への参入を検討する際に、参入の是非・自社が担い得る役割・初期投資の置き方を判断するための視点を整理
用語集 アイデンティティレイヤ（Identity Layer: L3） 認証の問題及び認可の問題を解決するレイヤ。
インダストリーサービス（Industry Service：IS） それぞれの産業や業界ユースケースに特化したビジネスアプリケーションやビジネスプラットフォーム等を提供するもの。
Open Data Spaces（ODS） 国や組織ごとの多様性を尊重する、オープンでスケーラブルな分散データマネジメントの技術コンセプト。
Open Data Spaces プロトコル（ODS Protocols：ODP） 分散データマネジメントを実現する機能を提供し、Open Dataspacesの相互運用性を担保する一連の技術的な取り決め。
エンタープライズデータ（enterprise data） 事業者が経済活動のために生成・取得、加工・利用、移転・提供、保管、破棄するあらゆるデータ（構造化・非構造化を問わない）の総称。
開世界仮説（Open World Assumption：OWA） ある情報が知識ベースに存在しない場合、その情報は「真でも偽でもない（未知）」と見なす考え方。RDF/OWLなどセマンティックWeb技術での前提。
ガバナンスパースペクティブ（Governance Perspective: P2） エコシステムにおいて特定の目的を達成するために共通ルールやポリシー等を定め、横断的な管理・監督・運営等を行うパースペクティブ。
共通機能（Common Functionalities） データスペース間の相互運用性を確保するための基本的なプロトコルを包含するもの。バージョンニング、ロギング、モニタリング、ノーティファイア等が該当する。
共通メタ識別子（unified meta identifier：UMI） 事業者・業界等の中で個別最適化され、それぞれ異質なものとして存在している識別子体系を抽象化する形で策定されるもの。
コアサービス（core services） DFSの中でも、特にL1～L4それぞれのレイヤにおいて中核的役割を果たすコアコンポーネントをマネージドサービスとして提供するものをいう。
構造化データ（structured data） Web APIのリクエスト/レスポンスデータやデータベース転送、メッセージキューなどの形式化されたデータ。システムによる読み取りを前提とし、スキーマの構造優先で、Open APIやAsync API等による明確な型定義に基づく。
後方互換性（backward compatibility） 同じ系列の新しい手段が、古い手段の仕様や機能を包含している（互換性がある）状態のこと。
コンプリメンタリプロトコル（Complementary Protocol） Open Dataspacesを実現するための補完的な機能を提供するための取り決めであり、対応するレイヤ・パースペクティブの機能を実現するために、必要に応じて採用してもよいプロトコル
サービスパースペクティブ（Service Perspective: P1） 機能及びオペレーションを包含するテクニカルな領域と、ビジネス領域を橋渡しするパースペクティブ。
参照実装（reference implementation） 何らかの機能を実現するハードウェアまたはソフトウェアであり、他者がそれを参考にして独自に実装することを助ける目的で作られたもの。
信頼性あるデータの自由な流通（Data Free Flow with Trust） プライバシーやセキュリティ、知的財産権に関する信頼を確保しながら、ビジネスや社会課題の解決に有益なデータが国境を意識することなく自由に行き来する、国際的に自由なデータ流通の促進を目指すというコンセプト。
スキーマファースト（schema-first） 予めスキーマを定義しておき、定義に合うようにデータを入力する方法論。
スキーマフレキシブル（schema-flexible） 事前定義されたスキーマがない、または複数の異なる事前定義されたスキーマがあることを前提に、データが読み取られる場合にのみ、メタデータ等に基づき解析が実行され、必要に応じてスキーマに適合する方法論。
セキュリティパースペクティブ（Security Perspective: P3） エコシステムにおいて全体的または部分的に要求されるセキュリティ要件及び対策を示すパースペクティブ。
セキュリティ・バイ・デザイン（security by design） セキュリティを企画・設計段階から確保するための方策。
セマンティクスレイヤ（Semantics Layer: L4） 宛先の問題及び意味の問題を解決するレイヤ。
仲介者（Intermediary） データ提供者及びデータ利用者が自前で環境構築と運用を賄えない場合に、DSSPとしてマネージドサービスを提供する主体。
DSSP（Dataspace Service Provider） 仲介者（Intermediary）がドメインオーナーに代わって提供するDPQMの基本的なソフトウェアスタックのマネージドサービス。
データスペースコンプリメンタリサービス（Dataspace Complementary Services：DCS） ODPで定めるコンプリメンタリプロトコルの要件を実現する際に、それらに求められる機能の技術実装等をマネージドサービスとして提供するものをいう。
データスペースファンダメンタルサービス（Dataspace Fundamental Services：DFS） ODPで定めるファンダメンタルプロトコルの要件を実現する際に、それらに求められる機能の技術実装等をマネージドサービスとして提供するものをいう。
データ提供者（data provider） データを提供し、データに係る利用制御を行使する主体。データの利用の許諾に際して適用されるべき保存・利用条件等に関する自己決定を行う。
データ利用者（data user） データを利用する主体。データ提供者による自己決定を遵守し、データ提供者が設定する保存・利用条件の範囲内でデータを取得、保存、利用する。
データレイヤ（Data Layer: L1） データに係る利用制御の問題、データ改竄の問題及びデータ品質の問題を解決するレイヤ。
同期処理（synchronous processing） APIリクエスト/レスポンスなど外部呼出しの結果を受信するまで待機する通信。指定されたデータの送受信が完了した時点で処理を終了する。
トラストパースペクティブ（Trust Perspective: P4） エコシステムにおいて全体的または部分的に要求されるトラスト要件及び対策を示すパースペクティブ。
トランザクションコンポーネント（transaction component） データ提供者がデータの送信にあたって使用するトランザクションレイヤ（L2）のコアコンポーネント。
トランザクションレイヤ（Transaction Layer: L2） 形態の問題、要求の問題及び手段の問題を解決するレイヤ。
ノーティファイア（Notifier） データトランザクションに関する更新・受領状況を、データ提供者と利用者間で共有するための情報通知機能。
Hybrid Service Model（HSM） 分散型サービスモデルと連邦型サービスモデルの混成形態。Domain Ownerが緩やかな規律に自らOnboardすることと、DSSPの仲介を経てOnboardする方式の両方が存在するサービスモデル。
バージョニング（Versioning） 仕様・設定・コンポーネントの変更を管理し、参加者間で同じ前提のもと相互運用性を維持する機能。
パースペクティブ（Perspectives） Open Dataspacesにおいて横断的な機能を果たす論理的な視点。ODS-RAMは、「①サービス（Service）」、「②ガバナンス（Governance）」、「③セキュリティ（Security）」、「④トラスト（Trust）」の4つのパースペクティブで構成される。
非構造化データ（unstructured data） 画像、動画、音声、図面、ログデータなどフォーマットが多様なデータ。固定的なスキーマに縛られない自由な構造を持つ。
非同期処理（asynchronous processing） バッチ処理、ファイル転送、ストリーミングなど、外部呼出しの結果を待たずに処理を継続し、コールバック等を通じて結果を受信する通信。受信側は呼出し側が処理を停止するまでデータの受信を継続する。
ファンダメンタルプロトコル（Fundamental Protocol） Open Dataspacesを実現するための主要な機能を提供するための取り決めであり、対応するレイヤ・パースペクティブの機能を実現するために採用しなければならないプロトコル。
閉世界仮説（Closed World Assumption：CWA） ある情報が知識ベースに存在しない場合、その情報は「偽」と見なす考え方。RDBなど、一般的なDBMSの前提。
モニタリング（Monitoring） システムのログから実行環境やサービスの稼働状況を把握し、システムの健全性やパフォーマンスを継続的に監視・管理する機能。
レイヤ（Layers） DPQMを機能目的に応じて論理的な階層に分離するものである。ODS-RAMは、「①データ（Data）」、「②トランザクション（Transaction）」、「③アイデンティティ（Identity）」、「④セマンティクス（Semantics）」の4つのレイヤで構成される。
連邦型サービスモデル（federated service model） DPQMを構成する基本的なソフトウェアスタックをDSSP（Dataspace Support Service）として仲介者（Intermediary）に代理で提供してもらいながら、ドメインオーナーとして、Data/Ontology Productの提供に責任を持つ方式。中小企業等の自前でのシステム整備・運用が難しい事業者の参入を支援する。
ロギング（Logging） 通信ログ、サービスログ、処理ログの3つのカテゴリに基づき、システムの通信状況、各サービスの処理結果、全体の監視・運用状況を包括的に記録・分析可能とする機能。
参考文献 Dehghani Z. (2019). How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.
Dehghani Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly Media.
Franklin M, Halevy A, Maier D. (2005). From databases to dataspaces: a new abstraction for information management.
Halevy A, Franklin M, Maier D. (2006). Principles of Dataspace Systems.
第5章 システム構築・運用構築手順（Ontology as a Product編） ここでは、ODS SDK for Semantic（以下SDK）が提供する、SAMM(Semantic Aspect Meta Model)によるセマンティック定義の作成方法と、Discovery Serviceへの登録方法、SDKの使い方と環境構築手順を示す。 詳細はSDKのドキュメント を参照のこと。
Dataspace Service Provider（DSSP）
」と呼称する。
なお、Open Dataspacesでは、このようなドメインオーナーがプロトコルに自らオンボードすることと、DSSPの仲介を経てオンボードする方式の混成を「Hybrid Service Model（HSM） 」と呼称している（図3）。
ODS-RAMにおいてサービスは、「データスペースファンダメンタル（Dataspace Fundamental） 」、「データスペースコンプリメンタリ（Dataspace Complementary） 」及び「インダストリー（Industry） 」の3つの形態に分類される。
A. 「データスペースファンダメンタルサービス（Dataspace Fundamental Services） 」（以下、「DFS」という。）は、ODPで定めるファンダメンタルプロトコルの要件を実現する際に、それらに求められる機能の技術実装等をマネージドサービスとして提供するものをいう。
B. 「データスペースコンプリメンタリサービス（Dataspace Complementary Services） 」（以下、「DCS」という。）は、ODPで定めるコンプリメンタリプロトコルの要件を実現する際に、それらに求められる機能の技術実装等をマネージドサービスとして提供するものをいう。
C. 「インダストリーサービス（Industry Service） 」（以下、「IS」という。）はそれぞれの産業やドメインユースケースに特化したビジネスアプリケーションやビジネスプラットフォーム等を提供するものをいう。基本的に、AIやBI（Business Intelligence）、DI（Decision Intelligence）など既存のビジネスで提供されているアプリケーションサービスがインダストリーサービスに相当する。
ODS-RAMで想定するサービス群は図4のように整理される。これらは網羅的ではない が、DFS及びDCSで特に典型的なものを、本節では定義する。サービスを提供するにあたり実装が必要となる技術仕様についてはプロトコルに、ガバナンス、トラスト及びセキュリティの考え方については、P2～P4のパースペクティブに示されるもの である。
A. 「コアサービス（Core services） 」は、DFSの中でも、特にL1～L4それぞれのレイヤにおいて中核的役割を果たすコアコンポーネントをマネージドサービスとして提供するものをいう。ODS-RAMにおいては、セマンティクスコンポーネント、アイデンティティコンポーネント、トランザクションコンポーネント、データストア等のコアコンポーネントについて、利用者が合意した規約・約款等に基づく契約関係の範疇において、サードパーティがこれらのマネージドサービスを提供することを許容する。
B. 「セマンティクスモデリングサービス（Semantics modeling service） 」は、L4においてセマンティクス提供者が公開するメタモデルの設計ならびに当該モデルのデータへの付与等をサービスとして提供するものをいう。
C. 「ディスカバリーサービス（Discovery and search service） 」は、L4においてエンドポイントを発見及び検索するための機能を提供するものをいう。
D. 「クレデンシャル発行サービス（Credential issuing service） 」は、L3においてクレデンシャルの発行をサービスとして提供するものをいう。
A. 「発見的契約サービス（Heuristic contracting service） 」は、新たにエンドポイントを発見したサービス利用者が、サービス提供者と自身で又はサードパーティの契約サービスを活用して電子的に新規契約するための機能を提供するものをいう。
B. 「精算・課金／決済サービス（Clearing and payment service） 」は、データスペースのサービス利用者及びサービス提供者双方に対してサービス提供者自身で又はサードパーティとして精算及び決済・課金の機能を提供するものをいう。
C. 「売買サービス（Marketplace service） 」は、データ提供者とデータ利用者を仲介する形でサードパーティが、あるいはデータ提供者またはデータ利用者がデータの売買に係る機能を提供するものをいう。
ガバナンスパースペクティブは、エコシステムにおいて特定の目的を達成するために共通ルールやポリシー等を定め、横断的な管理・監督・運営等を行うパースペクティブである。
Open Dataspacesは、特定の法域の制度や規制体系に依存しない設計 を原則としている。これは、Open Dataspacesが国・地域・業界を横断した分散データマネジメントを対象とする以上、いかなる単一の法制度体系や関連する法的要件をプロトコルに組み込んでしまうことも、参加者を制度的に拘束し、グローバル市場での参入障壁を生む「制度的ロックイン（Regulatory Lock-in） 」に陥る危険を孕むためである。従って、ODPはそれ自体として特定の法的義務への対応や、テクノリーガルな要件を課するものではない。
ただし、制度ロックインを回避した設計であることは、ODS-RAMが法令遵守の責任を免除することを意味しない。例えば、ODS-RAMでは法務的、技術的に実在する様々な利用制御をサポートするため、電子契約行為に関連するプロトコル（Heuristic Contracting Protocol）を選択的な方式として、そのインターフェースを用意するところまでを責任所掌としている。このプロトコルは法制度に関連する独自の契約交渉手順を含むものではなく、あくまで、すでに大きな市場が存在する電子契約サービスを提供するサードパーティアプリケーションとの接続接点のみを提供しており、データ共有契約に関する法的・制度的なローカライゼーションは、データトランザクションプロセスの外で補完的に実施されることを想定しているためである。企業・業界・国境を横断する分散データマネジメントにおいては、適用される法域ごとに異なる規制要件（データ保護・プライバシー・セキュリティ・輸出管理・知的財産・セクター規制等）が存在し、法令遵守は、サービス提供範囲に適応されるそれぞれの制度に応じて実効的な方法で実施されるべきである。
なお、ガバナンスパースペクティブにおける機能の整理 としては、一般的に想定される「標準化（Standardization） 」や「適合性評価（Conformity assessment） 」をはじめ、L1〜L4それぞれのレイヤで求められる共通ルール及びポリシーについて検討を行う必要がある。Open Dataspaces技術の実装者は、ODPの実装を前提としつつ、自らが対象とする法域・業界・ユースケースの法的要件を踏まえたガバナンスを実施する必要がある。
効率的な分散データマネジメントの促進のためには、Open Dataspaceを跨ぐ共通の識別ルールとして「共通メタ識別子（Unified Meta Identifier） 」の採用が重要である。共通メタ識別子は、企業・業界等の中で個別最適化され、それぞれ異質なものとして存在している識別子体系を抽象化する形で策定されるものである。共通メタ識別子は、分散データマネジメントにおける互換性、検索性、セマンティクス相互運用性等を解決するための重要な基盤といえる。 UMIとしては、例えば、IRI（International Resource Identifier）等が想定され、具体的な仕様についてはODPにて定められている。
セキュリティパースペクティブは、「Security by Design」を基本原則とし、セキュリティを前提ではなく設計対象として扱う。また、サイバー空間とフィジカル空間が相互に関与する動的な環境を前提に、識別・認証、データ保護、可用性、可観測性、応答・復旧等のサイバー・フィジカル・セキュリティ要求をレイヤ横断的に適用する設計を採用する。
セキュリティパースペクティブの原則としては、以下の3点を掲げ、ポリシーの決定と執行を分離して一貫性・説明可能性・監査性を確保する:
ポリシードリブンな制御（利用目的・コンテクストに応じた動的評価）
また、相互運用性とガバナンスを考慮し、セマンティクス及びオントロジーの検証・説明可能性の担保、ライフサイクル管理、透明性あるリネージュを設計に組み込む。
それぞれのレイヤにおけるセキュリティパースペクティブは以下のように整理される：
セマンティクスレイヤ（L4） ：宛先解決と意味解決の責務を明確化し、役割分離されたインターフェースと信頼確認の枠組みで運用する。セマンティクス及びオントロジーは最小化・匿名化・適切な取り扱い方針に基づき管理され、説明可能性、変更・撤回の伝播、可観測性指標を備えることでプロビナンスと監査性を担保する。OWAに則った拡張性を残しつつ、相互運用性のガバナンスを考慮する。
アイデンティティレイヤ（L3） ：識別・認証・認可はゼロトラストと最小権限を実現する枠組みで設計し、属性や関係性に基づく動的な権限制御を支援する。ポリシードリブンかつコンテキストベースの判断によりデータ提供者の利用制御を技術的に支える。ポリシー評価と執行の分離により一貫性・可監査性を確保する設計とする。
トランザクションレイヤ（L2） ：エンドポイントへのルーティング、要求の仲介、ポリシー自動化と合意条件の技術的反映を通じて、探索・転送・履歴管理までの一貫した制御を提供する。運用性とガバナンス観点から、制御フローの透明性と信頼性を考慮する。
データレイヤ（L1） ：CWAの選択的適用に則ったデータの機密性・完全性・品質を設計上の優先事項とし、データの扱い方針、改ざん検知可能な証跡、データ品質の評価と参照可能性を体系的に担保する。データ利用制御や保存・撤回ルールを明示し、利用と保護のバランスを図る。
共通機能（監査・可観測性・運用） ：透明性と追跡可能性を確保するための証跡管理、可観測性指標の定義、脅威検出とインシデント対応の枠組みを全体設計に組み込む。可用性・事業継続性・ネットワーク分離等のレジリエンス要件も設計段階で考慮する。
セキュリティパースペクティブの原則は技術的対策に留まらず、ガバナンスパースペクティブに示される参加者間の責任分担、運用ルール、監査・評価の枠組みを統合することを前提とする。相互運用性、公平性、営業秘密の保護、法令遵守を確保するためのガバナンスを明確にし、将来的な拡張や技術進化にも対応可能な柔軟性を維持する。
トラストパースペクティブは、「Trust by Design」を基本原則とし、信頼を前提ではなく、設計対象 として扱う。特定のドメインだけではなく、企業間・国境間でのデータマネジメントでは、信頼は設計によって構築されるべき性質だといえる。これが、ODS-RAMがIdentity Layer（L3）から、トラストパースペクティブ（P4）を明示的に分離して位置付ける理由である。
ODS-RAMでは、アイデンティティを３つの要素に分解し、それぞれに異なる責務を与えている：
実在性の検証（Identity Proofing）: 主体が現実世界に存在することを担保する。つまり、この主体は、現実世界のどの個人・組織に対応するのか？
認証（Authentication）: 主体の主張を確認する。つまり、この主体は、主張するアイデンティティの所有者か？
認可（Authorization）: 主体と資源の関係から行為を許可する。つまり、この主体は、この資源に対して、今、この操作をしてよいか？
トラストパースペクティブにおいて最も重要なのは、認証された主体と信頼してよい主体を同一視しないこと である。
Open Dataspacesでは、分散データマネジメントのリスクや用途に応じて、必要なトラストレベルを合意し、検証・署名・時刻保証などの手段を組み合わせることで、用途適合型の信頼構造 を構築する。これにより、Open Dataspaces は完全な統一ではなく、秩序と緩やかな規律に基づく信頼の相互接続 を実現する。
4.1.1 ODS-RAMが想定するサービスモデル 4.1.2 ODS-RAMが想定するサービスの形態 4.1.2.1 データスペースファンダメンタルサービス（DFS） 4.1.2.2 データスペースコンプリメンタリサービス（DCS） 以下のように、すべてのサービスが起動すれば完了である。 コンポーネントを個別に起動・終了する場合の手順は、「5.3 起動・停止」を参照のこと。
続けて、L3とOpenFGA, L2の初期設定を行うが、こちらもSDKが提供するスクリプトを実行すればよい。 詳細はSDKのドキュメント を参照のこと。
各コンポーネントを個別に起動・停止する手順は以下の通りである。
データ提供者は、「4.3 運用開始に向けた各種データ設定」で作成した事業者に対して、インダストリサービスが公開するAPIへの認可設定を実施する必要がある。 詳細はSDKドキュメントの該当する節 を参照のこと。
データ利用者は、表2に示すヘッダをHTTPリクエストに設定する必要がある。
データ利用者は、以下の手順で提供者からデータの取得を行う。
データアクセス：取得したアクセストークンを用いてデータアクセスを実施する。コマンド例を以下に示す。
コピー
$ curl -X POST "http://localhost:8090/test " \
-H 'api-key: 2dfd3409-ce01-4451-96fa-7e10c9681422y' \
-H "Authorization: bearer $ACCESS_TOKEN" \
-H 'X-ODS-UserId: 112233' \
-H "Content-Type: application/json" \
-H "Prefer: return=representation" \
-d '{"userid":112233}' | jq . 各コンポーネントが出力するログの種類は以下の通り。
L2が出力したログは課金情報の根拠となるため、ロギングサービスによって収集され、ファイルとしてオブジェクトストレージに格納される。 出力先やローテート間隔などの情報はSDKドキュメントの該当する節 を参照のこと。
L3は標準出力および標準エラー出力にログを出力する。 コンテナ上で実行している場合、以下のコマンドでログを確認できる。
精算・課金／決済サービスは標準出力および標準エラー出力にログを出力する。 コンテナ上で実行している場合、以下のコマンドでログを確認できる。
コピー
$ git clone https://github.com/open-dataspaces/SDK-docker-compose.git
コピー
$ cd SDK-docker-compose
$ git clone --branch=v1.0.0 --depth=1 https://github.com/open-dataspaces/L2-dp-webapi.git
$ git clone --branch=v1.0.0 --depth=1 https://github.com/open-dataspaces/L3-identity-component.git
$ git clone --branch=v1.0.0 --depth=1 https://github.com/open-dataspaces/DCS-Payment.git
コピー
$ docker compose up -d
コピー
[+] Running 17/17
✔ gateway Built 0.0s
✔ payment-app Built 0.0s
✔ l3-app Built 0.0s
✔ Volume "ods_pgdata" Created 0.0s
✔ Volume "ods_postgres_data" Created 0.0s
✔ Volume "ods_pgdata_openfga" Created 0.0s
✔ Container minio Started 1.0s
✔ Container postgres Started 1.1s
✔ Container fluentd Started 1.1s
✔ Container l3-app Started 1.0s
✔ Container payment-db Healthy 11.5s
✔ Container postgres-openfga Started 1.0s
✔ Container payment-app Started 12.0s
✔ Container keycloak Started 1.7s
✔ Container openfga Started 1.6s
✔ Container ods-minio-init-1 Started 1.4s
✔ Container gateway Started 2.2s
コピー
$ docker compose -f l3/docker-compose.yml up -d
コピー
$ docker compose -f l3/docker-compose.yml down
コピー
$ docker compose -f logging/docker-compose.yml up -d
コピー
$ docker compose -f logging/docker-compose.yml down
コピー
$ docker compose up -d gateway
コピー
$ docker compose -f l2/docker-compose.yml down
コピー
$ docker compose -f payment/docker-compose.yml up -d
コピー
$ docker compose -f payment/docker-compose.yml down
コピー
$ docker logs payment-app README 本サイトでは、Open Data Spaces（ODS)に関するドキュメントを公開します。
→ English Version
Open Data Spacesリファレンスアーキテクチャモデル V2 (ODS-RAM V2) ODS-RAM V2は、企業・業界・国境を横断した分散データマネジメントのためのリファレンスアーキテクチャで、技術パラダイムや階層構造モデル、プロトコルの関係性などにより構成される参照文書です。
ODS-RAM v2を読む： README
Open Data Spaces Protocols (ODP) ODPは、ODS-RAMをもとに分散データマネジメント技術の相互運用性確保のため実装すべき技術仕様及び標準オペレーションを定めるドキュメンテーション群です。
ODPを読む： README
Open Data Spaces 事業者向け参入ガイドブック（開発事業者向け／ユーザー事業者向け） Open Data Spaces 事業者向け参入ガイドブックは、開発事業者向けとユーザー事業者向けから構成されます。
開発事業者向けは、ソフトウェアやデータ関連サービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理するガイドブックです。
また、ユーザー事業者向けは、データマネジメントやAIサービスを利用または自社で実装する立場にある企業や行政機関等の実務者・経営企画担当者が、データスペース事業への参入を検討する際に、参入の是非・自社が担い得る役割・初期投資の置き方を判断するための視点を整理するガイドブックです。
事業者向け参入ガイドブックを読む：
Open Data Spaces 技術者向け導入ガイドブックは、ODSを採用・導入またはサービス提供する立場にある技術者を対象に、その技術的な全体像と基礎を理解し、設計・実装・運用に着手するための最初の指針を示すガイドブックです。
技術者向け導入ガイドブックを読む：
はじめに 本プロトコル仕様書（Open Dataspaces Protocol：ODP）は、Open Data Spaces Reference Architecture Model（ODS-RAM）を参照し、その設計原則と整合する形で、相互運用可能な通信手順（Protocol）の抽象仕様を提供することを目的とします。ODS-RAMで示す各レイヤ・パースペクティブの機能を抽象的なプロトコル仕様へ落とし込み、実装者へその設計思想を踏まえた技術開発の指針を提供します。そして、実装の参考例を示しつつ、実装者の利用する技術スタックに選択肢を与えるよう拡張性、汎用性のある抽象仕様の提供を目指します。
本プロトコル仕様書はODSエコシステムにおける公式プロトコル仕様（normative document）として策定され、ODS-RAMおよび関連文書の改訂に応じて継続的に更新される。
本仕様書は以下の領域を対象とし、ODS-RAMで定義される各レイヤ／パースペクティブに対応する。
Open Data Spaces Protocols (ODP) 本リポジトリは、Open Data Spaces Reference Architecture Model（ODS-RAM）を参照し、その設計原則と整合する形で、相互運用可能な通信手順（Protocol）を技術的に明確化する公式プロトコル仕様書（Normative Document）を管理します。 ODS-RAMが規定する各レイヤの機能を具体的なプロトコル仕様へ落とし込み、実装者が迷わずに実装できる仕様を提供することを目的とします。
各プロトコルは、論理的な定義（Protocol）と、それを特定の技術スタックにマッピングした実装例（Binding）の2層構造で定義されています。
Protocol（抽象仕様）: 技術スタックに依存しない、論理的なメッセージモデル、規定要件、状態遷移を定義します。
Binding（具象仕様）: 実際の通信方式（HTTPS/JSON等）に当てはめた際の実装例、共通ヘッダー、エラーマッピング等を記述します。
※ APIの詳細なI/F仕様（エンドポイント、詳細なパラメータ、スキーマ等）は本ドキュメントには含まれません。 実装にあたっては、別途公開されている「API仕様書」を併せて参照してください。
ロギング対象項目。xxxにはサービス提供者などから指定された文字列を指定（例：X-ODS-UserId）
Open Data Spaces 技術者向け導入ガイドブック データトラストアセスメント（Data Trust Assessment）
データトラストワージネス・クオリティアセスメント（Data Trustworthiness and Quality Assessment）
アイデンティティ・トラスト（Identity and Trust）
メタデータエクスチェンジ（Metadata Exchange）
ディスカバリー・サーチ（Discovery and Search）
ヒューリスティックコントラクティング（Heuristic Contracting）
クリアリング・ペイメント（Clearing and Payment）
Relationship Between Layers and Perspectives in ODS-RAM 図 1 ODS-RAMにおけるレイヤ・パースペクティブの関係性
Open Dataspacesを構築・運用するシステムアーキテクト・エンジニア
トランザクションコンポーネント、ID基盤、セマンティクス基盤等を実装する開発者
ODSエコシステムに参加する企業・自治体などの技術責任者
ODPの著作権は、IPA、METI、 NEDOに帰属します。なお、ODPは、NEDO「ウラノス・エコシステムの実現のためのデータ連携システム構築・実証事業」における成果を基にIPAにて編纂・取り纏めたものです。
本プロトコルを実装してOSSとして公開されるコンポーネントについては、各リポジトリに定めるライセンスに従うものとします。
6. オンボーディングとオペレーション システム開発やアプリケーションサービス提供等を行う開発事業者ならびにユーザー企業・行政機関のシステム開発部門及びデータマネジメント部門の実務者に向けた技術的な導入及びオペレーションについては、ODPを参照し、「ODS技術者向け導入ガイドブック 」*3で具体的に示している。また、ソフトウェアやデータマネジメントサービスを提供する事業者に向けた「ODS開発事業者向け参入ガイドブック 」*4、データマネジメントやAIサービスを利用または自社で実装する立場にある企業や行政機関等の実務者・経営企画担当者に向けた「ODSユーザー事業者向け参入ガイドブック 」*5についても公開している。
また、ODPの参照実装として提供されるオープンソースソフトウェア（ODS Middleware）、及びSDKそれぞれについては、下記のGitで公開している:
ODS SDK（Software Development Kit） :
脚注
*3 Open Data Spaces 技術者向け導入ガイドブック
*4 Open Data Spaces 事業者向け参入ガイドブック（開発事業者向け）
*5 Open Data Spaces 事業者向け参入ガイドブック（ユーザー事業者向け）
Protocol Overview（概要） 本プロトコルはODS-RAMにおけるモニタリング機能を定義する。 モニタリング機能はデータトランザクションの稼働ステータスを継続的に把握し、異常や障害を早期に検知する機能を提供する。本機能はロギング機能を利用して収集及び集約したデータに基づき、リアルタイムの状態把握、システムの可視化、及び異常の早期検知を可能にする。
Abstract Normative Specification（抽象仕様） shall: ロギング機能で収集されたデータからメトリクスを算出する機能を提供しなければならない。
Rationale: 各種状況の適切な監視を可能にするため
should: メトリクスの可視化を目的としたダッシュボードを提供することを原則とする。
Rationale: 状態の把握と利便性を向上させるため
may: メトリクスがユーザ指定の条件を満たした際に、ユーザへの通知やシステムへの介入を行う機能を提供してもよい。
本プロトコルに必要な概念は以下である。
モニタリングの対象はOpen Dataspacesを構成する各モジュールである。 本モニタリング機能の主な対象は以下である。Open Dataspacesが機微なデータを扱う点から、一般的なデータの永続化機能に加えて証跡及びトレース情報を対象とする。
連携サービス・APIの通信状況 : システムを通過する通信データおよびその通信履歴に基づき、トラフィック量、エラー率、レスポンス時間などを監視する。また各連携サービスやAPIのリクエスト数、成功率、失敗の種別、処理時間などを管理する。
システムリソースの状況 : CPU、メモリ、ディスク容量、ネットワーク帯域などのリソースを監視する。システムやサービスが設定した閾値を超えた場合には異常を検知しアラートを発報する。また収集したデータに基づき、定期的なレポートやトレンド予測を実施してシステム運用の改善活動に活用する。
セキュリティの状況と監査 : ネットワークやプロセスのようなシステムの構成要素、また各機能の挙動の監視を通じて、セキュリティの観点から通常とは異なる振る舞いを早期に検知する。またシステムの監査など証跡のための機能を提供する。
should: 他の運用管理ツールやAIによる分析を前提に、サービスとの連携を念頭に、外部に提供するインタフェースはAPIを通じた連携とすることを原則とする。
should: メトリクスを可視化するダッシュボードを提供することを原則とする。またユーザがダッシュボードをカスタマイズできるようにしてもよい。
should: メトリクスを監視して異常を検知した場合にはシステム管理者に通知することを原則とする。異常検知の目的はサービスの稼働状況に加えて、システムのセキュリティ状況の監視を含む。異常を検知する手段として、各種メトリクスに閾値を設定してもよい。
Protocol 本プロトコルはODS-RAMにおけるロギング機能を定義する。 ロギング機能は、通信ログ、サービスログ、処理ログの3つのカテゴリに基づき、システムの通信状況、各サービスの処理結果、全体の監視・運用状況を包括的に記録・分析可能とすることを目的とする。各ログは、それぞれ異なる保持要件、セキュリティ要件、および用途に基づき設計・運用される。
shall: ロギング機能はOpen Dataspacesの構成要素において発生する記録が求められる事象について、その事象の要件に基づく5W1Hの情報を付加して記録する機能を一貫して提供しなければならない。
should: ログの記録においては、情報を適切に保護する仕組みを取り入れ、特に機密性の高い情報については改ざん防止等の処理を実施する仕組みを提供することを原則とする。
5. プロトコル 「Open Data Spaces Protocols（ODP） 」*2は、分散データマネジメントを実現する機能を提供し、相互運用性を担保する一連の技術的な取り決めである。ODPは、「ファンダメンタル（Fundamental） 」及び「コンプリメンタリ（Complementary） 」のプロトコル群で構成される（表1）。
表 1 ODS-RAMにおけるプロトコル種別
メトリクスの例
リクエストやサービス処理におけるレスポンスタイムやエラー率
may: 異常を検知した場合には、自動的にシステムに介入してシステムリソースやプロセスを操作する機能を提供してもよい。ただし、この機能は介入対象システムや介入の範囲が事前に定義されていなければならない。またシステム管理者によって設定されたセキュリティポリシーや許可範囲が遵守されなければならない。介入した内容は監査のためにログに記録され、対応履歴として追跡可能でなければならない。
Rationale: 異常検知時におけるサービスの継続を維持するためすると共に、不必要な介入や潜在的なセキュリティリスクを最小化するため。
may: ロギング機能のデータと分離してメトリクスを別途保存してもよい。その際には時刻情報やトレースIDを用いてロギング情報とのトレーサビリティを確保することを原則とする。
Rationale: メトリクスの管理を効率化してロギング情報との整合性を維持することでデータの追跡性と分析精度を向上させるため。
may: サービス独自のログの収集及び加工に基づく外部監査向けのレポート作成機能を提供してもよい。
データ利用者に対してデータストアに格納されたデータを送信する主体
Concepts and Roles（概念および役割） Normative Requirements（規定要件） Protocol Overview（概要） 本プロトコルは ODS-RAM の L1「Data Trust Assessment」に対応する Fundamental Protocol であり、「データの完全性／非改竄性の評価・算定を成立させるインターフェース（完全性／非改竄性の評価・算定そのものの機能は含まない）」を担う。
「データトラストアセスメント（Data Trust Assessment）」プロトコル仕様書は、2026年度に公開予定である。
should: ログへのアクセスは標準化されたインタフェースにより一貫したアクセス手段が提供されることを原則とする。
本プロトコルにおけるログ機能では、ロールをシステム管理者、セキュリティ管理者、開発者、監査担当者に分類して、ログを通信ログ、処理ログ、サービスログに分類する。各カテゴリごとに役割と対象情報を定義して多様なシステム運用や監視ニーズに対応する指針を示す。
通信ログ : ODSを通過するメッセージ（例: リクエスト、レスポンス）やヘッダー情報を記録する。トラフィックや接続状況の監視、および異常検知を目的とする。
処理ログ : リアルタイムダッシュボードや運用監視ツールを通じて、システム全体の処理状況、エラー状況、リソース利用状況などの監視・運用改善を目的とする。
サービスログ : 個別の連携サービスやAPIの処理結果の記録を目的とする。サービスログにはユーザの処理内容や機密情報が含まれる場合があり、特定の情報については適切な保護が求められる場合がある。
本ロギング機能は、それぞれのカテゴリごとに以下の情報を対象とする。 通信ログ・サービスログについては、ユーザーの個人情報や処理内容が含まれる可能性があるため、適切な保護が必要となる場合がある。
ODSを通過するメッセージのリクエストおよびレスポンスを対象とする。
メッセージのボディに加えメタデータ（例: HTTPメソッド、HTTPヘッダー、ステータスコードなど）も対象とする。
対象とするシステムの要件や形態によって具体的な情報は様々であるため、システムごとの可用性や運用性を考慮して選別する。
ODSと連携する連携サービスの情報（サービスログ） :
連携サービスごとの各種機能や処理結果に関連する情報を記録対象とする。
サービスによっては機密性の高い情報を含むため、適切な保護が求められる。
shall: 各種ログは標準的なフォーマット（例: JSON, XML, CSV）で記録されなければならない。
shall: 各種ログはその元となる事象に関する時系列情報を含まなければならない。
should: 各種ログに含まれる機密性の高い情報については、記録時に匿名化などサービスの要件に応じた処理を実施することを原則とする。
should: 各種ログのうち信頼性がサービス品質に直結するログについては改ざん防止のための処理を実施することを原則とする。改ざん防止のアプローチの例としては検知（ハッシュや署名など）や、永続化（イミュータブルストレージやWORM（Write Once Read Many）メディア）などが挙げられる。
should: ログの保存期間はシステムの要件に基づき決定することを原則とする。この期間は監査や証跡のような制約による場合もある。
may: 各種ログは一貫性をもってアクセスする手段が提供されることを前提に、中央集約型、分散型いずれのストレージやデータベースでも利用してもよい。
may: 各種ログはログ永続化の容量の肥大化を防ぐため、過去のログを削除するログローテーション機能を実装してもよい。
should: 通信ログの記録内容には、以下の主要メタデータを含むことを原則とする。
アクセスメソッド（例: HTTP GET, POST など）
ステータスコード（例: HTTP 200 OK など）
通信ログの追跡のための識別子（X-TrackingID など）
should: 処理ログの記録内容には以下を含めることを原則とする。
リソース利用状況（CPU、メモリ、ディスク容量 など）
should: 処理ログを外部サービスと連携する仕組みを提供することを原則とする。
should: サービスログの記録内容には以下を含めることを原則とする。
Abstract Normative Specification（抽象仕様） Concepts and Roles（概念および役割） Normative Requirements（規定要件） Open Dataspacesを実現するための補完的な機能を提供するための取り決めであり、対応するレイヤ・パースペクティブの機能を実現するために、必要に応じて採用してもよいプロトコル
ODPを構成するプロトコルは表3に記載のとおりである:
※ F = ファンダメンタル（必須）、C = コンプリメンタリ（任意）
詳細 : 各プロトコルの詳細な仕様については、ODP を参照されたい。
Open Dataspacesを実現するための主要な機能を提供するための取り決めであり、対応するレイヤ・パースペクティブの機能を実現するために採用しなければならないプロトコル
Binding 実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。
Concrete Specification（実装例） Prerequisites（前提条件） 本プロトコルは HTTPS（TLS 1.2以上）を使用し、REST形式のHTTPリクエスト/レスポンスにより通信を行う。
エンドポイント ：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用
データ形式 ：リクエストおよびレスポンスの本文はJSON形式
認証・認可 ：OAuth 2.0ベースのトークン認証を利用
セキュリティ要件 ：TLS 1.2以上必須、暗号化通信を保証
本プロトコルで使用される各フィールドの定義を記す。
各フィールドについて、以下の情報を記す。
Request・Responseのフィールドは、以下の通り。
Request・Responseのフィールドは本プロトコルの各機能で異なるため、
Sent by・Resulting state(s)・Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装は
Protocol Notifierは、データトランザクションに関する更新・受領状況を、データ提供者と利用者間で共有するための情報を通知する機能を提供する。
本レイヤは以下の領域を対象とする：
通知先リスト管理 データ提供者が提供データの登録・更新・削除をデータ利用者に通知する際に必要な通知先リストの管理機能を提供する。
通知管理 データ提供者からの通知管理および、データ利用者からの通知情報確認機能を提供する。
本プロトコルに必要な概念は以下である。
Protocol 本プロトコルは ODS-RAM の L1「Data Trustworthiness and Quality Assessment」に対応する Fundamental Protocol であり、「データ品質／信頼性の評価・算定を成立させるインターフェース（品質／信頼性の評価・算定そのものの機能は含まない）」を担う。
「データトラストワージネス・クオリティアセスメント（Data Trustworthiness and Quality Assessment）」プロトコル仕様書は、2026年度に公開予定である。
データトラストアセスメント（Data Trust Assessment）
データの完全性／非改竄性の評価・算定を成立させるインターフェース（完全性／非改竄性の評価・算定そのものの機能は含まない）
データトラストワージネス・クオリティアセスメント（Data Trustworthiness and Quality Assessment）
データ品質／信頼性の評価・算定を成立させるインターフェース（品質／信頼性の評価・算定そのものの機能は含まない）
エンドポイントとプロセス制御、データ転送を担い、各レイヤの結節点としてトランザクションを成立させる
アイデンティティ・トラスト（Identity and Trust）
参加主体を識別し、正当な主体同士、かつ正当なリソースへの権限でのみデータ交換が成立する信頼の前提を提供
メタデータエクスチェンジ（Metadata Exchange）
データの所在や意味に関するメタデータを連携し、分散環境でのデータ発見性と意味判断を成立させる
ディスカバリー・サーチ（Discovery and Search）
ヒューリスティックコントラクティング（Heuristic Contracting）
サードパーティの電子契約アプリケーションを通じて利用条件・契約条件の定義・合意形成を支援するインターフェース（契約そのものは含まない）
クリアリング・ペイメント（Clearing and Payment）
サードパーティの電子決済アプリケーションを通じてデータ取引の実績を記録・照合して精算・課金／決済するインターフェース（精算・課金／決済そのものの機能は含まない）
データトラストワージネス・クオリティアセスメント(L1) R = Required（必須）
クライアントアプリごとに払い出されたAPIKeyを指定する。ODS独自項目
アクセストークンを指定する。例：Bearer < token >
リクエストのトレーシングを行う一意なIDを指定する。ODS独自項目
コンテンツの読み込み・実行ポリシーを指定し、スクリプトやリソースの許可元を制御する。
ブラウザのMIMEタイプ推測を禁止し、指定されたContent-Typeを強制する。
Strict-Transport-Security
指定期間、HTTPS接続を強制し、HTTPへのダウングレードを防止する。
リソースのバージョン識別子を指定する。GETメソッドにおけるレスポンス時の必須項目。
リソースの最終更新日時を指定する。GETメソッドにおけるレスポンス時の必須項目。
データ提供者がデータ利用者へ通知する際に必要な、通知先リストに係る操作を行う。
データ提供者がデータ利用者へ通知する内容に係る操作を行う。
Field Definitions（フィールド定義） Functional Description（機能詳細）
Open Dataspacesを介したデータ提供に関わる通知先リスト管理
Open Dataspacesを介したデータ提供に関わる通知管理
shall: 通知先リストは、データ提供者単位で管理されなければならず、異なるデータ提供者間で通知先リストが共有または混在してはならない。
Rationale: データ提供者ごとの通知設定の独立性およびセキュリティを確保するため。
may: 通知先リストの管理は、複数の通知先を一括で登録・更新・削除する機能を必要に応じて提供してもよい。
Rationale: 運用負荷を軽減し、管理作業の効率化を図るため。
may: 保持するデータを暗号化する場合、CRYPTRECが推奨する暗号方式等の標準的な暗号技術を、必要に応じて参照・採用してもよい。
Rationale: 運用要件に合わせた暗号化技術の採用を、検討可能とするため。
should: 通知の管理は、認証情報を用いたデータ提供者や利用者の情報を基に、認証・認可に基づいて行うことを原則とする。
Rationale: 前提とするL2やL3レイヤの要件に整合し、通知情報へのアクセス制御が必要であるため。
may: 通知の管理は、複数通知の一括登録・一括更新・一括削除する機能を必要に応じて提供してもよい。
Rationale: 運用負荷を軽減し、管理作業の効率化を図るため。
may: 保持するデータを暗号化する場合、CRYPTRECが推奨する暗号方式等の標準的な暗号技術を、必要に応じて参照・採用してもよい。
Rationale: 運用要件に合わせた暗号化技術の採用を、検討可能とするため。
Transaction（L2）を介して、本機能が利用されることを前提とする。
Identity & Trust（L3）のトークンを用いて、本機能が利用されることを前提とする。
Notifierを利用する際の、メッセージ交換シーケンスを以下に示す。
Abstract Normative Specification（抽象仕様） Concepts and Roles（概念および役割） Normative Requirements（規定要件） Non-functional / Cross-layer Requirements（非機能要件 / クロスレイヤ要件） Binding Concrete Specification（実装例） Prerequisites（前提条件） 本プロトコルは HTTPS（TLS 1.2以上） を使用し、 REST形式のHTTPリクエスト/レスポンス により通信を行う。
エンドポイント：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用する。
データ形式：リクエストおよびレスポンスの本文はJSON形式とする。
Field Definitions（フィールド定義） 本プロトコルで使用される各フィールドの定義を記す。
各フィールドについて、以下の情報を記す。
通信時にはクライアントから以下のヘッダー情報の付与が必要となる。以下に記載のないヘッダー情報については任意となり、Web API転送モジュールは関知しない。
Web API転送モジュールは透過的APIゲートウェイ方式を採用しており、ペイロード情報についてはデータ提供者が提供するAPIの仕様に依存するため、詳細な仕様については、該当するサーバー（データ提供者）のシステム仕様書を参照すること。
なお、エラー発生時の応答については以下のペイロード(JSON形式)が返却される。
Web API転送モジュールは、透過的APIゲートウェイ方式を採用し、ルーティング機能のみに限定しており、ペイロード情報の解析やモデル変換の機能は提供していない。また、Web API転送モジュールはデータ利用者のアプリケーションとデータ提供者が所有するシステム間通信に介在し、アイデンティコンポーネントと連携したトークン検証および認可制御のためのPEP（Policy Enforcement Point）機能を提供する。
トランザクションレイヤが提供する機能は以下の通りである。
Protocol Overview（概要） 本プロトコルでは、エンドポイントとプロセス制御、データ転送を担い、各レイヤの結節点としてトランザクションを成立させる機能を提供する。 また、本プロトコルのコアコンポーネント群であるトランザクションコンポーネント はODPを構成する各プロトコルの結節点であり、各レイヤ/パースペクティブ（Fundamental Protocols, Complementary Protocols）との通信を行う。
本プロトコルは、以下のトランザクションマネジメントを定義する。
データ転送
データ利用者からの要求に応じて、データストアのエンドポイントからデータを転送する機能。 データ構造（構造化/非構造化）および処理方式（同期/非同期）のデータ転送を実現するために、下記の4つのデータプレーンモジュールに分類されている。
Web API転送モジュール 同期処理の構造化データ（Web API等）の転送に特化したデータプレーンモジュール。
ストリーム転送モジュール 非同期処理の構造化データ（ストリームデータ）の転送に特化したデータプレーンモジュール。
ファイル/バルク転送モジュール 同期処理の非構造化データ（大規模なファイルやバルクデータ）の転送に特化したデータプレーンモジュール。
メディアストリーム転送モジュール 非同期処理の非構造化データ（ビデオや音声などのリアルタイムストリーミングデータ）の転送に特化したデータプレーンモジュール。
認証認可連携 クレデンシャル発行サービスおよびアイデンティティコンポーネント(L3)と連携し、リクエスト単位で認証認可制御を行う機能。
ロギング ロギング(Common Functionalities)と連携し、来歴情報およびクリアリング・ペイメント(DCS)で必要となる情報を記録する機能。
本プロトコルに必要な概念は以下である。
本仕様はWeb API転送モジュールを最小実装例として定義する。
shall: Open Dataspacesにおけるデータ転送は、データプレーンモジュールを介して行わなければならない。
Rationale: Open Dataspacesにおける信頼性、相互運用性を確保するため。
should: 複数のデータ構造および転送方式に対応可能な拡張性を持つことを原則とする。
should: アイデンティティコンポーネント(L3)と連携し、リクエスト単位での認証および認可制御を行うことを原則とする。
Rationale: Open Dataspaces横断での一貫したアクセス制御を実現し、セキュリティと相互運用性を確保するため。
should: データスペースコンプリメンタリサービス（DCS）が必要とする最低限のデータを記録できることを原則とする。
プロトコルが扱うメッセージの種類を以下に示します。
本プロトコルで送受信されるメッセージは、以下の要素で構成されている。
本プロトコルで扱う状態について記す。
本プロトコルで使用されるエラー処理について記す。
Protocol Identity & Trust（L3）は、参加主体を識別し、正当な主体同士、かつ正当なリソースへの権限でのみデータ交換が成立する信頼の前提を提供する機能を提供する。
本プロトコルは以下の領域を対象とする：
認証（Authentication） 自然人（Human）およびシステム（Machine）を主体として識別・認証し、利用コンテキストに応じた認証を実現する。
認可（Authorization） リクエスト単位でポリシーベースの動的認可を行う。
Binding 本プロトコルは HTTPS（TLS 1.2以上） を使用し、 REST形式のHTTPリクエスト/レスポンス により通信を行う。
エンドポイント ：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用
データ形式 ：リクエストおよびレスポンスの本文はJSON形式
Binding 実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。
通信プロトコル: HTTPS (TLS1.2以上)
該当操作が許可されていない旨を通知する。なお、再送しても成功しないため再送信は行わない。
リソースが存在しない旨を通知する。なお、再送しても成功しないため再送信は行わない。
最新のデータを再取得し、競合を解消させたうえで、再送信を行う。
サポートされないリクエスト形式指定時において返却される。
正しいContent-Typeを設定し、再送信を行う。
サーバ内部において何らかの異常発生時に返却される。
継続的に発生する場合はシステム管理者へ通知を行う。なお、再送信については行った操作によって実行要否を行う。
Rationale: Open Dataspacesにおけるデータ流通では、構造化/非構造化、同期/非同期など多様なユースケースが存在し、単一方式では相互運用性と実装容易性を確保できないため。
may: データプレーンモジュールは、コントロールプレーンオーケストレータを用いずに直接利用されてもよい。
Rationale: 導入容易性や段階的展開を可能にし、実装・運用の選択肢を確保するため。
Rationale: DCSとの情報連携を可能にするため。
データ利用者がWeb API転送モジュールに対し、特定の操作や情報の要求を行うために送信されるメッセージ。認証情報や要求パラメータを含む。
リクエストフィールドはIdentity & Trust（L3）の仕様に依るため、Identity & Trust（L3）を参照すること。
Web API転送モジュールがIdentity & Trust（L3）に対し、認証や認可の要求を行うために送信されるメッセージ。認証情報や要求パラメータを含む。
レスポンスフィールドはIdentity & Trust（L3）の仕様に依るため、Identity & Trust（L3）を参照すること。
Identity & Trust（L3）がリクエストに応じてWeb API転送モジュールに送信する結果メッセージ。認証・認可結果、トークン、エラー情報などを含む。
リクエストフィールドは転送先システムの仕様に依るため、データ提供者が公開する仕様を参照すること。
Web API転送モジュールがデータ提供者に対し、特定の操作や情報の要求を行うために送信されるメッセージ。データ提供者側のAPIの認証情報(APIキー)や要求パラメータを含む。
データ提供者から返却された正常系レスポンス、もしくはエラーレスポンスを受け取る。仕様については、データ提供者が公開する仕様を参照すること。
データ提供者がリクエストに応じてWeb API転送モジュールに送信する結果メッセージ。API実行結果、エラー情報などを含む。
データ提供者から返却された正常系レスポンス、もしくはエラーレスポンスを原則としてそのまま透過する。仕様については、データ提供者が公開する仕様を参照すること。
Web API転送モジュールがリクエストに応じてデータ利用者に送信する結果メッセージ。API実行結果、エラー情報などを含む。
クライアント（データ利用者） ⇒ Web API転送モジュール
リクエスト検証を行い、不正な場合はエラーレスポンスを生成して返却する。
クライアント（データ利用者） ⇒ Web API転送モジュール
Web API転送モジュール内で API-Key を検証し、不正な場合はエラーレスポンスを生成して返却する。
Identity & Trust（L3） 側で API-Key 検証に失敗
Web API転送モジュール ⇒ Identity & Trust（L3）
Identity & Trust（L3） のレスポンスをそのまま返却する。
アクセストークン無効／期限切れ等によりトークン検証に失敗
Web API転送モジュール ⇒ Identity & Trust（L3）
トークン検証結果に基づき、無効／期限切れの場合はエラーレスポンスをそのまま返却する。
Web API転送モジュール ⇒ Identity & Trust（L3）
認可判定結果に基づき、認可エラーとしてエラーレスポンスをそのまま返却する。
ルート未登録、パス／メソッド不一致等により転送先が決定できない
ルーティングの結果としてエラーとなる場合、エラーレスポンスを生成して返却する。
L3 または連携先に接続できない、無効な応答が返る等、外部通信が成立しない
Web API転送モジュール ⇒ Identity & Trust（L3） / 連携先システム
外部接続失敗／無効応答を検知した場合、エラーレスポンスを生成して返却する。
L3 または連携先からの応答が規定時間内に得られない
Web API転送モジュール ⇒ Identity & Trust（L3） / 連携先システム
タイムアウトを検知した場合、エラーレスポンスを生成して返却する。
Web API転送モジュール内部の例外等により処理できない
例外を捕捉し、エラーレスポンスを生成して返却する。
データ利用者に対してデータストアに格納されたデータを送信する主体
・データ利用者 ⇒ Web API転送モジュール
・Web API転送モジュール ⇒ Identity & Trust（L3）
・Web API転送モジュール ⇒ データ提供者
送信元がデータを操作するための要求や認証・認可を要求するために送信先に対して送信するメッセージ。リクエストに必要なヘッダ情報や要求パラメータを含む。
・Identity & Trust（L3） ⇒ Web API転送モジュール
・データ提供者 ⇒ Web API転送モジュール
・Web API転送モジュール ⇒ データ利用者
リクエストの送信先が送信元に対してリクエストに対する結果を送信するメッセージ。データの操作結果や認証・認可の検証結果、トークン、エラー情報などを含む。
メッセージの先頭に存在し、通信制御情報に必要なメタデータを保持する。
メッセージの中央部に存在し、業務データ本体を保持する。
連携先システムが返却した 4xx/5xx 等のエラー（外部サービス固有のエラー）
Abstract Normative Specification（抽象仕様） Concepts and Roles（概念および役割） Normative Requirements（規定要件） Non-functional / Cross-layer Requirements State Machine Diagram（状態遷移図） リクエストフィールドは転送先システムの仕様に依るため、該当するデータ提供者が公開する仕様を参照すること。
必須ヘッダー欠落、値不正などクライアント起因で成立しないリクエスト
R = Required（必須）
クライアントアプリごとに払い出されたAPIKeyを指定する。
アクセストークンを指定する。例：Bearer < token >
リクエストのトレーシングを行う一意なIDを指定する。クライアント側で指定されない場合はWeb API転送モジュールでUUIDを自動採番する。連携する機能によっては必須項目となる。（例：クリアリング・ペイメントとの連携時）
ODS内の制御用の拡張ヘッダ。例としてデータスペースコンプリメンタリサービス(DCS)の一つである精算決済サービスにおけるログを用いた整合性確認の用途がある。xxxには任意の文字列を記載。（例：X-ODS-UserId）
タイムスタンプ（ISO 8601 の UTC 形式）
PEP（Policy Enforcement Point）として、PDP（Policy Decision Point）であるIdentity & Trust（L3）と連携して認可制御を実現する。Identity & Trust（L3）が持つ認可機能（OpenFGA）とはAuthZEN APIで連携する。なお、認可制御はユースケースによって要否が異なるため、設定によってON/OFF制御を可能とする。
ODS基盤における保守運用のために必要なログを出力する。
Web API転送モジュール内処理の追跡性確保のための情報（ルーティング情報やトラフィック情報等）やデータスペースコンプリメンタリサービス（DCS）との連携のために必要な情報をログとして出力する。ロギング対象の情報は以下の通りである。
【リクエスト時】
・リクエスト送信元情報
・リクエスト転送先情報
・リクエストAPI情報
・リクエスト受信時間
・リクエスト送信時間
・X-TrackingID
・X-ODS-xxxヘッダの情報
【レスポンス時】
・レスポンス受信時間
・レスポンス送信時間
・X-TrackingID
・ステータスコード
Web API転送モジュールのルーティングに必要なルート情報を永続化する。
・ルート情報のDBへの永続化
ルート情報が再起動等でクリアされないようにDBに格納することで、永続化する。永続化された情報はWeb API転送モジュール起動時にルート情報としてロードされる。
・ユースケース毎にルート情報を管理可能
1つのDBを複数のユースケース（Web API転送モジュールはユースケース毎に用意）で共用したい場合、ユースケース毎のルート情報はDB（PosgreSQL）のデータベース内にスキーマを分けることで管理する。Web API転送モジュールからは、DBの接続情報として参照するスキーマを指定し、ユースケース毎のルート情報を取得する。
Web API転送モジュールでファイル送受信を行う。
・ファイル取得
連携先システムからWeb API転送モジュールを介してファイル形式のデータを取得できる。データサイズは数MB程度を想定。
・ファイル転送
連携先システムに対してWeb API転送モジュールを介してファイル形式のデータを転送する。データサイズは数MB程度を想定。
コンテナ基盤で動作し、クラウドサービス等に依存しない。
Web API転送モジュールはさらに、クライアントが要求している操作が許可されているかを確認するため、「認可チェック」エンドポイントへ HTTPリクエストを送信する。
アイデンティティコンポーネントはポリシーに基づいてアクセス権を評価し、認可結果をWeb API転送モジュールに返す。
認証・認可が通過すると、Web API転送モジュールはデータ提供者サーバーの API エンドポイントへ HTTPリクエストを送る。
サーバー（データ提供者）は要求された処理を実行し、その結果をWeb API転送モジュールへ返す。
Web API転送モジュールは受け取った API 結果をクライアントにそのまま返却し、クライアントはデータを取得する。
prefixを含むエラーコード。prefixは下記のとおり。
・dataspace: Web API転送モジュールでエラーが発生した場合
・auth: 認証認可関連のエラーが発生した場合
透過的APIゲートウェイとして、連携サービスへのルーティング機能を提供する。
ルーティングのルールを"ルート"として登録し、データ利用者とデータ提供者を仲介する。各ルートは、リクエストの条件（パス、メソッド、ヘッダなど）に基づき、転送先システムのAPIへリクエストを振り分ける。この仕組みにより、ルート設定を変更することで、転送先や条件を容易に追加・更新できる動的なルーティングを実現する。また、ルーティングの際には、Web API転送モジュールとして必要な処理(例：リクエストヘッダーにX-TrackingIDが含まれていない場合は、新規にUUIDを採番する、ヘッダーの内容を書き換える等)を実施する。
クライアントを認証する方式として以下の2つの認証を実施する。
・APIキー認証
リクエストヘッダー「API-Key」の検証をWeb API転送モジュール内で実施する。
・OAuth 2.0 / OpenID Connectトークンイントロスペクション
リクエストヘッダー「Authorization」のアクセストークンの検証をIdentity & Trust（L3）と連携して行う。検証の結果、無効または期限切れの場合はHTTPレスポンスステータスコードを「401 Unauthorized」として、JSON形式のエラーレスポンスを返却する。認証制御をWeb API転送モジュールと分離することで、責務が明確になり保守性が向上し、認証方式の変更や追加があってもゲートウェイへの影響を最小化できる。
クライアント（データ利用者）は、データ提供者の API を実行するため、Web API転送モジュールに対して HTTPリクエストを送信する。
Web API転送モジュールは、受け取ったリクエストに対してAPIキーチェックを行う。APIキーチェックを通過した場合、トークンの正当性を確認するため、アイデンティティコンポーネントの「トークンイントロスペクション」エンドポイントへ HTTPリクエストを送る。なお、リクエストヘッダーにX-TrackingIDが含まれていない場合は、新規にUUIDを採番する。
アイデンティティコンポーネントはトークンを検証し、その結果（有効性・スコープなど）をWeb API転送モジュールに返す。
Functional Description（機能詳細）
コピー
{
"code": "[dataspace] BadRequest",
"message": "Invalid request parameters",
"detail": "2025-12-17T04:37:18.189972258Z"
} トークンおよびクレデンシャル管理 アクセストークン・リフレッシュトークンを発行し、事業者識別（operator_id 等）などのビジネスコンテキストをクレームとして付与する。
Federation & Trust（トラスト連携） 異なる運営組織・異なるOpen Dataspaces間の相互信頼を確立する。
Federation（Open Dataspacesを跨ぐ信頼連携）
shall: Identity & Trust（L3） は自然人・システムの双方を識別できる仕組みを持たなければならない。
Rationale: ODS の業務要件では、人による操作とシステム間通信が混在するため、両者を明確に区別しなければならない。
shall: 認証・認可方式には OAuth 2.0 および OpenID Connect を使用しなければならない。 自然人主体の認証には OpenID Connect（Authorization Code Flow）を、 システム主体については OAuth 2.0（Client Credentials Flow）におけるクライアント認証によって行う。
Rationale: 国際的に広く普及しているため相互運用性を確保できる。
should: ユーザ認証には Authorization Code Flow（PKCE）を使用することを原則とする。
Rationale: 自然人を扱う ODS では不可欠。PKCE はセキュリティ水準を向上。
may: 追加クレデンシャル（例: Verifiable Credential）を利用してもよい。
Rationale: 将来の拡張性と他Open Dataspaceとの相互連携性を確保。
may: フィッシング体制の高い多要素での認証を利用してもよい。
Rationale: 多要素認証により、資格情報の窃取や再利用に起因する不正アクセスのリスク低減が可能。
Note (Future Consideration): 認証においては、将来的な検討事項として、 フィッシング耐性の高い認証方式（例：FIDO2 に基づくパスキー等）を 用いた多要素認証を採用することが考えられる。
shall: 認可判断をネットワーク境界（FW/DMZ）に依存してはならない。
Rationale: ゼロトラストアーキテクチャの原則に従うため。
shall: 認可判定に用いるsubject識別子は、アクセストークン内の検証済みクレームに基づかなければならない。
Rationale: 認証と認可を論理的に接続し、主体のなりすましや識別不整合を防ぐため。
should: 認可は API Gateway（粗粒度）と Application（細粒度）の二層構造とすることを原則とする。API Gateway（粗粒度）ではResource ServerのAPI利用のアクセス制御、Application（細粒度）ではリソースレベルでのアクセス制御を原則とする。
Rationale: 基盤レイヤと業務アプリレイヤを分離し、拡張性を維持するため。
should: PAPおよびPEP,PDP は分離することを原則とする。
Rationale: 政策管理と評価ロジックの分離はセキュリティと性能に寄与。
should: PEP ↔ PDP の通信は AuthZEN モデルと整合することを原則とする。
Rationale: 標準化されたReBACアプローチにより認可判断の一貫性が向上。
should: PAPおよびPDPは、論理的にはIdentity & Trust（L3）と統合されることを原則とする。
Rational: 認可モデルおよび判定ロジックの一貫性を確保し、ポリシー管理の分散による複雑化を防ぐため。
should: 認可モデルはReBACを原則とする。ReBACを採用する場合、認可モデルは少なくとも主体・対象・関係性（subject, object, relation）を明示的に表現できる構造を備えなければならない。
Rational: 権限継承や共有関係をグラフとして自然に表現でき、ポリシーの可読性・拡張性に優れるため。
should: アクセストークンは署名付き JWT を使用することを原則とする。
Rationale: 相互運用性と軽量性に優れる。
should: アクセストークンは必要最小限の短い時間にすることを原則とする。
Rationale: 漏洩時の影響を最小化するため。
should: operator_id / system_id などビジネスクレームを付与することを原則とする。
Rationale: Open Dataspacesにおける事業者主体の識別が必須。
may: Refresh Token を使用してよい。
Rationale: セッション維持を効率化するため。
should: 異なるOpen Dataspaces運営組織間の Identity Federation をサポートすることを原則とする。
Rationale: 将来的な相互運用性確保が不可欠。
should: フェデレーション環境においては、subject識別子は発行主体を識別可能な形式とすることを原則とする。
Rationale: Open Dataspace間連携時の主体衝突を防ぐため。
may: 第三者トラスト（PKI / DAPS 等）を使用してよい。
Rationale: 組織のポリシーに応じた選択肢を提供。
プロトコルが扱うメッセージの種類を以下に示します。
認証における代表的なシナリオとして、自然人主体の認証である認可コードフローのメッセージ交換シーケンスを以下に示す。
クライアントがサーバー（Identity & Trust（L3））に認証画面URL（ログイン画面）のリクエストを送信する :
クライアント ⇒ サーバー（Identity & Trust（L3））: 認証画面URL取得リクエスト
コピー
{
"client_id": "abc123xyz",：clientごとに払い出されたID
"redirect_uri": "https://example.com/home",：認証後にリダイレクトするURL
"code_challenge": "IevIR0cQsAuNuPha71dAbjkT-sipaqXEquPhtCqKL80"：PKCEで用いるチャレンジ文字列
} サーバー（Identity & Trust（L3））がリクエストを解析し、認証画面URL（ログイン画面）をクライアントに返送する :
サーバー（Identity & Trust（L3）） ⇒ クライアント: 認証画面URL（ログイン画面）返却レスポンス
ユーザのブラウザで認証画面URL（ログイン画面）にアクセスし、認証情報（ユーザIDとパスワード）を入力する。
ユーザのブラウザ ⇒ サーバー（Identity & Trust（L3））: 認可コード取得リクエスト
ユーザIDとパスワードを解析し、認可コードをユーザのブラウザに返送する
サーバー（Identity & Trust（L3）） ⇒ ユーザのブラウザ: 認可コード返却レスポンス
クライアントがサーバー（Identity & Trust（L3））に認証リクエストを送信する :
クライアント ⇒ サーバー（Identity & Trust（L3））: 認可コードを使った認証リクエスト
サーバー（Identity & Trust（L3））がリクエストを解析し、アクセストークンをクライアントに返送する :
サーバー（Identity & Trust（L3）） ⇒ クライアント: 認証レスポンス
Abstract Normative Specification（抽象仕様） Concepts and Roles（概念および役割） Normative Requirements（規定要件） Tokens & Credentials（トークン管理） State Machine Diagram（状態遷移図） 認証・認可 ：認証・認可方式には OAuth 2.0 および OpenID Connect を使用する。
自然人主体の認証には OpenID Connect（Authorization Code Flow）を、 システム主体のアクセス制御には OAuth 2.0（Client Credentials Flow）を用いる。
また、ポリシーベースでの認可制御を提供する。
セキュリティ要件 ：TLS 1.2以上必須、暗号化通信を保証
本プロトコルで使用される各フィールドの定義を記す。 なお、各APIの詳細な項目定義は別途公開している「API仕様書 」を参照すること。
Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装はAPI仕様書 の記載を参照すること。
本プロトコルの認証機能では以下の 2 種類の認証フローを提供する。
本プロトコルでは発行するアクセストークンに対し、業務上の識別に必要な以下2種類のカスタムクレームを付与する。
ユーザまたはクライアントが所属する 事業者（operator） を識別するための情報である。 本クレームは以下のフローにおいてアクセストークンへ付与される。
- Authorization Code Flow（認可コードフロー） → ユーザ払い出し時に指定された事業者を付与。
- Client Credentials Flow（クライアントクレデンシャルフロー） → クライアント（client_id）払い出し時に指定された事業者を付与。
クライアントが属するシステムを識別するための情報である。 本クレームは以下のフローにおいてのみアクセストークンへ付与される。
- Client Credentials Flow（クライアントクレデンシャルフロー）
Authorization Code Flow（ユーザを伴うフロー）では付与されない。
Field Definitions（フィールド定義） Functional Description（機能詳細） サービス定義方法: SAMM(Semantic Aspect Metamodel)
本プロトコルで使用される各フィールドの定義を記す。
航空業界のドローン航路におけるメタデータの例を挙げる。
ドメインアプリケーションからのRDF Patch更新通知をAMQPで受信する。
到着順序は保証されない（分散カタログ側で順序制御）
Sent by・Resulting state(s)・Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装はAPI仕様書の記載を参照してください
Concrete Specification（実装例）
コピー
{
"query": "SELECT ?s ?p ?o WHERE { ?s ?p ?o } LIMIT 10",
"target": "https://domain-app.example.com/sparql",
"options": {}
}
コピー
http://localhost:8080/resource/aircraft/DDDD2222-0000-0000-4444-000000000004
コピー
{
"@type": "sf:Point",
"geo:asWKT": {
"@value": "POINT (130.408585 33.588344)",
"@type": "geo:wktLiteral"
}
}
コピー
H id <uuid:...>
H prev <uuid:...>
TX
PA ex: <http://example.org/>
A ex:subject ex:predicate "object" .
D ex:subject ex:oldPredicate "oldObject" .
TC Field Definitions（フィールド定義） RDF Patch形式（Apache Jena/Fuseki） Functional Description（機能詳細） Protocol Overview（概要） 本プロトコルは ODS-RAM の L4「Metadata Exchange」に対応する Fundamental Protocol であり、データの所在や意味に関するメタデータを連携し、分散環境でのデータ発見性と意味判断を成立させるものである。 メタデータは、情報モデルとしてRDF(Resource Description Framework)を採用し、データモデルとしてJSON-LD 形式やTurtle形式を採用する。データやサービスの提供者がこのメタデータを公開することで、データやサービスの発見や解釈、利用が容易になる。また、この基盤的なプロトコルの上位プロトコルとして、Discovery and Search 等を用いることで、データやサービスがネットワーク上で分散的に存在しても、Open Dataspaces全体が透過的に一つのシステムとして機能することを可能にする。 このメタデータは、モビリティやサプライチェーンといった実社会におけるエンティティと、クラウド上のデータやサービスのアクセスを対応づけることを主に意図されているが、前者は必須ではない。
必須とする後者のメタデータにより、サービスの外部仕様がグローバルに意味解決可能となるように接地（意味定義を明確化）され、さらに、そこへのアクセスに必要な諸情報（宛先を含む）が明確になる。
これらのメタデータは、一般のWebアプリケーションサーバ/クライアントの側に構築される。すなわち、メタデータサーバは、アプリケーションサーバからメタデータを静的あるいは動的に取得する。 メタデータクライアントは、アプリケーションクライアントに対してメタデータを提供する。ここで、設計方針としては、通常のWebアプリケーションシステムがデータベース指向のシステム要件（トランザクション、リアルタイム性、高スループット）を満たすものであるのに対して、メタデータ関連のシステムは、広域環境で多種多様なデータの中から必要なデータを発見することを重視する代償として、データの一貫性等は一旦犠牲にし、必要に応じて追加するものとする。 そもそも実世界のデータや、既存のアプリケーションサーバ等のシステムの多様データを統一的なメタデータとして形式を変換し複製する以上、メタデータ管理を厳密に一貫性管理をする必要がる用途は限られていることを前提としている。
Abstract Normative Specification（抽象仕様） Concepts and Roles（概念および役割） shall: メタデータは、RDFで表現されなければならない。
Rationale: メタデータで表される意味（セマンティクス）の表現方法を統一し、相互運用性を確保するため。
shall: メタデータには、データ授受あるいはサービス提供に関わるインターフェースの意味定義が、グローバルに意味解決可能な形で含まれなければならない（e.g. SAMM）。
Identity & Trust（L3） と連携可能であること。
メタデータ自体へのアクセスにも、適切なアクセス管理が必要な場合には、Identity & Trust（L3）と連携し、権限管理がされること。
RDFモデルはODSセマンティクス方針に準拠する。
メタデータは、データやサービスを提供するシステムからメタデータサーバに提供され公開される。他のサービス提供者のメタデータを参照する、あるいはDiscovery Serviceに公開されるなどで、他のシステムから参照可能となる。
メタデータは、データやサービスの意味定義や宛先情報に関わるサービスメタデータと、実社会における実体と対応するリソースメタデータから構成される。サービスメタデータは、サービス仕様自体の記述、これを当該環境に展開した状態（インスタンス）などから構成されるが、サービス仕様自体の記述は、別のメタデータサーバに格納され、これを参照するなどで表現される。当該サービスに独自な仕様は当該メタデータサーバに格納されうる。サービスメタデータは、リソースメタデータから参照され得る。サービス仕様の記述は、SAMMなどを用いてAspect Modelとして記述される。
サービスメタデータは、二つのパートで構成される
@context は、メタデータで使用されるプレフィックスと名前空間との対応を定義する。
@graph は次の複数のオブジェクトから構成される。
DomainApp ：ドメインアプリケーション全体を表す。
DomainAppEndpoint ：SAMMによって定義されたエンドポイントのURI情報を表す。
BaseEndpoint ：REST APIのエンドポイントの共通部分のURI情報を表す。
SparqlEndpoint ：SPARQL用のエンドポイント情報を表す。
DomainAppはドメインアプリケーション全体を表す。
構造
DomainAppEndpointはSAMMによって定義されたエンドポイントのURI情報を表す。
共通構造
BaseEndpointはREST APIのエンドポイントの共通部分のURI情報を表す。
SparqlEndpointはSPARQL用のエンドポイント情報を表す。
リソースメタデータは、当該用途のアプリケーションが生成・管理する様々な形式のデータをRDFにより表現し、共通の語彙により意味を持たせた、ドメイン内データのメタデータである。ドメイン依存であるため、具体例は、binding.mdで挙げる。
(1) 基本構造
本データは JSON-LD により RDF を表現する
ID表現
例:
データ型
リテラル値は @value + @type で明示
本プロトコルで使用されるエラー処理について記す。
Michael Franklin, Alon Halevy, David Maier, "From Databases to Dataspaces: A New Abstraction for Information Management", SIGMOD Record, Vol. 34, No.4, Dec. 2005
Protocol Overview（概要） 本プロトコルは ODS-RAM の L4「Discovery and Search」に対応する Fundamental Protocol であり、メタデータをもとにした探索・検索の高度化を担うものであり、 Metadata Exchange 上に公開された情報を利用してリソース探索とエンドポイント解決を行う。
Abstract Normative Specification（抽象仕様） Concepts and Roles （補足） 「
shall: Discovery Service は、検索可能とするリソースを登録できるAPI（register）を持たなければならない。
Rationale: Discoveryは、サービスの提供者やデータの保持者が、保有するデータやサービスを検索対象となるために利用するのを原則としているため。Discovery Serviceは、Webサーチエンジンのように受動的（Passive）なインデックス化ではなく、サイト側が登録する能動型（Active）なインデックス化を行う。
shall: クライアントが、データやサービスにアクセスするために必要なエンドポイントの解決をするために、属性をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持たなければならない。
データ/サービス提供者に関する情報が、Discovery Serviceに登録されると、この情報のライフサイクル管理は次の状態遷移で管理される。
本プロトコルで使用されるエラー処理について記す。
Binding 実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。
Concrete Specification（実装例） Prerequisites（前提条件） 本プロトコルで使用される各フィールドの定義を記す。
Discovery Finder/Discovery Serviceは「サービスインスタンス」データを返却する。 サービスインスタンスはJSON-LD形式で表現され、以下の主要な構成要素を持つ：
ビジネスドメインにおけるアプリケーション（データ/サービス）のリソース情報を元に、そのリソースに関するアプリケーションのエンドポイントを解決
利用者が、ドメインで使用する様々なデータを検索キーで検索し、データおよびそのデータ獲得に必要なドメインアプリケーションのメタデータを解決
なお、独自のビジネスドメイン用にDiscovery Serviceを構築する場合、メッセージ処理とデータベース部分は自動生成されるが、それらをつなぐ処理のみ開発を行う必要がある。
Discovery Service利用者がDiscovery Serviceにアクセスするエンドポイントを解決するために使用
Discovery Serviceのエンドポイントを登録
既存のキーワードに登録するか新しいキーワードを作成して登録するか選択可能
Protocol クリアリング・ペイメントは、サードパーティの電子決済アプリケーションを通じてデータ取引の実績を記録・照合して精算・課金／決済するインターフェース（清算・課金／決済そのものの機能は含まない）を提供する。本プロトコルはComplementary Protocolsの1つとして、Open Dataspacesを実現するための補完的な機能である。
本レイヤは以下の領域を対象とする：
精算（Clearing） データ交換における、提供者と利用者間の取引を記録し、利用量と料金モデルに基づく精算処理を行う。なお、記録した取引は、ロギング機能を利用して収集したデータ交換の取引実績と比較することにより、精算対象を確認する。
課金／決済（Payment） 決済処理に必要な情報を提供する。なお、実際に決済を処理する機能については対象外である。
本プロトコルに必要な概念は以下である。
クライアントアプリごとに払い出されたAPIKeyを指定する。ODS独自項目
アクセストークンを指定する。例：Bearer < token >
認証フロー関連のAPI（パスワード変更を除く）では不要。
リクエストのトレーシングを行う一意なIDを指定する。ODS独自項目
コンテンツの読み込み・実行ポリシーを指定し、スクリプトやリソースの許可元を制御する。
ブラウザのMIMEタイプ推測を禁止し、指定されたContent-Typeを強制する。
Strict-Transport-Security
指定期間、HTTPS接続を強制し、HTTPへのダウングレードを防止する。
Access-Control-Allow-Origin
CORSに関する項目。
レスポンスを許可するオリジンを指定し、クロスオリジンアクセスを制御する。
Access-Control-Allow-Methods
CORSに関する項目。
クロスオリジンリクエストで許可するHTTPメソッドを指定する。
Access-Control-Allow-Headers
CORSに関する項目。
クロスオリジンリクエストで許可するリクエストヘッダーを指定する。
Access-Control-Allow-Credentials
CORSに関する項目。
クロスオリジンリクエストで認証情報の送信を許可するかを指定する。
ODS運営事業者が調査を行うのにあたり必要な情報（例：エラー発生時の発生日時）を設定する。
正常時の実行結果に対する業務データオブジェクト。
異常時では不要。
アクセストークンを検証し、トークンの有効性や関連情報を取得する。
リフレッシュトークンを使用してアクセストークンを再取得する。
リクエストに含まれるIDに対応するユーザのパスワードを変更する。
リクエストボディに含めたAPIKeyの有効性を検証する。
認可に利用するモデルの登録・取得を行う。登録についてはアクセス制限を設け、許可したユーザのみ登録可能となるようにする。
認可に利用するタプルの登録・取得を行う。登録についてはアクセス制限を設け、許可したユーザのみ登録可能となるようにする。
認可の判定を行う。API定義についてはAuthZENのevaluationエンドポイントの仕様に準拠する。
クライアントの登録およびクライアントシークレットの発行を行う。
事業者に紐づく付帯情報である事業所情報に関する操作を行う。
認可コードフロー/クライアントクレデンシャルフロー
本プロトコル上のクライアント（アプリケーション）を識別する ID。
認可コードフロー/クライアントクレデンシャルフロー
クライアントが Identity & Trust（L3）に対し自身を認証するために使用する秘密情報。
Rationale: 分散データマネジメントでは、データやサービスの場所がグローバルに任意とし、データやサービスの実態を各者が管理可能とすることでデータ利用制御を実現するが、クライアントからはデータの発見が課題となってしまうため、検索のキーとなる属性からデータやサービスのエンドポイントにアクセスできるようにする必要があるため。
shall: Discovery Serviceは、検索結果として、リソースのエンドポイントを含むメタデータを返却しなければならない。
Rationale: Discovery Serviceは、データやサービスの場所を特定するために利用されるため、検索結果としてエンドポイントを含むメタデータを返却する必要があるため。
should: Discovery Serviceは、キーワード検索をサポートすることを原則とする。文字列をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持つ。
Rationale: キーワードの一致から、そこに関連したデータやサービスのメタデータを返すインデックスが広く有用であるため。
should: Discovery Serviceへのメタデータの登録は、一定時間（TTL）後に無効となることを原則とし、継続的に検索可能とするには、継続（Keep Alive）指示を行うことを原則とする。
Rationale: データ/サービス自体が存在しなくなった際に、そのメタデータのみが存在している状態を可能な限り排除するため（c.f. 分散システムにおけるソフトステート管理）
may: Discovery Serviceは、地理空間検索をサポートしてもよい。地理空間属性をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持つ。
Rationale: 実世界における緯度・経度から、そこに関連したデータやサービスのメタデータを返すインデックスがユースケースによっては有用であるため。
may: Discovery Serviceにおけるメタデータ管理の一貫性要件は、Eventual Consistencyとしてもよい。
Rationale: 分散システムにおいてはスケーラビリティと障害耐性が重要であるため。Discovery Serviceに格納されるメタデータが、元のデータ/サービス提供者のメタデータとの一致性は、データ/サービスにアクセスする際に検証することで、多くの場合、問題とならない。
may: Discovery Service自体のメタデータも、前記要件と同様な形式（例：SAMMによるサービス定義）・手法で管理される。
Rationale: クライアントから統一的にアクセス可能となるため。
may: 各分野におけるDiscovery Serviceの構築は、インデックス化する属性の設定を前記メタデータ（例：SAMMによるサービス定義）を設定することで、Discovery Serviceの構築に必要な部品が構築される。
Rationale: 各分野におけるDiscovery Serviceの構築には、データベースの構築、メッセージの受理・応答などの処理が必要であるが、その多くは共通的な作業であり自動生成可能である。一方、Discovery Serviceの開発者が担うべき処理も多少存在することからテンプレートまでの生成とする。
shall: Discovery Finderは、クライアントが、Discovery Serviceにアクセスするために必要なエンドポイントの解決をするために、Discovery Service名あるいは利用する分野の名称等から、Discovery Serviceのエンドポイントを含むメタデータを返すAPIを持たなければならない。
Rationale: Discovery Serviceの宛先自体が、分野ごとに複数ありえるため、この宛先解決自体が必要となるため。
should: クライアントは、固定的にDiscovery Finderの宛先やAPIなどのメタデータ情報を予め保持していることを原則とする。
Rationale: Discovery Finderは、Open Dataspaces内にて唯一、あるいは少数の限定された数存在することを想定し、また分野ごとのDiscovery Serviceの取得が要求される頻度は高くないため、少数ノードで対応できるため。
データ/サービス提供者に関する情報を継続的に検索可能な状態とすることの指示
事業ドメインに関するデータ/サービスを提供する。複数のリソースを管理することができる。
データ/サービス提供者のデータ/サービスを利用する。
メタデータサーバ（Metadata Server）
メタデータをRDFとして公開する。Metadata Endpointで外部からの取得要求を受け付け、静的データについてはMetadata Storeから取得し、動的データについてはApplication Serverなどに随時取得しにいく。
メタデータをRDFとして格納する。主に静的データを扱う。
メタデータクライアント（Metadata Client）
メタデータを取得する。ブラウザの場合は、javascriptライブラリなど
メタデータエンドポイント（Metadata Endpoint）
Metadata ServerにおけるRDF取得エンドポイント。SPARQLエンドポイントも含む。
ディスカバリーファインダー（Discovery Finder）
どのディスカバリーサービスを用いるかを探すサービス。ディスカバリーサービスの宛先を含むメタデータが得られる。
ディスカバリーサービス（Discovery Service）
リソースの属性（緯度経度、文字列など）をもとにメタデータを検索する。メタデータには、検索対象のリソースの他に、これに関するデータ/サービス提供者のインターフェースの意味と宛先（エンドポイント）が含まれる。エンドポイントは、Metadata Endpointの他に、各サービス（予約など）のエンドポイントも含まれる。
Metadata Client ⇒ Discovery Finder
Metadata Client ⇒ Discovery Service
Discovery Serviceに登録される前の状態
Discovery Serviceに登録され、サービスの情報が検索可能となっている状態
Discovery Serviceに登録されていない状態、あるいは無効化されている状態
データ/サービス提供者に関する情報のDiscovery Serviceへの登録
データ/サービス提供者に関する情報のDiscovery Serviceからの削除
データ/サービス提供者に関する情報の作成/更新後、一定時間を経ったことを契機とする無効化
State Machine Diagram（状態遷移図） Protocol Overview（概要） 本プロトコルは ODS-RAM の DCS「Heuristic Contracting」に対応する Complementary Protocol であり、「サードパーティの電子契約アプリケーションを通じて利用条件・契約条件の定義・合意形成を支援するインターフェース（契約そのものは含まない）」を担う。
「ヒューリスティックコントラクティング（Heuristic Contracting）」プロトコル仕様書は、2026年度に公開予定である。
Clientに対して自身の代わりにResource Server（API Server）へのアクセス権限を認可（権限委譲）する主体。
Identity & Trust（L3）を運営する運営団体。
Service Providerから権限移譲を受けて、システムを利用する団体。
PEP から送信される認可判断要求を受け取り、PAP により定義されたポリシーおよびリクエストコンテキストを評価し、当該リクエストに対するアクセス可否（Permit / Deny）を決定する。
クライアントからのリクエストを受信し、必要に応じて PDP に対して認可判断を要求する。
サーバー（Identity & Trust（L3）） ⇒ クライアント
サーバー（Identity & Trust（L3））のIdPが認可コードを発行する際のメッセージ。
アクセストークンが期限切れ。リフレッシュトークンによる更新もしくは再認証が必要。
セッションまたはトークンが無効化された状態（ログアウト、失効、更新失敗など）。再認証が必要。
該当操作が許可されていない旨を通知する。なお、再送しても成功しないため再送信は行わない。
リソースが存在しない旨を通知する。なお、再送しても成功しないため再送信は行わない。
最新のデータを再取得し、競合を解消させたうえで、再送信を行う。
サポートされないリクエスト形式指定時において返却される。
正しいContent-Typeを設定し、再送信を行う。
サーバ内部において何らかの異常発生時に返却される。
継続的に発生する場合はシステム管理者へ通知を行う。なお、再送信については行った操作によって実行要否を行う。
サーバ外部において何らかの異常発生時に返却される。
一定時間ごとにリトライ（再送信）を行った後、解消しない場合は時間をおいて再操作を行うよう通知を行う。またシステム管理者へ通知を行う。
メタデータサーバ（Metadata Server）
メタデータをRDFとして公開する。Metadata Endpointで外部からの取得要求を受け付け、静的データについてはMetadata Storeから取得し、動的データについてはApplication Serverなどに随時取得しにいく。
メタデータをRDFとして格納する。主に静的データを扱う。
メタデータクライアント（Metadata Client）
メタデータを取得する。ブラウザの場合は、javascriptライブラリなど
メタデータエンドポイント（Metadata Endpoint）
Metadata ServerにおけるRDF取得エンドポイント。SPARQLエンドポイントも含む。
アプリケーションサーバ（Application Server）
データ/サービス提供者の業務アプリケーションサーバ。一般のアプリケーションサーバを含む。
アプリケーションクライアント（Application Client）
業務アプリケーションを利用するクライアント。専用ソフトウェア、あるいはブラウザ
Rationale: インターフェースの意味が曖昧では、データの受取り手やサービスの利用者が、意図しない利用になってしまうため。
shall: メタデータには、データあるいはサービス提供者が持つインターフェースの宛先情報を含まなければならない。
Rationale: 分散システムを一つのOpen Dataspaceとして透過的に見せるには、どこからでも、適切なアクセス管理のもと、そのサービスをグローバルにアクセス可能にする必要があるため。
should: メタデータは JSON-LD 形式で送受信されることを原則とする。
Rationale: Webベース実装との親和性が高く、広範な実装実績があるため。
should: データあるいはサービス提供者が、実社会における何らかの物理的・論理的な実体と関連する場合、これをメタデータとして持つことを原則とする。
Rationale: 実社会における実体と関連するサービスをネットワーク上で対応づけることが可能となるため。
should: 前記の実社会における何らかの物理的・論理的な実体が、他の提供者に関する実体と関連する場合、この参照関係をメタデータとして持つことを原則とする。
Rationale: 参照関係を辿ることで、他の提供者を発見し、システム全体の相互運用性を高めることができるため。
may: メタデータの差分を管理する機構が提供されてもよい（e.g. RDF Patch）。Eventual Consistencyを前提とするが、Lineage、タイムスタンプ、バージョン管理などで差分が管理されることが望ましい。
Rationale: 強い一貫性を必要とはしないものの、メタデータの鮮度が重要となる場合もあるため。
Aspect Modelを定義した名前空間 例：@prefix uasl: <urn:samm:com.foo.uasl:0.5.3#> .
APIを定義したドメインアプリケーションAPI定義ファイルが使用する名前空間 例：@prefix api: <https://uasl.foo.com/0.5.3/api#> .
ドメインアプリケーション用の名前空間 自社の名前空間を明示 例:@prefix inst: <http://www.example.com/uasl/instance#> .
省略のprefixは使用せずprefixはinstを使用して明示する。
ドメインアプリケーションのインスタンスは、ods:DomainApp型として定義する。
dcterms:conformsTo を使用してAspect ModelとAPI定義と明示的に紐づける。
Aspect Modelでドメインアプリケーションのプロパティとしたものは、実際の値を設定する。
ods:hasBaseEndpointを使ってAPIのベースEndpointを示す。
APIベースエンドポイントはods:BaseEndpointクラス（ods:DomainAppEndpointのサブクラス）として定義する。
ods:hasSparqlEndpointを使ってSPARQL用のEndpointを示す。
SPARQLエンドポイントはods:SparqlEndpointクラス（ods:DomainAppEndpointのサブクラス）として定義する。
ods:hasEndpointを使って各API用のEndpointを示す。
各APIエンドポイントはods:DomainAppEndpointクラス（ods:DomainAppEndpointのサブクラス）として定義する。
ods:accessURLプロパティを使って各エンドポイントのURLを示す。
特定のビジネス領域。事業ドメインごとにDiscovery Service等の共通サービスが構築され得る。
事業ドメインに関するデータ/サービスを提供する。複数のリソースを管理することができる。
データ/サービス提供者のデータ/サービスを利用する。
Metadata Client ⇒ Metadata Endpoint
Metadata Endpoint ⇒ Metadata Client
Normative Requirements（規定要件） Non-functional / Cross-layer Requirements データ/サービス提供者に関するメタデータ @graph 実社会における物理的・論理的な実体（エンティティ）と対応する、Open Dataspaces上で管理される情報。例えば、ドローンといった物理的な実体から、航路といった論理的な実体、企業間の商取引関係なども含まれる。Open Dataspaces内において、Discovery Serviceの検索対象となる。
R = Required（必須）
JSON-LD名前空間の定義。使用するボキャブラリ（dcterms, ods, serviceなど）のプレフィックスとURIを紐付ける
Discovery Serviceまたはドメインアプリケーションの定義。それらが提供するエンドポイント一覧やサービスプロバイダ名を含む
Discovery Serviceまたはドメインアプリケーションが持つ個別のAPIエンドポイント定義。各エンドポイントのURIを指定
Discovery ServiceまたはドメインアプリケーションのベースURL
ドメインアプリケーションが持つRDFサーバのSPARQLクエリを受け付けるエンドポイントのURL
検索結果：サービスインスタンスのメタデータ
インターフェース定義から、インデックス管理用のRDBテーブルを作成する
Discovery Serviceのエンドポイント(アクセスURL)を検索
検索キー：
ディスカバリーサービスのキーワード（例：UAS Lines）
事業ドメインを表すキーワード（例：ドローン、ドローン航路、ポートなど）
緯度経度の近いデータを近傍に管理することで、緯度経度情報を含む空間検索を高速に実施可能。緯度経度の範囲と、半径指定検索に対応
インターフェース定義から、メッセージ処理プログラムを生成する
Field Definitions（フィールド定義） Discovery Serviceが返却するサービスインスタンス例（航空分野のドローン航路） Discovery Finderが返却するサービスインスタンス例（航空分野のドローン航路） Functional Description（機能詳細）
コピー
{
"type": "https://api.example.com/success",
"title": "Request processed successfully",
"status": 200,
"detail": "time_stamp:2024-10-02T02:26:57.512Z, method:POST",
"data": {
"url": "https://ods.com/realms/myrealm/protocol/openid-connect/auth?client_id=myclient&response_type=code&scope=openid&redirect_uri=https%3A%2F%2Fmyapp.com%2Fhome"：認証画面URL
}
}
コピー
"login_user_id": "login_user_id_12345",
"password": "xx@&&1234Pass"
コピー
https://example.com/home?code=2c0d0237-9dc1-41da-86f3-d023ae599321.dc903c2f-9042-4940-869e-c0d753107b7f.0c395f1b-8931-467f-bf6a-db561be9742f&state=xyz123
コピー
{
"code": "2c0d0237-9dc1-41da-86f3-d023ae599321.dc903c2f-9042-4940-869e-c0d753107b7f.0c395f1b-8931-467f-bf6a-db561be9742f",：リダイレクトURIに遷移した際に付与される認可コード
"client_id": "abc123xyz",：clientごとに払い出されたID
"client_secret": "abc123xyz",：clientごとに払い出した秘密鍵
"redirect_uri": "https://example.com/home",：認可コード取得時に指定したリダイレクトURI
"code_verifier": "IevIR0cQsAuNuPha71dAbjkT-sipaqXEquPhtCqKL80"：認可コード取得時に指定したPKCE用のコードチャレンジ文字列
}
コピー
{
"type": "https://api.example.com/success",
"title": "Request processed successfully",
"status": 200,
"detail": "time_stamp:2024-10-02T02:26:57.512Z, method:POST",
"data": {
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cC...HiFZcDhzDEg",：アクセストークン
"expires_in": 300,：アクセストークンの有効期限(秒)
"token_type": "Bearer",：アクセストークンのタイプ
"not_before_policy": 0,：アクセストークンの適用開始時刻
"scope": "openid scope1 scope2",：クライアントスコープ
"refresh_token": "eyJhbGciOiJIUzUxMiIsInR5...9w67QsdnDQ",：IDPから取得したリフレッシュトークン
"refresh_expires_in": 3600,：リフレッシュトークンの有効期限(秒)
"id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI...IiwibWFuYWdlL"：IDトークン
}
}
コピー
{
"@context": { ... },
"@graph": [ ... ]
}
コピー
{
"@id": "inst:MyServiceProd",
"@type": "ods:DomainApp",
"dcterms:conformsTo": [ ... ],
"ods:hasBaseEndpoint": { ... },
"ods:hasEndpoint": [ ... ],
"ods:hasSparqlEndpoint": { ... },
"service:serviceProviderName": { ... }
}
コピー
{
"@id": "inst:xxxEndpoint",
"@type": "ods:DomainAppEndpoint",
"service:xxxRequestUri": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/api/v1/path"
}
}
コピー
{
"@id": "inst:myServiceBaseEndpoint",
"@type": "ods:BaseEndpoint",
"ods:accessURL": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/api/v1"
}
}
コピー
{
"@id": "inst:myServiceSparqlEndpoint",
"@type": "ods:SparqlEndpoint",
"ods:accessURL": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/sparql"
}
}
コピー
{
"@context": { ... },
"@graph": [ ... ]
}
コピー
http://localhost:8080/resource/aircraft/{UUID}
コピー
{
"@context": {
"dcterms": "http://purl.org/dc/terms/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"api": "https://localhost.com/v1/api#",
"inst": "http://www.example.com/myservice/instance#",
"ods": "https://github.com/ODS-DFS-L4/ods/",
"service": "urn:samm:com.uasl.service:1.1.0#"
},
"@graph": [
{
"@id": "inst:MyServiceProd",
"@type": "ods:DomainApp",
"dcterms:conformsTo": [
{
"@id": "api:UaslServiceWebService"
},
{
"@id": "service:UaslService"
}
],
"ods:hasBaseEndpoint": {
"@id": "inst:myServiceBaseEndpoint"
},
"ods:hasEndpoint": [
{
"@id": "inst:airwayReservationDetailGetEndpoint"
},
{
"@id": "inst:airwayReservationsPostEndpoint"
}
],
"ods:hasSparqlEndpoint": {
"@id": "inst:myServiceSparqlEndpoint"
},
"service:serviceProviderName": {
"@type": "http://www.w3.org/2001/XMLSchema#string",
"@value": "Service Provider Name"
}
},
{
"@id": "inst:airwayReservationsPostEndpoint",
"@type": "ods:DomainAppEndpoint",
"service:airwayReservationsPostRequestUri": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/api/v1/path"
}
},
{
"@id": "inst:airwayReservationDetailGetEndpoint",
"@type": "ods:DomainAppEndpoint",
"service:airwayReservationDetailGetRequestUri": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/api/v1/path"
}
},
{
"@id": "inst:myServiceSparqlEndpoint",
"@type": "ods:SparqlEndpoint",
"ods:accessURL": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/sparql"
}
}
]
}
コピー
{
"@context": {
"dcterms": "http://purl.org/dc/terms/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"ods": "https://github.com/ODS-DFS-L4/ods/",
"ads": "urn:samm:org.eclipse.esmf:1.0.0#",
"api": "https://airway-discovery.example.com/1.0.0/api#",
"inst": "http://airway-discovery.example.com/instance#"
},
"@graph": [
{
"@id": "inst:AirwayDiscoveryServiceProd",
"@type": "ods:DomainApp",
"dcterms:conformsTo": [
{
"@id": "ads:AirwayDiscoveryService"
},
{
"@id": "api:AirwayDiscoveryWebService"
}
],
"dcterms:description": [
{
"@language": "en",
"@value": "Production instance of Airway Discovery Service for finding and managing airway resources"
},
{
"@language": "ja",
"@value": "航路リソースの検索と管理のための航路ディスカバリーサービスの本番インスタンス"
}
],
"dcterms:title": [
{
"@language": "en",
"@value": "Airway Discovery Service - Production"
},
{
"@language": "ja",
"@value": "航路ディスカバリーサービス - 本番環境"
}
],
"ods:hasEndpoint": [
{
"@id": "inst:FindResourceEndpointProd"
},
{
"@id": "inst:RegisterDomainApplicationEndpointProd"
},
{
"@id": "inst:RegisterResourceEndpointProd"
}
],
"ods:sparqlEndpoint": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/sparql"
},
"ads:serverUrl": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/rpc-api/v1"
}
},
{
"@id": "inst:RegisterDomainApplicationEndpointProd",
"@type": "ods:DomainAppEndpoint",
"dcterms:conformsTo": {
"@id": "api:RegisterDomainApplicationAPI"
},
"dcterms:title": [
{
"@language": "en",
"@value": "Register Domain Application Endpoint"
},
{
"@language": "ja",
"@value": "ドメインアプリケーション登録エンドポイント"
}
],
"ods:endpointInformation": "JSON-RPC endpoint for registering new domain applications",
"ads:registerDomainApplicationRequestUri": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/rpc-api/v1/airway/operations"
}
},
{
"@id": "inst:RegisterResourceEndpointProd",
"@type": "ods:DomainAppEndpoint",
"dcterms:conformsTo": {
"@id": "api:RegisterResourceAPI"
},
"dcterms:title": [
{
"@language": "en",
"@value": "Register Resource Endpoint"
},
{
"@language": "ja",
"@value": "リソース登録エンドポイント"
}
],
"ods:endpointInformation": "JSON-RPC endpoint for registering new resources",
"ads:registerResourceRequestUri": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/rpc-api/v1/airway/operations"
}
},
{
"@id": "inst:FindResourceEndpointProd",
"@type": "ods:DomainAppEndpoint",
"dcterms:conformsTo": {
"@id": "api:FindResourceAPI"
},
"dcterms:title": [
{
"@language": "en",
"@value": "Find Resource Endpoint"
},
{
"@language": "ja",
"@value": "リソース検索エンドポイント"
}
],
"ods:endpointInformation": "JSON-RPC endpoint for finding resources by location and drone model",
"ads:findResourceRequestUri": {
"@type": "http://www.w3.org/2001/XMLSchema#anyURI",
"@value": "https://example.com/rpc-api/v1/airway/operations"
}
}
]
}
コピー
"@graph": [
{
"@id": "http://localhost:8080/resource/aircraft/DDDD2222-0000-0000-4444-000000000004",
"geo:hasGeometry": {
"@id": "http://localhost:8080/resource/aircraft/DDDD2222-0000-0000-4444-000000000004/geometry"
},
"publicFlag": {
"@value": "true",
"@type": "http://www.w3.org/2001/XMLSchema#boolean"
},
"ownerType": {
"@value": "1",
"@type": "http://www.w3.org/2001/XMLSchema#int"
},
"ownerId": "550e8400-e29b-41d4-a716-446655440018",
"operatorId": "DDDD2222-0000-0000-0000-0000",
"modelNumber": "B2-MD12348V1",
"modelName": "B2 Nimbus Pro V4",
"@type": "Aircraft",
"aircraftId": "DDDD2222-0000-0000-4444-000000000004",
"aircraftName": "B2ドローン",
"aircraftType": {
"@value": "3",
"@type": "http://www.w3.org/2001/XMLSchema#int"
},
"bodyWeight": {
"@value": "9.0e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"certification": {
"@value": "true",
"@type": "http://www.w3.org/2001/XMLSchema#boolean"
},
"dipsRegistrationCode": "B2-DIPS126",
"hasAircraftType": {
"@id": "http://example.com/aircraft#MultiRotor"
},
"hasOwnerType": {
"@id": "http://example.com/aircraft#OperatorOwned"
},
"latitude": {
"@value": "33.588344e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"longitude": {
"@value": "130.408585e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"manufacturer": "株式会社STU-B2",
"manufacturingNumber": "B2-MN456792",
"maxFlightSpeed": {
"@value": "65.0e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"maxFlightTime": {
"@value": "160.0e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"maxTakeoffWeight": {
"@value": "18.0e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
}
},
{
"@id": "http://localhost:8080/resource/aircraft/DDDD2222-0000-0000-4444-000000000004/geometry",
"geo:asWKT": {
"@value": "POINT (130.408585 33.588344 )",
"@type": "geo:wktLiteral"
},
"@type": "http://www.opengis.net/ont/sf#Point"
}
],
"@context": {
"geo": "http://www.opengis.net/ont/geosparql#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"@vocab": "http://example.com/aircraft#"
}
コピー
"@graph": [
{
"@id": "http://localhost:8080/resource/dronePort/DDDD2222-0000-0000-3333-000000000004",
"geo:hasGeometry": {
"@id": "http://localhost:8080/resource/dronePort/DDDD2222-0000-0000-3333-000000000004/geometry"
},
"visDronePortCompanyId": "B2-VIS126",
"updateTime": {
"@value": "2025-10-03T09:00:00Z",
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
},
"supportDroneType": "中型ドローン",
"storesAircraft": {
"@id": "http://localhost:8080/resource/aircraft/DDDD2222-0000-0000-4444-000000000004"
},
"@type": "DronePort",
"activeStatus": {
"@value": "2",
"@type": "http://www.w3.org/2001/XMLSchema#integer"
},
"address": "福岡県福岡市B2",
"altitude": {
"@value": "8.0e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"dronePortId": "DDDD2222-0000-0000-3333-000000000004",
"dronePortName": "B2福岡離着陸場",
"hasActiveStatus": {
"@id": "http://example.com/drone-port#AvailableStatus"
},
"hasPortType": {
"@id": "http://example.com/drone-port#UnmannedDronePort"
},
"latitude": {
"@value": "33.5986554e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"longitude": {
"@value": "130.4218919e0",
"@type": "http://www.w3.org/2001/XMLSchema#double"
},
"manufacturer": "株式会社MNO-B2",
"operatorId": "DDDD2222-0000-0000-0000-0000",
"portType": {
"@value": "1",
"@type": "http://www.w3.org/2001/XMLSchema#integer"
},
"publicFlag": {
"@value": "true",
"@type": "http://www.w3.org/2001/XMLSchema#boolean"
},
"serialNumber": "B2-SN789015",
"storedAircraftId": "DDDD2222-0000-0000-4444-000000000004"
},
{
"@id": "http://localhost:8080/resource/dronePort/DDDD2222-0000-0000-3333-000000000004/geometry",
"geo:asWKT": {
"@value": "POINT Z (130.4218919 33.5986554 8.0)",
"@type": "geo:wktLiteral"
},
"@type": "http://www.opengis.net/ont/sf#Point"
}
],
"@context": {
"geo": "http://www.opengis.net/ont/geosparql#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"@vocab": "http://example.com/drone-port#"
}
コピー
"@graph": [
{
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000",
"updatedAt": {
"@value": "2025-01-24T05:36:26.021Z",
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
},
"uaslName": "航路E",
"uaslId": "22222222-EEEE-0000-0000-446655440000",
"@type": "Uasl",
"belongsToUaslAdministrator": {
"@id": "http://localhost:8080/resource/uaslAdministrator/22222222-678643e0-b4d4-4d0f-866c-c441a4659be4"
},
"createdAt": {
"@value": "2025-01-24T05:36:26.021Z",
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
},
"droneId": [
{
"@value": "1",
"@type": "http://www.w3.org/2001/XMLSchema#integer"
},
{
"@value": "2",
"@type": "http://www.w3.org/2001/XMLSchema#integer"
}
],
"flightPurpose": "飛行目的-航路E",
"hasRepresentativePoint": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000/representativePoint"
},
"hasUaslPoint": [
{
"@id": "http://uasl-system-a.revitie.org/resource/uaslPoint/11111111-DDDD-0000-1111-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000004"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000001"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000002"
}
],
"hasUaslSection": [
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000002"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000001"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000004"
}
]
},
{
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000/representativePoint",
"longitude": {
"@value": "130.42092",
"@type": "http://www.w3.org/2001/XMLSchema#decimal"
},
"latitude": {
"@value": "33.597",
"@type": "http://www.w3.org/2001/XMLSchema#decimal"
},
"@type": "UaslRepresentativePoint"
},
{
"@id": "http://uasl-system-a.revitie.org/resource/uaslPoint/11111111-DDDD-0000-1111-000000000003",
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslPoint"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000004",
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslPoint"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000001",
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslPoint"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000003",
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslPoint"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000002",
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslPoint"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000003",
"connectsUaslPoint": [
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000002"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000001"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000004"
},
{
"@id": "http://uasl-system-a.revitie.org/resource/uaslPoint/11111111-DDDD-0000-1111-000000000003"
}
],
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslSection"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000002",
"connectsUaslPoint": [
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000002"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000001"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000004"
},
{
"@id": "http://uasl-system-a.revitie.org/resource/uaslPoint/11111111-DDDD-0000-1111-000000000003"
}
],
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslSection"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000001",
"connectsUaslPoint": [
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000002"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000001"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000004"
},
{
"@id": "http://uasl-system-a.revitie.org/resource/uaslPoint/11111111-DDDD-0000-1111-000000000003"
}
],
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslSection"
},
{
"@id": "http://localhost:8080/resource/uaslSection/22222222-EEEE-0000-2222-000000000004",
"connectsUaslPoint": [
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000003"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000002"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000001"
},
{
"@id": "http://localhost:8080/resource/uaslPoint/22222222-EEEE-0000-1111-000000000004"
},
{
"@id": "http://uasl-system-a.revitie.org/resource/uaslPoint/11111111-DDDD-0000-1111-000000000003"
}
],
"belongsToUasl": {
"@id": "http://localhost:8080/resource/uasl/22222222-EEEE-0000-0000-446655440000"
},
"@type": "UaslSection"
}
],
"@context": {
"geo": "http://www.opengis.net/ont/geosparql#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"@vocab": "http://example.com/uasl#"
} Open Dataspacesを介した処理における精算（Clearing）
Open Dataspacesを介した処理における課金／決済（Payment）
shall: 精算機能は、複数の証跡情報を突合して精算対象の取引実績を決定しなければならない。証跡情報は少なくとも (a) Dataspace Fundamental Services(DFS)の証跡、(b) 提供者申告、(c) 利用者申告を含まなければならない。
Rationale: データスペースの構成（連邦型・分散型）により、単一情報のみでは精算対象の正当性が担保できないため。
should: 証跡情報の (a) DFSの証跡、(b) 提供者申告、(c) 利用者申告、全て一致する場合に精算対象とすることを原則とする。
Rationale: 証跡間に矛盾が存在する場合、精算機能が自動で精算対象を確定してはならないため。
may: Industry Service(IS)の情報は、必要に応じて使用してもよい。
Rationale: 業務要件に応じた柔軟実装を許容するため。
may: 精算結果の状態は、必要に応じて定義し、管理してもよい。
Rationale: 複数の証跡情報を突合して精算対象の取引実績を決定するにあたり、状態管理の実装を許容するため。
may: 保持するデータを暗号化する場合、CRYPTRECが推奨する暗号方式等の標準的な暗号技術を、必要に応じて参照・採用してもよい。
Rationale: 運用要件に合わせた暗号化技術の採用を、検討可能とするため。
should: 決済の方式は、提供者が提示する決済方式から利用者が選択し、事前に取り決めることを原則とする。
should: 決済処理に必要な情報は、精算処理の結果を基にすることを原則とする。
may: 決済処理機能は、外部の決済サービスを活用してもよい。ただし、外部の決済サービスを選定した際には、当該サービスとの連携方法や必要な制御については、精算決済機能側でカスタマイズを行うことを原則とする。
Rationale: 業務要件に応じた柔軟実装を許容するため。また、決済サービスごとの差異を吸収し、精算決済機能としての一貫した提供を可能とするため。
may: 保持するデータを暗号化する場合、CRYPTRECが推奨する暗号方式等の標準的な暗号技術を、必要に応じて参照・採用してもよい。
Rationale: 運用要件に合わせた暗号化技術の採用を、検討可能とするため。
Transaction（L2）を介して、本機能が利用されることを前提とする。
Identity & Trust（L3）のトークンを用いて、本機能が利用されることを前提とする。
データ交換における、提供者と利用者間の各取引は、X-TrackingIDにて一意に特定できることを前提とする。
Clearing and Paymentを利用する際の、メッセージ交換シーケンスを以下に示す。
Abstract Normative Specification（抽象仕様） Concepts and Roles（概念および役割） Normative Requirements（規定要件） Non-functional / Cross-layer Requirements（非機能要件 / クロスレイヤ要件） Binding 実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。
Concrete Specification（実装例） Prerequisites（前提条件） 本プロトコルは HTTPS（TLS 1.2以上）を使用し、REST形式のHTTPリクエスト/レスポンスにより通信を行う。
エンドポイント ：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用
データ形式 ：リクエストおよびレスポンスの本文はJSON形式
認証・認可 ：OAuth 2.0ベースのトークン認証を利用
セキュリティ要件 ：TLS 1.2以上必須、暗号化通信を保証
本プロトコルで使用される各フィールドの定義を記す。
各フィールドについて、以下の情報を記す。
Request・Responseのフィールドは、以下の通り。
Request・Responseのフィールドは本プロトコルの各機能で異なるため、
Sent by・Resulting state(s)・Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装は
Loggingからのログ出力タイミングに合わせて、購入確定処理を実行する。
利用者からのデータ交換ステータスが交換完了、提供者からのデータ交換ステータスが交換完了、データ交換ログのステータスが成功、となったTransactionを請求予定額、支払い予定額の対象とする。
データ提供者が、指定したデータ利用者との取引情報について、期間・精算決済状態で絞り込み、取得する。
第1章 はじめに 「ODS 事業者向け参入ガイドブック（開発事業者向け）（本書） 」は、ソフトウェアやデータ関連サービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理することを目的とする。
本書は、個別仕様や実装手順を解説する技術書や手順書ではなく、参入判断に必要な概念理解と検討視点を提供することに主眼を置く。これらは、実際の参照実装OSSを用いて標準仕様でできることを確認しながら理解することが重要であり、構築運用ガイドブックにおいて具体例とともに扱うことを想定している。従って、本書は、その前段階として、Open Dataspacesの全体像を開発事業者の視点で理解し、どこに事業機会があり、どこから先は実装ガイドや参照実装で確認すべきかを切り分けることを目的としている。
本書でいう「開発事業者 」とは、データマネジメントやAIに関わる技術企業を幅広く含む主体である：
AIやBI（ビジネスインテリジェンス）、DI（意思決定インテリジェンス）等のホリゾンタルアプリケーションや業界特化のバーティカルアプリケーションを提供する事業者
該当操作が許可されていない旨を通知する。なお、再送しても成功しないため再送信は行わない。
リソースが存在しない旨を通知する。なお、再送しても成功しないため再送信は行わない。
最新のデータを再取得し、競合を解消させたうえで、再送信を行う。
サポートされないリクエスト形式指定時において返却される。
正しいContent-Typeを設定し、再送信を行う。
サーバ内部において何らかの異常発生時に返却される。
継続的に発生する場合はシステム管理者へ通知を行う。なお、再送信については行った操作によって実行要否を行う。
R = Required（必須）
クライアントアプリごとに払い出されたAPIKeyを指定する。ODS独自項目
アクセストークンを指定する。例：Bearer < token >
リクエストのトレーシングを行う一意なIDを指定する。ODS独自項目
コンテンツの読み込み・実行ポリシーを指定し、スクリプトやリソースの許可元を制御する。
ブラウザのMIMEタイプ推測を禁止し、指定されたContent-Typeを強制する。
Strict-Transport-Security
指定期間、HTTPS接続を強制し、HTTPへのダウングレードを防止する。
リソースのバージョン識別子を指定する。GETメソッドにおけるレスポンス時の必須項目。
リソースの最終更新日時を指定する。GETメソッドにおけるレスポンス時の必須項目。
データ利用者及びデータ提供者から、取引状態(成功/失敗)を登録する。
サービス利用に際し、価格情報となる利用料モデルに係る操作を行う。利用料モデルは、データ提供者/データ利用者/交換対象データ毎に定義するものとする。
サービス利用に際し、取引が可能かを確認する。取引可否を確認する際に、取引IDを発行して、その後の取引情報を管理する。
Field Definitions（フィールド定義） Functional Description（機能詳細） データマネジメントやAPI管理、認証・認可等のミドルウェアのマネージドサービスを提供する事業者
サービスの提供プロセスをソフトウェアとして実装し提供する事業者（Service as Software）
本書では、開発事業者がデータスペース事業への参入可否を判断するために必要な内容に焦点を当てる。判断に直接関係しない詳細な専門領域については扱わない。
開発事業者の立場から想定される参入の軸と検討ポイント
特定製品・特定ベンダーが提供するサービスに関する対応や実務
法制度に関する対応や、法務やガバナンスに関する実務
OSS（オープンソースソフトウェア）の導入手順、SDK（ソフトウェア開発キット）の利用方法
本書は、開発事業者がデータスペース事業への参入を検討するために必要な理解を、段階的に深められるよう構成している。各章で下記の内容を取り上げているので、読み進めて頂きたい。
第2章 ：産業構造の変化とOpen Dataspacesが求められる背景
第3章 ：Open Dataspacesの概念と構造、従来方式との違い
第4章 ：Open Dataspacesへの関わり方と開発事業者の検討ポイント
第5章 ：参入判断の進め方と小さく始めるための考え方
第7章 ：検討・実証・展開の各段階でのタスクと留意点
Open Data Spaces 事業者向け参入ガイドブック Open Data Spaces（ODS）について 「Open Data Spaces（ODS）」は、国や組織ごとの多様性を尊重する、オープンでスケーラブルな分散データマネジメントの技術コンセプトの名称である。 また、本書で利用する一般名称としての「Open Dataspaces」は、米国のデータスペース原著論文（Franklin et al., 2005; Halevy et al., 2006）及びデータメッシュ（Dehghani, 2019; Dehghani 2022）を中核として、民間企業・団体と連携した研究開発・商用水準での検証を経ながら設計された新世代の分散データマネジメント技術及びそれを構成する概念を指す。
（A）ODS 事業者向け参入ガイドブック（開発事業者向け）について 本書は、ソフトウェアやデータマネジメントサービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理することを目的とする。
本書は、個別仕様や実装手順を解説する技術書や手順書ではなく、参入判断に必要な概念理解と検討視点を提供することに主眼を置く。参入判断に当たっては、実際の参照実装ソフトウェアを用いて標準仕様でできることを確認しながら理解することが重要であり、「ODS技術者向け導入ガイドブック 」において具体例とともに扱うことを想定している。従って、本書は、その前段階として、ODSの全体像を開発事業者の視点で理解し、どこに事業機会があり、どこから先は開発者向けガイドや参照実装で確認すべきかを切り分けることを目的としている。
続きを読む： 第1章 はじめに
（B）ODS 事業者向け参入ガイドブック（ユーザー事業者向け）について 本書は、データマネジメントやAIサービスを利用または自社で実装する立場にある企業や行政機関等の実務者・経営企画担当者が、データスペース事業への参入を検討する際に、参入の是非・自社が担い得る役割・初期投資の置き方を判断するための視点を整理することを目的とする。
本書は、個別仕様や実装手順を解説する技術書や手順書ではなく、参入判断に必要な概念理解と検討視点を提供することに主眼を置く。これらは、実際の参照実装OSSを用いて標準仕様でできることを確認しながら理解することが重要であり、「ODS技術者向け導入ガイドブック 」において具体例とともに扱うことを想定している。従って、本書は、その前段階として、ODSの全体像をユーザー事業者(民間、公的セクター)の視点で理解し、どこに事業機会があり、どこから先は開発者向けガイドや参照実装で確認すべきかを切り分けることを目的としている。
続きを読む：
Open Data Spaces 事業者向け参入ガイドブック（開発事業者向け）の著作権は、IPA、METI、NEDOに帰属します。なお、本ガイドブックは、NEDO「ウラノス・エコシステムの実現のためのデータ連携システム構築・実証事業」における成果を基にIPAにて編纂・取り纏めたものです。 Open Data Spaces 事業者向け参入ガイドブック（ユーザー事業者向け）の著作権は、IPAに帰属します。
本ドキュメント（Open Data Spaces 事業者向け参入ガイドブック（開発事業者向け／ユーザ事業者向け））は、Creative Commons Attribution 4.0 International (CC BY 4.0) の下で提供されます。
ライセンス全文:
第3章 Open Dataspacesとは何か 3.1 Open Dataspacesの基本概念 Open Dataspacesは、企業内データ基盤の延長でも、単一企業が支配する共有プラットフォームでもない。 重要なのは、「すべてのデータをどこか一か所に集める（Push and Ingest）」ことではなく、「分散したまま、どこにあり、何を意味し、誰がどう使えるかを扱えるようにする（Serving and Pull）」ことである。
分散データマネジメントの手法としては、すでに米国などで「Data Mesh（データメッシュ）」といったアプローチが注目されており、その導入企業も増加している。しかし、Data Meshは「企業組織内に散らばったデータを、どう分散したままマネジメントするか」が焦点であり、企業や国境を横断するデータマネジメントについては、対応できていない。Open Dataspacesは、このギャップを埋めるためのアプローチである。
企業を横断するデータマネジメントには様々な課題があるが、Open Dataspacesは主に以下3点の課題に対処するための解決策を提供する：
Where to getの問題 ：データの存在・同一性・探索可能性を扱う。（例：そのデータは、そもそもどこにあるのか？そのデータは、このデータと同一のものを指し示しているのか？）
What to meanの問題 ：データの意味、語彙、意味的整合性を扱う。（例：そのデータは、何を意味しているのか？そのデータの意味は、このデータの意味と整合しているか？）
Who and How to useの問題 ：主体の信頼、アクセス、利用条件を扱う。（例：データにアクセスしようとしているのは誰か？誰がそのデータにアクセスできるのか？そのデータはどう使わなければならないか？）
これらはそれぞれ、「（1）DAD（Data Addressability and Discoverability） 」、「（2）OSI（Ontology and Semantic Interoperability） 」、「（3）IUC（Identity and Usage Control） 」の3本柱として整理されている。この3本柱の技術的詳細・設計原則・アーキテクチャへの影響については、Design PhilosophyおよびODS-RAMに体系化されている。本書では各柱の役割と開発事業者の参入余地との対応関係を整理するに留める。
従来のデータマネジメントは、自社内にデータを集約して管理・分析する発想と、必要な相手ごとに個別接続を行う発想の2つに依拠してきた。Open Dataspacesは、「集約」でも「個別調整」でもなく、分散したまま存在・意味・利用条件を扱うという別のアプローチを取る。 従来のデータマネジメントとの比較を表2に示す。より詳細な比較については、Design Philosophyを参照されたい。
表2 従来のデータマネジメントとの比較
従来、データ提供企業が外部提供をためらう理由は、単に情報漏洩リスクだけではない。 「そのデータが何を意味するかを外部に正しく伝えられない」「他社のデータと同一視されて誤用される」「利用条件を運用に落とし込みにくい」といった問題が重なっていた。 Open Dataspacesでは、データの存在や識別の問題、データの意味や語彙の問題、アクセスや利用条件の問題を分離して扱える。この分離により、データ提供企業は、自社の内部システムや内部識別子をそのまま統一することなく、必要な範囲・条件で外部提供を設計しやすくなる。
Open Dataspacesは、探索可能性、意味の整理、主体と利用条件の整理を分けて扱うことで、外部データ取得後の「意味の解釈・整合・利用条件確認」にかかる実務負荷を下げる。これにより、利用企業は外部データをBI/DI分析、業務アプリケーション、AI活用に組み込みやすくなる。
開発事業者にとっての価値は、企業横断のデータマネジメントに共通する機能をプロダクトやマネージドサービスとして切り出しやすいことにある。DAD・OSI・IUCの3つの整理は、そのまま参入余地にも対応し、各領域を独立したサービス実装対象として設計できる。
Open Dataspacesをソフトウェア市場として見た際の大きな特徴は、開発事業者がマイクロサービスとして実装に着手しやすい構造を備えていることである。Design Philosophyでは、ODSは「Minimal Yet Viable（必要最小限）」の考え方を重視し、フルスイートでの一括導入ではなく、必要な領域から段階的に導入できる構造として設計されている。 また、ODS関連の取組では仕様策定だけではなく参照実装OSS（ODS Middleware）による参照実装、開発者向けのSDK（ソフトウェア開発キット）が提供されており、開発事業者はゼロから設計・実装することなくPoC（Prrof of Concept）に着手できる。
最後に、AI産業とOpen Dataspaces市場の関係性を整理する。AI活用、とりわけ業務データを前提とした分析やAgentic AIの利用においては、単に大量のデータがあることよりも、「データの文脈、意味、利用条件、更新性」を継続的に扱えることの方が重要になる。Design Philosophyにおいても、AI時代において固有のコンテクストはデータの本質であり、ドメインオーナーがそれを明示的にオントロジーとして与えることの重要性が示されている。 Open Dataspaces技術は、こうした課題に対し、エンドポイントの検索可能性、セマンティックスやオントロジー、アイデンティティと利用制御の技術的基盤を提供する。これにより、例えば以下のような効果が期待できるであろう：
データ間の関係性や文脈を前提とした推論や解釈を行いやすくなる
データの出所や更新性を踏まえたAIパイプラインを構成しやすくなる
個別調整だけに依存せず、外部データをAI活用に組み込みやすくなる
次章では、この前提の上で、開発事業者がどのような立ち位置を取り得るのかを、参画構造の観点から整理する。
第2章 AI時代の産業構造転換とデータマネジメントの戦略的価値 2.1 日本の産業構造：ハード中心の強みと変化の兆し 日本の産業は長らく、自動車、精密機械、家電などの製造業を中心に、品質・信頼性・量産技術といったハードウェアの強みを基盤として競争力を築いてきた。これらは現在においても日本経済を支える重要な要素である。一方で、価値の形成構造は近年大きく変化している。製造時点の性能や品質だけでなく、運用段階での機能更新や外部サービスとの連携を通じて、継続的に価値が生み出される構造が一般化しつつある。こうした変化は自動車産業に限らず、多くの分野で観測されており、データやソフトウェアを活用した運用・サービスが価値競争の中心となりつつある。
2.2 世界的構造変化とプラットフォーム競争の現実 検索、OS、SNS、EC、クラウドといったデジタル領域では、利用者とデータの集積を基盤とするプラットフォーム型ビジネスが競争優位を確立してきた。利用者が増えるほどデータが蓄積され、そのデータを基にサービス改善が進み、さらに利用者が増えるというネットワーク効果が働くためである。
一方で、本書が対象とする産業データ連携の領域では、消費者向けプラットフォームとは異なる性質が支配的となる。企業間で扱われるデータは、契約条件、責任分界、機密性、規制対応といった前提を伴い、単一主体による集中的な管理や囲い込みが必ずしも合理的とはならない。。国立研究開発法人 新エネルギー・産業技術総合開発機構（NEDO）の調査*1によれば、このような産業データに係るアプリケーションおよびミドルウェアを中心とするデジタル関連市場は今後も拡大が見込まれており、2040年時点では国内で約30兆円規模、グローバルでは約200兆円規模に達すると予測されている。
2.3 「データはあるのに使えない」構造的問題とデータアクセス能力 AI活用を含む価値創出では、「どのデータを保有しているか」以上に、必要なデータへ適切な条件でアクセスできるか（データアクセス能力）が競争力を左右する。しかし多くの企業では外部データ活用が十分に進んでいない。背景は個社の努力不足ではなく、構造的な要因にある。データ連携が進まない構造的課題の詳細はDesign Philosophyに体系化されている。本書では、これらの課題が存在するという前提のもとで議論を進める。
次章では、Open Dataspacesが従来のデータマネジメント体系とどのように異なるのかを整理し、開発事業者が理解すべき機能構造について確認していく。
脚注
*1 NEDO. (2025). データスペース市場規模調査及びインパクトモデリング・シナリオ分析 調査報告書.
ODS-RAMをもとに分散データマネジメントを実現する機能を提供し、Open Dataspacesの相互運用性を担保する一連の技術的な取り決め
ODS 事業者向け参入ガイドブック（ユーザー事業者向け）
データマネジメントやAIサービスを利用または自社で実装する立場にある企業や行政機関等の実務者・経営企画担当者が、データスペース事業への参入を検討する際に、参入の是非・自社が担い得る役割・初期投資の置き方を判断するための視点を整理
ODSを採用・導入またはサービス提供する立場にある技術者を対象に、その技術的な全体像と基礎を理解し、設計・実装・運用に着手する
自社内部スキーマで管理し、意味と構造が一体化しやすい
構造から意味（セマンティクス・オントロジー）を分離して扱う（OSI）
アイデンティティ、アクセス、利用条件を明示的に扱う（IUC）
3.3 Open Dataspacesが提供する価値 3.4 開発事業者から見たOpen Dataspacesマーケットの特徴 3.5 AIとOpen Dataspacesの関係性 
