0.はじめに
みなさん、こんにちは。
今回は、（久しぶりに）デジタルアイデンティティネタです。
初めて（お客様の）SSOシステムを構築してから早2x年、様々なデジタルアイデンティティに携わってまいりました。そんな中、デジタルアイデンティティ領域であまり手が出せていない領域があります。
それはDID/VCです。
今回は、自分の知識を深める意味も込めて、DID/VCについて取りまとめてみます。
1. DID/VC
1-1. DIDとは
DID（Decentralized IDentifier）とは、個人（あるいは組織）を識別するものです。
従来システムで言うところの「ID」に該当します。
※ID＝identifier
DIDの日本語訳は、分散型識別子だったり、非中央集権型識別子だったりします。
（他にもいろいろありますので、若干混乱しますね）
DIDはW3Cが仕様を標準化しています。
https://www.w3.org/TR/did-1.0/
この中の「The DID Syntax ABNF Rules」で定義されていて、次の形式となります。
did = "did:" method-name ":" method-specific-id
DIDのサンプルは次の通り。
"did:example:123456789abcdefghi"
このサンプルの場合、method-nameが「example」、method-specific-idが「123456789abcdefghi」となります。
method-nameとは、DIDの種類を表す名前です。
色々な種類（DID Method）があります。例えば、「web」等があります。
https://www.w3.org/TR/did-extensions-methods/
method-specific-idとは、上記で指定したmethod-nameの中で一意となる値のことです。
各DID Methodで記載方法が定義されています。
例えば、webの場合、次の通りです。
https://w3c-ccg.github.io/did-method-web/
web-did = "did:web:" domain-name
web-did = "did:web:" domain-name * (":" path)
サンプルは次の通り。
did:web:w3c-ccg.github.io
did:web:w3c-ccg.github.io:user:alice
did:web:example.com%3A3000
ドメイン名を指定したり、その配下のパスを指定する必要があります。
1-2. VCとは
VC（Verifiable Credential）とは、個人の情報（属性）が正しいことを保証するものです。
※属性＝氏名、住所、電話番号のような、IDに紐づく情報のこと
VCには個人の属性以外にも、「その情報（属性）が正しいと保証する組織に関する情報」なども含まれます。
VCもW3Cが仕様を標準化しています。
https://www.w3.org/TR/vc-data-model-2.0/
サンプルは次の通り。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/58473",
"type": ["VerifiableCredential", "ExampleAlumniCredential"],
"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": "Example University"
}
}
}
さて、サンプルの中身について説明をしたいのですが、その前にDID/VCの登場人物を理解しておく必要があります。
それがIssuer/Holder/Verifierです。
1-3. Issuer/Holder/Verifierとは
DID/VCには、様々な登場人物がかかわっています。
主な登場人物がIssuer/Holder/Verifierです。
W3cでは、Issuer/Holder/Verifierの関係を次の図で表現しています。
すごく簡単に書くと、次の通りです。
1-3-1. Issuer
IssuerはVCを発行する人/組織のことです。
例えば、大学等が、卒業した人に関するVCを発行します。
この例の場合、VCに含まれる情報は、氏名、大学名、卒業年度等が考えられます。
（VCに含まれる情報は、Issuerに依存します）
1-3-2. Holder
HolderはVCを保持する人/組織のことです。
例えば、大学等が発行したVCを個人で保持します。
VCを保持する場所として有名なものはWalletですが、Wallet以外の場所に保存することもできます。
1-3-3. Verifier
VerifierはVCを利用する人/組織のことです。
例えば、企業等が雇用する人のVCを利用します。
（この場合、雇用する人はHolderということになります）
1-4. VCサンプル解説
さて、ここで先ほどのVCサンプルを再掲し、説明していきます。
- サンプル（再掲）
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/58473",
"type": ["VerifiableCredential", "ExampleAlumniCredential"],
"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": "Example University"
}
}
}
順番に説明します。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
…
最初の「"@context": [～]」の部分は、このVCが何者であるかを宣言しています。
「https://www.w3.org/ns/credentials/v2 」は、W3C公式のVC Data Model v2に準拠していることを示します。
「https://www.w3.org/ns/credentials/examples/v2 」は例示用であることを示します。
（サンプル用のVCである、ということですね）
なお、W3Cでは拡張についても定義しており、独自の情報を追加することもできます。
…
"id": "http://university.example/credentials/58473",
"type": ["VerifiableCredential", "ExampleAlumniCredential"],
"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
"validFrom": "2010-01-01T00:00:00Z",
…
次の「"id":～"validFrom":～」の部分について説明します。
まず「id」は、VCそのものを表す識別子です。基本的にユニーク（唯一無二）になります。
「type」の「VerifiableCredential」は、これがまさしくVCであることを表します。後ろの「ExampleAlumniCredential」はラベル情報です。実際のVCでは、このVCが何を示すかの情報を記載します（このサンプルでは、「サンプル アラムナイ クレデンシャル」となっていて、卒業生のクレデンシャルのサンプル、ぐらいの意味合いですね）。
「issuer」は、VCを発行した人/組織のDIDです。
「ValidFrom」は、VCがいつから有効かを示します。
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": "Example University"
}
}
}
最後の「"credentialSubject":～」の部分について説明します。
この部分は、IsserがVCを発行した対象であるHolderの情報と、そのHolderが所持するVC情報（HolderのためにIssuerが発行したVC情報）を表します。
最初の「id」は、VCを保持する人/組織のDIDです。
「alumniOf」の中にある「id」「name」は、VC情報そのものです。今回の例だと「name」が「大学名（Example大学」、その大学のdidが「id」部分です。
なお、「alumniOf」という名称は、サンプルとなります。
実際のVCでは異なるものが使われます。
まとめると、次の通りです。
1-5. DID/VCの優位性（メリット）
さて、ここまでで、DID/VCとIssuer/Holder/Verifierについて説明してきました。
ここからは、DID/VCのメリットについて説明します。
1-5-1. IDを自分で選択できる
まず一つ目は「IDを自分で選択できる」点です。
DIDは、自分で採番して、発行する必要があります。
そのDIDを、様々な用途で使用することができます。
（もちろん、用途毎にDIDを切り替えることもできます）
既存システムのIDの場合、基本的にはシステム管理者から指定されたIDを使用します。
システムが変われば、使用するIDも異なります。
（もちろん、メールアドレスがIDになるシステムの場合、同じメールアドレスを設定することはできます）
また、DIDは自分自身で発行するため、失効することがないという利点もあります。
（企業都合による失効（所謂アカバン）は発生しません）
※もちろん、自分自身で失効することはできます
1-5-2. 提示する情報を自分で選択できる
二つ目は「提示する情報を自分で選択できる」点です。
Issuerが発行したVCをVerifierに提示する際、その情報を自分自身（Holder）で選ぶことができます（選択的開示）。
例えば、次のようなVCがあると仮定します。
"alumniOf": {
"id": "did:example:1234567890abcdef",
"name": "Example University"
},
"graduation": {
"faculty": "Faculty of Engineering",
"department": "Department of Materials Science",
"graduationYear": 2024
},
"credits": {
"gradeA": 100,
"gradeB": 20,
"gradeC": 20,
"total": 140
}
このVCは、次のことを保証しています。
- Example大学の卒業生である
- 工学部材料学科を卒業している
- 卒業年度は2024年度である
- 取得単位は、A評価：100単位、B評価：20単位、C評価：20単位である
VerifierにVCを提示する際に、もちろん全部提示することもできます。
しかし、必要な情報だけを切り出して提示することもできます。
例として、次のようなケースが考えられます。
・大学を卒業しているかどうか → 「"name": "Example University"」を提示（卒業している大学名を提示）
・いつ大学を卒業したか → 「"graduationYear": 2024」を提示
・A評価が80単位以上あるか → 「True（ある）」を提示
このように、選択的に情報開示することができるため、プライバシーの観点でもメリットがあります。
2. 自己主権型アイデンティティ
さて、このようなDID/VCの優位性は、実は自己主権型アイデンティティ（Self-Sovereign Identity：SSI）という考え方に基づくものです。
SSIという言葉を広めたのは、クリストファー・アレン（Christopher Allen）という方です（ https://x.com/ChristopherA ）。
2-1. 自己主権型アイデンティティ（SSI）とは
自己主権型アイデンティティとは、個人がアイデンティティ管理の中心になるという考え方です。
従来型のアイデンティティは、中央集権型とかフェデレーション型と言われています。
従来型のアイデンティティは、個人で情報（属性）の管理が難しいものでした。
例えば、何かが欲しくて会員登録する場合を考えてみましょう。
氏名、住所、電話番号、メールアドレス、etc
様々な情報を登録する必要があると思います。
オンラインショップで商品を買って、それが家に届く場合、住所は必要でしょう。
では、電子書籍を買うときは、住所は必要でしょうか？
電話番号は？
また、登録した情報は、ずっと会員サイトに保存しておく必要があるのでしょうか？
こちらが何か買った時だけ、必要な情報では？
サイバー攻撃を受けたら、うちの住所が漏洩するのでは？
このような課題を解決するために、SSIやDID/VCが生まれました。
3. SSIとDID/VCの関係
SSIとDID/VCは、どのような関係があるのでしょうか？
3-1. SSIは思想・理念
SSIは、デジタルアイデンティティに対する思想・理念です。
自分のデジタルアイデンティティは自分で管理するべき、自分が中心となってコントロールすべき、という考え方です。
3-2. DID/VCは技術標準
一方、DID/VCは技術標準です。
W3Cが仕様を策定しており、全世界で利用することができます。
SSIの思想・理念を契機に、DIDやVCが発展してきています。
3-3. DID/VCはSSIだけのものか？
元々DID/VCは、SSIから始まっています。
しかし、DID/VCはその後も発展を続けており、いまや「SSIだけのもの」というよりは、「（SSIに限定されない）より汎用的に利用できるもの」になりつつあります。
そのため、DID/VCは、自己主権型アイデンティティの実現だけでなく、それ以外の用途にも利用することができます。
4. DID/VCの活用状況
様々な用途への活用が期待できるDID/VCですが、実証実験段階のものが多く、実運用これからというものが多いようです。
4-1. 新型コロナワクチン接種証明書アプリ
日本政府が公式に提供していた、新型コロナワクチン接種証明書アプリには、VCが利用されていました。
しかし、国内でこのアプリを使用する場面があまりなかった影響で、すでにサービス終了しています。
（また、この事例ではDIDは使用されていませんでした）
4-2. それ以外
国内でも様々な議論がなされています。
例えば「Verifiable Credential (VC/VDC) の活用におけるガバナンスに関する有識者会議」では、検討中のユースケースがいくつか報告されています。
- 金融機関のKYCへの活用 (本人確認）
- 個人を介したデータの利活用 （電子レシート）
- 生体情報VCによる社会課題解決 （チケット不正転売）
- 法人の財務状況の証明 （クレジットカード）
- 等々
4-3. DID/VC普及に向けた課題
DID/VCは黎明期で、活用はこれからです。
つまり、まだ普及には至っていません。どのような課題があるのでしょうか？
4-3-1. 既存の仕組みで充分である
一つ目は、既存の仕組みで大体のことができてしまう点です。
既存の仕組みで充分なケースもありますし、
既存の仕組みだと手間暇がかかったり面倒だったりするのですが、DID/VCの仕組みを（お金と時間をかけてまで）新規に導入するまでは至らないケースです。
例えば、先ほどの「新型コロナワクチン接種証明書」の件で考えると、
紙の証明書が発行できるのであればそれで充分と考えてしまうケースです。
既存の仕組みで充分なものを、新しい技術で置き換えることは、なかなかハードルが高いという現実があります。
そのため、DID/VCの普及には、既存の仕組みを置き換えてでもメリットがある「何か」が求められます。
4-3-2. DID/VCでないと解決できないものがない（少ない）
二つ目は、DID/VCを利用しないと解決できない問題がない（少ない）点です。
例えば、先ほどDID/VCの優位性で「提示する情報を自分で選択できる」という話をしました。
確かにこの点はDID/VCのメリットではあります。
しかし、これが解決できないと生活できない（生きていけない）かというと、そうでない場合も多いです。
例えば、お店でお酒を買うときに、20歳以上であるかを証明する場合を考えます。
20歳以上であることを証明できるDID/VCがあればそれを提示しますが、
一般的には身分証明書（マイナンバーカードや免許証など）を提示すると思います。
そして、それでお酒が買えます。
つまり、DID/VCによる「20歳以上であることの証明」がなくても、お酒を買うことができてしまいます。
そのため、DID/VCの普及には、DID/VCでないと解決できない「何らかの課題」が求められます。
4-3-3. 3者が得する仕組みがない（少ない）
三つ目は、3者が得する仕組みがない（少ない）点です。
ここでいう3者とは、Issuer、Holder、Verifierです。
IssuerがVCを発行することで、うれしい仕組み（儲かる仕組み）は何か？
HolderがVCを保持することで、うれしい仕組み（助かる仕組み）は何か？
VerifierがVCを確認することで、うれしい仕組み（得する仕組み）は何か？
そのため、DID/VCの普及には、3者に「何らかのメリット」が求められます。
もちろんビジネス目的利用ばかりではないため、必ず儲からないといけないわけではありません。
しかし、少なくとも3者にとってメリットがある何かが、DID/VC発展の肝になりそうです。
4-4. DID/VC普及のポイント
（これまでの議論をまとめると）DID/VC普及のためは、少なくとも次の3つを満たす必要があると考えています。
- 既存の仕組みでは解決できない課題
- DID/VCでないと解決できない課題
- Issuer、Holder、Verifierの3者にメリットがあるもの
図にすると、次の通りです。
上記図の赤点線枠の部分が、DID/VCが主戦場となる箇所で、かつ普及のポイントとなる箇所です。
これからDID/VCを推進していくためには、この赤点線枠部分を探し、かつ拡大していくことが求められます。
5. DID/VCの未来は？
様々な分野での活用が期待されるDID/VCですが、爆発的な普及はこれからのようです。
キラーコンテンツというか、主流となる利用方法や利用分野が確立されることで、一気に普及が広まることが期待されます。
また、利用促進に向けた法改正等の対応も、必要になってくるかもしれません。
5-1. DID/VCは未来のデジタルアイデンティティか？
部分的にYESであり、NOでもあります。
5-1-1. 統合ID管理を置き換えることは無い
現在主流の企業による統合ID管理をDID/VCが（すべて/大幅に）置き換えることは無いと思われます。
DIDはあくまで個人主導のIDであり、企業が管理するものではありません。
一方、企業は様々な理由により、企業主導のID管理が必要です。
これは、相反する思想であり、ゆえに、企業のIDがDIDに置き換わることは難しいと考えます。
（一部業務だけDIDになることは考えられます）
5-1-2. 認証を置き換えることも無い
同様に、現在主流の企業による認証をDID/VCが（すべて/大幅に）置き換えることは無いと思われます。
DID/VCは、そもそも認証用途で使用されるものではないため、既存の仕組みを置き換えるためには使用されません。
そのため、仮にDIDをIDとして使用することになったとしても、別途認証手段が必要となります。
（パスワードによる認証や、SAML/OIDC等のフェデレーション、その他の仕組みが必要です）
同様の理屈により、認証強化としてのMFAやパスキーも、置き換わることは無いと思われます。
5-1-3. 属性証明は置き換わる可能性あり
一方で、属性証明については、DID/VCに置き換わる可能性があると考えています。
情報漏洩の懸念や、プライバシーの問題もあり、自分の情報（属性）を自分でコントロールしたいという要望は、今後増えることが予想されます。
この辺りを解決する既存の仕組みはあまりない（普及していない）ため、DID/VCがそれを担う可能性は非常に高いと考えております。
6. おわりに
今回はDID/VCについて執筆しました。
正直、デジタルアイデンティティネタの中では、このテーマは最後に書こうと思っていました。
デジタルアイデンティティ領域の中では比較的新しいテーマなので、今回記事にすることができてよかったと感じています。
今回は技術的な点についてはあまり深彫りせず、概念的な話をメインとしました。
技術的な点については、今後深彫りできればと考えております。
今後普及することが期待されるDID/VCについて、皆さんも学んでみてはいかがでしょうか？
96.連載のリンク先
デジタルアイデンティティを学ぼう～第1回～デジタルアイデンティティって何だろう
https://qiita.com/peridotan/items/7de8a59e07188926153d
デジタルアイデンティティを学ぼう～第2回～MFA（多要素認証）
https://qiita.com/peridotan/items/e30a3cae663b46a50cf2
97.参考文献
98.更新履歴
- 2026.01.08 初版