サプライチェーン計画スイートのベンダーLogilityの評価

最終更新日：2026年11月4日

市場調査に戻る

Logilityは2025年4月からApteanの傘下にあり、需要予測、在庫計画、生産スケジューリング、供給計画、ネットワーク設計、注文への在庫配分のソフトウェアを提供しています。顧客には製造業、卸売業、小売業があります。計画アプリケーションとデータ統合を組み合わせ、2026年からは計画を業務上の対応につなぐOrchestration Centerも提供しています。(1, 2, 6, 18)

総合評価：4.0/10

評価分野	点数
サプライチェーン理解の深さ	4.4/10
意思決定と最適化の実質	4.8/10
製品と構成の整合性	3.6/10
技術的透明性	3.6/10
ベンダーの真摯さ	3.8/10

Logilityには業務上の実質があります。在庫目標を計算し、在庫を配分し、共用生産資源を計画し、配送ネットワークをモデル化します。中心的な弱点は、これらの計算と、自律的で経済的知能を備えたサプライチェーンという広い主張との距離です。在庫方針は依然として顧客が選ぶサービス目標を中心にしています。ネットワーク最適化は、ソルバーに合わせて在庫の経済性を近似します。新しいエージェントは調査と承認済み業務を速めますが、経済的に難しい例外には計画担当者が必要です。これらは、需要と供給の共同不確実性の下で、共通の金銭的目的に従い購入・配分・生産を選ぶ能力とは大きく異なります。

過去の経緯からも、この区別は重要です。Logilityは2019年にすでに自律予測エンジンを宣伝していました。2023年のDemandAI+では予測技術を再び買収し、2026年の実行層はApteanによるOpsVeda買収に続いて登場しました。この流れには実際の提供がありますが、次々と掲げた自律性、測定された残存作業量、経済成果を突き合わせた公開説明は乏しいままです。顧客が生産向けに書くPythonにも構成上の懸念があります。Logilityは柔軟性を宣伝する一方、そのコードを囲むセキュリティ境界を説明していません。(5, 10, 13, 14)

LogilityとLokadの比較

製造業者が、部品を緊急調達するか、倉庫間で完成品を移すか、利益率の低い注文を延期するか判断する場面を考えます。Orchestration Centerは影響する注文を特定し、部品表を通して不足を追い、対応の選択肢を示します。公開例では重大なトレードオフを計画担当者に任せ、定義済み方針の範囲で日常的な移動を許可します。Lokadの運用モデルは、関連する費用、制約、不確実性を保守される意思決定ソフトウェアに組み込み、実行可能な行動を経済的に順位付けして実行用の推奨を出すことです。違いはトレードオフを解く場所にあります。整理された選択肢を人間が検討するのか、全体に繰り返す選択を計算で解こうとするのかです。(7, Lokadの在庫最適化)

どちらにも導入と保守が必要です。Logilityは設定済みモジュール、統合マッピング、生産スクリプト、サービスを組み合わせます。Lokadのサプライチェーンサイエンティストは顧客固有の数値レシピを保守し、新しい制約や誤った仮定には同様に開発作業が必要です。実務的に比較すべきなのは、意思決定を運用・改善する総仕事量です。例外に速くアクセスできることは有用ですが、その例外について繰り返す経済判断は作業として残ります。意思決定ロジックへの再利用可能な修正なら、次回以降の計算でその作業をなくせます。(5, 15, 19, ホリミゼーション)

LokadのIntroduction to Supply Chainは、この比較の背景にある経済的視点を説明します。特定の導入成果を証明するものではありません。同様にLogilityが買収した予測ツール、在庫モデル、スケジューリング能力も、生成する選択、判断時に利用可能な情報、維持費用によって評価すべきです。

計画エンジンが実際に決めること

サービス目標では経済的な配分は解決しない

Automated Inventory Policiesは、正規分布に従う需要と、間欠的または不規則な需要を区別し、望むサービスレベルの安全在庫を計算します。より広い在庫製品群には、原材料、仕掛品、完成品にわたる多階層最適化があります。在庫同士の関係や難しい需要パターンを扱いますが、公開された制御変数は依然としてサービス目標です。(2, 3)

サービス目標だけでは、欠品回避に企業がいくら払うべきかは決まりません。同じ需要分布を持つ二つの部品でも、欠けた場合の結果は大きく異なり得ます。一方は高額な組立ラインを止め、他方には安価な代替品があるかもしれません。サービス目標を変えることは、その設定者に経済計算を移します。欠けている重要なつながりは、欠品、遅延、資本消費、廃棄の金銭的結果から、競合する在庫・生産の選択を導く文書化された手法です。

Logilityの確率的在庫の記事は、需要分布、サンプリング、再発注パラメータを説明します。しかし、需要と不確実な入荷の共同モデル、較正結果、全体での意思決定検証は示しません。モンテカルロという用語だけでは欠落は埋まりません。不完全なモデルを繰り返しサンプリングすれば、誤ったトレードオフを安定して推定することもあります。(20)

ネットワーク設計には近似が明示されている

2025年のネットワーク在庫ガイドは、珍しく具体的です。確率的安全在庫式の区分線形近似、並列求解、業務上の在庫計算を2%以内で再現するとされる曲線当てはめを説明しています。入力には月次予測誤差、平均フィルレート、保有費用があり、リードタイムは指定した活動と輸送区間から組み立てます。保管制約と在庫費用がネットワーク計算に入ります。(4)

これは難しいモデル化問題への具体的な技術対応です。同時に構成上の限界も示します。不確実性が、ネットワークソルバーで扱える式に圧縮されます。別の在庫計算と一致しても、将来の業務に対する経済モデルの妥当性は検証できません。通常二週間で納めるが、ときに二か月止まる仕入先は、輸送が少し遅くても安定した仕入先とは異なる選択を求めます。安全在庫の近似曲線は、これらの未来と対応行動がネットワーク選択に残っていることを証明しません。

改善の問題も同じく重要です。二つの部品が同時に故障する、代替品が需要を変える、緊急調達に段階的な値引きがあると業務から判明したなら、モデルはその相互作用を保持する必要があります。解ける状態を保つために相互作用を除かなければならない定式化は、誤った単純化を固定します。実行時間やソルバーの収束ではこの問題に答えられません。元のネットワーク問題を効率的に解けても、適応力の評価は制限されます。

生産では具体的な制約を扱う

2023年11月の生産機能リリースは、共用資源で異なる品目を同じ開始・終了時刻に計画する機能を文書化しています。焼成、硬化、乾燥などが対象です。さらに、資源固有の目標と制約を書くPythonベースのFlexible Scriptsを導入しています。一般的な複雑性対応の主張よりも、現実の業務モデル化を強く裏付けます。(5)

残る検証は、歩留まり、部品到着日、処理時間が入力と異なったときのスケジュールの挙動です。リリースは確率的スケジューリングや、状況に応じた行動の経済的選択を説明していません。表現力のある顧客スクリプトは忠実度を高められますが、生産方式が変わるたびに理解、試験、保守を要するロジックも生みます。

注文の実行はあるが、自律性より範囲は狭い

Intelligent Order Responseは、大半の注文を自動的に充足し、不足への対応を推奨すると説明されています。配分アプリケーションにも柔軟な規則と自動業務フローがあります。したがってLogilityは実行可能な配分判断に達しており、予測やダッシュボードだけではありません。(18)

経済的な難しさは在庫不足時に集中します。競合のない注文の自動充足は取引作業を減らしますが、遅らせる注文を他顧客の失注や、不確実な将来需要に備えて在庫を残す選択肢とどう比較するかは示しません。公開された配分資料は、その目的関数、利用する予測分布、実現利益に対する方針の検証を明かしていません。

エージェント、生産性、矛盾する自律性の主張

AppCentral上のDemandAI+は2026年4月に、予測精度の確認、履歴・予測の取得、傾向検出、学習機会の特定という四つのエージェントとともに登場しました。中心は需要情報と予測の保守です。発表では自律運用と人間の介入が可能とされ、異常は計画担当者の確認を要する場合があります。測定対象の範囲、残る担当者の労働時間、以前の自動予測業務との比較はありません。(9)

Orchestration Centerの実行範囲はさらに広いものです。4月の発表では、エージェントが顧客の制限内で継続的に評価・実行し、意思決定を記録し、例外を上位に回すとしています。しかし2026年8月の説明は「Decision Intelligenceは意思決定の自動化を意味しない」と述べ、行動選択の中心に人間を置きます。旧版と後継版の違いではなく、同じ製品の説明です。自動行動と意思決定支援の境界は未確定のままです。(6, 8)

6月の業務例は、どちらの標語より具体的です。Fill Rate、Shortage、Rebalancingのエージェントが、例として示した仕入先遅延と影響注文を調べます。通常の補充・移動は自動実行できますが、重大な配分、緊急輸送、生産変更は人間が扱います。その後で記事は2–5%の利益率改善を示唆しますが、測定した導入例や評価期間を挙げていません。(7)

この設計は情報収集の作業を減らせます。生産性の上限は、残る例外次第です。どの顧客を失望させるか、緊急輸送すべきかを毎回人間が選ぶなら、対象の拡大や意思決定頻度の増加は引き続き人的作業を生みます。公開証拠は、どれだけ作業が消えるか、制限設定へ移るか、ベンダーとパートナーの作業がどれだけ支えるかを測定していません。

改善の生産性は別の問題です。繰り返し利益を損なう推奨があれば、目的、データ解釈、可能な行動を修正し、過去の再実行と管理された導入を行うべきです。予測の再学習や例外の優先順位付けだけでは、この循環になりません。Logilityは設定可能な部品を公開していますが、計画・実行エンジンを通して修正を再利用可能にする、全体を検査できる手順はありません。

技術の歴史：繰り返される自律性の約束

時期	記録された進展	記録が示すこと
2014	サービスの差別化や延期を含め、在庫最適化をS&OPに位置付け。	在庫とサービスのトレードオフは、現在のAI用語よりずっと前から製品の課題でした。
2017–2018	Halo買収に続き、HaloBoostと外部シグナルを用いる小売分析。	買収した予測・分析手法を、生産性と精度の主張とともに導入しました。
2019	Voyager Pulse Wiseを自律的な需要パラメータエンジンとして宣伝。Halo Demand Sensingを提供。	当時の自律性は予測保守に関するもので、20–50%の精度改善を主張しました。
2023	Garvis買収でDemandAI+と自然言語アクセスを導入。確率的在庫方針と生産スクリプトも登場。	複数の異なる能力が進歩しましたが、刷新されたAI提案でも買収した予測技術が中心でした。
2025–2026	ApteanがLogility、次にOpsVedaを買収。DemandAI+がAppCentralに登場し、Orchestration Centerを提供。	新しい所有者の下で、計画と業務調整を組み合わせています。

出典：2014, 2018, 2019, 2023, Garvis, Aptean, OpsVeda, 2026年のリリース。

2023年より前の記録からは、知能の主張の範囲を疑う理由があります。Pulse Wiseの文書化された役割は予測パラメータの調整でした。これは限定された自動化であり、「自律」という語で経済的責任を負うサプライチェーン判断にまで広げることはできません。後の発表にも、以前約束した生産性の何割を達成したか、既存顧客がHaloやPulse WiseからDemandAI+へ移行したか、移行後にどの仕事が残ったかは示されていません。

Garvis買収の発表は、70件超の導入、週次計画時間の70%削減、予測誤差の15–30%削減を報告しました。共通の仕事量や評価手順が公開されていない、供給者側の報告です。現在のデマンドセンシングのページは別途、注文、流通在庫、実売、POSデータで予測誤差を最大30%削減すると宣伝します。手法と、情報条件をそろえた比較基準は不明です。(10, 17)

歴史上の問題は、より限定的な予測・業務改善を、新たなサプライチェーンの枠組みへ繰り返し格上げしながら、同じだけ継続した成果説明を欠くことです。買収は有用な技術をもたらせますが、経済・業務の証拠は世代間をつなぐ必要があります。そうしなければ、名称が変わるたびに約束がリセットされ、顧客の計画作業は残ります。

ソフトウェア構成要素と統合境界

公開証拠から分かる構成は一部です。

構成要素・層	証拠と対象範囲	保有費用への影響
Microsoft Azure、複製ストレージ、仮想マシンの復旧	2024会計年度の開示がLogility SaaSのホスティングを説明。	複製、復旧、セキュリティ運用を含み、クラウド提供でも費用はなくなりません。
C#/.NETからAzureマイクロサービス、Python/Kubernetesの予測アプリケーション、Angular移行	公開された同僚の推薦文が、別々のLogility開発案件を説明。製品名、時期、現在の稼働状況は不明。	アプリケーション近代化の証拠ですが、現在の製品群全体の構成は示しません。
並列・分散・インメモリのデータ統合	現在のデータ管理資料が変更レコードの処理と標準ソフトウェアから分離したマッピングを説明。	転送作業の削減は有用ですが、顧客固有のデータの意味はマッピングに残ります。
並列ネットワーク最適化機能	ガイドが在庫を考慮したネットワーク設計の並列求解を説明。	複数の求解は計算資源を消費し、整合したモデルと実行管理を要します。
OpsVeda由来のオーケストレーションとAppCentralエージェント	Apteanの買収・提供発表が追加の実行層とエージェント層を特定。	計画、方針、業務行動は層の境界を越えて整合させる必要があります。

出典：15, 16, 21, 4, 14, 9。

データ管理層は増分同期と分離した個別マッピングを文書化しています。統合作業を減らし、更新の境界を保つ実用的な仕組みです。しかし意味の食い違いは解決しません。取消注文、隔離ロット、遅延入荷は、予測、在庫、スケジューリング、実行で同じ意味を持つ必要があります。速いコネクタは、正しい解釈と同じ効率で誤った解釈も伝播させます。

公開資料は、買収したエンジン全体にわたる共通の版管理された意思決定モデルを示していません。現在の製品群のデータベース、ソルバー、メッセージ処理の完全な一覧もありません。未解決なのは製品をまたぐ保守と意思決定の整合性です。買収した計算同士を一致させることに、継続的な統合費用がかかります。

設定の保守、セキュリティ、経済的責任

顧客のロジックもソフトウェア費用に含まれる

2024会計年度の開示は、通常の導入期間を三〜九か月とし、追加コンサルティング、設定、インターフェース、研修は別途課金すると説明しています。導入時に財務・物流指標を設定し、適合を評価するとも述べています。新しいAI導入の主張を評価する具体的な実装工程です。(15)

継続して管理する対象には、サービス目標、優先規則、マッピング、計画スクリプト、オーケストレーションの制限があります。顧客は、各規則の所有者、相互作用の試験担当、有害な意思決定の調査担当、更新時に意味を保つ担当を決める必要があります。Logilityが標準統合コードと個別マッピングを分けることは、この一部に役立ちます。しかし、顧客の意思決定ロジック全体にわたる版管理、再実行、ロールバック、移行は公開資料に示されていません。(21)

費用はインフラ請求書ではなく、人間の突き合わせ作業として現れることがあります。新しい生産制約が配分方針を変えると、計画担当者が更新されていないモデルを何度も補うかもしれません。初期設定と予測実行時間だけを数えると、継続的な開発・運用労働を見落とします。

Pythonの柔軟性には強制されるセキュリティ境界が必要

Flexible Scriptsは、顧客が生産制約をPythonで表現できるようにします。発表は実行境界を文書化していません。読めるデータ、ネットワークや秘密情報への到達、依存関係の管理、資源消費の上限、本番への昇格手順が不明です。これらの制御は提出コードの外部で強制する必要があります。分析者のミスや侵害された依存ライブラリが、業務データへの無制限アクセスになってはなりません。(5)

2024会計年度の開示は、コードレビュー、試験、パッチ、アクセス制御、Azureの復旧設備を列挙しています。SOC中心の説明は、実務担当者のコードをどう封じ込めるか、侵害された実行IDがどれだけ被害を与えるかを示しません。認証と定例管理では、この構成固有の問題に答えられません。検査可能な封じ込め設計がないため、セキュリティ点は大きく下がります。(15)

成果には失敗の条件が必要

Logilityには名前の分かる業務利用者がいます。2020年の顧客セッションは、Kraft Heinzの在庫最適化とDixonのサプライチェーン変革を説明しています。この採用は利用を示しますが、現在のエージェントの純経済貢献を示しません。(22)

2026年6月の利益率の範囲、以前の予測改善、Garvisの時間削減には、共通の基準、測定期間、顧客・ベンダー・パートナーの継続費用計算がありません。現在の自律性提案で何を失敗とみなし、誰が是正するかも公開されていません。これは経済的責任を弱めます。開示にある導入指標は有用な出発点ですが、総保有費用控除後の持続的収益と結び付け、各当事者が実際に制御できる対象に責任を対応させる必要があります。

詳細評価

総合点は、以下の25項目を同じ重みで平均した編集上の評価です。4.04/10を4.0/10に丸めています。

サプライチェーン理解の深さ

基準	点数
経済的な問題設定	5/10
具体的な意思決定への到達	6/10
サプライチェーンに対する概念の明確さ	5/10
旧来の中核的な教義からの独立	3/10
見せかけのKPIへの抵抗力	3/10

平均：4.4/10。

経済的な問題設定 — 5/10。 ネットワーク設計には在庫・輸送費用が入り、オーケストレーションは高くつく対応の選択肢を考慮します。在庫方針の仕組みはサービス目標から始まり、希少資源の経済的配分は十分に定義されていません。(3, 4)

具体的な意思決定への到達 — 6/10。 注文配分と生産スケジュールは業務行動につながります。文書化されたオーケストレーションは重大な例外を計画担当者に任せるため、自動選択の範囲は制限されます。(5, 7, 18)

サプライチェーンに対する概念の明確さ — 5/10。 多階層在庫、生産同期、不足の伝播は具体的な業務関係を捉えます。それらを統合した経済的意思決定の枠組みは文書化されていません。(2, 5)

旧来の中核的な教義からの独立 — 3/10。 サービス目標、S&OPの合意、計画担当者による例外処理が中心に残ります。エージェントのアクセスはこの運用を速めますが、繰り返す手動トレードオフがなくなった証拠はありません。(3, 9, 11)

見せかけのKPIへの抵抗力 — 3/10。 予測誤差削減と提案された利益率改善には、十分に定義された評価がありません。公表数値では費用控除後の意思決定の経済成果を証明できません。(7, 10, 17)

意思決定と最適化の実質

基準	点数
確率モデルの深さ	4/10
最適化または機械学習の独自性と実質	5/10
現実の制約への対応	7/10
意思決定の自動化と労働生産性	4/10
現実の業務の複雑さへの適応力	4/10

平均：4.8/10。

確率モデルの深さ — 4/10。 間欠需要の分布と確率的在庫計算は文書化されています。公開された仕組みは、需要と供給の共同未来を較正し、行動を経済的に順位付けして選ぶことまでは示しません。(3, 20)

最適化または機械学習の独自性と実質 — 5/10。 在庫を考慮したネットワーク定式化は実際の計算を明らかにし、予測の歴史は実装済みエンジンを特定します。予測面と経済面の優位性は公開情報では弱くしか検証されていません。(4, 12, 13)

現実の制約への対応 — 7/10。 同期生産、独自の資源制約、ネットワーク保管上限、注文配分は具体的な制約に対応します。製品証拠の最も強い分野です。(4, 5, 18)

意思決定の自動化と労働生産性 — 4/10。 日常的な実行と情報収集は自動化できます。定義された対象全体で、残る例外・設定・支援の総労働量を測った報告はありません。(7, 9)

現実の業務の複雑さへの適応力 — 4/10。 スクリプトと統合マッピングで変更はできますが、ネットワーク近似と分離した意思決定層はモデル改訂を制約します。有害な推奨から、試験済みで再利用可能な経済的修正に至る手順がありません。(4, 5, 21)

製品と構成の整合性

基準	点数
構成の一貫性	4/10
システム境界の明確さ	5/10
セキュリティへの真摯さ	2/10
ソフトウェアの簡素さと総保有費用	3/10
プログラム・エージェント支援による運用への適合性	4/10

平均：3.6/10。

構成の一貫性 — 4/10。 統合層と買収したオーケストレーション基盤には分かる役割があります。予測、在庫、生産、実行を通した共通の版管理済み目的と意思決定モデルは公開されていません。(14, 21)

システム境界の明確さ — 5/10。 オーケストレーションは既存の計画・業務システムの上に明示的に置かれ、データ管理はERPインターフェースを示します。システム間の矛盾する推奨の責任は、それほど明確ではありません。(6, 21)

セキュリティへの真摯さ — 2/10。 顧客のPythonスクリプトは特定の攻撃面を生みますが、調べた資料には封じ込めが記載されていません。企業の安全手順や認証は、強制される実行制限の代わりにはなりません。(5, 15)

ソフトウェアの簡素さと総保有費用 — 3/10。 複数のエンジン、マッピング、スクリプト、方針には継続保守が必要です。標準統合ソフトウェアと個別設定を分けることは有用ですが、顧客ロジックの全費用と試験負担は不透明です。(15, 21)

プログラム・エージェント支援による運用への適合性 — 4/10。 スクリプト、自動配分、エージェントツールはプログラム機能を提供します。しかし意思決定業務全体は、顧客やコーディングエージェントが安全に改善できる検査可能・版管理済みソフトウェアとして公開されていません。(5, 9, 18)

技術的透明性

基準	点数
公開技術文書	4/10
ベンダーの仲介なしでの検査可能性	3/10
移植性とベンダー依存の可視性	3/10
導入手法の透明性	4/10
技術的主張を支える証拠の密度	4/10

平均：3.6/10。

公開技術文書 — 4/10。 ネットワークガイドは数式と設定の詳細を示します。製品群の目的関数、実行境界、インターフェースについて、同程度の公開文書は乏しいままです。(4)

ベンダーの仲介なしでの検査可能性 — 3/10。 公開資料で一部の計算と業務は調べられますが、主要な予測・在庫・オーケストレーション計算は再現できません。詳細評価はベンダーに依存します。(3, 6, 19)

移植性とベンダー依存の可視性 — 3/10。 外部システムとの統合は記載されていますが、顧客の規則、スクリプト、モデルを製品群の外で書き出し・再利用する方法はありません。データ移動だけでは意思決定ロジックを保てません。(5, 21)

導入手法の透明性 — 4/10。 開示は標準期間、サービス、導入指標を示します。回帰試験と、顧客固有の経済ロジックを管理しながら改良する方法の説明は、はるかに少ないものです。(15)

技術的主張を支える証拠の密度 — 4/10。 具体的な生産計画・ネットワークの仕組みは有用な証拠です。自律実行、予測改善、経済成果の根拠は、主に主張と例示的な業務フローです。(4, 5, 7, 10)

ベンダーの真摯さ

基準	点数
公開発信の技術的真摯さ	3/10
技術ロードマップの整合性	4/10
概念の明確さ	4/10
経済的責任	4/10
エージェント型ソフトウェア時代の競争力	4/10

平均：3.8/10。

公開発信の技術的真摯さ — 3/10。 同じOrchestration Centerに、両立しない自律性の範囲が示されています。具体的な計算や業務手順を挙げる箇所では、技術説明がより有用です。(6, 8)

技術ロードマップの整合性 — 4/10。 年表には予想だけでなく、提供済み製品と買収があります。しかし、繰り返す自律性の約束を、実際に引き受けた仕事量や経済成果と製品世代を越えて結ぶ継続的な証拠がありません。(12, 13, 10, 14)

概念の明確さ — 4/10。 不足の伝播と対応の調整は明確に説明されています。広い提案では、情報アクセス改善、予測調整、経済的に適切な意思決定の計算の区別が曖昧です。(7, 9)

経済的責任 — 4/10。 導入指標は評価の土台になります。公開された成果主張は、純収益、範囲を定めた継続義務、期待外れの成果を修正する責任を定義していません。(15, 7)

エージェント型ソフトウェア時代の競争力 — 4/10。 生産・ネットワークモデルには、依然として重要な分野固有の仕事があります。予測取得、調整画面、例外案内は再現しやすい一方、より深い自律的経済エンジンの公開証拠は限られています。(4, 5, 9)