市場調査に戻る
QADは、ERP、サプライチェーン計画、購買、在庫、工場での実行管理など、製造業務向けソフトウェアを提供する。以前はQAD DynaSysとして販売されていた計画スイートは、需要予測、調達、生産、配送、S&OPを対象とする。Redzoneは工場の現場業務を支援し、ChampionAIは企業アプリケーションの周囲にアシスタントと自動ワークフローを加える。(1, 7)
サプライチェーン総合評価：5.2/10
| 評価分野 | 評点 |
|---|---|
| サプライチェーンへの理解の深さ | 5.4/10 |
| 意思決定と最適化の実質 | 5.8/10 |
| 製品とアーキテクチャの一貫性 | 4.8/10 |
| 技術的透明性 | 5.2/10 |
| ベンダーの真剣さ | 5.0/10 |
QADには相応の製造機能がある。公開計画文書は、サプライヤーカレンダー、輸送積載、有限能力、供給変動を含む、実際の購買・生産計算を説明する。しかし、全体を支配するプロセスは、予測に基づく計画、在庫方針、設定された優先順位、担当者の介入の組み合わせに留まる。文書は、不確かな将来にわたり調達、生産、在庫の行動を評価する共通の経済目標を確立していない。(2, 3, 4)
新たなAI提案が扱うのは別の問題だ。文書処理、サプライヤーからの情報収集、質問への回答、古いカスタマイズの理解である。これらには実際に労働がかかるが、自動化しても補充や生産判断が良くなった証拠にはならない。NVIDIAとの統合計画とともに発表された、より広範なManufacturing Intelligence層は、2027年春の提供予定だ。想定される能力と、すでに本番稼働が説明されているワークフローは区別すべきである。(6, 9, 10)
QADとLokadの比較
QADの中心は、取引、材料記録、生産資源、工場チーム、それらを結ぶプロセスという製造業務環境だ。Lokadの定量的サプライチェーン手法は、その記録に基づく経済的意思決定を中心に据える。リードタイムを含む確率的な需要と供給に照らして、購買、生産、配分などの選択を評価する実行可能なロジックを構築する。
サプライヤーが遅れると、違いが具体的になる。QADのProcurement Championは連絡を追跡し、注文ワークフローを更新する。経済的に難しい問いは、特急対応、代替、注文の分割、生産変更、欠品の許容のどれを選ぶかから始まる。答えるには、下流への影響と不確かな代替案の比較が必要だ。事務の自動化は、その計算に使える情報を改善し得るが、計算自体を与えるものではない。(6)
Lokadの在庫最適化サービスでは、サプライチェーンサイエンティストがデータ解釈と意思決定ロジックを構築・維持する。そのため継続的なモデル改善が明示的に業務の一部になる。QADは類似の責任を、アプリケーション、顧客設定、導入サービス、運用チームに分散する。最近のカスタマイズ分析は、その負担の重要な部分を扱うが、公開成果は主に移行前の調査に関するものだ。(9, 14)
両ベンダーに必要な検証は、事業への理解が変わるにつれて意思決定システムが経済的に改善するかである。技術的に成功した移行、速い予測サイクル、生産性の高い担当者があっても、元の意思決定方針は誤ったままかもしれない。Lokadも自社の技術・サービス費用を差し引いた収益を示す必要があり、経済性を重視する姿勢は顧客成果の代わりにはならない。
計画ソフトウェアが実際に計算するもの
製造と購買には具体的なモデルがある
2019年のProduction Planning文書は、費用ベースの手法とヒューリスティクスを組み合わせ、材料、労働、工具、資源の制約を扱うと説明する。異なる生産段階や拠点、残業、外注、在庫積み増し、キャンペーン生産、保存期間に対応する。有用な判断を伴う、開発の進んだ製造モデルだ。公開説明は、数理定式化や競合する費用をどう統合するかを明らかにしていない。(2)
Procurement Planningも具体的だ。必要量は発注点、在庫日数、予測、DDMRPから得られる。その後の注文生成は、サプライヤーカレンダー、数量刻み、購買制約を守る。先読みロジックで将来の必要量を前倒しし、輸送能力を埋めることもできる。複数商品・期間を調整する機能だが、稼働率だけでは決められない経済的選択も生む。(4)
トラックの積載率を上げると単位輸送費は下がるかもしれないが、資金を早く拘束し、期限切れリスクを高め、より価値のある購買を押しのける可能性もある。実行可能な生産計画が、希少な原料を低利益の商品に使う場合もある。QADの費用・制約処理はこれらの一部に対応する。欠けているのは、将来の数量、時期、代替案が不確かな場合に、意思決定全体をどう評価するかという公開説明だ。
スイートの財務層は、業務計画を予算と比較し、運転資金や総資産利益率などの指標を示す。報告はシナリオの判断に役立つが、計画を財務面から見られることは、数値エンジンが期待経済収益によってその計画を選んだ証拠ではない。(5)
変動はモデルに入るが、共同意思決定の仕組みは不明
QADのDemand Planning文書は、在庫計算に予測誤差、需要と供給の分散、リードタイムを明示的に含める。また、意思決定の凍結期間に応じて時点をずらして予測精度を検証する方法も説明する。これらは適切な仕組みだ。不確実性を認め、予測が実際に必要だった時点で評価できる。(3)
より難しいのは不確実性の相互作用だ。材料の遅延、歩留まり変動、需要急増は、どの生産を確定すべきかを共同で変え得る。分散による安全在庫計算は、組み合わされた結果の確率分布も、その代替案の経済的順位も確立しない。公開文書はその接続を解明していない。
セグメント分けの規則とサービスレベル目標も吟味が必要だ。これらは、多くの下流のトレードオフを評価する前に、事業上の選好を在庫要件に変える。同一セグメント内の一律目標は、限界価値、代替可能性、期限切れリスク、顧客への影響の大きな差を隠し得る。セグメント分けを精緻にしても、設定作業が増える一方、経済的近似が修正されるとは限らない。(5)
予測の主張には意思決定に合った粒度が必要
過去の需要パンフレットは、予測精度が最大90%改善すると宣伝する。これは改善率の主張であり、SKU予測が90%の精度に達するという意味ではない。それでも、数値を解釈するための指標、基準値、期間、集約は示されない。デマンドセンシングという名称にも、追加のシグナルが適切な発注期限でどれだけ貢献するかという比較評価がない。(3)
製造業にとって有用な問いは、更新した予測が購買や生産判断を採算の良い方向に変えるかだ。商品を集約したり期間を長くしたりすると、意思決定に必要な違いを消しながら精度の百分率を改善できる。QADの時点をずらす検証機能は有用だが、見出しはその手順での結果を開示しない。
ChampionAI：事務自動化と意思決定責任
QADは会話型アシスタントと、バックグラウンドで動くChampionsを区別する。2026年9月のリリースは、請求書を読み、注文・受領と照合し、不一致を人に回す買掛金処理を説明する。本番の数値として、自動照合90%、スキャン請求書の抽出精度95%を挙げる。これらは文書処理の割合であり、需要予測ではない。(7)
調達製品は注文情報を監視し、サプライヤーをフォローし、例外を上位に回す。売上原価の削減可能性は、購買担当者を戦略的調達と交渉に振り向けられることに帰せられる。間接的な生産性の提案だ。浮いた時間の使い方と、そこから生まれる商業判断の改善に依存する。フォローを完了したこと自体は調達費用の削減ではない。(6)
それでもQADのChampionAIキャンペーンは、顧客チームがすべての行動を送信前に確認すると説明する。2026年1月のクラウドプログラムもAI出力を現状有姿で提供し、業務で依拠する前に適切な人間の確認を求める。対象は製造業務とサプライチェーンのクラウドサービスであり、Connected Workforceには別の条件がある。(8, 14)
自律性の宣伝の背後には、重要な運用上の問いが残る。どの行動を自動承認し、どれを抜き取り確認し、どれを個別確認するのか。その答えによって、労働が例外的な出来事に比例するか、取引の全量に比例するかが決まる。有害な意思決定方針を誰が修正できるかも決まる。
ChampionAIプラットフォームの技術職募集は、MCPインフラ、プロンプト、ツール接続、エージェントの展開を実際の開発業務として挙げる。言語モデルを企業ツールにつなげば、操作の摩擦を減らせる。一方、既存の画面、メッセージ、キューを効率良く扱うだけなら、古いワークフローを温存する。公開根拠は、この制御層が計画スイートの根本の目的や不確実性モデルを置き換えたとは示していない。(11)
買掛金処理には別の経済的検証もある。請求書処理を早く終えれば割引を得られる場合があるが、早期支払いは現金も早く消費する。適切な支払日は、割引、資金調達費用、契約条件、サプライヤーへの影響による。自動化はこのトレードオフを最適化すべきであり、処理の高速化と支払期間の短縮を同じ財務上の利益と扱うべきではない。(7)
技術の変遷と実現状況
| 時期 | 公開上の位置づけ | 実現したものと未解決の問い |
|---|---|---|
| 2016年 | クラウド製造ソフトウェアと選択的なインメモリ処理 | シミュレーションと取引履歴でインフラ要件が異なる理由を説明。 |
| 2018年 | Channel Islands近代化プログラムの完了 | Webインターフェース、RESTサービス、アプリケーション基盤を提供済みの成果として明示。 |
| 2019年 | AIによるDSCP | データ洗浄、需要クラスタリング、外部系列を使う予測を具体化。追加的な経済成果の測定はない。 |
| 2020年 | ブロックチェーンへの熱意の再評価 | QAD幹部が2017年の熱意を振り返り、導入と標準化の障壁を強調。 |
| 2025年 | Redzone生産性ベンチマーク | 大規模な運用データで、導入と指導を組み合わせたプログラムを測定。 |
| 2026–2027年 | ChampionAI、Lynx、Manufacturing Intelligence | 具体的なワークフロー製品と、翌年予定の広範な知能層が併存。 |
QADの歴史には、流行語を順番に採用するだけではない選別がある。2016年には、計画シミュレーションへのインメモリ計算を支持しつつ、取引履歴の万能解としては退けていた。作業に即したアーキテクチャ論である。同じ記事は顧客による更新の管理を重視していたが、現在のクラウドプログラムではQADが版の展開を管理し、顧客にテストを求める。クラウド近代化で、制御と作業の配分は変わった。(17, 14)
2018年のChannel Islandsの説明は、RESTアクセスと別個の統合サービスを備える、複数年の基盤・インターフェース計画を述べた。特定可能な工学的成果だ。2026年にもカスタマイズの把握に大きな作業が残ることは、新しい基盤だけで既存顧客の業務ロジックが移植可能になったり、安く変更できたりするわけではないと示す。(19, 9)
2019年のAIの主張も対象は特定できた。階層データの欠損補完、似た需要履歴の分類、外部系列の予測利用である。広範な知能という語彙は実証された作業を超え、とりわけ評価方法なしに因果関係に言及していた。これらの限定的なML機能は、現在の自律的な製造判断という主張を裏づけない。(16)
ブロックチェーンは別の前例だ。2020年、QADのTom Robertsは以前の熱意を公に振り返り、参加者に共通標準の採用と共有インフラの費用負担を求める難しさを説明した。実務上の障害を明示的に再評価する技術評論だった。QADのブロックチェーン製品が失敗した証拠ではない。(18)
2026年9月のManufacturing Intelligence発表はさらに野心的だ。予定するNVIDIA統合に支えられ、システムを横断して出来事を解釈し対応を開始する層を掲げる。市場投入予定は2027年春である。NVIDIAの名前はQAD固有の計画手法の改良を示す根拠ではなく、発表にも統合システムの導入済みベンチマークはない。経済的な主張は、今後の提供を確認すべき約束に留まる。(10)
ソフトウェア構成とアーキテクチャの境界
| 製品・チームと根拠の時点 | 文書化された構成要素 | 帰結 |
|---|---|---|
| DynaSys計画、2019年の製品文書 | インメモリ計画モデル、組み込みQlik分析、ERP交換用データハブ | 計画状態、分析、取引記録には整合した対応づけと更新が必要。 |
| ERP開発、2026年11月閲覧の求人 | Progress OOABLとJava開発 | 従来のアプリケーション実行環境には引き続き専門的保守が必要。 |
| ChampionAI基盤、2026年11月閲覧の求人 | MCPインフラ、Kubernetes展開、LaunchDarklyによるプロンプト展開。Python/FastAPIとPostgreSQLの技能も職務要件 | エージェント独自の実行、設定、評価、展開のライフサイクルが加わる。 |
| Lynx、2026年9月発表 | AWS TransformとAmazon Bedrock | 近代化はQADによる自社アプリケーションの解釈に加え、外部のモデル・変換サービスに依存。 |
| 全社採用ページ、2026年11月 | Java、JavaScript、AngularJS、C#、MySQL、MongoDB、Progress。AWSとGCPでのクラウド運用 | 広範な製品群は複数の技術系列を支える。その存在は単一の顧客導入構成を示さない。 |
単純な構成要素の数よりも、こうした境界が重要だ。計画エンジンはERPの数量と日付を一貫して解釈する必要があり、エージェントにはその記録を変更する権限が必要で、業務アプリケーションは承認された行動を実行しなければならない。表現が増えるたびに、対応づけ、リリース調整、障害診断が加わる。
QADはChampionsをERPやMESとは別の基盤に置くと明言し、旧式や他社のシステムにも導入する。段階的な採用が可能になる。一方、同じブランドだから同じ数値モデルとはいえない。異なる歴史と責任を持つアプリケーション間の接続を通じても、意思決定の意味が保たれなければならない。(7)
インメモリ計画はシナリオ計算を短縮しながら、相応のメモリ・再計算費用を残し得る。公開資料は、代表的なネットワーク規模、負荷に応じた実行時間、全体更新の費用を示さない。経済的な問いは、事業が変わっても意思決定システムを正しく維持するため、どれだけのインフラと専門作業が必要かである。
設定の維持と所有費用
顧客固有のロジックは、QADの提案と所有負担の中心だ。現在のLynxページは、カスタマイズを走査し、依存関係を説明し、旧来のロジックを現代的な拡張に変えると述べる。これは別の会話画面を増やすことより、長期的生産性に関係する。ソフトウェアを理解・変更する労力を減らそうとしているからだ。(23)
発表には具体例がある。匿名の受託製造・包装企業で1,000件超のカスタマイズを一覧化し、初回で約三分の二に移行経路を示した。案件は約50万ドルの予想節約額を特定した。これは調査、分類、範囲を定めた近代化計画の成果であり、すべての変更の完了や実現した節約の証明ではない。(9)
カスタマイズの動作を保存することは検証の一面にすぎない。ルールが経済的に悪い方針を忠実に再現する場合もある。有用な近代化には、その問題を診断し、根本の目的やデータ解釈を変え、代表的な状況を再実行し、安全に修正を提供することも容易にする必要がある。公開されたLynxの成果は、まだこの全循環を追っていない。
2026年のクラウドプログラムは、新しいシステムの変更を承認済みの拡張機構に限定し、顧客が開発環境へアクセスするため開発者認定を要求し、互換性のない変更をQADが阻止できるようにする。また、設定変更、テスト、データ洗浄、アップグレード案件を標準範囲から別途除外する。(14)
結果としてTCOには、利用料、統合、モデル維持、回帰テスト、有用な変更が本番に届くまでの遅れが含まれる。変更を制限すれば無秩序な改変を減らせるが、購入者には正当な変更を手頃に行う道も必要だ。アップグレードに安全な拡張でも、理解、検証、置換が高くつくことはある。
Mayoly Spindlerの過去事例は運用モデルを示す。2019年8月の事例は、2007年の計画開始、2008年の選定、需要から生産への段階的な案件、30人超の利用者、毎月の協働プロセスを説明する。導入は中央集約の計画規律を生んだが、部門をまたぐ継続的な参加も必要とした。(20)
セキュリティはエージェントの権限に対応すべき
QADの公開Security Overviewは、ネットワークとユーザーの分離、セキュリティテスト、責任分担を説明する。仮想ホスト、コンテナ、アプリケーション層の設定も顧客責任とする。しかし、各責任を現在の各SaaS製品に正確に対応づけていない。サービスが防ぐ誤りと、顧客が防ぐことを期待される誤りを知るには、この対応づけが必要だ。(15)
エージェント基盤の求人は、認可と範囲の審査、動作テスト、段階的なプロンプト展開を挙げる。関連する工学的活動だ。それでも公開説明は、侵害されたエージェントを実行時権限がどう制限するか、プロンプトとは独立してツール呼び出しをどう拘束するか、有害な行動をどう取り消すかを示さない。(11)
サプライヤーのメッセージや請求書は、信頼できない入力だ。エージェントがそれを読み、企業記録を更新できるなら、セキュリティ境界は悪意ある内容と誤ったモデル出力に耐えなければならない。承認が役立つのは、確認者が実際に提案された効果を見られ、その確認を迂回できない場合だけだ。認証や一般的な最小権限方針では、この性質は立証できない。
生産性の根拠と経済的責任
Redzoneの2025年ベンチマークは、対象集団と介入内容を珍しく明確にしている。2013–2024年に90日間の導入プログラムを完了した1,500工場を対象に、自動OEE記録と指導、経営陣の支援、協働ツールを用いた。QADは平均26.4%の生産性向上を報告する。観察対象はこの組み合わされた運用プログラムである。ソフトウェアの寄与を単独で特定したり、後から導入されたChampionsの価値を立証したりはできない。(22)
OEE向上は、販売可能な生産を増やし、残業を減らし、設備投資を避けるなら価値がある。一方、需要や在庫の判断が変わらなければ余剰生産を生むこともある。したがって工場生産性の指標には、サプライチェーンの収益につなぐ財務的説明が必要だ。
計画事例の根拠はより不完全だ。QADの匿名冷凍食品事例は、計画ソフトウェアとS&OP変更を組み合わせた九か月の導入後、在庫が約50万ドル減り、予測精度が17%改善したと報告する。費用の完全な分母と寄与の特定方法はない。Mayoly Spindlerは実名の業務上の証言を提供するが、そこでも継続的な計画労力を差し引いた経済的純収益は立証されない。(20, 21)
QADの公開クラウド条件は、経済的な意思決定品質よりも、サービス可用性とサポート義務を具体的に定義する。購入者は案件を、比較基準、測定期間、総費用、範囲を定めた是正プロセスに結びつける必要がある。そうしなければ、ベンダーは動くソフトウェアを納めても、顧客には不採算の計画方針が残り得る。(14)
サプライチェーン評価
サプライチェーンへの理解の深さ
| 評価基準 | 評点 |
|---|---|
| 経済的な問題設定 | 6/10 |
| 意思決定の到達点 | 7/10 |
| サプライチェーンの概念的明晰さ | 6/10 |
| 旧来の中核的教義からの自由度 | 4/10 |
| KPIによる見せかけへの耐性 | 4/10 |
平均：5.4/10。
経済的な問題設定 — 6/10。 調達・製造計算には実際の費用と資源の選択が含まれる。財務計画はサービスレベルを超えて視野を広げる。欠けているのは、需要と供給の不確かな結果にわたって意思決定を評価する、共通の金銭的目標である。(2, 5)
意思決定の到達点 — 7/10。 計画スイートは業務制約を含む購買、配送、生産計画を生成する。実行可能な出力だ。トレードオフの受け入れ、方針設定、例外処理には、依然として大きな周辺プロセスが必要になる。(1, 4)
サプライチェーンの概念的明晰さ — 6/10。 サプライヤーカレンダー、材料の依存関係、製造段階は、製品に詳しい業務語彙を与える。相互作用する不確実性のもとで、実行可能な計画を経済的に正当な確定判断へ変える部分では、公開された論理が弱くなる。(2, 4)
旧来の中核的教義からの自由度 — 4/10。 S&OP調整、サービスレベルによる分類、バッファー中心の補充が中核に残る。これらは仕事を整理する一方、目標や分類の背後に個々の判断の限界費用を隠し得る。(4, 5)
KPIによる見せかけへの耐性 — 4/10。 予測改善の見出しには再現可能な測定定義がない。Redzoneはより明確な業務評価を示すが、精度百分率やOEEの改善だけではサプライチェーンの採算を直接立証できない。(3, 22)
意思決定と最適化の実質
| 評価基準 | 評点 |
|---|---|
| 確率的モデリングの深さ | 4/10 |
| 最適化または機械学習の独自の実質 | 6/10 |
| 現実の制約への対応 | 8/10 |
| 意思決定の自動化と労働生産性 | 6/10 |
| 実際の業務の複雑さへの耐性 | 5/10 |
平均：5.8/10。
確率的モデリングの深さ — 4/10。 在庫計算は需要と供給の変動を認める。文書は、購買や生産確定の選択に入力される共同の確率的将来像を開示しない。そのため、相関する不利な結果の評価は不明なままだ。(3)
最適化または機械学習の独自の実質 — 6/10。 詳細な計画機能と特定された学習課題は、説明のないAIラベル以上の実質を与える。ただし、単純な代替手法を経済的にどう上回るか、新しいエージェントが数値エンジンをどう改善するかは、公開根拠から分からない。(2, 16)
現実の制約への対応 — 8/10。 製品は、輸送、材料、カレンダーの連動を含む重要な製造・調達制約を表現する。その表現の維持は導入作業として残り、範囲の広さだけで不確実性を解決できるわけではない。(2, 4)
意思決定の自動化と労働生産性 — 6/10。 文書処理とサプライヤー調整は反復作業を減らし得る。宣伝と契約には人間の確認が残り、公開された労働の数値は、監視、例外、継続設定を包括的に算入していない。(6, 8, 14)
実際の業務の複雑さへの耐性 — 5/10。 カスタマイズとLynxは業務ロジックを変える仕組みを与える。公開例は、失敗した計画上の前提を診断し、目的や行動を再定式化し、過去の再実行を行い、持続する修正を安全に公開するところまで追っていない。シナリオを速く選べても、その改善プロセスを立証したことにはならない。(9, 23)
製品とアーキテクチャの一貫性
| 評価基準 | 評点 |
|---|---|
| アーキテクチャの整合性 | 5/10 |
| システム境界の明確さ | 6/10 |
| セキュリティへの真剣さ | 3/10 |
| ソフトウェアの簡素さと所有費用 | 4/10 |
| プログラムによる運用・エージェント支援運用との適合性 | 6/10 |
平均：4.8/10。
アーキテクチャの整合性 — 5/10。 DSCPは統合計画モデルを説明し、Championsは別個の企業アプリケーションを横断する。一貫したデータ交換は開発されているが、製品群に共通する計算目標は確立されていない。(5, 7)
システム境界の明確さ — 6/10。 製品説明は、計画、取引、エージェントの流れをおおむね適切に区別する。システム横断の知能という発表は、既存アプリケーションのロジックと意思決定をどう整合させるか示す前に、想定する境界を大きく広げている。(1, 10)
セキュリティへの真剣さ — 3/10。 セキュリティと技術資料は、制御と検証責任を特定する。しかし、エージェント権限、拡張の封じ込め、侵害後の復旧は十分に検査できない。購入者は公開構成から、侵害されたツールや入力の潜在的被害を導けない。(11, 15)
ソフトウェアの簡素さと所有費用 — 4/10。 複数世代のアプリケーション、統合層、顧客拡張を維持する必要がある。Lynxは実在する費用源を狙うが、現在の根拠は、計画モデル改善の全ライフサイクルの負担低下を立証しない。(9, 13, 14)
プログラムによる運用・エージェント支援運用との適合性 — 6/10。 基盤サービスとエージェントツールはプログラム的アクセスを与える。持続的な生産性は、人手の確認負担を再現せずに、エージェントが実行可能な判断ロジックの検査、テスト、改善を支援できるかに、なお依存する。(11, 19)
技術的透明性
| 評価基準 | 評点 |
|---|---|
| 公開技術文書 | 6/10 |
| ベンダーを介さずに検査できること | 5/10 |
| 移植性とロックインの可視性 | 4/10 |
| 導入手法の透明性 | 6/10 |
| 技術的主張を裏づける根拠の密度 | 5/10 |
平均：5.2/10。
公開技術文書 — 6/10。 過去の製品文書は多くの計算と業務境界を説明する。現在の公開資料は、計画エンジンの定式化、不確実性モデル、再現可能な性能より、アプリケーションの対象範囲やAIワークフローに詳しい。(2, 3, 7)
ベンダーを介さずに検査できること — 5/10。 外部の者でも計画動作の相当部分を再構成し、進行中の技術領域を特定できる。決定的な数値目標と実行時保護は、独立した検査ではなく、依然ベンダーの説明を要する。(4, 11, 15)
移植性とロックインの可視性 — 4/10。 統合サービスはアプリケーションのデータを公開するが、移行には顧客固有の規則や依存関係の保存も必要だ。Lynx自身の提案が、既存環境にいかに多くの業務上の意味が埋め込まれ得るかを示す。(19, 23)
導入手法の透明性 — 6/10。 顧客事例と公開クラウド条件は、段階導入、参加、保守責任を特定する。特定顧客の経済モデルに必要な反復労力は、詳細な対象範囲の確定前には見積もりにくい。(14, 20)
技術的主張を裏づける根拠の密度 — 5/10。 従来の計画文書と業務事例には実質がある。広範なエージェント知能の主張は検証が薄く、最も野心的なシステム横断提案は今後の提供予定に留まる。(10, 21, 22)
ベンダーの真剣さ
| 評価基準 | 評点 |
|---|---|
| 公開発信の技術的真剣さ | 5/10 |
| 技術ロードマップの一貫性 | 6/10 |
| 概念的明晰さ | 5/10 |
| 経済的責任 | 3/10 |
| エージェント型ソフトウェア時代の競争優位の持続性 | 6/10 |
平均：5.0/10。
公開発信の技術的真剣さ — 5/10。 具体的な技術・業務説明と、広範な行動システムの主張が併存する。宣伝はしばしば、中間の意思決定機構を示さず、作業自動化から製造知能へ飛躍する。(7, 10, 11)
技術ロードマップの一貫性 — 6/10。 歴史には、提供済みの基盤、特定可能なML課題、ブロックチェーンへの熱意の明示的再考が含まれる。現在のNVIDIAに支えられた構想は未実現の将来の約束であり、貢献は提供後に測る必要がある。(16, 18, 19, 10)
概念的明晰さ — 5/10。 QADは製造と旧来のロジックに伴う実務負担を理解している。一方、正確な記録、効率的な流れ、経済的に健全な判断の区別は弱い。それぞれ異なる成功基準が必要だ。(6, 9)
経済的責任 — 3/10。 公開成果は、全導入・保守費用を差し引いた収益を示すことが少ない。AI確認義務と別途の変更サービスにより、顧客は判断品質について大きな責任を負うが、同様に明確な経済的是正の約束は公開されていない。(14, 21)
エージェント型ソフトウェア時代の競争優位の持続性 — 6/10。 製造の意味体系、既存アプリケーション、蓄積した統合は価値ある資産だ。Lynxは改善作業の生産性を扱うが、MCP制御と会話アクセスの優位性は、それらが根本の意思決定ロジックを持続的に改善しない限り弱い。(11, 23)
出典
サプライチェーン計画。日付なし。2026年11月4日閲覧。現在の計画範囲と製品機能。
生産計画。2019年。2026年11月4日閲覧。過去の製造制約、費用ベースの手法、ヒューリスティクス。
需要計画。2019年。2026年11月4日閲覧。予測、分散入力、時点をずらした検証、精度の主張。
調達計画。2019年。2026年11月4日閲覧。購買方針、注文制約、輸送の先読み。
需要・サプライチェーン計画。2019年。2026年11月4日閲覧。スイートモデル、財務の視点、技術構成。
[6] QAD — Procurement Champion
Procurement Champion。日付なし。2026年11月4日閲覧。現在のサプライヤーフォローと例外の流れ。
[7] QAD — Champion AssistとAccounts Payable Champion
Champion AssistとAccounts Payable Champion。2026-09-22。2026年11月4日閲覧。9月のリリース、請求書自動化、独立したChampion基盤。
ChampionAIキャンペーン。日付なし。2026年11月4日閲覧。キャンペーンの主張と行動確認に関する表現。
Lynx Champion発表。2026-09-22。2026年11月4日閲覧。近代化の仕組みと顧客の予想節約額。
[10] QAD — Manufacturing Intelligence発表
Manufacturing Intelligence発表。2026-09-22。2026年11月4日閲覧。システム横断の構想と2027年春の提供予定。
[11] QAD — Software Engineer, AI Agent Platform
Software Engineer, AI Agent Platform。日付なし。2026年11月4日閲覧。雇用主が記した基盤業務と必要な技術技能。
[12] QAD — Progress Developer II
Progress Developer II。日付なし。2026年11月4日閲覧。雇用主が記したERP開発業務。
採用ページの技術概要。日付なし。2026年11月4日閲覧。全社の技術系列。製品への割り当ては示されない。
クラウドプログラム文書。2026-01-13。2026年11月4日閲覧。2026年1月13日版。クラウド対象範囲、保守、AI責任。
セキュリティ概要。日付なし。2026年11月4日閲覧。責任分担と公開セキュリティ説明。
DSCP 2019リリース発表。2019-12-02。2026年11月4日閲覧。Business Wireが配信しNasdaqが転載した当時のQAD発表。
[17] QAD — QADがStratus Awardを受賞
QADがStratus Awardを受賞。2016-07-21。2026年11月4日閲覧。過去の構成選択と更新管理についての立場。
ブロックチェーンは禁句か。2020-07-07。2026年11月4日閲覧。幹部によるブロックチェーン導入障壁の再評価。
Channel Islands構想。2018-10-18。2026年11月4日閲覧。提供済みの基盤、インターフェース、統合作業。
Mayoly Spindler事例。2019-08。2026年11月4日閲覧。2019年8月更新の事例。実名顧客の経緯と業務プロセス。
冷凍食品メーカー事例。日付なし。2026年11月4日閲覧。匿名の計画導入と報告された業務成果。
[22] QAD — 2025年Redzone生産性ベンチマーク
2025年Redzone生産性ベンチマーク。2025-07-30。2026年11月4日閲覧。ベンダー調査の方法と測定された工場プログラムの成果。
Lynx Champion。日付なし。2026年11月4日閲覧。現在のカスタマイズ分析・変換の提案。