🗂️Gaia-X Registry には何が入っているのか ── 公開 API で中身を確かめる

本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント・一次情報と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

アイデンティティ・ウォレットの 4 つの機能と、学認のトラストアンカーで、学認では「名簿に署名する 1 本の鍵」が信頼の出発点になっていることを見ました。同じ役割を Gaia-X ではどこが担っているのかを、公開 API から実際に取得して確かめます。取得はすべて 2026-08-12 に行ったもので、認証は不要でした。

Gaia-X 全体の位置づけについてはGaia-X の Lighthouse プロジェクトとはも参照してください。

Registry は何を受け持っているか

Gaia-X で適合性証明を得るまでには、いくつかのサービスが順に関わります。参加者はまず、自分の法人情報やサービスの内容を決められた語彙で記述し（Self-Description と呼ばれます）、自分の証明書で署名して提出します。これを受け取る窓口が GXDCH (Gaia-X Digital Clearing House) で、その中に、法人登記番号を確認する Notary、記述の形と署名を審査して証明を発行する Compliance、そしてその判断材料を配る Registry があります。

窓口が 1 か所ではなく複数の事業者によって運用されている点が、この仕組みの特徴です。どの窓口を使っても同じルールで審査されるように、ルールとスキーマと信頼の根を Registry が一元的に配っています。

Registry 自身は誰かの適合性を判断しません。判断するのは Compliance で、Registry はその材料を配ります。公開されている API の一覧は次のとおりです。

curl -s https://registry.gaia-x.eu/v1/docs-json | python3 -c 'import sys,json;d=json.load(sys.stdin);[print(m.upper(),p) for p,v in d["paths"].items() for m in v]'

GET /v1/api/complianceIssuers
GET /v1/api/termsAndConditions
POST /v1/api/trustAnchor
POST /v1/api/trustAnchor/chain
POST /v1/api/trustAnchor/chain/file
GET /v1/api/trusted-issuers
GET /v1/api/trusted-issuers/{serviceType}
GET /v1/api/trusted-shape-registry/v1/shapes
GET /v1/api/trusted-shape-registry/v1/shapes/implemented
GET /v1/api/trusted-shape-registry/v1/shapes/jsonld/{key}
GET /v1/api/trusted-shape-registry/v1/shapes/{key}
GET /v1/api/trusted-schemas-registry/v2/schemas
GET /v1/api/trusted-schemas-registry/v2/schemas/{key}
GET /v1/trusted-schemas-registry/v2/schemas/{key}

最後の 1 本だけ /v1/api/ を経由しない旧形式のパスが残っています。同じ応答の info を見ると、サービス名は gx-registry、バージョンは 1.10.5 でした。

curl -s https://registry.gaia-x.eu/v1/docs-json | python3 -c 'import sys,json;print(json.load(sys.stdin)["info"])'

実際に返ってくるもの

以下は 4 つのエンドポイントを順に叩いた結果です。返ってくるのは窓口のホスト名、署名してよい DID (Decentralized Identifier、分散識別子)、記述の形、規約の本文でした。

正規の窓口の一覧

curl -s https://registry.gaia-x.eu/v1/api/trusted-issuers

3 系統に分かれて返ってきます。取得時点で registry が 11 件、compliance が 11 件、registration-notary が 12 件でした。

registry:
  registry.lab.gaia-x.eu/v1
  gx-registry.airenetworks.es/v1
  gx-registry.arsys.es/v1
  gx-registry.aruba.it/v1
  gx-registry.gxdch.dih.telekom.com/v1
  www.delta-dao.com/registry/v1
  registry.gxdch.gaiax.ovh/v1
  aerospace-digital-exchange.eu/registry/v1
  gx-registry.gxdch.proximus.eu/v1
  portal.pfalzkom-gxdch.de/v1
  registry.cispe.gxdch.clouddataengine.io/v1

compliance と registration-notary も、同じ事業者がそれぞれのパスで並んでいます。クラウド事業者や通信事業者が自分のドメインで窓口を運用していることが読み取れます。

適合性証明に署名してよい DID

curl -s https://registry.gaia-x.eu/v1/api/complianceIssuers

["did:web:compliance.gaia-x.eu"]

窓口は複数の事業者に分散していますが、適合性証明に署名する主体としてここに載っているのは 1 件でした。学認で言えば「メタデータ署名者の証明書」に相当する位置にあるものです。

記述の形（シェイプ）

curl -s https://registry.gaia-x.eu/v1/api/trusted-shape-registry/v1/shapes/implemented

["LegalParticipant","ServiceOffering","legalRegistrationNumber","GaiaXTermsAndConditions",
 "SOTermsAndConditions","PhysicalResource","VirtualResource","DataResource","LegitimateInterest",
 "SoftwareResource","InstantiatedVirtualResource","ServiceAccessPoint","ServiceOfferingLabelLevel1",
 "ServiceOfferingCriteria","CriteriaResponse","CriteriaEvidence"]

16 種類です。シェイプ (shape) は、提出された記述が満たすべき制約を機械可読に書いたもので、「このフィールドは必須」「この値は URI でなければならない」といった条件が書かれています。参加者 (LegalParticipant)、サービス (ServiceOffering)、資源 (DataResource / SoftwareResource など) といった、審査の対象になる概念がここで固定されています。裏を返すと、この一覧に無い概念は Gaia-X の適合性審査の語彙としては扱われません。個別のシェイプは SHACL (Shapes Constraint Language、RDF = Resource Description Framework のデータに対する制約を記述する W3C 勧告) の形式でも取得できます。なお、これとは別に trusted-schemas-registry という語彙側のエンドポイントもありますが、ここでは扱いません。

利用規約

curl -s --http1.1 https://registry.gaia-x.eu/v1/api/termsAndConditions

{"version":"22.10","text":"The PARTICIPANT signing the Self-Description agrees as follows:\n- to update its descriptions about any changes, be it technical, organizational, or legal …"}

参加者が同意する文言そのものが API から取れます。手元で発行した資格情報でも、参加者側の自己記述がこの版の規約を参照していました。

なお、termsAndConditions と complianceIssuers は取得時にしばしば 503 や 421 (Misdirected Request) が返りました。同じコマンドを間隔をあけて再実行すると取得できたので、記事中の応答は取得できたときのものです。421 は HTTP/2 のコネクション再利用に起因するようで、上のように --http1.1 を付けたほうが成功率が高い傾向がありました。

証明書の「根」は何か

Registry には trustAnchor 系のエンドポイントがあり、提出された証明書の連鎖が信頼できる根に届くかを検証します。ここで受け入れられる根は Gaia-X の Compliance Document で規定されていて、24.11 版では次のようになっています。

• EEA（欧州経済領域）、アイスランド、リヒテンシュタイン、ノルウェー: eIDAS 規則 (EU) No 910/2014 に基づく適格トラストサービスプロバイダ
• インド: eMudhra
• 韓国: KTNET
• アラブ首長国連邦: PASS
• 上記のような指定が Registry に無い国については、Extended Validation (EV) SSL 証明書で属性に署名することが認められている

いずれも、事業者の登記・所在地・電話番号の確認などを含む KYB / KYC（Know Your Business / Know Your Customer、法人と個人の確認手続き）を経て証明書を発行している主体であることが条件として書かれています。文書ではこの 3 つは "such as, and not limited to" の例示であり、受け入れ対象の一覧自体も "non-exclusive list" と明記されています。

日本については国別の指定が載っていないため、日本法人が署名する場合は最後の一般規定にあたる EV SSL 証明書の経路になると読めます。手元では許可リストに載っている本人が、ダウンロードできない ── Gaia-X の適合性証明を Ocean の認可に差し込むに書いた検証環境を組んでいますが、そちらは自己署名の証明書でローカルに完結させているので、本番の窓口に通す場合はここが追加の作業になります。

学認との対比

	学認	Gaia-X Registry
配っているもの	参加エンティティの名簿（650 件）	正規の窓口・シェイプ・規約・信頼の根の判定
個々の参加者は載るか	載る	載らない
信頼の出発点	自己署名の署名者証明書 1 枚	各国の適格トラストサービスプロバイダなど
誰が運用するか	国立情報学研究所 (NII)	Gaia-X の枠組みのもとで複数の事業者

もっとも、この 2 つは別の軸です。適合性証明そのものに署名する主体は 1 件で、学認の署名者証明書に近い位置にあります。一方、参加者が提出する証明書の連鎖をどこまでさかのぼって信じるかが、上の「信頼の根」にあたります。

方向がやや違います。学認は「参加者の名簿」を配り、Gaia-X Registry は「審査の材料」を配ります。Gaia-X で参加者そのものを一覧したい場合は、Registry ではなく各データスペース側の仕組みを見ることになります。

Pontus-X との関係

上の一覧に www.delta-dao.com/registry/v1、同じく compliance と notary のパスが並んでいます。Pontus-X を運営している deltaDAO が GXDCH の窓口を運用していて、その窓口が Gaia-X 側の正規の一覧に載っている、という関係です。

したがって「Pontus-X では deltaDAO が承認機関か」という問いへの答えは、二段構えになります。適合性証明を発行する窓口としては deltaDAO が運用している一方、審査のルールと、その署名主体としてどの DID を認めるかは Gaia-X 側の枠組みで決まっています。上で見たとおり、complianceIssuers に載っているのは did:web:compliance.gaia-x.eu の 1 件です。

一方、Pontus-X というデータスペースに参加者として加わるかどうかは、また別の層です。以前Pontus-X の参加者一覧を API で調べるで確認した範囲では、Pontus-X 側ではオンボードされた参加者に Identity Issuer NFT (0xCe1750f8…) が発行され、テストトークンの配布口はその保有を見て可否を判定していました。Gaia-X の適合性証明とは別に、エコシステム独自の名簿が動いていることになります。

まとめると、層ごとに「誰が決めるか」が分かれています。

層	決めている主体
資格情報の形	W3C
適合性のルールと署名主体	Gaia-X の枠組み
適合性審査の窓口	各国の事業者（Pontus-X の文脈では deltaDAO）
データスペースへの参加	各データスペースの運営

出典

• Gaia-X Registry (registry.gaia-x.eu) — 本文の応答はすべて 2026-08-12 に取得
• Gaia-X Trust Anchors — Gaia-X Compliance Document 24.11
• gx-registry（ソースコード）