この記事の対象読者

この記事は、これからDID/VCを体系的に学びたい人に向けた基礎解説です。

特に、次のような方を想定しています。

  • DID/VC、デジタル証明、ウォレットの全体像をつかみたい方
  • 行政、金融、教育、資格、労務などでデジタル証明の活用を検討している方
  • OpenID4VCI / OpenID4VP やVC Data Modelの前提を整理したいエンジニア
  • DID/VC関連の提案、PoC、プロダクト企画に関わる事業開発・プロダクト担当者
  • 技術仕様だけでなく、Issuer、Holder、Verifier、ガバナンスの関係まで押さえたい方

暗号技術やDID Methodの細部に入る前に、DID/VCがどのような課題を扱い、どの登場人物がどのようにつながるのかを理解することを目的にしています。

この記事で伝えたいこと

DID/VCは、デジタル空間で「誰が、何を、どの根拠で証明したのか」を機械的に検証できるようにするための技術群です。

大学の卒業証明、企業の在籍証明、金融機関の本人確認済み属性などを、紙やPDFの目視確認に頼らずシステムで検証できるようにします。

この記事では、DID/VCを初めて学ぶ人に向けて、登場人物、データ構造、発行・提示・検証の流れを整理します。

まず押さえるべき3つの登場人物

VCの世界では、よくIssuer、Holder、Verifierという3者モデルで説明されます。

DID/VCの基本構造

DID/VCの主役は「誰が誰に何を証明し、誰が検証するか」です。DIDや署名方式は、その検証可能性を支える部品です。

Issuer: 証明を発行する人・組織

Issuerは、証明書を発行する主体です。

大学、企業、自治体、金融機関、資格団体、プラットフォーム事業者などがIssuerになり得ます。

たとえば大学が「この人は本学を卒業した」と証明する場合、大学がIssuerです。企業が「この人は当社に在籍している」と証明する場合、企業がIssuerです。

VCの信頼性は、Issuerの信頼性に大きく依存します。

たとえば「医師資格VC」を受け取ったVerifierは、署名が正しいかだけでなく、そのVCを発行した主体が医師資格を証明する権限を持っているかも確認する必要があります。社会実装では、発行主体の認定、契約、業界ルール、行政制度、トラストフレームワークなどを組み合わせて、Issuerを信頼する根拠を設計します。

Holder: 証明を受け取り、管理し、提示する人

Holderは、VCを受け取って管理する主体です。多くの場合、個人や法人がHolderになります。

HolderはウォレットなどにVCを保存し、必要な場面でVerifierに提示します。

紙の証明書では、証明書のコピーを相手に渡すことが多くありました。しかしVCでは、証明内容、署名、発行者、期限、失効状態などを機械的に検証できます。さらに方式によっては、必要な属性だけを提示する選択的開示も可能になります。

Verifier: 提示された証明を検証する人・組織

Verifierは、Holderから提示されたVCやVPを検証する主体です。

採用企業、金融機関、オンラインサービス、自治体、イベント運営者、宿泊施設、教育機関などがVerifierになり得ます。

Verifierが知りたいのは、主に次の点です。

  • その証明は改ざんされていないか
  • 信頼できるIssuerが発行したものか
  • Holderが正しく提示しているか
  • 有効期限内か
  • 失効・停止されていないか
  • サービス利用に必要な属性を満たしているか

人の目視確認や発行元への個別照会を挟まず、自動的に検証できることがVCの大きな価値です。

VCは何を解決するのか

VCが向き合う中心課題は、証明をデジタルで渡した後に、その真正性や有効性を機械的に確認できる状態を作ることです。

PDF、画像、メール添付、スクリーンショット、会員画面の提示でも、ある程度の証明はできます。しかし、それらは次の問題を抱えています。

  • 改ざん検知が難しい
  • 発行者の真正性を確認しにくい
  • システムで自動検証しにくい
  • 必要以上の個人情報を渡しがち
  • 証明の再利用性が低い
  • 発行元への都度照会が必要になりやすい
  • 失効や有効期限の管理が難しい

VCは、これらの問題に対して、デジタル署名、標準化されたデータモデル、発行・保管・提示・検証のプロトコルを組み合わせることで解決を目指します。

DIDは何をするものか

DIDはDecentralized Identifierの略です。W3C DID Coreでは、DIDは中央集権的な登録機関、IDプロバイダー、認証局から切り離して設計できる識別子として定義されています。

ただし、ここで誤解しやすいポイントがあります。

DIDは、鍵やサービスエンドポイントなどの情報に到達するための識別子です。実在性、年齢、資格といった属性は、本人確認や属性確認の結果をVCとして発行することで扱います。

DIDは、主に次のような情報に到達するための識別子です。

  • 公開鍵
  • 認証・検証に使うメソッド
  • サービスエンドポイント
  • DID Document
  • DIDの管理主体に関する情報
DIDが検証に使われる流れ

DIDは、VCやVPの検証に必要な公開鍵や検証メソッドへ到達するために使われます。

VCにおいてDIDは、IssuerやHolderを識別したり、署名検証に必要な公開鍵を解決したりするために使われることがあります。

VCでDIDを使う場面は多くありますが、ユースケースや採用する仕様によっては、別の識別子や証明基盤を使うこともあります。

DID/VCを理解する上では、検証可能な証明書の流通に注目すると全体像をつかみやすくなります。多くの社会実装では、利用者や事業者にとっての価値はVC、つまり検証可能な証明書の流通にあります。DIDは、その実現手段の一部として位置づけるのが自然です。

VCの基本構造

W3C Verifiable Credentials Data Model 2.0では、VCは発行者があるSubjectについて行うClaimsを表現するデータモデルとして説明されています。

簡略化した卒業証明VCの例は次のようになります。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "did:example:university",
  "validFrom": "2026-04-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:student",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science"
    },
    "graduationDate": "2026-03-31"
  },
  "credentialStatus": {
    "id": "https://example.edu/status/24#94567",
    "type": "BitstringStatusListEntry"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2026-04-01T00:00:00Z",
    "verificationMethod": "did:example:university#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

主要なフィールドは次の通りです。

  • issuer: 誰が発行したか
  • credentialSubject: 誰・何についての証明か
  • validFrom / validUntil: いつからいつまで有効か
  • type: どの種類の証明か
  • proof: 改ざんされていないことを検証するための署名・証明
  • credentialStatus: 失効・停止などの状態確認に関する情報

たとえば、卒業証明VCなら、Issuerは大学、credentialSubjectは卒業生、Claimsは学位、学部、卒業年月などになります。

在籍証明VCなら、Issuerは企業、credentialSubjectは従業員、Claimsは所属、役職、在籍状態、有効期限などになります。

VCはJSONで表現されることが多いものの、見るべきポイントはデータ形式だけに留まりません。「誰が、何を、どの形式で、どのように検証可能にしたか」が本質です。

VP: Verifiable Presentation

VCとあわせて、VP（Verifiable Presentation）も押さえておきましょう。

VCはIssuerが発行する証明書です。一方でVPは、HolderがVerifierに提示するために構成した提示データです。

たとえばHolderが複数のVCを持っている場合、Verifierに対して必要なVCだけを提示する、または必要な属性だけを提示する、といった使い方が考えられます。

このときVerifierは、提示されたVPを検証します。

  • VPがHolderによって正しく作成されたか
  • 含まれるVCが改ざんされていないか
  • Issuerが信頼できるか
  • 有効期限や失効状態に問題がないか
  • 要求した条件を満たしているか

つまり、発行の単位がVC、提示の単位がVPです。

VCとVPの違い

VCはIssuerが発行する証明であり、VPはHolderがVerifierに提示するために構成するデータです。

発行・提示のプロトコル: OpenID4VCI / OpenID4VP

DID/VCの実装では、W3C仕様とあわせてOpenID Foundationの仕様も押さえておく必要があります。

特に実装に近いところでは、OpenID for Verifiable Credential Issuance、いわゆるOpenID4VCIと、OpenID for Verifiable Presentations、いわゆるOpenID4VPがよく登場します。

OpenID4VCIは、IssuerがHolderにVCを発行するためのOAuthベースのAPI仕様です。

OpenID4VPは、VerifierがHolderに対してCredentialの提示を要求し、Holderが提示するための仕様です。

ざっくり言えば、次のような関係です。

  • VC Data Model: 証明書そのもののデータモデル
  • DID Core: 識別子とその解決方法の基礎
  • OpenID4VCI: VCを発行するためのプロトコル
  • OpenID4VP: VC/VPを提示するためのプロトコル
  • Wallet: HolderがVCを受け取り、管理し、提示するアプリケーション

社会実装では、データモデルだけ分かっていても不十分です。実際に発行・提示・検証を回すには、ウォレット、Issuer、Verifier、プロトコル、信頼基盤、運用設計が必要になります。

OAuth/OIDCとDID/VCは何が違うのか

DID/VCは、OAuth 2.0やOpenID Connectと比較すると理解しやすくなります。

OAuth 2.0は、ざっくり言えば「クライアントアプリケーションがAPIにアクセスするための権限」を扱います。中心にあるのはアクセストークンです。

OpenID Connectは、OAuth 2.0の上に認証のレイヤーを足したものです。中心にあるのはIDトークンです。IDトークンは、ユーザーが認証されたという事実や属性情報を、クライアントアプリケーションが検証できる形で受け取るためのものです。

VCは、さらに別の角度から「証明」を扱います。Issuerが発行した証明をHolderが持ち運び、必要な相手に提示し、Verifierが検証します。つまり、VCは特定のログインセッションや特定サービス内の認証結果だけでなく、複数の場面で再利用できるポータブルな証明として設計できます。

OAuth/OIDC/VCの違い

OAuth/OIDCは現在のWebサービス連携に強く、VCはサービスをまたいで使える証明の流通に強みがあります。

この違いを押さえると、DID/VCを「証明の発行・保有・提示・検証の仕組み」として捉えやすくなります。

DID/VCとブロックチェーンの関係

DID/VCはWeb3やブロックチェーンの文脈で語られることがあります。ここで混乱しやすいのは、DID/VCとブロックチェーンを同じレイヤーに置いてしまう点です。

VCは、証明書のデータモデルです。誰が、誰について、何を証明したのかを、機械が検証できる形で表現します。

DIDは、識別子と、その識別子に紐づく公開鍵やサービスエンドポイントへ到達する仕組みです。

ブロックチェーンは、DID Methodや信頼基盤の実装で使われることがあるインフラです。たとえば、DID Documentの解決や変更履歴の管理にブロックチェーンを使う方式があります。

つまり、ブロックチェーンはDID/VCの必須構成要素というより、識別子や検証情報をどう公開・更新・参照するかを実装するための選択肢の一つです。

実際のDID/VCシステムでは、次の要素を組み合わせて設計します。

  • VCのデータモデル
  • Issuer / Holder / Verifierの業務フロー
  • ウォレット
  • VCの発行・提示プロトコル
  • DIDや公開鍵の解決方法
  • 失効確認の仕組み
  • Issuerを信頼するためのRegistryやガバナンス

ブロックチェーンを採用しても、証明書の中身、提示時のプライバシー、Issuerの信頼性、失効確認、業務フローとの接続は別途設計が必要です。

社会実装を考える場合は、次の問いを先に整理すると設計しやすくなります。

  • 誰がIssuerとして信頼されるのか
  • Verifierは何を根拠にIssuerを信頼するのか
  • 失効確認をどう行うのか
  • 個人情報をどこまでHolderに持たせるのか
  • ウォレットの本人拘束性をどう担保するのか
  • 法令・業法・本人確認制度とどう接続するのか
  • 事業者間で相互運用するためのプロファイルをどう決めるのか

DID/VCを理解するときは、「証明書のデータモデル」「識別子と鍵解決」「発行・提示のプロトコル」「信頼基盤の実装」を分けて見ると整理しやすくなります。

DID/VCが重要になる理由

多くの業務では、証明の確認に人手が残っています。

本人確認、資格確認、在籍確認、住所確認、年齢確認、卒業確認、法人確認、委任確認などは、業界を問わず繰り返し発生します。

オンライン化された手続でも、実際には次のような運用が残りがちです。

  • PDFをアップロードする
  • スクリーンショットを送る
  • 原本確認のために郵送する
  • 担当者が目視で確認する
  • 発行元に都度照会する
  • 同じ本人確認を複数サービスで繰り返す

この状態では、申請者にも確認する事業者にも負担が残ります。

VCを使うと、証明書をデジタルで発行し、Holderがウォレットで保管し、必要な場面でVerifierに提示できます。Verifierは、署名、有効期限、失効状態、Issuerの信頼性をシステムで確認できます。

たとえば、次のような使い方が考えられます。

  • 大学が卒業証明VCを発行し、採用企業が応募者の学歴を自動検証する
  • 資格団体が資格証明VCを発行し、サービス事業者が有資格者だけに機能を開放する
  • 企業が在籍証明VCを発行し、従業員が福利厚生や法人契約の申請で提示する
  • 金融機関が本人確認済み属性をVCとして発行し、別サービスで再利用する
  • 自治体や行政機関が対象資格の証明を発行し、申請手続の確認を自動化する

こうしたユースケースでは、紙やPDFを人が確認する運用から、システムが証明書を検証する運用へ移行できます。

デジタル庁のVerifiable Credential (VC/VDC) の活用におけるガバナンスに関する有識者会議でも、属性証明の活用では技術仕様だけでなく、発行主体の信頼性、利用場面に応じたガバナンス、制度との接続が論点として扱われています。

VCのライフサイクル

VCは、発行・保管・提示・検証・失効確認までを一つの流れとして設計します。

国内で見るべき論点

日本におけるDID/VCの議論では、技術仕様だけでなく制度・運用の観点が重要です。

特に見るべき論点は次の通りです。

1. Issuerの信頼性

VCは「誰かが何かを証明した」というデータです。したがって、Issuerが信頼できなければ、VCも信頼できません。

たとえば、誰でも「医師資格VC」を発行できてしまうなら、そのVCには社会的価値がありません。

実装では、Issuer Registry、認定制度、契約、業界団体、行政制度、トラストフレームワークなどによって、Issuerの信頼性を整理する必要があります。

2. Holder Binding

VCを提示している人が、本当にそのVCの正当な保有者なのかという問題です。

VC自体が正しくても、他人のVCをコピーして提示できてしまうなら問題があります。ウォレット、秘密鍵、生体認証、端末拘束、本人確認済みアカウントなどをどう組み合わせるかが重要です。

3. 失効確認

現実の証明には、失効や停止があります。

資格が取り消される、在籍状態が変わる、証明の有効期限が切れる、といったケースです。

VCでは、Credential Statusを使って失効状態を確認する仕組みが検討・標準化されています。W3CのBitstring Status List v1.0は、VCのステータス情報をプライバシーに配慮しながら効率的に公開するための仕様です。

4. プライバシーとデータ最小化

VCの大きな価値の1つは、必要な属性だけを提示できる可能性です。

年齢確認のために生年月日や住所まで渡す必要はありません。居住地要件を満たしていることだけを示せればよい場合もあります。

ただし、選択的開示やゼロ知識証明のような仕組みは、採用するVC形式やプロトコルによって実現方法が変わります。概念として語るだけでなく、どの仕様・形式で実装するかまで落とし込む必要があります。

5. 相互運用性

DID/VCは標準化が進んでいますが、標準があるだけでは相互運用性は保証されません。

実際には、データ形式、署名方式、ウォレット、発行フロー、提示フロー、認証方式、失効確認、メタデータ、信頼リストなどの組み合わせが必要です。

OpenID4VC High Assurance Interoperability Profileのように、高いセキュリティとプライバシーが求められる領域で相互運用のための要件を定義する動きもあります。

よくある誤解

誤解1: DID/VCはWeb3の話である

一部はWeb3と重なりますが、DID/VCはより広いデジタル証明の技術です。行政、金融、教育、資格、労務など、Web3以外の領域でも重要です。

誤解2: DIDを使えば本人確認が不要になる

DIDは識別子です。本人確認や属性確認の結果をVCとして発行することで、再利用可能な証明として扱えるようになります。

誤解3: VCを発行すれば自動的に信頼される

VCの検証には、Issuerを信頼する根拠が必要です。技術的に署名が正しくても、Issuerが信頼できなければ、その証明には意味がありません。

誤解4: ブロックチェーンが必須である

ブロックチェーンを使うDID Methodやユースケースはあります。DID/VC全体を見ると、証明の発行、保管、提示、検証、失効確認、Issuerの信頼性など、より広い設計領域を扱います。

誤解5: 標準仕様を採用すれば相互運用できる

標準仕様に加えて、プロファイル、テスト、運用ルール、信頼リスト、ウォレット対応が必要になります。

企業がDID/VCに取り組むときのチェックリスト

企業が最初に決めるべきことは、「どの証明業務を変えるのか」です。

たとえば、本人確認済み属性を再利用したいのか、資格確認を自動化したいのか、従業員や会員の所属証明をデジタル化したいのかで、設計は変わります。

検討時には、次の5点を先に整理すると議論が進めやすくなります。

  1. 証明したい事実
  2. - 例: 年齢、住所、在籍、資格、卒業、本人確認済みであること
  3. 登場人物
  4. - 誰がIssuerで、誰がHolderで、誰がVerifierになるのか
  5. 検証に必要な信頼
  6. - Verifierは何を根拠にIssuerを信頼するのか
  7. 運用上の制約
  8. - 有効期限、失効確認、個人情報、Holder Binding、監査をどう扱うのか
  9. 実装方式
  10. - VCの形式、ウォレット、OpenID4VCI / OpenID4VP、既存システム連携をどう選ぶのか

この順番で考えると、DID/VCを導入すること自体が目的化しにくくなります。重要なのは、証明の確認にかかっている手間、時間、リスクをどこまで減らせるかです。

技術記事としての結論

DID/VCは、デジタル社会で必要になる「証明」を、発行者、保有者、検証者の間で安全に流通させるためのアーキテクチャです。

日本でDID/VCの社会実装を進めるには、W3CやOpenID Foundationの仕様を理解するだけでなく、Issuerの信頼性、Holder Binding、失効確認、プライバシー、相互運用性、国内制度との接続をあわせて設計する必要があります。

これからDID/VCに取り組む企業は、「DIDを使うか」「ブロックチェーンを使うか」より先に、証明したい事実と検証したい業務を整理すると設計しやすくなります。

まず考えるべきなのは、どの証明が、どの業務で、誰にとって、どれだけのコストを下げ、どれだけの信頼を生むのかです。

DID/VCは、その問いに対する技術的な選択肢です。

参考資料