AT ProtocolのURI構文問題 RFC-3986非準拠の衝撃と解決への模索
AT Protocolで使われるAT URIがRFC-3986に準拠していない問題が表面化。IETF標準化の障害となり、開発者コミュニティで議論が活発化している。
分散型SNSプロトコル「AT Protocol」の中核をなすURIスキーム「AT URI」が、インターネット標準であるRFC-3986に準拠していない問題が浮上した。Blueskyのプロトコル設計者Bryan Newboldが自身のブログで詳細を公開し、コミュニティに衝撃が走っている。この問題は、IETF(Internet Engineering Task Force)における標準化の障害となるだけでなく、HTMLの<link>タグなど既存のURIパーサーとの互換性にも支障をきたしている。
問題の核心
AT URIは、at://did:plc:vwzwgnygau7ed7b7wt5ux7y2/app.bsky.feed.post/3k5nobkf2w72gのような形式をとる。スキームの直後にdid:plc:...というDID(Decentralized Identifier)が「authority」(権威)部分に置かれる。この設計がRFC-3986で定められたホスト+ポートの階層構造と衝突する。
RFC-3986のsection 1.2.3では、URIスキームによっては可視的な階層をスキーム自体に限定し、スキーム区切りより後を「不透明」として扱うことを許容している。Newboldはこの規定を根拠に、AT URIがRFC-3986に準拠していると2022年の設計時には判断していた。しかし、その後、より厳密な解釈ではDIDをauthorityに設定することが許容されないことが判明した。
なぜ今問題になったのか
この問題は2025年に初めてGitHubのissueで指摘された。しかし、最近になって顕在化した要因は二つある。一つは、AT URIをHTMLの<link>タグなど、適切に整形されたURI(またはURL)を期待する場所で使おうとする事例が増えたこと。もう一つは、AT ProtocolのワーキンググループがIETFでAT URIスキームを恒久登録することを目標として掲げており、標準化プロセスでこの非準拠が障害となっていることだ。
設計思想と現実のギャップ
Newbold自身は、AT URIをプロトコルの中でも最重要かつ最も優れた機能の一つと評価している。authority部分にプロバイダのホスト名ではなく個別のアカウント識別子を置く設計は、アカウントが自らのコンテンツの最終的な権威であり、プロバイダ間をシームレスに移動できるというAT Protocolの大原則を象徴する。この思想自体は変更されるべきではないと彼は主張する。
しかし、標準化と相互運用性を重視するIETFの枠組みの中で、この革新的な設計が曲げを強いられている。
影響範囲
問題の影響は多岐にわたる。まず、既存のURIパーサーライブラリの多くはAT URIを正しく解析できない。WHATWG(Web Hypertext Application Technology Working Group)のURL仕様の下では、AT URIは有効なWeb URLとして認識されない。さらに、<link>タグや<a>タグに使うことができず、Blueskyエコシステム外でのリンク共有に支障が出る。IETFでの恒久登録には、RFC-3986準拠が事実上必須であり、現状のままでは標準化が頓挫する可能性が高い。
可能な解決策
Newboldは可能な前方互換性のある修正案をいくつか提示しているが、どれも完全ではない。考えられる方向性として、以下のような選択肢が議論されている。
第一に、authority部分の文法を変更し、DIDを特別にエスケープする方法。これにより既存のURIパーサーでも処理可能になるが、既存のAT URIとの互換性が失われる。
第二に、URIスキームのセマンティクスを拡張し、DIDをauthorityとして受け入れる新しいRFCを策定する方法。しかしこれはIETFの合意形成に時間を要する。
第三に、AT URIを完全に新しいURIスキーム(例えばatdid:など)に置き換える方法。最も破壊的だが、長期的には最もクリーンな解決策となる可能性がある。
Newboldは「どの道を選んでも、エコシステムに一定の開発者の痛みと混乱をもたらす」と警告している。現時点では、Bluesky社内およびコミュニティで合意形成が進められている段階だ。
編集部の見解
短期的には、AT URIの非準拠問題は同プロトコルの普及を鈍化させる可能性がある。特に、BlueskyをSNSとして利用する範囲では問題が表面化しにくいが、サードパーティ開発者がアプリケーションを構築する際にURIパースでエラーが発生し、開発体験を損ねるだろう。IETFでの標準化が遅れれば、他の分散型プロトコル(ActivityPubなど)との相互運用性を目指す動きにも悪影響が及ぶ。 長期的に見ると、この問題は分散型プロトコル設計がインターネット標準との整合性をどれほど重視すべきかという根本的な問いを投げかけている。AT Protocolの「アカウントが権威である」という設計思想は革新的だが、既存の標準に適合させるための妥協点を見つける必要がある。もしこの問題を乗り越えられれば、AT URIは分散型識別子をURIに統合する先例となり、将来のプロトコル設計に影響を与える可能性がある。 編集部としては、IETFのワーキンググループがどのような妥協案を提示するかが最大の注目点だと考える。
参考
- The AT-URI Syntax Mess — 2026-06-29公開
よくある質問
- AT URIとは何か
- AT Protocol(Blueskyが開発する分散型SNSプロトコル)で使われるURIスキーム。`at://`で始まり、アカウントのDID(分散型識別子)をauthority部分に持つ。個々の投稿やレコードを一意に識別するために使われる。
- RFC-3986非準拠の実害は何か
- HTMLの`<link>`タグや`<a>`タグにAT URIを直接埋め込めない、既存のURIパーサーライブラリで正しく解析できない、IETFでの恒久登録が認められないなど、相互運用性と標準化に重大な支障が出る。
- どうすれば解決する見込みか
- 現時点ではBluesky社内とコミュニティで議論中。DID部分の文法変更、URIパーサーの拡張、完全な新スキームへの移行など複数の選択肢が検討されている。どの案も既存のAT URIとの互換性を一部犠牲にするため、合意形成は容易ではない。
コメント