WMSのリアーキテクチャの選定ポイント/選び方/種類

WMSのリアーキテクチャを検討し始めると、リファクタリングでモジュラーモノリス化にとどめるべきか、思い切ってマイクロサービスへ分解すべきか、判断に迷う情報システム部門は少なくありません。自社のリクエスト量とエンジニア体制、マテハン機器との連携要求を踏まえて技術的な選択肢を絞り込み、PoCで検証したうえで進め方を決めることが、WMSリアーキテクチャの選定における基本的な考え方です。

本記事では、着手前に整理すべき自社の課題、リアーキテクチャの3つの進め方、組織規模とコスト構造による評価軸、開発体制やベンダーの選び方、PoCでの検証項目を順に解説します。これから自社のWMSリアーキテクチャ計画を具体化する担当者の方が、比較検討の軸をそろえられる内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド

着手前に整理すべき自社の課題

リアーキテクチャの進め方を選ぶ前に、まず自社のWMSがどのような技術的な限界に直面しているのかを具体的に把握する必要があります。リクエスト量やエンジニア体制、マテハン機器との連携要求という観点から現状を整理すると、選ぶべきアプローチが見えやすくなります。

課題の整理を後回しにしたまま製品や技術トレンドの比較から入ると、自社の業務規模に見合わない過剰な分散システムを選んでしまったり、逆に将来のマテハン機器増設を想定しない設計を選んでしまったりします。まずは現状のシステム構成、開発体制、繁忙期のピーク負荷を数値で洗い出し、その後に進め方の選択肢を検討する順番を守ることが、選定の精度を高めるうえで欠かせません。

1日あたりのピーク時リクエスト数、現在のエンジニア体制の人数、リリース頻度といった数値を洗い出します。目安として、1日100万リクエスト以上の処理量とエンジニア50名以上の開発体制が、完全なマイクロサービス化を正当化するラインとして語られており、これに満たない場合は、まずモジュラーモノリスへの整理を軸にする方が現実的です。

リクエスト量が少なくても、特定のセール時期やマテハン機器の稼働ピーク時にだけ負荷が集中する場合は、そのピーク時の実測値をもとに判断することが重要です。平常時の平均値だけで判断すると、繁忙期の負荷に耐えられない設計を選んでしまう可能性があります。

自動倉庫やピッキングロボットとの連携において、どの程度の応答速度が求められているかを確認します。ミリ秒単位の応答が必要な工程があるかどうかで、エッジコンピューティングやイベント駆動型メッセージング基盤への投資の必要性が大きく変わります。

現時点でマテハン機器との連携がなくても、将来的に自動化設備の導入を計画している場合は、その計画も含めてリアーキテクチャの範囲を検討することが望ましいといえます。後から連携基盤だけを追加しようとすると、既存のアーキテクチャとの整合性を取るための追加工数が発生しやすくなります。

WMSリアーキテクチャの3つの進め方

WMSのリアーキテクチャには、大きく分けてモジュラーモノリス型、マイクロサービス型、両者を組み合わせたハイブリッド型という3つの進め方があります。それぞれ複雑度とスピード、必要な体制が異なるため、自社の状況に合わせて選び分けます。

外部から見た挙動を変えずに、在庫、ピッキング、入出庫といった機能をモジュール単位で明確に分離しつつ、デプロイの単位は一つにまとめる進め方です。インフラ構築のオーバーヘッドが少なく、手戻りのリスクも比較的小さいため、エンジニア体制が限られる企業でもMVPフェーズの範囲内で価値を提供しやすい方法です。

この進め方は、既存のWMSに大きな不満がなく、まずは技術的負債を整理してから将来の拡張性を確保したい企業に向いています。ただし、モジュール間の境界があいまいなまま進めると、後からマイクロサービスへ移行する際に再度設計をやり直す必要が生じるため、モジュール分割の段階からドメインの境界を意識しておくことが望ましいといえます。

コンテナオーケストレーションやサービスメッシュ、分散トレーシングをゼロから構築し、機能ごとに独立してデプロイ・スケールできるサービスへ分解する進め方です。実装複雑度は非常に高く、初期投資もモジュラーモノリス型より大きくなりますが、リクエスト量とエンジニア体制が一定規模を超える場合には、スケーラビリティの面で優位性を発揮します。

この進め方を選ぶ場合は、Kubernetesの運用経験や分散システムのトラブルシューティングに慣れたエンジニアの確保が前提になります。社内にそうした人材が少ない場合は、外部パートナーと共同でSRE体制を構築するか、段階的に内製化を進める計画をあわせて検討する必要があります。

安定して稼働するロケーション管理や在庫のようなドメインはモジュラーモノリスやコンテナ上に残し、マテハン機器連携のように負荷が突発的に集中する部分だけをマイクロサービスとして切り出す進め方です。全体を一度に作り替えるリスクを避けながら、負荷の高い部分から段階的にリアーキテクチャの効果を得られる点が特徴です。

この進め方では、どのドメインを安定領域とし、どのドメインを高負荷領域として切り出すかの線引きが最も重要な設計判断になります。線引きを誤ると、切り出したサービスと残されたモノリスの間で不要な同期処理が増え、かえって複雑さが増す結果にもなりかねません。

組織規模・トラフィックによる選定基準

進め方を選ぶ最初の評価軸は、組織の開発体制とシステムが処理するトラフィックの規模です。この軸を明確にしておくと、後続のコストやPoCの検討範囲も絞り込みやすくなります。

エンジニア体制が50名を超え、1日あたりのリクエスト数が100万件を超える規模になると、完全なマイクロサービス化によるスケーラビリティの向上が投資に見合う効果を発揮しやすくなるとされています。逆にこの水準に届かない場合、分散システムの運用オーバーヘッドの方が上回りやすく、モジュラーモノリスの方が適していることが多くなります。

エンジニア体制が15〜20名に満たない段階でDDDによる物理的なサービス分割を急ぐと、境界設計を保守しきれず「分散モノリス」に陥るリスクが高まります。この規模のチームでは、まずモジュラーモノリスとして内部構造を整理し、マテハン連携基盤など特に負荷が集中する部分だけをピンポイントで切り出す方が、現実的な選択とされています。

コスト構造とTCOの評価軸

リアーキテクチャの投資判断では、初期費用だけでなく、稼働後の運用コストまで含めた総保有コスト(TCO)で比較することが欠かせません。特にマイクロサービス化には、継続的にかかる「マイクロサービス税」と呼ばれる運用コストの増加が伴います。

分散トレーシングや集中ログ管理といった監視の仕組みを導入すると、モノリスと比較して監視の複雑さや運用オーバーヘッドが大きく増加するとされています。サービスメッシュを構成するプロキシやコントロールプレーンのメモリ消費も無視できず、サービス数が数百単位に達する規模では、軽量な構成と比べて相応に多くのクラウド費用がかかる可能性があります。

SRE人材の相場は月額80万〜130万円程度とされており、エンジニア体制が10〜15名に満たないチームでは、こうした専任の運用体制を維持するコストがメリットを上回りやすい点にも注意が必要です。

マイクロサービス化の初期投資は、モジュラーモノリス化と比較して大きくなる傾向がありますが、稼働後は必要な機能だけを個別にスケーリングできるため、インフラ利用コストを一定程度削減できる可能性があります。適切なドメイン設計とFinOpsの取り組みを組み合わせれば、TCO全体を中長期的に圧縮し、12〜36ヶ月程度で投資を回収できるという整理も見られます。

ただし、境界設計を誤って分散モノリス化してしまうと、この回収効果は得られず、むしろコストが肥大化します。TCOの試算は理想的な設計ができた場合の数値であることを前提に、境界設計の検証にかけるコストも含めて予算化することが重要です。

開発体制・ベンダー選定の評価軸

リアーキテクチャを外部パートナーと進める場合、機能や実績の説明だけでなく、並行開発の進め方やドメイン設計のファシリテーション能力まで含めて比較する必要があります。

候補となる開発会社が、Prismのようなモックサーバーを使ったコントラクト駆動開発をどの程度実務で運用しているか、コントラクトテストをCI/CDに組み込めるかを確認します。バックエンドの完成を待たずにマテハン制御やUI開発を並行して進められる体制があるかどうかは、開発期間に大きく影響します。

また、コントラクトの変更履歴をどのように管理し、破壊的な変更が発生した際に関係チームへどう周知しているかも確認しておくべき点です。API仕様の変更管理が属人化していると、マテハン制御側の実装が古い仕様のまま進んでしまうリスクがあります。

境界づけられたコンテキストの設計は、技術力だけでなく、現場担当者を巻き込んだイベントストーミングをどれだけ効果的に進行できるかに左右されます。過去にドメイン駆動設計を用いたプロジェクトでどのような境界設計を行い、分散モノリス化を避けられたかを、具体的な事例とともに確認することが望ましいといえます。

あわせて、境界設計の合意形成にかかった期間や、実装着手後に境界を引き直した回数といった実績を尋ねることで、提案書だけでは分からない実務対応力を推し量ることができます。倉庫の現場担当者を巻き込んだワークショップを何度開催し、どのように合意形成を進めたかという具体的な進行手順も、比較のポイントになります。

PoCでの検証項目と進め方

リアーキテクチャの成否は、パイロットフェーズでの技術検証に大きく左右されます。ドメイン境界の妥当性、イベント駆動アーキテクチャの信頼性、マテハン機器連携の性能を、それぞれPoCで確認します。

入出庫サービスとロケーション管理サービスの依存関係を定義し、Prismなどでコントラクトを再現したAPIモックを作成して、各サービスが独立してビルド・デプロイできるかを確認します。この検証で密結合が見つかった場合は、実装を進める前に境界の引き直しを検討します。

この段階でAPIモックへの結合テストを行っておくと、実装フェーズに入ってからサービス間のインターフェース仕様を大きく変更する事態を避けやすくなります。境界の妥当性を確認できないまま実装へ進むと、後工程での手戻りが大きくなるため、パイロットフェーズの時間配分としてもこの検証を軽視すべきではありません。

ピッキング指示後にロボット側でエラーが発生した場合に、在庫引当を解放する補償トランザクションが確実に実行されるかを、Sagaパターンのシナリオで検証します。あわせて、同じ処理を複数回実行しても結果が変わらない冪等性や、Transactional Outboxパターンによるメッセージ送信の信頼性も確認します。書き込みDBと読み取りDBを分離するCQRSを採用する場合は、同期の遅延がどの程度発生するかも合わせて測定します。

エッジでのフィルタリングによってどの程度レイテンシを削減できるか、ネットワークが切断された場合にローカル処理で最低限のピッキング・搬送指示を継続できるかを、カオスエンジニアリングの手法を使って検証します。安定領域はコンテナ、突発的なイベント処理はサーバーレスというハイブリッドな構成のコスト効率も、この段階で確認しておくべき項目です。

検証結果は、レイテンシの数値だけでなく、障害発生時に現場のオペレーターがどのような代替手順で作業を継続できたかという運用面の記録もあわせて残しておくと、本番移行後のマニュアル整備や教育計画に役立てられます。

選定前に確認しておきたいポイント

候補となる進め方やパートナーを絞り込んだ後も、段階移行のロードマップと社内体制を最終確認しておくことで、着手後の手戻りを防げます。

重要なモジュールに絞ったパイロット、初期のAPI連携を稼働させるMVP、プラットフォーム全体の移行を完了させる本番移行、そして独立したサービスとしてさらにスケールさせる段階と、フェーズを分けたロードマップを描いておくと、各段階での投資判断がしやすくなります。ストラングラーフィグパターンによる段階移行の考え方は、WMSのリアーキテクチャとはで詳しく整理しています。

境界設計を誤ると、サービスは分割されていても内部では強く依存し合う分散モノリスに陥り、運用コストだけが増えてしまいます。イベントストーミングを通じた境界の合意形成、Database per Serviceの原則を守れる体制、DevOpsやSREの継続的な運用体制が社内に整っているかを、着手前に確認しておく必要があります。

リアーキテクチャを支えるコンテナ基盤やイベント駆動基盤の具体的な製品・サービスを比較したい場合は、WMSのリアーキテクチャのパッケージ・クラウド製品一覧を参照すると、共通の評価軸で比較しやすくなります。

まとめ

WMSのリアーキテクチャを選定する際は、自社のリクエスト量とエンジニア体制、マテハン機器連携のリアルタイム要件をまず洗い出し、モジュラーモノリス型、マイクロサービス型、ハイブリッド型のいずれが適しているかを判断します。

組織規模とトラフィックの評価軸、マイクロサービス税を含むコスト構造の評価軸、API-first設計やDDDのファシリテーション実績という開発体制の評価軸をそろえたうえで、候補となるパートナーを比較することが重要です。評価を単純な印象に頼らず、確認方法まで統一しておくと、選定後の認識違いを防げます。

最終的な判断は、ドメイン境界の妥当性、Sagaパターンやオフライン耐性を含むPoCの結果に基づいて行うべきです。資料上の説明だけでなく、実際のマテハン機器やロボットに近い条件で検証することで、稼働後に発覚するリスクを大幅に減らせます。既製のクラウド型WMSでは吸収しきれない独自の業務ロジックやマテハン連携がある場合、riplaはフルスクラッチ開発の立場から、ドメイン設計からPoC、段階移行の実装まで一貫して支援しています。

▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。