市場調査に戻る
Vekiaは需要予測、在庫管理、補充を行うクラウドアプリケーションである。発注案を計算し、欠品リスクを特定し、物流の流れを監視するとともに、これらの機能を顧客の既存の取引処理システムに接続する。用途には小売の補充と保守部品の供給がある。(1, 7, 8)
サプライチェーン総合スコア：5.0/10。
| 評価分野 | スコア |
|---|---|
| サプライチェーンへの理解の深さ | 5.6/10 |
| 意思決定と最適化の実質 | 5.8/10 |
| 製品とアーキテクチャの一貫性 | 4.2/10 |
| 技術的透明性 | 5.0/10 |
| ベンダーの真剣さ | 4.4/10 |
Vekiaは具体的な発注判断を扱い、需要と納入時間の双方の不確実性を明示的に認識している。顧客事例では相当な自動化が報告されている。技術面で未解決なのは、商品や拠点をまたぐ経済計算にそれらの不確実性をどこまで取り込んでいるかである。公開研究に示される定式化には、あらゆるサプライチェーンとデータ量に対して最大限の最適化を行うという現在の約束より厳しい制約がある。(2, 8, 5)
事業継続性も差し迫った懸念である。2026年9月28日、リール・メトロポール商事裁判所はVekiaの保護計画を終了し、裁判所の監督下での再建手続きであるredressement judiciaireを開始した。観察期間は2027年3月28日までとなっている。補充判断を継続的に計算するサービスでは、ホスティング、サポート、モデル保守の継続性を数値性能と併せて購入判断に含める必要がある。(20)
VekiaとLokadの比較
両社とも、反復的な補充計算をソフトウェアで代替することを目指している。Vekiaは予測、在庫設定、優先順位付き提案、確認画面を備えたパッケージアプリケーションを提供する。Engineも、既存ERPに予測と発注自動化を追加する製品として位置づけられている。(1, 17)
Lokadの在庫最適化は、顧客の意思決定を表す数値モデルを継続的に保守することを中心に据える。需要と供給の不確実性、経済的な結果、業務上の制約をモデルに取り込み、サプライチェーンサイエンティストが計算を開発・保守する。出力として意図するのは、経済性に基づいて順位づけした行動の集合であり、人の労力は意思決定プロセスの改善に集中させる。この広い設計思想はIntroduction to Supply Chainで展開されている。
実務上の違いは、推奨が誤っていたときに何が起こるかにある。パッケージシステムでは、手動修正、しきい値の変更、供給業者設定の変更を促すことがある。継続的に保守される意思決定モデルでは、失敗を計算の改訂につなげ、その影響を業務全体で再検証すべきである。Vekiaは設定機能と説明機能を公開しているが、この第二の改善サイクルに関する公開情報は少ない。その価値は、継続的な修正作業が顧客チームにどれだけ残るかにも左右される。(3, 15)
技術の歴史と実現状況
Vekiaには、予測と補充に取り組んできた十年以上の実績がある。同社の沿革では、創業を2008年、コンサルティングからソフトウェアへの移行を2010年、SaaSへの移行を2018年としている。初期のAIという位置づけは、現在の言語モデルエージェントよりはるか前の、数値予測と発注を指していた。(11)
| 時期 | 公開されている根拠 | 意味 |
|---|---|---|
| 2014年 | リール大学でのManuel Davyの発表は、日々の在庫判断、疎な商品・店舗別売上、物流能力、数時間の計算枠を説明する。 | 当初の課題は業務に即して具体的だった。(12) |
| 2016年 | AsysがVekiaPlanとその人員計画チームを買収する。 | 対象は人員計画製品であり、Vekiaの補充事業の買収ではなかった。(13) |
| 2019–2021年 | OkaidiとEngieの公開事例が補充の処理量と結果を説明する。 | 機械学習の説明の背後に実運用が存在したことを示す。(9, 8) |
| 2021年 | Engineが確率的予測とERP連携を掲げ、前世代より25%改善したとして登場する。 | 改善の指標も試験手順も公開されていない。(11) |
| 2024年 | Vekiaが支援した博士論文が多階層補充を研究する。 | アルゴリズム、制限的な仮定、未解決の実用化作業が明らかになる。(5) |
| 2025–2026年 | 現在のページは確率的AIと拡張性のあるAPSを強調し、アプリケーション開発者の求人は三つのデータベース基盤を挙げる。 | 約束の範囲の広さに見合う、数値計算の対象範囲と基盤コストの説明が必要である。(2, 6) |
2021年の機械学習記事は、有用な発想とそれを広げすぎた説明の隔たりを示す。確実な未来を一つ予測する考え方から離れる点は妥当だが、その後で最も確からしいシナリオと事業目標に適したシナリオを選ぶと説明している。肝心の問いは残る。低確率でも損失の大きい失敗を含む複数の結果にわたって行動を評価するのか、それとも好ましい未来を一つ選んで判断するのか。同じ記事は、匿名の販促実験で売上が26%増え、残存在庫が42%減ったと報告するが、比較手順を示していない。(10)
Vekiaの過去のエンジニアリングには、直接評価できるだけの実質がある。弱点は、特定できる数値手法と包括的な製品保証との距離、および報告された便益を支える労働と費用の把握の乏しさにある。
数値的な意思決定とモデルの限界
現在の発注アプリケーションは、保管費、輸送費、発注費を考慮し、最小数量、在庫しきい値、補充遅延、発注頻度を設定できる。提案理由を示し、手動変更を認める。これらは実務上意味のある入力である。ただし、それらがあるだけで、需要と供給が不確実な状況で組み合わせた判断が利益を最大化するとはいえない。(3)
公開研究から分かること
2024年の論文は、需要サンプルと区分的凸費用を用いた単品・単一拠点の稼働中の最適化、および事前計算した発注を商品・期間間で組み合わせるMILPを説明する。拠点は分離されたままである。一方、提案された多階層モデルは平均需要と、供給量に制限がなく完全に信頼できる供給業者を仮定する。905品目の実務課題から抽出した試験では、40品目ずつの二つの部分集合がCPLEXの二時間制限に達した。著者は適応的局所探索を開発し、シミュレーションでは在庫と欠品のバランスを改善する一方、購入を含む総費用を増加させた。論文時点では、本番向けの実用化と需要・供給の確率的入力は今後の課題だった。(5, 20–22、27–30、40–41、96–98ページ)
これはソルバーの問題であると同時に、定式化の問題でもある。探索を高速化しても、入力から取り除かれた不確実性は戻らない。拠点を分離すると、個別に計算された推奨が後から共通在庫を奪い合うことにもなる。ソルバーの名称を新しくするだけでは、どちらの経済的欠陥も残る。
現在の確率的予測に関する主張
Vekiaは現在、需要、納入時間、在庫の確率的予測を明示的に宣伝している。供給業者の不確実性を認識する点には実質的な強みがある。ただし、公開資料には同時分布の較正結果、依存関係のモデル、それらの分布を競合する発注選択肢につなぐ計算例がまだない。(2)
依存関係は重要である。販促で需要が増えると同時に補充が混雑することもあれば、ある供給業者の遅延が多くの商品に同時に影響することもある。そのため、個々にはもっともらしい予測を集めても、複合的で高くつく欠品の確率を過小評価しうる。問うべきなのは、通常のサービス目標を追う費用が高すぎる場合も含め、これらの結果にわたって判断が経済的に妥当であり続けるかである。
需要のページは、継続的に調整される予測と安全在庫、および設定可能な商品・業務の条件を説明している。しかし、予測期間、失注の扱い、比較基準を示した、再現可能なSKU単位の予測評価は公開していない。確率的という用語は情報を与えるが、分布の品質と行動の価値は別々に実証すべき問いである。(4)
顧客成果と経済的説明責任
実名の二つの事例は、製品が使われる業務を具体的に示す。
| 顧客 | 公表された範囲と成果 | 未測定の項目 |
|---|---|---|
| Engie Home Services | 12週間先までの保守部品予測を使い、供給業者の制約、輸送費、部品価格を踏まえて補充する。Vekiaは在庫金額10%減、部品の供給可能性5%増、発注の95%自動化を報告する。 | 測定期間、利益への影響、導入費用、継続的な総労働量。(8) |
| Okaidi | 商品ライフサイクル、販促、天候、倉庫の状況、ユーザー設定を取り込み、毎晩1,500万–2,000万件の在庫ポジションを処理すると説明する。在庫2%減、売上2%増が報告されている。 | 計算時間、比較の設計、純利益、保守作業量。(9) |
Okaidiの処理量は、大規模処理の根拠になる。しかし、在庫ポジションの件数から判断間の結合の程度はほとんど分からない。独立した計算を数百万件行うことと、ネットワーク全体を協調させて一度に計算することでは、計算上の要求が大きく異なる。売上の改善を経済的リターンとみなすには、利益率と履行費用も必要である。
現在の機能ページは、対象集団、測定期間、費用の範囲を示さずに、発注の99%自動化と最大2%のEBIT上乗せを掲げる。自動化率は発注に関する数値であり、予測精度ではない。EBITの記述は、相対的な増加率なのか売上に対するパーセンテージポイントなのかも示していない。(15)
こうした欠落により、説明責任が非対称になる。ベンダーは魅力的な便益を公表する一方、顧客のパラメータ選択、データ、連携、業務遂行が性能を大きく左右する。純リターンの基準を定め、悪化の原因を割り当て、期待を下回ったときにVekiaが計算を改訂すると約束する公開の受け入れ方法はない。経済的説明責任には、導入完了という節目だけでなく、この継続的な義務が必要である。(7, 15)
業務生産性と設定の保守
Vekiaの自動化はレポート作成にとどまらない。発注案を再計算し、既存システムに渡すことで、反復的な事務作業を除去できる。Engieの事例では、中央チームが注文を受け付ける役割から、ソフトウェアの提案に基づいて判断する役割へ移ったとも説明される。これは有用な生産性の変化だが、提案の確認に残った労働量は測定していない。(8, 17)
プラットフォーム自体は、部分的な自動化とワンクリックでの承認・調整を説明する。したがって、分母にすべきなのは、通常の発注、例外、納入前倒し、データ修復、保守を含む業務全体の作業量である。自動生成される発注の比率が高くても、少数の例外に多大な費用がかかることはある。(1)
設定は別の作業負担を生む。欠品モジュールでは商品ごとのアラートしきい値を設定でき、コントロールタワーでは顧客チームが定めたイベントとしきい値を使う。供給業者、商品、経済条件が変わる際に備え、各設定には責任者、設定理由、廃止ルールが必要である。そうしなければ、見かけ上の自動化の内部に、隠れた手作業の計画システムが蓄積する。(15, 16)
有用な総費用計算には、サブスクリプション、連携、ホスティング関連料金に加え、設定の維持に継続して費やす時間を含めるべきである。誤った推奨を発見してから検証済みの修正を配備するまでの遅れも数える必要がある。Vekiaの公開情報は、この保守作業量を定量化せず、顧客の意思決定方針について、変更の版管理、過去データでの再実行、ロールバックも説明していない。(3, 7)
これはHolimizationで論じた、改善そのものの生産性の問題である。定式化の改善は、繰り返し行えるほど低コストでなければならない。担当者が発注を上書きすれば今日の取引は直る。その理由を取り込み検証すれば、後続の何千もの判断を改善できる。
ソフトウェアの構成要素とセキュリティ
Vekiaの2025年11月のフルスタック開発者求人は、アプリケーションの技術構成を明示している。それ以前のDevOps求人には、配備の仕組みが記載されている。(6, 14)
| 層 | 公表されている構成要素 | 根拠の日付 |
|---|---|---|
| ユーザーインターフェース | TypeScript、Angular | 2025年11月のアプリケーション開発者求人 |
| バックエンド | Java、Spring、Hibernate、Scala | 2025年11月のアプリケーション開発者求人 |
| データシステム | PostgreSQL、MongoDB、Snowflake | 2025年11月のアプリケーション開発者求人 |
| アプリケーションの配備 | マイクロサービス、Azure SaaS | 2025年11月のアプリケーション開発者求人 |
| 基盤とデリバリーのツール | Linux、Azure、Ansible、Bash、Terraform、Docker、Jenkins、Maven、Nexus、Kubernetes | 2021年2月のDevOps求人。それぞれが現在も使われているかは不明 |
三つの異なるデータ基盤は、スキーマ変更、IDとアクセスの管理、バックアップの挙動、同期、障害診断という実際の保守負担を課す。それぞれの役割は公開されていない。懸念はアーキテクチャの費用と調整負担にあり、とりわけ一つの発注計算がサービス間の整合した状態に依存する場合に重要となる。流行の基盤を並べても、その負担は解消しない。
連携ページはERP、倉庫、輸送、関連システムへの接続を説明し、設定期間は複雑さとシステム数によるとしている。Vekiaと顧客の技術チームが共同で連携を行う。重複防止、拒否された発注の突き合わせ、修正済み推奨をどのシステムが管理するかを説明する公開の取引契約仕様はない。接続障害時にも無人実行が信頼できるかどうかは、これらの詳細で決まる。(7)
セキュリティの開示は、欧州のAzureホスティング、暗号化、バックアップ、一般的なデータ保護の保証に限られる。テナント分離、コネクタ権限、本番変更の管理、試験済み復元手順は指定されていない。アカウントやソフトウェア依存関係が侵害された場合の被害を抑えるのは、こうした仕組みである。クラウド事業者の評判は、アプリケーション自身の設計の代わりにはならない。(2)
事業継続性
公式記録の経緯は明確である。2023年9月4日に保護手続きが始まり、2024年9月4日に八年間の保護計画が認可され、2026年9月28日の再建手続き開始に伴ってその計画が終了した。最新の公告は、支払停止日を2026年9月4日とする。これは再建手続きであり、清算の判決ではない。(18, 19, 20)
商取引上の帰結は、依存リスクの増大である。補充サービスには、画面への継続的なアクセス以上のものが必要となる。最新のデータ連携、運用サポート、保守されたアルゴリズム、復旧可能な顧客設定が要る。公開されている連携の約束だけでは、設定済みの意思決定プロセスを顧客がエクスポートし、独立して稼働できるとは分からない。したがって、ソフトウェアの技術的強みと、未解決の継続性リスクが併存している。(7, 20)
サプライチェーンスコア
サプライチェーンへの理解の深さ
| 評価基準 | スコア |
|---|---|
| 経済性に基づく問題設定 | 6/10 |
| 最終的な意思決定の具体性 | 7/10 |
| サプライチェーンに関する概念の明確さ | 6/10 |
| 時代遅れの中心的教義からの自由度 | 5/10 |
| KPIの見せかけに対する堅牢さ | 4/10 |
平均：5.6/10。
経済性に基づく問題設定 — 6/10。 発注費用と物流費用を直接扱っている。ただし、それらの費用をサービス目標や不確実な損失とどう整合させるかについて、公開説明は不十分である。(3)
最終的な意思決定の具体性 — 7/10。 出力は補充数量とERPにつながる業務フローに届く。弱点として残るのは、実行制御と財務的な受け入れ試験の公開仕様が乏しいことである。(3, 7)
サプライチェーンに関する概念の明確さ — 6/10。 不確実な未来を重視する姿勢は妥当である。発生しにくい結果が不釣り合いに大きな経済的影響を持つ場合、好ましいシナリオを選ぶ方式では、その利点の多くを失う。(10)
時代遅れの中心的教義からの自由度 — 5/10。 製品は確定的な予測を超えているが、設定可能な安全水準とアラートが依然として大きな位置を占める。それらの経済的根拠と継続的な保守は十分に示されていない。(4, 16)
KPIの見せかけに対する堅牢さ — 4/10。 実名事例は匿名の便益主張より評価しやすいが、現在のEBITの約束と大見出しの改善数値には、純リターンを計算するために必要な定義が欠けている。(8, 9, 15)
意思決定と最適化の実質
| 評価基準 | スコア |
|---|---|
| 確率的モデリングの深さ | 5/10 |
| 独自の最適化または機械学習の実質 | 7/10 |
| 現実の制約への対応 | 6/10 |
| 意思決定の自動化と労働生産性 | 6/10 |
| 実際の業務の複雑さに対する耐性 | 5/10 |
平均：5.8/10。
確率的モデリングの深さ — 5/10。 需要と納入の不確実性を明示的に認識している。同時分布、その較正、リスクを考慮した行動選択での利用については、説明が不十分である。(2, 4)
独自の最適化または機械学習の実質 — 7/10。 公開されたアルゴリズムは、実質的な開発と失敗した手法を示し、研究と実運用の隔たりを明らかにしている。(5)
現実の制約への対応 — 6/10。 実務的な発注制限と供給業者の条件を直接扱う。拠点間、競合する商品間、不確実な供給との相互作用については、より詳しい説明が必要である。(3, 8)
意思決定の自動化と労働生産性 — 6/10。 顧客事例は反復的な発注作業の除去を裏づける。例外と設定変更を含め、残る業務労働の総量は測定されていない。(8, 1)
実際の業務の複雑さに対する耐性 — 5/10。 論文は局所的発注の欠陥を特定し、より広い定式化を開発してシミュレーションで比較する。こうした修正を顧客業務へ配備し、回帰試験を維持する方法について、公開情報は乏しい。(5, 16)
製品とアーキテクチャの一貫性
| 評価基準 | スコア |
|---|---|
| アーキテクチャの整合性 | 5/10 |
| システム境界の明確さ | 6/10 |
| セキュリティへの真剣さ | 2/10 |
| ソフトウェアの簡素さと所有コスト | 3/10 |
| プログラムおよびエージェント支援による運用との適合性 | 5/10 |
平均：4.2/10。
アーキテクチャの整合性 — 5/10。 補充に集中したアプリケーションには、明確な機能的中核がある。公開されたデータ構成は、個別システムの責任や整合性の境界を説明しないまま、調整費用を持ち込んでいる。(1, 6)
システム境界の明確さ — 6/10。 Vekiaは顧客の取引処理ソフトウェアに併設する位置づけを取る。発注変更、再試行、失敗に関する権限の分担は、連携図ほど明確ではない。(7, 17)
セキュリティへの真剣さ — 2/10。 ホスティング、暗号化、バックアップの保証からは、アプリケーションの権限境界、テナント分離、侵害後に安全に復旧する能力はほとんど分からない。(2)
ソフトウェアの簡素さと所有コスト — 3/10。 開示されたアプリケーションと基盤には、相当な専門的保守が必要である。公開情報は、重複するデータ基盤が費用に見合う理由も、顧客の継続的な設定作業量も示していない。(6, 14, 16)
プログラムおよびエージェント支援による運用との適合性 — 5/10。 ERP連携と自動計算はプログラムによる運用を支える。顧客の意思決定方針を試験し、改訂し、安全に配備するための検査可能なインターフェースは乏しい。(7, 17)
技術的透明性
| 評価基準 | スコア |
|---|---|
| 公開技術資料 | 7/10 |
| ベンダーの仲介なしで検証できる範囲 | 5/10 |
| 移植性とロックインの可視性 | 3/10 |
| 導入方法の透明性 | 5/10 |
| 技術的主張を支える根拠の密度 | 5/10 |
平均：5.0/10。
公開技術資料 — 7/10。 論文により、過去の数値手法は例外的なほど検証しやすい。現在の製品資料ははるかに精度が低い。(5)
ベンダーの仲介なしで検証できる範囲 — 5/10。 公開機能とアプリケーション構成要素は、有意義な外部評価を可能にする。ただし、現在の意思決定計算の全工程を、それらの開示から再現することはできない。(3, 6)
移植性とロックインの可視性 — 3/10。 既存システムに接続することで置き換え作業は減るが、データをエクスポートしても、設定済みモデル、運用知識、実行プロセスは移転しない。それらの移植性は未指定である。(7)
導入方法の透明性 — 5/10。 連携の責任分担と業務設定は見える。データ検証、モデルの受け入れ、設定移行、継続的な改訂手順については、説明がはるかに少ない。(7, 16)
技術的主張を支える根拠の密度 — 5/10。 実名の導入事例は実際の運用状況を示す。報告成果には基準、費用、労働量の情報が十分に含まれず、ベンダーに帰属する経済価値を説得力をもって計算できない。(8, 9)
ベンダーの真剣さ
| 評価基準 | スコア |
|---|---|
| 公開説明の技術的な真剣さ | 4/10 |
| 技術ロードマップの一貫性 | 4/10 |
| 概念の明確さ | 6/10 |
| 経済的説明責任 | 3/10 |
| エージェント型ソフトウェアの世界における優位性の持続可能性 | 5/10 |
平均：4.4/10。
公開説明の技術的な真剣さ — 4/10。 具体的な確率的概念と、無制限の規模や最大限の最適化という主張が併存する。評価の定義が欠けているため、公開説明の説得力は弱まる。(2, 11)
技術ロードマップの一貫性 — 4/10。 長年の補充への集中と識別可能な製品世代は、目的の継続性を裏づける。現在の財務再建は、継続的な開発と保守に重大なリスクをもたらしている。(12, 11, 20)
概念の明確さ — 6/10。 製品は在庫の経済性と反復的な判断を直接扱う。起こりうる未来を、経済的に望ましい行動へ変換する仕組みの説明は不十分である。(10, 17)
経済的説明責任 — 3/10。 公表された便益には、純リターンの受け入れ基準も、意思決定プロセスの成果が低い場合の明確な是正義務も伴っていない。設定の継続的な責任があるため、この欠落の影響は大きい。(15, 16)
エージェント型ソフトウェアの世界における優位性の持続可能性 — 5/10。 補充の専門知識と自動化された本番処理には価値が残る。一方、失敗を診断し、意思決定プロセスを継続的に改善する労力を同程度に減らしたという実証はない。(9, 1)
出典
出典。日付なし、現行ページ。2026年11月4日閲覧。
出典。2025-03-14更新。2026年11月4日閲覧。
出典。日付なし、現行ページ。2026年11月4日閲覧。
出典。日付なし、現行ページ。2026年11月4日閲覧。
出典。2024-09-20。2026年11月4日閲覧。
[6] フルスタック開発者求人：本番アプリケーションの技術構成
出典。2025-11-21。2026年11月4日閲覧。
出典。日付なし、現行ページ。2026年11月4日閲覧。
出典。2020-03-28公開、2021-03-26更新。2026年11月4日閲覧。
出典。2019-01-15公開、2020-04-03更新。2026年11月4日閲覧。
出典。2021-05-05。2026年11月4日閲覧。
出典。2024-10-10更新。2026年11月4日閲覧。
[12] Manuel Davyの発表：未来のインターネット
出典。2014-07-03。2026年11月4日閲覧。
出典。2016-01-25。2026年11月4日閲覧。
出典。2021-02-08公開、2021-04-21更新。2026年11月4日閲覧。
出典。日付なし、現行ページ。2026年11月4日閲覧。
出典。日付なし、現行ページ。2026年11月4日閲覧。
出典。2021年当時のページ。2026年11月4日閲覧。
出典。2023-09-13。2026年11月4日閲覧。
出典。2024-09-13。2026年11月4日閲覧。
出典。2026-10-07。2026年11月4日閲覧。