配送先で困ったことをドライバーとの対話で聞き取って、配送先ごとの申し送りにする

処理の起点を決める

配送管理システムで配送完了が登録されたときを起点にします。

タイミングがこの構成の成否を分けます。 配送の直後が、いちばん覚えている時点です。帰庫後にまとめて聞くと、細かいことは思い出せません。

ただし、配送直後は次へ向かっている最中です。 そこで長い質問を出すと無視されます。最初の質問は1つだけにしてください。

◯◯（配送先名）、おつかれさまでした。
何か困ったことはありましたか？

［なかった］［あった］

「なかった」を押すだけで終わる形にしてください。 大半の配送は問題なく終わります。1タップで終わるから、次も押してもらえます。

「あった」を押した人にだけ、聞き取りを始めます。 月260件がここに当たる想定です。

もう1つの起点として、代走のときの事前配信があります。 配車の時点で、そのドライバーがその配送先へ行くのが初めてかを判定し、台帳の申し送りを事前に渡します。 これは対話ではありませんが、集めた情報を使う側の仕組みとして必ず組み込んでください。

月次の集計のトリガーも置きます。 月初に、前月の報告を集計して配車担当へ渡します。同じ配送先で繰り返し出ている報告は、配送先そのものと交渉すべき事柄です。

入力データを集める

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

困りごとの種類の一覧が、この構成の質を決めます。 自由記入で聞くと、ドライバーは答えるのが面倒になります。最初に種類を選ばせて、そこから絞り込む形にしてください。

この8種類が、実務ではほぼすべてを覆います。 種類を増やしすぎると選ぶのが面倒になります。「その他」を1つ置いて、そこに集まったものを見て種類を足してください。

「選んだあとに聞くこと」を先に決めておくことが重要です。 種類ごとに3〜4問。これを決めずに対話させると、聞くことがぶれます。

配送先台帳の項目も、あわせて整理してください。 現状の備考欄1つを、次の項目に分けます。

「有効期限」の列が、建設向けの構成では必須です。 工事現場は工期が終われば配送先そのものがなくなります。期限のない申し送りが残り続けると、台帳が使えなくなります。

過去の報告： 運用を始めてからたまります。同じ配送先で3回同じ報告が出たら、それは台帳に書くべき恒常的な制約です。 1回だけの報告は、その日の事情かもしれません。

AIへ渡す前に整形する

1. 配送先の特定 … 配送管理システムの配送先コードで紐づけます。名称での突合はしないでください。 同じ現場が複数の名前で登録されていることがあります
2. 初回かどうかの判定 … そのドライバーがその配送先へ行った回数を見ます。初回の人の報告は、恒常的な制約である可能性が高くなります
3. 既存の申し送りの取得 … 台帳にすでに書かれている内容を対話へ渡します。同じことを報告させないためです
4. 過去の報告の取得 … その配送先について過去に集めた内容を渡します
5. 車両の情報の付加 … 「入らなかった」という報告は、車格によります。どの車で行ったかを記録に残します
6. 個人情報の確認 … 配送先の担当者名は個人情報です。台帳に載せる範囲を決めてください

3の「既存の申し送りを渡す」ことが、対話の質を大きく左右します。 すでに台帳に「東側の資材置き場に停める」と書かれているのに、ドライバーが同じことを報告することがあります。既存の記載を渡しておけば、「それはすでに登録されています。それ以外に何かありましたか」と返せます。

この返しには、もう1つの効果があります。 台帳に書かれているのにドライバーが知らなかった、という事実が分かります。事前配信が届いていないか、読まれていないということです。 配信の仕組みを見直す材料になります。

2の「初回かどうか」の判定も、見かけ以上に効きます。 その配送先へ初めて行った人の報告は、「その配送先が初めての人にとって分かりにくい点」を示しています。 ベテランは無意識に対処しているため、報告しません。

初回の人の報告は、台帳へ載せる優先度を上げてください。 代走のときに役立つのは、まさにこの種の情報です。

5の車両の情報を記録する理由も補足します。 「入らなかった」という報告は、その車で入らなかったという意味です。4トン車では入れないが2トン車なら入る、という状態は珍しくありません。 車格を記録しないと、申し送りが「入れない」という誤った一般化になります。

AIに処理させる

対応の指示はさせません。 「次回からは裏口へ回ってください」といった指示を出させないでください。台帳へ反映するかは配車担当が決めます。

配送先への要望もまとめさせません。 「駐車場の確保を依頼すべき」という判断は、取引先との関係を見て人が決めます。

ドライバーの対応の評価もさせません。 「もっと早く連絡すべきだった」といった記述を出させないでください。報告が止まります。

指示内容を固定する

あなたは運送会社の運行管理の担当者です。
配送を終えたドライバーから、その配送先で困ったことを聞き取り、
次に行く人への申し送りにまとめることが役割です。

【厳守事項】
- 質問は1つずつしてください。一度に2つ以上聞かないでください。
  運転中や次の配送に向かう途中で答えることを前提にしてください。
- 質問は短く書いてください。1問30文字以内を目安にしてください。
- 選択肢で答えられる質問は、選択肢を示してください。
  自由入力を求めるのは、選択肢で表せないときだけにしてください。
- 聞き取りは4往復までにしてください。
  4往復で聞き終わらなければ「あとは配車担当から連絡します」と伝えて終えてください。
  **長く聞くと、次から答えてもらえなくなります。**
- ドライバーの対応を評価しないでください。
  「もっと早く連絡すべきでした」「確認不足です」と書かないでください。
- 次回の対応を指示しないでください。
  「次回は裏口へ回ってください」と書かないでください。
  台帳へ反映するかは配車担当が決めます。
- 配送先への要望をまとめないでください。
  「駐車場の確保を依頼すべき」と書かないでください。
- 下の「すでに台帳に登録されている内容」に書かれていることを報告された場合、
  「その点は登録済みです。それ以外に何かありましたか」と返してください。
- 「いつもそうなのか、その日だけか」を必ず確認してください。
  ここが分からないと、台帳に書いてよいかが判断できません。
- 答えが曖昧なまま2回聞き直しても具体的にならない場合、
  そのまま記録して「配車担当が確認します」と伝えてください。
- 最後に必ず「ありがとうございました」と伝えて終えてください。
  報告してもらうことが目的なので、気持ちよく終わることが大事です。

【配送先】
{delivery_site}

【すでに台帳に登録されている内容】
{existing_notes}

【この配送先についての過去の報告（直近5件）】
{past_reports}

【困りごとの種類と、種類ごとに聞くこと】
{question_sets}

【今回の配送の情報（車両・時間帯・荷物）】
{delivery_info}

「4往復まで」の制限が、この構成でもっとも重要です。 ドライバーは運転の合間に答えます。10往復も続けば、次から「なかった」を押すようになります。 聞き切れなかった分は、配車担当が電話で聞けばよいことです。

「1問30文字以内」の指示も効きます。 スマートフォンの画面で長い質問を読むのは負担です。「どこに停めましたか？」で十分です。

「いつもそうか、その日だけか」の確認は、台帳の質を決めます。 「今日は工事で裏口が塞がっていた」は一時的な事情です。これを台帳に書くと、翌週には誤った情報になります。

「気持ちよく終わる」の指示を入れる理由があります。 この構成は、ドライバーの自発的な協力で成り立ちます。報告して良かったと思える体験でないと、続きません。 実際に台帳へ反映されたことを後で知らせる仕組みも、あとで述べます。

出力形式を固定する

{
  "report_id": "",
  "delivery_site_code": "",
  "driver_id": "",
  "reported_at": "",
  "vehicle_class": "",
  "category": "reception | parking | unloading | time_window | receiver | slip | route | other",
  "findings": [
    {
      "item": "",
      "detail": "",
      "permanence": "always | usually | this_time_only | unknown",
      "maps_to_ledger_field": "",
      "conflicts_with_existing": false,
      "existing_text": ""
    }
  ],
  "turns": 0,
  "incomplete": false,
  "needs_dispatcher_call": false,
  "similar_past_reports": 0,
  "driver_first_visit": false,
  "suggested_note": ""
}

OpenAI API で出力をスキーマに沿わせるには、text の format に type: "json_schema" と strict: true、そして schema を渡します。 strict: true にすると、必須のキーが欠けたり、定義していない列挙値が返ったりしないことが保証されます。

ただし、トークンの上限に達した場合や、安全上の理由でモデルが応答を拒否した場合は、スキーマに沿わない応答になります。 拒否の場合は refusal のフィールドが別に返ります。受け取った側で、この2つの場合を扱う処理を入れてください。

permanence の列が、この構成の核です。 「いつも」「たいてい」「その日だけ」「不明」の4つに分けます。this_time_only は台帳へ反映しません。 unknown は配車担当が判断します。

conflicts_with_existing は、台帳の更新のきっかけになります。 台帳に「正門で受付」と書かれているのに「裏門で受付した」と報告されたら、どちらかが古いということです。

driver_first_visit を記録する理由があります。 初めて行った人の報告は、その配送先の「分かりにくさ」を示します。 ベテランが当たり前だと思っていることが、初回の人には分かりません。

suggested_note は、台帳に書く文の下書きです。 配車担当はこれを見て、そのまま使うか直すかを決めます。

システムへ連携する

台帳への自動反映は行いません。

自動反映をしない理由は、台帳が次に行く人の判断の根拠になるからです。 誤った情報が入ると、次の人が誤った行動をとります。1件ずつ確認する価値があります。

最後の「反映されたことの通知」を必ず入れてください。 報告したドライバーへ「あなたの報告を台帳に反映しました」と返します。これがないと、報告しても何も変わらないと感じて、次から報告しなくなります。

配送先への連絡は自動化しません。 「駐車場を確保してほしい」といった要望は、営業と配車担当が判断して伝えます。取引先との関係に関わることを自動化しないでください。

代走のドライバーへの事前配信は、自動で構いません。 配車の時点で、そのドライバーがその配送先へ行くのが初めてなら、台帳の申し送りをTeams で送ります。ここは判断が要らないため、自動でよい部分です。

人が確認する

配車担当が、台帳への反映を判断します。

確認を速くするための設計が効きます。

• suggested_note をそのまま台帳へ入れられる形にする
• 既存の記載と並べて表示する
• 同じ配送先の過去の報告をまとめて表示する
• similar_past_reports が多い順に並べる
• 反映・不採用をその場で選べるようにする

3つ目が効きます。 同じ配送先について3人から似た報告が来ていれば、それは確かな情報です。 1件ずつ見るより、配送先ごとにまとめて見るほうが判断が速くなります。

月次の見直しも、人の作業として組み込んでください。

例外に対処する

「報告がドライバーの評価に使われる」が、この構成を壊す最大の要因です。 「報告が多い＝トラブルが多いドライバー」という見方が生まれると、誰も報告しなくなります。導入時に、評価に使わないことを明確に伝えてください。 そして実際に使わないでください。

記録を残す

この記録は、台帳を育てる材料になります。

• 対話の全文（何を聞き、どう答えたか）
• 報告の種類と内容
• permanence の判定
• 既存の記載との食い違い
• 配車担当が反映したか、しなかったか、その理由
• 反映後、同じ配送先で同じ報告が出たかどうか
• 代走時の遅れの有無（台帳が効いているかの指標）

「反映しなかった理由」を必ず残してください。 同じ報告が繰り返し出て、繰り返し見送られているなら、判断の基準がドライバーに伝わっていないということです。

最後の項目が、この構成の効果を測る指標になります。 台帳の申し送りを事前に配信したうえで代走に行った場合と、そうでない場合で、現場での手間取りがどれくらい違うか。 ここが測れると、続ける理由がはっきりします。

対話の保存について、設計上の判断が要ります。 OpenAI の Responses API では、既定で応答が30日間保存され、store を false にすると保存されません。 ただし、会話オブジェクトに紐づいた応答は30日の期限の対象外で、会話とともに保持されます。 途中で中断した回答をあとから続けられるようにするなら会話オブジェクトを使いますが、その場合はデータが残り続けることを踏まえて、保持期間の方針を決めてください。

配送先の担当者名は個人情報です。 「現場監督の◯◯さん」と台帳に書くかどうかを、運行管理部で決めてください。役職だけで足りることが多くあります。