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

倉庫料金計算システムの発注・外注では、保管料や荷役料を計算できるだけでなく、WMSの実績から請求根拠を再現できる仕組みを選ぶことが重要です。

本記事では、倉庫会社や3PL、メーカー・小売の物流部門が、倉庫料金計算システムをどのような形で委託し、何をRFPに書き、どの契約・予算・比較基準で発注すればよいかを解説します。標準SaaS、パッケージのカスタマイズ、スクラッチ開発を比較しながら、2026年時点で確認できる公開料金と、要件に応じた個別開発の推定レンジも紹介します。

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

倉庫料金計算システムを発注・外注する前に知っておきたい全体像

倉庫料金計算システムは、単独の請求ソフトというより、入庫・出庫・在庫・作業実績を持つWMSと請求・債権管理をつなぐ業務基盤です。発注時に請求書の見た目だけを決めると、後から実績データや料金マスタの不足が判明し、Excel補正が残ってしまいます。最初に「何を計算するか」だけでなく、「どの実績を根拠に、誰が、どのタイミングで承認するか」まで決める必要があります。

荷主ごとに料金表、締め日、請求単位、最低保証額、割増条件が違う企業ほど、専用の料金計算機能が役立ちます。たとえば、常温・冷蔵・冷凍で保管単価が異なる倉庫、パレット・ケース・バラ・重量・容積を使い分ける3PL、返品や流通加工を個別請求する倉庫では、担当者の経験に依存したExcel管理が破綻しやすいです。自社倉庫だけを運営する企業でも、拠点数や作業種類が増え、月末集計と会計連携に時間がかかる場合は導入検討の対象です。

外注範囲は、要件定義だけ、製品導入だけ、料金計算エンジンの開発だけ、WMS・会計・請求書発行まで含む一括導入などに分けて考えます。社内に物流業務の知識はあるもののシステム化の経験が少ない場合は、業務整理とRFP作成を支援会社に委託し、製品選定と契約は自社で行う方法もあります。一方、複数荷主の料金表を自社の競争力に直結させたい場合は、要件定義から稼働後の保守まで同じ会社に委託し、料金ロジックの責任分界を明確にする方法が適しています。

倉庫料金計算システムの発注形態はどれを選ぶべきですか？

発注形態の結論は、料金表の複雑さ、拠点・荷主数、既存WMSの有無、社内で持てる運用体制で決まります。短期間で標準業務を始めるならクラウドWMS、標準機能を活かしながら独自の料金式を追加するならパッケージ＋カスタマイズ、料金計算と基幹連携を競争力として作り込むならスクラッチ開発が候補です。

クラウドWMSは、サーバー調達やバージョンアップを自社で抱えずに、在庫・入出庫・請求機能を早く使い始めやすい選択肢です。拠点追加や利用者追加の費用、月間明細数の上限、CSV・API連携の可否を契約前に確認します。公開料金の例では、クラークは基本機能が初期8万円・月額2万5,000円、請求機能が月額2万円、全機能を使うEnterprise版が初期8万円・月額8万円で、導入支援は初期30万円です。これは一社の公式料金例であり、倉庫料金計算システム全体の相場ではありません（出典: クラーク公式料金ページ、2026年8月確認）。

パッケージ導入は、物流業務の標準機能と導入ノウハウを利用しながら、料金表や外部連携だけを追加開発できる点が特徴です。標準機能、設定で対応する部分、アドオン開発する部分、別システムに残す部分を分けると、過剰なカスタマイズを防げます。デモでは、入庫実績の取込、日々の在庫、月末締め、返品、最低請求額、請求訂正、荷主向け明細照会までを実データに近いシナリオで見せてもらう必要があります。

スクラッチ開発は、荷主別の複雑な契約条件、独自の原価配賦、複数会社の請求、リアルタイムの基幹連携などを自社業務に合わせて設計しやすい方法です。その反面、料金ロジックの仕様変更、障害対応、開発会社の交代、OSやクラウドの更新まで自社の管理対象になります。料金計算エンジンをWMSから分離し、実績を受け取り、計算結果・明細・エラー・承認履歴を返す構成にすると、将来のWMS入れ替えや料金表変更に対応しやすくなります。

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

RFPは、機能の希望を書き並べる資料ではなく、各社が同じ条件で提案・見積できる発注条件書です。料金計算の対象、入力元、計算タイミング、例外、出力、移行、体制、保守を一つの流れで書きます。特に、代表荷主2〜3社の過去3か月分の実績を用意し、新旧計算結果を突合できる形にすることが、見積精度と導入後の品質を高めます。

最初に料金マスタを、荷主、契約、倉庫、温度帯、商品区分、作業区分、単位、適用期間、税区分に分けて棚卸しします。保管料は月末在庫か日次平均在庫か、入庫日・出庫日のどちらを基準にするか、最低保証量や月途中の入出庫をどう扱うかを明記します。荷役料は入荷、検品、棚入れ、出庫、ピッキング、梱包、返品、棚卸し、ラベル発行などの作業と、ケース・バラ・重量・作業時間などの課金単位を紐付けます。

例外処理は、通常料金よりも先に確認したい項目です。最低請求額、割増・割引、緊急作業、資材費、再配達、返品、廃棄、個別の手入力調整を、誰がどの権限で登録し、承認後にどのような履歴を残すかを決めます。計算式を変更した際に、変更前後の差額と承認者を確認できなければ、荷主から請求根拠を問われたときに説明できません。

料金計算は入力データが正しくなければ成立しません。WMSの在庫・入出庫・作業実績、販売管理・会計・請求書発行、EC・OMS、EDI、配送会社データのどれを正とするかを決め、CSVかAPIか、連携頻度、再取込、エラー時の再実行方法までRFPに書きます。APIが使えない既存システムでも、CSVの項目定義、文字コード、日付形式、重複判定キー、取込後の照合結果を決めれば、属人的な転記を減らせます。

荷主向けには、在庫・作業・請求明細をWebで照会できるか、請求書と明細の粒度を揃えられるかを確認します。管理者向けには、未請求、赤字作業、荷主別粗利、保管効率、作業生産性を分析できるデータを残します。これらは請求業務の効率化だけでなく、料金表の見直しと収益管理にも使われます。

受入基準には、画面が表示されることだけでなく、計算結果が正しいことを含めます。代表荷主の実績について、保管料、入出庫料、ピッキング料、梱包料、流通加工料、配送費の立替・付帯費用を旧Excelや現行請求と突合し、差異が出た場合に原因を追跡できる状態を合格条件にします。請求の締め処理、訂正、再計算、承認、請求書出力までを一つの業務シナリオとして試験します。

本稼働前は、一定期間の並行稼働を設定し、システム計算と現行計算を比較します。差異の理由が料金マスタの誤りなのか、実績取込の欠落なのか、現行運用の例外なのかを分類し、業務側が説明できる状態にします。新システムの結果を一度見ただけで切り替えるのではなく、月次締めを複数回経験してから切り替える方が、請求漏れや荷主とのトラブルを抑えやすいです。

契約形態は請負と準委任のどちらが適していますか？

契約形態は、成果物と要件をどこまで確定できるかで選びます。すべてを一つの契約に押し込むより、要件整理・企画は準委任、仕様確定後の開発は請負、稼働後の改善や運用支援は準委任というように、工程ごとに分ける方が実態に合いやすいです。契約書だけでなく、仕様書、見積条件、変更管理、検収、保守範囲を一体で確認します。

準委任は、担当者の知見や作業の提供を受けながら、業務整理、現行調査、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か月が一つの目安です。1拠点、少数荷主、保管料と基本荷役料、CSV入出力、請求書出力を対象にし、既存WMSの実績を取り込むケースを想定しています。

標準的な3PL向けは800万〜2,000万円、6〜12か月が目安です。複数荷主・複数拠点、契約単価、割増、最低料金、月次締め、荷主向け照会、WMS・会計・EDI連携、権限・監査ログを含む構成です。大規模・個別最適型は2,000万〜5,000万円超、12〜18か月になる可能性があります。複雑な従量課金、温度帯・重量・容積、ハンディやマテハン、複数会社・多拠点、リアルタイム連携、原価・収益分析を含む場合です。これらは確定見積ではなく、要件定義後に再見積もりする推定レンジです。

見積書では、要件定義・業務整理、料金マスタ設計、画面・帳票、計算エンジン、API・CSV連携、データ移行、テスト、現場教育、稼働立会い、保守を分けて記載してもらいます。金額が一式だけの場合は、どの機能が標準で、どこからが追加か、データ移行の対象件数、テストケース数、修正回数を確認します。見積の安さだけでなく、あとから追加費用になりやすい前提条件を見える化することが重要です。

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

委託先は、知名度や営業資料の見栄えではなく、料金計算の実務を理解し、データの正しさを担保できるかで選びます。比較対象には、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の本数、データ移行件数、ハンディ台数、サポート時間、障害時の復旧目標を揃えます。提案デモでは、入庫から在庫、出庫、作業、締め処理、請求訂正までを一度に実演してもらいます。営業担当の説明だけで判断せず、導入後に対応するプロジェクト責任者、物流業務担当、連携担当、保守窓口が誰かを確認します。

よくある失敗は、料金表を整理しないまま製品を決めること、既存WMSと請求システムの責任分界を決めないこと、データ移行を最後に回すこと、現場の例外を要件に入れないことです。対策として、代表荷主の過去データを使った計算サンプルを先に作り、料金マスタ、入力データ、出力明細、差異の扱いを合意します。追加開発が必要な機能には、優先度と稼働後対応の期限を付けます。

2026年4月からは、一定規模以上の荷主・物流事業者に中長期計画や定期報告などの措置が実施される制度もあります。物流効率化法の対応を意識する企業は、入出荷量、荷待ち・荷役に関する実績、積載や作業の状況を後から集計できるデータ設計にしておくと、業務改善と報告に活用しやすいです（出典: 国土交通省「物流効率化法」理解促進ポータル、2026年）。法令への適合をシステム導入だけで保証できるわけではないため、対象範囲と社内運用は別途確認します。

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

発注から本稼働までは、企画・現状分析、RFP・提案比較、要件定義、設計・開発、データ移行・テスト、並行稼働、本番切り替え、安定化の順に進めます。小規模なクラウド導入なら数か月で開始できる場合がありますが、複数拠点・複数荷主の個別開発では、テストと並行稼働を含めて6〜18か月程度を見込むことがあります。期間は機能数よりも、料金ルールの整理と連携・移行の難しさに左右されます。

発注側には、意思決定者、物流業務責任者、請求・経理担当、現場代表、情報システム担当、荷主との調整担当を置きます。システム会社だけで料金表を決めると、現場の例外や荷主との契約条件が抜けます。反対に現場の要望をすべて個別機能にすると、保守できない仕組みになるため、標準化する業務と残す例外をプロジェクト内で決めます。

定例会議では、課題一覧、仕様変更、未確定の料金ルール、連携エラー、データ移行件数、テスト結果、リスクと意思決定を記録します。特に料金マスタの決定者と、請求締めを承認する責任者を明確にします。AIによる需要予測や作業最適化を追加する場合も、AIの提案をそのまま請求や現場指示へ反映せず、人による承認と根拠データの追跡を残します。

稼働後は、料金表の改定、新しい荷主・拠点の追加、請求書様式の変更、外部システムの仕様変更、制度やセキュリティ要件の更新が起こります。保守契約では、障害対応だけでなく、マスタ登録支援、軽微な帳票変更、月次の利用状況確認、バックアップ・復旧テスト、脆弱性対応をどこまで含むか確認します。

導入効果は、月末集計時間だけでなく、請求漏れ・二重計上・単価適用ミスの件数、請求根拠の照会に答える時間、未請求や低採算作業の発見数、荷主・拠点追加に必要な日数で測ります。導入後3か月、6か月、12か月の時点でKPIを確認し、料金計算エンジンを業務改善の基盤として育てることが大切です。

よくある質問

倉庫料金計算システムの発注では、費用だけでなく、現行業務の整理と導入後の運用を含めて確認することが大切です。ここでは、発注前によく寄せられる質問に直接回答します。

標準的な保管・入出庫・請求で早く始めたいなら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実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

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