市場調査に戻る
Manhattan Associatesは、倉庫、輸送、受注管理、店舗、サプライチェーン計画のソフトウェアを提供しています。Manhattan Activeの各アプリケーションは、物理的な注文履行、在庫移動、人員、輸送、補充、顧客注文を調整します。ActivePlanningは、この実行系製品群に需要予測、配分、在庫計画を加えます。同社はGoogle Cloudで稼働するアプリケーションと並行して、導入済みのインストール型ソフトウェアも引き続きサポートしています。(1, 2, 3, 4)
サプライチェーン総合評価：5.5/10。
| 評価軸 | 評点 |
|---|---|
| サプライチェーンの深さ | 5.6/10 |
| 意思決定・最適化の実質 | 5.4/10 |
| 製品とアーキテクチャの整合性 | 5.8/10 |
| 技術的透明性 | 5.6/10 |
| ベンダーの真剣さ | 5.0/10 |
Manhattanの最も強い根拠は、業務実行とプラットフォームのエンジニアリングに関するものです。詳細なリリースノートは、発注の照合、倉庫を考慮した出荷計画、クロスドッキング、入荷の自動検証を説明しています。公開開発者文書は、環境の分離、データ複製、拡張、監査の仕組みを説明しています。(11, 12, 14, 15)
弱いのは経済的な意思決定モデルです。計画は依然として、予測、サービス目標、安全在庫、計画担当者が選ぶシナリオを中心に構成されています。資料は需要とリードタイムの変動を認めていますが、競合する在庫、輸送、注文履行の施策を評価する、統合された確率モデルは示していません。マーケティングも、いくつかの根拠が証明する範囲を誇張しています。事後的なM5順位には再現可能な公開プロトコルがなく、コードの再生成が技術的負債をなくし、プロンプトの指示がエージェントの信頼性を保証するとされています。その一方で、カスタマイズには依然として多額の有償作業が必要です。(6, 7, 9, 22, 26)
ManhattanとLokadの比較
Manhattanは、業務トランザクションと、それを実行する人員・設備を管理します。倉庫には、入荷、在庫記録、作業割当、ピッキング、梱包、出荷、自動化設備との接続が必要です。輸送業務には、出荷の作成、運送会社とのやり取り、輸送の委託、追跡、精算が必要です。企業の予測品質にかかわらず、こうした機能は必要であり続けます。Manhattanは、その実行環境の多くを提供します。(3, 4)
Lokadが集中するのは、そうした業務を方向づける経済的意思決定です。どれだけ購入するか、どこに在庫を置くか、どの需要を満たすか、費用の高い移送や代替調達をいつ正当化できるか、といった判断です。在庫最適化とサプライチェーン入門の背景にある考え方は、不確実性と財務的な結果を出発点にします。保守される数値レシピが日常的な意思決定を生成し、実務者は個々の商品を繰り返し判断するのではなく、レシピとその前提を改善すべきだという考えです。
例えばManhattanは、倉庫内のピッキング順序、輸送能力、配送要件を考慮して出荷をまとめられます。その出荷を急送すべきか判断するには、待つことで失う売上と顧客への影響、代替在庫の到着の不確実性、在庫の最善の競合用途も評価する必要があります。実行可能なルートは、この経済的判断の一部です。共通のアプリケーションデータモデルがあることは、共通の財務目的があることを示しません。
したがって、両社は同じシステムの異なる層を担えます。外部の意思決定エンジンが数量と優先順位を決め、Manhattanが購入、移送、注文履行を実行する構成です。ManhattanのAPIとイベントインターフェースは原理的にこの分離を支えます。ただし実際の連携では、意思決定の責任主体を維持し、競合するルールが密かに決定を書き換えないようにする必要があります。一方、Manhattan自身の計画モジュールは、予測、サービス方針、補充、配分を、実行ソフトウェアベンダーの製品群内に収めます。(2, 17)
意思決定、不確実性、最適化
実行機能には具体的な意思決定の仕組みがある
リリース26.2は、注文を分割する際に、倉庫の引当、容積計算、個々のピッキング順序を考慮する出荷計画を説明しています。ピッキング経路上の位置に応じてパレットをまとめることで、運賃を節約する一方で倉庫内の移動を過剰に増やす輸送計画を避けられます。これは業務領域間の具体的な相互作用です。同リリースは、入荷の自動化と、既存の拡張ワークフローへのエージェント統合も説明しています。(12)
ActivePlanningのリリース26.3も、有意義な詳細を示しています。Host Order Importは、実行システムで分割・統合された発注を照合し、元の計画参照を保持します。Flow Throughは下位階層の需要を仕入先への発注に集約し、上位の配送センターに長期保管することなく入荷を通過させます。これらは、利用可能な意思決定の前提となる状態の整合に取り組む機能です。(11)
Forward Buy on the Flyは、より限定的な経済計算を導入しています。利用者が値引き、値上げ、在庫保有費用、借入金利を設定し、選んだ結果を推奨発注に適用します。これは、一般的な在庫削減の主張より実質があります。ただし公開された画面は、計画担当者が選択するシミュレーションです。リリース文書は、競合するすべての購入、資金用途、期限切れリスク、不確実な需要の結果との自動比較を示していません。(11)
サービス目標が依然として計画の中心にある
補充スイートは、梱包単位、保存期間、在庫移送、仕入先の供給停止、季節的なリードタイム調整、ルールに基づく承認に対応しています。通常の発注処理を自動化し、高リスクまたは期限切れが近い在庫の移送を制限できます。こうした詳細は、現場で意思決定を生成するうえで重要です。(5)
しかしService Investment Strategies機能は、計画担当者に個別のサービス目標を設定させ、その安全在庫費用を比較させます。回転速度に基づくABC分類と、売上または数量による区分を明示的に使用しています。売上と販売頻度は、追加の一単位の限界的な経済価値を決めません。同じ分類内でも、利益率、代替、欠品の影響、期限切れ、資金の競合用途は大きく異なり得ます。一律目標から個別目標への移行は、方針に基づくシステムを改善しますが、経済的に適切な目的を確立するものではありません。(6)
MEIOのページは、需要とリードタイム双方の変動を考慮すると述べています。しかし、その不確実性をどう表現・較正し、商品、拠点、仕入先をまたいでどう組み合わせるか、得られた分布がどう意思決定に入るかは説明していません。公開ページは、安全在庫の配置と相互依存を機能的に説明していますが、統合された確率的な経済最適化器を示していません。(7)
予測手法は特定されているが、優位性は確立されていない
UFM.aiのホワイトペーパーは、Croston法、可変応答の指数平滑法、Holt-Winters、ARIMA/SARIMAに由来する構成要素を挙げ、それらを統計的な定式化にまとめ、機械学習で拡張すると説明しています。外部データが乏しいときは統計的な基盤を使い、追加要因が有用なときに適応させるとしています。単に予測をAIと呼ぶより具体的な説明です。数式、学習手順、再現可能なアブレーション評価の結果はありません。(8)
同じ文書は、M4コンペティションなどを根拠に、ハイブリッドモデルが代替手法より正確で信頼できると主張しています。コンペティションで成功したハイブリッド手法は、Manhattan独自の組み合わせや、異なる小売意思決定群での性能を検証するものではありません。ホワイトペーパーの匿名事例は在庫、サービス、売上の変化を報告していますが、顧客名、完全な評価期間、導入費用は明かしていません。
予測は、発注を改善せずに統計的損失を改善することもあります。利益率の高い補修部品の需要を過大予測することと、低利益率の生鮮品を過大予測することでは、経済的な影響が違います。Manhattanの開示は、予測改善が、サービス方針の計算を改めるだけでなく、次の購入、移送、配分の価値にどう変換されるかを示していません。
事後的なM5の主張には実際の手順が必要
Manhattanの計画ページは、M5との比較を2025年としています。専用のベンチマークページは、当初の5,500超のチームとの比較で上位1.4%に入ったと報告し、ブラインドで独立に採点され、現行製品のモデルが生成した結果だと説明しています。Walmartの日次売上と商品・拠点階層も特定しています。これはコンペティションとの後年の比較についてのベンダーの主張であり、Manhattanが元の2020年の大会に参加した証拠ではありません。(9, 31)
公開ページには、数値スコア、独立評価者の名前、予測ファイル、学習データの締切、評価期間、調整手順、集約水準別の結果がありません。精度部門と不確実性部門の両方に触れていますが、それぞれのManhattanの成績を分けて示していません。主催者は、点予測のWRMSSE順位と確率予測のWSPL順位を区別し、系列、期間、階層水準ごとの評価資料を公開しています。点予測での百分位順位は、分布予測の品質を示しません。(9, 10)
事後テストでは、モデル選択時に既に公開済みの評価結果を使わないための明確な統制も必要です。テストがブラインドだったというManhattanの説明には意味がありますが、非公開の手順では、何が誰から隠されていたかを独立に検証できません。評価成果物とモデル選択手順を公開すれば、比較は検証可能になります。
高順位は、特定の精度百分率、SKU・店舗レベルの性能、経済的収益を意味するわけでもありません。階層スコアは異なる水準の誤差を組み合わせますが、補充は特定の商品と拠点で行われます。欠けているのは、発注日時点で利用できた予測を、リードタイムと所有コストを経たあとの在庫、廃棄、サービス、利益に結びつける業務テストです。同ページがベンチマーク順位から実世界の意思決定の検証へ飛躍することは、開示した結果の範囲を超えています。
輸送最適化：どのモデルの中で探索を速めるのか
Manhattanの継続的最適化のページは、インメモリキャッシュ、マルチモーダルソルバー、ルート生成手法の自動選択を説明しています。輸送ネットワークの確率的分析が使用するアルゴリズムを決め、手動設定を減らすとしています。これは特定可能な適応的探索の仕組みです。その説明は、将来需要、輸送障害、不確実な到着、下流在庫への影響が統合してモデル化されていることを示していません。(13)
ページは速度が最大十倍になり、求解時間が最大80%減ると主張していますが、公開された問題集合、ハードウェア仕様、比較基準、経済評価はありません。この二つの最大値を同じ実行の測定値として扱うべきではありません。より重要なのは、ソルバーの速さがモデルの忠実度を示さないことです。配送約束、欠品、倉庫の混雑、代替施策を適切に表現して初めて、最適化が事業上の意味を持ちます。
LokadのHolimizationの考え方は、この区別を明確にします。最適化モデルの改善には、目的と利用可能な意思決定の変更が含まれます。Manhattanは拡張機構と業務パラメータを文書化していますが、最適化器の経済的定式化を改める同等のプロセスは示していません。パラメータの自動調整は、モデルが省略した経済的に重要な仕組みを追加できません。
技術の歴史とロードマップの一貫性
| 時期 | 公の提案 | その後の展開が示すこと |
|---|---|---|
| 2011–2012 | SCOPEのSupply Chain Process Platformは、共通データモデル、サービス指向アーキテクチャ、アプリケーション横断の最適化を約束しました。 | 計画と実行の統合は既に中心的な提案でした。エージェント追加によって初めて生じたものではありません。(27) |
| 2017 | Active Omniはクラウドネイティブ、バージョンレス、拡張可能な製品として登場しました。 | 現在の開発者文書と継続的なリリースは、持続したアーキテクチャ開発の証拠です。(28, 14) |
| 2019–2020 | Manhattanの広報誌は倉庫のAIと機械学習を推進するとともに、AIの見せかけに警鐘を鳴らしました。 | 記事は将来のアシスタントと当時の業務アルゴリズムを区別していました。この抑制は有用ですが、広範な予測の主張には依然として公開評価がありませんでした。(29) |
| 2020 | Active Warehouse Managementは、マイクロサービス、オーダーストリーミング、機械学習による人員と自動化設備の調整を伴って登場しました。 | 後年のリリースノートと顧客の処理量実績は、実行機能の継続開発を裏づけます。(30, 12, 24) |
| 2025 | ハイブリッドAIと事後的なM5比較が、計画に関する主要な主張になりました。 | 名称のある統計的構成要素は開示されていますが、ベンチマーク手順と経済成果の帰属は不完全です。(8, 9, 31) |
| 2026 | エージェント、MCPの相互運用性、導入の迅速化がスイート全体で宣伝されています。 | リリースノートはバックグラウンド処理と対話型アシスタントを区別しています。10月の総括は、夜間のコード生成が技術的負債をなくすという根拠のない主張もしています。(12, 23, 26) |
この歴史は、クラウドと実行分野に実質的なロードマップがあることを裏づけます。同時に、導入時の摩擦を減らして意思決定を統合するという同じ上位の約束が、新しい技術用語で繰り返し提示されてきたことも示します。重要な検証対象は、世代間で実際に消えた手作業、インターフェース、保守義務です。
2019年の記事は、初期のAI言説を評価するうえで特に有用です。業務アルゴリズムを支持し、対話型購買アシスタントを将来のものと位置づけていました。2020年の倉庫製品の発表は、その後、注文、人員、自動化設備の調整という具体的な課題を示しました。これらの主張は、企業全体の知能や自律的サプライチェーン管理より限定的であり、その範囲で評価すべきです。現在のエージェントカタログにも、同様に限定された自動化と対話支援が混在していますが、周囲の表現はより大きなものになっています。(29, 30, 23)
ソフトウェア構成とセキュリティ
文書化されているが大規模なソフトウェア資産
| 構成要素 | 確認できる役割 | 所有・運用への影響 |
|---|---|---|
| Java、Spring、DebianベースのOpenJDKイメージ、Docker、Google Kubernetes Engine | アプリケーション実行環境とコンテナ配備。 | イメージ作成と脆弱性検査の仕組みを備えた明確な実行環境に加え、大規模なオーケストレーション機構があります。(14, 15) |
| 250超のマイクロサービス | 文書化されたプラットフォームのアプリケーション、システム、ライフサイクルサービス。 | 多数の配備単位、インターフェース、障害境界の保守が必要です。この数は全顧客が使うサービス数ではありません。(14) |
| MySQL / Google Cloud SQL | 本番データの永続化と、対応する複製データベース。 | トランザクション状態と下流レプリカには、同期、スキーマ互換性、復旧が必要です。(19) |
| RabbitMQとElasticsearch | セキュリティ文書に記載されたメッセージングと索引サービス。 | 独自の容量、パッチ適用、復旧要件を持つ、状態を保持する追加コンポーネントです。(15) |
| Google Pub/Sub | 外部との非同期連携と監査ストリーム。 | サービスアカウントとメッセージ契約の管理は、引き続き連携運用の責任です。(15, 16) |
| Kafka、Spring Boot、MySQL binlogコネクター | Manhattanの変更データ取得パイプラインGravina。 | 別のメッセージング機構に複製の役割が定められています。データの可搬性には単純なファイル出力ではなく、パイプラインの運用が必要です。(19) |
| Rubik | スクリプトとKubernetes仕様を用いる、Manhattanのコンテナ化配備フレームワーク。 | ベンダー管理のライフサイクルツールはインフラを抽象化しますが、保守費用はなくしません。(14) |
公開文書は各構成要素に別々の役割を割り当てています。全体として運用負担は大きく、複数の状態保持システム、複製、コンテナのスケジューリング、拡張実行、アプリケーションサービスの互換性を維持しなければなりません。
2026年10月のベンダーの記事は、6,000万行のプラットフォームの約75%を毎晩再生成するため技術的負債が残らないというCTOの発言を引用しています。生成コードは反復的な実装作業を減らせます。しかし、スキーマ、業務上の意味、生成器、依存関係、テスト範囲、残りの手書きソフトウェアの負債はなくせません。コード量と再生成頻度は、単純さも正しさも証明しません。ソフトウェアの複雑さには費用が伴うという同社自身の認識に照らすと、この主張はとりわけ弱いものです。(26)
分離、連携、エージェントの権限
Manhattanの公開セキュリティガイドは、顧客環境ごとに別のGoogleプロジェクトとVPCを用い、リソースとネットワークを分離すると説明しています。アプリケーションのエンドポイントと制限された管理用エンドポイントを分け、範囲を限定したサービスアカウントや、非同期処理における利用者・組織・テナントのコンテキスト伝播を説明しています。これらは、脅威に対する境界を認識できるアーキテクチャ上の統制です。(15)
同じガイドは、重大な例外も明らかにしています。カスタム連携は暗号化されていない外向き呼び出しを実行でき、それは禁止ではなく非推奨です。したがって、プラットフォーム外に出るデータの安全性は、顧客固有の連携選択に一部依存します。監査ガイドは活動ストリームと変更検出を提供しますが、後者の多くは主としてManhattanの運用担当者から見えるものです。(15, 16)
Agent Foundryは、事前定義された認可済みAPIサービス、管理者設定の統制、コンテンツの無害化を追加します。APIの制限は意味のある封じ込め手段です。しかしFAQはさらに、指示によるガードレールがシステム指示への服従を保証し、捏造回答を防ぐと主張しています。プロンプトの指示は、そのような保証を与えません。セキュリティ上の問題は、誤ったり操作されたりしたエージェントが、指示にもかかわらず何を読め、何を変更できるか、そして認可と行動制限がモデルの外でどう強制されるかです。確認した資料は、顧客作成のワークフローと遠隔ツールについて、この境界を完全には説明していません。(22)
カスタムJava拡張にも具体的な境界があります。開発者用語集によると、プラットフォーム内で実行するカスタム拡張コンポーネントを開発・配備できるのは、Manhattanのプロフェッショナルサービス部門だけです。公開されたローコードとAPIによるカスタマイズの範囲はそれより広くなっています。本番データのそばで誰がコードを実行でき、誰が開発・保守費用を負担するのかを評価する際には、これらの仕組みを区別する必要があります。(18, 21)
設定の保守、可搬性、総コスト
拡張文書は、数百の業務設定、カスタムデータ属性、同期・非同期の拡張フック、UI拡張、外部サービスを説明しています。用語集は、同期ハンドラーが遅延を生む可能性と性能テストの必要性を警告しています。視覚的な画面が実装を生成する場合でも、これは継続的なソフトウェアエンジニアリングです。(17, 18)
バージョンレスな提供は、基本製品の大掛かりな更新プロジェクトをなくせるかもしれません。しかし商品、仕入先、チャネル、業務制約が変わったあとも、カスタムルールが意図した業務判断を表現しているか確認する必要はなくなりません。拡張はAPI互換性を保ちながら、経済的には誤ったものになり得ます。エージェント生成の拡張は作成手段を増やしますが、テスト、展開、可観測性、ロールバックの責任はなくしません。
財務報告は、この問題の規模を示しています。Manhattanは2025年に5.03億ドルのサービス売上を計上し、総売上の47%を占めました。サービス売上の約75%はクラウド契約に関連していました。同社によると、初期導入後も顧客は追加の拠点、機能、製品、サポートのためにサービスを購入し続けます。サービスは通常、時間・実費契約に基づいて時間単位で請求されます。これらの数字は拡張と保守の両方を含み、無駄の量を測るものではありません。クラウド提供でも相当量の有償の人手が必要だということを示しています。(1)
経済的責任という点では、時間単位の提供は明確な境界を作ります。支払いは実施した作業に対応し、顧客の実現利益に自動的に対応するわけではありません。したがって購入側には、基準値、完全な所有コスト、モデルや設定の不具合を修正する責任分担が必要です。公開事例の要約は、この会計を示していません。追加のコンサルティング、レビュー、エージェント設定は、主張する生産性改善から差し引かなければなりません。
可搬性には長所と制約があります。Data Streamは、ベンダー管理または顧客管理のCloud SQLへのMySQL複製を文書化し、APIは業務機能と設定を公開しています。これはデータに実用的な退出経路を与えます。設定済みの意思決定ロジック、拡張の挙動、エージェント方針の同等の可搬性を証明するものではありません。Developer Hubは、独自のOpenAPI仕様に別途秘密保持条件を課しています。公開概念文書は豊富ですが、詳細なインターフェースの検査は一部制限されます。(17, 19, 20)
エージェントと労働生産性
Manhattanのエージェントカタログには、実質的に異なる種類の仕事が含まれています。Verify ASN Agentは入荷の完了を確認し、バックグラウンドで終了処理を行います。別のエージェントは文書から出荷や請求書の情報を抽出し、業務記録を作ります。これは、人の作業待ち行列から取り除かれる具体的な取引処理です。一方、Wave Coordinatorは不足を調べて代案を提案し、Inventory Operationsは設定、障害、エラー、チケットのための自然言語インターフェースを提供します。後者は、人の注意を必要とする構造を保ったまま、既存の手順を速める可能性があります。(23)
リリース26.2はMCP ConnectとRemote MCPを追加し、外部エージェントがManhattanのツールを呼び、Manhattanのエージェントがテナント登録の外部サーバーを使えるようにします。ツールへのアクセスの標準化は、自律的な経済判断の設計・検証に比べれば安価な連携作業です。それ自体に最適化の評価を与える理由はありません。同じ商品確認、問い合わせ、承認の連鎖をエージェントに再現させることは、対話画面の下で主要な労働ボトルネックを温存する危険があります。(12)
同リリースは、スケジュール実行、バックグラウンド監視、拡張からの同期・非同期呼び出しにも対応します。こうした機能は対話操作を回避できます。したがって評価では、コネクターが利用できることと、実際に自動化された判断を区別し、無人完了、例外、人の修正、実務者あたりの継続的に管理できる仕事量を測る必要があります。公開カタログと会議報告には、代表的な計画導入全体についてのこうした指標がありません。
Pet Supplies Plusは、配置変更、設備、取扱量増加、Manhattan Active WMSなど複数の変更後に、時間あたり約170–180単位から240–250単位へ増加したと報告しています。受注から出荷までの時間も一日短縮したとしています。2025年6月の報告は、責任者が改善の15–20%超をWMSに帰属させたと引用しています。現在の要約は、WMSが15–20%の生産性向上をもたらしたと述べています。複合的な改善のうちソフトウェアが担う割合の下限から、ソフトウェア自体に帰属する増加率へどう移ったのか、要約は説明していません。(24, 25)
詳細な報告は、他の変更と顧客の留保を残しているため、帰属を判断する基盤として優れています。また、ActivePlanningの採用は2026年を予定していたと述べています。それ以前の倉庫改善は、その後の計画導入や新しいエージェントの性能を立証できません。
2026年10月の総括は、SP Richardsで在庫移送が減った事例と、Mavenが顧客サービスへの問い合わせを吸収した事例を加えています。これらは意味のあるタスク成果ですが、移送件数の減少や問い合わせの回避率だけでは純便益は決まりません。その後に確認すべきなのは、配送実績、費用、顧客問題の解決品質、例外処理やサポートに移った仕事を含めた総人的負担です。(26)
サプライチェーン評価
25の基準を等しく重みづけしています。各評価軸は五つの基準の平均で、丸め前の総平均は5.48、表示は5.5/10です。評点は製品カタログの広さだけでなく、開示された仕組みと結果を反映します。
サプライチェーンの深さ
| 基準 | 評点 |
|---|---|
| 経済的な枠組み | 6/10 |
| 意思決定の最終成果 | 8/10 |
| サプライチェーンに関する概念の明確さ | 6/10 |
| 時代遅れの中心的教義からの独立 | 4/10 |
| KPIの見せかけへの耐性 | 4/10 |
平均：5.6/10。
経済的な枠組み — 6/10。 運賃、在庫投資、劣化損失、先行購入の値引き、借入費用は具体的な経済的入力です。公開された意思決定モデルは、施策の統合評価を示すのではなく、実行費用とサービス方針の計算に分かれています。(5, 11, 13)
意思決定の最終成果 — 8/10。 倉庫作業、出荷計画、発注、入荷、補充は、実行機構が明示された業務上の成果です。これはManhattanの最も強い部分であり、個々の意思決定の経済的優位性については、根拠がより限定的です。(11, 12, 23)
サプライチェーンに関する概念の明確さ — 6/10。 発注照合、クロスドッキング、倉庫を考慮した出荷分割、調達制約は、実行業務の詳細な理解を示しています。計画思想は、不確実性や競合する施策の財務価値については精密さが劣ります。(5, 11, 12)
時代遅れの中心的教義からの独立 — 4/10。 継続的な実行とルールによる承認は、定期的な手作業の計画を超えています。しかし、サービス目標、ABC分類、安全在庫シナリオ、計画担当者による反復的な裁定が、在庫手法の土台であり続けています。(5, 6)
KPIの見せかけへの耐性 — 4/10。 一部の顧客報告は、実際の処理量と業務変化を示します。不完全なM5手順と、Pet Suppliesの生産性指標の説明されていない変更は、こうした結果から導く広範な結論を弱めています。(9, 24, 25)
意思決定・最適化の実質
| 基準 | 評点 |
|---|---|
| 確率モデルの深さ | 3/10 |
| 独自の最適化または機械学習の実質 | 6/10 |
| 現実の制約への対応 | 7/10 |
| 意思決定の自動化と労働生産性 | 6/10 |
| 現実の業務の複雑さに対する修正能力 | 5/10 |
平均：5.4/10。
確率モデルの深さ — 3/10。 MEIOは需要とリードタイムの変動を明示しています。ハイブリッド予測と適応的輸送の説明は、較正された同時不確実性や、それを共通の経済的意思決定モデルで使う方法を示していません。(7, 8, 13)
独自の最適化または機械学習の実質 — 6/10。 統計的構成要素、適応的ルート生成、倉庫を考慮した出荷判断は特定できます。その定式化と、独立に再現できる現在の評価は、最も強い優位性の主張を支えるには限定的すぎます。(8, 12, 13)
現実の制約への対応 — 7/10。 梱包単位、保存期間、倉庫のピッキング、クロスドックの流れ、上位システムの注文変更は具体的に扱われています。限界は、業務詳細の欠如ではなく、モデルの経済的・確率的な網羅性にあります。(5, 11, 12)
意思決定の自動化と労働生産性 — 6/10。 バックグラウンドの入荷確認、文書処理、ルールに基づく発注承認は仕事を取り除きます。顧客の処理量に関する根拠は有用ですが、計画全体の人手と、エージェントを導入した環境の保守負担は、公開資料では測られていません。(5, 23, 24)
現実の業務の複雑さに対する修正能力 — 5/10。 監査記録は設定変更を可視化し、拡張フックとProActiveのパッケージ化された移行は、アプリケーションロジックの改訂を支えます。最適化器の経済的定式化は、よりアクセスしにくいままです。省略された相互作用を追加し、保存した業務負荷で結果の判断を比較し、検証済みのモデル修正を本番に反映することは、文書で実証されていません。(16, 17, 21)
製品とアーキテクチャの整合性
| 基準 | 評点 |
|---|---|
| アーキテクチャの一貫性 | 6/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真剣さ | 6/10 |
| ソフトウェアの簡素さと所有コスト | 3/10 |
| プログラムおよびエージェント支援による運用への適合性 | 7/10 |
平均：5.8/10。
アーキテクチャの一貫性 — 6/10。 プラットフォーム文書は、共通の配備、メッセージング、拡張、ライフサイクルの仕組みを説明します。250超のサービスと複数の状態保持サブシステムには、なお調整費用が伴います。また、共有インフラが一貫した経済最適化器を証明するわけではありません。(14, 19)
システム境界の明確さ — 7/10。 上位システムの注文照合、APIとメッセージによる連携、顧客環境の境界、複製の責任が明示されています。これらのインターフェースは、実行システムを外部システムや意思決定ロジックから区別する助けになります。(11, 15, 17, 19)
セキュリティへの真剣さ — 6/10。 プロジェクト・VPCによる分離、範囲を限定したID、監査機構は評価できます。カスタムの外向き通信と、プロンプトによる保証の誇張は、連携とエージェントを完全に封じ込められるという信頼を制限します。(15, 16, 22)
ソフトウェアの簡素さと所有コスト — 3/10。 開示されたソフトウェア規模とサービス事業は、継続的な運用作業を具体化しています。バージョンレス更新と生成コードは、顧客固有の挙動の保守費用が低いことを示しません。(1, 14, 17, 26)
プログラムおよびエージェント支援による運用への適合性 — 7/10。 API、イベント、バックグラウンドエージェント、拡張フックは、大幅な自動化を可能にします。MCPはアクセス手段を増やしますが、その利用可能性を自律的な経済判断能力と混同すべきではありません。(12, 17, 23)
技術的透明性
| 基準 | 評点 |
|---|---|
| 公開技術文書 | 7/10 |
| ベンダーの仲介なしでの検証可能性 | 5/10 |
| 可搬性とロックインの可視性 | 5/10 |
| 導入手法の透明性 | 6/10 |
| 技術的主張を支える証拠の密度 | 5/10 |
平均：5.6/10。
公開技術文書 — 7/10。 開発者ポータルは、実際のアーキテクチャ、セキュリティ、拡張、複製機構を説明しています。最適化の定式化と現行の予測検証は、プラットフォームより大幅に不透明です。(14, 15, 17, 19)
ベンダーの仲介なしでの検証可能性 — 5/10。 技術的な読者は、プラットフォーム設計の多くを公開資料で確認できます。独自のOpenAPI仕様には秘密保持条件があり、M5結果には独立再現に必要な成果物がありません。(9, 20)
可搬性とロックインの可視性 — 5/10。 Data Streamは、顧客管理のデータベースへデータを届ける方法を説明します。設定済みワークフローの意味、カスタム拡張、エージェントの挙動は、Manhattanの実行環境とサービス境界への依存がより強く残ります。(17, 18, 19)
導入手法の透明性 — 6/10。 公開文書は、拡張の遅延、業務設定、API設定、ベンダー専用のカスタム部品、継続的な専門サービスを特定しています。代表的な導入のライフサイクル全体の労力は定量化していません。(1, 17, 18)
技術的主張を支える証拠の密度 — 5/10。 リリースノートとアーキテクチャガイドは、多くの業務上の主張を裏づけます。予測比較、普遍的最適化、技術的負債に関する主張は、開示された評価を超えています。(9, 11, 12, 26)
ベンダーの真剣さ
| 基準 | 評点 |
|---|---|
| 公的発信の技術的な真剣さ | 4/10 |
| 技術ロードマップの一貫性 | 6/10 |
| 概念の明確さ | 5/10 |
| 経済的責任 | 4/10 |
| エージェント型ソフトウェアの世界での競争力 | 6/10 |
平均：5.0/10。
公的発信の技術的な真剣さ — 4/10。 詳細な技術文書の価値は、プロンプトの指示が信頼性を保証し、夜間の再生成が技術的負債をなくすという主張によって損なわれています。ベンチマークページは証明を主張しながら、評価に必要な手順を公開していません。(9, 22, 26)
技術ロードマップの一貫性 — 6/10。 Active Omniから倉庫実行、現在の業務リリースに至る進展は、継続的な提供実績を示します。繰り返される統合の主張と新しいエージェント層には、連携作業と総所有コストを減らした根拠がなお必要です。(27, 28, 30, 12)
概念の明確さ — 5/10。 Manhattanは一部の対話型とバックグラウンド型のエージェント役割を区別し、物理的実行の依存関係を理解しています。しかし全体の説明では、予測改善、データ共有、作業高速化を、サプライチェーンの経済性向上と安易に同一視しています。(2, 9, 23)
経済的責任 — 4/10。 詳細なPet Suppliesの事例は因果関係に関するいくつかの留保を残し、財務報告はサービスモデルを明らかにしています。それでも公開情報は、完全なライフサイクル費用と帰属可能な利益を結びつけず、持続的に劣悪な意思決定ロジックの責任も定めていません。(1, 24, 25)
エージェント型ソフトウェアの世界での競争力 — 6/10。 トランザクション実行、倉庫連携、業務制約は、Manhattanにチャット画面を超える実質を与えています。その強みを維持するには、同じ大規模アプリケーション群の操作・設定手段を増やすだけでなく、反復作業を取り除くためにエージェントを使う必要があります。(11, 12, 23)
出典
出典は2026年11月4日に確認しました。顧客成果は発言主体を明示した報告であり、比較では実際に記載された時期、製品、指標を区別しています。
[1] Manhattan Associatesの2025年Form 10-K
年次報告書。Manhattan Associates、2026年2月4日提出。製品範囲、クラウドホスティング、専門サービス売上、請求モデル、継続的な顧客サービス。
ActivePlanningの概要。Manhattan、現行製品ページ。予測、補充、配分、実行アプリケーションとの関係。
倉庫管理。Manhattan、現行製品ページ。倉庫、人員、自動化、注文履行の機能。
輸送管理。Manhattan、現行製品ページ。計画、実行、運送会社、車両、精算の範囲。
在庫補充。Manhattan、現行製品ページ。保存期間、発注承認、仕入先の変更、移送、購入機会。
Service Investment Strategies。Manhattan、日付なし。サービス目標、ABC区分、安全在庫シミュレーション、財務比較。
MEIOの説明。Manhattan、日付なし。ネットワーク内の在庫配置と、需要・リードタイムの変動を考慮するという明示的主張。
従来の予測を超えて：ハイブリッドAIの優位性。Manhattan、日付なし。UFM.aiの名称が示された統計要素、機械学習との組み合わせ、匿名顧客事例。特に印刷ページ7–9。
M5ベンチマークの主張。Manhattan、事後評価を扱う現行ページ。上位1.4%という主張、ブラインドで独立に採点したという説明、競技部門の記述。
M5手法リポジトリ。M5コンペティション主催者、固定リビジョン。WRMSSEとWSPLの別々の評価、提出物、系列・期間・集約水準別の内訳を説明。
Waypoints Supply Chain Planning 26.3。Manhattan、2026年。上位システムの注文照合、先行購入、通貨処理、クロスドック補充。
Waypoints Supply Chain Execution 26.2。Manhattan、2026年。出荷とピッキング順序の調整、エージェント、スケジュール、拡張呼び出し、MCP Connect、Remote MCP。
Continuous Optimization。Manhattan、日付なしの現行ページ。インメモリキャッシュ、アルゴリズム選択、設定削減、性能の主張。
技術概要。Manhattanの開発者文書。Java・コンテナ構成、250超のマイクロサービス、イメージ作成、Rubik配備フレームワーク。
ActivePlatformのセキュリティ。Manhattanの開発者文書。顧客環境の分離、ID、通信、管理上の境界、明記された例外。
監査可能性。Manhattanの開発者文書。活動ストリーム、拡張・設定の追跡、変更検出へのアクセス。
拡張性と設定可能性。Manhattanの開発者文書。業務設定、データ属性、拡張フック、API、UI変更、外部連携。
用語集。Manhattanの開発者文書。同期ハンドラーの挙動、性能への影響、ベンダーのみが行えるカスタムJava拡張コンポーネントの開発。
Data Stream。Manhattanの開発者文書。MySQLログ、Gravina、Kafka、複製先、顧客とベンダーの運用責任。
Developer Hubの秘密保持契約。Manhattan、現行の公開条件。公開概念文書とは別に、独自のOpenAPI仕様へのアクセスを規定。
ProActiveローコードプラットフォーム。Manhattan、現行製品ページ。顧客によるカスタマイズと拡張作成の環境。
Agent Foundry。Manhattan、現行製品ページとFAQ。エージェント作成、API制限、管理者統制、指示によるガードレールの主張。
すぐに配備できるエージェント。Manhattan、現行カタログ。バックグラウンドでの取引処理、業務調査、対話支援を区別。
Pet Supplies PlusがManhattanによる効率改善を共有。Manhattan、2025年6月13日。処理量、他の業務変更、顧客による帰属、受注サイクルの改善、後年の計画導入構想。
Pet Supplies Plusの顧客ページ。Manhattan、日付なしの現行要約。生産性の帰属を詳細事例とは異なる形で表現。
ミラノからの記録：人は今も乗客ではなく操縦者。Manhattan、2026年10月19日。コード生成、技術的負債、導入期間、顧客のタスク成果に関する幹部の主張。
[27] Manhattan Associatesの2011年Form 10-K
2011年年次報告書。Manhattan Associates、2011年度について2012年に提出。SCOPE、サービス指向アーキテクチャ、アプリケーション横断の最適化、以前の共通プラットフォーム提案。
初のOmni-Channel-as-a-Serviceプラットフォーム。Manhattanの発表、2017年5月9日。クラウドネイティブ、バージョンレス、拡張可能というOmniの当初の提案。
Commerce Trends 2019/2020。Manhattanが執筆し、The Hive Networkが公開する雑誌。印刷ページ10–11に、Craig SummersによるAIの見せかけ、倉庫アルゴリズム、将来の対話型アシスタントの論考。
[30] Active Warehouse Managementの発表
クラウドネイティブWMSの発表。Manhattan、2020年5月20日。マイクロサービス、オーダーストリーミング、機械学習による自動化設備と人員の調整。
サプライチェーン計画の概要。Manhattan、現行製品ページ。事後的なM5比較を2025年と明記。