詳解ERC-8183：イーサリアム攻防AIエージェントの信頼問題の解答

執筆：Azuma、Odaily

3月10日、イーサリアム財団傘下の「人工知能（AI）とブロックチェーンの深度統合推進」に特化したdAIチームとVirtuals Protocolは、新しい標準ERC-8183を共同発表しました。

イーサリアム財団のAI責任者Davide Crapisは、この標準について、「ERC-8183はイーサリアムコミュニティが構築中のオープンなエージェント経済システムに欠かせない要素の一つです。この標準はx402やERC-8004と組み合わせて使用でき、エージェント間の安全なインタラクションのためのインフラとして機能します」と述べています。dAIチームはERC-8183の採用を支援し、中立的な標準となることを目指しています。

ERC-8183は何を解決しようとしているのか？

Virtuals Protocolが公開した紹介記事によると、ERC-8183はAIエージェント間の商取引を目的として設計されており、ブロックチェーン上のルールセットを定義しています。これにより、信頼できない二つのエージェントが「雇用 - 交付 - 決済」といった商取引の流れを、中央集権的なプラットフォームに依存せずに完結できる仕組みを実現します。

ERC-8183が解決しようとする核心的な問題は、エージェント同士が雇用・協力する際に、プラットフォームや法律、人間の仲裁を介さずに取引を完了させるにはどうすればよいかです。

例を挙げると、市場促進を重視するエージェントAが、画像生成に特化したエージェントBを雇い、マーケティング用のポスターを作成させたい場合、信頼の問題が生じます。双方は互いに知らず、信頼関係もないため、いつ支払いを行うべきかが問題です。Aが先に支払えば、Bがストライキを起こしたり、不合格の成果物を返す可能性があります。逆にBが先に作業を行えば、Aが報酬を支払わないリスクもあります。

従来のインターネット世界では、ユーザーと商家も同様の信頼問題に直面し、プラットフォームが中介役を担ってきました。プラットフォームはAの資金を預かり、Bのサービス完了を判断し、最終的に支払いを行います。私たちが馴染みのある淘宝（タオバオ）、京東（JD.com）、美団（Meituan）、滴滴（Didi）は、いずれもこのようなプラットフォーム型の仲介です。

イーサリアム財団とVirtuals Protocolが目指すのは、ERC-8183を通じてプラットフォームの役割を抽象化し、スマートコントラクトによって実行させることで、エージェント経済における分散型の仲介役を担わせることです。

ERC-8183の仕組み解説

ERC-8183の動作はそれほど複雑ではありません。この標準は「Job（タスク）」という新たな概念を導入しています。各Jobは一つの完結した商取引とみなせ、以下の三つの役割を含みます。

• Client（クライアント）：タスクを発注するエージェント
• Provider（提供者）：タスクを実行するエージェント
• Evaluator（評価者）：最も重要な役割で、タスクの完了を判断する役割

この中で特に注目すべきはEvaluatorです。ERC-8183の最も核心的な設計要素であり、標準ではEvaluatorは単なるブロックチェーン上のアドレス（address）として定義されています。しかし、より広義には、その背後にさまざまな実行形態が存在します。

• 主観的な作業（執筆、デザイン、分析など）の場合、EvaluatorはAIエージェントであり、提出された結果を読み取り、最初の要求と比較し、判断します。
• 計算、証明生成、データ変換などの決定性の高い作業では、ZK検証器（Zero-Knowledge verifier）を搭載したスマートコントラクトがEvaluatorとなることもあります。Providerが証明を提出し、Evaluatorがオンチェーンで検証し、「complete」または「reject」を自動的に呼び出して、タスクの完了または拒否を行います。
• 高価値または高リスクのタスクでは、Evaluatorはマルチシグアカウント、DAO、またはステーキングメカニズムに支えられた検証クラスターとなることもあります。

ERC-8183はこれらの異なる形態を区別しません。プロトコル層はただ一つ、「complete」または「reject」を呼び出すアドレスがどのようなものであれ気にしません。LLM駆動のAIエージェントであれ、ZK回路であれ、関係ありません。

続いてJobのライフサイクルについて説明します。各Jobは以下の四つの状態を持ち、それに伴う異なるフローを示します。

• Open（オープン）：クライアントがJobを作成し、タスクを公開し、明確に要求を示す段階
• Funded（資金調達済み）：クライアントが報酬をスマートコントラクトの預かりアドレスに送金する段階
• Submitted（提出済み）：Providerが作業を完了し、証明を提出した段階
• Terminal（最終段階：Completed / Rejected / Expired）：Evaluatorがタスクを審査し、結果に基づき完了（Completed）または拒否（Rejected）と判断し、資金をクライアントまたはProviderに振り分けます。時間内にProviderからの応答や完了がなければ、資金は返還されます。

これらの標準的なフローに加え、ERC-8183はモジュール化された拡張機能「Hooks」を備えており、より複雑な商用ケースに対応可能です。HooksはJob作成時に付加されるオプションのスマートコントラクトで、信用閾値、入札メカニズム、費用配分、その他の特殊な要件など、Jobの各ライフサイクルの前後にカスタムロジックを実行できます。

ERC-8183とx402、ERC-8004の違いは何か？

x402からERC-8004、そして今回のERC-8183へと進化してきましたが、馴染みのない読者は「なぜ次々に新しい規格が出てくるのか」と疑問に思うかもしれません。実際には、これらはAIエージェント経済システムの異なる段階に対応しており、解決すべき課題も異なります。

x402はHTTP支払いプロトコルで、「AIエージェントがAPI呼び出しのように直接支払いできる」ことを目指しています。ERC-8004はAIエージェントの身分と信用標準で、「信頼できるエージェントかどうか」を判断するためのものです。ERC-8183は商取引の段階に焦点を当て、「信頼できないエージェント同士が取引を完結させる」ための仕組みを提供します。

要約すると、x402は「どうやって支払うか」問題を解決し、ERC-8004は「相手が誰で、信頼できるか」を知るためのもので、ERC-8183は「安心して取引を行うにはどうすればいいか」を扱います。

これら三つは競合関係ではなく、補完関係にあります。共通の目標は、「分散型で自律的に動作するAIエージェント経済システム」の構築です。