路線を選ぶ

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両の誤差があります。山手線は動線がまだ未確認（仮置き）で、階段の位置は投稿が集まってから確定します。方向シェア・時間帯分布・運転本数・種別の構成比も仮定値です。

路線ごとに scale（公表の乗車人員と、実際に電車に乗っている人数の差を埋める倍率。乗り換えだけの利用や定期外の流入を含みます）と allday（終日まんべんなく使われる度合い。山手線のように通勤の山が緩い路線で使います）の2つを、公表されている最混雑区間の値に合うように決めています。いまの設定では、つくばエクスプレスの平日7:30・北千住到着が154%、山手線の外回り・上野→御徒町が135%になり、どちらも公表値と一致します。あてはめに使ったのはこの2点だけです。使っていない値でも合います：山手線の内回りは、こちらから場所を指定していないのに、公表と同じ新大久保→新宿がいちばん混む区間になり（約130%、公表136%）、時間帯の山も朝7:30〜8:30に出ます。これらのズレは投稿が集まるほど較正が吸収します。

出典

この試作は、投稿の保存先を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に紐づいた保存条件と購読を引き継ぎます。機種変更で困るのは課金した人だけなので、そこだけメールアドレスをもらう作りです。