DID（分散型ID）とは？

DID（Decentralized Identifier、分散型識別子）とは、特定のプラットフォームに依存せず、利用者自身が管理できる識別子の仕様です。W3Cが標準化しており、ブロックチェーンや分散台帳と組み合わせて、本人確認・資格証明・会員管理などに利用されます。従来のID管理がサービス事業者側にIDを預ける形式だったのに対し、DIDは利用者が自身のIDをコントロールできる「自己主権型アイデンティティ（SSI）」の中核技術です。

DIDは「識別子」、VC（Verifiable Credentials／検証可能な証明書）は「属性・資格の証明書」です。たとえば、DIDが「免許証番号に相当する識別子」だとすると、VCは「その免許証に書かれた情報（氏名・有効期限・運転種別など）」に当たります。VCはIssuer（発行者）・Holder（保有者）・Verifier（検証者）の3者モデルで運用され、DIDをHolderの識別子として参照します。両者はセットで設計されるのが標準です。

デジタル証明書（学歴・資格・免許）、サプライチェーンのトレーサビリティ、医療データのアクセス制御、地域通貨や会員証の本人確認の4分野で先行して実装が進んでいます。日本では金融機関のKYC（本人確認）連携、自治体の住民サービス、教育機関の卒業証明書のデジタル化などで実証実験が進んでいます。

PoC段階であれば did:key などの軽量メソッドを利用することで、構築コストを抑えて検証を始められます。本番運用では、DIDメソッドの選定、VCライブラリの実装、鍵管理のセキュリティ設計、ユーザーUXのウォレット設計が主な開発項目になり、規模により数百万円〜数千万円の幅があります。Netsujoでは構想段階の壁打ちから対応しています。

法規制との整合（個人情報保護法・KYC関連法規）、秘密鍵の管理設計、ユーザーが鍵を紛失した場合のリカバリ設計、検証側のシステム連携の4点を設計段階で確認する必要があります。特に「秘密鍵の管理責任をユーザーに渡す」というSSIの思想と、実用上のリカバリ要件のバランス設計がプロジェクト成否を分けます。

用途と運用主体で選びます。PoCや軽量実装には did:key（鍵自体を識別子に変換、即時利用可能）、組織が運営するサービスには did:web（DNSと連動した運用がしやすい）、長期改ざん耐性が必要な公的証明には did:ion（Bitcoin/IPFSベース）や did:ethr（Ethereumベース）が候補です。詳細比較は本記事のDIDメソッド比較表を参照してください。

主に3つのパターンがあります。1) MetaMask等の既存暗号資産ウォレットに拡張する方式、2) アプリ事業者専用のウォレットアプリを開発する方式、3) Microsoft Authenticator・Trinsic 等のサードパーティ DID ウォレットを利用する方式。ユーザー層がWeb3に慣れていない場合は専用アプリかサードパーティ製、開発コストを抑える場合は MetaMask 拡張が現実的です。

併用可能で、実証も進んでいます。マイナンバーカードの公的個人認証サービス（JPKI）で本人確認を行ったうえで、その結果を VC として発行し、DIDで管理する設計が現実的です。デジタル庁の「Trusted Web」推進会議でも、政府公的IDと自己主権型IDを橋渡しする方向性が示されています。

主に3つあります。1) 検証者（Verifier）側のVC検証ロジックを自社実装してしまい、署名検証や revocation チェックが甘くなる、2) revocation（失効）の仕組みを後付けにしてしまい、漏洩時の運用が破綻する、3) ユーザーの秘密鍵紛失時のリカバリ設計を後回しにする。設計段階でこの3点を verifier ライブラリ・revocation registry・recovery flow として明示することが重要です。