DIDは結局何をしているのか
Blueskyや、その基盤技術であるAT Protocolでは、ユーザーのアイデンティティとして did:web と did:plc という2種類のDIDメソッドが使われています。
この記事では、これらのDIDが実際にどんな役割を持っていて、Blueskyの中でどう動いているのかを整理します。
1. DIDの仕事は「解決」すること
DID（分散型識別子）の最も本質的な役割は「解決」することです。
DIDそのものは、単なる「ポインタ」に過ぎません。ユーザーの公開鍵やサービスのエンドポイントといった実体情報は、DIDそのものに含まれているのではなく、DID Document と呼ばれる別のドキュメントに記述されています。 つまり、DIDと実体（DID Document）は切り離されて管理されています。
実際にDIDを利用するときは、この識別子をキーとしてDID Documentを探し、その中身を参照する必要があります。この「DIDからDID Documentを引っ張ってくるプロセス」こそが「解決」です。
この仕組みの最大の利点は、実態が移動してもDIDを変えずに済む という点にあります。 例えば、利用しているPDSサーバーが変更したり鍵を更新したりしても、DID Documentの内容を書き換えるだけで済みます。DID自体は変わらないため、フォロワーとの繋がりや過去の投稿との紐付けは維持されます。
これは、特定のサーバーやプラットフォームへの依存を大きく下げ、アカウントの主権（コントロール権）をユーザー自身に取り戻すための重要なアーキテクチャになっています。
2. did:webの解決
Blueskyでは標準の did:plc に加えて、did:web も使えます。
これは、Webのドメイン名をそのままIDとして扱うやり方です。
仕組み
形式は did:web:{domain} です。
例えばドメインが example.com なら、DIDは did:web:example.com になります。
このDIDを解決してDID Documentを取りに行くときは、とてもシンプルです。
そのドメインの /.well-known/did.json にHTTPSでアクセスするだけです。
GET https://example.com/.well-known/did.json
このURLから返ってくるJSONが、そのままDID Documentになります。
既存のWebサーバーとDNSの仕組みをそのまま流用できるので、実装が簡単なうえ、ドメインさえ持っていれば誰でもすぐに作れます。
ドメインは「借り物」である
一方で、did:web にはアイデンティティの永続性という観点で課題もあります。
それは、ドメインはあくまでレジストラから借りているもの だという点です。
もしドメインの更新を忘れて有効期限が切れてしまったり、別のドメインに引っ越したりした場合、その did:web は無効になるか、最悪の場合は他人の手に渡ってしまいます。
DIDが変わってしまうと、システム上は「別人扱い」になります。 つまり、過去の投稿との紐付けやフォロワーとの繋がりを失うリスクにつながるというわけです。
企業のような、ある程度長期的にしっかりドメインを管理できるアカウントならそこまで問題にならないかもしれませんが、「個人のID」として考えると、少し心もとない気がします。
3. did:plcの解決
Blueskyでアカウントを作ると、デフォルトで割り当てられるのが did:plc です。
これは、さきほどの did:web が抱えていた「ドメイン（特定の管理者）への依存」を減らし、ユーザー本人に主権を戻すことを狙って設計されたメソッドです。
仕組み
形式は did:plc:{string} のような形で、後ろについているランダムに見える文字列は、アカウント作成時の最初の操作（Genesis Operation）をハッシュ化してBase32エンコードしたものの、先頭24文字部分です。
did:plc の最大の特徴は、DID Documentの変更履歴がすべて 署名された操作ログ（Operation Log） として管理されている点です。
DID Documentを更新したいとき（例えば、PDSの引っ越しや鍵の変更など）には、ユーザーは「操作用鍵対（Rotation Key）」の秘密鍵を使ってその変更操作に署名を行います。
この署名を検証することで、「この変更が正当な所有者によって行われたこと」を確認できます。これにより、特定のサーバー管理者に依存せず、数学的な正当性によってIDのコントロール権を担保しています。
PLC Directoryの役割と「Placeholder」
しかし、ここで一つ問題が生じます。 もし「正しい署名がされた変更」が同時に複数出てきたら、どちらを先に適用すべきでしょうか？
この順序性（Anti-forking）を保証するために存在するのが PLC Directory というサーバーです。
did:plc の解決は、このPLC Directoryに対して問い合わせることで行われます。
GET https://plc.directory/{did}
PLC Directoryは、署名されたOperation Logを正しい順序で保存・提供する役割を担っています。
これにより、did:plc は高い利便性とポータビリティを実現していますが、可用性の面ではPLC Directoryという単一のシステムに依存しているとも言えます。
plc が "Placeholder" の略なのは、このような背景だからなのです。
4. did:plcの書き換え
では、実際に did:plc の内容（DID Document）を更新する際、裏側ではどんなことが行われているのでしょうか。
Operationの作成とPOST
書き換えを行うには、変更内容を含んだ Operation（操作ドキュメントみたいなもの）を作成し、署名（sig）を添えてPLC DirectoryにPOSTします。
ここで注意したいのは、Operationの構造はDID Documentそのものとは微妙に違う という点です。
ぱっと見はよく似ていますが、Operationはあくまで「変更指示のための(多分)独自形式」であり、たとえば verificationMethod の表現方法などは、DID Documentの標準的な形式とは異なる形になっています。
もう一つ重要なルールとして、Operationには必ず 「直前の操作ログのID（CID）」を含める 必要があります。
「前回の状態はこのCIDで、その続きとして今回の変更を適用します」という形でブロックチェーンのようにつないでいくことで、あとから履歴を書き換えられないようにしています。
鍵の役割分担
did:plc では、権限の異なる2種類の鍵を使い分けています。
-
Rotation Keys（管理用の鍵） DID Document自体を書き換える権限を持つ、アカウント制御の根幹となる鍵です。 Operationへの署名は必ずこの鍵で行います。複数の鍵を登録でき、その並び順によって優先順位が決まるため、「普段の管理用」と「緊急時のリカバリー用」といった階層的な運用が可能になっています。
-
Verification Methods（利用用の鍵） 日々の投稿への署名やログイン認証など、アプリケーションを利用するために使う鍵です。 DID Document内でも公開され、他者はこの鍵を使って「投稿が本人によるものか」を検証したりします。
使い方
-
PDS（サーバー）を引っ越す場合: Operation内の
servicesにあるatproto_pdsのエンドポイントURLを新しいサーバーのアドレスに書き換え、Rotation Keyで署名してPOSTします。 -
鍵をローテーション（交換）する場合: 例えば「利用用の鍵」が漏洩した疑いがある場合、新しい鍵を生成して
verificationMethodの部分を書き換え、現在の有効な Rotation Key で署名して更新します。 もし「管理用の鍵（Rotation Key）」自体を交換したい場合は、更新前の Rotation Key で署名を行うことで、新しい Rotation Key へ権限を移譲します。
5. まとめ
DID自体の役割は結局「DID Documentを解決すること」にあります。
did:web は、既存のWeb（DNS）の仕組みを信頼の基盤とすることで、シンプルさと導入のしやすさを実現しています。
一方で did:plc は、署名技術と操作ログのチェーンを用いることで、特定の管理者への依存を減らし、高いアカウントポータビリティ（持ち運び可能性）を実現しています。
アプローチは異なりますが、どちらも「ユーザー主権のアイデンティティ」を実現するための技術です。 私たちが普段何気なく行っている投稿や「いいね」の裏側では、こうしたDIDの仕組みを通じて鍵が解決され、「確かにこの人によるものだ」と検証可能な形でネットワーク上に載っています。
Blueskyが目指す「ロックインのないSNS」は、こうした見えないIDの仕組みによって支えられているのです。
参考
(どうでもいいですがdid:plcのspecのバージョンはv0.2.1なのにURLがv0.1なのはいいのだろうかと思ったり...)
