博多港を見おろすオフィスの一室で、物流システム担当の松田氏はホワイトボードに二本の矢印を引いた。左にWMS、右にTMS。ふたつの箱を結ぶその線が、API接続であるべきか、統合基盤であるべきか——その問いは、数百万円規模の意思決定と、数年分の運用コストを静かに左右する。WMSとTMSの連携は、物流現場における地味でありながら本質的なアーキテクチャの選択であり、誤った方向に踏み出した場合、修正には相応の時間と費用がかかる。この記事では、福岡の中規模物流会社における診断プロセスを軸に、その判断基準を丁寧に解きほぐしていく。

WMSとTMSが「別々に存在する」ことの意味

倉庫管理システム（WMS）と配送管理システム（TMS）は、それぞれ異なる進化の文脈で育ってきた。WMSは入出庫、棚番管理、在庫精度の最大化を目的とし、TMSは配車計画、ルート最適化、ドライバーとの通信を担う。この二者が同一ベンダーのスイート製品として提供されていない限り、データのやり取りには何らかの「橋」が必要になる。福岡の中堅物流会社、仮に「博多ロジスティクス」と呼ぶが、そこでは出荷指示データをCSVで一日二回、手動でエクスポートしてTMSに取り込む運用が三年間続いていた。午前の便と午後の便の間に生じるデータの空白が、配車ミスと積み残しを毎週のように引き起こしていた。問題は技術の欠如ではなく、接続方式を選ばなかったことの結果だった。

API接続とは何か、その実態と限界

API接続とは、WMSとTMSがそれぞれの独立性を保ちながら、HTTPベースのインターフェースを通じてリアルタイムにデータを交換する方式だ。出荷指示が確定した瞬間にTMS側へPOSTリクエストが走り、配車計画が更新される。博多ロジスティクスの診断では、主要なWMSベンダーがREST APIのエンドポイントをすでに公開しており、TMS側も同様だった。接続自体は技術的に三週間ほどで実装できる見通しが立った。ただし、APIには版管理の問題がある。WMSのバージョンアップでエンドポイントの仕様が変わるたびに、接続コードの修正が必要になる。担当エンジニアが社内にいなければ、その都度ベンダーへの依頼と費用が発生する。小規模な更新でも年に一回から二回の仕様変更は珍しくなく、その維持コストを五年で試算すると、初期構築費用と同程度に膨らむことがある。

統合基盤という選択肢、その重さと安定性

統合とは、WMSとTMSの間にESB（Enterprise Service Bus）やiPaaS（Integration Platform as a Service）を置き、データ変換と連携ロジックを一元管理する方式を指す。MuleSoft、Dell Boomi、あるいは国内ではDataSpiderのような製品がその役を担う。この方式の利点は、WMSとTMS双方のバージョン変更に対して、統合レイヤー側でマッピングを修正するだけで対応できる点にある。各システムが互いの仕様に依存しないため、将来的にどちらかのシステムを入れ替えても、統合レイヤーを再設定すれば済む。博多ロジスティクスの診断では、TMSを二年後に別製品へ移行する計画が社内に存在していた。この情報が出た瞬間、統合基盤の優位性が大きく傾いた。初期導入費用はAPI接続の二倍から三倍になるが、移行コストを含めた五年総コストで比較すると、差は縮まるか逆転することもある。

診断で使った四つの判断軸

博多ロジスティクスへの診断で用いた判断軸は四つだった。第一に「更新頻度」——どれだけの頻度でシステムのバージョンアップが行われるか。年二回以上なら統合基盤の安定性が活きる。第二に「データ変換の複雑さ」——WMS側の出荷単位（ケース数）をTMS側の重量・体積に変換するような複雑なロジックが必要か。変換ルールが多岐にわたる場合、統合レイヤーで管理する方が保守性が高い。第三に「システム入れ替えの計画有無」——五年以内にどちらかのシステムを刷新する予定があるなら、疎結合の統合基盤が有利になる。第四に「社内の技術リソース」——API仕様の変更に自力で追随できるエンジニアがいるかどうか。この四軸を表形式で整理し、各項目にスコアをつけることで、定性的な議論が定量的な比較に変わった。

福岡の診断が示した結論と、その後

四軸の評価を経て、博多ロジスティクスが選んだのはiPaaSを用いた統合基盤だった。決め手はTMS入れ替え計画の存在と、社内に専任エンジニアがいないという二点だった。導入から六ヶ月後、出荷指示のリアルタイム連携が稼働し、CSV手動取り込みの作業は消えた。配車ミスは月平均で八件から一件以下に減少した。秋口、福岡の物流繁忙期が始まる前にシステムが安定稼働に入ったことは、現場にとって小さくない安堵だったと聞く。一方で、統合基盤の運用には学習コストがかかった。最初の三ヶ月は担当者がマッピング設定に慣れる期間が必要で、ベンダーのサポート費用も予算に加える必要があった。API接続で十分なケースも確かに存在する。システムが安定しており、自社エンジニアがいて、入れ替え計画もない——そういう環境なら、シンプルなAPI接続の方が無駄がない。

選択を誤らないための問いかけ方

最終的に、この種の意思決定を支えるのは技術知識よりも問いの立て方だと思う。「どちらの接続方式が優れているか」という問いでは答えは出ない。「五年後の自社の状態を想定したとき、どちらの方式が保守コストと柔軟性のバランスをとれているか」という問いに変えることで、議論の解像度が上がる。また、現行システムのベンダーに「APIの版管理ポリシーを文書で提示してほしい」と依頼することも有効だ。バージョン廃止の予告期間が三ヶ月なのか十二ヶ月なのかによって、API接続のリスク評価は大きく変わる。博多ロジスティクスの松田氏は診断の最後にこう言った——「選んだ後に正しくするより、選ぶ前に正しく問う方が、はるかに安上がりです」。その言葉は、どの物流現場にも当てはまる。

WMSとTMSの連携は、倉庫の棚と配送車の間に引かれた見えない神経のようなものだ。その神経の設計を、コストだけで決めることも、流行だけで決めることも、本質を見誤る。九月の博多港に霞がかかるころ、松田氏のホワイトボードには新しいシステム図が描かれていた。ふたつの箱を結ぶ線は今度は太く、安定していた。