最終更新：2026年11月4日
市場調査に戻る
StockIQは流通企業とメーカー向けのサプライチェーン計画ソフトウェアである。ERPにつなぎ、需要予測、在庫方針の設定、購買・移動注文の生成、製造補充計画、供給者監視、販売・在庫・業務計画を支援する。Edisonアシスタントは、アプリケーション内で自然言語の質問と操作を加える。(1, 8)
総合サプライチェーンスコア：5.8/10
| 評価軸 | スコア |
|---|---|
| サプライチェーンの深さ | 4.8/10 |
| 意思決定と最適化の実質 | 5.4/10 |
| 製品とアーキテクチャの一貫性 | 6.4/10 |
| 技術的透明性 | 6.8/10 |
| ベンダーの真剣さ | 5.6/10 |
StockIQの中心は従来型の在庫計画である。予測を選び、在庫の保護水準を計算し、補充方針を適用し、供給者や輸送の制約に合わせて注文を調整する。マニュアルはこれらを検査できるだけの詳細を公開する。同時に経済的な限界も示す。目標在庫日数や割り当てられたサービスレベルを満たしても、購買が希少な現金、能力、在庫を最適に使うことは立証されない。(2, 4, 6, 22)
製品には相当の運用上の実質がある。予定された注文は個別承認なしでERPへ送れ、実名顧客は発注作業の大幅な削減を報告する。ただし公開手法は、需要と供給の不確実性の較正された同時モデルや、判断を横断する共通の経済目標を立証しない。Edisonは人の確認を維持しながら新しい画面を加える。従来の自動化を上回る労働面での効果は未測定である。(5, 7, 8, 11)
StockIQとLokadの比較
StockIQは設定可能な計画アプリケーション、導入支援、継続サポートを販売する。計画担当者が方針を選び、出力を決める仮定を維持する。Lokadの運用支援付き在庫最適化サービスは、サプライチェーンサイエンティストに、データ解釈、経済目標、本番ロジックを含む数値的な意思決定プロセスの開発と保守を任せる。違いは単に誰が画面を供給するかではなく、誰が判断を設計し、ソフトウェアが何を最適化するかである。(10, 22, 23)
StockIQの発注手法はこの違いを具体化する。商品間で在庫日数を揃えれば補充を同期できるが、一日分の在庫の経済価値は、高利益の交換部品、代替しやすい付属品、陳腐化に近づく季節商品で異なる。Lokadの在庫最適化手法は、不確実性の下で期待される経済的影響によって実行可能な行動を順位付けする。比較の焦点は、判断プロセスがこうした差を表現し、共有制約と比較衡量できるかにある。(6)
StockIQはERP統合と注文準備を通じて労働を削減してきた。Lokadはこの既存自動化に対し、判断改善、反復確認の削減、事業条件が変わった際の安価な適応という追加利益を示す必要がある。サプライチェーンサイエンティストの保守時間も比較に入る。設定可能なアプリケーションも運用サービスも、誤った経済モデルを直す費用からは逃れられない。(7, 11)
予測、不確実性、購買判断
公開された予測プロセス
StockIQ独自の予測は複数の手法を組み合わせ、製品階層の上位から季節性を借りる。マニュアルは回帰ベースの傾向、季節係数、変動性の設定、バイアス検知を説明する。有用な指摘もある。反応を速めた設定は過去の予測誤差を減らしても、購買を悪化させ得る。この警告は統計的挙動と、それが動かす判断をつなぐ。(2)
トーナメントは三か月前に遡ったモデルで候補アルゴリズムとパラメータ組み合わせを実行し、誤差が最小の結果を選び、現行データで再学習する。現在の対象は反復的需要で、散発的、低回転、動きのない商品、新商品には直接StockIQアルゴリズムを使う。これは検査可能なホールドアウト手順だが、公開データセット、完全な探索空間、補充期間別の性能は示されていない。単一の選択期間は一時的に成功したモデルを優遇し得る。反復選択には、その調整から独立した評価期間が必要だ。(3)
安全在庫画面は予測誤差の入力、その出所とサンプル期間を公開し、wMAPEを総誤差数量を総販売数量で割った値とする。統計的在庫と有効な上書きを区別し、複数の計算手法を用意し、部品表やハブ・アンド・スポークの累積リードタイムを含める。これらは在庫推奨を追跡する助けになる。しかし、完全な予測分布を明らかにせず、割り当てたサービス目標が経済的に妥当とも示さない。(4)
リードタイム測定だけでは不確実性モデルは完成しない
StockIQは事務、製造、出荷、棚入れの遅延を測る。商品、供給者、拠点の各種グループで平均と標準偏差を求め、設定許容範囲外の観測を除外して再計算し、計画余裕を加える。次に段階的に広がる代替グループから選び、ERPリードタイムに対する変更を制限する。得られた要素が計画上の期間になる。(5)
これは信頼性の低いERPのリードタイムマスターを扱う。同時に重要なモデル選択を生む。遅れた配送は誤った時刻記録かもしれず、本当の混乱かもしれない。両方を同じように除けば、保護価値を決める裾そのものを失う。変更の上限は発注を安定させる一方、悪化する供給者への反応を遅らせるかもしれない。公開手法は、需要急増、供給者遅延、共通輸送障害を将来在庫の結果分布にどう組み込むか示さない。多数の商品が同時に危険にさらされる際、こうした依存が重要になる。
2026年4月の記事は、モデル精度だけでは在庫判断に足りないと認める。裏付け、安定性、信頼性の指標を提案し、AUCが正しい判断の割合ではない理由を説明する。精度競争より良い問いである。ただし複合信頼スコアの較正や、発注、待機、販売終了の金銭的影響への変換は公開しない。安定した推奨でも、一貫して高くつく場合はある。(14)
制約処理は具体的だが、目標は分断されている
発注方針には、EOQ付き発注点、ロット・フォー・ロット、最小最大、かんばん、注文駆動補充が含まれる。散発販売用の方針は独立予測を無視し、安全在庫の維持を目指す。これらは実行可能な挙動を作るが、需要のカテゴリ分けは判断ロジックも分ける。低回転の予備部品を持つか、配送を急ぐか、停止を受け入れるかの経済比較には、カテゴリ指定以上のものが必要だ。(22)
Order Wizardは重量、容積、パレット、コンテナ能力、最低数量、包装単位に合わせて数量を調整する。公開手法には、順番に倍数を加える方法や、注文在庫日数、見込み在庫日数、サイクル在庫の均等化がある。日数が延びると別商品を注文に追加できる。数量値引きの選択肢は、割引単価と保有費のペナルティを比較する。実用的な購買機構であり、値引きにはより限定的な経済計算がある。(6)
コンテナ最後のパレット枠を二つの商品が争う状況を考えよう。在庫日数を揃えても、一方を除く逸失利益、次便の遅延確率、代替、売れ残りリスクは評価されない。制約を満たして満載のコンテナでも、誤った在庫を積める。公開文書は、同じ経済目標でこれらを評価する共同の判断ルールを立証しない。
生産性と設定の保守
StockIQの自動発注は供給者・拠点別予定、最初の日次更新後または指定時刻の起動、承認済みの直接送信または確認への振り分けを扱う。通知は発注済み、省略、確認待ちを示す。定型発注処理を排除する具体的手段である。残る問いは、実際に自動送信される割合、方針を適切に維持する作業、例外費用である。(7)
2026年10月に登場したEdisonは質問への回答、推奨説明、購買注文作成、計画パラメータ変更、優先度更新ができる。現行FAQでは、Edison実行前にチームがすべての行動を確認するとしている。したがって人の判断待ち行列が残る。情報探索や入力を軽減できるかもしれないが、既存発注自動化に対する追加生産性を立証する前後比較は公開されていない。(8, 25)
重要な運用指標は、信頼できる購買判断一件当たりの総労働である。例外確認、パラメータ変更、データ修正、統合支援、ミスからの復旧を含む。SKUごとの会話が速くなっても、計画担当者によるSKU処理への依存は消えない。人の承認にも実行可能な速度と十分な文脈が必要で、なければ習慣的クリックになる。
設定には別の労働も生じる。予測応答性、分類閾値、サービス目標、リードタイムフィルタ、代替規則、発注方針、上書きが相互作用する。供給者の混乱は複数箇所の変更を要し得る。文書は各制御を説明するが、顧客方針全体の版管理、過去条件での再実行、改訂方針の安全な適用という一般機構は示さない。(2, 4, 5, 22)
欠品調査は、したがってバッファ追加より先へ進むべきだ。販売履歴が打ち切り需要を隠していたのかもしれず、代替関係が誤り、経済的に有利な速達を補充選択肢から落としていたのかもしれない。その種の失敗の修正には定式化の変更と結果の再試験が必要だ。商品別例外の増殖は元の問題を隠し、次の改訂を高くつかせる。
導入範囲は作業の一部を価格で示す
標準範囲は、既存ERP一つ、夜間更新一回、必須データフィード十種の検証、基本設定、注文書き出し機能、研修二十時間、開始後五週間の相談を含む。追加統合、専用出力、再研修、構造変更、段階展開は毎時250ドルのサービスとなる。採用定着支援の延長は週1,500ドルで、通常は一時間の会議二回か三回である。(10)
この境界は初期の約束を例外的に検査しやすくする。また、月額費用が保有コスト全体を表せない理由も示す。買収、新事業部、ERP変更、離職は別途請求作業を生み、顧客専門家の時間も使う。料金ページはユーザー数無制限と継続的な顧客成功支援を示すが、公開利用料や測定済み年間設定作業量は提供しない。(23)
発売時のリアルタイム予測という表現にも具体的限界がある。標準導入はERPデータを毎晩取り込む。変わらないスナップショットを継続的に考え直しても、まだ届いていない取引は分からない。高頻度の接続は可能かもしれないが、更新頻度と運用費用を導入仕様に含めなければならない。(10, 25)
顧客結果と経済的説明責任
Jofranの事例は導入を2018年とし、SharePointとの専用購買注文統合を説明する。サプライチェーン責任者Deniece Fredericksは、発注時間がおよそ十分の一になったと述べ、文書は欠品の70%減少を報告する。社長兼CFOのKristen Connellは、StockIQによって在庫節約で初年度に少なくとも10倍のROIを得たとしている。事例は、見つかった不足を埋めるベンダーの修正と、その後のERP移行も説明する。(11)
これらは実名での運用改善と是正開発の説明である。財務的発言は重要な会計上の問いを残す。在庫節約とは、在庫から解放した現金、回避した保有費、防いだ評価損、それらの組み合わせのどれか。一度の運転資本解放と反復する利益増加は異なる。事例は投資額の分母、サービス費、比較対象となる仮想的な購買方針を示さない。
Auvecoの事例は過剰在庫60%減、サービスレベル95%超、欠品7%未満、六か月以内の回収を報告する。Dynamics GP導入を2020年とし、その後のNetSuite移行を説明する。運用幹部Josh Woodが顧客側の帰属説明を行う。ただし過剰在庫は在庫の一部であり、定義は目標方針とともに変わり得る。開始時の数値や、運用割合を回収に結ぶ計算は示されていない。(12)
ホームページには予測誤差が20%から5%に下がったという証言もある。誤差式、予測期間、SKU・場所の粒度、重み、ゼロ需要の扱いなしでは、一般に達成可能な95%予測精度の主張を支えられない。需要集計は測定誤差を下げながら、発注を動かす商品別誤差を隠し得る。報告された運用改善は、それ自体の証拠で支えなければならない。(1)
サービスレベルのマニュアルは別の測定選択も示す。実出荷と要求注文の比較を優先するが、出荷詳細がない場合は日次需要と期首在庫からサービスを推定できる。非在庫品を除外することもできる。それぞれ異なる問いに答える方法だ。推定可用性は、実際の完全・定時納品を立証しない。顧客事例の前後比較には一貫した定義が必要である。(13)
公開導入範囲は、顧客の人員と検証責任を定める。公開EULAはStockIQから入手できる署名済み基本契約を参照するが、契約自体を公開しない。したがって公開証拠が立証するのは導入成果物と顧客が帰属させた便益であり、定義された経済的失敗基準や、期待外れの利益を是正する約束ではない。帰属は証拠に従うべきだ。ベンダー規則の誤り、顧客による手動上書き、実行失敗、入力欠落には別の修正が必要になる。(10, 24)
技術の歴史と実現状況
StockIQは2015年創業である。2019年4月の在庫分類記事は、ABC/XYZ分類と、不規則需要への対応を含む差別化された在庫方針を推奨する。現行方針文書もこの構造を維持する。継続性は見える。アプリケーションは、統一された経済的意思決定モデルに置き換えるのではなく、設定可能な在庫計画ルールを中心に発展した。(15, 16, 22)
2025年4月28日のSerent Capital提携発表は、AI予測と価格弾力性モデルへの投資を約束した。続く2025年10月のHuron Peakリリースは、弾力性曲線、価格変更シミュレーション、バリエーション計画用部品表を記録する。.NET Frameworkから.NET Coreへの移行、SSO変更、発注・計算上の多数の修正も記載する。具体的な開発上の実行である。弾力性機能は提供された曲線または顧客が編集した曲線を使う。シミュレーション画面の公開は、曲線の因果的推定や、調整に使った観測外での信頼性を立証しない。(16, 17)
AIという表現は別に評価すべきである。トーナメントのマニュアルは、モデル選択と組み合わせをAI/MLのアンサンブル手法と呼ぶ。AI + IQの資料は、異常販売検知、販売終了の兆候、顧客発注の通知もAIにまとめる。機能は特定されるが、新しい学習手法が旧実装を上回る追加便益は公開されない。技術価値は拡大されたラベルではなく、手法と判断への影響にある。(3, 26)
2026年10月のEdison発売は、言語インターフェースと業務操作を加える。在庫ロジックを理解するという広い主張には、公開された失敗分析や評価手順がない。レビュー時点では機能が発表されたばかりの新製品であり、長年の顧客節約はその貢献を測っていない。ロードマップには実現したアプリケーションと基盤開発がある一方、従来計画からAI主導改善への飛躍には裏付けがかなり少ない。(25)
ソフトウェア構成要素
導入手順と雇用主によるエンジニア求人は、既存製品のランタイム更新と、より新しいプラットフォーム刷新という二段階を示す。
| 構成要素 | 帰属できる役割と範囲 |
|---|---|
| .NET Framework → .NET Core / .NET 8 | Huronリリースとインストール手順はアプリケーション移行を示す。ローカル同期エージェントを持つホスト型顧客にもランタイム前提条件がある。(17, 18) |
| React, Next.js, TypeScript | 現行フルスタック求人で説明されるプラットフォームのフロントエンド。(9) |
| C# REST APIs, Dapper, PgBouncer | その刷新作業のアプリケーション層とデータベースアクセス層。(9) |
| TimescaleDB / PostgreSQL | テナントごとにスキーマを分けるDB構成が明記される。(9) |
| SQS, OpenTelemetry, Grafana Loki | 同じ開発範囲のイベント処理、分散トレース、ログ収集。(9) |
求人は刷新の初期にある小規模チームを記す。移行予定や、既存顧客のうち誰が新構成を使うかは示さない。未解決の運用費は、世代間の維持と移行である。データ変換、コネクタ挙動、認証、顧客設定のすべてに試験が必要だ。(9)
各要素の役割は分かるが、合計費用にはDB調整、キュー復旧、テレメトリ保存、アプリケーション修正、テナント移行が含まれる。テナント別スキーマには、誰が境界を越えられ、権限をどう強制するかという明確な回答も必要になる。計画負荷当たりの基盤費や、設定済み顧客環境の更新作業は公開資料で定量化されていない。
セキュリティと統合境界
StockIQは具体的な認証機構を公開する。Huron移行はSSOをPKCE付きOIDC認可フローへ変え、ログイン維持に必要なIDプロバイダー側の変更を記載する。公開APIガイドはロールと業務データ範囲、トークンハッシュの一方向保存、一時間有効のJWTへの交換を説明する。これらは認証情報の露出と統合側が見られるデータを制限し得る。(19, 20)
一方、APIガイドの期限説明は矛盾する。生成フォームには期限設定があるが、認証節は基になる秘密情報が期限切れしないとする。運用者には稼働版がどちらを強制するか知る必要がある。テナント間隔離の本番証拠、復元試験、Edisonからモデル提供者へのアクセスも未解決である。注文の人による承認は、提案に使われたデータの開示を防ぐものではない。(20, 8)
統合は内部予測エンジンより検査しやすい。APIはフィルタとページ分割を含め、HTMLとJSONでエンドポイント仕様を公開する。注文ファイル接続は、購買、移動、製造指図のヘッダーと明細を説明し、DB出力の代替もある。試験注文と、エクスポート再現に十分な内部情報の保存も説明する。独立した接続作業とERPへの引き渡し追跡を支える。(20, 21)
復旧には境界がなお重要だ。転送を再試行してもERP書き込みが重複購入を生んではならず、再生成注文が後の商業上の約束を上書きしてもならない。公開注文ファイル手順は、端から端までの冪等性と照合プロトコルを規定しない。記録を書き出しても、StockIQの予測や方針の実装が別エンジンへ移植可能になるわけではない。
サプライチェーン評価
サプライチェーンへの理解の深さ
| 評価項目 | 点数 |
|---|---|
| 経済的な問題設定 | 4/10 |
| 実行可能な意思決定への到達 | 7/10 |
| サプライチェーン概念の明確さ | 6/10 |
| 時代遅れの理論への依存の少なさ | 3/10 |
| KPIによる見せかけへの抵抗力 | 4/10 |
平均：4.8/10。
経済的な問題設定 — 4/10。 値引きと保有費の比較は購買経済の一部を扱う。判断を支配する在庫日数とサービスの目標は、競合する商品、限られた能力、不確実な供給に共通する目的を確立しない。(4, 6)
実行可能な意思決定への到達 — 7/10。 自動リリースを含む注文実行経路が文書化されている。在庫日数とサービスの方針だけでは、実行可能な行動間の経済的選択は十分に定まらない。(7, 21)
サプライチェーン概念の明確さ — 6/10。 マニュアルは需要パターン、仕入先遅延の構成要素、反応性の高い予測の影響を区別する。導入に役立つ区別だが、方針ルールへの集約では商品間や不確実な事象間の依存関係の一部が失われる。(2, 5, 22)
時代遅れの理論への依存の少なさ — 3/10。 分類、EOQ、在庫バッファ、在庫日数が意思決定の中心にある。代替、陳腐化、共通制約が最善の購入を左右する場合、それらの経済的仮定は一段と制約的になる。(15, 22)
KPIによる見せかけへの抵抗力 — 4/10。 信頼性の記事は統計的識別力と良い意思決定を正しく区別する。しかし、見出しの予測誤差が未定義で、サービス測定も設定次第なため、顧客成果間の比較は弱まる。(1, 13, 14)
意思決定と最適化の実質
| 評価項目 | 点数 |
|---|---|
| 確率モデリングの深さ | 4/10 |
| 最適化または機械学習の独自性と実質 | 4/10 |
| 現実の制約への対応 | 7/10 |
| 意思決定の自動化と労働生産性 | 7/10 |
| 実務の複雑さに対する修正能力 | 5/10 |
平均：5.4/10。
確率モデリングの深さ — 4/10。 予測誤差と測定された供給変動は計画に影響する。公開手法は、較正された需要とリードタイムの同時分布や、起こり得る結果を通じた経済評価を確立していない。(4, 5, 14)
最適化または機械学習の独自性と実質 — 4/10。 ホールドアウトによる選択と明示的な発注ヒューリスティックで数値処理を検査できる。公開証拠は、有力な従来手法に対する意思決定品質の独自の改善を確立しない。(3, 6)
現実の制約への対応 — 7/10。 購買機構は実際の仕入先と輸送の制約を扱う。限界は、制約が競合するとき、実行可能な数量の中から選ぶ目的にある。(6, 22)
意思決定の自動化と労働生産性 — 7/10。 定時実行とJofranの実名証言は、有意な作業削減を示す。残る総労働量とEdisonの追加効果は公開測定されていない。(7, 8, 11)
実務の複雑さに対する修正能力 — 5/10。 Jofranの事例は運用上の不足を埋めたベンダー側の変更を記す。公開された操作は調整を支えるが、データの意味を改め、別の定式化を試験し、安全に修正を投入する完全な工程は明らかでない。(11, 17, 22)
製品とアーキテクチャの一貫性
| 評価項目 | 点数 |
|---|---|
| アーキテクチャの整合性 | 6/10 |
| システム境界の明確さ | 8/10 |
| セキュリティへの真剣さ | 6/10 |
| ソフトウェア構成の簡素さと保有費 | 5/10 |
| プログラムおよびエージェントによる運用との適合性 | 7/10 |
平均：6.4/10。
アーキテクチャの整合性 — 6/10。 ランタイム移行と刷新の技術構成には特定できる目的がある。顧客移行、共存、旧アーキテクチャ廃止の記述は、長期的な運用形態を確定するには不足する。(9, 17, 18)
システム境界の明確さ — 8/10。 データ供給の責任、配置要件、注文出力は導入担当者に具体的な境界を示す。失敗または再実行されたERP書き込みをまたぐ取引照合の仕様は不十分である。(10, 18, 21)
セキュリティへの真剣さ — 6/10。 範囲制限付き認証情報、ハッシュ化された秘密情報、現代的なSSOは評価可能な機構である。期限の説明の矛盾、隔離とアシスタントのデータ境界の不十分な開示により、重要な統制が未検証のまま残る。(19, 20, 8)
ソフトウェア構成の簡素さと保有費 — 5/10。 公開サービス範囲はいくつかの継続費用を明らかにする。より大きな不確実性は顧客方針の維持と基盤移行の合計費用であり、どちらにも測定された運用基準値がない。(9, 10, 23)
プログラムおよびエージェントによる運用との適合性 — 7/10。 文書化された抽出・実行インターフェースは外部自動化を支える。基礎数値手法に対する顧客の制御は、記録とアプリケーション操作に対する制御より狭い。(20, 21)
技術的透明性
| 評価項目 | 点数 |
|---|---|
| 公開技術文書 | 8/10 |
| ベンダーを介さない検査可能性 | 7/10 |
| 移植性とロックインの可視性 | 6/10 |
| 導入手法の透明性 | 7/10 |
| 技術的主張を支える証拠の密度 | 6/10 |
平均：6.8/10。
公開技術文書 — 8/10。 マニュアルはアルゴリズム、方針の挙動、インターフェース、リリース変更を珍しいほど詳しく示す。完全なモデル仕様と再現可能な性能評価はなお欠けている。(2, 3, 17, 20)
ベンダーを介さない検査可能性 — 7/10。 見込み顧客は営業デモ前に重要な計算・統合上の選択を調べられる。予測と在庫計算の中核を独立に再現することは、非公開の実装詳細に制約される。(4, 5, 6)
移植性とロックインの可視性 — 6/10。 データと注文出力の形式は文書化されている。StockIQ外で設定済み意思決定の挙動を再現するには記録の出力以上が必要で、契約上の終了条件は公開されていない。(20, 21, 24)
導入手法の透明性 — 7/10。 範囲には成果物、顧客側の作業、研修、追加サービス料金が記載されている。継続的なモデル責任と回帰試験の範囲は、初期導入ほど明確でない。(10)
技術的主張を支える証拠の密度 — 6/10。 運用マニュアルは多くの製品機能を裏付ける。広いAIの主張には、既存の計画・統合機能に比べ、支える評価の詳細が大幅に少ない。(3, 17, 25, 26)
ベンダーの真剣さ
| 評価項目 | 点数 |
|---|---|
| 公開発信の技術的真剣さ | 6/10 |
| 技術ロードマップの一貫性 | 7/10 |
| 概念の明確さ | 5/10 |
| 経済的成果への説明責任 | 5/10 |
| エージェント型ソフトウェア時代の競争優位の持続性 | 5/10 |
平均：5.6/10。
公開発信の技術的真剣さ — 6/10。 手法文書と統計的挙動への率直な注意は真剣な評価を支える。AIの理解力に関する広い主張は、この新機能の公開証拠を超えている。(2, 14, 25)
技術ロードマップの一貫性 — 7/10。 弾力性に関する約束には確認できる実装があり、ランタイムと認証の変更にはリリース文書がある。残る不足は、新たなAIの位置付けによる数値上・経済上の追加効果である。(16, 17, 26)
概念の明確さ — 5/10。 StockIQは、良い統計スコアが悪い意思決定につながり得ると認識する。しかし一般の意思決定は依然として代理目標に頼り、不確実性、経済価値、共通制約を統合する方法は公開されていない。(2, 6, 14)
経済的成果への説明責任 — 5/10。 実名顧客がStockIQによる改善を述べ、導入義務も可視化されている。公開証拠は、純利益の評価、経済的失敗、期待利益が実現しない場合の是正責任を定義しない。(10, 11, 12, 24)
エージェント型ソフトウェア時代の競争優位の持続性 — 5/10。 ERP接続、維持される業務ロジック、稼働顧客は会話インターフェース以上の実質をもたらす。持続する差別化には、意思決定の経済性を高め、ますます利用しやすくなる自動化から競合が得られるものより総作業量を減らすことがなお必要である。(7, 11, 20, 25)
出典
すべての出典は2026年11月4日に閲覧した。
StockIQホームページ。製品範囲と予測誤差に関する証言。
アルゴリズムのマニュアル、2025年9月29日更新。予測の構築と反応性。
トーナメントのマニュアル、2025年9月29日更新。選択と対象条件。
安全在庫のマニュアル、2026年10月30日更新。入力、手法、上書き設定。
リードタイム計算マニュアル。フィルタと割当ロジック。
Order Wizardマニュアル。制約と数量調整手法。
自動発注の設定。リリース条件と承認設定。
Edison製品ページ。操作と確認要件。
雇用者StockIQによる求人、2026年確認。基盤刷新と各構成要素の役割。
導入範囲。成果物、責任、追加サービス料金。
顧客事例PDF、日付なし、2026年6月のパスで公開。実名顧客の発言。
Auveco事例。運用指標と導入経緯。
サービスレベル計算マニュアル、2025年8月27日更新。測定方法の選択肢。
[14] StockIQは在庫計画におけるAI判断の信頼性をどう定量化するか
Jake Lathamの記事、2026年4月29日。信頼度の尺度と意思決定に関する主張。
Jake Lathamの記事、2019年4月19日。過去の計画思想。
[16] StockIQとSerent Capitalが提携
Serent CapitalのBusiness Wire発表、FinancialContent転載、2025年4月28日。会社の起源と製品への約束。
バージョン2025.10.30、2025年11月7日更新。機能とランタイムの変更。
インストール手順。配置の前提条件。
SSO移行手順。認証プロトコルと更新要件。
公開APIガイド、2026年9月11日更新。認証情報、範囲、抽出挙動。
注文インターフェース手順。取引出力と試験。
発注方針一覧。補充の挙動。
料金とサービスの説明。契約規模の決め方とサポート。
公開EULAページ。署名済み基本契約への参照。
[25] AIサプライチェーン・インテリジェンス・エージェント
Packaging World掲載のStockIQによる発表、2026年10月9日。Edison発表時の主張。
StockIQのAI概要。機能の位置付けと日付付きウェビナー予定。