
- WhatsAppは7月19日の決勝で毎秒3000万通超を処理し、大晦日ピークの1.23倍を記録した
- Instagramのライブ動画視聴時間は7月比+90%、Facebookは+242%に増加した
- 共有の急増は試合中ではなく、給水タイムやハーフタイムなど中断時に集中していた
何が記録されたのか
Metaは2026年ワールドカップ期間中に観測したトラフィックの記録を、自社のエンジニアリングブログで公表した。7月19日の決勝(アルゼンチン対スペイン)では、WhatsAppが1秒あたり3000万通を超えるメッセージを処理した。これは2026年の大晦日に記録したピークの1.23倍にあたり、同プラットフォームの過去最高記録とされている。従来の記録はその12日前、ラウンド16のアルゼンチン対エジプト戦で毎秒2900万通としてすでに更新されていた。
他のサービスでも同じ時期にピークが重なった。Messenger、Threads、Instagram Directは合計で毎分4900万通のメッセージを処理している。Instagramでは推薦システムのトラフィックが前週比で最大80%増加し、決勝進出選手の合計フォロワー数は32.6億人から34.7億人へ増えた。アクティブフォロワーの増加分は2億1360万人(6.6%増)とされる。
動画と投稿の面でも数値が伸びた。ライブ動画の視聴時間はInstagramで7月の基準比+90%、Facebookで+242%。Threadsでは大会タグ付き投稿が15億インプレッションに達し、1日あたり約1500万人に届き、7月6日には2500万人まで増えた。Facebookではワールドカップに言及した投稿が8000万件に上ったという。
山は試合中でなく中断時に
Metaが試合イベントと世界全体のegressトラフィックを突き合わせたところ、共有の急増は主に試合の中断時に起きていたことが分かった。具体的には給水タイム、ハーフタイム、延長、試合終了の笛、表彰式といったタイミングである。決勝では通常時間の終了にあたる約4分間にトラフィックが46%増え、試合終了の笛から約15分間で57%増加した。
なかでも最大のピークを生んだのは、試合終了の笛だったという。Metaは「チャートを動かしたのはプレーではなく、その後の会話だった」と説明している。この傾向を前提として、以降に述べるキャパシティ設計が組み立てられた。
負荷そのものは、想定された仕組みで吸収されたとされる。Taijiがデータセンター間の負荷を分散し、KatranとProxygenがL4/L7のトラフィック分散を担い、世界規模の負荷分散システムが利用者を最適なエッジへ振り分け、AutoScalingが必要に応じて容量を確保した。
InstagramとWhatsAppの備え
Instagramは39日連続でトラフィックの急増にさらされた。決勝では試合終了の1分間にFeedのトラフィックが前日比76%増え、その後2時間は約21%高い水準が続いた。対応の柱は4つで、大会の進行に合わせて段階的に導入された。十分な容量バッファの事前確保、高トラフィック国(ブラジル、アルゼンチン、インド、インドネシア、スペイン)での重要度の低いバックグラウンド処理の縮退、下流データシステムへの波及防止、容量のしきい値に近づく前の早期警告である。Metaは容量バッファの事前確保を、今回最も効果の大きかった手段と位置づけている。
WhatsAppでは、最もトラフィックが多かった5分間に約84億通のメッセージを途切れなく配信したとしている。大会前に100以上の社内サービスを負荷テストして規模を調整し、トーナメントが進んで需要が高まるにつれて再テストと再調整を繰り返した。
エッジ側では、大会の数カ月前からネットワーク容量を分析し、ISPパートナーと協力して回線増強を実施したという。この増強分は大会後も恒久的な容量として残ると説明されている。
やらなかった2つのこと
Metaは、通常の高負荷対応で行う2つの施策を今回は実施しなかったと明かしている。1つはリージョン間の負荷移転である。過去の大規模イベントではピークが地域ごとに数時間ずれており、閑散な地域の容量で吸収できた。しかし今回は全リージョンが同時にピークを迎え、借りられる余剰容量がなかった。そのため地域ごとの需要を世界共通の係数から推計するのではなく、それぞれ個別に予測したという。
もう1つはデプロイ凍結である。大規模イベントでは継続的デプロイを止め、災害復旧訓練のようなリスクの高い運用を控えるのが定石とされる。今回はそれを省略し、大会期間中も通常のペースでデプロイを続けた。ピークの瞬間も含めて出荷を止めなかったとされ、判断の根拠として長年の信頼性向上の積み重ねが挙げられている。
Metaはこれらの知見を、2028年オリンピックのような大規模イベント向けの再利用可能なランブックとして位置づけている。段階的なデプロイのタイムラインや縮退を発動する判断基準も含まれるとしている。
現時点での注意点
今回の数値はMetaが自社ブログで公表したものであり、記事中に第三者による検証は示されていない。各システムの内部構成や、容量バッファが具体的にどれだけ積まれたかといった詳細も公開されていない。
国単位の縮退についても、どの機能を「重要度が低い」と判断したのかは明らかにされていない。ランブックの中身も同様に非公開である。数値の大きさだけでなく、こうした開示されていない部分がある点は押さえておきたい。
| サービス | 指標 | ピーク時の値 |
|---|---|---|
| メッセージ量 | 毎秒3000万通超(7月19日決勝) | |
| Messenger・Threads・Instagram Direct | メッセージ量 | 毎分4900万通 |
| ライブ動画の視聴時間 | 7月比+90% | |
| ライブ動画の視聴時間 | 7月比+242% | |
| Threads | 大会タグ付き投稿のインプレッション | 15億件 |
It wasn’t the gameplay that moved our charts. It was the conversations after it. The world came to Meta to watch the game and to share what it made them feel.
チャートを動かしたのは試合そのものではなかった。その後の会話だった。世界は試合を見るため、そして感じたことを共有するためにMetaに集まった。
今後の見通し
Metaは今回の対応を、2028年オリンピックなど大規模イベント向けの再利用可能なランブックとして位置づけている。段階的なデプロイのタイムラインや縮退の発動基準も含まれるとされるが、その中身は公開されていない。2028年オリンピックで「全リージョンが同時にピークを迎える」パターンが再現するかどうか、また事前に増強したエッジ容量が大会後の平常時需要をどれだけ吸収できるかが明らかになれば、この設計の有効性をより具体的に評価できるとみられる。数値の一部は今後更新・訂正される可能性もある。
日本の開発者・IT企業にとっての意味
日本のIT企業にとっての示唆は、ピーク対策の重心が「スパイクそのものをさばくこと」ではなく「スパイクの発生パターンを把握すること」にある点です。Metaは試合イベントとトラフィックを突き合わせ、急増が休憩時間に集中することを見つけたうえで容量計画を組み立てました。自社サービスでも、イベント単位ではなくユーザー行動の区切りで負荷を分析する余地があります。また、全リージョンが同時にピークを迎える状況ではリージョン間の負荷移転が効かないという指摘は、国内に複数リージョンを持つサービスにも当てはまります。十分な容量バッファの事前確保が最も効果的だったという記述は、オートスケーリングだけに頼らない設計を検討する材料になります。ただしMetaの専用システムは公開されておらず、そのまま再現できるものではありません。
気になる点
- WhatsAppの記録はどの試合で、いつ達成されたのか
- 2026年7月19日の決勝、アルゼンチン対スペイン戦で毎秒3000万通超を処理したとされています。これは2026年大晦日のピークの1.23倍にあたります。さらに12日前のラウンド16、アルゼンチン対エジプト戦でも毎秒2900万通を記録し、その時点で従来の記録を更新していました。
- Metaはなぜデプロイ凍結を行わなかったのか
- 大規模イベントでは継続的デプロイを止めるのが定石ですが、Metaは長年の信頼性向上の積み重ねを根拠に、今回は凍結を省略したと説明しています。大会期間中も通常のペースで出荷を続け、ピークの瞬間も同様だったとされています。ただし判断の詳細な基準は公開されていません。
- この負荷対策の手法は日本のサービスにも応用できるか
- 事前の容量バッファ確保や国単位の段階的縮退といった考え方は、規模を問わず参考になるとみられます。一方でTaijiやKatran、Proxygenといった基盤システムはMeta固有で、一般には公開されていません。具体的な再現手順は現時点では公表されていないため、原則だけを自社環境に合わせて解釈する必要があります。
用語解説
- Taiji
- Metaがデータセンター間で負荷を分散するために使うシステム。原文では負荷分散の役割を担ったと説明されている。
- Katran
- Metaが使うL4(トランスポート層)の負荷分散システム。原文ではトラフィック分散を担ったとされる。
- Proxygen
- MetaのHTTP関連ソフトウェア。原文ではL7(アプリケーション層)のトラフィック分散を担ったと説明されている。
- AutoScaling
- 需要に応じてサーバー容量を自動で増減させる仕組み。原文では必要に応じた容量確保を担ったとされる。
- graceful degradation(段階的縮退)
- 高負荷時に重要度の低い処理を止め、中核機能を守る設計手法。原文では国単位で適用されたとされる。
- egressトラフィック
- データセンターなどから外部へ出ていく通信量。原文ではこれと試合イベントを突き合わせて分析したとされる。
出典
2026 World Cup: Breaking Records, Spiky Charts and Reliability at Scale
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する