> For the complete documentation index, see [llms.txt](https://open-dataspaces.gitbook.io/ods-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://open-dataspaces.gitbook.io/ods-docs/jp/introductory-guide/kegaido/03-ods-basics.md).

# 第3章 Open Dataspacesとは何か

## 3.1 Open Dataspacesの基本概念

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

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

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

1. **Where to getの問題**：データの存在・同一性・探索可能性を扱う。（例：そのデータは、そもそもどこにあるのか？そのデータは、このデータと同一のものを指し示しているのか？）
2. **What to meanの問題**：データの意味、語彙、意味的整合性を扱う。（例：そのデータは、何を意味しているのか？そのデータの意味は、このデータの意味と整合しているか？）
3. **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に体系化されている。本書では各柱の役割と開発事業者の参入余地との対応関係を整理するに留める。

## 3.2 従来のデータマネジメントとの違い

従来のデータマネジメントは、自社内にデータを集約して管理・分析する発想と、必要な相手ごとに個別接続を行う発想の2つに依拠してきた。Open Dataspacesは、「集約」でも「個別調整」でもなく、分散したまま存在・意味・利用条件を扱うという別のアプローチを取る。 従来のデータマネジメントとの比較を表2に示す。より詳細な比較については、Design Philosophyを参照されたい。

**表2 従来のデータマネジメントとの比較**

| 観点            | 個別API連携        | 企業内データ基盤                   | Open Dataspaces                    |
| ------------- | -------------- | -------------------------- | ---------------------------------- |
| データの配置        | 接続先ごとに個別に扱う    | 自社内に集約して扱う                 | 分散したまま扱う                           |
| 探索            | 接続先や仕様を知っている前提 | 社内カタログを前提                  | 特定可能性・探索可能性を前提とする（DAD）             |
| 意味の扱い         | 個別実装に依存する      | 自社内部スキーマで管理し、意味と構造が一体化しやすい | 構造から意味（セマンティクス・オントロジー）を分離して扱う（OSI） |
| アイデンティティと利用制御 | 個別契約・個別実装に依存   | 社内権限管理が中心                  | アイデンティティ、アクセス、利用条件を明示的に扱う（IUC）     |

## 3.3 Open Dataspacesが提供する価値

### 3.3.1 データ提供企業にとっての価値

従来、データ提供企業が外部提供をためらう理由は、単に情報漏洩リスクだけではない。 「そのデータが何を意味するかを外部に正しく伝えられない」「他社のデータと同一視されて誤用される」「利用条件を運用に落とし込みにくい」といった問題が重なっていた。 Open Dataspacesでは、データの存在や識別の問題、データの意味や語彙の問題、アクセスや利用条件の問題を分離して扱える。この分離により、データ提供企業は、自社の内部システムや内部識別子をそのまま統一することなく、必要な範囲・条件で外部提供を設計しやすくなる。

### 3.3.2 データ利用企業にとっての価値

Open Dataspacesは、探索可能性、意味の整理、主体と利用条件の整理を分けて扱うことで、外部データ取得後の「意味の解釈・整合・利用条件確認」にかかる実務負荷を下げる。これにより、利用企業は外部データをBI/DI分析、業務アプリケーション、AI活用に組み込みやすくなる。

### 3.3.3 開発事業者にとっての価値

開発事業者にとっての価値は、企業横断のデータマネジメントに共通する機能をプロダクトやマネージドサービスとして切り出しやすいことにある。DAD・OSI・IUCの3つの整理は、そのまま参入余地にも対応し、各領域を独立したサービス実装対象として設計できる。

## 3.4 開発事業者から見たOpen Dataspacesマーケットの特徴

Open Dataspacesをソフトウェア市場として見た際の大きな特徴は、開発事業者がマイクロサービスとして実装に着手しやすい構造を備えていることである。Design Philosophyでは、ODSは「Minimal Yet Viable（必要最小限）」の考え方を重視し、フルスイートでの一括導入ではなく、必要な領域から段階的に導入できる構造として設計されている。 また、ODS関連の取組では仕様策定だけではなく参照実装OSS（ODS Middleware）による参照実装、開発者向けのSDK（ソフトウェア開発キット）が提供されており、開発事業者はゼロから設計・実装することなくPoC（Prrof of Concept）に着手できる。

## 3.5 AIとOpen Dataspacesの関係性

最後に、AI産業とOpen Dataspaces市場の関係性を整理する。AI活用、とりわけ業務データを前提とした分析やAgentic AIの利用においては、単に大量のデータがあることよりも、「データの文脈、意味、利用条件、更新性」を継続的に扱えることの方が重要になる。Design Philosophyにおいても、AI時代において固有のコンテクストはデータの本質であり、ドメインオーナーがそれを明示的にオントロジーとして与えることの重要性が示されている。 Open Dataspaces技術は、こうした課題に対し、エンドポイントの検索可能性、セマンティックスやオントロジー、アイデンティティと利用制御の技術的基盤を提供する。これにより、例えば以下のような効果が期待できるであろう：

* データ間の関係性や文脈を前提とした推論や解釈を行いやすくなる
* データの出所や更新性を踏まえたAIパイプラインを構成しやすくなる
* 個別調整だけに依存せず、外部データをAI活用に組み込みやすくなる

次章では、この前提の上で、開発事業者がどのような立ち位置を取り得るのかを、参画構造の観点から整理する。