3PLの物流センターに入って最初に目に入るのは、配車ボードと、担当者ごとに開かれた別々の画面です。物流 AI 自動化 / 3PL AI / 物流 DX を検討する担当者から相談を受けるとき、私が技術責任者としてまず確かめるのも、この一枚の風景でした。

輸送管理システム(TMS)に配車予定があり、倉庫管理システム(WMS)に在庫の数字があり、問い合わせは共有メールボックスとkintoneのアプリに溜まっている。複数の現場を回って共通して感じたのは、これらが「つながっていない」ことそのものより、その隙間を人が手で埋めている点でした。

配車担当者は在庫の欠品を電話で確認し、CS担当者は配送状況をTMSのログから読み取って顧客に返信する。一つの問い合わせに答えるために、三つの画面を行き来している。この往復こそが、3PL現場の見えないコストになっていました。

以下は特定の一社ではなく、複数の現場で繰り返し見たパターンを、従業員300名規模の3PL事業者という一つのモデルケースに再構成したシナリオです。登場する数値や期間は実績値ではなく、検討の目安として置いた想定であることを先に断っておきます。読み進める際は、自社の配車・在庫・CSに置き換えながら見ていただくのがよいと思います。

なぜ3PL物流の配車・在庫・問い合わせは、別々のシステムに閉じてしまうのか?

三つの業務がそれぞれ専用システムで最適化された結果、システムをまたぐ情報の受け渡しだけが自動化から取り残されているためです。個々のシステムに欠陥があるわけではありません。

TMSは配車を、WMSは在庫を、kintoneは問い合わせ管理を、それぞれ十分にこなします。困るのは、配車を決めるために在庫を見たいとき、その二つが別々のデータベースに立っている点でした。片方の画面で読んだ数字を、人が頭の中で突き合わせて判断している。

このモデルケースの現場では、朝の配車確定までに担当者が平均して四つの画面を開いていました。受注一覧、在庫、車両の稼働表、そして前日からの問い合わせ。どれも見なければ配車を確定できないのに、一つの画面には集約されていません。想定でいえば、一件の配送手配の裏で三回から四回の画面往復が発生し、それが一日に数十件積み重なる計算になります。

分離そのものは悪いことではないと考えています。基幹系と現場系を分けておくのは、障害の影響範囲を切るうえでも理にかなっている。問題は分離ではなく、システムの間に「制御ポイント」が置かれていないことでした。誰が、どのデータを、いつ参照して次の処理につないだのか。その受け渡しが記録も自動化もされないまま、人の記憶と電話に依存している。ここが3PL現場の構造的な弱点だと見ています。

もう一つ見落とされがちなのが、この隙間の作業が特定の人に偏る点です。全体を頭に入れているベテランが休むと、配車のスピードが目に見えて落ちる。システムが分かれていること自体よりも、その分断を埋める暗黙知が属人化していく方が、長い目で見た経営リスクでした。

配車業務にAIエージェントを重ねると、何が自動でつながるのか?

受注情報・在庫・車両の空き状況をAIエージェントが横断して読み取り、配車案の下ごしらえまでを自動で整えられます。人が担うのは最終判断だけになります。

配車の難しさは、変数の多さにあります。納品先の時間指定、車両の積載効率、ドライバーの稼働上限、当日の欠品。これらを同時に見て組み合わせるには経験が要り、その経験がベテラン一人に偏るのが3PLの慢性課題でした。

Beforeの状態を具体的に描くと、こうなります。配車担当者は受注一覧を印刷し、在庫画面で欠品の有無を確認し、稼働表を見ながら手作業で車両を割り当てる。この一連が、想定では朝の一時間から一時間半を占めていました。

Afterでは、AIエージェントが受注の入った時点で在庫と車両稼働を照合し、「この受注は在庫あり、A車の午前枠が最適」という配車案を先に提示します。担当者はその案を承認するか、現場の事情で組み替えるだけです。判断の主導権を人に残したまま、下ごしらえの往復が消えていく。ここが設計上の重要な線引きでした。

注意したいのは、AIエージェントが配車そのものを勝手に確定させるわけではないという点です。あくまで案を作り、根拠となった在庫と稼働のデータを添えて示す。人はその根拠を見て承認する。この「案と根拠の提示」までが、現時点で現場に馴染みやすい範囲だと考えています。

なぜ確定まで任せないのかというと、配車には数字に表れない事情が残るからでした。あの荷主は積み込みに時間がかかる、この時間帯の道路は詰まる、といった現場の勘は、まだ人が持っている。AIエージェントはその勘が働く前段の、機械的な照合と組み合わせを引き受ける役割にとどめておく方が、導入初期の納得感は高くなります。

具体的な処理の順番はこうです。受注が入ると、AIエージェントはまず納品先の時間指定と数量を読み、次にWMSの現在庫で引き当てが可能かを確かめ、最後にTMSの車両稼働表で空き枠を照合する。人が画面を行き来して数分かけていた突き合わせを、この三段でまとめて下ごしらえします。

担当者の手元には、根拠の数字が並んだ配車案が一枚届くだけになりました。どの受注をどの車に載せ、なぜその割り当てになったのか。その理由が案に添えられているので、承認する側は数字の出どころをたどりながら、現場の事情で組み替える判断に集中できます。

在庫の欠品と過剰は、AIエージェントでどこまで先回りできるのか?

出荷予定・入荷予定・現在庫をAIエージェントが突き合わせ、欠品や過剰の兆候を人が気づく前にアラートとして上げられます。単なる数字の集計ではなく、時系列の交差点を読む役割です。

3PLの在庫管理でつらいのは、荷主が複数いて、それぞれの入出荷リズムが違うことでした。ある荷主の商品が今週末に大量出荷され、別の荷主の入荷が遅れている。この二つが同じ棚のキャパシティを奪い合う瞬間を、人は事後にしか気づけないことが多い。

このモデルケースでは、AIエージェントに出荷予定と入荷予定を毎朝突き合わせる役割を持たせました。「金曜にBロケーションが在庫上限に達する見込み」という予測が水曜に出れば、荷主への確認や庫内の再配置を前倒しできます。欠品側も同じで、補充リードタイムを割り込む前に発注のアラートが上がる。

たとえば、こういう交差が起きます。荷主Aの季節商品が金曜に大量出荷され、同じ週に荷主Bの入荷ロットが前倒しで届く。片方は棚を空け、片方は棚を埋める動きが、同じロケーションで重なる。AIエージェントはこの出荷予定と入荷予定を日付軸に並べ、キャパシティが交差する地点を先に指し示します。

人が事後に気づいて慌てる場面を、予定表の段階で見えるようにするわけです。水曜のうちに交差が分かれば、荷主への確認も庫内の再配置も、手を打つ時間が残ります。

先回りといっても、AIエージェントが勝手に発注をかけるわけではありません。アラートには、なぜそう判断したのかという根拠の数字が付きます。担当者はそれを見て、発注するか、荷主に連絡するか、しばらく様子を見るかを決める。判断のための情報を早く手元に届けること、それがここでのAIの仕事でした。

この設計で効いてくるのは、属人化の緩和です。「この荷主のこの時期は危ない」という勘を、ベテランの頭の中からデータの突き合わせへ移す。勘が不要になるのではなく、勘を裏づける材料が全担当者に配られる状態になっていきます。

在庫の先回りは、配車と切り離せない点も強調しておきたいところでした。欠品が水曜に見えれば、金曜の配車計画をその時点で組み直せる。逆に、配車が先に決まってから欠品が発覚すると、車両の再手配という一番高くつくやり直しが発生します。在庫アラートと配車案が同じデータを見ているからこそ、この連鎖を上流で止められるのです。

問い合わせ対応(CS)をAIエージェントに任せると、現場はどう変わるのか?

配送状況の照会や再配達の受付といった定型の問い合わせを、AIエージェントがTMSとWMSを実際に参照して回答し、必要なら配車や在庫の引当までアクションを起こせます。回答で終わらず、処理まで進むのが従来のチャットボットとの違いです。

ここで、私がこの製品の設計思想として大切にしている一文を挙げます。「ChatGPTは答えます。WindyFloは働きます。」CS対応の文脈で言えば、問い合わせに文章で答えるところまでは多くのツールができる。難しいのは、その回答の裏で実際に配車枠を押さえたり、再配達をTMSに登録したりするアクションの方でした。

Beforeを描くと、CS担当者は「お荷物はどこですか」という照会に答えるために、まずTMSで配送ステータスを調べ、遅延していればWMSで在庫状況を確認し、その上で顧客に文章を書いていました。一件あたり数分、繁忙期はこれが一日中続く。

Afterでは、AIエージェントが照会を受けた時点でTMSの配送ステータスを参照し、現在地と予定を添えて回答します。再配達の希望が来れば、そのまま配車の空き枠を確認してTMSに登録の下書きまで作る。CS担当者は内容を確認して送るだけになりました。

ただし、すべてをAIに任せてよいわけではないと考えています。クレームや例外的な依頼は、人が受けるべき領域でしょう。定型と非定型を切り分け、定型はAIが処理まで進め、非定型は人にエスカレーションする。その振り分けの制御ポイントを最初に決めておくことが、CS自動化の設計で最も慎重にすべき部分でした。

再配達の受付を例にとると、処理はこう流れます。顧客から希望日時が届くと、AIエージェントはTMSで対象便の状況を確認し、WMSで在庫の引き当てが生きているかを見て、空いている配車枠に仮押さえの下書きを作る。CS担当者はその下書きを確認し、送信するか微調整するかを決めるだけです。

破損や誤配といった申告は、この自動フローには乗せません。人が事情を聞き取り、責任の所在を見極めながら対応すべき領域だからです。定型は処理まで、非定型は人へ。その分岐点を最初の設計で明文化しておくことが、CS自動化では最も慎重に決めるべき部分でした。

切り分けの基準は、現場ごとに違います。配送状況の照会や再配達の受付は定型に寄せやすく、破損や誤配のクレームは人が受ける、といった線引きを、導入前に問い合わせの実データから作っておく。この一手間を省くと、AIが例外対応まで抱え込んで、かえって顧客体験を損なうことになりかねません。

配車・在庫・CSを一本につなぐと、データはどこを通るのか?

各システムのデータはAIエージェントの連携基盤を経由し、どの処理がどのデータに触れたかを監査ログに残す構成が基本になります。データを一箇所に集めるのではなく、制御ポイントを通す設計です。

ここが、技術責任者として最も強調したい点でした。三つの業務をつなぐと聞くと、すべてのデータを一つの巨大なデータベースに集約する絵を思い浮かべる方がいます。その集約は、障害時の影響範囲とセキュリティの両面でリスクを大きくしてしまう。

このモデルケースで採った構成は、集約ではなく経由でした。TMS・WMS・kintoneはそのまま残り、AIエージェントが必要なときに必要なデータだけを参照する。参照した記録は監査ログに残り、後から「いつ、どの処理が、どの在庫を見て、何を提案したか」を追える。データの所在は元のシステムのまま、動きだけをつなぐ考え方です。

なぜ経由にこだわるのか。理由は三つありました。一つは障害の切り分けで、集約先が落ちれば全業務が止まるが、経由なら元システムは独立して動き続ける。二つ目は権限で、どの処理がどのデータに触れてよいかを連携基盤の制御ポイントで管理でき、荷主ごとの情報の壁を保てる。三つ目が追跡性で、監査ログがあれば「AIがなぜその配車案を出したか」を人が検証できます。

セキュリティを気にする荷主が多い業種なので、データを外部に出さない構成が取れるかどうかは選定の分かれ目になります。処理を自社の管理下、つまりオンプレミスや管理された環境の中で完結させられれば、配送先や在庫といった情報の外部流出を抑えられる。連携基盤がこの制御ポイントを持てるかどうかは、事前に必ず確認すべき項目でした。

kintoneと基幹系をまたぐ連携の考え方は、kintoneとSAP・外部システムをAIエージェントでつなぐ実装シナリオでも制御ポイントを軸に整理しています。物流と製造では扱うデータが違いますが、「入れ替えずに経由する」という設計の骨格は共通でした。

kintoneやERPを入れ替えずに、AIエージェントを重ねられるのか?

既存のkintoneやERPはそのまま残し、その外側でAIエージェントが連携する構成が取れます。入れ替えではなく、上に重ねる考え方です。

DX推進の現場でよく聞くのが、「kintoneを全社に入れたのに、外部のERPやECとの連携とAIの実行がkintoneの中で完結しない」という声でした。これはkintoneの欠陥ではありません。kintoneは社内業務の一元化に強い一方で、外部システムとの自律的な連携や実行は、もともとその守備範囲の外にあるからです。

境界を正しく引くと、判断がしやすくなります。kintoneでできること、できないことの線引きはkintone AIのできること・できないことで詳しく分けていますが、要点は「社内データの内側はkintone、外側の連携と実行はAIエージェント」という役割分担でした。

このモデルケースでは、問い合わせ管理をkintoneに残したまま、AIエージェントがkintone・TMS・WMSを横断して参照する形にしました。kintoneのアプリも、TMSの配車データも、どちらも作り直していません。既存の投資を捨てずに、その上へ連携の層を一枚重ねる。この「重ねる」進め方が、DX推進の責任者にとって稟議を通しやすい形でもありました。

入れ替えを前提にすると、移行リスクと現場の混乱が一気に膨らみます。稼働中のシステムを止めずに、まず一つの業務でAIエージェントを重ねて検証し、効果を見てから範囲を広げる。この順序が、3PLのように止められない現場では現実的でしょう。

稟議の観点でも、重ねる進め方は説明がしやすいものでした。既存システムの刷新は投資額が大きく、経営層の判断も重くなる。一方で、稼働中の資産を残したまま一業務から検証する形なら、初期投資を抑えつつ効果を数字で示してから次の投資判断に進めます。DX推進の責任者が上に説明する材料として、この段階の踏み方は理にかなっていました。

3PL物流でAIエージェントを検討するとき、何を基準に選べばよいのか?

「答えるだけか、実行までするか」「既存システムを入れ替えずに重ねられるか」「データを外部に出さない構成が取れるか」の三点が、3PL現場での実務的な選定基準になります。機能の多さより、この三つの適合を先に見るべきでした。

一つ目は、実行までの到達点です。配送状況を答えるところで止まるのか、再配達の登録や在庫の引当というアクションまで進むのか。3PLの負荷は照会そのものより、照会のあとの処理にあります。ここが自動化されなければ、体感の楽さは限定的でしょう。

二つ目は、重ねられるかどうか。稼働中のTMSやWMSを入れ替えずに、外側から連携できる構成かどうかです。入れ替え前提の提案は、移行の期間とコストを見積もり直す必要が出てきます。

三つ目が、データの管理境界でした。荷主の配送先や在庫は、外に出したくない情報を含みます。処理を管理された環境の中で完結させ、参照の記録を監査ログに残せるか。この確認を後回しにすると、導入の直前で止まることがありました。

進め方としては、まず自社の配車・在庫・CSの現状を棚卸しし、どの業務のどの往復が一番重いかを特定することをおすすめします。全部を一度につなぐ必要はありません。

製造業のERPを起点にした段取りは製造業のERPにAIエージェントをつなぐ6か月自動化シナリオにまとめていますが、物流でも「一業務から重ねて広げる」という順序は変わらないと見ています。

自社の3PL業務にどこから当てはめられるかは、現状の棚卸し結果に合わせてWindyFloの業種別相談で個別に検討できます。往復の重い一業務を見極めるところから始めるのが、無理のない入り方だと考えています。

よくある質問

出典・補足

• 製品情報・機能・料金・業種別相談の一次情報: WindyFlo公式サイト https://windyflo.com
• 本記事の配車・在庫・CSに関するシナリオ、数値、期間は特定顧客の実績値ではなく、複数の3PL現場で見られる共通パターンを従業員300名規模のモデルケースとして再構成した想定です。自社の状況への当てはめは個別の確認が必要です。
• SOC2・GDPR等の認証取得状況、対応コネクタ数、対応LLMの種別など、本記事で扱っていない個別スペックは、WindyFlo公式サイトおよび個別相談でご確認ください。
• 関連記事: kintoneとSAP・外部システムをAIエージェントでつなぐ実装シナリオ / kintone AIのできること・できないこと / 製造業のERPにAIエージェントをつなぐ6か月自動化シナリオ