市場調査に戻る
Intuiflowは、Demand Driven Technologiesが開発し、2026年1月にAlgoが買収した、製造・流通向けの計画ソフトウェアです。資材計画、補充推奨、生産スケジューリング、需要計画、販売・操業計画によってERPシステムを補完します。中心となる手法はDemand Driven Material Requirements Planning、すなわちDDMRPです。戦略的に配置した在庫バッファが補充と業務上の優先順位を決めます。(1, 2, 11)
サプライチェーン総合評価：4.8/10。
| 評価軸 | 評点 |
|---|---|
| サプライチェーンへの理解の深さ | 4.2/10 |
| 意思決定・最適化の実質 | 4.4/10 |
| 製品とアーキテクチャの一貫性 | 5.6/10 |
| 技術的透明性 | 5.8/10 |
| ベンダーの真剣さ | 4.2/10 |
Intuiflowには具体的な業務メカニズムがあり、公開されている設定文書も、類を見ないほど有用です。発注を生成し、部品表を考慮し、計画を実行につなげます。主な限界は意思決定モデルです。サービス目標、バッファ係数、フローの優先順位が、不確実性の下で実行可能なコミットメントを明示的に経済比較する仕組みの代わりを務めています。これらの規則を自動化すれば作業は減らせますが、最も価値の高い意思決定を規則が選ぶことまでは示せません。
Aptivは有意義な在庫改善を報告していますが、相当な導入作業を伴っています。ベンダーの過去のシミュレーションは、欠品の観測後に加えた調整も含め、バッファ手法を明瞭に示しています。現在のAutopilotは調整作業の解消を約束していますが、公開説明では、学習した方策が金銭的成果をどう改善するのか、供給の不確実性をどう取り込むのかまでは説明されていません。(7, 12, 14)
IntuiflowとLokadの比較
組立ラインを停止させかねない部品を考えます。通常の仕入先は安価ですが、ときどき納期に遅れます。代替仕入先は高価で、複数の完成品が同じ部品を必要としています。バッファは生産を守れますが、その望ましい大きさは、完成品の価値、到着日の分布、緊急輸送費、そして資金を必要とする他の購買との競合によって変わります。
Intuiflowは、在庫の配置、補充の優先順位、設定した保護水準を通じてこの問題に取り組みます。Lokadの在庫最適化アプローチは、確率的な将来予測と継続的に保守する数値的意思決定ロジックを用い、反復的なコミットメントを期待される経済的帰結から評価します。サプライチェーンサイエンティストがこのロジックを開発し、業務条件の変化に応じて改訂します。
違いは、ソフトウェアに何の最適化を求めるかです。高いサービス目標だけでは、次の支出をこの部品、別の部品、緊急輸送、代替調達先のどれに振り向けるべきかは分かりません。Introduction to Supply Chainで展開される視点は、こうした資源の使い道同士の競合を出発点とします。一方、Intuiflowの公開手法は、この判断の多くをバッファの配置、係数、優先順位、例外として組織に表現させます。
ソフトウェアが実際に計算すること
公開Client Playbookは、導入時の判断、業務手順、サポートへの移行を説明しています。旧来のReplenishment+の用語や、2023年の画面を含む顧客設定例が掲載されています。対応するメカニズムを知るには有用ですが、設定例を普遍的な初期値や、新しいAutopilotの仕様と混同してはいけません。(18)
バッファは不確実性を区分と係数に圧縮する
Smart Buffer Profilerは、需要履歴、リードタイムの範囲、変動係数を使って部品を分類します。利用者は、需要履歴の対象期間、適用条件のしきい値、リードタイム係数、変動係数、スパイクの対象期間を選びます。得られたプロファイルが色分けされたバッファ領域を決定し、緑の領域では最低発注数量、発注サイクル、リードタイム係数を考慮します。提案されたプロファイルは、承認前に確認できます。(3)
これは検査可能なヒューリスティックです。弱点は、判断前に捨てられる情報にあります。平均と変動係数が似た需要過程でも、分布の裾、持続性、仕入先の遅延との関係は異なりえます。同じ区分に入れても、経済的リスクまで同等にはなりません。バッファ領域の割合だけでは、低利益率の販売を失うことと、高価値の生産ラインを停止することの差を表現できません。
リードタイムの区分も、その長さを扱っており、将来の入荷に関する確率分布は公開されていません。手法は変動を記述していますが、発注選択時に起こりうる結果を金銭評価する、需要と供給の同時予測を公開していません。保護係数を上げれば、繰り返す問題を補えるかもしれません。しかし、どのリスクを補ったのか、別の対応のほうが安く済むのかは特定できません。
実行機能と部品表の処理には実体がある
処理設定は、バッファ付き部品とバッファなし部品を区別し、MRPの正味所要量計算と、バッファなし品目の供給オーダー自動生成を提供します。リードタイム圧縮は、バッファのない子部品が既に利用可能かを確認し、在庫のある子部品によって親品目の約束日を早められます。予測日次使用量を予測値から計算し、部品表に沿って展開することもできます。(4)
Workbenchでは、計画担当者が数量、日付、調達先、代替部品表を変更でき、積載や梱包の機能もあります。承認済みの発注は、ERPへ転送するための保留オーダーテーブルに送られます。意思決定から実行までの具体的な経路が存在します。(5, 6)
これらの相互作用は重要です。製品は独立したSKU別目標を超える範囲を扱います。残る問題は、システム全体で代替案をどう選ぶかです。代替調達先や代替部品表を担当者に提示するだけでは、不確かな供給可能性、利益率、共有能力、資金を用いて選択する計算が存在する証明にはなりません。その調整の多くは、公開されたバッファ規則の外に残されています。
スケジュールの実行可能性には条件がある
スケジューリングモジュールは、有限能力、機械、シフト、労働力、負荷グラフ、現場の進捗を説明しています。現在のページは「100%実行可能なスケジュール」を掲げ、現実のあらゆるボトルネックを考慮するとしています。(8)
モデル上の能力では実行可能なスケジュールでも、機械の故障、納品の遅延、部品の不合格によって破綻します。重要なのは、再計画の費用も含め、こうした可能性の下でどのコミットメントが経済的に妥当であり続けるかです。能力確認もバッファも、無条件の実行保証を信頼できるものにはしません。
S&OPでは概略能力計画に加え、仕入先の供給途絶や需要変化のシナリオを扱います。古いパンフレットは、将来のバッファ挙動をシミュレーションし、モデルの欠落を見つけるために予測を明示的に使っています。先を見越すこと自体は妥当ですが、シナリオを確認するだけでは確率は得られず、経済的に望ましい対応も選べません。(9, 21)
技術の歴史とロードマップの一貫性
Demand Driven Technologiesは2011年に設立されました。その技術的な軸は、需要主導の計画に置かれ続けています。2022年10月、NextworldはAPIによるIntuiflow統合を発表しました。一方、付随する会社紹介は既に、計画から実行までのAIと機械学習を宣伝していました。統合には具体的な仕組みがありましたが、幅広い知能の主張には、それに見合う検証がありませんでした。(2, 13)
過去のシミュレーションから見える実証の基準
著作権表示が2020年のホワイトペーパーは、会議の来場者57人が提供した需要数値を使う2014年の実演を説明しています。二つの品目を、90日と21日の固定リードタイムでモデル化しています。ある試行では、発注スパイクを事前に把握できなくすると、欠品が二日生じ、サービスは99.5%になりました。赤領域の安全割合を120%から150%へ上げるとサービスは100%に戻りましたが、年間在庫回転数は16.27から14.78へ低下しました。(12)
これが示すのは、保護を増やせば、試した系列での欠品を解消できるということです。次の系列に最適な保護水準を示してはいません。調整は失敗を観測した後に行われ、追加在庫と回避した欠品の金銭比較もありません。二品目の実験では、共有能力、仕入先障害の相関、品目群への配分も検証できません。報告されたサービス率は注文充足の結果であり、予測精度ではありません。
長く残る懸念は方法論です。過去の需要にうまく調整できたことが、頑健な計画の証拠として示されています。意味のある経済評価では、その後の意思決定を評価する前に方策を固定し、実行可能な代替案と比較し、モデル修正に費やした労力も含める必要があります。難しい過去の系列であっても、一つの系列にすぎません。
Autopilotは調整を刷新し、買収は対象範囲を変える
現在のAutopilotは、サービスレベル目標に対する日々のバッファ再調整、局所的な方策、例外アラート、本番変更前のシミュレーションを説明しています。これは実在する保守負担に対処します。公開情報に欠けているのは、学習目的、評価手順、供給の不確実性の扱いです。調整をリスクなしと表現するのは、シミュレーションで示せる範囲を超えています。(7)
2026年1月13日のAlgoによる買収発表は、同社の将来を見通す需要インテリジェンスと、Intuiflowの消費に基づく供給計画を組み合わせるとしました。統合後の会社はAlgoの下で事業を行い、買収条件は非公開です。二つの意思決定手法を計算上どう組み合わせるのかは説明されていません。(2)
ここにはアーキテクチャだけでなく概念上の緊張もあります。製品の訴求は予測への依存を批判しますが、予測は既にシミュレーションへ入力されており、現在は買収理由にもなっています。将来の消費に先立って補充する以上、その消費への期待は必ず含まれます。期待を使用率やバッファの中に隠しても予測リスクは消えず、前提の評価が難しくなるだけです。(1, 21)
ソフトウェア構成とシステムの境界
この製品のアーキテクチャを再構成するには、入手可能な採用情報よりも公開導入文書のほうが有用です。
| 層 | 文書化された構成要素・インターフェース | 運用上の意味 |
|---|---|---|
| ホスト型アプリケーション | シングルテナントのクラウドサービス | 顧客の分離を明示的な設計方針としている |
| ID管理 | Azure Active Directoryによるシングルサインオン | 企業のID管理でログインを制御できる |
| セルフサービス統合 | R+ Pusherまたは顧客が作成するAPI呼び出し | 抽出と転送のスケジュールを顧客が管理する |
| 管理型統合 | Microsoft Integration Runtime、ADX LiteとFullの選択肢 | マッピングと転送の責任は選択肢によって異なる |
| データ交換 | 部品・マスターデータの取り込みと保留オーダーの出力 | ERPとIntuiflowで各フィールドの管理主体を一致させる必要がある |
| 計画担当者向け分析 | Aptivのページで説明される組み込みPower BI | レポート層にも継続的な保守が必要 |
アプリケーションのデータベース、プログラミング言語の実行環境、Autopilotの学習基盤は明らかにされていません。そのため、ホスティング要件、依存関係、更新責任を導入前に評価することは困難です。
インターフェースガイドは、責任分担を珍しいほど具体的に示しています。セルフサービス方式では抽出と変換を顧客が担当します。ADX LiteではMicrosoft Integration Runtimeを顧客の管理境界内に置き、データソースへのアクセスを関連するテーブルとフィールドに限定します。他の選択肢では、抽出、マッピング、転送スケジュールを双方で分担します。これらは継続的な統合作業の責務であり、すべてのERPが問題なく接続できるという一度きりの約束ではありません。(15)
セキュリティ機構と残る露出
Algoは、シングルテナントによる分離、暗号化、テストと本番の分離、脅威監視を説明しています。Playbookには企業向けSSOと設定可能な管理者ロールが記載されています。これらの制御は顧客のワークロードを分離し、計画設定へのアクセスを管理します。(1, 16, 17)
フィールドの管理主体も実務的な制御です。取り込み設定によって、ERPが管理するフィールドをIntuiflow内で利用者が編集できないようにし、マスターの競合を防げます。設定例では、部品の直接編集をプロジェクトの中核チームに制限しています。(20, 22)
公開説明では、管理者侵害後の復旧、独立して保護されたバックアップ、コネクター資格情報の権限範囲、本番の方策変更の承認については具体性が乏しくなっています。テナントの分離が制限するのは一種類の露出であり、侵害された統合を無害にはしません。取り込まれたパラメータはアプリケーションコードを変えずに何千もの補充推奨を変更できるため、これらは重要な問題です。
生産性、設定保守、総費用
日常的なパラメータ確認をなくすというAutopilotの約束は、今日の生産性への期待に即しています。より厳しい検証は、通常の計画業務に必要な総作業量が減っているかどうかです。顧客の計画担当者、導入専門家、ベンダーのサポート、方策の保守担当者をすべて含める必要があります。例外が多いままであったり、根本原因を直さず繰り返されたりすれば、例外中心の運用でも大きなチームを必要とします。
マニュアルからは、解消または維持しなければならない作業が見えます。処理設定例では、平均日次使用量に52週間、変動性に26週間を選び、負の需要の扱いを切り替える設定を用意しています。季節調整には拠点別の月次係数と、明示的な時期の前提を使います。部品は個別にも一括ファイルでも保守できます。これらは設定として符号化された業務判断です。(4, 19, 20)
平均を取る期間を長くするとノイズを抑えられますが、本当の変化の認識も遅れます。返品を除外すれば需要統計を読みやすくできる一方、経済的に重要な情報が失われます。季節的な上乗せは供給可能性を改善しても、イベントの時期がずれれば余剰在庫を生みます。費用がかかるのは、どの解釈が正しいかを判断し、誤りに変わった時点を見つけ、安全に意思決定ロジックを直すことです。
これはHolimizationで説明される問題です。モデルそのものを継続的に改善しなければなりません。不適切な方策の中で再計算を速めても、その方策の改訂には代えられません。保守を測るうえで重要なのは、誤りの帰結も含め、経済的に意味のある修正ごとに必要な労力です。
Aptiv：相当な人的要素を伴う、有意義な成果
Aptivの事例は、試験導入工場で約30%の在庫改善と緊急輸送の減少を報告しています。二年間の試験導入、約三か月にわたる日々の指導、その後の再教育と専門家支援、100を超える工場への展開決定を説明しています。また、仕入先の最低数量を分割し、各工場の在庫を減らすための地域流通の変更も述べています。(14)
これらは検討に値する、信頼できる業務変更です。しかし、ソフトウェアの寄与を指導やネットワーク再設計から切り分けておらず、継続的な作業量や純利益も定量化していません。同じページの結論は、試験導入から100超の工場への拡大が数週間で行われたと述べています。この宣伝上の日程は、詳細な記述と矛盾し、展開の決定、実施、達成された範囲を曖昧にしています。
導入の語り方からは、説明責任のリスクも見えます。手法の遵守は監視されていますが、経済的な検証は手法自体を否定できなければなりません。そうでなければ、成功はDDMRPの正しさを確認し、期待外れの成果は従業員が従わなかった証拠になります。是正プロセスでは、担当者が規則を守ったかだけでなく、バッファや優先順位規則が誤っていたかも検証すべきです。
経済的説明責任と検査可能性
Intuiflowの公開文書によって、購入検討者はデモの前から実際の計算上の選択を問い直せます。これは不透明なAIの主張に比べ、大きな利点です。業務上の出力も検査可能であり、推奨発注、変更数量、出力されたコミットメント、パラメータ設定を、その後の出来事と比較できます。(3, 5, 6)
欠けているのは、こうした選択の金銭的な収支を継続して管理する仕組みです。在庫削減やサービスレベルだけでは、欠品、緊急輸送、割高な仕入れ、陳腐化在庫、導入、保守を含めた後に、方策が価値を生むかは分かりません。現在の需要計画資料はバイアス、絶対誤差、財務的影響に触れていますが、その財務評価が補充の選択をどう左右するかは説明していません。(10)
公開の成果報告では、実行の改善、ネットワーク設計の改善、意思決定の選択改善による利益を区別すべきです。いずれにも価値はありえます。最適化器の質を示すのは最後のものだけであり、プロセスを運用する費用を含めなければ、どれも純価値を示しません。製品の文書化された制御はこうした評価を可能にしますが、公開されている経済的証拠は依然として不十分です。
サプライチェーン評価
総合評価の4.8/10は、等しく重み付けした25の小項目の算術平均を丸めた値です。
サプライチェーンへの理解の深さ：4.2/10
| 項目 | 評点 |
|---|---|
| 経済的な問題設定 | 4/10 |
| 意思決定の最終的な到達点 | 6/10 |
| サプライチェーン概念の明確さ | 5/10 |
| 時代遅れの中心的教義からの独立性 | 2/10 |
| KPIの見せかけに対する頑健性 | 4/10 |
平均：4.2/10。
経済的な問題設定。 運転資金と業務継続性は重要ですが、公開された規則は、在庫と能力の競合する使い道を金銭評価していません。(1, 3)
意思決定の最終的な到達点。 推奨は明示的なワークフローを通じてERPのコミットメントになります。ただし、選択は設定した方策と計画担当者の判断に大きく依存します。(5, 6)
サプライチェーン概念の明確さ。 部品と切り離されたリードタイムの扱いには、業務領域の知識が表れています。相関する不確実性の経済的帰結は十分に展開されていません。(4)
時代遅れの中心的教義からの独立性。 DDMRPが全体を構成する教義であり続けています。その区分と保護係数は、経済的な代替案を比較する前に意思決定モデルを制約します。(3, 11)
KPIの見せかけに対する頑健性。 業務成果は飾りの予測スコアより重要です。それでも、シミュレーション上の完全なサービスと短縮された展開の語りは、証拠が示す範囲を誇張しています。(12, 14)
意思決定・最適化の実質：4.4/10
| 項目 | 評点 |
|---|---|
| 確率的モデリングの深さ | 2/10 |
| 独自の最適化・機械学習の実質 | 4/10 |
| 現実の制約への対応 | 6/10 |
| 意思決定の自動化と労働生産性 | 5/10 |
| 実際の業務の複雑性に対する耐性 | 5/10 |
平均：4.4/10。
確率的モデリングの深さ。 変動性は保護水準に影響しますが、公開されたメカニズムには、将来の需要と供給について較正された同時予測がありません。(3, 4)
独自の最適化・機械学習の実質。 バッファ計算は検査できます。学習した方策の目的と、将来に対する経済評価は明確ではありません。(3, 7)
現実の制約への対応。 製造の依存関係と実務的な発注制約は表現されています。そこから生じる代替案をシステム全体で経済選択する仕組みは、より不明瞭です。(4, 5, 8)
意思決定の自動化と労働生産性。 補充と調整の自動化は定型作業をなくせます。公開された便益は、保守と例外対応の総作業量を測っていません。(4, 7)
実際の業務の複雑性に対する耐性。 工業分野での導入は有用な証拠です。公開された是正プロセスは調整と手法の遵守を重視しており、バッファ規則そのものが不適切な場合に、費用の大きい失敗から別の経済方策の試験へどう進むかを示していません。(12, 14)
製品とアーキテクチャの一貫性：5.6/10
| 項目 | 評点 |
|---|---|
| アーキテクチャの整合性 | 6/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真剣さ | 4/10 |
| ソフトウェアの簡潔性と所有コスト | 5/10 |
| プログラム運用・エージェント支援との親和性 | 6/10 |
平均：5.6/10。
アーキテクチャの整合性。 業務モジュールは一貫した手法を共有します。買収による広範な統合は、技術的な仕様が十分に示されていません。(2, 21)
システム境界の明確さ。 統合の選択肢とフィールドの管理主体によって、ERP、顧客、ベンダー間の具体的な責任が定まっています。(15, 22)
セキュリティへの真剣さ。 ID管理、分離、編集制御は実務上の露出に対処します。復旧の独立性と統合の特権アクセスについては、より詳しい開示が必要です。(1, 16, 17, 22)
ソフトウェアの簡潔性と所有コスト。 見えるアーキテクチャの範囲には一貫性がありますが、運用費には相当な方策保守と統合保守が含まれます。(15, 19, 20)
プログラム運用・エージェント支援との親和性。 APIと一括保守は、画面操作を超える自動化を支えます。コネクターだけでは、経済的な意思決定規則は改善しません。(13, 15, 20)
技術的透明性：5.8/10
| 項目 | 評点 |
|---|---|
| 公開技術文書 | 7/10 |
| ベンダーの仲介なしでの検査可能性 | 6/10 |
| 移植性とロックインの可視性 | 5/10 |
| 導入手法の透明性 | 7/10 |
| 技術的主張を支える証拠の密度 | 4/10 |
平均：5.8/10。
公開技術文書。 Playbookは意味のある設定と業務メカニズムを明らかにしています。新しい学習・最適化の主張の文書化は、それほど充実していません。(3, 4, 18)
ベンダーの仲介なしでの検査可能性。 技術力のある購入検討者は、方策とその保守負担を直接確認できます。現在のAutopilotの評価を再現するには、なおベンダーの協力が必要です。(7, 18)
移植性とロックインの可視性。 転送インターフェースとフィールドの管理主体は文書化されています。蓄積された計画方策の再構成は、移行時の大きな作業として残ります。(6, 19, 22)
導入手法の透明性。 ガイドと導入事例は、設定、指導、業務変更を可視化しています。そのため、より現実的に所有コストを評価できます。(14, 18)
技術的主張を支える証拠の密度。 具体的な計算は限定された機能を裏づけます。完全な実行とリスクのない調整という主張には、同等の検証がありません。(7, 8, 12)
ベンダーの真剣さ：4.2/10
| 項目 | 評点 |
|---|---|
| 公開発信の技術的な真剣さ | 4/10 |
| 技術ロードマップの一貫性 | 6/10 |
| 概念の明確さ | 4/10 |
| 経済的説明責任 | 3/10 |
| エージェント型ソフトウェア時代の競争力 | 4/10 |
平均：4.2/10。
公開発信の技術的な真剣さ。 有用な技術詳細と、絶対的な保証や誇張した導入表現が同居しています。(7, 8, 14)
技術ロードマップの一貫性。 歴史には、特定の業務手法と実在するインターフェースを中心にした継続開発が見られます。広範なAIの主張に対する評価の説得力は、はるかに弱いものです。(2, 13)
概念の明確さ。 優先順位の不安定さを減らすことには価値があります。消費に基づく補充を予測からの脱却とみなすと、方策の中にある将来の前提が見えなくなります。(1, 21)
経済的説明責任。 成果報告は価値の可能性を示しますが、寄与の切り分けと総費用は未解決です。手法の遵守は、その経済的な妥当性の検証より優先されてはいけません。(14)
エージェント型ソフトウェア時代の競争力。 信頼できる実行と保守された産業知識は価値を保ちえます。単純なバッファ計算やワークフロー支援より、継続的な労力を極めて少なく抑えながら、優れた意思決定を実証するほうが競争力を守れます。(3, 5, 7)
出典
日付のないページは2026年11月4日に参照しました。公開Playbookは、顧客の設定例と旧来の用語を含む導入テンプレートです。その設定は、製品の普遍的な初期値として示されたものではありません。
Algo、Intuiflowの概要。モジュール、クラウド構成、分離、業務上の主張。
Algo、Demand Driven Technologiesの買収、2026年1月13日。
Demand Driven Technologies、Smart Buffer Profiler。
Demand Driven Technologies、処理設定。正味所要量、対象期間、予測、リードタイム圧縮、自動発注。
Demand Driven Technologies、Workbench。
Demand Driven Technologies、保留オーダー。
Algo、Intuiflow Autopilot。
Algo、スケジューリングと実行。
Algo、適応型販売・操業計画。
Intuiflow、需要計画。
Demand Driven Technologies、DDMRPとは、PDF。
Erik Bush、Demand Driven Technologies、DDMRPバッファのシミュレーション、著作権表示2020年、PDF。2014年の会議での実験と、その後のパラメータ変更を報告。
Nextworld、Intuiflow統合の提供開始、2022年10月18日。
Algo、二年間の試験導入を経てAptivが世界展開を決定。
Demand Driven Technologies、インターフェース設計。
Demand Driven Technologies、Azure Active Directoryのシングルサインオン。
Demand Driven Technologies、アカウントとアクセス。
Demand Driven Technologies、Client Playbook。
Demand Driven Technologies、計画調整係数。
Demand Driven Technologies、部品属性の変更。
Demand Driven Technologies、Intuiflow製品パンフレット、PDF。資材計画、スケジューリング、予測に基づくシミュレーション、AI・機械学習の訴求。
Demand Driven Technologies、インポートとエクスポート。