ERC-8128を読み解く──ERC-8004の先にある通信認証の設計
2026年02月12日
この記事を簡単にまとめると（AI要約）
目次
- ERC-8128とは何か
- 技術的な立ち位置
- セキュリティ強度を誰が決めるのか
- なぜAIエージェント文脈で意味を持つのか
- ただし、魔法ではない
- 総括：実装が始まった「エージェント認証」という問い
ERC-8004がメインネットで利用できる状態になりました。
この標準は、AIエージェントを「説明できて、検証もできる経済主体」として扱うための仕様です。かんたんに言えば、AIエージェントにきちんとした“身元”を与え、その活動履歴や評判を積み上げられるようにする仕組みです。
ERC-8004が目指しているのは、たとえば次のようなことです。
- エージェントに固有のIDを持たせる
- 過去の実績や評価を記録できるようにする
- その実績を他のサービスでも参照できるようにする
- 仕事・評価・支払いを同じレイヤーで結びつける
- プロトコル側でエージェントの信頼性を自動チェックできるようにする
つまり、エージェントを「ブラックボックスのプログラム」ではなく、「履歴と責任を持つ経済主体」として扱うための土台です。
ERC-8004については、過去の記事でも詳しく整理しています。背景や設計思想を深掘りしたい方は、そちらをご参照ください。本稿では繰り返しません。
その流れの中で、もう一つの標準案も語られています。Sliceが提案しているERC-8128です。彼らはこれを「Ethereum Identity for the Web」と呼んでいます。
こちらはERC-8004ほど広く議論されているわけではなく、ややニッチな提案です。ただし、問題意識はつながっています。
関係を整理すると、こうなります。
- ERC-8004：エージェントそのものの「ID・評判・検証」の標準
- ERC-8128：エージェントがWebやAPIとやり取りする際の「認証」の標準
たとえるなら、ERC-8004がエージェントの“身分証や履歴書”を整える標準だとすれば、ERC-8128はその身分証を使ってAPIにアクセスするときの“提示方法”を定める標準です。
ERC-8128が今後どこまで普及するかはまだ未知数です。ただ、エージェントが外部サービスを呼び出す世界が広がれば広がるほど、次の問題は避けられません。
- APIキーをどう安全に管理するか
- トークン漏洩をどう防ぐか
- サーバ間通信をどう信頼するか
ERC-8128は、まさにこの「通信レイヤーの認証」をEthereumアカウントベースで再設計しようとする試みです。
本稿では、ERC-8004の文脈を踏まえつつ、少しニッチではありますが、このERC-8128が何を目指しているのかを解説していきます。
※免責事項：本レポートは、いかなる種類の法的または財政的な助言とみなされるものではありません。
