NFTメタデータ標準

NFTメタデータ標準とは？

NFTメタデータ標準とは、暗号資産アプリケーションが非代替性トークン（NFT）の表すものを理解できるようにする、スマートコントラクトのインターフェース、JSON形式、URIルール、ストレージの運用方法の集合です。

NFTはオンチェーンで所有権を証明できますが、ユーザーが実際に目にする資産の内容はメタデータが説明します。名前、画像、説明、特性、アニメーション、ゲームのステータス、外部コンテンツなどが含まれます。

ほとんどの暗号資産エコシステムでは、トークンの記録とメディアの記録は別々のレイヤーです。

トークンの記録は、スマートコントラクトを通じてブロックチェーン上に保存されます。

メタデータは通常、JSONファイル、APIレスポンス、分散型ストレージ、またはオンチェーンにエンコードされたデータとして保存されます。

NFTメタデータ標準があることで、ウォレット、マーケットプレイス、ゲーム、インデクサー、ポートフォリオツール、分析プラットフォームは、この分離された情報を一貫した方法で読み取りやすくなります。

メタデータ標準がなければ、NFTプロジェクトごとにトークンの説明方法が大きく異なる可能性があり、NFTの検索、表示、取引、検証が非常に難しくなります。

あらゆるチェーン、メディア形式、アプリケーションを網羅する単一の普遍的なNFTメタデータ標準はありません。

代わりに、重要なメタデータ標準の多くは、広く使われているトークン標準であるERC-721、ERC-1155や、関連する拡張規格のERC-4906などに基づいています。

暗号資産分野でNFTメタデータ標準が重要な理由

NFTは多くの暗号資産アプリケーション間で移動できるよう設計されているため、メタデータ標準が重要です。

ユーザーは、あるアプリケーションでNFTをミントし、ウォレットで閲覧し、取引画面から出品し、ゲームで利用し、会員システムで認証し、分析ツールで追跡する場合があります。

こうした各システムには、そのNFTが何であるかを確実に把握する方法が必要です。

メタデータ標準は、システムが読み取れる予測可能なフィールドや関数を提供します。

開発者がNFTコレクションごとに独自の連携機能を構築する必要がなくなるため、相互運用性が向上します。

また、NFTが壊れたトークンや不明なトークンのように表示されず、明確な名前、画像、説明、属性とともに表示されるため、ユーザー体験も向上します。

メタデータ標準は、NFTの購入者がより適切な判断をするうえでも役立ちます。

メタデータが明確に構造化されていれば、ユーザーはNFTの購入や移転の前に、特性、希少性に関わるプロパティ、メディアリンク、コレクション情報を確認できます。

NFTの価値は、目に見える特性、メディアの品質、ユーティリティ、真正性、長期的なデータの可用性に結びつくことが多いため、これは重要です。

NFTメタデータ標準の主な構成要素

NFTメタデータシステムは通常、4つの主要な要素で構成されます。

1つ目は、メタデータURIを公開するスマートコントラクトのインターフェースです。

2つ目は、NFTを説明するJSONメタデータファイルまたはレスポンスです。

3つ目は、メタデータが参照する画像、動画、音声ファイル、3Dモデル、アニメーションなどのメディアです。

4つ目は、メタデータとメディアを長期にわたって利用可能な状態に保つストレージ方式です。

ERC-721 NFTでは、主要な関数は通常

です。

ERC-1155 NFTでは、主要な関数は通常

です。

これらの関数は、クライアントアプリケーションがメタデータを取得またはデコードするためのURIを返します。

このURIから取得されるメタデータは、シンプルで機械可読性が高く、ウェブや暗号資産アプリケーションで広くサポートされているJSON形式で記述されるのが一般的です。

ERC-721メタデータ標準

ERC-721は、Ethereum互換ネットワーク上のユニークなNFTに使われる、最も広く知られたトークン標準です。

公式のERC-721標準では、

、、などの関数を備えた、オプションのメタデータ拡張が定義されています。

関数は、NFTコレクションまたはコントラクトの名前を返します。

関数は、NFTコレクションまたはコントラクトの短いシンボルを返します。

関数は、特定のトークンIDのメタデータを参照するURIを返します。

ERC-721標準には、

、、などのフィールドを含むERC-721 Metadata JSON Schemaもあります。

フィールドは、NFTに読みやすいタイトルを付けます。

フィールドは、資産、コレクション、ユーティリティ、創作上のコンセプトを説明します。

フィールドは、NFTを表す画像を参照します。

多くのNFTプロジェクトでは、

、、、独自のプロパティなどのフィールドも含めていますが、これらすべてが元のERC-721標準で必須とされているわけではありません。

ERC-721メタデータJSONの例

基本的なERC-721メタデータファイルは、通常、シンプルなJSONオブジェクトです。

この例では、NFTの名前、説明、画像、2つの属性を定義しています。

画像にはIPFS URIが使われています。これにより、参照先のコンテンツが特定のコンテンツ識別子に一致するかをユーザーが検証しやすくなります。

配列は、特性、希少性を左右する要素、ゲームのステータス、会員ランク、その他の構造化されたプロパティの説明によく使われます。

アプリケーションはこのメタデータを読み取り、ユーザーにわかりやすい形式でNFTを表示できます。

ERC-1155メタデータ標準

ERC-1155は、1つのスマートコントラクト内で、代替可能トークン、準代替可能トークン、NFTを扱えるマルチトークン標準です。

そのため、ブロックチェーンゲーム、デジタルアイテム、エディション、バッジ、チケット、会員権、多数のトークンタイプを含むコレクションに適しています。

公式のERC-1155標準には、

関数に基づくメタデータURIの仕組みが含まれています。

この関数は、指定されたトークンIDのURIを返します。

ERC-1155は、特殊な

置換パターンにも対応しています。

URIまたはJSONの値に文字列

が含まれている場合、標準に準拠したクライアントソフトウェアは、これを64文字になるようゼロ埋めした小文字の16進数形式の実際のトークンIDに置き換えます。

1つのURIテンプレートで多数のトークンIDに対応できるため、この設計は便利です。

たとえば、ゲームコントラクトは1つのベースメタデータパスを使いながら、剣、スキン、バッジ、キャラクターごとに異なるメタデータファイルを割り当てられます。

OpenZeppelinのERC-1155 Metadata URIドキュメントでは、トークン固有のURIがERC-1155 Metadata URI JSON Schemaに準拠したJSONファイルを参照する方法を説明しています。

ERC-1155メタデータJSONの例

ERC-1155のメタデータファイルにはERC-721と同様のフィールドを含められますが、1つのコントラクト内で多数のトークンタイプを扱うためのプロパティが含まれる場合もあります。

この例では、名前、説明、画像、構造化されたプロパティを備えたゲームアイテムを説明しています。

パターンを使うと、クライアントが特定のERC-1155トークンIDに対応するメディアまたはメタデータを特定しやすくなります。

ERC-1155では多数のトークンタイプを管理できるため、IDごとに大きく異なる資産を表す場合は、メタデータの設計を特に明確にする必要があります。

token URIとメタデータURI

token URIは、NFTメタデータの保存場所をアプリケーションに知らせる参照情報です。

ERC-721では、URIは通常

から取得します。

ERC-1155では、URIは通常

から取得します。

メタデータURIには、いくつかの形式があります。

HTTPS URIは、ウェブサーバーまたはAPIエンドポイントを参照します。

IPFS URIは、IPFSのコンテンツアドレス方式で参照されるデータを指します。

Arweave URIは、Arweaveに保存されたデータを指します。

data URIでは、メタデータをURI自体に直接エンコードできます。

オンチェーンメタデータ関数は、スマートコントラクトから直接メタデータを生成して返すことができます。

各方式には、コスト、柔軟性、永続性、速度、信頼性の面でそれぞれメリットとデメリットがあります。

NFTメタデータ標準を適切に実装するには、token URIが安定していて読みやすく、プロジェクトの長期的なストレージ計画に沿っている必要があります。

一般的なNFTメタデータのフィールド

フィールドは、NFTの人間が読める名前を指定します。

フィールドは、NFTが何を表すかを説明します。

フィールドは、NFTのメイン画像を参照します。

フィールドは、動画、音声、HTMLアニメーション、その他のリッチメディアによく使われます。

フィールドは、詳細を確認できる公式ページへのリンクによく使われます。

フィールドは、特性、希少性データ、レベル、ステータス、カテゴリー、その他の構造化された値によく使われます。

フィールドは、表示する背景色の指定に使われる場合があります。

プロジェクト固有のデータが必要な場合は、独自のフィールドを追加できます。

対応していないアプリケーションでは独自フィールドが無視される可能性があるため、独自フィールドを使う場合はドキュメントで説明してください。

メタデータは、人にも機械にも役立つものである必要があります。

属性と特性

属性は、トークンの独自性や用途を説明するため、NFTメタデータの中でも特に重要な要素です。

プロフィール画像コレクションでは、背景、服装、目、口、アクセサリー、特殊効果などが属性に含まれる場合があります。

ブロックチェーンゲームでは、クラス、レベル、強さ、耐久性、クールダウン、希少性、スキルタイプなどが含まれる場合があります。

会員権NFTでは、ランク、ステータス、地域、イベントへのアクセス権、ロイヤルティレベルなどが含まれる場合があります。

デジタルアートでは、エディション、カラーパレット、生成方法、アーティストのシリーズ、素材のスタイルなどが含まれる場合があります。

属性を適切にフォーマットすると、ウォレット、エクスプローラー、分析ツールで特性データが正しく表示されやすくなります。

また、同じコレクション内でNFTを比較しやすくなります。

属性のフォーマットが不適切だと、混乱、希少性ランキングの不具合、アプリケーション間での表示の不一致につながる可能性があります。

画像とメディアのメタデータ

多くのNFTメタデータファイルでは、最も目立つ要素が

フィールドです。

通常はPNG、JPEG、GIF、SVG、その他の画像形式を参照します。

よりリッチなNFTでは、動画、音声、3Dファイル、インタラクティブメディア、HTMLベースの体験をメタデータから参照することもあります。

プロジェクトは、一般的なNFTアプリケーションで安全かつ確実に表示できるメディア形式を使用してください。

特にモバイルウォレットやインデクサーでは、大きなファイルによって読み込みが遅くなる場合があります。

ファイルには明確なMIMEタイプと安定したストレージリンクを設定してください。

ユーザーのセキュリティ上の懸念につながる安全でないスクリプト、不審な外部リダイレクト、ファイルは避けてください。

ユーザーはNFTの価値、有用性、信頼性を判断する前にメタデータを目にすることが多いため、メディアの品質は重要です。

オンチェーンメタデータ

オンチェーンメタデータは、スマートコントラクトに直接保存されるか、スマートコントラクトによって生成されます。

ユーザーがブロックチェーン上のコントラクトロジックやデータを確認できるため、メタデータの透明性が高まる可能性があります。

オンチェーンメタデータは、外部サーバーへの依存を減らすことにもつながります。

ただし、オンチェーンのストレージは、特に大きな画像、動画、詳細なJSONファイルの場合、コストが高くなる可能性があります。

そのため、オンチェーンNFTでは、コンパクトなSVG画像、ジェネラティブアートのロジック、Base64エンコードされたJSON、アルゴリズムによるメタデータなどがよく使われます。

メディアのサイズや更新の柔軟性よりも永続性と透明性を重視する場合、オンチェーンメタデータは有力な選択肢となります。

一方、大きなメディアファイル、頻繁な更新、複雑なオフチェーンデータが必要なNFTには適さない場合があります。

オフチェーンメタデータ

オフチェーンメタデータはブロックチェーン外に保存され、URIから参照されます。

画像、動画、音声ファイル、3Dアセットはオンチェーンに直接保存するには大きすぎる場合があるため、最も一般的な方式です。

オフチェーンメタデータは、中央集権型サーバー、分散型ストレージネットワーク、分散ファイルシステム、永続ストレージプロトコルなどに保存できます。

オフチェーンメタデータの主なメリットは柔軟性です。

主なリスクは、ストレージプロバイダー、サーバー、ゲートウェイ、プロジェクトチームへの依存です。

メタデータをホストしているサーバーが停止すると、NFTがオンチェーンに存在していても、ユーザーインターフェース上で表示が壊れる場合があります。

メタデータが変更可能なAPIを通じてホストされている場合、ブロックチェーン上の記録を変えずに、ユーザーに表示される内容をプロジェクトが変更できる可能性があります。

購入者は、メタデータが中央集権型か分散型か、不変か、更新権限を持つ主体によって管理されているかを理解する必要があります。

IPFSとNFTメタデータ

IPFSは、場所に基づくアドレス方式ではなくコンテンツアドレス方式を採用しているため、NFTメタデータに広く利用されています。

公式のNFTデータに関するIPFSのベストプラクティスでは、クリエイターがデータの永続性とユーザー体験を向上させる形でNFTデータを保存する方法が説明されています。

IPFSでは、コンテンツ識別子が特定のコンテンツを参照します。

コンテンツが変更されると、コンテンツ識別子も変わります。

これにより、同じコンテンツアドレスのもとでメタデータファイルやメディアファイルがひそかに変更されていないかをユーザーが確認しやすくなります。

ただし、IPFSのコンテンツを利用可能な状態に保つには、ピン留め、ストレージサービス、ノード、その他の永続化計画が必要です。

コンテンツを配信するノードがなければ、IPFSリンクがあっても役に立ちません。

優れたNFTプロジェクトは、ミント後、リビール後、そしてローンチ時の盛り上がりが落ち着いた後も、メタデータとメディアをどう利用可能な状態に保つか計画する必要があります。

中央集権型メタデータ

中央集権型メタデータは、サーバー、クラウドストレージ、またはプロジェクト管理のAPIに保存されます。

この方式は構築や更新が簡単です。

ダイナミックNFT、ゲームデータ、リビールシステム、頻繁なメタデータ更新にも対応できます。

一方、プロジェクトやサーバーの運営者がメタデータを変更、削除、リダイレクトできる可能性があり、信頼上のリスクが生じることがあります。

中央集権型サーバーは、障害が発生したり、契約期限が切れたり、ハッキングされたり、維持費が高額になったりする可能性もあります。

中央集権型メタデータが常に悪いわけではありませんが、明確に開示する必要があります。

NFTを正しく表示するためにプロジェクト運営のサーバーが必要かどうかを、ユーザーが把握できるようにしてください。

中央集権型メタデータを使うプロジェクトは、インフラを保護し、稼働状況を監視し、可能であれば長期的な移行計画を用意してください。

イミュータブルなメタデータ

イミュータブルなメタデータとは、確定後に変更できないメタデータです。

プロジェクトの所有者や管理者ウォレットが後からアートワーク、特性、説明を変更できないため、コレクターの信頼を高める可能性があります。

一点物のアート、固定されたコレクティブル、歴史的記録、証明書など、購入者がトークンの表現が変わらないと期待する資産では、イミュータブルなメタデータが特に有用です。

ただし、変更できないことによって誤りも恒久化する場合があります。

誤字、壊れたメディアリンク、誤った特性がある状態でメタデータをロックすると、修正が不可能または非常に困難になる可能性があります。

プロジェクトは、メタデータをロックする前に慎重に確認し、テストする必要があります。

購入者は、コレクションのメタデータがすでにロックされているか、プロジェクトがまだ更新権限を持っているかを確認してください。

ミュータブルなメタデータ

ミュータブルなメタデータは、ミント後に変更できます。

NFTのリビール、ゲームの進行、進化するアート、会員ステータス、ロイヤルティランク、動的なアイデンティティシステムなどに役立ちます。

ゲーム内の剣NFTは、プレイ後に新しいステータスを獲得する場合があります。

ユーザーが上位ランクに到達すると、会員権NFTがシルバーからゴールドに変わる場合があります。

アートワークNFTは、時間、ユーザーの操作、オンチェーンイベントに応じて進化することがあります。

ミュータブルなメタデータは優れた体験を生み出せますが、信頼性が求められます。

ユーザーは、誰がメタデータを変更できるのか、何を変更できるのか、変更範囲に上限があるのか、透明性のあるルールに基づいて更新されるのかを把握する必要があります。

ミュータブルなメタデータが不明確だと、特性、画像、ユーティリティが不公平に変更される可能性を購入者が懸念し、信頼が低下することがあります。

ERC-4906によるメタデータ更新の通知

ERC-4906はERC-721向けのメタデータ更新拡張で、メタデータの変更をアプリケーションが検知できるようにします。

単一トークン向けの

イベントを定義しています。

連続する範囲のトークンID向けには、

イベントを定義しています。

これらのイベントにより、ウォレット、インデクサー、NFTアプリケーションはキャッシュされたメタデータをより効率的に更新できます。

多くのアプリケーションは、リクエストの繰り返しを減らしてパフォーマンスを高めるためにNFTメタデータをキャッシュしているため、これは重要です。

標準的な更新イベントがなければ、プロジェクトがトークンの情報を変更した後も、アプリケーションに古いメタデータが表示され続ける場合があります。

ERC-4906は、メタデータ自体の形式を定めるものではありません。

メタデータが変更されたことを通知する標準的な方法を提供するものです。

ERC-7160による複数のメタデータURI

同じトークンに複数のメタデータURIが必要なNFTもあります。

公式のERC-7160マルチメタデータ拡張は、ERC-721トークンがトークンごとに複数のメタデータURIをサポートする方法を提案しています。

NFTに異なる状態、表示モード、バージョン、メディアレイヤー、メタデータ記録がある場合に役立ちます。

たとえば、NFTが公開画像用、ゲーム内の状態用、過去のバージョン用にそれぞれ別のメタデータURIを持つ場合があります。

マルチメタデータ設計によって柔軟性が高まりますが、ユーザーインターフェースでの明確な表示も必要です。

どのURIが有効なのか、または固定されているのかをユーザーが理解できない場合、複数のメタデータソースが混乱を招く可能性があります。

プロジェクトは、複数のメタデータURIを用意する理由と、アプリケーションがそれらをどう解釈すべきかを説明してください。

メタデータのキャッシュ

メタデータのキャッシュとは、毎回取得する代わりに、アプリケーションがNFTメタデータのコピーを保存することです。

キャッシュによって表示速度が向上し、ストレージシステムへの負荷が軽減されます。

一方で、メタデータが変更されたときに反映の遅れが生じることがあります。

あるウォレットには新しいメタデータが表示されても、別のアプリケーションには古いメタデータが表示される場合があります。

インデクサーでは、更新イベントの検知、新しいJSONの取得、メディアの処理、データベースの更新に時間がかかることがあります。

そのため、スマートコントラクト上では正しくメタデータが更新されていても、すべての場所に反映されるまで時間がかかる場合があります。

ERC-4906などの標準イベントはこの問題を軽減できますが、アプリケーション側でイベントを監視し、キャッシュを更新する必要があります。

NFTメタデータと希少性

特性は通常メタデータに保存されるため、メタデータは希少性に影響します。

プロジェクトが背景、服装、アイテムタイプ、エディション、レベル、その他の特性を属性で表す場合、希少性ツールはこれらのフィールドを使ってNFTを順位付けすることがあります。

メタデータが整っていれば、希少性を分析しやすくなります。

メタデータに一貫性がないと、希少性の計算に問題が生じる可能性があります。

たとえば、同じ特性を表すつもりでも、あるトークンでは

、別のトークンではを使う場合があります。

このような不一致があると、ツールが別々の値として扱うことがあります。

プロジェクトはローンチ前に、特性名、特性値、データ型、スペルを統一してください。

また、明確で公正な修正プロセスがない限り、販売後に希少性に関わるメタデータを変更しないようにしてください。

NFTメタデータとユーティリティ

NFTメタデータはユーティリティを説明できますが、それだけでユーティリティが提供されるわけではありません。

メタデータファイルには、アクセス権、レベルのステータス、ゲーム内の強さ、イベントへの入場、会員特典などがNFTに付与されると記載されている場合があります。

実際のユーティリティは、スマートコントラクト、ウェブサイト、ゲームサーバー、トークン保有者限定アプリ、オフチェーン契約などに依存する可能性があります。

そのため、メタデータは正確で、誤解を招かないものである必要があります。

プロジェクトがメタデータでユーティリティを主張する場合、ユーザーがその検証方法と利用方法を理解できるようにしてください。

ダイナミックなユーティリティを持つNFTでは、メタデータの更新がオンチェーンのルール、プロジェクトのサーバー、手動の管理者操作のどれによって制御されるのかを明確にする必要があります。

優れたメタデータは、将来の価値を過度に約束することなく、NFTの役割をユーザーが理解できるようにします。

NFTメタデータと知的財産

NFTメタデータは創作物を参照することがよくありますが、メタデータが著作権の所有者を自動的に定めるわけではありません。

NFTを購入することは通常、トークンを購入することであり、リンク先のアートワーク、音楽、動画、ブランド資産の著作権を自動的に購入することではありません。

米国著作権局のNFTに関する調査では、NFTの所有権と知的財産権は別個の問題となる可能性があると説明されています。

メタデータは画像を表示したりメディア資産を説明したりできますが、法的権利は通常、ライセンス条件、プロジェクトの利用規約、または別個の契約によって決まるため、この違いは重要です。

プロジェクトは、メタデータに曖昧または誤解を招く権利の説明を記載しないようにしてください。

関連メディアを商業利用する前に、NFTのライセンスを確認してください。

メタデータは発見や表示に役立ちますが、プロジェクトがそのように明確に設計していない限り、完全な法的契約として扱うべきではありません。

NFTメタデータのセキュリティリスク

安全でないファイル、悪意のあるウェブサイト、侵害されたサーバーをメタデータが参照している場合、セキュリティリスクが生じる可能性があります。

メタデータのフィールドに、ユーザーをフィッシングページへ誘導する外部URLが含まれている場合があります。

中央集権型ストレージが侵害されると、メディアファイルが差し替えられる可能性があります。

動的なメタデータエンドポイントが、ユーザーごとに異なるコンテンツを返す場合があります。

プロジェクトの管理者ウォレットが更新権限を悪用し、購入後に特性、画像、リンクを変更する可能性があります。

アプリケーションはメタデータを安全に処理し、危険な表示動作を避け、不審なリンクからユーザーを保護する必要があります。

プロジェクトは、更新権限、ストレージアカウント、デプロイキー、APIインフラを保護する必要があります。

ユーザーは、出所不明のNFTメタデータに含まれるリンクからウォレットメッセージに署名したり、ウォレットを接続したりしないでください。

NFTメタデータ標準のベストプラクティス

Ethereum互換ネットワーク上でNFTを構築する場合、プロジェクトはERC-721メタデータやERC-1155メタデータなど、広く認知された標準を利用してください。

JSONは有効で、シンプルかつ一貫した形式にしてください。

明確なフィールド名を使い、ドキュメントで説明されていない不要な独自フィールドは避けてください。

安定したメディアリンクを使い、ミント前に長期的なストレージを計画してください。

ローンチ前に、複数のウォレットやNFTアプリケーションでメタデータをテストしてください。

メタデータが変更可能か不変かを開示してください。

メタデータを更新できるウォレット、コントラクト関数、サーバーを保護してください。

ERC-721のメタデータ変更をアプリケーションが検知する必要がある場合は、ERC-4906イベントを利用してください。

外観、特性、ユーティリティ、希少性、保有者の期待に影響するメタデータ更新については、公開された変更履歴を残してください。

将来の価値について金融上の約束や誤解を招く主張をするために、メタデータを利用しないでください。

NFT購入者のベストプラクティス

可能であれば、NFTを購入する前にメタデータを確認してください。

token URIがIPFS、HTTPS、オンチェーンデータ、その他のストレージシステムのどれを参照しているか確認してください。

画像やJSONファイルが永続的か、変更可能か、プロジェクトのサーバーに依存しているかを理解してください。

特性が明確に構造化され、一貫性を保っているか確認してください。

メタデータにアートワークが表示されているだけで、商業利用権があると思い込まないでください。

ウォレット接続を求める外部リンクがメタデータに含まれている場合は注意してください。

表示されている画像は、価値、法的な所有権、将来のユーティリティが保証されていることを意味しないと理解しておきましょう。

メタデータの品質は、セキュリティ、流動性、クリエイターの評判、コミュニティの強さ、プロジェクトの実行力と並ぶ判断材料の1つとして考慮してください。

NFTメタデータの開発者向けチェックリスト

開発者は、NFTでERC-721、ERC-1155、その他のどのトークン標準を使うか決めてください。

選択した標準に適したメタデータ関数を実装してください。

公開前にすべてのJSONファイルを検証してください。

特性名とデータ型を統一してください。

プロジェクトの永続性に関する目標に合った方法でメディアを保存してください。

メタデータをロックするのか、更新可能にするのか、動的にするのか、完全にオンチェーンにするのかを決めてください。

強固なアクセス制御で更新関数を保護してください。

適切な場合は、標準的なメタデータ更新イベントを発行してください。

ウォレット、ブロックチェーンエクスプローラー、インデックスツールでNFTの表示をテストしてください。

後からユーザーが驚かないよう、メタデータの動作をすべて文書化してください。

NFTメタデータ標準に関するよくある誤解

よくある誤解の1つは、NFTメタデータが常にオンチェーンに保存されているというものです。

実際には、多くのNFTはオンチェーンにURIのみを保存し、JSONとメディアはオフチェーンに保存しています。

もう1つの誤解は、すべてのメタデータフィールドが公式に必須とされているというものです。

実際には、標準で定義されているのは一部の基本フィールドやインターフェースであり、広く使われているフィールドの多くは厳格な要件ではなく一般的な慣例です。

3つ目の誤解は、IPFSのメタデータは自動的に永続化されるというものです。

IPFSはコンテンツアドレス方式を採用していますが、コンテンツを利用可能な状態に保つには、ノード、ピン留め、ストレージサービスが必要です。

4つ目の誤解は、メタデータが更新されると常に何か不審なことが起きたというものです。

リビール、ゲームの進行、ストレージの移行、誤りの修正など、通常の更新もあります。

5つ目の誤解は、メタデータが著作権の所有者を定めるというものです。

メタデータは資産を説明できますが、法的権利はライセンス、利用規約、適用される法律によって決まります。

よくある質問

NFTメタデータ標準とは何ですか？

NFTメタデータ標準とは、名前、画像、説明、特性などのNFT情報をアプリケーションが読み取り、表示できるようにするスマートコントラクトのインターフェースとメタデータ形式の集合です。

ERC-721は主要なNFTメタデータ標準ですか？

ERC-721は主要なNFT標準の1つであり、そのオプションのメタデータ拡張はユニークなNFTで広く使われています。

ERC-721とERC-1155のメタデータの違いは何ですか？

ERC-721では通常、

を通じて1つのユニークなトークンのメタデータを返します。一方、ERC-1155はを使い、1つのコントラクト内で多数のトークンタイプのメタデータを管理できます。

NFTメタデータには通常どのようなフィールドが含まれますか？

NFTメタデータには通常、

、、のほか、、、などのフィールドが含まれる場合があります。

NFTメタデータはオンチェーンに保存する必要がありますか？

いいえ。NFTメタデータはオンチェーンにもオフチェーンにも保存できます。多くのNFTでは、オンチェーンのURIから参照されるオフチェーンのJSONファイルを利用しています。

多くのNFTがメタデータにIPFSを使うのはなぜですか？

コンテンツアドレス方式によって、サーバーの場所だけでなく特定のコンテンツ識別子にメタデータとメディアを紐づけられるため、多くのNFTでIPFSが使われています。

ミント後にNFTメタデータを変更できますか？

はい。コントラクト、URI、ストレージシステム、メタデータエンドポイントが更新に対応する設計であれば、ミント後にNFTメタデータを変更できます。

ERC-4906とは何ですか？

ERC-4906は、NFTメタデータが変更されたことを通知する標準イベントを提供するERC-721拡張規格です。

メタデータは著作権の所有権を証明しますか？

いいえ。メタデータはNFTのメディアやユーティリティを説明できますが、著作権の所有権は法的権利、ライセンス、プロジェクトの利用規約によって決まります。

高品質なNFTメタデータとはどのようなものですか？

高品質なNFTメタデータは、有効で一貫性と透明性があり、安全でインデックスしやすく、信頼できるストレージに紐づき、更新可能かどうかが明確です。

まとめ

NFTメタデータ標準は、ブロックチェーン上の所有権と、ユーザーがNFTに期待する視覚的、説明的、機能的な情報を結びつけるために不可欠です。

ERC-721とERC-1155は、Ethereum互換のNFTコントラクトにとって最も重要なメタデータの基盤を提供します。

ERC-4906はアプリケーションによるメタデータ変更の検知に役立ち、ERC-7160などの新しい拡張規格は、より柔軟なメタデータ設計を可能にします。

優れたNFTメタデータは、明確に構造化され、確実に保存され、誠実に説明されている必要があります。

推測に頼ることなく、ウォレット、ゲーム、取引ツール、ユーザーがトークンの表すものを理解できるようにする必要があります。

クリエイターや開発者にとって、メタデータ標準は相互運用性を高め、連携時の問題を減らします。

購入者やコレクターにとって、メタデータの品質は、NFTが理解しやすく、長期的に利用でき、安全で、うたわれているユーティリティに沿っているかを判断する手がかりになります。

NFTがアート、ゲーム、アイデンティティ、会員権、チケット、トークン化メディアへと広がり続ける中で、メタデータ標準は暗号資産NFTエコシステムを支える最も重要な基盤の1つであり続けるでしょう。