eコマース最適化ソフトウェア, 2025年2月

レオン・ルヴィナ＝メナールによる

最終更新: 2025年2月2日

はじめに

eコマース最適化ソフトウェアの市場は、AIによる魔法のような過大な主張に満ちているが、実際に内部を詳しく見ると、最先端技術を用いて在庫、価格、品揃えを共同で最適化するという約束を真に果たしているのはほんの一部のベンダーに過ぎないことが明らかになる。本稿では、実店舗を持たない純粋なeコマース向けの主要ソリューションを評価し、Lokad、RELEX Solutions、Blue Yonder、ToolsGroupを含む最も関連性の高いベンダーを、その技術的利点と欠点に基づいてランク付けする。Lokadは統一された確率的アプローチと高度な自動化によりリーダーとして際立つ一方、RELEXとBlue Yonderは、それぞれブラックボックスのAI複雑性や旧来システムの負債によって抑制された包括的なスイートを提供している。ToolsGroupは、確固たる数学に裏打ちされた実証済みの在庫最適化を提供するが、価格設定や品揃えへの展開において統合の課題に直面している。全体を通して、マーケティングの誇大宣伝を斬り、独立した証拠に基づいてベンダーの主張を精査し、しばしば口にされない注意点（例えば、意思決定を全体的に最適化できないことや高価なアーキテクチャへの依存）を明らかにするという、非常に懐疑的な視点を適用している。本稿の目的は、誇大広告よりも真実を重視する物語風の技術分析により、eコマース関係者が誰が実際に技術の最前線を推進しているのか、また誰が不足しているのかを理解できるようにすることである。

ゴールドスタンダードの基準: 共同最適化と先進技術

どのベンダーもAIやビッグデータを自慢できるが、eコマース事業を真に最適化するには、高い技術的および機能的基準を満たす必要がある。最も重要なのは共同最適化、すなわち在庫水準、価格設定、製品の品揃えの意思決定を同時に最適化する能力である。これらを個別に扱う（多くの従来システムがそうしているように）のは根本的に誤りであり、相互に密接に依存している（価格が需要に影響し、需要が在庫に影響し、品揃えの変更が双方に影響するなど）ためである。eコマースの最適化ソリューションはこれら三者をすべて調整しなければならない。例えば、予測が低調な販売を示す場合には、ある製品の在庫を減らしかつ早期に値引きを行う、あるいは品切れを避けるために特定商品の価格を引き上げるといった判断を下す。もし在庫だけを最適化し価格設定を無視する、またはその逆の場合、潜在利益を逃す結果となり、設計上不十分である。

共同最適化を超えて、真に最先端のソリューションは、最新の技術およびアーキテクチャを活用すべきである:

確率的予測: 単一の需要予測値ではなく、確率分布を用いて需要の不確実性を捉える。これは、需要パターンが不安定でSKUの“ロングテール”を持つeコマースにとって極めて重要である。従来のツール（例: 古いSAPやOracleのモジュール）は、1つの数字と安全在庫のみを算出するため、実際の変動性を見誤ることが多い ¹ ²。主要なベンダーは現在、結果の範囲を定量化する確率的または「確率論的」モデルを強調している。
経済的最適化: 意思決定は、単なる経験則だけでなく、経済的目標（利益、コスト、サービスレベル目標）に基づくべきである。例えば、真に最適化されたシステムは、在庫水準や価格を決定する際に、製品の利益率と保管コストを考慮する。これは、単に充足率の達成を目指すのではなく、期待される利益を最大化または総コストを最小化する行動を優先することを意味し、そのためにはアルゴリズムにコスト／収益パラメーターを組み込む必要がある。
スケーラビリティとコスト効率: eコマースのデータは膨大で（場合によっては数百万のSKU、日々の取引、複数チャネルを含む）、ソフトウェアは高額なハードウェア費用や低速なパフォーマンスを伴うことなく大規模データを処理しなければならない。すべてを単純にメモリ（RAM）上に保持するアーキテクチャは、スケールするにつれて途方もなく高価になる可能性がある。現代の設計は、分散処理、ディスクベースのデータストア、効率的なアルゴリズムなどを活用してクラウドコンピューティングを賢明に利用する。巨大なサーバーファームや高価なプラットフォーム（例えば、Snowflakeのデータクラウドの過剰利用）を必要とするソリューションは、投資収益率を低下させかねない。逆に、巧妙なエンジニアリングにより、一般的なクラウドインスタンス上でテラバイト規模のデータセットを数時間で処理できる ³ ⁴。
カニバリゼーション及び代替効果: 品揃えや価格設定の意思決定において、システムは製品同士が互いの需要に影響を及ぼすことを考慮しなければならない。例えば、二つの製品が非常に近い代替品である場合、一方を廃止すると需要が他方に移行する（カニバリゼーション効果）。これを扱うには、単純なOLAP分析や手動で定義された製品グループ以上のアプローチが必要であり、交差弾性や付帯率を学習するモデルが求められる。多くの旧来ツールは、各製品の需要を独立していると仮定するため、予測および品揃え計画の両面で誤りを引き起こす。最先端のベンダーは、このような関係を明示的にモデル化すべきである（例：トランザクションデータを用いた機械学習で製品の親和性を推測するなど）。
マーケットプレイスおよび競争の影響: 純粋なeコマース事業者は、AmazonやeBayでの競争、サードパーティ販売者など、マーケットプレイスの動向にしばしば影響を受ける。最適化ソフトウェアは、競合他社の価格設定やマーケットプレイスでの品切れといったシグナルを理想的には取り入れるべきだが、これをうまく実現している例は少ない。これは複雑でありながらもますます重要な分野であり、例えば競合他社が人気商品の在庫切れに陥った場合、自社システムがその機会を検知して価格や広告費を調整すべきである。同様に、直販とマーケットプレイスの両方で販売している場合、システムはチャネル全体で最適化を実施する必要がある（例えば、自社サイトで在庫過多にならないようにするなど）。
マルチチャネルおよびオムニチャネル機能: 実店舗がなくても、eコマース事業者は自社サイト、マーケットプレイス、場合によっては地域サイトなど、複数のオンラインチャネルを持つ可能性がある。最適化エンジンは、在庫が共有される場合や、あるチャネルでの価格設定が他のチャネルに影響する可能性があることを認識し、マルチチャネルの需要と在庫を包括的に管理すべきである。「エンドツーエンド」プランニングは単なる流行語ではなく、サプライヤーから顧客に至る全販売チャネル全体の全体像を把握することを意味する。
高度な自動化（“ロボット化”）: これらのシステムの究極の約束は自律的な意思決定である。理論上、ユーザーが毎日設定をいじることなく、補充オーダーや価格更新などを無人で実行できるはずだ。実際には、すべてのベンダーがユーザーによる設定変更を許容しているが、我々は人手の介入を最小限に抑えられるものを評価する。自動化を誇示しながらも、何十もの調整項目（パラメーター、重み付け係数、ルール）を露呈するソリューションには注意が必要である―それは内在的な矛盾である。真の自動化とは、ユーザーに常に再調整を要求するのではなく、アルゴリズムが最適な設定を見つけることから生まれる。最良のシステムは、新たなデータに応じて自己学習モデルが調整し、長期的に手動介入なしでも最適な意思決定を維持できるようにする ⁵。ユーザーが維持すべき「ドライバー」設定が少なければ少ないほど、自動化の信頼性は高まる。
堅牢でコスト効果の高いアーキテクチャ: コスト効率については既に触れたが、明確にしておく価値がある。近年の一部のソリューションは、スケール対応のためにSnowflakeのようなクラウドデータウェアハウスを採用している。これによりインフラの煩雑さは解消されるが、利用量に応じたコストモデルが導入される。もし計画ツールがSnowflakeのようなプラットフォーム上で膨大なデータ処理を要求するなら、コストが急騰する可能性がある（まるで1990年代のIBMのMIPSベースの価格設定のように、CPU使用量が増えるほど手数料が指数関数的に上昇する）。理想的なソリューションは、スマートなアルゴリズムを用いてビッグデータを処理し、クラウド使用量（ひいてはコスト）を合理的に維持する ⁴。同様に、買収によって構築されたソリューションは、異なる技術スタック上のモジュールの寄せ集めとなり、顧客にとって莫大な統合コスト（資金面やシステムレイテンシー）を招く可能性がある。クラウドネイティブで初めから統合されていることは有利だが、それは冗長なデータ移動を実際に排除し、新たなボトルネックを生み出さない場合に限る。

これらの基準を設定した上で、次にベンダーに目を向ける。私たちは、eコマース最適化において最も関連性の高いプレイヤーとしてLokad、RELEX、Blue Yonder、ToolsGroupをランク付けし、上記の基準に基づいてそれぞれを評価する。本分析は、各ベンダーがどのように問題に取り組み、どこに懐疑的な点があるかに焦点を当てた物語風のスタイルであり、単なる機能チェックリストではない。重要なのは、可能な限り信頼できる証拠（および直接の引用）に依拠し、ベンダーの主張を鵜呑みにするという一般的な罠を避ける点である。

1. Lokad – 確率的基盤を持つ統一的定量最適化

Lokadは、最先端技術を用いた共同最適化の考えを中心に構築されたベンダーとして際立っている。従来のサプライチェーンソフトウェアのように、調整可能なモジュール（予測、MRPなど）のセットとして提供されるのではなく、各クライアント向けに統一的な最適化ロジックが実装されたプログラムプラットフォームとして提供される。この「定量的サプライチェーン」と呼ばれるアプローチは、初期段階でより多くのデータサイエンスを必要とするかもしれないが、在庫、価格設定、補充など、すべての意思決定を一括で最適化するようにカスタマイズされたソリューションをもたらす。Lokadの哲学は、予測は目的を達成するための手段に過ぎず、本来の目的は、あらゆる制約と経済的トレードオフを考慮して、どれだけ購入するか、どの価格を設定するかといった意思決定を最適化することである。

中核となるのは確率的予測である。Lokadは需要に対して完全な確率分布を用いる先駆者であり、予測コンペティションという中立的な舞台でその実力を証明している。権威あるM5予測コンペティション（2020）では、Lokadチームは909チーム中世界6位にランクされ、これは細分化された小売データ（eコマース企業が直面するようなデータ）に焦点を当てたM5において、その技術が印象的に検証された結果である。特筆すべきは、M5が確率的（クオンタイル）予測を要求したことであり、これはまさにLokadの強みと一致する。この結果は、学術的な力量だけでなく実務上の関連性も示しており、彼らの予測が在庫および価格設定の最適化を支える最良のものであったことを物語っている。さらに、同社のCEOは、ある一定の段階を超えると、予測精度の向上がより優れた意思決定モデリングに比べて収穫逓減の結果しかもたらさないと強調している ⁶。言い換えれば、Lokadは予測精度の微小な改善を追い求めるのではなく、確率的予測を用いて意思決定（注文量、配分など）を最適化することに重きを置いている。この考え方は、在庫切れ、断続的な需要、代替効果といった問題に対処する際、予測指標の僅かな改善よりも重要であることを認識しており、eコマースにとって新鮮かつ重要な視点である ⁶。

技術面では、Lokadは最先端であり、非常にエンジニアリング志向である。彼らは、最適化スクリプト記述用のカスタムドメイン固有言語「Envision」を含む独自のクラウドネイティブテックスタックを構築した。このスタックは、大量のデータを効率的かつ経済的に処理するために設計されている。例えば、Lokadのシステムはクライアントのデータ（注文、クリックなど）を数ギガバイトからテラバイト規模で夜間数時間以内に処理し、翌日の意思決定を出力する ⁷ ³。そのため、すべてをRAMに読み込むことを避け、メモリマップファイルやオンディスクのカラム型ストレージを使用して、機械のメモリ容量を超えるデータセットも高速SSDへのスピルにより透過的に処理できる ³ ⁸。彼らは、Envision（自社エンジン）が、クラスタ全体のメモリ容量をも超えるデータセットに対しても「巧妙にNVMeドライブへスピル」し、見事に並列処理が自動的にコアやマシンに分散されることを明記している ³。結果として、Lokadはクライアントが莫大なRAMや専用機器に投資することなく、極めて大規模なSKU品揃えにスケールできるのだ。実際、彼らは稼働に必要なハードウェアを最小限に抑えることを強調しており、「実行ボタンをクリックするだけで数百ドルのクラウド料金が発生する」といった状況を回避している ⁴。これは微妙でありながら極めて重要な点であり、技術的にはビッグデータを処理できても莫大なコストがかかる重厚なエンタープライズシステムとの差別化となる。Lokadのアプローチは、サプライチェーン計算に特化した、Apache SparkやGoogle BigQueryに類似した最適化されたビッグデータパイプラインに近いものである。この効率性への注力が、ソリューションのスケール時におけるコスト効果を維持し、数百万レコードを扱うeテイラーにとって大きな利点となる。

Lokadによる価格設定と品揃えの処理は、個別のモジュールを通じて行われるのではなく、同一の最適化ロジックを用いる。プラットフォームが本質的にコード駆動であるため、相互作用をモデル化することが可能である。例えば、「各製品について、さまざまな価格帯での確率的需要を考慮し、在庫状況と再発注リードタイムを織り込み、在庫切れが頻発しない範囲で期待マージンから保管コストを差し引いた価格を選定する」といったスクリプトを書くことができる―これは簡略化した説明だが、価格設定と在庫管理が一体となって決定されることを示している。もし製品が過剰在庫の場合、コードは販売促進のために割引を決定し、在庫が不足している場合は、在庫を最も高い支払い意欲を持つ顧客に配分するために価格を引き上げる。これほどの相互作用を許容するベンダーは他にほとんど存在しない。基本的に、Lokadのソリューションは、商人のデータに合わせた独自の意思決定ポリシーを生成する。

カニバリゼーションおよび代替効果は、適切なデータを入力すれば自然に処理される。例えば、「商品Aが入手できない場合、その需要のどれだけが商品Bに移行するか」という入力を組み込むことが可能であり、こうした関係性は、過去の在庫切れや品揃えの変化を分析することで学習され、最適化に組み込まれる。Envisionが完全なプログラミング言語であるため、これらの複雑な需要ダイナミクスをコード化することができる。Lokadの文献によれば、システムは「製品、チャネル、時間帯間の相関関係を明らかにし」、各SKUが独立していると仮定するのではなく、それに応じた意思決定を行っている ⁹。単純な時系列外挿に依存することなく、プロモーション、在庫切れ、季節変動などを考慮した需要の完全な確率分布を算出する ¹⁰。これらの要因（在庫切れによる需要損失も含む）を捉えることで、Lokadは偏った売上データに基づく予測の古典的なゴミ入力問題を回避している。

Lokadが輝くもう一つの分野は、競合情報と外部データの統合です。このプラットフォームは、競合他社の価格、ウェブトラフィック、さらにはマーケティングキャンペーンのカレンダーなど、関連性のあるあらゆるデータを追加の入力シグナルとして取り込むことができます。彼らは「競合他社の価格設定」とマーケティングカレンダーといった外部シグナルを組み込む能力を明示的に言及し、プログラム設計のおかげで新しいアルゴリズムや入力を容易に試すことができると述べています ¹¹.

自動化と自律性： Lokadは、このグループの中でいわば「完全にロボット化された」サプライチェーンプランナーに最も近い存在です。考え方としては、一度スクリプト（ロジック）が設定され検証されれば、システムは日々（または日中）稼働し、人間の介入なしに推奨される意思決定を生み出すというものです。多くのLokadユーザーは、実際に購買発注や価格提案を自動生成し、プランナーがそれを簡単に確認するか、あるいは自動実行していることを信頼しています。システムは自己適応型で、最新データを用いて毎日予測モデルを再訓練し、それに応じて再最適化するため、手動でのパラメータ調整は不要です。実際、Lokadは終わりなき調整という業界習慣をあえて批判しており、自社システムは**「単純な時系列手法に依存しない」こと、また「ユーザーによる絶え間ない手動調整」*なしで動作することを強調しています ⁹. 季節性、イベント、不規則な需要の調整という重労働は、プランナーが予測を微調整するのではなく、アルゴリズムが担います。重要なポイントは実行可能性であり、Lokadは単なる診断結果ではなく、意思決定（または実行可能な推奨事項）を出力します。例えば、いくつかの「コントロールタワー」ダッシュボードが単にある商品の品切れリスクを指摘するだけなのに対し、Lokadは即座に発注数量や対応すべき価格変更を推奨します。これは、無人運用を望む場合には極めて重要であり、システムは*「単にアラートを表示するのではなく、是正措置を推奨する」**ことを目指しています ¹². 急速に変化するEC環境では、問題を知らせるだけのシステムでは不十分で、何をすべきか、あるいは自動で対処すべきかを示す必要があります。Lokadは後者を実現するために構築されています。

このような称賛を受ける一方で、Lokadに対して懐疑的になるべき点は何でしょうか？主な注意点は、Lokadのアプローチが非常にカスタムで技術的であることです。スイッチを入れるだけで、即座に素晴らしいユーザーインターフェースと全ての回答が得られるプラグアンドプレイ型SaaSではありません。ユーザー企業には、一定レベルのデータ成熟度と定量的手法への信頼が求められます。また、特に初期設定時には、Lokadのチーム（「サプライチェーンサイエンティスト」）に暗黙の依存関係があり、事実上、彼らが拡張チームとしてソリューションの実装を支援します。これは、明確に定義されたソフトウェアをインストールする場合とは異なるモデルです。もしクライアントがそのような協調的でエンジニアリングに重きを置いたプロセスに参画する準備ができていなければ、苦労するかもしれません。しかし、このモデルこそが、最適化の深みを可能にしているのです。柔軟性とパワーと使いやすさとの古典的なトレードオフにおいて、Lokadは明確にパワーと柔軟性を重視しています。

マーケットプレイスの視点から見ると、Lokadの価値提案は特にECのニーズに合致しているようです。EC企業は品切れ、在庫過多、プロモーションやインフルエンサーによる激しい需要急増といった多くの課題に直面しており、ERPやWMSで埋められなかった隙間を、BIダッシュボードやアドホックなPythonスクリプトなどのツールを寄せ集めることで補っています。Lokadは、これらすべてのシグナルを取り込み、ほぼ最適なプランを出力する専門レイヤーとして位置づけられています。彼らは、市場やERPが提供する単純なツールと自社を明確に対比し、それらはEC企業が扱う問題の**「ごく一部しか対応していない」**と指摘しています ¹³ ¹⁴. 例えば、Amazonのマーケットプレイスが翌週の需要予測を提供したとしても、サプライチェーンコストや複数倉庫の在庫は統合されません。Lokadの技術は、SKUレベルまでのすべての関連シグナルを問題なく処理し、ユーザーがスプレッドシートを手動で操作する必要もないよう設計されています ¹⁵. これは、広告通りに提供されれば非常に強力な価値提案です。

まとめると、Lokadはその包括的な最適化能力と先進技術により、我々のリストのトップに位置します。プログラムプラットフォームを通じて、在庫、価格設定、その他の要素を一体化して最適化できるという、共同最適化基準に真正面から応える能力があります。Lokadは、確率的予測および経済的ドライバーを駆使しており（流行る前からクオンタイル予測を実施していたことは、M5コンペティションでの成功によって示されています ¹⁶）、代替やマルチチャネル相関といった複雑な効果も恐れません。そのアーキテクチャはスケーラブルで、コスト意識も高く、力任せのインメモリ計算の罠を回避しています ³ ⁴. 自動化のレベルも非常に高く、手動調整は最小限に抑えられるとともに、単なる洞察ではなく意思決定を生み出すことに注力しています ¹². Lokadに対する懐疑は、技術が機能するかどうかよりも、組織がこのようなデータサイエンス重視のソリューションを受け入れる準備ができているかどうかに関わる部分が大きいです。また、大規模な実績についても疑問が残ります。Lokadは一部の競合他社より規模が小さいものの、（ケーススタディにおいては産業向けアフターマーケット流通業者やファッションEC事業者などの）著名なクライアントを有しています。以上の理由から、我々の調査において、Lokadは真に最先端のEC最適化ベンダーとして最高評価を獲得しています。

2. RELEX Solutions – AI駆動型小売最適化（ただし注意点あり）

RELEX Solutionsはフィンランド発のベンダーで、小売計画分野において急速に台頭しており、予測と補充に関して旧来の大手と並んで言及されることが多いです。RELEXは需要予測、在庫補充、割り当て、品揃え、労働力スケジューリング、そして最近では価格およびプロモーション最適化に至る統合プラットフォームを提供しています。彼らのコアな強みは食料品および小売（実店舗を含む）にあり、オンラインとオフライン両方のチャネルで計画を立てる能力を強調し、EC事業者にも積極的にアプローチしています。純粋なECユーザーにとって、RELEXの価値は、エンドツーエンドの計画、すなわち、先進のアルゴリズムを用いて需要変動に対応しながら、適切な在庫を適切な場所に、適正な価格およびプロモーションで提供する点にあります。

RELEXはそのAIと機械学習の活用を強くアピールしています。実際、CEOのMikko Kärkkäinenは小売業における「プラグマティックAI」の熱心な提唱者です。Kärkkäinenによれば、**「AI駆動型の在庫管理システムは、需要に影響を与える何百もの要因を処理する」ことで予測精度を向上させるとのことです ¹⁷. 彼はさらに、天候データのようなものは単一の要因ではなく、彼らの機械学習モデルが考慮する「何百もの異なる要因」（温度、湿度など）であると強調しています ¹⁸. これはRELEXのアプローチを象徴しており、予測シグナル（天候、プロモーション、祝日、ソーシャルメディアのトレンドなど）を幅広く収集し、機械学習を用いてそれらを売上に相関させるのです。その利点は、システムが、例えば、猛暑が祝日週末と組み合わさった時に特定の飲料の需要にどのような複合的影響を与えるかといった複雑なパターンを検出できる点にあります。しかし、懐疑的な見方としては、「何百もの要因」を謳うこと自体が、実質的な改善以上にマーケティング色が強いのではないかという点が挙げられます。ある一定の水準を超えると、入力を増やしても収穫が逓減するか、モデルがノイズに過剰適合して精度を下げる可能性があります。また、モデルがブラックボックスになってしまい、何百もの変数を実際に使用するモデルを人間が理解するのは事実上不可能です。RELEXは、「ガラスの箱」のアプローチ（AIの透明性）を提唱することで、このブラックボックス問題への懸念に対抗しようとしています。彼らは、単なる結果だけでなく、主要な要因をプランナーが確認できる予測の可視性を提供することについて語っています。しかし現実には、何百もの特徴量を持つニューラルネットワークやグラディエントブースティングモデルを完全に解釈することは難しく、プランナーはシステムを信頼せざるを得ないでしょう。これはAI/MLにおける一般的なトレードオフであり、RELEXは「大量のデータを投入し、アルゴリズムに解決させる」**という立場を取っています。

これで成果は出ているのでしょうか？RELEXの顧客は、従来手法が苦戦するプロモーションおよび季節のシーンにおいて、予測精度の向上や品切れの減少が報告されています。例えば、RELEXは天気予報を統合し、異常気象時に特定の天候に敏感な製品の予測誤差を最大75%削減したと主張しています ¹⁹. このような具体的な主張は、部分的に選ばれた事例である可能性があるため、慎重に受け取るべきです。それでも、RELEXのアプローチは、最新情報に基づいて予測を調整することで、短期予測（「需要センシング」）に付加価値をもたらしていると考えられます。実際、彼らの機械学習モデルは、新たなデータシグナルによってベースライン予測を継続的に微調整しているのです。これは、リアルタイムに近いデータを使って短期予測を更新する、いわゆる需要センシングに類似しています。RELEXは、その資料内で需要センシングをより広範なML予測に統合しており、別個のモジュールとして扱っていません。状況の変化に応じ、*「継続的で自動化された再予測」*を推進しています。

共同最適化の観点から、RELEXは在庫に加えて、価格設定と品揃えをどれだけうまくカバーしているのでしょうか？従来、RELEXは補充と割り当て（店舗やDCが品切れにならないようにすること）に最も強みを持っていました。どの製品をどの店舗に、またはどのSKUを扱うかを決定する品揃え計画もその一部であり、プラノグラム最適化（スペースプランニング）も含まれていました。価格最適化はこれまでの課題でしたが、2022年にRELEXはAI駆動型価格最適化機能を導入しました ²⁰ ²¹. 彼らはこれをプロモーション計画とシームレスに統合する形で展開しています。例えば、プロモーション計画ツールと価格最適化ツールは同じデータとUIを共有しており、小売業者はプロモーションを計画すると、システムが最適な割引率やタイミングなどを推奨し、その結果、在庫への影響も自動的に考慮されます。これは明らかに共同最適化に向かっています。しかし、RELEXが真に価格と在庫を同時に最適化しているのか、それとも依然として順次的（まず価格を決定し、その後在庫フローを調整する）に行っているのかは不明です。理想的な共同最適化では、価格設定時に在庫の制約も考慮すべきであり（例えば、供給が制約されている場合、過度なプロモーションは控えるなど）、RELEXの統合プラットフォームはそのような部門横断的な視点を可能にしていると考えられます。システムは「このプロモーションを全店舗で実施するにはDCの在庫が足りない」といったことに気づき、警告や調整を行うでしょう。彼らは、計画が実行可能であることを保証するために、価格とプロモーションをサプライチェーンと連動させる必要性を強調しています ²². つまり、RELEXはサイロを打破する重要性を十分に認識しています。

内部関係者の見解として、RELEXの魅力は、需要、供給、オペレーションといったすべてをユーザー向けの一つのプラットフォームに統合している点にあります。例えば、マーチャンダイズプランナーは、各部門間で共有された予測や制約を確認できるようになっています ²². これは、プランナーが価格決定がサプライチェーンに与える影響や、その逆を理解できることを意味し、この可視性はサイロ化したツールに比べ大きな進歩です。しかし、可視性は完全なアルゴリズム最適化と同義ではありません。RELEXは非常に一貫性のあるユーザー体験とデータモデルを提供しているものの、意思決定が依然として段階的に行われている可能性があります。価格最適化が理想的な価格を出力し、その後在庫モジュールがそれに基づいて計画を立てる、という流れかもしれません。緊密な連携により矛盾は生じませんが、在庫コストを同時に考慮して利益を最大化する単一の最適化問題を解いているとは限らないのです。後者を実現するのは複雑であり、その明示的な試みは、先に述べたLokad以外にはほとんど見られません。

技術アーキテクチャの観点から見ると、RELEXは非常に先進的です。彼らは初期の頃に、時系列や階層データに最適化されたカラム型の自社製インメモリデータベースエンジンを構築し、数千の店舗×SKUの予測を高速に計算できるようにしました。多くの事例研究では、RELEXがスプレッドシートやレガシーシステムに取って代わり、週次から日次の計画、または画一的な計画ではなく店舗別の計画といった、より細やかなデータ粒度の対応を可能にしたと報告されています。ECの観点からは、RELEXはグローバルなオンラインストアのSKUレベルの予測も問題なく扱えることを意味します。彼らはクラウド展開を行っており、スケールアウトも可能です。RELEXの技術に関して具体的なコストクレームは見受けられず、効率的な計算能力を誇っている点（学術的な創業者がアルゴリズムを大幅に最適化している）がむしろ評価されています。一つの特徴として、インメモリの「ライブデータベース」コンセプトがありますが、設定を誤ると大量のRAMを要する可能性もあります（これは推測に過ぎません）。一般的に、RELEXのスケーラビリティは市場で懸念される問題ではなく、何万ものSKUと多数の店舗を有する巨大な食料品チェーンにも対応しており、これは多くのEC事業者が扱うデータ量と同等かそれ以上です。

自動化 とプランナーの役割: RELEXはしばしば「自律的プランニング」と同時に「拡張判断」について語ります。彼らは自社ツールをプランナーを排除するブラックボックスとして位置付けてはいません。実際、ユーザビリティ―例えばUI、設定可能なダッシュボード、そして例外管理―を強調しています。このシステムは自動で発注書や転送の推奨を生成しますが、通常はプランナーがレビューし、承認します（特に導入初期段階では）。RELEXには「予測例外」という概念があり、AI予測が何らかの異常により大幅に逸脱した場合、フラグが立てられます。また、システムが何故その提案をしているのか（大まかには「天候が暑かったため、50%の持ち上がりを予測する」というように）をプランナーが確認できるシミュレーション機能も備えています。Mikko Kärkkäinenは、「最先端のソリューションは、実用的なAIと計算能力を活用し、人間の介入無しに自律的にタスクを最適化する」 と述べ²³、また*「自己学習・自己調整する自律的な小売プランニングはサイロを打破する」* とも記述しています⁵。少なくともビジョンとして、RELEXは大部分を自動運転のシステムにすることを目指しています。我々はここで完全な自律性についてはやや懐疑的です：RELEXを利用する大手小売業者は依然としてプランニングチームを有しており、そのチームはおそらく例外対応型で運用され、部分的な自律性を発揮しているのです。

RELEX（および同様のベンダー）における注視すべき矛盾点の一つは、極度の柔軟性と極度の自動化の両立という約束です。彼らはシステムが非常に柔軟であると主張しています（例：価格ルールの動作設定や予測モデルの調整が可能など）が、一方で自動調整も行うと述べています。ここには緊張関係があります。ユーザーが多くを手動で上書きできる場合、実際にはシステムがその手動設定に依存してしまうかもしれません。本当にAIを信頼しているなら、上書きの必要は次第に少なくなるはずです。RELEXの*「自動調整」*という言及は後者を意味し―すなわち、時間の経過とともに手動パラメータの調整が少なくなることを示唆しています⁵。また、RELEXのアプローチがプランナーをより監督者の役割にすることが示唆されているのも見受けられます。たとえば、ある記事ではRELEXのシステムがプランナーを手動作業から解放し、戦略的な動きに集中させたと述べられています²⁴。それでも、SelectHubのレビューを集計した情報源によれば、RELEXの一部が「使いにくい」と感じるユーザーや、特定の制約（運賃制限など）の予測において迂回策を講じる必要があるという問題も報告されています²⁵。これは、すべてが魔法のように完璧というわけではなく、ユーザーが介入せざるを得ない局面や、ツールがスムーズに動作しない部分が依然として存在することを示しています。

既知の問題や懸念点: RELEXには、一部の例に見られるような公に文書化された「失敗」事例（訴訟の見出しなど）はありません。一般的に、同社には好意的な噂が流れています。しかし、匿名化された内部情報では、非常に大規模かつ複雑な環境でRELEXを実装すると問題が浮上する可能性があると囁かれることがあります。たとえば、データ統合は困難であり（ゴミが入ればゴミが出る―クライアントのデータが乱雑であれば、RELEXは不適切な計画を生み出し、その責任がツールまたはデータどちらかに帰せられる）、また、RELEXの急成長（多くのクライアントを迅速に獲得している）により、Lokadのような手厚いサポートが得られない場合もあります。これはソフトウェア自体の批判ではなく、現実の成果に対する懸念―RELEXプロジェクトのうち、約束されたKPIを達成しているのはどれくらいか―に関するものです。ベンダーは好転事例（「Y顧客における在庫X%削減！」など）を好んで引用しますが、数値が実現しなかった例に触れることはほとんどありません。我々は、他のベンダーと同様に、RELEXにもいくつか成果が十分でなかったプロジェクトが存在すると考えており、それは例えば、変更管理の不備や、小売業者がシステムを十分に信頼せずに活用できなかったことが原因かもしれません。パートナーサミットでは、Blue Yonderでさえ、非効果的な変更管理やデータの問題が多数のプロジェクト失敗の要因であると認めています²⁶―同様のことがRELEXの実装にも当てはまる可能性があります。

もう一つ注目すべき点として、RELEXは多くの外部データを取り入れる傾向があります。これにはGoogleトレンド、来客数予測のためのモバイル位置データなどが含まれます。eコマース事業者にとっては、来客数のようなデータは無関係な場合もありますが、天候やトレンドといった他のデータは重要です。本当にこれらすべてのデータフィードが必要なのか疑問視すべきです。あるeビジネスでは、販売履歴に基づくシンプルなモデルがほぼ同等の精度を発揮するかもしれません。RELEXは、より多くのデータがより優れた予測をもたらすという考えを確実に売り込むでしょう。M5コンペティションの結果（私たちの知る限りRELEXは公に参加していませんでした）では、洗練されたモデルがシンプルなモデルを上回ったものの、その差は僅かでした。上位の手法はしばしば、多くのモデルをアンサンブルしたものであり、これはRELEXが内部で行っていることに似ています。しかし興味深いことに、純粋な機械学習アプローチが伝統的手法を一掃しなかったという結果もあり、入念に調整された統計モデルの組み合わせが勝利する傾向にありました。つまり、RELEXの主張をM5のような基準と照らし合わせると、確率的予測には確かに価値がある（実際彼らもそうしています）が、上位手法の間に唯一無二の秘密兵器はなく、入念なモデリングが重要であることが分かります。RELEXがこのような標準データセットにおける精度を公表していないため、我々は慎重な姿勢を崩しません。RELEXを検討するすべての人への懐疑的な助言は、改善の具体的証拠を要求し、明確な基準値を定義することです。例えば、RELEXが「予測精度を30%向上させた」と主張する場合、どの指標や基準に対して30%なのかを明確にするべきです。多くの場合、ベンダーは自社ツールを良く見せるシナリオ―例えば、素朴な予測や不調の年と比較して―に対して向上率を測定します。この研究の指針は、パフォーマンスの主張において基準値の明確さを要求せよというものです。

要するに、RELEX Solutionsは、需要、在庫、価格設定という主要な分野を統合的に扱い、最新のAI/ML技術を広範に活用しているため、トップベンダーとして評価されます。その強みは、数多くの要因を考慮した非常に詳細な予測、強力なプロモーションおよび季節計画の能力、そして全ての関係者に単一の真実の情報源を提供する統一プラットフォームにあります。拡張性（大規模小売で実証済み）、カニバリゼーション対応（製品間の影響を考慮する高度な予測モデルを通じて²⁷）、マーケットプレイス/オムニチャネル（オンラインとオフラインを同時に計画でき、場合によっては競合他社のデータも取り込める）といった点で評価されます。RELEXはまた、自動化に向けた推進も行っており、自動調整モデルや自律的な意思決定の主張をしていますが、実際には一部でユーザーの監視が残ります。主な注意点は、そのAI重視のアプローチに伴う複雑性と不透明性であり、ユーザーはある程度ブラックボックスを信頼しなければならず、マーケティングにおける誇大広告と実際の成果を区別する必要がある点です。我々はRELEXを高く評価しますが、注意書き付きです：強力なツールである反面、十分に活用するためには慎重な実装とデータ主導の文化が求められます。また、潜在的なユーザーには業界内の**「AIウォッシング」**に注意するよう奨励します。RELEXのメッセージは、実際に技術が存在するため比較的信頼できますが、Mikkoの「何百もの要因」に関する発言¹⁷でさえ、競合他社に比べて劇的に優れた成果を保証するものではなく、単なるAIへの熱狂とみなすべきです。eコマースの文脈では、RELEXは確かに役割を果たすことができますが、その結果を厳密に測定し、すべての豪華な機能が実際に使用されているのか、単にソフトウェア上で遊休状態にあるだけなのかを注視してください。

3. Blue Yonder – レガシー巨人の変革（主張対現実）

Blue Yonder（旧称JDA Software）は、サプライチェーンソフトウェアの巨人であり、小売業や製造業のプランニングシステムにおいて何十年もの歴史を有します。同社は、予測、補充、倉庫管理、輸送、労働力管理、価格設定を網羅する包括的なスイート（2020年に価格専門のRevionicsを買収後）を提供しています。eコマース事業者にとって、Blue Yonderは大手小売業者やCPG企業向けに構築されたソリューションを提供しており、この分野における企業向けの巨人と見ることができます。しかし、そのレガシーには、堅牢な機能性、拡張性、業界経験という強みと、重大な弱点（一部技術の時代遅れ、複数の買収による統合の問題、そしていくつかの目立つ失敗事例を含む実績）が伴います.

統合最適化の観点では、Blue Yonderの事例はやや混在しています。同社は、すべての要素に対応するコンポーネントを確かに備えています。例えば、予測にはLuminate Demand Edge、在庫管理にはLuminate Allocation/Replenishment、価格設定にはRevionicsを提供しています。理論上、これら三つを利用することで、調和の取れた戦略を実現可能です―例えば、予測結果が在庫計画と価格最適化モデルの両方に供給され、価格最適化は需要弾力性（本質的には異なる価格帯での需要予測）を考慮に入れることができます。Blue Yonderは、**エンドツーエンド、「計画から実行まで」統一されたLuminateプラットフォームのコンセプトを確実に市場に訴求しています。しかし実際には、これらのモジュールの多くは個別に進化し、最近になってようやく統合されたに過ぎません。たとえば、Revionicsの価格最適化エンジンは独自の歴史を持ち、買収後に統合されました。Blue Yonderの課題は、これらを一つの一貫したソリューションとして感じさせることにあります。同社は、歴史的に分断されたスイートを有していたことを認識しており、その結果として、2023年にSnowflakeクラウド上での「単一のデータモデルとアプリケーションプラットフォーム」への大規模なアーキテクチャ変革を発表しました²⁸。これは大変重要な動きで、データサイロを解消すべく、すべての製品を一つの大規模なクラウドデータリポジトリ（Snowflake）から読み書きするよう再設計することを意味します。CEOは、すべてのBlue Yonderアプリケーションが流動的にデータを共有する「世界のためのサプライチェーンオペレーティングシステム」**というビジョンを打ち出しました²⁸.

我々はこのビジョンを、有望でありながらも問題を孕むものと捉えています。有望であるのは、実現すれば多くの統合に関する頭痛の種―例えば、需要計画と価格設定間のバッチインターフェースが不要になり、文字通り同じSnowflakeのデータを参照できる―が解消されるからです。問題なのは、極めて野心的であり、リスクが高い点にあります。Blue Yonderのパートナーコンサルティング会社でさえ、「ビジョンは素晴らしいが、統合を完全に排除するのはほとんどのクライアントにとって過度に楽観的だ」 と指摘しています²⁹。クライアントは様々な場所にデータを保有しており、すべてが整然とSnowflakeに収まるとは限らないため、Blue Yonder以外のシステムに対してはカスタムの統合が依然として必要になるでしょう²⁹。要するに、Blue Yonderの戦略は進行中の作業であり、「レガシー」と見なされることへの対応策なのです。同社は、旧システムを一夜にして廃止する「クリフイベント」を強制しないと明言し、代わりにレガシーモジュールを徐々にマイクロサービス化し、顧客が自社のペースで移行できるようにすると述べています³⁰³¹。これは、現時点でBlue Yonderの顧客が、例えば旧JDAのオンプレミス需要計画を使用し、クラウド上のRevionicsと統合している可能性があることを示唆しています。完全に統一されたプラットフォームは、一般提供までには数年先になるかもしれません。その間、Blue Yonderにおける統合最適化はより手作業的であり、ツールを併用するものの、しばしばユーザー自身が調整を行う必要があります（例：価格チームの行動が在庫計画に反映されるようにするなど）。

Blue Yonderは、紙の上では数多くの技術要件を満たしているように見えます。例えば、現在は予測に機械学習を組み込み（2018年に買収したリテール向けAIを専門とするBlue Yonder GmbHの技術を活用）、様々な用途で**「説明可能なAI、機械学習、さらには生成AI」を使用していると主張しています³²。確かに、補充最適化やアロケーションなどに関する先進的なアルゴリズムが何十年にもわたって開発されています。しかし、Blue Yonderには多くの技術的負債**があるため、懐疑的に見る必要があります。同社の多くの中核アルゴリズムは90年代または2000年代初頭にi2 TechnologiesやJDAによって開発され、その後強化はされたものの、最近のクラウドリライト以前は旧式のアーキテクチャ上で動作していました（一部ソリューションではOracleデータベースが必要でした）。ゆえに、Blue Yonderが「認知的、機械学習駆動のプランニング」を謳う際には、本当に新技術なのか、単なる新しいブランディングなのかを疑問視すべきです。例えば、彼らの需要計画は現在、ホリデー時の予測上昇を見積もるために機械学習を使用しているかもしれませんが、基盤となるアーキテクチャが本当に現代のクラウドコンピュートパワーを活用しているのか、またはレガシーシステムに組み込まれているために制約を受けているのかは疑問です.

具体的な歴史的事例として、Blue Yonder（JDA）は2010年にi2 Technologiesを買収しました。i2は最適化重視のソリューションで知られていましたが、同時に実装失敗でも知られていました。特に、JDAがi2を買収した後、Dillard’s（大手百貨店）が、i2のソフトウェアが約束通りに機能しなかったとして2億4600万ドルの訴訟に勝利したことが有名です³³³⁴。これは大きな打撃であり、ソフトウェアおよびプロジェクトが極めてひどい失敗に終わり、顧客が支払った金額の30倍以上の損害賠償を受ける結果となりました。この一件は、15年前の出来事であるにもかかわらず、技術が過大に約束されるか、あるいは適切に実装されなかった場合、非常に評判の高いベンダーでも大きな失敗を犯す可能性があることを示しています。Blue Yonderはそのコストを吸収し、教訓を得たのです（ということを期待します）。これは、我々が懐疑的な姿勢を維持する理由を際立たせています。大手ベンダーは「世界クラスの製品」を謳うかもしれませんが、宣伝通りに動作しないという証拠は存在している場合があるのです。すべてのベンダーには失敗があり、Blue Yonderは少なくとも一度は公の裁判にまで発展した失敗を経験しています.

Blue Yonderの評価すべき点として、同社は問題への対応をよりオープンにしています。2023年のパートナーサミットでは、「レッドプロジェクト」（問題のある実装）について率直に議論し、その主要な原因はアルゴリズム自体ではなく、**「非効果的なチェンジマネジメントおよびデータ移行／統合の問題」**であると明らかにしました²⁶。彼らは、データを正確に扱い、顧客がプロセスに適応できるよう支援することが極めて重要であると強調しました。この内省は好ましく、Blue Yonderがプロジェクト失敗の原因を理解している証拠です。また、これは我々の全体的な分析テーマとも一致しており、問題はしばしば計算が間違っているのではなく、現実世界での統合が困難であることに起因しているのです。Blue Yonderがデータ統合の課題を指摘している点は、同社のスイートがいかに複雑であるかを反映しており、もしモジュールが真にシームレスに統合されていれば、データ移行はこれほどの頭痛の種にはならなかったはずです。実際に問題が生じているという事実は、顧客が完全なスイートを活用するために大規模なデータ調整を余儀なくされた可能性を示唆しています。Snowflakeによる統一データレイヤーはこの問題の解決を目指していますが、前述の通り、まだ初期段階です.

eコマースシナリオにおけるBlue Yonderの現在の能力を検証してみましょう：

需要予測: Blue Yonder Luminate Demand（特に Demand Edge）は、天候、イベント、価格設定など多くの要因を取り入れるために機械学習を活用しています。彼らは確率的予測へも舵を切っており、少なくとも計画の際に信頼区間や分位数を使用できるようにしています。ブログでの一例として、彼らは単にAIで要因をベースラインに重ねるのではなく、最新データを用いて日々、基礎から予測を再構築し、カレンダーの変動などを自動的に考慮し、新たな実績値が入ると自己修正する、と述べています ³⁵ ³⁶。これにより、プランナーが季節性の手動調整やプロファイルの維持を行う必要がなくなり、モデルがそれらを学習し適応することを主張しています ³⁶。これは最先端の予測手法に大いに沿ったものです。Blue Yonderのアプローチは理論上、継続的な学習、不確実性の認識（過大・過小予測のリスクやコストトレードオフについても言及 ³⁷）および、機械学習を用いて複雑な関係性（異なる天候やプロモーションがどのように需要を左右するか、など）を検出するという点で堅実です。
在庫および補充: これは長らくJDA/Blue Yonderの強みでした。彼らは多段階在庫最適化（MEIO）を提供しており、リードタイムや需要のばらつきなどを考慮して、eコマース向けの配送センターやフルフィルメントセンター全体の在庫レベルを最適化し、目標サービスレベルを達成できるようにしています。Blue Yonderのツールは推奨発注量や安全在庫などを生成できます。歴史的には、これらのアルゴリズムはルールやヒューリスティックに基づく、または特定の問題に対して線形計画法が使用されていました。現在は機械学習ベースの予測で補強されつつある可能性がありますが、コアの最適化はオペレーションズ・リサーチとシミュレーションの混合であると考えられます。BYは大規模なSKU計画にも確実に対応でき、多くのフォーチュン500企業が店舗補充にJDAを利用しており、これは大規模なeコマース倉庫での顧客供給と同等の規模です。
品揃え: Blue Yonderは、どの店舗にどの製品ミックスを展開するかという品揃えの意思決定を支援するカテゴリー管理ツールを提供しています。eコマース専業者の場合、品揃え計画は新製品の掲載や削除の決定を意味するかもしれません。BYのツールは、属性や実績データを用いて品揃えの変化を評価できます。しかし、これは通常、連続的なものではなく、定期的な戦略プロセスです。
価格最適化: Revionicsの買収により、Blue Yonderは小売業界（特に食料品および一般消費財チェーン）で広く使用される堅牢な価格最適化エンジンを獲得しました。これにより、基準価格、プロモーション割引、値下げの設定が可能となりました。RevionicsはAIを用いて価格弾力性や競合の価格影響をモデル化し、例えば「.99」で終わるなどの価格ルールを考慮しながら、マージンや収益成長などの目標を達成するための価格変更を推奨します。Blue Yonderの一部として、Revionicsは現在Luminate Pricingとして知られています。理論上、このエンジンはBlue Yonderの需要予測と組み合わさることで、価格変更が需要や在庫に与える影響をシミュレーションし、最適な価格を選定できる閉ループを実現します。Blue Yonderはこれを 「AIによって支えられる自律的価格設定」 としてマーケティングしており、必要に応じて（希望すればeコマースでは日中も）頻繁に実行可能です。

大きな疑問として、これらの要素は実際にどれほどうまく連携しているのか？ Blue Yonderは連携していると主張しています。例えば、彼らは価格ソリューションが需要ソリューションからの予測を取り込み、その結果を在庫ソリューションが発注計画に活用する価格を出力できると言うかもしれません。しかし、もしその統合がリアルタイムでなく、カスタムのIT作業を必要とする場合、ループは期待するほど緊密ではないかもしれません。現実的には、2023年のeコマースユーザーは、価格ツールを供給ツールとは別に利用し、予測弾力性の週次バッチ更新を行っている可能性があります。これは共同計画ではあるものの、瞬時に最適化を完了するという「聖杯」とは言えません。

AI/MLの主張に関して、Blue Yonderはマーケティングで流行語を多用する傾向があります。彼らは「コグニティブ」や「機械学習駆動」などの用語を使用しますが、その実質が伴っているかどうかを検証すべきです。実質がある証拠も存在しており、例えば、元々ドイツの子会社であったBlue Yonderは、ニューラルネットを用いて2014年の初期小売予測コンペティションで優勝するなどのアルゴリズムを開発し、公開していました。また、Blue Yonderの特許ポートフォリオは400以上の特許を保有しており、多くの研究開発投資の証となっています ³⁸。しかし、特許の数が直ちに製品の質を保証するわけではなく、単に多くの技術を試みた結果であるに過ぎません。懐疑的な視点としては、Blue Yonderに具体的な成果を示すよう求めるべきです。例えば、M5コンペティションや中立なベンチマークに参加したかどうか、そして具体的なビフォー・アフターの数字が示された事例はあるのかといった点です。いくつかの事例は存在しますが、ベンダー事例は往々にして華やかで基準の明確さに欠ける傾向があります。Blue Yonderが「ある小売業者が我々の価格設定利用でY%の利益増を実現した」と述べても、文脈がなければそれは単なるマーケティングに過ぎません。

Blue Yonderに関しては、コストと複雑性も考慮する必要があります。これらは大規模なエンタープライズシステムであり、実装には数ヶ月から数年を要し、ソフトウェアのセットアップだけでなく業務プロセスの再設計も伴います。Blue Yonderは通常、同社のプロフェッショナルサービスまたはパートナーファームによる実装を必要とします。所有コスト（ライセンス＋サービス＋IT）は非常に高額になる可能性があります。特に中規模の純粋なeコマース事業者にとっては、Blue Yonderは過剰であるか、または機敏なSaaSソリューションと比較して実装が遅すぎる可能性があります。大企業ですら、時には尻込みすることがあります。示唆に富む事例として、2018年にLidl（大手グローバル小売業者）が€500MのSAPプロジェクトをニーズを満たせなかったためにキャンセルした例がありました ³⁹。これはSAPの例ですが、巨大プロジェクトが失敗し膨大な予算を消費する可能性を示しています。Blue Yonderのプロジェクトも同様に複雑であり、パートナーであるJBF Consultingは、競合のManhattan Associatesが新プラットフォームのための再実装を要求する一方で、BYはより穏やかな移行を試みていると指摘しています ⁴⁰。Manhattanが「新技術への再実装」を選択した事実は、これらの移行が些細なものではないことを示唆しています。Blue Yonderは、段階的な進化によって悪夢のようなアップグレードを回避しようとしていますが、それは同時に顧客が現状、完全に最新の技術ではなく、新製品を待っている状態であることも意味します。

自動化の観点から見ると、今日のBlue Yonderは、LokadやRELEXが目指すほど自動化されていない可能性が高いです。多くのBY顧客は、ツールを使って推奨を生成し、その後プランナーが承認または調整を行っています。Blue Yonderは「自律的サプライチェーン」という概念を推進しており（特に2021年にPanasonicに買収されてからは、IoTデータを自動化された意思決定に接続することについて語っています ⁴¹）、しかし、顧客の多くは一部の決定はシステムに任せ、他は手動で上書きするというハイブリッドな運用を続けています。例えば、システムが発注を提案し、プランナーが例外を確認する（RELEXの場合と同様）ケースや、価格システムが価格変更を提案し、それをマーチャンダイジングマネージャーが確認してブランド戦略に合わないものを却下するケースがあります。ソフトウェアは多くのことが可能ですが、企業には一夜にして変わらない既存のプロセスがあります。

競争インテリジェンスとマーケットプレイス: Blue Yonderの価格ソリューション（Revionics）は、競合の価格データを取り入れる機能があり、競合対応の機能を備え、ライバルの価格情報を取り込んで自社の価格を調整することが可能です ⁴²。したがって、eコマースにおいて競合の価格フィードが利用可能であれば、Revionicsは最適化の際にそれを考慮することができます（例えば、価格イメージを維持するために競合よりもX%以上高くならない、または必要に応じて最低価格に合わせるなど）。これは価格の共同最適化においてプラスとなります。一方、Blue Yonderは、Amazon向けのチャネルアドバイザーのようなツールを提供するeコマース特化型ベンダーとは異なり、マーケットプレイス管理のモジュールを特に持っていません。つまり、Blue Yonderはコアな計画には利用できても、マーケットプレイス特有の戦術（広告、バイボックスなど）を管理するための別ツールが必要になる可能性があります。これはBlue Yonderの範囲外であり、非難するものではなく、伝統的なベンダーが対応していないeコマースの側面が存在するという注意点です（公正を期すために言えば、LokadやRELEXも広告入札などには対応していません）。

Blue Yonderの規模と歴史を考慮すると、そのメッセージに内在する矛盾点を精査する必要があります。例えば、Blue Yonderは自社のコマースプラットフォームで「リアルタイムのパーソナライゼーションと価格設定」を謳っている一方で、プランニングソリューションは従来、夜間計画や週次再計画といったバッチサイクルで運用されてきました。彼らはよりリアルタイムなデータ活用へと移行中であり（Snowflakeとのパートナーシップはほぼリアルタイムのデータ共有を可能にするためのものです）が、もしベンダーが「リアルタイム動的価格設定および在庫最適化」と主張するなら、システムが継続的に再計算しているのか、あるいはトリガーがあれば迅速に反応するだけなのかを問いただす必要があります。そして、品揃えの決定にリアルタイム性は本当に必要なのでしょうか？おそらく必要ありません―むしろ戦略的な判断となるでしょう。そのため、マーケティングの言葉が一貫性を欠いている場合、批判的な視点が鋭く働くのは当然です。Blue Yonderの広範なマーケティングは、長期戦略から即時実行まで何でも約束してしまうという罠に陥ることがあります。

Snowflakeのコスト懸念: ここで微妙ながらも重要な点を強調すべきです。Blue YonderがSnowflake上で構築されることで、顧客のコストモデルが変わる可能性があります。従来のライセンス制の代わりに、顧客はデータ量やクエリ頻度に基づいたクラウド利用料（Snowflakeクレジット）を支払うことになるかもしれません。もしBlue YonderのアプリケーションがSnowflake上で大規模な計算を行う場合、顧客のSnowflakeの請求額が急騰するリスクがあります。これは、使用量が多ければ多いほど支払いが増えるIBMメインフレームのMIPS課金に類似しており、システムを十分に活用できなくなる要因となり得ます。Blue YonderとSnowflakeは何らかの価格設定を協議していると思われますが、もし大規模データで計画シナリオが非常に頻繁に実行される場合、ユーザーは**「請求ショック」**に注意する必要があります。サプライチェーン計画は計算集約的になりがち（特にシナリオシミュレーションや確率計算の場合）であり、Snowflake上で非効率なプロセスが走れば大量のクレジットを消費してしまいます。Blue Yonderはおそらくこれを考慮に入れているものの、ユーザーは注意する必要があります。ビジネス価値と整合しないコストモデル（結果ではなく処理データ量に基づく課金など）は、過去の時代の落とし穴を思い起こさせます。

結論として、Blue Yonderは「次世代」ビジョンの実現という点で、純粋な新興ソリューションにはわずかに劣る評価を受けています。確かに豊富な機能性と多くの成功事例を有していますが、懐疑的かつ技術的な視点から見ると、同社は移行の途上にあります。彼らは近代化を試み、その過程でAI、統合、自動化について大々的に語っています。しかし、その変革が完全に実現するまでは、モジュール間のギャップや約束された成果を達成するために必要な実際の労力に対して、顧客は警戒するべきです。Blue Yonderのツールセットは、オムニチャネル事業を展開する多くの大手小売業者がeコマース側面でも利用しているように、eコマースの運営を確実に支援します。その幅広さは他のベンダーに類を見ず（ロジスティクスなども含めた広範な範囲をカバーしています）が、もしeコマース企業が需要と供給の最適化だけを必要とするなら、企業向けの堅牢性が特に必要でなければ、Blue Yonderは重すぎるかもしれません。我々の懐疑的な調査では、Blue Yonderの最先端であるという主張は、検証されるまではやや疑わしいものと見なされます―技術には確かな歴史があるものの、「AIファースト」で統一された本物のプラットフォームになったことを示す責任は彼らにあります。現時点では、非常に広範なソリューションと実装のためのリソースがある場合に選択すべき、強力だが扱いにくい選択肢としてBlue Yonderを見ることを提案します。もし迅速なROIや機敏性が最重要であれば、第一選択肢ではないかもしれません。

4. ToolsGroup – 在庫最適化の先駆者、フルリテールへの拡大

ToolsGroupはサプライチェーン計画分野のベテランであり、特に需要予測および在庫（ストック）最適化における専門知識で知られています。同社の主力ソリューションは、歴史的にはSO99+ (Service Optimizer 99+)と呼ばれ、サービスレベルに基づく在庫計画や多段階最適化に広く利用されてきました。言い換えれば、ToolsGroupは不確実性下で各拠点で「Xサービスレベルを達成するために必要な最小在庫」を企業が決定するのを支援する点に秀でており、これは配送やeコマース双方にとって重大な問題です。ToolsGroupは商業的に確率的予測を実装した最初の企業の一つであり、決定論的予測から脱却し、需要の全分布の利用を長らく提唱してきました ⁴³ ²。このアプローチは、今日私たちが最先端と考えるものと非常に合致しており、後に他のベンダーも採用しました。 eコマースの文脈では、ToolsGroupの強みは、需要が不規則な高SKU数の商品を取り扱いながらも最適な在庫目標を算出できる点にあります。多くのeテーラーは、販売頻度の低い「ロングテール」商品の取り扱いをしていますが、ToolsGroupの確率的モデルは、需要の散発的な性質を的確に捉えることで、単純に平均化してしまう誤りを回避し、最適な在庫計画を可能にします。また、彼らは機械学習を取り入れた予測モデルを通じて、新製品の導入、季節性、およびプロモーションにも対応しています。例えば、類似商品の履歴を参照するアナロジーや、属性に基づくモデリングを用いて新SKUの予測を行います。 ToolsGroupは、歴史的には在庫と需要に注力していましたが、近年、価格設定、プロモーション、および品揃えが補完的な要素であると認識しました。これに対応するため、ToolsGroupは2018/2019年にJustEnoughという企業を買収しました（JustEnoughは後にMi9 Retailの一部となり、その後ToolsGroupに売却されました）。JustEnoughのソフトウェアは、商品財務計画、品揃え計画、割り当て、ならびに値下げ最適化をカバーしており、本質的には価格値下げを含む小売マーチャンダイジング機能を提供します。この買収により、ToolsGroupは純粋なサプライチェーン分野から、小売計画と呼べる領域へと展開を拡大しました。現在、彼らはSO99+とJustEnoughの機能を組み合わせ、上位計画から実行まであらゆるフェーズをカバーする統合スイートとしてマーケットされています。

しかし、これらの製品の統合は懐疑論の重要な焦点となっています。2つの異なるソフトウェアプラットフォームを統合するのは容易なことではありません。ToolsGroupはデータモデルの統合に取り組んできました（彼らは「戦術的およびオペレーショナルプランニングに同じデータモデルを用いる」と述べ、一つの真実のバージョンを確保しています ⁴⁴）。彼らは、JustEnoughのプランニングシステムを在庫ハブと接続し、ほぼリアルタイムのデータフィードを実現する**“リアルタイム小売”**と呼ばれるソリューションを立ち上げました ⁴⁵ ⁴⁶。その考えは、セールスが発生する（または在庫が動く）と、そのイベントが即座にプランニングシステムへ流れ込み、その場で配分や補充の再計画が可能になるというものです。これは、ToolsGroupが固定された周期的サイクルではなく、より動的かつ継続的な計画を実現しようとしていることを示唆しており、他の近代的ベンダーと同様の狙いです。

しかし、詳しく掘り下げてみましょう。ToolsGroupが自社のソリューションを「リアルタイム小売―その瞬間の購買行動に対応する唯一のソリューション」⁴⁵と呼ぶのは、強い主張です。これは、何かが変わった瞬間に計画を調整できることを暗示しています。例えば、システムが自動的に在庫の転送を促すか、今日予想外の売上急増があった場合に注文の迅速化を行う可能性があるのです。もしそれが事実なら、計画と実行の境界が曖昧になります。しかし、懐疑的な見方としては、「リアルタイム」はおそらく、迅速に実行しやすい在庫の再配分など特定の機能に限定され、完全なアソートメントの再最適化など、リアルタイムでの実行には適さない他の機能には当てはまらない可能性があるということです。また、現代ではほとんどのベンダーが「リアルタイム」という用語をマーケティングに使用しており（多くは数分ごとまたは1時間ごとの更新を意味しますが、これは問題ありません）、ToolsGroupのCEO自身も需要の変化に応じて小売業者が迅速に軌道修正を行わなければマージンの侵食を招くと指摘しています⁴⁷。さらに、システムは新たな情報が入ると即座に再計算し、注文や転送を推奨すると主張しています⁴⁸。

仮にToolsGroupがJustEnoughを効果的に統合しているとすると、例えばユーザーはJustEnoughモジュールを用いて店舗またはチャネルごとのアソートメント計画を行い、そのデータをSO99+の在庫目標に反映させ、さらに最適化機能を使って端末商品のマークダウン価格設定を計画できるでしょう。これは、需要予測や在庫パラメータが計画されたマークダウンスケジュールを考慮している場合、共同最適化の側面をカバーしています。もし、結合された最適化モデルを構築していなければ、これは依然として逐次的なプロセス（先にマークダウンを決定し、その後在庫の結果を見る）になってしまいますが、データの流れという観点では統一されたソリューションです。

ToolsGroupが明らかに最先端の基準をクリアしているのは、確率的予測とサービスレベル最適化の面です。彼らは長年にわたり、単一の数字による予測は不十分であり、確率を用いて計画を立てる必要があると主張してきました。例えば、単に「期待需要 = 100」とするだけでなく、需要が120を超える可能性が10%であるという曲線も示します。そして、その最適化は、例えば95%の確率で需要を満たせるよう在庫レベルを決定するのです ⁴⁹ ⁵⁰。このアプローチは、不確実性や、相関のあるアイテム同士の場合には一定程度のカニバリゼーションにも対応します。興味深いことに、ToolsGroupは確率的予測を用いることで、より良い情報を供給し、SAP APOなどの従来型ERP計画システムの寿命を延ばすことができると提案していたこともあります¹ ⁵¹。これは、ToolsGroupの差別化要素が万能の計画UIよりも、予測と在庫管理の数学的精度にあることを示しています。

さて、自動化と使いやすさについてはどうでしょうか？伝統的に、ToolsGroupは一部ユーザーから「バックエンドエンジン」として評価され、UIがやや使いにくいとの指摘を受けていました。しかし、彼らは新しいWeb UIなどを通じてインターフェースの改善に努めています。より重要なのは、計画における自動化を強調している点です。例えば、「組み込みの自動化により計画作業負荷を最大90%削減」と主張しており⁵²、また顧客の事例では「プランナーの作業負荷が40～90%削減」や「在庫が20～30%削減」されたとよく報告されています⁵³ ⁵⁴。これらは大きな数字です。在庫削減の主張は、もし企業が以前非常に非効率で、予測に対する信頼不足から過剰な在庫バッファーを保持していた場合には、十分に説得力があります。プランナーの作業負荷の削減は、システムがより多くの作業を自動的に処理していることを意味します。これは、確率的システムが突発的な問題に対する対応を減らし、計画時の予測に基づいて対処するため、プランナーが手動で対応する必要が少なくなるという期待と一致します。しかし、90%の作業負荷削減は最も高いケースであり（例えば、従来10名のプランナーが1名に減った場合など、可能性はあるが一般的ではない）、また20～30%の在庫削減は、企業が元々「念のため」の在庫を過剰に抱えていた結果である可能性があるため、ToolsGroupが提示する数値はあくまで最良のシナリオであると考えられます。彼らが数値を範囲として示しているのは、結果がクライアントごとに大きく異なることを意味しています。

ToolsGroupの強みの一つは、安定性と特定分野へのフォーカスです。彼らは1993年に創業して以来、30年間にわたってサプライチェーン最適化に取り組んできました。Blue Yonderほどの大規模さはなく、RELEXほどのトレンド性もありませんが、忠実な顧客基盤とこの分野での深い専門知識を有しています。特に、在庫の収益性―つまり、品切れや過剰在庫を防ぐこと―に重点を置くeコマース企業にとっては、ToolsGroupのソリューションは非常に成熟しています。彼らのマルチエシェロン最適化は、複数のフルフィルメントセンターを持つeテイラーや、3PL倉庫で在庫を抱える企業にとって特に恩恵が大きく、在庫を本当に必要な場所に適切に配分しながら、中央のバッファーを軽量に保ちます。

しかしながら、ToolsGroupの弱点は価格最適化にあります。JustEnoughの買収により、クリアランス用のマークダウン最適化、すなわち割引スケジュールの決定機能を獲得しました。これは、季節商品やファッション分野のeコマースにおいて有用です。しかし、彼らはRevionics/Blue Yonderや専用の価格ベンダーが持つような真の動的価格最適化、つまり通常の価格最適化（利益や競争力を考慮したもの）にはまだ乏しいのです。彼らは基本的な機能を有しているか、またはパートナーと連携している可能性はありますが、価格と在庫の共同最適化が最優先の場合、ToolsGroupはBlue YonderやRELEXほどの充実した機能を持っていないかもしれません。つまり、ToolsGroupは与えられた価格を前提に在庫を最適化するものの、利益を最大化するための最適な価格設定を自動で提案することはできないのです（端末商品のクリアランスシナリオを除く）。これは重要な区別であり、彼らの**「最適化」は主に供給面（在庫レベル、補充）に焦点を当てており、需要喚起のための価格設定やプロモーションには重点を置いていない**ということを意味します―買収により一部の需要喚起ツールは加わったものの。

技術スタックの面では、ToolsGroupは現在、クラウドSaaSオプションを提供しており、「Inventory Hub」や「Fulfill.io」といった魅力的な名称で一部製品を展開しています。これは、彼らが近代化を図り、中規模のeコマース企業にもアピールしようとしていることを示しています。基盤エンジンは依然として先進的な統計手法を使用しており、おそらくはC++などの言語で計算を行っています。パフォーマンス限界に直面しているという話はなく、何百万ものSKUとロケーションの組み合わせに対応した実績もあります。とはいえ、ToolsGroupの弱点として指摘されるのは、「最適化ツール」として強力である一方、専門家による設定が必要である点です。彼らは、より簡素なアウトオブザボックスの機械学習（ML）を取り入れることで、これを解消しようとしています。例えば、需要センシング（短期的な傾向を用いて予測を調整する手法）を取り入れ、どの要因が需要に最も影響するかを機械学習で特定すると主張しています⁵⁵。さらに、確率的予測は人間による調整が不可能という神話を自社ブログで打ち破り、判断を取り入れつつも、過去のバイアスを数理的に補正できることを明らかにしています⁵⁶。これは、完全に人間を排除するのではなく、より良い情報で人間をサポートするというバランスの取れたアプローチを示しています。

カニバリゼーション効果：ToolsGroupの確率モデルは、設定次第ではカニバリゼーション（例として、代替品の関係を入力すれば、ある商品の在庫切れ時に一部需要が別の商品に流れる現象）を捉えることが可能です。しかし、これは関係性を設定するための手間や、機械学習によるアイテムのクラスタリングが必要となるため、自動化の程度は明確ではありません。とはいえ、ToolsGroupは2017年のブログで、**「ロングテール、断続的な需要、そして多チャネル」**という条件が従来のツールでは対応できず、確率的手法が必要であると強調しています⁵⁷。彼らは特に、市場チャネルが増加し、複数のストリームから集約された需要が生じる場合には、単一の数値予測では不十分となり、彼らのソリューションがマルチチャネル対応に優れていることをほのめかしています。例えば、ウェブサイトとAmazonで販売するeテイラーであれば、ToolsGroupを用いて統合需要の計画を行い、最適なチャネルごとの在庫配分を実現できる可能性があります。

ToolsGroupに関して注意すべき点の一つは、ユーザーエクスペリエンスの一貫性です。予測、在庫、アソートメントの各モジュールが1つのUIに統合されているのか、あるいはシステム間を行き来するような感覚になっているのかという点です。インターフェースの統一化には取り組んでいますが、実際のユーザーからのフィードバックが必要でしょう。おそらく、社内で開発されたRELEXの単一プラットフォームほどの統一感はないかもしれません。 トラックレコードの面では、ToolsGroupは在庫削減やサービスレベル向上を強調する多くの成功事例を持っています。SAPやJDAのような大規模な失敗例は公には知られておらず、規模が小さいため各プロジェクトにより多くの注目が集まる可能性があります。とはいえ、彼らは主に製造・流通企業に対して販売してきたため、小売やeコマース関係者にはあまり知られていないかもしれません。JustEnoughを通じた小売への進出により、かつてのJustEnough顧客が現在ToolsGroupを利用するようになっています。JustEnough自体は、計画機能はまずまずでしたが、スケーラビリティに制約があるとの評価（明確ではない点もあります）もあったため、ToolsGroupはこれらのモジュールを強化する必要がありました。懐疑的な立場からは、分析機能がどれほど統合されているのかを実際に確認することをお勧めします。例えば、JustEnoughモジュールで計画されたプロモーションが、SO99+の需要予測に自動的に反映されるかどうかなどです。おそらく、その場合はプロモーションによる上昇効果も統合されているでしょう。彼らは、「需要センシングの洞察により統計的予測が微調整される」と述べており⁵⁸、プロモーションや直近の傾向を考慮して基本予測を調整していることを示唆しています。外部からのデータポイントとして、Gartnerのようなアナリスト企業のレビューでは、ToolsGroupはサプライチェーン計画の分野でリーダーシップを発揮しているとされる一方、その能力が広範囲というよりも深い点に特化しており、UIが歴史的にあまりモダンではなかったと指摘されることがあります。これは現在、一部（新しいUI、統合）で改善されています。 eコマース専業プレイヤーの場合、ToolsGroupの採用は、在庫最適化が最重要の課題であり、実績のあるある程度独立したソリューションが必要かどうかにかかっています。もしそうであれば、ToolsGroupは在庫削減やサービス改善において迅速な成果をもたらす非常に適した選択肢となるでしょう。しかし、eコマース事業が価格最適化や最先端のオムニチャネル・マークダウン戦略の徹底的な実施を求めている場合、ToolsGroupはBlue YonderやRELEX、または専用の価格ツールほどの機能充実は期待できないかもしれません。その場合、別の価格ソリューションとの組み合わせが必要となり、統合上の課題も生じる可能性があります。（興味深いことに、ToolsGroupはこれに対して反対することなく、歴史的に在庫最適化に注力し、価格設定は他システムに任せる形で共存してきた事例もあります。）結論として、ToolsGroupは技術的に堅実で、専門家からスイートベンダーへと変貌した企業として評価されます。私たちはその予測におけるエンジニアリングの厳密さと、不確実性に妥協せず取り組む姿勢（確率を用いた計画により「予測は常に外れる」という常識を打ち消してきた点）を高く評価しています。ただし、最近の拡張、すなわち新たに統合された小売モジュールがコアと同等のパフォーマンスを発揮するかどうかについては引き続き慎重です。私たちが注視する内的矛盾は、現在完全に統合されているという彼らの主張です―もしもモジュール間でデータの手動エクスポート／インポートが必要となるような亀裂が見られれば、その提案は根本から損なわれるでしょう。しかし、入手可能な情報から判断すると、ToolsGroupはJustEnough買収後、より統一された体験を提供しているようです。さらに、計画におけるリアルタイムデータ活用の流れにも沿っており、これは称賛に値します。

確率的予測? はい、彼らはそれを推進してきました ⁴⁹ ⁴³.
経済的最適化? 在庫に関しては暗黙のうちに実施されています（サービスとコストのトレードオフを最適化します）が、Lokadのように利益について明示的ではありません。むしろ「最小限の在庫でサービス目標を達成する」という形のコスト最適化です。
スケーラビリティ? 一般的に問題なく、懸念すべき点はありません。そして、そのアプローチは効率的です（総当たり方式ではありません）。
カニバリゼーション? 可能性はありますが、先進的なモデリングによるものであり、彼らの主要な売りではありません。
マーケットプレイス／競争力? 本質的にはそうではなく、外部または入力データで対応する必要があり、ToolsGroupが自動的に競合他社の価格を取得するわけではありません。
自動化? はい、高い自動化が実現されています。セットアップ後、多くの計画タスクは、システムが注文提案を自動で発行し、プランナーがそれを承認するだけで完了します。彼らは、大幅な作業負荷削減と人為的バイアスの低減を謳っています。
ベンダー主張に対する懐疑: ToolsGroupのマーケティングは、改善統計を除けば他と比べてやや控えめです。彼らは技術の実働部分に焦点を当てており（確率的計画に関するブログは実質的で単なる見せかけではありません）が、最近ではすべてを「AI搭載」と呼ぶなど、AI流行語にも乗っています。ただし、伝統的なOR（オペレーションズリサーチ）とML（機械学習）の両面を保持している点は、健全な組み合わせと言えるでしょう.

結論として、ToolsGroupは技術的に堅実で、専門家からスイートベンダーへと変貌した企業として評価されます。私たちはその予測におけるエンジニアリングの厳密さと、不確実性に対して妥協を許さず取り組む姿勢（確率を用いた計画により「予測は常に外れる」という問題を長年打ち消してきた点）を高く評価しています。ただし、最近の拡張、すなわち新たに統合された小売モジュールがコアと同等のパフォーマンスを発揮するかについては引き続き慎重です。注目すべき内的矛盾は、現在完全に統合されているという彼らの主張であり、もしモジュール間でデータの手動エクスポート／インポートが必要とされる亀裂が見られれば、その提案は損なわれることになるでしょう。しかし、現時点での情報によれば、ToolsGroupはJustEnough買収後、より統一された体験を提供しているように見受けられます。さらに、計画におけるリアルタイムデータ活用の流れにも沿っており、これは称賛に値します。

最後に、他の場合と同様に、ToolsGroupに対するベンダー主張の精査です。たとえば、彼らが「90%以上の製品在庫状況、20～30%の在庫削減、40～90%の作業負荷削減」⁵³ ⁵⁴ といった具合に述べるとき、健全な懐疑心を持って、これらは達成可能な結果であっても保証されたものではないと考えるべきです。これらの数値は、おそらく各クライアントがそれぞれ高い指標のどれかを達成したものであり、ひとつのクライアントが同時にすべてを達成したものではありません。誰一人として、在庫が30%減少し、サービスが90%以上に上昇し、プランナーが一度に90%削減されることを期待すべきではありません。現実は通常、トレードオフと段階的な改善を伴います。ToolsGroupの手法は確かに大幅な改善を促すことができますが、現実的な目標を設定しながら進捗を測定することを勧めます。良い点は、ToolsGroupが測定可能な成果（サービス率、在庫金額）に焦点を当てているため、これらの指標を見ることで、うまくいっているかどうかが非常に明確になるということです。

宣伝文句を切り抜ける：教訓と推奨事項

これらのベンダーを通じて、eコマースの意思決定者が心に留めるべき、誇大宣伝と現実の一般的なテーマがいくつか浮かび上がりました：

流行語に注意: 「AI駆動、認知、需要感知、リアルタイム、自律」といった用語が自由に使われています。それらが具体的な能力に裏打ちされていることを確認してください。たとえば、「需要感知」 は一見素晴らしく聞こえます──昨日の売上やソーシャルメディアの話題を利用して本日の予測を調整する──しかし実際には数値をわずかに調整するに過ぎず、基本的には短期予測に留まります。業界の専門家は、需要感知を場合によっては*「ムートウェア」*、すなわち存在はするものの、良い予測が既に実現している以上の実質的な価値を提供しないものと評しています ⁵⁹。証拠のない「ヴェイパーウェア」的な概念に騙されないようにしましょう。ベンダーに対して、**「あなたのAIは現行のプロセスではできない具体的なことを何をしており、それを証明できますか？」**と問いただしてください。もし彼らが「300の要因を考慮しています」と言うなら、その要因が実際に効果をもたらしているのか、単に見栄えのする資料のためのものなのかを追及してください。
基準値とベンチマーク: 明確な基準値（例：昨年の在庫回転率、受注充足率、粗利益率など）を必ず設定し、ベンダーがその基準に対して改善を測定することに同意するか確認しましょう。多くのベンダーは文脈なしに非常に大きな割合の改善を主張しますが、それだけでは意味がありません。また、外部のベンチマーク（たとえば予測コンペティションや、具体的な数値を伴う公開事例）への参加も注視してください。M5コンペティションは、予測の優劣を分かつ一例であり、特に大手の従来型ベンダーはそこで結果を公表しなかったのに対し、小規模なプレイヤー（Lokad）が参加し優れた成果を上げたことが分かっています ⁶⁰。これにより、その技術に自信があるベンダーがどこかが判断できます。
統合の複雑性: ベンダーが買収を通じて成長した場合（Blue Yonder、ToolsGroupなど）、『すべてがひとつのプラットフォームになった』という約束には注意してください。本当の統合にはしばしば何年も要します。その間、実質的にいくつかのインターフェースを持つ別々のシステムを使用している可能性があります。これらを接続する実装には隠れたコストが生じることがあります。さらに、買収された二つのコンポーネントは、週単位の区切りや日単位、または異なる製品階層の定義など、特定のデータに対する考え方が一致しない場合があり、妥協や不整合を招く可能性があります。モジュール統合の経験について、参考顧客に話を聞くことが賢明です。
コスト構造: ソフトウェアライセンスやサブスクリプション費用だけでなく、運用時のコスト（該当する場合）や必要なインフラも評価してください。前述のように、Snowflakeのようなソリューションはクラウド実行コストを転嫁してくる可能性があります。また、非常にメモリ集約型のソリューションは、高性能なクラウドインスタンスを利用せざるを得ない状況に陥るかもしれません。あるベンダーは高額なサブスクリプション料金を提示し、すべての計算を含んでいる場合もあれば、別のベンダーは安価に見えても、必要な計算に対して大きなAWS/Azureの請求をあなたに課す場合もあります。所有コストの総額で比較していることを確認してください。SnowflakeのモデルがIBMメインフレームの落とし穴を彷彿とさせる可能性があると述べたように、使用量に基づく料金には注意し、そのモデルを用いるベンダーに透明性を求めましょう。
すべてのベンダーには失敗がある: どのベンダーも自社の失敗プロジェクトを強調することはありませんが、必ず失敗は存在します。実装はツールと同じくらい重要です。SAPやi2（現在はBlue Yonder傘下）などのトップベンダーでも数百万ドル規模の失敗例が見受けられました ³⁹ ³³。その原因は、しばしば不十分なデータ、不一致な期待、または企業がシステムの出力を採用しなかったことにあります。評価する際には、目標に達しなかったプロジェクトをどのように扱っているのか、ベンダーに尋ねてください。匿名化された教訓の例があるかどうかも確認しましょう。Blue Yonderは一般的な失敗原因を認めることで謙虚さを示しました ²⁶。もしベンダーが「我々は100%の成功率を誇っています」と言うなら、それは現実的ではありません。何が問題を引き起こす可能性があるのか、どのように対策を講じるのかについての議論を促してください。
リアルタイムと分析の深度における矛盾: ご指摘のように、一部の分析（たとえばネットワーク全体の品揃え計画など）は、実際のところリアルタイムで行うことはできません──大量のデータ処理や業務上の熟慮が必要だからです。もしベンダーが「リアルタイムの応答性」と「包括的な最適化」の両方を主張するなら、そのソリューションのどの部分がどの約束に対応しているのかを見極める必要があります。たとえば、ToolsGroupは在庫の状況をリアルタイムで更新できますが、主要な最適化処理は日次で行われる可能性があります。RELEXはほぼリアルタイムでデータを取り込むことができますが、AIを用いた価格最適化など一部の計画は依然として夜間のバッチ処理で行われるかもしれません。自社の業務ニーズに合わせて、ソリューション各部分の実行頻度を理解してください。リアルタイムは、たとえば受注可能在庫の更新やダイナミックプライシングの実行など、実行面では極めて重要ですが、戦略的な意思決定においては、スピードよりも深みと厳密さが重視されます。
人間によるオーバーライドと自律性: すべてのベンダーは、ある程度の自律性を主張しつつも、人間の入力を可能にしていると述べています。これは連続的なスペクトルの問題です。重要な問いは、システムが例外のみをフラグ付けして無人運用をデフォルトとするのか、それとも各判断についてユーザーの確認をデフォルトとするのかということです。真の効率向上を目指すなら、前者が望ましいです。もしベンダーがユーザーにどれほど多くのレバーや設定オプションがあるかを強調するなら、それはツールが良い結果を出すために多くの手動調整を必要とする可能性を示しており、自動化の約束に反します。理想的には、ツール自身がこれらのレバーを自動で調整すべきであり（たとえば、Blue Yonderは機械学習を活用することで、手動で設定していた季節プロファイルの必要性をなくしています ³⁶）、デモや試用の際に、どれだけの手動調整が必要だったかを確認して、信頼しつつ検証することが重要です。
AI/MLの詳細: ベンダーのAIに関する主張を詳しく検証してください。たとえば、予測に機械学習を利用しているのか、もし可能であればどのアルゴリズムを使用しているのか、またオープンソースのライブラリを使用しているのか、といった点を問いただしましょう（すべてが独自技術である場合、最新の技術動向に追随していない兆候であることもあります。主要なAIソリューションはTensorFlowやPyTorchなどのオープンソース、あるいは少なくとも著名なアルゴリズムを取り入れています）。もしベンダーが「独自のAIエンジン」をちらつかせながらも、平易な言葉で説明できない場合は懐疑的になるべきです。逆に、たとえば「我々はベースライン予測にはグラデーションブースティングを、価格設定には強化学習モデルを用いています」と具体的に説明できるなら、技術への具体的な投資が示されます。また、彼らのチームがその手法について学術界や業界のフォーラムで発表・参加しているかどうかも確認してください。これは真剣に取り組んでいる証拠です。

最後に、真実を追求する姿勢を強調します：光沢ある約束よりも、データと試用結果を重視するべきです。可能であれば、各ベンダーにあなたのデータの一部を使って予測または最適化を実施してもらい、その結果を定量的に評価するパイロットまたは概念実証プロジェクトを実施してください。たとえば、過去2年分の履歴データを提供し、3年目の予測（実績がある年）を行ってもらい、誰が最も近い予測をするか、または需要の微妙なパターンを特定できるかを確認します。あるいは、シナリオの最適化を依頼し、その後、実際の需要を使ってコストやサービスの成果をシミュレーションで検証させてもよいでしょう。自発的に競争を申し出るベンダーは少ないですが、優れたベンダーは自社の科学的根拠に自信を持っているため、しばしばそうした機会を提供します。たとえば、Lokadはパイロットプロジェクトを通じて関与することが多いです。Blue YonderやRELEXも、パイロットに類似した「ディスカバリー」フェーズを実施することがあります。ただし、その際は明確な成功基準を設定するようにしてください。

結局のところ、eコマース最適化ソフトウェア市場には自称**「AIの奇跡」が溢れていますが、深い懐疑心を持ち、エンジニアリングの証拠を要求することで、雑音を取り除くことが可能です。この調査では、技術革新と集中力の面でLokadがリードし、統一された小売機能に関しては（やや誇大宣伝もあるものの）RELEXが、幅広さと経験においては厳しい技術改修の中でBlue Yonderが、そして専門的な最適化能力（統合が進んでいる面で）においてはToolsGroup**が優れていることが示されました。各社は大きなメリットを提供できるものの、いずれもプラグアンドプレイの万能薬ではありません。真実は、成功する最適化は正しいツールと正しい実装戦略の両方から生まれるということです。以上の洞察と注意点を踏まえ、eコマース企業はこれらのベンダーに対して明確な視点を持ち、事実と堅実な論拠に基づいて選択を行うことができるのです。