LEI・DUNS・IANA番号──企業を指す既存の複数のID体系を1本のURIにまとめるGLUE Identifiersを読む

企業を一意に識別するグローバルなURIスキーム『GLUE Identifiers』を、IETF SPICEワーキンググループのドラフトで確認した。ゼロから新しいID体系を作るのではなく、LEI（法人識別子）・DUNS番号・IANAの企業番号（PEN）・ISO 6523といった既存の識別子体系を`glue:`という共通のURI形式に包む設計で、Microsoftのエンジニアも著者に名を連ねる。

企業や組織を一意に識別する仕組みは、世界にはすでに複数存在する——法人識別子（LEI）、Dun & Bradstreet社のDUNS番号、IANAが管理する私設企業番号（PEN）、ISO 6523……。だが、これらは互いに形式がバラバラで、システム間でやり取りする際に「どの体系のどの番号か」を都度明示する共通の書式がない。IETF SPICE（Secure Patterns for Internet CrEdentials）ワーキンググループのドラフト「GLobal Unique Enterprise (GLUE) Identifiers」（rev10、2026年7月23日更新、著者にMicrosoft社のP. Dingle氏を含む）の本文を確認すると、これらの既存体系を1つのURIスキームにまとめる仕様であることが分かる。

3行まとめ

GLUE URIはglue:<authority-identifier>:<external-identifier>という形式のURIスキーム。既存の企業識別子体系（LEI・DUNS・IANA PEN・ISO 6523など）を、それぞれglue:lei:...のような形で表現できるようにする「ラッパー」的な設計で、新しい採番体系をゼロから作るわけではない

GLUE URIはUS-ASCIIの制限された構文で定義され、パーセントエンコーディングは許可されない。そのため、非ASCII文字を使う外部識別子の体系はこの仕様の対象外になる

IANAレジストリの初期登録内容として、lei（GLEIF管理、大文字を小文字に変換する変換規則）・duns（Dun & Bradstreet管理、ハイフンを削除する変換規則）・pen（IANA管理）・iso6523（コロンをピリオドに置換する変換規則）の4つのAuthority Identifierが定義されている

`glue:pen:32473`という形式

ドラフトが示すGLUE URIの文法と例はこうだ。

Combining these, the ABNF [RFC5234] for a GLUE URI is: glue-uri = "glue:" authority-identifier ":" external-identifier [...] the following is a GLUE URI using the Authority Identifier "pen" and the External Identifier "32473". This example uses the Enterprise Number "32473" reserved for documentation in [RFC5612].

（これらを組み合わせると、GLUE URIのABNF（RFC 5234）は次のようになる。glue-uri = "glue:" authority-identifier ":" external-identifier。以下は、Authority Identifier「pen」とExternal Identifier「32473」を使ったGLUE URIの例だ。この例は、RFC 5612でドキュメント用に予約されているEnterprise Number「32473」を使っている）

glue:pen:32473

つまり「pen」（IANAのPrivate Enterprise Numbers）という既存の識別子体系における企業番号「32473」を、glue:という共通のプレフィックスで包んだ形になる。

既存の識別子体系ごとに定義された「変換規則」

GLUEが偉い点は、既存の識別子をそのまま使い回すのではなく、体系ごとの表記ゆれを吸収する変換規則を明示的に定義していることだ。レジストリの初期登録内容にはこうある。

7.1.2.1. lei: Authority Identifier: lei. URI: glue:lei. Organization: GLEIF. Transformation Rules: Convert uppercase characters to lowercase. [...] 7.1.2.2. duns: [...] Organization: Dun & Bradstreet. Transformation Rules: Delete hyphen characters. [...] 7.1.2.4. iso6523: [...] Organization: ISO/IEC 6523. Transformation Rules: Substitute period for any colon characters.

（7.1.2.1 lei：Authority Identifier：lei。URI：glue:lei。組織：GLEIF。変換規則：大文字を小文字に変換する。7.1.2.2 duns：組織：Dun & Bradstreet。変換規則：ハイフン文字を削除する。7.1.2.4 iso6523：組織：ISO/IEC 6523。変換規則：コロン文字をすべてピリオドに置換する）

LEI（Legal Entity Identifier、法人識別子）はGLEIF（Global Legal Entity Identifier Foundation）が管理する、金融機関の取引相手を一意に識別するための国際的な識別子体系で、DUNS番号は与信管理などで広く使われている民間の企業識別子だ。GLUEはこれらの「表記」をglue:という共通のURI形式に正規化するための、変換規則の集合としても機能する。

RFC化まであと一歩──だが議長団への「スコープ疑義」が残っている

このドラフトはIETF SPICEワーキンググループの正式な成果物（draft-ietf-のプレフィックスが付く）であり、この記事で扱ってきた他の多くの個人ドラフトとは異なり、ワーキンググループとしての合意形成プロセスを経ている。IETF Datatrackerの該当ページを改めて確認すると、この記事が想定していたよりもずっと先の段階に進んでいることが分かった。

項目	内容
著者	Brent Zundel、Pamela Dingle、Michael B. Jones
意図するRFCステータス	Proposed Standard
WGの状態	Submitted to IESG for Publication(IESGへ発行のため提出済み)
IESGの状態	IESG Evaluation::AD Followup
完了した正式レビュー	SECDIR(2回)・ARTART・GENART、いずれも「Ready」または「Ready w/nits」
総括	「Needs a YES. Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.」(承認にはYESが必要。DISCUSSが1件残っているが、それが解消されれば通過できるだけの賛成は集まっている)

つまりこのドラフトは、SECDIR・ARTART・GENARTという正式なレビューチームの審査を経て、すでにIESG(IETF全体の技術運営を担う最終承認機関)での評価段階にあり、RFC化まであと一歩のところまで来ている。

一方で、IESGメンバーのRoman Danyliw氏が出している「DISCUSS」(解消されるまで承認をブロックする異議)の中身をBallotページで確認すると、内容面の技術的な欠陥ではなく、手続き上の疑義であることが分かる。

For the responsible AD and WG Chairs: could the alignment of this document and the chartered scope of the SPICE WG be explained. [...] The program of work lists three items, none of which appear to align with this document [...] "IANA is NOT OK" -- The URN registration was not sent out in advance of this document being on the docket, but more importantly, the DE has significant feedback.

（責任者のADとWG議長団へ:この文書とSPICE WGの憲章上のスコープとの整合性を説明してほしい。作業計画には3項目が挙げられているが、いずれもこの文書とは一致していないように見える。「IANAはOKを出していない」──URN登録がこの文書の審議前に事前送付されておらず、それ以上に問題なのは、指定専門家(DE)から重要なフィードバックが来ていることだ）

つまり、GLUE Identifiersという文書自体の技術的な設計ではなく、「この文書はそもそもSPICE WGが正式に取り組むと合意した作業範囲(charter-ietf-spice-01で定義された3項目)に含まれているのか」という手続き上の疑義が、RFC化最後の関門として残っている。技術内容ではなく標準化プロセスの整合性が争点になっている、という点は、この記事の当初の調査(ドラフト本文のみを読んだ範囲)では見えていなかった。

DISCUSSが実際にいつ解消されるかは追えていない

Ballotページでこの手続き上の疑義を確認できた一方、responsible ADのChristopher Inacio氏やWG議長団がこのDISCUSSにどう応答したか、あるいは今後どう解消される見込みかは、この記事のBallotページの確認範囲(2026年8月31日時点のスナップショット)では分からなかった。メーリングリストでの実際のやり取りまでは追っていない。GLUE URIが、AIエージェントによる企業識別という文脈でどう使われることを想定しているかについても、この記事の一次ソースの範囲では明示的な記述を見つけられなかった（ドラフト自体はAIエージェントに限定した用途を謳っていない、企業識別子の一般的な標準化提案として書かれている）。この記事を書いている自分自身は、LEIやDUNS番号を業務で扱った経験がなく、既存の企業識別子体系の実務における使われ方についての土地勘は持たない。日本語ではZenn・Qiitaともに、GLUE Identifiers単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。