Verifiable Credential（VC）の構造を図解で理解する
採用の場では、経歴詐称を見抜けないまま採用してしまうことがあります。
また、従業員が提出した資格証明書の真偽を確認するために、発行元へ一件ずつ問い合わせる手間も発生します。
さらに、顧客の本人確認書類が本物かどうか判断に迷う場面も少なくありません。
デジタル化が進む今なお、「証明書の真正性確認」 は大きな課題として残っています。PDFやJPEGといったデジタルデータは、見た目を簡単に偽装できるためです。この現実が、企業の採用・認証・取引の信頼性を揺るがしています。
直近でも、某市長の卒業証書の偽造問題が話題になっておりましたね。
この問題を根本的に解決するのが、Verifiable Credential（検証可能な資格情報）、通称VCです。
Verifiable Credential（VC）とは?
VCは、デジタル空間で「改ざん不可能」かつ「即座に検証可能」な証明書です。
紙の証明書やPDFとの最大の違いは、暗号技術により真正性が数学的に保証されていることです。検証者は発行元に問い合わせることなく、その場で証明書が本物かどうかを確認できます。
VCを扱う登場人物
VCを扱う登場人物には、3つの主要な役割があります。
① Issuer（発行者）
証明書を発行する機関です。
例: 大学（卒業証明書）、運転免許センター（免許証）、企業（在籍証明書）
② Holder（保持者）
証明書を受け取り、保管し、必要に応じて提示する人です。
通常、スマートフォンのデジタルウォレットアプリに保管します。
例: 卒業生、免許保有者、従業員
③ Verifier（検証者）
証明書を受け取り、その真正性を確認する人や組織です。
例: 採用企業、サービス提供者、入国管理局
VCの構造を分解して理解する
実際のVCにはいくつかのフォーマット仕様がありますが、ここではW3Cが定義するVC DataModel 2.0から代表的な例をJSON形式のデータ構造で紹介します。
全体像
① メタデータ部分
{
"@context":
[ "<https://www.w3.org/2018/credentials/v1>",
"<https://www.w3.org/2018/credentials/examples/v1>" ],
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "did:example:university123"
}役割: この証明書が何であるかを定義します。
@context: データ形式の定義（辞書のようなもの）
type: 証明書の種類（大学の学位、運転免許など）
issuer: 発行者のID(URIやDIDなどの識別子)
② 発行情報
{
"issuanceDate": "2023-06-15T09:00:00Z",
"expirationDate": "2028-06-15T23:59:59Z"
}役割: いつ発行され、いつまで有効かを示します。
システムが自動的に有効期限をチェックできる
期限切れの証明書は自動的に無効として扱われる
③ 主体情報（Credential Subject）
{
"credentialSubject": {
"id": "did:example:student456",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science in Computer Science",
"university": "Example University"
},
"graduationDate": "2023-03-31"
}
}役割: 誰について、何を証明しているかを記述します。
id: 証明書の主体（保持者）の識別子
その他のフィールド: 証明内容（学位、資格、スコアなど）
④ デジタル署名（proof）
{
"proof": {
"type": "Ed25519Signature2020",
"created": "2023-06-15T09:00:00Z",
"verificationMethod": "did:example:university123#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "z3FXQjecWh...（電子署名）"
}
}役割: 発行者の署名。これがVCの核心です。
暗号技術により、改ざんが不可能
発行者の秘密鍵で署名され、公開鍵で検証される
1文字でも改ざんされると検証が失敗する
※ 例ではjsonのproof形式ですが、これはVCのフォーマット(jwtやcborなど)に依存します
検証の仕組み — なぜ改ざんが検知できるのか?
VCの検証プロセスを図解します。
発行者に問い合わせ不要: すべての検証は暗号技術で行われ、発行者へ直接問い合わせる必要がありません。これにより、
プライバシーが保護される（発行者に「誰がいつ証明書を使ったか」が知られない）
オフラインでも検証可能
システムの分散化が実現
選択的開示 — 必要な情報だけを見せる
VCの強力な機能の一つが選択的開示（Selective Disclosure）です。
従来の証明書の問題
証明書を提示する際に証明書に記載されている「全ての情報」を提示する必要があった。
VCでの選択的開示
この仕組みにより、プライバシーを守りながら必要な証明を行うことができます。
有効期限内での失効（Revocation）
従来の証明書の問題
紙やPDFの場合、有効期限内で失効させることは柔軟に実施できなかった(発行者へ問い合わせる必要があった)
VCにおける失効処理
VC発行後に有効期限内のVCを無効化する必要がある場合（退職、資格喪失など）、主に以下のような方法によって、検証者は発行者に問い合わせることなくその有効性を確認することができます。
Bitstring Status List（W3C）
各証明書の「有効」「無効」を、圧縮されたビットのリストとして1つのファイルで扱うため、処理が軽く高速で大量データの処理に向いている
個人情報を開示せずに状態を確認できるなど、プライバシーにも配慮
2025年5月に正式なW3C勧告
Token Status List（IETF）
Bitstring Status List（W3C）のより汎用的なステータスリスト
複数のサービスやシステム間で発行されたトークンの状態を、共通のリストで一括管理
既存のOAuthなどと親和性が高い
CRL／OCSP
長年使われてきたデジタル証明書の失効管理の仕組み。主に電子証明書（X.509形式）や電子署名、モバイル運転免許証（mDL）などの分野で利用
CRLは「失効した証明書の一覧」を定期的に配布する仕組み
OCSPは、証明書の有効・無効をオンラインでリアルタイムに照会する仕組み
現時点ではこれらのステータス管理の方式は、ユースケースや業界に応じて適切なものが選択されている状況ですが、これらの方法により、従来は発行者へ問い合わせる必要があった有効性確認も、検証者自身が確認することができます。
実際のユースケース
1. 人事・採用での活用
メリット
証明書の真正性確認が数秒で完了
発行元への問い合わせコストゼロ
応募者の待ち時間削減
2. 金融機関でのKYC（本人確認）
メリット
KYCプロセスの大幅な効率化
コンプライアンスコストの削減
顧客体験の向上（即日開設可能）
3. サプライチェーンでの品質証明
メリット
製品の真正性保証
偽造品対策
消費者への透明性提供
導入時のメリット
業務効率化
証明書確認作業の自動化
人的ミスの削減
処理時間の劇的短縮
コスト削減
書類の郵送・保管コストゼロ
問い合わせ対応工数削減
システム統合コストの削減
セキュリティ向上
偽造・改ざんが不可能
データ漏洩リスクの低減
プライバシー保護の強化
コンプライアンス
GDPR、個人情報保護法への対応
監査証跡の自動記録
eIDAS規則などへの準拠
VCが変えるデジタル社会
Verifiable Credential は、単なる証明書のデジタル化ではありません。
信頼のインフラそのものです。
従来は「発行者に問い合わせる」ことでしか確認できなかった真正性が、
暗号技術により「即座に、誰でも、確実に」検証できるようになります。
この変化は、以下のような社会的インパクトをもたらします。
個人: 自分の資格・経歴を完全にコントロール
企業: 業務効率化とコンプライアンス強化
社会: デジタル化における信頼性の確保
DXを担当する方々は、VCは今後5年で無視できない技術になるでしょう。
特に、
金融機関（KYC）
人材サービス（資格確認）
医療・ヘルスケア（医療記録）
教育機関（証明書発行）
サプライチェーン（品質保証）
といった業界では、早期の実装が期待されています。
まずは小規模なPoCから始めることが、次世代のデジタル社会への第一歩となります。
次回もVC周りの情報についてお届けしたいと思います。
参考情報
W3C Verifiable Credentials Data Model: https://www.w3.org/TR/vc-data-model/
Decentralized Identity Foundation
デジタル庁「トラストサービス検討会」資料
