本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント・一次情報と照合していますが、誤りが含まれている可能性があります。特に法令の解釈部分は法的助言ではありません。重要な判断を行う前にご自身でも一次情報をご確認ください。
「データスペース」「Compute-to-Data」という言葉は、聞くだけだと抽象的です。私は理解のために、自作の映像アノテーションツールの出力を題材にして、実際に EDC(Eclipse Dataspace Components) ベースの検証環境で「データを渡さずに解析させる」ところまで動かしてみました。本記事は、その過程で腑に落ちたこと ── 単体の API と何が違うのか / IIIF の認可と何が違うのか / どういうデータでこそ嬉しいのか ── を、動かして確かめた範囲で正直に整理したものです。
やったこと（デモの全体像）
題材は、ある公開映像（1906年サンフランシスコ、パブリックドメイン）に対して自作ツールが生成したシーン記述・看板OCR・地理手がかりなどのメタデータ（1フレーム=1ドキュメント、計14件）です。これを「コーパス」として解析エンジンに渡し、共起ネットワークを計算させます。
ポイントは、解析エンジンが返すのが result（解析結果）と paradata（来歴）だけで、原文（生データ）を取り出すエンドポイントが存在しないことです。これが Compute-to-Data ──「データのある場所で計算し、結果だけ返す。生データは提供者の管理下に留まる」── の中核です。
単体の API と「契約経由」は何が違うのか
同じデータ・同じ解析でも、実行経路を2通り用意して比べました。
実際の画面がこちらです。左が単体、右が契約経由。同じ共起ネットワークが返るのに、右上と右パネルの「契約ID」が null から実値に変わっているのが分かります。
実際の操作を短い動画（約34秒・字幕つき・音声なし）にしました。左が消費側クライアント、右の端末が実際に走る Dataspace Protocol（カタログ取得→契約交渉→transfer→一度きりの EDR トークン→provider 経由で実行）です。単体（契約ID null）→契約経由（契約IDが実値に）と切り替わり、右で「裏側」の手続きが確認できます。なお この試作では利用者の認証（VC）は未配線（requester.vc = null）で、本番のデータスペースは参加者認証が必須です（＝Pontus-X のオンボーディングがまさにそれ）。
「CtDゲートウェイって、ただのAPIでは？」への答え
見た目は普通の HTTP+JSON API です。特別なのは**「何を返さないか」を設計で保証している**点です。
- 生データを返すエンドポイントが無い。返るのは結果と来歴だけ。
- 実行できる解析は公開・固定の一覧で、各アルゴリズムが「返すもの／返さないもの」を宣言している。
- k-匿名性・マスキング・重複除去といった開示制御がパイプラインに常時組み込まれている。
そして契約経由（右側）では、解析エンジンが利用者から直接到達できない隔離ネットワークに置かれ、「カタログ→契約交渉→transfer→一度きりの通行証(EDRトークン)→提供側の公開API」という唯一の経路でしか実行できません。返ってきた来歴に契約ID（agreementId）が刻まれるのは、その結果が特定の契約に束縛されて生成されたことの証跡です。
逆に言えば、単体（左）は門番が無く、いまは誰でも叩けます。「データを渡さない」こと自体は単体でも成立しますが、「誰が・どの契約で実行したか」を来歴に刻み、隔離された経路に閉じ込める“門番”の層こそが、データスペースが足すものです。
正直な限界：この検証環境では、要求者の資格情報(VC)の検証や、ODRL ポリシーの厳密な強制、改ざん耐性ログ(Merkle)への実アンカーはまだ未配線です（来歴では該当欄が null のまま）。契約交渉が成立して
agreementIdが付くところまでは本物ですが、「制約を満たさない相手を実際に弾く」強制はこれからの範囲です。
IIIF Authorization API とどう違うのか
デジタルアーカイブに馴染みがあると、この「認可してから触らせる」構図は IIIF Authorization API に似て見えます。実際、構造は近い。でもデータの流れが正反対です。
IIIF Authorization Flow API（2.0）は、probe service で状態を確認し、access service で認証、access token service でトークンを取り、そのトークンでコンテンツ本体（画像・AV のバイト）を取得してクライアント側で表示します。認可判定を専用サービスに分けている点は洗練されていますが、最後にはデータ本体が利用者の手元に渡る（データが動く）モデルです。
Compute-to-Data は逆で、本体を渡さず、アルゴリズムをデータ側に送り、結果だけ返す（データは動かない）。
一言でいうと、IIIF Auth は「正しい人に“閲覧”させる」認可、Compute-to-Data は「本体を渡さず“解析”させる」仕組み。両者は競合ではなく補完で、「原資料の配信は IIIF Auth、解析は Compute-to-Data」という組み合わせも自然です。なお両者に共通するのは「制御（認可）の経路と、実データの経路を分ける」という設計思想で、そこは似ています。
（用語の注：access service/probe service は IIIF Auth 2.0 の呼称です。1.0 では login/clickthrough/kiosk/external という別体系の interaction pattern が使われます。「open」というアクセス段階は存在しません。）
で、これは誰が得をするの？ お金は？
ここは誤解しやすいので、事実関係を分けて整理します（一次情報で確認した範囲）。
- EDC ソフトウェア自体には「中間で手数料を取る中央運営者」がいません。Eclipse Foundation の OSS で、各参加者が自分のコネクタを自分で建てる（セルフホスト）。契約成立後はコネクタ同士がピアツーピアで交換します。
- ただし、現実のデータスペースには運営主体がいます。たとえば Catena-X は、オンボーディングやID発行を担うオペレーティングカンパニー（Cofinity-X 等）が別途存在し、ガバナンスを担う協会（Catena-X Association、会費は売上規模に応じ年額 €2,000〜€15,000+ のティア制）があります。立ち上げ原資はドイツ連邦経済・気候保護省(BMWK)や EU の公的資金。
- EDC 自体は決済しません。支払いは契約(ODRL)の義務として記述しうるものの、実際の決済は帯域外／別サービスです。
- つまり「お金」は主に会費＋公的原資の層で発生し、データ流通1件ごとに中央がトールを取る構造ではない。
そして「この“真ん中の信頼・決済のプラミング”を分散化しようとしているのが Pontus-X（Ocean、Web3）」という理解は妥当です。カタログ・アクセス権・清算をオンチェーン化し、アクセス権を Data NFT / Datatoken で表し、Oasis Sapphire（機密性を持つ EVM）上のスマートコントラクトで動かし、決済まで内蔵しようとしています。
| 観点 | EDC ベース（非ブロックチェーン） | Pontus-X / Ocean（Web3） |
|---|---|---|
| ソフトウェア | Eclipse の OSS・セルフホスト。中央のトール徴収者なし | Ocean/Oasis の OSS＋スマートコントラクト |
| お金の発生点 | 協会の会費＋公的原資（例：Catena-X €2k〜€15k/年） | Datatoken 売買・オンチェーン決済の手数料 |
| 決済 | EDC 外（帯域外／別サービス） | チェーン上で内蔵（EU 規制ステーブルコインを志向） |
| 誰が得をするか | インフラ提供者・運営会社・会費で回る協会。提供/利用者は主権を保持 | データ提供者（Datatoken 収益）、インフラ・決済プロバイダ |
注：トークンは役割ごとに分けて理解する必要があります。ネットワークの gas/手数料および現行の支払いトークンは EURAU（発行体 AllUnity、BaFin 規制の e-money。testnet faucet も EURAU を配布）。一方、カタログ上の既存アセットの価格建てには EUROe（別発行体 Membrane Finance）も多く使われています（カタログ記事 で実測。EUROe は旧 gas トークンで現在は非推奨）。両者は発行体も役割も異なるので混同に注意。初期はモックのステーブルコインでテストしていた経緯もあり、「決済が本番稼働している」と断言するのは避けたほうが安全です。また Pontus-X も Gaia-X の準拠性ガバナンスの傘の下にあり、「完全にコンソーシアムを排した分散化」ではなく「プラミングだけをオンチェーン化」というのが実態です。
いちばん大事な話：公開データでは、そこまで嬉しくない
ここまで動かして、正直に言うと 今回の題材（パブリックドメイン映像＋公開メタデータ）では、データスペースを使う必然性はほとんどありません。公開データなら、そのまま IIIF で見せて各自ダウンロードして解析してもらえばよく、門番も契約もオーバースペックです。
データスペースの利点（主権・秘匿）が効くのは、**「渡せない／渡したくないデータ」**のときです。私のドメイン（映像アーカイブ・史料）に引きつけると、たとえば：
- 著作権保護中の映像。日本の著作権法は、第30条の4で「思想又は感情の享受を目的としない」利用（情報解析＝多数の情報から抽出・比較・分類その他の解析を行うこと、を含む）を、原則として著作権者の許諾なく行えると定めています。ここで重要なのは、本体を「視聴・鑑賞できる態様」で第三者に渡すと『他人に享受させることを目的』に該当し、30条の4の射程を外れること。さらに「著作物の種類・用途・利用の態様に照らし著作権者の利益を不当に害する場合」は但し書きで除外されます。だからこそ、本体を渡さず、サーバ側で解析して結果だけ返す Compute-to-Data は、享受目的性と市場競合の両リスクを下げる方向に働き、30条の4の趣旨に沿わせやすい設計だと言えます（※これは設計論であって、「30条の4により適法」と断定できるものではありません。個別のケースは専門家にご確認ください）。
- 個人情報を含む記述・史料（実在人物・所在など）。マスキング・k-匿名性・アクセス契約が要る。
- 先住民・文化的制約のある資料。同意・権利管理を保ったまま解析だけ許す（これはまさに Web3 系のアーカイブ応用が動機に掲げている領域です）。
ただし公平のために付け加えると、公開データでもデータスペースに残る価値はあります ── 来歴・信頼（誰が出した本物か）、共通メタデータによる相互運用・発見可能性、そして大容量データを動かさずに計算する効率。「主権・秘匿」軸での利点が相対的に小さいだけで、ゼロではありません。
まとめ
- Compute-to-Data は「データを動かさず、結果だけ返す」。生データは提供者に留まる。
- 単体 API と契約経由（DSP）の違いは、門番（契約に束縛された唯一の経路と、それを刻む来歴）の有無。今回、同じ結果でも契約ID が
null→ 実値へ変わるところまで動かせた。 - IIIF Authorization API は「閲覧させる」認可（最後は本体を渡す）。Compute-to-Data は「渡さず解析させる」。補完関係。
- お金は主に会費＋公的原資の層で発生し、EDC 自体は決済しない。その信頼・決済を分散化するのが Pontus-X（Web3）。
- そして判断軸はシンプル：そのデータは渡せるか？ 渡せるなら公開で十分。渡せないデータでこそ、データスペースは初めて必要になる。
次は、この「渡せないデータ」側 ── 実際にマスキングが効く、制限付きコーパスでの挙動 ── を確かめて続報にしたいと思います。
本記事の解析エンジン・クライアントUI・データスペース基盤は、標準規格（IIIF / W3C Web Annotation / Dataspace Protocol / ODRL / PROV-O 等）に基づく自作の検証環境です。図は rough.js による自作、画面は実際の動作を撮影したものです。
コメント
…