Spotifyで1日に2度の大規模障害が発生、ブラウザのコンソールから見えた原因とは

2026年7月27日、Spotifyでストリーミングやログインができない大規模な障害が1日に2度発生した。公式な原因発表はないものの、ブラウザのコンソールログからサーバー側のCORSポリシー設定エラーが原因である可能性が浮上している。同日にはT-MobileやMetaでも障害が起きており、ユーザーはオフライン再生などの自衛策を講じることが推奨される。

■1日に2度発生したSpotifyの障害

2026年7月27日（月）、Spotifyの月間アクティブユーザー7億6100万人の多くが、ストリーミング、ログイン、ライブラリ検索、アカウント管理を利用できなくなる障害に見舞われた。障害は2波にわたって発生したが、公式な説明は行われていない。技術に詳しいあるユーザーがブラウザのコンソールで発見した、Spotify自身の認証エンドポイントにおけるCORSポリシーの失敗が、社外の人間が得られる最も有力な答えとなっている。

最初の障害は早朝に発生し、アジア地域のユーザーがウェブプレイヤーやデスクトップアプリでエラーに直面した。Spotifyのコミュニティモデレーターは、「問題が発生しました（Something went wrong）」や「ページが利用できません（Page not available）」というエラーの報告を認識し、約1時間で修正が展開された。これで解決したかに見えた。

しかし、アジア地域の問題が解決に向かう中、モデレーターは新たな別の問題が発生していることに気づいた。世界のほとんどの地域で「現在再生できません（Can't play this right now）」というエラーが広がり始めたのだ。この第2波はより深刻で、長引いた。Downdetectorでは太平洋時間午前11時43分（日本時間28日午前3時43分）までに3,000人以上のユーザーが問題を報告し、午後には7,000人を超えた。東部時間午後3時（日本時間28日午前4時）ごろ、X（旧Twitter）の@SpotifyStatusアカウントは「現在、ウェブページにいくつかの問題が発生していることを認識しており、調査中です！」と投稿した。約3時間後の東部時間午後6時（日本時間28日午前7時）に、「すべて復旧しました。ご辛抱いただきありがとうございます！」と復旧が報告された。

■ユーザーの状況とコンソールが示した原因

第2波の症状は各大陸で共通していた。オランダのユーザーは、シークレットモードを含むすべてのブラウザでウェブプレイヤーが「問題が発生しました」と返すと報告した。フランス、ドイツ、その他の欧州地域、ブラジル、オーストラリアのユーザーも、ウェブプレイヤーのすべての曲で同じ「現在再生できません」というエラーを報告した。欧州のAndroidアプリではアカウントがオフラインと表示され、同時にウェブプレイヤーでもストリーミングエラーが表示された。オーストラリアでは、曲が連続してスキップされ、広告サイクルに到達すると問題なく再生されるという現象が起きた。これは、広告配信は正常なまま、音声認証のパイプラインが壊れていたことを示唆している。

技術に詳しいあるユーザーが、インフラレベルでの障害の特徴と思われるものを特定した。ブラウザのコンソールを調べたところ、特定のエラーメッセージが大量に表示されていたのだ。「オリジン 'https://open.spotify.com' から 'https://clienttoken.spotify.com/v1/clienttoken' への fetch アクセスは CORS ポリシーによってブロックされました：リクエストヘッダーフィールド spotify-app-version は、プリフライト応答の Access-Control-Allow-Headers によって許可されていません」。サイトデータを消去しても問題は解決せず、エラーが示唆する通り、問題はユーザーのブラウザではなくSpotifyのサーバー側にあることが確認された。

■CORSプリフライトエラーがサーバーチェーン全体を停止させる理由

CORS（Cross-Origin Resource Sharing）は、ウェブページがどの外部リソースを取得できるかをHTTPヘッダーを使用して制御するブラウザのセキュリティメカニズムである。クロスオリジンリクエストを行う前に、ブラウザはプリフライトのOPTIONSリクエストを送信し、サーバーがリクエストのヘッダーを受け入れるかを確認する。サーバーは、Access-Control-Allow-Headersフィールドで許可されたヘッダーのリストを返す。必要なヘッダーがそのリストにない場合、ブラウザはリクエストを完全にブロックする。これはクライアントのバグではなく、仕様によるものだ。

Spotifyの場合、ブロックされたヘッダーは spotify-app-version であり、ウェブプレイヤーが認証トークンを取得するためにSpotifyのクライアントトークンエンドポイントに送信するものだった。このトークンがなければ、プレイヤーはアカウントにストリーミングの権限があることを確認できない。権限がなければ、すべての曲のリクエストが失敗する。この連鎖により、ストリーミング、ログイン、検索、アカウント管理が同時にダウンした理由（これらすべてのアクションが同じ認証パイプラインを経由するため）と、クライアント側の修正が機能しなかった理由が説明できる。Spotifyのサーバーでの設定変更により、トークンエンドポイントが受け入れるヘッダーのリストから spotify-app-version が削除され、その変更が元に戻されるまで、世界中のすべてのウェブプレイヤーセッションが締め出されたとみられる。

これが、2026年7月14日のSpotifyの障害時と同様に、オフラインダウンロードが両方の障害の波を通じて中断することなく再生され続けた理由でもある。ダウンロードされたコンテンツは、DRMライセンス付きのOGG Vorbis形式でローカルに保存されており、ライセンスはダウンロード時に検証されている。ユーザーがダウンロードしたトラックを再生する際、clienttokenリクエストは送信されず、プリフライトもトリガーされず、CORSポリシーがブロックすることもない。オフラインライブラリにとって、この障害は存在しないも同然だった。

■過去の障害対応との違い

月曜日の2度の障害に対するSpotifyの対応は、Gadget Hacksが分析した同社の2層構造のコミュニケーション慣行に沿ったものだった。つまり、大規模なグローバル障害に対しては詳細なエンジニアリングの事後報告（ポストモルテム）を行い、中規模の障害に対しては根本原因の説明なしに「状況報告から修正完了まで」のスレッドで済ませるというものだ。

2025年4月16日に発生し、世界中のほとんどのユーザーに3時間以上影響を与え、Downdetectorでの報告が48,000件を超えた障害の後、Spotifyのエンジニアリングチームは詳細な事後報告を公開した。Envoy Proxyのネットワークフィルターの順序変更がすべての境界インスタンスの同時クラッシュを引き起こし、それがKubernetesのフィードバックループに連鎖し、解決のためにエンジニアが境界サーバーの総容量を増やす必要があったという内容だ。2023年1月のグローバル障害の後には、Gitのメンテナンスウィンドウ後にDNSインフラが崩壊したことに起因するとして、分刻みのタイムラインを公開し、具体的な改善策を約束した。2022年3月の障害後にも、Google Cloud Traffic Directorとの相互作用が公に文書化され説明された。

しかし、月曜日の2度の障害については、そのような対応は一切行われていない。どちらのコミュニティスレッドも、実際に何が壊れたのかについての説明がないまま「調査中」から「修正済み」に移行した。この沈黙は、月曜日の障害に先立つ2026年の3つのインシデントにも当てはまる。Downdetectorの報告が30,000件を超え数時間続いた2026年5月12日の障害、約90分間続いた2026年6月19日の障害、そして同社の公式ステータスページにはインシデントが全く表示されなかったにもかかわらず、30分間で8,000件以上の報告があった2026年7月14日の障害である。Spotifyを独自に監視しているStatusGatorは、6年間で1,091件以上のSpotifyのインシデントを記録しており、Spotifyが自ら公表する前にサービス低下を一貫して検出している。

これが提起する説明責任の疑問は明確だ。2022年、2023年、2025年に公開されたSpotifyの事後報告は、それぞれインフラの改善を約束していた。それらの約束が2026年のインシデントの前に実行されたのか、あるいはインシデントを防ぐことができたのかについて、Spotifyは情報を提供していない。

■同日に発生したT-MobileとMetaの障害

月曜日の障害はSpotifyだけにとどまらなかった。T-Mobileは東部時間午後4時（日本時間28日午前5時）ごろから全国的な障害に見舞われ、ニューヨークやシカゴからロサンゼルスに至るまで、全国の顧客が通話、テキスト送信、データ通信を利用できなくなった。東部時間午後5時（日本時間28日午前6時）ごろのピーク時には、Downdetectorで63,000人以上のユーザーが報告を行った。注目すべきは、この障害がMint Mobile、Boost Mobile、Google Fiの顧客にも影響を与えたことだ。これらは独立しているように見えるが、T-Mobileの基盤ネットワーク上で稼働しているブランドであり、影響を受けた多くのユーザーが自分がT-Mobileの顧客であることを知らなかったという構造的な説明責任のギャップを露呈した。T-Mobileのサービスは7月28日の東部時間午前2時（日本時間28日午後3時）直前まで完全には復旧せず、約10時間の障害となった。根本原因は公表されていない。

Metaのプラットフォーム（Facebook、Instagram、Messenger）も7月27日に障害に見舞われ、米国、英国、欧州、インド、日本、オーストラリアのユーザーに影響を与えた。ユーザーが広範なアクセス障害を報告している間、Meta自身のステータスページには障害が表示されておらず、これは7月14日のSpotifyのステータスページのギャップと同様のパターンだった。

Spotify、T-Mobile、Metaの障害が共通のインフラ原因を共有していたかどうかは未確認のままである。一部のオブザーバーは、共有クラウドプロバイダーへの依存（複数の主要サービスがAWSインフラ上で稼働している）について推測したが、3つの障害を結びつける公式な根本原因は発表されておらず、公表されるまでは推測として扱うべきである。

■信頼性の問題に背景を与えるQ1 2026の業績

Spotifyは2026年第1四半期に好調な財務結果を報告した。売上高は45億ユーロ（約51億ドル、約8,364億円）、営業利益は7億1500万ユーロ（約8億1500万ドル、約1,337億円）で、月間アクティブユーザー数は7億6100万人、プレミアム加入者数は2億9300万人だった（為替レートは2026年7月28日時点の概算、1ドル＝164円換算）。これらの数字は、プラットフォーム全体の障害がもたらす代償を浮き彫りにしている。2億9300万人の有料加入者が、料金を支払っているサービスを月曜日の数時間利用できなかったのだ。

■Spotifyがダウンしたときの対処法

Spotifyの障害に対する最も確実な対策は、Spotifyのサーバーに依存しないコンテンツを用意することだ。サービスが利用可能な間に、最大5台のデバイスでオフライン再生できるようにプレイリスト、アルバム、またはポッドキャストをダウンロードしておくことである。ダウンロードされたコンテンツは認証とCDNパイプラインを完全にバイパスし、月曜日も中断することなく再生された。

リアルタイムの障害監視には、DowndetectorやStatusGatorの方が、7月14日の障害をリアルタイムで報告できなかったSpotifyの公式ステータスページよりも信頼できるシグナルとなる。インシデント発生時に運用上の更新が実際に表示されるのは、@SpotifyStatusのXアカウントではなく、Spotifyコミュニティの「Ongoing Issues（現在発生中の問題）」ボードである。7月27日のコミュニティスレッドは両方の波を確認し、他のどの公式Spotifyチャネルよりも最新の情報を提供した。ダウンロードしたコンテンツがない状態で障害に遭遇した場合、キャッシュのクリア、アプリの再インストール、ネットワークの切り替えなど、クライアント側のトラブルシューティングを行っても、Spotifyのサーバーインフラが修正されるまでストリーミングは復旧しない。

■注目ポイントQ&A

●なぜSpotifyは「現在再生できません」と表示するのですか？また、アプリを再起動しても直らないのはなぜですか？

Spotifyのウェブプレイヤーが「現在再生できません」と返す場合、問題はほぼ常にサーバー側にあり、認証または配信パイプラインの何かが失敗しています。7月27日の具体的な原因は、SpotifyのクライアントトークンエンドポイントでのCORSプリフライトの失敗でした。サーバーが、ウェブプレイヤーが認証トークンを取得するために送信する spotify-app-version ヘッダーの受け入れを停止したためです。このトークンがないと、すべての再生リクエストは音声配信レイヤーに到達する前にブロックされます。アプリを再起動しても、同じ壊れたエンドポイントに同じヘッダーを送信するため、結果は同じです。唯一の解決策は、Spotifyがサーバー側の設定変更を元に戻すことです。

●Spotifyのストリーミングが完全に壊れているのに、オフラインダウンロードが再生され続けたのはなぜですか？

ストリーミングとオフライン再生は、まったく異なるインフラ経路を使用しています。ストリーミング時、Spotifyアプリは同社の認証エンドポイントに接続し、OAuth 2.0トークンを検証した後、コンテンツ配信ネットワーク（CDN）を介してリクエストをルーティングし、音声チャンクをリアルタイムで取得します。トークンエンドポイントでのCORSブロックを含め、どのステップで失敗してもストリーミングは停止します。一方、ダウンロードされたトラックは、DRMライセンス付きのOGG Vorbis形式でデバイスのローカルに保存されており、DRMライセンスはファイルのダウンロード時に検証済みです。ダウンロードしたトラックを再生するのにサーバーとの通信は必要ないため、CORSの失敗、認証の障害、CDNの問題はすべてオフラインライブラリには影響しません。

●Spotifyは2026年に何度もダウンしています。状況は悪化しているのでしょうか？

その傾向は注目に値します。月曜日の2度の障害は、2025年4月以降で5回目、ここ約7週間で3回目の大規模なSpotifyの障害でした。2025年4月の障害では詳細なエンジニアリングの事後報告が行われましたが、5月、6月、7月14日、そして今回の7月27日の障害を含む2026年のインシデントでは、そのような報告は行われていません。公開された記録からは、2025年の事後報告で約束されたインフラの改善が、2026年の障害が頻発する前に完了していたかどうかは判断できません。同社は、それらの約束と現在進行中のインシデントとの関連性について何も言及していません。

●私はSpotify Premiumの加入者です。次の障害を避けるためにできることはありますか？

完全に信頼できる唯一の軽減策は、障害が発生する前にコンテンツをダウンロードしておくことです。Premium加入者は、最大5台のデバイスでオフライン再生できるようにプレイリスト、アルバム、ポッドキャストを保存できます。それ以外では、Spotifyの公式ステータスページは障害発生中にも「インシデントなし」と表示することがあるため、リアルタイムの障害シグナルとしてはSpotifyの公式ページよりもStatusGatorやDowndetectorをフォローすることをお勧めします。インシデント発生中は、Spotifyコミュニティの「Ongoing Issues」ボードが最も最新の公式情報源となります。

元記事: Spotify Went Down Twice Monday: a Browser Security Error in the Console Tells Why