「これだけクラウドが当たり前になった時代に、なぜ世界最大級のイベントが自前のサーバーを並べるのか」——FIFAワールドカップ2026の放送・運営インフラがオンプレミス中心で構築されると報じられ、クラウド移行を進めてきたインフラエンジニアの間で静かな話題になっています。クラウドファーストが合言葉になって久しいなか、これは「時代に逆行した選択」なのでしょうか。
結論から言えば、逆行ではありません。むしろ「ミッションクリティカルなワークロードをどこに置くか」という設計判断の、極めて教科書的な事例です。この記事では、オンプレ経験のあるエンジニアの視点から、FIFAがクラウドではなくオンプレを選んだ背景を整理し、そこから自分たちの現場でクラウドとオンプレをどう使い分けるべきかの判断軸を引き出します。速報の表面をなぞるのではなく、「自分の案件でこの判断をどう再現するか」まで踏み込みます。
FIFAワールドカップ2026のインフラで何が起きているのか
まず一次情報を整理します。2026年6月11日、Lenovo（レノボ）はFIFAワールドカップ2026の公式テクノロジーパートナーとして、大会の放送・運営インフラを支援すると発表しました。報道によると、その中核はクラウド上の仮想リソースではなく、テキサス州ダラスに置かれた国際放送センター（IBC）に物理的に設置されたサーバー群、つまりオンプレミス構成です。
確認できている主な数字は次のとおりです（2026年6月時点、Lenovo発表およびITメディア各社報道による）。
・主力サーバー: Lenovo ThinkSystem SR635 V3（ライブ映像データの管理・処理を担当）
・デバイス規模: Lenovo・Motorola製を合わせて17,000台超
・現場エンジニア: 200人以上が各会場・チームベースキャンプに配置
・映像配信: 1,000以上のスクリーンへ10チャネル経由で配信
・IPTVインフラの遅延: 5秒未満に抑制
・設計思想: ニアリアルタイムのAI搭載インフラを、ミッションクリティカルな環境向けに構築
ポイントは「IPTV遅延5秒未満」と「ミッションクリティカル環境向け設計」という2つのキーワードです。世界中で同時視聴される試合映像を、止めず・遅らせず・破綻させずに届ける。この要件が、インフラの置き場所を決めています。クラウドが不得意なわけではありませんが、この種の要件では「物理的に手元で握る」ことの価値が相対的に大きくなります。
なぜクラウドではなくオンプレを選んだのか（設計判断の3軸）
オンプレかクラウドかは、好き嫌いやトレンドで決めるものではありません。私が現場で判断するときは、必ず次の3つの軸に分解します。FIFAのケースもこの3軸で読み解けます。
1. 可用性の「責任分界点」をどこに置くか
クラウドの可用性は、AWSやAzureが提供するSLA（サービス品質保証）を前提に組み立てます。これは平常時には非常に強力です。しかしワールドカップのような「数十億人が同時に見る、やり直しのきかない一発勝負」では、可用性の最終責任を自分たちの手で握りたいという発想になります。
オンプレなら、電源・空調・ネットワーク・サーバーまで、障害ポイントをすべて自分たちで設計し、冗長化し、現場の200人体制で即応できます。クラウドだと、リージョン障害やサービス側の不具合が起きたとき、復旧のコントロールは最終的にクラウド事業者側にあります。「99.99%のSLAでは足りない、復旧を待てない瞬間がある」——これがミッションクリティカル設計の出発点です。
2. レイテンシと物理的近接性
IPTVの遅延を5秒未満に抑えるという要件は、放送インフラとしてはシビアです。報道によれば、ストリーミング配信の遅延を従来の約40秒から5秒未満へ短縮したとされ、この一桁台への作り込みがインフラ設計の主目的の一つになっています。映像処理・AI解析・配信を、視聴者に届くまでの経路でいかに短く保つか。ここで効いてくるのが物理的近接性です。
放送センター内に処理サーバーを置けば、ネットワークホップ数が最小化され、遅延のばらつき（ジッター）も抑えやすくなります。クラウドでも専用線やエッジロケーションを使えば近づけますが、「会場とIBCの間でデータが完結する」オンプレ構成のほうが、遅延を確定的にコントロールしやすい。リアルタイム映像のように「平均ではなく最悪値」を保証したいワークロードでは、この差が決定的になります。
3. 期間限定イベントのコスト構造
意外に見落とされがちなのがコストの考え方です。クラウドの強みは、需要の波に合わせてリソースを伸縮できる従量課金にあります。逆に言えば、ピークが読めて期間も限定されているワークロードでは、その強みが活きにくい場面があります。
大会期間中はほぼ常時フルスロットルで、需要の谷がほとんどありません。このプロファイルだと、ピーク性能に張り付いたクラウドリソースを長時間確保し続けるより、専用ハードを用意して使い倒すほうが、性能の確実性とコストのバランスを取りやすくなります。一過性イベントだからクラウド、という単純な図式が必ずしも成り立たないことを示す好例です。
クラウドとオンプレの使い分け早見表
FIFAの判断軸を、自分たちの案件に当てはめられるよう一般化したのが次の表です。設計レビューのチェックリストとして使えます。
| 判断軸 | オンプレが有利な条件 | クラウドが有利な条件 |
|---|---|---|
| 可用性の責任 | 最終復旧を自前で握りたい／秒単位の即応が必須 | 事業者SLAで十分／運用人員を抱えたくない |
| レイテンシ | 最悪値を確定保証したい／物理近接が効く | 平均遅延で許容／エッジ/CDNで吸収できる |
| 需要パターン | ピークが読めて常時高負荷／谷が少ない | 波が大きい／予測困難／スパイクがある |
| 期間 | 長期固定 or 期間限定で使い倒す | 立ち上げ初期／規模が不確定 |
| データ所在 | 規制・契約で物理所在を縛りたい | 所在に制約が少ない |
| 運用体制 | 専任エンジニアを現場に張れる | 少人数で運用を回したい |
注意したいのは、これは「オンプレ回帰の推奨」ではないという点です。多くの一般的な業務システムは、依然としてクラウドのほうが総合的に有利です。FIFAのようなオンプレ選択は、上の表で「オンプレが有利」側にチェックが集中するワークロードに限った話です。ここを取り違えて「世界的イベントもオンプレに戻したのだから自社も」と短絡すると、運用負荷とコストで足を取られます。
PR
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム（O’Reilly）
「秒単位の即応を自前で握る」とはどういうことか。可用性を事業者任せにせず、自分たちで信頼性を設計・運用する考え方を体系的に学べる定番書です。FIFAのオンプレ判断の背後にある思想が腹落ちします。
実務に落とすと何が変わるのか（コスト試算の考え方）
「うちはワールドカップじゃない」と思うかもしれませんが、判断のフレームは同じです。たとえば、年に数回しか走らない大規模バッチ、ライブ配信、リアルタイム取引照合のような「最悪値を保証したいワークロード」を抱えている現場は珍しくありません。
このとき、ざっくりでよいので次のような試算を並べて比較します。数字は架空の例で、実際の見積もりは自社の要件で置き換えてください。
・クラウド常時確保: ピーク性能に合わせたインスタンスを24時間×期間中ずっと確保。性能は確実だが、谷がない分コストは高止まりしやすい
・クラウド伸縮運用: オートスケーリングで需要に追従。コストは下がるが、スケールアウトの遅延と上限到達リスクを設計で潰す必要がある
・オンプレ専用機: 初期投資は重いが、期間中フル稼働なら単位性能あたりのコストは下がる。ただし調達・構築・運用人員という固定費が乗る
重要なのは「月額いくら」だけで比べないことです。可用性の責任を誰が持つか、復旧にかかる時間、運用人員の人件費、調達リードタイム——これらを含めた総保有コスト（TCO）で並べて初めて、FIFAと同じ土俵の判断ができます。クラウドの料金は分かりやすいぶん安く見えがちですが、ミッションクリティカル要件を満たすために専用線・冗長構成・監視体制を積み増すと、見えないコストが膨らむこともあります。
もう一歩踏み込むと、コスト比較では「平常時のコスト」と「障害が起きたときのコスト」を分けて考える視点が欠かせません。クラウドの従量課金は平常時の効率に優れますが、ミッションクリティカルなワークロードでは「1分のダウンがいくらの損失になるか」がコスト構造の中心になります。ワールドカップの試合中継が数秒でも乱れれば、ブランド毀損・契約上のペナルティ・視聴者の信頼低下といった金額換算しづらい損失が一気に発生します。この「止まったときの損失」が極端に大きいワークロードでは、平常時のコスト差は誤差になり、「確実に止めない」ことへの投資が正当化されます。FIFAが手厚いオンプレ構成と200人規模の現場体制にコストをかけているのは、まさにこの損失の大きさに見合った保険だと読めます。
自社で試算するときは、平常時のランニングコストの比較表とは別に、「最悪のダウンが起きたときに失う金額」を一行でもよいので明記してください。その数字が小さければクラウドの効率を取ればよく、桁違いに大きければ、多少コストが上がってもオンプレやハイブリッドで可用性を握る判断が合理的になります。比較の土俵を「平常時の安さ」から「最悪時の損失」へ移すこと——これがFIFAの設計判断から学べる最大の実務的教訓です。
ハイブリッドという第3の解
実務では「全部オンプレ」「全部クラウド」の二択になることはむしろ稀です。FIFAの構成も、配信の末端やバックオフィス系まですべてがオンプレとは限りません。現実解は、最悪値を保証したいコア部分はオンプレで握り、それ以外の伸縮性が欲しい部分や災害時のフェイルオーバー先としてクラウドを併用するハイブリッドです。
クラウド上のLinuxサーバー構築や、オンプレとクラウドをまたぐネットワーク設計の具体については、姉妹サイトLinuxMaster.JPでも実務寄りに解説しています。オンプレで培ったサーバー設計の勘どころは、クラウドに移っても確実に効きます。
オンプレを選ぶときに見落としがちな落とし穴
FIFAの事例を見て「やはり重要なシステムはオンプレだ」と判断に傾く前に、オンプレ採用に必ずついてくるコストと制約を直視しておく必要があります。クラウドに慣れた世代ほど、ここを軽く見て痛い目に遭います。私が現場で繰り返し見てきた落とし穴を整理します。
調達リードタイムという見えない制約
クラウドなら数分で立ち上がるサーバーが、オンプレでは見積もり・発注・納品・ラッキング・配線・初期設定まで、数週間から数か月かかります。FIFAが200人以上のエンジニアと17,000台超のデバイスを動かせるのは、明確な期日から逆算して計画的に調達したからです。「来週までに増強したい」が効かないのがオンプレの宿命で、需要が読めないワークロードと相性が悪い最大の理由がこれです。
逆に言えば、ワールドカップのように「いつ・どれだけ必要か」が確定しているイベントは、リードタイムの長さがリスクになりません。期日が決まっているからこそ、オンプレの計画調達が成立します。自社の案件で「需要も期日も確定しているか」を真っ先に問うべき理由です。
キャパシティプランニングの逃げ場がない
クラウドのオートスケーリングは、見積もりを多少外しても後から伸ばせる安全網です。オンプレにはこの安全網がありません。ピーク需要を読み違えてハードが足りなければ、その場で増やすことはできず、サービスが詰まります。逆に過剰に積めば、遊んだハードが固定費としてのしかかります。
だからこそミッションクリティカルなオンプレ設計では、ピーク見積もりに余裕を持たせたうえで、冗長化（N+1やN+2）まで含めて積みます。FIFAの「200人以上の現場エンジニア」という人員も、想定外の事態にハード交換や構成変更で即応するための、いわば人的な安全網です。クラウドなら自動化に任せる部分を、人と物量で担保している構図です。
運用の属人化とドキュメントの重み
クラウドはマネージドサービスが運用の多くを肩代わりしてくれますが、オンプレはパッチ適用・ファーム更新・障害切り分け・部品交換まで、すべて自分たちの責任範囲です。これを少人数で回そうとすると運用が属人化し、担当者が抜けた瞬間に詰みます。オンプレ回帰を検討するなら、運用設計とドキュメント整備に投資できるかを先に問うべきです。「ハードが安いから」だけでオンプレを選ぶと、運用コストで逆転されます。
クラウドへの「戻り道」も設計しておく
一度オンプレで組んだら戻れないわけではありませんが、データの持ち出し・ネットワーク再設計・アプリの可搬性確保には相応の手間がかかります。将来クラウドへ寄せる可能性があるなら、コンテナ化やInfrastructure as Code（コードによるインフラ定義）で、できるだけ環境に依存しない形で組んでおくと、後の移行コストを下げられます。FIFAのような期間限定構成は「使い切り」で割り切れますが、自社の常設システムでは「戻り道」も含めて設計しておくのが賢明です。
まとめると「ワークロード単位で考える」が結論
ここまでの議論を一段抽象化すると、本質は「システム全体をオンプレかクラウドかで二択にしない」ということに尽きます。FIFAのインフラも、放送のコア処理という最もシビアなワークロードにオンプレを充てているのであって、すべてを物理で抱えているわけではないと考えるのが自然です。
自社のシステムも、まずワークロード単位に分解します。リアルタイム性が命の処理、最悪値を保証したい処理、規制でデータ所在を縛られる処理——こうしたコアだけを切り出して「ここはオンプレ／ハイブリッドで握るべきか」を6軸で評価する。残りの大半は、伸縮性と運用負荷の低さを取ってクラウドに置く。この粒度で判断できるようになると、FIFAの選択が「特別なイベントの話」ではなく「自分たちの日常の設計判断」として地続きに見えてきます。
よくある質問（FAQ）
Q. これは「クラウド離れ」「オンプレ回帰」の流れなのですか？
いいえ。業界全体のトレンドがオンプレに戻っているわけではありません。FIFAの選択は、可用性の最終責任・確定的な低遅延・期間中フル稼働という条件がそろった、特定のミッションクリティカルワークロードに最適化した判断です。一般的な業務システムは引き続きクラウドが有利なケースが多数です。
Q. クラウドでは秒単位の可用性は実現できないのですか？
実現できないわけではありません。マルチAZ・マルチリージョン構成や専用線を組み合わせれば高い可用性を確保できます。ただし「最終的な復旧コントロールを自分たちで握る」という点では、物理を手元に置くオンプレに分があります。要件が「事業者SLAで足りるか／足りないか」のどちらに振れるかで判断が変わります。
Q. IPTVの遅延5秒未満はクラウドでは不可能なのですか？
不可能ではありませんが、放送センター内で処理が完結するオンプレ構成のほうが、遅延の最悪値（ジッターを含む）を確定的にコントロールしやすくなります。リアルタイム映像のように平均ではなく最悪値を保証したいワークロードでは、物理的近接性が効きます。
Q. 自社の小規模システムにこの判断軸は使えますか？
使えます。規模は違っても、軸は同じです。可用性の責任分界点・レイテンシ要件・需要パターン・期間・データ所在・運用体制の6軸で評価し、「オンプレが有利」側にチェックが集中するかを見てください。集中しなければクラウドが妥当です。
Q. ハイブリッド構成にすると管理が複雑になりませんか？
複雑になります。だからこそ、どこをオンプレで握り、どこをクラウドに逃がすかの境界を設計段階で明確にすることが重要です。境界が曖昧なまま「とりあえず両方」にすると、運用負荷だけが増えます。コア要件から逆算して最小限のハイブリッドに留めるのが定石です。
PR
オンプレ・クラウドを問わず「止めない運用」を支える設計の型を、インフラから業務まで通しで整理した一冊。FIFAのような現場の即応体制を、自分たちの規模でどう設計するかのヒントになります。
本記事のまとめ
FIFAワールドカップ2026がクラウドではなくオンプレミスを選んだのは、トレンドへの逆行ではなく、ミッションクリティカルなワークロードに対する合理的な設計判断でした。可用性の最終責任を自前で握ること、IPTV遅延5秒未満という確定的な低遅延、大会期間中の常時高負荷というコスト構造——この3つがそろったとき、物理を手元に置く選択が最適解になります。
大事なのは、この判断を「世界的イベントだから」で片付けず、可用性・レイテンシ・需要パターン・期間・データ所在・運用体制という6軸の汎用フレームとして自分の現場に持ち帰ることです。多くの業務システムは引き続きクラウドが有利ですが、「最悪値を保証したい一部のコア」だけはオンプレやハイブリッドで握る——その線引きができるエンジニアこそ、クラウド時代に本当に強いインフラ設計者です。
クラウドとオンプレの「設計判断」を体系的に身につけませんか？
オンプレの経験を活かしながら、可用性・コスト・レイテンシを軸にした実務直結のクラウド設計力を磨きたい方へ。
クラウド設計パターンの実務記事をまとめて読んで、判断の引き出しを増やしてください。
