トークン承認とRevoke完全ガイド

▽ 要約

市況:放置されたallowanceが、いまも継続的な攻撃面です。
規制:ERC-20とNFT標準は、承認前提の操作フローで動きます。
インフラ:revoke.cashやEtherscanで承認確認と取消ができます。
リスク:無限承認、偽サイト署名、古い権限の放置が危険です。

dAppを日常的に使うほど、ウォレットには見えにくい承認が蓄積します。トークン承認は便利な反面、接続を切っただけでは消えず、不要な権限は残した瞬間から攻撃面になります。

unnamed 4

結論は明快です。承認管理は「付与時に絞る」「月1回棚卸しする」「不要なら0またはfalseへ戻す」の3点を徹底すれば、被害確率を大きく下げられます。本稿では仕組み、棚卸し手順、被害事例、今後の改善策までを実務目線で解説します。

承認の棚卸しとRevoke手順

棚卸しは難しくなく、確認、不要判定、取消の3段階に分けると迷いません。

最初に行うべきは、いま有効な承認を一覧化することです。revoke.cashではウォレットを接続するか、アドレスを入力するだけで、チェーンごとのERC-20承認やNFTオペレーター権限を確認できます。まずはネットワークを切り替えながら、使っていないdApp、見覚えのないspender、上限が極端に大きい承認を洗い出します。

次に行うのは、残す承認と消す承認の仕分けです。判断基準は単純で、直近も使う正規サービスか、承認額が必要最小限か、コントラクト名やアドレスに違和感がないかの3点です。旧キャンペーン、終了したブリッジ、試験運用のdApp、フリーミントを装ったNFTサイトの権限は、迷ったら取消側に寄せるほうが安全です。

取消の実行は、基本的にRevokeボタンを押してウォレットで承認するだけです。取消はオンチェーン取引なのでガス代がかかりますが、これは保険料と割り切るべきコストです。MetaMask PortfolioやEtherscan系のToken Approval Checkerでも同様の確認と取消ができるため、revoke.cashが使いにくい環境でも代替手段はあります。

どうしてもツールで見つからない場合は、手動での取消に進みます。ERC-20は対象トークンのapproveでspenderを同じまま金額を0に戻し、ERC-721やERC-1155の包括権限はsetApprovalForAllをfalseに戻します。初心者にはやや難しいため、通常は一覧ツールを先に使い、手動操作は最後の選択肢にするのが無難です。

背景

Approveは資産移転ではなく権限設定であり、ERC-20は金額、NFTはコントラクト単位の許可として理解すると整理しやすくなります。

ERC-20のApproveは、第三者に残高を渡す操作ではありません。所有者がspenderに対し、一定額までtransferFromできる権限を与える設定で、実際の移転は後続のコントラクト呼び出しで行われます。DeFiで預け入れやスワップをするときに承認が先に求められるのは、この設計が標準フローだからです。

NFTでは性格が少し異なります。ERC-721やERC-1155でよく出るSetApprovalForAllは、特定の1点ではなく、そのコントラクト配下のNFT全体をオペレーターに扱わせる権限です。売買や一括出品には便利ですが、誤って悪性サイトに与えると、コレクション単位で資産を動かされる余地が生まれます。

ここで誤解されやすいのが、ウォレットのdisconnectです。接続解除で止まるのは、サイトがあなたのアドレス情報を参照したり、新たな要求を出したりする権限にすぎません。承認そのものはブロックチェーン上に残るため、危険なのは「もう使っていないから安全」と思い込んで放置することです。

市場への影響

承認の悪用は個別の盗難で終わらず、dAppの信頼コストと新規参加者の心理的障壁を押し上げます。

2024-01-16のSocket事案では、新規デプロイ契約の脆弱性を突かれ、承認を残していたユーザー資産が流出しました。被害は約$3.3M、230ウォレットに及び、最大被害は約$656,000相当のUSDCとされます。ここで示されたのは、プロトコル本体に資金を預けていなくても、承認が残っていれば外部要因で引き出し面になるという現実です。

2024-07-16のLI.FI事案では、脆弱なfacet追加直後に悪用され、無限承認を残していたウォレットが標的になりました。公表ベースの被害は約$11.6M、153ウォレットで、有限承認は影響を受けなかったと整理されています。この差は、承認額を絞るだけでも被害上限を抑えられることを示しました。

さらに、フィッシング経由のウォレットドレイナーは、承認リスクを広く一般化させています。2024年のEVM系フィッシング損失は約$494Mと報告され、承認や署名をだまし取る攻撃がWeb3利用者全体のコストになりました。承認管理は個人防衛に見えて、実際にはエコシステム全体の参加障壁を下げる基礎インフラでもあります。

関連:【初心者向け2025】仮想通貨エアドロップの受け取り方|メタマスク安全策<詐欺対策>ガイド

論点とリスク

典型的な失敗は、無限承認、更新時の競合、署名内容を読まないままの承認の3つに集約できます。

最も多いのは、必要量を超えた大きすぎる承認です。dApp側は再承認の手間を減らすために巨大な上限を提示しがちですが、利用者から見れば「将来その契約が侵害されたときの引き出し余地」を広げているにすぎません。とくに休眠dAppへの古い承認は、残高が増えたあとに危険度が上がるため、放置コストが時間とともに膨らみます。

次に見落とされやすいのが、allowance変更時のレースコンディションです。既存額を別の額へ直接更新すると、トランザクション順序次第で旧額と新額の両方を使われる余地があるため、標準側でもapprove-to-zero-then-setが推奨されています。再設定時は、いったん0に戻してから必要額を入れ直す癖をつけるだけで、古典的な事故は避けやすくなります。

もう一つの論点は、ガスレス承認や署名ベース承認を安全だと誤認しやすいことです。EIP-2612のpermitやUniswapのPermit2はUX改善に有効ですが、署名対象が複雑になるほど、利用者が意味を理解しないまま許可してしまう余地も増えます。Permit2は有効期限を持てる一方、Permit2本体への元承認が残る点も含め、署名の読み飛ばしは禁物です。

実務上は、ウォレットを用途で分ける運用が効きます。高額資産を置くメインウォレットでは枯れたdAppだけを使い、エアドロップや新興プロトコルの検証は残高を絞ったサブウォレットに隔離します。承認管理はウォレット単位で発生するため、資産と実験を分離するだけで、万一の被害範囲を大きく限定できます。

今後の注目点

改善の方向は、恒久的な承認を前提にしたUXから、期限付き・単発・可視化重視の設計へ移りつつあります。

まず注目したいのは、承認そのものを短命化する流れです。EIP-2612はトークン側実装が必要ですが、1回の署名で承認を扱えるため、二段階操作を減らせます。Permit2は対象トークンを選ばず署名承認を広げられ、期限付きの下位承認も扱えますが、万能薬ではなく、読み解けない署名を増やす側面も同時に持ちます。

規格面では、同一トランザクション内だけ有効な一時承認を定義するEIP-7674が議論されています。これが広く実装されれば、使い切りの承認を標準化でき、放置allowanceそのものを減らせる可能性があります。ただし現時点では普及途上であり、今日の利用者が頼るべき防御は、あくまで定期棚卸しと最小権限運用です。

当面の現実解はシンプルです。承認額は必要量に寄せる、再設定時はいったん0へ戻す、月1回は承認を棚卸しする、見覚えのない署名は拒否する、この4点を習慣にしてください。トークン承認は危険な機能ではなく、管理しないと危険になる機能です。理解して運用できれば、Web3体験の利便性と安全性は両立できます。

▽ FAQ

Q. Approveすると、すぐに資産は抜かれますか?
A. いいえ。ERC-20のApproveは即流出ではなく、悪性spenderがtransferFromできる状態になるだけで、直後に盗難が確定するわけではありません。

Q. dAppをdisconnectすれば十分ですか?
A. 不十分です。MetaMaskのdisconnectは接続解除にすぎず、承認はオンチェーンに残るため、Revoke取引を別途送る必要があります。

Q. Revokeには毎回ガス代がかかりますか?
A. はい。EthereumやBaseの承認取消はオンチェーン取引なので、1件ごとにネットワーク手数料と実行ガスが発生します。

Q. Permit2なら、もう無限承認は不要ですか?
A. 一部は改善します。Uniswap Permit2は期限設定に有効ですが、Permit2本体への承認や署名読解の難しさは残ります。

Q. NFTのSetApprovalForAllはどう消しますか?
A. ERC-721/1155ではsetApprovalForAllをfalseに戻します。revoke.cashやEtherscan系ツールからでも実行できます。

■ ニュース解説

承認管理は、単なる小技ではなく、2024年以降のWeb3セキュリティで最も実務的な防御の一つになりました。攻撃者は秘密鍵を奪わなくても、古い承認、偽のPermit署名、侵害されたdAppを組み合わせることで資産に触れられるためです。

今後は、ウォレット側の警告改善、期限付き承認の普及、危険コントラクトの可視化が進むほど、利用者の自己防衛コストは下がります。ただし、標準やUIの進化があっても、最後に被害を分けるのは「何に、いくら、いつまで許可したか」を自分で把握しているかどうかです。承認は利便性の代償ではなく、管理対象そのものだと捉える視点が、次の数年のWeb3利用ではますます重要になります。
投資家の視点:評価すべきは、派手な利回りよりも、承認の可視化、署名内容の表示、権限期限の設定、インシデント時の告知速度をどこまで実装しているかです。

※本稿は一般的な情報提供を目的としており、特定銘柄・金融商品の売買を推奨するものではなく、投資助言ではありません。投資判断はご自身の責任で行ってください。

(参考:Ethereum Improvement Proposals、Revoke.cash、MetaMask、Etherscan、LI.FI、CertiK、Scam Sniffer)