配車の電話が長くなるのは、車が見つからないからだけではありません。依頼の条件が半分しか揃わないまま、協力会社に一本目をかけてしまうことに原因があります。この記事では、電話・FAX・メールで届く求貨の依頼と求車（空車・帰り便）の情報を、条件の抽出・不足項目の洗い出し・社内記録からの候補提示・依頼文の下書きまで整えるところに範囲を絞ります。協力会社と車両・ドライバーの選定、運賃と条件の合意、社外への送信、配車の確定は人が決める範囲として残します。
配車の机の上には、複数の経路から同時に情報が届きます。荷主や元請からの「明日、大阪まで10t一台お願いできますか」という電話。協力会社から流れてくる「東北方面、明後日の帰り便あります」というFAX。メールに添付された配車表のExcel。チャットに貼られた住所と時間だけの短いメッセージ。これらが同じ案件を指していることもあれば、まったく別件のこともあります。
ここで負担になっているのは、条件に合う車を探すことだけではありません。依頼として相手に伝えられる形に条件がそろっていないことです。
この状態で協力会社に電話をかけると、相手から「それ何トン？」「手積み？」「着何時？」と返され、荷主側に確認して、もう一度かけ直すことになります。往復のたびに時間が過ぎ、その間に押さえられたはずの空車が埋まります。ベテランの配車担当は、聞くべき項目を頭の中に持っていて一度で埋めますが、その順序はどこにも書かれていません。担当が変わると、往復の回数が戻ります。
この記事が扱うのは、配車を決める手前の情報整理です。方面別・積載率といった配車計画そのものの最適化は輸配送最適化と配車計画で別に扱っており、この記事の範囲には含みません。物流・倉庫でAIをどこに置くかの全体像は物流・倉庫でAIエージェントができることを、荷主から届く出荷指示そのものの取り込みは出荷指示メール・Excelの取込を参照してください。
配車担当に届く連絡は、扱い方も鮮度も違います。すべてを同じメモ帳と同じホワイトボードに書くと、鮮度の短いものが埋もれます。まずは四つに分けて置くところから始まります。
| 類型 | 現場での届き方 | 主な入り口 | そろっていないことが多い条件 |
|---|---|---|---|
| 求貨（運んでほしい荷物の依頼） | 「明日、空いてる車ありますか」 | 電話・FAX依頼書・メール本文・添付Excel | 着時間の指定、荷姿とパレット枚数、附帯作業の有無 |
| 求車（空車・帰り便の情報） | 「◯◯方面、帰り便が一台空きます」 | 電話・FAX・チャット・メール一斉配信 | 積める時間帯の幅、車格と装備、その車の次の予定 |
| 変更・キャンセル | 「さっきの件、時間がずれます」 | 電話が中心、まれにメールの返信 | どの案件のどの条件が、いつから変わったのか |
| 条件の確認・折衝 | 「あれ、高速代は込みでしたっけ」 | 電話・メールの返信 | 前回どう決めたかの根拠と、決めた時点の記録 |
この四つのうち、求車の情報は鮮度が最も短いという特徴があります。届いた時点で使えた空車が、三十分後には埋まっていることが普通にあります。一方で変更とキャンセルは、見落とすと現場が空振りします。求貨の依頼と同じ列に混ぜて順番に処理すると、鮮度の短いものと影響の大きいものが件数の多いものに埋もれます。
分類そのものは、文面から機械的に判定できる余地があります。「空車」「帰り便」「空いてます」といった語が入る連絡と、発着地と積み日が入る依頼は、書き方の傾向が違うためです。ここを最初に置く価値は高いと考えられます。メールの経路については、対応漏れと滞留の管理の観点から共有メールの対応漏れ防止でも扱っています。
聞き直しが発生する箇所は、案件ごとにばらばらに見えて、実際には数種類に収まります。傭車の依頼で抜けやすいのは、次のような項目です。
逆に、求車（空車・帰り便）の情報側で抜けやすいのは、その車がいつまで動けるかと次の予定です。「東北方面、帰り便あります」という情報だけでは、何時に積めて何時までに戻る必要があるのかが分かりません。空車の情報は数が多く鮮度が短いため、この二項目が欠けているだけで使えない情報になります。
これらの項目は、聞き手が経験から補って会話を進めてしまうことがあります。補った内容がメモに残らないと、次に見た人には「決まっている条件」と「聞き手の推測」の区別がつきません。抜けている項目を抜けているものとして残すことが、この工程の要点です。
担当者が動き出すときに必要なのは、完成した配車案ではなく次の一本の電話で何を確認すればよいかが分かる状態です。実務で機能する形は、次の四点をひとまとめにして手元に置くことだと考えられます。
電話のメモ、FAXの画像、メールの本文と添付。どの連絡から来た情報なのかを、抽出した内容と紐づけて残します。抽出結果だけを残すと、後から「そう聞いたのか、そう解釈したのか」が確かめられません。変更やキャンセルが後から効いてくる業務では、原文が残っていること自体が価値を持ちます。
発着地、積み日時と着日時、車種と装備、荷姿と数量、重量、附帯作業、運賃に関する記載。読み取れたものを項目ごとに並べます。重要なのは確定として出さないことです。「10tウイング」と書かれていても、それが依頼側の希望なのか決定事項なのかは文面からは分かりません。候補として出し、確度が低いものはそう明示する方が安全です。
協力会社台帳、過去の傭車の履歴、登録されている空車の情報。担当者が参照できる範囲の記録から、その方面・その車格に該当しそうな相手を並べます。ここも並べるところまでで、選ぶことはしません。過去に同じ方面を走った実績があることと、今回受けてもらえることは別の話です。
依頼として成立するために足りていない項目を、そのまま列挙します。着時間、荷姿、附帯作業、待機の扱い。これが手元にあれば、一本目の電話で聞くべきことがまとまり、往復が減る可能性があります。経験の浅い担当者にとっては、ベテランの頭の中にあった順序が外に出た状態になります。
傭車の手配は、社外への一本の連絡が仕事の約束につながる業務です。取り返しがつく範囲とつかない範囲を、仕組みを入れる前に分けておく必要があります。
| 工程 | AIに任せられると考えられる範囲 | 人が確定すべき範囲 |
|---|---|---|
| 受け取り・分類 | 電話メモ・FAX・メール本文と添付をテキストとして取り込み、求貨・求車・変更・条件確認に分ける | 分類が妥当かの確認、どの連絡が同じ案件かの最終判断 |
| 条件の抽出 | 発着地・日時・車種と装備・荷姿・数量・重量・附帯作業の候補提示と、確度の低さの明示 | 抽出された条件が事実かどうかの確認 |
| 不足の洗い出し | 依頼として成立するために欠けている項目の一覧化 | 相手に何をどの順で確認するかの判断 |
| 候補先の提示 | 権限の範囲内の協力会社台帳・過去の傭車履歴・登録された空車から該当しそうな候補を並べる | 協力会社・車両・ドライバーの選定 |
| 過去の条件の参照 | 同種の案件で記録に残っている条件や取り決めの提示 | 今回の運賃・支払条件・附帯作業や待機の扱いの合意 |
| 運行の可否 | 連絡文に書かれている制約（時間指定・車両制限・入構条件）の抜き出し | 拘束時間・車両制限・現場条件を踏まえた運行可否の確認 |
| 記録 | 原文と抽出結果の紐づけ保存、社内メモの下書き | 記録として残す内容の確定、管理簿の整備が必要かどうかの判断 |
| 社外への連絡 | 問い合わせ文・依頼文の下書き作成 | 文面の承認と送信、依頼の確定と引き受けの意思表示 |
特に注意したいのは社外への送信です。傭車の依頼は、送った時点で条件の提示になり、相手が受けた時点で車とドライバーが動き始めます。読み取りや候補提示と違い、間違えたときに「見て捨てる」ことができません。下書きの作成までを機械に任せ、送ることを人の操作として残す設計を推奨します。
任せる範囲と承認を挟む位置の決め方は、AIエージェントに任せる範囲と人の承認ポイントの設計で扱っています。
配車の情報には、自社の記録と、他社から預かった情報が混ざります。荷主の出荷先や数量、協力会社の運賃、ドライバーの氏名。どれも社内で自由に回してよい情報とは限りません。仕組みに載せる前に、次の点を決めておく必要があります。
権限設計の一般的な考え方はAIエージェントの権限設計で整理しています。ここで述べているのは、その考え方を「他社の車と他社の荷物を扱う」という条件に当てはめたものです。
読み取りの精度以外のところで止まることが多いのが、この領域の特徴です。
次のいずれかに当てはまる場合、AIより先に検討すべき手段があると考えられます。
| 状況 | 先に検討すべき手段 | 理由 |
|---|---|---|
| 依頼が決まった書式のFAX依頼書で届いている | 定型フォーマット向けのOCR | レイアウトが固定なら、より安価で挙動が読める手段で足りる |
| 依頼元が数社で、窓口も書式も固定されている | 依頼フォームやExcelテンプレートの統一 | 構造化されて届けば、読み取りの工程そのものが要らない |
| 求車求貨のサイト上で条件が完結している | そのサイトの機能をそのまま使う | すでに構造化された情報を読み直す必要がない |
| 空車と協力会社の情報がすでにシステムに登録されている | その画面の検索条件と絞り込みの見直し | 記録が構造化されているなら、検索の設計で足りることがある |
| 毎朝決まった画面から決まった一覧を取得している | RPA | 手順が固定された繰り返しは、規則で書ける方が保守しやすい |
| 案件の管理をExcelで回していて、現状で破綻していない | 現状維持、または入力項目の見直し | 動いている運用を載せ替えるだけの理由がない |
実務では、これらを組み合わせるのが現実的な場合が多くあります。書式の決まったFAX依頼書は定型OCRで読み、サイト上の案件はそのまま使い、決まった一覧の取得はRPAに任せ、電話メモと自由文のメールという構造化されていない部分だけをAIが担うという分担です。すべてをAIに寄せると、簡単に解けたはずの部分まで説明の難しい仕組みに載せることになります。
手段の使い分けの整理はAIエージェント・チャットボット・RPAの違いに、書式がばらつくFAXの読み取りについてはFAX受注のOCR自動化にまとめています。
この領域は、全経路・全類型を一度に対象にすると例外の量で止まります。次の順序が現実的だと考えます。
この順序の背景にあるのは、手配の速さより一本目の電話の中身が誰にでも同じ形で用意される状態を先に作るという考え方です。起点が揃えば、経験の差が往復の回数に出にくくなります。ドライバー確保が構造的に厳しくなる前提での荷主側の備えについては2030年トラックドライバー不足の構造を、荷受け後の在庫・出荷に関する問い合わせ対応は3PL倉庫の在庫照会・誤出荷問い合わせを参照してください。
減る部分はあります。サイト上に条件が構造化された形で載る案件は、読み取りの工程そのものが要りません。それでも電話とFAXが残るのは、付き合いのある協力会社との間では条件の詰めが会話で進むこと、急な変更やキャンセルは電話の方が速いこと、そしてサイトに載せない案件が実際にあることが理由です。まずは直近の依頼と空車情報がどの経路から何件届いているかを数え、サイトで解ける分と、電話やFAXのまま残る分を分けるところから見た方が判断しやすくなります。
通話のメモや文字起こしをテキストとして渡せるなら、そこから条件の候補を抜き出すことはできます。ただし通話は、言い落としと言い間違いが混ざりやすく、聞き手が前提として補った情報がメモに残らないという性質があります。抽出した条件は確定した事実ではなく候補として扱い、もとになったメモや録音を併せて残す前提にしてください。通話の録音そのものは相手方への周知や社内の取り決めが関わるため、仕組みを入れる前に運用として決めておく必要があります。
そのまま送るべきではないと考えます。傭車の依頼は、送った時点で条件の提示にあたり、相手が受けた時点で仕事の約束として動き始めます。運賃、待機や附帯作業の扱い、着時間といった項目は、後から言った言わないになりやすい部分です。AIが作れるのは、集めた条件と社内の記録に基づく下書きまでです。確定した条件と、まだ確認が取れていない条件を区別した形で担当者が読み、必要な修正を加えたうえで、人が送る前提にしてください。
そういうものとして設計しない方がよいと考えます。社内の記録から、過去に同じ方面へ走った協力会社や、登録されている空車のうち条件に近いものを候補として並べることはできます。しかし、その車が今動けるか、そのドライバーで現場に入れるか、その運賃で受けてもらえるかは記録には書かれていません。選定は、相手の事情と自社との関係を知っている担当者の判断です。候補の提示までを機械に任せ、選ぶことを人に残す形にすると、候補が外れていたときにも気づけます。
この範囲には含めない前提で考えてください。運行が成立するかどうかには、ドライバーの拘束時間や休息、車両の制限、荷主側の入構条件といった要素が関わり、いずれも実態と最新の取り決めを踏まえた人の判断が必要です。AIが担うのは、依頼と空車の情報から条件の候補と不足している項目を並べるところまでで、その条件で走ってよいかどうかの確認は人が行います。管理簿のような記録を整える必要があるかどうかの判断も、同じく人の領域です。
仕組みの話をする前に、実際に届いている連絡を電話・FAX・メール・チャットに分け、どの条件が抜けて聞き直しが起きているかを一緒に見るところから始められます。定型OCRや依頼フォームの統一で足りると判断した場合は、そのように申し上げます。
傭車手配の情報整理について相談する