6分で読めます
エージェント型ウォレット vs 従来の暗号資産ウォレット：何が変わるのか
暗号資産取引所、取引プラットフォーム、決済サービスプロバイダー（PSP）を運営しているなら、すでに機能するウォレットインフラをお持ちでしょう。鍵は管理され、出金は実行され、スイープは定刻どおりに動いています。いま検討すべきは、「エージェント型ウォレット（agentic wallet）」が何かの作り直しを意味するのか、それとも既存の資産の上にコントロールレイヤーを追加することを意味するのか、という点です。
短い答えは、後者です。エージェント型ウォレットは新しいウォレットの種類ではありません。署名レイヤーの手前にプログラマブルな認可ロジックを置いた、馴染みのあるセルフカストディウォレットと同じものです。カストディモデルも、鍵のアーキテクチャも、トランザクションフローも、すべて変わりません。変わるのは、AIエージェントに何の署名を許すのか、どの条件下で許すのか、どんな監査証跡を伴わせるのかを、どう制約するかです。
2025年9月には、AP2が60社以上のパートナー（Coinbase、Mastercard、PayPal、Revolut）とともにローンチされ、Mandateベースのエージェント認可が標準となる見通しです。エージェントの署名内容を制約できないインフラは、取引相手が構築を進める標準と、すでに噛み合っていません。
この区別は、構築の意思決定において重要です。
従来のセルフカストディウォレットが実際に優れている点
何が変わるかの話に入る前に、従来のウォレットインフラが正しく果たしている役割について率直に述べておく価値があります。エージェント型という論調は、ときに既存の構成が壊れているかのようなニュアンスを伴いますが、そうではありません。
従来のセルフカストディウォレットは、鍵の完全な所有を提供します。秘密鍵を持つのはあなたであり、いかなるカストディアンも、あなたに代わって資金を凍結したり、回収したり、アクセスを失ったりすることはありません。運営者にとって、これはベースラインです。また、決定論的な実行も提供します。トランザクションが署名・ブロードキャストされれば、仲介者も、承認キューも、タイムアウトもなしに実行されます。スピードと最終性が重要な多くの運用ワークフローでは、これこそが利点なのです。
セルフカストディウォレットは、鍵ペアをクレデンシャルとして、オンチェーンのプロトコル、API、決済レイヤーに直接接続します。この合成可能性（コンポーザビリティ）こそが、暗号資産インフラをプログラマブルにしているものです。さらに、署名されたすべてのトランザクションはオンチェーンに残り、偽造不可能な署名と永続的な記録を持ちます。監査可能性のために追加のコストはかかりません。
これらは注意点ではありません。このアーキテクチャが生き延び、いまやエージェント型システムがその上に構築すべき基盤となった理由です。
エージェントのワークロードで従来型の認可が破綻する箇所
問題はウォレットではありません。従来のウォレットが、人間の意思決定サイクルの中で動く人間の署名者向けに設計されていた、という点です。
人間がトランザクションに署名するとき、その人は署名の瞬間に判断を働かせます。金額、宛先、タイミングを見て、決める。その判断こそが認可のコントロールなのです。
AIエージェントはそうは動きません。エージェントは数百、数千の判断を自律的に行い、そもそもループの中に人間がいないことも少なくありません。判断を働かせるために立ち止まることもありません。与えられた指示と、セットアップ時に付与された権限に基づいて実行します。権限が広すぎれば、調整機構のない署名ループが生まれます。狭すぎれば、エージェントは仕事を果たせません。
数分に一度動く人間の署名者に機能する認可モデルは、署名者が継続的に動くプロセスになると、即座に破綻します。
エージェントのワークロードに必要なのは、別のウォレットではありません。ウォレットを制約するプログラマブルな認可ロジックです。どの金額まで自律的に署名できるか、どの宛先が許可されているか、承認はどれだけ有効か、閾値を超えたら何が起きるか――そうしたルールです。このロジックは、エージェントと署名イベントの間に置かれます。
新興の標準は、これを形式化し始めています。2025年9月に発表され、A2AとMCPのオープン標準の上に構築されたGoogleのAgents-to-Payments（AP2）プロトコルは、Mandateと呼ばれる暗号署名付きのデジタルコントラクトを使い、エージェントが支払いを実行する前にユーザーの意図を証明します。AP2は従来型の決済と暗号資産／ステーブルコインの両方をサポートします。Coinbase、Ethereum Foundation、MetaMaskが共同開発したx402拡張は、AP2の中のHTTP 402ベースの暗号資産／ステーブルコインレイヤーです。
プロトコルレイヤーは着実に構築されています。運営者にとっての問いは、自社のウォレットインフラがそこに接続できるかどうかです。
「エージェント型ウォレットインフラ」が実践的に意味するもの
「エージェント型ウォレット」という言葉は、プログラマブルな認可アーキテクチャを備えたウォレット導入の略称です。具体的には、次の4つを意味します。
第一に、署名前に実行される支出ルールです。エージェントはトランザクションリクエストを送出します。署名レイヤーに届く前に、ルールセットがそれを評価します。金額はエージェントの認可上限内か？宛先は許可リストにあるか？リクエストは有効な時間枠内か？ルールを通過すれば、トランザクションは署名されます。通らなければ、エスカレーションされるか拒否されます。
第二に、有効期限付きの承認です。9時に付与された承認が、市場が動き状況が変わった23時になっても有効のままであるべきではありません。ディスパッチ単位で可視化できる承認期限コントロールは、無期限ではなく時間で区切られた認可モデルを提供します。
第三に、ロール別のアカウントです。すべてのエージェントが同じ権限を必要とするわけではありません。マーケットメイキングのエージェントとペイアウトのエージェントでは、必要な署名権限が異なります。ロール別のサブアカウントにより、認可レベルをエージェントの機能に対応させることができ、メインアカウントはサブアカウントレベルでセッションの有効性とアクセス範囲を制御します。
第四に、偽造不可能な認可証跡です。すべての署名イベントには、どの認可パスを通ったかを証明する暗号学的な記録が必要です。単なるログエントリではなく、監査や紛争時に提示できる実際の署名チェーンです。
これがアーキテクチャです。ウォレットそのものは変わりません。あなたが構築するのは、その上のレイヤーです。
従来型の認可で十分な場合
すべての運営者が今日これを構築する必要はありません。手動の署名コントロールを備えた従来型のウォレット構成は、次のような場合にうまく機能します。
- トランザクション量が少なく、各署名イベントを人間がレビューする運用が現実的に回る場合。
- エージェントが読み取り専用や照会タスクに限定され、署名権限を持たない場合。
- AIツールの初期の検証段階にあり、エージェントが必要とする署名範囲をまだ定義できていない場合。
- 規制・コンプライアンス上の位置づけにより、すべてのトランザクションに人間の承認が必要で、エージェントの完全な自律がそもそも範囲外になる場合。
エージェントがトランザクションに署名しないのであれば、エージェント型の認可レイヤーは不要です。先回りして構築しても、見返りのない複雑さが増えるだけです。
エージェント型認可を追加すべきとき
次のいずれかに当てはまるとき、認可レイヤーを構築してください。
- エージェントがすでに、あるいは今後、承認ループに人間を挟まずに、大量のトランザクションを自律実行する場合。
- AP2のように、エージェント実行の前にMandateベースの意図証明を要求する決済プロトコルと統合する場合。
- 現在の構成ではすべてのトランザクションに人間の承認が必要で、それがコンプライアンス要件ではなく運用上のボトルネックになりつつある場合。
- リスク特性の異なる複数種類のエージェントを運用しており、単一の権限レベルではすべてをカバーできない場合。
- コンプライアンスや取引相手の事情により、ログレベルではなく暗号レベルでエージェント認可を証明する監査証跡が必要な場合。
エージェントを大規模展開した後に認可アーキテクチャを後から組み込むコストは、最初から組み込む場合よりはるかに高くつきます。問題が顕在化してからではなく、いま考えておくべきだという主な根拠はこれです。
CoinsDoのWaaSインフラがこれにどう対応するか
CoinsDoは「エージェント型ウォレット」という単独の製品を提供しているわけではありません。インフラは、どのようなウォレット導入でも使うのと同じスタックです。エージェント型の認可レイヤーは、プラットフォームにすでに存在するコントロールを使って構築します。
CoinSendが認可ロジックを担います。
- カスタム承認フロー。レビュアー階層、閾値、高額トランザクション向けのエスカレーションロジックを備えます。エージェントのトランザクションリクエストも同じフローを通ります。署名の前にルールが発火し、閾値を超えればエスカレーションが作動します。
- 承認期限コントロール：各実行承認には設定可能な有効期限が付き、ディスパッチ記録ごとに確認できます。朝にエージェントが受け取った承認が、無期限に有効のままになることはありません。
- サブアカウントのロール管理。サブアカウントごとにきめ細かなロールを割り当て、メインアカウントが各サブアカウントのログインセッションの有効性を制御します。異なるエージェントには異なる権限スコープが与えられます。
- ガス代コントロール。手数料閾値に基づいてディスパッチを自動化します。手数料が許容範囲外のとき、エージェントは署名しません。
- 24時間365日の自動出金実行。継続的なペイアウト運用を支えます。
認可証跡はCoinSignを通じて管理されます。CoinSendの機能であるCoinSignは、RSA／HMAC-SHA256のデジタル署名を用い、モバイル、PC、ブラウザ拡張を横断するレビューを実現します。承認されたすべてのトランザクションには、偽造不可能な認可記録が残ります。APIは非対称署名による認証を使用しています。
入金側では、CoinGetが、自動のKYTアドレスリスクスクリーニングと、時間・残高・カスタムルールに基づいて複数アドレスの資産を集約する自動集金／スイープを担当します。ウォレットクライアントは、AndroidまたはPC／クラウドに3分以内でデプロイできます。
CoinsDoはどの時点でも秘密鍵を保持しません。エージェント型の認可レイヤーはセルフカストディの基盤の上に構築されます。これが、このユースケースに対する正しいアーキテクチャです。
とりわけ支出限度額の設計を評価している運営者には、実際の閾値とエスカレーションのロジックが配置される場所がまさにそこです。
エージェントが読み取り専用からトランザクション実行へと移行する段階にいるなら、いま目の前にある意思決定は認可アーキテクチャです。CoinsDoのWaaSインフラが、必要なコントロールレイヤーにどう対応するか、ぜひお問い合わせください。
よくある質問
エージェント型ウォレットは、別の種類のウォレットですか？
いいえ。エージェントが署名できる内容を制御する、プログラマブルな認可レイヤーを備えた標準的なセルフカストディウォレットです。カストディモデルと鍵のアーキテクチャは変わりません。
エージェント型認可を追加すると、セルフカストディを失うことになりますか？
いいえ。セルフカストディとは、秘密鍵をあなたが持つことです。認可ルールは署名レイヤーの上に位置してエージェントの振る舞いを制約するものであり、鍵の所有権を変えるものではありません。CoinsDoがあなたの鍵を保持することは、いかなる構成でもありません。
支出限度額とエージェント型認可レイヤーの違いは何ですか？
支出限度額は、認可レイヤーにおけるひとつのルールです。完全なエージェント型認可アーキテクチャには、支出限度額に加え、宛先の許可リスト、時間制限付き承認、ロール別アカウント、エスカレーション階層、暗号学的な認可証跡が含まれます。支出限度額だけでは、本番環境のエージェント導入には不十分です。
AP2プロトコルは、いつ構築上の論点になりますか？
エージェントがAP2を実装するプラットフォームを通じて支払いや受け取りを行うなら、認可レイヤーは実行の前提条件としてMandate検証を処理できる必要があります。まだAP2対応の取引相手と統合していない段階なら、注視する価値はありますが、直ちに構築要件になるわけではありません。
既存のウォレット導入に、作り直さずにエージェント型認可を追加できますか？
できます。ただし、基盤のウォレットインフラが、ハードコードされた挙動ではなく設定可能なレイヤーとして、ルールベースの承認フロー、期限付き認可、ロール別アカウントをサポートしている場合に限ります。インフラ選定が重要な理由はここにあります。構築の基盤となるウォレットは、これらのコントロールをAPIレベルで公開している必要があるのです。
