デイサービスの利用予定と住所から、送迎の車両割りと順路の案を毎日作る

処理の起点を決める

2つのきっかけで動かします。 1つは前日15時の定時実行で、翌日の迎えと送りの案を作ります。もう1つは当日の変更連絡で、生活相談員が入力欄に連絡の内容を書き込んだ時点で、案の作り直しを始めます。

前日15時にするのは、介護ソフトの翌日の予定が固まる時刻に合わせるためです。 午前中に翌日の予定の変更が入ることが多く、15時なら大半が反映されています。15時以降に予定が変わったら、当日の変更と同じ扱いで作り直します。

当日の変更は、1件ずつではなく、まとめて作り直すこともできます。 朝7時台に電話が集中するので、7時40分の時点で届いている変更をまとめて1回作り直すと、運転手への伝達が1回で済みます。まとめるか1件ずつかは、事業所の運用で決めます。

電話の内容を自動で拾うことはしません。 連絡は電話で届くことが多く、聞き取った内容を生活相談員が入力欄に書きます。入力された文章が、エージェントの入口です。

入力データを集める

質を決めるのは、条件表です。 生活相談員の頭の中にある条件を表に書き出さないと、計算は条件を知らないまま、最短の順路を出します。 最初の作業は、条件の書き出しです。

乗降に要する時間は、利用者ごとに持たせます。 玄関から車まで介助で5分かかる家と、玄関先で待っている家とでは、同じ地点でも止まる時間が違います。これを入れないと、計算上は間に合っても現場では遅れます。

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

移動時間の表は、毎回すべてを取り直しません。 利用者の住所は頻繁には変わらないので、地点の組ごとの所要時間を保存しておき、新しい利用者や住所の変更があった地点の分だけ取得します。

41地点の表を1回で取れないのは、組の数の上限のためです。 41×41は1,681組で、通常の経路の上限625を超えます。出発地と目的地を25地点ずつの区画に分けて要求すれば、1回あたり625組に収まります。 区画の組み合わせを順に取り、1つの表につなぎます。

住所で指定する地点は、1回の要求で合わせて50までです。 住所の文字列で毎回指定するより、一度、緯度経度に変換して保存し、以後は座標で指定するほうが、上限にも住所の表記の揺れにも強くなります。

返ってきた組の condition を必ず見ます。 経路が見つからなかった組が混ざっていると、その組の所要時間が空になります。空のまま計算に渡さず、その地点を点検の一覧に出します。

AIへ渡す前に整形する

1. 利用者の絞り込み … 翌日の利用予定から、送迎を使う利用者だけを取り出します。家族の送迎や自力で来る利用者を除きます
2. 乗降場所の決定 … 住所ではなく、実際に車を止める場所の座標を使います
3. 時間枠の設定 … 迎えなら「事業所への到着の時刻」と「家族が家にいる時刻」から、各地点の到着の時刻の範囲を作ります
4. 乗降の時間の加算 … 地点ごとの乗降に要する時間を、その地点に止まる時間として持たせます
5. 容量の設定 … 車両ごとに座席の数と車いすの席の数を、別の容量として持たせます
6. 同乗の制約の変換 … 同乗を避ける組み合わせを、計算の道具が扱える形（同じ車両に入れない制約）にします
7. 前の案の固定 … 作り直しのときは、変更に関わらない利用者を前の案と同じ車両に置くよう、ずらすと不利になる重みを付けます

3番目と4番目を軽く見ないでください。 時間枠が広すぎると、計算は到着の時刻を守っているつもりで、家族がいない時刻に迎えに行く案を出します。乗降の時間が抜けると、計算上は全員が間に合い、現場では最後の家が10分遅れます。

AIに処理させる

させるのは、変更の連絡を読み取って条件の変化に直し、4つの道具を順に呼んで案を作り、条件を満たさなければ緩める候補を示して計算し直すことです。

エージェントの役目は、この順番と、失敗したときの次の手を決めることです。 例えば、車いすの利用者が1人増えて車いすの席が足りず、solve_routes が全員を乗せる解を返せなかったとき。エージェントは「送りを2便に分ける」「車いす対応の車両の出発を15分早める」といった緩め方の候補を挙げ、どれを試すかを生活相談員に示します。

緩め方を自分で選んで確定させません。 2便に分ければ誰かの帰宅が遅れ、出発を早めれば誰かの迎えが早まります。どちらを取るかは、利用者と家族の事情を知っている人が決めます。

2行目がいちばん起きやすい失敗です。 「今日は車いすで」という連絡を受けて、エージェントが条件表のその利用者を「車いす」に書き換えると、翌日以降もずっと車いすのまま計算されます。 当日の変更は、その日の計算にだけ効かせます。

指示内容を固定する

あなたはデイサービスの送迎の計画を手伝う立場です。
順路と車両割りは自分で考えず、必ず道具を使って計算してください。

【使える道具】
- get_schedule ....... 利用予定、送迎の条件、前の案を取得する
- get_travel_matrix .. 地点間の所要時間の表を取得する
- solve_routes ....... 車両割りと順路を計算する
- check_constraints .. 案を送迎の条件に照らして点検する

【進め方】
1. 変更の連絡を読み、どの利用者の、どの条件が、その日だけどう変わるかを整理する
2. get_schedule で予定と前の案を取り、連絡に出てくる利用者が予定にいるかを確かめる
3. 新しい地点があれば get_travel_matrix を呼ぶ
4. solve_routes を呼ぶ。変更に関わらない利用者は前の案の車両に残す
5. check_constraints を呼ぶ。違反が0件になるまで、3回まで緩め方を変えて計算し直してよい
6. 結果を、前の案との差分と理由にまとめる

【厳守事項】
- 順路、到着の時刻、所要時間を、道具の結果なしに書かないでください。
- 変更の連絡に書かれていないことを補わないでください。
  連絡があいまいなとき（例：「少し遅れるかも」）は、条件を変えずに確認事項として挙げてください。
- 送迎の条件表を書き換えないでください。当日の変更は、その日の計算にだけ使ってください。
- 利用者のサービスの利用時間を、送迎の都合で変えないでください。
- 緩め方（便を分ける、出発の時刻を動かす、車両を足す）を試したときは、
  それが誰の到着・帰宅の時刻をどう変えるかを必ず書いてください。
- 違反が残る案、利用者を乗せられない案を、完成した案として出さないでください。
  その場合は、残った違反と、生活相談員に決めてほしいことを書いてください。
- 送迎を確定させたり、家族や運転手に連絡したりしないでください。

【変更の連絡】{change_notes}
【対象の日と便】{date_and_trip}

「道具の結果なしに書かない」を明記しないと、所要時間を推測で書きます。 地名から「10分ほど」と見積もった値が、道具の結果と同じ顔をして並びます。時刻と所要時間は、道具が返した値だけにします。

「あいまいな連絡は条件を変えない」も、書かないと起きます。 「少し遅れるかも」を「10分遅く迎えに行く」に直すと、家族が待っているのに通り過ぎる案ができます。 分からないことは、確認事項として人に返させます。

出力形式を固定する

エージェントの最後の返答を、次の形のJSONで受け取ります。 道具の結果そのものは、それぞれの道具が返すJSONをそのまま保存します。

{
  "date": "2026-09-30",
  "trip": "pickup",
  "status": "ready | needs_decision",
  "vehicles": [
    { "vehicle_id": "V2", "stops": [
      { "user_ref": "U-07", "eta": "08:32", "note": "" }
    ] }
  ],
  "changes_from_previous": [
    { "user_ref": "U-12", "from": "V1", "to": "V3", "reason": "" }
  ],
  "violations": [],
  "questions_for_staff": [""]
}

eta は solve_routes が返した到着の時刻を写したもので、エージェントは値を変えません。

1つ目の理由は、status で確定できるかどうかが分かれることです。 check_constraints の違反が0件で、全員が乗っていれば ready、それ以外は needs_decision です。needs_decision のときは、questions_for_staff に決めてほしいことが入ります。

2つ目は、changes_from_previous で朝の確認が速くなることです。 当日の作り直しで、生活相談員が見るのは送迎表の全体ではなく、誰がどの車両に移ったかの数行です。運転手への伝達も、この差分だけで済みます。

要は、status を道具の結果から機械的に決めることです。 エージェントが「おおむね問題ない」と書いても、違反が1件でもあれば ready にはしません。 最後の判定は、プログラムが check_constraints の結果から付け直します。

システムへ連携する

条件表には書き込みません。 条件表を直すのは生活相談員で、エージェントからの読み取りだけを許します。 道具として条件表を書き換える関数を用意しないことで、書き換えの経路そのものを作りません。

運転手への配信も作りません。 確定した送迎表を印刷するか、事業所の連絡の手段で送るかは、今の運用のままにします。

人が確認する

生活相談員は、すべての案を確定の前に見ます。

1. status を見る … needs_decision なら、questions_for_staff と violations を先に読みます
2. 差分を見る … 当日の作り直しでは、changes_from_previous の数行を確かめます。移された利用者が、その車両で困らないか（添乗の職員、乗降の介助）を見ます
3. 到着の時刻を見る … 家族の都合の時刻に近い家を中心に、eta を確かめます
4. 確定する … 送迎表に確定の印を付け、運転手に伝えます
5. 手で直したら記録する … 案をどう変えたか、なぜ変えたかを残します

5番目は、条件表を育てるための記録です。 生活相談員が毎回同じ理由で案を直しているなら、それは条件表に書かれていない条件です。 月に一度見直して、条件表に足します。

前日の案の確認は5〜10分、当日の作り直しの確認は数分が目安です。 それより長くかかる日が続くなら、条件表に抜けがあるか、乗降の時間の設定が現場と合っていません。

例外に対処する

上の2行が、計算の道具ならではの例外です。 条件が厳しすぎると解が無く、地点が多いと計算が長くなります。容量の制約の説明でも、需要が容量を超えると解が無いことがあり、時間の上限を設けること、訪問を落とす代わりに罰を与える方法が示されています。この構成では、利用者を落とした案を完成した案として出さず、必ず人の判断に回します。

記録を残す

• 変更の連絡の文章と、入力した人・時刻
• エージェントが呼んだ道具の順番、それぞれの入力と結果のJSON
• 計算に使った条件表と車両の表の版、移動時間の表の取得日
• 最後の案と status、生活相談員が確定した送迎表
• 生活相談員が手で直した箇所と理由
• 解が見つからなかった日と、選んだ緩め方

2つ目で道具の呼び出しを全部残すのは、案がおかしかったときに、どこで崩れたかをたどるためです。 連絡の読み取りが違ったのか、計算の入力が違ったのか、点検が見落としたのかが、ログから分かります。

5つ目は、第7章「人間の確認」で書いた条件表の見直しの材料です。