Verifiable Credentials
ブロックチェーンとDID／VCの違い‐基本事項‐
公開日 ：
DIDやVCはブロックチェーンの技術だと思われがちですが、両者は別のものです。証明を台帳に記録しないという設計の違いと、それが導入判断にどう影響するかを解説します。
この記事でわかること
- VCとブロックチェーンが、そもそも別の問題を解いていること
- ブロックチェーンが必要になる場面と、不要な場面
- 検討を始めるときに、何を前提にしなくてよいか
リード
DID（分散識別子）やVC（Verifiable Credentials）を説明すると、「それはブロックチェーンですか」と聞かれることがよくあります。関係がないわけではありませんが、同じものではありません。混同したまま検討を進めると、判断を誤ります。
先に、結論から
VC（Verifiable Credentials）を使うのに、ブロックチェーンは必要ありません。
両者は、解いている問題が違います。ブロックチェーンは、多数の参加者のあいだで同じ記録を一致させるための仕組みです。VCは、誰が何を保証したのかを、受け取った側がその場で確かめるための仕組みです。前者は台帳を共有することで、後者は電子署名を検証することで、それぞれの目的を果たします。
VCは、証明の中身を台帳に書き込みません。証明は本人の手元に置かれ、必要なときだけ相手に渡ります。だから、全参加者で記録を共有する必要がないのです。
検討を始めるにあたって、ブロックチェーンを前提にする必要はない。以下、なぜそう言えるのかを順に説明します。
前提：VCとは何か
VC（Verifiable Credentials）は、改ざんされたことが分かるデジタルの証明書です。社員証や資格証、委任状にあたるものをデータとして持ち運べるようにして、受け取った相手がその場で本物かどうかを確かめられるようにしたものです。
DID（分散識別子）は、その証明が本物かを確かめるときに必要な「発行者の公開鍵」を、どこから取ってくるかを解決するための仕組みです。
なぜ混同されるのか
DIDやVCは、自己主権型アイデンティティと呼ばれる考え方の中から出てきました。証明を発行元のデータベースに預けたままにするのではなく、本人が自分で持ち、必要なときに自分で提示する。そういう発想です。この考え方が広まりはじめた2010年代後半、実装の多くがブロックチェーンを前提にしていました。
「分散」という語が共通していることも、混同を招いています。分散型台帳、分散識別子。どちらも中央の管理者を置かないという発想は共有していますが、実現の方法は違います。
いまの標準仕様では、VCはブロックチェーンを必要としません。W3Cが定めるデータモデルは、どこに何を記録するかについて特定の技術を指定していないためです。
ブロックチェーンが解いている問題
ブロックチェーンは、多数の参加者が同じ記録を共有し、後から書き換えられないようにするための仕組みです。誰が誰にいくら送ったかといった取引の履歴を、中央の管理者なしで一致させたい。この問題を解くために作られました。
台帳に書き込まれた内容は、参加者全員が同じものを見ます。合意の仕組みがあるため、一部の参加者が勝手に書き換えることはできません。
VCが解いている問題
VCが解こうとしているのは、別の問題です。ある主体について「誰が、何を保証したのか」を、受け取った側がその場で確かめられるようにすること。
そのために使うのは、電子署名です。発行者が証明の内容に秘密鍵で署名を付け、受け取った側は公開鍵でその署名を検証します。内容が書き換えられていれば検証は通りませんし、秘密鍵を持たない者は署名を作れません。
ここで重要なのは、検証に台帳を必要としないことです。証明そのものが署名付きのデータであり、それを持っている人が提示し、受け取った側が数学的に確かめる。全参加者が同じ記録を共有する必要がありません。
どこでブロックチェーンが出てくるのか
では、なぜブロックチェーンの話が出るのか。関係するのは、公開鍵をどこから取ってくるかという部分です。
署名を検証するには、発行者の公開鍵が必要です。その鍵を、識別子から引けるようにする仕組みがDID（分散識別子）です。そしてDIDには複数の方式があり、そのうちのいくつかが分散台帳を使います。
一方で、台帳を使わない方式もあります。自社のWebサイトのアドレスをそのまま識別子として使い、いつものWebサーバーから公開鍵を配る方式であれば、必要なのは通常のWebサイトを公開するのと同じ仕組みだけです。企業が自社の従業員やAIエージェントに証明を発行する用途では、こちらで足りることが多くなります。
つまり、ブロックチェーンは選択肢のひとつであって、前提ではありません。
証明の中身は台帳に載せない
もうひとつ、設計として押さえておきたい点があります。VCの内容そのものを台帳に書き込むことは、通常しません。
理由は2つあります。
ひとつは、プライバシーです。所属や資格といった情報は、必要な相手にだけ見せるものです。全参加者が閲覧できる場所に置く設計にはなっていません。VCは保有者の手元に置かれ、提示するときだけ相手に渡ります。
もうひとつは、消せなくなることです。ブロックチェーンは書き換えられないことが利点ですが、それは削除もできないという意味でもあります。個人情報保護法制では本人からの消去の求めに応じる必要がありますが、台帳に書き込んだ情報は消せません。この不整合は、実務上かなり重い制約になります。
失効の情報については公開する必要がありますが、これも台帳でなくWebサーバーからの配布で実現できます。
比較
| ブロックチェーン | DID／VC | |
|---|---|---|
| 解いている問題 | 多数の参加者で同じ記録を一致させる | 誰が何を保証したかをその場で確かめる |
| 中核の技術 | 分散台帳と合意形成 | 電子署名 |
| 証明の保管場所 | 台帳（全参加者が共有） | 保有者の手元 |
| 検証の方法 | 台帳を参照する | 署名を検証する |
| 個人情報の扱い | 書き込むと削除できない | 台帳に載せない設計 |
| ブロックチェーンの要否 | 前提 | 選択肢のひとつ |
導入を検討する側にとっての違い
実務的には、次の点が変わります。
検討の前提が軽くなります。どのチェーンを使うか、手数料をどう負担するか、ネットワークをどう運用するか、といった論点が、必ずしも必要になりません。既存のWebサーバーと鍵管理の延長で構成できる場合があります。
法務や監査への説明がしやすくなります。電子署名の仕組みは、電子契約などですでに使われています。個人情報を台帳に書き込まないことも、説明の負担を下げます。
既存の仕組みとつながります。社内のID管理や証明書の運用と地続きで考えられるため、情報システム部門にとって理解しやすい構成になります。
判断の目安
社内のAIエージェントに権限を持たせる、従業員の所属を証明する、取引先に資格情報を示す。こうした用途では、台帳を使わない構成で十分に成立します。
一方、多数の組織が対等な立場で参加し、誰が信頼できる発行者なのかという一覧そのものを共同で管理したい、といった場面では、分散台帳が選択肢に入ることがあります。ただ、その判断は業界単位の枠組み作りの話であり、個々の企業が導入を検討する段階で扱う論点ではありません。
まずは、ブロックチェーンを前提にせずに検討を始めて構いません。
