本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。
データスペースについて、これまで別々の系統を触ってきました。
- Ocean Node に Compute-to-Data の実行環境を建て、アクセス制御が効くことを確認する（Ocean 系）
- Pontus-X の公開カタログを curl で覗く（Ocean 系）
- Pontus-X の参加者一覧を API で調べる（Ocean 系）
- データスペースは結局なにが嬉しいのか ── 自作ツールの出力を「渡さず解析」させてみた（EDC 系。EDC の上で Compute-to-Data を組んだ回）
Ocean 系（Pontus-X / Clio-X）と EDC 系（Eclipse Dataspace Components）を、それぞれ手元で動かす機会がありました。並べてみると、同じ言葉で呼ばれているものが、実はかなり違うことが分かります。
本記事では、どこまでが共通で、どこからが別物なのかを整理します。
結論から
共通するのは 記述と基準の体系（Gaia-X の語彙と資格情報）
違うのは データの流し方 — カタログの API・契約のやりとり・データの渡し方
共通の空席は その資格情報を誰が発行するのか
Gaia-X は実装ではなく、記述と基準の体系です
まず混乱しやすい点から。Gaia-X はソフトウェアの実装ではありません。Compliance Document を見ると、次のような章立てになっています。
Compliance Rules
Overarching Rules
Compliance for Participants 参加者
Compliance for Cloud Services クラウドサービス
Compliance for Data Exchange Services データ交換サービス
Criteria assessment methods 評価の方法
Gaia-X Trust Anchors 誰の署名を信じるか
Annexes: Label format / Process ラベルの形式など
参加者だけでなく、サービスやデータ交換サービスにも基準があります。記述のための語彙も定めており、たとえばサービスを表す gx:ServiceOffering には、誰が提供し（gx:providedBy）、どんな条件で使わせ（gx:servicePolicy）、利用規約は何か（gx:serviceOfferingTermsAndConditions）を書く欄があります。
ここは版によって名前が変わる部分です。上は現行のオントロジー（https://w3id.org/gaia-x/development#）の名前で、一世代前の Trust Framework では gx:policy / gx:termsAndConditions でした。SHACL シェイプを取得して属性名を数え直さないと、古い記事のコピーで詰まります。
定めていないのは、データそのものの転送方式です。信頼の側の手順は、むしろかなり細かく決まっています。
| Gaia-X が定めるか | |
|---|---|
| 参加者・サービスの記述と適合基準 | 定める |
| 適合性の水準（SC / L1 / L2 / L3） | 定める |
| 語彙とその検証（SHACL シェイプ） | 定める |
| トラストアンカー | 定める |
| 資格情報の発行・提示の手順 | 定める（OID4VCI / OID4VP） |
| ポリシーの記述形式 | 定める（ODRL） |
| データ製品の記述形式 | 定める（DCAT-3） |
| カタログへの問い合わせ API | 定めない |
| データの転送方式 | 定めない |
Architecture Document は、資格情報のやりとりに OpenID Connect for Verifiable Credentials（OID4VCI / OID4VP）を使うと書き、ポリシーには ODRL を、データ製品の記述には DCAT-3 を必須としています。Compliance Engine への入力も application/vp+jwt とメディアタイプ単位で決まっています。
つまり「Gaia-X は記述と基準だけ」というのは言いすぎで、信頼の手順までは決めていて、データの運び方は決めていない、という切り分けが正確です。だから同じ Gaia-X の語彙と信頼の手順の上に、別々のデータ流通方式が載ります。
Pontus-X の場合、参加の条件は公式のオンボーディング手順にこう書かれています。法人であること、登録番号（VAT ID・EORI・LEI などの法人識別子）とドメイン検証による身元確認を運営者が行うこと。そして Gaia-X Trust Framework への完全準拠は「任意だがネイティブに対応している」とされ、必須の関門ではありません。
つまり Gaia-X への適合は、Pontus-X に参加するための前提ではなく、参加したうえで選べる対応の一つ、という位置づけです。
何が共通で、何が違うか
| 共通か | Ocean 系 | EDC 系 | |
|---|---|---|---|
| Verifiable Credentials の形式 | 共通 | W3C VC | W3C VC |
| トラストアンカー | 共通 | eIDAS / EV SSL | eIDAS / EV SSL |
| Gaia-X の適合性証明 | 共通しうる | 対応（任意） | 繋げられる |
| カタログの形式 | 違う | DDO | DSP の Catalog |
| 契約のやりとり | 違う | datatoken の購入 | 契約交渉（negotiation） |
| 認可の判定（既定） | 違う | オンチェーンのトークン保有 | 提示された VC を評価 |
| データの渡し方（標準） | 違う | 動かさない C2D を内蔵 | 転送する（Transfer Process） |
上 3 行が共通で、下 4 行は別物です。プロトコルとしては、そのままでは繋がりません。Ocean 側は DSP を実装しておらず、DSP 側の適合性試験の対象でもありません。ただしこれは「両者を繋ぐ製品が存在しない」という意味ではなく、上位のアプリケーションが両方に対応する形の橋渡しは公にあります。
なお Ocean 側は C2D 専用ではありません。DDO の services.type には access（ダウンロード型）と compute（C2D）があり、公開カタログを数えた回ではダウンロード型が 7 割を占めていました。表の「動かさない」は Ocean が内蔵している特徴的な選択肢を指すものとして読んでください。
「データを動かさない」は規格が決めることではありません
ここは私自身が取り違えていた点です。
「データを渡さずに計算させる」はデータスペースの代名詞のように語られますが、これはプロトコルが定めていることではありません。Ocean は Compute-to-Data という名前でこれを機能として内蔵しており、EDC の DSP は逆に、転送を前提にした工程（Transfer Process）を標準として持ちます。差は「どちらを既定に置いているか」です。
ただし「EDC では渡さない構成が作れない」わけではありません。実際、冒頭に挙げた EDC 系の回では EDC の上でそれを組みました。解析エンジンを提供側の内部ネットワークに隔離して利用者から直接届かないようにし、契約と EDR トークンという唯一の経路でだけ実行させ、外に出るのは結果とパラデータだけで、生データを返す口をそもそも用意しない。渡さない側にするなら、提供側の作り込みで成立します。
EDC には Transfer Process という工程があり、名前のとおりデータを転送します。手元の Minimum Viable Dataspace（EDC 公式の最小構成の参照実装）で試したときも、契約交渉のあとに実データを取得しています。
transfer process : STARTED
EDR : endpoint=http://dataplane.provider.../api/public
data : provider の Public API から実データ（JSON 配列）を取得成功
では何が共通なのか。「条件付きで使わせる」という契約の構造です。
カタログに載せる 何があるかを公開する
条件を規則として書く 機械が読める形にする
判定してから渡す 条件を満たすか確かめる
記録する 誰に何を許したかを残す
データを動かすか動かさないかは、この上に載る選択肢のひとつです。
認可の根拠がまるで違う
実際に両方で「誰に見せるか」を書いてみると、差がはっきりします。
Ocean 系では、既定のアクセス許可はオンチェーンのトークンです。データを使う権利を表す datatoken（ERC-20）を持っているか、アクセス権の一覧である AccessList（ERC-721）に載っているか。判定は「持っているか、いないか」の二値です。
ただしこれは既定の話です。Ocean Node には認可の判断を外部の HTTP サーバに委ねる Policy Server という仕掛けがあり、そこで Verifiable Credentials の提示を条件にできます。Gaia-X の適合性証明を Ocean の認可に差し込んだ回では、許可リストに載っている本人でも証明を出さなければ 403 になりました。以下は既定の挙動として読んでください。
EDC 系では、提示された Verifiable Credentials をポリシーの評価式で走査します。アーカイブの利用許諾を書いてみたところ、判定の軸は 3 つ、それを当てる門が 2 段になりました。
判定の軸（評価式 3 本）
Membership データスペースの現メンバーか
Clearance 閲覧資格が general か restricted か（階層あり）
ClosurePeriod 寄贈者と合意した期間が明けたか（時計だけで判定）
門が 2 段
目録に出るか（カタログに載せる条件）
申請が通るか（契約を結ぶ条件）
門が 2 段あることで、「目録には載るが、閲覧はできない」が表現できたのが要点でした。アーカイブでは普通の状態ですが、既定の二値の判定では書けません。
記録の公開性が逆になる
もうひとつ、性質が逆になる点があります。
Ocean 系 誰がトークンを持っているかは、チェーンを読める全員に見える
EDC 系 提示は当事者間のやりとりで、第三者からは見えない
Pontus-X は参加に条件がありますが、読み取りは公開されています。参加者一覧を返す API は認証なしで応答し、2026 年 8 月 9 日の時点で 665 件を取得できました。ここでの 665 は登録レコードの数であって、参加している組織の数ではありません（同じ組織が複数のレコードを持ちます。一意な法人名は 471 でした）。いずれにせよ、参加のハードルと、閲覧のハードルは別だということです。
アーカイブの文脈に置き換えると、「誰がこの資料への閲覧権を持っているか」がチェーンを読める全員に見える、ということになります。アドレスと個人の対応が分からなければ直ちに個人は特定されませんが、一度でも対応が漏れれば遡れます。
ただしこれは「オンチェーンなら必ず公開」という話ではありません。今回読めたのは、そのコントラクトが履歴を平文で出し、参照用の関数も公開していたからです。Pontus-X の基盤は暗号化されたやりとりを扱える系統のチェーンでもあるので、公開されるかどうかは置き方の帰結として見るのが正確です。
共通して空いている席
そして、両方に同じ穴が空いています。
| 誰が発行するのか | |
|---|---|
| Ocean 系 | AccessList のトークンを誰が発行するか |
| EDC 系 | 閲覧資格の資格情報を誰が発行するか |
Ocean 系の実装では、学術認証フェデレーションを通じて認証し、そこからトークンを発行する構想が示されていますが、その発行の仕組み自体は作られておらず、手作業で発行されています。
EDC 側でも同じでした。アーカイブ用の規則を書いて検証したところ、手元にある資格情報で代用した構成では 5 件すべてが意図どおり動きました。ところが、アーカイブが本来使うはずの語彙のままで走らせると、4 件のうち確かに裏が取れたのは 2 件だけです。
Membership 許可の向きで確認できた
ClosurePeriod 拒否の向きだけ確認できた（許可の向きは代用版でしか見ていない）
Clearance 確認できない ── 拒否されたが、資格情報が無ければ何であれ同じ結果になる
閲覧資格の規則は、拒否されたこと自体が正しさの証拠になりません。その型の資格情報を発行する主体が存在せず、提示しようがないからです。
技術を替えても、この席は移動するだけで埋まりません。
触れていないもの
- IDS（International Data Spaces）や Catena-X といった、他のデータスペースの系統。ただし日本の実装についてはウラノスの ODS を手元に建てた回で扱いました
- Ocean 側と EDC 側を実際に相互接続する試み。本記事はそれぞれを別々に動かした結果です
- Gaia-X の適合性証明を EDC 側の認可条件に繋ぐこと。Ocean 側では試しましたが、EDC 側では未着手です
- 性能や運用コストの比較
まとめ
- Gaia-X は実装ではなく、記述と基準の体系。資格情報のやりとり（OID4VC）やポリシーの書き方（ODRL）まで決めているが、データの運び方は決めていない
- 共通しているのは Verifiable Credentials の形式・語彙・トラストアンカーまで
- カタログ・契約・認可・データの渡し方は別物で、プロトコルとしてはそのまま繋がらない
- 「データを動かさない」は規格が決めることではない。Ocean は C2D を内蔵し、EDC は転送を標準にしている。EDC でも提供側で作り込めば「渡さない」構成になる
- 共通しているのは「条件付きで使わせる」という契約の構造のほう
- 認可の記録の公開性は逆向き。ただし「オンチェーンだから公開」ではなく、そう置いたから公開になっている
- どちらにも「誰が資格情報を発行するのか」という席が空いたままになっている
出典
- Gaia-X Architecture Document ── OID4VCI / OID4VP、ODRL、DCAT-3、Registry の API、Compliance Engine の入出力形式
- Gaia-X Compliance Document ── 参加者・クラウドサービス・データ交換サービスの適合基準、トラストアンカー
- Pontus-X Onboarding Guide ── 参加条件と、Gaia-X Trust Framework への準拠が任意である旨
- Ocean Protocol DDO Specification ──
services.typeのaccessとcompute - Ocean Protocol Architecture ── datatoken（ERC-20）と data NFT（ERC-721）の役割の違い
- Dataspace Protocol Specification ── Catalog・Contract Negotiation・Transfer Process
- EDC Policy Engine ── ポリシー評価が拡張として実装される仕組み
本記事は、複数のエージェントによるファクトチェック（一次資料との照合・実測の再現・既発表記事との整合）を経て修正したものです。とくに「Gaia-X は通信の手順を定めない」「Ocean は C2D、EDC は転送」という当初の書き方は、いずれも一次資料と自分の過去の記録に照らして不正確だったため書き直しています。
コメント
…