はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、NFTを使って文化財や歴史的資産の来歴・価値・文脈を正確に記録し、改ざんできない形で保存・共有するための新しいメタデータ標準「CHAT（Cultural and Historical Asset Token）」を定める仕組みを提案しているERC6596についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

概要

ERC6596は、Cultural and Historical Asset Tokens（CHATs）、つまり「文化的・歴史的資産トークン」のための包括的なメタデータ標準を**Ethereumプラットフォーム上に確立することを目的としています。
CHATは、美術品・工芸品・収集品・希少品などの文化的・歴史的価値を持つ資産をデジタル上で表現するためのトークンです。

現状の課題

既存のNFT（非代替性トークン）標準は、資産の改ざん防止性や分散型所有を保証しています。
しかし、それらは文化財の「由来（provenance）」や「文化的・歴史的な重要性」を十分に表現する仕組みを備えていません。
そのため、博物館や文化機関が採用するには不十分です。

CHAT標準の目的

CHAT標準は、以下の3つの目的を持っています。

資産の来歴や文脈を保存して真正性を担保する
資産の価値を裏付けるために、その背景や歴史をメタデータとして記録します。
改ざんできない形で記録を残して透明性を確保する
博物館や個人所有者が、信頼できる形で資産情報をブロックチェーン上に残せるようにします。
既存のアート・文化領域のメタデータ標準との互換性を確保する
これにより、異なる機関や地域のデジタルアーカイブが連携し、検索や発見が容易になります。

このようにCHAT標準は、文化的・歴史的資産を真正で透明な形で保存・共有できる環境を整備し、Web3技術の社会的受容を加速させることを狙いとしています。

動機

文脈と意義の保存

文化的・歴史的資産の価値は、その由来や文脈（コンテクスト）に大きく依存します。
CHAT標準は、作品や遺物が「いつ、どこで、誰によって作られ、どのように扱われてきたか」という履歴を記録します。
また、新たな研究成果などによって文脈が変化した場合でも、その変遷を履歴として残します。
この仕組みによって、資産の真正性（authenticity）と文化的意義が確固たるものになります。

証拠に基づく保存

近年、世界的な博物館で発生した遺物の紛失やデータ流出の事例は、現行の記録管理体制の限界を示しています。
多くのシステムは「信頼ベース（trust-based）」で運用されていますが、ブロックチェーンは「証拠ベース（proof-based）」で記録を残せる技術です。

CHATを利用すれば、以下のことが可能になります。

改ざん不可能な形で、資産情報をEthereum上に保存
資産の更新・修正時に、その履歴を自動的に記録
誰が・いつ・どのように変更したかを追跡可能

これにより、透明性と説明責任（accountability）を確保できます。
文化機関は、信頼ではなく技術的証拠によって資産を守ることができるようになります。

相互運用性

芸術・文化分野では、すでに多くのメタデータ標準（例：OAI『Open Archives Initiative』やIIIF『International Image Interoperability Framework』**）が使われています。
CHAT標準はこれらと互換性を持ち、ブロックチェーン上で扱えるよう設計されます。
つまり、既存のアーカイブデータをそのまま生かしつつ、分散的に保存・共有できるようになります。

検索と発見

文化財の所有や歴史的情報は、多くの機関に分散しています。
完全な一元化は難しいですが、CHAT標準を使えば分散したデータを横断的に検索・発見することができます。

例えば、シルクロード遺跡の出土品（artifact）を、世界中の博物館にある仏教絵画・彫像・文献**と関連付けることができます。
このような連携によって、研究者や一般の人々が文化的資産の関係性を簡単に探索できるようになります。

CHAT標準は、以下のような幅広い利用者にとって有益です：

利用者層	活用例
一般の人々	文化遺産の学習や鑑賞
研究者・学者	歴史的関係性や出所の追跡
文化機関・博物館	展示・データ連携・管理
メディアやブランド	コンテンツ制作やデジタル展示

既存標準（ERC721）の課題

現在広く使われているERC721標準には、以下のような基本的なメタデータ拡張が含まれています：

項目	内容
`name`	コレクション名
`symbol`	シンボル名（略称）
`description`	説明文
`image`	画像URL

しかし、これだけでは文化的文脈や来歴情報を十分に表現できません。
そのため、多くのNFT発行者が独自のメタデータ形式を作っていますが、これが相互運用性の欠如を招いています。
特に文化的資産の場合、異なるコレクション間の関連性が極めて重要であるため、統一的な形式が必要です。

CHAT標準はこの問題を解決し、以下のような価値をもたらします。

資産の「文脈」や「歴史」を一貫した形式で記述
どのトークンも同様の構造で検索・比較可能
異なる機関の資産を横断的に発見できる

これにより、文化・歴史分野におけるブロックチェーンの利活用を本格的に推進できます。

仕様

概要

CHAT標準は、ERC721およびERC1155のメタデータ構造を拡張します。
互換性のあるコントラクトは、以下の条件を満たす必要があります。

対応するメタデータスキーマ（ERC721の場合は「Metadata JSON Schema」、ERC1155の場合は「Metadata URI JSON Schema」）を実装すること。
以下で定義される文化的・歴史的資産メタデータインターフェースを実装すること。

文化的・歴史的資産メタデータ拡張（TypeScriptインターフェース）

以下のTypeScriptインターフェースは、CHATメタデータの構造を示します。
この形式に準拠することで、トークンは互換性を持ちプラットフォーム間で統一的に扱うことができます。

interface HistoricalAssetMetadata {
    name?: string;                              // CHATの名称
    description?: string;                       // 資産の文化的・歴史的な背景を含む詳細な説明
    image?: string;                             // 表紙画像（image/* MIMEタイプ）のURI
    attributes?: CHATAttribute[];               // 表示用の属性リスト
    attributesExt?: ExtendedCHATAttribute[];    // 非表示の拡張属性リスト
}

attributesは主に表示用情報を含み、attributesExtは裏付けとなるドキュメントや詳細データを格納します。

CHAT属性

CHATAttributeは、文化的・歴史的価値を表現するための主要な項目です。
以下のように48種類の trait_type が定義されています。

`trait_type`	説明
Catalogue Level	記録がどの分類レベル（コレクション全体、個別作品など）に属するかを示す。
Publication / Creation Date	資産が作成または発行された最も古い日付（ISO 8601形式）。
Creator Name	制作者の名前や団体名。匿名の場合は推定文化や国籍を記載。
Creator Bio	制作者の略歴や説明。
Asset Type	資産の種類（例：絵画、彫刻、書籍など）。
Classification	美術品や建築物を分類するための用語またはコード。
Materials and Technology	使用された素材や技法。
Subject Matter	資産の主題。作品が描写する内容を示す。
Edition	作品の版数。
Series name	作品が属するシリーズ名。
Dimensions Unit	寸法の単位（例：cm、mm）。
Dimensions (height)	資産の高さ。
Dimensions (width)	資産の幅。
Dimensions (depth)	資産の奥行き。
Inscriptions / Marks	作品上の文字、ラベル、刻印などの識別情報。
Credit Line	公開時に表示される出典やクレジット情報。
Current Owner	現在の所有者名。
Provenance	所有履歴。過去の所有者や取得経緯を含む。
Acquisition Date	現所有者が資産を取得した日付。
Citation	出版物などで資産が引用された情報。
Keyword	研究目的などで使われるキーワード。
Copyright Holder	著作権保有者。
Bibliography	資産が参照・引用・利用された文献情報。
Issuer	トークンを発行した主体。
Issue Timestamp	トークンの発行日時。
Issuer Description	発行者の簡単な説明。
Asset File Size	デジタルファイルのサイズ（バイト単位）。
Asset File Format	ファイル形式（MIMEタイプを含む）。
Copyright / Restrictions	著作権や利用制限の状態。
Asset Creation Geo	作成国・地域・都市（ISO 3166-2形式に準拠）。
Asset Creation Location	資産が作成された具体的な場所。
Asset Creation Coordinates	作成場所の座標（緯度・経度）。
Relevant Date	資産の重要な関連日付（ISO 8601形式）。
Relevant Geo	資産と関連する国・地域・都市。
Relevant Location	資産に関係する特定の地名。
Relevant Person	資産に関係する人物。
Relevant Entity	資産に関係する組織・団体。
Asset Language	資産で使用されている言語（ISO 639準拠）。
Is Physical Asset	資産が実物（物理的存在）であるかどうかを示す真偽値。

拡張CHAT属性

ExtendedCHATAttributeは、追加の文書や裏付けデータなど、公開表示には含まれないメタ情報を保持します。

`trait_type`	説明
Asset Full Text	資産に含まれる全文。
Exhibition / Loan History	展示・貸出の履歴。開催場所、期間、企画者、主催者、協賛者などを含む。
Copyright Document	著作権に関する法的契約文書へのURI。
Provenance Document	資産の来歴を示す既存ドキュメントへのURI。
Asset URL	高品質な資産ファイルへのURI。
Copyright Document of Underlying Asset	トークン所有者の権利を明記した法的文書へのURI。展示・複製・販売・派生作品の作成権などを含む。

実装例：葛飾北斎「神奈川沖浪裏」

この例は、CHATメタデータの実際の利用方法を示しています。
例として挙げられているのは、葛飾北斎の代表作「神奈川沖浪裏（The Great Wave）」で、現在シカゴ美術館が所蔵しています。
このJSON形式はERC721およびOpenSea形式と互換性があります。

{
  "name": "Under the Wave off Kanagawa (Kanagawa oki nami ura), also known as The Great Wave, from the series “Thirty-Six Views of Mount Fuji (Fugaku sanjūrokkei)",
  "description": "Katsushika Hokusai’s much celebrated series, Thirty-Six Views of Mount Fuji (Fugaku sanjûrokkei), was begun in 1830...",
  "image": "ipfs://bafybeiav6sqcgzxk5h5afnmb3iisgma2kpnyj5fa5gnhozwaqwzlayx6se",
  "attributes": [
    { "trait_type": "Publication / Creation Date", "value": "1826/1836" },
    { "trait_type": "Creator Name", "value": "Katsushika Hokusai" },
    { "trait_type": "Creator Bio", "value": "Katsushika Hokusai’s woodblock print The Great Wave is one of the most famous..." },
    { "trait_type": "Asset Type", "value": "Painting" },
    { "trait_type": "Classification", "value": "Arts of Asia" },
    { "trait_type": "Materials and Technology", "value": "Color woodblock print, oban" },
    { "trait_type": "Series name", "value": "Thirty-Six Views of Mount Fuji (Fugaku sanjûrokkei)" },
    { "trait_type": "Dimensions Unit", "value": "cm" },
    { "trait_type": "Dimensions (height)", "value": 25.4 },
    { "trait_type": "Dimensions (width)", "value": 37.6 },
    { "trait_type": "Current Owner", "value": "Art Institute of Chicago" },
    { "trait_type": "Provenance", "value": "Yamanaka, New York by 1905" },
    { "trait_type": "Acquisition Date", "value": "1925" },
    { "trait_type": "Copyright Holder", "value": "Public domain" },
    { "trait_type": "Copyright / Restrictions", "value": "CC0" },
    { "trait_type": "Asset Creation Geo", "value": "Japan" },
    { "trait_type": "Relevant Location", "value": "Art Institute of Chicago" },
    { "trait_type": "Asset Language", "value": "Japanese" },
    { "trait_type": "Is Physical Asset", "value": true }
  ]
}

この例では、北斎の作品が持つ文化的背景（江戸時代、浮世絵、技法）と歴史的文脈（所蔵者の変遷、出版年、展示記録）がすべてメタデータとして記録されています。
このようなデータ構造により、作品の真正性・来歴・文化的価値が、ブロックチェーン上で永久に保存され、誰でも検証できるようになります。

補足

オフチェーンのメタデータJSONスキーマを拡張する理由

CHAT標準では、オンチェーン（ブロックチェーン上）での実装ではなく、オフチェーン（外部サーバー上）に保存されるメタデータJSONを拡張する方式を採用しています。
その理由は、既存のNFT標準（ERC-721およびERC-1155）が、すでにNFTに関連するメタデータを外部JSONファイルで管理する設計を持っているためです。

このアプローチにより、以下のような利点が得られます。

項目	説明
柔軟な拡張性	オフチェーンのメタデータ構造を利用することで、既存のNFTコントラクトを変更せずにCHAT標準を導入できます。つまり、新しいスマートコントラクトをデプロイしたり、既存資産を移行する必要がありません。
リスクの軽減	監査済みで安全性が確認された既存のスマートコントラクトコードをそのまま利用できます。新しい仕様導入時に発生しがちなセキュリティリスクを最小化します。
段階的な導入が可能	コレクション単位で段階的にCHAT標準を採用できるため、既存NFTプロジェクトが無理なく移行可能です。
既存プラットフォームとの互換性	OpenSeaなどの既存NFTマーケットプレイスやギャラリーが使用している仕組みと整合性があり、既存エコシステムに自然に組み込めます。

このように、オフチェーン拡張は「既存資産を壊さず」、「リスクを最小化し」、「段階的な進化を促す」という現実的で実装しやすい選択となっています。

attributes と attributesExt の分離設計

CHAT標準では、メタデータ属性を2つのプロパティに分けて管理します。
それが「attributes」と「attributesExt」です。
この設計は、NFTマーケットプレイスやギャラリーとの互換性を維持しつつ、学術的・文化的データの拡張性を確保するための工夫です。

`attributes` プロパティ

attributesプロパティには、NFTギャラリーやマーケットプレイスで表示・検索・分類に使用される主要なメタデータを格納します。
つまり、トークンの基本的な識別情報や公開すべき特徴がここに含まれます。

この設計により、CHATトークンは以下のようなメリットを得ます。

OpenSeaなど既存のNFTプラットフォームに自然に統合できる
作品名、制作者、分類、作成年代などが標準形式で表示される
研究者や収集家が検索・比較しやすくなる

例として、attributesには以下のような情報が含まれます。

`trait_type`	値の例
Creator Name	Katsushika Hokusai
Publication / Creation Date	1826/1836
Classification	Arts of Asia
Dimensions (width)	37.6
Current Owner	Art Institute of Chicago

これらは作品の見える情報であり、誰が見ても理解しやすい要素です。

`attributesExt` プロパティ

attributesExtプロパティは、一般ユーザーが見る必要はないが文化的・学術的に重要な裏付け情報を格納します。
例えば、展示履歴、来歴書類、著作権契約書、または作品全文データなどが含まれます。

この設計の目的は、以下の2点にあります。

目的	内容
表示の簡潔さ	一般のNFTユーザーやコレクターの体験を損なわず、UIが複雑にならないようにする。
専門利用への対応	研究者・学芸員・アーカイブ管理者などが必要とする深い情報を保持できるようにする。

これにより、CHATトークンは「文化的価値の可視化」と「学術的情報の保存」を両立できます。

設計の意図と効果

attributes と attributesExt の二層構造は、CHAT標準の中核的な特徴です。
この分離により、以下のような利点が得られます。

観点	効果
互換性	既存NFTギャラリーの仕様に完全対応。CHATトークンは既存システム上でそのまま表示できる。
拡張性	`attributesExt`を活用して、今後さらに詳細な文化データを追加可能。
利用者ごとの最適化	一般ユーザーには見やすく、研究者には十分な情報量を提供できる。
データの信頼性	公開・非公開情報を明確に分離することで、データ管理と検証が容易になる。

つまり、CHAT標準は「NFTの美術館版」とも言える構造です。
表のレイヤー（attributes）は鑑賞者向け、裏のレイヤー（attributesExt）は学芸員や研究者向けの情報保存層として機能します。

互換性

ERC721とERC1155と互換性があります。

セキュリティ

クライアント提供データとしての扱い

NFTプラットフォームやシステムは、Cultural and Historical Asset Metadata JSONファイルを「クライアントから提供されたデータ」として扱うことが推奨されています。
つまり、信頼できるデータとはみなさず、入力データの安全性を常に検証・制限することが前提となります。

この考え方により、外部から提供されるJSONデータを通じた攻撃（例えば、不正なスクリプトの挿入や改ざん）を防ぐことができます。

URIフィールドの取り扱いとSSRF対策

JSONメタデータ内には、画像や文書などへのURI（リンク）フィールドが多く含まれます。
このURIは外部のサーバーを指す可能性があるため、Server-Side Request Forgery（SSRF：サーバー側リクエスト偽装）攻撃のリスクがあります。

SSRFとは、攻撃者が悪意のあるURIを仕込むことで、サーバー自身に内部リクエストを送信させ、通常アクセスできない内部ネットワークやクラウドメタデータサービスなどにアクセスさせる攻撃です。

これを防ぐために、バックエンドシステムは以下のような対策を取るべきです。

項目	対策内容
URIの検証	スキーマ（http/https）を限定し、不正なプロトコル（file://, ftp://, gopher://など）を拒否する。
リクエスト制御	URI先への自動リクエストを避け、外部アクセスを必要最小限に制限する。
ネットワーク分離	メタデータ取得を行うプロセスを、内部ネットワークから分離する。

フロントエンド側でのXSS対策

フロントエンドまたはクライアント側のシステムでは、ユーザーが閲覧する画面にメタデータをそのまま表示する場合があります。
その時にCross-Site Scripting（XSS）攻撃の危険性が発生します。

XSSとは、攻撃者がスクリプトを仕込んだデータを通して、閲覧者のブラウザ上で不正なJavaScriptコードを実行させる攻撃です。

このリスクを防ぐため、以下のような対策が推奨されます。

項目	対策内容
制御文字のエスケープ	HTMLやJavaScriptの制御文字（例：<、>、&、"、'）をすべて適切にエスケープする。
安全なレンダリング	innerHTMLのような生のHTML挿入ではなく、フレームワークの安全なバインディング機構を使う。
コンテンツサニタイズ	信頼できない文字列をユーザー画面に出す前に検証・除去する。

リソース管理とDoS対策

メタデータJSONを処理するシステムは、データ量や入力構造が不正に操作されることで
**Denial of Service（DoS：サービス拒否攻撃）**を受ける可能性があります。

例えば、非常に大きな配列や無限ループを誘発する構造を送信されると、サーバーのメモリやCPUが過負荷になり、システムが停止するおそれがあります。

また、文字列や配列、オブジェクトなど可変長データの誤処理によりバッファオーバーフロー（メモリ領域の破壊）が起こるリスクもあります。

このような攻撃を防ぐには、以下の対策が重要です。

リスク	防止策
大量データ送信	データサイズや配列長を上限値で制限する。
無限ループ	JSON構造の深さ（ネスト数）を制限し、再帰処理に制限時間を設ける。
バッファオーバーフロー	メモリ割り当てを動的ではなく安全な固定サイズで行う。
例外処理の乱用	エラー時にコード実行を停止し、任意コードの実行を許可しない。

データの保全と分散ストレージ

CHAT標準では、メタデータJSONファイルおよびトークンの元となるデジタルリソースを
**分散型ストレージネットワーク（例：IPFSやArweaveなど）**に保存することが推奨されています。

これには以下のようなメリットがあります。

目的	内容
改ざん防止	分散ストレージはハッシュによる内容識別が行われ、改ざんが検出可能。
永続性	特定のサーバーが停止してもデータが失われにくい。
可用性	ネットワーク上に複数のノードがコピーを保持するため、アクセスが安定。

この分散保存によって、長期的な文化資産の保存と真正性の維持が可能になります。

メタデータの真正性について

CHAT標準はメタデータの形式と構造を規定していますが、メタデータ内で主張されている内容（例：所有権・出典・著作権など）が本物であるかどうかを検証する仕組みまでは含んでいません。

つまり、「このNFTの発行者が本当に正当な所有者か」、「提供された履歴が正確か」といった真正性の保証はERC6596の範囲外です。
今後、これらの真正性検証を扱う新しいプロトコルやEIPが提案される予定とされています。

引用

Phillip Pon phillip@artifactlabs.com, Gary Liu gary@artifactlabs.com, Henry Chan henry@artifactlabs.com, Joey Liu joey@artifactlabs.com, Lauren Ho lauren@artifactlabs.com, Jeff Leung jeff@artifactlabs.com, Brian Liang brian@artifactlabs.com, Joyce Li joyce@artifactlabs.com, Avir Mahtani avir@artifactlabs.com, Antoine Cote (@acote88), David Leung (@dhl), "ERC-6596: Cultural and Historical Asset Token [DRAFT]," Ethereum Improvement Proposals, no. 6596, February 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6596.

最後に

今回は「NFTを使って文化財や歴史的資産の来歴・価値・文脈を正確に記録し、改ざんできない形で保存・共有するための新しいメタデータ標準「CHAT（Cultural and Historical Asset Token）」を定める仕組みを提案しているERC6596」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！