検証可能なクレデンシャルの集合こそがIdentityを形成する理由
maruyamaデジタル領域では、「ID」という言葉があまりに広く使われるせいで、重要な概念の区別が雑に扱われがちです。社員番号、メールアドレス、ログインID、本人確認、権限管理。
これらは日常的に「IDの話」として一括りにされますが、ビジネスやシステム設計の現場でこれらを混同すると、早い段階で運用に無理が生じます。
金融業界向け専門メディアFinextraに掲載されたBo Harald氏の論考は、この混線に対して「Identification does not create identity - sets of verifiable credentials do（識別したからといってIdentityは成立しない。検証可能なクレデンシャルの集合こそがIdentityを形成する）」とストレートに切り込んでいます。
番号を振って相手を識別すること（Identifier）と、その人の実態を証明すること（Identity）は何が違うのか。なぜ「クレデンシャルの集合」という考え方が不可欠なのか。ID設計の成否を分ける3つの概念の整理とともに、その理由を紐解いていきます。
3つの概念の分離
デジタルアイデンティティの設計において、まず以下の3つを明確に区別する必要があります。
Identifier(識別子)：主体を参照するためのラベル
社員番号、口座番号、メールアドレス、DID（分散型識別子）などが該当します。W3Cの仕様においても、DIDは「任意のsubject（主体）を参照するためのIdentifier」と定義されています。
Identifierは「誰の話をしているのか」を特定するただの記号（ラベル）であり、その人がどのような立場で、何をしてよいのかまでを証明するわけではありません。
Identification(識別・証明の行為)：必要な事実を示すプロセス
日本語では「本人確認」と訳されがちですが、実務においては特定の場面で必要な事実を相手に確実に示す行為全体を指します。
いつ、何を、どの相手に、どの条件で明かすかをコントロールする動的なプロセスです。
Identity(アイデンティティ)：属性と関係性の集合体
Harald氏の定義を借りれば、Identityは「その人を成り立たせる属性、役割、関係性、権限のまとまり」です。「誰か（Who）」という情報だけでなく、「どういう立場で」「誰のために」「どの範囲で行動できるのか」までを含めて、初めて「その人が何者か」が成り立ちます。
この3つを混同すると、重大なリスクが生じます。
「社員番号（Identifier）を付与しただけで、その人の役職や現在の権限まで完全に把握できたと勘違いしてしまう」、あるいは「一回ログイン（Identification）できただけで、そのシステム上のすべての権限（Identityの一部）が証明されたと誤解する」といった事態が起きる危険性があるのです。
VCの集合体としてのIdentity
Finextra記事のタイトルで最も特徴的なのは、Identityを「sets of verifiable credentials（VCの集合体）」と複数形で表現している点です。
現実の社会において、人をひとつの属性だけで表現することは不可能です。
氏名や生年月日のほかに、国籍、所属、資格、役職、口座権限など、場面によって必要な情報は変わります。法人であれば登録情報や代表権、AIエージェントであっても動作権限や監査記録といった情報が求められます。
単一の記号（Identifier）だけでは、こうした複雑な情報を表現しきれません。
VC（Verifiable Credentials）がこの領域で力を発揮する理由は、Identityを用途ごとに切り出せる「検証可能な属性の集まり」として柔軟に管理できる点にあります。W3CのVC Data Model 2.0が定義するIHVモデル（発行者・保有者・検証者の三者間モデル）を用いれば、Identityを構成する要素ごとに、発行元や有効期限を持たせることが可能になります。
Identificationの制御で必要な情報だけを選んで渡す仕組み作り
この「必要な情報だけを選んで証明する（Identification）」という考え方が、実務において最も問われるのがデジタルウォレットの設計です。
たとえば、会社の代わりに自動で発注を行う「AIエージェント」がいるとします。このAIが「1万円未満の契約を結ぶ」ときに相手（取引先）へ証明すべきなのは、「このAIには1万円までの決裁権が与えられている」という事実だけです。AIを裏で動かしている担当者の名前や、会社の組織図といった余分な情報まで見せる必要はありません。
実務におけるウォレットを「すべての情報を丸ごと渡すための箱」として設計してしまうと、この柔軟なやり取りが成立しなくなります。Harald氏がウォレットを「コントロールパネル」と呼ぶ通り、その真の役割は「相手と場面に合わせて、必要な証明だけを選んで見せる」という情報のコントロール機能にあります。
番号ベースの管理から抜け出す
DIDやVCは、高いセキュリティやプライバシー保護を可能にする一方で、既存システムとの接続性やリカバリー設計の難易度といった、実装上のトレードオフを抱える技術です。しかしその議論は、しばしば「中央管理に依存しない、新しい独立した識別子」という特定の側面のみを強調し、導入さえすればあらゆる課題が解決するかのように語られがちです。
確かにDIDという新しいIdentifierの規格は、相手を特定するためのラベルとして有用です。
しかし、実装フェーズにおいて直面する本当の壁は「相手を番号で特定できるか」ではなく、「その人がどのような立場で、何の権限を持っているかを、相手にどうやって確実に伝えるか」という権限と信頼の設計にあります。
既存の中央集権的なアクセス管理（IAM）では、外部組織や独立したエージェント間で柔軟な権限委譲を表現しようとするたびに、個別のシステム連携コストが発生します。また、サービス提供側が本来不要な個人情報まで取得してしまうコンプライアンスリスクも無視できません。
こうした「基盤の作り直し」や「情報の過剰取得」といった課題は、私たちReceptが支援するDID/VC基盤の導入プロジェクトにおいて、必要な属性の提示だけで認証を完了させる仕組みを実装することで解消できます。
ひとつのID番号にすべての権限を紐付ける従来の運用（Identifierで縛り付ける運用）を離れ、「必要な属性の提示だけで認証を完了させる仕組み」が可能になるためです。
採用、教育、法人代表、業務委任、越境取引など、私たちが関心を持つ多くの領域では、単なる「識別番号」が一つ付与されているだけでは実務は回りません。相手が求める条件や権限をその時点で正当に持っていることを立証する仕組みが不可欠です。
Identifierは「誰か」を示すただのラベルであり、Identityは「その人が持つ属性や権限の集まり」です。
これらを区別し、必要な権限や属性だけを確実に証明できる仕組みを運用に落とし込むことが、実用的なトラストインフラへの確かな道筋を開きます。
★特別なお知らせ★
デジタルアイデンティティの最新トレンドを毎週お届け！
業界の最前線をまとめた「DID/VC Weeklyレポート」を毎週無料で配信中です。こちらから簡単に登録できますので、ぜひ情報収集や新規事業のタネ探しにご活用ください。
