[ERC7007] AI生成コンテンツをNFTにして検証できる仕組みを理解しよう！

Posted at 2025-10-01

はじめに

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

今回は、AIが生成したコンテンツをNFTとして発行し、その生成過程をブロックチェーン上で暗号的に検証できる仕組みを提案しているERC7007についてまとめていきます！

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

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

概要

ERC7007は、AIが生成したコンテンツ（AIGC：AI Generated Content）をブロックチェーン上で安全かつ検証可能に扱うための新しいNFT標準である「Verifiable AIGC-NFT Standard」について提案しています。
既存のERC721トークン規格を拡張し、AIによって生成されたコンテンツの信頼性や正当性を保証できるよう設計されています。

addAigcData 関数
AIGC データを追加するためのインターフェイス
verify 関数
AIGC データの正当性を検証するためのインターフェイス
AigcData イベント
AIGC データの追加や更新を通知するための新しいイベント
Enumerable / Updatable 拡張機能（任意）
AIGC データの列挙・更新を可能にする拡張
JSON スキーマ
AIGC-NFT のメタデータ構造を定義するための形式

さらに、**Zero-Knowledge Machine Learning（zkML）とOptimistic Machine Learning（opML）**という2種類の仕組みを取り入れ、AIモデルによって生成されたデータの正しさを検証可能にしています。

ERC7007では、各トークン（NFT）はprompによって一意に識別されます。
つまり、ユーザーが入力したプロンプトごとにNFTが生成され、その生成過程が証明可能になります。

動機

背景と目的

従来のERC721では、AIが生成したコンテンツのように「生成元モデル」と「入力情報（プロンプト）」をもとにしたNFTの検証には対応していませんでした。
Verifiable AIGC-NFT Standardは、これを解決するために設計されており、AI モデルと生成データの関係性を暗号的に証明できるようにします。

この仕組みにより、NFTの所有者や購入者は「本当に指定されたモデルと入力から生成されたコンテンツなのか」を確認できるようになります。
特に、AIモデルの著作者やAIGCクリエイターにとって、生成物の正当性や収益分配の透明性が確保されることは大きな利点です。

証明の種類と対応技術

ERC7007では、AIGCデータの検証に以下の2種類の証明手法を採用しています。

証明タイプ	説明	主な利用技術
有効性証明（Validity Proof）	正しい生成過程で得られた出力であることを証明	zkML（ゼロ知識機械学習）
不正防止証明（Fraud Proof）	不正な出力に対して異議申し立てを可能にする	opML（オプティミスティック機械学習）

開発者は、ユースケースに応じて zkML または opML のいずれかを選択できます。

zkML シナリオの動作

zkML（Zero-Knowledge Machine Learning）は、ゼロ知識証明という暗号技術を用いて「ある入力とモデルから導かれた出力が正しい」ことを情報を開示せずに証明します。

モデルの所有者は、学習済みモデルとそのZKP（ゼロ知識証明）検証用スマートコントラクトをEthereumに公開します。
任意のユーザーが、モデルに対する入力（プロンプト）を指定して推論タスクを発行します。
モデルを保持するノードが推論と証明を実行し、推論結果と証明データを検証コントラクトに送信します。
検証が成功すると、ユーザーはそのモデルと入力に対応する出力（AIGC）をNFTとして所有できます。

この仕組みにより、出力の正当性が暗号的に保証され、第三者が不正に生成結果を改ざんすることができません。

opML シナリオの動作

opML（Optimistic Machine Learning）は、オプティミスティック・ロールアップと同様の考え方を取り入れた仕組みです。
この手法では、まず推論結果を「正しい」と仮定して処理を進め、他のノードが不正を検出した場合のみ「チャレンジ」を行う方式を採用しています。

モデルの所有者は、学習済みモデルをEthereum上に公開します。
ユーザーが入力（プロンプト）を指定して推論タスクを発行します。
モデルを保持するノードが推論を実行し、その出力をブロックチェーン上に投稿します。
定められたチャレンジ期間の間、他のノードは不正がないか検証できます。
期間終了後、チャレンジがなければ出力は承認され、ユーザーはその出力をNFTとして所有します。

この方式は、ゼロ知識証明に比べて計算コストを抑えつつ、不正検出の柔軟性を高められる点が特徴です。

標準の意義と活用可能性

この標準は、AI モデル開発者やコンテンツクリエイターが、生成物を安心して公開・販売できるようにするための基盤です。
プロンプトと生成結果の対応関係をブロックチェーン上で検証できるため、著作権管理・収益分配・透明性の確保が可能になります。

例えば、AIアートやAI文章生成、音楽生成など、AIGCの分野で次のような応用が考えられます。

各プロンプトごとにユニークなNFTを生成し、出力とプロンプトの関係を証明
モデル作成者に対して、自動的に売上の一部を分配するメカニズムを導入
オープンソース化したモデルでも、出力結果を正確にトラッキングし収益化

zkML AIGC NFT プロジェクトのワークフロー例

以下は、zkMLに準拠したAIGC-NFTプロジェクトのワークフローです。

ワークフロー図

https://eips.ethereum.org/EIPS/eip-7007

各コンポーネントの役割

コンポーネント	説明
ML Model	学習済みの重みを含むAIモデル。入力を受け取り、推論を行います。
zkML Prover	推論結果に基づき、ゼロ知識証明を生成します。
AIGC-NFT Smart Contract	この提案に準拠したスマートコントラクトで、ERC721機能を完全に備えています。
Verifier Smart Contract	推論タスクとZK証明を受け取り、その正当性を確認します。結果は真偽値で返されます。

このワークフローを通じて、ユーザーが入力したプロンプトに対してモデルがどのように推論を行い、その結果がどのように証明・検証され、最終的にNFTとして発行されるかが明確に定義されています。

仕様

実装要件

ERC7007に準拠するコントラクトは、以下のインターフェイスを必ず実装する必要があります。

必須インターフェイス	役割
IERC7007	AIGC データの追加・検証のためのコアインターフェイス。
ERC721	NFT の基本機能（発行、所有、転送など）を提供。
ERC165	コントラクトが対応しているインターフェイスの識別を可能にする。

IERC7007インターフェイス

IERC7007は、AIGCデータの登録と検証のための主要なインターフェイスです。
以下の機能を提供します。

AIGCデータをNFTに紐づけて追加する。
zkML / opML を用いて、prompt・aigcData・proof の整合性を検証する。

コード全体

pragma solidity ^0.8.18;

/**
 * @dev Required interface of an ERC7007 compliant contract.
 * Note: the ERC-165 identifier for this interface is 0x702c55a6.
 */
interface IERC7007 is IERC165, IERC721 {
    /**
     * @dev Emitted when `tokenId` token's AIGC data is added.
     */
    event AigcData(
        uint256 indexed tokenId,
        bytes indexed prompt,
        bytes indexed aigcData,
        bytes proof
    );

    /**
     * @dev Add AIGC data to token at `tokenId` given `prompt`, `aigcData`, and `proof`.
     */
    function addAigcData(
        uint256 tokenId,
        bytes calldata prompt,
        bytes calldata aigcData,
        bytes calldata proof
    ) external;

    /**
     * @dev Verify the `prompt`, `aigcData`, and `proof`.
     */
    function verify(
        bytes calldata prompt,
        bytes calldata aigcData,
        bytes calldata proof
    ) external view returns (bool success);
}

`AigcData`

event AigcData(
    uint256 indexed tokenId,
    bytes indexed prompt,
    bytes indexed aigcData,
    bytes proof
);

AIGCデータが追加された時に発行されるイベント。

AIGC-NFTに対して新たにAIGCデータを紐づけた時に、このイベントが発行されます。
これにより、どのトークンにどの生成データが登録されたかを外部から確認できます。

パラメータ

tokenId
- 対象となるトークンの識別子。
prompt
- AIGC 生成時に使用された入力プロンプトのデータ。
aigcData
- 実際の生成コンテンツ（画像・音声・動画など）をバイト形式で保持。
proof
- zkML または opML によって生成された検証用の証明データ。

`addAigcData`

function addAigcData(
    uint256 tokenId,
    bytes calldata prompt,
    bytes calldata aigcData,
    bytes calldata proof
) external;

AIGCデータをトークンに追加する関数。

指定した tokenId に対して、AIGC 生成データおよび対応する証明情報を紐づけます。
この関数は、主にモデル推論の結果をNFTとして登録するために使用されます。

引数

tokenId
- 対象となるNFTの識別子。
prompt
- 生成に使用された入力プロンプトのデータ。
aigcData
- 生成結果（AIGC ファイル）のデータ。
proof
- zkML または opML によって生成された証明データ。

`verify`

function verify(
    bytes calldata prompt,
    bytes calldata aigcData,
    bytes calldata proof
) external view returns (bool success);

AIGCデータの正当性を検証する関数。

与えられた prompt・aigcData・proof の組み合わせが正しいかどうかを確認します。
この検証はzkMLまたはopMLの方式に基づいて実行されます。

引数

prompt
- 生成時に使用されたプロンプトデータ。
aigcData
- AIGCコンテンツのデータ。
proof
- zkMLまたはopMLの証明データ。

戻り値

success
- 検証が成功した場合は true、失敗した場合は false。

Enumerable

Enumerable拡張は任意の機能で、コントラクトがトークンIDとプロンプトの対応関係を公開・取得できるようにします。

コード全体

pragma solidity ^0.8.18;

/**
 * @title ERC7007 Token Standard, optional enumeration extension
 * Note: the ERC-165 identifier for this interface is 0xfa1a557a.
 */
interface IERC7007Enumerable is IERC7007 {
    /**
     * @dev Returns the token ID given `prompt`.
     */
    function tokenId(bytes calldata prompt) external view returns (uint256);

    /**
     * @dev Returns the prompt given `tokenId`.
     */
    function prompt(uint256 tokenId) external view returns (string calldata);
}

`tokenId`

function tokenId(bytes calldata prompt) external view returns (uint256);

指定した prompt に対応する tokenId を取得する関数。

プロンプトデータをもとに、関連付けられたNFTの識別子を返します。
これにより、どのプロンプトから生成されたトークンかを特定できます。

引数

prompt
- プロンプトデータ。

戻り値

tokenId
- 対応する NFT の識別子。

`prompt`

function prompt(uint256 tokenId) external view returns (string calldata);

指定した tokenId に対応する prompt を取得する関数。

NFTとプロンプトの関係を逆引きするために使用します。

引数

tokenId
- 対象となるNFTの識別子。

戻り値

prompt
- トークンに紐づくプロンプト文字列。

Updatable

Updatable 拡張も任意の機能です。
この拡張を実装することで、opML シナリオにおいてチャレンジ期間中に aigcData を更新できるようになります。

コード全体

pragma solidity ^0.8.18;

/**
 * @title ERC7007 Token Standard, optional updatable extension
 * Note: the ERC-165 identifier for this interface is 0x3f37dce2.
 */
interface IERC7007Updatable is IERC7007 {
    /**
     * @dev Update the `aigcData` of `prompt`.
     */
    function update(
        bytes calldata prompt,
        bytes calldata aigcData
    ) external;

    /**
     * @dev Emitted when `tokenId` token is updated.
     */
    event Update(
        uint256 indexed tokenId,
        bytes indexed prompt,
        bytes indexed aigcData
    );
}

`update`

function update(
    bytes calldata prompt,
    bytes calldata aigcData
) external;

AIGCデータを更新する関数。

特定のプロンプトに紐づくAIGCデータを新しい内容に更新します。
主にopMLのチャレンジ期間終了後に正しい出力を反映させるために使用されます。

引数

prompt
- 対象となるプロンプトデータ。
aigcData
- 新しいAIGCデータ。

`Update`

event Update(
    uint256 indexed tokenId,
    bytes indexed prompt,
    bytes indexed aigcData
);

AIGCデータが更新された時に発行されるイベント。

既存のNFTに紐づくAIGCデータが新しい内容に置き換えられたことを通知します。

パラメータ

tokenId
- 更新対象となったトークンの識別子。
prompt
- 対応するプロンプトデータ。
aigcData
- 更新後のAIGCデータ。

メタデータJSONスキーマ

AIGC-NFTのメタデータは、以下のJSONスキーマに従います。

{
  "title": "AIGC Metadata",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Identifies the asset to which this NFT represents"
    },
    "description": {
      "type": "string",
      "description": "Describes the asset to which this NFT represents"
    },
    "image": {
      "type": "string",
      "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
    },
    "prompt": {
      "type": "string",
      "description": "Identifies the prompt from which this AIGC NFT generated"
    },
    "aigc_type": {
      "type": "string",
      "description": "image/video/audio..."
    },
    "aigc_data": {
      "type": "string",
      "description": "A URI pointing to a resource with mime type image/* representing the asset to which this AIGC NFT represents."
    },
    "proof_type": {
      "type": "string",
      "description": "validity (zkML) or fraud (opML)"
    }
  }
}

このスキーマにより、AIGC-NFTに関連する情報を統一的な形式で管理できます。
特に、どのプロンプトから生成されたか、どの種類のメディアか、どの検証方式（zkML / opML）を使用しているかが明確に示されます。

MLモデルの公開（Model Publication）

ERC7007では、モデルの公開方法自体は規定していません。
ただし、推奨として以下のような手順を取ることが望ましいとされています。

推論を実行する前に、学習済みモデルのコミットメント（ハッシュや署名）をEthereum上に登録する。
verify 関数の内部で、このコミットメントを参照してモデルの整合性を確認する。

これにより、どのモデルから生成されたかをブロックチェーン上で追跡・検証できるようになります。

補足

トークンの一意性

ERC7007では、各トークンの tokenId は、そのトークンが生成されたプロンプト（prompt）をハッシュ化した値として決定されます。
この設計は以下の理由に基づいています。

決定的な識別子（Deterministic ID）
プロンプトから常に同じハッシュ値が生成されるため、同じプロンプトは同じ tokenId を持ちます。
これにより、NFTの識別が明確になります。
衝突耐性（Collision Resistance）
ハッシュ化によって、異なるプロンプトが同じハッシュ値になる可能性が極めて低く、重複発行を防ぐことができます。
重複発行の防止
同じプロンプト（＝同じ入力）から同じモデルとシードで生成されるAIGCコンテンツは、1つのNFTとしてのみ発行可能になります。
これにより、同一のコンテンツが複数のNFTとしてミント（発行）されることを防ぎ、NFTの真正性と希少性を保証します。

この仕組みにより、AIGCエコシステム全体で各トークンのユニーク性（唯一性）が維持され、信頼性の高いトークン管理が実現します。

異なる証明方式への一般化

ERC7007は、AIモデルの出力が正しいことを証明するために2種類の証明方式をサポートしています。

証明タイプ	利用技術	目的	特徴
有効性証明（Validity Proof）	zkML（Zero-Knowledge Machine Learning）	生成結果の正当性を暗号的に証明	証明が完了すれば即時に確定可能
不正防止証明（Fraud Proof）	opML（Optimistic Machine Learning）	不正な出力を検出・修正可能にする	確定までにチャレンジ期間が必要

この設計では、addAigcData 関数や verify 関数の引数がどちらの方式にも対応できるように汎用的に定義されています。
さらに、opML 特有のチャレンジ期間に対応するためにUpdatable 拡張が導入されています。
この拡張により、チャレンジ後のデータ更新が可能になります。

このような構造により、zkMLのような即時検証型と、opMLのような楽観的検証型の両方に対応でき、プロジェクトのニーズに応じた柔軟な実装が可能です。

`verify` インターフェイスの設計意図

verify 関数は、AIGC データが正しいかどうかを確認するための検証インターフェイスです。
この関数は読み取り関数として定義されており、ガスコストを最小限に抑える設計になっています。

動作の概要

証明方式	検証内容	条件
zkML	ZK（ゼロ知識）証明の正当性を検証	`proof` が有効であること
opML	チャレンジ期間の終了と最新データの確認	`aigcData` が確定後に更新されていること

設計上のポイント

verify 関数はzkML / opML の両方に対応するように設計されています。
zkMLの場合、proof が与えられ、それが暗号的に正しい場合のみ true を返します。
opMLの場合、チャレンジ期間が終了し、aigcData が最新であれば true を返します。
opMLでは、proof が空でも問題ありません。
これは、証明が存在しない場合でも、時間経過とチャレンジ処理によって正当性が保証されるためです。

このように、verify は最終的にAIGCデータが確定状態（finalized）であるかどうかを判定する関数です。

`addAigcData` インターフェイスの設計意図

addAigcData 関数は、AIGCデータをプロンプトとトークンに紐づけるためのインターフェイスです。
この関数は、ミント処理（NFT 発行）とデータ登録の中核を担います。

設計の柔軟性

この関数は、zkMLとopMLの両方式に対応できるように柔軟に設計されています。

証明方式	関数の挙動	検証条件
zkML	証明が完了した後に呼び出す	`verify` が `true` を返す必要あり
opML	チャレンジ期間前でも呼び出し可能	後に更新（`update`）で確定可能

zkMLでは証明生成に時間がかかるものの、推論タスクが小規模であることが多く、リアルタイムに検証・登録が可能です。
一方、opMLは大規模モデルの推論に対応でき、チャレンジ期間後にデータを更新することで最終的な正当性を担保します。

設計の背景

zkMLは小さなタスク向け（計算コストが許容範囲）に、opMLは大きなタスク向け（計算を楽観的に処理）に適しています。
そのため、addAigcData の呼び出しタイミングを分けることで、どちらの方式でも適切な運用が可能となります。

`update` の命名に関する選択

ERC7007では、データ確定の処理において finalize ではなく update という名前を採用しています。
これは、実際の運用上の頻度や効率性を考慮した結果です。

採用理由

チャレンジ成功はまれ
opMLのチャレンジ機構は例外的にしか発動しません。
したがって、毎回「finalize」と呼ぶのは実態にそぐわないため、更新を意味する「update」がより自然です。
ガスコストの削減
すべてのトークンで定期的に finalize を呼ぶ設計では、ガスコストが無駄に発生します。
実際に変更が必要なときのみ呼び出す update の方が、効率的でコストを抑えられます。

互換性

ERC7007はERC721を拡張する形で設計されています。
つまり、NFTの基本機能（所有・転送・メタデータ参照など）はERC721のルールに従ってそのまま動作し、その上にAIGC固有の機能（AIGC データの追加や検証）が追加されます。
すでにERC721に対応している周辺ツールやワークフローと整合が取れるため、導入時の影響を最小化できます。

観点	説明
継承関係	ERC721の機能に、AIGC追加・検証用のインターフェイスを加えています。
互換性の方向	ERC721に準拠した動作は維持され、AIGC向けの操作だけが拡張されます。
利点	既存の資産管理やビューアなどの仕組みをそのまま使いながら、AIGCの検証可能性を取り込めます。

参考実装

参考実装には、以下の内容が含まれます。

コンポーネント	説明
ERC-7007 for zkML and opML	ゼロ知識系（zkML）とオプティミスティック系（opML）の両方式に対応したERC7007の実装が含まれます。
ERC-7007 Enumerable Extension	トークン ID とプロンプトの対応を列挙できる拡張（Enumerable 拡張）の実装が含まれます。

これらの参考実装は、AIGCデータの追加・検証に関する最小限の実装例として扱えます。

セキュリティ

フロントランニングのリスク

フロントランニング（他者の取引を観測して、その内容を先回りで自分の取引として送る行為）とは、ブロックチェーンの公開メモリプールを監視して取引内容を盗み見し、より高い手数料で先に同内容の取引を実行してしまう攻撃です。
ここでは、ユーザーがプロンプト（生成指示）を使ってミントしようとしたときに、第三者がそれを先取りして権利を主張してしまう危険を指します。

要求事項

実装者は、安全なプロンプト取得フローを必ず組み込む必要があります。
公平で安全な取得手続きを実現するために、以下のようなフロントランニング耐性のある仕組みを使います。

手法	概要	ねらい
タイムロック（一定時間の待機）	ある操作の成立を、設定した時間が経過するまで有効化しない方式。	先回りで取り消せない即時成立を防ぎ、正当な申請者に手続きを完了する余地を与えます。
コミット・リビール（Commit–Reveal）	まずハッシュだけを提出して内容を隠し（コミット）、後で元データを公開して整合を確認する方式。	取引内容を公開前に奪われることを防ぎます
その他のアンチフロントランニング技術	上記以外の同目的の技術全般。	公平なプロンプト取得プロセスを守ります。

手順例：コミット・リビールの流れ

ユーザーは、プロンプトを直接出さずにハッシュ値（コミットメント）だけを送信します。
ブロックに取り込まれた後、指定された公開フェーズでプロンプトの元データを開示します。
コントラクトがハッシュとの一致を検証し、一致すれば取得が成立します。

この流れにより、公開前に第三者が内容を盗み見て先行申請することを防ぎます。

チャレンジ期間中のAIGCデータ変更（opML）

チャレンジ期間
opML（オプティミスティック機械学習）の前提で設ける、生成結果に異議が出せる時間帯のことです。
Updatable拡張
チャレンジの結果や更新が必要になった場合に、aigcData（AI 生成コンテンツのデータ）を更新できるようにするERC7007の任意拡張です。

要求事項

opMLのシナリオでは、チャレンジ期間中に aigcData が変更される可能性があります。
実装では、aigcData の更新をクリティカルな状態変更として扱い、初回ミント時と同じレベルのセキュリティと検証手続きを適用しなければなりません。
また、インデクサ（ブロックチェーンのイベントを読み取って外部検索・表示を行う仕組み）は、Update イベントの発行を常に確認する必要があります。
これにより、最終的に確定したデータのみを表示・参照できます。

手順例：更新時の確認フロー

チャレンジ期間の終了、または必要な更新の条件を満たしたことを確認します。
Updatable 拡張を用いて aigcData を更新します。
更新に伴い Update イベントが発行されることを確認します。
インデクサは Update を取り込み、最新の aigcData を参照対象として反映します。

引用

Cathie So (@socathie), Xiaohang Yu (@xhyumiracle), Conway (@0x1cc), Lee Ting Ting (@tina1998612), Kartin kartin@hyperoracle.io, "ERC-7007: Verifiable AI-Generated Content Token," Ethereum Improvement Proposals, no. 7007, May 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7007.

最後に

今回は「AIが生成したコンテンツをNFTとして発行し、その生成過程をブロックチェーン上で暗号的に検証できる仕組みを提案しているERC7007」についてまとめてきました！
いかがだったでしょうか？

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

Twitter @cardene777

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

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

[ERC7007] AI生成コンテンツをNFTにして検証できる仕組みを理解しよう！

はじめに

概要

動機

背景と目的

証明の種類と対応技術

zkML シナリオの動作

opML シナリオの動作

標準の意義と活用可能性

zkML AIGC NFT プロジェクトのワークフロー例

ワークフロー図

各コンポーネントの役割

仕様

実装要件

IERC7007インターフェイス

コード全体

AigcData

addAigcData

verify

Enumerable

コード全体

tokenId

prompt

Updatable

コード全体

update

Update

メタデータJSONスキーマ

MLモデルの公開（Model Publication）

補足

トークンの一意性

異なる証明方式への一般化

verify インターフェイスの設計意図

動作の概要

設計上のポイント

addAigcData インターフェイスの設計意図

設計の柔軟性

設計の背景

update の命名に関する選択

採用理由

互換性

参考実装

セキュリティ

フロントランニングのリスク

要求事項

手順例：コミット・リビールの流れ

チャレンジ期間中のAIGCデータ変更（opML）

要求事項

手順例：更新時の確認フロー

引用

最後に

`AigcData`

`addAigcData`

`verify`

`tokenId`

`prompt`

`update`

`Update`

`verify` インターフェイスの設計意図

`addAigcData` インターフェイスの設計意図

`update` の命名に関する選択