ウォレットの「署名」と「承認」は別物｜案内文で利用者に求める操作・求めない操作

ステーブルコイン決済に対応する案内ページを作るとき、「ウォレットで署名してください」「承認してください」という言葉を何気なく使っていないでしょうか。ウォレットの画面で利用者が押すボタンは似て見えますが、ある操作はその場で残高を動かし、ある操作は第三者に後から引き出す権限を渡します。そして、この区別がつかない利用者を狙って「公式」を名乗る署名依頼や承認依頼が出回ります。

本記事は、接続・送金・署名・承認の違いを基礎から整理し、事業会社の案内文・FAQ・ヘルプページで「当社が求める操作」と「当社が絶対に求めない操作」をどう明記するかに落とします。特定のウォレットアプリや事業者を勧めるものではありません。

ウォレットの4つの操作：署名と承認は何が違うか

まず用語です。ウォレットは、秘密鍵（資産を動かす指図に使う暗号の鍵）を保管し、指図に署名するソフトや機器です（管理の基礎は法人のステーブルコイン管理を参照）。利用者がウォレットで行う操作は、次の4つに分けると整理できます。

図: ウォレットの4つの操作と効果の違い（ERC-20・ERC-2612の仕様をもとに当サイト作成）。左の矢印は、署名の一部が承認と同じ効果を持つことを示す

接続は、一般にサイトへウォレットのアドレスを知らせる操作で、それだけでは残高は動きません。送金はトランザクション（台帳に記録される取引の指図）で残高を相手に移す操作で、記録された後は取り消せず、戻すには相手からの返送が必要です（オンチェーンの送付に組戻しはない）。残る2つが本記事の主題です。

「承認」は、相手に引き出しの枠を渡す操作

承認（approve）は、Ethereum系のチェーンで多くのトークンが採用するERC-20という共通仕様の機能です（チェーンが違えば仕組みも異なります）。仕様はapproveを、指定した相手（spender）が自分の口座から「上限額まで複数回」引き出せるようにする操作と定義しています。設定された残りの枠はallowance、相手が実際に引き出す操作はtransferFromと呼ばれます。

つまり承認した瞬間には何も起きません。残高が動くのは、後で相手がtransferFromを実行したときです。利用者から見ると「何も減っていないから大丈夫」と思える時間帯があり、ここが送金との大きな違いです。

もう1つ厄介なのが、署名の形をした承認です。ERC-2612が定めるpermitは、送金の手続き（トランザクション）ではなく署名したメッセージでallowanceを設定できるようにする拡張です。仕様は署名に期限（deadline）を持たせることを求めており、署名を受け取った側がそれを台帳に送るタイミングは受け取った側が決めます。利用者の画面には「署名」と出ても、効果は承認と同じになり得るということです。

なお、メッセージ署名の画面がわかりにくい問題は仕様の側でも認識されています。EIP-712は、署名するメッセージが従来は文脈の乏しい16進数の文字列として利用者に表示されていたことを課題に挙げ、内容を構造化して表示できるようにする規格を定めています。表示が改善されても、利用者が中身を読まずに押せば効果は同じです。だから案内文の側で、どの画面が出たら押してはいけないかを先に伝えておく意味があります。

承認の画面で利用者が読むべき2つの項目

正規のサービスでも承認を使う場面はあります。たとえば利用者に代わって契約（プログラム）が支払いを引き落とす設計では、事前にその契約への承認が必要になります。だから「承認は全部危ない」とは言えません。案内文で利用者に伝えるべきなのは、承認の画面で次の2つを読むことです。

1つ目は相手（spender）が誰かです。承認は「誰に」引き出しを許すかを指定する操作なので、相手が自社や取扱業者の案内した宛先と一致しない承認は、内容を問わず押すべきではありません。2つ目は上限額がいくらかです。ERC-20のapproveは上限額までの複数回の引き出しを許すため、1回の支払額よりはるかに大きい枠が入っていないかを確かめる必要があります。

ERC-20の仕様自体も、同じ相手への枠を別の値に変える際の攻撃手法に触れ、いったん0に設定してから新しい値を設定するよう利用画面を作るべきだと注記しています。枠の扱いは、仕様の段階から注意が要る論点として扱われているということです。案内文には、自社のフローで出る承認の相手と上限額の目安を、画面の例と一緒に載せておくと利用者が照合できます。

なりすましは「接続」から入り、「承認」で実害になる

JVCEAは、暗号資産の詐欺の手口として「ウォレットを接続すれば報酬がもらえる」「エアドロップに参加できる」といった誘導を挙げ、接続後にウォレット内の資産が勝手に送金されるなど、取り返しのつかない被害につながると注意を呼びかけています。秘密鍵やリカバリーフレーズ（鍵を復元するための単語列）の入力を「本人確認のため」などの理由で求める手口にも触れています。

前節の整理に重ねると、接続そのものより、接続した偽サイトが続けて求める署名・承認・鍵の入力が実害の引き金になる構図として読めます。

JVCEAは別の注意喚起（2025年12月24日）で、利用者に対し、業者のウェブサイトで「パスワード等をメールで求めることはない」といった方針を確認するよう勧めています。協会自身も、登録情報確認のお願いなどをメールで連絡することは絶対にないと明記しています。求めないことを公式に書いておくのは、利用者が偽の依頼を見分けるための材料を渡すことです。

事案：会員制ECが支払い案内を出した直後に偽の承認依頼が出回る

以下は当サイトが整理した架空の事案で、実在の企業・案件ではありません。

①既存事業と既存ユーザー：ホビー用品の会員制ECを運営する事業会社です。会員は個人中心で、公式SNSとメールマガジンでセール情報を発信しています。

②やろうとしていること：支払方法に円建てステーブルコインを追加します。利用者は自分のウォレットから、注文ごとに指定された宛先へ送金します。

③登録業者との役割分担：ステーブルコインの受け取りと着金の照合は、提携する登録業者の決済サービスが担います。EC側は注文画面への組み込みと案内、問い合わせの一次対応を担当します。

④想定される告知・導線：お知らせページ、決済画面の説明文、ヘルプページ、注文確認メール、公式SNSの告知投稿です。

公開から数日後、SNS上で同社のロゴを使った「公式キャンペーン：ウォレットを接続し、承認すると特典」という投稿が見つかったとします。同社の案内ページには「ウォレットで署名して支払います」としか書かれておらず、利用者が偽の依頼と見分ける手がかりがありませんでした。広告面での対処はSNSなりすまし詐欺広告の対策要請で整理していますが、ここで問題なのは、正規の案内文そのものが「当社は何を求めないか」を書いていなかったことです。

案内文に「求める操作／求めない操作」を書く

事案の会社の決済フローで利用者が行うのは、宛先と金額が決まった送金だけです。決済サービスによっては接続を伴うこともあるため、どの画面が出るかは取扱業者に確認して確定させます。そのうえで、告知面ごとに次のように書き分けます。

もし自社のフローで承認やpermitの署名が本当に必要なら、「求めません」とは書けません。その場合は、どの画面で、どの相手に、いくらまでの承認を求めるかを具体的に書き、それ以外は求めないと明記します。

FAQには、偽の依頼に応じてしまった利用者からの連絡も想定しておきます。JVCEAは被害に遭った場合の初動として、ウォレットの連携を解除すること、利用している取引所やウォレットサービスの公式サポートに連絡すること、DMやURL・送金履歴などの証拠を保存すること、相談窓口（警察相談専用電話#9110、消費者ホットライン188、協会の窓口）へ連絡することを挙げています。自社のFAQもこの流れに沿って書けますが、送金や引き出しはオンチェーンで記録された後は自社の操作で取り消せないため、「当社で取り戻せます」と読める表現は避けます。自社の決済に関係する被害かどうかの照合には、取引ごとの識別子が手がかりになります（着金確認の基礎）。

本記事の仕様と注意喚起は、2026年10月5日に次の原文で確認しました。ERC-20、ERC-2612、EIP-712、JVCEA「暗号資産に関する詐欺に遭わないために」、JVCEA「当協会や当協会会員を騙った勧誘や偽サイトにご注意ください」。

実務への示唆

最初の一歩は、利用者が押す画面を「接続・送金・署名・承認」に分けた1枚の表です。この表がないまま告知文を推敲すると、「署名してください」のような曖昧な言葉が残ります。

社内では、CSが「承認を求められた」という問い合わせへの一次回答と引き継ぎ先を決め、法務が「求めない操作」の表現を規約・契約と突き合わせ、情シスが公式ドメインの一覧と偽サイトの通報経路を用意します。

社外では、告知文・ヘルプ・決済画面の文言を作る広報・制作パートナーに表を仕様として渡し、キャンペーンやSNS投稿でも同じ文言を使うようレギュレーションに入れます。組んだ取扱業者のサポート窓口とは、画面の事実確認に加え、偽の署名依頼が出回ったときにどちらが何を告知するかを先に決めておきます。