WMSのリアーキテクチャのPoC（概念実証）は、モノリスをサービスに分解した構造そのものが技術的に成り立つかを確かめる検証です。「WMSのモダナイゼーション」「WMS刷新」「WMS更改」「WMSのリニューアル」のPoCと同じ検証内容だと思われがちですが、検証の軸は次のように明確に異なります。
- モダナイゼーション：既存データを正確に移行できるか
- 刷新：経営判断のための材料
- 更改：期限内に既存業務を代替できるか
- リニューアル：ハンディターミナル画面の操作性
とくに、ドメインが複雑に絡み合い、マテハン機器がミリ秒単位の応答を求めるWMSでは、本格開発前の3〜6ヶ月のパイロットフェーズでの技術検証が成否を分けます。
▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMSのリアーキテクチャにおけるPoCの位置づけ（構造検証という論点）
リアーキテクチャのPoCが何を検証するかを理解するには、隣接する記事群で扱うPoCや検証との違いを押さえておく必要があります。
WMSのモダナイゼーションPoC（移行の正確性検証）との違い
モダナイゼーションのPoCは、既存のロケーションマスタや在庫データを新環境へ正確に移せるか、旧システムとの並行稼働で数値がずれないかという「移行の正確性」を主に確かめます。
これに対してリアーキテクチャのPoCは、移行の正確性を前提にしたうえで、ドメインの分解方法とサービス同士の連携方法という、構造設計そのものの成立性を検証します。
モダナイゼーションのPoCが「今と同じ結果を再現できるか」を確かめるのに対し、リアーキテクチャのPoCは「今と同じ結果を、分解された複数のサービスが協調して正しく再現できるか」を問います。とくに、単一のコードベースでは発生しなかった結果整合性の問題や、サービス間通信の障害耐性は、このPoCで初めて本格的な検証の対象になります。
WMS刷新・WMS更改・WMSのリニューアルにおける検証との違い
「WMS刷新」のPoCは、投資対効果を経営層に示すための材料として位置づけられます。「WMS更改」のPoCは、期限内に既存業務を代替できるかの確証を得ることに特化します。また、「WMSのリニューアル」のプロトタイプは、画面の操作性や現場での迷いを特定するユーザビリティテストが中心です。
これらはいずれも、システムの内部構造をどう分解するかという論点には踏み込みません。
これに対してリアーキテクチャのPoCは、経営判断や画面の使いやすさとは別に、アーキテクトが技術的な意思決定を下すための検証に特化します。具体的には、「ドメイン境界の切り方は正しいか」「イベント駆動の非同期処理は本番相当の負荷でも整合性を保てるか」「マテハン機器とのリアルタイム連携は要求されるレイテンシを満たせるか」を確かめます。
ドメイン境界設計（コンテキストマップ）の妥当性検証
モノリスからマイクロサービスへ分解する際は、ドメイン駆動設計（DDD）でサービスの境界を正しく決めることが欠かせません。そのため、境界の妥当性を確かめる検証が、リアーキテクチャのPoCの出発点になります。
イベントストーミングとコンテキストマップのモック検証
ドメイン境界の検証は、開発者とドメイン専門家（倉庫の現場担当者など）が共同で行う「イベントストーミング」というワークショップから始まります。このワークショップでは、業務の流れを付箋やホワイトボードに書き出します。そのうえで、「境界づけられたコンテキスト（Bounded Context）」と、関係者の間で用語の意味がずれない「ユビキタス言語」を決めていきます。
この段階で固まった境界をもとに、「入出庫サービス」と「ロケーション管理サービス」がどのAPIでどう依存し合うかを、コンテキストマップとして定義します。次に、コードを書く前にPrismなどのツールでAPIのモックを作り、想定した連携が意味のある形で成り立つかを机上で検証します。
この工程を省くと、開発が進んでから境界を引き直す必要が生じ、複数のサービスにまたがる大規模な手戻りを招きます。
「分散モノリス」の回避テスト（Database per Serviceの検証）
境界設計を誤ると、ピッキングロジックを変更するたびに入出庫サービスのコードも修正し、同時にデプロイしなければならない「分散モノリス」に陥ります。これを防ぐため、PoCの段階で、各サービスが専用のデータベースを持つ「Database per Service」の原則を実際に適用します。
そのうえで、ロケーション管理サービスの担当チームが他チームと調整せずに独立してビルド・デプロイできるかを確かめます。具体的には、ロケーション管理サービスだけをデプロイし直しても、ピッキングサービスと入出庫サービスの動作に一切影響が出ないことを、リリーステストで確認します。
もし何らかの形で他サービスの再デプロイが必要になる依存関係が見つかれば、その時点で境界の引き直しを検討します。この回避テストをPoCの段階で実施しておけば、分散モノリス化に気づかないまま本開発を進む最悪の事態を防げます。
イベント駆動アーキテクチャ（Saga・CQRS等）のPoC
WMSでは、在庫の二重引当やデータ不整合を防ぐための非同期処理の基盤を検証することが、リアーキテクチャのPoCのもう一つの中核になります。
Sagaパターンの補償トランザクション検証
モノリス時代は、単一データベースのトランザクション（ACID特性）で整合性を担保できました。しかし、サービスを分割すると、この方法は使えなくなるため、Kafkaなどのイベントブローカーを用いた「Sagaパターン」による結果整合性の実装が必要になります。
PoCでは、たとえば「ピッキング指示」が出た後にロボット側でエラーが起きた場合を想定します。そのとき、イベントを遡って「在庫引当の解放（Restock）」を行う補償トランザクション（アンドゥ処理）が、確実に実行されるかを検証します。
あわせて、ネットワークの瞬断で同じイベントが2回送信されても安全に処理される「冪等性」を確かめます。さらに、データベース更新とメッセージ送信のずれを防ぐ「Transactional Outbox」パターンが正しく機能するかも、検証しておくべき項目です。これを怠ると、稼働後にまれにしか再現しない在庫の不整合という、原因の特定が極めて困難な障害に苦しむことになります。
CQRS（コマンドクエリ責務分離）とイベントソーシングのパフォーマンス検証
CQRS（コマンドクエリ責務分離）は、書き込み用のデータベースと、検索や在庫ダッシュボードなど表示用の読み取りデータベースを分けて持つ方式です。また、イベントソーシングは、イベントログから現在の在庫状態を再構築する方式です。これらを採用する場合は、書き込みから読み取り側への同期遅延（レイテンシ）を測るPoCが欠かせません。
ピッキング担当者がハンディターミナルで検品を完了させた直後、在庫ダッシュボードの数値が更新されるまでの遅延が、現場の業務スピードに直接影響します。
本番相当のトランザクション量を模したデータを流し込み、同期遅延が業務上許容できる範囲に収まるかを実測します。許容できない遅延が見つかれば、イベント配信の仕組みやインデックス設計を見直します。このサイクルを、PoCの段階で回しておく必要があります。
マテハン機器とのリアルタイム連携基盤（エッジ/IoT）の性能検証
IoTデバイスやロボットから高頻度に届くストリームデータを処理するインフラの検証も、リアーキテクチャのPoCの重要な柱です。
エッジコンピューティングによるレイテンシ削減検証
センサーやロボットからの膨大なデータをすべて中央のクラウドへ送ると、帯域幅コストが膨らみ、ネットワーク遅延も生じます。そのため、データが生まれる現場（各倉庫拠点）に近いエッジ側で、データのフィルタリングとリアルタイム処理を行うハイブリッド構成を組み、実際の応答速度を検証します。
具体的には、ピッキングロボットが棚からの搬送を開始してから、WMSが搬送完了を認識してピッキング指示を確定させるまでの一連の応答時間を測ります。エッジ処理あり・なしの両パターンで実測して比べ、業務上求められるミリ秒単位の応答性能を満たせるかを確認します。
この検証結果は、後のマテハン連携基盤の本開発における技術選定の根拠になり、プロジェクトの意思決定材料にもなります。
オフライン稼働（フォールバック）の検証
クラウドとのネットワーク接続が切れた場合でも、エッジ側のローカル処理によってピッキングや搬送指示の最低限の処理が止まらずに続けられるかという、耐障害性の検証も欠かせません。
PoCの段階で、カオスエンジニアリングの手法を使ってネットワーク接続を意図的に遮断し、エッジ側がどこまで自律的に処理を続けられるかを確かめます。さらに、ネットワークの復旧後に、クラウド側とのデータ整合性がどう回復するかも確認します。
あわせて、安定した「ロケーション管理」はコンテナ（Kubernetes）で動かし、マテハン機器からの突発的なイベントにはサーバーレス（FaaS）を使って即座にスケールさせる構成を想定します。この構成のコスト効率も、このフェーズで検証しておくと、後のインフラ設計とコスト見積もりの精度が高まります。
ストラングラーフィグパターンでの段階移行PoC
新しく作ったマイクロサービスへ、レガシーシステムからトラフィックを安全に切り替えていくための検証が、PoCの最終段階に位置づけられます。
垂直スライスの切り出しとAPIゲートウェイによるルーティング検証
システム全体を一気に切り替える「ビッグバンリリース」の代わりに、「特定エリアのピッキング機能のみ」といった業務単位の垂直スライスを切り出します。APIゲートウェイを使い、特定の条件を満たすトラフィックだけを新しいマイクロサービスへルーティングします。旧モノリスシステムを稼働させたまま段階的に移行できるかを、PoCで検証します。
具体的には、一部の拠点や一部のロケーションゾーンだけを対象に、新サービスへのルーティングを有効にします。そして、旧システムと新サービスの処理結果が一致し続けるかを、一定期間監視します。
この垂直スライスの検証がうまくいけば、次のスライスへ対象を広げていけると判断できます。逆に、うまくいかなければ、境界設計やルーティングロジックをこの段階で直せるため、本開発での致命的な手戻りを避けられます。
早期成功シグナル（CI/CD確立）とGo/No-Go判断
PoCの段階で、コンテナ化や自動テストを含むCI/CDパイプラインも構築しておくと、本開発へ移行すべきかを見極める土台になります。最初の垂直スライスが旧システムに悪影響を与えず独立稼働し、デプロイの頻度や修正のリードタイムが旧モノリス時代より向上していれば、本格的なMVP開発フェーズ（6〜12ヶ月）へ進む「Go」の判断材料になります。
逆に、境界設計の見直しが何度も必要になったり、イベント駆動の整合性検証で解決しにくい問題が繰り返し見つかったりする場合があります。そのときは、いったんモジュラーモノリスにとどめる方針へ切り替えるという「No-Go」の判断も、選択肢に含めておくべきです。
PoCの目的は、予定どおりに進めることより、事実に基づいて進めるべきかを判断することにあります。この姿勢が、リアーキテクチャという大きな投資を成功に導きます。
まとめ
ここまで見てきたとおり、リアーキテクチャのPoCは、分解後の構造が成り立つかを4つの論点で確かめるものです。論点は、ドメイン境界、イベント駆動（Saga・CQRS等）、マテハン連携（エッジ/IoT）、ストラングラーフィグパターンによる段階移行です。
既存データの正確な移行を確かめるモダナイゼーションのPoCとは、検証の軸が異なります。リアーキテクチャのPoCは、分散システム特有の技術検証に主眼を置きます。
具体的には、イベントストーミングによるドメイン境界の妥当性と、Sagaパターンの補償トランザクションの整合性を確かめます。さらに、エッジ/IoT連携基盤のレイテンシと耐障害性、垂直スライスの独立稼働も検証します。
これらの検証結果は、「Go/No-Go」の判断材料としてはっきり位置づけます。そのうえで、境界設計や分割の粒度を柔軟に見直しながら本開発へ進むことが、リアーキテクチャを成功させる鍵になります。
まずは対象を絞ったPoCで、ドメイン境界とマテハン連携基盤の技術的な成立性を検証します。確かな判断材料を得てから本開発に進むことを、お勧めします。
▼全体ガイドの記事
・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を創業。