サプライチェーン最適化ソフトウェア、2025年2月

ベンダーランキングと概要（技術的厳密性に基づく）

1. Lokad – 最高の技術的信頼性. Lokadはその透明性と技術的奥深さで際立っています。確率的予測のパイオニアであり、公開コンペティションでその手法を証明しました（M5予測精度コンテストにおいて、SKUレベルで第1位、全体909チーム中#6にランク付け ¹ – トップランクにおける唯一のベンダー主導チーム）。Lokadは、アーキテクチャに関する詳細な知見（例：Envisionと呼ばれるドメイン固有言語、クラウドベースの自動化）を公開し、単純な指標を超えた財務的に最適化された意思決定を重視しています。厳密な数学（分位点予測、確率的最適化）と完全にスクリプト可能な自動化ワークフロー（APIやコーディングを通じて）に注力することで、エンジニアリングを第一に考えた設計を実証しています。根拠のない大きなAI/MLの主張は一切行わず、代わりに技術的なホワイトペーパーやRAM制限を超えたデータスケーリングのためのオープンソースツールを提供しています ^{2 3}. このレベルの透明性と実績が、Lokadをトップに位置付けています.

2. Anaplan – 「Excel 2.0」プラットフォーム. Anaplanは基本的にスプレッドシートのエンタープライズSaaS版であり、独自のHyperblockインメモリエンジン ⁴ によって支えられています。技術的には、Hyperblockは何千人ものユーザーがリアルタイムでプランニングモデルに共同作業できる堅牢な多次元計算エンジンで、クラウドベースのパワフルなExcelのようなものです。Anaplanは専用のサプライチェーン最適化ツールではなく（このプラットフォームでは、予測とアルゴリズムによる最適化が*「二流の存在」*と位置付けられている ⁵）、その強みはモデリングとシナリオプランニングのための堅実なアーキテクチャにあります。神秘的なAIを売りにするのではなく、カスタムプランニングロジック構築のための信頼性が高く高性能なサンドボックスを提供しています。要するに、正直なアプローチを持つ強力な一般プランニングツールであり、予測の魔法に関する誇大な主張はなく、よく設計されスケーラブルなスプレッドシートのようなシステムです。この率直な技術提案が、Anaplanに高い信頼性の評価をもたらしています.

3. Kinaxis (RapidResponse) – インメモリシミュレーションエンジン. Kinaxisは、企業全体でサプライプランをその場で再計算できる独自の同時並行エンジンで知られています。技術的には、Kinaxisはこれを支えるために独自のデータベースエンジンを一から構築しました ^{6 7}. その結果、高速な「what-if」シミュレーションに最適化されたプラットフォームとなっており、ユーザーはシナリオを分岐（データ版Gitのように）させ、変更の影響を即座にフィードバックとして受け取ることができます ⁸. システムはスピード重視のためにすべてのサプライチェーンデータをインメモリ上に保持し、アルゴリズムがデータに直接メモリアクセスすることで最大のスループットを実現しています ⁹. この設計により、本当の意味での同時プランニング（例：販売、製造、在庫計画がリアルタイムで同時更新）が可能となっています。エンジニアリングの観点から、カスタムのインメモリかつバージョン管理されたデータストアを構築することは敏捷性をもたらす印象的な偉業です。しかし、その代償は高いハードウェア需要にあり、完全なインメモリアプローチはRAM要件の増大に伴い、大規模データのスケーリングが高コストになる可能性があります ¹⁰. 全体として、Kinaxisはアーキテクチャとパフォーマンスにおいて強い技術的厳密性を示し、流行りのAI主張を避けています。サプライプランニングやS&OPシミュレーションに優れる一方、標準搭載のML予測機能は他社に比べて少なめです.

4. SAS – 統計のパワーハウス. SASは老舗の分析ソフトウェア企業（1976年創業）であり、サプライチェーンの問題に対して強力な統計モデリングエンジンを提供します。その旗艦製品には1970年代にさかのぼる統計専用のドメイン固有言語（SAS言語）が含まれており ¹¹、おそらくオリジナルのデータサイエンスプラットフォームと言えるでしょう。SASの強みは、そのアルゴリズムの深さにあり、数十年にわたって構築された時系列予測モデル、最適化ルーチン、機械学習技術の膨大なライブラリを持っています。業界で最も才能あるエンジニアや統計学者を雇用し ¹¹、「AI」という流行語が登場するずっと以前から先進的な予測技術を先駆けてきました。サプライチェーンの文脈では、SASは需要予測や在庫分析によく利用されます。技術的には、堅牢で実績のあるシステムですが、同時に重量感があります。ツールは時として難解に感じられるかもしれません（世界は大半がPython/Rなどのオープンソース言語に移行しており、実際Jupyterノートブックは今や優れたオープンな代替手段となっています ¹²）。SASは魔法のようなAIを大々的に主張することはなく、その評判と堅実な技術に依拠しています。専門知識を持つ組織にとって、SASは誇大宣伝ではなく実際のアルゴリズム（ARIMA、ETSなど）に基づく確かな分析力を提供します。その主な欠点は、一般的な分析プラットフォームであるため、内部は非常に強力であるものの、サプライチェーンへの適用には熟練したユーザーを必要とし、最近の予測コンペティションで明確なベンチマークが行われていない点にあります（オープンソースツールがしばしばこれに匹敵します ¹³）.

5. Dassault Systèmes (Quintiq) – 最適化のスペシャリスト. Quintiqは（2014年にDassault Systèmesに買収）複雑なサプライチェーンの最適化とスケジューリングに特化したプラットフォームです。独自のドメイン固有言語Quillを特徴としており、これによりエンジニアは業務上の制約をモデリングし、数学的ソルバーを活用してカスタムソリューション（例：カスタム生産スケジュールやルーティングプラン）を構築できます ¹⁴. 製品にDSLが存在すること自体が、真剣なディープテックの熟練度の証拠であり、プランニング問題のためのプログラミング言語の設計は容易ではありません ¹⁵. Quintiqは、工場のスケジューリング、物流ネットワークの最適化、及びその他のNP困難問題といった、カスタム最適化モデルが必要とされるシナリオにおいて卓越しています。技術的には、サプライチェーンソフトウェアで利用可能な柔軟で強力な最適化エンジンの一つです。しかし、Quintiqが最適化に注力するため、例えばネイティブな予測機能が限定的であるなど、他分野が犠牲になっています ¹⁶. さらに、Quillに関する公開技術アップデートが乏しい点は、技術が陳腐化しているか、少なくとも急速に進化していないことを示唆しています ¹⁷. ユーザーはしばしばDassaultのコンサルタントに頼ってソリューションを構築しており、明確な公開ドキュメントがないため、最新の革新を評価するのは困難です。まとめると、Quintiqは複雑な最適化ニーズに対する一流の選択肢であり、DSLを通じた強固なエンジニアリングを実証しています – しかし、AIや予測の分野においては透明性や最新性に欠け、その強みは実装者が構築するものに依存していると言えます.

6. ToolsGroup (SO99+) – 条件付きの確率的パイオニア. ToolsGroupのソフトウェア（SO99+）は、長年にわたり需要予測と在庫最適化、特に確率的モデルに重点を置いてきました。需要計画、補充、多段階在庫最適化など、広範なサプライチェーン機能を提供し、初期の段階から**「力強くシンプルな」確率的予測を掲げていました。理論上は先進的に聞こえますが、ToolsGroupは需要の不確実性をモデル化し、予測を「自己調整」することで、より正確な在庫目標を実現すると述べています。しかし、技術的に詳細を検証すると懸念があります。公開資料は、依然として2000年以前の予測モデルを使用していることを示唆しており ¹⁸、マーケティング上で「AI」という用語を加えたものの具体性に欠けます。特筆すべきは、2018年以降、確率的予測を謳いながら同時にMAPEの改善を誇示している点です ¹⁹。これは露骨な矛盾であり、もし予測が真に確率分布であれば、単一値の精度を測るMAPEは直接適用できなくなるはずです ¹⁹. この不整合は、「確率的」という部分が表面的であるか、または新たな手法にもかかわらず従来の指標に合わせている可能性を示唆しています。さらに、ToolsGroupは「需要感知AI」などの流行語を使用していますが、これらの主張は科学文献や既知のベンチマークで裏付けられていません** ²⁰. 実際、多くのToolsGroupの導入事例は、依然として例外アラート付きの自動化されたルールベースシステムとして機能しています。結論： ToolsGroupは幅広い機能を有し、不確実性モデリングの先駆けでしたが、アルゴリズムの透明性の欠如およびマーケティングと現実とのギャップにより、技術的信頼性は中程度にとどまっています。堅実でドメインに特化したツールセットではあるものの、今日の水準では明確な最先端技術とは言えません.

7. Slimstock (Slim4) – 率直で堅実. Slimstockは流行を追わない新鮮な異端児です。そのSlim4ソフトウェアは、主流のサプライチェーン手法、例えば従来の安全在庫計算、再発注点、経済的発注量（EOQ）などに焦点を当てています ²¹. 言い換えれば、Slimstockは教科書で学ぶ確立された実績のある方法に従っています。これにより、派手なAI/MLや最先端アルゴリズムは採用されていないものの、Slim4は信頼性が高く、理解しやすいシステムとなっています。ベンダーはあいまいなAI主張を明確に回避し、代わりに日常のサプライチェーンニーズに沿った実用的な機能を強調しています ²². この誠実さは技術的な長所であり、ユーザーは何を得るか正確に把握でき、システムの挙動も予測可能です。もちろん、シンプルであることは時に制約ともなり、Slim4では確率的需要予測や高度な最適化機能は期待できません。高度に複雑なネットワークや大規模なデータ量を対象としていない（実際、その技術アーキテクチャは中規模問題向けの、インメモリキャッシングを備えた標準的なデータベースである可能性が高い）ものの、多くの企業にとっては、ツールが一貫して機能するのであれば、シンプルな方が望ましいのです。Slimstockは流行語を避けることで信頼性を獲得しており、その**「要点に絞った」アプローチは、他社のAIアピールと対照的として同業者から評価されています ²³**。まとめると、Slim4は技術的に最先端を走っているわけではありませんが、最小限の誇大広告と明確で低リスクなアーキテクチャにより、基本的な予測と在庫管理のための堅実な選択肢となっています.

8. o9 Solutions – ハイテク過剰宣伝マシン. o9は、需要予測、供給計画、S&OP、さらには収益管理を一つのプラットフォームで統合する、エンタープライズサプライチェーンの**「デジタルブレイン」として自社を位置付けています。技術的には、o9はインメモリデータモデル、グラフデータベース（「Enterprise Knowledge Graph (EKG)」と呼ばれる）や各種AI/MLコンポーネントなど、最新技術の概念を多数取り入れています。o9の技術的質量は途方もなく大きい** ²⁴ – エンタープライズソフトウェアの基準では、すべてのデータとプランニング分析を統合しようとする非常に野心的なアーキテクチャです。しかし、懐疑的に見ると、その多くは技術自体を目的としたものであり、明確な効果を伴っていません。o9のインメモリ設計は、大規模時に極めて高いハードウェアコストを伴い ²⁵、巨大なBIキューブを常時稼働させるようなものです。o9はそのEKG（ナレッジグラフ）により、優れた予測とAI駆動のインサイトを可能にすると謳っていますが、科学的根拠や信頼できるベンチマークは提示されていません ²⁵. 実際、o9の派手な主張の多くは、精査の下で崩れ去っています。企業は至る所でAIについて語る一方、GitHubで公開されているコードの一部は平凡な技術ばかりを示しています ²⁶. 例えば、o9は機械学習による需要予測や「デジタルツイン」シミュレーションといった機能を宣伝していますが、これらを公開コンペティションや査読付きケーススタディで実証してはいません。証拠がないため、これらのAI主張はマーケティングの誇大広告と見なさざるを得ません。とはいえ、o9には強みもあり、買収の寄せ集めではなく自社開発の統合プラットフォームとして、大規模なデータ統合を処理できます。ハードウェアに投資し、急な学習曲線に耐えられる企業にとって、o9は複雑なプランニングモデルを構築する柔軟性を提供します。しかし、エンジニアリングの観点からは、過剰に設計されたソリューションであり、複雑さが多く、先進技術への投資効果（ROI）が不明瞭で、データがメモリの限界を超えるとパフォーマンス問題が発生する可能性があります。o9がアルゴリズムのドキュメントやベンチマーク結果などの確固たる証拠を提供するまでは、その信頼性は疑問視されるでしょう.

9. SAP IBP (統合型ビジネスプランニング) – 包括的だが複雑。 SAPのIBPスイートは、従来のSAP APOの進化形で、現在はSAP HANAインメモリデータベース上でクラウドソリューションとして提供されています。SAP IBPは、需要予測、在庫最適化、供給計画、販売＆オペレーション計画など、SAPのERPとしっかり統合された全領域をカバーすることを目指しています。SAP IBPの強みは幅広さにあり、ほぼすべての計画面に対応するモジュールが存在し、何十年にもわたるSAPの経験から受け継がれた非常に豊かな機能性が備わっています。しかし、この幅広さは買収とレガシーシステムによってもたらされたものです。SAPは、SAF（需要予測）、SmartOps（在庫最適化）などの専門企業を買収し ²⁷、それらを自社ツール（APOやHANAなど）の上に重ね合わせました。その結果、内部的にはさまざまなエンジンやアプローチがごちゃ混ぜになった状態となっています ²⁷. そのため、IBPの技術アーキテクチャは洗練されておらず、自然に組み合わさることのないコンポーネントの集合体であり、大規模な統合作業が必要になります。SAP自身のドキュメントも、極めて高い複雑性と、全体を円滑に機能させるためのトップクラスのシステムインテグレーター（および相当な時間）の必要性を認めています ²⁸. 技術面では、IBPはリアルタイム性能を実現するために、インメモリ・カラムナーデータベースであるSAP HANAに大きく依存しています。HANAは確かに高速ですが、費用もかかります－大量の計画データをRAMだけで保管するのは本質的に高価です（RAMはディスクストレージの約100倍の価格がかかる） ¹⁰. これは、IBPを非常に大規模なサプライチェーンデータセットにスケールさせると、かなりのインフラコストが発生し、もしデータがメモリを超えると性能が著しく低下することを意味します。SAPは、いくつかの機械学習機能（例：「需要駆動MRP」やIBP for Demandの一部ML予測オプション）を追加し始めましたが、これらは主に透明性の低いオプションの追加機能に過ぎません。SAPのMLが他の選択肢より優れているという証拠はなく、実際、独立した予測コンペティションでSAPのアルゴリズムが目立った成果を出した例はありません。まとめると、SAP IBPは機能が豊富でエンタープライズで実績あり―機能面では全ての要件を満たすでしょうが、技術的な純粋性の観点から見ると、まちまちです：インメモリの速さとレガシーロジックの結合、統合された製品からくる多くの複雑性、そして買収した部品以上の予測や最適化における明確な技術革新はありません。企業は最適化の卓越性のためというよりも、SAP ERPとの連携のために選択することが多いのです。

10. Blue Yonder – レガシー・リーダーから寄せ集めへ。 Blue Yonder（旧JDA Software）は、需要予測、供給計画、マーチャンダイジング、実行にわたるフルスイートを提供しています。これは、JDAがi2 Technologies（サプライチェーン計画）、Manugistics、そして名前を引き継いだAIスタートアップのBlue Yonderなどを含む、長年のM&Aの結果です ²⁹. 残念ながら、エンタープライズソフトウェアは単純なパーツの合計ではありません。一つの統一ブランドBlue Yonderの下には、統一感のない（多くはかなり古い）製品群がぐちゃぐちゃに組み合わされている状態が潜んでいます ²⁹. 技術的には、Blue Yonderのソリューションは、旧来の決定論的な予測エンジンから、15年以上根本的に変わっていない在庫最適化モジュールまで多岐に渡ります。同社はLuminateプラットフォームで「AI」や「ML」機能を大々的に売り込んでいますが、詳細は乏しいです。実際、Blue Yonderのデータサイエンスチームに帰属するオープンソースプロジェクトや特許など、限られた公開成果物が示唆するのは、かなり従来の手法（例：時系列特徴抽出、ARMAおよび線形回帰モデル）を使用しているということです ³⁰. これらの手法は問題ないものの、数十年前のアプローチであり、最新の手法に劣る場合が多いです。Blue Yonderが大々的に謳うAIは、単に回帰分析やヒューリスティックな手法を再パッケージしたに過ぎないようです。透明性のあるケーススタディや技術論文がなければ、Blue Yonderの「革新的なAI予測」の主張はマーケティングの大袈裟表現であると見なさざるを得ません。さらに、買収した全コンポーネントの統合は継続中の課題であり、多くのクライアントが、「エンドツーエンド」の約束を実現するのに苦労していると指摘しています。なぜなら、各モジュール（需要、供給、フルフィルメントなど）が大幅なカスタマイズなしには自然に連結されないためです。 インメモリ vs. オンディスク？ Blue Yonderは、他と同様の完全なインメモリアーキテクチャを宣伝しておらず、システムの一部は標準的なリレーショナルデータベース上で動作している可能性が高いです。これはコスト面での救いとなるかもしれませんが、一方でデータが集約されなければ性能が低下する可能性も意味しています（例えば、古いシステムではバッチプランニングが用いられていました）。まとめると、Blue Yonderは警戒すべき事例です：かつては業界のリーダーだったものの、現在は幅広いが技術的に一貫性のないスイートを提供しています。その強みは業界経験と豊富な機能群にありますが、弱みは新たな「AI」機能に対する信頼できる証拠が乏しく、塗装だけの古い技術で構成されている点です。

（注： Infor（レガシーなGT NexusおよびMerciaコンポーネントを有する）、GAINS Systems（在庫最適化の専門企業）、John Galt Solutions（中堅市場向け需要計画）、Relex Solutions（インメモリエンジンを用いた小売予測）など、他にも存在します。焦点を合わせるために、上記では最も著名または示唆に富んだ事例をランク付けしました。個別にランク付けされなかったものにも同じ懐疑的基準が適用されます：例えば、RelexはインメモリのOLAPキューブスタイル設計を採用しており、スピードは優れていますが、大規模小売業者にとっては高額なハードウェアコストを保証します ³¹；Inforは買収を通じて成長しており、SAPやBlue Yonderと同様の統合問題を抱えています；GAINSやJohn Galtは確かな基本機能を提供するものの、新規技術に関する公に文書化された情報はほとんどありません。技術的詳細や証拠を公開していないベンダーは、いずれにせよ本研究の方法論では低く評価されるでしょう。）**

詳細な技術分析

本節では、トップのサプライチェーン最適化ソフトウェアの具体的な技術面に深く踏み込み、4つの主要分野（予測＆AI、オートメーション機能、システムアーキテクチャ、モジュールの統合）に焦点を当てます。すべての分析は、公開された技術情報または具体的な証拠に基づいており、明確にマーケティング用語を避けています。

予測＆AI機能

現代のサプライチェーン計画は需要予測の精度に大きく依存していますが、予測の優位性の主張は氾濫しており、しばしば根拠がありません。調査の結果、ほとんどのベンダーの予測能力は、マーケティングで「AI」や「機械学習」といった流行語が使われているにもかかわらず、標準的な統計手法を大幅に超えるものではないことが判明しました。

• 実績 vs. 誇大宣伝： すべてのベンダーの中で、Lokadだけが検証可能な世界クラスの予測実績を持っており、それはオープンなM5コンペティションのおかげです。LokadはSKUレベルの精度でトップにランクインすることで、確率的予測の腕前を証明しました ¹。これにより、より良い予測精度を主張するLokadの信頼性が高まります。対照的に、他のどのベンダーも独立したベンチマークで同等の結果を公開していません。例えば、一部のベンダーは専有アルゴリズム（あるベンダーはその手法を「Procast」と呼んでいます）を宣伝し、優れた精度を主張しますが、これらの手法はM5コンペティションの上位には見られなかったのです ³²。実際、学術的なオープンソースアプローチ（例：Rob Hyndman教授のRによる予測パッケージなど）は、ほとんどのクローズドな専有エンジンと同等かそれ以上である可能性が高いです ¹³。したがって、公開された証拠なしに「業界最高の予測精度」とのベンダー主張は、支持されないと扱うべきです.

• AIと機械学習の主張： 私たちはAI/MLの流行に対して極めて懐疑的でした。o9 SolutionsやBlue Yonderのようなベンダーは、パンフレットで「AI/ML駆動の予測」などの用語を多用しています。しかし、実質を追求すると、その内容は乏しいのが実情です。o9の場合、グラフベースの「Enterprise Knowledge Graph」によってより良い予測が得られるという主張は、科学的な裏付けがなく疑わしい ²⁵。Blue Yonderも同様にAIを謳っていますが、詳細を提供しておらず、彼らの技術を垣間見せる唯一の手段は、いくつかのオープンソースリポジトリから得られるもので、そこではかなり通常の時系列技法（ARMA、線形回帰、特徴量エンジニアリング）が使用されていることが示されています ³⁰。深層学習、先進的な確率的手法、またはその他の現代的なAIの証拠はなく、マーケティングを正当化するには不十分です。ToolsGroupは機械学習の概念（「需要センシング」を機械学習で行うと述べている）を取り入れましたが、こちらも査読付きの研究やコンペティションでの勝利といった検証がありません ²⁰。実際、ToolsGroupが「確率的予測」を従来の指標であるMAPEと組み合わせていることは、彼らのAIがブレークスルーというよりは単なる話題作りに過ぎないことを示唆しています ¹⁹。結論： Lokad（および、一定の範囲で実績のある統計モデルを使用するSAS）を除けば、ほとんどのサプライチェーンソフトウェアの予測は既知の手法（指数平滑法、回帰、場合によってはツリーベースのML）に基づいており、何か独自の天才的なAIによるものではないのです。真に革新的なアルゴリズムを持つベンダーは、それを公に示すはずですが、独立した検証が欠如しているのは明らかです.

• 確率的アプローチ vs. 決定論的アプローチ： 技術的な差別化の顕著な点は、ベンダーが確率的予測（需要結果の全分布を予測する）を採用しているか、単一点の予測にとどまるかという点です。Lokadは2012年以降、完全な確率分布の提唱者であり、実際に確率的予測に基づいて在庫水準などの意思決定を直接最適化しています。ToolsGroupも確率的予測を生成すると主張しています（おそらく需要のモンテカルロシミュレーションを通じて）が、「確率的」と主張する多くの企業が内部的には決定論的な指標やプロセスに戻っていることが分かりました。例えば、ToolsGroupが確率モデルを使ってMAPEを低減するというマーケティングは一貫性がなく、理由はMAPEは確率的予測の出力では計算すらできないためです ¹⁹。これは、評価のために最終的にプロセスが平均または中央値という一点予測に戻ってしまい、確率的な利点が損なわれていることを示唆しています。SAP、Oracle、Blue Yonderなどの他のベンダーも確率的な用語に言及し始めています（SAP IBPは現在「統計的アンサンブル」や信頼区間を備えています）が、ユーザーインターフェースやレポートは伝統的な誤差指標とともに単一の数値予測にデフォルトになっていることが多いです。本当の意味での確率的予測を採用するためには、KPIの再考（MAPEの代わりにピンボール損失、CRPS、またはサービスレベル達成度を用いるなど）が必要です。実際、Lokad以外の大手ベンダーがそこまで実践している証拠は見当たりませんでした。まとめると、確率的予測は、多くのベンダーにとってマーケティングが実情を先取りしている分野であり、内部でいくつかの分布を生成しているかもしれませんが、プランナーは依然として一点予測の数値や従来のKPIを見ており、そのパラダイムの採用は限定的であることを示しています.

• 予測指標と評価： 技術的な厳密性の重要な側面は、ベンダーが予測の品質をどのように評価するかです。MAPE、WAPE、またはバイアスといった指標にのみ依存し続けるのは赤信号であり、特にベンダーがAIまたは確率的方法を使用していると主張する場合、これらの指標は保守的で中庸な予測を促し、操作されやすい（例えば、高値と安値を削るなど）ためです。我々は、真に先進的な予測を行うベンダーは、単にMAPEだけでなく、サービスレベルやビジネス成果（例：品切れ確率、コスト影響）について語る傾向があることを観察しました。例えば、Lokadは「エラーのドル額の削減」と意思決定の最適化との整合性を強調しています ³³。これに対して、ToolsGroup、Blue Yonder、その他多くの企業はケーススタディで依然としてパーセンテージ誤差を強調しており、時代遅れの考え方を示しています。もし、ベンダーのドキュメントやデモでMAPE/WAPEのダッシュボードが多用されていれば、それはその予測が伝統的である兆候です。実際、ToolsGroupのMAPEに関する一貫性の欠如は既に指摘されています ¹⁹。要するに、サプライチェーンにおける真の最先端予測は、確率的な指標と実世界での検証によって証明されるべきであり、これは一部のプレーヤーを除いてほとんど存在しない属性です。

オートメーション＆ワークフロー機能

サプライチェーン最適化を達成するには、単にアルゴリズムだけではなく、ソフトウェアが計画プロセスをどれだけ自動化され、手操作なしに実行できるかも重要です。我々は、各ベンダーの主張とドキュメントを調査し、オートメーション、API統合、そして自律的意思決定のサポートに関する証拠を検証しました.

• Lokad： 自動化はLokadの特徴の一つです。全体のソリューションは、サプライチェーンプランナーが自らのロジックや意思決定をスクリプトにエンコードできるドメイン固有言語（Envision）を中心に構築されており、そのスクリプトがスケジュールに従って自動実行されます。Lokadは、データの更新や意思決定（予測、補充注文など）の再計算を手動介入なしに行うデータパイプラインとワークフローマネージャを明確に文書化しています ^{34 35}。さらに、～100のサプライチェーンで**「高度に自動化されたセットアップ」**を運用していると述べており ³⁵、これはソフトウェアがデータの取得、予測、及び意思決定（例えば、購入発注の提案）を完全自動で行っていることを意味します。加えて、Lokadはデータアップロードと結果ダウンロードのためのAPIを提供し、事務作業の自動化のための「AIパイロット」というコンセプトも持っています ³⁶。これらすべてが、真に高いレベルの自動化を実現していることを示しており、ユーザーの役割はほとんどコードやパラメータの監視と改善に限定され、すべての計画に対して手動でボタンを押す作業は不要です。Lokadの自動化へのアプローチは信頼性が高く、技術的にも詳細に説明されており（手動から自動への意思決定移行方法についての講義も行っています ^{37 38}）。

• Kinaxis: Kinaxis RapidResponseは、完全自動化の計画ではなく、シナリオ分析の迅速な実施とコラボレーションのために設計されています。「同時進行型計画」の概念は、全員が同じデータセットにリアルタイムで更新を加えながら作業することを意味しますが、通常はシナリオを評価し意思決定を行うために人間のプランナーが関与します。それでも、Kinaxisは特定の方法で自動化をサポートしており、ERPシステムからほぼリアルタイムでデータを取り込み、供給／需要マッチングのアルゴリズムを継続的に実行し、範囲外の事象が発生した際にはユーザーへアラートや例外メッセージを送信します。また、APIを介して機能を公開し、パワーユーザー向けに設定可能なアルゴリズムやマクロ形式のスクリプトを提供しています。しかし、Kinaxisは一般的に意思決定支援として位置付けられており、注文を自動的にリリースするブラックボックスではありません。ベンダーは「自律的サプライチェーン」と大々的に主張するのではなく、プランナーの効率化に注力しています。これは正直な姿勢であり、既製の状態ではRapidResponseは依然として人間の介在を前提としているため、“自己走行型”サプライチェーンシステムを求める場合には制約となり得ます。技術的には、Kinaxisは深い統合が可能（例えば、SAP ERPと統合して承認済みの計画を実行）ですが、全自動のエンドツーエンド運用には多くのカスタム設定が必要です。KinaxisがAI主導の意思決定推奨を提供している証拠は見当たりませんでした（彼らの強みは、ユーザーが定義したシナリオの迅速な計算にあります）。

• o9 Solutions: o9は、組織の「デジタルツイン」や推奨を行うAIといった概念を大々的にマーケティングしています。彼らは**デジタルアシスタントの文脈で「自動化」**について言及しており、おそらくインサイトの抽出やタスク実行を行うボットを指していると思われます。しかし、具体的な技術文書が存在しないため、どこまでが実現されているのかを断定するのは難しいです。*「o9はその計画に基づいてAPIを通じて自動的に補充注文をリリースできる」や「o9は独自にパラメーターを調整するために強化学習を利用している」*といった具体例は見当たりませんでした。o9の自動化ストーリーの曖昧さは懸念材料です。高レベルの議論は多いものの詳細がほとんどなく、インメモリのEKG基盤を考慮すると、o9はリアルタイムのデータ更新や再計算が可能であると推測されるものの、依然として情報の取り扱いについてはユーザーに依存している可能性が高いです。信頼できる参考資料がないため、o9の「自律性」に関する主張は未確認とみなします。APIを介して実行システムにo9を統合することは可能ですが（現代的なソフトウェアであるためAPI統合は存在するはずです）、実際にAIがどの程度の意思決定を自動化しているかは不明です。証拠は、現状のo9の自動化は意思決定の自動化というよりも、分析の迅速化（例：即時のwhat-ifシナリオ）に重点を置いていることを示唆しています。

• Blue Yonder: 近年、Blue Yonderは（特にパナソニックに買収されて以降）「自律型サプライチェーン」という用語を推し進め、最小限の人間の介入で運用可能なシステムを示唆しています。彼らは、Luminate Control Towerのように、AIを利用して混乱を検知し、対応を起動する可能性のあるコンポーネントをいくつか提供しています。しかし、Blue Yonderのレガシーな中核を考えると、いかなる自律性も既存モジュールの上にRPA（ロボティック・プロセス・オートメーション）または単純なAIエージェントを重ねることで実現している可能性が高いです。例えば、Blue Yonderの需要計画は予測を生成し、その上の「AI」層がリアルタイムの販売（需要感知）に基づいて自動的に調整したり、逸脱があればアラートを送信したりするかもしれません。しかし、完全自動の計画（注文の自動発行、在庫ポリシーの自動調整など）は、おそらくBYソリューションでは稀であり、通常はプランナーが意思決定の検証と承認を行っています。Blue Yonderがどのように意思決定を自動化しているかについての詳細な技術文献が不足しているのは示唆に富みます。もし真に自律的なプランナーがあれば、成功事例や技術ブログを公開するでしょう。代わりに、主にマーケティングウェビナーが公開されているため、Blue Yonderはバッチジョブ、計画の更新、場合によっては実行システムへのクローズドループ統合など一定の自動化は実現しているものの、この分野で先駆的な存在であるとは言えません。従来のシステムと同様に例外ベースの計画を採用している可能性が高いです（新しいAIの外観をアラートシステムに施しているだけです）。

• ToolsGroup: ToolsGroupは伝統的に「パワフリーシンプルな自動化」を誇ってきました。彼らは、自社システムが長時間にわたって無人運転モードで稼働し、例外発生時のみプランナーが介入することを主張していました。実際、ToolsGroupの哲学は、システムが自動的に再予測および再計画を毎日実行し、新しいデータに対応するというものです。その成果として、多くのToolsGroup顧客は、ソフトウェアが自動的に在庫目標を調整し、注文を推奨するため、プランナーの作業負荷が軽減されたと報告しています。さらに、ToolsGroupは承認済みの注文をERPシステムに転送するための統合ツールキットも提供しています。しかし、前述の矛盾点により、この自動化の知性については疑念があります。単に毎日同じ計算式を適用し、異常時にだけフラグを立てる（例外管理）に過ぎない可能性があるのです。ToolsGroupはAPIを提供し、スケジュール実行もサポートしているため、技術的には自動化の基盤は整っています。問題は自動化された意思決定の質です。彼らは「自己調整（self-tuning）」について多く言及しており、これはソフトウェアが新しいデータに応じて予測モデルのパラメーターを自動的に調整することを示唆しています ³⁹。もしこれが実現されていれば、常に人間が再構成する必要を排除する有用な自動化と言えます。独立した評価がないため、控えめに言えば、ToolsGroupは日常的な計画タスクにおいて高い自動化を提供していると考えられますが、その透明性の欠如により、この自動化がどれほど「賢い」のか（例えば、実際に学習し改善するのか、単に既定のルールに従っているだけか）を判断するのは難しいです。

• その他のベンダー: その他のほとんどのプレイヤーは、APIまたはファイルバッチを利用したデータ統合、スケジュールされた計画実行、そして例外ベースのワークフローといった標準的な自動化機能をサポートしています。例えば、SAP IBPは毎月自動的に予測ジョブを実行し計画結果を生成するよう設定できますが、通常はプランナーが出力を確認します。Anaplanは自動化に重点を置いておらず、むしろ手動のモデリングプラットフォームですが、APIを使用してデータのプッシュ／プルや特定の計算の自動化を行うことは可能です。Dassault/Quintiqは、最適化ルーチンをスケジュールに沿って実行するようスクリプト化でき（QuintiqのDSLにより、カスタムの自動動作がプログラム可能）、これも実装者がプログラムした通りの自律性に留まります。GAINS、Relex、Netstockなどのニッチなベンダーは、通常、購入注文や店舗間転送の推奨を自動的に生成するという意味で「エンドツーエンド自動化」を宣伝しています。重要なのは、どれだけの監視が必要かです。真に自律的な計画システムであれば、異常な状況の場合にのみ人間を呼び出し、その意思決定の根拠を文書化するはずです。現時点でこの理想を完全に実現しているベンダーは見当たりません。ほとんどの場合、人間が微調整と承認を行うか、最も簡単な意思決定のみが自動化され、残りは人の判断に委ねられています。

自動化のまとめ: ごく一部のベンダー（特にLokad）が、無人でAPI駆動の計画サイクルを可能にする自動化フレームワークについて公に詳細を示しています。他のベンダーは自動化の技術的手段を持っているものの、最終的には人間に依存しています。また、過去数十年で完全自動化から「例外管理」へフォーカスを移したベンダーもあることに留意すべきです。これはソフトウェアが可能なことを実行し、残りを人間に知らせるという半自動的なアプローチです ³⁸。この手法は実用的であるものの、十分に堅牢で信頼できるソフトウェアでなければ依存しすぎると問題になる可能性があります。我々の懐疑的見解としては、もしベンダーが意思決定をどのように自動化しているか（どのアルゴリズム、どのトリガー、どのAPI呼び出しを用いているか）を説明できないのであれば、その「自動化」は単なるマーケティングトークに過ぎないと考えます。

システムアーキテクチャとスケーラビリティ

内部アーキテクチャ、特にインメモリコンピューティングとオンディスクの利用、そして全体的な設計の選択は、サプライチェーンソフトウェアのスケーラビリティ、コスト、パフォーマンスに大きな影響を与えます。我々は、大量のデータと複雑な計算処理の対応に着目し、各ベンダーのコア技術スタックを検証しました。

• インメモリコンピューティング – 長所と短所: 主要なベンダーのいくつかは、インメモリアーキテクチャに依存しており、計算中に迅速なアクセスを実現するため、ほとんどまたはすべての関連データをRAMに読み込んでいます。これには、Kinaxis、Anaplan、o9、SAP HANA (IBP)、Relex、そして場合によってはシナリオ解決用のQuintiqが含まれます。利点は速度であり、RAMへのアクセスはディスクより桁違いに高速です。例えば、Kinaxisのエンジンはシナリオの即時再計算とデータセットに対する直接的なアルゴリズム操作を可能にするため、全データをメモリ上に配置します ⁹。また、SAPのHANAは、ライブデータの分析はリアルタイムの結果を得るためにインメモリで行うべきだという前提で構築されました ^{40 41}。しかし、全てをインメモリ設計にすることには根本的な問題があります。それは、コストとスケーラビリティです。 メモリ（RAM）はストレージに比べて極めて高価です。1TBのRAMは1TBのディスクの約100倍のコストがかかる可能性があります ¹⁰。また、サーバーのメモリサイズは物理的に制限されており、一般的なシステムは最大で0.5〜2TBのRAMしか持たず、大規模サプライチェーンではマルチテラバイトあるいはペタバイトのデータセットが一般的です。近年、RAMコストの大幅な低下が期待されたものの、実現には至っておらず、RAMの価格と容量はほぼ横ばいです ⁴²。これは、すべてのデータをメモリに要求するシステムが、データの増加に伴いインフラコストの急騰に直面するか、収容不可能な限界に達することを意味します。我々は、対策が取られていない限り、大規模サプライチェーンにおけるインメモリ設計への過度の依存を建築上の大失敗と位置付けます。

• メモリ対ディスク：現代の実践: 興味深いことに、広範な技術業界では、純粋なインメモリソリューションが大規模データの未来ではないと認識されています。新しいアーキテクチャは階層型のアプローチを採用し、ホットデータはメモリに、コールドデータはSSDなどに保持します ^{43 44}。一部のサプライチェーンソフトウェアはすでにこれを採用し始めています。例えば、Lokadはクラウドインフラにおいて明示的に「spill to disk」技術を使用しています。彼らのCTOは、約37GBのRAMと高速NVMe SSDを用いて100億行の小売データセットのオーバーフローをディスクに溢れさせる方法について説明しています ^{45 3}。ファイルのメモリマッピングを行い、最もホットなデータのみをRAMに保持し、必要に応じてソフトウェアが賢明にスワップすることで、ほぼRAMに近い性能を実現しています ^{46 47}。このアプローチは大幅なコスト削減を実現し、例えば、**ハイエンドRAM18GB分のコストで1TBのNVMe SSDが購入できる ³**ため、1バイトあたり50倍安価であり、なおかつ生のアクセス速度は約6倍遅いという、しばしば有用なトレードオフとなります。インメモリ中心のベンダー（Kinaxis、SAP、o9など）は、このような適応型メモリ管理について公に説明しておらず、そのソリューションは単に大量のRAMを要求するか、データの集約を必要とする可能性が示唆されます。Anaplanはモデルサイズの制限に苦しむことで知られており、一部の顧客はHyperblockのメモリ制限に直面してモデルを分割せざるを得ません。Kinaxisも非常に大規模なデータに対しては、複数のサーバーをネットワークで連携させる必要がある可能性が高いです（データ分散の概念はあるものの、各ノード内ではメモリ上に存在します）。SAP HANAはディスクへのオフロード（拡張ノードを有する）も可能ですが、パフォーマンスは低下します。要点として、硬直したインメモリ設計はスケーラビリティにおいて大きな警告サインです。小～中規模のデータでは非常に効果的に機能しますが、サプライチェーンが拡大（例：グローバル小売業者の詳細なSKU－店舗－日単位の計画など）すると、コストとパフォーマンスリスクが増大します。現代のエンジニアリングは、速度とコストのバランスを取るために、メモリとディスクの併用を重視しており、その対応をしていないベンダーは時代遅れと言えるでしょう。

• テックスタックと複雑性: メモリ以外のアーキテクチャ要素として、全体のテックスタック、すなわちモノリシックとマイクロサービス、最新プログラミング言語の使用などが挙げられます。深入りはしませんが、古参のベンダー（SAP APO/IBP、Blue Yonder）はよりモノリシックでレガシーなスタック上で動作しており、一方で新興のベンダー（o9、Anaplan）は最新技術を用いてゼロから自社システムを構築しています。例えば、SAP IBPのコアには、現在でもHANA/クラウドレイヤーに包まれた2000年代のエンジン（APOのオプティマイザーなど）が含まれています。これにより、抽象化の層が複数重なることで複雑さや非効率性が生じる可能性があります。Blue Yonderもまた、i2やJDA時代のレガシーコードが多数存在します。Kinaxisはややユニークで、90年代に創業された古いシステムながら、継続的に自社のデータベースカーネルへリファクタリングしており、専有のプロプライエタリスタックとなっています。Anaplanは、特定のユースケース（Hyperblock）のために非常に効率的な計算エンジン（Javaで構築）を開発し最適化していますが、オープンではなく、その制約（例：SQLクエリが使えない、セルベース計算によるアルゴリズムの複雑性の制限など）を受け入れる必要があります。o9のプラットフォームは、複数の技術（おそらくNoSQL/グラフデータベース、SparkなどML向け技術を含む）の混合体であり、複雑ながら理論上は柔軟です。

• ハードウェアとクラウド: 注目すべきはクラウドネイティブ設計の傾向です。多くのベンダーは現在、自社ソフトウェアをSaaSまたは少なくともクラウドホスティングで提供していますが、必ずしも全てが真のクラウドネイティブというわけではありません。例えば、Anaplanとo9はクラウド向けにゼロから構築されたマルチテナントSaaSです。**Lokadはネイティブにクラウド対応で（Microsoft Azure上で動作し、リソースを動的に割り当て）**います。SAP IBPはクラウドホスティングされていますが、基本的には各クライアントがHANA上で独立したインスタンスとして運用されており（厳密な意味でのマルチテナントではありません）、ToolsGroupやBlue YonderはSaaS提供もしていますが、これらはしばしばクラウド上で自社が管理するオンプレミスソフトウェアに過ぎません。なぜ技術的に重要かというと、クラウドネイティブなアーキテクチャは通常より弾力的であり、必要なときに（大規模な計画実行時など）コンピュートリソースをスピンアップし、終了後にスピンダウンしてコストを管理できるからです。非クラウドシステムは、たとえ時折しか使用されなくてもピーク容量を購入する必要があります。また、クラウドネイティブシステムは、他のクラウドサービス（例えば、クラウドMLサービスやデータレイク）との統合がよりスムーズに行える可能性があります。我々の調査では、最もクラウドネイティブでスケーラブルな設計のソリューションは、Lokadとo9（場合によってはAnaplanも）に見られる一方で、他社は追随する段階にあります。しかし、クラウドネイティブであることだけが優れたアーキテクチャを保証するわけではなく、o9はクラウドネイティブであるものの、そのインメモリに依存するアプローチには疑問が残り、SAP IBPがクラウド上にあるからといって、その複雑性の問題が解消されるわけではありません。

• 並行性とリアルタイムのニーズ: 一つのアーキテクチャ上の考慮点は、システムが同時利用者とリアルタイム更新をどのように扱うかです。Kinaxisはこの点で際立っており、複数のプランナーが同一のデータセット上で同時にシナリオプランニングを行えるよう設計されています。これは慎重なデータバージョン管理とロックのロジックを必要とし、Kinaxisは分岐メカニズムを通じてこれを実現しました ⁸。他の多くのツールは伝統的にバッチ方式（計画、公開、その後別個の協働）に従っていました。現在、多くが同時プランニング機能を追加しています。Anaplanは、複数のユーザーが同時にモデルの異なる部分で作業できるようにしており（本質的にGoogle Sheetsのようにセルベースであるためです）、SAP IBPはサーバーからのデータを要求に応じて更新可能な「Microsoft Excelのような」UIを導入しましたが、真の同時実行性（複数ユーザーが同一の計画を同時に編集すること）は限定的です。o9は知識グラフを持っているため、ある程度の同時実行性をサポートしている可能性があり、複数のユーザーが異なるノードを調整できます。多くのユーザーとリアルタイムに稼働できるシステムは堅牢なアーキテクチャを示すため、技術的評価においてはKinaxisとAnaplanが高評価となります。他社も同様の機能を持ちうるものの、古いアーキテクチャのために実現が難しく、パフォーマンスが遅いか逐次的なプロセスを強いられる場合が多いのです。

アーキテクチャの要約: 私たちはパターンを特定しました：インメモリ中心の設計（Kinaxis, Anaplan, o9, Relex, SAP HANA）は速度を提供する反面、スケーラビリティとコストに課題があり、一方、ハイブリッド設計（Lokadのspill-to-diskや近代的なデータベースを使用するツールなど）はよりスケーラブルでコスト効率が高いということです。すべてをRAM上に置く必要があると主張するベンダーは、SSDの速度向上と分散コンピューティングの進化を考えれば、もはや時代遅れのアプローチと見なされ、明確な赤信号となります ^{43 44}。また、複数の買収から生まれたベンダーのアーキテクチャ（SAP、Blue Yonderなど）は、過度に複雑で多くの調整を必要とする傾向があることを指摘します。Kinaxisの単一コードベース、Anaplanの単一エンジン、Lokadの単一エンジンといったシンプルで独自開発されたアーキテクチャは、より一貫性があり技術的に保守しやすいといえます。サプライチェーンソフトウェアを評価する際は、ベンダーが自社のソフトウェア構築方法（マイクロサービス、カスタムDB、MLライブラリの活用など）について何か公表しているかを確認すべきです。エンジニアリングに関する議論が全くない場合、そのアーキテクチャはブラックボックスであり、レガシーであるか独自性に自信がない可能性を示しています。

統合とモジュールの一貫性（M&Aの影響）

サプライチェーンプランニングは通常、需要予測、在庫最適化、生産計画などいくつかの領域にまたがります。一部のベンダーは有機的に構築された統合スイートを提供しますが、他は買収により拡大し、新たなモジュールを後付けしています。私たちは各ベンダーのソリューションがどのように統合され、成長戦略からどのような赤信号が見られるかを検証しました。

• Blue Yonder (JDA) は買収による成長の代表例です。すでに述べたように、これは**「様々な時代の製品が寄せ集められた行き当たりばったりの集合体 ²⁹」**です。JDAは、複数のモジュールを持つi2を買収し、その後Manugisticsを、さらに倉庫管理用のRedPrairie、そしてAI用のスタートアップBlue Yonderを買収しました。それぞれの部品は独自のデータベーススキーマとロジックを持っていました。その結果、今日でもBlue Yonderの需要計画、供給計画、在庫最適化は統一されたデータモデルを共有しておらず、統合はインターフェースに依存しています。これは、完全なスイートの導入が実質的に複数の個別ソフトウェアパッケージの統合であることを意味するため、赤信号です。ベンダーの製品が真に統一されていない場合、データ同期の遅延、一貫性のないユーザーインターフェース、機能の重複といった問題が発生します。Blue Yonderの場合、いくつかのモジュールが正直に重複しており（買収により、従来のManugisticsとi2の２通りの在庫計画が存在する可能性があります）、同社はこれを合理化するために努力していますが、完全には解決されていません。技術的観点から、企業の合併時にソフトウェアが魔法のように混ざり合うことはない ²⁹ – それには何年もの再エンジニアリングが必要です。Blue Yonderがその再エンジニアリングを完了したという証拠は見受けられません。したがって、一貫性の欠如は重大な技術的弱点です。

• SAP IBP もまた、買収されたコンポーネントを組み合わせています。SAPはSAFやSmartOpsなどを買収し、それらをIBPの傘下に統合しました ²⁷。ユーザーは、IBPの各モジュールが別々のアプリのように感じられる（例えば、需要向けのIBPと在庫向けのIBP）と指摘しています。IBPの安全在庫最適化ロジックはおそらくSmartOps買収に由来し、需要センシングはSAFや内部開発から来ている可能性があります。統合はBlue Yonderの場合よりは優れており、SAPは少なくともUIを書き換え、すべてをHANAデータベース上に展開しました。しかし、IBPは依然として単一のコードベースではないのです。SAPは、IBPの実装には通常数年と専門の統合者が必要であると明言しており ²⁸、この点自体が潜在的な不一致と複雑さを示す赤信号となっています。

• Infor（上位10には入っていないものの）も、MerciaのサプライチェーンプランニングやGT Nexusなど、複数のプランニングシステムを買収・統合してきました。その結果、真に統一されたプランニングプラットフォームには至らず、Inforは実行システムに重点を置く傾向があります。これは、買収が必ずしも優れた統合プランニング製品を生み出さなかった例の一つです。

• Dassault (Quintiq)：この場合、Dassaultによる買収は、Quintiqを他のプランニングツールと統合することなく、そのまま独立した提供物として生産/スケジューリング最適化に注力させる形を取りました。したがって、Quintiq内部の一貫性は良好ですが、すべての領域をカバーしていないという欠点があります（例：需要予測がネイティブに存在しない ¹⁶）。Dassaultのポートフォリオには、MES向けのAprisoなど他の製品がありますが、これらはQuintiqと深く統合されていません。統合の観点では、Quintiqは自己一貫性はあるものの、機能的には狭いといえます。ユーザーの観点からは、別の需要予測ツールと統合する必要が生じ、クライアント側で追加の作業が必要となる可能性があります。

• Kinaxis は主に有機的に成長しました。2020年に小規模なAI企業Rubikloud（小売AI向け）と、2022年にサプライチェーン設計ツールであるCastle Logisticsを買収しましたが、これらは比較的新しく、統合の様子は今後注視されるところです。従来、RapidResponseは設定により多様なプランニング面を一製品で扱っていました。この一貫性は大きな強みであり、Kinaxisではすべてのモジュール（需要、供給、在庫）が単一のデータベースとユーザーインターフェースを共有しています。同様に、Anaplanは一つのプラットフォーム上に、営業、財務、サプライチェーン計画といった異なるプランニング「アプリ」を構築しており、Hyperblock環境内で技術的に非常に一貫性を保っています（ただし、モデルテンプレートが異なるだけです）。o9 Solutionsもまた、有機的に開発された単一のプラットフォームで多くの領域をカバーしており、主要なプランニングベンダーの買収によって成長したわけではありません。従って、Kinaxis、Anaplan、o9の三社は統一性という点でアーキテクチャ上の利点を持っています。ただし、彼らに対する注意点は、異なるモジュールの統合ではなく、その単一プラットフォームが各領域の深い要件に真に対応できるかどうかという点です。

• ToolsGroup & Slimstock: これらのベンダーは、需要および在庫計画という自社のニッチに専念しています。彼らは他社を買収することはほとんどなく、必要に応じて実行システムと提携または統合を行っています。これは、彼らのソフトウェアが内部的に一貫している（単一のコードベースである）ことを意味し、良い点ですが、もしクライアントが生産スケジューリングのようなより広範な機能を必要とする場合、別の製品との統合を自ら行う必要があります。ToolsGroupは近年、S&OP機能を追加し、2018年に機械学習のためのAIスタートアップEramosを買収しましたが、これらは別製品として販売されるのではなく、コア製品に統合された形です。従って、ToolsGroupやSlimstockにとって統合は大きな問題ではなく、その単一焦点設計がユーザーの要求する範囲を十分にカバーしているかどうかが課題となります。

統合の要約: 懐疑的な視点から言えば、ベンダーの歴史において複数の大規模な買収があることは警告サインです。これにより、万能な製品となるがいずれも卓越していない、隠れた複雑性を持つ製品が生まれる傾向があります。Blue YonderやSAPは、この点で、買収した多数の部品を無理に統合しようとしたために技術的な複雑さを抱えています。逆に、有機的に構築された単一の統合プラットフォームを持つベンダーはこれらの問題を回避できますが、その単一プラットフォームがすべてを十分にこなせるかどうかは依然として検証が必要です。ソフトウェアを評価する際は、各モジュールの出所について尋ねるべきです：需要計画モジュールと供給計画モジュールが別々の元会社から来ている場合、データの共有方法と統合がシームレスであるか、またはインターフェース経由であるかを確認してください。買収した技術が一から統一アーキテクチャに書き直されなかった限り（これはコストと時間の面から稀です）、結果は通常、フランケンシュタインシステムとなるのが歴史の教訓です。我々の調査はこれを裏付けており、技術的な優雅さで高評価を得たベンダー（Lokad、Kinaxis、Anaplan）は全体として一体的なソリューションを築いているのに対し、Blue YonderやInforのように低評価のベンダーは、統一されない異質な技術を積み上げた結果となっています。

重大な弱点と赤信号

我々の徹底的なレビューにおいて、見込み顧客が注意すべき再発する弱点と赤信号がいくつか特定されました。以下は、具体的なベンダーの例を交えて主要な問題点をまとめたものです。

• 根拠のない「AI/ML」主張: 優れたAIまたは機械学習を何の確固たる技術的証拠もなく主張するベンダーには非常に懐疑的になるべきです。例えば、Blue YonderはAIを大々的に宣伝していますが、内容の乏しい曖昧な主張しか提供しておらず ³⁰、そのわずかな手法の断片からは、最新のAIではなく旧式の技術に依存していることが示唆されています。同様に、o9 SolutionsはAIやグラフベースの知能を誇っていますが、公開されているコードや資料の分析では「大量のAI宣伝」に留まり、実際の分析は平凡であると示されています ²⁶。ベンダーが査読付き論文、特許、コンペ、または詳細な技術論文などで裏付けることができない場合、それは単なるマーケティング上の誇大宣伝だと考えるべきです。真に先進的なベンダーは、自社のアルゴリズムについて詳細に説明することを誇りに思うはずです。

• 競争力のあるベンチマーキングの欠如（予測の優位性主張）: 多くのベンダーは*「クラス最高の予測精度」*を主張しますが、Lokadを除いて、それを公開のコンペや論文で証明した事例はありません。我々は、このような主張を検証されない限り偽りとみなします。例えば、あるベンダーの独自アルゴリズムが「他よりも正確である」と自慢したものは、M5コンペティションの上位には見当たらず ³²、これはその主張に根拠がないことを強く示唆しています。実際、伝統的なサプライチェーンソフトウェアベンダーで、Lokad以外が世界規模の予測コンテストのトップ100に入った例は一件もありません。これは大きな赤信号であり、これらのベンダーが参加しなかったか、あるいは参加しても良い成績を残せなかったことを意味します。実用的なアドバイス: 彼らのツールが、M5やM4の標準データセットのようなベンチマークでどのような成績を収めたのか、客観的な精度結果を提示するよう要求してください – もし提示できなければ、その誇大宣伝は信用に値しません。

• インメモリ・アーキテクチャの行き過ぎ: すべてをインメモリ設計に依存するベンダーには、スケーラビリティとコストの面で疑問を呈すべきです。インメモリコンピューティングは高速ですが、RAMはディスクに比べ1GBあたり約100倍高価であり ¹⁰、近年その価格対性能比は停滞しています ⁴²。その結果、純粋なインメモリソリューションは大量データに対してスケーラブルでなく、コストが嵩む可能性があります。SAP IBP（HANA）やo9は、膨大なデータセットをメモリにロードする場合にのみ高性能を保証しており、これは非常に高額なハードウェアやクラウド料金を意味します ^{24 31}。現代のシステム設計では、このアプローチから離れる動きが見られ、ある専門家は「すべてをRAMに詰め込むブームは実用的な限界に達し、データベースは再びディスクへの依存を見直している」と述べています ^{43 44}。もしベンダーが依然としてインメモリ専用の考え方に固執するのであれば、それはアーキテクチャ上の赤信号と考えるべきです。よりスケーラブルなベンダーは、階層型ストレージやクラウドの弾力性など、無限のRAMを必要とせずに大規模データを扱うための戦略について語るでしょう。

• M&Aによるブラックボックス（統合の不具合）: ベンダーの製品スイートが多数の買収の結果である場合、統合のギャップや機能の重複に注意を払う必要があります。前述の通り、**Blue Yonderのスイートは、長期間にわたる買収によって、時代遅れの製品の寄せ集めとなっている ²⁹**のに対し、**SAP IBPのモジュールは異なる買収企業から来ている ²⁷**ため、複雑で「ツールのコレクション」に留まっています。企業向けソフトウェアは、買収によって簡単に「混ざり合う」ものではなく ²⁹、完全な再エンジニアリングが行われなければ（これは稀で非常に時間がかかります）、顧客自身がモジュール間の統合を行わざるを得なくなります。これにより、一貫性のないユーザー体験、重複したデータ入力、そして脆弱なインターフェースが生じる可能性があります。赤信号の症状: ベンダーの実装では、各モジュールを最適に連携させるために1年以上にわたる大勢のコンサルタントが必要とされる – これはSAPの場合にも認められています ²⁸。統一プラットフォーム、または買収コンポーネント間の重複が最小限であるベンダーを選ぶべきです。

• 矛盾する指標と流行語: 業者の技術的説明に内部矛盾や新しい用語で偽装された旧態依然の手法が含まれている場合、微妙ながらも重要な警告サインとなります。ひとつの明白な例は、ToolsGroupが確率的予測を宣伝しつつ同時にMAPEの改善を言及している ¹⁹ ことで、これは彼らが単に古い手法に新しい用語を散りばめているだけであることを示しています（確率的予測の評価にMAPEを使用するのは概念的に誤りです）。別の例では、業者が「先進的なAI」を使用していると主張しながら、MAPEや従来のサービスレベルといった古い指標で成功を測定している場合があり、これは新パラダイムを真に採用していないことを示唆しています。同様に、安全在庫の手法にも注意が必要です: 業者がAIで在庫を最適化すると主張していても、実際に調べると依然として1980年代の数式（例：正規分布の仮定と静的な安全係数を用いる）で安全在庫を計算しているなら、それは矛盾を孕んでいます。我々は実際に、業者が「確率的」または「最適な」在庫について語る一方で、その文書からは標準的な安全在庫計算や充足率などの時代遅れの指標の使用が明らかになる事例を確認しました。 結論: 宣伝内容と実際の測定・提供内容との不整合は重大な警告サインです。もし業者が現代的でAI主導であると謳いつつ、数十年前と同じKPIや手法を用いているなら、その革新は表面的なものに過ぎない可能性が高い。

• 時代遅れのアルゴリズムと実践: サプライチェーン理論は（決定論モデルから確率論モデルへ、単一段階から多段階最適化へと）進化しているのに対し、一部のソフトウェアはその流れに追いついていません。数十年前の手法への依存は弱点であり、業者がそうではないと偽る場合、なおさら問題です。例えば、需要の変動を動的に考慮しないで、依然として主に安全在庫＋再発注点の固定リードタイムロジックを在庫管理に用いているツールは時代遅れです。我々は、Slimstockが伝統的な数式（安全在庫、EOQ）に明確に焦点を当てている ²¹ ことに注目しました — これは基本的なソリューションとしては許容できるものの、明らかに最先端とは言えません。仮に先進的と称される業者が透明性を欠いているなら、実際には同じ手法を用いながら認めたくない可能性があります。さらに、Blue Yonderのオープンソースコードの断片がARMAモデルを示している ⁴⁸ 例もあり、これは販売資料でAIを謳っているにもかかわらず、1970年代の予測手法に依存していることを意味します。Infor、Oracle、John Galt などの下位層の業者もまた、Wintersの指数平滑法や簡易な最適化ソルバーといった、長年にわたって使用されている時系列手法やヒューリスティックに頼ることが多いですが、これらは動作するものの、決して現代的ではありません。重要なのは、古い手法を使うこと自体ではなく（状況によっては古い手法が最適な場合もあります）、それを革新的と謳いながら使ったり、より良い手法が存在するにもかかわらずそれだけに頼る点です。常に、「在庫最適化は需要の全分布を考慮しているのか、それとも単一のサービスファクターだけなのか？ マルチエシェロン最適化を使っているのか、単一ノードの計算だけなのか？」といった実際に用いられているアルゴリズムについて問いただすべきです。曖昧あるいは回避的な回答は、その手法が時代遅れであることを示唆しています。

• 技術的透明性の欠如: 最後に、メタ的な警告サインとして、業者が技術文書を一切提供しない、つまりホワイトペーパーもなく、リファレンスアーキテクチャもなく、アルゴリズムの解説もない場合、それ自体が警告となります。我々の調査では、技術面で高評価を得た業者（Lokad、Kinaxis、SASなど）は、ブログ、学術論文、または技術ノートといった形で少なくとも何らかの技術的情報を提供していました。一方、低評価の業者はマーケティング用のパンフレット以上のものを提示できないことが多いのです。たとえば、o9やBlue Yonderから詳細な技術ホワイトペーパーを見つけ出すのはほぼ不可能で、出回ってくるのは光沢のあるパンフレットばかりです。それに対して、Lokadは業者のアプローチを比較した18ページに及ぶ詳細な市場調査を公開しており ^{49 29 25}、さらに彼らのアルゴリズムの動作を解説するビデオも提供しています。もし業者が自社ソリューションの仕組みを秘密にしているなら、それは実際には特別なものではないのではないかと疑問が生じます。透明性は信頼性と直結します。 バズワードの背後に隠れ、手法を開示しない業者は、おそらく「普通の技術に余計な装飾を施しただけ」である可能性が高いのです。

結論として、非常に懐疑的でエンジニアリングを重視する視点を適用すると、多くの「先進的な」サプライチェーン最適化ソフトウェアは、約束ばかりで検証可能な革新性に乏しいことが明らかになります。マーケティングの虚飾を取り払い、我々は実際に触れられるデータ構造、アルゴリズム、性能、そして効果の証明に焦点を当てました。最良のソリューションは、示された予測精度、明確なアーキテクチャの選択、そして率直な文書化といった技術的中身を提供することで際立っていました。一方、劣ったものは矛盾、曖昧さ、そして時代遅れの基盤によって自らを露呈していました。この研究は、すべてのサプライチェーン実務者に向けた教訓です: 業者の主張を鵜呑みにしてはいけません。 証拠を求め、内部を精査し、サプライチェーンにおいても他のIT分野と同様に、**真の最先端の進歩は通常、オープンサイエンスと堅実なエンジニアリングによって裏付けられているのであって、ただ高尚なマーケティング主張に終始してはならないのです。

脚注