AIエージェント経済インフラ：リサーチ入門（パート1）
AIエージェント経済インフラ：リサーチ入門（パート1）
出典：OKX Ventures。この記事は、OKX Venturesの深掘りリサーチレポートを基にしています。長文のため、2部構成で公開します。パート1はマクロ経済の文脈、x402プロトコル、ERC-8004、Virtuals Protocolに焦点を当てます。パート2では、OpenClawとより広範な業界トレンドについて掘り下げます。乞うご期待ください。
エグゼクティブサマリー
AIエージェントは、受動的なコパイロットから能動的な経済参加者へと急速に進化しています。サービスを発見し、条件を交渉し、トランザクションをトリガーし、そして（ますます）オンチェーンでの価値決済を行っています。重要な変化は「AIが賢くなる」ことではなく、「AIが報酬を得て、支払えるようになる」ことです。これにより、ソフトウェアは市場の主体となり得ます。
OKX Venturesはこれを、マシンツーマシン（M2M）決済ネットワークとエージェント経済インフラスタックの出現と捉えており、アイデンティティ、信頼、決済、エージェントマーケットプレイスがコンポーザブル（組み合わせ可能）なプリミティブ（基本要素）となります。2026年の展望では、複数の標準や業界パイロットと並行して、エージェント型決済が初期のブレークアウト段階に入ると強調しています。（okxventures.medium.com）
パート1では、ビルダー（開発者）の会話でますます目にするようになる3つの基盤となる要素に焦点を当てます。
- x402：リクエストごとの暗号決済を、長らく保留されていた
402 Payment Requiredステータスコードで復活させるHTTPネイティブな決済ハンドシェイク。 - ERC-8004：トラストレスなエージェント発見 + 評判 + 検証のためのイーサリアム標準提案。
- Virtuals Protocol：エージェントをトークン化された経済主体とみなし、ACPを通じてエージェント間の商取引を標準化するオンチェーンエコシステム。
1) マクロ経済の背景：なぜエージェント経済にはクリプトレールが必要なのか
1.1 エージェントは「APIネイティブビジネス」になりつつある
Web2では、ソフトウェアは通常、アカウント、サブスクリプション、APIキー、請求書、チャージバックを通じて収益化されます。エージェントはこれらの前提を覆します。
- エージェントは、タスクの途中で「サインアップ」したくありません。
- エージェントは、人間に設計されたKYC/アイデンティティチェックを確実に通過できません。
- エージェントは、タイトなループ（データ取得 → 推論実行 → アクション実行 → 結果検証）で動作するため、月額請求よりもリクエストごとの決済の方が自然な場合が多いです。
だからこそ、ステーブルコインのマイクロペイメント、オンチェーン決済の最終確定性、そしてプログラム可能な認証が、特に多くのサービスを連鎖させるAI駆動ワークフローにおいて、再び重要性を増しているのです。
1.2 標準化の収束：ツール、アイデンティティ、信頼、決済
現代のエージェントスタックは、レイヤーごとに標準化されつつあります。
- ツール接続性（エージェントが外部サービスを呼び出す方法）— 例：Model Context Protocol (MCP)
- エージェント間通信（エージェントがメッセージをやり取りし、調整する方法）— 例：Agent2Agent (A2A)
- アイデンティティと識別子（集中型ディレクトリなしでエンティティを解決する方法）— 例：W3C Decentralized Identifiers (DIDs)（w3.org）
- 決済＋決済（価値がどのように移動するか）— x402のようなプロトコルが、決済をHTTPフローのネイティブな一部にすることを目指しています。
方向性は明確です。エージェントが自律的に取引できるようになるためには、機械可読で、デフォルトでパーミッションレス、そして敵対的条件下で検証可能なインフラスタックが必要です。
2) x402：HTTP 402 Payment Requiredをオンチェーン決済フローに変える
2.1 突然重要になった「未使用」のHTTPステータスコード
HTTPステータスコード402は数十年前から存在していましたが、HTTPセマンティクス仕様では将来の使用のために予約されていました。（datatracker.ietf.org） 参照：RFC 9110 — HTTP Semantics
x402はその予約されたスペースを利用し、具体的で開発者フレンドリーな意味を与えます。それは「このリソースが必要なら、有効な支払い情報をつけて再試行してください」ということです。
HTTP中心の概要については、MDN: 402 Payment Requiredをご覧ください。
2.2 x402が提案するもの（そしてなぜそれが魅力的か）
x402の設計では、AIエージェント（または任意のクライアント）がAPI/リソースをリクエストします。
- クライアントリクエスト → 支払いが添付されていないリクエストが到着
- サーバーがHTTP 402を返す → 価格設定+支払い指示が含まれる
- クライアントが署名済みの支払い承認をつけて再試行
- サーバーが検証し、支払いをブロードキャスト → リソースを返す
このフローは、従量課金アクセスにおけるAPIキー、アカウント、サブスクリプションを排除するために明示的に位置づけられています。（x402.org） 主要参照：x402 Whitepaper (PDF)
2.3 なぜx402は「エージェントネイティブ」なのか（単なる新しい決済ボタンではない）
x402は、エージェント経済インフラの議論において、エージェントが実際にどのように機能するかと一致しているため興味深いのです。
- アトミックな意図ループ：「データが必要 → 支払う → タスクを続行する」
- 長期間有効なAPIキーのような秘密鍵がない：一般的なセキュリティ上の脆弱性を削減
- コンポーザブルな収益化：あらゆるAPIエンドポイントがマイクロマーケットになり得る
これがエージェント型決済の核心です。単にクリプトで支払いを可能にするだけでなく、決済を機械トリガー可能なプロトコルレベルのものにし、通常のインターネットフローに埋め込むのです。（x402.org）
2.4 x402だけでは解決できない困難な問題
x402は決済の輸送をエレガントにすることができますが、プロダクショングレードのエージェント商取引にはさらに多くのレイヤーが必要です。
- 承認と予算：誰がこのエージェントにいくら、どのような制約で支出することを許可したか？
- 紛争/品質保証：サーバーが約束された結果を提供しなかった場合はどうなるか？
- サービスのアトミック性：決済を実行+配信に堅牢にバインドできるか？
- エージェントのアイデンティティと信頼：相手のエージェント/サービスが正当であることをどうやって知るか？
ここで、ERC-8004のような標準やVirtuals ACPのようなエコシステムプロトコルが、競合するのではなく、非常に補完的なものとなります。
3) ERC-8004：イーサリアム上のトラストレスエージェント（アイデンティティ、評判、検証）
x402がエージェントがどのように支払うかに関するものであるなら、ERC-8004はエージェントがどのように発見され、組織の境界を越えて信頼されるかに関するものです。
3.1 ERC-8004が提案するもの
ERC-8004（「トラストレスエージェント」）は、ブロックチェーンを使用して以下のことを提案するドラフトイーサリアム標準です。
- エージェントを発見する
- エージェントを選択する
- 事前の信頼関係なしにエージェントと対話する
これは、中心に以下の構造を定義します。
- IDレジストリ
- 評判レジストリ
- 検証レジストリ
ERC-8004は、カスタマイズ可能な信頼モデルを強調し、リスク資産額に応じたセキュリティを提供します。低リスクのタスクから高リスクのタスクまで（評判フィードバック、ステークで保護された再実行、zkML証明、またはTEEベースのアプローチなどのオプションを含む）。（eips.ethereum.org） 主要参照：EIPs上のERC-8004
3.2 これはAIエージェント経済にとってなぜ重要なのか
実質的な資金を扱う文脈でのエージェントの失敗のほとんどは、「モデルの知能」によるものではなく、信頼の境界線によるものです。
- どのエージェントが何を実行したかを検証できるか？
- エージェントが侵害された場合、影響範囲を限定できるか？
- 合意されたルールに従って結果が計算/チェックされたことを証明できるか？
ERC-8004のレジストリは、エージェントの信頼をコンポーザブルにするための直接的な試みであり、閉鎖的なプラットフォームごとに毎回再発明される必要はありません。
3.3 ERC-8004 + x402：自然な組み合わせ
実用的なメンタルモデル：
- x402：「従量課金サービスのための決済ハンドシェイクはこちらです。」
- ERC-8004：「エージェント/サービスを発見し、信頼を評価する方法はこちらです。」
これらを組み合わせることで、場当たり的なエージェント決済からオープンエンドなエージェント経済への道筋が描かれます。エージェントはプロバイダーを見つけ、信頼を評価し、支払いを行い、次に進むことができます。
4) Virtuals Protocol：トークン化されたエージェントの社会 + エージェント商取引プロトコル（ACP）
Virtuals Protocolは、エコシステムと調整の角度からエージェント経済にアプローチします。エージェントをオンチェーンの経済主体とみなし、出力を生成し、収益を上げ、タスクを調整できるようにします。
4.1 Virtualsが構築していると主張するもの
Virtuals Protocolは、それ自身のフレームワークで「AIエージェントの社会」と説明しています。これは、エージェントがブロックチェーンを通じて、パーミッションレスに作業を調整し、取引し、結果を決済するオンチェーンエコシステムです。（whitepaper.virtuals.io） 主要参照：Virtuals Protocol Whitepaper
注目すべき設計上の選択：このプロトコルは、$VIRTUALをエージェント間のやり取りにおける基盤となる取引通貨および流動性ペアとして位置づけています。（whitepaper.virtuals.io）
4.2 ACP：エージェント間商取引の標準
Virtualsは、標準化されたプロトコルがなければ、エージェント商取引の統合は、カスタムコードと脆い仮定の組み合わせ問題になる、と主張しています。特にエージェント数とトランザクションタイプが増加するにつれて。（whitepaper.virtuals.io） 参照：Agent Commerce Protocol (ACP)
重要なのは、ACPは単なる「決済」ではないことです。それは以下に関するものです。
- エージェントの提供するものの発見可能性
- 構造化されたジョブワークフロー
- オンチェーン決済パス
- エージェント商取引のための共有語彙
4.3 ACP v2は現実世界の複雑さへの移行を示唆
Virtualsのドキュメントでは、ACP v2を主要なアップデートとして説明しており、（他のものに加えて）以下を導入しています。
- ワークフローのための統合ジョブインターフェース
- ドメイン固有の要件のためのカスタムジョブ提供スキーマ
- エージェント間の関係とやり取りの履歴の永続的なオンチェーン記録としてのアカウント（whitepaper.virtuals.io）
これは、エージェント商取引が本質的に異種であるために重要です。「データセットを購入する」「監査を実行する」「取引を実行する」「メディアアセットを配信する」といったことは、現実的に単一の厳格なスキーマには適合しません。
4.4 Virtuals + ERC-8004 + x402：補完的な役割
一貫したスタックが出現する可能性があります。
- ERC-8004：境界を越えた発見+信頼プリミティブ
- x402：API/サービスのための摩擦のないリクエストごとの決済
- ACP (Virtuals)：商取引ネットワーク内でのワークフロー、ジョブ構造化、エージェント間調整
2026年の未解決の問いは、エージェントが取引できるかどうかではなく、エコシステムが互換性のない閉鎖的なサイロに断片化するのを防ぐために、ワークフローと信頼の表面を十分に標準化できるかどうか、ということです。
5) ビルダーとユーザーのためのチェックリスト：2025〜2026年に注目すべきこと
5.1 ビルダー向け：「コントロールプレーン」の欠如
エージェント型決済やオンチェーンエージェントインタラクションを統合している場合、以下を優先してください。
- 支出ポリシー（加盟店ごと、タスクごと、時間枠ごとの制約）
- キーの分離（運用キーとトレジャリーキーを分離）
- 監査可能性（すべての意図に署名し、領収書を保存）
- フォールバックとサーキットブレーカー（一時停止可能なフロー、エッジケースでの人間による承認）
これが「エージェント経済インフラ」が現実になる場所です。決済は簡単です。安全な決済は困難です。
5.2 ユーザー向け：自己保管（Self-Custody）がエージェントの安全プリミティブになる
エージェントが取引できるようになると、ウォレットセキュリティはニッチな懸念ではなくなり、運用リスク管理になります。
多くのチームが採用している実用的なアプローチは、役割ごとの資金の分離です。
- 限定された日常的なエージェント支出のための、監視された少額のホットウォレット
- 意図的に予算を補充するだけのコールドストレージトレジャリーウォレット
DeFiや従量課金クリプトサービスとやり取りするエージェントを実行している場合、ハードウェアウォレットが自然に組み込まれる場所でもあります。例えばOneKeyは、自己保管のために設計されており、オンチェーンワークフローをサポートしながら、長期間の資金をオフラインに保つことができます。
次回（パート2プレビュー）
パート2では、このインフラストラクチャマップを以下に拡張します。
- OpenClaw：エージェントランタイム/ツールレイヤーにおけるその役割と、クリプトユーザーにとっての意味
- より広範な業界の軌跡：相互運用性、コンプライアンス圧力、セキュリティインシデント、そしてオープンスタンダードと閉鎖プラットフォームの戦い
免責事項：この記事は情報提供のみを目的としており、金融アドバイスを構成するものではありません。
