AIエージェントがオンチェーンで自律的に操作するためには「エージェントウォレット」が必要です——エージェントがトランザクションに自律的に署名してブロードキャストできるメカニズムです。しかし「エージェントウォレット」は単一のソリューションではなく、設計上の選択肢のセットです：誰が秘密鍵を管理するか？認可範囲はどれほど広いか？取り消せるか？攻撃からどのように保護するか？この記事では主流の4つのエージェントウォレット設計アプローチを比較します。
よくある初心者の設計：「AgentにメインウォレットのAPIキーをそのまま使わせればいい、どうせ私のお金だから。」これには3つの根本的な問題があります：第一に、攻撃面が最大になります——メインウォレットの秘密鍵がAgentシステムに触れると、Agentシステムのどのコンポーネントが侵害されても、すべての主要資産が露出します。第二に、認可を階層化できません。第三に、Agentの操作能力を取り消せません。専用のAgentウォレットはこの3つの問題をすべて解決します。
アーキテクチャ1：独立したEOAホットウォレット（最もシンプル、最も一般的）
設計：Agentのために新しいEthereumのEOA（外部所有アカウント）を生成し、秘密鍵を独立して保存します（メインウォレットとは異なる）。Agentはこの秘密鍵を保持し、トランザクションに直接署名します。セキュリティ：秘密鍵はメインウォレットから完全に隔離されている（良い点）；しかし秘密鍵はAgentのランタイム環境に存在する必要がある（悪い点）——ランタイム環境が攻撃されると、秘密鍵が漏洩する可能性があります。適用シナリオ：低額のテストと開発環境；Agentが管理する資金規模が許容損失範囲内（例：$100〜$500）。
アーキテクチャ2：ERC-4337アカウントアブストラクションウォレット（本番環境に推奨）
設計：ERC-4337標準を使用してスマートコントラクトウォレットをデプロイします；Agentの操作認可はコントラクトロジックに記述されています——日次最大支出・許可されたコントラクトのホワイトリスト・許可された操作タイプなど、これらはすべてコントラクトレベルで強制執行され、Agentの「自律性」に依存しません。セキュリティ：安全境界はオンチェーンコントラクトにあり、バックエンドコードより回避が難しい；マルチシグをサポート；コントラクトのアップグレードで認可範囲を変更でき、資金の移動が不要。適用シナリオ：本番環境・中額（$500〜$50,000）・明確に検証可能なオンチェーン安全境界が必要なシナリオ。
アーキテクチャ3：MPC多者計算ウォレット（エンタープライズグレードのセキュリティ）
設計：MPC（多者計算）技術を使用して秘密鍵を複数の異なる場所（例：あなたのサーバー・ユーザーのデバイス・信頼できるサードパーティ）にシャード化します。トランザクションに署名するには複数のシャードの協力が必要で、どの場所も単独で完全な秘密鍵を保持しません。セキュリティ：極めて高い——攻撃者が1つのシャード場所を侵害しても完全な鍵を再構築できません。CoinbaseのAgentKitは同様のMPCアーキテクチャを使用しています。適用シナリオ：機関レベル・大額資金管理（$50,000以上）・最高のセキュリティ要件のシナリオ。実装複雑度は高く、通常はFireblocks・Lit Protocol・Privyなどの成熟したMPCサービスプロバイダーを使用します。
アーキテクチャ4：限定ERC-20 Approve認可（最も軽量だが適用範囲が狭い）
設計：Agentに秘密鍵を与えず、メインウォレットを使ってAgent管理の「実行コントラクト」に限定のERC-20 approve認可を設定します。Agentはこの認可範囲内でのみ操作でき、認可を超える操作はコントラクトによって直接拒否されます。セキュリティ：設計上最も安全——Agentに秘密鍵を与えず、Agentはあなたが与えたトークン認可のみを持ち、認可が期限切れまたはあなたによって取り消された後はAgentは完全に操作できません。適用シナリオ：特定のトークンの固定戦略操作；DeFiプロトコルの限定操作。
実用的な妥協案：階層型ストレージ。Agentの操作ウォレットには「数日分の運転資金」だけを保持し（ホットストレージ）；残りの資金はAgentシステムに接続されていないコールドストレージに保持します；あなたが定期的に手動でAgentの操作ウォレットに補充します。推奨される資金階層化比率：操作ウォレット（ホット）には総戦略資金の5〜10%；コールドストレージには90〜95%。問うべき質問：「このウォレットが完全に盗まれても許容できるか？」
Agent操作ウォレットにはGas代とA2A支払い手数料の継続的な補充が必要です。重要な設計上のポイント：補充はあなたが手動でトリガーすべきであり、Agentがメインウォレットから自動抽出すべきではありません——自動補充メカニズムは実質的にAgentにメインウォレットへのアクセスを与え、ウォレット隔離の安全境界を破壊します。補充トリガー通知を設定し（操作ウォレット残高が$X以下になったときに通知）、補充するかどうかを手動で決定します。
Agentウォレットの設計は純粋な技術的問題ではありません——「すべてが最悪のケースになった場合、最大でいくら損失するか」を直接決定します。Agentウォレットのアプローチを選ぶ前に一つの質問に答えてください：「このAgentウォレットのすべての資金が盗まれた場合、損失はいくらか？」セキュリティ設計の究極の目標はAgentシステムを「攻撃不可能」にすることではなく、「最悪のケースの損失をあなたが許容できる範囲内に」することです。