タクシー会社の乗車記録から翌日の時間帯・エリアごとの乗車の需要を予測し、乗務員の出庫の枠と待機場所の案を出す

処理の起点を決める

毎日15時の定時実行を起点にします。 翌日の天気予報が出そろい、運行管理者が夕方に翌日の指示を作る前に一覧ができている時刻です。当日の朝に作る形にはしません。 早番の乗務員には前日のうちに出庫の時刻を伝える必要があるからです。

作るのは翌日の1日分だけです。 1週間分をまとめて作ると、天気予報の外れが大きい日の案が混ざります。週の見通しが欲しいときは、別に中央の値だけを参考として出します。

モデルの学び直しは月に1回です。 毎月1日に直近24か月で学ばせ直し、前のモデルより当たっているかを確かめてから入れ替えます。 当たり方が悪くなっていれば、前のモデルを使い続けて運行管理者に知らせます。

入力データを集める

質を決めるのは、配車の依頼の「配車できたか」の列です。 この列があれば、応えられなかった依頼の件数を時間帯とエリアで数えられます。無ければ、車が足りなかった時間帯の需要を知る手がかりがありません。 書き始める前に、配車システムが断った依頼を記録しているかを確かめてください。

催しの表は営業所が作ります。 会場の終演の時刻は、乗車の記録からは分かりません。ここに載っていない催しの日は、モデルが普段と同じ傾向で見込みます。

読まない列も決めておきます。 配車アプリの利用者のID、電話番号、降車の位置は書き出しの段階で外します。見込みに要るのは、時刻とエリアの件数だけです。

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

配車システムとメーターの記録から、前日までの乗車と配車の依頼をそれぞれ書き出します。 項目と形式は製品ごとに違うので、最初に書き出しの列を決めて固定します。毎日の処理の最初に、列の名前と数が決めたとおりかを照らし、違えばそこで止めます。 配車システムの更新で列が1つずれただけで、エリアの件数がすべて別のエリアに入るからです。

メーターの記録に乗車の位置が残らない車両がある場合は、その車両の乗車を「位置なし」として数え、営業所の時間帯の合計にだけ入れます。 エリア別の件数には入れられませんが、枠の割り当てに使う合計は正しくなります。

学ばせるときの答えは、「乗車件数 ＋ 応えられなかった依頼の件数」にします。 応えられなかった依頼は、同じ客が何度も依頼し直していることがあるので、同じ迎えの位置から10分以内に続いた依頼は1件にまとめます。 流しの客の取りこぼしは記録に残らないので、この答えも需要の下限だと割り切ります。

AIへ渡す前に整形する

1. エリアへの当てはめ … 乗車と迎えの位置を、エリアの区分の表で24エリアに当てはめます。区域の外の位置は「区域外」にまとめます
2. 1時間ごとの集計 … エリア × 1時間ごとに、乗車件数と応えられなかった依頼の件数を数えます。件数が0の時間帯も行として作ります
3. 依頼のまとめ … 同じ位置から10分以内に続いた依頼を1件にします
4. ずらした特徴 … 1週間前・2週間前・前年の同じ曜日の同じ時間帯の件数を列にします
5. 天気の区分 … 降水量を「なし・弱い・強い」の3つに束ね、カテゴリの型にします
6. 異常な日の印 … 大きな事故や災害で営業が止まった日は、学ばせる記録から外します

学ばせる記録の1行は、次のような形にします。1行が「ある営業所の、あるエリアの、ある日の1時間」です。 24エリア × 24時間 × 365日で、1営業所あたり年に約21万行になります。

{
  "office": "north",
  "area": "station_east",
  "date": "2026-09-18",
  "hour": 22,
  "weekday": "fri",
  "holiday_flag": "eve_of_holiday",
  "month_end": true,
  "rain_class": "light",
  "temp_c": 19.5,
  "event_end_nearby": true,
  "lag_7d": 14,
  "lag_14d": 11,
  "lag_364d": 9,
  "rides": 17,
  "unserved_requests": 6,
  "target": 23
}

rides と unserved_requests は答えを作るための列で、特徴には入れません。 特徴に入れるのは、翌日の15時の時点で分かる列だけです。lag_364d は前年の同じ曜日に合わせた値で、暦の日付ではなく曜日をそろえて引きます。 祝日の前の金曜と普通の金曜は、holiday_flag で分けます。

2番目の「0件の行を作る」を省くと、見込みが多めにずれます。 乗車が無かった時間帯の行が無いと、モデルは「件数がある時間帯」だけから学びます。深夜の住宅地のような時間帯こそ、0件の行が要ります。

4番目で「1日前」を使わないのは、15時の時点で前日の深夜の記録が出そろっていないことがあるからです。 予測の時点で手に入らない値を特徴に入れると、検証では当たるのに本番では当たらないモデルになります。

AIに処理させる

させるのは、翌日の1時間ごと・エリアごとの需要の件数を、中央の値と上側の値で見込むことだけです。 台数への換算、枠の割り当て、休息期間の確認は、見込みを受け取った後の Python の側で行います。

見込みは2つ出します。 loss="poisson" のモデルで中央の見込み、loss="quantile" で quantile=0.9 のモデルで上側の見込みです。台数は中央の値で決め、上側の値は「足りなくなりそうな時間帯」に印を付けるのに使います。

台数への換算は、決まった式で行います。

必要台数（時間帯 t）= Σ エリア の 中央の見込み ÷ 1台が1時間に運べる件数（営業所の実績）
不足の印 = Σ エリア の 上側の見込み ÷ 1台が1時間に運べる件数 ＞ その時間帯の稼働台数
出庫の枠の台数 = 早番・通常・遅番の組み合わせのうち、
                 各時間帯の稼働台数と必要台数の差の合計が最も小さいもの

3行目が大事です。 見込みを乗務員ごとの「取れたはずの件数」に直して成績と比べると、待機場所を指示された乗務員ほど不利になることがあります。 見込みはエリアと時間帯のもので、人のものではありません。

当たり方は、時間帯の合計とエリア別の2段で見ます。 枠の割り当てに効くのは営業所全体の時間帯ごとの合計で、待機場所の案に効くのはエリア別の件数です。エリア別の1時間の件数は小さく、ばらつきが大きいので、合計が当たっていればまず枠の案は使えます。 検証では、時間帯の合計の絶対誤差の平均と、上側の見込みを実際の件数が超えた割合（9割の分位なら1割前後が目安）を毎月の一覧に出します。超えた割合が2割を超えるようなら、上側の見込みが低すぎます。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、学習・計算・一覧の作成を決める設定を、ひとつのファイルにまとめます。

【見込む先】
target: 乗車件数 ＋ 応えられなかった依頼の件数（10分以内の重複は1件）
単位: 営業所 × エリア（24）× 1時間
学習期間: 前月までの24か月  検証: TimeSeriesSplit（日付の単位で4つに分け、gap で直前の1日を除く）

【モデル】
中央の見込み: HistGradientBoostingRegressor(loss="poisson")
上側の見込み: HistGradientBoostingRegressor(loss="quantile", quantile=0.9)
categorical_features: from_dtype
入れ替えの条件: 検証の期間で、前のモデルより絶対誤差の平均が小さいこと

【台数への換算】
1台が1時間に運べる件数: 営業所ごとの直近3か月の実績
出庫の枠: 早番 6:00／通常 8:00／遅番 11:00（いずれも日勤）

【休息期間の確認（改善基準告示）】
日勤: 前日の終業から継続9時間を下回る枠には入れない
      （継続11時間を下回る場合は「努力の基準未満」と表示）
1日の拘束時間: 13時間を超える割り当ての案は出さない
隔日勤務: 割り当ての対象外（勤務表どおり）

【待機場所】
各時間帯で中央の見込みの多い上位5エリアに、見込みの比で台数を割る
会社が使える乗り場と待機所の一覧にある場所だけを出す

【一覧に載せる内容】
- 時間帯ごとの稼働台数の案、必要台数、不足の印
- 乗務員ごとの出庫の枠の案と、候補から外した理由
- 時間帯ごとの待機場所と台数の案
- 前日の案と、運行管理者が決めた割り当て

休息期間の基準を設定ファイルに書くのが大事です。 厚生労働省のページでは、タクシーの日勤の休息期間は継続11時間を与えるよう努めることを基本とし、9時間を下回らないものとされています。9時間は外す線、11時間は表示する線として分けて持ちます。 1日の拘束時間は13時間以内（延長しても上限15時間）とされているので、案では13時間を超える割り当てを出しません。

待機場所を「会社が使える場所の一覧」に限るのは、見込みが多いエリアでも車を止めてよい場所が決まっているからです。 一覧に無い場所を案に出すと、乗務員が路上で待つことになりかねません。

出力形式を固定する

一覧は表で出し、同じ内容を JSON でも残します。 表は運行管理者が読むため、JSON は翌日が過ぎた後の突き合わせのためです。

{
  "run_at": "2026-10-14T15:00:00+09:00",
  "office": "north",
  "target_date": "2026-10-15",
  "hourly": [
    { "hour": 7, "demand_median": 0.0, "demand_p90": 0.0,
      "required_cars": 0, "planned_cars": 0, "shortage_flag": false }
  ],
  "shift_plan": { "early": 0, "normal": 0, "late": 0 },
  "assignments": [
    { "driver_id": "", "proposed_shift": "early | normal | late",
      "rest_hours_before": 0.0, "excluded_from": [], "reason": "" }
  ],
  "standby": [ { "hour": 7, "place_id": "", "cars": 0 } ],
  "model_version": "",
  "decided_by": "",
  "decided_shift_plan": null
}

1つ目の理由は、案と決定を同じ行に残せることです。 shift_plan は計算が埋め、decided_shift_plan は運行管理者が埋めます。翌月の振り返りで、案どおりなら足りたか、運行管理者の判断でどうだったかを比べられます。

2つ目は、excluded_from と rest_hours_before で外した理由が分かることです。 早番に入れられなかった乗務員が、休息期間のためか、他の理由かを読めます。

システムへ連携する

配車システムへは書き込みません。 待機場所の案を配車システムに入れて自動で指示を出すと、運行管理者が乗務員の事情を見て直す余地がなくなります。

人が確認する

1. 不足の印がある時間帯を見る … 予備の乗務員や、隔日勤務の乗務員の出庫の時刻で手当てできるかを考えます
2. 外した乗務員の理由を見る … 休息期間で外れた乗務員を、案と違う枠に入れていないかを確かめます
3. 記録に無い事情を足す … 道路の工事、新しい催し、車両の整備の予定を見て、待機場所と枠を直します
4. 決めた割り当てを記録する … 案と違う割り当てにしたら、decided_shift_plan と短い理由を残します

2番目を省かないでください。 案は休息期間を守った形で出ますが、運行管理者が直すときに守れていない枠へ移すことがあります。 直した後の割り当ても、同じ計算でもう一度確かめられるようにします。一覧の表計算に「確かめ直す」のボタンを置き、直した割り当てを読み込んで同じ計算をかける形が扱いやすいです。

3番目は、営業所の運行管理者どうしで共有します。 駅前の工事で乗り場の位置が変わった、病院の外来の時間が変わった、といった情報は、どれか1つの営業所が知っていても、他の営業所の案には入りません。 催しの表と同じ場所に「エリアの変化」の欄を作り、気づいた人が書き足します。

目標は、90件をならして1件20分です。 不足の印が無く、前日と案が大きく変わらない日は数分で終わり、雨や催しの日は手当てを考えるのに時間がかかります。

例外に対処する

3行目を「外す」側に倒しているのは、誤りの向きを決めるためです。 確かめられない乗務員を早番に入れると、休息期間を割っていても気づけません。 外れて足りなくなる分は、運行管理者が手で補います。

記録を残す

• 毎日の書き出しと、1時間ごと・エリアごとの集計
• 見込み（中央の値と上側の値）と、使ったモデルの版
• 出庫の枠の案、割り当ての案、外した理由
• 運行管理者が決めた割り当てと、案と違うときの理由
• 翌日の実際の乗車件数と、応えられなかった依頼の件数
• 設定ファイルの変更の履歴（休息期間の線、出庫の枠の時刻）

4つ目と5つ目を並べて残すのが、この構成の振り返りの土台です。 3か月分たまると、見込みが外れやすい時間帯とエリア、運行管理者の判断が案より当たる場面が分かります。