WMSのリアーキテクチャのパッケージ/クラウド製品一覧

WMSのリアーキテクチャで使う製品は、自社構築のパッケージ型とクラウドベンダーのクラウド型に分かれます。どの製品が合うかは、データ処理の特性と既存クラウドとの統合性で変わります。

補償処理の要否も踏まえて組み合わせると、現場の課題に合う基盤を選べます。各テーマの詳細は関連記事でも確認できます。

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

パッケージ型とクラウド型の技術基盤の違い

自社構築とクラウド型を、継続保守と運用負荷の観点で比べる図
保守を担う側が運用負荷を左右します。

自社データセンター内に基盤を個別に構築する形は、WMSのリアーキテクチャでは一般的になっていません。機能や料金を具体的に確認しやすいのは、クラウドベンダーが提供するクラウド型です。そのため、この先で取り上げる製品もクラウド型が中心です。

パッケージ型の論点は自社構築と継続保守

構築形態を選ぶときは、導入後の運用負荷も含めて検討することになります。

  • 自社構築:データセンター内にストリーミング基盤やコンテナ実行基盤を個別に構築し、自社で保守する形も理論上は可能です。
  • 継続保守:メッセージング基盤のバージョンアップやパッチ適用、可観測性の確保までを自前で続ける体制が前提になります。
  • 運用の継続性:マテハン機器から24時間、絶え間なくイベントを扱う基盤ほど問われる点です。

クラウド型が中心になっている理由

多くの企業が、マネージドサービスとしてクラウド型を選んでいます。クラウド型なら、クラスター管理やパッチ適用をベンダー側に任せられます。倉庫の稼働拡大や機器追加に伴ってイベント量が増えるため、運用を委ねられるかどうかがプロジェクト全体の負荷を左右します。

ポイント

自社構築は理論上は可能でも、保守を自前で続ける体制が前提になります。クラウド型なら、クラスター管理やパッチ適用をベンダーに任せられ、イベント量が増えても運用を委ねられるかが負荷を左右します。

製品を比較するときの共通軸

製品と自社の相性は、次の2軸で確かめます。機器データの特性やドメイン分割の方針に合うかは、機能一覧からは読み取りにくいからです。

  • データ処理特性:順序保証や重複排除、負荷変動への対応が、自社のデータに合うかを見ます。
  • 既存基盤との統合性:クラウド、認証、ネットワーク、監視と連携できるかが対象です。

データ処理特性との適合性

機器台数やセンサーの項目数によってイベント量は変わり、順序保証や冪等性も求められます。一般的な業務データとは異なる特性です。

ストリーム処理基盤では、取り込み速度に加えて、順序保証の方式や重複排除、遅延時のリトライの振る舞いを確かめます。一方で、実行基盤では、ピッキングのピーク時に高負荷の処理を個別に拡張できるかを比べます。

既存クラウド基盤との統合性

既存環境との連携条件は、統合時の負担を左右し、選ぶ製品も変えます。

  • AWSとの統合:AWSを主に使う場合、AWSにネイティブ統合された製品なら、認証やネットワーク設定の重複を避けられます。
  • 複数環境への対応:複数クラウドの併用や特定ベンダーへの依存を避けたい場合は、マルチクラウド製品が柔軟性を保ちやすいこともあります。
  • 監視・ログの統合:既存の運用基盤とどこまで統合できるかが、運用開始後の負荷に関わります。

評価の手順はWMSのリアーキテクチャの選定ポイントで整理しています。

ポイント

製品と自社の相性は、データ処理特性と既存基盤との統合性の2軸で見ます。機器データの特性やドメイン分割の方針は、機能一覧だけでは判断しにくい点です。

WMSのリアーキテクチャを支える主要クラウド製品6選

クラウド製品の役割をイベント処理、サービス実行、ワークフローの3区分で示す図
役割ごとに候補を組み合わせて整理できます。

2026年7月時点で公式ページと対応内容を確認できた6製品を紹介します。機器連携向けのイベント駆動型ストリーム処理基盤と、マイクロサービスの実行・オーケストレーション基盤に分けて見ていきます。掲載順は、優劣を示すランキングではありません。

Amazon MSK(Managed Streaming for Apache Kafka)

Amazon MSKは、性能や可用性に加えて、WMSでの運用面と料金も確かめたい製品です。

  • サービス:Amazon MSKは、AWSが提供するフルマネージドのApache Kafkaです。
  • Expressブローカー:従来比で高いスループットと、速いスケーリングを実現するとされています。
  • 可用性:マルチAZ展開により、インフラの自動検出、軽減、復旧に対応しています。
  • WMSでの候補:機器追加でイベント量が段階的に増えるなら、プロビジョニングや保守をAWSに任せられます。
  • 料金:具体的な金額の記載はなく、従量課金制とだけ書かれています。

Amazon Kinesis Data Streams

Amazon Kinesis Data Streamsは、サーバー管理が不要なAWSのリアルタイムストリーミングサービスです。オンデマンドモードでは、自動スケーリングに対応します。

ログやイベントデータの取得、イベント駆動型アプリケーションに向いています。たとえば、ピッキングロボットや自動倉庫のセンサーイベントも取り込めます。

2026年7月時点の公式サイトでは、取り込みは1GBあたり0.032ドルから、取得は1GBあたり0.016ドルからとされています。ただし、適用条件や最新の価格は、見積もりの時点で確認してください。

Confluent Cloud

Confluent Cloudは、Kafka開発チームが提供するフルマネージドサービスです。

  • プランとコネクタ:Basic・Standard・Enterprise・Freightの各プランと、120以上の事前構築コネクタがあります。
  • 複数環境への対応:複数クラウドやオンプレミスをまたぐ連携基盤の候補になります。
  • セキュリティ:RBAC、暗号化、監査ログなどの機能が備わっています。

具体的な料金は記載がなく、プラン名だけが示されています。また、新規登録時には30日間400ドル分のクレジットが提供されると、公式に案内されています。

Amazon EKS(Elastic Kubernetes Service)

Amazon EKSは、AWSのマネージドKubernetesサービスです。クラスターインフラの管理自動化に加え、容量計画とスケーリングの自動化にも対応しています。

DDDで分けたロケーション管理やピッキング、入出庫などのマイクロサービスを稼働できます。さらに、Amazon EKS Auto Modeは単一クリックでのクラスター管理自動化に対応しています。

AWS上にストリーム処理基盤がある場合は、認証やネットワーク構成を共通化しやすくなります。ただし、料金の具体額は示されておらず、Pricingページでの確認が必要です。

Temporal

Temporalは、マイクロサービス間のワークフローをコードで書いて実行するオーケストレーション製品です。

  • Sagaパターン:try…catchのように扱えると、公式に案内されています。
  • 補償処理:ピッキング指示、ロボットへの搬送依頼、完了検収などが途中で失敗した場合の処理を、複雑な自前実装なしに組み込めます。
  • 実行形態:セルフホストとTemporal Cloudがあり、Cloudには1,000ドルの無料クレジットがあります。

自動リトライやタイマー、状態の永続化に対応しているため、長時間のワークフローを追跡できます。そのため、分散トランザクションの整合性確保が課題の分離プロジェクトで候補になります。料金はPricingページで確認が必要です。

AWS Step Functions

AWS Step Functionsは、AWS Lambda関数などを組み合わせて、サーバーレスのワークフローを構築するサービスです。

  • 設計と統合:画面上で設計でき、220以上のAWSサービスと連携できます。
  • 状態管理:自動的なエラーハンドリングと、実行状態の管理機能を備えています。
  • 利用候補:AWS中心のサーバーレス構成で、ピッキングエラー時の補償処理をLambda関数群で組む場合に適しています。

Temporalのような長時間実行ワークフローの永続化については記載が少ないため、必要な整合性のレベルに応じて使い分けます。また、公式ページにも具体的な料金の記載はありません。

自社の課題別に候補を絞る方法

6製品を一度に細部まで比べるより、まず技術要素の課題を洗い出すと、候補を絞りやすくなります。

マテハン連携のストリーム処理基盤が逼迫している場合

自動倉庫やロボットを増設しても処理が追いつかない場合は、ストリーミング製品を候補に入れます。具体的には、Amazon MSK、Amazon Kinesis Data Streams、Confluent Cloudが挙がります。

AWS中心ならMSKかKinesis、複数クラウドやオンプレミスを横断するならConfluent Cloudが出発点になります。どの製品も、順序保証と冪等性の実装方法をデモで確かめます。

マイクロサービスの分離と整合性確保を進めたい場合

ロケーション管理やピッキングを切り出すなら、実行基盤のAmazon EKSが候補になります。複数サービスにまたがる補償処理には、Temporalを組み合わせます。

AWS中心のサーバーレス構成なら、AWS Step Functionsも比較対象になります。そのうえで、分散トランザクションの保証レベルが要件に合うかを、実際のピッキングシナリオで確かめます。

料金・契約前に確認すべきこと

総保有コストの検討項目としてデータ流量、処理規模、サポート体制を並べた図
同じ条件と契約範囲で見積もりを比べます。

6製品の多くは具体的な金額を公開しておらず、従量課金や個別見積もりが前提になっています。そこで、データ流量や処理規模を伝えたうえで、総保有コストを確かめます。

課金の対象と単位

ストリーミング基盤は、データ転送量やパーティション数、クラスターのインスタンスサイズなどで課金される場合があります。

実行基盤やワークフローも、稼働時間やリクエスト回数に応じた従量課金が中心です。そのため、現在の台数に加えて、1年後・3年後のイベント量やサービス数も伝えて見積もります。

サポート体制と契約形態

Confluent CloudやTemporalなど、オープンソース起源の技術を使うサービスには、セルフホスト版と商用クラウド版が併存するものがあります。

イベントの取り込みが止まると、倉庫全体に影響が及びます。そのため、障害時に自社だけでは解決できない場面も想定しておきます。

商用サポートの対応時間や問い合わせ窓口、契約に含まれる範囲を事前に確認すると、本番稼働後の不安を減らせます。

ポイント

6製品の多くは金額を公開せず、従量課金や個別見積もりが前提です。データ流量と処理規模を伝え、同じ条件で見積もりを比べます。サポートの対応範囲も、契約前に明らかにしておく必要があります。

デモとPoCで最終候補へ絞る進め方

資料での比較で2〜3製品に絞り込んだら、実際の機器データや一部のピッキング動線で検証します。その際、アーキテクトに加えて現場の運用担当エンジニアも参加すると、導入後の認識のずれを減らせます。

1機能のフルパス検証

一部のロボットやセンサーのイベントを取り込み、サービスで処理して、その結果をピッキング指示や在庫更新に反映します。

正常系に加えて、メッセージの重複や欠落、障害時の停止箇所も追跡します。そのうえで、レイテンシや障害の切り分けにかかる時間、監視画面でどこまで見えるかを記録し、展開時の判断材料にします。

移行効果の実測と稟議での活用

PoCの前に、ピッキングロジックの変更にかかる確認工数やリリースまでの所要時間を記録します。加えて、マテハン連携のイベント遅延件数も記録し、PoC後の数値と比べます。

効果は、一般的な数字をそのまま当てはめるより、自社の機器台数と開発チームの実績値で算出するほうが、経営層への説明に根拠を持たせられます。

ポイント

資料比較で2〜3製品に絞った後は、実際の機器データや一部のピッキング動線で検証します。フルパスの動作と、障害時の切り分けにかかる時間を記録し、展開時の判断材料にします。

WMSのリアーキテクチャの製品比較で押さえておきたいポイント

製品を比べるときは、買い切り型の有無やおすすめ順位よりも、機器データ量とサービスの分割方針に合うかを見ます。比較の前提を、各製品で同じ条件にそろえることが大切です。

パッケージ型が必要な場合の個別構築

機能や料金を確認しやすい製品は、クラウド型が中心です。一方で、自社データセンターでの完全な構築が必須なら、オープンソース製品の組み合わせや外部ベンダーとのハイブリッド構成も比べます。

最優先課題による製品の選び分け

企業に共通する1位はなく、最優先課題に合う製品が候補になります。その最優先課題は、マテハン連携の逼迫、サービス分離、分散トランザクションの整合性などです。

対象範囲と課題を明確にしたうえで、製品の組み合わせを2〜3案に絞り、PoCへ進みます。

複数年の総保有コストでの料金比較

各社に同じイベント量、サービス数、サポート条件を示し、数年単位の総保有コストを比べます。利用料に加えて、学習や統合作業、商用サポートの費用も含めて考えます。

まとめ

買い切りのパッケージを探すより、役割ごとにクラウド製品を組み合わせるほうが現実的です。分けるのは、機器連携のストリーム処理と、マイクロサービスの実行・オーケストレーションの2つです。

6製品には、マルチクラウド対応、AWS基盤との統合、Sagaパターン対応など、それぞれ異なる強みがあります。

課題診断から2〜3案への絞り込み

ストリーム処理の逼迫、サービスの密結合、分散トランザクションの整合性から、最優先課題を決めます。そのうえでデータ特性と既存クラウドとの統合性で比べると、話題性に左右されずに候補を絞れます。

実データによるPoCでの確認

資料比較で絞り込んだ候補は、実際の運用に近い条件で確かめます。

  • 検証対象:自社の機器データやピッキング動線を使ったPoCで、機能一覧より実態に近い形で判断します。
  • 実測項目:レイテンシや障害対応にかかる時間も、数値で押さえておきます。

既製品では、独自のドメイン分割や基幹連携を吸収しきれない場合があり、個別の設計・実装支援が必要になることもあります。そうしたときは、riplaがフルスクラッチ開発の立場から、不足部分の整理や業務に合わせたWMSのリアーキテクチャ実装を支援しています。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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