エージェントウォレット: AIエージェントのためのセッションと権限モデル

2026年9月2日公開読了時間 4 分

オンチェーンで取引するAIエージェントは、署名1つで実際の資金を動かせる状態にある。市場を読み、DEXを介したルートを選び、実行の準備ができている。これを安全に運用できるかどうかは、1つの問いに帰着する。エージェントが誤動作した場合、乗っ取られた場合、あるいは単にバグがあった場合に何が起きるか。ウォレットを空にできてしまうのか、被害が出る前に止められるのか。

エージェントウォレットとは何か、通常の暗号資産ウォレットとどう違うのか

通常のウォレットは、本人だけが保持する鍵ですべてのトランザクションを人間がレビューし署名することを前提としている。エージェントウォレットはその逆を前提とする。AIエージェントや自動化されたプロセスが継続的に署名を行い、人間が毎回承認をクリックすることはないが、資金を所有する個人や組織が最終的な制御権を保持する。

違いは、ウォレットに入っている残高やアドレスではなく、署名鍵を取り巻く権限モデルにある。すなわち、エージェントに何を許可するか（スコープ化された権限）、どのくらいの期間許可するか（時間制限付きセッション）、そして何か問題が起きたときにどれだけ速く遮断できるか、という点だ。

Agent Walletsはこれらをそれぞれ直接扱う。

スコープ化された権限: CLIセッションには、送金、スワップ、ブリッジ、コントラクト呼び出しなど、付与した特定の署名メソッドだけが含まれる。1つのコントラクトの関数だけに鍵を制限するのは、CLIの権限ではなくWallet API のセッションキー権限である。
時間制限付きセッション: すべての付与には有効期限があり、誰も取り消さなくてもアクセスは自動的に失効する。
迅速な遮断: Alchemyダッシュボードから、またはalchemy wallet disconnectでCLIセッションを取り消すと、トランザクション不要で検証レイヤーにおいて即座に有効になる。

スコープ化された権限と有効期限は、Agent Wallets CLI製品をEVMとSolanaの両方で直接使う場合でも、独自のユーザー向けに基盤となるWallet APIsのセッションキー・プリミティブの上に構築する場合でも見られる。トランザクションのマイニングを待たない即時遮断はCLI側の話だ。Wallet APIのセッションキーを削除するのはオンチェーンでのアンインストールになる。

エージェントウォレットはどのようにして秘密鍵をエージェントから遠ざけるのか

エージェント向けに安全なトランザクションを設計するということは、通常のウォレットが1つの鍵にまとめてしまっているものを分離することを意味する。カストディ（誰が秘密鍵を保持するか）、認可（何が許可されているか）、そして制御（誰が承認あるいは停止できるか）の3つだ。

Turnkeyは、ハードウェアのセキュアエンクレーブ内にカストディを保持し、同じエンクレーブ内でポリシーエンジンを実行する。そのため署名は、リクエストがルールを通過した後にのみ生成され、エージェントが鍵に触れることはない。
CrossmintとCoboは、代わりにウォレットをオーナーキーとエージェントキーに分割する（CoboはCoboは単一の鍵ではなく独立した複数の当事者間でのMPCを使う）。これにより、エージェントの鍵はオーナーが設定した制限の範囲内でのみ機能する。
Alchemyは同じ分離をCLIに組み込んだ。ローカルで生成されたセッション署名者がエージェントを認証し、別のカストディアンが実際の秘密鍵を保持する。これにより、エージェントは鍵に一切触れることなく認証と署名を行える。

実際にどのように動作するかは以下の通りだ。

alchemy wallet connectを実行すると、CLIはローカルでP-256の鍵ペアを生成し、それがマシンの外に出ることはない。
Alchemyダッシュボードでセッションを承認すると、その公開鍵が特定の権限と設定した有効期限にスコープされた署名者として紐づけられる。
ウォレットの実際の秘密鍵は、埋め込みウォレットのパートナー（デフォルトではPrivy）が保持する。
すべての署名呼び出しは2段階のチェックになっている。Alchemyのバックエンドがカストディアンの期待する正確なペイロードを構築し、CLIがそれをローカルで署名し、セッションがまだ有効な場合にのみリクエストがカストディアンに届く。エージェントが秘密鍵を受け取ったり扱ったりすることはない。

プロビジョニングと権限制御にはどのインフラを使うべきか

誰のために構築しているかによって、2つの経路がある。

コーディングエージェントや社内の自動化にウォレットを与える場合、Alchemy CLIのAgent Walletsが最速の経路であり、秘密鍵をそのままCursorに貼り付けることを、エージェントが実際に安全に使えるものに置き換えるのと同じアプローチだ。

ダッシュボードでウォレットを作成し、alchemy wallet connect --mode sessionを実行し、セッションの権限と有効期限を承認すれば、エージェントはすぐに送金やコントラクト呼び出し、さらにEVMメインネットでのスワップやブリッジに使えるスコープ化されたセッションを手に入れる。SDKの統合は不要で、CLIのagent-promptコマンドはコマンド、フラグ、エラーコードの完全な一覧をエージェントに渡すので、正しくその表面を使うためにドキュメントを読みに行く必要がない。

自社のユーザーが署名をエージェントに委任するプロダクトを構築している場合は、Wallet APIsのセッションキーを活用する。ユーザーのスマートアカウントはEIP-7702の下でオンチェーンで委任され、セッションキーと権限の配列を指定してwallet_createSession（SDKではclient.grantPermissions()）を呼び出し、ユーザーは1回のEIP-712承認に署名し、その後のすべてのアクションはオーナーの鍵ではなくセッションキーでエージェントが署名する。

何を委任できるのか、権限の粒度はどの程度か

委任はここで2つのレイヤーで機能する。1つはセッションがそもそもどのアクションを呼び出せるか、もう1段深いレイヤーとして、その呼び出しがどれだけの価値、あるいはどの特定のコントラクトに触れられるかだ。

CLIセッションのレベルでは、最初のレイヤーは許可されたメソッドのリストになる。

セッションにはevm.signMessage、evm.signTypedData、evm.signAuthorization、evm.prepareCalls、evm.sendCalls、solana.signTransactionを含めることができる。
すべてはAlchemyのウォレット呼び出し（wallet_prepareCallsとwallet_sendCalls）を経由するため、順序付けやバッチ処理といったトランザクションのロジスティクスやガススポンサーシップはあなたの代わりに処理される。

トレードオフとして、セッションは単独の秘密鍵のように任意のraw EVMトランザクションに署名することはできない。そのため、エージェントがraw EVMトランザクションを渡して署名させることを前提とするサードパーティのSDKやプロトコルに接続する必要がある場合、そのフローは現状CLIセッションでは機能しない。これがあなたに必要なユースケースであれば、お問い合わせいただきたい。

Wallet APIsのレベルでは、セッションキー権限はより細かく設定できる。CLIの権限リストが答えるのは「はい」か「いいえ」だけだ。すなわち、このセッションはそもそもsendCallsを呼び出せるか。Wallet APIの権限はその上に制限を追加する。転送が許可されるかどうかだけでなく、どれだけの量が、どのトークンで、どの特定のコントラクトを通じて動けるかまで指定できる。エージェントに実際の支出上限、たとえば24時間のウィンドウで1つのトークンにつき100 USDCの上限のような、単にどのアクションが有効かというスイッチだけでなく実際の制限が必要な場合は、Wallet APIsを活用する。

Permission type	What it restricts
`native-token-transfer`	Caps how much native token (ETH, say) the key can move, via a fixed allowance
`erc20-token-transfer`	Caps cumulative ERC-20 transfers and approvals for one token contract to a set allowance
`gas-limit`	Caps how much gas the key can spend across transactions
`contract-access`	Allows every function on one named contract, nothing else
`functions-on-contract` / `account-functions` / `functions-on-all-contracts`	Allows only specific function selectors, on one contract, on the account itself, or everywhere
`root`	Full access to everything, a very dangerous permission to grant. Use judiciously.

すべての権限にはexpirySecも付随するため、1つの付与によって、たとえば1つのステーキングコントラクト、100 USDCの上限、24時間のウィンドウをすべて同時にセッションキーにスコープすることができる。

エージェントのウォレットセッションを承認、検証、失効させる方法

承認は人間によって一度だけ行われる。CLIフローでは、それはセッションを接続する際のダッシュボードでの承認ステップだ。Wallet APIsフローでは、オーナーがセッションキーの権限を承認するEIP-712タイプ付きデータに署名することがそれにあたる。

検証は、状態を変更するすべてのアクションの前に行われるべきであり、セットアップ時だけではない。エージェントが取り返しのつかないことをする前にalchemy --json --no-interactive wallet status --verifyを実行する。これはアクティブな署名者、セッションの有効期限、有効な権限を返すので、エージェント（あるいはあなたのオーケストレーションコード）は処理を進める前にセッションがまだ有効であることを確認できる。

失効には2つのメカニズムがある。

ダッシュボードから、あるいはalchemy wallet disconnectを使うと、セッションは検証レイヤーで失効する。次の署名の試みは、カストディアンに届く前に、即座に、トランザクション不要で拒否される。
CLI製品の外で、スマートアカウントのレベルで直接セッションキーを管理している場合、セッションキーを削除することは、そのバリデーターをアンインストールするためのユーザーオペレーションを意味し、他のオンチェーンアクションと同様に送信されマイニングされる必要がある。

エージェントのアクセス失効を即座に行うための設計方法

エージェントが何か誤ったことをしているのを発見し、失効を実行したとする。あなたのキルスイッチがオンチェーンに保存されたルールを変更することで機能する場合、その変更は依然としてトランザクションとして送信され、マイニングされて初めて実効となる。そのため、ブロックタイム、あるいはそれ以上の長さの間隙があり、すでにシステムに停止を指示していてもエージェントがまだ行動できてしまう。問題は、その間隙が生じないように失効をどう設計するかだ。

これは、エンフォースメントがどこにあるかに帰着する。エージェントとチェーンの間に立つものがスマートコントラクト内に保存されたルールだけである場合、そのルールをオフにすることはコントラクトの状態を変更するトランザクションを送信することを意味し、そのトランザクションは変更が実効になる前にマイニングされる必要がある。代わりに、署名やブロードキャストされる前にリクエストをチェックするレイヤーでエンフォースメントが行われる場合、失効はそのチェックを削除または無効化するだけであり、それを行った瞬間に実効になる。

AlchemyのAgent Wallets、Turnkeyのポリシーエンジン、Coboのpactシステムはすべてこの後者のパターンを使っている。

Turnkeyはroot以外のエージェントユーザーを削除し、その認証情報からのその後のすべてのリクエストはエンクレーブで失敗する。
Coboはpactとそのapiキーをサーバーサイドで失効させ、エージェントの次のAPI呼び出しが拒否されると明言している。
Alchemyはバックエンドの検証レイヤーでセッションを失効させ、次の署名の試みは、Alchemyのインフラを出る前、つまりカストディアンに届く前に拒否される。

Crossmintは異なるアプローチを取る。その権限はスマートコントラクトウォレット自体の内部に存在するため、エージェントの署名者を削除することはそのコントラクトのオンチェーン状態への変更になる。ルールがサーバーではなくチェーン自体によって強制されることは、侵害されたエージェントが回避しにくい一方で、トレードオフは速度にある。オンチェーンの権限を変更するにはトランザクションを送信する必要があるため、失効はチェーンが持つ決済時間を引き継ぐことになり、これはバックエンドチェックによるアプローチでは完全に回避できるものだ。

Agent Wallets と Wallet API のセッションキーの比較

Agent WalletsもWallet APIs経由のセッションキー利用も、どちらも秘密鍵をエージェントから遠ざける。異なるのは、どれだけの制御が必要か、実際に誰がエージェントに委任するのか、そして失効がどう機能するかだ。CLIセッションはトランザクション不要で検証レイヤーで遮断される。Wallet APIのセッションキーのアンインストールはユーザーオペレーションのマイニングを待つ。

Use Agent Wallets (the CLI)	Use Wallet APIs session keys
You're wiring up a coding agent or an internal script and want it signing in minutes, no SDK integration required.	You're building a product where your own end users delegate signing to an agent on their own smart account.
A yes/no capability list, can this session send, swap, bridge, or make contract calls, is enough scoping for what the agent does.	You need an actual spend cap, like a fixed allowance on native token or one ERC-20, enforced by the permission itself.
The Alchemy dashboard is a fine place to create the wallet and approve sessions by hand.	You need contract- or function-level allowlists as the real enforcement boundary, not just a capability flag.
The CLI already handles what the agent needs to do: sending, batching calls, and getting its gas sponsored across EVM and Solana, plus swapping and bridging on EVM mainnet.	You need to grant session keys from your own app. Neither path signs an arbitrary raw EVM transaction for a third-party SDK today. Reach out to us if that's the use case.

Alchemy と Turnkey、Crossmint、Cobo の比較

Provider	Where custody lives	Where policy is enforced	Instant revoke without a mined transaction
Alchemy Agent Wallets	Embedded wallet partner (Privy by default) for CLI sessions, or any signer you choose via Wallet APIs	Backend session-verification layer for CLI sessions; onchain session-key permissions on the smart account for custom Wallet APIs integrations	Yes for CLI sessions, via dashboard or `wallet disconnect`. Wallet API session keys: no, uninstalling the validator is a mined user operation
Turnkey	AWS Nitro secure enclave (TEE)	Policy engine running inside the same enclave, evaluated before every signature	Yes, delete the non-root agent user or toggle a DENY policy
Cobo Agentic Wallet	MPC across independent parties, no single key	Three-stage server-side policy engine (permission, rule, counter), evaluated on every request	Yes, freeze or revoke a pact; the API key gets invalidated server-side
Crossmint	Dual-key smart contract wallet: owner key plus an agent key sealed in a TEE	Onchain, inside the smart contract itself (per-transaction limits, allowlists, time windows checked at execution)	By design, no. Removing a signer changes the wallet contract's onchain signer set, so it settles like any other onchain operation rather than a synchronous backend check

要するに、Alchemy CLIセッション、Turnkey、Coboはいずれもオフチェーンで強制し、即座に失効する。Crossmintと Wallet API のセッションキーはオンチェーンで強制するため、失効は決済時間を引き継ぐ。

避けるべきよくある間違い

ガススポンサーシップを支出制限として扱わないこと。 スポンサーシップポリシーが決めるのは誰が手数料を払うかであって、エージェントがどれだけ動かせるかではない。実際の支出上限にはセッションキー権限やコントラクトの許容量を使う。
オンチェーンの権限変更をキルスイッチとして頼らないこと。 アクセスの失効がバリデーターのアンインストールやオンチェーンでの署名者の変更を意味する場合、インシデント発生時にブロックタイムに縛られることになる。代わりに署名の前段にバックエンドまたはエンクレーブによるチェックを置き、オンチェーンレイヤーは第2の防御線として維持する。
より早くブロックを解除するためにroot権限を付与しないこと。 Alchemy自身のドキュメントもこれを「付与するのが非常に危険な権限」と呼んでおり、そもそもセッションをスコープする意味を無くしてしまう。エージェントが実際に必要とする特定のコントラクト、関数、あるいはトークンにスコープすること。
取り返しのつかないアクションの前に検証をスキップしないこと。 1時間前には有効だったセッションが、すでに失効あるいは期限切れになっている可能性がある。取り消せない何かを行う直前に、wallet status --verify（あるいはあなたの統合における同等の手段）で確認すること。
「エージェントウォレット」が1つのアーキテクチャを意味すると想定しないこと。 Turnkey、Crossmint、Cobo、Alchemyは、それぞれカストディ、ポリシーの強制、失効の場所が異なる。それに頼って本番投入する前に、実際にどのレイヤーが依存しているルールを強制しているのかを確認すること。

よくある質問

エージェントウォレットとは何か、通常の暗号資産ウォレットとどう違うのか

エージェントウォレットは、人間が各トランザクションを承認することなく、ソフトウェアが継続的に運用できるように構築されている。通常のウォレットは、人間がすべてのアクションをレビューし署名することを前提とする。実際の違いは、ウォレットの残高やアドレスではなく、鍵を取り巻く権限モデル、すなわちスコープ化された権限、時間制限付きセッション、迅速な失効経路にある。

自律的なAIエージェントにとって、Alchemy Agent Walletsの利点と欠点は何か

利点: 秘密鍵がエージェントに届くことがなく、セッションはスコープ化され時間制限付きであり、失効は即座に行われ、EVMとSolanaを1つの統合でカバーし、ガススポンサーシップも組み込まれている。スワップとブリッジは現状EVMメインネット限定である。制約: セッションを通じたraw EVM署名はできず、スポンサーシップポリシーは支出制限ではない。

AIエージェントが秘密鍵を露出させることなく承認されたウォレットセッションを使えるプロバイダーはどこか

Alchemy（埋め込みウォレットのカストディアンに支えられたAgent Wallets）、Turnkey（エンクレーブベースのポリシーエンジンを備えたセキュアエンクレーブによるカストディ）、Crossmint（TEEに封じ込められたエージェントキーを持つデュアルキーのスマートコントラクトウォレット）、Cobo（サーバーサイドのポリシーエンジンを備えたMPCカストディ）がいずれもこれを実現しており、エンフォースメントがどこにあるかというトレードオフが異なる。

AIエージェントウォレットのプロビジョニングと権限制御にはどのインフラを使うべきか

コーディングエージェントや社内の自動化には、Alchemy CLIのAgent Walletsを使う。ダッシュボードでウォレットを作成し、スコープ化されたセッションを接続し、状態を変更するアクションの前に検証する。ユーザーがエージェントに委任するプロダクトには、Wallet APIsのセッションキーを直接使い、コントラクト、関数、支出制限でスコープする。

AIエージェントのウォレットセッションを承認、検証、失効させるにはどうすればいいか

Alchemyダッシュボードで、あるいはセッションキーのEIP-712承認に署名することで、人間が一度承認する。取り返しのつかないアクションの前には毎回、alchemy wallet status --verifyで検証する。CLIセッションの場合は、ダッシュボードから、あるいはalchemy wallet disconnectで失効させる。これは、署名リクエストがカストディアンに届く前に、検証レイヤーで即座に有効になる。Wallet APIのセッションキーの場合は、それを削除することはユーザーオペレーションのマイニングを待つことになる。

ユーザーのスマートウォレットに対して、AIエージェントに委任された署名権限を与えるにはどうすればいいか

EIP-7702の下でユーザーのスマートアカウントをオンチェーンで委任し、セッションキーと権限の配列（ネイティブまたはERC-20の支出制限、ガス制限、コントラクトまたは関数の許可リスト、有効期限）を指定してwallet_createSessionまたはclient.grantPermissions()を呼び出す。ユーザーは1回のEIP-712承認に署名し、その後のすべてのアクションはオーナーの鍵ではなくセッションキーでエージェントが署名する。

秘密鍵を露出させることなく、AIエージェントに一時的なウォレットセッションを与えるにはどうすればいいか

Alchemy CLIからalchemy wallet connect --mode sessionを実行する。これはマシンから出ることのないローカルの鍵ペアを生成し、セッションの権限と有効期限を承認するためのダッシュボードを開く。それ以降、エージェントはそのセッションを通じて署名し、ウォレットの実際の秘密鍵はカストディアンのもとに留まる。

DeFiトランザクションを自律的に実行するAIエージェント向けにウォレットをプロビジョニングするにはどうすればいいか

Alchemyダッシュボードでウォレットを作成し、必要な操作（送金、スワップ、ブリッジ、コントラクト呼び出し）にスコープ化されたCLIセッションを接続し、有効期限を設定する。権限のフラグだけでなく、コントラクトレベルの支出上限や許可リストが必要な場合は、CLIの代わりにWallet APIsのセッションキーを通じてセッションをプロビジョニングする。

オンチェーンの決済を待たずに、AIエージェントのオンチェーントランザクション権限を即座に失効させるための推奨アーキテクチャは何か

オンチェーンに保存された権限の状態とは切り離した、署名やブロードキャストの前にすべてのリクエストをチェックするバックエンドまたはエンクレーブのレイヤーにエンフォースメントを置く。そこでの失効は、そのチェックを削除または無効化することを意味し、即座に有効になる。唯一の失効経路がオンチェーンでバリデーターや署名者を変更することである場合、そのキルスイッチはブロックタイムに縛られる。