DID（分散型ID）とは？
仕組みから活用事例・開発方法まで解説
パスワード漏洩、プラットフォーム依存、データの一元管理リスク。従来のID管理の限界が顕在化しています。
DID（Decentralized Identifier）は、W3C標準の分散型ID仕様で、これらの課題をアーキテクチャレベルで解決します。本記事では仕組み・活用事例・開発に必要な技術スタックを整理します。
ー 01
従来のID管理の課題とDIDが注目される背景
2023年の主要サービス漏洩件数は世界で8億件超（IBM Security調べ）。IDとパスワードの組み合わせに依存する認証モデルは、攻撃者にとって単一障害点を提供し続けています。
プラットフォーム依存の問題も深刻です。TwitterのAPIポリシー変更で数百万ユーザーが一夜にしてサービスを失ったように、中央集権型のIDはプラットフォーム側の意思決定に完全に従属します。
従来型ID管理が抱える3つの構造的問題
これらの課題に対して、「ユーザーが自分のIDを所有・管理する」というSSI（Self-Sovereign Identity）の概念が台頭しています。DIDはそのSSIを技術標準として実装するための仕様として、W3Cによって2022年7月に勧告（Recommendation）化されました。
EU eIDAS 2.0（2024年〜）による電子ウォレット義務化、デジタル庁の実証実験など、公共インフラとしての採用が本格化しています。
ー 02
DIDとは — W3C標準の定義と従来IDとの比較
DID（Decentralized Identifier）は、W3Cが標準化した分散型識別子の仕様です。形式は did:method:identifier のURI形式で表現されます。例：did:ethr:0x1234...abcd
最大の特徴は「中央の認証機関に依存しない」点です。特定企業やサーバーが停止しても、DIDの有効性はブロックチェーン等の分散台帳によって維持されます。
Centralized ID
サービスごとにIDとパスワードを管理します。プラットフォーム側がデータを保有し、漏洩・削除・サービス終了のリスクをユーザーが負います。
Federated Identity
Google・Apple等のプロバイダーに認証を委任します。利便性は上がりますが、プロバイダーへの依存度が増します。アカウント停止でサービス利用不可になるリスクがあります。
Decentralized Identifier
W3C標準のID形式です。ブロックチェーン等の分散台帳にIDを登録し、ユーザー自身がIDを管理します。特定プラットフォームへの依存がありません。
DIDが解決するもの・解決しないもの
解決するもの
- ✓プラットフォーム依存からの脱却
- ✓必要な属性だけを選択開示できる
- ✓単一障害点の排除
- ✓クロスサービスでのポータブルなID
解決しないもの
- ✗秘密鍵紛失リスク（鍵管理は依然必要）
- ✗オンチェーンデータの永続性（GDPR削除権との矛盾）
- ✗ユーザーがID管理の責任を持つことのUX負荷
ー 03
DIDの仕組み — DID Document・VC・DIDメソッドの3要素
DIDエコシステムは3つの技術要素で構成されます。それぞれの役割を理解することが、DID実装の設計判断の基礎になります。
DID Document
DIDに紐づくメタデータの集合体です。公開鍵・認証方式・サービスエンドポイントなどを記述したJSONドキュメントで、ブロックチェーンや分散ストレージに格納され、誰でも参照可能な公開情報として機能します。
Verifiable Credentials（VC）
W3C標準の「検証可能な資格情報」仕様です。発行者（Issuer）がDID署名で発行し、保有者（Holder）がウォレットで管理し、検証者（Verifier）が署名を確認する3者モデルです。学歴・資格・属性情報を改ざん不可能な形で表現できます。
DIDメソッド
DIDの作成・解決・更新・失効の操作仕様を定義するプロトコルです。did:ethr（Ethereum）、did:ion（Bitcoin Layer2）、did:key（ローカル鍵ペア）など100以上のメソッドが登録されています。用途・規制・インフラ要件に応じてメソッドを選定します。
VCの3者モデル（Issuer / Holder / Verifier）
大学・政府・企業など。DID署名でVCを発行します。発行したVCの内容に対して責任を持ちます。
VC受領者。デジタルウォレットで保管し、必要なタイミングで提示します。何を誰に開示するか自身で決定できます。
VCを受け取る側。Issuerの公開鍵でデジタル署名を検証し、VC内容の真正性を確認します。Issuerへの問い合わせは不要です。
Netsujoが開発したDIDプラットフォーム
Netsujoは地域通貨・デジタル会員証向けのDIDプラットフォームを自社開発・運用しています。did:ethrベースの実装でVC発行・ウォレット管理・検証APIをワンストップで提供しています。詳細はDIDプラットフォームページを参照。
ー 04
DIDの活用事例 — 4つのユースケース
DIDの実用化は特定の産業・業態で先行しています。以下の4事例は、技術的な成熟度が高く、ROIを算出しやすい領域です。
大学の卒業証書、国家資格、研修修了証などをVCとして発行します。転職・入学・融資の場面で提出するたびに発行機関に問い合わせる手間がなくなります。偽造検証は署名確認のみで完結し、検証コストを大幅に削減できます。
製品の原材料・製造工程・輸送経路の各ステップをDIDで署名し、改ざん不可能なトレーサビリティを構築します。フェアトレード認証・有機認証・カーボンフットプリントの証明など、ESG文書の信頼性を担保するユースケースで導入が進んでいます。
患者が自分の医療記録・投薬履歴・検査結果をVCとして保有し、必要な情報だけを医療機関や保険会社に選択的に開示します。GDPR・個人情報保護法への対応として、データ最小化原則をアーキテクチャレベルで実装できます。
自治体・商店街・コミュニティが発行するDIDベースの会員証・ポイントです。中央管理サーバーを持たずに発行・認証が可能で、スマートコントラクトと組み合わせることで地域経済圏の自律的な運営が実現します。Netsujoが開発したCycleはこのモデルを採用しています。
PoCとしてDIDを試したい場合
上記のユースケースはいずれもPoC段階から始められます。DIDの技術検証は did:key を使えばブロックチェーン不要で実施できるため、2〜4週間・数十万円規模からの検証が可能です。PoC設計の詳細は「PoCとは？進め方・費用・成功のポイントを解説」で解説しています。
ー 05
DID開発で必要な技術スタック
DID実装では、既存のWeb認証スタックとは異なるレイヤーの技術選定が必要になります。主要な選定カテゴリを整理します。
did:ethr
Ethereumベース。EVM互換チェーン全般に対応。エンタープライズ実績が豊富。
did:ion
Bitcoin Layer2（Sidetree）。マイクロソフト主導。高いセキュリティ要件に対応。
did:key
ブロックチェーン不要。鍵ペアのみでDIDを生成。PoC・クローズド環境に適合。
Veramo
Node.js製VCフレームワーク。複数DIDメソッドに対応し、プラグイン構成で拡張可能。
SpruceID / DIDKit
Rust製。軽量でモバイル・エッジ環境への組み込みに向いている。
Walt.id
エンタープライズ向けのオープンソースWalletおよびVC発行インフラ。EU eIDASとの親和性が高い。
MetaMask / WalletConnect
EVM系DIDの秘密鍵管理。ブラウザ拡張またはモバイルアプリで署名操作を提供。
HSM / AWS KMS
エンタープライズ向け鍵管理。ハードウェアセキュリティモジュールで秘密鍵をオフライン保護。
Custodial Wallet
ユーザーに鍵管理を求めない設計。UX優先の場合に採用されますが、自己主権性は低下します。
チェーン選定の判断軸
パーミッションレス（Ethereum/Polygon等）：オープンなエコシステムに参加でき、既存ウォレットを再利用できます。ガス代・トランザクションレイテンシが課題です。
パーミッションド（Hyperledger Besu等）：参加者を制限でき、規制業種での採用に向いています。スループットが高い反面、エコシステムの規模は小さくなります。
チェーンレス（did:key / did:web）：最もシンプルで導入コストが低く、PoC・クローズドユースケースに適合します。ただしDID失効には外部インフラが必要です。
ー 06
DID導入時の注意点
DIDの技術的成熟度は高まっていますが、本番導入には技術以外の領域での準備が必要です。見落とされやすい3点を整理します。
法規制・標準への整合確認
EU eIDAS 2.0は2024年からEUウォレットの義務化を段階的に進めています。日本では2026年現在、デジタル庁が「デジタル認証アプリ」でDIDベースの電子証明書実証を行っています。本番導入前に適用法規と既存標準との整合を確認する必要があります。
秘密鍵の紛失・失効設計
秘密鍵を紛失するとDIDの制御を失います。ソーシャルリカバリー（複数の信頼者に分散管理）、HSMによるバックアップ、カストディアル設計のどれを採用するかを設計段階で決定する必要があります。失効（Revocation）の仕組みもVC発行と同時に設計しておきます。
ユーザーUXの簡素化
DIDの技術的な複雑さをそのままユーザーに見せると離脱率が高くなります。鍵管理をバックグラウンドに隠蔽し、ユーザーに見える操作は「証明書を追加する」「開示する」の2ステップに絞るUIが採用されています。エンタープライズ向けでは、既存の社内IdP（SAML/OIDC）とのブリッジ実装が現実的です。
設計段階で確認すべき問いリスト
- ▸秘密鍵を紛失したユーザーのリカバリーフローはあるか？
- ▸発行したVCを失効させる仕組みはあるか（Revocation Registry）？
- ▸オンチェーンデータのGDPR削除権への対応方針は確認済みか？
- ▸ウォレットを持たないユーザーのオンボーディング手段はあるか？
- ▸既存のIdP（Active Directory等）とのブリッジは必要か？
Web3・ブロックチェーン全般の戦略設計について
DID導入判断はブロックチェーン活用戦略の一部です。技術選定だけでなく、法規制・既存システムとの統合・ROI設計まで含めたコンサルティングも提供しています。
Web3コンサルティングサービスを見るまとめ
DIDはW3C標準として策定された分散型IDの仕様です。プラットフォーム依存・過剰な情報開示・単一障害点という従来型ID管理の3つの構造的問題に対して、アーキテクチャレベルで解決策を提供します。
仕組みの中核はDID Document・Verifiable Credentials・DIDメソッドの3要素です。VCの3者モデル（Issuer/Holder/Verifier）を理解することが、DID実装設計の出発点になります。
活用領域はデジタル証明書・サプライチェーン・医療データ・地域通貨の4分野が先行しています。技術スタックはDIDメソッド選定・VCライブラリ・鍵管理の3レイヤーで構成されます。
導入時は法規制整合・鍵管理設計・ユーザーUXの3点を設計段階で確認する必要があります。PoC段階は did:key を活用すれば低コストから検証を開始できます。
DID開発・分散型ID実装
DID基盤の設計から
本番運用まで対応
DIDプラットフォームの自社開発・運用実績を持つNetsujoが、設計選定からVC発行基盤構築・既存システム統合まで一気通貫でサポートします。初回相談は無料です。