DID/VCは何を使って実装する？主要OSSの開発元、導入事例、選び方
はじめに
DID/VCの規格を理解したら、次は修了証を発行してみたい。 前回の記事では、W3C VC、SD-JWT VC、mdocで、同じ修了証の表し方と検証方法がどう変わるかを比較した。 ところが、実装を探すと今度はwalt.id、Procivis One、Credo、Multipazと、別の名前が並び始める。 規格の名前を覚えたと思ったら、次は製品名である。
これらは、公開されたソースコードをライセンスの条件に従って利用・改変できるOSS（オープンソースソフトウェア）であり、サーバーとして起動して使うものもあれば、自分のアプリへ組み込んで使うものもある。 同じDID/VCの実装でも自分たちで作る範囲が変わるため、今回は開発元と利用例を確認しながら、システムのどの部分を任せられるのかを紹介する。
発行・保管・検証をAPIで試す候補がwalt.idとProcivis One Core。TypeScriptで処理を組み込む候補がCredo、スマホの鍵管理やmdocの提示を調べる候補がMultipazである。EUDIPLOとEUDI Wallet参照実装も含め、各ソフトウェアの役割と、この連載での使い方を紹介する。2026年10月6日の公開資料を確認したもので、今回の環境で各OSSを起動して接続試験を行った結果ではない。
発行者、ウォレット、検証者のどこを作るのか？
研修会社が修了証を発行し、受講者が保管して採用企業へ提示するためには、研修会社の発行サービス、受講者のウォレット、採用企業の検証サービスを用意し、それぞれの間で証明を受け渡せるようにする必要がある。
| 役割 | 修了証サービスで行う処理 | 業務システム側に残る判断 |
|---|---|---|
| 発行者 | 修了情報から証明を作り、署名してウォレットへ渡す | 受講を終えたか、誰へ発行するか |
| ウォレット | 証明と鍵を管理し、利用者の操作に応じて提示する | 何を誰に見せるかを、利用者が判断できる画面と運用 |
| 検証者 | 受け取った証明の署名、期限、必要な属性などを調べる | その研修会社と研修内容を、自社の採用条件として認めるか |
証明をウォレットへ発行する手順がOpenID4VCI、ウォレットから相手へ提示する手順がOpenID4VPであり、W3C VCやSD-JWT VC、mdocという証明の形式と組み合わせて使う。 これらの規格で証明を受け渡せるようになっても、誰が研修を修了したかは研修会社が確認し、その研修を採用条件として認めるかは採用企業が判断するため、受講管理や合否判定は業務システム側に残る。
API基盤とSDKの違い
API基盤であれば、業務システムからHTTPなどでAPIを呼び出して証明の作成やウォレットとの通信を依頼するため、既存のシステムのプログラミング言語を選ばず利用することが可能だ。一方、SDK（Software Development Kit）はアプリに組み込んで使うライブラリや開発用の道具で、鍵の生成や証明の受領・提示などを自分のプログラムから呼び出し、画面や保存方法をアプリに合わせて実装する際に使うもので、組み込む側のプログラミング言語と基本的には同じものを選ぶことが必要であるが、API通信のオーバーヘッドがないため、実行速度や通信条件、トランザクションなどの考慮がよりAPIよりも少ない。
また、各OSSはAPIとSDKのどちらか一方だけを提供しているわけではないのもややこしいところではあるが注意したい。例えばwalt.idにはライブラリやスマホアプリがあり、Procivisにも組み込み用のSDKがある。またCredoやMultipazでサーバー側を実装することもできるため、選定する際は、自分たちが作るシステムのどの処理に使うのかを考える必要がある。要するに、まだこのDID/VCという世界ではとりあえず、これを使えという決定的なOSSはまだ出ていないというのが2026年10月現在では現状である。
主要なDID/VCのOSS
今回紹介する六つには、発行や検証を処理する基盤、アプリへ組み込むSDK、構成を学ぶための参照実装が含まれており、連載で接続を試すために使うOSSでも、自社サービスの基盤として採用することは可能である。 そこで、ソフトウェアとして何ができるかと、この連載でどう使う予定かを分けて表にまとめた。
| OSS・参照実装 | 開発元・背景 | ソフトウェアの役割 | この連載での使い方 |
|---|---|---|---|
| walt.id Community Stack | オーストリア・ウィーンに本社を置くwalt.id。CommunityとEnterpriseの製品を展開 | 発行・保管・検証のAPI、ライブラリ、アプリ | 同じ修了証を使い、APIで発行から検証まで試す |
| Procivis One Core | スイスのProcivis AG。Orell Füssliの子会社 | 発行・保有・検証を担うCore APIと組み込みSDK | walt.idと比較し、主教材を選ぶ |
| Credo | Hyperledger Aries Framework JavaScriptから発展。OpenWallet Foundationのプロジェクトで、Animoなどが開発に参加 | Node.jsやReact Nativeに証明の処理を組み込むTypeScriptのフレームワーク | アプリのコードで発行・提示・検証の処理を追う |
| Multipaz | Googleが始め、OpenWallet Foundationへ寄贈 | スマホやサーバーでmdocやSD-JWT VCを扱うSDK | スマホの鍵管理、近接・オンライン提示を調べる |
| EUDIPLO | Mirko Mollikを中心に開発。OpenWallet Foundationで育ち、現在のREADMEはLF Decentralized Trustのプロジェクトと記載 | 業務システムとウォレットの間で発行・提示の通信を担う基盤 | 外部ウォレットとの接続を試す |
| EUDI Wallet参照実装 | 欧州委員会 | 欧州のデジタルIDウォレットの構成を示すアプリ・ライブラリ・サーバー | 実装方法を学び、修了証を受け取るウォレットの候補として試す |
たとえばEUDIPLOは自社サービスの発行・検証基盤として使えるので、連載ではこれを業務システム側に置き、外部ウォレットとの接続を試す予定である。 EUDI Wallet参照実装は、欧州のウォレット構成を学ぶためのコードとして読むとともに、修了証を受け取る側の候補としても使ってみたい。
表に何度か登場したOpenWallet Foundation（OWF）は、Linux Foundationの傘下でウォレットに使うOSS部品を共同開発する場であり、W3CやIETFが共通の仕様を策定するのに対して、その仕様を使うコードの開発が行われている。
2026年9月1日の公式発表では、OWFは2027年1月1日付でLF Decentralized Trustへ加わる予定とされているが、既存プロジェクトの運営体制や技術委員会、憲章は維持されると説明されている。
walt.id：発行から検証までをAPIで試す
walt.idは、発行者、ウォレット、検証者のAPIに加え、それらを作るライブラリとアプリを公開しており、Community StackのREADMEには、W3C VC、SD-JWT VC、mdoc/mDLと、OpenID4VCI・OpenID4VPを扱う構成が示されている。 ここでいうmDLはモバイル運転免許証のことで、mdocを使う代表的な文書種別だ。
今回の修了証であれば、研修会社のシステムから発行APIを呼び、受講者がウォレットへ受け取った証明を、採用企業側の検証APIで確かめる構成を試せるため、まず証明が三者の間をどう渡るのかを理解するのに使いたい。 誰が研修を修了したかを判断する処理や、採用条件との照らし合わせは業務システム側で作り、証明の作成や受け渡し、検証の処理をwalt.idへ任せるという分担になる。
開発元はウィーンに本社を置く企業で、公開コードを自分の環境で運用するCommunity Stackと、商用のEnterprise Stackを分けている。 この違いが運用に関わる例が失効、つまり発行済みの証明を無効として扱う仕組みで、公式資料によると、Community Stackでは状態リストの管理と公開を利用者側で行い、Enterprise Stackにはそのためのサービスがある。 そのため、Community版で間違って発行した修了証を取り消すなら、状態リストを公開する処理も用意し、採用企業側がその状態を確認して受け入れを拒否できるところまで組み合わせる必要がある。
発行・検証・ウォレットをサービスとして提供した事例
walt.idの2026年3月の事例記事では、グローバルICT企業が発行・検証・ウォレット機能をサービスとして展開する基盤を構築したと説明されており、これらの機能を業務システムから利用する構成を考える上で参考になる。 使われたのはEnterprise Stackで、顧客の社名は明かされていないため、これから試すCommunity版がどのような構成で本番運用されているかまでは、この事例から確認できない。 同記事の「5億人超」も、将来サービスを届けられる潜在的な利用者層を表しており、すでにウォレットを使っている人数とは区別して読む必要がある。
実際にCommunity版を試す際には、READMEにv2のAPIと旧v1実装の説明が併記されているため、参考にする手順とAPIの世代、設定を合わせることが重要である。 また、「Web Walletは準備中」という記述はv2のWebアプリについてのものであり、スマホ用にはCompose WalletやiOS Walletへの案内が別に用意されている。
Procivis One：自治体でも使われるデジタル証明の基盤
Procivis One Coreは、発行・保有・検証の処理を共通のコアで扱うRust製のOSSで、READMEには、W3C VC、SD-JWT VC、ISO mdocや、OpenID4VCI・OpenID4VPなどが対象として挙げられている。 Core APIを起動すれば、研修会社による発行から受講者による保有、採用企業による検証までを共通のコアで試せるため、同じ修了証を使ってwalt.idと比較する候補にしている。
開発元のProcivis AGはスイスの企業で、Orell Füssliの子会社であり、Coreをサーバーとして使う構成のほか、ウォレットへの組み込み用SDKも提供している。 公開リポジトリのCoreを使う場合は、受講管理との連携や自社向けの画面をどう作るかも決める必要があり、管理画面などを含めて導入したい場合には、One Deskなどを含むEnterpriseの機能も比較対象になる。
Zug市の教職員証と、リトアニアの試験環境
具体的な利用場面が分かるのが、2024年9月に発表されたZug市の事例である。 Procivisの発表によると、500人超の教員へデジタル職員証を発行し、eZugアプリで提示して市内の対象文具店で割引を受けられるようにするもので、紙のカードと有効期間を示すシールの更新作業を置き換える用途として説明されている。
この事例では、市が発行した職員証を教員が持ち歩き、市内の店が受け入れるため、発行した組織の外でも証明を使う運用が行われている。 今回の研修修了証も、研修会社が発行したものを別の採用企業へ持っていく構成なので、利用場面を考える上では参考になる。 ただし、公開された発表にはOSSの版や設定までは示されていないため、同じ構成をOne Coreで再現できるかは、これから確かめる必要がある。
リトアニアの事例は、欧州のデジタルIDウォレット（EUDI Wallet）に向けた国のサンドボックス、すなわち事前に接続や利用方法を試す環境の受注である。 こちらは国民向け本番サービスの全面稼働を報告するものではなく、試験環境を構築する段階の案件なので、同じ政府や自治体での採用でもZug市の利用例とは段階が異なる。
ProcivisのGetting StartedにはCore APIで発行・提示・検証する手順があるので、walt.idと同じ修了証を使い、起動に必要な作業や通信の追いやすさ、失効や再発行にどこまで手を加えるかを比べる予定である。 この比較では、サーバー上で保有者役を再現する場合と、スマホ内部に鍵を置く場合を、それぞれ試す予定である。
Credo：TypeScriptでアプリに組み込む
CredoはNode.jsやReact Nativeで使えるTypeScriptのフレームワークなので、これらを使っているサーバーやスマホアプリに、鍵やDIDの管理、証明の発行・受領・提示・検証の処理を組み込む場合に検討しやすい。 一方、既存の業務システムから証明の発行を依頼したいのであれば、walt.idやProcivis OneのAPIを呼び出す構成も選べるため、自社の開発言語と、証明を扱う処理をどこに実装したいかによって候補が変わってくる。
今回の例では、受講者が修了証を受け取り、採用企業へ見せる内容を選ぶアプリを作る際に、鍵や証明を扱う処理をCredoから呼び出せる。 その場合も、受講者が操作する画面や業務処理は自分たちで設計するため、完成したスマホ画面から検討したい場合には、Credoを使うBifoldやParadym Walletも候補になる。
前身はHyperledger Aries Framework JavaScriptで、OWFの紹介は、従来のAries系技術から、複数の通信規格や証明形式を扱う構成へ発展してきた経緯を説明している。 メンテナー一覧では開発を担う人を確認でき、後述の年次報告にはAnimoなどの組織による貢献も記されている。
実績については、OWFに提出された2024年の年次報告が、カナダのBritish Columbia、アイルランド政府、CREDEBL経由のブータンなどを利用例として挙げている。 これはプロジェクト側の採用報告であり、各現場が最新のOpenID4VC構成を本番で使っているかまでは示していないため、以前からの利用実績と、今回採用したい方式への対応状況は分けて確認することになる。
2026年10月6日の確認では、GitHubの最新リリースはv0.7.2だった一方、公開ガイドの表示はv0.6.xで、READMEにも古い仕様へのリンクが残る箇所があった。 このように資料の版がそろっていないため、現行実装の対応範囲を調べる際は、採用するタグのコードと設定例、移行資料を合わせて確認することが重要である。
連載では、まずCredoを呼び出すコードから証明の処理を追い、受講者の操作まで含めて試す段階で、必要な画面や端末に合わせてアプリの構成を選ぶ予定である。
Multipaz：スマホの鍵とmdocを扱う
Multipazは、Googleが始めてOWFへ寄贈したデジタル証明のSDKであり、Kotlin Multiplatformを使ってAndroid、iOS、サーバー向けの処理を共有できる。 mdocに加えてSD-JWT VCやオンライン提示も扱うため、受講者がスマホに証明を保管し、採用企業の近くの読み取り機へ提示する場面と、Web経由で提示する場面の両方を調べる候補になる。 こうした近くの端末同士で証明を受け渡す方法を「近接提示」といい、サーバー上で発行や検証のAPIを動かすだけでは分からない、スマホの鍵管理や提示操作を調べるために使う予定である。
2026年9月1日のGoogleの解説は、MultipazをGoogle WalletとEUDI Wallet参照実装の基盤となる部品として紹介しており、利用者が使う製品や参照実装の内部に、このSDKが組み込まれていることが分かる。
Multipazを使えば自分のウォレットや検証アプリを作れるが、Google Walletという製品に修了証を登録したい場合には、その製品が受け入れる証明の種類と発行者の条件を満たす必要がある。 OSSのREADMEにもGoogleの公式サポート対象製品ではない旨が記されているため、自作アプリについては、必要な認証やサポートの条件を別途確認することになる。
プロジェクトのREADMEには、Android/iOSのテストアプリ、近接読み取りアプリ、Web上の検証サービスへの案内がある。 これらを使って受講者のスマホに鍵を置き、採用企業側から提示を求める構成を試しながら、鍵を端末外へ取り出せるか、端末の認証とどう組み合わせるかも実際の端末と設定で確かめる予定である。
確認時点では1.0前で、APIと保存データの変更可能性が明記されているため、教材では使った版を固定し、アップデート後に古いウォレットデータを読み込めるかも確認項目に含める。
EUDIPLO：業務システムとウォレットをつなぐ
EUDIPLOは業務システムとウォレットの間に置くミドルウェアであり、公開資料では、業務側がHTTP/JSONのAPIを呼び、ウォレットとのOpenID4VCI・OpenID4VP通信をEUDIPLOへ任せる構成が説明されている。 今回の例であれば、研修会社のシステムが修了証の発行を依頼するとEUDIPLOがウォレットとの発行の通信を引き受け、採用企業側では、ウォレットへ証明の提示を求める通信を任せることができる。 研修を修了したかどうかは従来の業務システムで判断し、証明をウォレットへ渡す通信をEUDIPLOに任せる構成にできるため、既存の研修管理システムへデジタル修了証を追加したい場合に検討できる。 受講者のウォレットは別に用意し、業務システムとEUDIPLOのAPIをつなぐ部分を自分たちで実装するという分担になる。
プロジェクト提案では、Mirko Mollikを中心とする開発体制を確認できる。 OWFで育ってきたプロジェクトで、現在のREADMEはLF Decentralized Trustのプロジェクトと記載している。
異なる名前のOSSでも、同じ部品を使うことがある
EUDIPLOとCredoは、発行・提示の通信処理に@openid4vc/*というライブラリ群を使っている。
確認したCredoの依存定義とEUDIPLOの依存定義では、同じライブラリ群でも指定する版は異なる。
両者をつなげればアプリ全体として動くかは確認できるが、通信処理の一部を共有しているため、その結果だけで通信規格を独立に実装した二者の相互運用まで確認したとは言えない。 連載では通信、証明形式、暗号処理のどこを比較したかも記録し、同じ部品を使って接続できた例と、別々の実装を接続できた例を区別する。
EUDI Wallet参照実装：欧州のウォレット構成を学ぶ
EUDI Wallet参照実装は、欧州委員会が公開しているアプリ、ライブラリ、サーバーの実装群であり、コードを読みながらEUのデジタルIDウォレットの構成を学ぶことができる。 AndroidアプリのREADMEも、主な目的を技術的な例示と説明し、本番利用に向けた設定ガイドを別に案内している。 今回の修了証で使う場合には、発行サービスと受け渡せる証明形式や通信方式を合わせ、研修会社を発行者として信頼する設定も用意する必要がある。 参照実装のコードを読むことで欧州のウォレットの組み立て方を学べることに加え、こちらで作った発行サービスから修了証を受け取れるかを確かめる接続先としても検討している。
用途から候補を選ぶ
ここまで紹介したOSSには、できることが重なるものもあるので、自分が作りたいサービスのどの部分を任せるかを決めてから候補を選ぶとよいと思う。 次の表は公式資料を読んだ段階での検証候補であり、性能や導入工数は今後、実際に動かしながら比較する予定である。
| まず確認したいこと | 候補 | 追加で決めること |
|---|---|---|
| 研修会社から発行し、採用企業で検証する一連の流れ | walt.id、Procivis One Core | 同じ証明の内容、利用するAPIの世代、鍵と証明の保存場所 |
| TypeScriptの既存アプリへ処理を組み込む | Credo | モジュール、保存先、画面、サーバーと端末の分担 |
| スマホでmdocを持ち、対面やWebで提示する | Multipaz | 実機とOS、鍵の保管方法、発行者の証明書を信頼する設定 |
| 業務サーバーを外部ウォレットへ接続する | EUDIPLO | 接続するウォレットの版、証明の形式、通信の設定 |
| EUの参照構成との接続を調べる | EUDI Wallet参照実装 | アプリと各サーバーの版、テスト用証明書と信頼設定 |
導入を検討する際には、利用条件にも目を通しておきたい。 今回挙げたCommunity Stack、One Core、Credo、Multipaz、EUDIPLOの各リポジトリはApache-2.0のライセンスを掲げるが、EUDIのAndroidウォレットアプリはEUPL-1.2である。 同じプロジェクト名で公開されていても、アプリ、サーバー、商用サービスでは利用条件が異なる場合があるため、採用する部品ごとにLICENSEを確認することが重要である。
また、サーバー上で利用者の鍵を管理するウォレットと、スマホ内で鍵を管理するウォレットでは運用者の責任が変わるため、発行・提示のAPI一覧に加え、誰が鍵を使え、紛失時には誰が復旧を受け付けるのかまで調べておくことをおすすめしたい。
実装の比較で確かめること
walt.idとProcivis One Coreの比較では、まずSD-JWT VCで同じ研修修了証を発行・受領・提示・検証し、その後W3C VCとmdocで試せる範囲を確認する。 起動までの手順、通信の追いやすさ、必要な端末や外部サービス、失効・更新に必要な追加作業を記録することで、対応規格の一覧からは分からない、実際に組み合わせる際の作業を把握したい。
正常に通る例に加え、書き換えた証明、期限切れ、別人の鍵、認めていない発行者、取り消した証明も扱う。 状態情報を取得できない場合は「失効していた」と混ぜず、エラーや保留になる条件として記録する。
SSIは、利用者が自分のデータの主権者になり、サービスを越えて証明を持ち運ぶという考え方だが、そのためには発行者と提示先が、証明の読み方と受け渡しの手順を共有できることが前提になる。 ところが、実際には実装ごとに細かな接続条件が異なり、それぞれがOSSを選んだ後で調整しなければならないため、私はこの負担が普及を難しくしている理由の一つだと考えている。 この連載では、動いた組み合わせと失敗した条件を具体的に残し、これから導入する人が同じ調整をやり直さずに済むような教材にしていきたい。
よくある質問
どれを使ってもブロックチェーンが必要か？
ブロックチェーンは必須ではなく、採用するDIDメソッドや鍵を確認する方法、証明形式によって構成は異なるため、チェーンを使う場合にはどの情報を置き、検証時に何を参照するかを決めることになる。
OSSを使えば、すぐに自社の修了証サービスになるか？
証明を発行・提示する部品は再利用できるが、受講管理との連携や発行対象者の確認は自社の業務に合わせて実装し、受け入れる企業とも合意する必要があるため、OSSを動かす作業と合わせて準備することになる。
公式の接続試験に通っていれば、独自の接続試験は不要か？
公式の試験や認証にも対象とする役割、版、設定、証明形式の範囲があるため、自社の修了証の内容や発行者を相手が受け入れるかは、実際に使う構成で確かめる必要がある。
まとめ
今回の連載では、まず同じ研修修了証を発行し、受講者が受け取って採用企業へ提示するまでを通して動かしたいので、APIから一連の処理を試せるwalt.idとProcivis One Coreを先に比較する。 その結果を見ながら、アプリ内部の処理を調べる際にはCredo、スマホの鍵管理やmdocの提示を調べる際にはMultipazを使うという順番で進める予定である。 既存の業務システムから外部ウォレットへつなぐ構成はEUDIPLOで試し、欧州のウォレット構成を学びながら接続する際にはEUDI Wallet参照実装を使うことも検討している。
開発元の実績も選定の参考にはなるが、商用版の事例や政府の試験環境で使われた構成と、これから自分たちが作る構成では条件が異なるため、その実績だけで今回使うOSSを決めることはできない。 主教材は、対応規格の一覧に加えて、実際に動かした際にどれだけの実装や運用作業が必要になるかを確かめてから選びたい。