2026年10月20日、なぜRevolutカードはすべて決済拒否されたのか?障害を徹底解説
今朝、レジ、給油機、ATMでRevolutカードが拒否されたなら、カードに問題があったわけでも、あなたに問題があったわけでもありません。2026年10月20日(火)の朝、Revolutは全社規模の障害に見舞われました。カード決済、送金、ATMでの引き出し、さらにはアプリへのログインまでもが、英国、フランス、スペイン、ドイツ、ギリシャ、そしてアイルランドの顧客に対して機能しなくなりました。Revolutは複数のサービスに影響するサービス障害を確認したと発表し、すべての顧客の資金とデータは安全だと述べました。最も可能性の高い引き金は、6時08分(UTC)、つまりパリ時間8時08分に始まった、GoogleのロンドンリージョンでのGoogle Cloud障害で、Googleはその後、これを電源イベントによるものとしています。事情に詳しい関係者がロイターに語ったところによると、Revolutの障害はこのGoogle Cloudの障害に関連していたとのことです。両社とも、この関連を公式には確認していません。
ライブ報道が伝えるのは、Revolutがダウンしているという事実だけです。決済チェーンのどこで障害が起きているのか、なぜレジでは時々通るのに無人の給油機では必ず拒否されるのか、ロンドンの一つのクラウドリージョンがどうやってフランスのガソリンスタンドでカードを止められるのか、までは教えてくれません。この記事ではそれらの疑問に答え、今回の障害を最近のロシアのデータセンターへの攻撃や、新たに公開されたLinuxの仮想マシンの脆弱性と切り分けた上で、発行会社の障害一つで二度と立ち往生しないために何を携帯すべきかをまとめます。
10月20日、なぜ私のRevolutカードは拒否されたのか?
そのカードで行われるすべての決済を承認する会社であるRevolutが、数時間にわたって応答できなかったからです。Clubicの報道によると、パリ時間8時頃から、アプリにはエラーメッセージが表示され、店舗やタクシーでカードが拒否され、送金も失敗しました。Revolutはフランスだけで800万人以上の顧客を抱えています。フランスのテック系メディアはレジとATMでの決済拒否を報じました。
Revolut自身のステータスページは、状況に追いつくのが遅れました。パリ時間9時42分の時点でも全システム正常稼働中と表示されており、その後になって、カード決済、送金、ATM引き出し、プレミアムサービス、ログインを含む31のサービスを一部利用不可として掲載しました。その朝の経過は以下のとおりです。
| 時刻(パリ) | 時刻(UTC) | 出来事 | 出典 |
|---|---|---|---|
| 8時00分頃 | 6時00分頃 | 8時頃から、Revolutアプリにエラーメッセージが表示され、店舗やタクシーでカードが拒否され、送金が失敗する | Clubic |
| 8時08分 | 6時08分 | Google自身のタイムラインによると、ロンドンリージョンeurope-west2でGoogle Cloudのインシデントが始まる | Google Cloudステータス |
| 9時42分 | 7時42分 | Revolutのステータスページは依然として全システム正常稼働中と表示。その後、31のサービスを一部利用不可として掲載 | Yahoo Finance UK |
| 9時50分 | 7時50分 | The Journalが報じたRevolutの声明:複数のサービスに影響するサービス障害、顧客の資金とデータは安全 | The Journal |
| 10時35分 | 8時35分 | Googleがインシデント開始から約2時間半後に最初の公式ステータス更新を投稿:europe-west2でのエラー増加と断続的なネットワーク障害 | Google Cloudステータス |
| 11時24分 | 9時24分 | Googleが顧客に対し、可能な場合は影響を受けたワークロードを別のゾーンまたはリージョンに移行するよう勧告 | Clubic |
| 12時11分 | 10時11分 | Revolutは、今朝問題が特定されて以来修正に取り組んでいると述べ、影響を受けたすべての人に謝罪 | Irish News (PA) |
| 13時00分 | 11時00分 | Googleの最新ステータス更新:エンジニアは依然調査中、原因は示されず、次回更新はパリ時間14時00分と予告 | Google Cloudステータス |
| 13時12分 | 11時12分 | Googleが、europe-west2-bゾーンでの障害は電源イベントが原因だと発表。電源イベントは緩和され、サービスは段階的に復旧中 | Google Cloudステータス |
| 13時25分 | 11時25分 | 最終確認時点:Googleのインシデントは依然継続中で、38の製品を掲載。サービスは復旧中、完全なインシデント報告書は未公表。Revolutからの復旧通知も原因に関する声明もなし | Google Cloudステータス |
10月20日パリ時間13時25分の時点で、Googleは障害をeurope-west2-bゾーンでの電源イベントによるものとし、電源イベントは緩和され、サービスは段階的に復旧中だと述べていますが、インシデントは依然継続中で、完全なインシデント報告書は公表されていません。Revolutからは復旧通知も出ておらず、原因も明らかにされていません。RevolutまたはGoogleが事後報告書を公表した時点で、この記事を更新します。
原因はRevolutか、Visaか、それとも店舗か?
すべてのカード決済には三者が関わります。店舗の端末とその取引銀行(アクワイアラー)がカード情報を読み取り、承認リクエストを送信します。カードネットワーク、つまりVisa、Mastercard、フランスではCBが、そのリクエストを中継します。そしてカードの背後にいる銀行である発行会社(イシュアー)が、リアルタイムで可否を回答します。10月20日については、Visa、Mastercard、CBからのインシデント報告は確認できず、他のカード発行会社からカードの問題も報告されていません。あらゆる証拠から見て、障害はカード発行会社としてのRevolutにあったことになります。
| チェーンの構成要素 | 誰か | 役割 | 10月20日に障害が起きたか? |
|---|---|---|---|
| 端末とアクワイアラー | 店舗の決済端末とその取引銀行 | カード情報を読み取り、承認リクエストを送信する | 他行のカードでは問題の報告なし |
| カードネットワーク | Visa、Mastercard、CB | リクエストを発行会社に中継する | いずれのネットワークでもインシデント報告は確認できず |
| 発行会社 | Revolut | リアルタイムで決済を承認または拒否する | はい:あらゆる証拠から見て、ここが壊れた |
発行会社の障害とは、カードの背後にいる銀行が決済ネットワークの承認リクエストに応答できなくなることで、店舗がどこであれ、国がどこであれ、すべての端末が一斉にそのカードを拒否する状態を指します。外から見てパターンが奇妙に見えたのはそのためです。カードはあらゆる場所で同時に使えなくなる一方で、隣の人は問題なく支払っていたのです。
これは、無人の給油機が毎回拒否したのに、レジでは時々カードが通った理由も説明します。フランスの24時間無人給油機は、ノズルを手に取る前に、スタンドが設定した上限額、多くの場合100〜150ユーロの承認を発行会社に求め、給油後に実際の金額に置き換えます。この事前承認には発行会社からのリアルタイムの応答が必要なため、発行会社が沈黙している間、給油機は毎回ノーと答えます。給油機は発行会社の障害を可視化するだけで、障害の原因ではありません。通った決済があった理由として考えられるのは、一部の端末が少額をオフラインで承認して後で精算できることで、Clubicが大半のカードが拒否される中、一部のRevolut顧客は一部の店舗で支払いができたと報じたのは、そのためかもしれません。
Google Cloudと私の銀行カードにどんな関係があるのか?
多くの銀行やフィンテック企業は、ソフトウェアの大部分を借り物のクラウドインフラ上で動かしており、そのインフラが落ちれば、サービスも一緒に落ちることがあります。Googleによると、問題は6時08分(UTC)に始まりました。約2時間半後のパリ時間10時35分に投稿された最初のステータス更新は、ロンドンリージョンであるeurope-west2でのエラー増加と断続的なネットワーク障害を報告しました。カード保有者にとって、この空白は重大でした。約2時間半の間、Googleのステータスページには何も表示されず、パリ時間9時42分の時点でRevolutのページも全システム正常稼働中と表示していたのです。The Registerは、europe-west2-bが同リージョンの3つのアベイラビリティゾーンの一つであると指摘しています。Googleのインシデントページには、Kubernetes Engine、Cloud Run、BigQuery Data Transfer Serviceを含む影響を受けた38の製品が掲載され、Googleは影響を受けたすべての人への謝罪を投稿しました。パリ時間13時12分、Googleは最初の原因を明らかにしました。更新には「電源イベントにより、europe-west2-bゾーン内で障害が発生していました。電源イベントは緩和されています」と記され、サービスは段階的に復旧中とされています。Googleの声明は自社のゾーンに関するものであり、Revolutには言及していません。パリやフランクフルトを含む欧州の他のGoogleリージョンでは、問題は報告されていません。
Revolutとの関連は、あくまで関係者の話であり、確認されたものではありません。事情に詳しい関係者がロイターに語ったところでは、Revolutの障害はGoogle Cloudの障害に関連していたとのことですが、Revolut自身の声明はGoogleに言及していません。The Journalは、この障害はサードパーティプロバイダーの障害に起因すると見られていると、社名を挙げずに報じました。同じ朝、英国のDowndetectorにはLloyds、Halifax、Bank of Scotland、HSBC、NatWest、Santander UK、MBNAに加え、Royal Mail、Rightmove、GOV.UKの報告急増が表示され、ドイツのINGの顧客はオンラインバンキングとアプリへのログインに問題を抱えました。これらの報告をGoogle Cloudと公式に結びつけた者は誰もおらず、またDowndetectorの急増は誤解を招くこともあります。不安になったユーザーが、実際には正常なサービスを確認しに行くからです。
最終的な事後報告書が何を語るにせよ、この出来事の形には見覚えがあります。9月にChatGPT、Claude、Grokが同時に落ちたとき、共有クラウドが第一の容疑者とされ、結局は原因ではないと判明しました。今回は、単一のクラウドリージョンが最有力の説明ですが、依然として未確認です。多くの企業が同じ建物を借りていれば、その建物の一つの欠陥が一瞬にして全員の欠陥になり得ます。そして今回、問題となったサービスは、あなたのポケットの中のカードだったのです。
サイバー攻撃だったのか、ロシアのデータセンター攻撃と関係があるのか?
入手可能な証拠に基づけば、いいえです。2026年10月8日以降、ウクライナのドローンはサソヴォ、カルーガ、ウラジーミルのYandexのデータセンターを攻撃し、ロシアと近隣諸国でYandexのサービスに支障が出ました。これらの攻撃についてはこちらで詳しく取り上げています。これらの攻撃に関する報道は、欧州の銀行、カード決済、西側のクラウドプロバイダーへの影響に一切言及していません。Revolutはロシアで事業を行っていません。Revolutの障害はロンドンのGoogleの施設の問題と時期が重なったものであり、二つの出来事を結びつける情報源はありません。両者に共通するのは一点だけです。どちらも、重要なサービスが少数の物理的な建物に集中していることを示しています。しかし一方はインフラへの軍事攻撃であり、他方はごく普通のクラウド障害であって、両者を混同しても誰の得にもなりません。
ハッキングを示すものもありません。侵入を報告した情報源はなく、Revolutは顧客の資金とデータは安全だと述べており、同じく今朝影響を受けた家計管理アプリのEmmaは、自社の問題を技術的な障害でありセキュリティ侵害ではないと説明しました。事後報告書が出るまでサイバー攻撃を正式に排除することはできませんが、今日見える限りのすべては攻撃ではなくクラウドインシデントを指しており、Google自身も現在、ロンドンの障害をeurope-west2-bゾーンでの電源イベントによるものとしています。完全なインシデント報告書はこれから公表される見込みです。
LinuxのPwnEscape脆弱性のせいか、それとも相次ぐクラウド障害の一つか?
二つ目の疑問にも同じ扱いが必要です。新たに公開されたLinuxの脆弱性が背後にあった可能性はあるのでしょうか。障害の5日前の2026年10月15日、LinuxカーネルのCVEチームはCVE-2026-99999、通称PwnEscapeを公開しました。カーネルのネットワークコード、具体的にはIPv4チェックサム処理における重大な脆弱性で、CVSS 3.1で10点中9.3と評価されています。評価が高いのは、このバグが可能にすることのためです。悪意あるゲスト仮想マシンが細工したネットワークパケットを送信することで、稼働先のホストマシンのカーネルを破壊でき、研究者たちは自身のラボでホストのメモリ漏えい、ホストのクラッシュ、ホスト上でのroot権限によるコード実行を実証しました。この脆弱性は、特定のハイパーバイザーではなく、ゲストのトラフィックを処理するLinuxネットワークスタックに存在します。
発見自体は秩序立ったものでした。研究チームのPWN.AIはVercelのサンドボックスセキュリティチャレンジの最中にこのバグを発見し、9月4日にカーネルメンテナーに非公開で報告、修正は10月14日にLinuxカーネル本体に取り込まれました。さらに重要なのは、実際の悪用が報告されていないことです。CVEエントリーに記録された10月16日のCISAの評価には「悪用:なし(Exploitation: none)」と記載されており、この脆弱性はCISAの既知の悪用された脆弱性カタログにも載っていません。Googleはこれに関するセキュリティ情報を公表しておらず、10月19日までの同社のセキュリティ情報にも言及はありません。Googleはロンドンの障害をeurope-west2-bゾーンでの電源イベントによるものとしており、Revolutの声明はGoogleにも脆弱性にも触れておらず、Emmaは自社の問題を技術的な障害でありセキュリティ侵害ではないと説明しました。PwnEscapeと今回の障害を結びつける信頼できる情報源はありません。
とはいえ、背景にある流れは現実のものです。この秋は大規模なクラウドインシデントが相次ぎました。9月1日には、定期的なルーターメンテナンス中に切断されたネットワーク光ファイバーケーブルが原因で、Google Cloudのアイオワ州us-central1リージョンの2つのゾーンの一部が、米国太平洋時間7時41分から11時52分までの約4時間孤立し、16の製品に影響しました。9月30日から10月1日にかけては、ExpressRoute、VPN Gateway、Azure Firewall、Application Gateway、Azure VMware Solutionを含むMicrosoft Azureのゲートウェイサービスが、20時30分(UTC)から18のリージョンで混乱し、Microsoftはインフラのオペレーティングシステム保守作業との相関を挙げました。10月8日と9日には、ロードバランシングの設定更新がus-central1のGoogle Cloud Storageノードに過負荷をかけ、2日間で合計約18時間にわたる書き込みエラーを引き起こしました。
これらの報告から導かれる公正な結論はこうです。インシデントの連続は現実であり、どれほど多くのものが一握りのプロバイダーに依存しているかを示しています。しかし、公表された原因はメンテナンス作業、設定変更、キャパシティであり、これらの報告のいずれも攻撃や脆弱性に言及していません。ロンドンの障害は、今やこのパターンに当てはまります。Googleはこれを電源イベント、つまり攻撃ではないもう一つの原因によるものとしていますが、完全なインシデント報告書はまだ公表されていません。
なぜ障害の後にフィッシングメッセージが来るのか?
障害は、詐欺師に出来合いのストーリーを与えるからです。何千人もの人がたった今カードを拒否され、不安になり、銀行からの連絡を待っています。カードが停止されたという偽のSMSに情報確認用のリンクが付いていれば、普通の火曜日よりも今日のような日の方がはるかに信じられやすいのです。今後数日間、SMS、メール、電話でその波が来ると想定してください。
特にRevolutについては、これを深刻に受け止めるべき理由があります。2026年9月、イタリア政府の規制当局を装い、正規の政府ドメインからメールを送った攻撃者が、約650人の顧客のデータを入手しました。その中には身分証明書、写真、口座明細、取引履歴が含まれていました。Revolutはこれを高度な外部によるなりすまし詐欺と呼び、自社のシステムと顧客の資金は影響を受けていないと述べ、影響を受けた人々に連絡しました。この漏えいは10月20日の障害とは無関係ですが、一部の顧客の実際の情報が出回っていることを意味し、フィッシングメッセージが本物らしく個人に宛てられたものに見える原因になります。
本物の銀行サポート担当者がPIN、パスワード、ワンタイムパスコード、カード情報を必要とすることはなく、電話をかけてきたからといってアプリでの承認を求めることもありません。疑わしい場合は電話を切り、アプリから銀行に連絡してください。障害に関するメッセージ内のリンクは開かず、アプリを直接開いてお知らせを読んでください。防波堤として、Le VPNのThreat Protectionは、既知のフィッシングやマルウェアのドメインを読み込まれる前にブロックします。SMSの受信自体を止めることや、生まれたばかりの詐欺ドメインをすべて捕捉することはできないため、あなた自身の警戒心が第一の防衛線であることに変わりはありません。
次回、立ち往生しないためには?
次のRevolut障害を防ぐことはできませんが、自分にとっては何事もなかったことにできます。
- 別の発行会社のカードを2枚目として携帯する。Revolutの2枚目のカードは、1枚目と一緒に使えなくなります。フランス在住者であれば、CBネットワークのフランスの銀行カードが良い補完になります。承認するのが別の発行会社だからです。
- 現金をいくらか持っておく。燃料と食料に足りる程度です。RevolutのATM引き出しも止まっていたので、引き出すタイミングは障害の最中ではなく、その前です。
- ガソリンスタンドでは、発行会社の障害中は無人給油機より有人の窓口を試す価値があります。ただし、そこでも拒否される可能性はあります。
- まずステータスページとアプリ内のお知らせを確認する。カードがブロックされた、あるいは不正利用されたと決めつける前に、発行会社がインシデントを報告していないか確認してください。Revolutは、カードの凍結、利用限度額、保留中の3-Dセキュア確認、無効化された決済タイプといった通常の拒否理由も一覧にしており、具体的な理由はアプリに表示されます。
- 慌ててカードを凍結、解約、再設定しない。発行会社の障害中にそれをしても何も変わらず、解約したカードはサービス復旧後に再発行を待つことになります。
- Revolutサポートを名乗って連絡してきた相手には、絶対に情報を渡さない。今日のような日は特にです。
- タイムスタンプ付きのスクリーンショットを保存する。決済拒否や送金失敗で金銭的な損害が生じた場合に備え、サービス復旧後にアプリからRevolutサポートに申し立ててください。
役に立たなかったであろうものが一つあります。VPNです。これはVPNプロバイダーである私たちが言うことです。カードの承認は端末、カードネットワーク、発行会社の間で行われ、フランスのVPNサーバーを経由していようがいまいが、あなた自身の接続は決済が承認されるかどうかに関与しません。VPNはあなたの通信を保護し、Threat Protectionと併せて、今日のような日の後に出回る詐欺ドメインの多くをフィルタリングします。しかし、銀行を動かし続けることはできません。
Googleはeurope-west2-bゾーンでの電源イベントという最初の原因を明らかにしましたが、完全なインシデント報告書はこれからです。報告書が出たとき、注目すべき点は三つあります。電源イベントが具体的に何を停止させたのか、RevolutがGoogle Cloudとの関連を自らの言葉で認めるかどうか、そして欧州中のレジでカードがすでに拒否されていたのに、なぜ同社のステータスページが全システム正常稼働中と表示していたのか、です。
執筆者について
Le VPN ニュースデスク
Le VPN Research Team は Le VPN ブログのニュースデスクです。インターネット遮断、検閲、新しいプライバシー法、サイバーセキュリティインシデントの動きを追い、出典の明確なわかりやすい報道に仕上げています。すべての記事は一次情報源に基づいて作成され、その情報源と照らし合わせてファクトチェックを行ったうえで、公開前に Le VPN の編集ルールに沿ってレビューされます。
Le VPN Research Team の記事 →