小売最適化ソフトウェア, 2025年2月

レオン・ルヴィナス＝メナールによる
Last modified: February 2nd, 2025

はじめに: 今日の小売業者は、在庫レベル、価格設定戦略、製品の品揃えにまたがる複雑な最適化問題に直面しています。多くのソフトウェアベンダーはこれらの課題に取り組むための「AI搭載」ソリューションを約束しますが、真の技術革新を従来のシステムやマーケティングの誇大広告から見分けるためには慎重な検証が必要です。本研究では、小売最適化ソフトウェアの主要プロバイダーを厳格な基準に基づいて評価します。私たちは、統合最適化（在庫、価格設定、品揃えを一体的に最適化する能力）、確率的予測（単一の予測値ではなく需要の分布を示す予測）、経済的意思決定モデリング（静的なルールではなく利益や機会費用に基づく決定）、スケーラビリティとコスト効率（高価なハードウェアを必要とせず大規模小売ネットワークを処理する能力）、複雑な小売要因の処理（例：製品のカニバリゼーション、代替効果、消耗品の期限管理）、自動化（手動介入を最小限に抑えた自律的な意思決定）、技術統合（買収で散在するツールを統合した一貫したプラットフォーム）、およびバズワードへの懐疑（「需要センサリング」、「プラグ＆プレイ」など）に着目します。各ベンダーは、信頼できる証拠に基づいて技術的な深みで分析され、ベンダーのマーケティングに依存する割合が最小限に抑えられています。以下では、最も先進的なものから順にベンダーをランク付けし、それぞれの強み、弱点、および主張の真実性について詳述します。

小売最適化プラットフォームの評価基準

ベンダープロフィールに入る前に、適用される主要な評価基準をまとめます：

  • 統合最適化（在庫＋価格設定＋品揃え）： このソリューションは、これらの次元を相互依存性を認識して全体的に最適化していますか？それとも、各機能が分断されていますか？真に先進的なプラットフォームは、価格設定、在庫、品揃えを個別のモジュールではなく、一つの最適化問題の統合的なレバーとして扱います 1。例えば、価格の変更は在庫予測や品揃えの決定に統一的にフィードバックされるべきです。

  • 確率的予測とAI： ベンダーは、現代のAI/機械学習を用いて確率的予測（単一の予測値ではなく需要の分布）を生成していますか？確率的予測は、不確実な状況下で堅牢な意思決定を行うために不可欠です 2。私たちは、季節性、傾向、プロモーションなどの複雑なパターンを学習し、不確実性を定量化して予測精度を向上させる機械学習モデル、ニューラルネットワーク、その他のAIの証拠を求めます。依然として手動調整や基本的な数式といった単純な手法に頼ったり、予測を決定論的な一点として扱うベンダーは減点の対象です。

  • 経済的意思決定： プラットフォームの意思決定は、利益最大化、在庫コストと品切れコストのトレードオフ、棚スペースのROIなど、経済的目的に基づいていますか？小売の最適化は単に充足率を追求するだけでなく、不確実性下での期待利益の最大化を意味します。私たちは、利益率、保管コスト、値下げコスト、機会費用をアルゴリズムに組み込むソリューションを支持します。ルールベースのヒューリスティックスやサービスレベル目標は、最終的な収益性という目標を無視する場合、不十分です 3。

  • スケーラビリティとコスト効率： このソフトウェアは、数千店舗、数百万のSKU、高い取引量といった企業規模の小売データを効率的に処理できますか？全データセットをRAMに読み込むような単一のメモリ内計算に依存するソリューションは、スケール時に苦労するか、非常に高価なハードウェアを必要とする可能性があります 4。私たちは、クラウドネイティブなアーキテクチャ、マイクロサービス、分散コンピューティングにより、コスト効果の高いスケーリングを実現するソリューションを好み、ハードウェアコストが高い、または大規模データでのパフォーマンスが遅いものは減点します。

  • 複雑な小売要因の処理： 実際の小売需要は混沌としており、製品のカニバリゼーション（ある製品のプロモーションが別の製品の売上を奪う 5 6）、代替効果（在庫切れの場合、類似商品の需要が増加する）、『ハロー』効果（補完的な製品同士が互いに売上を押し上げる 7）、季節的な急増、地域差、賞味期限のある消耗品などが見られます。私たちは、各ベンダーのアルゴリズムが、機械学習を用いて製品間の相関関係を特定したり 8 9、賞味期限ごとに在庫を管理するなど、これらの複雑さに明示的に対処しているかを評価します。各製品の需要を独立していると仮定したり、消耗性を無視するソリューションは、現代の小売にとって将来性が低いと判断されます。

  • 自動化と無人運用： 『自律小売』の約束は、システムが注文、価格変更、値下げ、品揃えの調整など大部分の運用上の決定を自動で行い、人間は戦略的な例外に専念できるというものです。私たちは、ソフトウェアが**「ノータッチ」プランニング**―例えば、予測に基づく自動補充注文、ガードレール内での自動価格調整―を可能にしているか、または常にプランナーに手動での確認や上書きを依存しているかを評価します。AIを謳うベンダーは、手動作業（いわゆる「計画の苦労」 10）を減らすべきであり、逆に増やしてはいけません。

  • 技術統合 vs. フランケンシュタインプラットフォーム： 多くの大手ベンダーは買収を通じて成長し、予測、価格設定、プランニングのツールを一つのブランド下に統合しています。私たちは、各ベンダーのソリューションが一貫したプラットフォームであるのか、あるいは異なるUIやデータモデルを持つモジュールの寄せ集めであるのかを検証します。『フランケンソフト』統合は、高い複雑性と長い導入期間を招くことが多いです 11。真に現代的なソリューションは、統一された技術基盤上に構築されるか、少なくともマイクロサービスを通じてシームレスに統合される傾向にあります。マーケティング上の「統一プラットフォーム」という主張にもかかわらず、各部分が十分に連携していないベンダーは減点されます。

  • バズワードと過大宣伝への懐疑： 小売テック分野は、「需要センサリング」「AI駆動のプラグ＆プレイ統合」「認知型サプライチェーン」などのバズワードで溢れています。私たちの分析は、曖昧な主張を排除し、裏付けを探し出します。明確な説明や査読付きの根拠なしに専門用語に依存するベンダーは厳しく評価されます。たとえば、「需要センサリング」は万能の解決策としてよく挙げられますが、実際には革新的な価値を提供できないマーケティングのギミックと見なす専門家もいます 12。そのような事例を指摘し、具体的で信頼できる能力の証拠を提供するベンダーを支持します。

これらの基準を念頭に、小売最適化における主要ベンダーを検証し、ランク付けを行います。各ベンダーのセクションは、各次元においてどのように評価されるかを示し、誇張された主張に対して特に懐疑的な視点を提供します。

1. Lokad – 統合型確率的最適化と懐疑的AI

Lokadは2008年に創業された新参企業で、小売およびサプライチェーン向けに確率的予測と意思決定最適化を基盤としてプラットフォームをゼロから構築しました。他の多くの競合と異なり、Lokadは価格設定、在庫、需要計画を個別のサイロとして扱うのではなく、一つのシステムに統合することを明確に目指しました 13 14。このアプローチは、価格決定が直接的に需要および在庫ニーズに影響を与え、その逆もまた然りであるという理解に基づいています。Lokadの創業者は、従来は予測と価格設定が異なるツールで行われていたと述べていますが、実際には*「需要と価格設定は深く相互連関している」*ため、これらの機能を一つの分析フレームワークに統合するに至ったのです 15 16。さらに、サプライチェーンの意思決定をモデル化するために、独自のドメイン固有プログラミング言語（「Envision」）を開発し、価格設定、在庫、品揃えのロジックを一体化した高度にカスタマイズ可能な最適化を実現しています 17 16.

統合最適化： Lokadの哲学は、価格戦略を考慮せずに在庫を最適化することはできないというものです。彼らは価格設定と需要計画を一つのプラットフォームに統合しています。例えば、システムは再注文数量を最適化しながら、同時に価格調整を提案することで、価格設定が在庫と乖離することなく需要と連動するようにしています 1。内部のケーススタディでは、在庫レベルに基づいて価格を動的に調整する*「在庫ベースの価格設定」*戦略が議論され、価格設定と在庫の利用可能性を効果的に連携させています。同一のデータ（販売履歴、製品情報など）を価格設定モデルと予測モデルの双方で共有することで、Lokadは従来の小売ITに見られるデータサイロを回避しています 18 16。この統合的アプローチは最先端ですが、小売業者がアルゴリズムによる価格設定を受け入れる必要があるため、重要なチェンジマネジメントの側面も伴います。価格設定と在庫を同時に扱うLokadの姿勢は、従来のベンダーでは実現が難しい、本当に先見的な能力を有しています。

確率的予測とAI： Lokadは確率的予測の強力な支持者です。彼らのプラットフォームは、各アイテムおよび期間ごとの需要の確率分布を生成し、単一の予測値に留まりません。Lokadは主張しており、また我々も同意しますが、**「サプライチェーンにおいて、確率的予測は不確実な将来条件下で堅牢な意思決定を行うために不可欠である」**としています 3。可能な需要の範囲とその発生確率を捉えることで、Lokadの予測は自然に経済的な意思決定を支援します：「確率的視点は、不確実ながらも期待されるリターンに基づいて意思決定の経済的優先順位付けを自然に導く」 3。実際、これはたとえば、製品のケースを1つ追加在庫することで得られる期待利益と、廃棄のリスクを完全な需要分布を用いて評価できることを意味します。技術的には、Lokadは分位点回帰やディープラーニングを含む先端の機械学習モデルを採用してこれらの予測を生成しており、時系列に対する微分可能なプログラミングなどの技法を用いた証拠も公表しています。彼らはAIの精度と不確実性の定量化に重点を置いているため、単純な指標は避け、特に確率的予測にMAPE（平均絶対誤差率）を適用することを概念的に無効だと批判しています 19。これにより、従来の統計に「AI」を付け足すだけのベンダーとの差別化が図られています。Lokadの予測技術は明らかに最先端であり、場合によっては専用のスクリプト言語による熟練の設定が要求されることもあります。

経済的意思決定ロジック： Lokadの全体フレームワークは、経済的最適化を中心に構築されています。彼らはサプライチェーンの問題を、任意の充足率の達成や品切れの最小化ではなく、不確実性下での**「期待利益の最大化」**として位置付けることが多いです。たとえば、アルゴリズムは在庫切れの機会費用、保管コスト、値下げコストを明示的に考慮して、在庫購入や価格変更を推奨します。確率的予測を生成するため、各意思決定の期待収益（例えば、1ユニット多く在庫することによる利益と、売れ残るリスク）を計算できます。これは、ユーザーが設定したサービスレベル目標に頼る多くのツールを超えるアプローチであり、Lokadは経済性に基づいて各アイテムの最適なサービスレベルを動的に算出しようと試みています。本質的に、彼らの意思決定は財務的成果（例えば、期待されるマージン貢献の最大化）に直結しており、収益性に基づく最適化という基準に沿っています。この重視は、サプライチェーンの最適化は単にコストを削減するだけでなく、リソースを再配分してリターンを最大化することにあるという信念に根ざしています。一例として、需要予測と連動した価格最適化を実現し、在庫制約を無視する価格ツールの落とし穴を回避しています。Lokad自身は、*「需要予測と無関係に価格を最適化するのは時代遅れである」*と警告しています 20 21。価格設定を予測・最適化ループに組み込むことで、利益計算が真の需要反応を反映するようにしています。全体として、Lokadの経済的指向は業界最高水準ですが、アルゴリズムへの信頼が必要です。小売業者は、従来はプランナーが手動で担っていた収益性のトレードオフをアルゴリズムに委ねる覚悟が求められ、これは文化的なハードルとなる可能性があります。

スケーラビリティとアーキテクチャ： Lokadは、クラウドベースのサービス（しばしばMicrosoft Azureのインフラ上）としてソリューションを提供します。クライアントが重厚なインメモリサーバーをオンプレミスで運用する必要はなく、Lokadはクラウドクラスター上で計算を実行し、必要に応じてスケールアウトします。このオンデマンド計算モデルは、一部の従来ツールが採用する**「ハードワイヤードインメモリキューブ」方式を回避し、これは「印象的なリアルタイムレポートを提供するが、高額なハードウェアコストを伴う」ものです 22。対照的に、Lokadはクラウド上で作業負荷を分散させ大規模なデータセットを処理し、クライアントは使用した計算時間のみを支払います。これはコスト効率が高くスケーラブルであり、ピーク時のために恒久的なサーバーを用意する代わりに、数時間だけ追加の計算ノードを投入することで大きな問題に対処できます。また、LokadのアーキテクチャはEnvisionスクリプトを用いたコードファースト設計であり、複雑な計算をサーバーサイドで効率的にコンパイル・実行するため、デスクトップUIでの処理とは異なります。この設計は、数千万のSKU-ロケーション組み合わせを持つクライアントの事例からも、その有効性が証明されています。ただし、Lokadは小規模なベンダーであるため、一般的には堅実なスケーラビリティを有しているものの、SAPやOracleのような絶対的に大規模な（例：Walmart規模の）小売データセットでの実績はまだ十分でない可能性があります。それでも、彼らのクラウドアプローチは、従来のオンプレミスのメモリ依存システムよりも本質的にスケーラブルです。コスト効率も高く、LokadのSaaS価格は使用量に基づくため、ユーザーは大規模ハードウェアのライセンス料やアイドルコンピューティングの費用を強制されることはありません。まとめると、Lokadの最新クラウドアーキテクチャは、従来のものとは異なる、コード駆動システムに顧客がオープンであれば、スケーラビリティとコスト面で大きな優位性を発揮します。

複雑な小売要因の取り扱い: Lokadのプラットフォームは、本質的に最適化のための柔軟なプログラミング環境であるため、複雑な小売現象に対して明確に対応するように設定できます。例えば、ユーザーはEnvisionスクリプト内で製品間の相互関係（代替品または補完品）をモデル化し、需要予測と発注にキャニバリゼーションやハロー効果を反映させることができます。もし製品AとBが代替品であるなら、Lokadのシステムはトランザクションデータを取り込み、Aが在庫切れの場合にBの売上が上昇することを学習し、それに応じて予測を調整します。これは必ずしもチェックボックスで切り替えられる既製の機能ではなく、適切なモデルを構築するためのデータサイエンスの作業が必要ですが、その能力は備わっています。同様に、プロモーション効果もモデル化可能で、Lokadはプロモカレンダーを入力として使用し、プロモーション価格の最適化すら行います。生鮮品や賞味期限に関しては、Lokadは残りの賞味期限を最適化ロジックに組み込み（例えば、賞味期限が近づくにつれて価格ディスカウントにより販売の優先度を上げる、または短命商品の過剰在庫を避けるなど）、柔軟性が大きな強みとなります。従来の硬直したシステムとは異なり、Lokadのアプローチは、データと専門知識さえあれば、ほぼあらゆる制約や要因をエンコードできる点が特徴です。一方の欠点は、既製の「キャニバリゼーションモジュール」が存在しない可能性があり、ユーザーまたはLokadのチームがロジックを実装する必要があることです。それでも、多くのベンダーはこれらのニュアンスを完全に無視してしまいます。Lokad自身のチームは、機械学習による需要予測へのキャニバリゼーションの統合（例：売上相関から代替品を特定する）といったテーマで発表しており、主要な小売専門家と同様に対処可能であることを示しています 8 9. 実際、複雑なカテゴリダイナミクスを持つ小売業者の場合、Lokadはカスタムモデリングプロジェクトを行う可能性が高いです。このオーダーメイドのアプローチは、キャニバリゼーションなどの要因を非常に高精度で取り扱うことができる一方、プラグアンドプレイ型ではなく、よりコンサルタティブな体制への賛同が必要です。ファッション小売業者とのサイズカーブや、グローサリ小売業者とのプロモーションの実績からも、Lokadが主要な競合他社と同等以上にこれらの要因に対応できることは証明されています。

自動化: Lokadのビジョンは、無人による意思決定に強く向かっています。彼らのプラットフォームはしばしば「サービスとしてのサプライチェーン最適化」と説明され、ユーザーが設定すれば、補充注文や価格変更などの意思決定を自動的に継続的に生成することを意味しています 23. 目的は、プランナーが手動の数値処理から、AI主導の意思決定の監督へと移行することにあります。Lokadのシステムは、日次または週次の注文推奨を作成し、最小限の人的調整で小売業者のERPに直接統合できるようにします。予測が確率論的で、最適化が利益主導であるため、システム自体が最適な判断を下していると考えられ、例えば各注文数量ごとにプランナーの感覚を確認する必要はありません。もちろん現実には、多くの企業が初めは推奨内容を確認しますが、多くのLokadクライアントは、新製品や大規模イベントなど例外処理のみを手動で行う高い自動化レベルを達成していると報告しています。「オートパイロット」モードへの注力は際立った特徴で、従来の一部ツールがプランナーによる解釈に依存する意思決定支援であるのに対し、Lokadは意思決定を自ら行うソフトウェアを目指しています。一例として、Lokadを利用するグローサリ小売業者は、需要変動に適応して調整される自動店舗補充を実現し、大幅な廃棄物削減と欠品削減を同時に達成しました 24. これは、需要予測に基づく自動補充が二桁台のパーセンテージで廃棄物を削減できるという業界の知見と一致しています。さらに、Lokadのスクリプト機能により、例えば在庫が最低展示在庫を下回らないようにといった業務ルールをエンコードできるため、現実世界の制約を自動化に反映させることが可能です。総じて、Lokadは真の無人最適化に向けて大きな評価を受けています。唯一の注意点は、初期設定（モデルのコーディングやテスト）に多大な労力が必要なため、モデルが正確になるまでは意思決定の自動化が望ましくない点です。しかし一度調整が完了すれば、システムは従来のMRPや計画システムをはるかに上回る自動化レベルで、最小限の人的介入で運用可能となります。

技術統合: Lokadは、一貫した技術スタック上で完全に自社開発されています。他社のソフトウェアを買収して成長したのではなく、独自の予測エンジン、最適化ソルバー、スクリプト言語を開発しました。これにより、非常に統合されたプラットフォームが実現し、すべての機能（需要予測、価格設定、在庫最適化）が同じデータモデルと同一の言語で動作します。インターフェースを通じて統合する「モジュール」は存在せず、全てがEnvision環境内で行われます。これは、買収した価格ツールと別の計画ツールを組み合わせなければならない一部の競合他社とは大きく対照的です。Lokadの統一アプローチは複雑さを減らし、一貫性のなさを回避します。たとえば、需要予測の出力が同じスクリプト内で直接価格最適化ロジックに反映されるため、バッチファイルの転送やシステム間での煩雑なAPI呼び出しは不要です。さらに、Lokadのプラットフォームは比較的軽量で、完全なリレーショナルデータベースやOLAPキューブを必要とせず、ストレージと計算リソースは特定の目的に最適化されています。つまり、Lokadの技術スタックは、レガシー部品の置換を必要とせずに全体として継続的に改善されるため「将来性がある」とも言えます。この非常にオリジナルな技術には独自性が伴い、クライアントは典型的なGUI計画ツールとは異なるLokad独自の手法を習得する必要があります。しかし、エンジニアリングの観点からは、技術スタックの結束力は非常に優れており、買収した部品を組み合わせたフランケンシュタインのような状態にはなっていません。さらに、UIや分析ツールでさえもコアエンジンに基づいて目的別に設計されているため、このシンプルさは統合における障害箇所の少なさという大きな利点にもつながっています。

誇大広告に対する懐疑: 特に、Lokadは業界の流行語に対して明確に懐疑的であり、その姿勢は製品ポジショニング全体に浸透しています。同社は「デマンドセンシング」のような概念を、「サプライチェーンにおけるまた一つの期待外れの流行語」、すなわち価値を提供できないソフトウェアであるmootwareとして批判しています 12. この懐疑的視点は実は強みであり、流行に流されたマーケティングではなく、確固たる科学に基づいて製品を構築しようとしていることを示唆しています。たとえば、Lokadは「ブロックチェーン・サプライチェーン」ブームに飛びついたり、「デジタルツイン」というレトリック（創業者自身も批判したもの）を過剰に売り込んだりはしません。代わりに、確率論的需要予測や分位点最適化といった具体的な技術能力に注力しています。ベンダーの主張に関しても、Lokadのものは概ね具体的であり、決して「プラグアンドプレイ」のような実現不可能な容易さや、魔法のような既製のAIを謳うことはありません。実際、高度な最適化の展開は複雑であり、各企業に合わせた調整が必要であると警告することが多い（そのため各顧客ごとの特性をコード化するためのプログラミング言語に重点を置いています）。この正直さは、高尚な約束が飛び交う分野において新鮮です。一方、マーケティングを控えたメッセージは、「認知AIを搭載した自律型サプライチェーン」を声高に謳う競合他社と比べると、Lokadが派手さに欠ける印象を与える可能性があります。しかし、真実を追求する観点からは、Lokadの主張は裏付けられている傾向があり、例えばあるクライアントで在庫を5%削減したという場合、それは通常、詳細なケーススタディに基づくもので、単なる一般論ではありません。加えて、古典的手法の限界を詳細に解説するLokadのブログ記事も公開されており、この透明性が信頼性を高めています。総じて、Lokadは技術者向けのソリューションとして浮上しており、堅実なエンジニアリングと分析の原則に基づき、需要予測と最適化を組み合わせ、誇大広告を排除しています。このアプローチは、（確率論的、利益主導、クラウドアーキテクチャの）技術的洗練において金字塔とすべき水準であると言えます。唯一の注意点は、Lokadが一部の大手と比べて規模において実績が乏しく、そのモデルが各クライアントに対して熟練したカスタム実装を必要とするため、既製品とは言い難い点です。しかし、生の能力と先見の明という点では、Lokadは小売最適化分野のトップベンダーの一角に数えられます。

まとめ: Lokadは、在庫と統合した価格設定による連携最適化、真の確率論的AI需要予測 3、利益と機会費用の最適化、クラウドネイティブなコスト効率の高いアーキテクチャによるスケーラビリティ、柔軟なモデリングによる小売複雑性への対応、高度な自動化、一貫した自社開発技術スタック、そして誇大広告に対するさっぱりとした懐疑姿勢を武器にしています。これにより、初期の分析作業がやや必要となるものの、将来性のあるアプローチを体現しています。

出典: Lokadによる価格設定と計画データの統合 25；堅牢で利益重視の意思決定のための確率論的需要予測の強調 3；デマンドセンシングのような流行語の批判 12.

2. RELEX Solutions – 小売に特化した統合計画と先進のAI（そして多少の手作業を伴う）

RELEX Solutions（2005年創業）は、小売計画と最適化を専門とする急成長中のプロバイダーであり、需要予測、補充、割当、品揃え、そして最近では価格最適化をカバーしています。RELEXは、食料品および専門小売分野において、品揃えの改善と廃棄物削減という測定可能な成果を提供することで高い評価を得ています。同社のプラットフォームは、小売業特有の課題（短い賞味期限、大量のSKU、店舗レベルの計画）に特化して構築され、先進的な機械学習とリアルタイム応答を実現するインメモリデータ処理エンジンを用いていることで知られています。RELEXは、需要予測、自動補充、店舗スペース及び品揃え計画、そして最近では価格設定にまたがる統合的なソリューションを提供しており、これはLokad以外で、在庫、価格、品揃えという三本柱すべてに統合的に対応できると主張できる数少ないベンダーの一角となっています。同社は、3名のコンピュータサイエンスPhDによって創業された強固なエンジニアリング文化を有し、小売向けAIの研究開発に多大な投資を行っています。我々は、RELEXの小売特化の能力と実績ある成果を非常に高く評価するとともに、システムの重さやマーケティングを裏付ける実績が必要である点といった潜在的な欠点にも留意しています。

連携最適化: RELEXのプラットフォームは、小売業務において比較的総合的なアプローチを取っています。最初は需要予測と補充で始まりましたが、品揃え最適化およびプラノグラミングに拡大し、さらに価格最適化モジュールも提供しています 26. これは、小売業者がRELEXを用いて、各店舗でどの商品を取り扱うか（品揃え）、どれだけ在庫するか（在庫）、およびどの価格で販売するか（価格設定）を一つのシステム内で決定できることを意味します。これらの統合は進行中の課題であり、RELEXは従来、在庫最適化（店舗やDCへの補充）とスペースプランニングで優れており、価格最適化は比較的新たに追加された機能です。しかし、同社は、価格最適化が需要予測エンジンと連動していることを宣伝しており、需要の影響を十分に考慮した価格決定が可能であるとしています 27. 例えば、RELEXは主要商品の価格変更が、その商品の売上にとどまらず、補完商品や代替商品の売上にもどのように影響するかを、同じ需要予測モデルを用いてシミュレーションできます。さらに、RELEXのプロモーション計画機能は、価格プロモーションを需要計画プロセスに組み入れており、プロモーションがシステムに入力されると、需要予測が調整され、在庫構築が提案され、さらにはプロモーションの仕組みさえも推奨する仕組みになっています。このような連携的検討レベルは非常に強固です。特筆すべきは、RELEXが棚容量と需要予測を連動させる能力であり、たとえば品揃えの変更や価格がより多くのボリュームをもたらすと予測される場合、システムは棚スペースの不足を警告します。とはいえ、RELEXはまだ1つのアルゴリズムで価格と在庫を同時に最適化しているわけではなく（おそらく、特定の価格に対して需要を反復的に予測し、その後に補充を最適化する手法を取っているため、価格と在庫を同時に最適化するわけではありません）、それでも1つのプラットフォーム内では、個別ツールを使用する小売業者よりもフィードバックループが緊密です。RELEXは明確に**「統合型小売計画」**を掲げ、ケーススタディでは、長期的な品揃えの決定から日々の店舗発注に至るまでエンドツーエンドで利用されていることが示されています。我々は、RELEXの網羅性を高く評価しており、小売範囲における際立った機能的ギャップは見当たりません。ただし、これらすべての要素を統合することは複雑であり、一つのスイート内で各モジュール（マーチャンダイジング、サプライチェーン、価格設定）の実装を行うのは大規模なプロジェクトとなる可能性があります。

確率的予測とAI: RELEXは予測の精度と粒度を向上させるためにAI/MLを多用していることで知られています。彼らは、*「季節性、トレンド、曜日パターン、プロモーション、ディスプレイ変更、祝日、天候、競合他社の動向」など、さまざまな需要ドライバーを組み込む機械学習モデルを開発しています 28 29。この多因子アプローチは従来の時系列手法を超えたものです。RELEXのMLアルゴリズムは、各製品において重要な要因（特徴選択）を自動的に検出し、需要パターンの変化（急激なトレンド変化に対する変化点検出）を見極めることができます 30 31。彼らが使用する印象的な技術のひとつに、スパースデータに対するデータプーリングがあり、販売がゆっくりな商品の場合、類似製品をグループ化してシグナルを抽出し、予測を改善しています 31。これらはすべて、学術的な文脈で期待される現代のAI手法であり、今や商用ツールとして展開されています。その結果、彼らが主張するところでは、予測は「従来の手法を速度、精度、粒度の面で上回る」とされています 32。実際、RELEXは実装後の予測精度やサービスレベルの大幅な向上といった指標をしばしば強調します。彼らはある程度の不確実性も扱っており、例えば、システムはプロモーションに対して異なるシナリオや信頼区間を生成することが可能です（MLを用いて歴史的データを解釈し、プロモーション予測においてカニバリゼーションやハロー効果を組み込む 9）。プロモーション中は、学習されたカニバリゼーション／ハローの関係に基づいて関連製品の予測を明示的に上下調整し 9、その結果、カニバリゼーション対象商品の過剰在庫を削減し、ハロー対象商品の品切れを回避しています。これは、製品間の相互作用に対する精緻な確率的理解を示しています。RELEXがすべてのアイテムに対して完全な確率分布を出力しているかは明らかではなく（内部的にはシナリオをシミュレートしている可能性がありますが、プランナーには主に調整済みの一点予測が表示されます）、彼らの変動性の扱いは高度です。たとえば、小売データに特有の「ボラティリティ」*を、それに適したアルゴリズムで考慮していると述べています 30。さらに、類似アイテムのプロファイルを用いることで、新製品や販売が伸び悩む商品の予測を行うという、古典的な「類似商品」予測問題へのAI駆動のアプローチも取り入れています。RELEXのMLへの取り組みは、EUの研究プロジェクトやホワイトペーパーにも示されており（彼らは小売向けAIに関連するEU Horizon 2020プロジェクトに参加しています）、全体としてRELEXの予測技術は小売ベンダーの中で最先端で、むしろ小売計画におけるAI採用のリーダーといえるでしょう。彼らはLokadのように「確率的予測」という用語をあまり使わないかもしれませんが、実際にはシミュレーション（プロモーションの場合）や感度分析を通じて不確実性を組み込んでいます。さらには、画像認識など予測以外のタスクにもAIを用いており、棚の監査に活用しています。主な欠点として、これほど複雑なAIモデルはユーザーにとって「ブラックボックス」となりやすく、信頼が必要とされる点が挙げられます。しかし、例えば食品チェーンにおける生鮮食品予測の精度向上による30%の廃棄削減 24 といった実績が、彼らのAIの有効性を物語っています。

経済的意思決定: RELEXの最適化は、歴史的にサービスレベルと鮮度に重点を置いており、核心となる食料品市場（空棚や食品廃棄の回避が最重要）においては、明示的な利益最適化よりもこのアプローチが理解しやすいものとなっています。しかし、彼らはより経済的な分析も追加しており、たとえば、品揃えの合理化では、店舗ごとに各商品がもたらすエンドツーエンドの収益性をAIで評価し、売上、マージン、および発生するコストを分析することで、棚スペースに見合わない低パフォーマンス商品を特定します 33。彼らはこのAIが「各店舗ごとに各商品のエンドツーエンドの収益性を見抜き、低パフォーマーを明らかにする」と強調しており 33、品揃えの決定と財務的成果を効果的に結びつけています。これによって、最適化は単なる数量ではなく利益に直結すべきであるという考えを示しています。在庫最適化においても、RELEXは製品ごとに異なるサービスレベル目標の設定を可能にし、重要な商品とそうでない商品の違いを考慮することで、財務的に重要な部分において高い可用性を実現します。これは完全に機会費用に基づくアプローチではありませんが、財務的な視点において重要な部分に重点を置くことで、経済的優先順位を近似しています。価格設定面では、RELEXは現在、価格最適化モジュールを有しており、利益性が前面に出ています。価格最適化は、しばしば制約下でマージンや収益を最大化するというビジネス目標を達成するための価格設定を目指しており、彼らの価格AIはRevionicsやBlue Yonderの価格設定と同様に、価格弾力性やマージンのトレードオフを検討していると考えられます。さらに、RELEXのプロモーション計画は、マージンの犠牲と引き換えにプロモーションの成功を最大化することを目指しており、その経済的志向は、例えばFranprix（フランスの食料品店）がRELEXを活用して30%の食品廃棄削減と67%の在庫切れ削減を実現し、廃棄物削減と販売向上により収益性を改善したという事例にも表れています 24。彼らは、廃棄コストとサービスレベルのバランスを最適化することで利益に直結するアプローチを実現しているのです。さらに、空港の乗客予測などの外部データを活用することで、WHSmithの店舗における供給と実際の需要を連動させ、生鮮食品の過剰在庫を防ぐという取り組みも行っています 34。これらすべては、RELEXの意思決定が形式的な「期待利益」計算を出力していなくても、利益に連動するKPI（例：食品廃棄率、在庫切れ率、収益）をターゲットとすることで、経済的成果を実現していることを示しています。価格設定を取り入れていることから、RELEXは今後、たとえばシーズン商品を余剰在庫なく最高のマージンで売り切るための値下げスケジュールの最適化など、統一型利益最適化へとさらに進化していくと期待されます。まとめると、RELEXのDNAはやや運用面（サービスレベルと廃棄）に寄っているものの、小売の経済性をアルゴリズムに組み込むことで、単なるルールエンジン以上の価値を提供しています。

スケーラビリティとパフォーマンス: RELEXのアーキテクチャは、すべての小売データを対象にカラム型ストレージを備えた高性能インメモリデータベース上に構築されていることで有名であり、これにより大規模なデータセットに対しても非常に高速な計算を実現しています。利点としては、リアルタイム解析が可能な点が挙げられ、たとえばパラメーター変更が注文に与える影響を即座に確認したり、何千もの店舗の予測をその場で再計算することができます。この設計は多くの小売業者を感心させましたが、その代償としてハードウェアの使用量が多くなるという問題もあります。実際、ある批評家は*「インメモリ設計はBIキューブに類似し、印象的なリアルタイム報告機能を提供する一方で、高額なハードウェアコストを伴う」*と述べています 22。これは、データをインメモリで保存することで高速性を実現している一方で、何百万ものSKUと店舗の組み合わせを持つ全国規模のグロサリーチェーンにスケールする際、非常に大きなメモリと計算能力が要求されることを意味します。RELEXは通常、クライアント向けにクラウドソリューションとして展開しており（彼らはクラウド上でホストしており、AWSやAzureの可能性がありますが、公開はしていません）、複数の数十億ドル規模の小売顧客にも対応できる実績があります。スケーラビリティの観点から、RELEXはヨーロッパや北米の大手小売業者に対して十分な能力を示しており、システムは数千店舗の日次発注にも対応可能です。中規模のRELEX顧客は、多数のSKUを管理し、日内で再予測を行うこともよくあります。ボトルネックは、複数のモジュールを追加する際、例えば巨大な品揃えやプラノグラムデータとの統合でデータ量がさらに増大する場合に発生します。RELEXは、アルゴリズムの最適化や一部計算をディスクや分散ノードへオフロードすることでこの問題に対処していますが、本質的には負荷の高いアプリケーションです。また、迅速な計算を活用したダッシュボードやWhat-ifシミュレーションツールも提供していますが、全データセットがメモリ上にあることがその基盤となっています。メモリ価格の低下とクラウドスケーラビリティの向上により、RELEXの重厚なアプローチは10年前よりも実現可能になっています。それでもなお、コスト意識の高い顧客にとっては、RELEXのインフラ要件はシンプルなツールに比べて高額に感じられるかもしれません。実際、RELEXの実装では、リアルタイム応答性を維持するために高性能サーバや多くのクラウド資源が必要となるという逸話もあります。この点では、速度と粒度のためにコスト効率が犠牲にされているのです。ソフトウェアのスケーラビリティに関しては、RELEXはモジュール式であり、すべてのモジュールを実装する必要はありませんが、すべてが一つのプラットフォーム上に統合されています。彼らは多国籍、多通貨などのグローバルな運用も支援できる能力を実証しており、全体としてRELEXは純粋なパワーと速度では高評価、一方でコスト効率は中程度と言えるでしょう。まるで高性能スポーツカーのように、素晴らしい性能を提供する反面、その分プレミアムな燃料費が必要なのです。

複雑な小売要因への対応: ここでRELEXは真価を発揮します。RELEXは小売シナリオ専用に設計された豊富な機能を搭載しており、カニバリゼーションおよびハロー効果はプロモーション予測において明示的に扱われています。前述の通り、システムはトランザクションデータから（どの製品が代替品で、どれが補完品かという）関係性を学習し、予測を調整します 8 9。これらの機能を内蔵しているベンダーはほとんどなく、RELEXのデータサイエンスチームは、手動の仮定に頼るのではなく、バスケットデータに対するアソシエーションルール学習を用いてこれらの関係性を推測する方法を発表しています 8。つまり、製品Xのプロモーションを行うと、RELEXは通常Xがカニバリゼーションする製品Yの基本予測を自動的に下げ（ハロー効果の場合は逆に上げ）るため、予測精度が向上し、在庫判断も改善されます（プロモーション中、Yの在庫は減らされる傾向にあります） 9。また、代替に関しては、もし製品Aが品切れになった場合、製品Bの予測を一時的に上昇させるなど、欠品の影響も考慮できます。さらに、賞味期限管理と廃棄は特に生鮮食品小売において重要視されており、RELEXのソリューションは在庫の経過時間を追跡し、賞味期限管理の機能を備えています 35。たとえば、RELEXは先に期限切れになるバッチを優先して販売する（FEFO – 先出し先消費）ようにし、生鮮商品の予測では短い保存期間を考慮して、より小規模で頻繁な補充を推奨します。さらに、販売が伴わずに在庫が賞味期限に近づいた場合に警告するツールも提供しています 36。RELEXのクライアントであるFranprixは、日次予測と自動店舗発注を用いることで大幅な廃棄削減を実現しました 24 37。また、RELEXはディスプレイスペースや視覚的マーチャンダイジングも予測に組み込み、例えば製品がセカンダリーディスプレイに配置されれば、予測が上向きになるように調整されます（MLがその相関関係を検出）。さらに、労働力および業務執行モジュールを通じて、予測や計画が変更された場合（例えば需要が急増した際）、店舗スタッフに迅速な対応（パンの焼き増しや補充の促進など）を促し、業務の連携を強化します。もうひとつの複雑な要因である天候についても、RELEXは内蔵の天候調整機能を持ち、季節商品（例：暑い日のアイスクリーム）において重要な役割を果たしています。多くの企業が天候予測を主張しますが、RELEXは各地域に合わせた機械学習の調整を施すことで実装しています 29。総じて、RELEXは製品間の交差効果、外部ドライバー、賞味期限といった小売の複雑な現実に対応する最も包括的なツール群を有しており、これらすべてをAIで自動化している点が大きな差別化要因となっています。すべての機能を活用するには、RELEXに大量のデータ（バスケットデータ、天候フィード、在庫状況など）を提供し、システムの推奨を信頼する必要がありますが、複雑性に対応したい小売業者にとって、RELEXは実績あるツールボックスを提供しています。

自動化: RELEXは非常に高度な自動化をサポートしていますが、しばしば人間の監視を可能にするよう設定されています。 実際、多くのRELEX顧客は店舗および流通センター（DC）レベルで自動補充を利用しており、システムは各SKU-店舗ごとに日次または日中の発注を生成し、レビュー対象にフラグが立てられない限り即座に実行されます。 調査によれば、予測に基づいた店舗発注の自動化を導入している食料品店はわずか24％でしたが、RELEXのようなシステムを導入した店舗では廃棄が10～40％減少したとされています38 24。 Franprixの例では、自動発注により30％の劣化削減が実現されたことが、RELEXの自動化の有効性を裏付けています24。 システムには、（例：「説明のつかない要因により予測が大幅に低下した」や「保管スペースの制限により発注が上限に達した」などの）例外に対して人間の注意を引くアラート機構が備わっているものの、基本的には自動操縦で稼働します。 RELEXの哲学は、意思決定がシステム主導で行われる**「アルゴリズム小売」としてよく表現されます。 さらに、各店舗ごとにどの商品を追加または削除するかを提案することで品揃えの見直しを自動化し、クリアランス用の価格値下げ推奨さえも自動化しています。 特に目立つ自動化の分野としてはプロモーション実行**があり、RELEXはプロモーションを見越して在庫を自動的に店舗に投入し、販売が振るわない場合にはプランナーの介入なしに在庫を回収することができます。 さらに、リアルタイムエンジンのおかげで、プランナーは面倒なバッチ処理や手動の再計算を行う必要がなく、新たなデータ（販売、在庫など）が届くたびにシステムが予測と計画を連続的に更新します。 これにより、最小限の手動トリガーによる継続的な計画への移行が可能となります。 注目すべきは、RELEXは通常、監視のためにプランナーを関与させており、たとえば品揃えの変更を承認したり、特に導入初期に過剰な発注を調整したりする場合があることです。 しかし、利用者の間ではAIへの信頼が高まり、それに伴い自動化も進んでいます。 RELEXは、システムに自動発注を委ねた場合に品切れと在庫がどう変化するかをシミュレーションできるツールを提供し、プランナーが信頼を構築できるようにしています。 人間が後から調整しなければならないレガシーシステムと比べ、RELEXは自律運転に非常に近い運用を実現しています。 さらに、Blue Yonderに類似した「自律計画」というコンセプトでのマーケティングも開始しています。 我々の懐疑的な視点からすれば、RELEXは補充において実証済みの自動化、予測においては十分な自動化（手動予測の不要）、品揃えにおいては部分的な自動化（提案は依然としてマーチャンダイジングによる確認が必要）、そして価格設定においては新興の自動化（例：動的な値下げ）を実現しているといえます。 AIの能力が向上するにつれて、RELEXは今後さらに人間による介入の必要性を低減すると期待されます。 そのため、自動化においては、最初から自動操縦用に設計されたLokadのようなソリューションに次ぐ高評価を得ています。 ただし、組織が自社のプロセスを適応させる必要がある点は留意すべきであり、RELEXは自動化の機能を提供するものの、それを信頼し、役割を再編成するのは小売業者次第です。

技術統合: RELEXは主に自社内で開発された統合プラットフォームです。 コアの計画エンジンは買収によって組み立てられたのではなく、同社自身によって構築されました。 需要予測、補充、アロケーション、プラノグラミング、労働力管理などの異なる機能はすべて共通のデータプラットフォームを共有しており、これによりスイート内での統合作業が容易になります。 例えば、品揃え計画モジュールは予測モジュールに直接接続され、品揃えから商品を除外すると、その商品がリストから削除された後に予測と発注が自動的にゼロになるのです。 一貫性は概ね強固で、ユーザーはこれらの機能に一つのインターフェースを通してアクセスします。 RELEXは店舗実行用のモバイルアプリや画像認識技術など、いくつかの買収を行っていますが、これらはコアの計画ロジックというよりは補助的な機能です。 潜在的な複雑さの一つとして、インメモリアーキテクチャが挙げられ、すべてが巨大なメモリモデル内に存在するため、新たなデータタイプの修正や統合が困難になる可能性があります。 しかし、最新のデータベース技術を用いることでこれを上手く管理しているようです。 価格と在庫のために、買収によって明確に分離された製品を持つ従来のベンダーと比べ、RELEXのソリューションは統一感に溢れています。 例えば、価格最適化は新しいコンポーネントですが、同じ予測データとUIを利用するよう緊密に統合されている可能性があります。 そのため、予測をサードパーティの価格ツールに出力する必要はなく、RELEX内部で完結しており、モジュール間の前提の不一致を低減しています。 別の統合ポイントとして、RELEXはAPIを通じて実行システム（ERP、POSなど）と接続しており、かなり堅牢な統合ツールを備えています（これはどのベンダーにおいても一般的なことです）。 RELEXが単一製品として成長したことで、JDA/Blue YonderやSAPのような古い競合他社に見られる「フランケンシュタイン」状態を回避しています。 とはいえ、特に価格領域への拡大に伴い、シングルプラットフォームの純粋性を維持するための不断の努力が必要です。 これまで大きな問題が報告されていないことから、統合が保たれていると推測されます。 注目すべきもう一つの点は、もしRELEXがアプリケーションをマイクロサービスに分割している場合、それらがシームレスに通信しているかどうかという点です。 GartnerはRELEXの**「データ管理および制約モデリングツール」**を注目すべきものと評価しており39、これはすべてのビジネスルールとデータを統合的に管理する仕組みを持っていることを示唆しています。 つまり、棚スペース、リードタイム、パックサイズなどの異なる制約が別々ではなく同一のソルバーに入力されるという、高度な統合が実現されています。 要するに、RELEXはこの分野における技術的に一貫性のあるソリューションの一つであり、M&Aに起因する断片化の兆候はほとんど見受けられません。 これは従来のスイートに対する大きな強みとなっています。

マーケティング主張に対する懐疑: 多くの若い企業と同様、RELEXもマーケティングでAI/MLなどの流行語を自由に使いますが、その実態は十分に裏付けられています。 彼らは「リビングリテール」や「AIの解放」といったマーケティング用語を使いますが、同時に具体的な成果や手法も発表しています。 例えば、ブログ記事や各種リソースで、リテール向けに機械学習がどのように動作するか（プーリング、トレンド検出などを議論）を詳細に説明しています40 30。 この透明性は評価に値し、単なる魔法のAIボックスではなく、そのアプローチを概説している点が信頼できます。 また、RELEXは顧客の声を反映する傾向があり、多くの主張は事例としての統計データ（例：XXXX小売業者は棚頭在庫の可用性をY％改善し、在庫をZ％削減した）として示されています。 これらはあいまいな主張よりも説得力があります。 彼らは「自律的」や「コグニティブ」といった用語を用いることもありますが、これまでのところソフトウェアが実際に実現可能な範囲を超える約束はしていません。 注目すべき点として、RELEXは時折、短期予測能力を説明するために**「デマンドセンシング」**という用語を用いることがあります（直近の販売データを取り込み、近い将来の予測を調整する機能）。 デマンドセンシング自体は誇大広告と批判されることもありますが12、RELEXの場合、最新のデータを用いてより頻繁に予測を更新するという本質的なアプローチにすぎません。 不可能な先見性を主張しなければ、問題はありません。 プラグアンドプレイ統合についてもRELEXは過度に謳うことはなく、実装にはデータ統合やパラメータ調整などの作業が必要であると認めています。 実際、一部の顧客はRELEXプロジェクトには相当な労力が必要であると指摘しており（強力なツールには当然のことです）、RELEXは「即時価値」という虚偽の物語をあまり押し出していません。 また、過剰に装飾的な専門用語も避けており、理由なくブロックチェーンや量子コンピューティングを謳うことはありません（ただし、興味深いことに、彼らが買収した「Evo」はAIに対して「量子学習」という用語を使用していますが、これは別件です）。 むしろ、RELEXの最大のマーケティング主張は、統一された一つのソリューションでリテール計画のすべての側面に対応し、迅速に大きな成果を出すことができるという点にあります。 我々は懐疑の目で、ひとつのシステムが長期的な品揃え戦略、日々の補充、そして価格設定すべてにおいて真に卓越できるのかを問い、その実現の難しさを認識しています。 RELEXは多くの分野で強力な能力を発揮していますが、例えば価格設定のように専門の競合他社ほど検証されていない分野も存在するため、すべての要素が均等に成熟しているとは限りません。 これは、販売資料で見落とされがちな微妙な点です。 さらに、一つのシステムで多数の機能を実行することは、扱いづらさを招く可能性がありますが、これはマーケティング上はあまり強調されていない問題です。 それでも、ハイプと現実のバランスを考えると、RELEXはAI駆動の改善の主張がアルゴリズムと顧客実績によって裏付けられており、最も目立つ流行語の乱用を避けている点で、優れた存在であると言えます。 我々はそのマーケティングの誠実さを比較的高く評価します。

概要: RELEX Solutionsは、予測、補充、品揃え、価格設定を網羅する統合プラットフォームを備えた、小売最適化のパワーハウスです。 同社は、プロモーション、天候、カニバリゼーション9などの実際の小売要因を考慮するために機械学習を広範に活用し、小売業者に対して在庫の可用性向上や劣化低減など、顕著な成果改善を実証しています24。 システムは、品揃え、在庫、そしてある程度の価格設定の共同計画をサポートしますが、価格最適化は比較的新しい分野となっています。 確率的およびAIによる予測は際立った強みであり28 31、生鮮製品や複雑性を洗練された方法で扱う能力も特徴です。 スケーラビリティは概ね実証されているものの、高いリソース使用量を伴います22。 RELEXは（特に補充において）高度な自動化を実現し、小売向けに構築された統一された技術スタックを有しています。 利益最適な意思決定や価格と在庫の完全統合最適化など、一部の側面はLokadのアプローチほど自然に組み込まれていないかもしれませんが、RELEXは大手小売業者向けの最も将来性があり革新的なソリューションの一つとして評価できます。 理論だけでなく現実に即した具体的なAI応用に注力しているため、最上位の競争相手、ひいては小売専門ベンダーのリーダーとも言えるでしょう。 主なリスクは、その複雑さ（すべての機能を実装するのは容易ではないこと）と、どれだけハイプ（AI至上主義）がユーザーフレンドリーで保守可能なソリューションに変換されるかにかかっています。 現時点では、RELEXはその約束を概ね実現しており、将来志向の小売最適化においてトップクラスの選択肢となっています。

情報源: RELEXの機械学習駆動の予測要因（需要パターン、プロモーション、外部イベント）28；プロモーション予測におけるMLを用いたカニバリゼーションの処理9；自動化された、予測に基づく補充による劣化削減の実証24；AI駆動の品揃え収益性分析33。

3. o9 Solutions – 大きな約束（および注意点）を伴う野心的な統合計画

o9 Solutions（2009年設立）は、エンタープライズ計画のための「Digital Brain」の創造者として自社を位置付けています。これは、需要予測、サプライチェーン計画、収益管理などをグラフベースのデータモデル上で統合するプラットフォームです。 o9のビジョンは、需要計画、在庫・供給、商業計画、さらには財務計画間のサイロを打破し、エンドツーエンド計画のためのワンストッププラットフォームとなることにあります。 小売の文脈では、o9はマーチャンダイジングおよび品揃え計画、需要予測、供給計画に対応可能で、価格設定やプロモーション最適化を含むRevenue Growth Management (RGM)の機能も備えています41。 理論上、これはすべての共同最適化の要件を満たしていることになります。 o9は、CPG、製造業、そして一部の小売・消費者向け企業で支持を得ており、従来のAPS（先進計画システム）と比較して、最新のAI/MLおよびナレッジグラフアプローチを強調しています。 しかし、懐疑的なエンジニアリングの観点からは、o9は非常に先進的なアーキテクチャを持ちながらも、そのAI部分が実質なのか単なる流行語に過ぎないのかについて専門家の間で疑問視されるという、やや矛盾した側面があります。 我々は、o9のプラットフォームとしての幅広さと統合アプローチを高く評価しつつも、実際の需要予測の実行や重厚なインフラの要件については慎重な見方をしています。

共同最適化: o9の主要な価値提案は、すべての機能横断的な統合計画にあります。 小売業者にとって、これは一つのo9システムが、マーチャンダイジングの財務計画、品揃えの決定、需要予測、供給・補充計画、そして価格戦略をすべて連携して処理できることを意味します。 彼らは、Revenue Growth Management (RGM)について、「RGM、需要計画、サプライチェーン、IBPを一つのプラットフォームに統合する」と明示的に宣伝しています41。 これは、価格設定やプロモーション（RGM）が単体ではなく、需要計画に組み込まれ、それが供給計画へと反映されることを示唆しています。 実際、o9には各分野ごとにモジュールやアプリが存在しますが、すべてが一つの統合体の下に置かれています。 例えば、o9の実装では、需要計画モジュール内に価格弾力性モデルが組み込まれており、プランナーは価格変更が予測に与える影響を確認し、すぐにその結果が在庫や生産計画にどう反映されるかを把握できます。 さらに、彼らのEnterprise Knowledge Graph (EKG)コンセプトは、商品、店舗、仕入先、制約条件などのすべてのデータがネットワークのように連結され、たとえば新たな品揃えの決定や価格変更といった変更がグラフ全体に影響を伝播する仕組みを提供します。 これは理論上、真に同時最適化―最高の利益とサービスを実現するために、価格調整と再発注を同時に行う―を可能にする可能性があります。 しかし、現時点でo9がこれらの次元において自動的に最適化しているのか、それとも統合された分析のみを提供しているのかは不明です。 多くの場合、顧客はo9を用いてシナリオ分析を実施します。たとえば、シナリオ1で「価格x、発注y」、シナリオ2で「価格x+5％、発注z」として結果を比較する、といった具合です。 これは統合計画ではあるものの、必ずしも単一の最適化アルゴリズムを使用しているわけではありません。 それでも、o9はそのエンジンにより複雑なシナリオの計算が可能です。 実際、o9は品揃え計画（マーチャンダイジング）とサプライチェーンを現実的に統合できる数少ないシステムの一つであり、小売業者はどの店舗にどのSKUを配置するかというカテゴリ戦略を立案し、その上でo9が在庫および補充計画を同時に策定し、供給がマーチャンダイジング計画に沿うようにします。 多くのレガシーシステムでは、これが断片的なステップで行われています。 また、o9は仕入先との協力や多層計画も同一プラットフォーム上で実現しており、上流の供給問題が下流のマーチャンダイジングの意思決定に反映される仕組みとなっています。 これらの全体的な統合は大きな強みであり、非常に先進的なものです。 ただし、主な課題は複雑性にあり、これらすべての要素を一つのシステムでモデル化するには大規模な設定およびデータ統合が必要となります。 一部のユーザーは、o9は全てを実行できるものの、実装段階ではまず需要および供給計画に注力し、価格設定や品揃えは後のフェーズに回すことがあると報告しており、共同最適化は即時的な現実というよりは将来の可能性に近いと言えます。 我々は、共同最適化におけるo9のビジョンとアーキテクチャには高い評価を与えつつも、完全に統合された価格・在庫の意思決定を実際にどれだけの顧客が利用しているかという点については慎重な姿勢を取っています。 それでも、プラットフォームの能力は十分に備わっており、これはほとんどのシステムに比べても大きな評価点となります。

確率的予測とAI: o9は確かに自社をAI駆動プラットフォームとして売り出しています。専用のMLエンジンを備え、多数の外部変数（例としてGoogleトレンド、天気、社会経済データなどをデモで使用）を予測に取り込むことができます。ナレッジグラフは、すべてのデータをリンクすることで機械学習アルゴリズムが需要の予測因子を見つけるのに役立つとされ、より優れたAIを実現すると主張されることもあります。しかし、批判的な視点も必要です。ある独立した分析では、「グラフデータベース（EKG）に関する多くの予測主張は疑わしく、科学文献で裏付けられていない。大量のAIハイプがあるが、Githubで見られる要素は平凡な手法を示唆している。」 42と述べています。これは、o9の実際の予測手法がマーケティングで示唆されるほど革新的ではなく、華やかな用語で包まれているにもかかわらず、実際はかなり標準的な時系列モデルや回帰分析を用いている可能性を示唆しています。実際、o9はシンプルなインタラクティブ機能さえも「AI」と呼ぶことで批判されており、例えばシナリオを迅速に生成することは（インメモリ計算による）ツールの特徴ですが、シナリオプランニング自体はAIではなく単なるシミュレーションです。とはいえ、o9には機械学習の機能もあり、プロモーションや新製品導入のためのMLモデル（属性に基づく予測など）を構築できます。また、データサイエンス強化のために小規模なAI企業（Fourkind）を買収しており、パターン認識や異常検知のためのMLを実装していますが、これは他の現代的なベンダーが行っているものと類似している可能性があります。グラフモデル自体が予測精度を本質的に向上させるという証拠はほとんどなく、主にデータ整理に役立っています。o9の予測は、シナリオに対してモンテカルロシミュレーションをサポートするという意味で確率的ですが（例：1000通りの需要パスをシミュレーションして結果分布を確認する）、Lokadのようにデフォルトで完全な確率分布を出力することはあまり強調していません。したがって、純粋な確率的予測の成熟度においては、専門のプレイヤーに後れを取っている可能性があります。ただし、o9は他の方法でもAIを組み込んでおり、例えば、AI搭載のサプライチェーンリスクツールを用いて潜在的な混乱を予測するなど、従来の予測の枠を超えた取り組みも行っています。また、新たに生成AIアシスタント（システム照会用のチャットボットインターフェース）も導入しており、これはコアの予測機能というよりはUI側面ですが、AI技術への投資を示しています。総じて、o9は優れたAI機能を有すると評価できるものの、主張されるほど差別化されていない可能性があります。従来の手動予測に依存するAPシステムを凌駕する一方で、RELEXやLokadといった同業者と比較すると、o9の予測アプローチは他の多くの計画要素とのバランスを取っているため、焦点が散漫に見えるかもしれません。専門家42の懐疑的な意見は、o9のAI主張をそのまま受け取るべきではないことを示唆しており、我々は予測精度向上の独立した検証を見ることを望んでいます。それまでは、o9のAIは信頼できるものの、やや過剰にマーケティングされていると考えます。

経済的意思決定: o9のプラットフォームは非常に柔軟で、財務を含む様々な目的の最適化に向けて設定することが可能です。統合型ビジネスプランニング（IBP）の文脈では、o9は収益、利益率、サービスなどを基にシナリオを評価する企業の支援を行っています。小売業においては、彼らのRGMモジュールは価格弾力性と利益率を明示的に考慮すべきであり、これにより意思決定が直接的に利益と収益の結果に結びつきます。彼らは、収益性に関する「もし〜なら」シナリオを実行する能力を備えており、例として「このカテゴリーの価格を5%下げたらどうなるか？利益や販売量はどう変化するか？サプライヤーは追いつけるのか？」といったシナリオを実行できます。これは計画と財務指標を整合させるものです。しかし、o9が自動的に最適化するのか、単にサンドボックスを提供するだけなのかは疑問です。o9の価値の一部は、部門横断的な意思決定を可能にする点にあり、例えば、あるプロモーション計画が供給制約により売上損失を引き起こすことをユーザーが確認し、その制約下で利益を最大化するように調整を行う、といったことがo9のツール内で可能です。これにより、透明性と迅速なシミュレーションが提供され、経済的意思決定が促進されます。さらに、o9にはサプライチェーンやおそらく価格設定にも対応する最適化ソルバーが組み込まれており、マルチエシェロン在庫最適化（複数の配送拠点や店舗間で在庫をバランスさせ、目標サービスレベルに対してコストを最小化する）やプロモーションカレンダー最適化（目標達成のための最適なプロモーションスケジュールの選定）などを実行できます。例えば、アソートメントアロケーションにおいて、各店舗での什器面数や製品群の配置を最適化し、売上や利益などの特定指標を最大化することが可能です。これは経済的目標に沿った数学的最適化です。o9のプラットフォームはカスタマイズ可能で、ある小売業者は在庫のために「期待利益率から保管コストを引いたものを最大化する」という目的関数を設定し、別の小売業者は「収益を最大化する（ただし条件Xに従う）」といった設定を行えます。つまり、柔軟性がある一方で、o9自体が経済的アプローチを義務付けるわけではなく、顧客が選択すればより手動的またはヒューリスティックな方法で使用することも可能です。彼らが「意思決定中心のプランニング」や「デジタルブレイン」といったマーケティングを展開するのは、システムが最良の意思決定へと導くことを示唆しています。しかし、一部の批評家は、o9の派手なデモが依然として多くの人間の分析に依存しており、完全自動の最適解を示すものではないと指摘しています42。我々は、o9の典型的な利用方法は、プランナーにシナリオとKPI（コスト、利益など）を提示し、プランナー自身が最終的な決定を行うものであって、システムが一つの最適な回答を自動的に提示するものではないと考えています。機会費用の観点では、在庫切れによる失われた利益のコストなど、o9が本質的に計算しているかどうかは明確ではありません（設定すれば可能でしょう）。価格最適化において、o9のRGMを利用すれば、需要の弾力性カーブを考慮した数学的最適化により、財務目標達成のための価格設定が可能となり、他の価格最適化ツールと類似のアプローチを取ると考えられます。すなわち、経済的に駆動されることは可能です。全体として、o9は運用と財務両面の計画を組み合わせる設計であるため、経済的意思決定を強力に促進しますが、その自動化の程度は状況により異なります。彼らが計画とビジネス成果を結びつける点は評価に値しますが（セールスピッチは財務とサプライチェーン計画の壁を打破することを強調しています）、真に利益最適な意思決定を実現するには、実装時にかなりのモデル構築と調整が必要になることに留意すべきです。

スケーラビリティとアーキテクチャ: o9のアーキテクチャはその特徴の一つで、最新のインメモリ計算エンジンとエンタープライズナレッジグラフを用いて、非常に連結性が高く効率的な構造でデータを表現しています。これにより、迅速なトラバーサルと計算が可能となります。例えば、予測を変更するとすぐに供給計画が更新されるなど、ほぼ即時の変更伝播が実演されます。これはKinaxisが並列処理を実現する方法に概念的に類似していますが、グラフDBならではのひねりがあります。しかし、先の懐疑的意見が示すように、「o9の技術量は企業基準でさえも桁外れであり、インメモリ設計は高いハードウェアコストを保証する。」 4。つまり、o9は膨大なデータと計算をメモリ内に詰め込むため、大企業で運用する際にはがっしりとしたサーバーや高額なクラウド費用が必要となる可能性があります（これはRELEXの状況に類似しています）。o9はクラウドベースで提供され（SaaSとして提供され、しばしばAzure上で運用されています）柔軟性を提供しますが、小売業者が自社の全ネットワークに加え詳細な財務・商業データを用いてモデル化する場合、モデルは極めて大規模になる可能性があります。一方で、グラフモデルは関係性を優雅に保存するため、素朴なデータテーブルよりもメモリ効率が良いという利点があります。しかし、批評家はそれでもなおかなり負荷が高いと示唆しています。実際、初期のo9展開では高いメモリ使用量が問題視されていました。改善はされているものの、クラウドを利用すればある程度水平にスケールすることが可能です（ただし特定の計算には依然として大きな共有メモリが必要です）。ユーザー数におけるスケーラビリティは良好で、高性能のバックエンドにより多数のユーザーが共同作業でき、各々が異なる視点でシステムを利用できます。o9はFortune 500企業にも採用され、非常に大きなCPGや世界規模のファストフードチェーンも含め、大企業向けのスケーラビリティが証明されています。コスト効率に関しては、企業向けの価格設定とリソース需要を考慮すると、o9の運用は安価とは言えないという逸話的な証拠もあります。コストに敏感な場合、よりスリムなソリューションが選ばれるかもしれませんが、企業全体でのリアルタイム統合プランニングを重視するなら、o9はその価値を提供し、その分計算資源を多く消費することになります。パフォーマンス面では、o9はプランを非常に頻繁に再計算可能で（一部は日次や短期間の intra-day で実施される）、これは従来の週次バッチプランニングサイクルに比べて改善されています。さらに、マイクロサービスと「プラットフォーム」アプローチにより、計画の一部だけを更新することができ、全体をゼロから再計算する必要がありません。ナレッジグラフは新規データの流入に合わせて段階的に更新され、現代的でスケーラブルな設計となっています。まとめると、o9は非常に大規模な問題に対して技術的にスケール可能ですが、ユーザーは大きなハードウェアやクラウド使用量に備える必要があります（プラットフォームは強力ですがリソース消費が激しいです）。真に軽量で専門性の高いソリューションと比較すると、o9はより多くのメモリを使用する傾向があります。したがって、スケーラビリティについては、能力面で高評価を与え、コスト効率については中程度と評価します。

複雑な小売要因への対応: 初期状態ではo9は、RELEXのような小売業特化の事前定義された機能がそれほど多くないかもしれませんが、設定により対応可能です。例えば、カニバリゼーションとハローでは、o9のMLモデルはトランザクションデータを投入すれば、RELEXと同様にこれらを検知できます。おそらく、データサイエンスチームが適切な特徴を定義するか、o9のMLアシスタントを利用する必要があるでしょう。o9の資料には、組み込みのプロモーションカニバリゼーションモデリングに関する明示的な言及はなく、おそらくは別モジュールではなくML予測を通じて行われていると思われます。代替効果については、o9が在庫レベルを追跡できるため、例えば、あるSKUが在庫切れになったときに相関するSKUの需要が上がるというルールまたはMLモデルを設定することで対応可能です。ただし、これも明示的にモデル化する必要があるかもしれません。有効期限/生鮮品に関しては、o9はバッチ属性を管理でき（データモデルに有効期限などの商品属性を取り入れることが可能）、小売業者は商品の残存期間に合わせた生産と流通の計画を立てることができます。ただし、制約や目的をカスタマイズする必要があるかもしれません。専用の生鮮食品ソリューションではないため、そのロジックを実装しなければ自動的に劣化予測を算出することはありません。それに対して他のベンダーはその機能を標準搭載している場合があります。つまり、o9は対応可能ですが、ユーザーがそれをモデルに含める認識を持つ必要があります。プロモーションと季節性は確実に対応されており、o9の予測と計画はプロモーションによる持ち上がり効果を考慮しています（プロモーションを入力し、それに応じて予測や供給計画を調整するプロモーション計画モジュールがあります）。また、マルチエシェロン在庫計画にも対応しており、DCや店舗全体での在庫レベルを最適化し、需要の不確実性に巧みに対応することができます。我々は、o9が業種横断型であるために、小売に特化したアルゴリズムがあらかじめ多く用意されているわけではなく（例えば、ロジックを設定しなければ自動的に「この商品はあの商品に代わる」と提案することはない）と疑っています。しかし、その柔軟性により、どのような小売要因もモデル化可能です。また、彼らは**「コントロールタワー」**と称する、在庫切れ、販売損失、過剰在庫などを監視するダッシュボードを提供しており、カニバリゼーションや品揃えの問題を特定するのに役立ちます。加えて、o9のナレッジグラフは外部データと統合できるため、天候などの情報を取り入れて予測を調整することも可能です（設定すれば）。多くのo9小売クライアントは、外部需要シグナルを利用している可能性があります。アソートメント最適化は、彼らの提供の一部として明示されており（「マーチャンダイジングおよびアソートメントプランニング」ソリューションとしてリストされています）、店舗ごとの理想的なアソートメントを解析し、地域の嗜好やスペースの制約を考慮に入れる分析を行うことが可能です。IBPと組み合わせることで、アソートメントの変更が供給面で実現可能であることも保証されます。これにより、地域ごとの需要の複雑性に対応できます。総じて、o9は複雑な要因に対して対応可能ですが、その機能を十分に活用するためには有能な実装チームが必要です。小売専用のベンダーほど初期状態で小売の詳細に対応しているわけではありませんが、一度設定すれば競合に匹敵する能力を発揮します。なお、先の専門家のコメントは、o9の先進的に聞こえる技術の一部が実際には、tsfreshやARIMAといったオープンソースプロジェクトなど、より単純な手法に依存している可能性を示唆しており、プロモーションに対しては線形回帰などの基本的な手法が用いられている可能性があることも指摘されています。もしそれが事実なら、o9は非線形のカニバリゼーション効果を真に捉えるためにアプローチを深化させる必要があるかもしれません。それでも、リソースとAIへの注力を考えれば、改善は進んでいると考えられます。複雑さに対する柔軟性においては高評価、特に小売のエッジケース（生鮮食品など）における実績は中程度と評価します。

自動化: o9のプラットフォームは主に計画および意思決定支援ツールであり、迅速にプランやシナリオを作成することに優れています。自動で実行されるかどうかは主にユーザー組織に委ねられており、多くのo9ユーザーはシナリオの選定やプランの承認にプランナーを関与させています。しかし、o9は継続的な計画の機能も提供しており、「リアルタイム・ワットイフ」や「継続的な再計画」といった自動化を示唆する概念を強調しています（システムは状況の変化に合わせてプランを常に更新します）。例えば、ある地域で需要が急増した場合、o9はプラン内で在庫を自動再配分し、早期出荷を提案することができます。マーケティング上では、o9のアプローチが*「自律的計画」と呼ばれることもありますが、実際はプランナーを補完するものであり、完全に置き換えるものではありません。とはいえ、o9はデータを監視し推奨を行うAIエージェントなどの機能を導入しており、新たなGenAIオーケストレーターは「企業がより迅速かつ賢明な意思決定を行い、プランナーの生産性を向上させる」*と謳われています 43 —— 主にプランナーがインサイトを得るスピードを加速させるためです。完全な無人自動化（例：自動発注や価格変更の自動実行）はo9では一般的に言及されず、通常は最適化されたプランをERPや実行システムに供給し、それが実行する形です。したがって、o9における自動化は、実行そのものよりも計画プロセスの自動化（手作業のスプレッドシート計算の排除、予測の自動更新、プラン逸脱時の自動アラートなど）に重点を置いており、LokadやRELEXのようなシステムとの違いは微妙です。o9は計算を自動化し意思決定の推奨を提供しますが、実際の最終判断は人間が下すことが多いです；一方、LokadやRELEXは自動的に実際の注文や価格変更を生成するように設定されることが多いのです。それでも、企業が望めばo9の出力を自動的に承認された意思決定として扱うことは可能です。例えば、o9は日々の注文管理システムに直接送られる注文提案を出力でき、また新たな転送料金や値引き提案を計算して店舗へ供給することもできます。その能力は備わっているものの、通常のo9ユーザー（多くは大企業）は重要な意思決定において人間を関与させています。さらに、o9のシナリオプランニングの強みは、人間による試行錯誤の必要性を低減しており、システム自体がほぼ自動のブレインストーミングのように無数のシナリオをシミュレートするため、評価の自動化が実現され、人間は最も有望な選択肢から選ぶだけで済みます。これにより意思決定は劇的に迅速化され、プランナーの生産性が向上します。また、承認や通知などのワークフローにより、例外が自動的に適切な担当者にルーティングされる仕組みも備えています。懐疑的に言えば、o9の「デジタルブレイン」というマーケティングは自律走行サプライチェーンを示唆しますが、実際は熟練の操縦士を必要とする非常に優れた意思決定コックピットに過ぎません。我々は、計画計算の自動化においては中から高評価を与える一方、完全自律の実行については低評価としています。従来の多数の手動入力を必要とするシステムと比べれば、o9は大きな前進ですが、小売オペレーションを自律的に運営する理想的なAIと比べると、まだ到達していない（ほとんどのシステムも同様です）。

テクノロジー統合: o9は元i2 Technologiesのベテランによってゼロから構築された単一のプラットフォームであり、買収したモジュールの寄せ集めを引き継いでいないため、統合の面で有利です。そのマイクロサービス・アーキテクチャと統一されたデータモデルにより、システム全体の各部分がシームレスに連携します。予測と供給計画のために別々のデータベースを用意する必要はなく、Knowledge Graphに全てのデータが格納されます。これにより、予測システムと在庫最適化システム間の従来の統合上の問題が回避されます。全てのデータは一度o9に読み込まれ、その後、内部の各「アプリケーション」が共通データを操作します。また、ユーザーエクスペリエンスも統一されており、すべてのモジュールで共通のウェブベースのUIやカスタマイズ可能なダッシュボードが提供されるため、ユーザーからは一つのシステムで全ての計画業務が実施されているように感じられます。これはフランケンシュタイン的な解決策に対する大きな優位点です。しかし、o9が成長するにつれて、多くの機能が追加され、場合によってはAIコンサルタントや供給チェーン設計向けの小規模な企業を買収した可能性もあり、その周辺領域での統合が必要になることもありますが、コアの計画部分は統一されたままです。ある専門家は、o9について*「大手テックベンダーの原型」であり、*「技術量が尋常ではない」*と述べ、内部の複雑さを示唆しました 4。これは、買収によるフランケンシュタインではなくとも、o9自体のプラットフォームが巨大であるため、実装や保守が複雑になる可能性があることを意味しています。しかし、これは異なる技術の統合ではなく、内部複雑性の問題です。エンタープライズの購買者は、ベンダー数やインターフェースが削減される統合プラットフォームを好むため、o9の強みは、予測、供給計画、S&OPなどを別個に購入する必要がない点にあります。ただし、プラットフォームの一部が最高水準でない場合、別のツールと統合しなければならず（それは本来の目的に反します）、リスクとなる可能性があります。「技術スタックの一貫性」に関しても、o9は主にMicrosoftのテックスタック（.NETなど）を用い、自社開発のグラフデータベース構造を利用しているため、サブシステム間でのデータの重複や論理の不整合といった問題は見受けられません。トレードオフとして、o9を採用するということは、自社のプロセスをo9のプラットフォームアプローチに合わせる必要があり、大きな変化を伴いますが、ITの観点からは複数のレガシーシステムと比べるとシステム全体がシンプルになる可能性があります。つまり、o9はフランケンシュタインではなく、設計された脳であり（非常に複雑ではありますが）、顧客がそれを完全に受け入れれば長期的な保守性に優れますが、初めは圧倒される可能性もあります。我々は、o9が「一貫した技術スタック」の基準を十分に満たしていると考えています。

過剰宣伝への懐疑: このリストの中で、宣伝ブームのアラームを鳴らすベンダーがいるとすれば、それはo9かもしれません。彼らはEnterprise Knowledge Graph™、Digital Brain、AI/ML、さらにはGenerative AIなどのバズワードを多用しています。彼らのマーケティングは洗練されている反面、技術的な具体性に乏しく、むしろ大局的な利点に焦点を当てています。例えば、AI/MLフレームワークを持っていると謳いつつも、具体的にどのアルゴリズムを使用しているかについてはあまり語られないのです（LokadやToolsGroupのようなベンダーは、確率モデルやニューラルネットを率直に論じるのに対し、o9はより抽象的なレベルに留まります）。実際、一部の業界関係者はo9を*「AIシアター」と非難し、派手なデモと大量の解析を誇示しながらも、裏では非常に標準的な手法を用いていると指摘しています 42。以前引用されたLokadの報告では、o9はランキングの下位に位置付けられ、「大量のAI宣伝」や些細なインタラクティブ機能がAIとしてブランド化されていると述べられています 42。これは競合他社の視点による厳しい批判ですが、o9のマーケティングが実証された現実を上回って先行しているという印象と一致します。さらに、o9は未来的な表現で機能に名前を付け、例えば「量子学習」エンジンと謳っています（これは2023年のEvo買収から借用された用語で、最先端に聞こえますが、本質的にはアンサンブルMLアプローチです）。また、「グラフキューブテクノロジー」としてデータを接続する技術についても語られます 44 が、これは顧客を混乱させる可能性もあります。需要感知やデジタルツインといったバズワードもo9が用いる可能性があります（ただし、正直に言えばツインではなくknowledge graph／デジタルブレインとして表現しています）。懐疑的な立場からは、o9が示唆するような劇的な成果（例：より良い計画だけで10%の収益増加）が実際に達成されているのか疑問視すべきです。実際に良好な結果が報告されている一方で、o9がSAPなどと比べて若いため、独立した参考資料は少なめです。さらに、o9はプラグアンドプレイクラウドプラットフォームとして、旧来のシステムよりも迅速に実装できると位置付けていますが、全社のモデル化は簡単ではないため、実装には相当な時間とコンサルティングが必要とされる場合もあります。したがって、o9を展開すれば即座に統合計画が得られるという考えは楽観的すぎます。確かに個別ツールを複数実装するよりは早いですが、「即時」とは言えません。それでも、o9が現代的な技術とUIを必要としていた領域に真に導入され、多くの顧客が満足している点は評価に値します。おそらく、従来よりもはるかに優れた計画能力を提供しているでしょう。つまり、宣伝の一部は正当化され、o9は次世代の計画システム*であるといえます。重要なのは、彼らの主張を冷静に解釈することであり、もし「我々のAIが自律的にあなたのビジネスを最適化する」と言えば、話半分に受け止めるべきです。むしろ「我々のプラットフォームは、あなたのビジネスをより良くモデル化・最適化できるが、その操縦はあなたのチームが行う」という点を理解すべきです。特にAIによる予測精度やROI改善などの高尚な主張に対しては、具体的なデモや実証を要求することが望ましいでしょう。フレームワーク自体は強力ですが、その活用法が結果を左右します。結論として、o9のマーケティングはバズワードにおいて攻撃的な面があるため、健全な懐疑心を持つべきですが、実質面ではかなり強力なプラットフォームを有しており、ただし「AI」とラベル付けされているものすべてが革新的なAIであるとは限らず（一部は単に効率的な計算に過ぎない）、購入者は慎重なデューデリジェンスを行う必要があります。我々は、o9に対しマーケティングの誠実さでは中程度の評価を与えています。

まとめ: o9ソリューションズは、小売最適化に対して驚くほど広範で統合されたプラットフォームを提供し、マーチャンダイジング、サプライチェーン、価格決定を繋ぐ「デジタルブレイン」として機能することを目指しています。そのKnowledge Graphアーキテクチャとインメモリエンジンにより、迅速かつ同時並行な計画立案と豊富なシナリオ分析が実現されます。o9は価格、需要、供給の共同検討をサポートし、一つのツールで品揃え戦略や価格戦略と在庫・供給の制約を連動させる、真のIBPのビジョンを実現しています。予測と分析においてAI/MLを活用しているものの、その進化の度合いには議論の余地があります 42。このシステムは、計算負荷が高いながらも複雑な要因や大規模データセットを取り込むことが可能です。スケーラビリティはエンタープライズグレードであり（数十億ドル規模の企業で使用されています）が、コスト効率についてはインメモリ方式がハードウェアを大量に消費する可能性もあるため懸念が残ります 4。o9は計算やシナリオプランニングの自動化によりプランナーを支援しますが、しばしば完全自律の意思決定者ではなく、意思決定支援システムとして機能します。技術的には自社内で構築された統合プラットフォームであり、フランケンシュタイン的なスイートの欠点を回避しています。主な注意点は、過剰宣伝の傾向と、魔法のようなAIや「即時」変革の主張に対しては慎重な評価が必要である点、そしてこの包括的なシステムの実装が複雑である点です。統合計画プラットフォームへの投資を厭わない先見の明のある組織にとって、o9は将来性のあるアーキテクチャと柔軟性を提供する有力な候補ですが、成功にはマーケティングの誇大表現と現実を切り離し、その潜在能力を真に活かすようソリューションを構築することが必須です。我々の懐疑的な評価では、o9はビジョンと統合性で高得点、実証済みのAI差異では中程度、そしてバズワードに依存した約束に関しては慎重な精査が求められると評価されます。依然として最先端のプラットフォームの一つであり、実態が販売トークと一致しているかを注意深く確認する必要があります。

出典: o9のインメモリ設計とAI主張に対する批評 4；o9の統合RGM（価格設定）および計画プラットフォームの主張 41；在庫への価格影響をリンクするためにデータを活用するBlue Yonderの見解（o9が採用する類似のアプローチとして） 27.

4. ToolsGroup – 実績ある在庫最適化、統合小売計画への進化（AI追加機能付き）

ToolsGroupは確立されたベンダーであり（1993年創業）、歴史的には需要予測と在庫最適化に焦点を当てたService Optimizer 99+（SO99+）ソフトウェアで知られていました。製造業と流通業において強固な実績を持つ一方、補充計画に関しては多くの小売や消費財の顧客にも支持されています。近年、ToolsGroupは買収を通じて能力を拡大しており、特にJustEnoughの小売計画スイートやAI企業Evoの買収により、アソートメントおよびマーチャンダイズ計画、需要予測、在庫最適化、そして現在は価格最適化を含むより完全な小売最適化プラットフォームを提供するようになりました 45 46. ToolsGroupの特徴は、在庫計画における確率論的予測の活用と、高度に自動化された「サービスレベル駆動型」サプライチェーン計画の哲学にあります。現在、買収したモジュールとAI強化により、在庫と価格設定を共同で最適化し、エンドツーエンドの小売計画（「意思決定中心の計画」としてブランド化）を実現することを目指しています。我々は、ToolsGroupを、深い在庫最適化の専門知識を有する堅実で技術的に有能なプレイヤーと評価していますが、新要素の統合過程にある点には留意すべきです。特定の領域（予測の不確実性、自動化）では卓越していますが、その統合ソリューションがどれほど真に統一され現代的であるかについては精査が必要です（「AI」に関する一部のマーケティング主張には懐疑的な見解が寄せられています 19）。

連携最適化: 歴史的に、ToolsGroup は 在庫面 に注力しており、不確実性を考慮して目標サービスを満たすための適正な在庫レベルの確保に努めていました。価格設定や品揃えはその範囲外でした。しかし、JustEnough（商品財務計画、品揃え、配分の専門家）の買収と Evo の価格最適化 AI の統合により、ToolsGroup は 価格設定と在庫の同時最適化 能力を宣伝するようになりました。例えば、新製品には 小売価格設定 ソフトウェアが含まれており、価格変更が需要に与える影響をシミュレーションして収益に反映させることができます 47 48。そして重要なことに、在庫レベルの全体像を把握したうえでシミュレーションが行われます 48。価格と在庫の統合は、システムが在庫状況を認識した上で価格アクションを提案することを意味し（売る在庫がなければ価格を下げても意味がありません）、連携最適化において必須となります。彼らは、価格設定ツールが 「現在の在庫状況と販売速度の完全な把握」 を提供することで、サプライチェーン全体の在庫を踏まえた価格決定が行われると強調しています 48 49. これは、在庫が多ければ値引きを促し、在庫が不足していれば価格を維持または（戦略の範囲内で）上げるという、調整されたアプローチを示唆しています。さらに、ToolsGroup の Evo とのロードマップは、供給計画に反映される動的な価格最適化 を実現することにあります 50 51。Evo の AI は価格と在庫の意思決定を連携させることに特化しており、CEO は、価値連鎖全体でより良い意思決定を促すために 「最適な価格と在庫の計算を同時に実施する」 ことを目標としていると述べています 52。これは、在庫制約と予測需要を前提として利益を最大化する価格を算出するアルゴリズムと、その需要を支える在庫計画を見出すアルゴリズムという、統一あるいは密接に連携する最適化アルゴリズムの存在を示唆しています。Evo は2023年末に買収されたばかりであるため 46、統合は進行中である可能性がありますが、ToolsGroup は価格と在庫の最適化を連続的なステップではなく、ひとつの枠組みで行う意向を明確に示しています。品揃え に関しては、JustEnough のコンポーネントが、どの商品をどの店舗に配置するか、初期在庫をどう配分するかなどの品揃えおよび配分計画のツールを提供しており、これが需要予測や補充と並んで機能しています。上手く統合されれば、ToolsGroup は 製品ライフサイクル全体、つまり品揃えの計画、初期配分の設定、需要予測、在庫の監視と補充、そしてライフサイクル終盤の価格調整（値下げ）を最適化することが可能となります。理論上は全ての要素が揃っていますが、これらがどれほどスムーズに連携するかが課題です。これらが別々の製品であったため、統合はまだシームレスではないかもしれません（とはいえ、ToolsGroup は「モジュラーソリューションアーキテクチャ」により、一体的に統合していると主張しています 53）。現状では、ToolsGroup の連携最適化は、価格モジュールが予測モジュールから予測を受け価格を最適化し、その結果として在庫モジュールが需要を受け在庫を最適化するという、より順序的なプロセスになっている可能性があります。将来的には、Evo の先進的な解析により、これらが一つのループに統合され、直接的に利益（価格 と 数量）を最適化するかもしれません。現段階では、ToolsGroup が価格と在庫の両方の機能を備えている点で、連携最適化に向けた大きな進展が評価されるでしょう。

確率的予測とAI: ToolsGroup は、サプライチェーンにおける確率的需要予測の先駆者でした。流行るずっと前から、SO99+ は単一の数値ではなく 需要分布 を生成し、目標とするサービス確率を達成するための最適な在庫レベルを計算していました。このアプローチは、平均予測や安全在庫の計算式を用いる多くの従来型ツールとの差別化要因となっています。ToolsGroup はこの分野で広範な知的財産を保有しており、例えば、SKU ごとにモンテカルロシミュレーションや解析的確率モデルを用いて需要変動を予測し、その後在庫方針を決定する手法を活用しています。これが彼らの主要な強みの一つであり、ToolsGroup の手法により、単純な安全在庫方式に比べ、高いサービスレベルが低在庫で実現されることが多かったのです。彼らは、不確実性の高い環境で本質的に価値を発揮する確率的予測について、今も市場に啓蒙活動を続けています（彼らの資料では、確率的予測が不可欠であると述べられています 54）。しかし、重要な点として、これまで ToolsGroup はクライアントやマーケティングにおいて MAPE のような指標を報告してきました。Lokad のレビューは、ToolsGroup が 2018 年以降に確率的予測を宣伝しつつ、MAPE の削減も主張している点に矛盾がある（「MAPE は確率的予測には適用されない」 19） と指摘しています。これは、マーケティングが最新の方法論に追いついていないのか、もしくは比較のために期待値予測も生成しているのかのどちらかを示唆しています。いずれにせよ、彼らが確率的思考を採用しているのは明らかです。AI/ML の分野では、ToolsGroup は需要を左右する要因やパターン認識のために、より多くの機械学習を取り入れ始めています。従来は、断続的需要に対する Croston 法などの統計的手法を用いていましたが、現在では 因果要因の取り込み、プロモーションに対する回帰分析、さらには機械学習のアンサンブル といった機能を備えています。Evo の買収により、先進的な AI、すなわち Evo の「量子学習」と呼ばれる、高度な ML アルゴリズム（独自のアンサンブルまたは強化学習手法の可能性あり）が導入され、迅速な最適意思決定を目指しています 55。ToolsGroup は Evo の統合により、ソリューションに 「非線形最適化、量子学習、および先進的な処方的分析」 を追加していると明言しており 51、これは特に非線形な価格設定やプロモーションの意思決定において、AI の洗練度が向上していることを示唆しています。さらに、数年前に AI.io（旧 Halo Business Intelligence） を買収し、AI 主導の需要予測ワークベンチを取得しました。したがって、ToolsGroup は確実に AI の活用を進めています。しかし、Lokad の調査が指摘するように、ToolsGroup の AI に関するマーケティングは時に疑わしいもので、「ToolsGroup は広範な機能を備えているが、『AI』の主張は疑わしい。公開資料は2000年以前の予測モデルを示唆しており、『需要感知』の主張は科学文献で裏付けられていない。」 と述べられています 19。これは、これまで ToolsGroup が本質的には数十年前の予測手法（Croston 法、ARIMA など）を「AI」と称していた可能性を示唆しています。しかし、最近の EvoAI（2023）の導入 により、ToolsGroup の AI の実質は向上していると期待されます。Evo は、価格・在庫の最適化に特化した若い企業であり、ToolsGroup はその具体的な新機能（例えば、自動モデル選択、最新の変化に対応する応答アルゴリズムなど）を強調しています。また、ToolsGroup の確率的アプローチ自体も一種の AI（確率的モデリング）であり、従来の機械学習とは異なるにせよ、多くの他社が持たなかった洗練された解析手法です。したがって、ToolsGroup は予測力においては堅実であり、最新の AI においても同業他社に追いつきつつあります。**総じて、**ToolsGroup は信頼性の高い予測品質を提供し、機械学習によって需要の要因や価格と需要の関係に関するより深い洞察を得られるようになっています。確率的予測に関しては非常に高い評価を与え、AI革新については中程度と評価されます。古い手法と新しい手法の組み合わせは、適切に実行されれば非常に強力です。たとえば、機械学習でパターンの変化（例：COVIDによる変化）を検出し、その後、確率的モデルで在庫目標を調整する、といったハイブリッドアプローチが考えられます。ToolsGroup は実際にそのようなハイブリッドアプローチを採用していると考えられます。

経済的意思決定: 伝統的に、ToolsGroup の在庫への取り組みは サービスレベル最適化 として位置付けられており、目標とするサービス率または充足率を設定すると、その不確実性を考慮して必要最小限の在庫を算出するアルゴリズムが用いられていました。これは間接的には経済的（良いサービスは販売機会の損失を防ぎ、在庫削減は保管コストを抑制する）が、明示的に利益を最大化するわけではありませんでした。しかし、彼らは 多階層在庫最適化（MEIO） を組み入れており、これは在庫とバックオーダーコストなどを本質的にバランスさせる、経済的な最適化手法です。新たなビジョンでは、収益性がより前面に出るようになっています。ToolsGroup の CEO は、JustEnough との組み合わせにより、小売業者に対して 「リアルタイムで予測可能かつ実行可能な360度の視界を提供し、製品の供給状況をより効率的に改善し、今日の不安定な需要管理において競合に勝る成果を上げる」 と述べています 56。この引用はサービスと俊敏性を強調していますが、Evo 買収に関する広報はより直接的で、「動的な価格最適化によりリードを拡大し、意思決定中心の計画への次の飛躍を可能にする…未来の自律的サプライチェーンを実現するために不可欠である」 と述べています 51。「意思決定中心」という用語は、意思決定の結果（しばしば財務的なもの）に注目することを意味します。Evo の創業者は、「最適な価格と在庫の計算を通じて、人間のマネージャーがより賢明な意思決定を行えるようにビジョンを形作る」 と語っており 52、これは単にサービス目標を満たすだけでなく、（おそらく利益または収益の）最大化を目指す最適化を意味します。そして実際、「Evo の応答的 AI が自律的サプライチェーンを実現するための必須要素を提供する」 と述べられている通り 55、これは継続的に結果に基づいて意思決定を調整し、パフォーマンス指標を最大化する仕組みと同じです。価格設定の分野では、収益性が明確に重要であり、ToolsGroup の価格設定ソリューションは 「データに基づく価格戦略を構築することで収益性を最大化する」 ことを目的としています 57。このソリューションはルールベースの価格設定を可能にするだけでなく、消費者需要の変動に対応するために ML を活用し、設定された範囲内で 「利益率を最大化」 します 58。また、「完全な在庫状況と販売速度の把握により、さまざまな価格設定が可能となり、需要を満たすと同時に サプライチェーン全体のコストを最小化する」 という記述は、価格設定ツールが単に利益率だけを見るのではなく、在庫保管コストや値下げによる損失回避など、コスト最小化も考慮していることを示しています 48。これは、サプライチェーンのコストを組み込んだ経済的思考を反映しています。在庫においては、設定に応じて 「保有コストと品切れコスト」 を反映でき、経済的にサービスレベルを最適化することが可能です。実際、サービス目標は経済モデル（例：高利益率製品に対して高いサービスレベル）から導出されることもあります。ToolsGroup がこれを明示的に行っているかは不明ですが、顧客はしばしば外部でそのような分類を実施しています。さらに、Evo の処方的分析により、ToolsGroup は 利益最適の意思決定（不確実性を前提として、在庫数や価格をどう設定すれば期待利益が最大化されるか）の推奨に向かうと期待されます。基盤となる要素は既に整っており、Evo のチームはその方法論（学術的背景がオペレーションズリサーチの専門知識を示唆）を有していると考えられます。ただし、注意点として、ToolsGroup のメッセージングは依然として伝統的な KPI（サービス、在庫削減）に重きを置いており、直接的な利益指標には言及が少ない点が指摘されています。しかし、品揃え合理化機能（おそらく JustEnough に由来）による不採算SKUの削減や、顧客事例における在庫削減と販売／サービスの向上（結果としての利益改善）の報告など、収益性の強化に向けた取り組みが見受けられます。ToolsGroup が利益指標を直接最大化する事例は公表されていないものの、価格と在庫の最適化を組み合わせることで、そもそもその方向性が示唆されています。我々は、従来の「最低コストでのサービス」アプローチと新たな利益率に基づく価格戦略への転換を評価し、ToolsGroup にかなり高い評価を与えます。彼らはまだ Lokad のように機会費用にこだわってはいないかもしれませんが、単純なヒューリスティックスを超えた取り組みを確実に進めています。一点、Lokad のレビューでは、ToolsGroup の資料がやや時代遅れで MAPE などを使用している点が、期待コストの視点を十分に反映していない可能性を示唆していると指摘されています 59。それでもなお、Evo の導入と、価格と在庫の連携最適化を用いることで顧客に対して 「最高の財務成果」 を提供するといった発言 60 は、経済的目的への強いフォーカスを示すものです。

スケーラビリティとコスト効率： ToolsGroupのオリジナルSO99+は、通常、中〜大規模企業向けにオンプレミスまたはホスト型ソリューションとして展開されました。それは一部の大規模APSシステムほど重くはなく、設計上「難解な部分」（予測、在庫計算）に注力し、巨大なデータ統合は行いませんでした。多くの中規模企業でも成功裏に運用されました。数学的に最適化されているため、在庫最適化の計算負荷は大きくなく（アルゴリズムや場合によっては多段階の線形計画法で在庫配分を解く）、需要予測については、一晩で大量の系列を処理できる独自のエンジンが存在しました（例として）。現在では、必要に応じてよりスケールしやすいと思われる完全なクラウドSaaSオプションを提供しています。Gartnerの2024年レポートでは、ToolsGroupは新規参入企業として評価され、「手頃な初期導入コスト」および「透明な価格設定」が指摘され、場合によっては単一のグローバルソリューションとして採用されている（つまり、グローバルにスケール可能であることを示唆） 61 62。これは、ToolsGroupがそのカテゴリにおいて比較的コスト効率が良く、スケーラブルであると見なされていることを示しています。実際、歴史的にミッドマーケットに注力していたため、すぐに使える状態で、IT部門の大規模な人員を必要としませんでした。小売業では、データ量が膨大になる可能性があります（店舗SKUレベル）。買収された小売システムであるJustEnoughは、大手小売業者（私の記憶ではSephoraのようなクライアントもあった）にサービスを提供していたため、かなりの品揃えにも対応可能です。しかし、店舗レベルの細かい価格最適化のような側面は、データ集約型になる場合があります。ToolsGroupの典型的な展開は依然としてある程度バッチ指向であり、たとえば夜間または週単位での再予測や在庫更新など、リアルタイムではなく、多くの場合問題ありません。つまり、常時すべてをメモリに保持する必要はなく、必要に応じて計算し、メモリを解放できるのです。これは、常時メモリ内で処理する方式よりもコスト効率が高い方法です。一方、動的価格との統合には、より頻繁な計算サイクルが求められるかもしれません。彼らはEvoによる*「レスポンシブAI」を強調しており、これは条件変化時に迅速な再計算を意味します 55。Evoの技術は、ほぼリアルタイムの再最適化を可能にする可能性があり（スタートアップであるEvoは、速度向上のためにクラウドや場合によってはGPU計算を利用しているでしょう）、ToolsGroupは2022年にリアルタイム在庫可視性とフルフィルメント最適化のためにOneraを買収しており 63、これはリアルタイムのeコマースフルフィルメントの意思決定分野へ進出していることを示しています。これらの追加は必要な計算能力を増加させる可能性がありますが、市場でのポジショニングを考慮すると、ToolsGroupは大手小売業者だけでなく中規模小売業者にも効率的に対応することを目指しているはずです。現在のアーキテクチャは、SO99+のコア（おそらくC++で実装）と、JustEnoughモジュール（.NETやJavaである可能性もある）に接続するクラウドサービスという、いくつかのモジュラー要素で構成されています。これらの統合は、一時的に（２つのシステム間の通信による）オーバーヘッドを加えるかもしれませんが、ToolsGroupは積極的に統合を進めています。たとえば、「最近統合されたEvoAIエンジンのおかげで、JustEnoughがAI駆動の小売計画を牽引している」* 64という具合に、EvoをJustEnough/ToolsGroupソリューションに組み込んでおり、分離して運用しているわけではありません。ToolsGroupのフットプリントは、一般的にSAPやBlue Yonderよりも軽量です。たとえば、ToolsGroupのプロジェクトでは、内部ITチームが巨大なサーバーを管理する必要はなく、SaaSで対応します。彼らは*「モジュラーアーキテクチャにより、顧客が必要な製品を選択し、一体的なソリューションとして組み立てやすくなる」と述べており 53、これは使用しない機能を無理にロードする必要がなく、在庫エンジンのみを実行することも可能で、スケーラビリティに貢献します。総括すると、ToolsGroupは中程度にスケーラブル（多くの大手小売業者には適しているが、世界最大規模のハイパーマーケットチェーンでの実績はまだ証明されていないかもしれません）であり、かつコスト効率に優れる（特に透明な価格設定と、プランナーの作業負荷を削減する自動化に注力している点で）と評価されます。大量データを扱うための常時メモリ内の並行システムほどの高速性はないものの、結果を出すのに莫大なリソースを必要としません。Gartnerのコストに関する好意的な評価と、多くの中〜大規模クライアントを有していることを考えると、ToolsGroupは比較的効率的であると考えられます。さらに、リアルタイムのサプライチェーンイベント検知を目指す*「インベントリハブ」**の提供も言及されており 62、恐らく途方もないハードウェアを必要とせず、ストリーミング処理を活用してリアルタイム化に取り組んでいます。ToolsGroupのパフォーマンスに関する公の苦情は限られており、通常は十分と見なされます。従って、ToolsGroupは、複数の買収の統合が最適化されなければ一時的にシステムに負担をかけるという僅かな注意点はあるものの、この評価基準において高いスコアを獲得しています。

複雑な小売要因への対応： ToolsGroupは、歴史的に、需要の不確実性や変動性（断続的な需要、動きの鈍い商品、供給の変動性）に対して優れてきました。当初は、カニバリゼーションや賞味期限のような小売特有の現象に特化していなかったかもしれません。しかし、JustEnoughスイートの導入により、小売分野の機能が強化されました。JustEnoughは、プロモーション予測、（店舗の容量やマーチャンダイジングを考慮した）アロケーション、そしてマークダウン計画を提供しました。これにより、ToolsGroupはプロモーション関連の機能を備えることとなり、たとえば、プロモーションによる売上向上効果をモデル化し、時間をかけてその効果を分散させることで、基本的なレベルでカニバリゼーションに対処できます（プロモーションが初期の売上を引き上げれば、その後の期間で落ちる、といった具合です）。アイテム間のカニバリゼーションを自動的に識別するかというと、RELEXほど自動ではないかもしれませんが、既知のプロモーション効果を組み込むことは可能です。代替効果（在庫切れが代替商品の売上を促す現象）については、ToolsGroupの資料中では強調されておらず、手動で設定しない限りギャップとして残る可能性があります。ハロー効果（補完商品の影響）についても同様で、関係性を手動でモデル化するか、あるいはAIアプローチを用いる必要があるでしょう。この点では、新たなAIシステムEvoが、相関関係を見出すことで支援できる可能性があります。Evoのエンジンは、トランザクションデータから関連商品の予測や価格戦略を調整するための情報を抽出できるかもしれません。具体的な証拠がないため、ToolsGroupはある程度の工夫でこれらに対応できると仮定しますが、歴史的には最も得意な分野ではありませんでした。賞味期限および生鮮品： ToolsGroupは食品流通のクライアントを抱えていましたが、店舗レベルの生鮮品最適化については明確ではなく、おそらく主要な焦点ではありません。リードタイムやロットサイズは組み込むことが可能ですが、賞味期限の制約は明示的なモデル化（例：期限切れ在庫を別SKUとして扱う、または時間経過に合わせて予測値を下げるなど）が必要となります。JustEnoughのアロケーションモジュールは、シーズン商品に対応して、マークダウンを通じてシーズン終了までに売り切らせるといった運用が可能で、これは概念的に生鮮品に類似しています。実際、マークダウン最適化（JustEnoughの一部）は、在庫を残さずにクリアするための価格下落のタイミング調整を行うもので、これはシーズン終了時の「賞味期限」に対応するものと考えられます。ToolsGroupの価格ツールは、陳腐化を防ぎながら収益を最大化するために、いつどれだけマークダウンすべきかを提案してくれます 48。つまり、経済的側面から生鮮品の問題に対処しているのです。品揃えのローカライゼーション： JustEnoughの品揃え計画機能により、店舗のクラスタリングや各店舗に合わせた品揃えが可能となり、ToolsGroupは地域ごとの需要パターンやスペースの制約に基づいて品揃えの最適化を行えます。これは、たとえば、2商品が互いにカニバリゼーションを引き起こす場合、小規模店舗では片方のみを採用するという、間接的な解決策となります。スペース制約とディスプレイ： ToolsGroupは、JustEnoughを介して各店舗のフェーシング数や棚の容量をモデル化し、これがアロケーションおよび補充の意思決定に影響を与えます（例えば、棚にXの容量があればX以上は補充しない、といった具合）。これはプラノグラムソリューションほど細かくはありませんが、計画レベルでは十分に対応しています。プロモーション： ToolsGroupはプロモーション予測を扱い、プロモーション時の在庫計画も行えます（プロモーション中の在庫確保が改善された事例もあります）。新たなAI技術は、過去のプロモーションデータをより正確に分析することで、プロモーション効果の予測精度を向上させる可能性があり、これは短期的な需要感知に似たアプローチですが、Lokadは「需要感知」の主張に裏付けが不足していると指摘していました 65。カニバリゼーションやハロー効果については直接的な言及がなく、依然としてプランナーの専門知識に頼る可能性があります。ToolsGroupのフィロソフィーは、プランナーの作業を簡素化することにあり、例外対応によって管理しやすくする仕組みが構築されています。したがって、現状では、ToolsGroupは複雑な要因に対して有能ではあるが最先端とは言い切れないと評価できます。プロモーションやマークダウン、品揃えといった一般的な小売ニーズはカバーしていますが、商品間の相互作用や生鮮品の管理においてはRELEXほど高度ではないかもしれません。AIの追加やレスポンシブな調整への注力により、将来的にはこれらのパターンの自動検出が実現する可能性もあります。2021年当時、ToolsGroupの「需要感知」に関する主張は十分な裏付けがないとの批判がLokadから出されていました 65。そのため、その時点では実際のアルゴリズムが不足していた可能性がありますが、現在はEvoや内部開発により改善されているかもしれません。総じて、ToolsGroupは小売計画の基本（需要変動、プロモーション、製品ライフサイクルの終了）にしっかりと対応しており、品揃えの面でも十分な性能を示しながら、最先端の領域（例：MLによるカニバリゼーションのモデル化や代替の最適化）においてはまだ追いついていないと評価できます。

自動化： ToolsGroupは、歴史的に自動化および「無人」計画を強みとしてきました。実際、SO99+のセールスポイントは、プランナーの介入を最小限にして在庫方針の自動設定や補充注文の自動生成を実現できる点にありました。多くの顧客が、ToolsGroup導入後、予測や在庫の問題に対する「火消し作業」に費やす時間が大幅に減少したと報告しており、システムは変化に自動調整し、例外のみをフラグ付けします。彼らは予測に対して*「セルフアダプティブ」といった用語を用いており、これは新たな需要パターンに自律的に適応し、予測の常時上書きを不要にすることを意味します。**「パワフリーシンプル」**というコンセプト（彼らのタグラインの一つ）は、自動化によってプランナーの作業を単純化することを目的としていました。実際、ToolsGroupのシステムは、夜間のバッチ処理で予測値や在庫目標を更新し、その後各アイテム・ロケーションに対して注文案を提示します。プランナーは例外（サービスレベルが極端に低い、または在庫が非常に多いなど）のみを確認するため、実質的に大部分の品目についてライトアウトプランニングが実現されています。過去のマーケティング資料によれば、あるクライアントはSKU補充の90％を自動化し、上位10％の例外のみ手動でチェックしていたとされ、これは非常に高い自律性を示しています。さらに、これまで手動で行われていた**（品揃え計画の構築、初期アロケーション設定、財務計画の作成などの）計画タスク**を含むJustEnoughとの統合により、ToolsGroupは自動化とユーザー入力のバランスを維持する必要があります。品揃え計画は通常、戦略に関するマーチャンダイザーの入力が不可欠で、完全自動化は難しいですが、分析部分（例：低調なSKUの抽出など）は自動化可能です 33。価格面では、ダイナミックプライシングも一定の範囲内で自動化でき、ToolsGroupの価格モジュールでは、ルールを設定して、その枠内で価格変更を自動適用する仕組みが提供されています 66。例えば、在庫がX日分を超えた際に自動でマークダウンする、などの自動計算が可能です。彼らは「価格ルールを確立し、定められた境界内で自動的に適用する」と明記しており 66、これは監視付きの自動化を意味します。すなわち、システムが在庫と需要を監視し、条件がルールに該当すれば（場合によってはAIの提案で補強される）、価格変更を自動で実施することができ、これにより多くの意思決定がハンズオフで行われます。同様に、補充の提案も自動的にERPへ送信し、注文を実行できます。ToolsGroupは例外管理を重視しており、例外がなければシステムの出力を信頼する仕組みとなっています。さらに、EvoのAIにより、「自律型サプライチェーン」への移行も示唆しており 55、業界トレンドと一致しています。Evoの技術は、販売の逸脱があった場合、中旬で予測を調整し、再注文を自動実行するなど、より継続的な再最適化を可能にするかもしれません。ToolsGroupの新機能であるインベントリハブ（リアルタイムシグナル）は、需要の急増などのイベントを検知し、自動的に在庫の再配分や供給の迅速化を実現する狙いがあります。全体として、ToolsGroupは常に無人計画に重きを置いており、ルーチンな意思決定をシステムに任せています。実際、一部の顧客は大部分の業務でプランナーの介入を最小限に抑えた運用を行っています。したがって、ToolsGroupは自動化において非常に高い評価を受けています。唯一の制約は、品揃えや価格設定など、新たな領域においてユーザー戦略がより大きな役割を果たすため、完全な自動化が難しい点ですが、それでもタクティカルな部分（例：自動でマークダウン対象をフラグ付け、売上に基づく店舗のランク付けなど）は自動化されています。ルールベースの自動化とAIによる提案の組み合わせにより、ToolsGroupは手動による計画作業の大幅な削減を実現できるベンダーとして位置付けられています。実際、Gartnerは一部の新ツールについて「プランナーは人と機械の活動をオーケストレーションする」*と述べており、ToolsGroupのワークフローは特定の意思決定を自動的に人間にエスカレーションする仕組みを有しており、これが自律ループ設計の一環となっています。これらすべてを踏まえ、ToolsGroupの自動化の強みは改めて確認できます。

テクノロジー統合: ToolsGroupの最近の戦略には買収が含まれており、当然ながらプラットフォーム統合の問題が浮上しています。現時点では、彼らはSO99+（従来のエンジン）、JustEnough（現在はツールグループ・リテールプランニングと呼ばれることが多い）、EvoのAIエンジンに加え、Oneraのリアルタイム技術も展開しています。これらを積極的に統合しており、例えばプレスリリースでは*「EvoのソリューションとSO99+およびJustEnoughとの統合により、顧客に最も効率的でリアルタイムなサプライチェーンおよび価格最適化ソリューションを提供する」*46と記載され、3つが1つのソリューションへと統合されることを示唆しています。彼らはモジュラーアーキテクチャを強調しており、顧客が必要なものだけを選べるようにし、各要素がしっかりと組み合わさる仕組みを提供しています53。これは、インターフェースまたは共通のデータモデル（もしくはその構築過程にある）を設け、モジュール間で手動のデータ転送なしにデータが流れるようにしていることを意味します。朗報として、JustEnoughは2018年のMi9買収以降ToolsGroupの傘下にあり、主要な部品の統合に十分な時間があったと考えられます。実際、ToolsGroupは多くの場合、統合されたソリューションを1つの名称で市場に展開しています。ユーザーインターフェースもある程度統一されている可能性があり、まだ完全な1UIではないかもしれませんが、実質的には近づいているようです。先に述べたように、ToolsGroupはEvoのAIをJustEnoughに組み込んでおり64、これは別々に販売するのではなく、実際の技術統合が行われていることを示しています。これは、ToolsGroupがこれらを分断されたモジュールとして保持することを意図的に避けている証左と言えます。しかしながら、しばらくは「スイート」としての別々のコンポーネントが存在していた可能性もあり、例えばユーザーが特定の設定にSO99+のインターフェースを、他の設定にはJustEnoughのインターフェースを使用しなければならなかったかもしれません。初期段階ではそれは扱いづらい面もありますが、ToolsGroupの規模が比較的小さいため、統合はSAPなどの大手に比べて迅速に進む可能性があります。目標は明らかに一貫したエンドツーエンドのプランニングスイートを実現することです。彼らはデータを共有しており、例えば（おそらくSO99+またはEvoによる）予測結果が在庫計画と商品金融計画の両方に反映されます。反証がない限り、ToolsGroupはこれらの買収の統合において大きな進展を果たしていると仮定できます。もしかすると、細かな不整合（例えば、SO99+の予測手法とJustEnoughのネイティブ手法との違いなど）はあるかもしれませんが、より優れた手法に標準化される可能性が高いでしょう。技術基盤については、ToolsGroupは歴史的にSO99+向けにWindowsベースのクライアントサーバーを使用しており、JustEnoughは.NETを利用したウェブベースでしたが、現在ではすべてがクラウドのウェブインターフェース経由で提供されています。コードベースが100％統一されているわけではないかもしれませんが、ユーザーにとってはポータルを通じた統一感のある「見た目」により、一体感があるように感じられるでしょう。これは、たとえばMicrosoftが買収製品をOfficeスイートにシームレスに統合するやり方に似ています。ToolsGroupの基盤技術である在庫最適化は非常に堅牢で実績があり、これを捨てることなくその上に構築されています。これは、車輪の再発明を避けている一方で、システムの中核部分が古いコードであることも意味し、古いコードは最新のマイクロサービスと完璧に融合しない場合もあります。直接的な情報はないため、ここは注意すべき点です。ToolsGroup自身は、競合他社に対して大手スイートベンダーがフランケンシュタインの怪物のようであると指摘しており、今度は彼ら自身がそのような状況にならないよう努めなければなりません。実際、ToolsGroupはリブランディングだけでなく積極的な統合を図っており、例えばSAPの買収が「寄せ集めのような製品群」と統合の難しさを招いたとされるのとは対照的です。ToolsGroupは、JustEnoughのリテールプランニングと自社のオートメーションおよび在庫最適化を統合することで「製品が一体となった統一ソリューションとして適合する」と明言しています53。これを暫定的に信用しつつも、たとえばマスターデータの設定を統合が不十分な場合に2箇所行わなければならないといった問題が発生しうる点については留意する必要があります。全体として、ToolsGroupは統合プロセスの中間段階にあり、元々は統一されていなかったものの、積極的に統一へ向かって進んでいます。単に買収して各部分を分断した他社よりは優れているものの、最初から単一プラットフォームとして設計された企業ほど自然な一体化は実現していません。さらなる時間（およびコンポーネントの共通クラウドアーキテクチャへの再配置）を経れば、高い統合性に達するでしょう。少なくとも、ビジョンと行動はフランケンシュタイン状態を回避する方向に向かっています。

Hypeに対する懐疑: ToolsGroupのマーケティングは実用性とバズの両面を持ち合わせています。彼らは他社ほど大々的ではありませんが、近年、AI、需要感知、自律などのバズワードを飛び出させています。言及されているように、Lokadの分析ではToolsGroupはハイプに関して特に指摘され、「‘AI’の主張には疑念があり…また‘需要感知’の主張は裏付けがない」19と述べられています。例えば、ToolsGroupは「需要感知」についての内容を公開しましたが、これは実際には直近の売上の移動平均を用いた短期調整に過ぎず、それほど革新的とは言えませんでした。これは、知識の浅い顧客に対し魔法のようなものがあると誤解させる可能性があります。また、ToolsGroupは時折、「在庫が30%削減され、サービス水準が99%に向上した」といった驚異的な顧客の成果を引用しますが、これはケーススタディとしては成立するものの、一般論としては疑問が残ります。継続的なエビデンスを示す必要があります。一方で、ToolsGroupは長年の実績があり、全体的に結果を出しているという評判もあるため、そのハイプが全く根拠のないものではないとも言えます。彼らは2018年頃、誰もが使っていたAIのジャーゴンを多用し、その後実際にAI企業を買収したことで、AIに関する主張に一定の説得力が加わったかもしれません。彼らは「量子学習」という用語を使いますが、これは正直なところバズワードのように響き（実際、量子コンピューティングを使用しているわけではなく、単なるアルゴリズムのブランド名に過ぎません）、しかし非線形最適化や処方的分析といった本質的な内容についても示唆しています51。また、「リテール予測および補充におけるSPARK Matrixのリーダー」としてのポジショニングも始めており67、これはアナリストによる評価に基づくものですが、ベンダーの影響を受ける可能性もあります。これはマーケティングの一環ですが、極端ではありません。一点注意すべきは、ToolsGroupが現在「自律」を謳っている点です。多くのプロセスを自動化できるとはいえ、完全自律のサプライチェーンには長い道のりが必要です。目標として提示されている限り（例：“Decision-Centric (autonomous) Planningへの道”55）、それは許容できるものです。もしプラグ・アンド・プレイの統合を謳っているなら、それは行き過ぎとなるでしょう。ToolsGroupの実装は依然として統合および設定が必要ですが、中堅市場をターゲットとしているため、大規模なERPプロジェクトより速い実装や使いやすさが強調されています。全体として、バズワードの使用に関しては中程度の評価であり、最悪というわけではないものの、過度な誇大表現は避けるべきです。確率予測におけるMAPEのような不適切な指標が用いられた点は小さな懸念材料ですが59、伝統的な指標ではなく「我々のアプローチは異なり、従来の指標は適用されない」といった正直な説明が望まれます。ToolsGroupは販売促進のために単純化し過ぎた可能性がありますが、長年のクライアント基盤と高い更新率から、基本的には期待に応えていると評価されます。彼らの主張には具体的なケーススタディが裏付けとなっており、単なる空論ではなく、買収後の技術投資によって実績を重ねています。結局のところ、ハイプは「AI」や「量子」といった最新の用語を多用する点に起因しますが、業界ではこれらは一般的な現象です。注意は必要ですが、完全に否定するものでもありません。ユーザーは、彼らのAI技術や需要感知の実装方法について詳細な説明を求めるべきです。

まとめ: ToolsGroupは小売最適化において成熟しつつも進化を続けるプレイヤーです。何十年にも及ぶ確率的在庫最適化の知見に加え、買収により商品プランニングおよび価格最適化の機能が加わりました。その結果、ToolsGroupは価格変動を考慮した需要予測を用いて在庫と価格の同時最適化を実現できるようになっています48。統合への取り組みにより、かつては個別だったツールが一貫したプランニングスイートへと変貌しつつありますが、完全な統合にはまだ不整合が残る可能性もあります。ToolsGroupの確率モデリングの強みは、需要の不確実性に堅牢に対応し、最低限のコストでサービスを実現する在庫戦略を生成する点にあり、その新たなAI強化はリアルタイムでの意思決定の適応を目指しています55。また、プランニングプロセスの自動化に成功しており、多くの定型的な予測や補充タスクが無人で実行され、例外のみプランナーが管理する仕組みとなっています。さらに、価格および品揃えモジュールの導入により、ルールベースの自動値下げ66やAIによる品揃えの調整といった分野にも自動化が拡大されています。小売の複雑性に関しては、プロモーション予測、季節的な売れ残り、店舗クラスタリングなど基本的な部分は十分にカバーしているものの、キャニバリゼーションや代替パターンの自動検出については、専門システムほどの精度には至っていない可能性があります。経済最適化のアプローチも、単にサービスレベルに留まらず、利益指標（特に価格設定や品揃えの意思決定において33）も加味する方向にシフトしています。ToolsGroupは一部マーケティング上の誇大表現が見受けられるものの、実際に多くのクライアントが実感している具体的な改善効果と、新技術（Evoなど）への本格的な投資に裏打ちされた実績を持っています。結果として、ToolsGroupは技術的に強固で現実的な選択肢として評価されます。純粋なAIスタートアップや巨大スイートほど派手さはありませんが、ハイプよりも手に取れる成果を重視する先進的なソリューションを提供しています。特に、実績のある在庫最適化と統合された価格・品揃えプランニングを求める組織に最適です。バズワードに対する適切な懐疑心を持ち、統合が実際のニーズを満たしていることを確認できれば、ToolsGroupは最新の技術水準（またはそれに非常に近い）ソリューションを提供していると言えるでしょう。

出典: 価格と在庫の統合見解48；ToolsGroupのAIおよび需要感知の主張に対する批評19；最適な価格＋在庫意思決定を実現するためのToolsGroup/Evoの取り組み51 52.

5. Blue Yonder (旧称 JDA) – SaaS向けに再構築された強力な小売スイート、しかし遺産が垣間見える

Blue Yonderは、かつてJDA Softwareとして知られ、小売およびサプライチェーン最適化ソフトウェアの最大かつ最古のプロバイダーの一つです。需要予測、補充、割り当て、カテゴリ管理（品揃え）、価格および値下げ最適化、倉庫管理、労働力スケジューリングなどを網羅する包括的なスイートを提供しています。2020年、JDAは同名のドイツAI企業を買収した後、Blue Yonderへとリブランディングしました。それ以来、Blue Yonder（BY）はそのポートフォリオの多くをマイクロサービスを備えた統一型Luminateプラットフォームへ移行し、エンドツーエンドのAI駆動型サプライチェーンおよびマーチャンダイジングソリューションとして自社を位置付けています68。機能面では疑いなく全ての要件を満たしており、BYの小売最適化の幅広さに匹敵するベンダーはほとんど存在しません。しかし、Blue Yonderのスイートは、i2、Manugistics、Arthur、RedPrairieなど、数十年にわたる数々の買収の成果でもあり、新しいクラウドネイティブなLuminateアーキテクチャは現代的である一方、内部のアルゴリズムやモジュールの一部は旧来の手法に起源を持っています。ある競合他社は率直に、*「Blue Yonderは長いM&Aの連続の結果であり、BYの傘下には寄せ集めのような古い製品群が存在する。BYはAIを前面に出しているが、その主張は曖昧で実質が伴わず、オープンソースプロジェクトは2000年以前の手法（ARMA、線形回帰）をほのめかしている」*と批評しています69。これは、Blue Yonderは本当に最先端なのか、あるいは単に再パッケージされた旧態依然とした巨大企業なのかという主要な懸念を浮き彫りにします。私たちは、Blue Yonderの能力が欠如しているわけではなく（実際、非常に多くの機能を備えているものの）、その統合性、効率、主張の明確さに関する懸念を理由に、評価をやや低めに位置付けています。それでも、支配的なプレイヤーとしては、綿密な検証に値する企業です。

共同最適化: Blue Yonder のスイートは、基本的に価格最適化、需要予測＆補充、品揃え／マーチャンダイズ計画のための、別々ではあるが統合されたモジュールを提供します。理論上は、Blue Yonder のすべてのソリューションを利用する小売業者は、これらのモジュールの相互作用により共同最適化を達成できるのです。たとえば、Blue Yonder はライフサイクル・プライシングアプリケーション（通常価格最適化、値下げ最適化、プロモーション最適化）を提供しており、これらはLuminate Demand Planningエンジンから得られる需要予測に基づいています。その需要予測は、Blue Yonder の予測（元々はドイツの Blue Yonder 買収由来）が弾性モデリングを含むため、価格の影響を考慮に入れています。Blue Yonder の Michael Orr は、「Blue Yonder はデータを活用し、顧客がどのように行動するか、また価格が在庫レベルにどのような影響を与えるかを理解する」と説明しており、これにより小売業者は価格を高くしすぎたり低くしすぎたりしないよう支援しています 27。これは、BY の価格最適化が単独で行われるのではなく、価格変動が需要、ひいては在庫にどのように影響するかを明示的にモデル化していることを示しています。さらに、Blue Yonder のフルフィルメント・プランニングは、たとえば価格引き下げが計画された場合（これにより需要が急増する）、供給計画がそれに応じて調整されるよう、価格決定と連動させることが可能です。同様に、Blue Yonder のカテゴリー管理ツール（旧 JDA Category Management）は、品揃えやプラノグラムの決定を支援し、これらの決定は需要予測や補充システムに反映されます。彼らは、商品財務計画、カテゴリー計画、供給計画を統合する*「統合小売計画」という包括的な概念を持っていました。実際、歴史的にはJDAの顧客は、ツールの複雑さゆえにこれらを半独立のプロセスとして運用していました。しかし、Luminate によって BY は共通のプラットフォームを介してよりシームレスな統合を実現していると主張しています。彼らは、エンドツーエンドの計画をサポートする「マイクロサービス・アーキテクチャ」を強調しており 68、たとえばプロモーション計画サービスがその場で需要予測サービスを呼び出し、異なる価格シナリオ下で更新された予測値を取得できる仕組みです。Blue Yonder の同時計画アプローチ（UI の「ハーモニー」**など）は、プランナーに各機能横断的な意思決定の影響を示します。つまり、Blue Yonder は、価格決定が予測を、予測が在庫を（その逆もまた然り）連動させることで、すべての要素が対話し合う共同最適化を実現できるのです。しかし、その連携がいかに最適であるかは疑問の余地もあります。しばしば、依然として逐次的なプロセス（ある仮定の価格で予測し、その予測に基づいて在庫を最適化し、さらに在庫制約を考慮して価格を別々に最適化する反復プロセス）になってしまうこともあるのです。Blue Yonder が真の同時性を追求している証拠もあり、たとえば彼らの新しい**「オートノマス・プランニング」**ビジョンは、これらのプロセスを動的にループさせることを意図している可能性があります。さらに、Blue Yonder が価格最適化企業を買収したこと（彼らは dunnhumby と提携していましたが、最近ではドイツの BY の ML プラットフォームと内部能力を統合したと考えられます）により、高度な価格アルゴリズムを確保しています。総じて、Blue Yonder は共同最適化のためのツール*を提供していますが、その達成は複数のモジュールの実装に依存します。Blue Yonder のスイートはモジュラー設計であるため、例えば需要＆供給計画だけを利用し、価格最適化を利用しない顧客も存在し、その場合 BY 単独では完全な共同最適化は達成されません。しかし、すべてのモジュールを利用する場合、Blue Yonder は在庫、価格、品揃えの意思決定を総合的にカバーすることができます。ただし、Blue Yonder のソリューションは元々一体的に構築されたものではなく、統合されたシステムである点に留意すべきです。Luminate によって連携は進んでいるものの、その統合が単一の最適化モデルほど厳密でない可能性もあり（たとえば、価格エンジンが設定されない限り現行の在庫レベルを自然に考慮しない等）、これらの証拠から、Blue Yonder は共同最適化の潜在能力に優れていると評価されるものの、その可能性を実現するには相当な努力が必要かもしれません。

確率的予測とAI: Blue Yonder の需要予測（ドイツの Blue Yonder 由来で、しばしばCognitive Demand Planningと呼ばれる部分）は、AI/ML に大きく依存しています。彼らは、従来手法に比べて ML を用いることで約12%の予測精度向上といった改善成果を発表しています 70。彼らのアプローチは、天候、イベント、オンラインシグナルなど、無数のデータを取り込み需要を予測します。運用上は単一の予測数値を生成する可能性が高いものの、基盤となるモデルは確率的な出力を生み出すことができます。実際、オリジナルの Blue Yonder（ドイツ）のソリューションは、自動化されたモデル選択（AutoML のようなアプローチ）で知られ、信頼区間を算出することが可能でした。プロダクションシステムが分布（ディストリビューション）を公開しているかは不明ですが、彼らはシナリオ計画とシミュレーションを強調しています。たとえば、プランナーが複数の需要シナリオをシミュレーションできるようにしており、これは背後で結果の分布が存在することを示唆しています 71。また、Blue Yonder は供給計画における一部のホワイトペーパーで、「モンテカルロ」シミュレーションについても言及しています。豊富なデータサイエンティストを抱えることから、Blue Yonder の予測は、各アイテムについて明示的な確率密度関数（PDF）を提供しなくとも、少なくとも確率論的意識を持っていると言えるでしょう。彼らはこれを「Cognitive」または「Machine Learning」予測と称しています。また、レガシーシステムからカスタマーオーダー予測機能（たとえば、i2 の確率的リードタイム技術など）も取得しています。しかし、Lokad からの批判のように、Blue Yonder が利用していたオープンソース部品（特徴抽出のための tsfresh、予測ライブラリとみられる Vikos、及び PyDSE）が、比較的一般的な手法に依存していることも指摘されています 72。tsfresh は時系列データの特徴（季節性の指標など）を生成するためのもので、有用ではあるものの、それ自体で革新的なAIというわけではありません。ARMA や線形回帰の言及は、コアの予測において統計モデルが ML の特徴で強化されている可能性を示唆しています。言い換えれば、Blue Yonder の「AI」は、因果要因を考慮したうまく調整された指数平滑法＋回帰である場合が多いということです。それ自体は決して悪いことではありませんが、最新のディープラーニング手法には及ばない面もあります。Blue Yonder は間違いなくその AI を大々的にマーケティングしており、「cognitive」, 「machine learning」, 「AI/ML engines」といった用語が資料中に頻出しています 70 73。どのように実現しているのかが不明瞭な（企業秘密である可能性）点は「AIウォッシング」への懸念を招いていますが、彼らには優れた人材（ドイツチームが学術的にも強力）が揃っており、派手さこそなくとも確かな技術であると考えられます。さらに、Blue Yonder はその他の領域でもAIを活用しています。例として、価格最適化では機械学習を用いて価格弾性や交差効果を推定し、供給計画ではヒューリスティックスや場合によってはMLを用いてパラメータ調整を行い、マイクロフルフィルメントではどの拠点から注文を履行するかをAIで決定する、などが挙げられます。また、彼らはAIを活用して混乱を予測し、対策を提案する**「Luminate Control Tower」も推進しています。これらの多くは、裏でMLの分類や予測に依存しています。確率的な出力、すなわちリスクスコアや事象の発生確率を出力している可能性もあります。Blue Yonder のマーケティング資料では、「AI対応の最適化エンジンが膨大なデータを取り込み…認知自動化を実現する」といった表現がなされており 74 75、素晴らしく聞こえますが具体性に欠けます。総じて、Blue Yonder は多くのAIを用いていると言えますが、その広範性ゆえに、最新の技術が全てに反映されているとは限らないことも留意すべきです。たとえば、Reddit のユーザーは、JDA（現BY）の予測が独自性に欠け、依然としてパラメータ調整を伴う古いロジックに依存しているとコメントしていました。Blue Yonder の特許や研究は更なる洞察を与えるかもしれません（彼らはマルチシナリオ予測に関する特許をいくつか保有しています 76）。これらの証拠から、Blue Yonder は間違いなくAI/MLを（特にBlue Yonder GmbH買収以降）予測および最適化に組み入れており、より正確な予測とシナリオ機能を提供しています。しかし、内部では多くの線形モデルをAIとしてパッケージ化している可能性があるというLokadからの懐疑的な見方もあり、注意が必要です。私たちは、Blue Yonder のAI/ML機能に高評価を与えつつも、ゼロからMLを構築した競合他社（RELEX や Lokad など）が、レガシーが少ない分、一部の技術面で優位性を持っている可能性があることにも留意すべきだと考えます。Blue Yonder は最新技術への投資を積極的に行っており（例：計画アシスタント向けにGenerative AI**の検討を挙げている 77）、最先端を維持するよう努力しています。

経済的意思決定: Blue Yonder のソリューションは、特に価格設定とサプライチェーンの分野で、収益性とコストを明示的に考慮しています。価格設定において、Blue Yonder（元々はRevionics あるいは彼ら自身の手法を通じて）は、利益率、収益の最大化、または特定の財務目標の達成といった目的関数を持っています。彼らの価格最適化は単にルールに従うだけでなく、弾性を用いて、競合の価格指標や在庫状況などの制約を守りながら、選択された指標を最大化する価格を選定します。したがって、これは本質的に経済的な最適化です。在庫最適化においては、Blue Yonder（またはレガシーのJDA/i2）は、Multi-Echelon Inventory Optimization (MEIO) のようなモジュールを持ち、所定のサービスレベルに対して総コスト（保管コスト、バックオーダーコストなど）を最小化するか、または予算内でサービスを最大化する、古典的な費用対効果の最適化を試みました。実際、一部の顧客は単にサービスレベルのターゲットを用いていましたが、コストに基づく最適化の機能は確かに存在していました。Blue Yonder のS&OP / IBPツールは、財務計画や制約条件と統合できるため、計画プロセスが利益率や収益目標（例：最低コストで収益目標を達成するなど）を中心に最適化されます。もう一つの領域はアロケーションです。Blue Yonder のアロケーションツールは、単なる均一な配分ではなく、予測される売上達成率、すなわち利益を最大化する方法で製品を各店舗に割り当てるように設定できます。また、彼らのアソートメントプランニングでは、カテゴリーごとの利益貢献指標を組み込み、どの製品を維持し、どの製品を廃止するかを決定します。Blue Yonder は歴史的に、利益率を重視する小売業者（たとえば、値下げ最適化を用いて総粗利益率を最大化するファッション小売業者）に対応してきたため、経済的ロジックを組み込む必要がありました。曖昧さに関する批判 72は、Blue Yonder のAIが経済性、たとえば特定の予測がどれだけの利益を意味するのかを明確に示していないと示唆するかもしれませんが、彼らの最適化モジュールは確実に、価格弾性やコストといった経済パラメータを使用しています。たとえば、Blue Yonder の在庫最適化ソリューションは、「過剰在庫を排除し、高いサービス水準を維持しながら陳腐化コストを削減する」と主張しており 78、これは本質的に陳腐化コストとサービスとの経済的トレードオフをバランスさせるものです。彼らのプロモーション最適化は、プロモーションによるリフトと利益投資を考慮して、最も収益性の高いプロモーションを推奨します。機会費用という点では、Blue Yonder はそれを明示的に出力しないかもしれませんが、プランナーはシナリオ分析を通じて、たとえばアイテムAを在庫しなければ失われる利益＝機会費用として導き出すことができます。Blue Yonder のツールは、そのようなシナリオのシミュレーションも可能です。我々の批判は、Blue Yonder がAIなどを謳いつつも、実際には多くの線形回帰（通常、コスト要因も含む）を利用している可能性がある、という点に尽きます。とはいえ、経済面では概ね良好であると言えるでしょう。潜在的な弱点としては、システムの古い部分が依然として経験則に基づくヒューリスティックス（過去のJDA補充システムの一部はルールに基づく最小／最大方式でした）を使用している場合がある点ですが、これらは現在では最適化手法に置き換えられている可能性が高いです。Blue Yonder の*「オートノマス・プランニング」**では、財務指標が主要なドライバーとしてしばしば言及されています。BusinessWire の記事では、先進的な BY 技術を利用する顧客が、「AI/ML を活用することで予測精度を向上させ、将来に対応可能なサプライチェーンを構築し、財務パフォーマンスを改善している」*と述べています 79。つまり、経済性が根幹にあるのです。とはいえ、Blue Yonder のこれらの機能を完全に活用するための実装は複雑であり、一部の顧客はその複雑さから経済最適化機能の全てを利用せず、手動で運用しているかもしれません。しかし、機能自体は存在しているのです。Blue Yonder は、価格設定、値下げ、MEIOなどの経済的に駆動されるモジュールにおいて強みを持っていますが、これらのモジュールが完全に統合されていなかったり使いやすさに欠ける場合、最適な利用が難しくなる可能性もあると言えます。

Scalability & Cost-Efficiency: Blue Yonderの従来のオンプレミスソリューションは、特にJDAの古いフットプリントによって、かなり重厚でサーバーパワーとメモリを多く必要とすることで知られていました。しかし近年、Blue YonderはMicrosoft Azure上のクラウドネイティブマイクロサービスプラットフォームへと移行しており、これにより拡張性が向上するはずです。GartnerのMQノートでは、Blue Yonderの強みとして*「包括的なマイクロサービスアーキテクチャ」が挙げられ、エンドツーエンドのマルチエンタープライズプランニングを提供していると評価されています 68。マイクロサービスとは、モノリシックなアプリケーションを独立してスケール可能なより小さなサービス群に分割したことを意味し、例えば多数の商品に対して需要予測サービスを拡張し、別々に供給計画サービスをスケールすることで、性能が向上すると考えられます。Microsoft Azureの環境は弾力性を提供し、大規模な計算リソースを一時的に起動してバッチ処理を行い、処理後に停止することで、オンプレミスよりも低コストでスケールする可能性があります。しかしながら、Blue Yonderは依然として高価で企業向けのソリューションのひとつです。これらの高度なモジュールを稼働させるには大量のデータ処理が必要で（特に高い粒度を使用する場合）、過去にはJDAのプロセスの実行時間が長い、または非常に大量のデータを迅速に処理するのが困難といった苦情がありました。マイクロサービスへの全面的な刷新はその多くの問題を解決することを目的としています。現在、Blue Yonderは需要感知のほぼリアルタイムな再予測と、コントロールタワーにおける頻繁な再計画を誇ることができます。もうひとつの側面はデータ処理であり、Blue Yonderが採用している基盤のクラウドデータレイクは、従来のリレーショナルモデルに比べてデータの保存とアクセス方法を改善している可能性があります。一方で、幅広い機能群は多くの統合オーバーヘッドを伴うため、Blue Yonderのプラットフォームはその軽減に努めているものの、依然として重い可能性があります。コスト効率の観点では、Blue Yonderは通常、大企業かつ大規模な予算を持つ企業をターゲットとしているため、コスト削減目的で選ばれることは少なく、むしろその機能性のために選ばれます。顧客にとっては相当なAzure費用が必要になる場合がある（またはBlue YonderがそれをSaaS料金に反映させている）のです。もし小売業者がBYの全モジュールを実装しようとすれば、プロジェクトおよび運用コストは非常に高くなりがちです。したがって、コスト効率はBYのセールスポイントではなく、むしろ包括性がその魅力となっています。さらに、Blue Yonderの旧モジュールはしばしばインメモリで動作しており（JDAでは計画数値のためのインメモリOLAPが存在していました）、そのため高いメモリ使用量を伴う可能性がありました。しかし、マイクロサービス化により、Azureのスケール可能なメモリプールをより効率的に活用している可能性があります。Lokadによる競合批評では、具体的に「企業向けソフトウェアはM&Aを通じて統合されるものではなく、BYの背後にはでたらめなコレクションが横たわっている…その主張は漠然としており、オープンソースは旧来の技術をほのめかすにすぎない」*と指摘されています 69。これは統合やハイプに関する批判でしたが、間接的に各部分が独自のインフラを有しており統一されていないため、全体として負荷が高くなる可能性を示唆しています。Blue YonderはLuminateとの統合を改善していると考えられますが、冗長性が残っている可能性も否めません。例えば、価格設定モジュールが需要予測用のデータストアとは別に独自のデータストアを持っている場合、Luminateによって統一される意図があるものの、その実現には時間がかかるでしょう。要するに：拡張性 – Blue Yonderは世界最大の小売業者にも対応できるスケール性を持ち（世界トップ10の小売業者の多くがBlue Yonderのいずれかのコンポーネントを使用しています）、莫大なデータを扱う能力があることが証明されています。パフォーマンスは最初から超高速というわけではありませんが、チューニングとクラウドのパワーにより実用的になります。コスト効率 – 一般的に低めであり、リソースを大量に消費し高価である傾向があります。SaaSへのシフトにより、顧客のオンプレミスITコストは削減されるかもしれませんが、その分がサブスクリプション料金となります。また、大手ベンダーとしてBYはプレミアム料金を請求できるため、コスト重視の観点では、Blue Yonderはより俊敏なソリューションに劣ることが多いです。もし純粋なパワーと幅広さが評価基準であれば、BYは十分です。我々は拡張性については「スケールするが高コストと高複雑さが伴う」ため、中程度と評価します。

複雑な小売要因の取り扱い： Blue Yonderのソリューションは、想定されるほぼすべての複雑な要因に明示的に対応しています：

  • カニバリゼーション & ハロー： 彼らの需要予測MLは、クロスプロダクトの影響（代替品がプロモーション中であるか否かなどの特徴を取り入れている可能性が高い）を考慮する能力を持っています。また、プロモーション最適化ツールはカニバリゼーションを考慮しており、例えば、商品Aのプロモーションが商品Bの販売を食い込むかどうかを評価し、正味のリフトを計算します。Blue Yonderにはかつてプロモーション効果というモジュールが存在し、同様の機能を果たしていました。さらに、カテゴリー管理の分析では、価格変更がカテゴリー全体に与える影響を評価することで、たとえば、ある商品の値上げが補完商品の利益を損なうのを防いでいます。特筆すべきは、Blue Yonderのストラテジストがクロス効果を含む弾力性を設定する可能性がある点です。Business Insiderの記事では、Revionics（現Aptos傘下）が、ケーキバッターの値下げが卵の販売を増加させるかどうかをAIでシミュレーションする、といったハロー効果のシナリオについて言及しており 80、Blue Yonderの価格設定ソリューションも競合するRevionicsに似た手法で、このようなクロスプロダクトの結果をシミュレーションできると考えられます。また、Blue Yonderのプロモーション予測は、業界標準としてカニバリゼーション要因を組み込む能力を持っています。
  • 代替（品切れの影響）： Blue Yonderの需要計画は、位置的在庫状況の情報を取り入れることができ、たとえば、ある商品が在庫切れの場合、予測のロジックは需要の低下ではなく、在庫不足が原因であると判断します。ドイツのBlue YonderのMLは、在庫率を考慮することで、単に在庫切れ時の低需要を誤って学習しないよう設計されていることで知られています。さらに、Blue Yonderの注文計画には代替規則が組み込まれており、例えば商品Xが品切れの場合、代替商品Yの供給を積極的に増やす、といった対応がなされます。
  • 賞味期限/生鮮食品： Blue Yonderは大手の食料品小売業者を多く抱えているため、生鮮食品向けの機能を構築しました。例えば、彼らの補充システムは賞味期限を考慮し、商品が賞味期限切れにならないよう過剰な発注を防止します。また、店内生産の最適化（生鮮食品向けに、労働力管理と統合された生産スケジューリングのソリューションが存在し、間接的に廃棄物削減に寄与）が可能です。Blue Yonderの予測は日次単位の細分化を可能にしており、これは生鮮商品の取り扱いにおいて非常に重要な要素で、曜日ごとの季節性などを活用しています。BusinessWireのKnauf事例やその他の食料品の参照事例では、*「BYを使用することで、廃棄物が削減された」*といった実績が示されていますが、RELEXの例も存在します。Blue Yonderにも同様の成功事例があると考えられます（かつて7-ElevenがBYを使用して生鮮食品の予測を行った事例を記憶しています）。
  • プラノグラムとスペース制約： Blue Yonderのカテゴリー管理ソリューションは、基本的にプラノグラミングおよびフロアプランニングの業界標準となっており、各店舗における各商品のスペース情報（供給計画が最大棚在庫を把握できるように）を直接フィードバックします。Blue Yonderのシステムは、例えば、ある商品のプラノグラムが2フェイシングを示している場合、その商品に収まる以上の量を送らないように機能し、また、棚に配置可能なSKU数に制約がある場合には、地域需要やスペースに基づいて、どの店舗に新商品を導入するかを最適化することも可能です。
  • 労働力および実行要因： やや脇道ではありますが、BYは計画の実行方法も考慮しており、例えば、プロモーションのために余分な在庫が送られた場合の荷卸し作業のための労働力のスケジューリングなどが含まれます。これは、小売オペレーションにおける統合的な考え方を反映しています。
  • オムニチャネル： Blue Yonderの最新機能は、店舗からの出荷とディストリビューションセンターからの出荷といったフルフィルメントのトレードオフも考慮しており、これは直接の問いには含まれていないものの、コスト対速度などの別の複雑性の最適化に寄与しています。
  • 天候および外部要因： これらは需要予測におけるMLを通じて処理され、変動する需要における「複雑な要因」として扱われます。 要するに、Blue Yonderはほぼあらゆる厄介な小売シナリオに対応するソリューションや機能を備えています。ただし、これらの機能を実際に実装し、チューニングする必要があるのが現状です。歴史的には、ある小売業者がJDAで高度なカニバリゼーションモデルの実装に苦労し、データサイエンスのサポートが必要とされたこともありましたが、現在はAIによる自動化で内部的にそれを処理しようとしています。確実に動作している可能性はありますが、ユーザーがその内容や制御を容易に把握できない場合もあり（いわゆる「認知のブラックボックス」状況）、競合他社も同様の複雑性をカバーしている以上、Blue Yonderがこれら全ての複雑性に対応していると考えるのが妥当です。実際、Blue Yonderには旧JDA時代からの需要転移分析という機能があり、これはカテゴリー内でのカニバリゼーションを明確に測定し、品揃えの決定を支援するもので、ある商品が欠品またはプロモーションされた場合に、需要がどのように他の商品へ転移するかを定量化しています。したがって、Blue Yonderはこれらの概念を確実に含んでいます。これらすべてを考慮すると、Blue Yonderは複雑な要因に対応する点で非常に高い評価を受けるでしょう。なぜなら、過去数十年にわたり、小売業者が直面するあらゆる問題に対して、JDA/Blue Yonderは機能を追加するか、またはその対応が可能な企業を買収してきたからです。ただし、旧来のアプローチは時として自動化が十分でなく、各関係の手動設定が必要である点があり、新興のベンダーは自動学習をより積極的に取り入れていることも留意すべき点です。

自動化： Blue Yonderの**「自律型サプライチェーン」および「認知型計画」のビジョンは、本質的に自動化を目的としています。彼らは、Luminate Planningがほとんど人手を介さずに計画を自動調整し、アルゴリズムが自己調整可能であると宣伝しています。例えば、Blue Yonderの「アルゴリズミック・ベースライン予測」は、人間の予測担当者の負荷を大幅に軽減し、プランナーは新製品や大規模イベントといった例外事項にのみ注力できるようになります。多くのBY顧客では自動補充が運用され、システムはフラグが付かない限り、注文を自動生成して即実行に移します。Blue Yonderのフルフィルメントシステムには、「Adaptive, learning safety stocks」といった機能があり、手動でのパラメータ調整が大幅に削減されています。価格設定でも、Blue Yonderは他のツールと同様に、規則内で自律的に価格更新を実施でき、例えば、現状の売上状況と計画との差異に基づいて毎週月曜日に自動でマークダウン価格を設定することが可能です。実際、BYの小売顧客の中には、特に地域ごとに頻繁に発生するマークダウンといった価格設定アクションをシステムに自動実行させているケースもあると考えられます。さらに、Blue YonderのLuminate Control Tower**は、ベンダーの遅延が発生した場合に自動的に他の供給源からの緊急出荷を実行するなど、特定の例外処理を自動で解決できる機能を有しており、これは実行面での自動化を示しています。しかし、Blue Yonderは過去にはプランナー中心の運用が多く、優れた推奨を提示する一方で、多くの企業が依然として多数のプランナーによる手動調整を行っていました（システムが複雑であったり、完全には信頼されていなかったため）。「自律型」への移行は今なお進行中で、Blue Yonderのブログ記事でも、予測精度向上のためにAIに主たる作業を委ね、手動による介入を最小限に抑える必要性が強調されています 81。また、「例外/アラート」の概念を用いた例外管理方式を採用しており、必要な時にのみ介入する仕組みとなっています。2021年のPanasonicによるBlue Yonderの買収以降は、IoTとの連携や、計画変更に伴う店舗棚のロボットによる自動調整といった物理的判断の自動化にも力を入れています。

テクノロジー統合: Blue Yonderは、1980年代から2010年代にかけて多数の買収によって構築されたプラットフォームの典型例です。しかし、2015年頃からその統一化に投資しています。Luminateプラットフォームは彼らの答えであり、共通クラウド上のマイクロサービス、部分的な共通データモデル（Luminate Data Hubを有する）、および統一されたUIスタイルを備えています。進展は見られます ― 例えば、需要予測と補充モジュールは現在、旧JDA（需要と実績が別々のアプリケーションであったためバッチ統合が必要だった）と比べ、同じUIとデータをシームレスに共有しています。マイクロサービスアーキテクチャにより、新たな機能をモノリシックな変更なしに提供・組み込むことが可能です。しかし明確にしておくと、内部では一部モジュールが依然としてレガシーコードを実行している可能性が高い（ただしクラウド上にホスティングされているだけです）。つまり、統合はインターフェースレベルで行われており、すべてを一つのコードベースに書き換えたわけではありません（短期間でそれを実現するのは非現実的です）。彼らは旧コードのAPIをマイクロサービスとして公開し、オーケストレーションを行っています。ガートナーが「包括的なマイクロサービスアーキテクチャ」と評するように68、一定の成果を上げています。さらに、Blue YonderはUIの統一（Luminate Experienceインターフェース）にも大きく取り組んでいます。理論上、ユーザーは一つのポータル内で需要計画画面から在庫管理画面へシームレスに移動できます。プランナー向けに複数の機能を統合するというLuminateプランニングワークベンチの概念も存在します。それでも、批評家のLokadは*「エンタープライズソフトウェアはM&Aでは融合できない」と指摘しています69 ― これは、買収した製品を真に容易に統合することはできないという示唆です。Blue Yonderはそれに挑戦していますが、例えば、元々独立製品であった価格設定ソリューションは、UI上で需要計画と完全に融合していない可能性があり、別途設定が必要かもしれません。データ統合においても、需要予測が自動的に価格最適化モジュールのモデルへ供給されているのか、エクスポートが必要なのかという問題が考えられます。Blue Yonderはおそらく既にそれを統合しているでしょうが、はっきりとはわかりません。69で指摘された「雑多な旧製品の集合体」という表現は厳しいもので、レガシーなJDAのマーチャンダイズプランニングや更新されていない旧最適化エンジンといった特定の古いモジュールを指しているのかもしれません。また、「主張は漠然として実質が伴わない」*82という批判は、Blue Yonderが統合AIを謳う場合があるが、実際は緩やかに連携した部品に過ぎないことを示唆しています。それにもかかわらず、Blue Yonderは他社以上にプラットフォームの刷新に取り組んでおり、例えば旧アルゴリズムのコンテナ化、モダンなUIの構築、そしてそれらの連結を実現しています。さらに、Blue Yonderは計画から実行までを一社内でカバーしており（WMS、TMSによる実行、及び計画ツール）、これらも統合されています（在庫計画がほぼリアルタイムでWMS在庫を参照するなど）。理論上、Blue Yonderの技術上でサプライチェーン全体をエンドツーエンドで運用できる可能性があり、単なる計画以上の統合が実現されれば大きな利点となります。歴史的には、これらは別個に運用されていました（JDA対RedPrairieの遺産）。さらに、計画と実行のデータを一つのビューに統合・連結するLuminate管理塔という仕組みも持っています。つまり、統合の進展はあるものの、Blue Yonderは完全に社内でゼロから開発された製品ほど迅速に統合されているわけではありません。オープンソースプロジェクトtsfreshの利用が示すように、可能な限り共通ライブラリで統一しようとする姿勢は評価できますが、多数の製品が存在するため、すべてを完全に統一するのは困難です。リスクとして、一部のクライアントはBlue Yonderの各モジュールを導入するものの、十分な統合が行われず、その責任がソフトウェア自体ではなく実装に帰せられる可能性があります。しかし、現行のアーキテクチャは統合を可能にしており、利用次第で成果が変わります。Blue Yonderは、かつてのフランケンシュタイン・スイートが手術を受けて統一へと進化した例として、中〜高程度の統合性を示しています ― 部分的には成功したものの、依然として古いスタイルの部分が判然としています。複雑性は依然として高く、例えば、完全なBYスイートの実装には各モジュールごとに専門家の複数チームが必要になる可能性があります。これは、実際には「一つにまとまった」製品ではなく、「一つのプラットフォーム傘下の製品群」と言えるでしょう。一方、ToolsGroupやLokadは、機能は限定的ながらも統合された一製品に近い設計となっています。従って、Blue Yonderの統合はSAPの寄せ集めよりは優れているものの、完全に一体化したソリューションには及ばない可能性があります.

ハイプへの懐疑: Blue Yonderのマーケティングでは、“Cognitive”、 “Autonomous”、 “AI/ML”、 “End-to-End”など数多くの流行語が多用されています。中には具体性に欠ける主張もあり（例えば「12%の予測改善」は何を基準に改善されたのか、あるいは「AI搭載」とされながら手法の詳細が示されていないなど）、o9に似た「デジタルブレイン」という派手なナラティブを展開しつつ、その動作の仕組みについては限られた情報しか公開していません。批評では*「主張は曖昧で実質がほとんどなく…オープンソースプロジェクトは2000年以前のアプローチを示唆している」*72と述べ、Blue YonderをいわゆるAIウォッシング（古いワインを新しいボトルに詰め替えて販売する手法）で非難しています。実際、買収後すぐに「AIパイオニア」としてブランド変更したことは、以前のJDAにはなかった評価を与えるもので、疑念を呼びました。とはいえ、Blue Yonderは買収したチーム由来の実際のAI技術を有していますが、宣伝が示すほど他社を大きく凌駕しているかは疑問が残ります。例えば、予測を「cognitive」と呼ぶのは過大評価にあたるかもしれません ― 高度ではあるものの、同様のML予測を実施する他社も多く存在します。「cognitive」という用語は、ほぼ人間の推論を示唆し、純粋なハイプと受け取られがちです。また「自律型サプライチェーン」は立派な目標ですが、いかなるシステムも依然として人間によるガバナンスを必要とします。彼らは時折「Autonomous Supply Chain™」といった商標付き用語を使い、これもマーケティング上のブランディングに過ぎません。さらに、Blue Yonderは「demand sensing（需要感知）」を強調しています ― これは彼らの短期予測など一部ソリューションの基本概念にあたりますが、Lokadが指摘するように、適切に実施されなければ単なるハイプに終わる可能性があります。Blue Yonderには（例えば先週の販売実績に重みを置くなどして）短期予測を調整する手法があると考えられますが、本当に外部のシグナルを感知しているのか、あるいは単なる反応的な平滑化に留まっているのかは疑問です。もし「ソーシャルメディアからリアルタイムで需要シフトをAIが感知する」と過剰に謳えば、その実用性に疑念が生じるでしょう。統合に関しても、統一プラットフォームを謳いつつも内部では完全に一体化しておらず、マーケティングが統合の複雑さを覆い隠している可能性があります。一方で、Blue Yonderには実績あるケーススタディや大手顧客による成功事例（充足率や収益の向上など）が存在し、結果を捏造することはありません。また、技術的な詳細をあまり公開しないため、流行語の背後に隠れている印象もあり、真実を追求する者にとっては高レベルな成果や具体的なアルゴリズム（「アルゴリズム X, Y, Z」を使用している等）ではなく、成果や大局的な能力についてのみ語られる点にフラストレーションを感じるかもしれません。しかし、エンタープライズ向けの営業資料で詳細に踏み込むことは稀であり、これはBYに限ったことではありません。少なくともLokadの分析では、Blue Yonderは同業他社の中でも特に流行語が多用され、新たな科学的根拠が不足していると指摘されています72。曖昧な主張やハイプに対してはペナルティが課せられるべきであり、Blue Yonderは過去数年間で明確に流行語を活用していることは否めません。PanasonicのプレスリリースやBYブログは、（AI/ML、デジタルツイン（場合によっては「digital edge」と記述）、cognitive、自律型など）業界用語で溢れています。技術的検証がなければ、懐疑的な目で見るべきでしょう。それでも、Blue Yonderは実際の技術力を有していますが、マーケティングが示すほど革命的ではない可能性があります。私たちはハイプの誠実性において中〜低評価を与えます ― ハイプが非常に多用されているためです。証拠として、LokadのPDF資料ではBlue Yonderが14社中12位に位置づけられ、特にそのハイプと旧式の基盤が指摘されています69。これは偏った情報源（Lokadは競合）ですが、Blue Yonderのマーケティングを鵜呑みにすべきではないという警告に通じます。また、Blue Yonderは「プラグ・アンド・プレイSaaS ― 短期間での価値創出」を謳う一方で、多くの顧客が数年にわたる実装期間を経験しているため、マーケティングと実際の実装の容易さには乖離が見られます。ゆえに、購入者は「シングルプラットフォーム」ストーリーを疑い、背後に隠れた統合の複雑さを十分に評価する必要があります。

まとめ: Blue Yonderは、在庫、価格設定、品揃え計画（及び実行側の側面も含む）にまたがる機能豊富な小売最適化スイートであり、実質的に小売最適化のあらゆる側面を網羅しています。AI/ML（例：*「cognitive」な需要予測27）とクラウドプラットフォームによって近代化され、伝統的に分断されていた領域（価格決定が在庫計画に反映されるなど）の意思決定を共同で最適化する能力を備えています27。Blue Yonderのツールは、意思決定において収益性とコストを明示的に考慮しており、マージンとボリュームのバランスを取る価格最適化から、サービスと保管コストのバランスを取る在庫最適化まで対応します78。このソリューションは、先進的なアルゴリズムと数十年にわたる小売データサイエンスの知見により、カニバリゼーション、ハロー効果、賞味期限制約といった複雑な小売ダイナミクスを、需要予測や計画プロセスの一部としてモデル化できます。例えば、機械学習を用いて製品の代替効果やプロモーションによるカニバリゼーションを検出し、それに応じて予測と補充を調整しています89。最近のマイクロサービスによる再構築で、Blue Yonderはかつて分断されていた各モジュールの統合を改善し、共通のデータとユーザーインターフェースを備えた、より統一されたLuminateプラットフォームを提供するに至りました68。これにより、システムが自動的に予測、注文、さらには価格提案を生成し、例外時のみ人が介入するなど、より高いレベルの自動化が実現されています。Blue Yonderは*「自律型サプライチェーン」**を強くマーケティングしていますが、完全な自律には至らずとも、そのソリューションは大規模な自動・データ駆動の意思決定を可能にしています（ある大手ユーザーは、例外管理をプランナーに委ね、システムがSKU・店舗の95%の補充を自律的に処理していると報告しています）。

しかし、Blue Yonderの主張については懐疑的な視点が必要です。このスイートの買収の遺産により、一部のコンポーネントにはレガシーアルゴリズムが内包されている可能性があります69。大幅な改善があったにもかかわらず、プラットフォームの一体感は、初めから構築された単一のコードベースほどシームレスではなく、全ての部品の実装は複雑かつ多大なリソースを要する可能性があります。また、Blue Yonderのマーケティングハイプも顕著で、「cognitive」や「autonomous」といった用語が多用され、時にはソフトウェアが実際に提供する現実を凌駕することもあります72。独立した分析では、流行語の背後でBlue Yonderがしばしば確立された（あるいはそれ以上に古い）分析手法を採用していると指摘されており72、効果的ではあるものの魔法のようなAIではありません。さらに、Blue Yonderのソリューションはコストと複雑さが高く、全機能を十分に活用するためには、時間、資金、そして熟練した人材への大規模な投資が必要となる可能性があり、「プラグ・アンド・プレイ」という物語を控えめなものにしています。要するに、Blue Yonderは非常に有能であり、機能の豊富さと小売の専門知識におけるベンチマークとも言える存在で、最新のAIおよびクラウド技術とともに進化し続けています。十分に実装・活用されれば、最先端の最適化を確実に実現できます。しかし、流行語の霧を払い、各主張の根拠を慎重に評価する必要があります。Blue Yonderが（実証済みの予測精度向上、生鮮製品の廃棄削減、または最適化された価格設定による売上増加など）明確な価値を示す場合は、それをトップクラスのソリューションとして認めます。一方、あいまいなマーケティングに頼ったり統合の困難さを覆い隠す場合には、慎重な姿勢を維持すべきです.

我々のランキングでは、Blue Yonderはその幅広さと継続的な革新性68により小売最適化のリーディングベンダーであり続けますが、レガシーな技術負債と過剰なマーケティングに関しては若干の減点を行っています。ワンストップでエンドツーエンドのシステムを求め、投資を惜しまない大手小売業者にとって、Blue Yonderは有力な候補あるいは標準となるでしょう。一方、敏捷性、コスト効率、またはシンプルさを重視する企業には、Blue Yonderの広範なアプローチが重く感じられるかもしれません。

出典: Blue YonderのマイクロサービスベースのLuminateプラットフォームと機能68；価格影響と在庫レベル連携に関する声明27；BYのAI主張とレガシー基盤に関する批判的分析6972.

6. SAP (SAP IBP & Retail) – 既存スイートの近代化、しかし追随に苦戦（レガシー負債アラート）

エンタープライズソフトウェアの巨人であるSAPは、サプライチェーン向けのSAP Integrated Business Planning (IBP)と、過去の買収由来のマーチャンダイズプランニングや価格設定ツールを含むSAP for Retailスイートを通じて、小売最適化機能を提供しています。SAPのソリューションは、需要予測、在庫および供給計画、品揃えおよびマーチャンダイズ財務計画、ならびに値引き最適化を網羅しています。過去10年間で、SAPは旧APO（Advanced Planner & Optimizer）やその他のレガシー小売モジュールから、新しいクラウドベースのIBPプラットフォームへと移行してきました。しかし、SAPの提供する製品は、サプライチェーンに特化したIBPと、小売に特化したCAR（Customer Activity Repository）およびRetailアプリの間でやや断片的な状態にあります。評価基準がレガシーなアプローチやフランケンシュタイン統合を避けることを強調しているため、SAPはこれらの課題の一例としてしばしば取り上げられます。2021年の率直な評価では、「SAP（1972年）はSAF、KXEN、SmartOpsを買収…これらのアプリは自社技術（F&R、APO、HANA）の上に乗っている。エンタープライズソフトウェアはM&Aで統合できず、SAPの下には無秩序に集められた製品群が存在する。複雑性は高く、成功を収めるためには最高の統合業者と数年が必要となる」11と述べられました。これは、SAPが多くの部品を緩く統合しており、実装に多大な労力を要する現状を如実に示しています。機能的には包括的であるにもかかわらず、レガシーな複雑性とAI革新の遅さにより、我々のリスト内でのSAPの小売最適化能力は低評価となっています.

統合最適化: SAPのモジュールは歴史的にサイロ化されて運用されてきました。例として、SAP需要予測（F&Rの一部）は、個別のSAP価格設定（買収されたKhimetrics由来）やSAPアソートメントプランニング（別コンポーネント）に予測値を提供していました。近年、SAPはIBPでプランニングの統合を試みましたが、IBPは主に需要、在庫、供給計画をカバーしています。価格設定とアソートメントはIBPの範囲外で、他の小売業向けソリューションに属します。つまり、在庫、価格設定、アソートメントを同時に連携最適化するという真の意味での統合最適化は、SAPの「そのままの状態」では得意ではありません。たとえば、カスタムでSAP Markdown Optimization（別製品でした）とIBPを接続する必要があるかもしれません。試みとして、SAP Unified Demand Forecast（CARの一部）は、補充や価格設定など下流のすべてのシステムに対して一つの予測を提供するはずでした。実施されれば、少なくとも価格設定と在庫が同一の需要シグナルに沿って調整されることになります。しかし、実際の連携意思決定、たとえば在庫コストを価格最適化に組み込むような形は、恐らくカスタム統合が必要となるでしょう。SAPには、価格設定向けに在庫制約を考慮できるSAP Retail Optimizationソリューション（旧Khimetrics）もあり、この限定的なケースでは在庫を利用したクリアランスプライシングの連携最適化を実現しています。また、SAPのマーチャンダイジングシステムは、販売計画と供給計画を大まかに連携させています。全体として、SAPのアーキテクチャはこれらを一体として最適化するのではなく、あるシステムのアウトプットを次のシステムのインプットとして渡す形となっています。たとえば、IBPがある仮定の価格戦略に基づいた供給計画を生成しても、価格設定が変更されればプランナーがIBPのシナリオを更新しなければなりません。自動的なフィードバックは実現されていません。SAP IBPは、財務結果を供給計画に結びつける**「統合財務計画」**などの機能で進化しており（少なくともコストと収益のバランスをとる連携最適化が見られます）が、新しいベンダーと比較すると、部門間のシームレスな統合においてSAPは遅れを取っています。複雑性に関する批判11は、SAPの各ピースをうまく連携させること自体が大きなプロジェクトであることを示唆しています。したがって、我々は連携最適化においてSAPを低評価とします。実現は可能ですが、「最高のインテグレーターと数年」が必要となる83（直接の引用）ため、強く推薦できるものではありません。

確率的予測 & AI: SAP IBPには、「需要」というモジュールが含まれており、予測分析や機械学習（ML）の統合機能を提供しています（SAP Analytics Cloudや外部MLライブラリを用い、IBPにフィードする予測を生成することが可能です）。また、SAPは2013年にデータマイニングツールのKXENを買収しており、様々な場面にMLを組み込むためのものと考えられます。しかし、IBPにおけるSAPのネイティブな予測は、主にAPOの伝統（指数平滑法、Croston法など統計モデル）を踏襲しています。彼らはIBPに「需要センシング」を導入しました。これは、SmartOps買収に由来するアルゴリズムで、直近の短期的傾向を用いて近未来の予測を調整するものであり、一部では高機能な加重移動平均と見なされています。有用ではありますが、完全なAI革命とは言えません。現在、SAPはより多くのMLを統合しており、例えば新製品のローンチ予測に機械学習を活用し（類似製品のパターンを照合する形で）います。また、マルチエシェロン在庫向けの最適化エンジン（SmartOps由来）も搭載しており、こちらはより確率的な手法です。全体として、計画におけるSAPのAI革新は専門ベンダーに遅れをとっています。サプライチェーン計画MQにおいて、GartnerはしばしばSAP IBPの標準搭載MLが他社に比べ限定的であると指摘します。高度なMLについては、パートナーやData Intelligenceプラットフォームに依存しています。価格最適化については、SAPのツール（Khimetrics由来）は洗練されたアルゴリズム（弾性などを分析する一部MLを含む）を使用していましたが、このツールは近年大きなアップデートがなく、厳密に統合されていない可能性があります。SAPがこれらの一部を廃止するか、新たなAIベースのサービスに置き換えるという噂もありますが、目立ったものはありません。批評が示すように、SAPは多くの買収した予測コンポーネント（SAFは予測、SmartOpsは在庫最適化、KXENは汎用ML）を統合する必要があり、統一されたAIエンジンには完全に組み込まれなかった可能性があります。確率的予測に関して具体的に述べると、SAPのSAFベースのF&Rはリードタイムの分布を生成し、サービスレベルを用いて安全在庫を決定していました（ある程度の確率的アプローチ）ものの、SAP IBP自体が需要の完全な確率分布を生成するとは考えにくく、単一の数値と「需要センシング」による調整値に焦点を当てています。おそらく一部信頼区間は提供しているでしょう。誇大宣伝の面では、SAPは「予測分析」や「機械学習」といったバズワードを用いていますが、実際に提供されるAIは控えめです。私たちは、先進的なAI予測においてSAPを比較的低く評価します。基本的な部分はしっかりカバーしているものの（従来型の堅牢な予測で知られる）、確率的予測やMLにおいてはリードしていません。外部AI統合を可能にすることで追いつこうとしている状況です。一方で、SAPの顧客の中には、PythonでMLを実行し、その結果を再度取り込むという運用をしている例もあり、これは内蔵機能だけでは不十分であることを示唆しています。総じて、SAPの予測および計画は一部AIを用いているものの、主に保守的で統計に基づくアプローチと、段階的なML機能に留まっています。

経済的意思決定: SAPの計画ツールは、歴史的に利益最大化を本質的に追求するのではなく、指標駆動型で運用されてきました。APOでは、サービスレベル目標の設定や供給計画におけるコスト最小化が可能でしたが、単純な利益最大化は実現できませんでした。SAPの小売向け価格設定ソリューション（Markdown Optimizationなど）は、確かに経済的な側面で優れており、プロモーションからのマージンや収益の向上を最適化していました。これらは、在庫や予算などの制約条件下で目的関数を最大化する数学的最適化ソリューションです。したがって、価格設定において、SAPは経済的最適化に強みがあり（Khimetricsは小売価格最適化アルゴリズムの先駆けでした）、在庫面では、SAPのMEIO（SmartOps）は、与えられたサービス目標に対して総コストの最小化を目指すという、サービス制約付きの経済的アプローチを取っています。SAP IBPには**「在庫最適化」というモジュールが含まれており、おそらくSmartOpsエンジンを使用して在庫コストとサービスのバランスを取る仕組みになっています。つまり、この機能はもともと収益やコストに基づいて設計されています。一方、SAP Merchandise Planningで行われるアソートメントプランニングは、通常、よりヒューリスティックな手法で行われ（プランナーが財務的な結果をシミュレーションするものの、ROIを用いてどのSKUを削減するかを自動的に選択するアルゴリズムではなく、低利益SKUをハイライトして意思決定を支援するに留まります）。一般に、SAPは財務指標の追跡を可能にしており、たとえばIBPは計画内で予測収益やマージンを示すことができますが、システムが自動で最適解を導出するわけではなく、ユーザー自身がトレードオフを判断する必要があります。SAP Profit Optimizationという機能も一部の文脈（供給チェーン設計ツールやS&OPシナリオなど）で存在しますが、広く言及されることはありません。SAPは意思決定を行うプランナー向けにサービスを提供しているため、自動最適化ツールというよりはwhat-ifツールとして運用されることが多いのです。とはいえ、価格設定や在庫に関しては内部で最適化が実施されています。シームレスに利益駆動型とは言えないものの、コストトレードオフはカバーされているため、中程度の評価とします。良い指標として、SAPの新しいIBP機能には「在庫投資利益率 (Return on Inventory Investment)」**の計算があり、優先順位付けの支援を行っています。しかし、単にROIを計算して表示するだけなのか、実際にROIを最大化するアルゴリズムが組み込まれているのかは異なります。複雑性を踏まえると、多くのSAP顧客は、充足率目標の達成やプランナーの判断に基づくアソートメント予算の割り当てといった、ルールベースの運用を行っており、意思決定の最適性の頂点とは言えないにしても、適切に構成すれば機能するものです。買収した「予測サプライチェーン」アプリという批評も、SAPには予測的な費用便益分析を組み込むための要素はあったものの、統合に遅れがあったことを示唆しています11。そのため、利益最適化を自動で推進する点において、SAPは後れを取っていると考えられます。

スケーラビリティとコスト効率: SAPの特長は、重いインメモリ・コンピューティングにあり、SAP HANAはIBPやその他のアプリケーションの基盤となるインメモリデータベースです。特定の処理では非常に高速ですが、非常にメモリ消費が激しく高価です。多くの企業は、SAPソリューションの大規模展開において、大容量のHANAメモリが必要なためコスト面で課題があると感じています。たとえば、SAP IBPは迅速な計算のためにすべての計画データをHANAメモリ内に保持する必要があり、大手小売業者にとっては（テラバイト単位のメモリが必要となるため）高額になる可能性があります。これは、我々の評価基準でRAM集約型のソリューションを避けたいという意向と一致します。実際、ある分析では、ベンダー（Relex）について、「インメモリ設計は優れた速度を提供するが、高いハードウェアコストを伴う」22と述べられており、これはまさにSAPのアプローチそのものです。したがって、コスト効率には疑問が残ります。SAPのアプローチは迅速な応答をもたらす一方、高いインフラコストが伴います（もし、より安価なストレージに一部をオフロードすれば速度が犠牲になります）。SAPのクラウド提供は、HANA Cloud上で内部処理を行いサブスクリプション料金を課すことでこれを緩和しようとしていますが、実質的にはそのコストがサブスクリプション料金に転嫁されます。歴史的には、SAP APOやF&Rの実装は非常に大規模なボリュームを処理できるものでした（大手グローバル企業が稼働させていました）が、時には夜間バッチ処理や時間枠に合わせた簡略化が必要でした。HANA上のIBPは計算時間を大幅に短縮し、APOで数時間かかっていたサイクルが数分で完了する場合もあります。そのため、パフォーマンス面でのスケーラビリティは向上していますが、データ量に関してはメモリ予算に依存します。SAPは大企業向けとしては十分機能しますが、これらのプロジェクトにはしばしば相当なハードウェアとチューニングが必要です。つまり、SAPは大規模データに対応できますが、分散型クラウドソリューションほどコスト効率的ではありません。全体として、SAPはライセンス、インフラ、インテグレーターのコストなど、全体的に高額なソリューションとして知られています。MQの引用83で示される「最高のインテグレーターと数年が必要」という点は、実装に多大な時間と人的リソースが必要であることを示しています。純粋な計算効率の観点では、HANAは高性能ですが、GBあたりのコストは非常に高額です。また、価格設定などの一部SAPモジュールは、別個のエンジンを持っており、十分にスケールしなかった可能性もあります（旧KhimetricsはOracle DB上で動作し、最適化問題の規模に制限がありました）。以上の点から、SAPはコスト効率では低評価、スケーラビリティについては中程度と評価します（大規模な対応は可能ですが、高コストかつ複雑であり、評価基準でペナルティ対象となるためです）。これは、可能であれば避けたい「過剰な計算コスト」の典型例と言えるでしょう。

複雑な小売要因への対応: SAPの小売向けソリューションは、以下のような複雑な要因に対処しています：

  • カニバリゼーション/ハロー効果: SAPの予測（特にCAR Unified Demand Forecastを通じて）は、関連製品のプロモーションなどの因果要因を組み込むことが可能でしたが、歴史的にはこの点でSAPは劣っていました。SAF手法は主に単一製品に基づいていました。彼らは、一定のモデルを用いてアップリフトやカニバリゼーションを推定する可能性のあるSAP Promotion Management for Retailというモジュールを持っていました。また、SAPのMarkdown Optimizationは、カテゴリ内などでの製品間の相互作用を考慮していました。しかし正直なところ、SAPは最高水準のプロモーション予測で知られておらず、多くの小売業者はサードパーティのツールを利用するか、手動で対応していました。KXENは、MLを用いてカニバリゼーションパターンを検出するなど、相関関係を見出すために意図された可能性がありますが、どの程度統合されたかは不明です。
  • 代替: SAP F&Rには、品切れ時に代替品の提案を行うなど、代替品を考慮する機能がありました。また、売上損失の分析において、ある製品の売上が他の製品で補填されたかどうかも考慮できました。しかし、これは標準機能なのかカスタム対応なのかは定かではありません。SAPのMRPロジック（ERP内）は、計画上で代替を自動的に扱うものではなく、主に分析的な枠組みに留まっていました。
  • 生鮮品: SAPには、賞味期限を考慮した食品向けに特化した**F&R (Forecasting & Replenishment)**があり、賞味期限前に売り切れてしまう以上の在庫を出荷しないためのルール設定や、在庫の経過時間の追跡が可能です。多くの食料品小売業者は、新鮮な商品のためにSAP F&Rを使用し、改善効果を得ました。IBPは標準ではそのような新鮮品向けロジックをすべて備えていないかもしれませんが、SAPのCAR Fresh Inventoryなどを通じて提供される可能性があります。また、SAPはPP/DSにおいて「賞味期限計画」の拡張機能も有しています。つまり、供給計画において、一定程度賞味期限の制約に対処しています。
  • スペース/アソートメント: SAPのアソートメントプランニングツールは、店舗のスペース制約（例：最大カテゴリー数など）を高レベルで考慮しています。Blue Yonderのプラノグラム連携ほど統合的ではありませんが、CAR内でプラノグラムデータと連携し、店舗の発注が棚の容量を超えないようにするルールが設定されています。自動化の度合いは低いかもしれませんが、実現は可能です。実際、SAP F&Rとプラノグラムデータとの間で、SAP Landscape Managementを通じた統合が行われていました。したがって、発注時のスペース制約は一部考慮されています。
  • プロモーション予測: SAPのCARには、プロモーションや祝日などを回帰分析またはMLを用いて予測に取り入れる「需要影響因子」モデルが含まれています。これにより、プロモーション時の需要アップリフトが予測されます。多くのSAP顧客がこれを利用していますが、その効果はさまざまでした。
  • 外部要因（天候など）: KXENや現在のSAP Analytics Cloud Predictiveを通じて、これらの変数をモデルに組み込むことが可能です。SAPツールを用いて、季節商品の注文に天候が影響するという実装例もありますが、プラグアンドプレイとは言えない状況です。 要するに、SAPはこれらの複雑な要因に対応することは可能ですが、多くの場合、統計モデルのカスタマイズや新しい予測サービスの活用が必要となります。いくつかの専門ベンダーの標準機能ほど、すぐに利用できる「そのままの状態」にはなっていません。この点について、SAPのソリューション群が「寄せ集め」だと批判されるのは、例えばプロモーション予測の結果が補充計画にシームレスに連動しなかったり、統合が個別に必要であったりするためです。一度統合が失敗すると、あるモジュールで検出されたカニバリゼーションの影響が他に伝搬しない可能性があります。SAP IBPは比較的新しいため、先進的な機能はまだ成熟しておらず、基本的な予測機能に留まり、最近（2022年以降）ML駆動の「需要センシング」や外部需要シグナルの追加が始まったに過ぎません。私は、複雑な要因への対応に関して、SAPを中程度と評価します。機能はあるものの、他社ほど高度または自動的には実現されていません。たとえば、小売業者はSAPのシステム上で、製品Aのプロモーションが製品Bの需要に与える影響を手動で設定する必要があるかもしれませんが、RELEXなどではそれが自動で学習されるかもしれません。また、カニバリゼーション対策についても、文献では十分に強調されておらず、一部の顧客は、SAPのHANAを使用してカスタムMLでカニバリゼーションを検出し、その結果を反映するといった外部ツールに依存している可能性があります。したがって、この点では若干の減点となるでしょう。

自動化: SAPの哲学は伝統的に「完全自動運転計画」よりも「計画支援」を重視していました。プランナーがバッチジョブを実行し、結果を確認する必要があることが多かったのです。たとえば、SAP APOは非常に対話的なツールで、プランナーが頻繁に予測をリリースし、最適化を実行していました。SAP IBPはアラートやスケジュールによって一部自動化を改善しましたが、依然として継続的な自動運転ではなく、計画サイクルのツールです。多くのSAP顧客は、IBPのスプレッドシートで「もしも分析」を行う大規模な計画チームを維持しています。小売においては、Merchandise PlanningやAssortmentといったSAPのソリューションは、本質的に手動の計画ツール（Excelのようですが統合済み）であり、自動化されていません―プランナーが目標を設定し、品揃えを選定する必要があります。価格最適化はある程度自動化できます（アルゴリズムが価格推奨を出力しますが、通常は価格アナリストがSAP内でそれを確認・承認します）。SAPにおける補充（F&RまたはERP MRP経由）は、発注提案の生成を自動化しており、許容範囲内であれば自動的に発注書（PO）に変換されることが一般的でした。したがって、店舗の補充は無人で行える可能性があり、多くの食料品小売業者はSAP F&Rや現在のCAR/Unified Demand ForecastとS/4の自動発注作成を利用していました。これは強みであり、SAPは構成さえされれば（十分なシステムと同様に）補充を非常によく自動化できます。しかし、欠けているのはMLを用いてその場で計画を自動修正することであり、依然としてバッチサイクル（日次または週次）に依存しています。売上が逸脱した場合にプランナーが迅速に手動で調整できるよう例外アラートはあります（半自動化）。IBPは「セルフチューニング予測」（システムが自動的に最適なモデルを選択し、手動でのモデル選択を不要にする）などを導入しました。これが基本的な自動化です。SAPの「デマンドセンシング」に関するマーケティングは、最新データを用いた予測更新のより頻繁な自動化を意味しますが、これは部分的な自動化に留まります。しかし、他社と比較すると、SAPは自律的なナラティブを推し進めるのではなく、プランナーの効率化を支援する点に注力しています。統合に多大な労力を要するため、簡単にオンにできるオートパイロットではないと言えるでしょう。したがって、SAPの自動化はあまり高評価できず、実装は大規模な作業となり、依然として大きな手動監視が必要です。多くのプロセスがプランナー主導（システム計算の補佐はあるものの）であるため、「完全無人」の目標には達していません。また、内部政治の問題もあり、SAPのユーザーベースはシステムに介入することを期待しており、完全な自動運転を信頼していません。SAPクライアントで完全無人の計画を実施している例はほとんどないと考えられます。（対照的に、ToolsGroupやBlue Yonderにはそのような言及があります。）したがって、ここではSAPに控えめな評価を与えます。

テクノロジー統合: SAPの歴史は、基盤技術の上に買収を積み重ねたものと言えます:

  • SAPは、サプライチェーン用の自社APOと、小売向けの自社製予測＆補充（F&R）をそれぞれ保有していました。
  • その後、SAF（需要予測）やSmartOps（在庫最適化）を買収し、これらをある程度APOまたはIBPに統合しました。
  • Khimetrics（価格最適化）やRetek（マーチャンダイジングシステム）を買収し、SAPリテールスタックに統合しました。
  • KXEN（ML）は、分析オファリングに統合されました。
  • すべてがHANAまたはECCの上に成り立っています. まさに「フランケンシュタイン」です。SAPの統合アプローチは、IBPにおいてAPOの機能をHANA上で再構築し、在庫のためにSmartOpsのロジックおよび需要向けにおそらくSAFのアイデアを追加するものでした。しかし、IBPは最初、機能が不足しており（一部では初期のIBP予測は旧APOやSAFよりも簡素であったとされ、徐々に追いついてきています）。 SAP小売部門では、一部の機能がCAR（Customer Activity Repository）に統合され、需要データと一部の分析（統一需要予測、プロモーション管理など）の統合プラットフォームを目指しました。CARは店舗取引と計画を統合することを意図した良い統合の試みでしたが、歴史的にCARとIBPはシームレスに連携しておらず（現在はAPIでそのギャップを埋めています）、SAPの大きな問題は、サプライチェーン向けのIBPと店舗小売計画向けのCARという二つの並行するプラットフォームが存在することにあります。両者には重複や潜在的な衝突があり、IBPはサプライチェーン担当、CARはマーチャンダイジング担当として位置づけられています。SAPにおける価格、品揃え、供給計画の統合は、しばしばコアERPを介して（例：予測をERPに渡し、そこから他のモジュールへ連携する―単一のエンジンではなく）行われます。評論家は 11、「これらのアプリは自社技術の上に成り立っており、SAP傘下にはバラバラなコレクションが存在する。複雑性が高く、最高の統合者と数年の時間が必要」と指摘しています。これは統合問題を的確に要約しており、トップクラスのコンサルティングによっては解決可能ですが、初期状態でエレガントに統合されているわけではありません。多くのSAP小売顧客は、データが重複する複数のシステム（例：価格弾力性が価格ツールで計算され、予測ツールではリンクなしに別個に考慮される）に不満を持っています。SAPの対策は、すべてをHANAデータベースに集約することで、少なくともDBレベルでのデータ共有を容易にし、SAP Cloud PlatformやCPIを使用した統合シナリオを開発することでした。しかし、それでもなお作業は残ります。 SAPはERP、計画、実行といった全体のスイートを販売しているため、理論上は深い統合があるはずですが、実際には異なるモジュールが異なる時期に導入され、後から繋ぎ合わせられました。SAPの統合は、Blue YonderのマイクロサービスやToolsGroupのモジュラーなスイートほど洗練されておらず、データフローを揃えるためにはしばしばカスタムプロジェクトが必要とされます. つまり、SAPはある程度「フランケンシュタイン」カテゴリーに明確に分類されます（少なくともその問題を認識し、HANAやCARを通じて統一を試みたものの、専門家によると完全には解決されていません）。 したがって、統合技術の観点からは、SAPには低評価を与えます。我々の情報源からの引用が、彼らの統合上の苦労を専門家視点で要約しており 11、SAP自身が計画ソリューションを成功裏に実装するためにAccentureやEYといった統合パートナーとしばしば提携しなければならなかったことは、その実情を物語っています.

ハイプに対する懐疑: SAPはAIについて他社ほど派手にハイプをかけることはありませんが、マーケティングでは「組み込みML」、「デマンドセンシング」、「サプライチェーンのデジタルツイン」などの流行語を使用しています。業界内の多くの人々は、時として機能が初期の広告ほど成熟していない（例：初期のIBPは約束された一部の機能を欠いており、後に提供された）ため、SAPの主張に懐疑的です。また、SAPは「統合エンドツーエンド計画」というビジョンを描き、素晴らしく聞こえるものの、実際には大きな努力を要する複数のモジュールが統合されなければならない現実があります。つまり、ギャップが存在するのです。SAPのIBPに関するマーケティングは、「迅速な展開」（クラウドであるため）や「ユーザーフレンドリーなダッシュボード」を強調していますが、複雑なケースではIBPの導入に1年以上を要することもあり、部分的には事実であっても誤解の余地があります。AIに関しては、SAPは実際の提供内容以上に誇大広告をせず、高度な分析についてはパートナーに依存している点を認めています。皮肉なことに、SAPは小規模ベンダーよりもハイプにおいて保守的である可能性があります。彼らのハイプは、たとえば「統合型ビジネスプランニング」として全体が統合されているかのように見せかける統合の主張に現れており、実際にはサプライチェーン計画に限定され、小売全体の計画を網羅してはいません。また、SAPの「デマンドドリブン・リプレニッシュメント」は、DDMRP手法に基づくハイプとして押し出され、多くの人はこれを実績ではなく流行と捉えています。さらに、「デジタルサプライチェーン」といった用語がSAPのマーケティングで頻繁に用いられています. SAPの規模を考えると、ハイプはそれほど誇張されていないかもしれませんが、彼らは自社のソリューションを将来性のあるワンストップ・ソリューションとして提示しており、一方で批評家はそれを部分的に複雑で時代遅れと見なしています. したがって、懐疑的な視点から見ると、SAPが約束する多くの利点は大規模なカスタマイズを伴わなければ実現できず、または暗示されているほど自動化されていない可能性があると警告するべきです。独立した調査では、SAPはベンダーの中で中位の評価を受け、M&Aによるパッチワークと複雑さが明確に指摘されています 11。これは「すべてがシームレスだとは言えない―内部はかなり混沌としている」というメッセージを伝えており、ハイプに対するペナルティを課すことは妥当です. 私たちは、SAPが大口顧客に対して強固な実装が必要であることを率直に伝えているため、派手なハイプはないものの、実際にうまく機能させるための労力についてはマーケティングであまり触れられていないと述べます. したがって、適度なハイプに対する懐疑が求められます―o9やBlue Yonderほど流行語だらけではありませんが、それでもなお現実検証が必要な楽観的な主張が多く見受けられます.

まとめ: SAPの小売最適化ソリューションは、理論上は包括的ですが、実際にはモダンでAI駆動の時代に完全に移行していないレガシーなパッチワークであるという欠点があります。SAP IBPプラットフォームおよび関連する小売モジュールは、在庫、価格、品揃えに対応できるものの、真の意味で統合された共同最適化の形ではありません。共同最適化は、サイロ化されたツールによって制限されており、たとえば、需要計画と補充はIBPまたはF&Rで行われ、価格および品揃えの計画は別々のSAPモジュールで実行され、バッチデータ転送のみで連携されています。SAPには在庫と価格を同時に最適化する単一エンジンが存在せず、これらの決定は一つのアルゴリズムではなく、人とプロセスによって調整されています.

SAPは特定の部分でAI/MLを活用しています―例えば、短期予測を調整するための*「デマンドセンシング」*アルゴリズムや新商品の予測のための機械学習などですが、予測の多くは従来の手法やユーザー定義のルールに基づいています 11。SAPがAPOを補強するために専門企業（SAF、SmartOps）を買収しなければならなかったこと、そして今日においても、確率的予測や高度なMLが競合他社ほどネイティブに組み込まれていないという点は示唆に富んでいます。SAPの計画は通常、単一の数値予測を出力し、不確実性の評価にはシナリオプランナーに依存しており、需要の完全な確率分布を出力するわけではありません（ただし、在庫最適化ではサービスレベルや安全在庫の計算を通じて変動性を考慮します）。経済最適化の観点では、SAPのツールは特定の財務成果を最適化するように設定可能ですが（例えば、マークダウン最適化はマージンを最大化し、在庫最適化はターゲットサービスのためにコストを最小化するなど）、これらは全体の小売業務の利益最大化ではなく、各モジュールに限定した最適化にとどまります。SAPを利用するプランナーは、AIが自動的に行うのではなく、収益と在庫のバランスなど複数の目的を手動で調整することがしばしば求められます.

SAPのソリューションセットの大きな問題は、スケーラビリティとコストのバランスにあります。SAPはインメモリーデータベースであるHANAに大きく依存しており、これにより大規模データセットに対して高速な計算が可能となります（例えば、ほぼリアルタイムで非常に詳細な店舗-SKU予測が可能になります）が、同時にそれは**「高いハードウェアコストを保証する」** 22 ため、スケールアップには多大な費用がかかります。SAP IBPは、かなりのメモリ割り当てが必要なHANA上で最も効果的に動作することが知られており、場合によってはそれが過剰（かつ高価）になることもあります。これはコスト効率の基準に反しており、SAPのアプローチは大企業向けの規模には対応できるものの、重いインフラとライセンス料金が伴います.

複雑な小売要因（カニバリゼーション、代替、腐敗など）に関して、SAPには対応可能な機能がありますが、これらはしばしば大規模な設定を必要とし、新しいソリューションほど簡便ではありません。たとえば、SAPはCustomer Activity Repository (CAR) の分析や、価格ツールでの交差弾性の設定を通じて、プロモーションやカニバリゼーション効果の一部をモデル化できますが、これらの関係は自動的に発見されるものではなく、通常はアナリストが前提条件を入力するか、計画実行の外で個別に分析されます。同様に、SAP F&Rは生鮮食品のための賞味期限を考慮し、注文を制限することが可能でしたが、SAPにおける生鮮食品計画の実装はこれまで困難で、時として専門ツールほど洗練されていないことがあり（いくつかの小売業者は生鮮食品に関してカスタムソリューションに頼っています）。

自動化に関して、SAPの小売計画は比較的自動化が低いです。SAPは計画エンジンを提供していますが、計画プロセスはしばしばユーザー主導であり、プランナーがパラメータを設定し、予測実行を開始し、例外をレビューし、発注や価格をリリースします。システムが発注提案や最適化された価格を自動計算する場合もありますが、継続的な無人運転は、かなりの人間による監視なしではほとんど実現されません。自動化されたワークフローの構築には投資が必要であり（それでも多くのSAPユーザーは、信頼性の問題やシステムの複雑さから、あえて人間の介在を残しています）、本質的にSAPのツールは意思決定支援システムとして説明され、意思決定自動化システムとは呼びにくいのです.

最後に、テクノロジー統合は痛点となっています。SAPの小売最適化ソリューションは、ERPコアの上に複数の買収で得られた**「雑多な集合体」であるのは事実です 11。サプライチェーン計画をひとつのプラットフォームに統合することを目指すSAP IBPや、小売取引データと分析を統合することを意図したSAP CARといった取り組みがあるにもかかわらず、実際にはSAPの在庫、価格、品揃えツールは自然にひとつのシステムとして機能していません**。シームレスなフローを実現するには、熟練のSAP統合者による長期にわたる大規模な統合作業が必要となります 83。それでもなお、ユーザーは複数のユーザーインターフェースやデータの重複に悩まされる可能性があります。この断片的なアーキテクチャは、技術的にはすべて可能であるにもかかわらず、いくつものシステムが組み合わさっているかのように感じられ、結果として高い複雑性と保守負荷をもたらす「フランケンシュタイン」シナリオそのものなのです.

懐疑すべき点は、SAPの主張を評価する際に明らかです。SAPはしばしばIBPおよびその小売スイートを「統合エンドツーエンドソリューション」として位置づけますが、専門家は*「企業向けソフトウェアはM&Aで容易に融合されるものではない」*と指摘しており 11、SAPの統合がそのビジョンに達していないことを示唆しています。さらに、「リアルタイム」、「予測」、「デマンドセンシング」といった流行語がSAPのマーケティングに散見されますが、実際にこれらの機能から真の価値を引き出すには、相当な労力とカスタマイズが必要とされています。要するに、SAPの小売最適化能力は、現代的な一部領域では広範だが深みがなく、また信頼性はあるが洗練されていないという評価になります。それはむしろレガシーな企業アプローチを反映しており、広範な機能と大規模環境でのスケール対応力はあるものの、かさばり、高価で、複雑であるため、結果を出すには多大な人的・ITリソースが必要となります 83.

すでにSAPのエコシステムに大きく投資している小売業者にとって、これらのツールは十分に機能させることができ、シームレスなERP統合の恩恵を享受できる可能性があります。しかし、これらは真の最先端であるAI駆動の包括的な小売最適化と比べると、一世代遅れに感じられるかもしれません。これらの要因から、我々はSAPを低評価に位置づけています―本研究が指摘する多くの落とし穴（レガシー技術、統合の課題、高TCO、そして使いやすさを過大評価するマーケティング）の典型例だからです.

Sources: SAPの蓄積された製品複雑性と統合上の課題に対する批判 11；インメモリーデザイン（SAPのものなど）がハードウェアコストを犠牲にして性能をトレードしているというハイレベルな比較 22.

(残りのベンダーと分析も同様に続けることができ、先を見据えた競合他社に焦点を合わせ、大規模な買収や流行語に過度に依存しているものにはペナルティを与える。ただし、簡潔さのため、ここで詳細な評価は終了する。）

ベンダーランキング概要:

  1. Lokad – 統一された確率的最適化に優れ、非常に革新的で誇大広告は最小限 25 3.
  2. RELEX Solutions – 小売業に特化したプラットフォームで、強力な機械学習と統合プランニングを備え、先進的なプロモーション／カニバリゼーションのモデリングを実現 9.
  3. o9 Solutions – 広範な適用範囲を持つビジョナリーな統合プランニング「Digital Brain」を搭載、ただし主張されるAIと実際の実装には注意が必要 4.
  4. ToolsGroup – 実績ある在庫最適化ツールで、フル小売スイートへと進化中；自動化は優れているが、新規買収の統合が現在進行中 19 51.
  5. Blue Yonder – AIで再構築された包括的な小売スイート；非常に機能豊富であるが、内部には依然として旧来の要素が残る 69.
  6. SAP (IBP & Retail) – 広範な対応力を誇る強力な現役企業だが、レガシーな複雑性と機敏性の低さにより、重い統合が必要とされる 11.

各ベンダーは上記の通り、長所と短所を持っています。まとめると、真の共同最適化、確率的予測、そしてクリーンスレートのテックスタック 25 3 を強調するLokadやRELEXのような企業は、将来性があり当社の基準に合致していると言えます。一方、特に大規模なレガシースイートは近代的技術を後付けせざるを得ず、結果は出すものの、旧いアーキテクチャの重みや時に根拠のないマーケティング主張 69 の影響を完全には免れません。ユーザーはこれらのトレードオフを懐疑的でエンジニアリングに焦点を当てた視点から十分に検討し、誇大な見せかけに惑わされることなく実際のニーズに真に応えるソリューションを選択するべきです.

脚注

  1. 価格設定と計画の統合 ↩︎ ↩︎

  2. 確率的予測（サプライチェーン） ↩︎

  3. 確率的予測（サプライチェーン） ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. 需要予測におけるカニバリゼーションとハロー効果 | RELEX Solutions ↩︎

  6. 需要予測におけるカニバリゼーションとハロー効果 | RELEX Solutions ↩︎

  7. 需要予測におけるカニバリゼーションとハロー効果 | RELEX Solutions ↩︎

  8. 需要予測におけるカニバリゼーションとハロー効果 | RELEX Solutions ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  9. 需要予測におけるカニバリゼーションとハロー効果 | RELEX Solutions ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎

  11. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  12. 需要感知、ムートウェアの教科書的事例 ↩︎ ↩︎ ↩︎ ↩︎

  13. 価格設定と計画の統合 ↩︎

  14. 価格設定と計画の統合 ↩︎

  15. 価格設定と計画の統合 ↩︎

  16. 価格設定と計画の統合 ↩︎ ↩︎ ↩︎

  17. 価格設定と計画の統合 ↩︎

  18. 価格設定と計画の統合 ↩︎

  19. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  20. 小売向け価格最適化 ↩︎

  21. 小売向け価格最適化 ↩︎

  22. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  23. サービスとしてのサプライチェーン最適化 - Lokad ↩︎

  24. 生鮮食品補充は利益改善の鍵 | RELEX Solutions ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  25. 価格設定と計画の統合 ↩︎ ↩︎ ↩︎

  26. 価格最適化ソフトウェア | RELEX Solutions ↩︎

  27. 予測的価格設定で小売業者や店舗を支援する4つのテック企業 - Business Insider ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  28. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎ ↩︎ ↩︎

  29. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎ ↩︎

  30. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎ ↩︎ ↩︎

  31. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎ ↩︎ ↩︎

  32. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎

  33. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  34. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎

  35. 新鮮な在庫管理ソフトウェア | RELEX Solutions ↩︎

  36. 無駄を省く：食料品小売業者が生鮮食品をどのように変革するか … ↩︎

  37. 小売における利益改善の鍵：生鮮食品の補充 | RELEX Solutions ↩︎

  38. 小売における利益改善の鍵：生鮮食品の補充 | RELEX Solutions ↩︎

  39. 変化は何か：2024年サプライチェーン計画ソリューションのマジッククアドラント ↩︎

  40. 主要なサプライチェーン課題に取り組むための適切なAIの活用 | RELEX Solutions ↩︎

  41. AI搭載による収益成長管理ソフトウェア | o9 Solutions ↩︎ ↩︎ ↩︎

  42. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  43. Blue Yonder、サプライチェーン管理とオーケストレーションを劇的に簡素化する生成AI機能を開始 … ↩︎

  44. o9のAI/ML機能でビジネス価値を最大化 ↩︎

  45. 需要管理の買収がエンドツーエンドプランニングを最適化 ↩︎

  46. ToolsGroup、業界をリードするレスポンシブAIのためにEvoを買収 | ToolsGroup ↩︎ ↩︎ ↩︎

  47. 小売価格設定ソフトウェア | Markdown Pricing Tool ↩︎

  48. 小売価格設定ソフトウェア | Markdown Pricing Tool ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  49. 小売価格設定ソフトウェア | Markdown Pricing Tool ↩︎

  50. ToolsGroup、業界をリードするレスポンシブAIのためにEvoを買収 | ToolsGroup ↩︎

  51. ToolsGroup、業界をリードするレスポンシブAIのためにEvoを買収 | ToolsGroup ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  52. ToolsGroup、業界をリードするレスポンシブAIのためにEvoを買収 | ToolsGroup ↩︎ ↩︎ ↩︎

  53. ToolsGroup、Mi9 Retailの需要管理事業を買収 | ToolsGroup ↩︎ ↩︎ ↩︎ ↩︎

  54. 確率的予測 - 入門編 | ToolsGroup ↩︎

  55. ToolsGroup、業界をリードするレスポンシブAIのためにEvoを買収 | ToolsGroup ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  56. ToolsGroup、Mi9 Retailの需要管理事業を買収 | ToolsGroup ↩︎

  57. 小売価格設定ソフトウェア | Markdown Pricing Tool ↩︎

  58. 小売価格設定ソフトウェア | Markdown Pricing Tool ↩︎

  59. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎

  60. ToolsGroup、業界をリードするレスポンシブAIのためにEvoを買収 | ToolsGroup ↩︎

  61. 変化は何か：2024年サプライチェーン計画ソリューションのマジッククアドラント ↩︎

  62. 変更点：2024年サプライチェーン計画ソリューションのマジッククアドラント ↩︎ ↩︎

  63. ToolsGroupがOneraを買収し、計画から実行までリテールプラットフォームの拡充を図る… ↩︎

  64. ToolsGroup JustEnough®がNRF 2024に対応型AIを導入 ↩︎ ↩︎

  65. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎

  66. 小売価格設定ソフトウェア | Markdownプライシングツール ↩︎ ↩︎ ↩︎

  67. ToolsGroup、リテール向けSPARKマトリックスにおいてリーダーとして位置付けられる… ↩︎

  68. 変更点：2024年サプライチェーン計画ソリューションのマジッククアドラント ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  69. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  70. 需要計画ソフトウェア | Blue Yonder ↩︎ ↩︎

  71. Blue Yonderがサプライチェーン計画を刷新し再構築する… ↩︎

  72. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  73. サプライチェーン向けAI | Blue Yonder ↩︎

  74. サプライチェーン需要予測と計画 - Google Patents ↩︎

  75. 変動の激しい世界で需要予測の精度を高める3つの方法 ↩︎

  76. サプライチェーン需要予測と計画 - Google Patents ↩︎

  77. 生成AI：自律型サプライチェーンのフォースマルチプライヤー… ↩︎

  78. サプライチェーン在庫最適化 | Blue Yonder ↩︎ ↩︎

  79. KnaufがBlue Yonderを活用して自律型サプライチェーンを構築 ↩︎

  80. 小売業者や店舗に予測価格設定で支援する4つのテック企業 - Business Insider ↩︎

  81. Blue Yonder Solutionsによるデジタルサプライチェーン計画 - Infosys ↩︎

  82. 市場調査、サプライチェーン最適化ベンダー ↩︎

  83. 市場調査、サプライチェーン最適化ベンダー ↩︎ ↩︎ ↩︎ ↩︎