インフラ観測by rvessa
収束障害発生/発表 2026/09/16 16:50最終更新 2026/09/18 10:40

【収束】Salesforce の大規模障害で PayPay の問い合わせフォームが約6時間使えず(2026年9月16日)

SalesforcePayPay

最新の更新 · 2026/09/18 10:40

収束済みの事象として記録を作成。Salesforce のステータス記録と PayPay の復旧告知、報道2本で、発生・復旧の時刻と影響範囲(問い合わせフォームに限られ、決済そのものの停止は確認されていないこと)を確認した。

分かっていること

  • 公式確認 Salesforce は、日本時間2026年9月16日16時50分ごろから17日0時26分ごろまで、コアサービス(Core Service)で「重大な遅延・断続的なエラー・一部サービスへのアクセス不能」が起きたと自社のステータス(Trust)に記録している。区分は serviceDisruption / severity: major。 [Salesforce Trust]
  • 公式確認 PayPay は「Salesforce社のシステム障害により、2026年9月16日(水)16:50頃から、各種お問い合わせフォームがご利用いただけない場合があります」と告知し、同じ告知に「9月16日(水)22:35頃に復旧確認いたしました」と追記している。 [PayPayからのお知らせ]
  • 公式確認 PayPay の告知が挙げている影響は「各種お問い合わせフォーム」であり、コード決済・オンライン決済が使えなくなったという記載は無い。この告知は「機能・サポート情報」に分類されていて、PayPay の「障害情報」の一覧には載っていない。 [PayPayからのお知らせ][PayPayからのお知らせ]
  • 公式確認 Salesforce は障害の最中に、原因を「内部のログインサービスからの応答待ちでリクエストが滞留し、サーバのリソースを消費している」と説明し、その後「レガシーのログインサーバに影響する外部依存の障害が原因と考えている」「コアシステムの構成要素のひとつで負荷が上がり、リクエストの処理能力が下がった」と更新している。 [Salesforce Trust]
  • 公式確認 Salesforce は third-party のインフラ事業者にも確認し、「先方の側に問題は無いと確認された」と記録している。 [Salesforce Trust]
  • 公式確認 Salesforce は日本時間9月17日3時59分ごろに事象を解決済みと宣言し、復旧時刻を15:26 UTC(日本時間9月17日0時26分)と記載した。根本原因の分析結果(rootCause)は現時点で公表されていない。 [Salesforce Trust]
  • 公式確認 報道(ITmedia NEWS)は、この障害を「7時間半の大規模障害」とし、Salesforce の年次カンファレンス Dreamforce の開催中に起きたこと、日本では平日夕方から深夜の時間帯にあたり多くの企業に影響したこと、PayPay のフォームにも影響が出たことを伝えている。 [ITmedia NEWS][ITmedia NEWS]
  • 公式確認 Salesforce は9月16日24時台以降、影響範囲は当初の見立てより狭く、影響は Hyperforce 環境の一部に絞られる、first-party の環境には影響が無かった、と更新している。9月17日にはサンドボックスが影響を受けていなかったとして対象インスタンスから除外した。 [Salesforce Trust]

分かっていないこと

  • Salesforce が言う「レガシーのログインサーバに影響する外部依存の障害」が具体的に何だったのか。根本原因の分析結果はまだ公表されていない。
  • PayPay 側で、問い合わせフォーム以外の機能(コード決済・オンライン決済・チャットサポートなど)に影響があったかどうか。告知はフォームについてのみで、他への波及は確認できていない。
  • 障害中に送信できなかった問い合わせが、復旧後にどう扱われたか(再送が必要か)。PayPay の告知に記載は無い。
  • PayPay 以外の日本の決済・EC 事業者で、同じ障害を理由にした告知を出したところがあるか。当サイトの確認範囲では見つかっていない。
  • PayPay が告知を掲出した時刻。告知ページには掲載日(2026年9月16日)しか記載が無い。

経過タイムライン

  1. Salesforce のコアサービスで障害が始まる(Trust の記録では 07:50 UTC)。PayPay の告知が挙げる問い合わせフォームの発生時刻も同じ16時50分ごろ。 [Salesforce Trust]

  2. Salesforce が最初の更新を出す。「全リージョンの複数インスタンスに影響する事象を調査中。重大な遅延・断続的なエラー・一部サービスへのアクセス不能が起きうる。ヘルプポータルからのサポートケース作成もできない」。 [Salesforce Trust]

  3. Salesforce が「内部のログインサービスからの応答待ちでリクエストが滞留している」と原因の方向を示す。 [Salesforce Trust]

  4. Salesforce が「レガシーのログインサーバに影響する外部依存の障害が原因と考えている」と更新。third-party のインフラ事業者側には問題が無いことを確認したとしている。 [Salesforce Trust]

  5. Salesforce がテスト用インスタンスでの修正の検証に成功し、全インスタンスへの展開を開始。 [Salesforce Trust]

  6. ITmedia NEWS が Salesforce の障害と PayPay のフォームへの影響を報じる。 [ITmedia NEWS]

  7. PayPay が問い合わせフォームの復旧を確認(告知の追記による)。 [PayPayからのお知らせ]

  8. Salesforce が後から復旧時刻として記載した時点(15:26 UTC)。以降、テレメトリは健全な状態が続いたとしている。 [Salesforce Trust]

  9. Salesforce が事象の解決を宣言。技術的な引き金と根本原因は今後の調査とした。 [Salesforce Trust]

  10. ITmedia NEWS が「7時間半の大規模障害から復旧」として続報を出す。 [ITmedia NEWS]

X の反応

話題の規模: 日本では平日(水曜)の夕方から深夜にかけての事象で、報道は SNS 上の反応が大きかったと伝えている。当サイトが直接確認できたのは公式告知と報道で、一般利用者の投稿は集計・引用のいずれも行っていない。

主な論点

  • 業務時間帯に CRM が使えず仕事が止まった、という企業利用者の反応
  • クラウドの信頼性を売る会社が自社カンファレンス(Dreamforce)の最中に落ちた、という皮肉
  • PayPay が使えないのではなく、問い合わせ窓口が使えないという切り分け

一般の利用者の投稿は件数・地域・時刻の集計としてのみ扱い、本文の埋め込みはしていません。

背景と経緯

この事象の位置づけ

まず、誤解を避けるために先に書く。この事象で PayPay の決済が止まったという告知・報道は無い。 止まったのは「各種お問い合わせフォーム」、つまり支払いそのものではなく、支払いで困ったときの窓口である。

そのうえで、当サイトがこれを記録するのは、上流の位置が今までの事例と違うからだ。 2026年7月16日の AWS CloudFront 障害や 2026年9月17日未明の Google Play 課金障害は、 いずれも決済の処理そのものが通る経路の上流だった。今回の Salesforce は決済経路には乗っていない。 乗っているのはサポートの経路である。

決済インフラの可用性を利用者の側から見ると、実際には2つの層がある。

  1. 払えるかどうか(決済処理の経路)
  2. 払えなかったときに問い合わせられるかどうか(サポートの経路)

2 が落ちても 1 は動く。ただし 1 と 2 が同時に落ちると、利用者は「使えないうえに連絡もできない」状態になる。 今回はたまたま 1 が無事だったが、別々の上流に乗っているものが同時に落ちない保証はどこにも無い。 この日の日本では、同じ 9月16日の深夜に Google Play の課金障害(上記の記事)も起きている。 時間帯がずれたため重ならなかったが、重なりうる組み合わせではあった。

もうひとつ、運用上の注意として記録しておく。PayPay のこの告知は 「機能・サポート情報」に分類されていて、「障害情報」の一覧には出ていない。 当サイトが下流の確認先として持っている PayPay の障害情報ページだけを見ていると、この事象は拾えない。 Salesforce のステータスも、当サイトが定期的に見ている上流(AWS・Cloudflare・Azure・Google Cloud・Google Play)には入っていない。 上流にも下流にも定点の網の外側があり、今回はその両方に該当した。

利用者が取れる代替手段

PayPay が告知で案内しているのは「復旧まで今しばらくお待ちください」に相当する内容だけで、 代替の連絡手段は示されていない。Salesforce の案内も、利用企業向けに 「サポートケースの作成ができない」と伝えるにとどまる。

告知の範囲で言えることは次の2点である。

  • 問い合わせフォームは 9月16日22時35分ごろに復旧確認済み。この時刻以降は通常どおり送信できる。
  • 障害中に送信できなかった問い合わせが復旧後にどう扱われたか(自動で届いているのか、 送り直す必要があるのか)について、PayPay は説明していない。障害の時間帯に送信を試みて エラーになった心当たりがある場合は、送れているかを前提にせず、送り直すほうが確実である。

復旧後の振り返り

  • 上流(Salesforce)の障害時間は約7時間36分(日本時間9月16日16時50分ごろ〜17日0時26分ごろ)。 下流(PayPay の問い合わせフォーム)の停止は約5時間45分(16時50分ごろ〜22時35分ごろ)で、 下流のほうが先に復旧している。Salesforce がリージョンごとに段階展開したという記録と整合する。
  • 経過の型は、当サイトが Google Play の事例で整理した「上流と下流がそれぞれ独立に事後告知を出す」型とは違い、 下流(PayPay)が障害の最中に上流の名前を出して告知した型だった。 利用者から見て原因の切り分けが最初からできていた点で、9月17日未明の Google Play の事例より情報は多かった。
  • 一方で、上流の Salesforce が復旧時刻を「15:26 UTC」と確定させたのは、解決宣言と同じ9月17日3時59分ごろで、 障害の最中には復旧見込みが出ていない。「いつ直るか」が分からない時間が長かった点は、 AWS CloudFront の事例と同じである。
  • 根本原因は未公表のまま。Salesforce は「技術的な引き金と根本原因を調査する」としているため、 事後報告が出た場合はこのページに追記する。

この記事の情報源

更新履歴

  • 収束済みの事象として記録を作成。Salesforce のステータス記録と PayPay の復旧告知、報道2本で、発生・復旧の時刻と影響範囲(問い合わせフォームに限られ、決済そのものの停止は確認されていないこと)を確認した。

この記事は、Grok による X 検索・Web 検索で集めた取材メモをもとに、Claude が編集方針に従って執筆・更新しています。 X の投稿に基づく情報と公式に確認できた情報はラベルで区別しています。誤りは訂正一覧で公開します。詳しくは編集方針。