はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、JSON-LD形式を利用してNFTメタデータを構造化し、外部データとつなげられる仕組みを提案しているERC7280についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
ERC721、ERC1155、ERC3525といった非代替性トークンのメタデータに、リンクされたデータを扱える仕組みを追加します。新しい情報は、従来のメタデータ JSON にある linked_data という項目の中に保存します。
ERC721については以下の記事を参考にしてください。
ERC1155については以下の記事を参考にしてください。
ERC3525については以下の記事を参考にしてください。
ここで扱うリンクされたデータとは、JSON-LDという形式を使い、意味を持たせたデータとして表現できる仕組みです。 JSON-LDは、通常のJSONと同じように扱えますが、外部にある定義やスキーマとつなげられるため、単なる情報の羅列ではなく、関係性や意味を持つデータとして扱えるようになります。
この拡張により、NFTのメタデータがより柔軟になり、複数の規格やサービス間で扱いやすくなります。 画像や名前といった最低限の情報だけでなく、構造化された詳細な情報を保持できるようになるため、NFTがより幅広いコンテキストで利用できるようになります。
動機
現在のNFTで利用されているメタデータ形式は、表現できる内容が限られており、意味を持たせた構造化データを扱うことができません。 例えば、属性や説明を文字として保存するだけでは、別のサービスやアプリケーションがその内容を理解したり、関連付けたりすることが困難です。
JSON-LDを取り入れることで、メタデータに意味や関連性を持たせられるようになります。 外部のスキーマと接続できるため、ほかのシステムと情報を共有しやすくなり、内容の解釈が統一されます。
この仕組みによって、以下のような効果が期待できます。
| 目的 | 説明 |
|---|---|
| メタデータの表現力向上 | これまで難しかった複雑な情報を構造化して扱えるようになります。 |
| 外部データとの連携 | 外部スキーマと接続することで、他システムが意味を理解しやすくなります。 |
| 利用範囲の拡大 | コンテンツの文脈が明確になるため、NFTをより多用途に利用できます。 |
これにより、NFTが単なるデジタル所有権を超え、より実用的で相互運用性の高い存在になります。
仕様
ERCでは、JSON-LD形式のメタデータを既存のメタデータJSONに追加し、linked_data という新しい項目の中に保存します。
linked_data は複数の情報を扱うため配列になっており、その中の各要素は schema と data の2つの項目を持つオブジェクトです。
schema はデータの定義を示し、data は実際の内容を保持します。
以下はメタデータJSONの記述例です。
{
"name": "Example NFT",
"image": "ipfs://example-image",
"linked_data": [
{
"schema": {
"uri": "https://schema.org/Person",
"name": "Person",
"description": "A human individual"
},
"data": {
"uri": "ipfs://example-data",
"lang": "en-US",
"name": "Alice",
"description": "Creator of the asset"
}
}
]
}linked_data
linked_data は必ず配列として定義され、複数の構造化データを扱えます。
配列内の各要素は schema と data を含むオブジェクトであり、両方とも必須項目です。
| 項目名 | 必須レベル | 型 | 説明 |
|---|---|---|---|
schema |
MUST | object | 構造化データのスキーマを示します。 |
data |
MUST | object | スキーマに基づく具体的なデータを示します。 |
スキーマ
schema では、外部スキーマや定義の参照情報を扱います。
URIはスキーマの場所を示し、name はスキーマの識別名です。
description は必要に応じて追加できます。
| 項目名 | 必須レベル | 型 | 説明 |
|---|---|---|---|
uri |
MUST | string | スキーマのURIです。 |
name |
MUST | string | スキーマの名称です。 |
description |
OPTIONAL | string | スキーマの説明文です。 |
データ
data では、実際の内容を表現します。
uri はデータが存在する場所を示し、lang では言語タグを指定できます。
IETF標準の形式を使用し、en-US のように地域を含む表記が可能です。
name と description は必要に応じて設定できます。
| 項目名 | 必須レベル | 型 | 説明 |
|---|---|---|---|
uri |
MUST | string | データのURIです。 |
lang |
OPTIONAL | string | データの言語を示します。IETF言語タグを使用します。 |
name |
OPTIONAL | string | データの名称です。 |
description |
OPTIONAL | string | データの説明文です。 |
ERC7280で linked_data を定義することで、NFTメタデータに意味を持つ構造化情報を追加できるようになり、ほかのシステムとの連携や解釈がより容易になります。
これにより、メタデータの取り扱いが明確になり、拡張性も確保できます。
補足
ERC7280は、NFT用の「普通のWebページ」を用意しやすくするために、JSON-LD形式のメタデータを使えるようにしています。 ここでいうJSON-LDは、「リンクされたデータ（Linked Data）」をJSONで表現するための形式で、検索エンジンなどが意味を理解しやすいデータ構造です。
NFTのメタデータに linked_data 配列が追加されることで、以下のような流れでWebページ側にJSON-LDを埋め込めるようになります。
- NFTのメタデータの
linked_data配列の中から、JSON-LDとして利用できる要素を探します。 - その要素の中にある
uriを取得します。 uri先からJSON-LDの中身を取得します。- 取得したJSON-LDを、そのNFTを紹介するWebページのHTMLのヘッダ（
<head>タグ内）に埋め込みます。
この流れを踏むだけで、NFTの発行者（minter）が、例えばGoogleの検索結果にどう表示されるかをある程度コントロールできるようになります。 検索エンジンは、HTMLヘッダに埋め込まれたJSON-LDを読み取り、構造化データとして解釈するためです。
さらに、より一般的な「相互運用性」の観点では、linked_data に任意のスキーマとデータを含められることが重要になります。
NFTメタデータの中に、どのような種類のデータでも、対応するスキーマと一緒に格納できるため、そのNFTメタデータ自体をさまざまなアプリケーションの「データソース」として扱えます。
ここでスキーマが存在することによって、実装側は「どのフィールドに何が入っているか」を事前に把握しやすくなります。 その結果、アプリケーションの実装や連携をシンプルにし、同じNFTメタデータを複数のサービスが共通の理解のもとで扱いやすくなります。
互換性
ERC7280は、既存のNFTメタデータ形式と後方互換性を保ったまま拡張されます。
具体的には、linked_data という新しいキーを追加していますが、これはあくまで「追加の項目」であり、必須ではありません。
そのため、以下のような点が保証されています。
- すでに発行されているNFTや、従来どおりのメタデータ形式を使っているNFTは、そのまま何も問題なく動作します。
linked_dataキーが存在しないメタデータも、従来と同じように扱われます。- 既存のアプリケーションは、これまで通りメタデータを取得・利用でき、
linked_dataに対応していなくても動作に影響はありません。
つまり、linked_data に対応した実装を行うかどうかは、各アプリケーションやプラットフォーム側の判断に任されます。
対応したい場合は新しいキーを解釈すればよく、対応しない場合でも今までと同じメタデータだけを見て処理を続けられるため、エコシステム全体に対して安全に拡張できる形になっています。
参考実装
ERC7280は、linked_data を利用したメタデータの例を示しています。
以下のJSONは、新しい形式がどのように記述されるかをわかりやすく示したものです。
{
"name": "NFT Name",
"description": "This NFT represents...",
"image": "https://example.org/images/nft.png",
"linked_data": [
{
"schema": {
"name": "VideoObject",
"uri": "https://example.org/schemas/VideoObject.json"
},
"data": {
"uri": "https://example.org/data/video1.json"
}
},
{
"schema": {
"name": "MusicRecording",
"uri": "https://example.org/schemas/MusicRecording.json"
},
"data": {
"uri": "https://example.org/data/music1.json"
}
},
{
"schema": {
"name": "GoogleTravelImpactModel",
"uri": "https://example.org/schemas/GoogleTravelImpactModel.json"
},
"data": {
"uri": "https://example.org/data/gtim1.json"
}
}
]
}この例では、linked_data 内に3つのオブジェクトが含まれ、それぞれ異なるスキーマとデータを持っています。
どれか一つの形式に固定されるのではなく、必要に応じて別々のスキーマを追加できます。
以下の表では、それぞれの役割を整理しています。
| 対象 | 説明 |
|---|---|
| VideoObject | HTMLの<head>タグにJSON-LDとして埋め込むことで、Google検索のリッチリザルトに対応できます。 |
| MusicRecording | schema.orgのスキーマに基づいたデータですが、リッチリザルトには対応しません。 |
| GoogleTravelImpactModel | Google専用のスキーマで、特定用途のデータを扱えます。 |
重要な点は、どのスキーマであっても linked_data に追加できることです。特定の規格や用途に縛られず、拡張性の高いメタデータを構築できます。
サンプルとして挙げられているファイルは、以下のようにスキーマとデータが対応しています。
| スキーマファイル | データファイル |
|---|---|
| VideoObject.json | video1.json |
| MusicRecording.json | music1.json |
| GoogleTravelImpactModel.json | gtim1.json |
実装者は必要なスキーマとデータを用意し、linked_data に追加するだけで扱えるため、複雑な処理を追加する必要はありません。
セキュリティ
ERC7280は、既存のNFTやメタデータ処理と比べて、新たなセキュリティ上の問題を追加しません。
linked_data は外部データを参照できるため、次の点に注意する必要があります。
- 外部から取得したデータは、信頼できる場所から配布されているか確認します。
- データの内容をそのまま信用せず、必要に応じて検証します。
- 一般的なNFTのメタデータ処理と同様に、安全な取り扱いを徹底します。
要約すると、特別なリスクが増えるわけではなく、既存のベストプラクティスを守ることで十分に安全に扱えます。
linked_data を使うかどうかに関係なく、外部リソースを参照する場合は、信頼性と検証手順を確保することが重要です。
引用
Yohei Nishikubo (@yoheinishikubo), "ERC-7280: NFT Metadata Extension like JSON-LD [DRAFT]," Ethereum Improvement Proposals, no. 7280, July 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7280.
最後に
今回は「JSON-LD形式を利用してNFTメタデータを構造化し、外部データとつなげられる仕組みを提案しているERC7280」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
