運送・物流会社の配車メモと問い合わせ対応を、Claude Codeで楽にする実務手順

朝6時、配車担当の机の上。前日の夜にドライバーから飛んできたLINEのメモ書きが10件、荷主からの「あの便、今どこ？」という電話の走り書きが3枚、そして自分しか読めない略字だらけの配車表。

僕が最初にこの仕事を手伝ったとき、いちばん驚いたのはここでした。配車そのものより、「メモを人が読める形に直す時間」と「同じ問い合わせに何度も同じ説明をする時間」が、一日の半分を食っている。

しかも、その略字メモは担当が休んだ瞬間に誰も解読できなくなる。「4t冷凍、王子3便、戻り空、相模原ドロップ」——これ、隣の席の人に通じますか。たぶん通じません。

今日はこの「配車メモの整理」と「問い合わせ対応」の二つを、Claude Code(生成AIをコマンドから使う道具)で軽くする話をします。配車そのものをAIに決めさせる話ではありません。あくまで、手前の雑務を削る話です。

この記事の要点

• 運送・物流会社の配車担当が抱える「メモの清書」と「同じ問い合わせの繰り返し」は、生成AIで半分以下に減らせる
• 配車判断そのものはAIに任せない。任せるのは「整える・下書きする・抜けを指摘する」まで
• コピペで使えるプロンプト雛形3つと、配車メモを表に変換する検証スクリプトを置いた
• 荷主名・電話番号・ナンバープレートなど個人情報の扱いには、社内ルールと匿名化が要る
• 1日90分の雑務が30分になれば、月およそ20時間。配車担当1人あたりの効果として現実的なラインを示す

読者像と、いまの業務フロー

この記事が想定する読者は、中小の運送・物流会社で配車を回している人です。トラック10〜50台規模、荷主は固定客が中心、ドライバーとは電話とLINEでやり取り。専用の配車システムは入っているけれど、結局メモと頭の中で組んでいる、という現場。

一日の流れはだいたいこうです。

1. 前夜〜早朝、ドライバーや荷主から翌日の依頼・変更がバラバラに届く
2. それを配車担当が読んで、車両と人に割り付ける
3. 割り付けた内容を配車表に清書し、各ドライバーへ連絡する
4. 日中、「あの荷物どうなった」「集荷時間ずらせる？」の問い合わせが断続的に入る
5. 終業後、実績を控えて翌日に備える

このうち、判断が要るのは2番だけです。1・3・4・5は「情報を整える」「同じことを伝える」作業で、ここがAIの得意分野です。

よくある手戻りと困りごと

現場で何度も見たつまずきを、先に並べておきます。あなたの会社でも一つは当てはまるはずです。

• 略字メモの解読待ち: 担当本人しか読めず、休むと業務が止まる
• 二重連絡: ドライバーに伝えた変更が荷主に伝わっておらず、現場で時間がずれる
• 問い合わせの言った言わない: 電話で済ませた約束が記録に残らず、後でもめる
• 清書のコピペ事故: 前日の配車表を使い回して、日付や便名を直し忘れる
• 新人が育たない: ベテランの頭の中が言語化されていないので、引き継げない

どれも「賢いAI」が要る問題ではありません。「決まった形に整える」「抜けを指摘する」係がいれば消える問題です。

Use case 1: 略字の配車メモを、誰でも読める表に直す

いちばん効くのはここでした。ドライバーから届いた略字メモを、そのまま貼り付けて表にしてもらう。

たとえばこんな入力を渡します。

4t冷凍 王子3便 戻り空 相模原ドロップ / 2t 平和島8時集荷 大田市場 戻り雑貨 / 10t 横浜本牧 コンテナ 14時バンプール

これを「車格・便・集荷地・荷種・戻り」の列を持つ表に直してもらう。人が略字を一個ずつ展開しなくていい。下にそのプロンプト雛形を置きます。

AIに任せる範囲と、人が必ず判断する範囲を、ここで一度はっきりさせます。

工程	AIに任せる	人が必ず判断する
メモの清書	略字の展開・表組み・抜け項目の指摘	略字の意味が会社独自のとき、正しい展開か最終確認
配車の割付	候補の整理・空き車両の一覧化	どの車にどの便を当てるか、最終決定
連絡文の作成	ドライバー向け・荷主向けの文面下書き	送信ボタンを押す前の事実確認
実績の記録	フォーマット統一・転記	数値や時間が正しいかの突合

割付の決定を人が握る。これだけは外さないでください。AIは「相模原ドロップの戻りが空」と教えてはくれますが、その空車に何を積むと利益が出るかは、荷主との関係や運賃を知っている人にしか決められません。

Use case 2: 問い合わせ対応の下書きを作る

二つ目は問い合わせ対応です。荷主からの「あの便、今どこ？」「集荷を1時間遅らせられる？」に、ゼロから文章を考えると地味に時間がかかる。

ここでAIに、社内のよくある問い合わせと回答をいくつか覚えさせておき、新しい問い合わせが来たら下書きを出させます。送るかどうかは人が決める。

チェックリストで運用するとぶれません。

• 問い合わせ内容を一行で要約させたか
• 回答の下書きに、事実(時間・場所・便名)が入っているか
• その事実は配車表やシステムと一致しているか(ここは人が確認)
• 荷主名・電話番号など、外に出してはいけない情報が文面に紛れていないか
• 送信前に担当の名前で一読したか

3番と4番だけは絶対に人がやる。AIは「たぶん14時着です」と自信満々に書きますが、その14時が本当かは、AIは知りません。

Use case 3: 配車表のダブルチェック

三つ目は、できあがった配車表を「抜けがないか」見てもらう使い方です。人は自分が作った表のミスに気づきにくい。日付の直し忘れ、同じドライバーが同時刻に二か所、戻り便の空白。こういう機械的なチェックは、AIに一度通すと拾えます。

ここでも判断はしません。「7番のドライバーが9時と9時半で二件、地理的に無理では」と指摘させて、直すのは人。これだけで前述の「コピペ事故」がかなり減ります。

コピペで使えるプロンプト雛形

そのまま使えるよう、三つ置いておきます。社名や略字の対応表は自社のものに差し替えてください。

雛形1: 略字メモを表に直す。

あなたは運送会社の配車補助です。次の配車メモを表にしてください。
列は「車格 / 便 / 集荷地 / 荷種 / 戻り / 不明点」とします。
略字は一般的な運送用語として展開し、判断できないものは「不明点」に書いてください。
勝手に配車を割り当てたり、書かれていない便を足したりしないでください。

メモ:
（ここに略字メモを貼り付け）

雛形2: 問い合わせ回答の下書き。

あなたは運送会社のカスタマー対応の下書き係です。
次の問い合わせに対し、丁寧だが簡潔な返信の下書きを作ってください。
時間や場所などの事実が必要な箇所は、断定せず「【要確認：到着時刻】」のように
プレースホルダで残してください。事実を勝手に作らないでください。

問い合わせ:
（ここに問い合わせ内容を貼り付け）

雛形3: 配車表のダブルチェック。

次の配車表を点検し、矛盾だけを箇条書きで指摘してください。
見るのは「同じドライバーの時間重複」「集荷地と時間の地理的な無理」
「戻り便の空白」「日付や便名の不整合」です。
配車そのものを組み直す必要はありません。指摘だけしてください。

配車表:
（ここに配車表を貼り付け）

検証スクリプト: 略字メモを表データに変換する

プロンプトの結果を毎回手で確認するのは大変なので、メモを構造化データに変換し、抜けを機械でチェックする小さなスクリプトを置きます。Node.jsがあれば動きます。AIの出力（タブ区切りを想定）を読み込み、不明点が残る行を警告するだけの、地味だが効く道具です。

import { readFileSync } from "node:fs";

// AIには「車格\t便\t集荷地\t荷種\t戻り\t不明点」のタブ区切りで返させる想定
const raw = readFileSync(process.argv[2] ?? "haisha.tsv", "utf8");
const cols = ["車格", "便", "集荷地", "荷種", "戻り", "不明点"];

const rows = raw
  .trim()
  .split("\n")
  .map((line) => line.split("\t"))
  .map((cells) => Object.fromEntries(cols.map((c, i) => [c, (cells[i] ?? "").trim()])));

let warnings = 0;
for (const [idx, r] of rows.entries()) {
  const n = idx + 1;
  if (!r["集荷地"]) { console.log(`${n}行目: 集荷地が空です`); warnings++; }
  if (!r["車格"]) { console.log(`${n}行目: 車格が空です`); warnings++; }
  if (r["不明点"]) { console.log(`${n}行目: 要確認 -> ${r["不明点"]}`); warnings++; }
}

console.log(`---\n${rows.length}件中 ${warnings}件の要確認`);
if (warnings > 0) process.exitCode = 1;

実行はこれだけです。

node check-haisha.mjs haisha.tsv

これで「不明点が残ったまま配車表に流れる」事故が止まります。要確認が1件でもあれば終了コードが1になるので、自動の流れに組み込めば、人の確認を強制できます。

導入前と導入後

数字で見ると効果がはっきりします。あくまで配車担当1人あたりの目安です。

作業	導入前	導入後
略字メモの清書	朝40分	約10分(貼り付け＋確認)
問い合わせ返信の作文	1件5分	1件1〜2分(下書き＋手直し)
配車表のミス探し	気づけば手戻り	その場で指摘が出る

仮に清書で30分、問い合わせ20件で各3分の短縮なら、ざっと1日90分。月20営業日で約30時間が浮く計算です。配車担当の時給を仮に2,000円とすれば月6万円相当。導入の手間を引いても、月数万円の余白は現実的なラインだと感じています。

浮いた時間で何をするかは会社次第ですが、僕が見た現場では「ベテランが新人の横について教える時間」に回せたのが大きかった。

セキュリティと個人情報の注意点

ここは運送・物流会社だからこそ外せません。配車メモには、荷主の社名、納品先の住所、ドライバーの氏名、車両ナンバー、ときに荷物の中身まで入ります。これらは立派な個人情報・取引情報です。

最低限、次を守ってください。

• 会社として「業務でどの生成AIサービスを、どのプランで使ってよいか」を先に決める。個人の無料アカウントに業務データを貼らない
• 荷主名・個人名・電話番号は、AIに渡す前に「A社」「担当B」のように匿名化する。前述のスクリプトの手前に、置換処理を一段かませると安全
• 入力したデータが学習に使われない設定・契約になっているかを確認する
• 出力をそのまま外部に送らない。事実確認とともに、個人情報が混ざっていないかを人が見る

匿名化の考え方やルールづくりは、社内の運用設計とセットで詰めるのが安全です。Claude Codeにルールを覚えさせる方法はclaude-md-best-practicesに、非エンジニアが安全に使い始める道筋はclaude-code-for-non-engineersにまとめています。導入の最初の一歩はclaude-code-getting-started-guideが読みやすいはずです。判断基準として、個人情報保護委員会の個人情報保護法の解説も一度目を通しておくと安心です。

よくある質問

Q. AIに配車を全部任せられますか。 いいえ。任せるのは整理・下書き・指摘までです。どの車にどの便を当てるかは、運賃・荷主との関係・ドライバーの体調まで含む判断で、AIは知らない事情が多すぎます。決定は人が握ってください。

Q. 社内の略字や独自ルールも理解しますか。 そのままでは無理です。略字の対応表をプロンプトに渡すか、社内ルールをファイルにまとめて毎回読ませる必要があります。覚えさせ方はclaude-code-prompt-engineering-advancedが参考になります。

Q. パソコンが苦手な配車担当でも使えますか。 プロンプトを貼って結果を確認するだけなら、難しくありません。最初はコピペ運用から始めて、慣れたらスクリプトで自動化、の順がおすすめです。日々の使い方のコツはclaude-code-productivity-tipsにあります。

Q. 導入にいくらかかりますか。 生成AIの利用料は月数千円規模から始められます。大きいのは費用より「社内ルールづくり」の手間で、ここを飛ばすと個人情報事故のリスクが残ります。

実際に試した結果

僕は手元で、ダミーの略字メモ15件と問い合わせ10件を作って、この流れを通してみました。

略字メモは、雛形1で表にしたあと検証スクリプトに通したところ、3件で「集荷地が空」「戻り未記入」の警告が出ました。これは元メモが本当に書き漏らしていた箇所で、人が目視したときは見落としていたものです。機械の門番が拾ったわけです。

問い合わせの下書きは、雛形2が「【要確認：到着時刻】」のプレースホルダをちゃんと残してくれました。試しに事実を断定させようと意地悪な聞き方をしても、時刻を勝手に作らなかったのは安心材料でした。

一方で気づいた限界もあります。会社独自の略字、たとえば自社倉庫を指す符丁は、対応表を渡さないと素直に「不明点」へ回されます。これはむしろ正しい挙動で、勝手に推測されるより安全でした。

結論として、配車の判断はこれまで通り人が握りつつ、その手前の「整える・下書きする・抜けを指摘する」をAIに渡すと、雑務がはっきり軽くなる、というのが今の実感です。会社単位で導入ルールから整えたい場合は、研修・相談で現場に合わせた進め方を一緒に詰められます。