メタデータ標準

メタデータ標準とは？

メタデータ標準とは、暗号資産、トークン、ブロックチェーンアカウント、デジタルコレクティブル、トランザクション、分散型IDに関する情報の命名、形式、保存、取得、解釈方法を定める共通ルールです。

メタデータとは、別の資産やデータオブジェクトを説明するデータです。

暗号資産分野のメタデータには、トークン名、シンボル、小数桁数、画像、属性、作成者、外部リソース、メディアタイプ、発行条件、原資産などの情報が含まれる場合があります。

メタデータ標準により、ウォレット、ブロックチェーンアプリ、エクスプローラー、インデクサー、分析システム、スマートコントラクトが同じ情報を一貫して解釈できます。

共通の標準がなければ、あるアプリは

というフィールドを使用し、別のアプリはを使用し、さらに別のアプリはメディア参照をまったく認識できない可能性があります。

メタデータ標準では、コントラクト関数、データフィールド、JSON構造、識別子、更新イベント、検証ルール、保存方法、セキュリティ要件を定めることができます。

一部のメタデータはブロックチェーンに直接保存されますが、それ以外はWebサイト、分散型ストレージネットワーク、非公開データベースに保存されます。

メタデータ標準は相互運用性を高めますが、情報の正確性、永続性、合法性、安全性を保証するものではありません。

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

ブロックチェーンの記録には、一般ユーザーには理解しにくい技術的な識別情報が頻繁に含まれます。

トークンのコントラクトアドレスは特定の資産を識別しますが、アドレスだけでは、読みやすい名前、ロゴ、説明、表示桁数はわかりません。

メタデータは、技術的なブロックチェーン情報を、ソフトウェアが表示でき、ユーザーが解釈できる構造化データに変換します。

ウォレットは標準化されたメタデータを使って、正しいトークン名と残高を表示できます。

NFTアプリは、メタデータを使って画像、アニメーション、説明、特性を表示できます。

分散型IDアプリは、検証鍵、サービスエンドポイント、発行者、クレデンシャルの対象者、クレデンシャルの種類を特定するためにメタデータを使用できます。

標準があれば、暗号資産ごとにアプリが個別のカスタム連携を構築する必要性を減らせます。

また、データの検証、欠落フィールドの検出、実装の比較、システム間での情報移行も容易になります。

メタデータ標準とメタデータの違い

メタデータとは、資産に付随または関連付けられた実際の説明情報です。

メタデータ標準とは、その情報の構造化方法と解釈方法を定めたルールです。

「Digital Access Pass」というテキストは、メタデータに保存されたトークン名である場合があります。

標準では、トークン名を

というフィールドに格納し、文字列として表現するよう定めることができます。

メタデータは標準に準拠する場合も、一部のみ準拠する場合も、完全に独自の形式を使用する場合もあります。

メタデータ標準とメタデータスキーマの違い

メタデータ標準は、メタデータの作成と交換に関する広範なルールを定めます。

メタデータスキーマは、メタデータ文書で使用可能な構造、フィールド、データ型、検証要件を定めます。

標準には、1つ以上のスキーマのほか、スマートコントラクトのインターフェース、更新イベント、URIルール、処理手順が含まれる場合があります。

スキーマでは、

を文字列、を配列、をURIとして指定するよう求めることができます。

文書が有効なJSONであっても、必須のメタデータスキーマに準拠しているとは限りません。

メタデータ標準とトークン標準の違い

トークン標準は、トークンの動作と、他のアプリがスマートコントラクトとやり取りする方法を定めます。

メタデータ標準は、そのトークンの説明情報をどのように表現するかを定めます。

1つのトークン標準に、動作関数と任意のメタデータ関数の両方が含まれる場合があります。

たとえば、代替可能トークンの標準では、送金、残高、承認、総供給量、名前、シンボル、小数桁数が定義されることがあります。

NFT標準では、所有権と送金の関数を定義し、メタデータURIを使って説明情報の場所を示す場合があります。

暗号資産のメタデータ標準を構成する主な要素

識別子

識別子は、あるブロックチェーン、コントラクト、トークンの種類、トークンの個体、アカウント、クレデンシャル、メタデータ文書を他と区別します。

例として、チェーン識別子、コントラクトアドレス、トークンID、分散型識別子、URL、URI、コンテンツ識別子があります。

フィールド名

フィールド名が標準化されていれば、発行者ごとに異なるラベルを推測することなく、ソフトウェアが情報を特定できます。

一般的なフィールドには、

、、、、、、があります。

データ型

データ型は、値が文字列、数値、整数、ブール値、オブジェクト、配列、null値のいずれであるべきかを定めます。

データ型を一貫させることで、テキストを想定するアプリに数値が渡されるといった問題を防げます。

必須フィールドと任意フィールド

標準では、準拠するすべての実装が提供しなければならない情報を必須とし、追加機能のために任意フィールドを認める場合があります。

ソフトウェアは、任意フィールドが常に存在すると想定してはいけません。

URIルール

メタデータ標準では、メタデータ文書やメディアファイルの場所を示すURIをコントラクトがどのように返すかを定める場合があります。

URIはリソースを識別しますが、アプリがそのリソースを取得または解釈する方法はURIスキームによって異なります。

更新ルール

更新ルールでは、メタデータを変更できるか、誰が変更できるか、更新があったことをアプリがどのように把握するかを説明します。

完全性ルール

完全性ルールにより、取得したメタデータが想定した暗号学的ハッシュまたはコンテンツ識別子と一致するかをアプリが確認できます。

検証ルール

検証ルールは、不正形式、欠落、競合、非対応のメタデータがユーザーに届く前に特定します。

オンチェーンメタデータ

オンチェーンメタデータは、ブロックチェーンの状態、コントラクトストレージ、トランザクションデータ、またはブロックチェーンによって保護される別のリソースに直接保存されます。

アプリは一般的なWebサーバーに依存せず、ノードからメタデータを読み取れます。

基盤となるブロックチェーンにアクセスできる場合、オンチェーンストレージは高い可用性と完全性を実現できます。

一方、保存する1バイトごとにトランザクションコストやネットワークの長期ストレージ要件が増える可能性があるため、コストが高くなる場合もあります。

完全なオンチェーンメディアには、簡潔なテキスト、エンコードされたベクター画像、手続き型生成、データURIが使われることがあります。

アップグレード可能なコントラクトや管理者が制御するコントラクトでは返される情報を変更できるため、オンチェーンであることが自動的に不変性を意味するわけではありません。

オフチェーンメタデータ

オフチェーンメタデータはブロックチェーンの外部に保存され、ブロックチェーンにはその参照情報が記録されます。

参照先には、HTTPSリソース、分散型ストレージ上のオブジェクト、非公開サーバー、アプリケーションプログラミングインターフェース、コンテンツアドレス指定されたファイルなどがあります。

オフチェーンストレージは、ブロックチェーン上のコストを抑えながら、大きな画像、動画、文書、詳細な属性セットに対応できます。

その一方で、可用性、ホスティング、ドメイン、セキュリティ、コンテンツ変更に関する追加リスクが生じます。

通常のサーバーが消失しても、トークンはブロックチェーン上に残りますが、メタデータを利用できなくなる可能性があります。

ハイブリッドメタデータ

ハイブリッドメタデータは、オンチェーン情報とオフチェーンファイルを組み合わせます。

スマートコントラクトがトークンID、所有権、メタデータURI、コンテンツハッシュをオンチェーンに保存しつつ、完全なJSON文書やメディアは別の場所に保存する場合があります。

この方法では、ストレージコストを抑えながら、アプリが取得したコンテンツを検証できるようにすることができます。

セキュリティは、どのフィールドがオンチェーンで保護され、どのフィールドが引き続き変更可能かによって異なります。

代替可能トークンのメタデータ標準

代替可能トークンのメタデータは、ウォレットやアプリが交換可能な暗号資産を正しく表示するのに役立ちます。

最終版のERC-20トークン標準では、トークン名、シンボル、小数桁数を取得する任意関数が定義されています。

フィールドは、読みやすい資産名を示します。

フィールドは、ティッカーのような短い表記を示します。

値は、最小のオンチェーン単位をユーザーが読める数量に変換する方法をインターフェースに示します。

小数桁数が18のトークンでは、表示上の1トークンは最小単位10¹⁸個に相当します。

複数の無関係なコントラクトが同じ値を使用できるため、名前やシンボルだけではトークンを一意に特定できません。

信頼性の高いアプリは、シンボルだけでなく、ブロックチェーンとコントラクトアドレスによって資産を特定する必要があります。

小数桁数のメタデータ

小数桁数のメタデータは整数のトークン残高の表示方法を変えますが、基盤となるオンチェーン単位を自動的に分割するものではありません。

表示されるトークン残高 = 生のトークン残高 / 10^小数桁数

小数桁数が6の場合、生の残高250,000,000は250トークンと表示されます。

小数桁数のメタデータが誤っていると、残高が実際より大きく、または小さく表示される場合があります。

金融計算では、浮動小数点による近似ではなく、正確な整数演算を使用してください。

ERC-721メタデータ標準

ERC-721は、各トークンに個別の識別子を持たせる非代替性トークンの最終標準です。

ERC-721標準の任意のメタデータインターフェースでは、

、、関数が定義されています。

関数は、特定のトークンIDに関連付けられたURIを返します。

そのURIから取得されるメタデータには通常、名前、説明、画像URIが含まれます。

アプリが追加フィールドに対応することはありますが、すべてのインターフェースで一貫して表示されるとは限りません。

ERC-721は、すべてのメタデータをコントラクトに直接保存することなく、メタデータへのアクセス方法を標準化します。

一般的なERC-721メタデータフィールド

名前

フィールドは、個々のトークンまたは表現される資産の、人が読める名前を示します。

説明

フィールドは、トークン、メディア、ユーティリティ、履歴、または表現されるアイテムを説明します。

画像

フィールドには、トークンに関連する画像を指すURIが含まれます。

アニメーションURL

フィールドは、動画、音声、インタラクティブメディア、3Dコンテンツ、その他のリッチコンテンツを指す場合があります。

外部URL

フィールドは、公式の情報ページやアプリケーションページにユーザーを誘導する場合があります。

属性

配列には、カテゴリ、レベル、エディション、色、ステータス、その他のトークン固有の特性を記述できます。

アプリが正しく並べ替えや比較を行えるよう、コレクション全体で特性の形式を統一する必要があります。

ERC-1155メタデータ標準

ERC-1155は、1つのスマートコントラクト内で複数の代替可能、非代替性、セミファンジブルなトークン種別に対応します。

最終版のERC-1155マルチトークン標準では、任意のメタデータURIインターフェースと関連するJSONスキーマが定義されています。

関数は、トークン種別のメタデータURIを返します。

標準では、メタデータ値にプレースホルダー

を含めることができます。

対応するクライアントは、

を付けず、小文字でゼロ埋めした64文字の16進数文字列として表現したトークンIDに、このプレースホルダーを置き換えます。

この置換によって、1つのURIパターンを効率的に複数のトークンIDに利用できます。

ERC-1155のスキーマには、name、description、image、decimals、propertiesなどのフィールドが含まれます。

ERC-721とERC-1155のメタデータの違い

ERC-721は通常、

を通じてトークン固有のURIを返します。

ERC-1155はURIテンプレートを返し、アプリがトークンIDの置換によって内容を調整できます。

ERC-721は個別に識別できるトークンを前提として設計されていますが、ERC-1155は1つのコントラクトで複数のトークンカテゴリーを表現できます。

どちらの標準でも、メタデータは通常JSONとして取得され、外部メディアを指すことができます。

すべてのNFTが同じメタデータ形式に従うと想定せず、適切なインターフェースを判別して処理する必要があります。

メタデータ更新標準

変更可能なNFTメタデータでは、アプリが以前のバージョンをキャッシュし、更新を把握できない場合があるという課題が生じます。

最終版のERC-4906メタデータ更新拡張では、ERC-721のメタデータ変更をアプリに通知するための標準イベントが定義されています。

イベントは、メタデータが変更された1つのトークンを識別します。

イベントは、影響を受ける連続したトークンIDの範囲を示します。

アプリはこれらのイベントを監視し、トークンのURIを通じて更新後のメタデータを取得できます。

イベントはメタデータが変更されたことを通知しますが、変更後の文書全体を含むわけではありません。

新たなオンチェーンメタデータ標準

ブロックチェーンアプリでより構造化されたオンチェーン情報が必要とされるなか、新しいメタデータ提案が引き続き開発されています。

ERC-8048は2025年9月、マルチトークンおよびNFTレジストリに直接保存するキー・バリュー形式のメタデータに関するドラフト提案として公開されました。

現行のERC-8048ドラフトでは、トークンIDと文字列キーを指定してメタデータバイトを返す関数が提案されています。

また、メタデータ値が設定されたときにアプリが監視できるイベントも提案されています。

ERC-8048はまだドラフトのため、最終版または広く採用された標準として説明してはいけません。

ドラフト提案は変更されたり、進展が止まったり、広範な実装の支持を得られなかったりする可能性があります。

メタデータ形式としてのJSON

JSONは軽量なテキスト形式で、コントラクト、サーバー、ウォレット、アプリ間で暗号資産のメタデータを交換する際によく使われます。

IETFのJSON標準では、オブジェクト、配列、文字列、数値、ブール値、null値が定義されています。

JSONオブジェクトにはフィールド名と、それに対応する値が含まれます。

JSONは読みやすく、幅広くサポートされ、Webアプリで処理しやすいため広く利用されています。

JSONとして有効であることは、その文書がトークンのメタデータスキーマに従っていることを証明しません。

アプリは、セキュリティおよび相互運用性の方針に基づいて、重複値や想定外の値を拒否する必要があります。

NFTメタデータ構造の例

この例では一般的なフィールドを使用していますが、あらゆるNFTアプリに共通する完全なスキーマではありません。

URI、属性構造、任意フィールドは、それらを利用する標準やアプリに照らして評価する必要があります。

JSON Schema

JSON Schemaは、JSON文書の構造と値を検証するための機械可読ルールを提供します。

スキーマでは、必須プロパティ、想定されるデータ型、最小値、文字列パターン、許容値、入れ子になったオブジェクトのルールを定義できます。

公式のJSON Schema Draft 2020-12は、2026年時点で一般仕様の最新リリース版です。

暗号資産プロジェクトは、トークンのミントや公開前にメタデータを検証するためJSON Schemaを利用できます。

ウォレットやインデクサーも、スキーマを使って無効または非対応のデータを特定できます。

スキーマ検証で確認できるのは構造であり、説明、画像、所有権の主張、発行者の表明が真実であることまでは証明できません。

JSON-LDメタデータ

JSON-LDは、リンクトデータの意味情報をJSONに追加し、フィールドや型を世界的に定義された概念に結び付けられるようにします。

安定版のJSON-LD 1.1勧告では、相互運用可能なリンクトデータのJSONベース形式が定義されています。

プロパティは、短いフィールド名をより具体的な識別子や語彙に対応付けます。

プロパティは、主体またはリソースを識別できます。

プロパティは、説明対象のエンティティの種類を示します。

JSON-LDにより、トークン化資産、クレデンシャル、ID記録、実世界資産のシステムで、意味を一貫させてメタデータを交換しやすくなります。

内容が変更されたり利用できなくなったりするリモートコンテキストには、依存性とセキュリティのリスクがあります。

暗号資産のメタデータにおけるURI標準

Uniform Resource Identifier（URI）は、標準化された文字形式でデジタルまたは物理的なリソースを識別します。

URIの一般構文標準では、URIスキームで使われる共通構造が定義されています。

暗号資産のメタデータで一般的なスキームには、

、、があります。

HTTPS URIは、Webドメインとサーバーを通じて管理される場所を識別します。

IPFS URIは、コンテンツ識別子を通じてコンテンツを特定します。

data URIは、コンテンツをURI内に埋め込みます。

アプリは対応するスキームを確認し、認識できないURIを安全なWebリンクとして扱わないようにしてください。

場所によるアドレス指定とコンテンツによるアドレス指定

場所によるアドレス指定は、リソースをどこに要求すればよいかをアプリに示します。

コンテンツによるアドレス指定は、コンテンツ自体から導かれる情報に基づいてリソースを識別します。

HTTPS URLは、サーバー上のファイルが変更された後も同じ場所を指し続ける場合があります。

コンテンツ識別子は、同じエンコード方式とハッシュルールのもとで参照コンテンツが変わると、別の値になります。

そのため、コンテンツによるアドレス指定は完全性の検証を向上させますが、コンテンツが引き続きホストされ、取得可能であることまでは保証しません。

IPFSメタデータ

IPFSは、コンテンツアドレス指定された識別子を通じてNFTのメタデータやメディアを保存する用途によく使われます。

公式のIPFSコンテンツアドレス指定のドキュメントによると、コンテンツ識別子（CID）には、コンテンツの暗号学的ハッシュとエンコード方式から導かれた情報が含まれます。

同じコンテンツアドレス指定の設定を使用した場合、コンテンツを変更すると別のCIDになります。

トークンURIでは、

形式を使用してメタデータ文書やファイルを特定できます。

公開ゲートウェイは、そのURIをブラウザーでアクセスできるHTTPSリクエストに変換する場合があります。

ゲートウェイはコンテンツそのものの識別子ではなく、コンテンツを取得するための経路です。

CIDは、少なくとも1つのアクセス可能なプロバイダーがデータを引き続き利用可能にしなければならないため、恒久保存を保証しません。

メタデータの完全性

メタデータの完全性とは、取得したデータが、信頼できる参照情報の作成後に予期せず変更されていないことを指します。

メタデータ文書から暗号学的ハッシュを計算し、想定される信頼済みハッシュと比較できます。

メタデータの完全性が有効：計算したハッシュ = 信頼済みの想定ハッシュ

ハッシュが一致すればバイト列が一致している証拠になりますが、元のコンテンツが正確または承認済みであることまでは証明しません。

コンテンツアドレス指定されたメタデータでは、識別子に完全性情報を含めることができます。

場所によってアドレス指定されたメタデータでは、別途保存されたハッシュ、電子署名、完全性記録を使用できます。

メタデータの真正性

真正性は、誰がメタデータを作成、承認、管理したかを示します。

電子署名を使うと、メタデータ文書を暗号鍵に結び付けられます。

ただし、検証者はその鍵が想定される作成者、発行者、コントラクト管理者、組織に属しているかを判断する必要があります。

侵害された鍵による有効な署名でも、承認されていない文書が認証される場合があります。

引き続き、鍵のローテーション、失効、アクセス制御、インシデント対応手順が必要です。

不変のメタデータ

不変のメタデータとは、定められた時点以降にコンテンツまたは信頼済みの参照情報を変更できないよう設計されたメタデータです。

データ全体をオンチェーンに保存する、変更できないコンテンツ識別子を保存する、更新権限を恒久的に無効にするといった方法で不変性を実現できます。

どの部分が不変なのかを、プロジェクトが正確に説明する必要があります。

不変のJSON文書が、変更される可能性のある外部画像を指している場合もあります。

不変のスマートコントラクトが、変更可能なサーバー上の場所を参照することもあります。

真の不変性を評価するには、参照経路全体を確認する必要があります。

変更可能なメタデータ

変更可能なメタデータは、トークンの作成後に変更できます。

進化するゲームアイテム、変化するメンバーシップ、償還可能な資産、IDステータス、保守記録、実世界資産の更新などに活用できます。

一方で、権限を持つ当事者や侵害された管理者が、画像、説明、特性、外部リンクを差し替えることも可能です。

メタデータ標準では、更新権限、手順、イベント、履歴、今後の変更を凍結する条件を定める必要があります。

アプリは、変更可能なメタデータを恒久的なものとして説明してはいけません。

凍結されたメタデータ

凍結されたメタデータとは、以前は編集可能だったメタデータを、以降の変更が想定されない、または許可されない状態にしたものです。

凍結処理は、コントラクトコードまたは別の独立検証可能な制御によって実施される必要があります。

メタデータが凍結されたというWebサイト上の説明は、更新権限を取り除く技術的な制限よりも確実性が低いものです。

プロキシのアップグレード、ガバナンス上の操作、管理者鍵によって変更権限が復活できるかどうかを確認してください。

メタデータのバージョン管理

メタデータのバージョン管理では、メタデータ文書やスキーマが時間とともにどう変化したかを記録します。

バージョン識別子により、アプリはどのルールを適用すべきか判断できます。

セマンティックバージョンでは、メジャー、マイナー、パッチの番号を使い、互換性のない変更と互換性のある追加・修正を区別できます。

過去のバージョンは、監査、紛争、移行、以前のトークン状態を正確に表示する際に役立ちます。

以前の文書を履歴を残さず上書きする変更可能なURIでは、ユーザーが当初受け取った内容を再構成するのが困難になります。

クロスチェーンのメタデータ標準

クロスチェーンアプリでは、異なるブロックチェーン上で似た名前やアドレスを持つ資産を区別できる識別子が必要です。

無関係な資産が同じシンボルを共有する場合があるため、ティッカーシンボルだけでは不十分です。

CAIP-19資産識別子標準では、資産の種類や個々の資産を特定するためのチェーンに依存しない形式が定義されています。

完全な識別子には、ブロックチェーンの名前空間、ブロックチェーン参照、資産名前空間、コントラクトまたは資産参照、任意のトークンIDを組み合わせることができます。

チェーンに依存しない識別子を使うと、ウォレット、決済システム、ブリッジ、ポートフォリオツールで資産メタデータを交換する際の曖昧さを減らせます。

ただし、ブリッジされたトークンが元の資産によって完全に裏付けられていることを証明するものではありません。

ラップド資産とブリッジ資産のメタデータ

ラップドトークンまたはブリッジトークンは、別のブロックチェーンや技術システムを通じて資産を表します。

そのメタデータには、現在のブロックチェーン、トークンコントラクト、表現される資産、発行者またはブリッジの仕組み、関連する償還条件を記載する必要があります。

ラップされた資産であることを明示せず、元の資産の名前やロゴを複製すると、ユーザーに誤解を与える可能性があります。

シンボルが同じだからといって、償還権や安全性も同じだとアプリが想定してはいけません。

メタデータでは、資産がネイティブ、ラップド、ブリッジ、合成、その他のいずれの形態かを明確にする必要があります。

分散型識別子のメタデータ

分散型識別子は、ブロックチェーン関連の主体を検証方法やサービス情報に結び付けることができます。

DID文書には、コントローラー、暗号学的検証方法、認証関係、サービスエンドポイントを含めることができます。

W3Cは、DID Core version 1.1を2026年3月5日にCandidate Recommendation Snapshotとして公開しました。

version 1.1は引き続き勧告の策定段階にあるため、実装者は最終版のDID Core 1.0勧告と区別する必要があります。

DIDメタデータは、トークン発行者、組織、クレデンシャル、ウォレット、自動化されたエージェントに利用できます。

DIDはその方式に基づく管理権限を示しますが、コントローラーが主張するすべての内容が正確であることを自動的に証明するものではありません。

検証可能なクレデンシャルのメタデータ

検証可能なクレデンシャルは、発行者が対象者について行う主張を表すために、構造化メタデータを使用します。

W3C Verifiable Credentials Data Model 2.0は、2025年5月15日にW3C勧告となりました。

このモデルでは、発行者、クレデンシャルの対象者、種類、有効期間、クレデンシャルのステータス、データスキーマ、保護方式に関する情報が定義されています。

暗号資産アプリは、本人確認、メンバーシップ、コンプライアンス、教育、専門資格、トークン化されたアクセス権に検証可能なクレデンシャルを利用できます。

有効なクレデンシャル証明は、該当する暗号方式に基づいて保護されたデータが改ざんされていないことを示します。

発行者を信頼できるか、またクレデンシャルが目的に適しているかは、検証者が別途判断する必要があります。

トークン化された実世界資産のメタデータ

トークン化された実世界資産のメタデータには、不動産、有価証券、コモディティ、請求書、環境関連の主張、メンバーシップ、法的権利などが記載される場合があります。

所有権や償還について理解するために必要な文書のすべてが、トークンコントラクトに含まれているとは限りません。

メタデータには、法的合意、発行者、カストディアン、評価日、法域、資産識別子、監査、制限、ステータス情報を記載できます。

メタデータのリンクがあるからといって、外部の法的文書に拘束力が生じるわけではありません。

トークンが関連する事業体や資産に対して法的に執行可能な請求権を与えるかどうかを、ユーザーは確認する必要があります。

機微な個人情報や商業情報を、公開ブロックチェーンに恒久的に保存すべきではありません。

メタデータのローカライズ

ローカライズにより、名前、説明、その他の読みやすいメタデータを複数の言語で表示できます。

標準では、各テキスト値に対応する言語を特定する必要があります。

要求された言語が利用できない場合の代替表示方法を、アプリで定めておく必要があります。

翻訳では、宣伝用コンテンツだけを簡略化するのではなく、重要なリスク、法的情報、償還情報を保持する必要があります。

システム間で名前が文字化けしないよう、文字エンコードを統一してください。

メタデータのアクセシビリティ

アクセシブルなメタデータは、スクリーンリーダー、テキストによる代替情報、キーボード操作、その他の支援技術に頼るユーザーに役立ちます。

アプリやスキーマが対応している場合、画像には意味のあるテキスト説明を付ける必要があります。

重要な情報を画像やアニメーション内だけに記載してはいけません。

重要なトークンの状態を伝える唯一の手段として、色、動き、音を使用しないでください。

アクセシビリティを高めることで使いやすさが向上し、より幅広い人がメタデータを理解できるようになります。

暗号資産のメタデータにおけるメディアタイプ

メディアタイプは、JSON、PNG、SVG、MP4など、リンク先ファイルの形式を示します。

アプリはメディアタイプの情報を使い、リソースの処理方法を判断できます。

サーバーが見慣れたファイル名で想定外のコンテンツを返す場合があるため、ファイル拡張子だけでは信頼できません。

アプリは応答の種類を確認し、ファイル構造を検証し、安全な表示ルールを適用する必要があります。

HTMLやSVGなどのアクティブ形式には、スクリプト、外部参照、インタラクティブな動作が含まれる場合があるため、通常の静止画像より強力な制御が必要です。

メタデータのキャッシュ

ウォレット、インデクサー、アプリは、処理速度を上げ、繰り返しのネットワークリクエストを減らすため、メタデータをキャッシュすることがよくあります。

キャッシュによって、許可された更新後も古い名前、画像、属性が表示され続ける場合があります。

更新イベント、有効期限ポリシー、バージョン識別子、手動更新ツールにより、古いデータの問題を軽減できます。

キャッシュされたコピーは、情報源とタイムスタンプを確認せずに、現在の正式な状態として扱ってはいけません。

コンテンツアドレス指定されたメタデータは、コンテンツが変わると識別子も変わるため、完全性を保ったまま安全にキャッシュできます。

メタデータのインデックス作成

メタデータインデクサーは、ブロックチェーン上の参照情報を収集し、文書を取得してフィールドを検証し、高速な検索や表示に備えてデータを処理します。

インデクサーは、異なる標準のデータを1つの内部形式に正規化する場合があります。

正規化により使いやすさが向上する一方、非対応フィールドが削除されたり、元のスキーマ間の違いが見えにくくなったりする場合があります。

インデクサーは、元の情報源、取得時刻、ブロックチェーン識別子、コントラクトアドレス、トークンIDを保持する必要があります。

ユーザー向けアプリでは、コントラクトから直接取得したメタデータと外部データベースが追加した情報を区別する必要があります。

メタデータの検証

メタデータの検証では、データが必須の構文、スキーマ、識別子、フィールド型、セキュリティルールに従っているかを確認します。

構文検証では、文書が整形式のJSONやその他の想定形式であるかを確認します。

スキーマ検証では、必須フィールド、値、構造を確認します。

URI検証では、リソース参照が許可されたスキームを使用し、有効な形式であるかを確認します。

完全性検証では、ハッシュやコンテンツ識別子を照合します。

意味的検証では、関連するブロックチェーンや資産の文脈に照らして情報が妥当かを確認します。

メタデータに含まれるすべての主張を証明できる単一の検証方法はありません。

暗号資産のメタデータに関するセキュリティリスク

悪意あるリンク

メタデータ文書に含まれる外部URLから、ユーザーがフィッシングサイトに誘導される場合があります。

悪意あるメディア

画像やアニメーションのフィールドが、安全でない表示ソフトを悪用したり、ユーザーを追跡したりする目的のアクティブコンテンツを参照する場合があります。

過大なファイル

攻撃者は、メモリ、帯域幅、ストレージ、処理能力を消費させる目的で、極端に大きなメタデータやメディアファイルを提供する場合があります。

再帰的な参照

メタデータが相互に繰り返し参照する追加リソースにリンクし、過剰なリクエストを発生させる場合があります。

Unicodeによる偽装

トークン名やシンボルに、信頼できる資産に見せかけるため、形の似たUnicode文字が使われる場合があります。

メタデータの差し替え

管理者や侵害されたサーバーが、ユーザーによるトークン取得後に変更可能なメタデータを差し替える場合があります。

スキーマの操作

リモートスキーマやJSON-LDコンテキストが変更され、文書の解釈が変わる可能性があります。

プライバシー追跡

固有のメディアURLにより、特定のウォレットやユーザーがトークンのメタデータを閲覧した時刻が明らかになる場合があります。

虚偽の主張

メタデータには、所有権、希少性、真正性、法的権利、準備金、作成者の承認について虚偽の主張が含まれる可能性があります。

メタデータとウォレットフィッシング

ウォレットが見慣れないトークンを検出し、そのメタデータに報酬を約束するメッセージやアカウントの問題を警告するメッセージが表示される場合があります。

メタデータがユーザーを悪意あるWebサイトに誘導することもあります。

トークンを受け取ったからといって、その名前、画像、Webサイト、発行者を信頼できるとは限りません。

ユーザーは、ブロックチェーン、コントラクトアドレス、公式情報源、求められているウォレット操作を個別に確認してください。

メタデータ文書がユーザーの秘密鍵やリカバリーフレーズを求める必要はありません。

メタデータのプライバシーリスク

公開メタデータから、個人名、所在地、クレデンシャル、メンバーシップ、健康情報、金融上の関係が明らかになる場合があります。

公開ブロックチェーンに直接保存されたデータは、削除が困難、または不可能な場合があります。

機微なメタデータを暗号化すると一般公開を抑えられますが、鍵管理や長期的な機密性に関する課題が生じます。

候補となる元の値が簡単に推測できる場合、公開ハッシュから情報が明らかになる可能性もあります。

プロジェクトは個人データを最小限に抑え、暗号資産の目的に必要な情報だけを保存する必要があります。

暗号資産のメタデータ標準を設計する方法

ユースケースを定義する

設計者は、メタデータがどの資産、ID、クレデンシャル、アプリを説明するのか特定する必要があります。

一意の識別子を定義する

識別子では、名前やシンボルに頼らず、ブロックチェーン、コントラクト、資産の種類、個別のトークンを区別できるようにする必要があります。

データ形式を選ぶ

形式は広くサポートされ、必要な場合には決定論的で、想定されるデータ量に適したものである必要があります。

必須フィールドを定義する

信頼性の高い相互運用性に必要なフィールドのみを必須にする必要があります。

データ型を定義する

各フィールドについて、型、許容範囲、エンコード方法、エラー処理方針を明確にする必要があります。

URIの動作を定義する

標準では、対応するURIスキーム、相対参照のルール、取得時の要件、セキュリティ制限を明示する必要があります。

変更可能性を定義する

メタデータを誰が更新できるか、将来的に更新を無効化できるかを標準で説明する必要があります。

完全性の保護方法を定義する

重要な外部文書では、ハッシュ、コンテンツ識別子、署名、その他の検証可能な完全性確認方法を使用する必要があります。

バージョン管理を定義する

アプリが、互換性のないスキーマのバージョンや将来の拡張を確実に特定できる方法が必要です。

障害時の処理を定義する

欠落、不正形式、取得不能、過大、非対応のメタデータをソフトウェアがどう処理するかを標準で説明する必要があります。

セキュリティ上の考慮事項を文書化する

仕様では、悪意ある入力、リモート参照、プライバシー、アクセス制御、アップグレード権限、サービス妨害のリスクを説明する必要があります。

暗号資産プロジェクト向けメタデータのベストプラクティス

ティッカーシンボルではなく、ブロックチェーンとコントラクトアドレスを資産の主な識別情報として使用します。

必要なユースケースをすでに扱う最終版の標準がある場合は、それに従います。

ドラフトまたは実験的なメタデータ拡張は、その旨を明確に表示します。

トークンコレクション全体で、安定したフィールド名とデータ型を使用します。

公開前にすべてのメタデータ文書を検証します。

変更されないことが期待されるリソースには、コンテンツアドレス指定または暗号学的ハッシュを使用します。

ユーザーがトークンを取得する前に、更新権限と凍結ルールを公開します。

対応している場合は、標準化された更新イベントを発行します。

監査や紛争に備えて、過去のメタデータのバージョンを保持します。

個人情報や機密データを公開ブロックチェーンに恒久保存しないようにします。

アクティブメディアを制限し、外部コンテンツを表示する前にサニタイズします。

意味のあるテキスト説明と言語情報を提供します。

重要なオフチェーンファイルには、冗長な保存手段を用意します。

重要な参照情報のいずれかが変更可能な場合、不変であると主張しないでください。

トークンメタデータの評価方法

正しいブロックチェーンとトークンのコントラクトアドレスを確認します。

コントラクトがどのトークン標準とメタデータ標準に準拠するとしているかを確認します。

技術的に可能であれば、コントラクトからURIを直接読み取ります。

メタデータがオンチェーン、HTTPS、IPFS、その他のどのシステムに保存されているかを確認します。

利用できる場合は、コンテンツ識別子やハッシュを検証します。

コントラクト、URI、メタデータ、スキーマ、ストレージ参照を誰が変更できるか確認します。

メタデータ更新イベントが発行されるか確認します。

リンク先のメディアや外部URLを慎重に調べます。

法的主張や資産の裏付けに関する主張は、独立した資料と照合します。

真正性の証明として、ロゴ、名前、ティッカーシンボルだけに頼らないでください。

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

よくある誤りは、有効なJSONであることを、トークン標準に準拠している証拠とみなすことです。

トークンシンボルを、世界で一意な資産識別子として使用することも誤りです。

一部のプロジェクトは、通常のサーバーにメタデータを保存しながら、資産が完全に不変であると宣伝しています。

別の文書にIPFS CIDを記載しつつ、その文書のURIをコントラクトから置き換えられるようにしているプロジェクトもあります。

同じコレクション内で属性名や値が統一されていないメタデータ文書もあります。

アプリが、サニタイズやコンテンツ制限を行わずにアクティブメディアを表示する場合もあります。

開発者が、すべてのウォレットでカスタムメタデータフィールドがサポートされていると想定する場合があります。

変更可能なメタデータを更新した後に、更新イベントを発行しないこともよくある誤りです。

ドラフト提案のフィールドや動作が今後も変更される可能性を開示せずに、その提案を使用するプロジェクトもあります。

機微な個人情報をオンチェーンに恒久保存すると、重大なプライバシーおよびコンプライアンス上の問題が生じる可能性があります。

よくある質問

メタデータ標準を簡単に説明すると？

メタデータ標準とは、暗号資産やブロックチェーン記録に関する説明情報を構造化、保存、取得、解釈するための共通ルールです。

暗号資産のメタデータとは？

暗号資産のメタデータとは、トークン、NFT、ブロックチェーンアカウント、クレデンシャル、トランザクション、表現対象の資産に関する情報です。

暗号資産にメタデータが必要な理由は？

メタデータは、ソフトウェアが読みやすい名前、シンボル、画像、小数桁数、属性、ID、外部リソースを表示するのに役立ちます。

メタデータはブロックチェーンに保存される？

オンチェーン、オフチェーン、またはブロックチェーン上の参照情報と外部ファイルを組み合わせたハイブリッド方式で保存できます。

オンチェーンメタデータとは？

オンチェーンメタデータとは、ブロックチェーンの状態、スマートコントラクトのストレージ、トランザクションデータに直接保存された説明データです。

オフチェーンメタデータとは？

オフチェーンメタデータはブロックチェーンの外部に保存され、ブロックチェーンにはURIなどの参照情報が記録されます。

オフチェーンメタデータは安全ではない？

安全に利用できますが、管理が必要なホスティング、完全性、可用性、ドメイン、更新に関するリスクが生じます。

ERC-20で定義されているメタデータは？

ERC-20では、トークン名、シンボル、小数桁数を取得する任意関数が定義されています。

トークン名とシンボルは一意？

いいえ。無関係なコントラクトが同じトークン名やシンボルを使用する場合があります。

代替可能トークンはどのように識別すべき？

シンボルだけでなく、ブロックチェーンとコントラクトアドレスによって識別する必要があります。

ERC-721メタデータとは？

ERC-721メタデータは、トークン固有のURIを使って個々の非代替性トークンに関する情報を提供します。

ERC-1155メタデータとは？

ERC-1155メタデータは、1つのコントラクト内で複数のトークン種別に対応できるURIインターフェースとJSONスキーマを使用します。

ERC-1155の

{id}

プレースホルダーとは？

対応するアプリは、

を付けない、小文字の64文字の16進数形式にしたトークンIDで置き換えます。

ERC-4906とは？

ERC-4906は、ERC-721のメタデータ更新をアプリに通知するイベントを定めた最終版の拡張です。

ERC-8048とは？

ERC-8048は、マルチトークンおよびNFTレジストリに直接保存するキー・バリュー形式のメタデータについて、2025年に公開されたドラフト提案です。

ERC-8048は最終版の標準？

いいえ。現在もドラフトであり、最終化までに変更される可能性があります。

暗号資産のメタデータにJSONが使われる理由は？

JSONは読みやすく軽量で、幅広くサポートされ、構造化データの交換に適しています。

有効なJSONなら有効なトークンメタデータといえる？

いいえ。該当するメタデータスキーマとアプリの要件も満たす必要があります。

JSON Schemaとは？

JSON Schemaは、JSON文書を検証する機械可読ルールを定めます。

JSON-LDとは？

JSON-LDは、JSON構造にリンクトデータの意味と世界的に定義された識別子を追加します。

メタデータURIとは？

メタデータURIは、トークンのメタデータを含む、または表すリソースを識別します。

IPFS CIDとは？

IPFS CIDは、コンテンツの暗号学的ハッシュとエンコード方式から一部導出されるコンテンツ識別子です。

IPFS CIDは恒久的な保存を保証する？

いいえ。コンテンツの識別には役立ちますが、アクセス可能なプロバイダーがデータを保存し続けることまでは保証しません。

コンテンツアドレス指定されたメタデータとは？

コンテンツアドレス指定されたメタデータは、サーバー上の場所だけでなく、コンテンツ自体から導かれる情報によって識別されます。

メタデータの完全性とは？

メタデータの完全性とは、取得したバイト列が信頼済みのハッシュ、コンテンツ識別子、署名、その他の完全性参照情報と一致することです。

ハッシュが一致すればメタデータの真実性を証明できる？

いいえ。バイト列が想定したコンテンツと一致することは示せますが、内部の主張が正確であることは証明しません。

NFTのメタデータは変更できる？

はい。コントラクトやストレージシステムで権限を持つ主体による更新が許可されている場合、変更される可能性があります。

凍結されたメタデータとは？

凍結されたメタデータとは、今後の変更が技術的に制限または無効化された状態の情報です。

オンチェーンメタデータは常に変更されない？

いいえ。アップグレード可能なコントラクトや管理者が制御するストレージでは、オンチェーンメタデータを変更できる場合があります。

メタデータのバージョン管理とは？

メタデータのバージョン管理は、スキーマや文書の経時的な変更を識別し、保持するものです。

CAIP-19とは？

CAIP-19は、暗号資産の種類や個々の資産を識別する、チェーンに依存しない標準です。

クロスチェーン識別子が重要な理由は？

異なるブロックチェーン上の資産が、似た名前、シンボル、コントラクト形式を理由に混同されるのを防ぎます。

DIDメタデータとは？

DIDメタデータは、分散型識別子、コントローラー、検証方法、サービスエンドポイントを説明します。

検証可能なクレデンシャルのメタデータとは？

発行者、クレデンシャルの対象者、主張、有効期間、ステータス、スキーマ、保護方法を説明します。

メタデータにマルウェアが含まれることはある？

メタデータが悪意あるリンク、スクリプト、アクティブメディア、過大なファイル、その他の危険なコンテンツを参照する場合があります。

NFTを受け取るとウォレットがフィッシングの危険にさらされる？

はい。依頼していないトークンのメタデータに、ユーザーをだますための悪意あるリンクや偽の報酬メッセージが表示される場合があります。

メタデータがリカバリーフレーズを要求することはある？

正規のメタデータ文書、トークン発行者、サポート手続きがウォレットのリカバリーフレーズを必要とすることはありません。

メタデータから個人情報が漏れることはある？

はい。公開メタデータから、本人確認情報、メンバーシップ、所在地、クレデンシャル、金融上の関係が明らかになる場合があります。

暗号資産のメタデータはどのように検証できる？

構文検証、スキーマ検証、URIルール、暗号学的ハッシュ、署名、意味的な確認を通じて検証できます。

メタデータ標準の最大の限界は？

標準はデータの相互運用性を高めますが、説明された資産、発行者、主張の正当性を保証できません。

トークンメタデータを信頼する前に何を確認すべき？

ブロックチェーン、コントラクトアドレス、メタデータ標準、ストレージ方法、更新権限、完全性の参照情報、外部の主張を確認してください。

まとめ

メタデータ標準は、暗号資産、NFT、ID、クレデンシャル、ブロックチェーン上のリソースに関する説明情報の構造化と交換方法を定めます。

ウォレット、スマートコントラクト、インデクサー、アプリが、名前、シンボル、小数桁数、画像、特性、識別子、外部リソースを一貫して解釈できるようにします。

主な暗号資産メタデータの仕組みには、代替可能トークンのフィールド、ERC-721のトークンURI、ERC-1155のメタデータスキーマ、ERC-4906の更新イベント、JSON、JSON Schema、JSON-LD、コンテンツ識別子、チェーンに依存しない資産識別子があります。

メタデータはオンチェーンに直接保存する方法、オフチェーンでホスティングする方法、ブロックチェーン上の参照情報と暗号学的な完全性検証を組み合わせるハイブリッド方式で保存できます。

オンチェーン保存は不変性を保証せず、コンテンツアドレス指定も恒久的な利用可能性を保証しません。

アプリはスキーマを検証し、外部コンテンツをサニタイズし、更新権限を確認し、バージョン履歴を保持するとともに、名前やシンボルを一意の識別情報として信頼しないようにする必要があります。

ユーザーは、メタデータを説明情報として扱い、トークンの真正性、価値、裏付け、法的執行可能性の証明とみなしてはいけません。

適切に設計されたメタデータ標準が暗号資産の相互運用性を高めるには、安全なストレージ、正確な主張、明確なガバナンス、プライバシー保護、信頼性の高い検証が伴う必要があります。