食品小売向け在庫・補充ソフトウェアベンダーAfreshの評価

著者：Léon Levinas-Ménard

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

Afreshは、店舗補充、在庫カウント、調理済み食品の生産、レシピ管理、配送センターの仕入れを支援する食品小売向けソフトウェアを提供しています。店舗従業員はアプリケーションで在庫を確認し、推奨された発注や生産作業を実行します。配送センターのバイヤーは倉庫への補充と仕入れの例外処理に利用します。当初は生鮮部門向けに開発されましたが、2026年3月には、包装食品、冷凍食品、一般商品、健康・美容商品へと対応範囲を広げたと発表しました。 1 2 3 4

総合評価：6.0/10。

評価軸	点数
サプライチェーンに関する深さ	6.4/10
意思決定と最適化の実質	6.8/10
製品とアーキテクチャの一貫性	5.0/10
技術的透明性	5.6/10
ベンダーの真摯さ	6.0/10

Afreshは、公開された発注の目的関数、需要と在庫の確率モデル、保存可能期間が意思決定をどう変えるかという説明を備え、傷みやすい商品の在庫に対して実質的な技術基盤を持っています。最も強い裏付けは、店舗の生鮮部門の運営に関するものです。食品小売全体の採算を最適化するという、より広い主張の裏付けは十分ではありません。特に、売場の陳列ルール、倉庫の仕入れ、店舗作業が相互に作用する領域が問題になります。ソフトウェアは発注を改善しても、その発注を不採算にするルール自体は放置することがあり得ます。 5 6 10

Afreshは複数の仕組みを評価できるだけの技術的詳細を公開しており、顧客事例には継続的な利用と業務改善が含まれています。一方、総保有コスト、セキュリティ侵害の封じ込め、最新の配送センター向け機能や店舗全体を対象とする機能の採算については、公開された裏付けが薄くなっています。

AfreshとLokadの比較

Afreshは、食品小売の意思決定を店舗チームやバイヤー向けのアプリケーションに組み込んでいます。Lokadは、継続的に保守する意思決定システムを中心に据えています。このシステムは、不確実性の下で実行可能な行動を経済的に評価し、選んだ行動を業務システムに送ります。その広い設計思想は『サプライチェーン入門』で展開されています。違いは、どちらが確率予測を使うかではなく、意思決定ロジックの責任と対象範囲にあります。

Afreshが公開したShrinkAware方策は、商品の劣化、販売機会損失、在庫保有にコストを割り当てます。在庫モデルも、在庫量を不確実なものとして扱います。これらは、Supply Chain Scientistsが顧客の数値的な意思決定ロジックを構築・保守する、Lokadの在庫最適化サービスと重なる部分です。 5 6

より難しい違いは、商業上の前提が誤っているときに現れます。陳列の最低数量が、期限内に売れる量を超える在庫を要求することがあります。倉庫は古くなった商品を店舗へ送ることで、自らの在庫消化指標を改善できるかもしれません。意思決定システムは、そうしたインセンティブに従う発注を計算するだけでなく、それを明らかにして修正しなければなりません。Afresh自身による問題の説明は、その最適化がどこまで及ぶかを具体的に検証する材料になります。 10

食品小売業者にとって、Afreshは売場のカウンター、レシピ、歩留まり、在庫カウント、日中の調理に関する豊富な知識を、すぐ使える形で提供します。Lokadは、相互に作用する意思決定全体にわたって、経済モデルを適応させ保守することにより重点を置いています。実務上の比較では、従業員、バイヤー、売場担当者、エンジニア、管理者が継続して行う作業まで数えたうえで、どちらの仕組みがより良い実行可能な意思決定を生むかが問われます。

歴史：技術的な継続性から、より広いAIの約束へ

Afreshは2017年に創業しました。2020年7月の資金調達発表では、すでにAIを活用した生鮮食品プラットフォームと説明し、売上、廃棄、利益率の改善を訴えていました。当時の主張は、対象を限定した食品小売アプリケーションに関するものでした。その後の技術的な発信は、単に後から用語を変えるよりも、その主張に実質を与えています。 12

2021年の技術記事は、傷みやすい商品を発注する際、正確な点予測だけでは不十分な理由を説明しました。動的計画法による小さな例を示した後、商品の経過日数を追跡すると状態空間が爆発的に増えることを示しています。記事は、この教材と本番環境の手法を明確に区別しました。シミュレーションによるコストや廃棄の改善は説明用の結果であり、顧客の成果ではありませんでした。 7

その後、2022年の確率的な食材発注、2023年のShrinkAware方策、2024年の在庫推定と販促予測へと続きました。いずれも食品小売の具体的な問題を扱い、仕組みの一部を開示しています。この流れは、一貫した技術ロードマップを裏付けます。不確実性、傷みやすさ、不完全な観測が、各記事を通じて中心にあります。 8 5 6 9

顧客側の報告も継続利用を裏付けています。Albertsonsの2025年サステナビリティ報告書は、2024年に青果、精肉、水産部門でAfreshを利用したと記載しています。これはAfreshの営業資料とは独立して実務利用を確認するものですが、その記述だけではソフトウェアに帰属する経済的リターンを切り分けられません。 13

2025年11月のFresh Buyingの発表から、裏付けの性質が変わります。発表では、AIエージェントが予測、仕入先の選定、トラック積載の構成、問題解決を連携させると説明され、Wakefernが導入予定の初期顧客として挙げられました。2026年3月の拡張では、提案範囲が店舗全体に広がりました。6月のGrocery Outletの発表は、店舗全体の発注に向けて製品を選定したという内容です。これらは製品の方向性と商業上のコミットメントを示しますが、公開済みの技術記事が主に説明しているのは、それ以前の生鮮売場向けコンポーネントです。 14 4 20

したがって、歴史から見える懸念は、実証された仕組みと宣伝される対象範囲の間に広がる距離です。Afreshの数年にわたる具体的な技術開発は評価に値します。最近のエージェントや全社規模の主張には、実際に稼働する意思決定の範囲、失敗、費用を差し引いた業務成果について、同程度の開示が必要です。

意思決定の仕組み：意味のある確率と、不完全な経済的範囲

傷みやすい商品に対する実際のコスト目的関数

ShrinkAwareは、劣化、販売機会損失、在庫保有のコストを組み合わせます。売場在庫とバックヤード在庫を区別し、棚が完全に空になる前から不足ペナルティを発生させます。著者らはまた、推定にかける労力は意思決定の感度に応じるべきだと説明しています。保存可能期間の小さな誤差は、商品によって影響が大きく異なります。Afreshは、2023年の導入後、従来の方策に対して商品ロスがさらに5–10%減少したと報告しています。記事は、対象となった導入先の標本や再現可能な評価を公開していません。 5

これは、予測精度を最適化し、結果として生じる在庫が利益を生むことを期待するよりも、しっかりした出発点です。しかし、陳列量が少ないことにコストを付けても、その金額が適切だとは限りません。ペナルティは経済的に妥当な需要損失を表す場合もあれば、棚を恒常的に過剰補充させる売場側の好みを表す場合もあります。意思決定の質は、この違いをどう測定し、継続して管理するかに左右されます。

在庫の不確実性と、数えることの価値

Afreshの2024年のInvHMM記事は、真の在庫を隠れた状態、実地カウントをノイズを含む観測としてモデル化しています。粒子フィルタは、販売、入荷、商品ロス、期限切れを通じて複数の在庫推移を維持し、カウント結果が届くと相対的な妥当性を更新します。Afreshは、信頼できる測定値の一部を対象に、継続記録方式の在庫管理より平均二乗誤差が10–40%低かったと報告しています。 6

有用な貢献は、行動との結び付きです。カウントによって次の発注が大きく変わる可能性があれば、数える価値があります。どの在庫量が妥当であっても発注しないのであれば、数え直すことの即時的な利益は小さくなります。サンプリング自体は基本的な数値手法です。どの不確実性を解消する価値があるかを選ぶことは、実際の店舗作業を減らせます。公開された説明はその選択の仕組みを示していますが、複数商品と供給事象の同時較正は、ほとんど検討されていません。 6

業務上の期間に合わせた予測検証

Afreshの販促予測記事は、販売、価格、店舗・商品ID、陳列規模、販促の種類を使うエンコーダー・デコーダーネットワークを説明しています。発注間隔と配送の遅れに対応させて、三日間の需要を評価します。アブレーション実験では販促情報を除き、生じる悪化を分位点損失と較正で比較しています。販促開始に近いある時点で、80パーセンタイルの予測に対して報告された77.5%のカバー率は、較正の結果です。予測精度が77.5%だという主張ではありません。 9

これは、ほぼ完璧な精度をうたう見出しよりはるかに情報量があります。選んだ集約は明示された補充期間に対応し、不確実性も見えるままです。次の経済的な問いは、改善した予測がまだ間に合う発注を変えるか、そして変更された発注がどれだけ利益を守るかです。販促初日の後に予測が改善すれば、その後の補充には役立っても、開始時の配分には遅すぎることがあります。

レシピは商品を結び付けるが、依存関係は依然として重要

2022年のレシピ教材は、調理済み商品の需要を、共通食材の需要に変換します。レシピ商品の分布からサンプリングし、換算係数を適用して、食材発注の分位点を導きます。例では、需要が互いに独立し、開店前に入荷と調理を即座に行えると明示的に仮定しています。代替、歩留まりの変動、食材不足は拡張課題として残しています。 8

共通の販促は複数のレシピの需要を同時に増やし、競合する料理は需要を奪うかもしれません。これらの関係が重要な場合、独立した抽出では、合算した食材所要量の分布の裾を誤って表現します。サンプル数を増やしても、欠けた依存関係は修復できません。教材はこの限界を明示しています。

Afreshの2026年10月のレシピ資料は、部門をまたぐ食材の紐付けと、店舗固有の食材識別や歩留まりを説明するようになりました。また、手動修正がモデルに欠けた文脈を示すことも認めています。これは、事業の表現を保守するうえで実務的な前進です。ただし、現在の本番システムが需要、歩留まり、供給の不確実性をどう同時にモデル化するかは示していません。 11

配送センターの仕入れは意思決定範囲を広げる

2026年10月の配送センター向け資料は、確率的な需要、在庫バッファに反映する仕入先の信頼性、輸送費と商品劣化のトレードオフ、先行仕入れの資金上限、代替品へ移る需要を挙げています。通常の発注は自動送信できますが、先行仕入れにはバイヤーの承認が必要です。 3

未解決なのは、これらの要素をどう統合するかです。信頼性の統計と設定可能なリードタイムは、将来の納品日や納品量の分布を表現しなくても、バッファを改善できます。局所的には利益の出る先行仕入れが、別の用途の方が有益な能力や資金を消費することもあります。公開された説明は、同時確率モデルも、連動する行動の選定方法も明かしていません。そのモデルはさらに、仕入先の慣行、取引条件、店舗の行動が変わっても正しく機能し続ける必要があります。この保守負担はホリミゼーションの中核であり、ソルバーが答えを返せば消える実装上の細部ではありません。

設定の保守、生産性、責任

経済的リターンを壊す前提に、誰が責任を持つのか

2026年10月、Afreshのアカウントマネジメント担当副社長の記事は、店舗発注の指標が一見良好でも、商品ロスの結果が期待外れになる状況を説明しました。ある例では、配送センターの過剰仕入れと、残存期限の短い商品を下流へ送る行動を損失の原因としています。別の例では、週販が一箱の十分の一なのに、ブラッドオレンジを二箱必要とする陳列を挙げています。記事は、その陳列を満たす発注システムは、要求された通りに動いていると主張します。 10

この最後の主張は、経済的責任の境界の弱さを示します。その陳列は、鮮度を考える前でも約二十週間分の需要に相当します。廃棄削減を売りにするシステムなら、この矛盾を具体的な対応につなげ、陳列変更の責任を割り当てるべきです。赤字を生む指示に忠実に従うことは、最適化の成功ではありません。

著者は、コンサルティングの経験上、報告されたシステムの失敗はほぼ常に、人とプロセスの不整合に由来したと述べています。陳列の例は、その区別の限界を示します。ソフトウェアは、予測可能な廃棄を生む売場の入力を受け入れているのです。経済的責任は、こうした入力を検出し修正することまで含める必要があります。アプリケーション自身が変更できない場合に、誰が動くべきかも含まれます。 10

Afreshのレシピ紐付けの記事は、より良い姿勢を示しています。繰り返される手動修正は、モデルに文脈が欠けている徴候かもしれない、というものです。現在の顧客密着型エンジニアの求人も、顧客の真の問題を見つけ、解決策を構築し、削減時間や廃棄量などの成果を測る責任をエンジニアに割り当てています。これらはモデルの保守に向けた建設的な取り組みです。ただし、求人は業務の進め方を記述したものであり、契約上のリスク分担や監査済みのプロジェクト収益を示す証拠ではありません。 11 19

減る仕事と、残る仕事

Afreshの店舗発注ページは、発注作業が40–50%速くなると宣伝し、ガイド付きのカウントと発注確認を説明しています。既存の小売業者の画面に向けて、バックエンドAPI経由で推奨を提供することも可能です。重要な生産性向上は、計算が減り、観測対象をより適切に絞れることです。店舗の基本的な業務には、依然として従業員の判断と現物確認が含まれます。 1

Production Planningは食材と完成品を結び付け、日中の調理を計画します。従業員は生産前に推定在庫を確認します。設定された最低数量は拘束力を持ち、製品は実行状況、手動修正、指示の遵守を記録します。 2 必要な物理作業と、避けられる計画作業を区別することが重要です。果物を切るには労働が必要ですが、モデルが計算できる数量を繰り返し修正する作業は、継続的なソフトウェアコストです。

Fresh Thymeの事例は、70店舗の企業で紙ベースの生産計画を置き換えたと説明しています。指示の遵守率が約40%から90%へ上がり、ロティサリーチキンの売上が前年比70%増、デリの売上が8.8%増になったと報告しています。また、本社が得た可視性を店舗指導に活用する様子も述べています。これらの数字は業務の変化を示しますが、純粋な経済効果を算出するために必要な追加労働、廃棄、利益率、導入費用は示していません。 15

Heinen’sは、より限定された別の例を提供します。期末に価格ベースで行っていたカウントを、商品単位のスキャンへ置き換えました。CFOは、現在のカウント所要時間が四時間だと述べていますが、公開資料には以前の処理時間の数値がありません。商品識別の改善は具体的ですが、この説明から労働削減率を計算することはできません。 16

これらの改善は、レシピや歩留まりの保守、陳列最低量の見直し、データ連携の修正、例外の調査、カウント、遵守状況の監督という、継続的な作業全体に照らして評価すべきです。速い店舗画面には価値があります。持続的な生産性の優位には、店舗や購買担当ごとの意思決定作業の総量が減り、同じだけの作業が中央サポートチームに移らないことが必要です。

ソフトウェア構成要素とセキュリティ

現在の求人と提携情報からは、比較的一貫したプラットフォームの方向性が読み取れます。Orderingのバックエンド求人は、Afreshの技術スタックとしてPython、JavaScript、TypeScript、React Native、Databricks、GraphQLを明記し、Azureを必要経験に挙げています。顧客密着型エンジニアの求人は、そのチームがDatabricksとAzureをPySparkおよびdbtとともに運用すると記載しています。いずれも、この評価のために取得した、日付のない現行求人です。 18 19

構成要素または境界	裏付け	影響
発注アプリケーションとサービス	Ordering求人に記載された言語、React Native、GraphQL	業務手順が変われば、モバイルとサービスのコードを連動して進化させる必要がある。
データエンジニアリング	顧客密着型開発でのDatabricks、Azure、PySpark、dbt	処理、オーケストレーション、データ変換とその運用コストは、引き続きサービス提供の一部となる。
顧客データ交換	Databricks Open Sharing、旧称Delta Sharing	既に同プラットフォームを使う小売業者では、重複する連携作業を減らせる可能性がある。
業務システム連携	推奨APIと購買システムへの接続	実行は引き続き、保守された対応付けと小売業者のシステムに依存する。

2026年10月のDatabricksの発表は、既存の管理された環境にある顧客データへアクセスし、標準化したデータを返す仕組みを説明しています。これは有用な連携方式です。しかし、提携名自体は、発注モデルが優れること、運用が安いこと、保守が容易なことを独立して裏付けません。そうした成果を確認するには、重複ストレージ、処理、連携作業、継続的な開発時間の測定が必要です。 17

Afreshの配送センター資料は、SSO、SCIM、アクセス制御、暗号化、契約終了時のデータ破棄を挙げています。一方、テナント分離、サービス認証情報が侵害された際の影響範囲、サポートアクセスの制限、破壊的変更後の復旧は説明していません。 3 これらは、設計によるセキュリティを評価するために必要な仕組みです。コンプライアンスの状況は、こうした設計上の問いへの答えにはなりません。

エンジニア職の説明も、本番コードと特権操作の権限を明らかにしていません。Afreshがホストする環境や顧客に接続された環境へのアクセスには、強制可能な境界が必要です。認証情報、依存関係、ネットワークアクセスへの制限も含まれます。

サプライチェーン評価

総合点は、以下の25項目を同じ重みで平均したものです。2026年11月4日時点で公開されていた裏付けを評価しています。

サプライチェーンに関する深さ

項目	点数
経済的な枠組み	7/10
意思決定の実行への到達	8/10
サプライチェーンに関する概念的明確さ	8/10
陳腐化した定石からの自立	5/10
見せかけのKPIへの耐性	4/10

平均：6.4/10。

経済的な枠組み — 7/10。 公開された生鮮品の発注目的関数は、数量とコストを結び付けています。弱点は、商業上の都合で課された設定がその経済性を上回る影響を持っても、意思決定システムが修正しないことです。 5 10

意思決定の実行への到達 — 8/10。 店舗発注、調理数量、仕入れ発注は具体的な出力です。購買システムとの連携により、配送センター向け製品には、助言やレポートを超えて実行に至る経路があります。 1 2 3

サプライチェーンに関する概念的明確さ — 8/10。 Afreshは、傷みやすさ、不完全にしか分からない在庫、食材の変換、良い予測と良い発注の違いを説明しています。これらの仕組みは、物理的な事業を有用な細かさで捉えています。 6 7 11

陳腐化した定石からの自立 — 5/10。 確率分布は固定的な計画バッファを改善しますが、サービスへの選好や陳列最低量は依然として結果を左右します。そうした設定の経済的妥当性を、方針の保守作業にいつまでも委ねることはできません。 2 5

見せかけのKPIへの耐性 — 4/10。 技術記事は較正、誤差、意思決定コストを区別しています。一方、営業用の事例は売上と遵守率を強調し、経済的リターンの全体計算を公開しません。そのため、良好な中間指標が収益性の代わりになり得ます。 9 15

意思決定と最適化の実質

項目	点数
確率モデリングの深さ	7/10
最適化・機械学習の独自の実質	7/10
現実の制約への対応	8/10
意思決定の自動化と労働生産性	6/10
実際の業務複雑性への対応力	6/10

平均：6.8/10。

確率モデリングの深さ — 7/10。 需要分布と不確実な在庫推定について、仕組みと検証が開示されています。配送、歩留まり、代替、共有資源利用の同時不確実性については、裏付けが十分ではありません。 6 8 9

最適化・機械学習の独自の実質 — 7/10。 ShrinkAwareと在庫モデルは、汎用的な補充方式の具体的な欠点に対処します。その貢献は、サンプリングやニューラルネットワークの新しさではなく、問題の定式化と業務での使い方にあります。 5 6

現実の制約への対応 — 8/10。 レシピの紐付け、鮮度、調理工程、購買上の制約は明示的に扱われています。残る問題は業務知識の不足ではなく、ネットワーク全体における制約の相互作用です。 2 3 11

意思決定の自動化と労働生産性 — 6/10。 数量の推奨と通常仕入れの自動化は作業を減らします。一方、ガイド付きの店舗確認、例外処理、遵守の監督にはなお相当の作業があり、顧客事例も継続作業の全体を測定していません。 1 3 15

実際の業務複雑性への対応力 — 6/10。 Afreshは、繰り返す手動修正をレシピ文脈の欠落に結び付け、食材の対応付けや歩留まりの修正を説明しています。顧客密着型エンジニアは、業務上の問題を試験導入や再利用できるプラットフォーム変更へ転換します。これらは意思決定モデルを見直す具体的な経路です。ただし、過去データでの再実行、経済的な受入試験、変更の管理されたリリースは、十分に文書化されていません。 (11, 19)

製品とアーキテクチャの一貫性

項目	点数
アーキテクチャの整合性	6/10
システム境界の明確さ	6/10
セキュリティへの真摯さ	3/10
ソフトウェアの簡素さと保有コスト	4/10
プログラムおよびエージェントによる運用への適合性	6/10

平均：5.0/10。

アーキテクチャの整合性 — 6/10。 発注と生産は食材と予測の情報を共有し、開示された技術スタックにはプラットフォームとしての方向性があります。ただし、最新の仕入れ機能やエージェント機能が、そのアーキテクチャをどう共有するかは公開資料から十分に見えません。 2 18 19

システム境界の明確さ — 6/10。 業務インターフェースと従業員の作業手順は理解できます。一方、設定済みルールに従った発注が予測可能な廃棄を生むとき、経済的責任は不明確になります。 1 3 10

セキュリティへの真摯さ — 3/10。 認証とアクセス制御の機能は列挙されています。しかし、封じ込め、特権アクセス、破壊的な障害からの復旧、連携先の侵害がもたらす影響については、同じ水準の説明がありません。 3

ソフトウェアの簡素さと保有コスト — 4/10。 データ基盤、アプリケーションサービス、顧客固有の開発は継続的な運用コストを生みます。ホスティングの消費量も、継続的な設定作業も定量化されていません。 17 18 19

プログラムおよびエージェントによる運用への適合性 — 6/10。 APIと発注の自動送信により、機械による実行が可能です。エージェントの提案が信頼できるのは、経済的前提の統制を維持しつつ意思決定作業をなくせる範囲に限られます。発表された範囲の広さは、公開された実装の詳細を超えています。 1 3 14

技術的透明性

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

平均：5.6/10。

公開技術文書 — 7/10。 技術記事は、企業向け計画ソフトウェアとしては珍しいほど詳しく、目的、前提、モデル、評価尺度を説明しています。新しい製品範囲に関する開示は、数学的な内容より機能説明に偏っています。 5 6 9 3

ベンダーの仲介なしでの検証可能性 — 6/10。 読者はデモを受けずに、意味のある仕組みや教材コードを調べられます。ただし、報告された本番環境での改善を再現したり、実際に稼働する意思決定ロジックの全体を確認したりすることはできません。 7 5

移行性とベンダー依存の可視性 — 4/10。 データ交換と推奨APIは画面への依存を減らします。しかし、小売業者が学習済みの挙動を出力し、方策の選択を再構成し、意思決定プロセスを作り直さずにモデルを置き換える方法は説明されていません。 1 17

導入手法の透明性 — 6/10。 製品文書と技術職の求人から、データ作業、導入、継続的な顧客対応が見えます。必要な作業の把握には役立ちますが、その費用が予測可能か、前提変更時に誰が負担するかは明らかになりません。 2 19

技術的主張を支える証拠の密度 — 5/10。 コンポーネント単位の評価と実名の導入事例は、生鮮部門に関する中心的な主張を支えています。より広い経済的成果と最新の拡張機能は、ベンダーの要約や製品発表への依存が強くなっています。 6 9 13 14

ベンダーの真摯さ

項目	点数
公開発信の技術的な真摯さ	6/10
技術ロードマップの一貫性	7/10
概念的明確さ	7/10
経済的責任	4/10
エージェント型ソフトウェア時代の競争力	6/10

平均：6.0/10。

公開発信の技術的な真摯さ — 6/10。 エンジニアは説明用モデルと本番運用を区別し、重要な限界を説明しています。一方、営業資料の広範なAIや利益率の主張は、精密さに欠けます。 7 8 12 14

技術ロードマップの一貫性 — 7/10。 日付のある一連の公開物は、同じ生鮮食品の問題への継続的な取り組みと、それに関連する製品拡張を示しています。最近のエージェント訴求により、新機能でも同等の継続性を示す必要性が高まっています。 5 6 7 14

概念的明確さ — 7/10。 Afreshは、在庫観測、保存可能期間、変換工程が意思決定問題の一部であると理解しています。ただし、陳列に起因する損失の扱いは説得力に欠けます。不経済な指示を、ソフトウェア責任の境界として受け入れているからです。 6 10 11

経済的責任 — 4/10。 顧客事例は利益の可能性を示し、顧客密着型開発は測定された成果を重視しています。それでも公開資料はプロジェクト全体の採算を示さず、不利な結果を周辺業務のせいにする余地を残しています。 10 15 19

エージェント型ソフトウェア時代の競争力 — 6/10。 画面が作りやすくなっても、傷みやすい商品の在庫に関する知識と、意思決定に役立つデータモデリングには価値が残り得ます。持続的な強みは、バイヤーに別の作業一覧を示すアシスタントではなく、信頼でき、保守された経済的意思決定でなければなりません。 6 11 14