Cursorに秘密鍵を貼り付けるのをやめる：コーディングエージェントにウォレットを持たせる方法

開発の真っ最中だとする。Cursor上のエージェントがコントラクト呼び出しを書き、ネットワークを選び、テストトランザクションを送る準備ができている。計画と署名済みトランザクションの間に立ちはだかるものはひとつだけ、鍵だ。そこであなたは秘密鍵をエージェントが読み込める.envファイルに貼り付け、作業を続ける。

このたった一つのステップこそが、多くの経験豊富な開発者がAIを実際の資金に触れさせない理由だ。秘密鍵はオールオアナッシングだ。一度エージェントがそれを読める状態になれば、そのウォレットにあるものはすべて、どのチェーン上でも、永久に、取り消す手段もなく動かせてしまう。そしてエージェントは設計上確率的だ。ほとんどの場合は非常に優秀だが、時々自信満々に間違える。

もっと良いやり方がある。鍵を渡さずにウォレットを渡すのだ。以下では、それがAlchemy CLIのagent walletsでどう機能するか、そして実際の限界がどこにあるかを説明する。

問題は鍵であって、エージェントではない

エージェントをリスクとして扱いたくなるが、エージェント自体は実はそれほど問題ではない。秘密鍵はそもそも共有されることを想定して設計されていない。「これだけの額まで送れる」「これらのチェーンでのみ」「今後1時間だけ」「いや、今すぐ止めろ」といった概念が一切ない。それは完全な制御権を与える単一の秘密であり、使う唯一の方法はそれを露出させることだ。

これまで、開発者には2つの選択肢しかなく、どちらも実際のコストを伴っていた。鍵を.envに貼り付けて、エージェントに資金の完全な制御を与えることを受け入れる方法だ。これでは、たった一度の意図しないプロンプトでウォレットが空になりかねない。あるいは、ウォレットSDKを自前のバックエンドに組み込み、認証、署名、失効を自力で再構築する方法もあるが、これはほとんどのチームが手を出すべきではない数週間の作業になる。前者はリスクが高すぎ、後者はコストが高すぎる。

本当に必要なのは、スタックの他の部分ですでにアクセスについて考えているやり方に近いものだ。ルートパスワードを配ったりはしない。スコープを絞った認証情報を発行し、何ができるかを設定し、終わったら失効させる。ウォレットも同じように機能すべきだ。

agent walletsの仕組み

Alchemy CLIのagent walletsを使えば、ダッシュボードからウォレットを作成し、ターミナルにスコープを絞った期限付きのセッションを付与し、エージェントにコマンドラインから実際のトランザクションを送らせることができる。秘密鍵はCLIに触れることも、Alchemyに触れることも、.envファイルに置かれることもない。これは、それぞれ別の当事者が所有する3つの層として捉えるとわかりやすい。

カストディ層:鍵は他者が保持する

ウォレットの秘密鍵は、私たちの組み込みウォレットパートナーであるPrivyが、彼らのインフラ上で保持している。ラップトップにも、リポジトリにも、私たちのシステムにもない。これがリスク計算を変える点だ。あなたが.envに貼り付けようとしていた秘密は、今やあなた自身もエージェントも直接扱うことのないものになっている。

セッション層:エージェントに与えられるのは秘密ではなく権限

alchemy wallet connectを実行すると、CLIはあなたのマシン上で新しいP-256鍵ペアを生成し、その秘密鍵側はデバイスから外に出ることはない。ブラウザがAlchemyダッシュボードを開き、そこでウォレットを選びセッションを承認する。承認により、あなたのCLIの公開鍵がそのウォレット上の署名者として追加され、特定の機能に限定され、あなたが設定した有効期限で区切られる。

それ以降、すべての署名呼び出しは2段階のチャレンジになる。私たちのバックエンドがPrivyが期待する正確なペイロードを構築し、あなたのCLIがそのバイト列をローカルで署名し、その後にのみリクエストがPrivyに届く。セッションが期限切れになっている、失効している、あるいはバインディングチェックに失敗している場合、次の署名試行は私たちのインフラを離れる前に拒否される。エージェントはあなたが保持する秘密を通じてではなく、あなたが定義したセッションを通じて動作している。

コントロール層:キルスイッチはあなたが持つ

ウォレットの作成や失効ができるのはダッシュボードだけであり、失効はワンクリックで即座に反映される。ターミナルからalchemy wallet disconnectを実行することもできる。セッションが意図しない動作を始めたら、それを終了させれば署名は止まる。セッションが正しく振る舞うことをただ願うだけの状況に置かれることはない。いつでも終了させられるからだ。

エージェントが実際にできること

セッションが有効になると、エージェントは幅広いトランザクション操作を扱えるようになる。EVMチェーン上では、ネイティブトークンやERC-20の送金、コントラクト呼び出し、ERC-20の承認管理、スワップ、メインネット間のブリッジが可能だ。Solana上では、SOLやSPLトークンを送金できる。トランザクションはWallet APIsを通じて実行されるため、Gas Managerによるガススポンサー、バッチ処理、自動リトライ、ERC-20でのガス支払いも付随してくる。

CLIはエージェント向けのツールサーフェスとして構築されているため、あなたのエージェントはこれらのコマンドを自ら把握する。--jsonフラグは構造化された出力を返し、--no-interactiveはコマンドがプロンプトでブロックされるのを防ぎ、alchemy agent-promptはすべてのコマンド、フラグ、エラーコードを記述したJSONドキュメントを出力する。それをシステムプロンプトに組み込めば、エージェントは一度に全体の操作範囲を把握できる。統合すべきSDKはなく、ドキュメントから推測させる必要もない。

これは誰のためのもので、どんなフローに適しているか

これは、CursorやClaude Codeで日々オンチェーン開発をしている開発者向けだ。DeFiプロトコルを統合したり、決済フローを組んだり、コントラクトをテストしたりしていて、署名が必要な時点で止まるのではなく、エージェントに実際にトランザクションを実行させたい人だ。エージェントにコードを書かせたあと、オンチェーンの部分だけ手作業で仕上げた経験があるなら、これがそのギャップを埋める。以下の2つのフローで、その価値がよくわかる。

一つ目は、ビルドとテストのループだ。あるプロトコルと統合していて、エージェントがコードを書き終えたとする。それが実際に動くかどうかを知るには、誰かが実際のトランザクションを送る必要がある:コントラクトに資金を送り、呼び出し、結果の状態を確認し、調整し、もう一度実行する。これを手作業で行うと、すべてのトランザクションを自分で承認して貼り付けることになり、まさにエージェントを導入して排除したかった面倒な作業そのものになる。セッションを使えば、ウォレットを作成し、少額の残高を入金し、短い有効期限を設定したセッションを承認し、エージェントにループ全体を実行させることができる。エージェントは送信し、結果を読み取り、あなたが見ている間に繰り返し、セッションが期限切れになれば、そのアクセスは自動的に終了する。

二つ目は、複数ステップのオンチェーンタスクを実行するエージェントだ。単一の呼び出しではなく、一連の作業になることもある:メインネット上でトークンをスワップし、収益をL2にブリッジし、それをポジションに預ける、といった具合だ。各ステップを自分で実行する代わりに、結果を記述してエージェントにセッションを通じてそのステップを実行させることができる。セッションが制限するのはエージェントがどの機能をどれだけの期間使えるかであって、どれだけの額を動かせるかではない。したがって、そのタスクに必要な分だけウォレットに資金を入れ、短い有効期限を設定し、終わったら失効させる。

境界線について率直に見ておく

お金を扱うツールは、作り手がその限界について明確であるほど信頼しやすい。本番環境でこれに頼る前に知っておくべき、いくつかの限界を挙げる。

ガスと手数料スポンサーシップのポリシーはトランザクション手数料を制御するものだ。ウォレットの支出上限ではないので、Gas Managerのポリシーをエージェントが動かせる額の上限として扱ってはならない。スワップとブリッジは現時点ではEVMメインネットのみだ。セッション署名者は生のEVMトランザクションを直接署名するわけではなく、アクションはwallet_prepareCallsやwallet_sendCallsといったAlchemy Wallet API呼び出しを通じて実行される。そしてセッションは、あなたがダッシュボードで設定した通りにスコープされる。設定した有効期限と機能こそが実際の境界であり、単なる目安ではない。

これらはどれも回避策ではなく、システムが本来そう動くように設計されている。ウォレットがカストディを保持し、セッションが権限を運び、そして終了させる権限はあなたが持ち続ける。

始め方

CLIのagent walletsは今すぐ利用可能で、ウェイトリストも別料金プランもない。必要なのはNode 22以上とAlchemyアカウントだ。3つのコマンドで、エージェントが操作可能なウォレットにたどり着ける:

接続ステップはダッシュボードを開き、そこでセッションを承認し、そのスコープと有効期限を設定する。状態を変更するワークフローの前には、エージェントにまずセッションを検証させる:

作業が終わったら、セッションを終了させる:

オンチェーンで最も要求水準の高いプロダクトを構築しているチームは、すでにAlchemyの上で動いており、100以上のチェーンにわたり年間1兆ドル以上を動かしている。agent walletsの意義は、その同じインフラが、鍵を渡すことなく、コーディングエージェントに渡すウォレットを支えるようになったことだ。Cursorに秘密鍵を貼り付ける代わりに、スコープを絞ったセッションをエージェントに与え、いつでも失効させられる状態を保てる。

agent walletsのドキュメントを読む、Alchemy for agentsを見る、あるいはCLIをインストールして試してほしい。

FAQ

秘密鍵を共有せずにAIコーディングエージェントにウォレットを持たせるにはどうすればいいですか?

Alchemyダッシュボードでウォレットを作成し、ターミナルでalchemy wallet connect --mode sessionを実行する。CLIがローカルで鍵ペアを生成し、ダッシュボードがスコープを絞った期限付きのセッションを承認する。エージェントはそのセッションを通じてトランザクションを送信し、秘密鍵はウォレットプロバイダーの下に留まり、決して露出しない。

秘密鍵は実際どこに保存されていますか?

ウォレットの秘密鍵は、Alchemyの組み込みウォレットパートナーであるPrivyが、彼らのインフラ上で保持している。あなたのマシン、リポジトリ、.envファイルに書き込まれることは決してなく、CLIやAlchemy自身のシステムに触れることもない。あなたのエージェントは、鍵そのものではなく、承認されたセッションを通じて動作する。

エージェントのウォレットへのアクセスを失効させることはできますか?

できる。Alchemyダッシュボードからワンクリックでセッションを失効させるか、ターミナルでalchemy wallet disconnectを実行する。失効は即座に反映され、そのセッションからの次の署名試行は拒否される。セッションは、承認時に設定した時刻に自動的に期限切れにもなる。

agent walletでエージェントは何ができますか?

EVMチェーン上では、エージェントはネイティブトークンやERC-20の送金、コントラクト呼び出し、承認の管理、スワップ、メインネット間のブリッジができる。Solana上では、SOLやSPLトークンを送金できる。トランザクションはAlchemyのWallet APIsを通じて実行されるため、ガススポンサー、バッチ処理、リトライ、ERC-20でのガス支払いが利用できる。

スポンサーシップポリシーはエージェントが使える金額を制限しますか?

いいえ。ガスと手数料のスポンサーシップポリシーはトランザクション手数料を制御するものであり、ウォレットの残高ではない。支出上限ではない。エージェントができることの実際の境界は、ダッシュボードでセッションに設定した機能と有効期限であるため、セッションは意図的にスコープすべきだ。

始めるには何が必要ですか?

Node 22以上とAlchemyアカウントが必要だ。CLIのagent walletsはウェイトリストも別料金プランもなく利用可能だ。npm i -g @alchemy/cli@latestでインストールし、alchemy authを実行し、alchemy wallet connect --mode sessionでダッシュボードからセッションを承認する。