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

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

オンチェーンで取引するAIエージェントは、署名ひとつで実際の資金を動かせる状態にある。市場を読み、DEXを通るルートを選び、実行の準備ができている。これを安全に出荷できるかどうかは、1つの問いに集約される。エージェントが間違えたとき、乗っ取られたとき、あるいは単にバグがあったとき、何が起きるのか。ウォレットを空にすることはできるか、被害が出る前に止められるか。

権限制御付きのエージェントウォレットをプロビジョニングするには、エージェントに秘密鍵ではなくスコープ化されたセッションを渡す。コーディングエージェントや社内の自動化には、Alchemy CLIのAgent Walletsを使う。alchemy wallet connect を実行し、許可するアクションと有効期限をダッシュボードで承認し、作業が終わればセッションを即座に取り消す。自社のユーザーがエージェントに権限を委任するプロダクトでは、Wallet APIのセッションキーを使う。EIP-7702のスマートウォレットの上に、トークンごとの支出上限、コントラクトの許可リスト、ガス上限、有効期限を追加できる。どちらの場合も、エージェントがオーナーの鍵を保持することはない。

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

通常のウォレットは、本人だけが持つ鍵で、すべてのトランザクションを人間がレビューし署名することを前提にしている。エージェントウォレットはその逆を前提にする。人間が毎回承認ボタンを押すことなく、AIエージェントや自動化されたプロセスが継続的に署名し続ける一方で、資金の所有者(個人または企業)が最終的な支配権を保持する。

違いは、ウォレットの残高やアドレスではなく、署名鍵を取り巻く権限モデルに帰着する。エージェントに何が許可されているか(スコープ化された権限)、それをどれだけの期間許可するか(期限付きセッション)、何か問題が起きたときにどれだけ速く止められるか、の3点だ。

Agent Walletsはこれらすべてを直接扱う。

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

スコープ化された権限と有効期限は、Agent Wallets CLI製品を直接使う場合でも(EVMとSolanaの両方で)、独自ユーザー向けに基盤となるWallet APIのセッションキープリミティブの上に構築する場合でも共通して現れる。マイニングされたトランザクションなしでの即座の停止はCLIの経路だ。Wallet APIのセッションキーの削除はオンチェーンのアンインストールになる。

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

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

Turnkeyはカストディをハードウェアのセキュアエンクレーブ内に保持し、ポリシーエンジンも同じエンクレーブ内で実行する。そのためリクエストがルールを通過した後にのみ署名が出力され、エージェントが鍵に触れることはない。
Crossmintと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 APIのセッションキーを使う。ユーザーのスマートアカウントはEIP-7702の下でオンチェーンに委任され、セッションキーと権限配列を指定して wallet_createSession(またはSDKの client.grantPermissions())を呼び出す。ユーザーは1回のEIP-712認可に署名し、それ以降のすべてのアクションはオーナーの鍵ではなくセッションキーでエージェントが署名する。

何を委任でき、権限はどこまで細かく設定できるのか

ここでの委任は2つの層で機能する。セッションがそもそも呼び出せるアクションと、もう一段深く、それらの呼び出しが触れられる金額や特定のコントラクトだ。

CLIセッションのレベルでは、最初の層は許可されたメソッドのリストだ。

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

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

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

Permission type	What it restricts
`native-token-transfer`	固定の許容量を通じて、ネイティブトークン(たとえばETH)をその鍵が動かせる量に上限を設ける
`erc20-token-transfer`	1つのトークンコントラクトについて、累積のERC-20転送と承認を設定した許容量に制限する
`gas-limit`	複数のトランザクションにわたってその鍵が消費できるガス量に上限を設ける
`contract-access`	指定した1つのコントラクトのあらゆる関数を許可し、それ以外は許可しない
`functions-on-contract` / `account-functions` / `functions-on-all-contracts`	特定の関数セレクタのみを、1つのコントラクトで、アカウント自体で、あるいは全体で許可する
`root`	すべてへのフルアクセス。付与するには非常に危険な権限であり、慎重に使うべきだ。

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

エージェントのウォレットセッションを承認、検証、取り消す方法

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

検証は、設定時だけでなく、状態を変更するあらゆるアクションの前に行うべきだ。エージェントが不可逆的なことを行う前に alchemy --json --no-interactive wallet status --verify を実行する。これはアクティブな署名者、セッションの有効期限、有効な権限を返すため、エージェント(またはオーケストレーションコード)は続行前にセッションがまだ有効であることを確認できる。

取り消しには2つの仕組みがある。

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

エージェントのアクセスの取り消しを即座にするにはどうすればよいか

エージェントが何か問題のあることをしているのに気づき、取り消しを行ったとする。もしキルスイッチがオンチェーンに保存されたルールを変更する仕組みであれば、その変更が実際に有効になる前に、トランザクションとして送信されマイニングされる必要がある。そのため、ブロック時間、場合によってはそれ以上の期間、すでにシステムに停止を指示したにもかかわらずエージェントがまだ動ける窓が生まれる。問題は、その隙間が生じないようにどう取り消しを設計するかだ。

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

AlchemyのAgent Wallets、Turnkeyのポリシーエンジン、Coboのパクトシステムはいずれも後者のパターンを採用している。

Turnkeyはルート以外のエージェントユーザーを削除し、その認証情報からの以降のすべてのリクエストはエンクレーブで失敗する。
Coboはパクトとそのバックエンド側のAPIキーを取り消し、エージェントの次のAPI呼び出しは拒否されると明確に述べている。
Alchemyはバックエンドの検証レイヤーでセッションを取り消し、次の署名試行はAlchemyのインフラを出る前、カストディアンに届く前に拒否される。

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

Agent Wallets 対 Wallet APIのセッションキー

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

Use Agent Wallets (the CLI)	Use Wallet APIs session keys
コーディングエージェントや社内スクリプトを組み込んでおり、SDKの統合なしで数分で署名させたい場合。	自社のエンドユーザーが、自分自身のスマートアカウントでの署名をエージェントに委任するプロダクトを構築している場合。
はい/いいえの権限リスト、このセッションは送金、スワップ、ブリッジ、コントラクト呼び出しができるか、でエージェントの動作に十分なスコープが取れる場合。	ネイティブトークンや1つのERC-20への固定の許容量など、権限自体によって実施される実際の支出上限が必要な場合。
Alchemyダッシュボードは、ウォレットを作成しセッションを手動で承認するのに十分な場所だ。	権限フラグだけでなく、コントラクトや関数レベルの許可リストを実際の実施境界として必要とする場合。
CLIはエージェントが必要とすることをすでに処理する。送信、呼び出しのバッチ処理、EVMとSolanaにまたがるガススポンサーシップ、さらにEVMメインネットでのスワップとブリッジだ。	自社のアプリからセッションキーを付与する必要がある場合。現状、どちらの経路もサードパーティのSDK向けに任意の生のEVMトランザクションに署名することはできない。それが必要な用途であればお問い合わせいただきたい。

AlchemyとTurnkey、Crossmint、Coboの比較

Provider	Where custody lives	Where policy is enforced	Instant revoke without a mined transaction
Alchemy Agent Wallets	CLIセッションでは組み込みウォレットのパートナー(デフォルトではPrivy)、Wallet APIを使う場合は選択した任意の署名者	CLIセッションではバックエンドのセッション検証レイヤー、カスタムのWallet API統合ではスマートアカウント上のオンチェーンのセッションキー権限	CLIセッションでは可能。ダッシュボードまたは `wallet disconnect` 経由。Wallet APIのセッションキーは不可。バリデータのアンインストールはマイニングされるユーザーオペレーションだ
Turnkey	AWS Nitroセキュアエンクレーブ(TEE)	同じエンクレーブ内で動作するポリシーエンジン。すべての署名の前に評価される	可能。ルート以外のエージェントユーザーを削除するか、DENYポリシーを切り替える
Cobo Agentic Wallet	独立した複数の当事者にまたがるMPC。単一の鍵はない	3段階のサーバー側ポリシーエンジン(permission、rule、counter)。すべてのリクエストで評価される	可能。パクトを凍結または取り消すと、APIキーがサーバー側で無効化される
Crossmint	デュアルキーのスマートコントラクトウォレット。オーナー鍵に加え、TEEに封印されたエージェント鍵	オンチェーン、スマートコントラクト自体の内部(トランザクションごとの上限、許可リスト、実行時にチェックされる時間ウィンドウ)	設計上、不可。署名者の削除はウォレットコントラクトのオンチェーンの署名者セットを変更するため、同期的なバックエンドチェックではなく、他のオンチェーン操作と同様に決済される

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

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

ガススポンサーシップを支出上限として扱わないこと。 スポンサーシップポリシーが決めるのは誰が手数料を払うかであり、エージェントがどれだけ動かせるかではない。実際の支出上限にはセッションキー権限またはコントラクトの許容量を使うこと。
オンチェーンの権限変更をキルスイッチとして頼らないこと。 アクセスの取り消しがバリデータのアンインストールやオンチェーンの署名者変更を意味するなら、インシデント発生時にブロック時間に縛られることになる。代わりに署名の前段にバックエンドまたはエンクレーブのチェックを置き、オンチェーン層は第二の防衛線として扱うこと。
早く解除するためだけに root 権限を付与しないこと。 Alchemy自身のドキュメントも、これは付与するには非常に危険な権限だと述べており、そもそもセッションをスコープする意味を失わせる。エージェントが実際に必要とする特定のコントラクト、関数、トークンにスコープすること。
不可逆的なアクションの前の検証を省略しないこと。 1時間前は有効だったセッションが、すでに取り消されているか失効している可能性がある。取り消せないあらゆることの直前に wallet status --verify (または統合先に応じた同等のもの)で確認すること。
「エージェントウォレット」が単一のアーキテクチャを意味すると想定しないこと。 Turnkey、Crossmint、Cobo、Alchemyはいずれもカストディ、ポリシーの実施、取り消しを異なる場所に配置している。依存しているルールが実際にどの層で実施されているのかを、出荷する前に確認すること。

よくある質問

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

エージェントウォレットは、人間が各トランザクションを承認することなく、ソフトウェアが継続的に動作するために作られている。通常のウォレットは人間がすべてのアクションをレビューし署名することを前提とする。本質的な違いは鍵を取り巻く権限モデルにある。スコープ化された権限、期限付きセッション、速い取り消し経路であり、ウォレットの残高やアドレスではない。

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

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

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

Alchemy(組み込みウォレットカストディアンに支えられたAgent Wallets)、Turnkey(エンクレーブベースのポリシーエンジンを備えたセキュアエンクレーブカストディ)、Crossmint(TEEに封印されたエージェント鍵を持つデュアルキーのスマートコントラクトウォレット)、Cobo(サーバー側のポリシーエンジンを備えたMPCカストディ)がいずれもこれを行っており、実施がどこにあるかでトレードオフが異なる。

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

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

AIエージェントのウォレットセッションを承認、検証、取り消すにはどうすればよいか

Alchemyダッシュボードで、あるいはセッションキーのEIP-712認可に署名することで、1回、人間が承認する。すべての不可逆的なアクションの前に 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 APIのセッションキーを通じてセッションをプロビジョニングする。

オンチェーンの決済を待たずにAIエージェントのオンチェーントランザクション権限を即座に取り消すための推奨アーキテクチャは何か

署名やブロードキャストの前にすべてのリクエストをチェックするバックエンドまたはエンクレーブのレイヤーに実施を置き、オンチェーンに保存された権限状態とは分離しておく。そこでの取り消しは、そのチェックを削除または無効化することを意味し、即座に有効になる。取り消しの経路がオンチェーンのバリデータや署名者の変更しかない場合、キルスイッチはブロック時間に縛られる。