先に結論を出します。ただし1本のランキングにはしていません。QR決済で守るのは「アカウント」、電子マネーで守るのは「媒体と残高」で、防御の構造が別物だからです。理由は第6章で嫌でも分かります。

QRコード・バーコード決済6サービス

達成率＝得点÷（満点28−N/A分）。開示率＝（満点28−N/A分）÷28。順位は達成率ではなく得点の絶対値で並べています（達成率だけ見ると、何も書いていないサービスが100%になってしまうため）。

電子マネー4サービス

第1章 おわり — 次は第2章「銀行と決済は法律の土台が違う」

ここが今回いちばん大きな発見でした。銀行口座のお金と、PayPay残高やSuicaの残高は、守っている法律が別物です。

「補償方針を作って情報提供せよ」と言われているだけ、というのがどういう意味を持つのか。金融庁のガイドラインを読むと、補償方針に何を書くべきかがはっきり指定されています。

注目してほしいのは「補償の有無」という部分です。つまり「補償しません」と書くことも、制度上はまったく正しい対応なのです。

だから nanaco は公式FAQで「補償はございません」と書けます。楽天Edy は「原則として払戻しや盗難・紛失時の残高補償はできません」と書けます。モバイルSuica は「原則として、当社は責任を負わない」と書けます。各社が不誠実なのではなく、法律が「補償せよ」と言っていないのです。この一点を知らずに「大手だから補償されるはず」と思い込んでいると、いざというときに足元が抜けます。

意外なことに、相談が多いのは新しいQR決済ではありません

もうひとつ、公式の数字で直感がきれいに裏返る話をします。内閣府の消費者委員会が2026年8月3日にまとめた資料には、支払手段ごとの決済額と消費生活相談の件数が載っています。これを割って「1兆円あたり何件の相談が出ているか」を計算してみました。

出典：消費者委員会 支払手段の多様化と消費者問題に関する専門調査会 第19回（2026年8月3日）資料1「取りまとめについて（案）」p.8。決済額は経済産業省公表資料、相談件数は国民生活センター資料。決済額は暦年・相談件数は年度で単位が混在しているため、正確な比率ではなく桁の感覚として読んでください。1兆円あたりの件数は筆者の計算です。

決済額はコード決済が電子マネーの2倍以上あるのに、相談件数は電子マネーのほうが約2倍多い。比率で見ると約4倍です。「新しいQR決済のほうが危ない」という感覚は、少なくともこの数字の上では成り立ちません。そして後払い決済の桁違いの多さは、また別の記事で扱うべき話です。

第2章 おわり — 次は第3章「採点方法・決済版7つの壁」

銀行の記事で使った「7つの壁」は、口座開設から送金・被害補償までの流れに沿って防御を7段に分ける考え方でした。決済サービスでは、お金が動く場面が違うので壁を組み替えています。しかもQR決済版と電子マネー版で中身を変えました。

壁は7つ、各壁に2項目ずつ、1項目2点。合計28点満点です。

電子マネーの壁④だけ、逆向きに採点しました

「残高上限が低いほど加点」というのは一見おかしく見えますが、電子マネーは第6章で見るとおり盗られた分が戻ってきません。だとすれば、入れられる金額の天井が低いこと自体が防御になります。現行のモバイルSuicaの上限2万円は、この基準では最も安全です。そして2026年秋に予定されている「上限30万円」への引き上げは、この基準では減点になります。この逆説は第7章で詳しく書きます。

0点とN/Aを、意地でも分けました

銀行8行の記事では、8点と12点の差が結局「情報開示の丁寧さ」の差でしかなく、体感できる安全性の差とは限らないと書きました。今回はその反省を採点方式そのものに組み込んでいます。

そのうえで2つの数字を出します。達成率＝得点÷（28−N/A分）で「書いてあることをどれだけ満たしているか」、開示率＝（28−N/A分）÷28で「そもそもどれだけ説明しているか」。守りの強さと説明の丁寧さを、最初から別の列に分けたわけです。

第3章 おわり — 次は第4章「QR決済6サービスの防御を並べる」

まず入口です。壁①〜③、アカウント・端末・チャージの防御を横に並べます。

続いて壁④〜⑥、支払い・検知・停止です。

24時間365日の監視を公式に明記しているのは、6社のうち3社（PayPay・d払い・メルペイ）だけでした。楽天については注意が必要で、楽天カードは24時間365日のAI監視を明記していますが、楽天ペイ／楽天キャッシュのページには記載がありません。別サービスの説明を混ぜて「対応済み」と数えるわけにはいかないので、ここはN/Aとしています。

AEON Payは「開示していない」のではなく「見つけにくい場所に置いてある」

入口の説明（壁①〜⑤）が薄いためAEON Payは6位になりましたが、これを「対策が弱い」と読むのは間違いです。実際に「資金決済法に基づく情報提供」のページを開いてみると、むしろ補償の細部はPayPayに次いで詳しく書かれていました。

つまりAEON Payの弱点は対策そのものではなく、情報の置き場所です。「安全への取り組み」という分かりやすい1枚にまとまっておらず、法定の開示ページと利用規約PDFに分散しています。PayPayやd払いのように読者が最初にたどり着けるページで説明していれば、順位はもっと上でした。

なお混同されがちですが、イオンカードの「利用停止手続日を含めて61日前まで遡って補償」はクレジットカードの制度で、前払式支払手段としてのAEON Pay残高の話ではありません。この2つは別物です。

第4章 おわり — 次は第5章「補償の時計」

ここがこの記事の山場です。4社が「原則全額補償」と書いています。しかし差は金額ではなく、時間制限と過失の線引きにありました。まず「何日以内に申請しなければいけないのか」を図にします。

各社の公式案内・利用規約・資金決済法に基づく表示から作図。d払いにはこの30日とは別に「申告した日から遡って90日より前の不正利用は対象外」という制限があります（軸が違うため図には含めていません）。au PAYは「申告日から60日以内の決済のみ」という書き方で、起点が他社と少し違います。AEON Payは日数ではなく「直ちに停止措置を講じ、連絡すること」という書き方なので、日数の軸に乗らず図には含めていません。

そして期限だけを見ていると足元をすくわれます。全10サービスの補償条件を、対象外の条件まで含めて並べます。

「重大な過失」と「過失」は、まったく別の話です

表のなかで見落としやすいのが、右から2番目の列です。PayPay・d払い・au PAYは「故意または重大な過失」があるときに補償しないと書いています。ところが楽天キャッシュの資金決済法に基づく表示は「会員等の故意又は過失に起因する損失である場合」を対象外と書いています。「重大な」が付いていません。メルペイも「故意・過失がある場合には補償金額を減額」としています。

法律の言葉としての「重大な過失」は、ごく普通の不注意より一段重い、ほとんど故意に近いような落ち度を指します。そこに「重大な」があるかないかで、実際に補償されるかどうかの分かれ目はかなり動きます。

AEON Payはもうひとつ別の書き方をしています。「故意または重大な過失」を対象外にしたうえで、「銀行口座又はクレジットカード等の利用・管理について、管理不十分、利用上の過誤その他の帰責性がある場合」も対象外と加えているのです。「重大な過失」に届かない普通の管理ミスも読み込める書き方で、実質的な広さは楽天ペイに近くなります。

どのサービスが良い悪いという話ではありません。「全額補償」の4文字だけでは何も分からないということです。

第5章 おわり — 次は第6章「電子マネーに7番目の壁は無い」

第1章で「2つのランキングを合算してはいけない」と書いた理由がここです。電子マネー4サービスについて、公式が何と書いているかをそのまま引用します。

4社に共通しているのは、「止めた時点で残っていた残高を、新しいカードに移す」までしかしないという設計です。使われてしまった分は戻ってきません。だから電子マネーでは、壁⑤（見つける）と壁⑥（止める）の速さが、そのまま被害額を決めます。

問題は「止まるまでに丸1日かかる」ことです

残高上限・窓口の受付時間は日本資金決済業協会の掲載情報。受付時間は電話窓口のもので、Webからの停止手続きは別に用意されている場合があります（モバイルSuicaは会員メニューサイトから手続きします）。それでも、電話でしか動けない状況になったときにこの差は効いてきます。

注目してほしいのは3行目です。モバイルSuicaもnanacoも、停止手続きをしてから実際に止まるまでに翌日までかかります。そしてJR東日本は、その空白を自ら明記しています。

これは隠さずに書いてくれているという意味で、むしろ誠実な記述です。ただし読者の側は、「落としてから丸1日、穴が空いたままになる」という前提で備える必要があります。オートチャージを設定している人は、その穴が残高上限で止まらず、クレジットカードの限度額まで広がる可能性があるということです。

第6章 おわり — 次は第7章「2026年に効く5つの変化」

FeliCaの脆弱性は「残高が盗まれる」話ではありません

CVE-2026-59776は、CVSS v4.0で7.0（重要度「高」）という数字が付いています。数字だけ見ると不安になりますが、評価ベクトルを読むと攻撃方法の欄がAV:P（Physical＝物理）です。つまり対象のカードに物理的に近づかないと成立しません。ネット経由で遠くから狙えるものではありません。

そして楽天Edy・nanaco・WAON・Suica・QUICPayはいずれも「影響はない」と公表しています。ソニーの説明にあるとおり、FeliCaを使うサービスのセキュリティはICチップ単体ではなく、カード・店舗端末・サーバーまで含めたシステム全体で作られているからです。楽天Edyも「ICカード・店舗の端末・サーバシステムまでを含んだ、独自のシステムセキュリティ」と説明しています。

それでもこのCVEに触れる価値があるのは、「パッチを出せない脆弱性」という珍しい事例だからです。欠陥がシリコンに焼き込まれているので、ソフトウェア更新では直せません。ソニーが2025年8月に公表してからJVNでの正式公表まで11か月かかったという経緯も含めて、ハードウェアの脆弱性がどう扱われるのかを知る良い教材です。

2026年秋、この記事の前提が崩れます

最後の行がいちばん大きい変化です。モバイルSuicaにコード決済が載ると、次の3つが同時に起きます。

サーバー管理になること自体は、止めるまでの空白時間が縮む可能性があるという意味で歓迎できる変化でもあります。ただし守るべき対象が「カード」から「アカウント」に変わるのなら、利用者側の備えも変わらなければなりません。パスキーの設定と、送金機能の扱いです。

第7章 おわり — 次は第8章「選び方と、今日やる設定」

点数の高い順に乗り換えるべき、という結論にはなりません。何を重く見るかで答えが変わるので、目的別に整理します。

第8章 おわり — 次はよくある質問