FIFA ワールドカップ 2026は、アメリカ・カナダ・メキシコの3か国開催です。 会場が大陸全体に散らばっているので、チームによって移動の負担がかなり違いそうだな、と思いました。
そこで、各チームのグループステージの「移動スケジュールの重さ」を、Elastic を使って地図とダッシュボードで見えるようにしてみました。この記事では、何を作ったのか、何のデータを使ったのか、そしてどこまでが言えてどこからは言えないのかを、なるべくシンプルに説明します。
概要
一言でいえば、「どのチームの移動スケジュールが最も過酷か」を可視化したダッシュボードです。 中心となるのは、独自の「移動負担スコア（travel_burden_score）」です。念のためお伝えしておきますが、これはあくまで仮説に基づいたカスタム指標であり、公式なデータではありません。今回は以下の5つの要素に重みをかけて組み合わせてスコアを算出しました。
- ベースキャンプから各試合会場までの距離
- ベースキャンプから最も遠い会場までの距離
- 試合順に見た会場間の移動距離
- 試合間の休養日数
- タイムゾーンの移動（時差）
つまり、「長距離の移動が多い」「時差が大きい」チームほどスコアが高くなる仕組みです。
着眼点
なぜ面白いと思ったのかというと同じ「グループステージ3試合」でも、チームによって移動の負担には天と地ほどの差があるからです。
例えばボスニア・ヘルツェゴビナ代表の場合、ベースキャンプはサンディに置かれますが、試合会場はトロント、ロサンゼルス、シアトルと各地に分散しています。これを地図で見ると、大陸を横断するようなハードな移動が必要なことが一目瞭然です。
数字だけではピンと来なくても、地図上に線を描いてみるとその過酷さが伝わりますよね。これがダッシュボードを作ってみようと思った最大の理由です。
手法
背景を知らない方のために、使ったものを簡単に説明します。
データはすべて公開データです。 自分で試合結果や移動データを作ったりはしていません。
- 試合日程・会場：OpenFootball（無料・自由に使える公開データ）
- 各チームのベースキャンプ：FIFA の公式発表ページ
- 会場やベースキャンプの座標：Wikipedia / GeoNames などの公開情報
これを Elastic の仕組みに載せています。Elastic という名前を初めて聞く方向けに、まずひとことで言うと、検索（Search）・監視（Observability）・セキュリティ（Security）を1つにまとめたデータプラットフォームです。
具体的に使ったのは次の3つです。
- Elasticsearch：データをためて高速に検索・集計できるエンジン。Elastic の心臓部です。今回の「チームごとの移動データ」をここに入れています。
- Kibana：そのデータをグラフや表で可視化するツール。ダッシュボードはここで作ります。
- Kibana Maps：地図の上にデータを重ねて見せる機能。ベースキャンプ、試合会場、移動の線を地図に描いています。
データの整形（距離の計算など）は、シンプルな Python スクリプトで行っています。距離は2点間の直線距離で計算しています。
ここはとても大事なので、はっきり書きます。これは 実際の移動ルートや、チームのコンディションを直接示すものではありません。
- 距離は「直線距離」です。実際の移動は道路や飛行機なので、もっと長くなります。
- ベースキャンプは「都市レベル」の座標です。正確な練習場の場所までは使っていません。
- あくまで「日程表から見える移動の負担」を推定しているだけです。
なので、「移動が重い＝負ける」という話ではありません。 ただ、スケジュール上の移動負担をデータで眺めてみるという意味では、面白い切り口になったと思っています。
ダッシュボードの作り方は1つじゃない（しかも AI に任せられる）
大きく3つあります。
- 手動で作る：Kibana の画面で、パネルを足したり並べたりして作る。一番わかりやすい方法です。
- API で作る：Python などからプログラムでダッシュボードを生成する。今回はこの方法で、ダッシュボードをファイル（NDJSON）として書き出し、誰でも取り込めるようにしました。
- AI に任せる：Elastic には、AI エージェント向けのSkillsが公開されていて、その中にはダッシュボード作成用のものもあります。つまり、AI に作らせることもできます。
さらに Agent Builder という機能もあります。これは、自分のデータの上で動く「質問に答えるアシスタント」を作れる仕組みです。実務で複雑なダッシュボードを扱うときに、その裏にあるデータについて「なぜこのチームが1位なの？」のような質問を自然言語で投げて、答えてもらう、といった使い方ができます。
なぜ Elastic でやると面白いのか
今回はサッカーを題材にしましたが、やっていることは、もっと一般的な問題と同じです。
「公開（または社内）の予定データに、場所の情報をくっつけて、距離・休み・時差から負担を点数にして、地図とダッシュボードで見せる」 という流れです。
これは、たとえば次のような場面とそのまま重なります。
- 現場スタッフをどの拠点からどの現場へ動かすか（フィールドオペレーション）
- イベントの会場配置と人員の動き
- 配送・物流の負荷
- 拠点ごとの混雑やインフラ負荷
- セキュリティ：ログインがどの国・拠点から来ているかを地図に出し、ふだんと違う場所からのアクセスを見つける（不正アクセスの兆候の可視化）
Elastic は、データの取り込みから、検索、集計（ES|QL という問い合わせ言語。Splunk を使ったことがある方は、あの SPL と同じ立ち位置のものだと思ってください）、ダッシュボード、地図までを1つの基盤でまかなえます。だから「予定データを運用の知見に変える」のに向いています。サッカーの例は、その分かりやすい入り口というわけです。
まとめ
大会が終わったら、実際の結果やチームのパフォーマンスと推定した移動の大変さ見比べてみるのも面白そうだなと思っています。
ここで個人的な感想を少しだけ。
Elastic は、コツをつかむまでは正直ちょっと小難しいところがあります。でも今は GenAI（生成AI）を一緒に使うことで、その最初のハードルがかなり下がってきている感じがします。「全部を自分で覚えてから作る」のではなく、AI に手伝ってもらいながら作って、動かしながら理解することができる時代になってきたな、と実感しました。
最後まで読んでいただき、ありがとうございました。
