AI駆動のサプライチェーン最適化ソフトウェア, 2025年6月

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

最終更新日: 2025年6月2日

はじめに

『AI駆動』のサプライチェーンソフトウェアに対する過剰な宣伝にもかかわらず、高度なアルゴリズムを用いて在庫、価格設定、品揃えの同時最適化を実現しているベンダーはほんの一握りです。多くのソリューションはこれらの要素を個別に扱うに留まり、この研究ではそのアプローチが根本的に問題があると指摘しています。定量的なサプライチェーン最適化の技術的限界に挑戦するグローバルプレイヤーとして、Lokad、RELEX Solutions、Blue Yonder、ToolsGroup、およびo9 Solutionsを挙げます。Lokadは統一された確率的意思決定エンジンと高い自動化レベルによりリーダーとして浮上し、一方でRELEXとBlue Yonderは既存のレガシー問題や統合の課題により、幅広いエンドツーエンドのスイートを提供しています。ToolsGroupは、小売価格設定に進出する確率的在庫最適化の先駆者であり、o9 SolutionsはAI駆動の統合プラットフォームを売りにしていますが、我々は現実との乖離を考慮して慎重な姿勢を維持しています。特に、Kinaxis、SAP、Oracleといった既存大手は、計画において顕著であるものの、（例えば供給または需要計画の一方に集中するなどの）サイロ化されたアプローチや、実際に意思決定を自動化せずにAIコンポーネントを追加する手法のため、本評価では減点対象となります。我々はマーケティングの誇大表現を排除し、技術的証拠を精査し、ベンダーの主張と現実との乖離を明らかにするという、非常に懐疑的な視点を適用しています。目的は、経済的成果を重視しつつ、バズワードではなく透明で技術的に厳密な市場の物語を提供することにあります.

AI駆動型サプライチェーン最適化に求められる高水準

AIでサプライチェーンを真に最適化するには、ただ見栄えのするダッシュボードを作成したり予測を微調整するだけではなく、非常に高度な機能が求められます。我々はゴールドスタンダードとなる基準を以下のように定義します:

在庫、価格、品揃えの同時最適化： ソリューションは、どの製品をどれだけの量で在庫するか、同時にどの値段で販売するか、さらに商品の品揃えを選択する決定を行う必要があります。これらの側面を個別に扱う（従来の計画ツールが行っているように）は、本質的に最適とは言えません ¹. 価格は需要に影響し、需要は在庫に影響します。品揃えの変更はその両方に影響を及ぼします。例えば、高度なシステムは、動きが鈍い商品の在庫を減らし、早期に割引を行うか、逆に在庫切れを避けるために希少商品の価格を上げるといった、一貫性のある戦略の一環としてこれらを決定するかもしれません ² ³. 統一された最適化なしに、予測、補充、価格設定のための個別の“モジュール”を販売し続けるベンダーは、機会損失を招くとして評価を下げられます.
不確実性の確率的予測： 不確実性への対処は不可欠です。単一の予測値の代わりに、主要なベンダーは需要、リードタイム、返品その他の不確実性について確率分布を使用します ⁴. この確率的アプローチは、単純な一点推測ではなく（例：需要が120単位を超える可能性が10%あるなど）、起こり得る結果の範囲を捉えます ⁵. 特に今日の変動の激しい市場やロングテールSKUにおいては重要です。旧式のシステム（旧SAP、Oracleなど）は、最良の推定値と静的な安全在庫を提示するだけで実際の変動性を見誤りがちです ⁶. 我々は、確率モデルを採用してリスクを定量化し、例えば95%のサービス確率を達成するための在庫レベルを設定するなど、予測にただ盲目的に従うのではなく意思決定を可能にするベンダーを支持します ⁷.
経済的最適化（利益重視の意思決定）： AI最適化は、単なる運用KPIではなく、ビジネス成果―利益の最大化または総コストの最小化―に焦点を当てるべきです。つまり、経済的要因（マージン、保管費用、欠品ペナルティ、価格弾力性）を意思決定のロジックに直接組み込む必要があります ⁸. 例えば、真に「最適な」システムは、期待利益が正当化される場合にのみ製品を在庫し、売れ残りリスクと高いマージンのバランスを見ながら価格を設定します。多くのレガシーツールは、（充足率や予測精度といった）狭い指標のみを個別に最適化しますが、我々はむしろ、トレードオフをモデル化するシステム、例えば充足率を若干下げても利益率を大幅に改善できるシステムを求めます ⁹.
自動化と『ロボット化』された意思決定： サプライチェーンにおけるAIの約束は、自律的または少なくとも『ハンズフリー』な意思決定です。最良のソリューションは、日々の運用で人手による微調整を最小限に抑え、プランナーが例外管理の監督的役割に移行し、システムが数値を処理しルーチンな意思決定を実行することを求めます。ゆえに、我々は自動化に関するベンダーの主張を厳しく精査します。ツールが「自律的」と宣伝しながらも、プランナーが多数のパラメータ（手動設定、頻繁な上書きなど）を調整しなければならない場合、それは内在する矛盾を示しています ¹⁰. 真の自動化とは、システムが最小限の手動介入で自己調整し、適応することを意味します ¹¹. 我々は、実際に無人運用（自動的に注文や価格を生成するなど）を実証するベンダーを支持し、「AI」機能が実際のものであるか、あるいは依然として人間に依存した派手な提案に過ぎないのかを検証します。完全なロボット化計画はまだ100%実現可能ではないかもしれませんが、それに最も近いものには評価を与えます.
スケーラビリティと最新アーキテクチャ： 2025年のサプライチェーン最適化は、ビッグデータ―数百万に及ぶSKUとロケーションの組み合わせ、クリックストリームの需要データ、多段階ネットワークなど―を効率的に処理する必要があります。我々は技術スタックを検証します。プラットフォームがクラウドネイティブで、分散コンピューティングと最適化されたアルゴリズムを使用しているのか、あるいは高額なハードウェアを必要とする従来のインメモリやオンプレミスのアーキテクチャに固執しているのかを見極めます。すべてをRAM上に置くか旧式のデータベースを使用するという発想は、スケール時に途方もなく高コストになる可能性があります。例えば、インメモリの「ファストカルク」は小規模データでは機能するかもしれませんが、大規模な問題では処理が詰まったり、クラウド料金が跳ね上がったりします ¹² ¹³. 我々は、クラウド基盤上で費用対効果を持ってスケールするために、ストリーミング、カラムナーデータ処理、並列計算などの巧妙なエンジニアリングを実証するベンダーを評価します ¹⁴ ¹⁵. 逆に、高価な技術（例えばSnowflakeの過剰使用や巨大な専用サーバーの必要性など）に大きく依存している場合、実際の投資対効果に対して警戒すべきサインです ¹⁶.
データ統合と外部インテリジェンス： 現実の最適化は真空状態では起こりません。競合他社の価格、マーケットコンディション、さらにはIoTシグナルなど、外部データを容易に取り込めるシステムを評価します。競合他社の価格や市場の在庫状況を組み込むことで、価格設定や品揃えの決定が大幅に改善される可能性があります ¹⁷ ¹⁸. これをうまく実現しているベンダーは少なく、多くは内部の過去データのみを考慮しています。オンラインと実店舗など、複数チャネルのデータを一つの計画モデルに統合する能力も極めて重要です ¹⁹. つまり、AIシステムは**「ガラスボックス」拡張性**を備え、新たなデータソースやカスタムロジックを透明性をもって追加し、意思決定を改善できるようにすべきです ²⁰. あなた独自のデータを取り込めない硬直したブラックボックスモデルは、競争上の優位性をもたらすには不向きです.
実績と科学的厳密性： 我々は、ベンダーの技術が実際に機能するという証拠を求めます。中立的な予測や計画のコンペティション（例えばM5予測コンペティション）への参加や、具体的な数字を伴う事例研究は大きな重みを持ちます。注目すべき例として、LokadのチームはM5コンペティションで世界909チーム中6位に入るという、非常に細かな小売予測チャレンジにおいて印象的な成果を収めました ²¹. 対照的に、多くの大手ベンダーはAIのベンチマークを公開したことがなく、「AIの精度」を自慢しつつも競技や詳細情報の公開を行っていない場合、懐疑の余地があります ²². また、失敗の事例も検証します。例えば、かつてBlue Yonderの一部となったi2 Technologiesのケースでは、その最適化ソフトウェアがDillard’sで酷い失敗をし、陪審が2億4600万ドルの損害賠償を命じたことがあります ²³ ²⁴. こうした事例（稀ではありますがしばしば内密に扱われるもの）は、壮大な主張に疑問を呈すべきであることを思い起こさせます。結局のところ、我々はマーケティングよりも検証可能なエンジニアリングの詳細に依拠し、文脈を欠いた有料アナリストレポートやあまりにも肯定的な顧客の引用を退けます. (業界関係者が冗談交じりに述べたように、GartnerのMagic Quadrantのリーダーはしばしば製品の優秀性よりもベンダーの予算を反映している ²⁵.)

これらの基準を確立した上で、次に各ベンダーに注目します。以下では、各プロバイダーの技術とアプローチを技術的実力および真のAI駆動最適化を実現する能力に基づいて評価し、厳密に検証します。各評価は、ドキュメンテーションや第三者の分析などの実証に基づいており、本当の革新とバズワードに彩られた約束とを分けるためのものです.

1. Lokad – 統一された確率的最適化と『ロボット化』された意思決定

Lokadは、最先端の技術を用いて同時最適化を明示的に実現するために設計されたベンダーとして際立っています。従来の予測、在庫、価格設定などのモジュールから構築されたスイートとは異なり、Lokadは各クライアント向けに統一された最適化ロジックを実装するプログラム的なプラットフォームを提供します ²⁶. このアプローチは、Lokadによって『定量的サプライチェーン』と呼ばれ、個別のサイロ化されたツールを微調整する代わりに、全体の意思決定プロセス（予測→発注→配分→価格設定）を一貫したモデルとして組み込むことを意味します。初期のデータサイエンス作業は必要ですが、その結果、購入、生産、補充、価格設定、品揃えといった全ての意思決定を一括して最適化するテーラーメイドのエンジンが得られます ²⁷.

Lokadの中核には確率的予測があり、同社は需要に対して単一の予測値ではなく完全な確率分布を用いる先駆者でした。これは中立的な場でも実証され、権威あるM5予測コンペティションではLokadのチームが世界909チーム中6位という印象的な成果を収めました ²¹. 特にM5では、分位点の予測という確率的推定が要求され、これはLokadの理念と完全に一致しています。これにより、Lokadの技術が需要の不確実性に対して世界最良と渡り合える具体的証拠が示されました。さらに重要なのは、Lokadが単に予測精度そのものに固執するのではなく、その確率的予測を用いて意思決定を改善することに注力している点です。同社は、ある一定の水準を超えると予測精度のごく僅かな向上に執着することは収穫が薄いと論じ、重要なのは現状の不確実性を踏まえたより良い意思決定モデルであると主張しています ²⁸. 実際、これはLokadが多少の予測誤差を許容しつつも、その誤差を考慮した在庫や価格設定の意思決定を堅牢に保つこと（例えば、在庫切れと過剰在庫のコストを理解し適切に最適化すること）を意味します ²⁹. このように、予測の虚栄心指標ではなく意思決定の質に重点を置くアプローチは、統計数値に終始するだけでなく実際の経済性（利益への影響）と一致しており、新鮮です.

エンジニアリングとスケーラビリティ： 技術的には、Lokadは非常にエンジニアリング志向でクラウドネイティブです。最適化スクリプト記述用のカスタムドメイン固有言語「Envision」を含む、自社の技術スタックをゼロから構築しました ³⁰. このシステムは、大量のデータを効率的かつ経済的に処理するように設計されており、実際の導入例では、数GBから数TBに及ぶデータ（注文、クリック、取引）を数時間の夜間バッチで処理して翌日の意思決定を出力しています ³¹. これは全てをRAMに詰め込むのではなく、メモリマップドファイル、オンディスクのカラムストレージ、そして巧妙なストリーミング技術により、メモリ以上のデータも高速SSDにスピルして処理するためです ³². このアプローチは、特化したSparkとカスタムデータベースエンジンの中間に位置する、最適化されたビッグデータパイプラインに似ています。ユーザーにとって、これはLokadが数百万のSKUや複雑なネットワークに対し、大規模なサーバーファームや天文学的なクラウド料金を必要とせずにスケールできることを意味します。Lokadは、実行に必要なハードウェアが驚くほど少なく、クラウド計算で「実行ボタンを押すだけで数百ドルかかる」という罠を回避できる点を明示しています ¹⁵. これは、膨大なデータ処理が可能であっても高コストや低速なパフォーマンスに陥りがちな重厚なエンタープライズツールとの差別化において、微妙ながらも極めて重要な要素です。一般的なクラウドインスタンス上で大量の品揃えを迅速に処理できるLokadの能力 ³²は、スケーラビリティとコスト効率という点で大きな強みとなります.

Lokadのプラットフォームは本質的にコード駆動であるため、在庫、価格、品揃えの意思決定は個別のモジュールではなく、それらはスクリプト内に統合されています。例えば、各製品について、様々な価格設定における確率的需要を検討し、現状の在庫やリードタイムを考慮した上で、在庫切れを防ぐために適切な頻度を維持しながら、期待マージンから保管コストを差し引いた価格を選定するEnvisionスクリプトを書くことができます ³. これは仮説上の話ではなく、まさにLokadが可能にするロジックです。もし製品が在庫過剰であれば、スクリプトは売上促進のために値下げを決定するかもしれませんし、希少であれば、在庫を最も価値のある用途に割り当てるために価格を上げるかもしれません ³³. 他のベンダーで、このレベルの価格と在庫の相互作用を一つのモデルで実現しているところはほとんどありません。Lokadは、データからカスタムの意思決定方針を生成し、その出力は単なる「予測」や「計画」ではなく、（例えば何単位購入するか、どの価格に設定するかといった）具体的な意思決定のセットとなり、不確実性下でビジネス目標を最大化します.

また、Lokadは製品のカニバリゼーションや代替品といった複雑な効果にも柔軟に対処します。製品が相互に関連している場合（代替または補完関係）、適切なデータや制約をモデルに投入することでこの関係をエンコードできます。例えば、Lokadは過去の在庫切れ事象から学んだ「もし商品Aが入手できなければ、その需要のX%が商品Bに流れる」という関係性を組み込むことが可能です ³⁴. これにより、多くのツールが各SKUの需要を独立と仮定して見落としがちな、製品間での需要移動を考慮した最適化が可能となります ³⁵. 過去のデータ分析により、製品間やチャネル間の相関関係（例：新たな類似商品の投入が既存商品の売上に及ぼした影響など）を明らかにし、それを需要予測や意思決定に組み入れることができます ³⁶. この能力は、どのSKUを維持または削除するかという品揃えの決定や、例えば一つ値下げすると他の商品にも不必要に影響が及ぶのを防ぐための価格設定において、極めて重要です.

外部データや競合インテリジェンスの取り込みにおいて、Lokadは非常に柔軟です。プラットフォームは、クライアントが提供するあらゆるデータセットを取り込むことができ、ウェブサイトからスクレイピングされた競合他社の価格情報、Googleトレンド、天気予報、サプライヤーの信頼性統計など、あらゆるものに対応します。実際、Lokadはモデルに「競合他社の価格設定などの外部シグナル」やマーケティングカレンダーを統合することを明示している¹⁷。システムがスクリプト環境であるため、新たなデータ入力の追加は比較的容易であり、考慮され得る要因についてハードコードされた制限はありません。例えば、競合他社の価格指数を活用することで自社の価格決定が向上する場合、Lokadはそれを最適化ロジックに組み込むことを可能にします。これは、デフォルトで内部の売上や在庫データのみを使用する多くのパッケージ型ソリューションとは対照的です。Lokadのアプローチは、ブラックボックスというよりはむしろ**「グラスボックス」であり、ユーザー（ある程度のデータサイエンスのスキルを持つ者）がロジックを確認・修正し、新たな予測因子を追加したり、代替アルゴリズムを試すことができます。その代償として、一般的なプランナー向けのシンプルなポイントアンドクリック型UIではなく、「サプライチェーンサイエンティスト」による設定が必要となります³⁷。Lokadの見解では、この初期労力が、ビジネスに正確に適合し、その後のルーチンな意思決定を真に自動化**するシステムへと還元されるというものです。実際、多くのLokadクライアントは、あたかもカスタム構築された「予測＆在庫補充の頭脳」を持つかのようで、一度設定・検証されれば、最小限の介入で稼働します。

自動化の観点では、Lokadは今日、最も「ロボット化されたサプライチェーンプランナー」に近い存在と言えます。スクリプトが整備されテストされた後、システムは日次（または日中）で稼働し、人手による編集なしに推奨される意思決定を出すことができるのです³⁸。実際、Lokadを利用する企業は、しばしば購入注文、割り当て計画、または価格更新を自動生成し、その後プランナーによる簡易な妥当性確認や推奨事項の実行を行います。自信が十分な場合には、自動的に注文を実行するケースもあります。これは、人間が関与しないという意味ではなく、作業負荷が大幅にシフトすることを示しています。プランナーはプロセス全体を監督し、（モデルがカバーしていない特別な事例などの）例外処理を担当するため、手作業で数値を計算する必要はなくなります。LokadのCEOは、ソフトウェアが継続的に意思決定を微調整し、人間が戦略的選択またはエッジケースの処理に専念する、完全にロボット化されたサプライチェーンを理想として描いています³⁸。我々の分析では、意思決定モデルの品質に注力し、自動化に適した技術を活用することで、手動での微調整の必要性を最小限に抑えており、Lokadの設計はそのビジョンと十分に一致していることが分かります。もちろん、成功は実装に依存しており、モデルの設定が不十分だったりデータが劣悪な場合には結果も悪化します（ガベージイン、ガベージアウト）。Lokadは、データ品質やモデル検証についてクライアントと密接に連携することでこれを緩和しています。それでも、信頼は重要な要素であり、企業は自動化システムを信頼する覚悟が必要です。Lokadの実績（公に失敗事例がなく、優れたケーススタディが存在すること）はその信頼構築に寄与していますが、見込み利用者はどんな「自動操縦」に対しても慎重にアプローチすべきです。要するに、Lokadは統一された、確率論的かつ高度に自動化された最適化アプローチを提供しており、その深さはめったに見られません。一方で、既製品のオフザシェルフアプリではなく、サプライチェーンの意思決定をコード化するという新たな働き方を受け入れる必要がある点は留意すべきです。そのパラダイムに投資できる組織にとって、現時点でLokadはAIを活用したサプライチェーン最適化の分野で高い水準を示しています。

出典: Lokadの哲学や技術の詳細は、公式文献²⁶ ²¹ ³や予測コンペティションにおける公開ベンチマーク²¹から引用されています。エンジニアリングの実践（カスタムDSL、メモリマップされたビッグデータ処理）は、技術的な解説¹⁴ ³²に示されています。価格設定および競合データの統合については、文書および事例³ ¹⁷に記述されています。同社の自動化に対する姿勢は、インタビューやユーザーレポートに反映されており、一度設定されるとシステムが最小限の手動入力で意思決定を出すことが示されています³⁸。

2. RELEX Solutions – AIによる小売計画（統合されているが、いくつかの注意点あり）

フィンランド発のRELEX Solutionsは、予測および在庫補充の伝統的大手と並び、小売およびサプライチェーン計画スイートとして急速に台頭しました。RELEXは、需要予測、自動補充、割り当て、品揃え計画、さらには労働力スケジューリングや価格最適化を1つのシステムで網羅する統一プラットフォームを展開しています³⁹ ⁴⁰。同社の中核的強み（および初期の焦点）は、膨大なSKU数、店舗、そして複雑なプロモーションが存在する食料品およびオムニチャネル小売にあります。RELEXは、オンラインとオフラインのチャネルを連携して計画できる能力を強調しており⁴¹、これは現代の小売業者にとって非常に重要です。eコマースまたはオムニチャネルの事業者にとって、RELEXのバリュープロポジションは、先進的なアルゴリズムにより、適切な在庫を適切な場所に、適切な時に、適切な価格とプロモーションで提供するエンドツーエンドの計画プロセスの実現にあります。

AIの活用と「プラグマティックAI」： RELEXは、AI/MLの活用を強力に推進しており、CEOのMikko Kärkkäinenはしばしば、実際に小売KPIに測定可能な改善をもたらす「プラグマティックAI」を提唱しています。彼らは、自社の機械学習モデルが需要に影響を与える「何百もの要因」を処理して予測精度を向上させると自負しています⁴⁰。例えば、Kärkkäinenは、天候が単一の要因ではなく、場所や時間ごとの気温、湿度など、需要に影響を与える「何百もの異なる要因」であると指摘しており、RELEXのモデルはそれらすべてを考慮に入れています⁴²。これは、天候、プロモーション、祝日、ソーシャルメディアのトレンド、競合の動向、経済指標などを含む幅広い予測シグナルを捉え、アルゴリズムにパターンを見出させるというRELEXの基本的なアプローチを示しています。その利点は、システムが複雑な相互作用（例えば、猛暑と祝日週末が組み合わさることで飲料販売が急増するなど）を検出できる点にあります。しかしながら、「何百もの要因」を謳うことは、実質的な意味よりもマーケティング的な側面が強い可能性があるという懐疑的見解も存在します。予測において、あまりにも多くの入力を追加すると、収益逓減に陥ったり、ノイズに対する過剰適合によって精度が低下したりすることがあります⁴³。また、RELEXは「グラスボックス」の透明性について語っていますが、実際にアルゴリズムが何百もの変数を使用している場合、その内部ロジックを人間が完全に把握することは不可能です⁴⁴。結果として、プランナーはブラックボックスを信頼せざるを得なくなります。RELEXは、例えば「この急上昇は猛暑とプロモーションが原因です」といった主要な要因を表示する予測説明用ツールを提供することで、この問題を緩和しようと試みていますが、その効果にも限度があります⁴⁴ ⁴⁵。彼らが推進するプラグマティックなアプローチは、理論的な優雅さよりも数値の改善を重視するものであり、それ自体は問題ありませんが、一部の主張（無数の要因追加による大幅な誤差削減など）が、選び抜かれた成功事例に過ぎない可能性があると我々は警告します⁴⁶。

結果に関して、RELEXには、特にプロモーションや季節的急増のような計画が難しい状況下で、予測精度の向上や品切れの減少が見られるという多数の顧客事例があります。よく引用される例として、天気予報を統合することで、RELEXは異常気象時に特定の天候感受性製品の予測誤差を最大75%削減できたと主張しています⁴⁷。このような劇的な数値は、全体的な予測誤差ではなく、特定の事例（例えば、予想外の猛暑時にある特定のアイスクリームであったなど）を指している可能性があるため、慎重に受け止める必要があります。それでも、RELEXの機械学習モデルが、従来のシステムでは捉えきれなかった短期的な需要変動を把握できることを示唆しています。本質的に、RELEXは古典的な需要予測と、いわゆる**「需要センシング」を融合させ、POS販売、天気、Google検索など最新のデータを用いて直近期間の予測を連続的に調整しています⁴⁸。条件変化に応じた連続的な自動再予測**の考えを推進しており⁴⁸、新たな情報が入るたびに翌数週間の予測を日次あるいは日中で再計算する仕組みとなっています。これは現代のベストプラクティスに則っており、RELEXが得意とするところです。

共同最適化 – 在庫、品揃え、そして現在は価格： 歴史的に、RELEXは補充および割り当てにおいて卓越しており、マルチエシェロンロジックを活用して各店舗または配送センターに地域需要に基づく適切な在庫を供給してきました。また、品揃え計画やプラノグラム（陳列棚スペース）の最適化機能も備えており、実店舗小売において重要な役割を果たしています⁴⁹。しかしながら、価格最適化は長らく未対応の分野でした。これを受け、RELEXは2022年にAI駆動の価格最適化モジュールを導入しました⁵⁰。同社は、分断された価格戦略が問題であることを認め、これを既存の計画スイートと統合することを試みたのです。RELEXの価格ソリューションは、基本価格の決定、プロモーション、値下げを扱い、システム全体と緊密に統合されていると位置付けています⁵¹。例えば、ユーザーがRELEX上でプロモーションを計画すると、システムは最適な割引率とタイミングを推奨し、その後、在庫への影響（サプライチェーンが需要増を補えるかどうか）を自動的に考慮します⁵²。これは、価格と供給計画をひとつのループで統合する共同最適化に向かう動きです。しかし、RELEXのエンジンが、価格と在庫を同一モデル内で同時に真に最適化しているのか、あるいは、まず価格を算出し、その後在庫が調整されるという、うまく連携した順次プロセスなのかは未だ不明です。理想的には、制約条件を考慮して利益最大化を実現する価格と在庫の組み合わせを、ひとつのアルゴリズムが選択するべきです。我々は、現状RELEXが完全にその段階には達していないと推測しており、価格モジュールが需要弾力性に基づいて価格を提案し、その後、在庫システムが第二段階で適応している可能性が高いと考えます。しかしながら、すべてが一つのプラットフォームおよびデータモデル上にあるため、反復処理は緊密に行われます。少なくとも、プランナーがシミュレーションするプロモーションや価格変更が在庫の可用性と照合されることは保証されており（例：「配送センターに十分な在庫がなければ大規模プロモーションは予定しない。あるいは、実施する場合はシステムが供給リスクを警告する」）⁵³。また、RELEXのマーケティングでは、価格やプロモーションをサプライチェーンと連携させることで、計画が現実的かつ実行可能になると謳っており⁵⁴、これによりマーチャンダイジング部門とサプライチェーン部門間のサイロ化が解消されます。

ユーザーエクスペリエンスの観点から、RELEXはこれら全ての機能を一つの一貫したインターフェイスに統合した点で高く評価されています。商業プランナーとサプライプランナーは、RELEX上で同じ予測を共有し、同一の制約条件を確認できるため⁵⁵、各機能ごとに連携のない別々のツールやスプレッドシートを使用していた従来の方法に比べ、大きな改善が見られます。とはいえ、統合されていることと真の最適化が同義であるとは限りません。RELEXは統一されたビューを提供し、一貫性を確保します（適切に使用すれば、サプライチェーンがサポートできないプロモーションを価格チームが無批判に実施することはありません）が、RELEXが最適な価格と在庫を共同で最適化しているのか、あるいは単に人間がこれらの決定を調整しやすくしているだけなのかは疑問です。我々の懐疑的な見解では、現時点では後者の傾向が強く、価格ツールが弾力性や販売目標に基づいて良好な価格を算出し、その後在庫ツールが供給計画を策定するという、互いに情報を提供し合うに留まっていますが、それが必ずしも価格と在庫の両方を網羅する単一の利益最大化アルゴリズムになっているわけではありません⁵⁶。一段階の全体的な最適化を実現することは非常に複雑であり、これを達成できるのはLokadのような非常に専門的なアプローチのみが主張できることでしょう。それでも、RELEXはデータおよびUXの統合という面で緊密な統合を実現しており、非常にシームレスな計画スイートの一つといえます。

アーキテクチャとスケーラビリティ： RELEXの技術スタックは非常に先進的で、大規模環境下での高速性が評価されています。興味深いことに、RELEXの創設者（学術的背景を有する）は、初期の段階で大規模な予測を迅速に処理するため、カスタムのインメモリ・カラム型データベースエンジンを構築しました⁵⁷。この「ライブデータベース」により、競合他社が週次または月次で予測を行う中、各SKU・店舗ごとに日次の予測を算出し、一般的なハードウェアでメモリ使用量を最適化することで実現できたのです。本質的に、RELEXは迅速なデータ取得と計算のために、データを事前に集計し整理しています。これは旧来のツールからの脱却において差別化要因となり、多くのケーススタディで、システムが大量のデータを詰まらせることなく処理できるため、プランナーが大まかな計画から非常に詳細な計画へと移行できたと報告されています⁵⁸。eコマースの文脈では、RELEXは数万から数百万品目のSKUレベルの計画を処理し、頻繁に予測を更新できると考えられます。また、クラウド展開をサポートし、水平スケーリングも可能です。実際、業界からRELEXのスケーラビリティに関する苦情はなく、むしろExcelや旧式システムが対応できなかった詳細なデータを扱える点がセールスポイントとなっています⁵⁹。ただし注意すべきは、そのインメモリ方式は誤用されるとコストがかさむ可能性がある点です（例えば、実際に100万SKU×1000日のシミュレーションをメモリ上に保持しようとする場合など）。しかしながら、RELEXの設計は十分に効率的であり、公開された重大な問題として報告されてはいません。同社は、数千の店舗、総計数百万のSKUを有する大規模な食料品チェーンにサービスを提供しており、これは多くの純粋なeコマース企業が扱うデータ量を上回るため、ボリューム面での懸念はありません。まとめると、RELEXのアーキテクチャは現代的で高速ですが、大量のメモリ使用に依存しています。最適化は十分に行われていると思われますが、ユーザーは依然として適切なデータ管理（ゴミが入力されれば、速やかにゴミが出力される）を実践する必要があります。

自動化とユーザーロール: RELEXはしばしば**「自律計画」への移行を言及するが、同時に強化された意思決定支援も強調している。彼らはプランナーを排除しようとしているわけではなく、むしろプランナーの効率を向上させることに注力している。システムは予測、注文、さらには店舗間移動やプラノグラムの自動入力まで行えるが、通常は人間がレビュー／承認する – 少なくとも初期段階では ⁶⁰ ⁶¹. Mikko Kärkkäinenは理想を「自己学習・自己調整する自律小売計画」と表現し、計画機能間のサイロを打破している ⁶². 実際、多くのRELEX顧客は半自動モードで運用している可能性が高い：ソフトウェアが作業の90％を担い、プランナーが例外処理や監視を行う ⁶³. たとえば、RELEXには「予測例外」があり、AI生成の予測が明らかに異常な場合（たとえば、明確な理由なく昨年より300％高い場合）、システムはそのまま進めるのではなくレビューのためにフラグを立てる ⁶⁴. この種のガードレール**は信頼構築において重要である。時間が経つにつれて、AIの性能が向上すれば、プランナーはそれをより信頼し、介入が減少するかもしれない。RELEXはシステムが自己調整し（データが増えるにつれてパラメータを調整する）手動介入が減ると主張している ⁶⁵. また、RELEXの実装によりプランナーが火消し作業から解放され、戦略的な動きに専念できる例も確認された ⁶⁶ – これは各社が日常業務の大部分をシステムに任せていることを示唆する。しかし現実は複雑で、第三者が収集したユーザーフィードバックには、RELEXのシステムの一部が「使いにくい」または特定の制約（例えば、輸送能力の制限のモデリングなど）のために回避策を必要としているとの指摘もある ⁶⁷. これは自律性の主張にもかかわらず、ユーザーが内蔵機能の限界に直面し、手動で対応せざるを得なくなる場合があることを示している。RELEXは決して魔法のようなものではなく、手動作業を大幅に削減するが、完全なハンズオフシステムという印象は現状では誇張である。

既知の問題と実装: いくつかの競合と異なり、RELEXは大々的な公の失敗や訴訟を起こしておらず、一般的には評判が良い。しかし、急成長企業であるため、実装がセールストークに比べて劣る可能性もある。内部情報によれば、非常に大規模で複雑な小売環境において、RELEXは課題に直面することがあり、その原因はソフトウェア自体の問題ではなく、データ統合の困難や組織変革の問題に起因することが多い ⁶⁸ ⁶⁹. 小売業者のデータが混沌としている場合、どんなAIシステムも魔法のように解決できない。悪いデータが供給されれば、RELEXは誤った計画を生み出す（その場合、ツールに責任があるのか、データに責任があるのか？）。さらに、RELEXは多くの顧客を迅速にオンボーディングしており、その結果、サービスやサポートが行き届かない場合がある。特に、各クライアントと密に連携する小規模ベンダー（例：Lokad）と比べると、十分なサポートやカスタマイズが受けられないこともある。これはソフトウェア自体の欠陥ではないが、成果に影響する – ツールはその実装と採用状況によって性能が左右される。ベンダーは最良のROI（例：「ある小売業者はRELEXで在庫を30％削減！」）を強調するが、ROIが実現しなかった例を公表することはほとんどない。RELEXも他のベンダー同様、約束されたKPIに届かなかったプロジェクトが存在したと疑われる。もしかすると、プランナーがシステムを十分に信頼せずに上書きしたか、データの問題で最適に動作しなかったのかもしれない。これらは公には検証しにくい。注目すべきは、競合他社（Blue Yonder）でさえ、ほとんどのプロジェクト失敗は不十分なチェンジマネジメントとデータ統合によるものであり、アルゴリズムのミスではないと認めたことである ⁷⁰. 同様に、RELEXもデータの整備と、ユーザーが実際に推奨事項を活用するための支持が必要である。

もう一つの側面：RELEXは小売向けに多くの外部データを取り入れる傾向がある（例：携帯電話からの来店者数データ、検索関心を示すGoogle Trendsなど）。これらの中には純粋なeコマースにはあまり関連性がないものもある（来店者数は明らかに該当する）が、これはRELEXが利用可能なすべてのシグナルを活用するという考え方を示している ⁷¹. eコマース企業にとって、RELEXはウェブ解析データやオンライン競合の価格が提供されればそれらを取り込むことができるが、標準の提供内容は小売シナリオに合わせて調整されている。専用の価格設定ツールのように自動で競合価格を取得するわけではないが、クライアントがそのデータを提供すれば、RELEXの価格最適化はそれを考慮に入れることができる。

RELEXに関する評決: 当社は、包括的かつ統合されたアプローチと最新の技術スタックにより、RELEXを非常に高く評価している。明らかに多くの基準を満たしており、品揃え、在庫、そして現在は価格設定を一つのプラットフォームで管理し、機械学習を広範に活用（場合によってはそれが過剰になることもある）し、膨大なデータにスケールできるように設計され、さらに一定の自動化をサポートしているが、プランナーは依然として関与している。注意点として、一部のAIに関する主張は過剰なマーケティングかもしれない（何百もの要因は印象的だが、常に比例した成果をもたらすとは限らない ⁴³）、また「共同最適化」が数学的に純粋でない可能性もある – 限定的な場合を除いて、価格と在庫の単一統合最適化モデルというより、統合された計画ワークフローに近い可能性がある。さらに、大規模なスイートであるため、Lokadのようなプラットフォームアプローチが提供するオーダーメイドの調整と同等の柔軟性はなく、大企業全体に実装するにはより多くの労力（データ統合、ユーザートレーニング等）が必要となる場合がある。加えて、RELEXは小売に特化しており、複雑な製造サプライチェーンでは、詳細な生産能力最適化などでギャップが見られるかもしれないが、小売においては最高水準である。総じて、RELEXは次世代小売計画のリーダーであり、AI駆動かつサイロフリーな計画へと推進しているが、完全に自律している（まだ）わけではなく、統合上の課題も存在する。我々が持つ懐疑は、彼らの最も大胆な主張を精査し、ユーザーがこれを魔法の解決策と誤解しないようにする点にある – RELEXの成功には、依然としてデータとプロセスの改善が求められる。

出典: RELEXの機能は、企業資料およびCEOインタビューからまとめられている ⁴⁰ ⁴². 2022年にプレスリリースで価格最適化の導入が報告された ⁵⁰. Mikko KärkkäinenのAIに関するコメント（「何百もの要因」、「自己学習、自己調整計画」）は、業界の記事に記録されている ⁴² ⁶². ユーザーのフィードバック（使いにくい部分、輸送制約の問題など）は、SelectHubのレビュー集約ツールを通じて報告された ⁶⁷. また、RELEXの統合アプローチと、依然として必要な人間による監督の必要性の証拠も引用している ⁵³ ⁶⁰. 業界の課題に関する比較（Blue Yonderのプロジェクト失敗に関する指摘 ⁷⁰）および外部データ利用 ⁷¹ が、RELEXの強みと限界の背景を示している。

3. Blue Yonder – 旧態依然の巨人が変革の途上に（約束と現実）

Blue Yonder（旧称JDA Software）は、サプライチェーンソフトウェアの巨人の一社であり、小売および製造計画の分野で数十年にわたる歴史を有する。そのスイートは巨大で、需要予測や補充管理から倉庫管理、輸送、労働力スケジューリング、そして2020年以降は価格最適化（価格設定の専門企業Revionicsの買収後）に至るまで、あらゆる領域を網羅している ⁷² ⁷³. 大手小売業者やCPG企業であれば、Blue Yonderはサプライチェーンの各部分に対応するソリューションを持っている可能性が高い。さらに、eコマースやオムニチャネルを展開する企業に対しても、Blue Yonderは世界最大規模の小売運営向けに開発された機能を提供している。しかし、その幅広さには旧来の遺物が伴う。Blue Yonderの多くのモジュールはもともと別個の製品であった（多くは買収によるもの）ため、これらを一つの首尾一貫した最新システムに統合するのは依然として困難な課題である。Blue Yonderが複数回の買収（JDA自体はi2 Technologies、Manugisticsなどの合併から形成された）を経験していることは、その技術スタックが継ぎ合わせのように感じられる要因でもある ⁷⁴.

共同最適化と統合: 紙の上では、Blue Yonderは共同最適化のためのすべての要素を完璧に満たしている。同社は、需要予測エンジン（「Luminate Demand Edge」）、在庫および補充ツール（多段階最適化など）、そして価格最適化エンジン（Revionics、現在はLuminate Pricingとしてリブランディング）を備えている ⁷² ⁷⁵. 同社は、これらのコンポーネントが連携して機能するエンドツーエンドのビジョンを掲げている。たとえば、需要予測が在庫計画と価格決定の両方に供給され、価格エンジンは需要の弾力性（すなわち、価格変更が需要にどう影響するかを予測）を考慮し、すべてが「Luminate Platform」で統合される。理論上は、Blue Yonderのすべての要素を用いれば、価格チームの動きが供給制約を反映し、逆もまた然りの調整の取れた計画が実現できるはずである。実際には、 歴史的にこれらのモジュールはバラバラで、データインターフェースで緩く繋がっているに過ぎなかった。たとえば、Revionicsは買収時に独自のデータベースとUIを持っており、これをJDAの需要計画と連携させるにはIT統合が必要であった。Blue Yonderはこの断片化を認識し、2023年に大規模なアーキテクチャ刷新を発表した。それは、単一のデータモデルとプラットフォームへの移行であり、Snowflake（クラウドデータウェアハウス）を統一データ層として積極的に活用するものである ⁷⁶ ⁷⁷. CEOは、すべてのBlue Yonderアプリがこの共通のクラウドリポジトリを通じてデータを流動的に共有する「サプライチェーンオペレーティングシステム」のビジョンを描いた。つまり、需要計画と価格設定の間で従来型のバッチ統合の必要性を排除し、すべてが同じクラウドデータに読み書きされ、ほぼリアルタイムで同期する状態を目指している。

このビジョンは、サイロ化されたシステムという重大な弱点に対応しているため、有望だ。もしBlue Yonderがこれを実現できれば、顧客は真のワンストップ計画を享受できるだろう。つまり、少なくともBlue Yonderのコンポーネント間では、モジュールを接続するためにカスタムインターフェースを構築する必要がなくなる ⁷⁸. しかし、我々はこれに対して若干の懐疑を抱いている。これほどの規模のスイート全体を一つのプラットフォームで再構築するのは、非常に困難な作業である。Blue Yonderは実質的に、多くのレガシーなオンプレミスコードを、単一の真実の源としてSnowflakeを使用するクラウドマイクロサービスに変換しようとしている。彼ら自身のコンサルティングパートナーも、このビジョンは素晴らしいものの、「統合を完全に排除するのは過度に楽観的かもしれない」と警告している ⁷⁹. 大企業は様々な場所にデータを保有しており、すべてがSnowflakeにうまく収まるわけではない ⁷⁹. したがって、Blue Yonderの内部モジュールが統合されたとしても、他システム（SAP ERPなど）との統合は引き続き必要となるため、プラグアンドプレイにはならない。さらに、移行は段階的に行われており、Blue Yonderは顧客を遠ざける可能性のある「一気に大変革する」置き換えを行っているのではなく、古いモジュールを段階的にマイクロサービス化し、顧客に各自のペースで移行するよう促している ⁸⁰. つまり、現時点では、多くのBlue Yonder顧客が依然として旧システムと新システムの混在状態にあり、例えばオンプレミスでJDAの需要計画を運用し、場合によってはRevionicsをSaaSで利用し、両者間でデータフィードが存在する ⁸¹. 完全に統一されたプラットフォームは、あと1～2年後にしか利用できず、既存顧客の移行にもさらに数年を要するかもしれない。したがって、現状では、Blue Yonderによる「共同最適化」は依然として手動での調整を必要とする。たとえば、小売業者はBlue Yonderを価格設定および供給計画に利用するが、計画チームが価格チームの出力を供給計画に反映させる必要があり、これは自動的な一体化プロセスとは言えない ⁸². この点について、我々はBlue Yonderに若干の減点を行う。すべての部品は揃っているが、マーケティングが示唆するほどの結束力は、少なくとも現時点では見受けられない。

先進的アルゴリズム vs. レガシーテクノロジー: Blue Yonderは多くの先進的なアルゴリズムを誇っている。元々のBlue Yonder（2018年にJDAが買収したドイツのAIスタートアップ）は、小売向け予測のための多くの機械学習の知的財産をもたらした ⁸³. 現在、Blue Yonder（同社）はそのアプリ全体で「説明可能なAI、機械学習、さらには生成AI」を使用していると謳っている ⁸³. また、ネットワーク最適化などの分野で、前身のi2やManugisticsによって数十年にわたって培われたオペレーションズリサーチの深い専門知識を有している。しかし、ここで非常に注意すべきなのは、Blue Yonderが大量の技術的負債を抱えている点である。そのコードベースの大半は1990年代や2000年代初頭のオンプレミス向けに構築されたものである。確かに、一部は現代的なUIやマイクロサービスに更新・包装されているが、根底では一部モジュールが旧来のアーキテクチャ由来の前提や制限（例：Oracleデータベースの必要性、シングルスレッドでの動作など）を依然として保持している ⁸⁴ ⁸⁵. Blue Yonderのマーケティングが「認知的、ML駆動の計画」と謳うとき、我々は本当に新技術なのか、あるいは古いワインを新しいボトルに詰め替えただけなのかと問いかける ⁸⁶ ⁸⁷. 多くの場合、これは漸進的な改善に留まり、例えば現在の需要計画は休日の需要増加や天候の影響のためにMLモデルを利用している – これは良いことであるが、全体のシステムは依然として旧来のものに類似しており、ただMLコンポーネントが追加されているに過ぎない ⁸⁸. レガシー計画エンジンにML予測を盛り込むのと、AIのために計画エンジン自体を再設計するのとは、大きな差がある。Blue Yonderは変革の途上にあり、その一部は最先端であり、一部は改造されたレガシーである。

具体的で（戒めにもなる）逸話：i2 Technologiesは、現在Blue Yonderの中に組み込まれているが、強力な最適化ソフトウェアとともに、いくつかのプロジェクトの惨事でも知られていた。最も悪名高かったのは、Dillard’s対i2事件である。2010年にJDA（Blue Yonder）がi2を買収した後、デパートチェーンであるDillard’sが2000年代のi2の実装失敗を理由に訴訟を起こした。陪審はDillard’sに約$246百万の損害賠償金を命じ、基本的にi2のソフトウェアが約束を果たさなかったと判断した ²³ ²⁴. これは企業向けソフトウェアにおける最大級の判決の一つである。約15年前の出来事であり、古い歴史と見なせるが、一つの重要な点を強調している：有名なベンダーであっても、技術が過大に宣伝されたり適切に実装されなかった場合、巨大な失敗を招く可能性がある。Blue Yonderはその訴訟を（控訴でより低額となったが）和解し、厳しい教訓を学んだとみられる。我々がこれを取り上げるのは、Blue Yonderを特定して非難するためではなく、懐疑を強調するためである。どんなに大きく「業界をリードする」ベンダーであっても、成功が保証されるわけではない。Blue Yonderの歴史には大きな成功とともに、大きな失敗も存在する。

ブルー・ヨンダーの評価すべき点は、近年、このような問題に対してより率直に取り組む姿勢を見せ始めたことである。2023年のパートナーサミットでは、ブルー・ヨンダーは「レッドプロジェクト」（失敗した実装）について率直に議論し、その主な原因は悪いアルゴリズムではなく、**「非効果的なチェンジマネジメントとデータ移行／統合の問題」**であると指摘した ⁷⁰。本質的に、プロジェクトが失敗したのは、顧客のデータが十分に統合・クリーンでなかったり、ユーザーがシステムを採用しなかったためであり、数理計算が機能しなかったからではない。この内省は、市場全体で見られる現象と一致しており、他社においても同様に、数学的手法がいくら優れていても、組織やデータが整っていなければプロジェクトは失敗するという事実を裏付けている。ブルー・ヨンダーがデータ統合の課題を強調する点は、同社の自社スイートの複雑さを間接的に示している。もしそのモジュールが真にプラグ・アンド・プレイであれば、データ統合はそれほどの痛点にはならないだろう。統一されたSnowflakeデータレイヤーへの移行はその問題に対処するための試みだが、先にも述べたように、現在進行中の作業である ⁸⁹.

AI最適化の現状機能： 2024年頃の主要分野におけるブルー・ヨンダーの能力を見てみよう:

需要予測： ブルー・ヨンダーのLuminate Demand（特に新しい「Demand Edge」モジュール）は機械学習を活用し、天候、イベント、価格シグナルなど多数の外部要因を取り込むことができる ⁹⁰. また、確率的予測のサポートへと舵を切っており―LokadやToolsGroupほどネイティブではないかもしれないが、プランナーが単一の数値ではなく、信頼区間やシナリオレンジで作業できるようにしている ⁹¹ ⁹². ブルー・ヨンダーのアプローチは、資料に記されている通り、最新データを用いて予測をゼロから継続的に再構築するというもので、固定された季節プロファイルを使用して微調整するのとは異なる ⁹³. 同社は、モデルが新たな実績データごとに自己修正し、カレンダーの変化などに自動的に対応すると主張している ⁹⁴. これは最先端の予測手法と完全に一致しており、RELEXなどが行っているローリングアップデート（プランナーがリセットする静的パラメータを持たない方式）と類似している。さらにブルー・ヨンダーは、不確実性の取り込みと過大・過少予測に伴うコストのトレードオフについても明確に言及している ⁹². 例えば、在庫切れリスクと過剰在庫リスクの理解、そしてそれらのトレードオフの意思決定が示唆され、これは予測とプランニングの連携における経済的最適化の考え方を意味している ⁹² ⁹⁵. 総じて、紙の上ではブルー・ヨンダーの予測能力は強力で現代的であるが、精度の中立的なベンチマーク（例えば、M5への公開参加など）が確認されておらず ⁹⁶、その優位性の主張を検証するのは困難である.
在庫＆補充： これは長年にわたるブルー・ヨンダーの得意分野である（JDAやi2の時代からの伝統技術）。同社は、リードタイムの変動、需要の不確実性、所望のサービスレベルなどを考慮し、流通ネットワーク全体における最適な在庫水準を決定する堅牢な多段階在庫最適化（MEIO）を提供している ⁹⁷. ブルー・ヨンダーのツールは、推奨される注文数量、安全在庫レベル、補充スケジュールを算出することができる。これらのアルゴリズムは、かつてはルールベースとOR（オペレーションズリサーチ）モデルの組み合わせで構成されており、例えば、ヒューリスティックや線形計画法のソルバーを用いて在庫を配分していた。今日では、機械学習を利用した需要予測をそれらの計算に組み込むことが多いが、コアとなる論理（在庫配置の最適化など）は実績のあるOR手法に依拠している。ブルー・ヨンダーは確かに大規模プランニングに対応可能であり、多くの大手小売業者（Fortune 500企業）が店舗補充目的でJDAを使用していることは、大規模なeコマース流通センターのプランニングにも類似している。ブルー・ヨンダーの在庫最適化能力は堅実であるが、必ずしも独自のものではなく、ToolsGroupやSAPなど他社も同様のMEIOを有している。重要なのは、これが他の要素（需要および価格）とどの程度連携するかである.
品揃え＆マーチャンダイジング： ブルー・ヨンダーはカテゴリーマネジメントおよび品揃え計画ツールを備えており、どの製品をどの店舗やオンラインカテゴリーに配置すべきかを判断する支援を行う ⁹⁸. 同社は、製品のパフォーマンス、属性、地域ごとの嗜好を分析し、品揃えに関する意思決定を導く。eコマースにおいては、「品揃え計画」とは、どのSKUを保持または廃止するか、あるいは新商品をどのように導入するかという決定を意味する場合がある。ブルー・ヨンダーのソリューションは、属性および販売データを活用して新商品のパフォーマンスを予測することができる（おそらく旧i2の「類似商品」予測を用いる可能性もある）。通常、品揃え計画は連続的ではなく、定期的（季節ごとのリセットなど）に行われるものである。ブルー・ヨンダーはこれにも対応しているが、これはマーチャンダイジングチームが時折使用するモジュールであり、日常的な業務ではない。存在自体は重要だが、我々が「AI最適化」としてより注目するのは、日々の価格および在庫管理の決定である.
価格最適化： Revionicsの買収により、ブルー・ヨンダーは業界をリードする価格決定エンジンを手に入れた。Revionicsは、多くのスーパーマーケットや総合小売業者などで、日常の基本価格、プロモーション割引、値下げの設定に使用されている。AIを活用して価格弾力性（価格変更が需要に与える影響）を推定し、競合他社の価格データも一部取り込むことができる ⁹⁹ ¹⁸. そのツールは、マージン改善や売上成長などの目標を達成するため、価格変更を推奨しつつ、（価格の末尾、既知の競合との差などの）制約を遵守する。現在はLuminate Pricingとしてブランド展開され、このエンジンは非常に洗練されており、理論上は需要予測と連携して閉ループを形成する。例えば、「価格を10%下げれば、予測需要が20%上昇し、在庫が対応可能／不可能になる」といったシミュレーションが可能である。ブルー・ヨンダーはこれを、必要に応じて（eコマースでは日内でも）実行可能な**「AIによって駆動される自律的価格設定」**として市場に打ち出している ¹⁰⁰. Revionicsが長年にわたり価格アルゴリズムの洗練を重ねてきた専門家であったことを考えると、これはブルー・ヨンダーの武器の中でも強力なコンポーネントの一つである.

最大の疑問は、**これらの各要素が実際にどれほどうまく連携しているか？**という点である。ブルー・ヨンダー側は「十分に連携している」と主張する―それがLuminate Platformの売り文句である。しかし、我々の調査によれば、もし企業がこれらすべてのモジュールを展開した場合、真にクローズドループの最適プロセスを実現するためには、多くの統合作業とプロセス調整が必要となる ¹⁰¹. 例えば、価格システムが毎週新たに価格ファイルを生成し、それを誰かが次回実施のために需要予測システムに取り込み、最終的に在庫計画が更新される、といった流れである。これは共同プランニングではあるが、完全に統一された即時の最適化ではない。バッチ処理および逐次処理（価格実行、その後供給実行）となる可能性が高い。ほぼリアルタイムな連携を実現するのが新しいSnowflakeデータモデルの狙いだが、全ての要素がその新アーキテクチャ上に移行していなければ（現状ではごく一部の顧客のみ）、実際は従来型の運用に近い。つまり、ブルー・ヨンダーは共同最適化に必要な全機能を備えているものの、多くの場合、ユーザー自身が統合者となる必要がある。これは、最初から一体化して最適化を実現しているベンダーよりも一段階劣るアプローチである.

AI/MLの実体対ハイプ： ブルー・ヨンダーのマーケティングは、時に「コグニティブ」「自律的」「AI/ML駆動」などのバズワードの寄せ集めのように感じられる ¹⁰². 我々は、その背後にある実体を求めている。実際、ブルー・ヨンダーの歴史には本物のデータサイエンスが息づいており、例えば、ドイツのブルー・ヨンダーチームは2014年の小売需要予測コンペティションで優勝を果たしている ¹⁰³。また、同社は400以上の特許を保有しており（少なくとも多大な研究開発が行われていることを示す） ¹⁰⁴. しかし、特許の数がそのまま実際の製品品質を保証するわけではない。懐疑的な立場としては、具体的な成果を求めるべきである：ブルー・ヨンダーは公にベンチマーク（M5等）を実施したことがあるのか？その公開記録はない ¹⁰⁵. また、具体的な数値を提示した事例研究を発表しているのか？事例研究は存在するが、他のベンダー同様、都合の良い事例だけが選ばれ、文脈が欠けている（例：「小売業者Xは我々の価格設定により5%の利益増を実現した」―どの基準と比較しているのか？） ¹⁰⁶. したがって、ブルー・ヨンダーが間違いなく優秀なデータサイエンティストを抱え、内部で非常に先進的なアルゴリズムを運用しているとしても、評価者は主に彼らの言葉および二次情報に頼らざるを得ない。注意すべきは、コストと複雑性がいかに華麗なAIの実力を相殺し得るかという点である.

コスト＆複雑性： ブルー・ヨンダーのソリューションはエンタープライズグレードであるため、高価で導入に時間がかかる。フルスケールのブルー・ヨンダー展開には数ヶ月から数年を要し、しばしば大量のコンサルタント（ブルー・ヨンダー側または認定パートナー）が必要となる。ソフトウェアライセンスに加え、サービス、ハードウェア／クラウドのコストも重なり、総所有コストは非常に高額になる。中規模のeコマース企業にとっては、ブルー・ヨンダーは過剰であるか、単に予算オーバーとなりかねない。大企業でさえもつまずいた例があり、ブルー・ヨンダー以外の代表例として、2018年にキャンセルされた5億ユーロ規模のSAPプロジェクトによるLidlの失敗が挙げられる ¹⁰⁷―これは、メガプロジェクトが如何にして崩壊し、多額の資金を消費するかを示している。ブルー・ヨンダーのプロジェクトは通常それほど大規模ではないが、依然として大きな試みである。あるパートナーのコメントによれば、競合のManhattan Associatesはプラットフォームをゼロから再構築する（その結果、顧客に再実装が必要となる）ことを決断したのに対し、ブルー・ヨンダーはより穏やかな進化路線を採っている ¹⁰⁸. どちらのアプローチにもコストは伴う：Manhattanの方法は、新技術採用の際に基本的にゼロから始める必要があり（初期負担が大きい）、一方、ブルー・ヨンダーの方法は、現状やや旧式の技術に依存しつつ新機能の到来を待つ（痛みが時間に分散される）というものである。いずれにせよ、顧客はアップグレードの際の複雑性に直面する。このため、ブルー・ヨンダーがレガシーであっても、新興のSaaSベンダーを検討する企業が現れるのは、より迅速または低コストな展開が魅力的だからである。要するに、ブルー・ヨンダーを評価する際には必要な大規模な労力を考慮すべきであり、それは迅速なクラウド契約ではなく、しばしば大規模な変革プロジェクトとなる.

自動化の現実： ブルー・ヨンダーは「自律的サプライチェーン」について語っており、特に2021年にパナソニックに買収されて以降、IoTデータを自動化された意思決定に結びつけるといった取り組みを強調している ¹⁰⁹. しかし、我々の評価では、ほとんどのブルー・ヨンダー顧客は依然として従来型の運用を続けている―すなわち、ソフトウェアは推奨を提示するが、その後の判断は人間が行っている。つまり、プランナーはブルー・ヨンダーのツールを使って（注文数量、配分、価格などの）推奨を受け取るが、その後それらを承認または調整する。これはRELEXの典型的な利用法と類似しており、ある程度の自動化は実現されるが、最終判断には人間の監督が入る。場合によっては、特定部分（例えば、一定上限までの自動補充注文）が自動実行されることもあるが、多くの大企業における文化やプロセスからすると、しばらくの間はハイブリッドな運用となる。すなわち、ブルー・ヨンダーの技術は多くを自動化できるとしても、実際にはシステムがプランナーを補助する形で実装され、完全に置き換えるものではない。時間が経つにつれて信頼が向上したり、ブルー・ヨンダーがリアルタイム機能を改善したりすれば状況が変わるかもしれないが、初日から完全な自律サプライチェーンを期待してブルー・ヨンダーを購入するのは誤りである。これはむしろ旅路であり、例外設定や慣熟度に応じて、システムに任せる決定の割合を徐々に増やしていくことになる.

競合インテリジェンス＆マルチチャネル： 良い点の一つは、ブルー・ヨンダーの価格設定（Revionics）が競合他社の価格データを明示的に取り扱っていることである。もし競合他社の価格フィードがあれば、システムは「競合Xより5%以上高く設定しない」といったルールや、競合間の価格差を考慮した弾力性モデルを組み込むことができる ¹⁸ ¹⁰⁹. これは、価格の透明性が高いeコマースにとって非常に価値がある。すべてのサプライチェーンツールが競合価格を考慮しているわけではないため、ブルー・ヨンダーの価格ソリューションはその点で優位性を持つ。マーケットプレイス（Amazon/eBay）あるいはマルチチャネルに関しては、ブルー・ヨンダーは特にマーケットプレイス管理（例：広告入札やバイボックス最適化―これらは同社の範疇外）を提供していない。したがって、コアな在庫管理や価格設定にはブルー・ヨンダーを利用しつつも、チャネル特有の戦略には他のツールが必要となる場合がある。これは珍しいことではなく、他の大手ベンダーも同様に対応していない（LokadやRELEXもAmazon広告の最適化は行っていない）。もちろん、ブルー・ヨンダーはプランニングのためにチャネル間の需要を集約することが可能であり、これは標準的な機能である.

我々が注視する点の一つは、メッセージングにおける内部矛盾である。ブルー・ヨンダーのマーケティングは、長期的な戦略的力量と同時にリアルタイムの俊敏性を謳うことがあり、これが誤解を招く可能性がある。例えば、「リアルタイムパーソナライゼーションと価格設定」と言いつつ、プランニングシステムは（最近まで）ほとんどがバッチ処理（夜間、週次）で運用されていた ⁸⁶. 現在は、Snowflake統合によりほぼリアルタイムのデータ更新が可能になってきているが、批判的な視点からは、「価格は本当に継続的に再計算されているのか、それともオンデマンドでの再計算に留まっているのか？」「本当に『リアルタイム品揃え最適化』が必要なのか？」と問い直す必要がある（おそらく必要ない―通常は戦略的なもので、毎時行うものではない）。従って、ブルー・ヨンダーが各文脈で「リアルタイム」とは何を意味するのかを慎重に解釈すべきである。多くの場合、それはトリガーがあれば迅速に対応できるという意味であり、全ての決定が毎秒連続して再最適化されるという意味ではない ⁸⁷. この点を指摘することで、時折見受けられる過剰に誇大な表現に対する警戒を促す.

Snowflakeプラットフォームに関する懸念： 一見些細ながらも重要な点は、ブルー・ヨンダーが新プラットフォームにおいてSnowflakeを多用していることである。Snowflakeは第三者提供のデータウェアハウスであり、強力ではあるが、データ保存や計算に基づいて課金される。もしブルー・ヨンダーのアプリケーションが内部でSnowflake上で複雑なクエリを実行すれば、そのコストは契約内容にもよるが顧客に転嫁される可能性がある。プランニングシステムは計算集約的になりがちで、膨大なデータ処理を要する。最適化されなければ、高額なSnowflakeの請求が発生する恐れがある。ブルー・ヨンダーのパートナーであるJBF Consultingは、以前から「請求ショック」の可能性について警告しており、これは従来のメインフレーム請求方式（使用量が多いほど料金が大幅に上がる方式）に例えられる ¹¹⁰. 要は、ブルー・ヨンダーの新体制で多数のシナリオや非常に大規模なプランを実行すれば、意図せずしてSnowflakeのクレジットが急速に消費される可能性がある ¹¹¹. ブルー・ヨンダー側はこれを緩和するため、最適化や交渉を実施することが予想されるが、ユーザーはその動向を注視すべきである。これは「クラウド」が必ずしも安価であるとは限らず、アーキテクチャの選択が重要であることを浮き彫りにしている。先に述べたように、Lokadのアプローチはまさにこの理由で高額なレイヤーへのコスト転嫁を避けたが、ブルー・ヨンダーはSnowflakeを活用することで柔軟性を得る一方、潜在的なコスト増加のリスクも伴う。これは使用パターンに依存する.

ブルーヨンダーの総合評価： 当社は、AI最適化ビジョンの実現においてブルーヨンダーを、より専門的な「ニュージェン」ソリューションよりもやや下と評価していますが、それでもなお強力な存在です。　ブルーヨンダーは非常に豊富な機能を備えており、数十年にわたるノウハウがツールに組み込まれ、大企業での多くの成功事例があります。しかし、懐疑的な技術的観点から見ると、ブルーヨンダーは変革の途中にあるベンダーと言えます。彼らはAI、統合、オートメーションについて口先だけで語りますが、その多くは将来志向またはマーケティング主導であり、現実の顧客にとっては、サイロが徐々に統合され、機能が近代化されるという、より平凡な状況です。「信じてください、変革が完了すれば数年後には素晴らしくなります」というニュアンスも含まれています。既にブルーヨンダーに投資している場合はそれで問題かもしれませんが、新規購入者は、より新しいソリューションがそのタイムラインを飛び越えられるのか疑問を抱くかもしれません。ブルーヨンダーのプラットフォームは、大規模なeコマース運営をサポートできる（多くの大手オムニチャネル小売業者が利用している）ため、機能面での問題はありません。問題は効率性と俊敏性にあり、迅速なROIを提供するのか、それとも実装と調整に2年を要するのか、また各モジュールが真に一体となって動作するのか、あるいはチームが最終的に出力結果を手作業で組み合わせる羽目になるのか、という点です。要するに、ブルーヨンダーは強力ではあるものの重厚なシステムであり、最先端を維持するために自己革新の過程にあります。その革新が完全に実現され、証明されるまでは、潜在的な利用者は統合のギャップ、技術的負債、そしてセールススライドで描かれる華やかな成果を達成するための労力について注意深く検討する必要があります。ブルーヨンダーのビジョンは魅力的ですが、懐疑的な立場としては、その実行が約束に追いつくかどうかを注視し続けます。

出典: ブルーヨンダーの統合戦略やSnowflakeによるプラットフォーム刷新は、ブルーヨンダーの発表およびパートナーによる分析により記録されています ⁷⁶ ⁷⁷。統合に関する楽観論やコストについてのパートナー（JBF Consulting）からの警告が引用されています ⁷⁹ ¹⁶。過去の問題や訴訟の例は、ニュース報道（Dillard’s対i2）から引用されています ²³ ²⁴。需要予測におけるブルーヨンダーの機械学習活用や連続予測へのシフトは彼らのブログ記事に記されており ⁹⁰ ⁹³、Revionicsを通じた価格設定機能や競合他社の価格対応については製品説明から参照されています ⁹⁹ ¹⁸。リアルタイム対バッチ処理やマーケティング上の矛盾に関する議論は、ブルーヨンダー自身の幅広いマーケティング主張と既知の技術的制約の比較から導かれています ⁸⁶ ⁸⁷。また、ブルーヨンダーのAIおよび統合推進に対する批判的見解については、「Blue Yonder Review」分析にも依拠しています ⁸⁴ ¹⁰².

4. ToolsGroup – 確率的在庫管理の専門家、リテールAIへの拡大

ToolsGroupは、サプライチェーン計画のベテランであり、特に需要予測と在庫最適化で知られています。歴史的にはSO99+ (Service Optimizer 99+)と呼ばれたフラッグシップソフトウェアは、サービスレベルに基づく在庫計画とマルチエチェロン最適化の先導的なソリューションでした ¹¹² ¹¹³。率直に言えば、ToolsGroupは「不確実な状況下で各拠点で99%のサービスレベル（またはその他の目標）を達成するために必要な最小在庫は何か？」という問いに優れて答えることで、数多くのSKUを扱い、欠品を避けながら過剰在庫を防ぐ必要のある流通業者や製造業者の間で人気を博しました。特筆すべきは、ToolsGroupが2000年代頃に確率的予測と計画を実装した最初の商用ツールの一つであり、企業に対して単一の数値による予測から、可能な需要の全分布を活用する方向へと舵を切ることを提唱した点です ¹¹⁴ ¹¹⁵。このアプローチはかつては革新的でしたが、現在ではベストプラクティスとして認識され、他のベンダーも追随するようになりました。いろいろな面で、ToolsGroupは現在私たちが**「AI駆動」在庫最適化と呼ぶものの先駆者であったのです（当時はあまりAIという流行語を使っていなかったものの）。 eコマースやその他、品揃えが豊富で需要が断続的な複雑なビジネスにおいて、ToolsGroupの確率的モデリングの強みは非常に重要です。彼らは、時折販売される「ロングテール」商品の取り扱いを自然に行います。例えば、ほとんどの月で実際の販売が0で、ある月に10個売れる場合、毎月2個と予測するのではなく、需要の確率曲線を生成してその断続的な性質を捉えます ¹¹⁶。その後、最適化により、例えば補充前に在庫切れとなる確率が5%に留まるような在庫量を算出します。これは、販売速度の遅い多数の商品を扱うeコマース販売者にとって理想的です。ToolsGroupは、目標を達成するためだけに予測を過大にするのではなく、実際の変動性に見合った安全在庫を計画する仕組みを持っています。また、新製品予測の仕組み（類似商品のアナロジーや属性ベースのモデルを用いて新SKUを予測する）を備え、プロモーションや季節変動に応じて需要分布を調整する機能も提供しています ¹¹⁷. 歴史的に、ToolsGroupはサプライサイド、すなわち需要予測、安全在庫計算、補充計画に注力していました。価格設定や品揃えの最適化は提供していなかったのです。これらの要素が在庫計画を補完することを認識し、ToolsGroupは戦略的な一手として、2018〜2019年にJustEnoughという企業を買収しました ¹¹⁸ ¹¹⁹。JustEnoughは、商品財務計画、品揃え、割り当て、マークダウン価格設定のソリューションを備えた小売向けソフトウェアであり、小売業者が店舗への製品分配、店舗別の品揃え計画、ライフサイクル終了商品のマークダウン最適化を行うのに役立つことで知られていました。JustEnough（かつて小売ソフトウェア企業MI9の一部であった）を買収することで、ToolsGroupは純粋なサプライチェーン領域から、より広範な小売計画**分野へと事業を拡大しました。現在、彼らはSO99+エンジンとJustEnoughの機能を組み合わせた統合スイートを展開しており、**サプライチェーンおよび小売マーチャンダイジング ¹²⁰ ¹²¹**の双方において、上位計画から実行までをカバーすることを目指しています。

統合上の課題： ベンダーが2つの異なるプラットフォームを統合する際、統合自体が懸念事項となります。ToolsGroupは、SO99+とJustEnough由来のコンポーネントのデータモデルやワークフローを統一するために取り組んでいます。彼らは「戦術的および運用的計画のための同一のデータモデルを実現する」ことで、ひとつの正確な情報源を保証しようとしています ¹²²。例えば、JustEnoughの計画システムと「Inventory Hub」を連携させ、データがほぼリアルタイムで流れるようにする**「リアルタイムリテール」**というコンセプトを立ち上げました ¹²³。これは、販売が行われたり在庫状況が変化した際、その情報が迅速に計画エンジンへ供給され、再割り当てなどの迅速な対応を可能にすることを示唆しています。彼らは、これにより固定された定期バッチではなく、動的かつ連続的な計画が可能になると主張しています ¹²⁴。この考え方は、実行データと計画の境界を打破し、その場で計画を調整できるようにするという他のアプローチと共通しています。

しかし、ToolsGroupがマーケティングで謳う「リアルタイムリテール ― 現在の購買行動に即座に対応する唯一のソリューション」という表現は、やや誇張されている印象があります ¹²⁵。システムが頻繁に更新されるのは素晴らしいことですが、すべての意思決定が即座に行われるべき、あるいは行われることが可能というわけではありません。季節の中盤で在庫の再配置や予測の更新が頻繁に起こるのは確かですが、商品構成や財務計画を「その瞬間」に完全に再最適化するのは現実的ではなく、通常は十分な検討を経た上で、週単位または月単位で行われるものです。つまり、他のベンダーと同様に「リアルタイム」という概念は、在庫の再バランスや短期予測の調整など特定の層にのみ適用され、戦略全体の抜本的な見直しには当てはまらない可能性が高いのです。現在、すべてのベンダーが何らかの形で「リアルタイム」を謳っており、多くの場合、数分または数時間以内にデータと推奨事項を更新できることを意味していますが、これは通常十分な更新頻度と言えます。ToolsGroupのCEOは、需要の変動時にマージンの侵食を防ぐため、小売業者は迅速に方向転換すべきだと述べており ¹²⁶、それは事実であり、ほぼリアルタイムのデータがそれを支援しています ¹²⁷。重要なのは、ToolsGroupのシステムがそのデータに基づいて自動的に行動するのか、単にプランナーに警告するだけなのかという点です。彼らは「新たな情報が入ると即座に自動再計算し、注文または転送を推奨する」と示唆しています ¹²⁷。もし実際に機能するなら、それは非常に強力な仕組みとなるでしょう。例えば、オンライン販売が急激に増加した場合、システムは即座に、販売の鈍い店舗からeコマース用倉庫への在庫移動を提案する可能性があります。独立した形で、どの程度クライアントが完全に自動化できているかの確認は取れていませんが、ToolsGroupは明らかにその実現を目指しています。

JustEnough統合により、理想的なシナリオでは、ToolsGroupのユーザーはエンドツーエンドの計画を実現できます。すなわち、チャネルごとの品揃えミックスの計画、店舗への初期割り当て、SO99+エンジンを用いた在庫の補充および維持、そしてライフサイクル終了時の在庫整理のためのマークダウン最適化が可能です。共同最適化の側面は、これらの各要素が連携する場合に現れます。例えば、マークダウン計画ツールが、来月特定の商品が50%オフになると需要予測に伝えた場合、その商品の予測は引き上げられ、それに伴い推奨在庫レベルが変動します。ToolsGroupは、統一されたデータモデルがこのような連携（プロモーションやマークダウン計画が需要モデルに反映される）を可能にしていると示唆しています ¹²⁸ ¹²⁹。ただし、最適化は逐次的である可能性が高く、まずマークダウン戦略を決定し、その効果が在庫に現れるという流れであり、マークダウンと在庫を同時に一つのアルゴリズムで決定するわけではありません。それでも、サイロ化されたシステムから大きく前進していると言えるでしょう。これは、RELEXのアプローチに似ており、統合されたデータが一貫性を保証するものの、価格設定と供給を同時に最適化する単一の問題として解決しているわけではありません ¹³⁰.

最先端の基準： ToolsGroupは、確率的予測と不確実性の処理において明らかに光っています。数十年にわたり、単一の数値による予測では不十分であり、計画には変動性を十分に考慮すべきだと主張してきました ⁷。彼らのシステムは「期待値」だけでなく、全体の分布（例：P10、P50、P90の需要）を生成し、その分布を用いて所望のサービスレベルを達成する、または総コストを最小化する在庫目標を算出します ¹³¹。例えば、「予測が100なら、安全のために110を保持しよう」とする代わりに、「需要がX以下である確率が95%であるため、Xを在庫する」と言います ¹³¹。この方法は需要の不確実性を本質的に捉え、またToolsGroupはこれらの計算においてリードタイムの不確実性も考慮しています（例：リードタイムにばらつきがある場合、安全在庫が適宜調整される）。確率に基づく計画により、予期せぬ事態を自然に軽減し、欠品や極端な過剰在庫を防ぐことができます。また、彼らは確率的出力を他のシステムの改善に活用できる点も強調しており、例えばToolsGroupのリスク調整済み需要数値を**SAP APOのようなERPに入力して改善する ¹³²**といった提案もしています。実際、ToolsGroupはそのエンジンがより良い入力を提供することで、レガシーシステムの寿命を延ばすと提案したこともあり、これは彼らの主要な価値が華麗なUIではなく、数学的な部分にあることを示唆しています ¹³².

UIの話をすると、ToolsGroupは歴史的にやや実用的なインターフェースを持っていました。これは、プランナーやアナリストが数値を扱うためのバックエンドツールとして使用され、華麗なダッシュボードに重点を置いていなかったためです。近年では、ウェブベースのUIなどを追加して近代化が進められています ¹³³。しかし、主要なユーザー層は、UIが古くとも洗練されたエンジンを評価するサプライチェーンアナリストでした。今日では、作業負荷を軽減するために計画の自動化が強調され、ToolsGroupの資料では「組み込みの自動化により計画作業負荷が最大90%削減される」と主張されています ¹³⁴。また、システム使用後にプランナーの作業負荷が40–90%削減、在庫が20–30%削減されたといった顧客の成果が頻繁に引用されています。これらは大胆な数字ですが、慎重に解釈する必要があります。90%の作業負荷削減は、以前は10名のフルタイムプランナーがいた企業が、主に火消しや緊急対応に追われていた状態から、ToolsGroupによって混沌が平準化され、1名にまで減少したケースかもしれません ¹³⁵。しかし、それはおそらく例外的なケースです。20–30%の在庫削減は、企業がもともと大量の余剰在庫を抱えていたことを意味する場合が多く、通常は完全に非効率でなかった企業では10–15%程度の改善が一般的でしょう ¹³⁶。それでも、ToolsGroupがこれらの幅を提示しているという事実は、ルーチンな需要予測および補充業務の大部分を自動化し、プランナーをエラー対応から解放することを目指している証拠です。確率的アプローチは、最初から不確実性を考慮することで、緊急事態の発生を減少させ、最終的な突発的対応や手動での再配置を軽減するはずです ¹³⁷。ただし、マーケティングは常に最良のシナリオを強調する傾向があるため、注意が必要です。少なくとも、40–90%の作業負荷削減という範囲で提示している点は、クライアントによって結果が大きく異なることを示唆しています ¹³⁵.

ToolsGroupは1993年に創業した長い歴史を背景に、**安定性と深い専門知識 ¹³⁸**を有しています。Blue Yonderほどの規模や、一部のAIスタートアップほどの注目は集めていないものの、忠実な顧客基盤と強力なアルゴリズムによる評価を得ています。彼らの顧客は製造業、流通業、アフターマーケット部品、そして一部の小売業に及び、在庫（欠品でも過剰在庫でもない）を主な懸念とするeコマース企業にとって、ToolsGroupは非常に成熟したソリューションです。複数のフルフィルメントセンターやグローバルネットワークを持つ場合、そのマルチエチェロン機能は各拠点のみならずネットワーク全体（例：地域倉庫と中央倉庫の在庫量のバランス）の最適化に有用で、必要な場所へ在庫を供給しつつ総在庫量を低く保つことが可能です.

弱点: ToolsGroup にとって最大の課題は プライシング最適化 です。JustEnough の買収により markdown 最適化（これは価格設定ですが、消費期限切れや在庫一掃のシナリオに限定される）が導入されました ¹³⁹ ¹⁴⁰. これは、陳腐化した在庫を体系的に処分する必要がある季節商品やファッションeコマースに有用です。しかし、ToolsGroup は Blue Yonder の Revionics や専門のプライシングベンダーに匹敵する、堅牢な日常的な動的価格設定機能をまだ持っていません。基本的な価格弾力性の分析を行うか、またはパートナーに依存している可能性があります。もしクライアントの優先事項が日々の販売価格（利益率や競争上の理由による）の最適化であるなら、ToolsGroup は最強の選択肢とは言えません。彼らのDNAは供給計画に重きを置いており、「価格が既定されている前提で、いかに需要を効率的に満たすか」という考えに基づいています。彼らは markdown やプロモーション計画の部分で需要形成に取り組み始めていますが、通常の価格設定に対する完全な最適化は彼らの得意分野ではありません ¹⁴¹. つまり統合最適化の観点では、ToolsGroup は価格が与えられた場合の在庫最適化は可能ですが、利益を最大化する最適な価格を示すことはできません（例外として markdown 提案の場合を除く）。これは重要な差異です：ToolsGroup の最適化は主に供給志向（在庫水準、補充）であり、Blue Yonder や RELEX のようなベンダーは、需要志向のアクション（価格変更、プロモーション戦略）を提案するためのプライシングエンジンに投資しています ¹⁴¹ ¹⁴². 一部の企業にとっては問題ないかもしれません—別のツールを用いて価格設定を行うか、戦略に基づいて価格を設定するでしょう—しかし、これは ToolsGroup が統合最適化の聖杯の一部を欠いていることを意味します。

テクノロジースタック: ToolsGroup は現在、クラウドSaaS版を提供しており、イメージの刷新のために “Inventory Hub” や “Fulfill.io” のような名称にリブランディングしています。内部では、多大な計算処理は多年にわたって洗練された高度に最適化された C++ やそれに類するコードに依存している可能性が高いです。ToolsGroup のパフォーマンスに対する苦情はなく、数百万の SKU-ロケーション組み合わせを持つクライアントも処理しています。むしろ、ToolsGroup のアキレス腱は、熟練した設定が必要な「オプティマイザーのツール」として認識されている点かもしれません ¹⁴³ ¹⁴⁴. 彼らは、需要センシング（最新トレンドを反映した短期予測の調整）や、需要を喚起する要因の自動特定といった、より多くの即戦力機械学習（ML）を追加しています ¹⁴⁴ ¹⁴⁵. 例えば、どの変数（価格、天候、プロモーション）が予測に最も影響しているかを示すために、特徴量の重要度アルゴリズムを実行する場合があります ¹⁴⁶. さらに、確率的予測が人間の判断を取り入れられないという神話に対して、プランナーが上書き入力でき、システムがそれを適切に扱う（そのプランナーの歴史的バイアスを考慮して）ことをブログで明確に説明しています ¹⁴⁷. これはバランスの取れたアプローチを反映しており、ToolsGroup は人間を完全に排除しようとしているのではなく、洗練されたエンジンを提供し、人間の入力も許容する一方で、数学的手法によりその入力が統計的整合性を崩さないように保証しています（例えば、プランナーが常に過大評価する場合、システムはそのバイアスを学習します） ¹⁴⁵ ¹⁴⁷.

ToolsGroup はある程度、カニバリゼーションおよびマルチチャネルに対応できます。構成次第では、彼らの確率モデルは関連製品をも考慮することができ（代替グループを定義するか、ML を用いて関連製品をクラスタリングする必要があるでしょう） ¹⁴⁸. 完全に自動ではありませんが、例えば製品 A が品切れとなった場合に一部の需要が製品 B に流れるといったシナリオをモデル化する能力を持っています ¹⁴⁸. 彼らはマルチチャネル計画（複数の流れから需要を集約すること）の課題について論じ、従来の単一数値予測がそのようなシナリオでは崩れることを指摘しました ¹⁴⁹. 例えば、ToolsGroup のソリューションは全チャネルからの総需要予測を生成し、必要に応じてチャネル別の在庫配分も支援できます ¹⁵⁰. 多くのeコマース事業者はマーケットプレイスで販売したり、複数のサイトを運営しているため、ToolsGroup はグローバルに計画を立てた後、最適に在庫を配分することを勧めるでしょう（例えば、Amazon が実際により多くの需要を牽引している場合に、自社サイトに全在庫を割り当てないようにシステムが保証するなど）。チャネル配分はしばしばより単純なビジネスルールで対応可能ですが、彼らのアプローチは確率論を活用することで、自然に予測の統合や分割ができる形でマルチチャネルをサポートしているのは大きな強みです ¹⁵⁰.

ユーザー体験は、買収後の注目点です。RELEX（自社内で一体化されたプラットフォーム）は、個別であった ToolsGroup+JustEnough よりも統一感があるように感じられるかもしれません。ToolsGroup はおそらく UI をシームレスに再構築していますが、例えば在庫モジュールと品揃えモジュールの間に違いを感じるユーザーもいるかもしれません ¹⁵¹ ¹⁵². 新たに統合されたプラットフォームに対するユーザー評価はまだ見られていませんが、潜在的な摩擦の要因となり得ます。彼らは間違いなくプロモーション計画と予測を統合しており（プロモーション効果が予測に反映される） ¹⁵³ ¹⁵⁴、これは必須です。懐疑的な私たちの立場としては、将来の利用者には完全なワークフロー（例：プロモーションの計画から在庫計画の調整を見るまで）のデモを依頼し、統合が宣伝されている通りスムーズであるかを確認することを推奨します。

実績: ToolsGroup には、在庫削減およびサービスレベル改善に焦点を当てた多くのケーススタディがあり、これが彼らの得意分野です。大手企業のようなスキャンダラスな失敗は公に見られておらず、それは彼らが小規模でプロジェクトを綿密に管理しているためかもしれません。旧来の JustEnough の顧客も引き継がれており、非常に大規模な小売業者向けの JustEnough のスケーラビリティはおそらく限定的だった（中堅市場向けであったため）、そのため ToolsGroup はその部分を強化する必要があったのでしょう ¹⁵³ ¹⁵⁵. トップティアの小売業者であれば、品揃えや計画部分が自社のデータ規模に対応しているかを確認することが重要です。ToolsGroup の計算能力の強さは信頼を与えますが、小売関連部分の統合には再エンジニアリングが必要だった可能性があります。

結論として、ToolsGroup は先進的な数学を用いて在庫およびサービスレベルを最適化し、小売計画機能も強化した企業にとって、非常に信頼性の高い選択肢です。彼らは長年にわたる確率モデルと実証済みの最適化エンジンの活用により、技術的アプローチのリーダーの一角として位置付けられます。彼らは多くの基準を満たしています：不確実性モデリング（優れている）、経済的最適化（本来、サービスとコストのトレードオフを最適化するという経済的目的を持つ）、スケーラビリティ（概ね良好で、数百万の SKU-ロケーションを処理可能）、そして増大する自動化（クライアントは手動計画を大幅に削減していることが多い）です。しかし、統合最適化のプライシング面では若干不足しており、もしビジネスの中心にダイナミックプライシングがある場合、ToolsGroup 自体は日々の価格を最適化しないため、追加のソリューションや戦略が必要になるかもしれません ¹³⁹ ¹⁴¹. また、やや小規模なベンダーであるため、ToolsGroup は大手企業のような広範なエコシステムや実装チームを持っていない可能性がありますが、それはエキスパートからのより直接的な対応を意味するという点でプラスとなる場合もあります。私たちの懐疑的な見解では、ToolsGroup はマーケティングにおいてはあまり派手ではないものの、実際には「AI サプライチェーン」の多くの先駆け、すなわち確率的予測や自動化の面でパイオニアであったと考えられています ¹¹⁴ ¹¹⁵。しかし、流行する前からそれらの技術を実践していたため、「AI」としては常に認識されてこなかったのです。現在、彼らはバズワードを取り入れているに過ぎず、本質的にはモダンな見た目を加えた堅実なエンジンであるということを忘れてはなりません。企業はバズワードに惑わされず、その実質を評価すべきであり、ToolsGroup の場合、その実質はサプライチェーンの数理において強みを発揮しつつ、より広範な小売計画機能をどれだけ上手く統合できるかが新たな課題となっています。

参考文献: ToolsGroup の歴史的な焦点および確率的アプローチは、彼らの文献や第三者による分析で記述されています ¹¹² ¹¹⁴. JustEnough の統合およびリアルタイム小売に関する主張は ToolsGroup の発表に基づいています ¹¹⁸ ¹²³. 我々は作業負荷や在庫削減に関する ToolsGroup 自身の主張を引用しています ¹³⁴ ¹³⁵が、それらが最良のケースであるという点には懐疑的であることも指摘しています ¹³⁶. 日常的な価格最適化能力の欠如は、業界の知見およびこの領域における ToolsGroup の提供内容（またはその欠如）から浮き彫りにされています ¹³⁹ ¹⁴¹. マルチチャネルおよびカニバリゼーションへの対応は、ToolsGroup のブログや資料で参照されています ¹⁴⁸ ¹⁵⁰. さらに、「レガシーベンダー」が買収に依存しているという言及（Logility/Garvis、Kinaxis/Rubikloud）など、ToolsGroup 自身の買収統合の課題と対比するための独立した文脈も使用されています ¹⁵⁶. ユーザー体験の統合に関する指摘は、プラットフォームの性質や利用可能なコメント（例：ToolsGroup の統一データモデルに関する声明 ¹²²）から推測されます。

5. o9 Solutions – 高い野心を持つ統合計画「デジタルブレイン」

o9 Solutions は、2009年に設立された新参企業であり、急速に注目を集め、統合ビジネスプランニングのための次世代「デジタルブレイン」として自らを位置付けています。o9 のプラットフォームは、企業全体の統一データモデル、すなわちEnterprise Knowledge Graphの概念に基づいて構築され、先進的な分析と AI を組み合わせることで、需要計画、供給計画、SNOP/IBP（販売＆オペレーション計画）、さらには収益管理における意思決定を支援します。より簡単に言えば、o9 は全ての計画機能（予測、サプライチェーン、商業、財務）が AI アルゴリズムとリアルタイムデータ統合によって一体となる単一プラットフォームを目指しています ¹⁴⁶ ¹⁵⁷.

統合された範囲: o9 は需要予測、調達から生産、流通に至るサプライチェーン計画、さらに 価格とプロモーション計画 など、幅広い分野をカバーしています ¹⁵⁸ ¹⁵⁹. 彼らは「統合ビジネスプランニング（IBP）」を積極的に打ち出しており、これは o9 上で需要、供給、財務計画がすべて同期していることを意味します ¹⁶⁰. これは、サプライチェーン内部だけでなく、サプライチェーンと商業計画の間のサイロを打破するという流れに沿ったものです。例えば、営業チームがプロモーションを計画すれば、o9 の供給計画が即座にその情報を反映し、供給側に制約があれば、財務計画にその影響が現れます。これは多くの大企業が目指す包括的なアプローチです.

統合最適化、特に価格最適化に関して、o9 は 価格最適化ツール を提供しています。彼らは、弾力性モデル や外部要因のスコアカードを用いて需要計画と統合し、最適な価格変更のタイミングを見出すと述べています ¹⁵⁸. また、過去のプロモーション実績を分析し、将来のキャンペーンを計画するためのプロモーション最適化機能も備えています。専業のプライシングベンダーではありませんが、o9 には価格を通じて需要を調整し、その結果を供給の意思決定にフィードバックするための要素が揃っています。おそらく、日々の価格変更では Revionics のような細かさはなく（例えば、価格戦略のシナリオプランニング程度の高レベルなアプローチ）、全体的な計画の文脈においてプロモーションと価格設定をカバーしています。したがって、歴史的に価格分野に何も持たなかった Kinaxis とは異なり、o9 は収益面への対応もある程度果たしており、これは統合最適化の評価基準においてプラスです.

AI と分析: o9 は自らを AI搭載 プラットフォームと位置付けています。内部には、さまざまな分析手法が組み込まれています:

予測分析: 需要および供給の統計的予測と機械学習モデル ¹⁴⁶.
指示的最適化: 計画シナリオのための最適化エンジン（おそらく線形/整数計画ソルバー等）を備えています ¹⁵⁷.
シミュレーション & シナリオプランニング: ユーザーが様々な供給/需要シナリオを容易にシミュレーションできる、内蔵のワットイフ分析 ¹⁶¹.
生成AIとNLP: 最近、o9 は生成AI（ChatGPT のようなもの）を活用し、自然言語でのプラン問い合わせや、洞察の自動生成などを行っている点を強調しています ¹⁶². これはコアの数理ではなく、ユーザー体験向上のための新たなトレンドです.
オープンアーキテクチャ: o9 は R/Python ライブラリとの統合を可能にしており ¹⁶³、必要に応じてデータサイエンティストがカスタムアルゴリズムを組み込むことができます。このオープン性は、プラットフォームの AI を拡張したい上級ユーザーにとって魅力的です.

これらの機能は、o9 の AI が単なる付随的な層ではなく、しっかりと組み込まれていることを示唆しています。彼らは AI/ML を「後付け」のものではなく、分析エンジンの不可欠な構成要素として提示しています ¹⁶⁴. 例えば、o9 は需要センシングに機械学習を用いる可能性があり（RELEX に類似して最新データで短期予測を調整する）、また、企業の「デジタルツイン」を強調し、その上で最適化を実行して指示的な提言を行います ¹⁶⁵ ¹⁵⁷. つまり、o9 のモデルは実際のサプライチェーン（能力、制約など）を忠実に再現しており、その結果を正確にシミュレーションし、例えば、ある工場が稼働停止した場合に別の工場への生産振替や在庫の再調整といったアクションを提案できるのです.

テクニカルスタック: o9 は、Microsoft Azure 上で展開されることが多い、最新のクラウドベースソリューションとして構築されています。彼らは以下の点を強調しています:

統合ビジネスプランニング言語（IBPL） – o9 独自のスクリプト環境で、モデルやレポートを構築するために使用されます ¹⁶⁶. これは、Lokad の Envision や AIMMS のモデリング言語に類似しており、標準設定を超えたカスタマイズを可能にします.
ビッグデータ & インメモリ処理: 彼らは様々な技術を組み合わせており、Hadoop やインメモリ技術の利用が、大規模データを分散ストレージと高速メモリアクセスの組み合わせで処理しようとしていることを示しています ¹⁶⁷. おそらく、基礎データを Hadoop（または類似の分散ファイルシステム）に格納し、迅速な計算のために必要な部分をメモリに読み込むのでしょう.
グラフデータベース: Forbes は、o9 がグラフデータベースの概念を活用していると指摘しており ¹⁶⁸、これは彼らの「ナレッジグラフ」アプローチと一致します。すなわち、製品、顧客、サプライヤーといったエンティティおよびその関係をグラフで表現し、ネットワーク内での混乱の伝播を検出するなど、一部のクエリにおいて強力です ¹⁶⁹.
API と統合: 彼らは ERP や他のシステムと接続するためのオープンAPIを備えており、統合が鍵であることを認識しています ¹⁷⁰.

技術的には、o9 は非常にクラウドネイティブでスケール向けに構築されています。大量の予測データ、サプライチェーンモデルなどを、メモリと分散コンピュートの組み合わせで処理することが期待されます。しかし、各クライアントごとに（例えば、サプライチェーンのデジタルツインモデルの構築など）かなりの設定作業が依然として必要となる可能性があります。独自のスクリプト言語が存在するということは、上級クライアントが深くカスタマイズできる一方で、完全なオフ・ザ・シェルフ製品ではなく、ある程度のモデリング作業が必要であることも意味します（これは Lokad の哲学によく似ていますが、o9 は大企業向けの標準プロセスにも対応するため、より多くの事前構築済みテンプレートも備えています）.

Independent Validation: o9は急速な成長を遂げ、注目の高いクライアントを獲得しています（例：2025年にトヨタとの契約を発表 ¹⁷¹）。独立系の記事ではo9の革新性が強調されており、たとえばa Dallas Innovatesの記事では彼らの「デジタルブレイン」と、それがどのようにサイロを打破するかが論じられています ¹⁷²。Forbesは、グラフDBの使用や先進的な最適化といった技術的な差別化を強調しました ¹⁶⁹。これらは、o9が単なるマーケティングに留まらず、実際のイノベーションで注目を浴びているという信頼性を高めています。さらに、彼らはHCLのような大手SI（システムインテグレーター）や、Microsoftのようなテック企業と提携しており、プラットフォームへの信頼が感じられます ¹⁷³.

懐疑的な見方 – 課題点: o9のビジョンは魅力的ですが、いくつかの点で注意が必要です:

流行語の乱用: o9は「セルフドライビングサプライチェーン」、「デジタルツイン」、「ナレッジグラフ」、「ジェネレーティブAI」などの用語を多用しています。これらの概念の一部は実際に製品に組み込まれているものの、基本をかえって見えにくくする可能性があります。たとえば、多くのベンダーがシナリオプランニングを行い、それをデジタルツインと呼んでいますが、o9が流行に乗せた名称を使ったからといって自動的に優れているわけではありません。重要なのは、これらのアイデアをクライアントに対してどれだけ効果的に実装できるかであり、単に言及するだけでは不十分です.
統合の複雑さ: 大企業の統一されたデジタルモデルを構築するのは困難です。多数のデータソース（ERP、CRM、MESなど）に接続し、データをクレンジングしてo9の構造にマッピングする必要があります。データの品質が悪かったりサイロ化していたりすると、o9のプロジェクトは苦戦する可能性があります。ある分析では、プラットフォームの成功は「データの質、シームレスな統合…、そしてユーザーの採用」にかかっていると述べられています ¹⁶⁹。これはすべてのプランニングソフトウェアに当てはまりますが、o9の幅広い範囲は多くのシステムに影響を与えるため、統合作業が増えるという問題があります。ユーザーの中には、計画のすべての側面を一度にデジタル化することに圧倒されるかもしれません.
ユーザーの採用: もし企業文化が計画プロセスを分離している場合、o9のような一つのプラットフォームへ移行することは大きな変化となります。ツール自体は優れていても、たとえば財務部門がサプライチェーンに依存した予測を信用しなければ、抵抗が起こる可能性があります。o9が唯一の真実の情報源となるためには、組織全体の整合が必要であり、これは容易なことではありません（これはo9の技術的欠陥ではなく、現実的な障壁です）.
実績のあるROI: o9には事例研究があり、急成長を遂げていることから、価値を提供していることが示唆されます。しかし、比較的新しい製品であるため、長期的な効果に関する公開データは限られています。あるクライアントは絶賛する一方、他のクライアントは複雑だと感じるかもしれません。問題は、その成果（サービスの改善、在庫削減など）が従来の手法を明確に上回っているかどうかです。大手企業ではレガシーシステムやExcel/手動のプロセスに取って代わることが多いため、相当の改善が期待されるものの、各環境には固有の事情があります.

本研究の他の製品と比べると、o9のフォーカスはやや広範であり（サプライチェーンだけでなく全体的なIBPも対象としています）、特に在庫と価格の共同最適化に関しては、両方のモジュールを有しているため要件を満たしています。しかし、価格最適化の深さはLokadやBlue Yonderほどではないかもしれません。むしろシナリオ分析（例：「異なる価格帯で需要がどのように変動するか」）に依存し、その後プランナーが判断するという方針であり、自動的に最適価格を日々算出するものではありません。MicrosoftのApp Sourceで「PriceAI」と言及され、市場データや目標に基づいて価格が調整されることから ¹⁷⁴、少なくとも自動化された動的価格設定機能は備えていることが示唆されます。もしそうであれば、例えばEコマースサイト向けに、ルールや競合他社のデータを考慮して無人で価格を最適化できる可能性があります。直接的なユーザーフィードバックはないものの、o9の価格設定はまずまずだと慎重に楽観視していますが、主要な差別化要因としては強調されていません.

o9が特に優れているのはシナリオプランニングと部門横断の調整です。ユーザーは「もしこのカテゴリの価格を5%上げ、主要なサプライヤーが2週間遅れるとどうなるか？収益や在庫にどのような影響があるか？」といった仮説シナリオを試すことができ、o9はその影響の連鎖全体をシミュレーションします。これは意思決定にとって強力ですが、その洞察を正しく解釈し活用するためには熟練したユーザーが必要です。システムは純粋な自動化ではなく、ヒューマン・イン・ザ・ループモデル（システムが洞察を生成し、人間が意思決定を行う）に近いものです。しかし、より自動化された推奨に向けて進化しています。マーケティングでは、自らを「ディシジョンマネジメント」または「ディシジョンインテリジェンス」システムと称し、日常的な意思決定の自動化も目指しています.

現在の市場における立ち位置: o9は、IDCやGartnerなどのアナリストレポートでリーダーまたはビジョナリーとして位置付けられることが多く、その最新技術と急速な成長が評価されています。報告によれば、2024年にはサブスクリプション収益が37%成長したとのことで、その勢いは顕著です ¹⁷⁵。また、トヨタの例や他のFortune 500企業といった注目すべき実績もあります。これにより、実際のところ大企業はo9をSAPやKinaxisといった既存システムに代わる有力な選択肢と見なしていることが示唆されます.

ただし、注意すべきは、o9もエンタープライズソフトウェア特有の一般的な課題から免れているわけではないという点です。実装は単純ではなく、多くの場合、実装パートナー（多くの大手SIがクライアント向けにo9を実装するため）が成功の鍵を握ります。プロジェクトが不十分に実行された場合、ツール自体が非難される可能性があります。現時点でo9に関する具体的な失敗事例は確認できておらず、これは大きな公的失敗がまだ起こっていないか、もしくは判断するには早すぎることを示唆しているかもしれません。また、初期段階ではすべてを一新するのではなく、段階的に補完していく戦略が取られている可能性もあります（クライアントによっては、特定の計画側面にのみo9を採用し、段階的に導入する場合もあります）.

我々の評価: 我々はo9ソリューションズを、真に現代的なアーキテクチャと統合された哲学を備えた有力な候補と評価しています。いくつかの点で我々の基準を満たしており、それは計画の一環として価格およびプロモーションを考慮している点です（最適化の深さは中程度かもしれませんが、統合は実現されています） ¹⁵⁸ ¹⁵⁹。また、高度な予測技術によって不確実性に対応しており、リスクやセンシングへの強調から、確率的あるいは少なくともシナリオベースのプランニングをサポートしていると考えられます。さらに、スケールとスピードに対応すべく、適切にクラウドコンピュートやインメモリ処理を活用して構築されています ¹⁶⁷。ただし、インメモリ処理を大量に使用する場合はコストに注意が必要でしょう（これはKinaxisのスピードとメモリのトレードオフと似た考察です）。自動化へのアプローチはややハイブリッドであり、分析を自動化して処方的な提案をする一方、多くのo9ユーザーは依然として完全自律型のクローズドループシステムではなく、意思決定支援ツールとして運用していると考えられます。とはいえ、「セルフドライビング」サプライチェーンというビジョンはメッセージとして明確であり、その目的のためにプラットフォームを「AI搭載デジタルブレイン」と呼んでいます ¹⁷²。

誰かがo9が一夜にしてすべての計画面を容易に統合するとほのめかすような過剰な約束には依然として懐疑的ですが、o9が増加するクライアント基盤を通じてその能力を実証している事実が、その懐疑心を和らげています。要するに、o9はその潜在能力を最大限に活用すれば多くの成果を上げられるプラットフォームですが、企業がどこまでこのツールで意思決定の自動化を進めるかは環境によって異なります.

ランキングの観点から、もし焦点が在庫と価格の最適化といった狭い分野に限定されるなら、o9はLokadやRELEX（前者はその特定の問題に、後者は小売業界に特化した実績あるアルゴリズムを持つ）に僅かに及ばない可能性があります。o9はより幅広い用途に対応しているため、特定のニッチ領域における非常に専門化されたアルゴリズムは持たないかもしれませんが、幅広い分野をカバーし、技術的にも最新です。我々は、o9のビジョンと堅固な技術基盤に高い評価を与える一方で、同ツールが実際にどの程度の自動化や在庫削減をもたらしたのかといった公開された成果の証拠を、もっと見る必要があると考えています.

出典: o9の機能は、公式情報 ¹⁶⁰ ¹⁵⁸ および、その技術的特徴を強調するLokadによるレビュー ¹⁶⁶ ¹⁶⁷ をもとにまとめられています。また、o9のアプローチと成功を確認する独立系の記事が引用されており ¹⁷² ¹⁶⁹、懐疑的な指摘は流行語と現実の評価に基づいています ¹⁶⁹。さらに、o9の価格モジュールとプロモーション計画に関する情報は、同社のウェブサイトの記述から引き出されており ¹⁵⁸ ¹⁵⁹、プレスリリースで報告された成長やクライアント実績も参照されています ¹⁷⁵ ¹⁷¹.

6. Kinaxis – 高速な「同時進行型計画」リーダー（価格設定機能が欠如）

Kinaxisは、カナダのベンダーで、数十年にわたりサプライチェーン計画（特にハイテクや自動車分野）において頼れる存在となっているRapidResponseプラットフォームで知られています。Kinaxisの特徴は同時進行型計画であり、サプライチェーン計画のすべての部分（需要、供給、在庫、キャパシティ）がリアルタイムで同時に更新され、複数のプランナーが同じデータに同時に取り組むことが可能です。要するに、Kinaxisは、何か変更があるたびに即座に計画を再計算し、ユーザーに瞬時の「もしも」分析や連鎖的な更新を提供する超高速なインメモリ計画エンジンを先駆的に開発しました ¹⁷⁶ ¹³。これは、ほとんどの計画がバッチ処理だった約15年前には革命的なものでした。現在でも、Sales & Operations Planning (S&OP)や複雑な製造業の運用計画に非常に支持されています.

しかし、Kinaxisは歴史的に需要と供給のバランスに注力しており、価格設定や収益管理には重きを置いていませんでした。彼らのクライアントは、需要予測の精度、供給の約束、サービスレベルの維持といった点を重視する、在庫生産または受注生産のメーカーであり、動的な価格設定にはあまり関心がありませんでした。最近まで、Kinaxisには高度な統計的予測モジュールが内蔵されておらず、顧客は予測をインポートするか、基本的な手法を用いていました。市場がAIへとシフトするのを受け、Kinaxisは買収やパートナーシップを通じ、機械学習による予測と分析を追加し始めました。特に、2020年に小売需要予測と分析に特化したAIスタートアップのRubikloudを買収しました ¹⁷⁷。また、確率的予測能力のための提携も行われました。これらは本質的には、機能のギャップを埋めるための**「追加モジュール」**として導入されたものです ¹⁷⁷ ¹⁵⁶。例えば、Rubikloudの技術は小売やCPGにおける需要感知を向上させ、Kinaxisの供給計画の強みを補完するものでした。しかし、これらをRapidResponseに統合する作業は現在も進行中です.

我々の基準から見ると、Kinaxisは在庫と価格の共同最適化において大きく不足しており、実際、価格設定にはほとんど触れていません。非常にサプライチェーン計画ツール（需要、供給、在庫、キャパシティ、場合によってはS&OP財務など）であり、マーチャンダイジングや価格設定ツールではありません。Rubikloudの買収後も（プロモーション向けの小売AIを有していたにもかかわらず）、Kinaxisのコア製品には価格最適化機能が欠如しています。異なる価格仮定で需要計画をシミュレーションするシナリオは可能かもしれませんが、価格を推奨するエンジンは持っていません。したがって、統合された価格決定が必要な場合、Kinaxisは別の価格設定ソリューションと組み合わせる必要があります。これは、共同最適化の観点から重大なギャップであり、包括的なAI最適化の文脈においてKinaxisに減点を与える理由となっています.

不確実性の取り扱いに関して、Kinaxisの元々のアプローチはより決定論的でした。通常、1つの予測（多くの場合、ユーザー提供または合意形成された計画）に基づいて供給の伝播を実施していました。Kinaxisは確率的な予測や安全在庫最適化をネイティブに生成することはなく、ユーザーが安全在庫ポリシーを設定し、Kinaxisはそのポリシーを尊重する形でした。最近の強化により、確率的プランニング（おそらくパートナーシップを通じて）を導入し、不確実性下でのバッファーレベルなどを算出するようになりました。しかし、Kinaxisが確率的手法の先駆者であったとは言えず、追加モジュールを通じて追いついている状況です。現在では、メッセージングにAI/MLが含まれ、「Planning.AI」といった名称もありますが、詳細は乏しいです。これは、最初からの確率的最適化というよりも、主にML駆動の予測やおそらく異常検知を統合しているに過ぎないように見受けられます。実際、ある批評ではKinaxisは本質的に進化中のレガシーアーキテクチャ、すなわち決定論的なコアに新たなAIコンポーネントを接ぎ合わせたものとされており ¹⁷⁸、技術スタックの一貫性に疑問が呈されています。新たなAI要素は完全に統合されていない可能性があり（例えば、ML予測のために別プロセスを走らせ、それをインメモリエンジンに投入する必要があるなど）、完全な一体化とは言い難い状況です.

Kinaxisのインメモリ同時実行エンジンは、その強みであると同時に弱点でもあります。中規模のデータに対しては非常に高速な計算とシナリオシミュレーションを実現しますが、極めて大規模なデータを投入すると、メモリやパフォーマンスの限界に直面します ¹⁷⁹ ¹⁸⁰。これは、複数のユーザーが同時に操作できる超強力なスプレッドシートのようなもので、インタラクティブな使用には最適ですが、例えば数十億件のレコードを一度に解析する用途には設計されていません。Kinaxisは通常、週単位のバケットや製品ファミリー、SKUなどの集約レベルで動作します。もし企業が数百万のSKUと顧客の組み合わせをリアルタイムで計画しようとすると、苦戦するか、莫大なRAMやサーバークラスターが必要となるでしょう。これは既知のトレードオフで、Kinaxisはスピードを優先するためにスケールを犠牲にしているのです。細部の一部をオフロードする（例えば、ヒューリスティックや細かい詳細に対する簡略化した仮定を用いる）ことでこれを緩和していますが、Lokadやo9のアプローチのような本質的な「ビッグデータ」指向ではありません ¹⁸¹ ¹⁸²。例えば、ある情報源では、データが非常に大規模な場合、Kinaxis用に大規模なハードウェアに投資しないとコスト/パフォーマンスの壁に直面する可能性があると指摘されています ¹⁷⁹。Kinaxisはこの問題を認識しており、特にクラウド展開が進む中で計算の分散化に取り組んでいる可能性が高いですが、これはその設計上の制約です.

別の視点として、Kinaxisは強力なシナリオプランニングとヒューマン・イン・ザ・ループによる意思決定で知られています。プランナーはこれを用いて協力し、需要の急増やサプライヤーの問題といった変化に迅速に対応します。これはあらゆる意思決定の自動化ではなく、人間のプランナーがより良く、より速く判断するためのガイドとなるものです。Kinaxisはしばしば「ヒューマン＋AI」のシナジーを訴求し、完全な自律性ではなく、人間と機械の協働を重視しています ¹⁸³ ¹⁸⁴。彼らは自らのAI機能に「Maestro」という名称を付け、プランナーを支援するためのオーケストレーションプラットフォームとして提供しており、プランナーに取って代わるものではありません ¹⁸⁵ ¹⁸⁶。我々の基準ではより多くの自動化を支持しますが、Kinaxisの哲学は実用的で、人間が得意とする判断や例外処理を行い、その一方で機械が瞬時に数値計算を行うというものです。しかし、その反面、依然として多くのプランナーの入力が必要で、LokadやToolsGroupが主張するほど労力の削減には至っていないという点が挙げられます.

Kinaxisは、公に予測コンペティションなどに参加したことはなく、プラットフォームであるため、そのアルゴリズムの卓越性を単独で定量化するのは難しい。多くの企業において、俊敏性やサービス指標の向上によってその価値が実証されている（在庫削減や計画サイクルの短縮などの事例があるが、Kinaxisのマーケティング由来のものが多いため具体的には引用しない）。また、KinaxisがRubikloudを買収したことは、特に小売/CPGセグメントにサービスを提供し、AIブームに遅れをとらないために、より優れたAI/ML予測が必要であると認識していたことを示している。Rubikloudは、小売向けの需要AIおよび価格設定AIにおける専門知識をもたらした（Rubikloudはプロモ最適化の製品を持っていた）が、RubikloudをKinaxisに統合するということは、これらの機能がひとつの最適化に深く組み込まれているのではなく、個別のモジュールまたはサービスとして存在している可能性が高い。MQレビューでの批判は、Kinaxisの新機能が*「ボルトオン」*であり、技術スタックの一貫性に疑問を投げかけるものだった ¹⁵⁶ ― 例えば、Rubikloudの部分は単に疎結合なのかという点である。

競争状況： Gartnerの2024年サプライチェーン計画マジッククアドラントでは、Kinaxisは依然としてリーダーであったが、その背景には多数の顧客や堅実な財務実績といった強固な実行実績があった ¹³。しかし、技術的には真の最先端のAIというよりも進化途中と見なされている。Gartnerはその自動化と整合性を評価したが、独立した分析では矛盾が指摘された：Kinaxisはリアルタイムであらゆる詳細レベルの情報を語っているものの、実際には詳細とリアルタイム性のスケーリングは、Kinaxisにとってさえも困難である ¹⁸⁰。Kinaxisの同時並行処理は短期の再計画やシミュレーションには優れているが、本質的に確率的なものでもコスト最適化されているわけでもなく、ルールを定義して結果を確認する必要がある（Kinaxisは供給配分など特定の事例向けの最適化ソルバーを持っているが、すべての意思決定に対するグローバルな最適化を実現しているわけではない）。

価格設定および市場データ統合に関して、Kinaxisは競合他社の価格を自動的に取り込んだり、価格決定を推進したりはしていない。たとえ価格といった需要要因を予測の入力として組み込むことができたとしても、それらを自ら収集することはない。KinaxisのRubikloud買収により、プロモーション時のリフト係数を組み込んだり、AIを用いてプロモーションの効果を分析する能力が多少得られたかもしれないが、日常の価格設定はその範囲に含まれていない。

評価： Kinaxisは、反応速度と同時協働が不可欠な複雑な製造・流通シナリオのサプライチェーン計画において、依然として最上位のソリューションである。企業が「もしも」のシナリオを迅速に実行し、計画を同期させるのに大いに役立つ。しかし、我々の定義するAI搭載サプライチェーン最適化（価格設定や真の自動意思決定を含む）という文脈では、Kinaxisは主要な要素（価格設定、完全自動化、確率的最適化）を欠いており、特定のスケールでは非常に効果的な技術アーキテクチャを有していても、大規模データに対して安価にスケールアウトできず、不確実性を最もエレガントに取り込むことができない。大規模な小売ネットワークを持つ企業や価格決定が必要な企業は、補強なしではKinaxisが不十分と感じるだろう。したがって、AI最適化における革新性の評価ではKinaxisを低く位置づけるが、サプライチェーン計画におけるその強固な実行実績は認めるべきである。これは、確固たる既存企業が自己革新を試みる典型例であり、KinaxisはAI機能（Rubikloudの技術など）を追加し、マーケティングで「Planning AI」を謳っている ¹⁸⁷が、潜在的な利用者には内部を精査するよう助言する ― 現時点でKinaxisのAIは、表面的な追加機能や個別ソリューションに過ぎず、変革されたコアではない可能性がある ¹⁸⁷。

また、Kinaxisの典型的な顧客（例えば、エレクトロニクスOEMや自動車部品サプライヤーなど）は、これらの業界において価格設定が別の商業チームや原価プラス方式で扱われるため、Kinaxisによる価格最適化を必要としない可能性がある。したがって、Kinaxisはその点を優先していない。しかし、世界がより統合された意思決定とAIへ移行する中で、Kinaxisはその領域に拡大するか、さもなくば時代遅れと見なされるリスクを負うことになる。

また、Kinaxisは他のテクノロジーとの提携も開始している（例えば、AI支援と断片化の解消を目的としてDatabricksとのパートナーシップが発表された ¹⁸⁸）。これは、現代のデータプラットフォームを活用してビッグデータとAIをより適切に扱う必要があることを認識していることを示唆している。良い動きではあるが、古いコアに新しい要素を追加している点が浮き彫りになっている。結論として、Kinaxisはやや折衷的な存在である。本来の目的である、人間が介在する迅速で同時進行のサプライチェーン計画には非常に優れており、その分野で実証済みの価値を有する。しかし、本研究の文脈でのAI駆動による包括的最適化においては、Kinaxisは*主要要素（価格設定、完全自動化、確率的最適化）*を欠いており、技術アーキテクチャも特定の規模では非常に効果的であっても、大規模データに対して安価にスケールアウトすることができず、不確実性を最もエレガントに取り込む仕組みにはなっていない。大規模な小売ネットワークや価格決定が必要な企業にとっては、補完がなければKinaxisは不十分と感じられる。したがって、我々はAI最適化における革新性の評価でKinaxisを低く位置づける一方、サプライチェーン計画での強固な実行実績を認める。これは、既存の強固な企業が自社を革新しようとする典型例であり、KinaxisはAI機能（Rubikloudの技術など）を追加し、マーケティングで「Planning AI」を謳っている ¹⁸⁷が、利用を検討する際は内部構造を確認することを勧める ― 現状、KinaxisのAIは表面的な追加機能や個別のポイントソリューションに過ぎない可能性がある ¹⁸⁷。

出典: Kinaxisの同時計画およびインメモリアプローチの遺産は、各種分析で言及されている ¹⁷⁶ ¹⁷⁹。Rubikloud買収によるAIの追加が記録されている ¹⁷⁷。ボルトオンAIおよびスケーラビリティの問題に対する批判は、Gartner MQのLokadレビューからのものである ¹⁵⁶ ¹³。Kinaxisの自動化の主張とメモリ制限の現実が引用されている ¹³ ¹⁸⁰。また、Kinaxis自身が人とAIの融合について述べた発言（ウェブサイトやマーケティングにおいて「human intelligence with AI」などの用語が使われる ¹⁸³）も参照している。Databricksとの提携によるAIデータ処理強化については、BusinessWireの記事で言及され、いくつかのギャップに対処する方向性が示されている ¹⁸⁸。

結論：AIサプライチェーン最適化におけるハイプと現実の狭間をどう乗り越えるか

この市場調査では、AI駆動のサプライチェーン最適化の分野に対して、批判的かつエビデンスに基づいた視点を適用した。その結果、真に有能なプレイヤーはごくわずかで、多くは見せかけに過ぎないという状況が明らかになった。不確実性下での在庫、価格、アソートメントのエンドツーエンド最適化という概念は極めて困難であり、厳密な数学、スケーラブルな技術、そしてすべてのベンダーが提供できるとは限らない自動化への信頼が求められる。 Lokadは、統一された確率的アプローチと、分断された計画を超える意思決定最適化への注力により際立っている。それは「AI搭載」が意味するべきものであり、すなわち、ビジネスのためのカスタムモデリング、確率的予測が経済的意思決定ルールに直接反映される仕組み、そしてほぼ無人で運用可能な自動化を実現している ²¹ ³。さらに、そのクラウドアーキテクチャの費用対効果 ³² や、M5コンペティションでの成果などの具体的実績が、そのリーダーとしての地位を補強している。対価として求められるのは、柔軟性と深みを実現するための熟練した設定である。 RELEXとBlue Yonderは、主要なスイートベンダーとして幅広い機能を提供し、現代化へ向けた競争を展開している。RELEXは、小売分野においてそのAIの才覚と統合プラットフォームで輝いており、棚スペースから価格設定に至るまで、無数のシグナルを処理する実用的なAIで対応している ⁴⁰ ⁵⁰。我々の分析では、RELEXの確率的予測およびシームレスなユーザー体験という強みが、実際にはその一部「自律性」が依然として人間による操作やデータの精査を必要とする現実によって部分的に相殺されていることが明らかになった ⁶⁰ ¹¹。Blue Yonderは、何十年にもわたるサプライチェーンの巨人であり、特に価格設定のためにRevionicsを追加した後は、あらゆる要素と深いドメイン知識を有している ⁷² ⁹⁹。しかしながら、これは移行中の寄せ集めに過ぎず、我々の精査で、Blue Yonderの統一された「Luminate」ビジョンが理想論に留まり、実際には完全に実現されていないことが明らかになった ⁷⁶ ⁷⁸。クライアントは、統合のギャップやAIの流行語の背後に潜む技術的負債に注意すべきであり、Dillard’sの訴訟騒動は、約束が現実を上回るとどうなるかを痛感させる事例である ²³。RELEXとBlue Yonderはともに能力面でリーダーであるが、その真の革新（例：RELEXの連続再予測、Blue Yonderの実績あるMEIOアルゴリズム）を、マーケティング上の誇大広告（例：完全なリアルタイム全知性の主張）と切り離して見極めるためには、懐疑的な視点が必要である。 ToolsGroupは、定量的厳密さ（先駆的な確率的在庫最適化）の遺産を背景に、買収を通じて小売計画を強化している。我々の調査では、ToolsGroupは不確実性の扱いや供給計画の自動化において技術的に優れており ⁷ ¹³⁴、何を行い（サービスレベルと在庫管理）何を行わないか（日々の価格最適化）について率直であることが確認された ¹³⁹ ¹⁴¹。その課題は、新たなマーチャンダイジング機能を完全に統合し、順次的な計画ではなく真の共同最適化を提供することである。それにもかかわらず、派手なマーケティングよりも最適化の数学に焦点を当てる姿勢は、流行語に溺れる新興プレイヤーがひしめく業界において新鮮である。 o9 Solutionsは、新しい波の「AIプラットフォーム」を体現しており、モダンな技術スタックと幅広い統合範囲で確実に印象を与える。あらゆる計画を網羅する**「デジタルブレイン」となることを目指し、ナレッジグラフやオープンアルゴリズムハブといった最先端のアイデアを活用している ¹⁶⁶ ¹⁶⁹。我々がo9に対して懐疑的であるのは、その技術自体（堅牢に見える）ではなく、現実にワンストッププラットフォームを実現する難しさにある。多くを約束し、迅速に一部を提供できる可能性が示されている（成功事例も存在する）が、企業は具体的な段階的価値が裏付けられていないまま壮大なビジョンに流されないよう注意すべきである。o9を取り巻く流行語の密度は非常に高いため、見込みユーザーは自社の問題に対して、例えば「どのようにしてo9が我々のデータを用い、我々の価格設定と在庫を共同で最適化するのか」といった具体的なデモを要求するべきである。潜在能力は疑いなく存在する。最後に、Kinaxis（および大まかに言えばSAPやOracle**）は、従来のサプライチェーン計画のリーダーであることが、必ずしもAI駆動の最適化のリーダーであることに直結しないことを示している。Kinaxisの同時計画エンジンは、迅速な人間介在型再計画において本来の目的に対して卓越しているが、多くの既存企業がレガシーなコアにAI機能を後付けしているという現実を浮き彫りにしている ¹⁷⁷ ¹⁷⁸。彼らは「AI/ML搭載」と言えるかもしれないが、それは断片的で時に表面的なものに留まる。Kinaxisの価格統合の欠如は、共同最適化を重視する本研究において明確な欠点である。SAPやOracleについてはここでは詳述しないが、同様のパターン―膨大なポートフォリオにいくらかのAIを散りばめ、基本的にはモジュールベースのソリューションを提供し、利用者がそれらを組み合わせなければならない―が見受けられる。統合の負担はしばしば顧客や高額なコンサルタントにのしかかる一方、前述のベンダーはよりシームレスな体験の提供に努めている。そして、Gartner MQの批評家が指摘するように、これら大手は技術的優位性ではなく、規模や関係性によってリーダーとされがちである ¹⁸⁹ ¹⁹⁰。 主要なポイント：

流行語にご注意を： 多くのベンダーは「AI駆動、認知、自律」といった用語を気軽に使う。我々の調査では、技術文書や独立した研究に踏み込まなければ、誤解を招きやすいことが分かった。例えば、「リアルタイムAI計画」を謳うベンダーであっても、一晩中のバッチ処理と一部の機械学習による予測に依存している場合がある ― 要するに、新瓶に入った古ワインのようなものだ ⁸⁶ ⁸⁷。常に具体的な点を確認すべきである：具体的にAIは何をしているのか？どのようにテストまたは検証されているのか？証拠に基づいて改善が定量化できるのか？懐疑的な視点とは透明性を求めることであり、我々は、例えば「AI」とは単にARIMAの代わりにXGBoostやニューラルネットを使った予測に過ぎないという事実を明らかにした ― それ自体は悪くはないが革新的ではない。
統合が王道（かつアキレス腱でもある）： 至高のシステムとは、在庫、価格、アソートメントという伝統的に分断された領域を横断して最適化する単一のシステムである。現実には、ベンダーは異なる起源から来ており、その能力を組み合わせている。Lokadは設計上、コードを用いて統一モデルを構築することでこの問題を回避した。RELEXはほとんど自社内で構築し、一貫性があるように見えるが、結局は後になって価格設定を追加せざるを得なかった。Blue YonderとToolsGroupは買収を通じた道を歩み、依然としてそれらの要素を統合し続けている ⁷⁶ ¹¹⁸。現状、多くの提供物は「統合はされているが完全な一体化には至っていない」状態である。企業は、各要素を協調させるために相当な労力が必要になることを覚悟すべきである。共通のデータプラットフォーム（Blue YonderのSnowflake、ToolsGroupのInventory Hubなど）へ移行するベンダーは正しい方向にいるが、それは長い道のりである。その間、部門横断的な最適化には、段階的なプロセスと、人間の監視が不可欠であると考えなければならない。
不確実性に対しては、確率的かつ経済的な最適化が不可欠： 確率的予測の重要性が広く認識されるようになったのは歓迎すべき進展である。我々の調査対象となった全主要ベンダーは、ネイティブに対応するか、あるいは対応を主張している。これは、しばしば不意の驚きをもたらした決定論的計画の時代からの前向きな変化である。同様に、コストや利益の考慮を組み込む傾向―すなわち、純粋なサービスレベルやフィルレートの考え方から、利益最適な意思決定へとシフトする動きが見られる ¹⁹¹―は顕著である。しかし、その度合いは様々である。ToolsGroupとLokadは、サービスや利益の目標に対して非常に明確に最適化を行っている。RELEXとBlue Yonderは、一部の計画において、過大予測と過小予測のコストのバランス ¹⁹² など、コストのトレードオフを組み込んでいる。ソリューションを評価する際には、ツールが経済的価値をどれほどうまく優先順位付けできるか（例えば、すべての在庫切れを同等に扱わず、低利益商品の在庫切れは高利益商品の在庫切れほど重大ではない等）を確認すべきである。もし、ベンダーが単位コスト、保有コスト、価格弾力性などを容易に考慮に入れられなければ、いかなるAIの力をもってしても真に最適な成果は得られない。それは単に「実現可能な」計画を提示するに過ぎず、結果として金銭的損失を招く可能性がある。
自動化対制御 – ヒューマンファクター： すべてのベンダー分析に共通するテーマは、実現可能な自動化の水準と人間による制御の必要性との間のバランスであった。これは、極度の自動化（設定して放置する）とユーザーの柔軟性の間でのバランス調整の問題である。あるベンダーは自動化寄りに傾いており（Lokadはそれを目指し、RELEXはそれを示唆するが、その上で多くのユーザー設定可能なレバーを付加している ¹¹）、一方で Kinaxis のような企業は、自動化を犠牲にしてでもユーザーにより多くの制御権を与える方針を取っている。最適な選択は、企業の文化や成熟度に依存する。本調査の懐疑的見解としては、多くのベンダーが「自律的な計画」を約束しているものの、実際はせいぜい半自律であるという点にある ⁶⁰ ¹⁹³. 企業は、流行語に安心して AI システム導入後に計画チームを解散できると考えるべきではなく、むしろ計画チームの役割を向上させること、つまり AI に雑務や数値計算を任せ、人間が例外処理、戦略、検証を担う体制を目指すべきである。時間をかけて信頼が築かれれば、システムにより多くの自律性を付与することが可能になる。その移行を促進するベンダー（透明性、オーバーライド機能、そしてオーバーライドからの学習を提供するもの）が、最良の成果をもたらすだろう。その観点から、（Lokad や ToolsGroup のようにロジックを確認・調整できる）「ガラスの箱」方式は、理由の説明もなく回答を出す純粋なブラックボックスよりも、信頼を与えるかもしれない。
誇大宣伝よりも証拠と厳密性： 最後に、全体を見渡すと、サプライチェーンソフトウェア市場はアナリストレポート、スポンサー付きケーススタディ、および好意的な ROI 主張で溢れている。本研究ではあえてそれらを除外した結果、一般的な認識と技術的現実との間に乖離があることが浮かび上がった。例えば、Gartner のマジック・クアドラントでは、市場での存在感を理由に X をリーダーに挙げるかもしれないが、技術的には X が AI において後れを取っている可能性がある（Oracle や Logility にその兆しが見られた）。一方、アナリストのレーダーにさえ乗っていないベンダー（おそらく費用をかけていないために）は、革新的な取り組みを実現している可能性もある ²⁵ ¹⁸⁹. したがって、意思決定者は、派手なクアドラントに惑わされるのではなく、むしろアーキテクチャのホワイトペーパー、参考顧客による技術講演、または小規模な試作プロジェクトの実施に踏み込むべきである。ベンダーが、あなたの問題の一部に関して自社技術を証明するよう求められたとき（例えば、ある製品ラインに対する 8 週間の概念実証）、その営業トークの背後にどれだけの実体があるのかが明らかになることが多い。実際、外部競技会に参加したり技術ブログを公開しているベンダー（Lokad、Blue Yonder の一部、ToolsGroup のブログなど）は、現実に根ざした取り組みを行っており、自らの考えを公開している傾向がある ¹⁰⁴. これは良い兆候である。一方、一般的なマーケティング用語しか持たず、技術的な深堀りが一切なければ、実際の深みが欠如している可能性がある。

要約すると、AI を駆使したサプライチェーン最適化市場は成熟しつつあるものの、依然として大きな約束と不均一な成果が特徴である。ソリューションを求める企業は、各ベンダーの主張を冷静な事実と照らし合わせる必要がある。すなわち、そのベンダーは共同最適化を実証しているのか、それとも単に統合について語っているだけなのか。不確実性に対して定量的に対処できるのか、または依然として単純なバッファに頼っているのか。彼らは、実際に意味のある形で AI を活用しているのか（例：中立的な評価での勝利や高パフォーマンスを達成しているのか）それとも、ただ古い手法に AI 用語を散らしているだけなのか。本研究のようにこれらの困難な疑問を投げかけることで、不要な雑音を排除できる。その見返りとして、単なるハイプサイクルに乗るだけでなく、真に最先端を切り拓く極わずかなソリューションを見出すことができる。2025 年には、確率的予測から自動価格設定に至るまで、サプライチェーンの意思決定を革新する技術が存在するが、ベンダーを選ぶ際には、真の革新と*「AI ウォッシング」*を見極める必要がある。本レポートが、この違いを明らかにし、どのベンダーが真に限界を押し広げ、どのベンダーが派手な用語で後れを取っているのかをより明確に理解する一助となれば幸いである。