BIM・IFCブログに戻る
デジタルツイン · 2026-10-16 · 8分
都市のリアルタイムデータの鮮度は？6つのフィードを24時間計測
「リアルタイム」という言葉は、データが届いた時点でどれだけ古いかについて何も語りません。私たちはライブのデジタルツインが読み込む公開フィード6件を24時間記録し、そこに含まれるすべての車両とステーションについてデータの経過時間を計測しました。答えは1秒未満から1分半までと幅があり、フィード自体のタイムスタンプがそれを覆い隠すこともあります。
IFC Viewer Onlineで表示した都庁前駅 A4出口のデジタルツイン。東京の地図上にA4出口のIFCモデルが置かれ、ホームにいる都営の列車の番号がライブで上に浮かんでいる
ライブのフィードは、どれも「リアルタイム」をうたっています。しかしデジタルツインにとって、この言葉はツインの色が何を意味するかを決めるたった1つの数字を覆い隠しています。データが届いた時点でどれだけ古いか、です。3分前に自転車がなかったために赤く塗られたドックは、今まさに自転車がないドックと同じではありません。
そこで計測しました。バルセロナ、ヘルシンキ、東京のライブのツインが読み込む公開フィード6件を24時間記録し、すべてのレスポンスに含まれる車両やステーションの1つひとつについて、提供元が書き込んだ時刻とデータが届いた時刻を比較しました。ログはすべて公開しています[log]。
この記事のポイント
- HSLのMQTTストリームは1秒未満で届きました。GTFS-Realtimeで配信される同じ車両群は約2秒前のデータでしたが、こちらのフィードはブラウザーからは読めません。
- 都営の列車の位置は約30秒前のものでした。都営バスの位置とBicingのステーションは中央値で約1分半前、90%が約3分以内でした。
- フィード自体のタイムスタンプは誤解を招くことがあります。Bicingのファイルは約0.3秒前のものでしたが、中のステーションが報告したのは約95秒前でした。
- Endollaの充電器のフィードには報告時刻がまったくなく、各充電器の状態が最後に変わった時刻しかありません。そのため、どれだけ最新のデータなのかを示せません。
- 14,329件のリクエストはすべて応答があり、MQTTストリームは1日を通じて毎分メッセージを届けました。
典型的なレスポンスに含まれる車両やステーションの経過時間の中央値と、その90%が収まる範囲。
計測の方法
- 2026年10月15日21:15（UTC）から10月16日21:15（UTC）まで、時刻を同期したヨーロッパの1台のコンピューターで計測しました。
- HSLのGTFS-Realtimeは15秒ごと、Bicingと都営の2つのフィードは30秒ごと、Endollaは5分ごとにポーリングしました。HSLのMQTTストリームはヘルシンキ地域を対象にサブスクライブし、1分ごとに集計しました。
- レスポンスごとに、含まれる車両やステーションの経過時間の中央値と90パーセンタイル値を求めました。グラフには、24時間を通じたそれらの典型的な値を示しています。
経過時間とは、到着時刻から、提供元が各項目に書き込んだタイムスタンプを引いたものです。GTFS-Realtime[gtfsrt]では車両の位置が計測された時刻、GBFS[gbfs]ではステーションが最後に報告した時刻、HSLのストリーム[hfp]では各メッセージ自身の時刻、ODPTでは各列車のレコードの時刻です。
フィードごとの結果
| フィード | 届き方 | 経過時間の中央値 | 項目の90%が収まる値 | レスポンスあたりの件数 |
|---|
| HSLのバス、HFP（ヘルシンキ） | MQTT、プッシュ配信 | 1秒未満 | 1秒未満 | 毎分約28,000件のメッセージ |
| HSLの車両、GTFS-Realtime（ヘルシンキ） | HTTP、15秒ごと。CORSなし | 1.9秒 | 1.9秒 | 車両843台 |
| 都営の列車、ODPT（東京） | HTTP、30秒ごと | 28秒 | 30秒 | 列車92本 |
| 都営バス、GTFS-Realtime（東京） | HTTP、30秒ごと | 88秒 | 3.1分 | バス490台 |
| Bicingのステーション、GBFS 3.0（バルセロナ） | HTTP、30秒ごと | 95秒 | 2.8分 | ステーション543か所 |
| Endollaの充電器、GELFS（バルセロナ） | HTTP、5分ごと | 記載なし | 記載なし | コネクター1,366個 |
2026年10月15〜16日の24時間における典型的な値。件数は中央値です。都営は深夜帯には列車もバスも運行していません。結果は3つのグループに分かれます。HSLは各バスが送る内容をその場で公開するため、経過時間はMQTTではほぼゼロ、まとめて配信されるGTFS-Realtimeのファイルでも約2秒です。都営の列車のレコードは、通常30秒ほど前のものでした。都営バスとBicingのステーションはそれぞれ数分おきに報告するため、どの時点でもおよそ半数が1分半より古くなっています。バスの49%、ステーションの52%が90秒を超えていました。
「最新」を示すタイムスタンプ
Bicingのステーション状態ファイルにはlast_updatedの時刻が含まれており、その値は常に現在時刻から1秒以内でした。ファイルには配信される時点で時刻が刻まれるからです。一方、中に含まれる543か所のステーションが報告したのは、中央値で95秒前でした。ファイルの時刻を信じたツインは、1分半前のデータに「0秒前に更新」と表示することになります。都営バスのフィードにも、程度は軽いものの同じ傾向が見られます。ファイルのタイムスタンプは約16秒前、バスは約88秒前でした。
教訓はシンプルです。経過時間はファイルではなく、項目ごとに決まるものです。各車両や各ステーションが報告する時刻を読み取り、それを表示しましょう。
古さを示せないフィード
Endollaの充電スポットのファイルは、5分ごとの計測286回のうち262回でサイズが変わっており、きちんと更新されているのは明らかです。しかし各コネクターが持っているのは、状態が最後に変わった時刻だけです。半数は約21時間、10分の1は10日以上変化していませんでした。夜間に誰も使わなかった充電器なら完全に正確な値ですが、報告が止まった充電器の可能性もあります。フィードからはこの2つを区別できません。ツインはこうしたデータを「公開されたままの値」として表示することはできても、ライブとして表示することはできません。
プッシュかポーリングか
HSLの2つのチャネルは同じバスを配信しています。MQTTでは各位置が発生したその場で届きますが、ポーリングするファイルでは次のバッチを待ち、さらにブラウザーが次のポーリングを待つ時間が加わります。ポーリングにはコストもかかります。Bicingのファイルは543か所すべてのステーション分で圧縮前約268KBあり、必要なステーションが1か所だけのツインでも、ポーリングのたびに全ステーションをダウンロードします。ソースの更新より速くポーリングしても、その帯域を二重に使うだけです。
ツインにとっての意味
- 値の横に経過時間を表示しましょう。基準はファイルではなく、各項目自身のタイムスタンプです。
- 「古い」とみなすしきい値は、そのフィードの通常の経過時間より上に設定します。ここで紹介しているライブ事例では、HSLのバスの乗り場に45秒、都営の列車に2分、都営バスの停留所に10分、Bicingに15分を使っています。
- グレーは「最近のデータがない」ことを意味します。最後の値を最新のように見せてはいけません。
- 提供元がプッシュに対応していればそちらを選び、ポーリングはソースが更新されるペースより速くしないようにします。
- 項目ごとの時刻がないフィードは、表示はできても、ライブとは呼べません。
そもそもWebページがこれらのフィードを読み込めるかどうかは、問題のもう半分です。詳しくはWebページから読める都市オープンデータで解説しています。ヘルシンキのツインがMQTTストリームをどう使っているかは、MQTTで作るバスターミナルのツインをご覧ください。
都市のリアルタイムデータの鮮度は？6つのフィードを24時間計測