路線バスの会社が乗降の記録（ICカード）から Python で系統・時間帯ごとの乗客数を予測し、ダイヤの見直しの候補を出す

処理の起点を決める

毎月2日の朝6時に動かします。 前月の末日の最終便の精算が締まり、精算の仕組みから乗降の記録が書き出された後です。計画課が月の初めの会議の前に検討表を見られる時間に間に合わせます。 書き出しの時刻は、精算の仕組みの保守の会社と決めます。

ダイヤの改正の前は、もう一度動かします。 改正の案ができたら、案の便の時刻で同じ見込みを作り直し、改正後の便ごとに、最も混む区間の人数の見込みと定員の比べを出します。改正の案そのものを作るのではなく、案の便に見込みを当てはめるだけです。

書き出しが届いていない、または件数が前月の半分を下回るときは、動かしません。 精算の仕組みの障害や書き出しの漏れで記録が欠けた月を、そのまま学ばせないためです。計画課に知らせ、保守の会社に書き出しのやり直しを頼みます。

入力データを集める

質を決めるのは、学校の予定です。 通学の系統の乗客数は、学校が授業のある日かどうかでほぼ決まります。祝日の表だけでは、夏休みの始まりの日も、試験期間の早帰りも入りません。 沿線の高校・大学の年間の予定を、毎年の初めに日付の表にします。

乗降調査の割合も欠かせません。 ICカードの記録には現金の乗客が入りません。現金の割合は系統ごとに違い、高齢の乗客の多い系統ほど高くなりがちです。 年1回の乗降調査で数えた割合を、系統ごとに持ちます。

データの取得方法を決める

精算の仕組みからは、決まった列の並びで、1か月分の乗降の記録をファイルに書き出す設定を作ります。書き出しは保守の会社の作業になることが多いので、列の並びとカードの番号の置き換えの方法を、最初に取り決めます。

GTFS-JPのデータは、改正のたびに版を残します。 前年の同じ月と比べるには、前年の便と今年の便がどう対応するかが要ります。便の番号は改正で振り直されることがあるので、系統・方向・始発の停留所の発車の時刻の時間帯で対応を取ります。

カードの番号の置き換えは、月ごとに鍵を変えません。 同じカードが翌月も同じ記号になるようにしておくと、定期券の乗客が何月から乗らなくなったかを数えられます。ただし、計画課は記号から人を割り出せず、置き換えの鍵は精算の仕組みの側だけが持ちます。

AIへ渡す前に整形する

1. 乗車と降車を組み合わせる … 同じ記号のカードの、同じ便での乗車と降車を1つの乗車にします。降車のタッチが無いもの（タッチの忘れ、精算の失敗）は、別に数えます
2. 便に当てる … タッチの車両と時刻から便を決め、停留所を stop_sequence の順に並べます。日をまたぐ便は24時を超える時刻で扱います
3. 車内の人数を積み上げる … 便ごとに、停留所の順に「乗車 − 降車」を足していき、区間ごとの車内の人数を出します。いちばん大きい区間が、その便の最も混む区間です
4. 現金の乗客を補う … ICカードの人数を、系統ごとの現金の割合で割り戻します。割り戻した値と元の値は別の列に持ちます
5. 異常の日を外す … 運休・迂回・大幅な遅れ・臨時便の日を、運行管理の記録から印にします
6. 時間帯に束ねる … 始発の停留所の発車の時刻で1時間ごとに束ね、系統・方向・時間帯・日ごとの乗客数と、その時間帯の便の最も混む区間の人数の最大を作ります
7. 項目を作る … 曜日、日の種類、祝日、学校の授業の有無、試験期間、年末年始、降水量、雪、前年の同じ週の乗客数、その時間帯の便の数

3番目を正しく作るのが、この構成の土台です。 降車のタッチが無い乗車を「その便の終点まで乗った」と扱うと、終点に近い区間の車内の人数が多めに出ます。 降車の無いものは、その系統の区間ごとの降車の割合で振り分け、振り分けた数は別に残します。

7番目に「その時間帯の便の数」を入れるのは、便を減らした月の乗客数の減りを、需要の減りと取り違えないためです。 1時間に3便から2便に減らせば、その時間帯の乗客数は便の数とともに動きます。便の数を項目に入れておくと、改正の案の便の数で見込みを作り直せます。

AIに処理させる

させるのは、系統・方向・時間帯・日の種類ごとに、翌月から3か月先までの乗客数と最も混む区間の人数を、真ん中と幅で見込むことだけです。 定員との比べ、印付け、候補の並べ替えは、決まった計算で行います。

真ん中はポアソン損失、幅は分位点の損失で、別々のモデルにします。 乗客数は0以上の数える値で、時間帯によっては1便に数人という少ない数になります。二乗の誤差で学ばせると、少ない時間帯で見込みがマイナスに振れることがあります。 混雑の判断には上側を使うので、上側は quantile=0.9 のモデルで見込みます。

2行目がいちばん起きやすい失敗です。 「7時台の便を7時15分に動かしたら何人乗るか」を見込みたくなりますが、記録にあるのは、いまの時刻で乗った人だけです。 時刻を動かした後の乗り換わりを数字で出すと、根拠の無い数字が検討表に並びます。改正の案に当てはめるのは、便の数が変わった時間帯の、時間帯全体の乗客数までにします。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と計算の規則を書いておきます。

【モデル（全系統で1つ。系統・方向は項目として持つ）】
- scikit-learn の HistGradientBoostingRegressor
  ・真ん中   … loss="poisson"
  ・上側     … loss="quantile", quantile=0.9
  ・下側     … loss="quantile", quantile=0.1
  ・categorical_features = [系統, 方向, 日の種類, 時間帯]
    （pandas の category 型にしておく）
  ・目的の値 = 時間帯ごとの乗客数（現金の補い後）
               と、時間帯の便の最も混む区間の人数の最大
- 学ばせる記録 = 過去3年。異常の日の印のある日は外す
- 学ばせ直しは毎月。確かめは直近3か月を外して学ばせ、外した3か月で見る

【見込みの作り方】
- 翌月から3か月先までの日ごとの暦と、平年並みの気象の値を項目にする
- 便の数は現行のダイヤの値。改正の案があるときは案の値でも作る
- 日ごとの見込みを、日の種類ごとの1日あたりの平均に直す

【印を付ける条件】
- crowd        … 最も混む区間の上側が、その便の車両の定員の90％以上
- sparse       … 時間帯の便の1便あたりの乗客数の真ん中が5人未満
- shift        … 真ん中が前年の同じ月の実績から15％以上違う
- short_history … 学ばせる記録が12か月に満たない（新しい系統・経路の変更）
- no_alight    … 降車のタッチが無い乗車が、その系統の乗車の10％超
- 印の無い系統は、見込みと前月の実績を並べて検討表に載せる

定員の90％、5人未満、15％という線は、計画課が決める値です。 線を設定の表に置き、プログラムには書き込みません。線を変えたら、いつ誰が変えたかを残します。 線が変わると、同じ見込みでも拾われる便が変わるからです。

quantile=0.9 を混雑の判断に使うのは、10日に1日の混み方まで見るためです。 真ん中で比べると、雨の日や試験期間の初日にだけ積み残しが出る便を拾えません。積み残しは平均の日ではなく混む日に起きます。

出力形式を固定する

系統・方向・時間帯・日の種類ごとに、次の形のJSONを作り、表にして検討表に載せます。

{
  "route": "",
  "direction": 0,
  "day_type": "weekday | saturday | holiday | school_off",
  "hour_band": "07",
  "month": "",
  "trips_in_band": 0,
  "riders": { "p50": 0, "p10": 0, "p90": 0 },
  "peak_load": { "p50": 0, "p90": 0, "capacity": 0, "peak_segment": "" },
  "last_year_same_month": 0,
  "ic_share_used": 0,
  "flags": ["crowd | sparse | shift | short_history | no_alight"],
  "top_factors": [""],
  "model_version": "",
  "planner_note": ""
}

1つ目の理由は、peak_segment で「どこで混むか」を示せることです。 便全体の人数だけでは、どの停留所の間で立ち客が出るかが分かりません。混む区間が駅の手前の数停留所に限られるなら、区間便という選び方も検討できます。

2つ目は、ic_share_used で補いの前提を残せることです。 見込みは現金の割合で割り戻した値なので、乗降調査の割合が古いと、見込み全体がずれます。 どの割合を使ったかを並べておけば、調査をやり直すべき系統が分かります。

3つ目は、planner_note に担当の書き添えを残せることです。 「4月から沿線の高校が移転」「病院の外来の曜日が変わる」のように、記録に無い事情を担当が書けば、それが翌年の暦の項目の候補になります。

システムへ連携する

運行の時刻のデータにも、何も書き戻しません。 改正の案の便の時刻は、計画課が自分で作ったGTFS-JPの案のファイルから読みます。見込みから時刻を書き換える経路は作りません。

通知には乗客数の数字を流しません。 流すのは「crowd が何便、sparse が何便」と検討表の場所だけにし、乗降の記録から作った数字が連絡の場の外へ写される経路を作りません。

人が確認する

計画の担当が見るのは、印の付いた系統の根拠です。 印の無い系統は、見込みと前月の実績の並びを流し見て終わりにします。全系統の表を前の方法で作り直す運用にすると、第10章の18.0時間には収まりません。

1. crowd を先に見る … 上側が定員の90％を超える便です。運行の部門に、積み残しや乗り切れない報告が実際に出ているかを確かめます
2. shift を見る … 前年から大きく変わった系統です。沿線の施設の開業・閉店、学校の移転、経路の変更など、記録に無い理由が無いかを確かめます
3. sparse を見る … 乗客の少ない時間帯です。その時間帯の便が、通院や通学の唯一の足になっていないかを確かめます
4. no_alight と short_history を見る … 見込みの土台が弱い系統です。検討の候補に入れる前に、乗降調査で人数を確かめます
5. 書き添える … 確かめた事情を planner_note に残します

3番目を省かないでください。 乗客数が少ない便を減らすと、その時間にしか通えない人の足が無くなります。 乗客数の見込みは、減便の候補を並べる道具であって、減便を決める道具ではありません。自治体の補助を受ける系統は、とくに地域の協議の場で確かめてから進めます。

課長が在職しているうちは、月に1回、印の無い系統も並べて見てもらいます。 見込みと課長の見立てが同じ向きにずれる系統が続くなら、モデルに入っていない手がかり（沿線の行事、病院の外来の曜日）があるということです。 その手がかりを暦の項目に足すことが、引き継ぎの中身になります。

例外に対処する

上から2行目は、毎月必ず起きます。 降りるときのタッチを忘れる乗客、精算の機械の不調、車内の混雑で後ろの扉から降りた乗客がいます。割合が急に増えた系統は、機械の故障を疑って運行の部門に知らせます。 見込みの誤りより先に、記録の取り方の問題を直します。

記録を残す

• 読み込んだ乗降の記録の件数と、置き換えの方式の版
• 便ごとの乗車の人数、区間ごとの車内の人数、最も混む区間
• 系統・方向・時間帯・日の種類ごとの見込み（真ん中・上側・下側）と印
• 計画の担当の書き添え（planner_note）と、候補にした・しなかった理由
• 翌月の実際の乗客数と、見込みの外れ方
• モデルの版、学ばせた期間、印の線の値

5つ目の外れ方は、系統ごとに毎月並べます。 外れが続く系統は、暦の項目が足りないか、現金の割合が古いかのどちらかです。外れ方の記録が、見込みを信用してよい系統とそうでない系統の目印になります。