はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、AIエージェントをNFTとして作成・管理・売買できる仕組みを提案しているERC7662についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
AIエージェントをNFTとして扱うためには、従来のNFT設計では不十分な点があります。 ERC7662は、その課題を解決するためにAIエージェント専用のNFT標準を定義しています。
なぜ通常のNFTメタデータでは足りないのか
一般的なNFTでは、画像URLや説明文などを「トークンメタデータ」としてJSON形式で保持します。 しかし、AIエージェントの場合、以下のような情報を扱う必要があります。
- AIエージェントの振る舞いを決めるプロンプト
- システム指示や制約条件
- モデルの使い方に関する設定情報
ここでいうプロンプトとは、AIに対して「どのように振る舞うか」、「何を目的とするか」を指示するテキストのことです。 これらは単なる説明文ではなく、AIエージェントそのものの価値を決める重要なデータです。
このようなデータを通常のNFTメタデータにそのまま含めるのは適切ではありません。 理由は主に2つあります。
1つ目は、プロンプトが長くなりがちで、NFTメタデータとして扱うにはサイズが大きいことです。 2つ目は、プロンプト自体が知的財産であり、誰でも読める状態にすべきではない場合が多いことです。
カスタム構造体によるデータ定義
ERC7662では、AIエージェントNFTに必要な情報をカスタム構造体（custom struct）として定義します。 カスタム構造体とは、スマートコントラクト内で独自に定義するデータのまとまりです。
これにより、以下が可能になります。
- AIエージェントに必要な情報の形式を標準化できる
- マーケットプレイスや管理ツールが共通の形式でデータを読み書きできる
オンチェーンに保存しない理由と分散ストレージ
ERC7662では、プロンプトなどの実データを直接オンチェーンには保存しません。
オンチェーンとは、Ethereumなどのブロックチェーン上に直接データを書き込むことです。 オンチェーン保存は透明性が高い一方で、以下の問題があります。
- ガスコストが非常に高い
- 大きなデータには向いていない
- 基本的に誰でも内容を閲覧できる
そのため、ERC7662ではプロンプトなどのデータを分散ストレージのURLとして扱います。 分散ストレージとは、IPFSなどの中央管理者を持たないストレージネットワークです。
NFTには「どこにデータがあるか」というURLのみを保持し、実体データは分散ストレージ側に置く設計です。
NFT所有者のみが読めるようにする仕組み
AIエージェントのプロンプトは、NFTの価値そのものです。 そのため、ERC7662ではNFTの所有者だけが内容を読める仕組みを前提としています。
ERC7662では、データを非公開にする方法として2つの選択肢を示しています。
- 1つ目は、所有者のみが復号できる形でデータを暗号化する方法
- 2つ目は、別の手段によるアクセス制御を行う方法
この中で、推奨されているのはスマートコントラクト固有のパラメータを使って暗号化し、NFT所有者だけが復号できる方式です。
暗号化とは、第三者には意味の分からない形にデータを変換することです。 復号とは、それを元の内容に戻すことです。
この仕組みにより、NFTを持っている人だけがAIエージェントの中身を利用できる状態を実現します。
動機
AIエージェントとNFTの相性
AIエージェントは「作成され」、「利用され」、「価値が評価される」存在です。 この特徴はNFTと非常に相性が良いです。
NFTは以下を得意とします。
- 所有権を明確にする
- 売買や譲渡を可能にする
- 希少性や価値を表現できる
AIエージェントをNFTとして扱うことで、「AIエージェントそのものを売買する市場」をオンチェーンで実現できます。
標準化が必要な理由
AIエージェントNFTを実際に流通させるためには、単にNFTを発行するだけでは不十分です。
以下のようなプロダクトが同じ形式を理解できる必要があります。
- NFTマーケットプレイス
- AIエージェント管理ツール
- ノーコードAI構築サービス
- インフラプロバイダ
そのため、AIエージェントNFTに含まれるデータ構造を標準化する必要があります。
標準化とは、「この形式で書かれていれば、誰でも同じように解釈できる」という共通ルールを作ることです。
ERC7662は、AIエージェントNFTに必要なカスタム構造体を定義し、 どのプロダクトでも同じ方法で作成・解析できる状態を目指しています。
新しいNFTの用途と流動性の創出
ERC7662の目的は、単に技術的に正しいNFTを作ることではありません。
- AI分野におけるNFTの新しい使い道を提供すること
- AIエージェントに対してNFT市場という流動性を与えること
流動性とは、「売りたいときに売れて、買いたいときに買える状態」のことです。
ERC7662が広く採用されることで、以下のようなエコシステムが期待されています。
- 専門分野ごとのAIエージェントを作るクリエイター
- AIエージェントを購入・利用するユーザー
- AIエージェントNFTを扱うマーケットプレイス
これにより、AIエージェントが単なるツールではなく、オンチェーンで価値が流通する資産として扱われる世界を実現しようとしています。
仕様
ERC721互換とAgentインターフェースの実装要件
ERC7662に準拠するコントラクトは、まずERC721として通常どおりNFTをmint（発行）・transfer（移転）できる必要があります。 そのうえで、追加でAgentインターフェースを実装しなければなりません。
ERC721については以下の記事を参考にしてください。
ここでいうインターフェースは、外部から呼べる関数の形（シグネチャ）とイベントの型を固定するための約束です。
仕様で定義されているインターフェースは以下です。
interface IERC7662 is IERC721 {
function getAgentData(uint256 tokenId) external view returns (
string memory name,
string memory description,
string memory model,
string memory userPromptURI,
string memory systemPromptURI,
bool promptsEncrypted
);
event AgentUpdated(uint256 indexed tokenId);
}getAgentData が返す内容
nameエージェント名。descriptionエージェントの説明。- model 利用するモデル識別子（例: gpt-4-0125-preview のような文字列）。
- userPromptURI ユーザープロンプトの保存先URL。
- systemPromptURI システムプロンプトの保存先URL。
- promptsEncrypted プロンプトが暗号化済みかどうかのフラグ。
ここでいうユーザープロンプトは「個別の依頼や目的など、ユーザー側の入力として扱うプロンプト」です。 システムプロンプトは「AIエージェントの基本方針・制約など、土台になる指示」です。
Token IDとAgent情報のマッピング
ERC7662は、NFTのToken ID（tokenId）と、そのNFTに対応するAgent情報を結びつけるマッピングを必須にしています。
マッピングとは、Solidityでいう mapping(tokenId => AgentStruct) のように、キーから値を引けるデータ構造です。
ここが標準化されることで、マーケットプレイスや管理ツールが「この tokenId のAIエージェント情報を読みに行く」動きを共通化できます。
マッピングを公開し、URIは暗号化で保護するのが推奨
ERC7662は、Token IDとAgent情報のマッピングについて、公開（public）にすることを推奨しています。 ただし、ユーザープロンプトURIとシステムプロンプトURIは、所有者以外に読まれないように暗号化するのが推奨です。
ここは設計の意図がはっきりしていて、「マッピングを隠す」より「URI（およびその参照先）を暗号化する」方向を強く推しています。
推奨されているプライバシー設計の考え方
- マッピングは公開のままにして、Agentの基本情報（
name/description/model）が誰でも検証できるようにします。 - 一方で、プロンプト本体にアクセスできるURIは暗号化して、NFT所有者だけが復号できるようにします。
その暗号化においては、暗号化時に設定するコントラクト固有のパラメータを使い、復号が「そのNFTの保有者にだけ成立する」ような復号ロジックにします。
また、暗号化を提供する方式やプラットフォーム（例: どの仕組みで暗号化したのか）は、NFTのデータプロパティとして取得できるようにすることが推奨されています。 これにより、取り扱う側（マーケットプレイスやエージェント実行基盤など）が、方式ごとに予測可能な復号処理を組めます。
マッピングをprivateにして保護する案もあるが推奨しない理由
ERC7662は別案として、マッピング自体を private にして、カスタム関数で「NFT保有者だけアクセス可能」にする実装もあり得ると言っています。
ただしこの方式には問題があります。
マッピングを private にしても、結局プロンプトはURLとしてどこかに存在するため、そのURLが露出した時点で参照されるリスクが残ります。
そのため、以下が推奨されています。
- マッピングは公開
- URI（および参照先データ）は暗号化
さらにこの方式は、公開情報として次の点を検証できる利点もあります。
- Agentの
name/description/modelを第三者が確認できる - User Prompt / System Prompt のURIが「暗号化された形で存在する」ことを確認できる
新しいAgentトークンをmintする関数の必須要件
ERC7662に準拠したコントラクトは、新しいAgentトークンを mint する関数を必ず実装する必要があります。
このmint関数は以下の振る舞いを持つべきとされています。
| 要件 | 内容 |
|---|---|
| Agentプロパティを受け取る | name, description, model, userPromptURI, systemPromptURI などを引数で受け取ります |
指定した recipient に mint する |
mint 先アドレスを引数で指定できる想定です |
tokenId にAgentプロパティを紐づける |
mint した tokenId に対してAgent情報を保存します |
| 作成イベントをemitする | 新規Agent作成を示すイベントを発行します |
プロンプト暗号化機能の推奨要件
ERC7662は、ユーザープロンプトとシステムプロンプトを暗号化する機能を、コントラクト側に持たせることを推奨しています。
この暗号化機能は以下の振る舞いを持つべきです。
| 要件 | 内容 |
|---|---|
| token ownerだけが暗号化できる | 所有者以外が勝手に暗号化・差し替えできないようにします |
userPromptURI / systemPromptURI を暗号化版に更新する |
平文URIを暗号化されたURI（もしくは暗号化された参照情報）に置き換えます |
| 暗号化フラグを立てる | promptsEncrypted = true のように状態を更新します |
ここでいう「暗号化版URI」は、文字どおりURL文字列が暗号化されている場合もあれば、復号に必要な情報を含む参照子になっている場合もあり得ますが、ERC7662が言っているのは「URIとして保持する値が暗号化されたものになる」という点です。
AgentCreatedイベントの推奨
ERC7662は、以下のイベントを実装することが推奨されています。
event AgentCreated(string name, string description, string model, address recipient, uint256 tokenId)このイベントは新しいAgentトークンが mint されたときにemitするべきです。
イベントには「新規作成されたAgentの主要情報」が入るため、外部サービスが一覧化したり、マーケットプレイスが取り込みやすくなります。
ユーザープロンプトへの動的変数注入ルール
ERC7662は、ユーザープロンプトを実行する前に、外部システムが動的変数を差し込めるようにする設計も想定しています。 この動的変数は、必ず以下の形式で囲む必要があります。
{dynamicVariableName}
たとえば {userName} のように書くことで、Webフォームや自動化システムが「ここは差し替え可能な変数」と認識できます。
ここでいう動的変数注入は、プロンプトのテンプレート中のプレースホルダを、実行時の値で置換することです。
マーケットプレイス表示のためのERC-721拡張データの推奨
ERC7662は、NFTマーケットプレイスがAIエージェントNFTを表示しやすいように、ERC721標準に「追加データ」を持たせることを推奨しています。
特に重要なのがModelです。 Modelが分かると、そのエージェントがどのプラットフォームのモデルを使うのかが推測できます。
例として以下が挙げられています。
gpt-4-0125-previewなら OpenAIclaude-3-opus-20240229なら Anthropic
また、Agent NameとAgent Descriptionは、ERC721の標準的な name / description を使って表示できるとしています。
補足
AI Agent NFTを統一的に扱うための標準化
ERC7662は、AIエージェントをNFTとして作成・解析するための共通ルールを提供します。 ここで重要なのは「作る側」だけでなく、「読む側」も同じ前提で扱える点です。
ERC7662に準拠していれば、以下が保証されます。
- AI Agent NFTにどの情報が含まれているかが明確
- どの関数を呼べばAgent情報を取得できるかが共通
- マーケットプレイスやツールが独自解釈をしなくて済む
これにより、AI Agent NFTを扱うエコシステム全体での相互運用性が成立します。
AI Agent NFTに必須となるパラメータの明確化
ERC7662は、AI Agent NFTを作成・利用するために必要な情報を明確に定義しています。
Agentとして必須とされるのは以下です。
| 項目 | 意味 |
|---|---|
| Name | AIエージェントの名前 |
| Description | 何をするエージェントかの説明 |
| Model | 利用するAIモデルの識別子 |
| User Prompt | 実行時にユーザー側から与えるプロンプト |
| System Prompt | エージェントの基本方針となるプロンプト |
これらを「何となくメタデータに入れる」のではなく、Agent構造体として明示的に定義する点がERC7662の重要な特徴です。
既存ERC721メタデータにプロンプトを置かない理由
通常のERC721では、追加情報はトークンメタデータ（tokenURIが指すJSON）に入れます。 しかし、AIエージェントのプロンプトをここに置くのは現実的ではありません。
理由は明確です。
- トークンメタデータは誰でもアクセスできる
- NFTを所有していなくてもプロンプトを読めてしまう
- プロンプト自体がAIエージェントの価値であり、知的資産にあたる
ERC7662は、この問題を「Agent構造体」と「アクセス制御」で解決します。
なぜ「構造体をprivateにする」だけでは不十分なのか
一見すると、Agent構造体を private にして、「NFT保有者だけが呼べる関数で取得する」設計も考えられます。
しかし、この方法には根本的な問題があります。
- 構造体内にはプロンプトのURIが含まれる
- URIがどこかで露出すれば、その先のデータは誰でも取得できる
- 結果として、プロンプト内容が保護されない
このため、ERC7662はアクセス制御ではなく暗号化を推奨しています。
推奨される解決策：オンチェーン暗号化と所有者連動の復号
ERC7662が推奨する方法は以下です。
- プロンプトは暗号化された状態で保存する
- 暗号化されたデータのURLをAgent構造体に持たせる
- 復号条件を
ownerOf(tokenId)に紐づける
ここでいうオンチェーンサービスとは、EVMのコントラクトパラメータを条件にして「復号できるかどうか」を判定できる仕組みです。
これにより、以下の状態を作れます。
- NFTを持っていない人は復号できない
- NFTを譲渡すると、新しい所有者が復号できる
- プロンプトの価値がNFT所有権と完全に結びつく
互換性
ERC721との完全互換を前提にした拡張
ERC7662は、ERC721を置き換えるものではありません。 ERC721に機能を追加する「拡張標準」として設計されています。
そのため、以下の点が保証されています。
- ERC721の既存関数は一切変更されない
- 関数シグネチャも挙動もそのまま
- ERC721対応ウォレットやサービスは、そのまま扱える
既存ERC721機能がそのまま使える理由
ERC7662に準拠したNFTでも、以下のような関数は通常どおり動作します。
| 関数 | 内容 |
|---|---|
transferFrom |
NFTの転送 |
approve |
承認設定 |
balanceOf |
保有数の取得 |
ERC7662で追加されるのは Agent関連の情報と関数だけ です。 ERC721のコアロジックには一切手を入れないため、既存のインフラを壊しません。
ウォレット・サービス側の対応について
ERC7662に対応していないウォレットやサービスでも、
- NFTとしての表示
- 転送や売買
- 所有権の管理
は問題なく行えます。
ERC7662対応の機能（Agent情報の表示や実行など）は、対応したマーケットプレイスやDAppが追加で活用する形になります。
参考実装
実際のプロダクトでの実装状況
ERC7662は、すでにオンチェーンでAIエージェントを作成・管理・利用するDAppの中で実装が進められています。
この実装では、以下を組み合わせています。
- AI Agent NFTを作成・管理するDApp
- プロンプトを暗号化する暗号化プラットフォーム
- 分散ストレージネットワーク（暗号化データの保存先）
プロンプト暗号化の具体的な流れ
この実装では、プロンプトをカスタムEVMContractParametersを使って暗号化しています。
これは、「どの条件を満たしたときに復号できるか」をスマートコントラクトのパラメータで指定できる仕組みです。
条件として使われるのが、NFTの所有者です。
ownerOf(tokenId)が復号条件になる- NFTを持つアドレスだけが復号できる
なぜmint後に暗号化を行うのか
参考実装では、NFTをmintしたあとに暗号化プロンプトを追加します。 理由は単純です。
tokenIdはmint後でないと確定しない- 暗号化・復号条件に
tokenIdを使う必要がある
そのため、以下の流れになります。
- Agent NFTをmintする
- tokenIdが確定する
- tokenIdを条件に含めてプロンプトを暗号化する
- 暗号化されたURIをAgent構造体に設定する
addEncryptedPrompts 関数の役割
この流れを実現するために、参考実装では addEncryptedPrompts 関数が追加されています。
この関数は以下の役割を持ちます。
- mint後に呼び出すことを前提
- 暗号化済みの
userPromptURI/systemPromptURIを設定 - Agent構造体の追加パラメータも同時に更新
これにより、DApp側は「mint → 暗号化 → 登録」という一連の操作を安全に行えます。
参考スマートコントラクトについて
ERC7662の参考実装となるスマートコントラクトは、assets フォルダに用意されています。
このコントラクトは、概念実装ではなく実用前提の実装例になっています。
- ERC721として正しく動作する
- ERC7662のAgentインターフェースを実装している
- 実際のDApp利用を前提とした設計になっている
引用
Greg Marlin (@marleymarl), "ERC-7662: AI Agent NFTs [DRAFT]," Ethereum Improvement Proposals, no. 7662, March 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7662.
最後に
今回は「AIエージェントをNFTとして作成・管理・売買できる仕組みを提案しているERC7662」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
