WMSのリアーキテクチャのPoC・プロトタイプ・モックアップ開発について

WMSのリアーキテクチャにおけるPoC（概念実証）と聞くと、「WMSのモダナイゼーション」「WMS刷新」「WMS更改」「WMSのリニューアル」のPoCと同じ検証内容だと思われがちですが、本記事が扱う検証項目は明確に異なります。モダナイゼーションのPoCが既存データを正確に移行できるかという「移行の正確性」を検証するのに対し、刷新・更改は経営判断や期限管理の文脈でPoCが位置づけられ、リニューアルのPoCはハンディターミナル画面の操作性を検証します。これらに対して本記事が扱う「リアーキテクチャ」のPoCは、モノリシックな既存WMSをロケーション管理・ピッキング・入出庫というドメインごとにマイクロサービス分解する際に、その構造設計そのものが技術的に成立するかを検証することに主眼を置きます。WMSはこれら3つのドメインが複雑に絡み合い、かつマテハン機器（自動倉庫・ロボット）からミリ秒単位の応答が求められるため、本格的な開発前のパイロットフェーズ（3〜6ヶ月）における徹底した技術検証が、プロジェクト全体の成否を分ける最重要工程になります。

本記事では、WMSのリアーキテクチャにおけるPoC・プロトタイプ・モックアップについて、ドメイン境界設計（コンテキストマップ）の妥当性検証、イベント駆動アーキテクチャ（Saga・CQRS等）のPoC、マテハン機器とのリアルタイム連携基盤（エッジ/IoT）の性能検証、そしてストラングラーフィグパターンによる段階移行PoCまでを体系的に解説します。データ移行の正確性を検証するモダナイゼーションのPoCとは異なり、本記事では「アーキテクチャの構造設計そのものが技術的に成立するか」を検証するという論点に焦点を当てます。

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

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

WMSのリアーキテクチャにおけるPoCの位置づけ（構造検証という論点）

リアーキテクチャのPoCが何を検証するものかを理解するには、隣接する記事群のPoC・検証の位置づけとの違いを押さえておく必要があります。

「WMSのモダナイゼーション」のPoCは、既存のロケーションマスタ・在庫データを正確に新環境へ移せるか、旧システムとの並行稼働で数値がずれないかという「移行の正確性」を主眼としています。これに対して本記事が扱うリアーキテクチャのPoCは、移行の正確性を前提としつつ、さらに一段深く「そもそもドメインをどう分解すべきか」「分解したサービス同士がイベント駆動でどう連携すべきか」という、構造設計そのものの技術的な成立性を検証します。モダナイゼーションのPoCが「今と同じ結果を再現できるか」を確かめるのに対し、リアーキテクチャのPoCは「今と同じ結果を、分解された複数のサービスが協調して正しく再現できるか」という、分散システム特有の難しさに踏み込む点が最大の違いです。単一のコードベースでは発生しなかった結果整合性の問題や、サービス間通信の障害耐性といった論点は、リアーキテクチャのPoCで初めて本格的に検証対象になります。

「WMS刷新」ではPoCは投資対効果を経営層に示すための材料として位置づけられ、「WMS更改」ではPoCは期限内に既存業務を代替できるかの確証を得ることに特化し、「WMSのリニューアル」ではプロトタイプは画面の操作性や現場での迷いを特定するユーザビリティテストが中心になります。これらはいずれも、システムの内部構造がどう分解されているかという論点には踏み込みません。これに対して本記事が扱うリアーキテクチャのPoCは、経営判断の材料でも画面の使いやすさの検証でもなく、「ドメイン境界の切り方は正しいか」「イベント駆動の非同期処理は本番相当の負荷でも整合性を保てるか」「マテハン機器とのリアルタイム連携は要求されるレイテンシを満たせるか」という、アーキテクトが技術的な意思決定を下すための検証に特化しています。

ドメイン境界設計（コンテキストマップ）の妥当性検証

モノリスからマイクロサービスへの分解において、ドメイン駆動設計（DDD）を用いてサービス境界を正しく設定するための検証が、リアーキテクチャPoCの出発点です。

ドメイン境界の妥当性検証は、開発者とドメイン専門家（倉庫の現場担当者など）が共同で行う「イベントストーミング」というワークショップから始まります。業務プロセスを付箋やホワイトボードで可視化し、「境界づけられたコンテキスト（Bounded Context）」と、関係者間で用語の意味がずれない「ユビキタス言語」を定義していきます。この段階で固まった境界をもとに、「入出庫サービス」と「ロケーション管理サービス」がどのようなAPIでどう依存し合うのかをコンテキストマップとして定義し、実際にコードを書く前にPrismなどのツールを用いてAPIのモックを作成し、想定した連携が意味のある形で成立するかを机上で検証します。この工程を省略していきなり実装に入ると、開発が進んでから境界の引き直しが必要になり、複数サービスにまたがる大規模な手戻りを招きます。

境界設計を誤ると、ピッキングロジックを変更するたびに入出庫サービスのコードも修正・同時デプロイしなければならない「分散モノリス」に陥ります。これを防ぐため、PoCの段階で、各サービスが専用のデータベースを持つ「Database per Service」の原則を実際に適用し、ロケーション管理サービスの担当チームが他チームとの調整なしに独立してビルド・デプロイできるかを検証します。具体的には、ロケーション管理サービスだけをデプロイし直しても、ピッキングサービス・入出庫サービスの動作に一切影響が出ないことを確認するリリーステストを行い、もし何らかの形で他サービスの再デプロイが必要になる依存関係が見つかった場合は、その時点で境界の引き直しを検討します。この回避テストをPoCの段階で実施しておくことが、本開発フェーズで分散モノリス化に気づかず突き進んでしまう最悪の事態を防ぎます。

イベント駆動アーキテクチャ（Saga・CQRS等）のPoC

WMSにおいて、在庫の二重引当やデータ不整合を防ぐための非同期処理の基盤検証が、リアーキテクチャPoCのもう一つの中核です。

モノリス時代であれば単一データベースのトランザクション（ACID特性）で担保できていた整合性は、サービスが分割されると使えなくなるため、Kafkaなどのイベントブローカーを用いた「Sagaパターン」による結果整合性の実装が必要になります。PoCでは、たとえば「ピッキング指示」が出た後にロボット側でエラーが発生した場合に、イベントを遡って「在庫引当の解放（Restock）」を行う補償トランザクション（アンドゥ処理）が確実に実行されるかを検証します。あわせて、ネットワークの瞬断によって同じイベントが2回送信されても安全に処理される「冪等性」や、データベース更新とメッセージ送信のタイミングのずれを防ぐ「Transactional Outbox」パターンが正しく機能するかも、この段階で検証しておくべき重要な項目です。これらの検証を怠ると、稼働後にまれにしか再現しない在庫の不整合という、原因の特定が極めて困難な障害に苦しめられることになります。

書き込み用のデータベースと、検索・在庫ダッシュボードなど表示用の読み取りデータベースを分離するCQRS（コマンドクエリ責務分離）や、イベントログから現在の在庫状態を再構築するイベントソーシングを採用する場合は、書き込みから読み取り側への同期遅延（レイテンシ）を測定するPoCが欠かせません。ピッキング担当者がハンディターミナルで検品を完了させた直後に、在庫ダッシュボード上の数値が更新されるまでにどの程度の遅延が生じるかは、現場の業務スピードに直接影響します。本番相当のトランザクション量を模したデータを流し込み、同期遅延が業務上許容できる範囲に収まるかを実測したうえで、許容できない遅延が見つかった場合はイベント配信の仕組みやインデックス設計を見直すというサイクルを、PoCの段階で回しておくことが重要です。

マテハン機器とのリアルタイム連携基盤（エッジ/IoT）の性能検証

IoTデバイスやロボットからの高頻度なストリームデータを処理するインフラの検証も、リアーキテクチャPoCの重要な柱です。

センサーやロボットからの膨大なデータをすべて中央のクラウドへ送信すると、帯域幅コストの肥大化とネットワーク遅延が発生します。そのため、データが生成される現場（各倉庫拠点）に近いエッジ側でデータをフィルタリング・リアルタイム処理するハイブリッドアーキテクチャを構築し、実際の応答速度を検証します。具体的には、ピッキングロボットが棚からの搬送を開始してから、WMS側が搬送完了を認識してピッキング指示を確定させるまでの一連の応答時間を、エッジ処理あり・なしの両パターンで実測比較し、業務上要求されるミリ秒単位の応答性能を満たせるかを確認します。この検証結果は、後のマテハン連携基盤の本開発における技術選定の根拠として、そのままプロジェクトの意思決定材料になります。

クラウドとのネットワーク接続が切断された場合でも、エッジ側のローカル処理によって最低限のピッキングや搬送指示が止まらずに継続できるかという耐障害性の検証も欠かせません。PoCの段階でカオスエンジニアリングの手法を用いて意図的にネットワーク接続を遮断し、エッジ側がどこまで自律的に処理を継続できるか、そしてネットワーク復旧後にクラウド側とのデータ整合性がどう回復するかを確認します。あわせて、安定した「ロケーション管理」はコンテナ（Kubernetes）で動かし、マテハン機器からの突発的なイベントにはサーバーレス（FaaS）を用いて即座にスケールさせる構成のコスト効率も、このフェーズで検証しておくと、後のインフラ設計とコスト見積もりの精度が高まります。

ストラングラーフィグパターンでの段階移行PoC

新しく構築したマイクロサービスへ、レガシーシステムから安全にトラフィックを切り替えていくための検証が、PoCの最終段階として位置づけられます。

システム全体を一気に切り替える「ビッグバンリリース」ではなく、「特定エリアのピッキング機能のみ」といった業務単位の垂直スライスを切り出し、APIゲートウェイを利用して特定の条件を満たすトラフィックのみを新しいマイクロサービスへルーティングし、旧モノリスシステムを稼働させたまま段階的に移行できるかをPoCで検証します。具体的には、一部の拠点や一部のロケーションゾーンだけを対象に新サービスへのルーティングを有効化し、旧システムと新サービスの処理結果が一致し続けるかを一定期間監視します。この垂直スライスの検証がうまくいけば、次のスライスへ段階的に対象を広げていくという判断ができ、逆にうまくいかなければ、境界設計やルーティングロジックをこの段階で修正できるため、本開発フェーズでの致命的な手戻りを避けられます。

PoCの段階で、コンテナ化や自動テストを含むCI/CDパイプラインをあわせて構築しておくことが、本開発フェーズへ移行すべきかを判断する重要な材料になります。最初の垂直スライスが旧システムに悪影響を与えることなく独立稼働し、デプロイの頻度や修正のリードタイムが旧モノリス時代と比べて向上していることが確認できれば、本格的なMVP開発フェーズ（6〜12ヶ月）へと進む「Go」の判断材料となります。逆に、境界設計の見直しが何度も必要になったり、イベント駆動の整合性検証で解決困難な問題が繰り返し見つかったりする場合は、いったんモジュラーモノリスにとどめる方針へ切り替えるという「No-Go」判断も選択肢に含めておくべきです。PoCの目的は「予定通り進めること」ではなく「進めるべきかどうかを事実に基づいて判断すること」であるという姿勢が、リアーキテクチャという大きな投資を成功させるための土台になります。

まとめ

本記事では、WMSのリアーキテクチャにおけるPoC・プロトタイプ・モックアップについて、構造検証という位置づけ、ドメイン境界設計（コンテキストマップ）の妥当性検証、イベント駆動アーキテクチャ（Saga・CQRS等）のPoC、マテハン機器とのリアルタイム連携基盤（エッジ/IoT）の性能検証、そしてストラングラーフィグパターンでの段階移行PoCを体系的に解説しました。既存データを正確に移せるかを検証するモダナイゼーションのPoCとは異なり、リアーキテクチャのPoCは、イベントストーミングによるドメイン境界の妥当性、Sagaパターンによる補償トランザクションの整合性、エッジ/IoT連携基盤のレイテンシと耐障害性、そしてストラングラーフィグパターンによる垂直スライスの独立稼働という、分散システム特有の技術検証に主眼があります。これらの検証結果を「Go/No-Go」の判断材料として明確に位置づけ、境界設計や分割粒度を柔軟に見直しながら本開発へ進むことが、リアーキテクチャを成功させる鍵となります。まずは対象を絞った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を創業。