トークン承認とは、トークンのインターフェース標準ERC-20のApproveなどを通じて、指定した相手にトークンの利用枠を与える仕組みです。ウォレットの接続は支出権限の付与とは異なり、接続を解除しても承認は自動的には消えません。EIP-20は承認額の照会と利用を定義し、EIP-2612は条件を満たす署名で承認額を設定できるようにします。有限額の例で、効力・利用・取り消しを区別します。資料の確認日は2026年10月27日です。
サイトに接続し、確認画面を読み、署名します。画面上では似た操作が続きますが、そのたびに同じ権限を渡しているわけではありません。ログインの確認もあれば、相手が後からトークンを動かせるようにする要求もあります。
この違いは、数字を一つずつ追うと分かりやすくなります。本記事では、上限20を設定し、12が使われ、残った8をゼロにする一つの仮定を使います。何を確認して初めて「完了」と言えるのかを、操作の順番に沿って見ていきます。
接続・トランザクション・署名は、それぞれ権限が違います
接続しただけの状態と、特定の相手にトークンの支出を許可した状態は別です。 まずはウォレットと管理権限の基本に立ち返り、各画面で何を求められているかを確認します。
ウォレットの接続だけで支出権限が付くわけではありません
接続は通常、サイトが公開アドレスを取得したり、以後の操作を要求したりする入口です。接続したことと、特定のトークンを使う許可を与えたことを同じ記録にしないでください。MetaMaskの公式資料「Disconnect wallet from a dapp」も、接続解除でトークン承認は取り消されないと注意しています。すでにチェーン上にある承認額を変えるには、別の操作が必要です。
ERC-20でいうspenderは、保有者に代わってトークンを使えるよう許可されたアドレスです。コントラクトの場合も、通常のアカウントの場合もあります。条件を満たせば、transferFromを通じて保有者から受取先へトークンを移せます。「ルーター」と表示されているだけで、正規の相手だと確認できるわけではありません。
ApproveとPermitでは、効力を持つまでの流れが違います
Approveは通常、チェーン上のトランザクションとして承認額を変更します。ウォレットで送信しただけで完了とはせず、成功した結果と、その後の承認額を確認します。未確定の段階で、新しい額がすでに有効になったとは扱えません。
Permitのような署名型の許可には、チェーン外で署名を作り、本人または別の人が後からチェーン上に提出する仕組みがあります。自分がその場でネットワーク手数料を払わなくても、許可が無害になるわけではありません。署名の内容と、いつ・どの条件で提出できるかを読む必要があります。ほかのプロトコルには独自の署名や利用の仕組みがあり、同じ取り消し方法を一律には使えません。ハードウェアウォレットの使い分けも、この内容確認の代わりにはなりません。
承認を調べるときは、四つの識別情報を固定します
どのネットワークで、誰の、どのトークンを、誰に使わせるかをそろえて初めて、同じ承認を比較できます。 一つ違えば、同名のトークンや似たアドレスでも別の状態を見ている可能性があります。
ネットワーク・保有者・トークンコントラクト・spenderを照合します
承認額を調べる際は、ネットワーク、保有者の公開アドレス、トークンのコントラクト、spenderを記録します。allowance(owner, spender)は、対象のトークンコントラクトで、保有者が相手に与えている利用枠を調べるための呼び出しです。銘柄名だけではコントラクトを特定できません。
spenderと最終的な受取先も、必ずしも同じではありません。相手に支出権限を与えることは、特定の一つの受取先だけを許可することと同義ではないためです。実際の制限はコントラクトの仕組みによるので、画面のサービス名だけで範囲を決めつけないようにします。
承認額と残高は、別々の数字です
残高は、そのアカウントが現在保有する量です。承認額は、指定した相手が条件に従って使える量です。上限を大きくしても手数料が免除されるわけではなく、残高がある範囲で許可を使われる可能性が広がります。承認額が現在残高より大きければ、後で入ったトークンも対象になり得ます。20を承認しても残高が20増えたり、その場で20が送られたりはしません。
本記事は、使用するたびに有限の承認額が減るモデルに限定します。最大値を指定した場合に額を減らさない実装などもあるため、後の「20から12を引いて8」という計算を、すべてのトークンや無制限承認に当てはめることはできません。12しか必要ないなら、なぜそれより大きい枠を求めるかを理解し、次回の便利さだけで確認を省略しないようにします。
一つの例で追う：20を承認し、8が残り、0にします
以下は仕組みを確認するための仮定で、実際の承認・署名・送金は行っていません。 アカウントAの残高をトークンTの100単位とし、相手Sに20の利用枠を与えます。その後、Sが12をRへ移し、残った枠を取り消す流れです。A・T・S・Rは説明用の記号で、実在の配置先や運用成績を示しません。
手順1：現在値0を確認し、今回の上限20を決めます
操作前に四つの識別情報を照合し、その組み合わせの承認額が0であると確認した時点を記録します。Sによる利用が本当に必要か、信頼できる画面のSのアドレスと一致するかも確認します。これで分かるのは対象の一組が0ということだけで、ほかのトークンや相手の権限もすべてゼロだと確認できたわけではありません。
今回の上限20は説明用の設定です。使う予定の量と許可範囲を先に決め、表示されたトークンやSが予定と違えば操作を中止します。サイトの要求額に合わせて、理由なく上限を広げる手順にはしません。
手順2：Approveの成功後に、承認額20を再確認します
Approveの送信前に、送信先、呼び出し内容、承認額、手数料を読みます。トークンの最小単位で表示された整数と、人が読む単位の違いにも注意が必要です。表示を比較するときは、そのトークンの小数桁数に従って単位をそろえます。
送信後も、未確定なら承認額20が有効になったとは記録しません。成功を確認し、同じ組み合わせを問い合わせて20になっていることを確かめます。この時点では、例のトークン残高は100のままです。Approve自体のネットワーク手数料に使うネイティブ資産は、トークンTの残高と分けて扱います。
手順3：12の利用成功後は、残高88・承認額8になります
次に、SがtransferFromを使ってAからRへ12単位のTを移し、その処理が成功したと仮定します。有限の承認額が減り、ほかに変動がない本例では、残高は100 − 12＝88、承認額は20 − 12＝8です。88と8は違う対象を数えているので、一致する必要はありません。
実際の確認では、正しいトークンと受取先の転送記録、残高、承認額を照合します。別の入出金や承認変更があれば、88・8になるとは限りません。処理が失敗したなら、成功を前提とした12の減算をそのまま記録してはいけません。
残った8も利用可能な許可です。コントラクトに別の制限がなければ、先ほどのR以外が受取先になる可能性もあります。「今回の送金は終わった」ことと「残りの権限が消えた」ことを分けて判断します。
手順4：取り消しの成功を待ち、承認額0を確認します
残りを取り消すために0を設定しても、そのトランザクションが未確定なら、以前の8が利用できる状態のままかもしれません。どの処理が先に実行されたかが重要です。成功を確認してから再度問い合わせ、承認額0と、ほかに変動がなければ残高88であることを記録します。
8の許可を取り消しても、8単位が残高へ返ってくるわけではありません。まして、すでに移った12を取り戻す処理ではありません。
EIP-20では、ゼロでない承認額を別のゼロでない額へ変更する際の順序の問題も扱っています。いったん0にする画面設計があっても、それだけであらゆる競合や危険を防げるとは限りません。実装によって額を増減する別の方法や制限もあります。攻撃が疑われるときは、上限の変更を繰り返すのではなく露出したものを評価します。
承認額0では解決しない、二つの問題があります
ゼロになったのは指定した組み合わせの現在の承認額であり、過去のすべての署名や秘密鍵の状態ではありません。 ここからは、前の20・8・0の例に含めていない別の条件を見ます。
まだ提出されていないPermitは、別に確認します
EIP-2612型のPermitは、署名、nonce、deadlineなどの条件を満たすと、後から承認額を設定できる場合があります。nonceは署名の再利用を防ぐための値、deadlineは提出の有効期限です。期限内だから安全という意味ではなく、ほかの条件とともに有効性を判断します。
通常のapprove(0)で現在の承認額を0にしても、あらゆる種類の未提出署名が自動で無効になるわけではありません。どの方式の署名か、すでに使われたか、どの条件が残っているかを分けて調べます。前の仮定にはPermitはなく、ここで二回目の支出が実際に起きたと付け加えてはいません。
秘密鍵が漏れていれば、取り消しだけでは管理権限を変えられません
秘密鍵を持つ人は、新しいトランザクションを作れる可能性があります。一つの承認額を取り消したり、アプリのパスワードを変えたりしても、相手が持つコピーは消えません。秘密鍵・シードフレーズ・パスワードの役割を分け、影響する管理元を確認する必要があります。
ただし、不審な承認が一つ見つかっただけで、秘密鍵の流出まで証明されたことにもなりません。何を渡したか、どの処理が成功したかに応じて調べます。ウォレット侵害時の確認手順では、権限の問題と管理用の秘密の漏えいを区別しています。
署名の前に、入口・対象範囲・手数料を確認します
管理ツールに表示された情報は確認の手掛かりであって、すべての権限が載るという保証ではありません。 毎回、相手・範囲・効力を持つ方法を説明できるか確かめます。画面が読めない、情報が合わない、サイトが照合を省くよう急がせる場合は止めます。事後の棚卸しは、次の不明な署名の安全を保証しません。
信頼できる入口から、ツールの対応範囲を確かめます
知らない相手のメッセージ内リンクから承認管理を始めず、自分で確認した公式の入口を使います。公開情報の問い合わせに、シードフレーズや秘密鍵を渡す必要はありません。ツールが別の操作を求めてきた場合は、「調べるだけ」と思い込まず、その要求を改めて読みます。
MetaMaskの公式資料「Spending caps」は、支出上限の確認と取り消しを説明しています。ただし、一覧に出せる権限はツールの対応範囲に依存します。表示がなくても、ほかのチェーン、非代替性トークン（NFT）の操作権限、独自のプロトコル署名がないとは言えません。本記事のERC-20の例を、それらの処理ルールにそのまま置き換えることもできません。
ネットワーク手数料と中止条件を一緒に確認します
Approveや取り消しは通常、チェーン上の手数料を必要とします。署名型の許可では、提出する別の人が手数料を払う場合もあります。誰が手数料を払うかと、誰にトークンを使わせるかは別の問題です。失敗した処理のガス代の考え方では、準備額と実際の費用を分けて説明しています。
日常の管理なら、まず費用と予算を確認して操作を判断します。一方、スイーパーボットが疑われる場合に、取り消しを完了させようと旧アカウントへネイティブ資産を補充してはいけません。このプログラムは入金を監視し、自動で素早く資産を移します。承認額だけでなく中止条件も計画に書くことで、権限の対処中に新たな資産を危険にさらすのを避けます。
本記事は仕組みの説明と仮定の例であり、実際の承認や取り消しは行っていません。個別の資産処分を勧めるものではありません。トークンやプロトコルの実装は異なり得ます。侵害が疑われるときは、実際の記録と信頼できる公式サポートに基づいて判断してください。