Last modified: 2025年2月2日

サプライチェーン計画ソフトウェアは、不確実な状況下で（何を生産し、在庫し、または移動させるか、そしていつ）意思決定の最適化を目的としており、単なる取引記録に留まりません。ある定義によれば、サプライチェーンとは、変動性と制約に直面した際のオプショナリティを、数量的かつ実践的に巧みに操ることであり…根底にある業務の直接管理ではなく、選択肢を育み選び出すことに重点を置いています。¹ 言い換えれば、最良の計画ツールは、単なる取引管理（注文や在庫の追跡）ではなく、最適化（例：最適な在庫量や生産レベルの決定）に焦点を当てています。本調査は、マーケティングよりも具体的な技術的根拠を重視し、世界中の主要なサプライチェーン計画および予測ソフトウェアベンダーを比較評価します。各ベンダーを主要な基準に基づいて評価します：

• 確率的予測 – 単一の予測値を超えて、完全な分布や高度なモデルを提供しているでしょうか？「AI/ML」による予測と謳う場合、M5のような国際予測コンペティションでの顕著な成績など、その主張を裏付ける証拠はあるのでしょうか？
• 自動化の度合い – システムは、人の手を加えることなく無人で予測と計画を実行できるでしょうか？意思決定能力はどれほど自律的なのでしょうか？
• スケーラビリティとパフォーマンス – この技術は、大規模なデータを効率的に処理できるでしょうか？（データが増加し、メモリコストが停滞する中、インメモリアーキテクチャは十分にスケールしない点に注意が必要です。）
• 技術統合と買収 – このソリューションは、統一された技術スタック上に構築されているのでしょうか、それとも買収されたモジュールの寄せ集めなのでしょうか？長い買収の歴史は、分断され矛盾する技術につながる可能性があります。
• 技術的信頼性 – ベンダーの技術的主張は、科学的原則またはエンジニアリングの証拠によって裏付けられているでしょうか？私たちは、具体的な説明やピアレビューによる検証がない限り、流行語（「AI/ML」「需要センシング」）を排除します。
• 一貫性と矛盾 – ベンダーのメッセージは整合しているでしょうか？（例：確率的予測を謳いながら、MAPEのような決定論的な精度指標を強調するのは警戒すべき兆候です。）
• 時代遅れの手法 – 現代の確率的最適化と矛盾する、単純な安全在庫計算式などの旧式な手法を指摘します。
• 意思決定志向のアウトプット – ソフトウェアは、単に予測を提供するだけでしょうか、それともその予測に基づいて最適化された意思決定（注文計画、在庫目標など）を提示するのでしょうか？真の目的は、単なる数字ではなく意思決定を促すことにあります。

アプローチ： 各ベンダーの評価には、公開された技術文書、信頼できる分析、そして（可能な場合は）オープンなベンチマークやコンペティションの結果を活用しています。ベンダーの誇大広告、支払われたアナリストレポート、光沢あるケーススタディは、確固たる証拠がない限り無視されます。口調は意図的に懐疑的であり、主張はデータやエンジニアリングの実体によって裏付けられる必要があります。一貫性の欠如や透明性の不足は、重大な弱点と見なされます。

以下では、技術的リーダーシップに基づいて主要なサプライチェーン計画ソフトウェアベンダーをランキングし、それぞれの簡潔な理由付けを示します。ランキングの概要の後、上記の技術基準に沿って整理された詳細な比較が続きます。すべての記述は、信頼できる情報源による引用（【source†line】形式）で裏付けられています。

技術的卓越性によるトップベンダーランキング

1. Lokad – 最先端の確率的最適化 Lokad は技術革新をリードし、確率的予測と真に意思決定中心の計画を先駆けました。早くも2012年、Lokadは確率的予測を提唱し（他社よりもほぼ10年先を行き）、その全体ソリューションをそれに基づいて構築しました ²。予測と計画を別々の工程とする他のベンダーとは異なり、Lokadのシステムは（Envisionと呼ばれるドメイン固有言語上に構築され）確率モデルから直接、最適化された意思決定（注文や在庫レベル）を生成します。Lokadの技術的信頼性は卓越しており、手法を公開・文書化している点、またそのチームが著名なM5予測コンペティション（909チーム中）でSKUレベルでの最高精度を達成した点がそれを物語っています ³。この実績ある詳細な予測での勝利は、Lokadの最先端の予測能力を裏付けています。このプラットフォームはクラウドネイティブで、完全自動化（定期的に無監視で予測と最適化が実行）されており、スケーラブルなクラウドコンピューティングを活用することで、インメモリ設計の限界を回避しています。まとめると、Lokadは確率的、オートメーション重視、かつ実証的根拠に基づくアプローチでサプライチェーン最適化の基準を打ち立てています。

2. Kinaxis – 迅速なインメモリ計画と新興AI Kinaxis は、その非常に高速な「同時進行型計画」エンジンで知られる確立されたリーダーです。RapidResponse プラットフォームは、インメモリアーキテクチャを利用し、供給、需要、在庫にまたがるリアルタイムのシナリオシミュレーションを実現します。この設計により、プランナーは瞬時に「もしも」分析を行うことができ、応答性の向上に大きく寄与します。しかし、インメモリ計算への依存が強いと、データ増加に伴い高いハードウェアコストとスケーラビリティの制約が生じる可能性があります（大規模導入には莫大なRAMが必要となる） ⁴。従来、Kinaxisはユーザー定義のルールや手動調整を活用した決定論的計画に注力していました。業界の変化を受け、Kinaxisは最近、買収やパートナーシップを通じて確率的手法を取り入れました。例えば、パートナーWahupaから確率的多段階在庫最適化（MEIO）エンジンを追加し、需要予測用にAI企業Rubikloudを買収しました。これらの追加機能は、Kinaxisに先進的な予測と不確実性のモデリングをもたらしますが、その一方で技術スタックの一貫性に疑問を呈する要素もあります。Kinaxisの「AI」や機械学習に関するメッセージは、他の競合と比べると慎重であり、人間と機械の知能の融合を強調しています。実際、Kinaxisは計画の再計算自動化に優れており、データが変わるたびにシステムが自律的に需給バランスを再調整しますが、従来はプランナーにパラメーター設定を依存しており、最終的な意思決定の完全自動化は実現していません。新たな確率的モジュールにより、Kinaxisは決定論的遺産を踏まえつつも、不確実性下での意思決定自動化へと移行しています。まとめると、Kinaxisは強力なリアルタイム計画プラットフォームを提供し、AI主導の予測にも追随していますが、新たな確率的機能が徹底的に統合されていることを証明する必要があります。

3. o9 Solutions – 大きな野心とビッグデータ o9 Solutions は、2009年創業の比較的新しい企業で、サプライチェーンの「デジタルブレイン」としてしばしば称されます。技術的には、o9は非常に野心的で、グラフベースのデータモデル（Enterprise Knowledge Graph、通称「EKG」）を用いた広範なプラットフォームを構築し、大規模で複雑なデータセットに対応しています（これにより、エンドツーエンドの計画ツールを求める大企業に人気があります）。しかし、o9のアプローチにはトレードオフが伴います。報告によれば、システムはインメモリ設計を採用しており、迅速な分析を可能にする一方で、大規模利用においては「高いハードウェアコストを保証する」とされています ⁴。これは、問題に対してより多くのRAMを投入すると費用がかさみ、最終的には限界に達するというスケーラビリティの懸念を引き起こします。o9はAI/MLを前面に出してマーケティングを行っていますが、実質と宣伝を見極める必要があります。例えば、そのナレッジグラフが予測を唯一向上させるという主張は、科学的根拠がなければ疑わしいものです ⁵。実際、GitHub上で公開されているo9の技術要素の分析は、主に標準的な手法を採用していることを示唆しており（壮大な「AI」ブランドを正当化するほどの革新性はない） ⁶。o9はある程度の確率的シナリオ計画をサポートしており、複数の需要シナリオをモデル化してシミュレーションを実行できますが、真の確率的予測分布を提供しているのか、単なるシナリオ分析に留まっているのかは不明です。このプラットフォームは特定の計画タスクを自動化できるものの、最終的には人間が「デジタルブレイン」を操作する意思決定支援として位置付けられています。全体として、o9は技術重視で多機能なプラットフォームですが、インメモリコンピューティングへの依存と、AIに関する主張の曖昧さが、技術的リーダーシップの評価をやや低くしています。むしろ、o9は統合されたビジョンとビッグデータ処理においてリーダーと言えるでしょう。

4. Relex Solutions – 小売業向け自動化（制約あり） Relex Solutions（2005年創業）は、小売需要予測、補充、そしてスペースプランニングを専門としています。高度に自動化された店舗補充を可能にすることで評判を得ており、多くの大手食料品店が、Relexを利用して店舗レベルの需要を自動的に予測し、最小限の人手で注文を生成しています。この、困難な小売環境下でのエンドツーエンドの自動化は、顕著な強みです。Relexはまた、プロモーションや地域のイベントを考慮した、小売向けに最適化された最新の機械学習を用いた予測手法を誇っています。とはいえ、内部を詳しく見ると、いくつかのアーキテクチャおよび方法論上の制約が明らかになります。Relexのシステムは、非常に高速な分析とレポートを実現するために、インメモリ、OLAPスタイルのデータキューブ設計 ⁷ を採用しています。これにより、俊敏なダッシュボードが実現されますが、同時にハードウェアコストが増大し、複雑な最適化問題を本質的に解決することはできません。実際、Relexのリアルタイムで細分化されたアプローチは、ネットワーク全体の最適化と矛盾する可能性があり、製品のカニバリゼーションや代替といった現象に直面した際、大規模なサプライネットワーク全体での最適な意思決定の調整に苦労するかもしれません ⁸。また、Relexの予測モデルが宣伝されているほど「次世代」ではない兆候もあり、その手法の多くが2000年以前の（回帰や時系列の平滑化など）方法に依存している証拠が示唆されています ⁹。彼らは小売業者向けに99%以上の在庫充足率を誇っていますが、業界調査（例えばECR協会によるもの）では、実際の棚上在庫率はそれより低いことが示され、このような一律の主張には疑問が呈されています ¹⁰。Relexは、小売向けに内製された一貫性のある技術スタックを有し、大規模な買収によって成長していないため、一貫性が保たれています。まとめると、Relexは小売自動化のリーダーとして印象的なハンズオフ運用を実現できますが、予測科学における技術的深度は疑問視され、さらにインメモリアーキテクチャであるため、他社と同様のスケーラビリティの懸念を共有しています。

5. ToolsGroup – 初期の革新者から現在の「AI」推進へ ToolsGroup（1993年創業）は、SO99+ソフトウェアを提供しており、歴史的にはサービスレベル重視の予測と在庫最適化で知られていました。「AI」が流行語になるずっと前から、ToolsGroupは、需要の変動性をモデル化して所望のサービスレベルを達成するための安全在庫を決定するなど、サプライチェーンにおける確率的概念を普及させる役割を果たしてきました。実際、彼らのツールは、（特に動きの遅い品目において）需要の確率分布を生成し、目標充足率を実現するための在庫目標を計算することができます。しかし、近年、ToolsGroupのメッセージはAI/MLブームに乗る形でシフトし、そこで信頼性の亀裂が露呈しています。彼らは「AI搭載」の計画を大々的に宣伝していますが、公開情報から、コアとなるアルゴリズムが依然として基本的には従来の（2000年以前の）統計モデルであることが示唆されています ¹¹。特に、2018年頃から出力を「確率的予測」としてブランド化しながら、同時にMAPEの改善を自慢し始めたことは、明らかな矛盾を孕んでいます—なぜならMAPE（決定論的な予測誤差指標）は*「確率的予測には適用されない」*ものだからです ¹²。これは、誤解か、あるいはマーケティング上の手練手管、すなわち確率的予測を生成しているにもかかわらず、中央値と実績をMAPEで比較して評価しているのかもしれません（これでは確率的手法の趣旨を外してしまいます）。また、ToolsGroupは短期予測の調整のために「需要センシング」を謳っていますが、そのような主張は科学文献によって支持されておらず ¹²、しばしば再パッケージされた移動平均に過ぎません。肯定的な面として、ToolsGroupのソリューションは、サプライチェーン計画（需要予測、在庫最適化、S&OPなど）において非常に機能が充実しており、完全自動モード（夜間に自動で補充提案を生成）が実現可能です。その最適化への注力（最小限の在庫でサービス目標を達成すること）は、意思決定志向の予測と合致しています。しかし、明確な技術的証拠のない最新のAI主張や、現代的なクラウドネイティブではない可能性のある（おそらく単一サーバー中心の）アーキテクチャが、技術的リーダーシップの評価をやや低下させています。要するに、ToolsGroupは確率的在庫モデリングにおける実績あるプレイヤーですが、新たなAI主張を裏付け、その手法が停滞していないことを保証するために、より一層の透明性が必要です。

6. Blue Yonder – 強力なレガシー、寄せ集めの技術 Blue Yonder (1985年にJDA Softwareとして創業、Blue Yonderという小規模なAI企業の買収後にブランド変更) は、サプライチェーン計画の巨人です。需要計画、供給計画、小売など幅広いソリューションを提供しています。長年にわたり、Blue Yonder (BY) は 多数の買収 を通じて大規模なポートフォリオを構築しており、Manugistics（サプライチェーン最適化）やi2 Technologiesの部品、そして最近ではBlue Yonder AIスタートアップまで含まれます。その結果、たとえひとつのブランドの下にあっても、「無秩序な製品群、そのほとんどが時代遅れ」 となっています ¹³. 技術的には、Blue Yonderのレガシーモジュール（需要予測やフルフィルメントなど）は、しばしば古い手法（例：ヒューリスティックな予測、安全在庫を用いたルールベースの計画）を利用しています。同社は現在、マーケティングで「AI/ML」を誇示していますが、その主張は あいまいで中身が乏しい ¹⁴. ひとつの示唆として、Blue YonderのGitHubにはtsfresh, PyDSE, Vikos など少数のオープンソースプロジェクトしかなく、これらは 基礎となる予測手法をほのめかしている もので、最新の深層学習や確率モデルではなく、主に特徴抽出＋ARIMA/線形回帰モデルなどの伝統的な手法を示唆しています ¹⁵. 言い換えれば、BYの「AI」はブレイクスルーというよりも話題性に留まっている可能性が高いのです。プラットフォームの一体感に課題がある―計画、補充、在庫最適化が、シームレスに連携するのではなく、別々のエンジンとして存在している（統合には大規模な実装作業が必要です）。Blue Yonderは、特定の分野で非常に強力な最適化能力を持っており（例：モダナイズすれば、レガシーなi2アルゴリズムはサプライチェーンネットワーク最適化において強力になり得る）、多くの大企業が、MRPプロセスを駆動する予測の生成や安全在庫レベルの設定など、計画業務の自動化のためにBlue Yonderを導入しています。しかし、新しい技術リーダーと比較すると、Blue Yonderは 技術的に停滞している ように見えます。というのも、主に決定論的な予測（しばしばMAPEやバイアスなどの古い指標で評価される）に固執し、中心的な計画要素として 時代遅れの安全在庫フォーミュラ を使用し、AI用語を薄くしか採用していないからです。その資源を考えれば、Blue Yonderは進化する可能性を秘めていますが、現時点では大手ベンダーのトレードオフ、すなわち 広範な機能性 を持ちながらも 断片的で老朽化した技術スタック を体現しているのです ¹³. 技術の観点から、より先進的な競合他社よりも低く評価せざるを得ません。

(その他の注目すべきベンダー：SAP IBP や Oracle SCM Cloud もサプライチェーン計画スイートを提供していますが、これらは主に取引型ERPシステムの拡張機能です。これらは、レガシーシステムや買収から生じた大きな技術的負債と複雑さを引き継いでいます。例えば、SAPの計画製品は、SAP APO、SAP HANA、そして買収したツール（予測用のSAF、在庫用のSmartOps）などのコンポーネントが混在したもので、実質的に「多くの製品の集合」であり、大量の統合作業を必要とします ¹⁶. これらのERPに紐づくソリューションは、ある面では強力であるものの、一般的には 予測科学や自動化のリーダー とは言えないため、上位ランクからは除外されています。)

---

主要なベンダーを紹介した後、ここでは 各基準ごとの分析 に踏み込み、各ベンダーが確率論的予測、自動化、スケーラビリティなどの点でどのような位置にあるのかを、証拠や具体例を交えて明らかにしていきます。この比較的視点は、各ソリューションの長所と短所を詳細に浮き彫りにします。

確率論的予測：決定論的モデルを超えて

現代のサプライチェーン最適化は、単一の「最もあり得る」数値ではなく、可能な結果の範囲や分布（確率付き）を推定する 確率論的予測 から大いに恩恵を受けます。確率論的予測は需要の変動性をより正確に捉え、より堅牢な意思決定を可能にします（例：在庫をX単位保有した場合の品切れの確率を把握するなど）。我々は、真に確率論的手法を採用しているベンダーと、決定論的予測に固執しているベンダーを比較検証しました。主な所見は以下の通りです：

• Lokad は、確率論的予測を深く組み込んでいる点で際立っています。彼らは （2012年以降）早期に確率論的モデルを推進 し²、その能力を継続的に向上させてきました。Lokadのアプローチは、すべての最適化の基盤として確率的な需要分布を利用しており、例えば、需要分布全体を積分してさまざまな在庫量の期待利益を算出します。Lokadの予測技術の信頼性は、国際的なコンペティション によって裏付けられており、Lokadチームは M5 Forecasting CompetitionでSKUレベルの最高精度 を達成しました³。重要なのは、M5が確率論的予測そのものであった（ランキングは加重分布誤差指標に基づいていた）ということで、Lokadの成果は、その手法が微細なレベルで正確な確率分布を生成する最先端であることを示しています。実際、Lokadは単なる数値ではなく、各商品の需要に対する完全な確率分布（またはシナリオ）を生成し、直接的に意思決定の最適化スクリプトに反映させています。

• ToolsGroup は、サービスレベル最適化の文脈で長年にわたり確率論的機能を提供してきた点は評価に値します。同社のソフトウェアは、明示的な需要分布（しばしば間欠需要モデルやその他の統計的フィッティングを通じて）を作成した上で、所望のサービス確率を満たすための在庫目標を算出できます。しかし、内側に確率論的モデルを組み込むことと、その精神を完全に受け入れることは異なります。2018年以降のToolsGroupのマーケティングは、確率論的予測のリーダーとしての再ブランディングを試みていますが、一方で MAPEの改善と確率論的予測を並行して語る ことにより¹²、その立場を弱めています。これは矛盾しており、もし本当に分布を予測しているならば、主にMAPE（単一の「正しい」数値を前提とする）によって評価することはあり得ません。彼らが依然として決定論的指標に依存しているという事実は、依然としてポイント予測を生成し、分布は在庫必要量のシミュレーションのためにのみ使用している可能性を示しています。したがって、ToolsGroupには確率論的能力があるものの、これらの手法の 洗練度は最先端とは言えない 可能性があり、確率論的予測にどこまで本気で取り組んでいるのか、それとも単なる追加機能として活用しているのかは不明瞭です。

• Kinaxis は歴史的に、コア製品において確率論的予測を提供しておらず、ユーザーが入力するか、単純な統計から生成されたポイント予測に依存していました。このギャップを認識したKinaxisは、Wahupaと提携し、確率論的MEIO（Multi-Echelon Inventory Optimization） エンジンを組み込みました¹⁷。さらに、機械学習による需要予測を専門とするAI企業（Rubikloud）を買収しました（おそらく本質的には確率論的、例：予測区間の生成）。2023年時点で、Kinaxisは「Planning.AI」または類似の機能をマーケティングし、「不確実性を受け入れ」、意思決定に確率論を活用する必要性を明示的に認めています¹⁸。これは前向きな展開ですが、比較的新しいため、Kinaxisの確率論的予測の成熟度は依然として進化中です。私たちは、Kinaxisやその関係者が公開予測コンペに参加したり、詳細な手法を公開したのを見たことがなく、その確率論的能力の 技術的証明 は彼らの主張に留まっています。

• o9 Solutions も概念上は不確実性モデリングを強調しており、彼らのナレッジグラフは多くの因果要素を格納でき、データを連携させることでより良い予測を生成すると主張しています。しかしながら、実際にo9が確率論的予測を提供しているという公の証拠（公開された精度ベンチマークやオープンなアルゴリズム）は見当たりません。彼らの資料におけるベイジアンネットワークやモンテカルロ法の言及もまばらです。o9のコードリポジトリで発見された要素は、革新的な確率論的アルゴリズムというよりは、従来の予測技術に焦点を当てているように見受けられます⁶。o9が別の証拠を示すまでは、主に強化された決定論的予測（場合によってはシナリオ分析を伴う）を提供していると仮定せざるを得ず、いかなる「確率論的」ラベルも単なるマーケティング上のものかもしれません。

• Relex Solutions は、小売業、特にプロモーション品や生鮮品など変動性の高い分野を扱っています。彼らは内部的に、プロモーション商品の需要分布の推定や、所定のサービスレベルに基づく各店舗の安全在庫必要量の計算など、いくつかの確率論的手法を採用している可能性が高いです。しかし、Relexの公開資料は「確率論的予測」を明示的に謳っておらず、むしろ機械学習による予測精度の向上（通常はより良いポイント予測を意味する）について語られています。Relexに関する査読では、彼らの予測技術は2000年以前のものであると示唆されており⁹、これは主に指数平滑法のような決定論的手法、場合によっては季節性やトレンドを伴う方法―ポイント予測や安全在庫のための標準偏差を算出する技術―に依存していることを意味します。したがって、Relexは完全な確率曲線をユーザーに提供するのではなく、「予測してからバッファを加える」という従来のパラダイムに依存している可能性があります。

• 伝統的な需要計画において、Blue Yonder はARIMA、指数平滑法、場合によっては因果要因のための機械学習など、さまざまな統計モデルを用いて予測を行い、通常は集約された上で合意形成プロセスを経る―根本的には決定論的です。Blue Yonderは一部の文脈で確率論的な用語に言及し始めています（誰もがそうしているため）が、彼らの オープンソースへの貢献がARIMAや回帰に依存している ことから¹⁵、確率論的予測は強みではない と言えます。また、彼らは依然としてMAPE、バイアス等といった決定論的指標を推奨しており、Blue Yonderが既知の予測ベンチマークに参加しているのも見受けられません。

• その他のベンダーとして、John Galt Solutions は「Procast」というアルゴリズムを市場に出し、優れた精度を謳っていますが、レビューではProcastがM5のような大規模予測コンペの上位に入っていなかったため、その主張は疑わしいとされています¹⁹. 実際、一般に利用可能なオープンソースの予測ツール（例：ProphetやHyndmanのRパッケージ）は、同等かそれ以上の性能を発揮する可能性があります²⁰. これは共通のテーマを示しており、真の革新はオープンな評価がある場所に現れる ということです。Lokad以外のほとんどのベンダーが公開コンペに参加していないことは、彼らが予測において学術界やオープンソースの先端を本当にリードしているわけではないことを示唆しており、もしそうであれば、これらのフォーラムで証明していただろうということです。

まとめると、確率論的予測は差別化要因 です。Lokadは、その実力と完全に統合された確率論的意思決定で明確にリードしています。ToolsGroupとKinaxisはその重要性を認識しつつも、最近になって統合を始めたところであり（説得力を持たせるためには指標やプロセスの整合が必要です）、その他のベンダーは、パンフレットで「確率的」といった用語をちらつかせたとしても、依然として決定論的なアプローチに留まっています。この違いは重要であり、真に確率論的な予測がなければ、計画システムは粗野な安全在庫に頼らざるを得ず、リスクとコストの最適なバランスを取ることができません。

自動化の度合い：完全自動の計画対人間の介在

予測および計画における自動化とは、監視や時折のパラメータ調整を除き、データ取り込み、予測生成、計画最適化、さらには意思決定の実行といったプロセス全体を 手動介入なしに 実行できるシステムの能力を指します。数千の予測を手作業で調整することが不可能な大規模運用や、変化に迅速に対応する必要がある場合（ロボットは人間よりも速く反応します）において、高い自動化は非常に重要です。私たちは、それぞれのソリューションがどれほど自動化されているか、また 「無人での」計画 実行をサポートしているか（またクライアントが実際にそのように利用しているか）を評価しました。以下はその観察結果です：

• Lokad は自動化を前提に設計されています。そのEnvisionスクリプト環境により、予測および補充のロジック全体をプログラミングしてスケジュールすることが可能です。多くのLokadの導入事例では、システムが毎日または毎週自動的に新しいデータを取り込み、予測を再計算し、意思決定を最適化（例：発注量や配分プランの生成）し、それらをERPや実行システムに出力する、完全にロボット化された運用が実現されており、一切の人手による調整が不要となっています。モデルが正しく設定されれば、手動での介入は最小限に抑えられ、プランナーはルーチンな調整ではなく、例外対応やモデル改善に専念できるという考え方です。Lokadの成功事例は、この自動化のおかげでプランナーの作業負荷が劇的に削減されたことをしばしば強調しています。本質的に、Lokadはプランナーを日々の調整を手作業で行う存在ではなく、むしろデータサイエンティストやプロセスの監督者として扱っています。

• Relex Solutions も、特に 補充 において高い自動化を実現しています。例えば、食料品小売業者向けには、Relexは予測、在庫状況、リードタイムを考慮して、毎日自動的に店舗への発注を生成することができます。Relexを導入している一部の小売業者は、それを十分に信頼しており、大部分の発注が自動で実行され、プランナーは逸脱した提案のみを確認するだけとなっています。Relexのシステムは、例外処理のためのワークフロー（例：予測が通常と大きく異なる場合にフラグを立て、その後人がレビューする）をサポートしていますが、基本的には需要計画と発注を自動実行するように設計されています。これは、数百万に及ぶSKUと店舗の組み合わせという規模で手動計画が不可能な小売業において、重要なセールスポイントとなっています。ただし、この自動化を実現するには、安定した成熟モデルと狭い対象（例：食料品の主要品目）が必要となる点は留意すべきです。より複雑な多段階の製造計画では、Relexの存在感は薄れるものの、その領域内では、無人の予測および補充 が、メモリ内アーキテクチャの制約の範囲内で実現可能であることを証明しています。

• Kinaxis は 再計算の自動化 を提供します – 同時並行処理により、データが変更されるたびに、サプライチェーンモデル（部品表、在庫、キャパシティ）を通じて変更が伝播され、すべての依存計画が自動的に更新されます。これは、各レベルごとに個別の計画サイクルを手動で再実行する必要をなくすという自動化の一形態です。しかし、キナクシスは伝統的に、プランナーがある程度関与することを前提としています。すなわち、プランナーはシナリオを設定し、その結果を検証し、どのシナリオを採用するかを決定します。キナクシスは、例えば在庫が閾値を超えた場合に計画を自動承認するなど、アラートシステムを通じて定型的な意思決定を自動化することが可能ですが、一般的には「ダーク」な自動操縦装置ではなく、意思決定支援ツールとして利用されます。それにもかかわらず、AIやより高度な予測の統合により、キナクシスはより自動化された意思決定へとシフトしつつあります。例えば、新しいMEIOは各計画実行時にエシェロン間で在庫バッファーを自動的に再調整でき、ユーザーは問題がなければその結果を受け入れることができます。同社はまた「自己治癒型サプライチェーン」と呼ばれる仕組みにも投資しており、より高い自律性を示唆しています。しかし、その顧客基盤（航空宇宙、自動車など、プランナーが慎重な業界）を考えると、完全に手を離した計画はキナクシスの展開においては一般的ではありません。

• o9 Solutions も同様に、通常は 計画プラットフォーム として展開され、プランナーや需要管理者などのユーザーが積極的に関与しながら、予測の調整、S&OP計画への協働、シナリオの実行を行います。技術的には定期的な予測更新の設定など、計算の自動化が可能ですが、o9の哲学は人間のプランナーをAIの洞察で補完することであり、完全に置き換えることを目的としていません。「組織のデジタルツイン」というマーケティング用語は、ソフトウェア上にサプライチェーンを忠実に再現することを意味しますが、鏡は通常、あなたの行動を反映するだけで、独自に判断するわけではありません。私たちは、o9を完全自律的に運用しているという証拠を見つけることはなく、むしろこれは横断的な計画を促進するための単一のデータモデルと分析ツールとして利用されています。自動化は、意思決定の自動化というよりも、モジュール間のデータフロー統合の自動化に重点を置いています。

• ToolsGroup は従来、「ロータッチ計画」アプローチを提唱してきました。同社のSO99+ツールは、各SKUに対して統計的予測を自動生成し、在庫目標を算出、さらには補充注文の提案まで自動で行うように設定できます。実際、多くの中規模企業はこれを利用して自動生成された購入注文や生産提案を採用し、プランナーはシステムが特異な状況下で確信が持てない場合などの例外だけを確認しています。自動化の度合いはシステムの推奨に対する信頼度に依存します。ToolsGroupは、確率論的アプローチがより信頼性の高い在庫推奨につながり、その結果、企業がより自動化された発注に安心して移行できると強調しています。しかし、ToolsGroupのモデルが適切に調整されていない場合、ユーザーが多くを上書きする可能性もあります。技術的には、ToolsGroupは予測や初期計画をバッチ処理の無人モードで実行することが可能ですが、Kinaxisのようなオンザフライの再計画には必ずしも適しておらず、むしろ夜間のバッチ処理型の計画に重点を置いています。

• Blue Yonder (JDA) には、ESP (Enterprise Supply Planning) や Fulfillment などのコンポーネントがあり、予測や在庫ポリシーに基づいて、供給オーダーや在庫移動の推奨を自動的にリリースできます。多くのBlue Yonderのユーザーは自動生成された結果に依存しており、例えばシステムは地域倉庫を補充するための配送注文を自動で作成し、目標在庫レベルに達するようにします。Blue YonderのDemandモジュールは、毎週または毎月、基準となる予測を自動生成することが可能です。しかし、歴史的には、JDA/Blue Yonderの実装では需要プランナーが予測を調整し、供給プランナーがシステムの推奨オーダーを確認するといった多くの人間によるワークフローがありました。このソフトウェアは自動化をサポートしているものの、「手を離す」メンタリティを必ずしも推奨しておらず、むしろプランナーの作業台として機能しています。さらに、BYの製品群が寄せ集めになっているため、需要計画から供給計画モジュールへと手動介入なしでデータを流すエンドツーエンドの自動化を達成するには、大規模な統合作業が必要となる場合があります。したがって、技術的には可能であっても、実際のBlue Yonderの現場では計画に対して多くの人間の監視が行われています。

要約すると、自動化の能力は主要なツールすべてにおいてさまざまな程度で存在しますが、その哲学と実際の活用方法は異なります。LokadやRelexは、それぞれのニッチ市場で真の自律計画の限界を押し広げている点で注目され（Lokadは多様な業界向けに完全にスクリプト化されたサプライチェーン・オートパイロットを可能にし、Relexは小売でそれを実現している）、伝統的な大手ベンダーは自動化をより慎重に扱い、最終的な意思決定はプランナーに委ねる傾向があります。これは、システムの予測が十分に信頼できなければ、ユーザーは自動運転に任せないという信頼性の問題を反映しています。すなわち、自動化の有効性は、その背後にあるインテリジェンスの質に依存するということです。確率論的で意思決定志向のツールが求められる主な理由は、システムが自ら良い判断を下せるようにし、自動化を実現可能にするためです。ベンダーを評価する際、企業は「このシステムは自立して1ヶ月間動作し、我々のパフォーマンスを維持または向上させることができるか？」と問いかけるべきです。最高の技術はその問いに対して「はい」に近づいていますが、他の技術は依然として基本的に手動の介在を必要としています。

スケーラビリティとパフォーマンス：アーキテクチャが重要

サプライチェーン計画は、しばしばビッグデータ（多数のSKU、店舗、注文、IoT信号など）や、多くの変数にまたがる複雑な最適化計算に直面します。各ソリューションの基盤となるアーキテクチャ―メモリ内配置か分散処理か、増大するデータ量への対応方法―は、そのスケーラビリティとパフォーマンスに直接影響します。アーキテクチャの選択が不適切であれば、業務拡大に伴い、処理速度の低下や莫大なハードウェアコスト（またはその両方）につながる可能性があります。 各ベンダーにおけるスケーラビリティの主要なポイント：

• インメモリ対分散：主要なテーマのひとつは、ほとんどのデータをRAMに読み込むことで高速な計算を実現するソリューションと、より分散型でオンデマンドの計算（クラウドスタイル）を行うソリューションとの差です。Kinaxis、o9、Relex、および SAP IBP は強力なインメモリコンポーネントを有しています。キナクシスのエンジンは、すべての関連計画データをRAM上に配置し瞬時に再計算するという考えのもとで構築されており、一定の規模までは効果を発揮しますが、数テラバイト以上のデータをメモリ内に保持して拡張することは、非常に高コストで技術的にも困難になります。o9やRelexもまた、インメモリ設計により**「高額なハードウェアコストを伴う」**とされており ^{4 7}、実質的にはユーザーは巨大なRAMを搭載したサーバーまたはクラスタに対して費用を負担することになります。このアプローチは、10〜20年前にメモリが安価で、データサイズも控えめだった時代には有効でしたが、現在はメモリ価格が横ばいになり、データの複雑性が増しているため、将来性に乏しい戦略となっています。対照的に、Lokad は完全にクラウドベースであり、すべてのデータをRAM上に保持する必要はありません。必要に応じて、多数のマシンで並列処理を行い、その後リソースを解放するオンデマンドコンピューティングを活用することで、単一マシンのRAM上限に達することなく、非常に大規模な問題に対してスケールアウトすることが可能です。

• 大規模時のパフォーマンス：Blue Yonderの旧来モジュール（例としてSAPのAPOやJDAのレガシーシステムなど）は、時に大規模な問題に対して苦労し、運用前にデータの集約やセグメンテーションを要求されることがありました。新しいクラウド版（BY Luminate）は、メモリ管理や弾力的なスケーリングが改善されている可能性がありますが、その具体的な証拠は乏しいです。SAP IBP はHANAというインメモリ・カラム型DBを使用しており、大量のデータを扱えますが、非常に高いインフラコストが伴い、また計画実行を迅速に完了するためには、しばしばデータをあるレベルに集約する必要があります。Oracleのプランニング はリレーショナルDBをバックエンドとして利用し、一部の処理をディスクにオフロードできますが、計算ごとの処理速度は低下する可能性があります（ただし、Oracleはデータベースのチューニングを行っています）。ToolsGroup は、通常、単一サーバー上で数千から数万のSKUという中規模データセットを処理していましたが、非常に大規模なSKU数の場合、計算対象を慎重に限定しなければパフォーマンスが低下する可能性があります。最近はクラウド版に移行しており、スケールアウトが可能と推測されますが、コアアルゴリズムが分散コンピューティング用に再設計されたのか、単に大きなVM上にホスティングされただけなのかは不明です。

• 欠陥のあるアプローチ：「インメモリ設計」の欠陥は特に強調すべき点です。いくつかのベンダーは、サプライチェーン全体を巨大なメモリ上のモデル（OLAPキューブや巨大なスプレッドシートに相当）として構築するアプローチを取りました。これは中小規模のケースでは非常に高速ですが、線形にスケールせず、簡単に分散処理することができず、データの追加がメモリ需要の組み合わせ爆発を引き起こす可能性があります。Lokadのベンダー調査 では、o9やRelexの設計は「印象的なリアルタイム報告を提供する」一方で、本質的にハードウェアコストを押し上げ、グローバルな最適化問題への対応が難しいと指摘されています ⁷。同様に、キナクシスの文献も、かつて32ビットシステムで約4GBのRAMが制限要因であったことを示唆しており、現在は64ビットにより拡張されたものの無限ではないと認めています ²¹。根本的な問題は、データの増加速度がRAMの容量を上回っている点にあります。例えば、小売業者が2,000店舗と50,000 SKUに対し、店舗×SKU×日単位で計画を立てると、1億件のタイムシリーズとなり、その規模のインメモリキューブ（過去および将来を含む）は数十億セルに達し、現実的ではありません。分散処理により、店舗ごとまたは賢明なパーティショニングを行うアプローチの方が、よりスケーラブルです。

• 同時実行対バッチ処理：キナクシスの強みは、すべての計画データをRAM上で一斉に再計算する同時実行性にあります。これは対話型の利用には非常に効果的ですが、完全なモデルをRAM上に保持する必要があります。一方、バッチ処理型システム（例：夜間のLokad実行やToolsGroupの手法）は、課題を分割して並列処理することでスケール可能です。例えば、LokadのEnvisionは問題を複数のサブ問題に分割し、クラウド上で並列処理するため、リアルタイムの対話性を犠牲にしても、スケーラビリティと計算能力を提供します。業務のニーズに応じ、どちらの方式が望ましいかは異なりますが、最良の計画を追求するなら、膨大なシナリオ空間を夜間にバッチ処理する方法が、簡易なリアルタイム計算を上回る場合があります。

結論： Lokadのクラウドプラットフォームのようなソリューションは、水平スケーリングを前提に構築され、ビッグデータのボリュームに対しても限界に達することなく処理できる一方で、インメモリ中心のソリューション（Kinaxis、o9、Relex、SAP） は、データ複雑性の増大に伴い、スケーラビリティのボトルネックやコストの急騰というリスクを孕んでいます。これらを評価する企業は、自社のサプライチェーンデータの規模と将来的な成長を慎重に見極めるべきです。また、いくつかの新興「AI」計画スタートアップが、あえてインメモリのモノリスを回避し、マイクロサービスやビッグデータフレームワークを採用している点も注目に値します。さらに注意すべきは、パフォーマンスのチューニングが導入チームに委ねられることが多い点です―もしベンダーが、モデルをメモリ内に収めるために大幅なデータ集約や剪定を要求するなら、それはスケーラビリティ上の赤信号と言えるでしょう。本当にスケーラブルな技術は、詳細なデータを損なうことなく処理できるはずです。

技術統合と買収：統一プラットフォーム対フランケンスイート

ベンダーの歴史―自社で有機的にソリューションを構築したのか、買収を通じて拡大したのか―は、技術の一貫性と統合性に大きな影響を及ぼします。買収した多数の要素で構成される計画スイートは、異なるモジュールが異なるデータベース、ユーザーインターフェイス、あるいはプログラミング言語を使用する結果となり、全体としての一体感が損なわれがちです。我々は各ベンダーの背景を検証しました。

• Blue Yonder (JDA) は、買収による成長の最も明確な例のひとつです。これまでに、JDAはサプライチェーン計画アルゴリズムのためにManugisticsを、（2008年に決裂したものの）i2を、小売店舗のスペース計画のためにIntactixを、倉庫管理のためにRedPrairieを、そしてAI/ML予測のための新興企業であるBlue Yonderを買収してきました。これにより、現行のBlue Yonderソリューションスイートは寄せ集めの状態となっており、例えば、需要計画は旧Manugisticsエンジンを、フルフィルメントは別のシステムを、価格最適化は他の買収に由来するものとなっています。Lokadの調査では、「企業ソフトウェアはM&Aによって一体化することはなく…BYブランドの下には寄せ集められた製品群が存在する」 と指摘されています ¹³。彼らはこれらを、共通のUIや場合によってはAzure上の共通データ層を用いる「Luminate」プラットフォームの下に統合しようと試みていますが、根本的にはこれらをひとつのスムーズなシステムとして纏めるのは困難です。クライアントはしばしば一部のみを実装し、各モジュール間の連携にはカスタムの統合作業が必要となります。一貫性の欠如は必然的に生じ（例えば、あるモジュールは確率論的ロジックをサポートする一方、別のモジュールはそうでないなど）、分断された技術スタックは、矛盾する運用手法が同一スイート内に共存することを意味します（例として、BYの一部は先進的な機械学習を謳う一方、別の部分では20年前の安全在庫計算式を使用している）。

• SAP も同様に、自社開発と買収の両方を行ってきました。特に、SAPは2009年にSAF（予測ベンダー）を、2013年にSmartOps（在庫最適化ベンダー）を買収し ¹⁶、さらに従来はAPOを社内で開発していました。これらはすべて、SAPのIntegrated Business Planning (IBP) クラウド提供に統合されました。その結果、SAP IBPは、予測、在庫、供給といった異なるモジュールを持ち、ひとつの傘の下にあるものの、時として別々の製品のように感じられます。予測ではSAFのアルゴリズム、在庫最適化ではSmartOpsの論理が使用されることがあり、ピアレビューではSAPのスイートは*「製品群の集まり」*と称され、複雑性が高いため「最高のインテグレーターと数年の期間」が必要と警告されています ²²。言い換えれば、統合は実装チームに委ねられ、すべてのコンポーネントをシームレスに連携させるのは容易ではありません。

• Kinaxisは、これまでほぼ自社内開発で作られており、主要製品RapidResponseは数十年にわたり内部で開発されてきました。これにより、非常に統一感のある（1つのデータモデル、1つのユーザーインターフェース）製品となりました。しかし、過去3～4年間で、Kinaxisは戦略的な買収やパートナーシップを通じて不足していた部分を補っています。例として、確率論的在庫最適化のためにWahupaと提携¹⁷、AI予測のためにRubikloudを買収、そして2021年にサプライチェーン分析プロバイダーのPranaを買収するなどです。Kinaxisはこれらを拡張可能なプラットフォームを通じて統合しており（ユーザーインターフェース上で「ノーコード」統合をうたっています）が、実際にはこれらは接続された別々のエンジンです。たとえば、WahupaのMEIOはRapidResponse内のネイティブコードではなく、サービスとして動作する可能性があります。時間が経つにつれてKinaxisはこれらをより密接に統合する可能性もありますが、予測変動データをWahupaのエンジンに供給し安全在庫レベルを返す、といった緩い連携に終始するリスクは常に存在します。多数の買収を重ねているベンダーと比べても、Kinaxisは比較的一体感がありますが、フランケン・スイートの道を辿らないか注視する価値があります。

• o9 Solutionsは創業者（元i2のメンバー）によってほぼ自社内で構築されています。同じ基盤上で開発されたモジュールを持つ単一のプラットフォームです。o9はほとんど買収しておらず（一件はサプライチェーンネットワーキング企業の小規模な買収、最近ではAI/MLスタートアップのProcessiumを買収しましたが、計画アルゴリズムにおいては大きな買収はありません）。したがって、o9の技術スタックは古参競合他社よりもより統一されたもので、すべてがo9 Enterprise Knowledge Graph上に存在し、同じUIフレームワークを使用しています。これは一貫性という利点があります（データベーススキーマの重複がないなど）が、もし技術の一部が弱い場合、買収で簡単に解決できず、内部開発で補う必要がある点が欠点です。これまで内部開発で対応してきましたが、その過程で（例えば、内在する平凡な予測手法などの）制限も浮き彫りになっています。

• ToolsGroupは主にSO99+製品を中心に有機的に成長しました。我々の知る限り、他のプランニングベンダーの大規模な買収は行っていません。そのため、需要予測、在庫最適化、補充モジュールは一体となって設計されています。結果として、ややモノリシックではありますが一貫性のあるアプリケーションとなっています。ToolsGroupにとっての課題は近代化であり、2010年代にはそのアーキテクチャとUIが時代遅れでしたが、その後クラウド移行とインターフェースの更新に取り組んできました。それでも一体感があるという点は、ToolsGroupが比較的シンプルで、他のツールを組み込む必要なく、サービスレベル最適化をエンドツーエンドで提供できる理由の一つです。

• Relex Solutionsも小売業向けにゼロからプラットフォームを構築しました。隣接分野の企業（直近では労働力管理ソリューションや店舗スペースプランニングソリューション）の買収はありましたが、主要な予測および補充エンジンは自社開発です。そのコアは統一されており（すべてのデータが同じインメモリDBに格納されているため、任意の指標をリアルタイムでユーザーに表示できます）、新分野での買収は統合の隙間を生む可能性があるものの、Relexは古参ベンダーの買収ラッシュからはまだほど遠い状態です。

断片化されたスイートの主要な問題は、単に技術的負荷が大きいだけでなく、機能的な不整合にもあります。たとえば、あるモジュールが（安全在庫を伴う）決定論的プランニング向けに設計され、別のモジュールが確率論的な入力を前提としている場合、両者は衝突する可能性があります。具体的には、ある買収による在庫最適化モジュールが安全在庫を計算し、別の買収による需要計画モジュールがそのUI上でどう扱うか分からず、混乱や重複入力を引き起こすケースがあります。実際、ベンダーがマーケティング上で確率論的予測を推進しているにもかかわらず、セールス＆オペレーション計画モジュールではMAPEを追跡し、単一の数値によるコンセンサス予測を用いているといった、製品系統の違いに起因する内部矛盾も見受けられます。

これに対して、一貫性のあるプラットフォームを持つベンダーは、たとえば確率論的手法への全面的な移行などの変更を容易に実施できます。LokadはすべてをEnvision言語とクラウドバックエンドで構築し完全に統一されているため、内部矛盾なく確率論的最適化に焦点を当てたメッセージを打ち出せるのは非常に示唆に富んでいます。同様に、一般的なプランニングプラットフォームであるAnaplanも技術的には非常に統一され（一つのHyperblockエンジンを採用）ていますが、専門のサプライチェーンアルゴリズムは欠けているため、Anaplanの一貫性は評価できますが専門性には限界があります²³。

したがって、技術の観点からは、多数の合併で生まれたスイートには注意が必要です。予測部分と計画部分が本当に同じエンジンまたはデータモデルを共有しているのかを確認すべきで、そうでなければ、統合上の苦労や潜在的に矛盾する出力が生じる可能性があります。

技術的信頼性：AI/MLハイプを見抜く

すべてのベンダーが「AI駆動のサプライチェーン」や「機械学習による予測」を謳う現代において、彼らがこれらの主張をどのように裏付けているかを精査することが不可欠です。我々は、査読付きの研究、文書化された独自アルゴリズム、オープンソースへの貢献、または中立的なベンチマークでの実績など、先端技術の具体的な技術的証拠を求めます。また、単なるif-elseルールに過ぎないものをAIと呼ぶなど、バズワードの誤用もチェックします。以下は各ベンダーの状況です：

• Lokadは高い技術的信頼性を示しています。単にAIを謳うだけでなく、そのアルゴリズムを解説するコンテンツ（例えば、M5コンペで優勝した予測モデルの仕組みを詳細に説明する講義²⁴など）を公開しています。同社のCEOやチームは、なぜ分位点予測のアンサンブルやピンボール損失の使用などの手法が採用されるのかについて、ブログや講義を通じて技術的議論に参加しています。また、M5のようなコンペの限界や実際のサプライチェーン問題がいかに異なるかを公然と認めることで^{25 26}、これは単なるマーケティングの飾りではなく、真剣なエンジニアリングの姿勢を示しています。さらに、Lokadの革新的な中核技術であるEnvisionプログラミング言語は、単なる汎用MLではなく、サプライチェーン最適化のために作られたドメイン固有言語という独自の技術成果物です²⁷。これは外部者が評価できる具体的な技術であり、その一部は公開されています。Lokadは有料アナリストの引用に頼らず、手法のピアレビューを招いています。このオープンさと、スローガンよりも科学を重視する姿勢が、信頼性の金字塔を築いています。

• 一方、Blue YonderはAIに関して曖昧な言葉を使う傾向があり、「LuminateプラットフォームにAI/MLを組み込む」といった表現をするものの、どの技術やモデルが使われているかの詳細な説明はありません。Lokadの調査では、Blue Yonderの**AI主張には『ほとんど実質がない』**と明言され、入手可能なわずかな成果物は、**従来型の予測手法（ARMA、回帰分析）**に依存していることを示唆しています¹⁴。例えば、BYが「需要の変動を感知するためにAIを使用している」と主張しても、実際には数十年前の技術である最近の売上高に対する線形回帰を用いているのであれば、AIという言葉は過剰な表現となります。さらに、tsfreshのような時系列特徴抽出のオープンソースプロジェクトが存在することは、透明性という点でBYに有利ですが、これらのプロジェクト自体はよく知られた汎用ツールであり、独自の革新ではありません。BYのデータサイエンスチームから公開された成果やコンペの実績がないことも、彼らの主張がよりマーケティング寄りであることを示唆しています。要するに、Blue Yonderは重厚なAIブランディングを裏付ける説得力のある技術的証拠を提供しておらず、これは信頼性に対する赤信号です。

• o9 Solutionsも同様に懐疑的な見解を呼び起こします。彼らは差別化要素としてEnterprise Knowledge Graph (EKG)の概念を掲げ、これはデータの関係性を捉える一種のAIであると示唆しています。グラフデータベースは有用ですが、データをグラフとして保存すること自体に『予測の天才性』があるわけではなく、その上に乗るアルゴリズムが重要です。Lokadの調査では、o9がグラフに基づく予測主張は科学文献によって裏付けられていないと指摘しています²⁸。さらに、o9のGitHubを詳しく調べても革新的なアルゴリズムは見つからず、彼らのAIに関する議論は、多くの他社も備えるような汎用的な能力（「高度な分析」や「MLによる予測」）にとどまっています。彼らは「デジタルブレイン」「AI/ML」「knowledge graph」といったバズワードを使っていますが、外部の検証が伴っていません。o9が他社を上回るMLモデルの詳細なホワイトペーパーを公開するか、厳密なデータで顧客事例が文書化されるまでは、o9のAIは主にハイプに過ぎないと考えるのが最も安全でしょう。さらに、サプライチェーンコミュニティでは、深層強化学習による供給最適化や新規の確率モデルなど、本当に革新的なAI概念は通常、学術的またはオープンなフォーラムで議論されるものであり、o9がそうした場で発表していないことは、独自技術の不足を示唆しています。

• Kinaxisはマーケティングにおいて比較的控えめであり、全ての文章で「AI」を過剰に使わない点は、誇大表現が少なく良い面といえます。しかし、AIパートナーとの統合が進むにつれて、AIの強調が増しています。好例として、WahupaのCEOと共著で執筆されたブログ記事^{29 30}があり、確率論的手法と統計的手法について議論する中で、Kinaxisが科学に深く踏み込む姿勢（確率論、意思決定時の不確実性などへの言及）を示していることが分かります。これは、彼らが堅実な方法論に基づいて製品提供を行おうとしていることを示唆しています。しかし、Kinaxisはその手法の結果について自らを証明する必要があり、例えば「新しいML予測が旧来の手法に比べてX%精度向上」を詳細に公表していないのは、まだ統合過程にあるためと考えられます。つまり、Kinaxisの信頼性は移行期にあり、かつては予測技術のリーダーであると主張していなかったため誤解を招くことはなかったものの、今や高度な分析を謳う以上、証拠を待つ必要があります。少なくとも、Wahupaとのパートナーシップは、外部の専門知識が必要であったことを認めるものであり、これは信頼に足るものです（確率論を極めていると偽るのではなく、専門家を迎え入れたのです）。

• ToolsGroupは残念ながら、実体の裏付けなくAIバズワードに便乗したため、その信頼性を損ねました。調査では、彼らのAI主張が**「疑わしい」とされ、公開資料においても2000年前のモデル**の示唆が見られると指摘されています¹¹。これは、ToolsGroupが既存機能を単に「AI」として再ブランド化しているに過ぎない可能性を示唆します。たとえば、ToolsGroupが「需要感知のためのAI」を宣伝していても、実際の調査ではそれが単に最新売上に重みを置くルールでしかなく、真のAIではなくアルゴリズムの微調整に過ぎない可能性があります。詳細な情報が公開されていないため、疑いを払拭するのは難しいです。彼らの信頼性は、確率論的在庫モデルで真に先行していた2000年代初頭の頃は高かったものの、現在は停滞の可能性に苦しんでいます。

• SAS（我々がトップにはランクしていないものの候補に入っている）は、一般的に技術的信頼性は高く（統計学の長い歴史を持つため）評価されますが、その反面、コア技術が古いという側面があります。SASの予測手法は十分に文書化されており（多くの統計手法に関する教科書を実際に執筆している）、しかしそのため最新の機械学習技術を組み込むには、SASでのカスタム作業が必要となる可能性があります。Lokadの調査は、SASを先駆者として認めつつも、現在はPythonノートブックなどのオープンソースツールに取って代わられていると示唆しています³¹。SASは通常、過剰に売り込むことはなく、その評価は評判に依存していますが、サプライチェーンソリューションとしては市販されることは少なく、企業がSASを用いてカスタムソリューションを構築するケースが多いです。

• 一般的な観察：ベンダーの技術に対する誠実さを試す簡単な方法は、彼らが時折、自社技術の限界や適切な使用事例を認めるかどうかを見ることです。マーケティング色の強いベンダーは、AIが全てを解決すると主張しますが、本物の技術を持つベンダーは「これができること、そしてこれがうまく機能しない可能性がある領域」を明確に示します。たとえば、Lokadは特定の需要に対してなぜあるモデルが機能しないのか（断続的需要に対する手法の失敗理由など）を頻繁に議論し、知的誠実さを示しています^{26 32}。Lokad以外でそのような微妙な公開議論に応じるベンダーはほとんどなく、大多数は楽観的な一般論に終始しており、これは賢明な顧客にとっては警戒すべき点です。

結論として、技術的実力の具体的証拠―例えばコンペティションでのランク、詳細な技術ブログ、あるいはユーザーコミュニティでの議論など―は、多くの大手ベンダーにおいて乏しいのが現状です。Lokadは（M5優勝、公開解説など）証拠の提供において先頭に立っており、Blue Yonderやo9などは、時代遅れの技術をほのめかすハイプを提供しているため、彼らの主張する「AI革命」に疑問が投げかけられます¹⁵。見込み客は、ベンダーに対して、彼らのアルゴリズムがどのように動作し、なぜ優れているのかを具体的な用語で説明するよう要求すべきであり、もし回答が単なるバズワードの寄せ集めであるならば注意すべきです。本当のサプライチェーンにおけるAI/MLの価値は、実証可能である必要があります（例：「我々は勾配ブースティングツリーを用いて天候のような非線形の需要ドライバーを捉え、1000SKUにおいて基準値比5%の改善を証明した」―このような表現は「我々のAIはデータ中の隠れたパターンを見つけ出す」に比べ説得力があります）。

ベンダーのアプローチにおける一貫性と矛盾点

A表面的な革新の明白な兆候は、ベンダーのメッセージや手法に内部矛盾が含まれている場合です。我々はそのような矛盾、例えば不確実性を説きながら決定論的な指標で成功を測ったり、旧来の手法を排除すると主張しながらも内部では使用し続けたりする例を調査しました。注目すべき発見は以下の通りです：

• 確率論的手法 vs 決定論的手法の指標: 述べたように、ToolsGroupはこの点で問題があり、確率論的予測能力を謳いながらもMAPE（平均絶対パーセンテージ誤差）の低減という結果を示しています¹²。MAPEは一点予測誤差の指標であり、真に確率論的予測を行っているならば、キャリブレーション、確率論的対数尤度、分位点に対するピンボール損失、または少なくとも達成されたサービスレベルについて語るはずです。MAPEに固執することで、ToolsGroupは本来の確率論的な主張と矛盾してしまっています。この矛盾は、「確率論的」出力が単に変換された決定論的予測であるか、またはR&Dが十分に採用していないマーケティング的なオーバーレイであることを示唆しています。

• デマンドセンシング・ハイプ: 多くのベンダーは、最新トレンドを捉える特別な短期予測（例えば、最新の販売状況や外部シグナルの活用）を持っているかのように示すために「デマンドセンシング」という用語を用いる。ToolsGroup、SAP、およびGAINSystemsはこの用語を使用している。本研究では、これらの「デマンドセンシング」に関する主張は、文献で裏付けられていない**「バポウェア」**であることが多い ³³。もしもベンダーが「我々のAIは3か月先の需要変動を察知する」と主張しながら、その方法を説明できず（また、査読付きの研究でその信頼性が確認されていない場合）、それは警告すべきサインとなる。同じベンダーが、依然として基本的な時系列モデルを併用している場合、矛盾が生じる。つまり、標準的な指数平滑予測に先週の調整を加え、それを「センシング」と称しているのである。これは、些細な調整を突破口と誇張している矛盾点である。

• 決定論的KPIの使用: ベンダーのケーススタディやインターフェースが、AI/MLを強調しているにもかかわらず、MAPE、バイアス、トラッキングシグナルなどの決定論的KPIに依拠していないか注視せよ。例えば、あるベンダーが機械学習を謳いながらも、デモではプランナーが予測MAPEの改善やABCセグメンテーションを用いて安全在庫を設定している場合、それは矛盾している。真のML駆動の確率的計画では、期待コスト、品切れ確率、またはその他の確率的指標に焦点を移すはずであり、伝統的なMAPEやABC分類（予測可能で静的な需要を前提とするもの）には依存しない。我々は、大手ベンダーのマニュアルにおいて、ある章では新しいAIモジュールを論じながらも、別の章でARIMAパラメータや安全在庫ルールの調整を指示しているという二面性を確認した。

• 安全在庫の理念: 不確実性管理を謳いながらも、依然としてプロセスの中心に「安全在庫」を据えるベンダーには重大な哲学的矛盾がある。安全在庫の概念は、決定論的な予測にバッファを加えたものである。完全に確率論的な枠組みでは、需要分布とサービス目標に基づいて最適な在庫レベルを直接算出する（これにより「基本在庫」と「安全在庫」が一体となる）のが理想である。もしベンダーが「我々はAIで在庫を最適化する」と主張しながら、ユーザーに「希望するサービスレベル」を入力させ、正規分布の仮定に基づいて安全在庫を算出しているならば、実際には旧来の手法に新たな名称を与えているにすぎない。例えば、Blue Yonderの在庫最適化は（歴史的には）分散とサービス目標に基づき安全在庫を計算するが、これは本質的な確率的最適化ではなく、単なる数式の適用に過ぎない。Lokadのようなベンダーは、真の確率的最適化では、需要分布に対応してすべての在庫が機能すべきであり、「安全」と指定された部分のみを区別すべきではないと明言している。従って、もしあるベンダーが「次世代プランニング」を売り出しながらも、解決策ガイドで安全在庫の設定維持を要求するならば、それは一貫性の欠如を示している。

• AIマジック vs. ユーザーコントロール: 一部のベンダーは同時に「我々のAIが自律的にサプライチェーンを運営する」と「ユーザーにプランニングプロセスの完全な制御と可視性を提供する」と主張している。バランスは必要だが、過度に広範な主張は矛盾を引き起こす。もしAIが真に自律的ならば、ユーザーが常時監視する必要はなく、逆にユーザーが常に微調整を行わなければならなければ、それは自律的とは言えない。マーケティングはしばしば「オートパイロットとマニュアルオーバーライドの両立」を約束するが、実際のところ、システムはどちらか一方に傾く傾向がある。特定のベンダーを指摘するわけではないが、全自動の約束とともに、多数のプランニングパラメータのスクリーンショットを提示し、ユーザーに設定を求める姿勢は、矛盾したメッセージを発している。

我々の調査では、矛盾に対処する明確な例として、Lokadが主流とどのように自らを差別化しているかが挙げられる。Lokadは教育コンテンツにおいてMAPEなどの指標や安全在庫の概念を明確に批判し、それに基づく方法論（確率的指標の使用と意思決定の直接計算）を展開している ^{12 32}。これに対して、GAINSystemsのようなベンダーは最適化指向を謳いながらも、依然としてデマンドセンシングや旧時代のマッチングアルゴリズムなどを強調しており ³³、まさに二兎を追う状況にある。さらに、John Galt Solutionsは独自の予測アルゴリズムが他を凌駕すると主張するが、独立したランキングには現れず、査読論文によればオープンソースと大差ない可能性がある ¹⁹。これは、主張と証拠との間に矛盾があることを示している。

まとめると、ベンダーを評価する際には内部の一貫性を確認することが重要である。すなわち、彼らが説いていることを実際に実践しているかどうかを見極めるべきである。もしあるベンダーが不確実性と最適化について大きく謳っているなら、その資料が同時に決定論的な指標や単純な手法を賞賛していてはならない。不一致は、いわば「新しい考え方」が表面的なものであることを示唆している。

時代遅れの手法: 旧態依然としたプランニングのレッドフラッグ

サプライチェーンプランニングは進化しており、かつて標準とされた手法が、現代の能力を踏まえると時代遅れまたは最適とは言えないとみなされることがある。あるベンダーが依然としてそのような手法に依存しているかを見極めることは重要である。以下は、いくつかの時代遅れ（もしくは少なくとも「旧式」の）手法と、各ベンダーの立ち位置である：

• 安全在庫を頼りにする手法: 先に述べたように、安全在庫を予測に付加する独立したクッションとして扱うのは、古いアプローチである。安全在庫そのものが「悪い」のではなく、変動に対するバッファは常に必要だが、現代の手法は変動性を直接組み込む。もしあるベンダーの基本手法が「指数平滑法で予測し、その後、安全在庫 = zスコア * シグマ * リードタイムの平方根を計算する」ものであれば、それは1960年代の理論が今なお適用されていることを意味する。例えば、SlimstockのSlim4はこのような主流の数式（安全在庫、EOQ）を誇示し、率直に採用している ³⁴。Slimstockは、AIを使っているふりをするのではなく、「日常だが重要な実務」に焦点を当てている点で正直さが評価される ³⁵。しかし、技術リーダーシップの観点から見ると、これらの手法は時代遅れである。LokadやWahupa（Kinaxisのパートナー）は、周期在庫と安全在庫という人工的な区分を廃し、確率モデルから直接最適な再発注点／数量を算出する方向へのシフトを主張する。多くの既存ツール（SAP、Oracle、旧JDAなど）は、今なお安全在庫パラメータに依存している。これは、基盤となる数式があまり変わっていないことを示す警告サインである。真に最適化に基づくシステムであれば、在庫コストと品切れコストを入力し、政策を解く形で、あえて「安全在庫」と明示することなく、各品目ごとに最適な在庫レベルを出力するはずである。

• MAPEおよび決定論的指標: MAPE、バイアスなどを成功の主要な尺度として用いるのは時代遅れといえる。なぜなら、これらの指標は直接的にビジネス成果と連動せず（例として、MAPEが低くてもサービスレベルが悪い可能性がある上、不確実性を無視している）、また、予測に対してピンボールロス（分位点ロス）や、計画に対しては期待コストなどの新しい指標が好まれているためである。もしも、あるベンダーのケーススタディで「予測精度を70%から80%のMAPEに改善した」とする基準が用いられているならば、それは過去に固執している証左である。John Galtによる予測精度の強調も同様の傾向にあり（同僚から疑問視されたこともある） ¹⁹。現代的な視点では、「同じサービスレベルで品切れをX%、在庫をY%削減した」とする結果に基づくアプローチが求められる。

• ヒューリスティックなセグメンテーション（ABC、XYZ）: 旧来のプランニングでは、アイテムを取扱量（ABC）や変動性（XYZ）で区分し、各グループに対して異なるプランニングパラメータを適用していた。これは、限られた計算能力や単純なモデルに対処するためのヒューリスティックであり、Aランクのアイテムには一つのアプローチ（おそらく手動での注視）を、Cランクのアイテムには別のアプローチ（例えば、ミンマックスルール）を適用するというものである。しかし、各SKUを個別かつ連続的に最適化できる計算能力があれば、このセグメンテーションはやや時代遅れとなる。手動でのABC分類や、「ラフか滑らかか」などと需要を分類させるシステムは、異なる需要パターンを自動的に堅牢に処理するアルゴリズムがないための頼りにしている可能性がある。多くの既存システム（そして一部の新しいシステム）では、いまだにこの手法が用いられている。理想的には、AI駆動のシステムはSKUごとのパターンを自動で学習し、人間による分類を不要とするはずである。

• 日常的な手動による予測の上書き: 従来の需要計画では、マーケティング情報などに基づいて統計予測を定期的にユーザーが上書きすることが前提とされる。人間の判断は重要であるが、もしシステムの予測精度が極端に低く、プランナーが各サイクルで多くの予測を全面的に見直さなければならないのであれば、そのシステムは本質的に旧来のアプローチである。現代のシステムは、より多くのデータを取り込むことにより（例えば、プロモーション情報を既に認識しているなど）上書きを最小限にすることを目指している。予測をユーザーが手動で調整しやすいというベンダーの強調は、そのアルゴリズムが初期状態では信頼に足らないことを示唆している可能性がある。近年の傾向は、例外的な場合にのみ上書きを行う形態にシフトしている。

• スプレッドシート依存: もし、あるベンダーのソリューションが、最終的な分析のためにユーザーにデータをExcelへエクスポートさせたり、Excelをインターフェースとして使用させたりする場合（中堅市場向けのツールの中にはある）、これは未成熟なソリューションの兆候である。先進的なツールは、必要な分析および意思決定支援をプラットフォーム内で全て提供する。（Anaplanは興味深い例で、実質的には強化されたクラウドスプレッドシートであり、制御されたマルチユーザー環境の中でスプレッドシートのパラダイムを採用している。これは、モダンでありながら同時に旧式の側面も併せ持つ。）

我々が収集したデータによれば、Slimstockは意図的に古くからあるが実証済みの手法（安全在庫、EOQ）を使用している ³⁴。率直な姿勢は称賛に値するが、これらの手法は確率論的最適化の前では時代遅れと言える。あまり知られていないが長年続くベンダーのGAINSystemsも、古典的な予測モデルに固執しており、彼らが謳うML機能（「マッチングおよびクラスタリング」など）も2000年前の技術 ³³であることから、内部に新しい工夫がほとんど見られない。さらに、LokadによるGAINSystemsのレビューは、これらを明確にバポウェアと位置付け、実際に時代遅れまたは効果が見込めないと評価している ³³。

Blue YonderとSAPは、多くのレガシーを引き継いでいる。例えば、SAPの多くの実装では、依然としてABCを用いて異なる安全在庫レベルを設定したり、低需要時に単純移動平均予測を使用したりする。もし新たな「機械学習を用いたIBP」がこれらの基本を刷新しないのであれば、実質的には新瓶に詰め替えた旧いワインと同じである。

革新を謳いながらMAPEを使用するなど、矛盾する指標の存在は既に一貫性の欠如として論じたが、それは同時に旧来の指標に固執している証拠でもある。

結論として、最先端のソリューションを求める企業は、依然として安全在庫パラメータ、ABCセグメント規則、そして予測精度の％を主要なKPIとしているベンダーには注意すべきである。これらは、そのソリューションが前世紀の手法に根ざしている兆候である。むしろ、サービスレベル、コスト、確率といった、現代のサプライチェーンサイエンスの言語を強調するベンダーを選ぶべきである。

意思決定志向の予測: 予測から行動へ

最後に、各ベンダーが単に予測を行っているのか、あるいはその予測に基づいてユーザーが最適な意思決定を行うのを実際に支援しているのかを評価する。サプライチェーンにおける最終目標は、美しい予測そのものではなく、サービスを最大化しコストを最小化するために、適切な行動（発注、在庫管理、スケジューリング）を取ることである。予測および関連する制約／コストを踏まえた最適化済みの推奨事項（発注数量、生産計画、在庫目標など）を直接出力するソリューションを「意思決定志向」と呼ぶ。以下は、各ベンダーの比較である：

• Lokadは非常に意思決定志向である。実際、彼らは予測そのものの重要性を軽視し、「予測は優れた意思決定につながって初めて価値がある」という暗黙の理念を貫いている。LokadのEnvisionを使用すれば、需要の予測で終わることなく、確率的予測の下で、例えば100ユニット発注と200ユニット発注という複数の候補に対して期待利益やペナルティを計算し、期待される成果を最大化する意思決定を選択する。ユーザーへの出力は「需要は120になる」ではなく、「例えば130ユニットを発注せよ」とその根拠（予測分布とコストパラメータを考慮して品切れリスクと在庫過剰リスクのバランスを取るため）とともに提示される。これはまさに指示的、すなわち意思決定中心の分析である。Lokadは、予測が直接実行に反映されることを保証し、MOQ、賞味期限、予算制限といった制約も最適化に組み込んでいる。したがって、Lokadは予測を行動に移すための要件を明確に満たしている。

• ToolsGroupも意思決定志向であり、特に在庫および補充の意思決定に焦点を当てている。彼らのSO99+ツールは単に予測を行うのではなく、サービスレベル目標を達成するための在庫水準や再発注点を推奨する。実際、ToolsGroupの実装では、各SKUに対して「Xユニットの安全在庫を維持し、在庫がYまで減少したら再発注すべきであり、結果として現在Zユニットの注文となる」といった推奨が出力される。これは、予測に基づいて導かれた意思決定（補充数量）である。従って、ToolsGroupは常に単なる予測ではなく、指示的な出力を提供している。ただし、意思決定の対象は主に在庫政策に限られており（生産計画の最適化も行っているが、流通分野が得意である）、また、ToolsGroupの推奨は予測の不確実性のモデル化に左右される（これについては批判している）。とはいえ、ToolsGroupはユーザーが予測を元に手動で発注を決定することを求めず、その計算を自動化している点は評価に値する。

• Blue Yonderおよびその他の従来型スイートでは、予測モジュールと計画モジュールが分離されることが多いです。たとえば、BY Demand が予測を行い、その後 BY Supply（または Fulfillment）がその予測を用いて計画を算出します。統合実装の場合、最終的には（マスタープロダクションスケジュールや配備計画のような）意思決定の推奨結果が得られます。Blue Yonderは完全な計画最適化モジュールも提供しており、たとえばFulfillmentモジュールは、中央倉庫からDC（ディストリビューションセンター）への補充方法を推奨します（実質的には、予測と在庫データを用いて計画注文を作成するDRPエンジンです）。また、Production planningモジュールは最適化された生産順序やスケジュールを作成できます。つまり、BY全体としては意思決定を網羅していますが、これらの意思決定がどれほど最適で統合的であるかは、すべての要素が実装され、調整されているかに依存します。過去には、あるモジュールの出力が次のモジュールにとって必ずしも最適ではなかった（例えば、予測が供給計画で直面する制約を考慮していなければ、実現不可能な計画が生じる）という批判がありました。真に意思決定指向のアプローチでは、これらの制約を予測時または統一的な最適化の中で考慮する必要があります。Blue Yonderの「自律的サプライチェーン」という新たなメッセージは、ループ（予測から意思決定への自動的な流れ）を閉じることを意味しますが、技術の混合状態を考えると、そのシームレスさは明確ではありません。

• Kinaxisは非常に意思決定・アウトプット志向であり、その主な目的は、実行可能な計画（供給計画、在庫予測など）を迅速に生成することにあります。ユーザーは通常、これらの計画をもとに意思決定を確認または調整（例：注文の早期手配や供給の再配分）します。Kinaxisの新機能MEIOの追加により、特に在庫バッファ、すなわち資金とサービスのバランスを考慮して安全在庫レベルを推奨するという一連の意思決定が明確に最適化されるようになりました ³⁶。従来、Kinaxisでは異なる安全在庫シナリオをシミュレーションしてその結果を示すのみで、必ずしも最適なものを提示するわけではありませんでしたが、確率論的MEIOにより数学的に最適なものを探し出そうとします。その他の分野（たとえば生産や流通計画）では、Kinaxisは内部でヒューリスティックスや最適化（スケジューリングや割り当てのための最適化ソルバーを一部搭載）を用いますが、Kinaxisの強みの多くは厳密な最適化というよりもシミュレーションにあります。つまり、ユーザーの意思決定の結果を極めて迅速にシミュレーションできますが、どのシナリオを採用するかはしばしば人間に委ねられます。まとめると、Kinaxisはほぼリアルタイムで推奨アクション（計画注文、再スケジュールなど）を一通り提示する、確実な意思決定支援システムですが、MEIOのような特定の機能や、明らかな場合を除き、人間の入力なしに自動的に「最適な」計画を選択するわけではありません。

• o9 Solutionsもまた、需要、供給、在庫などにまたがる計画（すなわち一連の意思決定）を生成することに注力しています。o9は、制約下でコストを最小化または利益を最大化するための線形計画法など、特定の問題に対して最適化エンジンを備えています。これは、リソースの最適な配分を見出すという「デジタルブレイン」コンセプトの一部です。しかし、すべてのo9顧客がこれを最適化された形で利用しているわけではなく、中には協調計画のためにそのプラットフォームを利用する、つまり基本的には手動の意思決定であってもより良いデータ可視化を享受する場合もあります。問題は、o9がネイティブに確率論的な意思決定最適化をサポートしているかどうかです。おそらく強くはサポートしておらず、シナリオ分析（「もし10%余分に生産したら、結果はどうなるか？」）は行うものの、必ずしもシナリオ全体の期待値を計算するわけではありません。つまり、意思決定指向ではある（推奨するサプライチェーン計画を提供する）が、不確実性下での最適性については明確ではありません。

• Relex Solutionsは、小売業に特化しているため、主要なアウトプットは店舗またはDCへの注文と在庫目標です。Relexは、予測とパラメータに基づいた自動補充システムとして、これらの意思決定を直接生成する点で優れています。また、棚スペースの配分と在庫のような、小売業特有の意思決定上のトレードオフ（例：スペースが限られている場合、在庫と品ぞろえのバランスの取り方）も、統合計画・スペースプランニングアプローチにより最適化可能です。Relexの意思決定は主にユーザー設定のルール（サービスレベル目標や供給日数など）によって駆動されますが、システムはこれらのルールを満たす実際の注文を算出するための数値計算を行います。決して単に「今週の予測は100ユニット」と表示するだけではなく、現在の在庫が50で予測が100、かつリードタイムなどを考慮して、小売業者に今すぐ50ユニットの追加注文を行うよう指示する、まさに意思決定指向のシステムです。とはいえ、Relexは場合によっては戦術的すぎる（適切な再注文は行うが、長期的なネットワーク全体の影響は十分に考慮しない―各ノードは局所的に最適化される）可能性もあります。

要約すると、意思決定指向の予測こそが、単なる分析ツールと真のサプライチェーン最適化ソリューションとの差異を生み出す要因です。トップクラスのすべてのベンダーは、単なる予測ではなく意思決定のアウトプットを提供することを目指しており、これが本研究の対象に含めた理由です（研究概要では、意思決定を最適化しない純粋なトランザクションまたは予測ツールは除外すると明記されています）。ただし、これらの意思決定における最適性や不確実性の統合の度合いは異なります：

• LokadとToolsGroupは、コストやサービス目標を用いて予測と意思決定を明示的に結び付けています（Lokadは期待コストを最適化するカスタムスクリプトを通じ、ToolsGroupはサービスレベル目標に基づいて在庫の意思決定を導き出します）。
• Kinaxisとo9は包括的な計画を生成し、意思決定の検討を可能にしており、Kinaxisは最近、より正式な最適化（在庫最適化など）を追加しました。
• Blue Yonderは、意思決定を生み出す個別の最適化モジュールを持っており（完全に活用すれば、あらゆる計画が得られますが、それらを連携させるのは手間です）。
• Relexは、特定の意思決定群（補充）を非常にうまく自動化しますが、他の分野（長期的なキャパシティプランニングなど）では劣る面があります。

ソリューションを評価する際、企業は次の点を問い詰めるべきです：「システムが予測を行った後、どのような意思決定を推奨し、それらが最適であることをどのように保証するのか？」 もしベンダーが明確な回答を示せなかったり、ユーザーが予測を手動で解釈せざるを得ない場合、そのベンダーは真に最適化指向とは言えないでしょう。この問いは、例えば、洗練されたML予測が実際に在庫削減につながるのか、単にグラフ上の見栄えの良い数値に過ぎないのかを明らかにします。

結論

本比較研究では、主要なサプライチェーン計画および予測ソフトウェアベンダーを技術的視点から評価し、マーケティング上の約束よりも実際の能力を重視しました。評価の結果、この分野での技術的リーダーシップには、証拠に裏打ちされた先進的な予測（できれば確率論的なもの）、スケーラブルで現代的なアーキテクチャ、高度な自動化、統一され精緻に設計された技術スタック、そして何よりも処方的意思決定への注力が必要であることが明らかとなりました。

Lokadは、確率論的予測の先駆的な取組みと意思決定最適化に対する徹底したフォーカスにより、主要リーダーとして浮上しました―これは外部のベンチマーク（例：M5コンペティションでの勝利）や透明性のある技術コミュニケーションによって実証されています ^{3 2}。この事例は、MAPEのような指標や安全在庫の概念に対する懐疑が、健全な経済学に基づいたより頑健なソリューションにつながることを示しています ^{12 32}。

Kinaxisやo9 Solutionsのような他のベンダーは、AI/MLへの多大な投資と非常に幅広いプラットフォームの構築を進めていますが、その「AI」が表面的なものでなく、かつ高額なコストをかけずにシステムがスケールすることを市場に納得させる必要があります ⁴。また、Blue Yonder (JDA)やSAPのような長年のプレイヤーは、豊富なサプライチェーン分野の経験と機能を持っていますが、多数の買収による断片化されたシステムや時代遅れのアルゴリズムというレガシーが露呈し、矛盾や技術革新の進展の遅さを招いています ^{13 16}。さらに、ニッチ専門のToolsGroupやRelexは（それぞれ在庫最適化、小売の補充において）強力なソリューションを提供していますが、それぞれに限界があり、ToolsGroupは自社のAI主張を最新技術で裏付ける必要があり ¹¹、Relexのインメモリアプローチはその適用領域外では弱点を露呈するかもしれません ⁷。

分析から明らかになったのは、技術的詳細や結果をオープンに提供するベンダーが、バズワードに依存するベンダーよりも信頼を集めるということです。誇大宣伝が蔓延するこの分野では、意思決定者が確固たる証拠と一貫性を求めることが極めて重要です。たとえば、あるベンダーが機械学習を使用していると主張するなら、改善前後の精度やコストへの影響を提示するよう求めるべきです。もし確率論的予測が謳われているなら、どのように測定され、計画に活用されているかの証拠を要求すべきです（回答が決定論的な指標でごちゃ混ぜになっている場合は注意が必要です）。

さらに、サプライチェーンの複雑性が増すにつれて、スケーラビリティと自動化は単なる望ましい機能ではなく、不可欠な要素となります。手作業やExcel時代の慣行にとらわれたソリューション、もしくは英雄的なハードウェアなしではビッグデータに対応できないソリューションは、長期的に企業に十分なサービスを提供できません。本研究が示す、インメモリの一律型アーキテクチャへの懐疑は、より分散型でクラウドネイティブなアプローチが、コストと機能の両面で優位性を示しているというデータによって裏付けられています。

最後に、どのサプライチェーン最適化ソフトウェアにおいても究極のベンチマークは、そのソフトウェアがもたらす結果、すなわち在庫コストの削減、サービスレベルの向上、迅速な対応、そしてより効率的なプランナーワークフローにあります。これらを実現するためには、単なる巧妙な数式だけではなく、その数学的手法を実際のビジネス現実に合致する統一された自動意思決定プロセスに統合する必要があります。最も優れたベンダーは、予測 -> 最適化 -> 意思決定 -> 結果というループを、透明で科学的に信頼できる方法で閉じるものです。予測が孤立している、または不確実性を無視した意思決定ルールに固執する者は、取り残されるでしょう。

結論として、サプライチェーン計画ソリューションを評価する企業は、各候補を厳格な技術的視点で検証する必要があります。光沢あるパンフレットに惑わされず、ここで提示した厳しい問い―ベンダーは確率論的予測を提供しているのか、単一の数値のみなのか？システムは自律運用可能で、実際に大規模運用が実証されているのか？技術は統一されているのか、それとも古い部品の寄せ集めなのか？「AI」を理解しやすく事実に基づいた形で説明しているのか？―を投げかけるべきです。このレベルの厳格さを求めることで、単に美しいダッシュボードを提供するだけでなく、優れた意思決定を実現できる真の技術的リーダーを、サプライチェーン最適化の分野で見出すことができるのです。本稿のランキングと分析は出発点として、Lokad、Kinaxis、o9、Relex、ToolsGroup、Blue Yonder（他にも含む）といった主要プレイヤーを示しており、それぞれに強みと留意点があります。各ベンダーが自らの主張を実証する責任があると同時に、サプライチェーンを推進する頭脳を選ぶ際には、ユーザー自身が健全な懐疑心と根拠に基づく判断を維持する必要があります。

脚注