荷主管理システム開発の発注/外注/依頼/委託方法について

荷主管理システムの発注・外注は、WMS・TMS・OMSのどこまでを対象にするかを決め、標準機能と個別開発を切り分けてから進めることが成功の近道です。

荷主管理システムを導入したいものの、「既製品を契約すべきか」「開発会社へ依頼すべきか」「RFPに何を書けばよいか」「見積書の金額をどう比べればよいか」で迷う企業は少なくありません。この記事では、荷主企業が発注・外注を進める際の考え方を、発注形態、要件整理、契約、費用相場、委託先選定、見積比較、導入後の検証まで一つの流れにまとめます。

▼全体ガイドの記事
・荷主管理システム開発の完全ガイド

荷主管理システムの発注・外注は何から始めますか？

最初に行うことは、システム名を決めることではなく、どの業務の情報を一つにつなぎたいのかを定義することです。荷主管理システムは統一された単一製品名ではなく、荷主の受注・出荷、倉庫在庫、配送手配、納品実績、物流費を管理する仕組みの総称として使われます。そのため、自社の課題を整理しないまま「荷主管理システム一式」と依頼すると、会社ごとに提案範囲が変わり、見積比較が難しくなります。

在庫、入荷、棚入れ、ピッキング、検品、棚卸を中心に改善したい場合はWMS（倉庫管理システム）が中心です。配車、運送会社への依頼、配送ルート、納品時間、到着状況を重視する場合はTMS（輸配送管理システム）が中心になります。ECや販売チャネルの受注を取り込み、出荷指示へ変換する業務はOMS（受注管理システム）が担います。実際の案件では、基幹・ECからOMSへ受注を取り込み、WMSへ出荷指示を送り、TMSや配送会社APIから実績を返す構成が多いため、最初から三つを独自開発する必要はありません。

次に、受注、出荷指示、入荷予定、在庫照会、検品、配送依頼、納品確認、返品、請求、物流費分析の各工程で、誰が何を入力しているかを確認します。たとえば、倉庫から毎日送られる在庫CSVを担当者が加工し、営業がメールで納期を確認し、経理が別の表で保管料を計算しているなら、それぞれがシステム化の候補です。ただし、すべてを一度に対象にすると現場の負荷が高くなるため、誤出荷率、在庫差異、出荷処理時間、荷待ち時間、物流費のうち、経営上の優先度が高い2〜4個を最初のKPIに絞ります。

発注形態はどれを選ぶべきですか？

発注形態は、SaaS・クラウド製品の標準利用、パッケージ導入と連携開発、個別開発の三つに分けて比較すると判断しやすくなります。重要なのは、安い順に選ぶことではなく、業務の独自性と変更頻度に合う方式を選ぶことです。標準化できる業務まで個別開発すると初期費用と保守負担が増え、特殊な料金計算や設備連携まで標準機能に無理に合わせると現場が定着しにくくなります。

SaaSやクラウドWMSは、サーバーを自社で用意せず、月額料金や出荷件数に応じた従量料金で利用する方式です。小規模な荷主、EC出荷が中心の企業、まず在庫や出荷実績を見える化したい企業に向いています。たとえばSunLOGIは、公式料金例として初期費用0円、1倉庫・1荷主で月500件なら合計17,500円、月10,000件なら125,000円、月30,000件なら195,000円と掲載しています（出典: SunLOGI「料金について」、2026年8月確認）。この金額はサービス利用の例であり、機器、個別連携、データ移行、教育費まで含む発注総額ではありません。

在庫、入出荷、ハンディ検品などはパッケージの標準機能を使い、基幹・EC・EDI・配送会社API・会計との接続や独自帳票だけを追加する方式です。WMSの基本部分を毎回作り直さずに済むため、フルスクラッチより短期間で立ち上げやすく、業務の差別化部分にも予算を配分できます。一方で、標準機能に合わせて業務を変える範囲と、追加開発する範囲をFit to Standardの会議で決める必要があります。過剰なカスタマイズは、製品アップデートのたびに改修費が発生する原因となります。

荷主別の保管料・荷役料・運賃計算、特殊なロット・期限管理、温度帯や危険物の追跡、独自の配車ロジック、マテハンやAGVとの連携など、標準製品では業務上の強みを表現できない場合は個別開発を検討します。ただし、要件を自由に書けることと、将来も安全に運用できることは別問題です。個別開発を選ぶ場合は、完成後の保守要員、障害時の復旧、OSやミドルウェアの更新、API仕様変更、法改正対応まで含めて発注先と分担を決めます。

RFPと要件整理はどのように進めますか？

RFP（提案依頼書）は、欲しい機能の羅列ではなく、現状の業務、達成したいKPI、対象範囲、前提条件、提案してほしい内容を同じ形式で伝える文書です。委託先に丸投げするのではなく、発注側が比較の軸を作るために利用します。特に荷主管理では、荷主・倉庫・運送会社・営業・経理が同じデータを扱うため、利用者ごとの権限と業務の境界を先に書くことが重要です。

現状整理では、受注が基幹・EC・EDI・CSVのどこから来るか、出荷指示を誰が作るか、在庫をどの頻度で更新するか、配送会社へ何を渡すか、納品・返品・欠品をどう戻すかを記載します。月間出荷件数、出荷行数、SKU数、拠点数、荷主数、運送会社数、同時利用者数も、直近の通常月と繁忙期に分けて示します。さらに、バーコードやQRコード、ハンディ端末、プリンター、ラベルサイズ、通信環境など現場の制約を記載すると、後から発生する追加見積もりを減らせます。

機能要件には、マスタ管理、受注・出荷指示、入荷、在庫、ロケーション、ロット・期限・シリアル、検品、送り状、配送状況、返品、物流費、KPI、権限管理を記載します。各機能は「できること」だけでなく、業務ルールと例外を書きます。たとえば欠品時に分納するのか、返品を良品・不良品に分けるのか、運賃を荷主別に計算するのかで、必要なデータ構造が変わります。

非機能要件には、稼働時間、画面応答、同時利用者数、バックアップ、復旧目標、障害通知、監査ログ、暗号化、MFA、データ保存期間、APIの再送、SLA、保守窓口を含めます。WMSや配車とハンディ端末・自動化設備を連携する場合は、IPAが2026年4月版で公開した「制御システムのセキュリティリスク分析ガイド」も参考にし、停止した場合の事業影響から要件を考えます（出典: IPA、2026年）。

RFPには、委託先に提出してほしい資料も指定します。提案書は想定業務フロー、システム構成、標準機能と追加開発の境界、連携方式、移行方法、体制、スケジュール、保守、リスク、前提条件を同じ順番で提出してもらいます。デモはきれいな成功パターンだけでなく、欠品、返品、再出荷、配送会社API停止、通信断、ラベル再発行といった異常系を実データに近い条件で見せてもらいます。

見積もりは、要件定義、設計、開発、連携、移行、テスト、教育、リリース、保守に分け、作業量、単価、期間、成果物、除外事項を記載してもらいます。「一式」とだけ書かれた金額は安く見えても比較できないため、追加条件が発生した場合の単価や変更管理の方法まで確認します。

契約形態はどのように使い分けますか？

荷主管理システムでは、SaaSの利用契約、パッケージのライセンス契約、導入支援契約、受託開発契約、保守運用契約が組み合わさります。開発の契約形態は、要件の確定度、成果物の明確さ、発注側がどれだけプロジェクト管理に参加できるかで決めます。契約書の名称だけで判断せず、成果物、検収、変更、知的財産、瑕疵対応、再委託、終了時の引き継ぎを確認します。

請負契約は、合意した成果物を完成させ、発注側が検収する形に向いています。画面、API、帳票、バッチ、移行データ、操作マニュアル、テスト結果など、何を納品物とするかを一覧化し、受入条件を具体化します。荷主管理では「在庫が見られる」だけでは不十分で、棚卸後の差異処理、同一商品のロット違い、欠品時の分納、運送会社から返るステータスなど、受入データと業務シナリオを基準に検収することが重要です。

要件定義、現場調査、Fit to Standardの判定、データ移行計画、アジャイルな改善など、作業の成果を一つの完成品だけで定義しにくい工程では、準委任契約が使われることがあります。稼働時間や役割、会議体、報告内容、作業範囲、責任分担を明記し、発注側も意思決定を遅らせない体制を用意します。準委任だから予算が無制限になるわけではなく、月次の上限工数、変更承認、終了条件を決めることが大切です。

個別開発では、ソースコード、設計書、API仕様書、テストコード、インフラ設定、IaC、運用手順書、第三者ライセンスの扱いを確認します。発注側が著作権の利用範囲を確保したい場合は、成果物の権利帰属や利用許諾、改変・再利用の条件を契約に反映します。サービス終了や委託先変更に備え、データを標準形式で取り出せること、バックアップを受け取れること、保守会社へ移行できることも、発注時に決めておくと安心です。

荷主管理システムの費用相場はいくらですか？

荷主管理システムの費用は、公開料金のあるSaaSなら初期0〜数十万円、月額1〜20万円程度から始められる例があります。一方、既存の基幹・EC・WMS・TMS・配送会社・会計を連携し、複数拠点や独自の料金計算まで含めると、初期費用は数百万円から数千万円規模まで広がります。以下の金額は荷主管理システムだけの統一統計ではなく、公開WMS料金と業務システム開発の一般的な相場を組み合わせた、企画段階の推定レンジです。

公開料金の比較では、初期費用、月額基本料、出荷件数の従量料、拠点・荷主追加、端末、導入支援を別々に読みます。日本倉庫協会が掲載するMPS LOGIの参考価格では、月額利用料は1〜5,000明細で66,000円、5,001〜10,000明細で110,000円、10,001明細以上で220,000円、初期導入支援は550,000円です。データ移行、教育、荷主・拠点追加、ハンディ端末は追加料金として示されています（出典: 一般社団法人日本倉庫協会「MPS LOGI」、2026年8月確認）。

クラーク（Qrark）も、基本料金月額25,000円・初期80,000円、在庫・ハンディ・請求・寄託者などのオプションを公開しています。複数拠点、月間50,000行超、独自要件は別見積もりになり得るため、安い基本料金だけで選ばないことが必要です（出典: クラーク公式料金ページ、2026年8月確認）。このように、製品の公開料金は予算の下限を知る材料として使い、API連携、業務移行、現場教育、並行稼働を含めた総額は個別提案で確認します。

企画段階の目安として、SaaSの標準利用は初期0〜30万円、月額1〜20万円程度に従量料金を加え、数日〜1か月程度で始めるケースが考えられます。クラウドWMS・TMSに導入支援を付ける場合は初期30〜100万円、月額5〜30万円程度、1〜3か月程度が一つの目安です。パッケージにAPI、帳票、マスタ、移行を加える場合は初期300〜1,500万円程度、個別開発のMVPは500〜2,000万円程度、全社・多拠点のWMS/TMS統合は2,000万円〜1億円超という推定レンジになります。

これらは確定価格ではありません。連携先の本数、データ移行件数、ハンディ端末数、拠点数、同時利用者数、テスト範囲、24時間運用の有無で大きく変わります。社内Q&Aで示された一般業務システムの人月単価目安は、PM90万〜150万円、SE65万〜110万円、PG50万〜90万円、テスター45万〜80万円です。見積もりでは単価だけでなく、各工程の人月と担当ロールを確認し、要件追加によって当初費用が1.3〜1.5倍になるリスクも予備費として扱います。

発注時は初期費用だけでなく、5年間の総保有コスト（TCO）を比較します。月額利用料、従量料金、クラウド・ネットワーク費、端末レンタル、保守、監視、バックアップ、API利用料、配送会社の契約費、教育、追加拠点、法改正対応、マスタ整備、改善開発を並べます。SaaSは初期費用が低くても出荷数に比例して従量料金が増える場合があり、スクラッチは導入後の保守とセキュリティ更新が必要です。年間費用の見通しと、出荷数が増えた場合の料金表を提示してもらいます。

委託先選定と見積比較では何を確認しますか？

委託先は、会社の知名度や見積総額だけでなく、自社と似た業務を理解し、現場で使える状態まで責任を持てるかで選びます。荷主管理では、EC出荷型、複数倉庫型、配車・配送型、物流費・請求型、設備連携型で適した会社が違います。候補を3〜5社程度に絞り、同じRFP、同じサンプルデータ、同じデモシナリオで比較すると、提案の違いが見えやすくなります。

「物流の実績があります」という説明だけでは不十分です。月間出荷行数、SKU数、拠点数、荷主数、3PLとの役割、ECや基幹との接続、ロット・期限管理、返品や欠品の扱いが自社と近いかを確認します。可能であれば、同規模の導入企業から、導入前の課題、稼働までの期間、移行時の苦労、現場教育、稼働後の保守について話を聞きます。顧客名を出せない場合でも、匿名化した構成、テスト項目、KPIの改善方法を確認できる会社を選びます。

見積比較では、機能数の多さより、どこまでを金額に含めているかをそろえます。要件定義、画面・帳票、API・EDI、マスタ連携、データ移行、端末設定、テストデータ作成、現場教育、並行稼働、切り戻し、リリース立ち会いを行単位で比較します。標準機能を「対応可」としていても、設定で済むのか、追加開発が必要なのか、追加開発の際の単価はいくらかを質問します。

配送会社との連携では、送り状発行や住所チェックをAPIで自動化できるかも確認します。SGシステムのBiz-Logi API導入事例では、送り状を後出しで発行する運用によって、AGVを含む出荷体制の効率化につなげています（出典: SGシステム「Biz-Logi API導入事例」、2026年8月確認）。このような事例を参考に、提案会社へ「自社の現場でどの作業を前後させると効果が出るか」まで説明してもらいます。

提案時の担当者が稼働後も窓口になるか、現場と開発の間を誰が調整するか、再委託先はどこか、障害時に何分以内に受け付けるか、復旧目標は何かを確認します。担当者の経験だけでなく、設計書やテスト結果を残すプロセスがあるかも重要です。SaaSならデータのエクスポート形式、解約時の返却期間、料金改定、サービス終了時の通知を、個別開発ならソースコードとインフラ情報の引き渡しを契約に含めます。

評価表は、業務適合性、連携・データ移行、現場操作性、セキュリティ、導入体制、保守、5年TCO、提案の透明性に重みを付けて作ります。費用だけで逆転できないように、最低限満たすべき条件を先に設定します。候補が要件を満たさない場合は、無理にカスタマイズするのではなく、対象範囲を段階導入へ分ける判断も必要です。

発注後のテスト・移行・現場定着はどう進めますか？

発注が決まった後も、要件定義書を納品物にして終わりにせず、実データと実機を使った検証を早い段階から行います。最初は1拠点、1商材、1配送会社などに対象を絞り、標準フローで現場が使えるかを確認してから、拠点や荷主を増やします。これにより、全社展開後に判明しやすいマスタ不備や端末操作の問題を小さく抑えられます。

移行対象を商品、取引先、配送先、運送会社、運賃、ロケーション、在庫、受注、出荷実績、返品履歴に分け、コード変換、重複、欠損、桁数、日付、ロット・期限の扱いを確認します。受入テストでは、通常の出荷だけでなく、欠品、分納、返品、再出荷、棚卸差異、送り状の再発行、APIの遅延、通信断、誤ったバーコードを試します。合格条件、未解決課題、再テスト日を一覧で管理し、検収の根拠を残します。

現場教育は、管理者向け、倉庫作業者向け、荷主担当者向け、運送会社向けに分け、実際の画面と端末で行います。マスタ登録、出荷指示、検品、在庫調整、返品、締め処理など、利用者が日常的に触る順番で手順書を作ると定着しやすくなります。操作説明だけでなく、「分からないときに誰へ連絡するか」「誤出荷の疑いがあるときに何を止めるか」まで決めます。

通信障害、停電、API停止、端末故障、クラウド障害に備え、紙の出荷指示、後追い入力、在庫差異の確認、復旧後の再送手順を用意します。稼働後は、誤出荷率、在庫差異、出荷処理時間、納期遵守率、荷待ち時間、問い合わせ件数を月次で確認し、導入前の基準値と比べます。物流効率化法では、2026年4月から一定規模以上の特定荷主などに中長期計画、物流統括管理者、定期報告などが求められます。荷待ち時間などを継続して記録できるデータ設計は、業務改善だけでなく報告準備にも役立ちます（出典: 国土交通省「物流効率化法」理解促進ポータル、2026年）。

よくある質問（FAQ）

ここでは、荷主管理システムの発注・外注を検討する企業から特に寄せられやすい質問に回答します。自社の条件によって最適な方式は変わるため、回答をそのまま結論にせず、RFPに落とし込む際の判断材料として活用します。

倉庫内の入出荷、在庫、検品が主な課題ならWMSだけで始められる場合があります。ただし、受注の取り込み、配車・配送状況、運賃計算、物流費分析まで管理したい場合は、OMS、TMS、基幹システム、配送会社APIとの連携が必要になるため、最初に業務範囲を切り分けます。

必要になることがあります。3PLへ委託していても、荷主側で出荷指示、在庫、納品実績、返品、問い合わせ、物流費を確認できなければ、CSVの往復やメール確認が残るためです。倉庫側のWMSを置き換えるのではなく、荷主ポータルやAPIで必要なデータを共有する方式もあるため、既存の3PLとの役割分担をRFPに書いて提案を受けます。

まず3〜5社程度に同じRFPを渡し、提案範囲と見積条件をそろえて比較する方法が現実的です。SaaS・パッケージ・個別開発を混ぜる場合は、製品の月額と開発会社の初期費用を単純に比べず、5年総額、業務適合性、移行、教育、保守、撤退条件を同じ評価表で確認します。要件が曖昧な場合は、いきなり本開発を依頼せず、要件定義や現場調査を先行発注する方法もあります。

依頼できますが、最初から全機能を個別開発する必要はありません。SaaSやパッケージで在庫・出荷の標準機能を利用し、独自の帳票、料金計算、基幹連携だけを小さく追加する方が、費用と運用リスクを抑えやすいです。月間出荷数が少なくても、商品特性やトレーサビリティ要件に独自性がある場合は、MVPを作って現場検証してから段階的に広げます。

まとめ

荷主管理システムの発注・外注では、最初にWMS・TMS・OMS・基幹・配送会社のどこまでを対象にするかを決め、紙やExcelで残っている業務と改善KPIを整理します。そのうえで、標準利用、パッケージ＋連携、個別開発を比較し、RFPには機能要件だけでなく、データ移行、API、端末、セキュリティ、障害対応、教育、保守、5年総額まで書きます。

候補会社へ相談する前に、対象拠点、月間出荷件数、SKU数、利用者、連携先、現場端末、重要KPI、希望時期、予算の考え方を一枚にまとめます。見積書は「一式」の安さではなく、含む範囲、前提、除外事項、追加単価、体制、契約、解約や引き継ぎ条件を確認します。これらがそろうと、発注先との認識違いを減らし、経営層にも投資効果を説明しやすくなります。

導入は、1拠点・1商材・1配送会社など小さな単位でMVPを稼働させ、実データと実機で受入テストを行ってから段階展開します。荷待ち時間、在庫差異、誤出荷、納期遵守率、物流費などを継続的に測り、現場教育と障害時の代替手順を整備します。発注のゴールはシステムを納品してもらうことではなく、荷主・倉庫・運送会社が同じ情報を使い、物流業務を改善し続けられる状態を作ることです。

▼全体ガイドの記事
・荷主管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。