路線を選ぶ

1. どこからどこまで乗るか（OD）を先に決める

まず時間帯ごとに「その駅から乗る人の数」と「その駅で降りる人の数」を出し、そのうえで出発駅と到着駅の組み合わせを作ります。遠い駅ほど選ばれにくい重力モデルを種にして、行の合計＝乗る人、列の合計＝降りる人にそろうまで繰り返し調整します（Furness法）。

これにより「北千住や秋葉原でどっと降りる」といった動きが、仮定ではなく計算から出てきます。降車も号車ごとに正確に分かるようになりました。

2. どの種別に乗るかは速さと待ち時間で決まる

以前は種別ごとに「好まれやすさ」を手で決めていましたが、いまは停車駅から所要時間を計算し、本数から待ち時間を出して選ばれ方を決めます。目的地に停まらない種別に乗る人は、手前の停車駅までを乗車区間として扱います。

3. 号車は「乗る駅の階段」と「降りる駅の出口」で決まる

いちばん大きな変更点です。以前は「降車駅で便利な位置」を全員共通の1つの数字にしていましたが、いまは行き先ごとに、その駅の出口の位置を使います。出口の位置は、改札からの距離で重みづけした動線の平均位置として自動で求まります（北千住の上りなら66m付近＝3号車あたり）。乗車時間が短い人は降り口をあまり気にしないので、効き具合は乗車時間に応じて弱まります。

乗車客を10回に分けて配り、そのつど混み具合を更新するので、混んだ号車ほど次の人が入りにくくなります。乗車率240%を上限とし、超えるぶんは次の電車へ回します。

4. 環状線・直通運転・他路線への広げ方

計算部分は路線のデータから独立しています。新しい路線は次を用意すれば動きます。

• 駅の一覧（名前・営業キロ・1日平均乗車人員・住宅地/都心の度合い）
• ホームの動線（階段・エスカレーター・エレベーターの位置と改札からの距離）
• 種別ごとの停車駅と時間帯別の本数
• 編成両数と号車ごとの定員、女性専用車の規則
• 表定速度と1駅停車あたりの所要増（この2つで所要時間が出ます）

環状線（山手線・大阪環状線など）は、駅の並びが端で折り返さずつながります。loop:true を立てると、駅番号の差を輪の長さで割った余りで数え、内回り・外回りは短いほうの向きに自動で振り分けます。1周ぶんだけ計算すると「起点の駅がいつも空で始まる」不自然さが出るので、3周ぶん流して2周目だけを採用し、混み具合が一巡して落ち着いた状態を見ています。山手線の外回りは朝7:30の上野→御徒町がいちばん混み、公表値と同じ水準になります。

直通運転は、複数の路線をつないだ一続きの運転系統として扱えるようにしてあります。駅の並びに他社線の駅を続けて書けば、OD も号車の選択もそのまま境界をまたいで計算されます。編成両数が変わる直通（10両と8両が混じるなど）も、種別ごとに両数を持たせて表せます。

5. 投稿による自動較正

投稿された6段階を代表乗車率（45/75/100/125/155/195%）に直し、同じ駅・方向・曜日区分の予測と比べます。投稿は分かる号車だけで成立します。

ズレは4つの層に分けて覚えます。上の層ほど多くの投稿で決まるので早く安定し、下の層は投稿が集まってから効きはじめます。

各層は件数 n に応じて n/(n+k) だけ効かせます（k は路線8・駅6・時間帯4・号車3）。投稿が少ないうちは自動的に上の層へ寄り、増えるほど細かい層が立ち上がります。平均は外れ値に強いHuber平均を使い、さらに「混んだ号車ほど投稿されやすい」偏りを打ち消すため、1件あたりの重みを 1 / max(0.35, 予測混雑率) にしています。

号車ぶんの件数がしきい値を超えたら、λ_g・λ_p・β をその駅の投稿に合う値に探索し直します。

確からしさ

実測に基づくのは、駅別の乗車人員（2025年度）、営業キロ、ホーム長と編成定員、号車の向き、女性専用車、種別ごとの停車駅、公表されている最混雑区間の水準です。表定速度と1駅あたりの停車時分は、路線ごとに公表されている所要時間から逆算しています（TXは快速45分・普通57分、山手線は1周約60分）。各駅の動線の座標・改札からの距離・通過能力は公式構内図からの目測で、アイソメ図から読む都合上おおむね±1両の誤差があります。山手線・東西線・千代田線・銀座線・埼京線は、各駅の乗車位置案内（何号車の何番ドアが階段・エスカレーター・エレベーターに近いか）を書き写したもので、ドア単位（±5m程度）の精度です。改札までの距離までは分からないため、そこは種類ごとの標準値を置いています。埼京線は大崎〜浮間舟渡の10駅ぶんだけで、残りは未確認です。方向シェア・時間帯分布・運転本数・種別の構成比も仮定値です。

路線ごとに scale（公表の乗車人員と、実際に電車に乗っている人数の差を埋める倍率。乗り換えだけの利用や定期外の流入を含みます）と allday（終日まんべんなく使われる度合い。山手線のように通勤の山が緩い路線で使います）の2つを、公表されている最混雑区間の値に合うように決めています。いま対応している9路線それぞれについて、公表されている最混雑区間の値にぴったり合うように決めてあります（つくばエクスプレス 北千住154%／山手線 外回り上野→御徒町135%／中央線快速 中野→新宿158%／京浜東北線 大井町→品川159%・川口→赤羽158%／総武線各停 錦糸町→両国151%／東西線 木場→門前仲町160%／千代田線 町屋→西日暮里150%／銀座線 赤坂見附→溜池山王153%／埼京線 板橋→池袋167%）。路線ごとに使ったのは、この1〜2点だけです。あてはめに使っていない値でも合います：山手線の内回りは、こちらから場所を指定していないのに、公表と同じ新大久保→新宿がいちばん混む区間になり（134%、公表136%）、総武線各停の代々木→千駄ケ谷も93.8%（公表93%）になります。これらのズレは投稿が集まるほど較正が吸収します。

出典

この試作は、投稿の保存先を3つのうち使えるものへ自動で切り替えます。上から順に試し、最初に使えたものを採用します。

いまの保存先は「投稿で予測がどれだけ直ったか」のいちばん上に出ています。この画面（claude.ai のアーティファクト）は外部への通信が塞がれているため、ここでは 1 の Supabase は選ばれません。自分のサーバーや Vercel などにこの HTML を置いたときだけ有効になります。

1. Supabase 側の用意

プロジェクトを作り、SQL Editor で komiden-supabase.sql を実行します。作られるのは次の4つです。

• crowd_reports — 混雑度の投稿。観測した実際の時刻（obs_min）を必ず持ちます
• facility_reports — 階段・エスカレーター・エレベーターの位置報告
• accuracy_log — 投稿が届いた時点の予想と実測。モデルを変えたときの良し悪しを後から言えます
• line_activity — 路線ごとの投稿数（ビューなので容量を使いません）

RLS は「読むのは誰でも可・入れるのも誰でも可・書き換えと消しは誰も不可」にします。UPDATE と DELETE のポリシーを作らなければ、RLS が有効なかぎり全部拒否されます。

2. HTML 側の設定

この HTML を読み込む前に、次の1行を置くだけです。ここに書く anon キーは公開前提のもので、RLS が実際の守りになります。

3. 無料プランで足りるか

無料プランはデータベース500MB・帯域5GB/月・月間アクティブ5万人です。投稿1件はおよそ150バイトなので、1日1万件でも1日1.5MB、180日ぶんで270MB。読み取りは「路線ごとに直近90日を一括で1回」だけなので、起動1回あたり数十KBに収まります。

無料プランは7日間まったくアクセスが無いと止まります。SQL に週1回の軽い読み取りを入れてあるので、利用が無い時期でも止まりません。180日より古い投稿と90日より古い精度ログは毎晩消して、500MBに収まり続けるようにしています。

4. アカウントを作らない作り

アカウントはありません。メールアドレスもパスワードも受け取りません。投稿は端末の中で作った匿名IDのまま行い、保存した条件もその端末に残ります。

お支払いが済むと、その人だけの利用ID（KMD- で始まる英数12文字）が1本出ます。機種変更や2台目は、このIDを入れてもらうことで引き継ぎます。こちらの表に入るのは、このIDを SHA-256 で潰した文字列だけで、元のIDには戻せません。誰が買ったかを、こちらから知る手立てはありません。IDを忘れた方への対応は、決済会社側の記録から引きます（手順は「利用IDを忘れた人への対応」）。