AWS障害はなぜPayPayを止めた？クレカ障害との違いとは

2026年7月16日、Xのトレンド欄が「PayPay障害」の話題で埋め尽くされていました。私は最初「またPayPay単体のトラブルかな」と軽く見ていたのですが、調べてみるとこの日は朝と夕方で原因のまったく異なる2つの決済障害が重なっていたことが分かりました。単なる一企業のシステムトラブルではなく、私たちの生活を支えるキャッシュレス決済インフラの構造そのものが見えてくる、なかなか興味深い一日だったと感じています。この記事では、何が・いつ・なぜ起きたのかを整理しながら、暮らしにどう関係するのかを一緒に見ていきましょう。

正直、最初にニュースの見出しだけを見た時は「また大手のサービスがダウンしたのか」くらいにしか思っていませんでした。ですが時系列を一つひとつ突き合わせていくうちに、朝の出来事と夕方の出来事が別物だと気づき、そこから一気に整理する意欲が湧いてきました。難しく感じる方もいるかもしれませんが、要点を絞って丁寧に解説していきます。

結論：今日は「無関係な2つの障害」が同じ日に重なった

まず押さえておきたいのは、この日起きたのは1つの事件ではなく2つの独立した障害だったという点です。朝はクレジットカードの決済ネットワーク、夕方はPayPayが依存するクラウドインフラ。技術的な原因は完全に別物でした。

朝：クレジットカード決済網の障害（8時10分頃〜12時08分頃）

Visa傘下の決済基盤「CyberSource」と、国内のカード会社をつなぐ「CARDNET」でタイムアウトが発生し、コンビニやスーパーでのクレジットカード決済、モバイルSuica・PASMOへのチャージが一時的に利用できなくなりました。こちらは正午前には復旧しています。

夕方：AWSクラウド障害がPayPayに波及（17時頃〜18時30分頃）

午後4時45分頃、AWSの監視システムがAmazon CloudFrontという配信基盤で5xxエラーの急増を検知。ここからPayPayのアプリ起動やバーコード表示ができなくなる障害が始まりました。19時39分にはPayPay広報が「原因はAWS側」と正式に説明しています。

時系列で見るとより明確になる

朝の障害は8時10分頃に発生し、11時55分から12時08分頃にかけて順次復旧しています。一方、夕方の障害はAWS Health Dashboardが16時45分頃に異常を検知したことに始まり、17時台にPayPayの通信エラーが急増、17時40分頃には主要メディアが速報を出し、18時30分頃にほぼ復旧、19時39分にPayPay広報が公式に原因を説明するという流れをたどりました。こうして時系列を並べてみると、2つの障害の間には約5時間の空白があり、技術的にも時間的にも独立した出来事だったことがより明確になります。

なぜ利用者は「1つの大障害」だと誤解したのか

私自身も最初は「今日はキャッシュレス全体が終わった日」だと感じました。原因の異なる2つの障害が同じ日に重なったことで、SNS上では「サイバー攻撃では」「日本の決済インフラが同時多発的に崩壊した」という憶測まで飛び交っていたようです。実際には、偶然のタイミングの一致だったと理解しておくと、次に似た状況が起きても冷静に対応できると思います。

私が興味深いと感じたのは、こうした「偶然の重なり」がパニックを増幅させる構造そのものです。1つの障害だけなら「またか」で済んでいたかもしれませんが、朝と夕方で立て続けに起きたことで、多くの人の中で「今日は特別におかしい日」という印象が強く刻まれてしまったのだと思います。

夕方のAWS障害はなぜPayPayを止めたのか、仕組みを整理

アプリの「起動」自体がクラウド頼みだった

PayPayのアプリは、起動時にホーム画面やバーコードのデータをサーバーから読み込む仕組みになっています。その通信経路であるAmazon CloudFrontが不調になったことで、アプリを開くこと自体ができなくなりました。決済機能だけでなく、公式サイトまでもが同じ基盤でホスティングされていたため、一次情報を確認しようとした利用者がアクセスできないという二重の混乱も生まれています。

影響はPayPayだけにとどまらなかった

同じCDNを使うモバイルSuica（Android版）でもログイン障害が発生し、note やニコニコ生放送といった国内の主要Webサービスにも同時多発的にエラーが波及しました。特定の1社のミスというより、多くの企業が同じクラウド基盤に依存しているという、業界全体の構造が浮き彫りになった形です。

決済インフラのように「止まってはいけないサービス」が外部の基盤にどこまで依存すべきかという課題は、実は今回が初めてではありません。私も改めて調べていて、決済という業界そのものが抱える構造的なリスクの幅広さに驚かされました。決済代行という近い業界でも、事業構造そのものが行き詰まって破綻に至った例があります。全東信、負債1259億円で破産。決済代行ビジネスの構造と今後では、決済という「止められないビジネス」が抱える別種の構造的リスクを整理しているので、あわせて読んでみると理解が深まると思います。

みずほ銀行のメンテナンスという第三の要因

この日はさらに、みずほ銀行側の計画メンテナンスも予定されており、PayPayカードや一部チャージ機能が時間帯によって利用しづらい状態にありました。これは事前に告知されていた作業であり、AWS障害やクレジットカード網の障害とは無関係です。しかし利用者からすれば、同じ日に「予定されたメンテナンス」「朝の障害」「夕方の障害」という3つの事象が重なって見えたわけで、実際以上に大きな混乱として受け止められた背景の一つといえるでしょう。

復旧が約1時間半で済んだ理由

AWS側のインフラ復旧に伴い、PayPay側も順次サービスを正常化させ、18時30分頃には主要メディアが「ほぼ復旧した」と報じました。後述する過去の障害と比べても、比較的早い部類の対応だったといえそうです。

朝のクレカ障害との違い、混同されやすい理由

技術的な原因は完全に別物

朝の障害は国際ブランドの決済基盤とカード会社をつなぐネットワークのトラブル、夕方の障害はPayPayが利用するクラウドインフラのトラブルです。関わっている企業も技術要素もまったく異なります。

それでも「同一視」されやすい構造的な理由

一般の利用者からすると、見えているのは「レジで払えない」という同じ現象だけです。原因の違いを意識する機会がないまま、同じ日に2度も決済トラブルに遭遇したことで「デジタル決済全体が信用できない」という不安が増幅されたと考えられます。背景にある技術要素を知っているかどうかで、同じニュースの受け止め方が大きく変わる典型的な例だと思います。この視点はぜひ覚えておいてください。

似たような「仕様なのに障害や詐欺だと誤解される」構造は、決済以外の場面でも起きています。たとえばLINE安否確認はなぜ表示される？171との違いと詐欺の見分け方で扱った事例も、正常な仕組みの通知が利用者には異常事態のように映ってしまうという点で共通しています。仕組みを知っているかどうかで、同じ現象への受け止め方が大きく変わるのです。

情報源そのものが遮断される二次被害

今回特徴的だったのは、障害の影響がPayPayの決済機能だけにとどまらなかった点です。PayPay公式サイト自体も同じAWSのCloudFront上でホスティングされていたため、利用者が状況を確認しようとしてもアクセスできないという二次的な混乱が生まれました。一次情報が得られない状態が続くと、SNS上で未確認情報や憶測がより拡散しやすくなります。情報インフラと決済インフラが同じ基盤に同居していたことも、今回のパニックを大きくした一因だったと考えられます。

利用者から見た「わかりにくさ」も課題

技術的な原因が違っても、利用者にとっては「決済ができない」という結果は同じです。この情報の非対称性、つまり運営側は原因を正確に把握していても、利用者側にはその区別がリアルタイムで伝わりにくいという構造も、混乱を助長する要因の一つだったと考えられます。障害情報の発信タイミングや分かりやすさも、今後の各社の課題として残るところでしょう。

唯一の共通点は「決済インフラの単一障害点」

2つの障害に技術的なつながりはありませんが、どちらも「1つの基盤が止まると広範囲に影響が及ぶ」という単一障害点（SPOF）の構造を持っている点は共通しています。この視点を持っておくと、今後似たニュースに接した時にも冷静に整理しやすくなるはずです。

午前と夕方、2つの障害の影響時間を計算してみた

「結局この日、どれくらいの時間キャッシュレス決済に不安を抱えていたのか」を、実際に時刻データから計算してみました。

実際に計算してみた：朝は3時間58分、夕方は1時間30分

朝の障害は8時10分から12時08分まで続いたとされており、これは238分（3時間58分）にあたります。夕方の障害は17時から18時30分までの90分間（1時間30分）。単純に足し算すると、238分＋90分＝328分、つまり5時間28分になります。

1日の約23%が「決済に不安を感じる時間」だった

328分を1日24時間（1440分）で割ると、328÷1440×100≈22.8%。計算してみると、この日は1日の実に4分の1近くの時間帯で、多くの利用者が何らかの決済不安を抱えていた計算になります。数字にしてみると、SNSでの拡散が異常な規模になったことにも納得がいきました。

過去の障害と比べても長い部類ではない

ただし誤解してはいけないのは、この5時間28分は「2つの別々の障害の合計」であって、1回の障害が5時間半続いたわけではないという点です。個々の障害としては、後述する過去事例と比べても平均的か、やや短い部類に入ります。数字を分解して初めて見えてくる事実だと感じました。

こうした計算をしてみると、SNS上の「今日はもうキャッシュレス終わった」というような投稿が、実際の障害時間以上に大きな不安として広がっていたことも見えてきます。人の受け止め方は、実際の時間の長さだけでは決まらないということを、この一日はよく示していると思います。

過去の障害と比較して見える構造的リスク

2024年・2025年との比較表

比較項目	2026年7月16日（今回）	2025年4月15日	2024年5月15日
発生時刻	17:00頃〜18:30頃	17:15頃〜約1時間	12:15頃〜15:30頃
直接原因	AWS CloudFrontの通信不調	AWS東京リージョンの電源系統トラブル	PayPay中継サーバーの高負荷
復旧までの時間	約1時間半	約1時間	約3時間15分
特筆すべき背景	同日朝にクレカ網の障害が先行発生	データセンター設備の物理的トラブル	昼休みの決済ピークタイムと重複

3回のうち2回がAWS起因という事実

2025年4月と2026年7月、直近の大規模障害2回はいずれもAWS側のインフラトラブルが直接の原因でした。PayPay単体の企業努力だけではコントロールしきれない領域にリスクが存在しているということが、この比較から見えてきます。表にして並べてみると、原因はバラバラでも「クラウド頼み」という構造だけは一貫しているのが分かります。

似た構造の問題は、決済業界に限らず金融グループ全体の再建戦略においても重要な論点です。たとえば楽天グループは本当に復活できる？では、通信・金融インフラを自社でどこまで抱えるかという経営判断の難しさを扱っており、今回のテーマと合わせて読むと、決済・通信インフラの「どこまで外部に委ねるか」という共通の論点が見えてきます。

利用者としてできることは限られているが、無力ではない

こうした構造的なリスクは、規模の大きな企業ほど自社だけで抱え込まずに複数のクラウド事業者を併用する「マルチクラウド化」で軽減しようとする動きもありますが、コストや運用の複雑さとのトレードオフがあり、すべての企業がすぐに実行できるわけではありません。クラウド基盤側のリスクを個人が直接コントロールすることはできません。ただし、物理カードや現金という「クラウドに依存しない決済手段」を1つ持っておくこと、障害直後は取引履歴をこまめに確認する習慣を持つことは、誰でも今日から始められる備えです。私自身、今回の一件をきっかけに、財布の中に必ず数千円の現金を入れておくようにしました。便利さと引き換えに手放していたものを、少しだけ取り戻すような感覚です。なお、二重決済や返金に関する最終的な判断は、必ず利用した店舗やPayPayの公式窓口に確認するようにしてください。

賢く・美しく・暮らしを整えるアイテムたち

決済トラブルに振り回されない暮らしを整える意味でも、身の回りのアイテムを見直すのは良いきっかけになります。

あわせて読みたい

• RansomHouseとは？ニチレイを狙った身代金要求集団の正体
• 義援金と支援金の違いとは？電子決済で令和8年熊本地震に寄付する前に
• 楽天モバイルはなぜ地下鉄で弱いと言われる？2026年の技術背景と今後の見通し
• FAANGからMANGOSへ——2026年のAI覇権争いの構造と、日本の投資家が知っておきたいこと

よくある質問

Q. そもそも今回のPayPay障害はなぜ起きたのですか？

PayPayが利用しているAWSのAmazon CloudFrontという通信基盤で5xxエラーが増加したことが直接の原因です。PayPay広報も原因がAWS側にあることを正式に認めています。

Q. 朝のクレジットカード障害と夕方のPayPay障害は同じ原因ですか？

いいえ、まったく別の原因です。朝はVisa傘下のCyberSourceやCARDNETというクレジットカード決済網のトラブル、夕方はPayPayが利用するAWSクラウドインフラのトラブルで、技術的なつながりはありません。

Q. モバイルSuicaも影響を受けたと聞きましたが本当ですか？

本当です。モバイルSuica（Android版）もPayPayと同じCDN（CloudFront）をシステムの一部で利用しており、同時刻にログインしづらい状態が発生しました。

Q. オフライン支払いモードとはどんな仕組みですか？

インターネット接続が確認できない場合に自動的に表示される、事前生成済みのバーコードを使った決済方法です。店舗側の端末がオンラインであれば、過去24時間で5回・1回5万円までの範囲で決済を完了できます。

Q. なぜPayPayの公式サイトまで見られなくなったのですか？

公式サイト自体もAWSのCloudFrontを使ってホスティングされていたため、アプリと同時にサイトも閲覧しづらい状態になりました。一次情報にアクセスできなくなったことが、SNSでの情報拡散を加速させた一因と考えられます。

Q. 過去にも同じような障害はありましたか？

2025年4月15日にAWS東京リージョンの電源トラブルで約1時間、2024年5月15日にはPayPay中継サーバーの高負荷で約3時間15分の障害が発生しています。直近2回のうち今回を含む2回がAWS起因です。

Q. 「障害の補償をします」というSMSは本物ですか？

大規模障害の直後は、復旧や補償を装うフィッシングSMS・メールが増える傾向があります。文中のURLはタップせず、公式アプリの「お知らせ」欄で情報を確認することをおすすめします。

Q. PayPay銀行も止まっていたのですか？

銀行の基幹システム全体が停止したわけではありません。一部の外部連携チャージ等で影響が出た可能性はありますが、同日はみずほ銀行側の計画メンテナンスも重なっており、両者が混同されやすい状況でした。

Q. 今後もこうした障害は起こり得るのでしょうか？

多くの決済サービスが少数のクラウド事業者に依存している以上、同種の障害が今後も起こり得る構造は残っています。個人としては、現金や物理カードなど「クラウドに依存しない支払い手段」を1つ備えておくことが現実的な対策といえます。

Q. 復旧後に利用者が確認すべきことは何ですか？

アプリの取引履歴を開き、身に覚えのない重複決済や不自然な残高の減少がないかを確認してください。異常があれば、PayPayではなく利用した店舗に直接問い合わせるのが正しい手順です。