WMSのリアーキテクチャにおけるフルスクラッチ・オーダーメイド開発は、既存のWMSを一から作り直す選択肢で、その中核は次の設計にあります。
- モノリシックな既存WMSをドメインごとに分解するマイクロサービスアーキテクチャ
- ドメイン駆動設計（DDD）
- API-first設計
採用には明確な条件があり、費用、規模、開発会社の選び方を合わせて見る必要があります。
▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMSのリアーキテクチャにおけるフルスクラッチの位置づけ
フルスクラッチを検討するなら、隣接する記事群で扱うフルスクラッチとの違いを、先に押さえておく必要があります。
AWSの「7Rs」モデルでは、この選択肢は「Rearchitect（リアーキテクト）」に当たり、実装複雑度は「非常に高い（Very High）」、コストは「最高額」に分類されます。実装の難度もコストも高いため、採用するかどうかは条件で見極める必要があります。
WMSのモダナイゼーション（リビルド全般）との違い
「WMSのモダナイゼーション」が扱うフルスクラッチは、5つの技術的アプローチのうち「リビルド」に当たります。既存のロケーションマスタや在庫データを引き継ぎながら、老朽化したロジックを根本から作り直します。独自ロジックの完全再現に主眼を置いている点が特徴です。
一方で、ここで扱うリアーキテクチャのフルスクラッチは、そのリビルドのなかでも一段踏み込みます。マイクロサービスを採用するかどうか、DDDでドメイン境界をどう切るか、API-first設計でフロントとバックエンドの並行開発をどう実現するかという、アーキテクチャ上の設計選択に焦点を当てます。
マテハン機器連携や特殊な引当ロジックがあるためにリビルドを選ぶ判断は、モダナイゼーションの記事で扱われます。そのうえで、リビルドを選んだあとに「どんな構造で作るのか」を決める段階が、この論点の役割です。
WMS刷新・WMS更改・WMSのリニューアルとの違い
WMS刷新は、そもそもフルスクラッチに踏み切るかという経営判断とROI試算を中心に考えます。WMS更改は、EOS/EOLという期限のなかで、フルスクラッチが現実的な選択肢になるかを逆算する場面です。WMSのリニューアルでは、画面デザインをフルスクラッチで作り込むかテンプレートを使うかという、体験面の判断が中心になります。
これらに対して、ここで扱うリアーキテクチャのフルスクラッチは、経営判断、期限、デザインとは独立した論点です。マイクロサービス化、DDD、API-firstという技術選択を採用するための、組織的・技術的な条件を扱います。
経営層が刷新を決め、更改の期限が定まったあとに、アーキテクトが実際に技術選定を行う場面で、この論点が直接必要になります。
マイクロサービスアーキテクチャで一から作り直す場合の費用感
Kubernetesなどのコンテナオーケストレーション、サービスメッシュ、分散トレーシングといったクラウドネイティブ基盤を、ゼロから構築することになります。そのため、初期投資は極めて高額になります。
初期投資40%増と「マイクロサービス税」
従来のモノリシックなシステム開発と比べると、分散インフラの構築や高度なツールの導入により、初期投資は40%高くなるとされています。加えて、稼働後のランニングコストにも「マイクロサービス税」と呼ぶべき負担が乗ります。
たとえば、サービスメッシュ（Istioなど）を導入すると、コンポーネント間の通信を制御するために各サービスにプロキシが付随し、プロキシ1つあたり50〜100MBのメモリと100〜200mのCPUを消費します。数百のサービスが稼働するWMS環境では、クラスター全体で25〜50GBもの追加メモリが必要になり、クラウド費用を直接押し上げます。
また、分散トレーシングや集中ログ管理による監視が複雑になり、運用オーバーヘッドも40〜50%増えます。そのため、この増加分をフルスクラッチの予算計画に織り込んでおく必要があります。
TCOと投資回収期間の考え方
一方で、FinOpsを適切に運用すれば、セール時などに高負荷となる機能（ピッキングや在庫引当など）だけを独立してスケーリングできます。こうして無駄なリソースを削れば、長期的にはコストを抑えられます。
業界標準として、モダナイゼーション成功時のTCO（総所有コスト）削減効果は20〜45%とされ、初期の追加投資は12〜36ヶ月（1〜3年）で回収（ペイバック）できると見込まれます。
そのため、フルスクラッチを検討するときは、初期投資の額だけで判断せず、稼働後のスケーリング効果まで含めた複数年のTCOで投資対効果を評価することが不可欠です。経営層への説明にも、実務上の判断にも、この見方が求められます。
DDD採用を判断すべき条件
DDDは、「ロケーション管理」「ピッキング」「入出庫」といったWMSのドメイン境界を厳密に設計する手法で、マイクロサービス化には欠かせません。ただし、採用すべき明確な閾値が存在します。
Go/No-Goライン（トラフィック規模と組織規模）
1日のリクエスト数が100万回以上で、かつ開発組織に50名以上のエンジニアがいる状態は、DDDとマイクロサービス化が確実に利益をもたらす損益分岐点とされています。
どちらか片方だけでは足りず、両方が揃って初めてフルマイクロサービス化への投資が正当化される点に注意が必要です。
トラフィックは多いがエンジニアが少ない企業では、分割によって生まれる運用の複雑さを支えきれません。逆に、エンジニアは多いがトラフィックが少ない企業では、分割で得られるスケーラビリティのメリットを活かす場面そのものがありません。
見送るべき条件とモジュラーモノリスという代替
エンジニアチームが15〜20名未満の規模である場合、実装難易度の高いDDD（実装複雑度High）の専門知識の習得や、分散インフラの維持管理にリソースを取られるリスクが高まります。
境界設計を誤ると、コード修正のたびに全サービスをデプロイし直す「分散モノリス」という最悪のアンチパターンに陥ります。そのため、この規模では、DDDによる完全な物理分割は見送り、単一のコードベース内でドメインごとに論理的な境界を分けた「モジュラーモノリス」にとどめるべきです。
モジュラーモノリスでも、DDDによるドメインモデリングの考え方は活かせます。そのため、トラフィックとエンジニア規模がGo/No-Goラインを超えた段階で、モジュールをそのままマイクロサービスへ切り出す、段階的な移行の道を残せます。
API-first設計を採用する開発会社選定のポイント
API-first設計は、バックエンドの実装前にAPIの「契約（コントラクト）」を定めておく手法です。これにより、WMSと、ハンディターミナルやECサイト、ERPといったフロントの並行開発が可能になります。
開発会社を選ぶときは、API-firstを実際に運用できる実績と能力があるかを見極める必要があります。
コントラクト駆動開発の習熟度
設計ツールやモックサーバー（Prismなど）を使い、APIの仕様書を単なるドキュメントにとどめず、自動テスト（コントラクトテスト）としてCI/CDパイプラインに組み込めるかどうかが問われます。この力の有無が、選定の大きな判断材料になります。
API仕様が変わったとき、その変更が既存の連携先（マテハン制御システムやハンディターミナルアプリなど）に破壊的な影響を与えないかを自動で検知できる体制があるか、提案の段階で具体的に確認しておく必要があります。
ドキュメントとしての仕様書だけを納品する会社と、コントラクトテストまで運用に組み込める会社とでは、特に稼働後の保守性に大きな差が生まれます。
並行開発マネジメント能力
API-firstの最大のメリットは、統合が3.9倍、変更が5.6倍高速化する点にあるとされています。
この効果を得るには、WMSのバックエンド（サーバー側）の完成を待たずに、マテハン制御側の開発チームやUIチームが仕様のズレなく並行して進められる体制を、開発会社がリードできるかどうかが問われます。
過去のプロジェクトで複数チームが同時並行で開発を進めた実績があるか、API仕様の変更をどんなプロセスで管理しているかを、具体的にヒアリングする必要があります。単に技術力があるだけでなく、複数チームをまたぐプロジェクトマネジメント能力を備えているかを見極めます。
マテハン機器連携基盤を含めた規模別費用と進め方
自動倉庫やピッキングロボットから、ミリ秒単位の大量のストリームデータが発生します。これを処理する基盤の構築は、プロジェクト予算の大部分を占める最難関の領域です。
データ・エッジ基盤への先行投資というセオリー
すべてのセンサーデータをクラウドに送ると、遅延や帯域幅のコストが膨大になります。そのため、現場側に「エッジコンピューティング基盤」を構築し、Kafkaなどを使った非同期のイベント駆動アーキテクチャを採用します。ただし、この実装複雑度はHigh〜Very Highに分類される高難度の領域です。
WMSやTMSにおける配車最適化やマテハン連携などの事例では、プロジェクト全体の予算やリソースの40〜60%を「初期のデータクレンジングと基盤整備」に先行投資するのが、成功のセオリーとされています。
逆に、アプリケーション機能の開発に予算を偏らせ、この土台への投資を後回しにすると、稼働直前にマテハン機器との連携が計画どおりに動かないという、致命的な事態を招きかねません。
規模別費用とSRE体制の継続コスト
Kafkaのメッセージブローカー運用、冪等性やSagaパターン（結果整合性・補償トランザクション）の実装、Kubernetesの維持管理には、高度なSRE（サイト信頼性エンジニア）が欠かせません。
インフラ運用を担うSRE人材の市場相場は月額80万〜130万円程度です。そのため、専任のプラットフォームチーム（数名規模）を維持する継続的なランニングコストを、中長期のP&L（損益計算）に組み込んでおく必要があります。
WMSのフルスクラッチによるマイクロサービス化が真価（ROI150%以上のスケールメリット）を発揮するのは、組織規模（50名以上の開発者）とトラフィック（100万リクエスト/日以上）の条件を満たす場合に限られます。条件を満たさない場合は、既存のERPやSaaSを組み合わせるコンポーザブルアプローチや、モジュラーモノリスでの段階的なリファクタリングを検討するとよいでしょう。
まとめ
WMSのリアーキテクチャにおけるフルスクラッチ・オーダーメイド開発は、リビルド全般とは異なる位置づけにあります。費用感、DDD採用の条件、開発会社の選び方、規模別の費用と進め方を見てきました。
初期投資はモノリス比で40%高く、マイクロサービス税による運用オーバーヘッドの増加もあります。ただし、適切な設計とFinOps運用のもとでは、TCO全体で20〜45%削減し、12〜36ヶ月で投資を回収できると見込まれます。
「1日100万リクエスト以上」「エンジニア50名以上」というGo/No-Goラインを満たさない場合はモジュラーモノリスにとどめるのが安全です。満たす場合は、DDD・API-first設計・エッジ/IoT連携基盤の実装実績が豊富な開発会社を選ぶことが、WMSのリアーキテクチャを成功させる鍵です。
まずは自社のトラフィック規模とエンジニア体制を客観的に評価し、複数の開発会社に相談することをお勧めします。
▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。