物流システム開発で先に決める5つ【2026年版】庫内5業務・引当ルール・検品・外部接続・輸送制約

「物流システムを作ることになったが、何から決めればいいのかわからない」——倉庫を持つ会社の担当者から、こうした相談をよく受けます。検索すると出てくるのは開発会社の一覧と費用相場ばかりで、自社の倉庫で何を決めればベンダーと話が進むのかは、どこにも書いていない。見積もりを3社から取ったのに、範囲が違いすぎて比べられなかった。そんな経験をお持ちの方も多いはずです。

結論から言うと、物流システムの開発が難しいのは費用が高いからではなく、決めなければならないことが庫内の外まで広がっているからです。入荷・格納・ピッキング・梱包・出荷という庫内5業務に加えて、ロケーションの持ち方、どの在庫を引き当てるかのルール、誤出荷を止める検品の方式、送り状と運送会社、取引先とのEDI、3PLとの責任分界、そして輸送そのものの時間制約までが1つの設計に絡みます。この絡まりを解かずに金額だけを比べるのが、失敗のもとです。

決めごとを先に並べてしまえば、既製品で足りるのか、どこを作る必要があるのかを自分で判断できます。逆に、決めごとが曖昧なまま開発を始めると、テスト段階で現場から「この順番では作業できない」と言われ、設計に戻ることになります。物流は、在庫の「数」ではなく在庫の「状態」を扱う領域です。数が合っていても、どの棚の、どのロットを、いつ出してよいかが決まっていなければ、誤出荷は止まりません。

本記事では、物流システムが指す範囲(WMS・TMS・OMSの線引き)、庫内5業務で決まる要件とロケーション管理、誤出荷を仕組みで止める引当ルールと検品設計、送り状・運送会社API・EDI・3PLといった倉庫の外との接続、2024年問題という輸送の制約、そして外部チームで作るときの進め方の順に解説します。制度に関する記述は国土交通省・厚生労働省・消費者庁などの公開資料を直接確認し、確認日を本文に明記しました。費用相場は別記事に譲り、ここでは要件の中身だけを書きます。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社は庫内・配送を含む物流システムの開発に対応しています。そのうえで実際に届く相談は、「WMSを作りたい」ではなく「既存のWMSや3PL、自社のECや基幹システムをどうつなぐか」という形が多くを占めます。この記事を読み終えるころには、自社が決めるべきことの一覧と、それを誰に頼むべきかの見当がついているはずです。

物流システム開発が指す範囲——WMS・TMS・OMSの線引きと、定義が統一されていないという前提

「物流システムを作りたい」という相談で最初に起きるのが、言葉の行き違いです。発注側は倉庫の中の作業を想像し、提案側は配車や運賃計算を想像している。あるいは、受注データの取り込みまで含まれると思っていたのに、見積もりには入っていなかった。物流という言葉が指す範囲は広く、しかもシステムの呼び名が5つも6つも並びます。まずはこの地図を共有するところから始めてください。

WMS・TMS・OMS・WES・WCSの守備範囲

現場で使われる主な略称は次の5つです。商品が動く順に並べると、守備範囲の違いがわかりやすくなります。

多くの会社が最初に必要とするのはOMSとWMSで、WESとWCSは自動倉庫やソーターを導入している現場に限られます。TMSは自社便を持つ会社や、運賃の管理が重い会社で先に必要になります。自社がどこから手を付けるかは、いま一番人手がかかっている場所で決めてください。

公的に統一された定義はない——だから見積もりの範囲がずれる

ここが重要な前提です。WMSやTMSといった略称には、法令やJISのように一意に定まった公的定義がありません。 業界で広く使われている呼び名であり、どこまでを含めるかは提供する会社の解釈に委ねられています。

実際、本記事の作成にあたって上位に出てくる解説記事5本の見出し92本を集計したところ、WMSの説明にWES・WCS・OMSを含める記事と、含めない記事が混在していました。同じ「WMS」という言葉で話していても、片方は棚卸まで、もう片方は配車まで想像している。これでは見積もりが比較できません。

対策は単純です。略称で会話しないこと。「入荷検品はハンディで行うか」「ロケーションは持つか」「配車はこのシステムで行うか」と、機能で確認してください。RFPや見積もり依頼書には、略称ではなく業務名を並べます。

なお、この範囲の切り方はそのまま費用に効きますが、金額そのものは案件ごとに大きく振れるため本記事では扱いません。規模別・機能別の相場は「業務システム開発 外注 費用」の記事に整理してあります。開発方式(パッケージ、スクラッチ、ノーコード)の分類も「スクラッチ開発とは」の記事に譲ります。

範囲を合わせる手がかり: 国土交通省の物流情報標準ガイドライン

社内やベンダーとの間で範囲の言葉を揃えたいとき、参照できる公的な資料があります。国土交通省と経済産業省が関わる「物流情報標準ガイドライン」です。物流に関わるデータ項目の標準形式を定めることを目的に2021年10月に初版が公開され、2025年2月7日にver3.00へ改訂されたと国土交通省が発表しています(2026年9月19日確認)。運営管理は一般社団法人フィジカルインターネットセンターが行うと、同省が発表しています。

このガイドラインは物流業務プロセスや物流メッセージのデータ項目を扱うもので、WMSの機能一覧ではありません。それでも、「出荷情報」「運送計画情報」といった項目の並びを見れば、自社と取引先の間でやり取りすべき情報の骨格がわかります。取引先とのデータ連携を設計に含めるなら、早い段階で目を通しておく価値があります。

範囲の地図が描けたら、次は倉庫の中に入ります。物流システムの要件の大半は、ここで決まります。

庫内5業務で決まる要件——入荷・格納・ピッキング・梱包・出荷と、ロケーション管理

倉庫の中は、入荷・格納・ピッキング・梱包・出荷の5つに分けて考えると設計が進みます。この5つはどの業種の倉庫にもあり、業種ごとの違いは「各業務で何を確認するか」に現れます。逆に言えば、この5業務それぞれについて決めごとを埋めれば、要件定義の骨格はできあがります。ベンダーに相談する前に、次の表を自社の言葉で埋めてみてください。

5業務ごとに「決めること」の一覧

この表で埋まらない欄があったら、そこが要件の穴です。私の経験では、「欠品時にどうするか」と「分割出荷の扱い」が空欄のまま開発に入り、テスト段階で戻るケースが多く見られます。現場は例外処理を毎日こなしているので、当たり前すぎて説明されないのです。

ロケーション管理をどう持つか——固定ロケーションとフリーロケーションの分かれ目

5業務の中で、1つ決めると全体に波及するのがロケーション管理です。方式は大きく2つに分かれます。

現実には中間の形も多く、定番品は固定、季節品はフリーという「併用」が広く使われています。どれを選ぶにせよ、フリーロケーションを選んだ時点でハンディターミナルの導入は事実上必須になります。紙とペンで棚番号を書き写す運用は、繁忙期に必ず崩れます。

あわせて決めるのが、ロケーションの番地の付け方です。エリア・列・段・間口をどの桁数で表すか、後から棚を増設したときに番号が連続するか。ここは地味ですが、バーコードのラベル設計とピッキングの並び順に直結します。ロケーション番号の体系を後から変えるのは、稼働後にやると最も痛い変更です。要注意です。

ピッキング方式の選択が、画面と端末の設計を決める

ピッキングの方式も、画面設計を左右する決めごとです。主に次の3つがあります。

• シングルピッキング(オーダー別): 1つの注文ごとに商品を集める。少量多品種の通販に向く。歩行距離は長くなる
• トータルピッキング(種まき方式): 複数注文の同じ商品をまとめて集め、後から注文ごとに仕分ける。同じ商品が多数の注文に出る場合に効率が高い。仕分けの工程と場所が必要になる
• マルチピッキング(摘み取り+複数台車): 1度の歩行で複数注文を同時に集める。中間的な方式で、台車の口数だけ注文を並行処理する

方式が変われば、ハンディの画面に出す情報が変わります。シングルなら「次の棚と数量」を出せば足りますが、マルチなら「どの口に入れるか」まで表示しなければ作業できません。方式を決めずに画面を作ると、現場で使えないものができあがります。

繁忙期のピーク時に何人が同時にハンディを使うか、応答が何秒まで許容されるかも、ここで数値にしておきます。こうした性能や可用性の目標は非機能要件と呼ばれ、決め方は「非機能要件とは」の記事にまとめてあります。

梱包と出荷の要件は「同梱物」と「送り状」で膨らむ

梱包と出荷は、一見すると単純な作業です。ところが要件を詰めると必ず膨らみます。原因は同梱物の出し分けと、送り状の発行です。

同梱物は「初回購入者にはチラシA、定期便にはチラシB、ギフト指定なら明細金額を非表示」といった条件が絡みます。この条件がどこから来るのか——OMSが持つのか、WMSが持つのか——を決めないと、出荷の直前で情報が足りなくなります。条件は必ず受注側の情報に依存するため、原則としてOMS側で決めて出荷指示に載せる形が破綻しにくい設計です。

送り状は外部システムとの接続になるため、次章以降で改めて扱います。ここで押さえておきたいのは、庫内5業務の要件は「例外処理を書き出せたかどうか」で品質が決まるという点です。正常系は誰でも書けます。欠品、数量違い、破損、分割、キャンセル、出荷後の訂正。この6つを各業務について書き出せていれば、要件定義はほぼ終わっています。

誤出荷を仕組みで止める——先入先出・ロット・期限の引当ルールと、ハンディでの検品設計

誤出荷が起きた翌日、現場では朝礼で注意喚起が行われます。数週間は減り、そしてまた戻ります。人は同じ品番の違うロットを目で見分けられませんし、繁忙期に1日数百行のピッキングをこなす中で集中力だけに頼るのは無理があります。誤出荷を減らす方法は1つだけで、機械が読める識別子を付け、作業の順番をシステムが強制することです。 ここでは引当ルールと検品設計の2つに分けて整理します。

なお、在庫管理をExcelやノーコードで自作できるかという論点は、既存記事「在庫管理システム 自作」に手段別の限界としてまとめてあります。本記事では手段の比較ではなく、どの手段を選んでも避けて通れない「引当ルールの設計」だけを扱います。

「どの在庫を出すか」は4つの条件で決まる——倉庫・ロケーション・ロット・ステータス

在庫システムが「品番Aが120個ある」と表示していても、その120個のうち出荷してよいのはごく一部かもしれません。出荷可能な在庫を選ぶことを引当と呼び、判定は次の4条件の組み合わせで行います。

この4条件のうち1つでも管理していなければ、その分だけ人の判断に頼ることになります。逆に、4つとも持っていれば「出荷可能な在庫のうち、最も古いロットの、ピッキングエリアにあるものから引き当てる」という指示を機械的に出せます。

先入先出と期限切れ間近の扱い——消費期限と賞味期限は別物

食品・化粧品・医薬品のように期限のある商品を扱うなら、先入先出(古いものから出す)をシステムで担保します。ここで前提として押さえておきたいのが、期限表示には2種類あり、意味が違うということです。

消費者庁の食品表示基準では、消費期限は定められた方法で保存した場合に腐敗や変敗などで安全性を欠くおそれがないと認められる期限を、賞味期限は定められた方法で保存した場合に期待されるすべての品質の保持が十分に可能と認められる期限を指します(消費者庁「食品の期限表示に関する情報」・2026年9月19日確認)。前者は安全性、後者は品質の目安です。

この違いは、システムの判定式に直接効きます。消費期限を過ぎた在庫は出荷不可として機械的に止める設計が自然ですが、賞味期限は「残り日数が何日を切ったら出荷を止めるか」という業務ルールを自社で決める必要があります。そして、この残日数のルールは納品先によって違うのが実情です。食品業界には納品期限を賞味期間の3分の1以内とする商慣習があり、農林水産省はこの見直し(納品期限の緩和)に取り組む事業者を継続的に公表しています(農林水産省「商慣習見直しに取り組む食品製造・小売事業者の公表」・2026年9月19日確認)。つまり、出荷可否の判定日数は取引先ごとのマスタとして持たなければ運用できません。 1つの固定値で組むのは失敗のもとです。

誤出荷が起きる4地点と、そこで止める仕組み

誤出荷は最後の出荷作業で起きるとは限りません。起点は4か所あり、それぞれに止める手段があります。

要点は、どの地点でも「照合しなければ次の画面に進めない」構造にすることです。警告を出すだけで先に進める設計にすると、繁忙期には必ず読み飛ばされます。一方で、全地点を全点検品にすると作業時間が伸びます。どこを厳格にするかは、商品の単価と誤出荷1件あたりの損失(返送費、信用の毀損、回収の手間)で決めてください。

ハンディターミナルとバーコード/二次元コード——GS1-128でロットと期限を1本に載せる

ロットや期限まで照合したい場合、商品のJANコードだけでは足りません。JANコードは商品の種類を表すもので、個々のロットや期限は含まれていないからです。

ここで使えるのがGS1-128です。GS1 Japan(一般財団法人流通システム開発センター)の説明によれば、GS1-128シンボルはアプリケーション識別子(AI)に従って表したデータを、コード128という国際規格の一次元シンボル(ISO/IEC15417)で表現したバーコードで、アルファベットや記号も表現でき、複数のデータを連結できる可変長のバーコードです。ケース単位の商品やパレットといった物流単位の識別に利用されます(GS1 Japan「GS1-128シンボル」・2026年9月19日確認)。アプリケーション識別子は情報の種類とフォーマットを管理する2桁から4桁の数字で、商品コードに続けてロット番号や期限を連結できます。

取引先から届く段ボールにGS1-128が印字されていれば、入荷時の1スキャンで品番・ロット・期限をまとめて取り込めます。印字されていない場合は、自社で受入ラベルを発行して貼る運用になります。どちらの運用になるかを、入荷元ごとに調べてから設計してください。 当社でも決済や認証まわりで外部の規格に合わせる開発を手がけてきましたが、識別子の仕様は後から変えると読み取り機の設定から帳票まで波及します。先に決めるべき部類の代表です。

誤出荷を減らす投資の本質は、検品機器の購入費ではなく、照合を飛ばせない業務フローの設計。

倉庫の外とつなぐ——送り状と運送会社API、配送状況の追跡、EDI、複数倉庫・3PL・返品

倉庫の中の要件が固まったら、次は外との接続です。ここで工期が延びるプロジェクトが本当に多い。理由は技術的な難しさではなく、相手の都合で日程が決まるからです。運送会社のAPIには申込みと商談の段取りがあり、EDIの形式は取引先が指定し、3PLのシステムは簡単には変えられません。開発の見積もりに調整期間が入っていないと、着手の前から遅れます。

私のところに届く物流まわりの相談も、実は「WMSを一から作りたい」より「既存のWMSや3PL、自社のECや基幹システムをどうつなぐか」という形が多いのが実情です。ここは丁寧に見ていきます。

送り状と運送会社API——申込みと商談に時間がかかる前提で組む

出荷の最後に必要になるのが送り状です。発行の方式は3段階あります。

1. 運送会社の送り状発行システムに手入力する: 件数が少ないうちはこれで足ります
2. CSVを出力して取り込む: システムから出荷データを吐き出し、運送会社のシステムに読み込ませる。多くの現場がここにいます
3. APIで直接連携する: 自社システムから送り状番号を取得し、そのまま印字する

3の方式は魅力的ですが、条件があります。ヤマト運輸は2024年6月12日に、顧客のシステムから送り状を発行できる「B2クラウドAPI」の公開を発表しました(ヤマトホールディングス ニュースリリース・2026年9月19日確認)。同社のサービス案内では、B2クラウドAPIは法人向けで、商談時に利用内容を確認したうえで提供され、開発環境から本番環境まで3か月ほどの期間を見込むよう案内されています。料金は1採番あたりの従量課金制で、条件により月額固定費が発生する場合があるとされています(ヤマト運輸「B2クラウドAPI」・2026年9月19日確認)。

つまり、APIを使う前提でスケジュールを引くなら、開発着手より前に申込みを済ませておく必要があります。 佐川急便もEC事業者向けに「スマートAPI」を提供しており、貨物ステータス取得、変更可能日時取得、予定日時変更、変更可能通知の4つのAPIが用意されています。利用までの流れは問い合わせ、返答、商談、申込み手続き、開発、利用開始と案内されています(佐川急便「スマートAPI」・2026年9月19日確認)。どちらの会社も、まず商談を挟む点は共通です。どの運送会社を使うか、複数社を使い分けるかによって、この調整の本数が変わります。

運送会社の選択ルールも決めごとです。方面別か、サイズ別か、着日指定の有無か。ルールが2社以上にまたがる場合、送り状のフォーマットも出力先も分岐するため、出荷画面の設計が一段複雑になります。

配送状況の追跡と、問い合わせを減らす設計

出荷後の「いつ届きますか」という問い合わせは、件数が増えるほど無視できない工数になります。配送状況を自社システムに取り込めば、カスタマーサポートが運送会社のサイトを都度開かずに答えられます。

ここで決めることは3つです。第一に、取得の頻度。リアルタイムに近づけるほど負荷と費用が増えます。多くの用途では1日数回の取得で足ります。第二に、どこまで顧客に見せるか。マイページに出すのか、発送完了メールの中のリンクだけにするのか。第三に、取得できなかったときの表示です。運送会社側の反映が遅れることは普通にあるため、「情報がまだありません」を正しく出せないと、かえって問い合わせが増えます。

取引先とのEDI——受発注と出荷のデータをどの標準に寄せるか

小売や卸と取引していると、受発注のデータをEDIでやり取りすることになります。ここで発注側が直面するのは、取引先ごとに形式が違うという現実です。取引先が10社あれば10通りの変換処理を抱えることになりかねません。

この問題に対して、国が標準化を進めています。前章で触れた国土交通省の「物流情報標準ガイドライン」は、物流に関わるデータ項目の標準形式を定めるもので、2021年10月に初版が公開され、2025年2月7日にver3.00へ改訂されました(国土交通省報道発表・2026年9月19日確認)。同報道発表では、標準貨物自動車運送約款の改正への対応、新たなトラックの標準的な運賃への対応、運送事業者から荷主企業へのCO2排出量報告への対応などが改訂のポイントとして挙げられています。

現実には、既存の取引先が明日から標準に乗り換えることはありません。それでも設計上できることはあります。取引先ごとの形式差を業務ロジックに埋め込まず、入口の変換層だけに閉じ込めることです。 中心のデータ構造を標準の項目名に寄せておけば、取引先が増えても変換の定義を1本足すだけで済みます。取引先が2社を超えた時点で、この作りにしておく価値があります。

複数倉庫・3PL・返品——責任分界点をどこに引くか

倉庫が複数ある、または一部を3PL事業者に委託している場合、最初に決めるのは機能ではなく責任分界点です。

3PLに委託していても、自社が持つべきデータの粒度だけは自分で決めてください。 委託先が2社あってデータの粒度が違うと、全社の在庫を1つの画面で見ることができなくなります。粒度を揃える交渉は契約更新の時期でないと難しいので、早めに始めるのが得策です。

返品は設計で最も忘れられる領域です。返ってきた商品を良品として再入庫するのか、検査中というステータスで保留するのか。再入庫したときのロットと期限はどうするのか。開封済みの扱いは。通販で返品率が数%あるなら、この処理の設計は出荷と同じだけの重みを持ちます。

自社の倉庫の中だけで完結する要件が、ここまでで何割あったでしょうか。外との接続まで含めて工程を引けているかどうかが、この種のプロジェクトの成否を分けます。

2024年問題は「輸送の制約」として要件に入る——一次資料で確認した中身【2026年9月19日時点】

「2024年問題は運送会社の話で、荷主の自分には関係ない」と考えている方がまだいます。しかし制度の中身を読むと、荷主側にも義務が生まれており、しかもそれは倉庫の運用時間という形で日々の作業に効いてきます。ここでは、国土交通省・厚生労働省の公開資料で直接確認した内容だけを書きます(すべて2026年9月19日確認)。

何が変わったのか

輸送能力への影響として、国土交通省関東運輸局のページでは「2024年:約14%、2030年:約34%の輸送能力不足のおそれ」という推計が示されています。

読み取っておきたいのは2点です。1つは、ドライバーの拘束時間には1日13時間という枠があり、その中には荷待ちや荷役の時間も含まれるということ。もう1つは、物流効率化法によって荷主側にも努力義務が課されたということです。「運送会社が何とかする」で済む構造ではなくなりました。

制度がシステム要件に落ちる3か所——出荷締め時刻、納品リードタイム、荷待ち時間の記録

制度の話を、システムの要件に翻訳します。効いてくるのは主に3か所です。

1つ目は出荷締め時刻です。 ドライバーの拘束時間に上限がある以上、集荷の時刻は運送会社の都合で決まります。これまで「17時までの注文は当日出荷」としていたものが、集荷時刻の前倒しで成立しなくなることがあります。システム側では、締め時刻を固定値でコードに書かず、曜日別・運送会社別・方面別に設定できるマスタとして持ってください。加えて、締め時刻を過ぎた注文を翌日扱いに自動で回す処理と、ECの画面に表示するお届け予定日の計算が連動している必要があります。

2つ目は納品リードタイムです。 取引先への納品が翌日必着だった条件が、翌々日に緩む(あるいは緩めてもらう交渉をする)ケースが出ています。受注時に自動で算出している納品予定日のロジックが、取引先ごと・方面ごとに設定可能になっているかを確認してください。ここが固定値だと、条件が変わるたびに改修が発生します。

3つ目は荷待ち時間と荷役時間の記録です。 物流効率化法では、荷主を含む事業者に対して運転者の運送および荷役等の効率化に関する判断基準が省令で定められ、2025年4月1日に施行されました。あわせて2026年4月1日施行分の政省令もあります(国土交通省「物流効率化法 関係政省令」・2026年9月19日確認)。取り組みを説明するには、まず実態の数値が要ります。トラックが構内に入った時刻、荷役の開始と終了、出た時刻。これらを記録する仕組みがなければ、短縮したかどうかを示せません。トラック予約受付の仕組みを併せて検討する会社が増えているのは、この記録と平準化を同時に解こうとしているからです。

制度対応というと身構えますが、要件としては「固定値をマスタにする」「時刻を記録する」という地味な話に落ちます。逆に言えば、この2つを設計時にやっておけば、制度が動いても改修せずに済みます。ここまでが決めごとの全体像です。最後に、これを外部のチームと一緒に作る場合の進め方を書きます。

外部チームで物流システムを作るときの進め方と、当社が向く案件・向かない案件

ここまでの決めごとを、外部の開発チームと一緒に形にする場合の話をします。物流は現場を見ないと設計できない領域が多く、外部チームとの相性がはっきり出ます。まず渡す前の準備、次に当社の場合の向き不向きを、順に書きます。

渡す前に揃える4点——現行フロー図、帳票の実物、マスタの現物、繁忙期の数値

外部に相談する前に、次の4点を揃えてください。これがあるかどうかで、初回の打ち合わせの密度がまったく変わります。

1. 現行フロー図: 入荷から出荷までを、例外処理込みで1枚に描く。きれいな図でなくて構いません。手書きの写真で十分です
2. 帳票の実物: ピッキングリスト、納品書、送り状、返品伝票の現物。現場が手書きで書き足している欄こそが要件です
3. マスタの現物: 商品マスタ、取引先マスタ、ロケーション一覧のExcelそのもの。項目名と実データの両方を見せてください
4. 繁忙期の数値: 1日の最大出荷件数、ピーク時の同時作業者数、SKU数、ロケーション数。平常時ではなく繁忙期の数字で

とくに2番目の「手書きで書き足している欄」は、システムに載っていない業務ルールの化石です。ここを拾えるかどうかが、要件定義の質を決めます。要件定義そのものの進め方は「要件定義 進め方」の記事に5ステップでまとめてあるので、併せてご覧ください。

当社の位置づけ——物流システムの開発に対応しています。向かない案件も先に書きます

先に位置づけを書きます。当社は庫内(WMS)と配送(TMS)を含む物流システムの開発に対応しています。 サイトで公開している事例は、介護記録SaaS「CareViewer」、HELTEQ、金融系マッチングサービスの3件で、公開している実績の領域は決済アプリ(Stripe連携・二要素認証・ウォレット・PDF出力)、AIチャットボット、求人プラットフォーム(ATS)、ヘッドレスCMSによるWebサイトなどです。

そのうえで、次のような案件は当社には向きません。理由は実績の有無ではなく、提供している体制と対象領域です。

• 自動倉庫・コンベア・ソーターなどのマテハン設備の制御が主題の案件(WCS/WESの領域)。当社が提供するのはソフトウェア開発のチームで、設備そのものの制御は対象としていません。設備メーカーや、その設備の導入実績がある会社に相談してください
• 既存の大規模WMSパッケージのカスタマイズが主体の案件。そのパッケージを扱うベンダーのほうが確実です
• 庫内の現場に常駐して業務設計から伴走することが必要な案件。当社の体制は開発チームの提供であり、現場常駐のコンサルティングは提供していません

合わない案件を引き受けても、お互いに損をします。相談をいただいた段階で、その旨はその場でお伝えしています。

当社が力になれるのは「つなぐ側」——体制・単価・進め方

一方で、本記事の第4章で扱った「倉庫の外とつなぐ」部分——自社ECや基幹システムと、既存WMSや3PLの間をつなぐ連携基盤、受注を束ねるOMS側の開発、配送状況を取り込んで顧客に見せる画面、出荷実績を集約するダッシュボード——であれば、当社の実績領域と重なります。外部APIとの連携や、要件が動き続けるプロダクトの継続開発は、当社が続けてきた仕事そのものです。

体制は2パターンから選べます。パターンAは日本人PMまたはブリッジSEをフロントに置き、その後ろにエンジニアを付ける形(推奨)。パターンBはエンジニアのみの形です。1名から契約でき、最短2週間で開始、増員は約1週間、縮小や交代は1か月単位で対応します。公開単価は実務3年目安で1,500USD(1USD=150円換算目安で約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。最小構成は日本人PMフロント+2〜3人月で月額約80万円からになります。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

品質は3点セットで担保しています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。この進め方は月額固定でチームを確保するラボ型開発の形に近く、仕組みの詳細は「ラボ型開発」の記事にまとめてあります。

最後にもう一度書きます。物流システムの相談で最も多い失敗は、範囲が曖昧なまま見積もりを比べることです。決めごとを並べてから相談する。それだけで、選べる相手も、話の速さも変わります。

【FAQ】物流システム開発でよくある質問

最後に、相談の場で実際によく出る質問を5つまとめます。どれも記事本編の内容とつながっているので、詳しくは該当の章に戻ってご確認ください。

Q1. WMSと在庫管理システムの違いは何ですか

扱う対象が違います。在庫管理システムは在庫の「数」を管理するもので、どの商品が何個あるかを把握します。WMSは在庫の「所在と状態」に加えて、庫内の作業そのものを管理します。どの棚にあるか、どのロットか、誰がいつピッキングしたか、検品は済んだか。在庫数が正しくても誤出荷は起きるので、庫内の作業事故を減らしたいならWMSの領域になります。自社で在庫管理を作れるかという論点は「在庫管理システム 自作」の記事をご覧ください。

Q2. 既製品とスクラッチ開発の境目はどこですか

判断の材料は「自社のルールが、その業界で一般的かどうか」です。入荷から出荷までの流れが一般的で、ロット管理や3温度帯のような要件が既製品の標準機能に収まるなら、既製品で足ります。逆に、同梱物の出し分け条件が複雑、引当ルールが独自、複数チャネルの在庫を特殊な優先順位で振り分ける、といった条件が3つ以上あるなら、既製品に無理に合わせると運用が破綻します。実務では「既製品+足りない部分だけ作る」という構成が最も多く、現実的です。開発方式の分類は「スクラッチ開発とは」の記事に整理してあります。

Q3. 開発期間はどのくらい見ておけばよいですか

規模によるため一概には言えませんが、開発そのものより前の調整期間を必ず工程に入れてください。 第4章で触れたとおり、ヤマト運輸のB2クラウドAPIは開発環境から本番環境まで3か月ほどの期間を見込むよう案内されています(2026年9月19日確認)。EDIの形式確認や3PLとのデータ粒度の交渉も同様に時間がかかります。技術的な開発が終わっても、外部との接続が整うまで本番に出せないという事態は珍しくありません。

Q4. 3PLに委託していますが、自社でシステムを持つべきですか

委託先のWMSをそのまま使うのであれば、自社でWMSを持つ必要はありません。ただし、自社が把握する在庫データの粒度だけは自社で決めてください。 委託先が2社以上ある場合、粒度が違うと全社の在庫を1つの画面で見ることができなくなります。この場合に自社が作るのは、WMSではなく各社のデータを受け取って揃える連携基盤です。規模が小さく済むことが多く、投資対効果も見えやすい領域です。

Q5. 物流に詳しい開発会社をどう選べばよいですか

評価軸そのものは一般のシステム開発と共通で、詳しくは「システム開発会社 選び方」の記事にまとめてあります。物流固有で加えるなら、確認する点は2つです。1つは、庫内の作業を見たことがあるか。ピッキングの方式を聞いて即答できない相手は、画面設計で必ずつまずきます。もう1つは、できない領域を自分から言うかどうかです。当社も、設備そのものの制御のように対象としていない領域は最初にお伝えしています。範囲の広い領域で「全部できます」と答える相手には、要注意です。物流システムの選定で最後に効くのは、範囲を正直に切れる相手かどうかという一点。

まとめ: 物流システム開発は、費用の前に決めごとを並べた会社が速い

物流システムの開発が難しいのは費用が高いからではなく、決めなければならないことが庫内の外まで広がっているからです。WMS・TMS・OMSという略称には公的に統一された定義がないため、略称で話すと見積もりの範囲がずれます。庫内は入荷・格納・ピッキング・梱包・出荷の5業務に分けて決めごとを埋め、ロケーション管理を固定にするかフリーにするかを先に決めてください。方式が決まれば、ハンディの画面も棚のラベルも自然に決まります。

誤出荷は注意喚起では止まりません。出荷可能な在庫を倉庫・ロケーション・ロット・ステータスの4条件で機械的に選び、入荷・格納・ピッキング・出荷検品の4地点で「照合しなければ次に進めない」構造にしてください。消費期限と賞味期限は食品表示基準で定義が異なり、賞味期限の残日数のルールは取引先ごとに違うため、固定値ではなくマスタで持ちます。倉庫の外との接続は技術ではなく相手の都合で日程が決まるので、運送会社APIの申込みやEDIの形式確認、3PLとのデータ粒度の交渉を工程の頭に置いてください。2024年問題も、出荷締め時刻をマスタにする、荷待ち時間を記録するという形で要件に落ちます。

当社は庫内・配送を含む物流システムの開発に対応しています。ただし庫内設備の制御や大規模パッケージのカスタマイズが主題の案件は、その領域の会社に相談されることをお勧めします。とくに力になれるのは、自社ECや基幹システムと既存WMS・3PLをつなぐ側です。費用相場の全体像は業務システム開発を外注する費用、在庫管理を自作できるかの判断は在庫管理システムの自作もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どこから着手すべきかの整理と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。