倉庫料金計算システム開発の発注/外注/依頼/委託方法について

倉庫料金計算システムの費用は、荷主・拠点の数や料金ルール、WMS連携の範囲によって変わります。初期10万円から個別開発の5,000万円超まで幅があります。

各社の見積もりを同じ条件で比べるには、発注形態を決め、料金ルールや連携の範囲を先に整理しておくのが近道です。

▼全体ガイドの記事
・倉庫料金計算システム開発の完全ガイド

倉庫料金計算システムの発注・外注の全体像

倉庫料金計算システムは、WMSの入出庫や在庫、作業実績のデータと、請求・債権管理をつなぐ業務基盤です。請求書の見た目だけを先に決めると、実績データや料金マスタが足りず、Excelでの補正が残りやすくなります。そのため、計算の内容だけでなく、どの実績を根拠に誰が承認するかも一緒に決めておく必要があります。

導入が役立つ企業の特徴

荷主ごとに料金表や締め日、請求単位、最低保証額、割増条件が異なる企業ほど、専用の料金計算機能が役立ちます。

  • 温度帯で単価が異なる倉庫:常温・冷蔵・冷凍の保管料を、それぞれ分けて管理
  • 課金単位が多い3PL:パレットやケース、バラのほか、重量・容積を使い分けます。
  • 個別作業を請求する倉庫:返品や流通加工の料金を扱います。
  • 拠点や作業が増えた企業:月末集計や会計連携に時間がかかる場合も、導入の対象になります。

料金条件が担当者の経験に依存していると、Excelでの管理は破綻しやすくなります。また、自社倉庫だけを運営する企業も、専用の料金計算機能の導入対象になり得ます。

外注する範囲の決め方

委託する範囲は、解決したい業務課題と、社内で担う作業との分担で決めます。

  • 委託する工程:要件定義や製品導入、料金計算エンジン開発のうち、どこを任せるか。
  • 一括導入:WMS・会計・請求書発行との連携も含めて任せる形です。
  • 業務整理を委託:システム化の経験が少ない場合、業務整理とRFP作成を任せ、製品選定と契約は自社で進めます。
  • 一貫して委託:複数荷主の料金表が競争力に直結する場合、要件定義から保守まで同じ会社に任せ、料金ロジックの責任の範囲を明確にします。

倉庫料金計算システムの発注形態の選び方

クラウドWMS・SaaS、パッケージ導入、スクラッチ開発の特徴を3つのパネルで示した図。
標準機能から個別要件まで、必要な適合度に応じて選択肢が広がります。

発注形態は、料金表の複雑さと拠点・荷主の数を基準に、既存WMSや社内体制を合わせて決めます。たとえば、短期導入を急ぐならクラウドWMS、独自の料金式を足すならパッケージ、基幹連携が必要ならスクラッチ開発が候補です。

クラウドWMS・SaaSの利用

クラウドWMSは、サーバーの調達や更新作業を自社で抱えずに済み、在庫・入出庫・請求の機能を早く使い始められる選択肢です。

  • 利用規模の費用:拠点や利用者の追加料金、月間明細数の上限
  • 外部連携:CSV・APIを使えるかどうかと、契約に含まれる範囲

具体的には、クラークの基本機能が初期8万円・月額2万5,000円、請求機能が月額2万円です。Enterprise版は初期8万円・月額8万円で、導入支援は初期30万円です。ただし、これは一社の例であり、システム全体の相場ではありません(出典: クラーク公式料金ページ、2026年8月確認)。

パッケージ導入とカスタマイズの組み合わせ

パッケージ導入では、標準機能と追加開発の範囲を切り分けたうえで、デモで適合性を確かめます。

  • 追加開発:標準機能と導入ノウハウを生かし、料金表や外部連携を追加できます。
  • 範囲の切り分け:どこまでを標準機能と設定で賄い、どこからアドオンや別システムに残すかを分けて、過剰なカスタマイズを防ぎます。
  • デモ確認:入庫実績、在庫、月末締めを、実データに近いシナリオで確認します。返品や請求訂正から最低請求額、荷主向けの明細照会まで含めて見ます。

スクラッチ開発の選び方

スクラッチ開発を選ぶかどうかは、個別要件と運用の負担を比べて判断します。

  • 業務への適合:複雑な荷主契約や独自の原価配賦、複数会社の請求に合わせて設計でき、リアルタイム連携も組めます。
  • 運用負担:料金ロジックの変更や障害対応、開発会社の交代、OSやクラウドの更新も、自社で管理する必要があります。
  • 将来の変更:計算エンジンをWMSから分けて実績を受け取り、結果・明細・エラー・承認履歴を返す構成にすると、WMSの入れ替えや料金表変更に備えやすい。

ポイント

標準機能で業務が収まるかをまず確かめ、収まらない料金ルールや連携の量から、クラウドWMS、パッケージ、スクラッチ開発のどれに寄せるかを決めます。

RFPと要件整理の進め方

料金ルールと例外、実績データと外部連携、受入基準と並行稼働を上下3層で示した図。
料金の定義から実績の照合まで、要件を積み上げて整理できます。

RFPは、各社が同じ条件で提案と見積もりを出せるよう、発注条件をまとめた文書です。機能の希望だけでなく、計算対象から保守までを一つの流れで書きます。

代表荷主2〜3社の過去3か月分の実績を用意し、新旧の計算結果を突き合わせられる形にしておきます。この実績は、見積もりの精度と導入後の品質を高める材料になります。

料金ルールと例外の洗い出し

料金マスタは、荷主と契約ごとに分けて、倉庫や温度帯、商品・作業区分まで洗い出します。単位や適用期間、税区分も含めます。

  • 保管料:月末在庫と日次平均在庫のどちらを使うか、入庫日と出庫日のどちらを基準にするかを決めます。
  • 最低保証:最低保証量と、月の途中で入出庫があった場合の扱いを定義します。
  • 荷役料:入荷から出庫までの各作業と、返品や棚卸し、ラベル発行を作業単位で整理します。
  • 課金単位:ケースやバラ、重量、作業時間などを、それぞれ作業に紐付けます。

例外では、最低請求額や割増・割引、緊急作業、資材費などを扱います。再配達や廃棄、手入力の調整も対象にします。そのうえで、例外料金を誰が登録できるか、承認後の履歴をどう残すかも決めておきます。

計算式を変えた場合は、変更前後の差額と承認者を追えるように設計し、荷主から請求根拠を問われたときにも、変更内容を説明できるようにします。

実績データと外部連携の定義

料金計算は、入力データが正確であることが前提です。そのため、データごとに正本を決め、連携の方法と頻度、再取込やエラー時の再実行をRFPに書きます。

  • 物流実績:WMSの在庫、入出庫、作業実績を整理します。
  • 販売・請求:販売管理と会計、請求書発行それぞれの役割を定めます。
  • 外部データ:EC・OMS、EDI、配送会社データのうち、連携が必要なものを決めます。

APIが使えない場合も、CSVの項目や文字コード、日付形式を決めておけば、属人的な転記を減らせます。また、重複判定キーと取込後の照合結果も決めておきます。

荷主向けには、在庫や作業、請求明細をWebで照会させるかどうかを決め、請求書や明細の粒度も確認します。管理者向けには、未請求や赤字作業、荷主別の粗利を分析できるデータを残しておきます。さらに、関連データは、請求の効率化だけでなく、料金表の見直しや収益管理にも使われます。

受入基準と並行稼働の決め方

受入基準には、画面の表示だけでなく、計算結果が正しいことも含めます。具体的には、代表荷主の実績を旧Excelや現行の請求と突き合わせ、差異の原因をたどれることを合格条件にします。

  • 突合対象:保管料や入出庫料、ピッキング料や梱包料。流通加工料や配送費の立替・付帯費用も含みます。
  • 業務シナリオ:請求締めと訂正、再計算の流れを、承認から請求書出力まで試験します。
  • 並行稼働:一定期間、現行の計算と比べて、差異の原因をマスタの誤りや取込漏れ、現行運用の例外に分けます。

月次締めを複数回経験してから切り替えると、請求漏れや荷主とのトラブルを抑えやすくなります。

ポイント

料金ルールと例外、実績データの連携、受入基準の三つを、RFPに書けるところまで具体化できているかが判断の目安です。

請負と準委任の選び方

契約形態は、成果物と要件をどこまで確定できるかで選びます。たとえば、要件整理は準委任、仕様が決まった後の開発は請負、稼働後の改善や運用支援は準委任と、工程ごとに分ける方法があります。

契約書に加えて、仕様書と見積条件を一体で確認します。そのうえで、変更の扱いや検収、保守の範囲も決めておきます。

要件定義は準委任、開発は請負に分ける考え方

準委任は、知見や作業の提供を受けながら進める工程に向きます。要件が変わる段階で完成物と金額を固定すると、追加費用や納期の遅れにつながることがあります。

  • 準委任の対象:業務整理や現行調査から、RFP作成や製品比較、プロトタイプ検証まで。
  • 準委任の条件:作業内容と責任者、稼働時間を、会議体や成果記録とあわせて明文化します。
  • 請負の対象:料金マスタや計算処理、CSV・API連携を納品物にし、請求書出力や権限管理も含めます。
  • 変更管理:料金単位、荷主、連携項目の追加を変更要求として扱う条件を決めます。

請負は、合意した仕様どおりにシステムや機能を完成させ、検収まで行う工程の契約です。そのぶん、納品物と受入基準を具体的に決めておく必要があります。

契約書と見積条件で確認する項目

契約と見積もりでは、成果物や納期、検収に加えて、瑕疵対応と再委託の扱いを確かめます。クラウド型では、月額に含む利用者数や荷主数、拠点数、明細数と、超過時の課金も確かめます。

知的財産権やデータの所有権、秘密保持も対象です。障害連絡や保守時間、SLA、終了時のデータ返却も含みます。

  • クラウド費用:月額に含む利用者・荷主・拠点数や明細数と、超過時の課金。
  • 個別開発の保守:環境の監視とセキュリティ、軽微な改修、法改正・料金表変更への対応。
  • アクセス保護:テナント分離や最小権限、多要素認証、通信と保存時の暗号化。
  • 運用管理:操作と料金マスタの変更ログ、バックアップと復旧訓練、委託先のアクセス管理。

料金計算のデータには、荷主名や在庫、出荷実績のほか、作業者や作業時間が含まれる場合があります。また、開発費と保守契約を分けて、月額に含む範囲や追加費用の条件を確認します。

国土交通省は2026年7月7日に、物流分野の倉庫向け情報セキュリティ安全ガイドライン第2版を改訂しました。発注時には、この改訂を踏まえて確認項目を更新する時期です(出典: 国土交通省「物流分野における情報セキュリティ確保に係る安全ガイドライン」、2026年)。

倉庫料金計算システムの費用相場の目安

費用は、標準SaaSと個別開発を分けて見ます。公開料金から確認できるクラウド型の目安は、初期10万〜80万円程度、月額2万5,000〜22万円程度です。

この範囲は、複数の公開料金例をもとにした目安です。荷主・拠点・明細の数や、ハンディの有無によって変わり、データ移行や個別連携でも差が出ます。

クラウド型の初期費用と月額費用

日本倉庫協会が紹介するMPS LOGIの料金は、月1〜5,000明細で6万6,000円、5,001〜10,000明細で11万円です。10,001明細以上の場合は、月額22万円です。

  • 導入支援:初期費用は55万円です。
  • 別オプション:在庫移行やマスタ設定、運用テストのほか、操作教育と本稼働の立会い。
  • 追加単位:荷主または拠点1つごとに、初期11万円・月額1万1,000円の例です。

料金例の出典は、一般社団法人日本倉庫協会の「MPS LOGI」です(掲載料金の確認日は2026年8月)。

月額だけで比べると、明細数や導入支援の違いを見落としやすくなります。そこで、5年間のTCO(総所有コスト)には、初期設定や移行、教育、API接続を含めます。さらに、追加料金や帳票変更、問い合わせ対応も見ます。

CSV加工や手入力が残る場合は、担当者の作業時間や請求ミスのリスクも比べます。

個別開発の費用レンジと期間

倉庫料金計算システム単体の公的な市場平均は確認できないため、次に示す金額は、公開SaaS料金や一般的な業務システムの工数、WMS連携の複雑さをもとにした編集部の推定です。各金額は目安で、要件定義の後に再見積もりします。

  • 小規模構成:300万〜800万円、期間は3〜6か月が目安です。
  • 標準的な3PL向け:800万〜2,000万円、期間は6〜12か月が目安です。
  • 大規模・個別最適型:2,000万〜5,000万円超、12〜18か月かかることもあります。

小規模構成は、1拠点・少数荷主を想定しています。保管料と基本荷役料、CSV入出力、請求書出力を対象に、既存WMSの実績を取り込みます。

標準的な3PL向けは、複数の荷主や拠点、契約単価を扱う構成です。割増や最低料金、月次締めを含みます。さらに、荷主照会やWMS・会計・EDIとの連携、権限・監査ログも入ります。

大規模構成は、複雑な従量課金や温度帯・重量・容積による課金、ハンディやマテハンとの連携を含む場合です。複数会社や多拠点、リアルタイム連携のほか、原価・収益分析まで対象になることもあります。

費用の内訳の分け方

見積書では、要件定義や料金マスタ設計、計算エンジンを工程ごとに分けて示してもらいます。連携や移行、テストも、同じ粒度で書いてもらいます。あわせて、教育や稼働立会い、保守の費用も見えるようにします。

金額が一式の場合は、標準機能と追加機能の区分や移行件数を確認します。テストケース数や修正回数も見ておきます。そのうえで、追加費用になりやすい前提も書き出してもらいます。

ポイント

標準SaaSと個別開発では費用の桁が違うため、まず発注形態を決め、見積もりの範囲をそろえてから比べると、金額の読み違いを減らせます。

委託先の選定と見積比較の確認項目

委託先は、知名度や営業資料より、料金計算の実務を理解し、データの正しさを担保できるかで選びます。

候補には、WMSベンダーや業務システムに強いSI会社、料金計算部分を開発できる専門会社を含めます。

発注側は、各社に同じ実績データとシナリオを渡し、標準機能と設定、追加開発と外部連携を分けた提案を求めます。

物流業務と料金計算の実績の確認

WMSの導入社数だけでなく、料金計算の実務経験を次の観点から確かめます。

  • 請求根拠:保管料や荷役料、流通加工料、配送費の立替・付帯費用を追跡できるか。
  • 業務条件:複数荷主や拠点、温度帯、重量・容積課金の実例。返品や最低保証、手入力調整の扱い。
  • 実装方法:各機能が標準、設定、個別開発のどれに当たるか。

NECのEXPLANNER/Lgは、倉庫管理や基幹・周辺連携を含む大規模SIの候補です。シーネットのci.Himalayas/R2は、入出庫や在庫、棚卸しなどの標準機能を掲げています。請求機能や、EDI・マテハンとの連携も含まれます。

ロジザードZEROや東計電算のAWMSのほか、フレームワークスのLogistics Station iWMS G5、大塚商会のW-KEEPERも比較対象です。また、個別の料金計算が標準機能で賄えるか、アドオンになるかを、提案の段階で確かめます。

相見積もりの同条件比較

合計金額だけでなく、機能の適合や連携、移行・教育、保守を同じ項目で比べます。納期や体制も含めて並べます。評価表の配点は、業務への影響の大きさに応じて決めます。

  • 料金マスタの柔軟性:25点の配点例
  • 実績データ連携:20点の配点例
  • 請求根拠と監査ログ:15点の配点例
  • 導入・並行稼働支援:15点の配点例
  • 拡張性・保守、費用・納期:それぞれ15点、10点の配点例

配点は、自社の優先順位に合わせて変えます。各社の前提は同じ条件にそろえ、月額や明細数、荷主と拠点の追加単価、API数を見ます。さらに、移行件数やハンディ台数、サポート時間と復旧目標も確かめます。

デモでは、入庫から在庫、出庫、作業、締め処理、請求訂正までを通しで実演してもらいます。加えて、導入後のプロジェクト責任者や物流業務の担当、連携担当、保守窓口も確認します。

発注後に起こりやすいリスクと対策

発注後の失敗を抑えるには、要件とデータ、制度対応を早めに確かめておく必要があります。特に要件の漏れは、料金表の未整理や責任の境目の不足、現場の例外の抜けから起きやすいため、発注前に防いでおきます。

  • 要件の漏れ:料金表の未整理や責任の境目の不足、現場の例外の漏れを防ぎます。
  • 移行の遅れ:代表荷主の過去データで計算サンプルを作り、入力と明細、差異の扱いを合意します。
  • 追加開発:機能の優先度と、稼働後の対応期限を付けます。

2026年4月からは、一定規模以上の荷主や物流事業者を対象に、中長期計画や定期報告などの措置が実施される制度もあります。そのため、物流効率化法を意識する企業は、入出荷量や荷待ち・荷役の実績を後から集計できるデータ設計にします。

積載や作業の状況も集計できれば、業務改善と報告に活用しやすくなります(出典: 国土交通省「物流効率化法」理解促進ポータル、2026年)。ただし、システムを入れただけで法令への適合が保証されるわけではないため、対象範囲と社内の運用は別途確かめる必要があります。

ポイント

料金計算の実務を理解し、請求根拠を追える会社かどうかを、同じ実績データと条件で出させた見積もりを並べて判断します。

発注から稼働までの進め方と期間

企画・現状分析から並行稼働・本番切替・安定化までの4段階を矢印でつないだ工程図。
後半にテストと並行稼働を置き、切替までの流れを確認できます。

工程は企画と現状分析から始まり、RFPと提案の比較、要件定義へと進みます。その後は設計・開発、移行・テストを経て、並行稼働と本番切替、安定化に進みます。

小規模なクラウド導入は、数か月で始められる場合があります。一方で、複数拠点や荷主を対象にした個別開発では、テストと並行稼働を含めて6〜18か月程度かかることがあります。

期間は機能の数に加え、料金ルールの整理や連携、移行の難しさで左右されます。

発注側のプロジェクト体制

発注側には、意思決定者と物流業務の責任者を置き、請求・経理の担当者や現場代表、情報システム担当も加えます。荷主との調整担当も必要です。

  • 業務の決定:料金マスタの決定者と、請求締めの承認者を明確にします。
  • 定例会議:課題や仕様変更、未確定のルールを記録します。連携エラーや移行件数、テスト結果、リスクや決定事項も含めます。

開発会社だけで料金表を決めると、現場の例外や契約条件が抜けることがあります。一方で、要望をすべて個別機能にすると保守が難しくなるため、標準化する業務と例外として残すものを分けて決めます。

発注側は、AIによる需要予測や作業の最適化を加える場合も、提案をそのまま請求や現場指示に反映させず、人が承認し、根拠データを追えるようにしておきます。

本稼働後の保守と改善の見積もり

料金表や荷主・拠点、請求書の様式は、稼働後に変わります。外部システムや制度、セキュリティ要件も変わるため、保守範囲と効果測定を前もって決めておきます。

  • 保守範囲:障害対応やマスタ登録、軽微な帳票変更を含みます。利用状況の確認や復旧テスト、脆弱性対応も範囲に入れます。
  • 効果指標:集計時間、請求漏れ・二重計上・単価ミス、根拠照会の回答時間。
  • 業務改善:未請求・低採算作業の発見数、荷主・拠点追加の日数も測ります。

導入後は3か月、6か月、12か月の節目でKPIを確認し、料金計算エンジンを業務改善の基盤として育てていきます。

よくある質問

発注では費用だけでなく、現行業務の整理と導入後の運用も確かめておきます。よくある疑問を、順に取り上げます。

倉庫料金計算システムはSaaSと個別開発のどちらがよいですか?

標準的な保管や入出庫、請求を早く始めたい場合は、SaaSが候補になります。複雑な料金式や基幹連携を競争力にしたい場合は、個別開発が選択肢です。

代表荷主の実績でSaaSの標準機能を検証し、不足する部分だけアドオンで補う段階導入も現実的です。

見積もりを取る前に何を準備すればよいですか?

荷主や拠点ごとの料金表と締め日、保管料や荷役料の単位を整理します。割増や割引、最低請求、返品や流通加工などの例外も、あわせてまとめておきます。

過去3か月分の実績と現行の請求書、Excelを用意し、WMSや会計、配送会社との連携対象も整理します。利用者と権限、移行データ、稼働希望時期も準備します。そうすると、各社が同じ条件で見積もりを出せます。

倉庫料金計算システムの費用を抑える方法はありますか?

まずは対象の拠点と代表荷主を絞り、標準SaaSやパッケージの設定を優先します。全荷主と全例外を一度に個別開発する形は避けます。

発注側は、請求根拠に直結する保管料・荷役料・締め処理を先に整え、分析や高度な自動化は第2段階に分けます。

移行やテスト、教育、保守を削りすぎると、稼働後の手作業が増えます。そのため、初期費用だけで判断しないようにします。

発注後に料金表が変わったらどうすればよいですか?

料金表はソースコードに埋め込まず、料金マスタで管理します。料金マスタには荷主や契約、単価を持たせ、適用期間と承認履歴も残します。

変更の申請と承認、適用開始日を決めておきます。過去の請求への影響や再計算の可否も決めておけば、単価変更の後も請求根拠を説明できます。

マスタ項目の追加や計算式の変更を保守の範囲で扱うか、追加開発とするかは、契約時に確かめます。

まとめ

製品名や初期費用だけでなく、料金ルールと実績データ、請求根拠を一つの業務として整理します。例外処理や保守も、同じ流れで扱います。

クラウドWMSやパッケージ+カスタマイズ、スクラッチ開発は、企業規模や運用条件に応じて選びます。

発注前に決めておく事項

代表荷主2〜3社の過去実績を用意して、保管料や荷役料、付帯費用の計算サンプルを作ります。

RFPには、標準機能と追加開発の区分や、WMS・会計・EDIとの連携を書きます。移行やテストと並行稼働、権限・監査ログ、保守も記載します。

見積比較では、初期費用や月額だけでなく、明細数や荷主・拠点の追加まで見ます。教育や障害対応、5年間のTCOも、同じ条件で比べます。

最初の一歩は現行業務の洗い出し

まずは開発会社へ委託する前に、料金表やExcel、請求書、WMS・会計データを集めます。そのうえで、手作業の計算と問題になっている差異を整理します。

資料をもとにRFPを作り、物流業務と料金計算の両方を理解する委託先に相談すると、不要な機能や個別開発を減らせます。

▼全体ガイドの記事
・倉庫料金計算システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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