iOSアプリ「うちの沿線速報」を、ヒーローズ・リーグ2026に応募しました。
コンセプトは、駅に着く前に、もう遅延を知っている。 です。
この記事では、アプリの紹介に加えて、なぜこのアプリを作ったのか、どう設計したのかをまとめます。作品ページと紹介動画へのリンクは記事の最後にあります。
応募概要
- 応募先：ヒーローズ・リーグ2026
- 作品名：うちの沿線速報
- コンセプト：駅に着く前に、もう遅延を知っている。
- プラットフォーム：iOS（App Storeで公開中）
本作は、公共交通オープンデータチャレンジ2026への参加にあわせて開発を進めてきたアプリでもあります。
紹介動画
動画が表示されない場合は、YouTubeで見るからご覧ください。
なぜ作ったのか
通勤で一番困るのは、遅延そのものよりも遅延を知るタイミングでした。
駅に着いて、改札の前の電光掲示板を見て初めて遅れていると分かる。その時点では、もう別の経路に切り替えるには遅すぎます。家を出る前に分かっていれば、1本早く出る、別の路線を使う、といった選択ができたはずです。
運行情報を見られるアプリやサイトは、すでにたくさんあります。でも「見に行けば分かる」のと「見に行かなくても分かる」のは別物です。毎朝わざわざ確認しに行くのは続きませんし、確認しない日に限って遅れていたりします。
そこで、自分が使う路線に変化があったときだけ、向こうから知らせてくれるアプリを作ることにしました。
どんなアプリか
駅に着いてから遅延を知るのではなく、出発前に必要な運行変化を知るためのアプリです。
首都圏を中心とした対応路線の運行情報を確認できます。対応状況は利用するデータソースの提供状況によって異なります。
曜日・時間帯に合わせて通知条件を設定
通勤に使う路線でも、休日の昼間に遅延の通知が来ても困ります。そこで、通知を受け取る曜日と時間帯を設定できるようにしました。「平日の朝だけ」のように、自分が実際に乗る時間に合わせられます。
遅延履歴と遅延傾向を確認できる
起きた遅延は履歴として残り、路線ごとの遅延回数を7日間・全期間で確認できます。「この路線は最近よく遅れる」が感覚ではなく数字で分かるので、早めに家を出るかどうかの判断材料になります。
利用する路線・方向を登録
利用する路線・方向を登録できます。通知は、登録した路線の運行状態の変化と、曜日・時間帯などの通知条件をもとに行います。
技術構成
| 役割 | 使っているもの |
|---|---|
| アプリ | Flutter / Dart |
| 運行情報の取得元 | ODPT等の運行情報 |
| 取得・判定処理 | Cloudflare Workers |
| 状態と履歴の保存 | Cloudflare D1 |
| 通知の配信 | APNs（Apple Push Notification service） |
運行情報は、公共交通オープンデータチャレンジ2026を通じて提供されているODPT（公共交通オープンデータセンター）のデータなどを利用しています。
設計の見どころ
端末ごとに上流APIを叩かない
最初に決めたのは、各端末が運行情報のAPIを直接ポーリングしないことです。
アプリが自分で定期的に情報を取りに行く作りにすると、利用者が増えるほど上流のAPIへのアクセスが増えます。電池と通信も消費しますし、iOSではアプリが裏で好きなタイミングで動けるわけでもありません。
そこで、サーバー側で5分間隔に運行情報をまとめて取得し、その結果を全利用者で共有する構成にしました。上流へのアクセスは利用者の数に関係なく一定で、端末は通知を受け取るだけで済みます。
情報の「表示」ではなく、状態の「変化」を通知する
このアプリの中心は、運行情報をそのまま流すことではなく、状態変化を通知することです。
Workersは5分ごとに取得した運行情報を、D1に保存してある前回の状態と比較します。そして、
- 正常 → 異常（遅延や運転見合わせが発生した）
- 異常 → 正常（平常運転に戻った）
という状態の切り替わりを判定します。切り替わりがあった場合は、その路線を登録している利用者ごとに曜日・時間帯などの通知条件を判定し、条件に合う利用者へAPNsで通知を送ります。
処理の流れをまとめると、次のとおりです。
- Cloudflare WorkersがODPT等の運行情報を5分間隔で共通取得する
- D1に保存した前回状態と比較し、正常→異常、異常→正常の状態変化を判定する
- 状態変化があった路線について、利用者ごとに曜日・時間帯等の通知条件を判定する
- 条件に合う利用者へAPNsで通知する
文言が変わっただけでは再通知しない
運行情報は、遅延が続いている間も「〇〇駅で発生した人身事故の影響で」「運転再開見込みは〇時頃」のように、文言が何度も更新されます。
この文言の変化をそのまま通知のきっかけにすると、ひとつの遅延で何通も通知が届くことになります。通知が多すぎるアプリは、やがて通知ごと切られてしまいます。それでは「駅に着く前に知る」という目的が果たせません。
そこで、文言の変更だけでは再通知しない設計にしました。通知するのは、あくまで正常と異常の間で状態が変わったときです。
同じ考えから、インストール直後や路線を追加した直後に、すでに起きていた遅延を「新たに発生」として通知しないようにもしています。これはアプリにとって「初めて見た状態」であって、「変化」ではないからです。
遅延履歴・傾向分析
状態変化を記録していく仕組みは、そのまま遅延の履歴にもなります。D1に蓄積した状態変化から、路線ごとの遅延回数を集計して「遅延傾向」として表示しています。
通知のために作った状態管理が、そのまま分析にも使えるのは、この設計のよいところだと思っています。
ヒーローズ・リーグで見てほしいところ
- 「状態変化通知」を中心に設計したこと 運行情報を見やすく並べるアプリではなく、「変化があったときだけ知らせる」ことを軸に作っています。
- 通知過多を避けるための状態管理 前回の状態との比較、文言変更での再通知をしない判定、初回取得時の扱いなど、「知らせない」ための判断を丁寧に積み上げました。
- Cloudflare Workers / D1 / APNs の組み合わせ サーバー側で5分間隔に共通取得し、状態をD1に持ち、変化だけをAPNsで届ける構成です。個人開発でも運用しやすく、利用者が増えても上流APIへの負荷が増えない形を目指しました。
作品ページ・紹介動画・ダウンロード
ProtoPediaでは、作品の詳細を見ることができます。 ProtoPedia「うちの沿線速報」
YouTubeでは、3分未満の紹介動画を公開しています。 紹介動画を見る（YouTube）
App Storeから、iPhoneで利用できます。 App Storeで「うちの沿線速報」を見る
アプリの機能や更新履歴は、「うちの沿線速報」アプリページにまとめています。公共交通オープンデータチャレンジ2026への参加については、こちらの記事で紹介しています。
