Agent Wallet

AgentウォレットとEOAウォレットの根本的な違いは何ですか？なぜMetaMaskの秘密鍵をAgentに渡せないのですか？

表面上はどちらも「秘密鍵を持つイーサリアムアドレス」ですが、設計ロジックはまったく異なります。

通常のEOAウォレット（MetaMask・ハードウェアウォレット）の設計前提：人間が各トランザクションの前に確認します——「この送金は正しいか？金額は？アドレスは？」人間が最後のセキュリティゲートです。そのためEOAウォレットにはプログラマチックな操作制限は組み込まれていません。

Agentウォレットの設計前提：各操作前に人間の確認がありません——Agentが完全に自律して実行します。そのため安全境界はコード層に内蔵される必要があります：支出上限のハードコード（$100を超える操作は人間の確認のために一時停止）・ホワイトリストアドレス（Agentはホワイトリストに登録されたコントラクトとのみインタラクション可能）・日次累計上限（人間の監視なしに長時間稼働するAgentが大口操作を積み重ねるのを防止）。

MetaMaskの秘密鍵をAgentに渡せない理由：秘密鍵がAgentに保持されると、AgentのLLM推論がPrompt Injectionで侵害された場合、攻撃者はAgentにどんな金額でもどんなアドレスにでも授権させることができます——プログラマチックなガードレールが存在しません。これは上限なしのクレジットカードをハッカーに操作される可能性があるロボットに渡すことと同じです。

Agentウォレットの4つの主流アーキテクチャは何ですか？それぞれどのシナリオに適していますか？

アーキテクチャ1：EOA + コードガードレール（最もシンプル） 通常のEOAアドレスを使用し、秘密鍵をバックエンドに保存し（AWS Secrets Manager・暗号化された環境変数）、コード層ですべての安全境界を実装します（金額検証・ホワイトリスト・日次上限）。コストが最も低く、デプロイが最速です。初期段階のAgentと低資金量のシナリオに適しています。

アーキテクチャ2：MPCウォレット（マルチパーティ計算） 秘密鍵を複数の「シャード」に分割して分散保管します（例：2-of-3：Agentが1つ・あなたの携帯が1つ・サービスプロバイダーが1つ）。署名にはシャードの協力が必要で、どの1つのシャードが単独で漏洩しても署名を完成できません。Privy・Turnkeyが商業MPCウォレットサービスを提供しています。

アーキテクチャ3：スマートコントラクトウォレット（Safe / ERC-4337） スマートコントラクトを使ってマルチシグまたは条件付き承認ロジックを実装します。Agentの操作リクエストはコントラクトに提出され、プリセットルールに従って実行されます（上限超過にはマルチシグが必要・ホワイトリストコントラクトとのインタラクションのみ許可）。セキュリティが最も高く、ルールは透明でオンチェーン監査可能です。

アーキテクチャ4：Coinbase AgentKitカストディアルウォレット CoinbaseのMPCインフラが秘密鍵を管理し、SDKが標準化されたAgentウォレット機能を提供します。Baseチェーンとの統合が最も深く、PaymasterによりAgentはETHを保持せずにUSDCでGasを支払えます。迅速なプロトタイピングとBaseチェーン戦略に適しています。

AgentウォレットのGasコスト問題をどう解決しますか？AgentがGasを自分で支払うデザインパターンは何ですか？

GasコストはオンチェーンAgentで最も見落とされがちですが、ユーザー体験に最も影響する問題です。主流の4つの解決設計：

1. ETHリザーブ（最も基本的）：AgentウォレットにETH（または対象チェーンのネイティブトークン）を一定量保有してGasリザーブとします。低水位アラートを設定します（0.01 ETH以下で補充通知）。シンプルですが、クロスチェーンデプロイでは各チェーンでGasリザーブを維持する必要があり、管理コストはデプロイチェーン数に線形増加します。

2. Paymaster（ERC-4337アカウント抽象化）：スマートコントラクトウォレット（ERC-4337パターン）はPaymasterメカニズムをサポートします——第三者Paymasterコントラクトが代わりにGasを支払い、AgentはUSDCのみを保持し、Gasコストはから差し引かれます。CoinbaseのBase・zkSyncがPaymasterをサポートしています。これによりAgentの財務ロジックがクリーンになります：USDCだけが必要で、Gasトークンの管理は不要です。

3. Relayerサービス（ガスレスモード）：Agentは未署名のトランザクションを生成してRelayer（例：OpenZeppelin Defender）に提出します；RelayerがGasを支払ってブロードキャストし、AgentのUSDC残高からコストを差し引きます。ERC-4337をサポートしないチェーン（例：SolanaのJito）に適しています。

4. スポンサーシップ（特定シナリオ向け）：一部のDeFiプロトコル（例：AaveのGasZip）はプロトコルとのユーザーインタラクションにGasコストを吸収します。これらのプロトコルでのAgent操作はゼロGasで可能ですが、特定のプロトコルがサポートする操作に限定されます。

AgentウォレットのPrivate Keyが漏洩したらどうすればいいですか？緊急対応プロセスは何ですか？

Agentウォレットの秘密鍵が漏洩した場合、通常のウォレットよりも深刻な結果をもたらします——Agentは24時間稼働している可能性があり、攻撃者はすぐに鍵を悪用でき、リアルタイムの人的監視がない可能性があります。完全な緊急対応プロセス：

ステップ1（0-5分）：Agentサービスプロセスを即座に停止する。 漏洩を疑う理由に関係なく、まず停止します——Agentサービスを停止しても既にブロードキャストされたトランザクションは取り消せませんが、新しいトランザクションのブロードキャストを防げます。

ステップ2（5-10分）：すべてのERC-20承認を取り消す。 サービスが停止していても、AgentウォレットアドレスがトークンコントラクトにApproveを持っている場合、攻撃者はコントラクトを直接呼び出してトークンを転送できます。メインウォレットを使って、承認済みのすべてのトークンコントラクトに対してapprove(agentAddress, 0)を呼び出してください。revoke.cashを使って迅速にクエリおよびバッチ取り消しができます。

ステップ3（10-30分）：Agentウォレットの残余資金を新しいアドレスに転送する。 サービスを停止し承認を取り消した後、Agentウォレットの残余資金を、まったく新しい未使用のアドレス（メインウォレットではない）に即座に転送します。

ステップ4（30-60分）：根本原因分析。 ログから「秘密鍵がどのように漏洩したか」を調べます。

ステップ5：新しいAgentウォレットで再デプロイする。 元のアドレスを再利用しないでください——資金が転送された後でも、古いアドレスの操作履歴から攻撃者が戦略ロジックを推測できる可能性があります。