2.1 日本の産業構造：ハード中心の強みと変化の兆し

日本の産業は長らく、自動車、精密機械、家電などの製造業を中心に、品質・信頼性・量産技術といったハードウェアの強みを基盤として競争力を築いてきた。これらは現在においても日本経済を支える重要な要素である。一方で、価値の形成構造は近年大きく変化している。製造時点の性能や品質だけでなく、運用段階での機能更新や外部サービスとの連携を通じて、継続的に価値が生み出される構造が一般化しつつある。こうした変化は自動車産業に限らず、多くの分野で観測されており、データやソフトウェアを活用した運用・サービスが価値競争の中心となりつつある。

2.2 世界的構造変化とプラットフォーム競争の現実

検索、OS、SNS、EC、クラウドといったデジタル領域では、利用者とデータの集積を基盤とするプラットフォーム型ビジネスが競争優位を確立してきた。利用者が増えるほどデータが蓄積され、そのデータを基にサービス改善が進み、さらに利用者が増えるというネットワーク効果が働くためである。

一方で、本書が対象とする産業データ連携の領域では、消費者向けプラットフォームとは異なる性質が支配的となる。企業間で扱われるデータは、契約条件、責任分界、機密性、規制対応といった前提を伴い、単一主体による集中的な管理や囲い込みが必ずしも合理的とはならない。。国立研究開発法人 新エネルギー・産業技術総合開発機構（NEDO）の調査*1によれば、このような産業データに係るアプリケーションおよびミドルウェアを中心とするデジタル関連市場は今後も拡大が見込まれており、2040年時点では国内で約30兆円規模、グローバルでは約200兆円規模に達すると予測されている。

2.3 「データはあるのに使えない」構造的問題とデータアクセス能力

AI活用を含む価値創出では、「どのデータを保有しているか」以上に、必要なデータへ適切な条件でアクセスできるか（データアクセス能力）が競争力を左右する。しかし多くの企業では外部データ活用が十分に進んでいない。背景は個社の努力不足ではなく、構造的な要因にある。データ連携が進まない構造的課題の詳細はDesign Philosophyに体系化されている。本書では、これらの課題が存在するという前提のもとで議論を進める。

次章では、Open Dataspacesが従来のデータマネジメント体系とどのように異なるのかを整理し、開発事業者が理解すべき機能構造について確認していく。

脚注

*1 NEDO. (2025). データスペース市場規模調査及びインパクトモデリング・シナリオ分析 調査報告書.

1.1 本書の目的

「ODS 事業者向け参入ガイドブック（開発事業者向け）（本書）」は、ソフトウェアやデータ関連サービスを提供する事業者が、データスペース事業への参入を検討する際に、参入の是非、自社が担い得る役割、初期投資の置き方を判断するための視点を整理することを目的とする。

本書は、個別仕様や実装手順を解説する技術書や手順書ではなく、参入判断に必要な概念理解と検討視点を提供することに主眼を置く。これらは、実際の参照実装OSSを用いて標準仕様でできることを確認しながら理解することが重要であり、構築運用ガイドブックにおいて具体例とともに扱うことを想定している。従って、本書は、その前段階として、Open Dataspacesの全体像を開発事業者の視点で理解し、どこに事業機会があり、どこから先は実装ガイドや参照実装で確認すべきかを切り分けることを目的としている。

1.2 想定読者

本書でいう「開発事業者」とは、データマネジメントやAIに関わる技術企業を幅広く含む主体である：

• AIやBI（ビジネスインテリジェンス）、DI（意思決定インテリジェンス）等のホリゾンタルアプリケーションや業界特化のバーティカルアプリケーションを提供する事業者

• データマネジメントやAPI管理、認証・認可等のミドルウェアのマネージドサービスを提供する事業者

• サービスの提供プロセスをソフトウェアとして実装し提供する事業者（Service as Software）

• 事業会社における新規事業責任者や技術企画担当

本書では、開発事業者がデータスペース事業への参入可否を判断するために必要な内容に焦点を当てる。判断に直接関係しない詳細な専門領域については扱わない。

• Open Dataspacesの基本概念

• 開発事業者の立場から想定される参入の軸と検討ポイント

• 小さく始めるための実務的な観点

• 設計思想やアーキテクチャパラダイムの解説

• 特定製品・特定ベンダーが提供するサービスに関する対応や実務

• 法制度に関する対応や、法務やガバナンスに関する実務

• ドメイン・業界別のユースケースの要件や分析、戦略

参照すべき関連ドキュメントは表1のとおりである。

表 1 参照先

本書は、開発事業者がデータスペース事業への参入を検討するために必要な理解を、段階的に深められるよう構成している。各章で下記の内容を取り上げているので、読み進めて頂きたい。

• 第2章：産業構造の変化とOpen Dataspacesが求められる背景

• 第3章：Open Dataspacesの概念と構造、従来方式との違い

• 第4章：Open Dataspacesへの関わり方と開発事業者の検討ポイント

分散データマネジメントにおいては、ドメインオーナーであるデータ提供者に対して、どの機能・責務を補完的に担い得るかという観点でステークホルダーを整理することが重要である。 ODS-RAM では、相互運用性を、特定技術や製品ではなく「プロトコルの組み合わせ」として定義している。ファンダメンタルプロトコルは、すべてのOpen Dataspacesで共通に成立すべき最低限の枠組みを示し、コンプリメンタリプロトコルは、用途や成熟度に応じて採用される拡張領域を示す。 これを踏まえて、機能別に役割を整理すると、大まかには表3のように示すことができる。

表 3 ODSにおけるサービス主体種別

5.1 参入検討の出発点（GTM戦略の策定）

Open Dataspaces技術を活用したサービスは、単に新しい技術やプロトコル仕様への対応そのものを目的とするものではない。 まず何よりも、分散データマネジメントにより事業としてどのような価値が生まれ得るのかに着目する必要がある。

5.2 参入パターンを構成するGTM戦略の整理軸

個社のGTM戦略は、どの課題に関与するか、どの機能範囲を担うか、どこまで価値提供に踏み込むかといった選択の組み合わせとして定めていく必要がある。 本節では、参入形態を組み立てるためのGTM戦略における4つの整理軸を示していく。

（1）対象となる顧客（ICP）

第一の整理軸は、「理想的な顧客像（ICP：Ideal Customer Profile）」の設定である。 大まかには、データ提供者・データ利用者・仲介者（マネージドサービスやサードパーティアプリケーションの提供者）の3つに集約される。同じ機能でも、どのようなICPを設定するかで、価値の言語化・価格設計・責任境界が変わる。

（2）ICPが抱える課題への関与単位

第二の整理軸は、ICPが抱える課題（ペイン）の解像度の高い特定である(表5)。「Where to getの問題（DAD）」「What to meanの問題（OSI）」「Who and How to useの問題（IUC）」のどのペインにソリューションを提供するかを選択し、GTM戦略とプライシングモデルを決定する。関与範囲の取り方によって、専門特化型の参入や包括的な参入など、必要となるGTMモーションが変化する。 また、フェーズという観点で顧客課題を整理することも有効である：

表 5 導入フェーズごとの顧客の課題

第三の整理軸は、ODS-RAMにおける機能範囲のどの部分をソフトウェアとして担うかである。 プロトコルに近いほど運用責任が大きくなる一方、アプリケーションサイドではドメイン知識や業務理解が差別化要因となる。

最後の軸は、どこまでを自社の提供責務（SLA）として引き受けるかである。 プロトコルを実装した機能提供までか、運用・監視・更新対応まで含めたマネージドサービスとするか、利用設計や改善支援まで支援するか、によってGTMモーションが変わる。

本節では、前節で整理した参入パターンの考え方を具体化するため、代表的な3つの事業例を示す：

データディスカバリー、セマンティクス管理、アイデンティティ管理、利用制御など、ODS Protocolsで定義される機能をソフトウェアとして実装し、データ利用者や提供者に対し、それらをマネージドサービス（あるいは、自社運用のためのオンボーディング支援サービス）として提供する参入形態。 ファンダメンタルプロトコルのみをマネージドサービスとして提供するパターンや、コンプリメンタリプロトコルをサードパーティアプリケーションとして提供するパターン、それらの組み合わせなどが想定される。

データモデリング、意味付与、更新管理などを含め、データそのものの整備に必要となる工数に対するサービスをソフトウェアとしてデータ提供者に対して提供する形態。

Open Dataspacesを通じて取得した外部データを活用し、特定業界向けのAIやBI、DIアプリケーションをデータ利用者にサードパーティサービスとして提供する形態。

本節では、開発事業者が実際に参入の是非を判断するための現実的な材料を整理する。 ここで示す内容は精緻な事業計画を立てるためのものではなく、「この参入は自社にとって現実的か」「どの程度の体制・リソースが必要か」を見極めるための目安である。

参入パターンによって、必要となる投資規模や実装の難易度は大きく異なる。以下は一般的に想定でき得る傾向であり、個別条件によって前後し得る点に留意されたい。

• プロトコル実装のマネージドサービス: 仕様や標準規格への理解と実装対応が前提。単一コンポーネントのPoCはエンジニア数名・数ヶ月程度から着手可能なケースもあるが、本格展開には専門チームを前提とした中長期投資が必要となる。

• データを中心としたサービスのソフトウェア提供: 顧客単位での段階的着手がしやすい。提供データの品質保証・責任分界・契約モデルの整理といった非技術的要素の抽象化がスケーリングを左右する。

• インダストリーサービスとしてのアプリケーション: Open Dataspaces技術の実装負荷自体は相対的に低いが、顧客価値の設計と成果責任の比重が高くなる。

技術的な運用を確認するPoCに加え、参入判断においては「ビジネスとして意味があるか」を検証する視点が不可欠である。 コスト削減効果・価値創出効果によるROI、リードタイム、データドリブンアプローチの有用性について、自社なりの仮説と数値感を持てるかどうかが、本格参入に進むか否かを判断する一つの目安となる。

次章では、これらの参入戦略を前提として、ODS Protocolsを実装する際の基本的な考え方を整理する。

また、参入判断においては、技術的な成立性だけでなく、ビジネス価値の仮説検証が重要となる。 次章では、これらの参入戦略を前提として、Open Dataspaces技術を実装する際の基本的な考え方を整理する。

Open Dataspacesは、企業内データ基盤の延長でも、単一企業が支配する共有プラットフォームでもない。 重要なのは、「すべてのデータをどこか一か所に集める（Push and Ingest）」ことではなく、「分散したまま、どこにあり、何を意味し、誰がどう使えるかを扱えるようにする（Serving and Pull）」ことである。

分散データマネジメントの手法としては、すでに米国などで「Data Mesh（データメッシュ）」といったアプローチが注目されており、その導入企業も増加している。しかし、Data Meshは「企業組織内に散らばったデータを、どう分散したままマネジメントするか」が焦点であり、企業や国境を横断するデータマネジメントについては、対応できていない。Open Dataspacesは、このギャップを埋めるためのアプローチである。

企業を横断するデータマネジメントには様々な課題があるが、Open Dataspacesは主に以下3点の課題に対処するための解決策を提供する：

1. Where to getの問題：データの存在・同一性・探索可能性を扱う。（例：そのデータは、そもそもどこにあるのか？そのデータは、このデータと同一のものを指し示しているのか？）

8.1 本書のまとめ

本書が扱ってきた内容は、Open Dataspacesという新たな分散データマネジメントパラダイムを理解するための概念整理にとどまらず、開発事業者がどのように関連事業に参入し、どの領域で価値を発揮できるかを実務的に整理することであった。

第2章では産業構造の変化とOpen Dataspacesが求められる背景を整理し、第3章でODSの基本概念と3本柱（DAD・OSI・IUC）の意義を示した。 第4章では役割構造とサービスモデルを示し、第5章では参入戦略の4つの整理軸と参入パターンを整理した。 第6章では構築フェーズに向けた考え方を整理し、第7章では検討・実証・展開（GTM）というステージ別の進め方を提示した。 本書が示したのは「万能なアーキテクチャ」でも「唯一の正解」でもない。開発事業者が直面しやすい迷いどころを体系的に整理し、判断のための土台を提供することに焦点を置いた。

8.2 Open Dataspacesは接続の積み重ねである

Open Dataspacesという言葉は大規模な国家的基盤のような印象を与えがちであるが、実際には個別の主体間の接続や個別PoCの積み重ねによって形成される。 そのため、開発事業者が取り組むべき最初のステップは、自社の強みを反映した小さな構成要素を安定的に提供することである。 インターネットがそうであったように、Open Dataspacesでは「大きなものに参加する」のではなく、各社の小さな成果が集まって大きな構造が形成されるものである。

8.3 責任境界の明確化が参入成功の鍵となる

本書を通じて繰り返し示したのは、「どこまで作るか」以上に「どこまで作らないか」を明確にする重要性である。 運営主体が担う領域、ODS Middlewareが担う領域、他社が補完する領域、自社が実装する領域、将来追加する領域を分け、それぞれの境界を明確にすることが参入の成功を左右する。

8.4 小さな参入が大きなエコシステムを形成する

第7章で示したように、Open Dataspaces導入は段階的に進む。 自社アセットの棚卸し、担当するビルディングブロックの決定、最小構成PoCの設計と評価など、初期の取り組みはすべて参入行為である。たとえ小規模であっても、PoCの成功はOpen Dataspacesにおける信頼形成の第一歩であり、次の展開につながる実績となる。

8.5 AI時代におけるODS開発事業者の役割

AIの高度化により、データへのアクセス、品質、意味的整合性がこれまで以上に重要となった。大量のデータよりも、適切に取り扱われたデータへの継続的アクセスが価値の源泉となる。 Open Dataspacesはその前提を実現するための仕組みである。開発事業者は、データが安全に移動するための技術基盤の整備、意味的整合性や品質を支える仲介機能の提供、利用条件や契約の制約を技術的に反映する仕組みの実装、Open Dataspacesを利用するアプリケーションの開発、という役割を担う。

Open Dataspacesは複雑に見えるが、本質は提供・利用というシンプルな営みの集合である。開発事業者が最初の一歩を踏み出すために必要なのは次の三点である：

• 自社が担う最小単位を定めること

• 初期段階で全てを実装しようとせず、小さく進めること

• 他主体との接続を通じて学習し、段階的に拡張すること

本書で示した考え方やステップは、迷いを減らし、最初の接続や初期PoCを現実的に進めるための支援を目的としている。Open Dataspacesは、誰かが一括して構築する巨大基盤ではなく、参加する主体の取り組みが積み重なって形成されるエコシステムである。 本書が、みなさんの検討や準備を支える一助となり、Open Dataspaces活用の可能性を見いだす契機となれば幸いである。

• 独立行政法人情報処理推進機構. (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: 設計思想とアーキテクチャパラダイム. 独立行政法人情報処理推進機構.

6.1 本章の位置付けとねらい

本章は、第4章で整理したOpen Dataspacesにおけるサービス提供の構造、ならびに第5章で整理した参入パターンを前提として、ODS Protocols実装のマネージドサービス及びデータを中心としたサービスのソフトウェアを提供する主体が、技術的な実装に着手する際に押さえておくべき基本的な考え方を整理するものである。

6.2 サービスの構築フェーズにおける全体像

サービスの構築フェーズに進むにあたり、開発事業者は次の観点を整理しておく必要がある：

• 自社が担う関与形態（Fundamental/Complementary/Industry、またはその組み合わせ）

• プロトコルによる規律領域と設計の裁量がある領域との切り分け

• 参照実装OSS（ODS Middleware）活用と自社開発部分の切り分け

• 非機能要求と運用設計の基本観点を含めたサービス構築スコープの明確化

「ODS Protocols（ODP）」は、参加者間の相互運用性を成立させるために必要な役割分担や手続き、主体間のやり取りの構造を定義するものである。「どのような振る舞いが求められるか」という外形的な枠組みを示す一方で、具体的な技術スタック・内部コンポーネントの構成までを固定するものではない。

重要なのは、「プロトコルが示すのは外部との整合が必要な振る舞いであり、内部構成までを固定するものではない」という理解である。この切り分けを明確にすることで、外部との相互運用性を確保しながら、自社の差別化領域に開発リソースを集中させることが可能となる。

プロトコルを実装するための基本的なコンポーネントについては、ODSの開発コミュニティが擁する参照実装OSS（ODS Middleware）を活用することで、実装負荷を軽減しつつ相互運用性を確保しやすくなる。

一方で、業務固有のロジック、運用を支援する管理機能、分析や可視化などの付加価値領域は、自社の強みを活かした実装対象となる。OSSをマネージドサービスとして提供する際には、どの部分をOSSに依存し、どの部分を自社の責任範囲として保持するかというSLAを明確に設計する必要がある。 また、プロトコルやOSSの更新に追随できるよう、マイクロサービスアーキテクチャを採用することが設計指針として示されている。

サービス提供では、非機能要求と運用設計が重要な位置を占める。可用性や拡張性は分散データマネジメントの継続性に直結する。また、監査性や可観測性も重要であり、データのトランザクション履歴やプロセスを追跡可能な形で記録し、必要に応じて参照できることは、ガバナンスやトラストを技術的に支える基盤となる。セキュリティについてはOpen Dataspaces固有の要件に加え、通信の暗号化や鍵管理、脆弱性対応といった一般的な標準との整合を前提とする。

サービスの構築において開発事業者が特に意識すべき要点は、次の三点に整理できる：

• プロトコルによって規律される領域と、自社裁量で設計できる領域を混同しないこと

• ODS Middleware活用と独自実装の境界を明確にし、更新追随や交換可能性を意識した構造とすること

• 非機能要求と運用設計を、実装の後工程ではなく初期段階から構築スコープに含めること これらの観点は、Design Philosophyに示された設計指針3原則（①ベンダーロックインの回避、②制度的ロックインの回避、③Product-likeなサービス志向の設計）とも対応する。

本章で整理した観点は、次章で扱う導入ステージ別の検討や実践に直結する基盤となるものである。

7.1 導入ステージ別整理の考え方

本章では、Open Dataspacesのサービス導入を「検討・実証・展開（GTM）」の3ステージに分け、各ステージで何を確認し、どこまで整理すべきかを示唆する。 表6に導入ステージ別の検討・実施内容を示す。

表 6 導入ステージ別の検討・実施内容

これらは厳密に分離された工程ではなく、事業環境やユースケースに応じて往復しながら進むこともある。 重要なのは、各ステージで整理すべき観点を明確にし、技術と事業の成立性の双方を段階的に確認していくことである。

検討ステージは、第5章で整理した参入パターンを前提として、実際の構築スコープに落とし込むフェーズである。 「何を作り、何を作らないか」を具体化することが目的となる。

実証ステージでは、最小構成（MVP）で「技術・事業・運用が成立するか」を確認する。 目的は完成度を上げることではなく、外部と整合が必要な領域と自社の任意領域が分離された設計で、運用まで含めて回る見通しを得ることである。

GTMステージは、実証ステージで確認した成立性を前提として、ミドルウェアを継続的に提供・運用可能なプロダクトへと移行する段階である。 標準仕様の更新、運用要件の変化、対象データスペースや業界の拡張に耐えられる構造を備えているかが問われる。

ODS開発者コミュニティが提供するOSSは、複数の運用環境で再利用されることを前提としたプロダクトである。本節では、検討・実証・展開のいずれのステージでも共通して意識すべき設計上の注意点を整理する。ミドルウェア開発において特に重要となる注意点は次の通りである：

• 運用要件を内部構造に固定しない（資格情報形式・ログ要件等はOpen Dataspaceごとに異なるため設定や外部連携として扱う）

• 共通処理と任意機能を混在させない（相互認証・転送プロセスなど必須処理と、契約処理・仲介機能など任意処理は分離）

• 利用条件の表現形式に依存しない構造にすること

• 複数モーダルのデータ転送方式を前提とすること（API・ストリーミング・バルク転送等）

次章では、本書全体を通じて整理してきた内容を踏まえ、データスペース関連事業参入を検討する開発事業者にとっての考え方を総括する。