サプライチェーンソフトウェアベンダーPluto7の評価

著者：Léon Levinas-Ménard

最終更新：2026年11月4日

Pluto7はGoogle Cloudの導入サービスと、予測、在庫計画、製造分析を行うPlanning in a Boxプラットフォームを提供している。Pi Agentは対話型のアクセスを提供し、専門エージェントを調整する。このプラットフォームは企業データ、業務ルール、推奨、シミュレーション、業務システムへの接続を組み合わせる。 1 2 3

サプライチェーン総合評価：3.4/10。

評価項目	得点
サプライチェーンへの理解の深さ	3.2/10
意思決定と最適化の実質	3.2/10
製品とアーキテクチャの整合性	4.0/10
技術的透明性	4.0/10
ベンダーの真摯さ	2.6/10

Pluto7は有用なデータ統合や機械学習のプロジェクトを実施してきた。現在の提案ははるかに広い。数秒で自律的に動作し、継続的に自己改善し、大きな財務効果を生むサプライチェーンである。公開された仕組みや顧客の証拠は、その広さを裏付けていない。確認できるのはデータ準備、予測、対話による調査、設定可能な実行であり、経済的意思決定エンジンの大部分は明らかでない。 1 7 8

最も重大な懸念は具体的である。現行のROI計算機は、売上高の固定割合から便益を導いている。過去に公開された導入手順は、異例に広範なクラウド権限を要求していた。最新のAlphaEvolve発表は優れた外部技術の名を挙げるが、その出力を経済的に意味あるものにするサプライチェーン評価器は公開していない。 4 6 7 19

Pluto7とLokadの比較

Pluto7は企業データを接続し、既存の計画システムの上に設定可能な知的機能を提供する。Lokadの在庫最適化は、不確実性の下で経済的に優先順位を付けた意思決定を計算することを中心とし、サプライチェーンサイエンティストがその数値ロジックを保守する。Pluto7の公開された運用例は情報アクセスの高速化を重視する。Lokadが目指す出力は、代替案の評価から導かれる購買、配分、その他の確定行為である。どちらも事業固有のエンジニアリングを必要とする。

例えば、別の倉庫で余剰在庫を見つければ、緊急の在庫確認は解決できる。しかし移送量の決定には、受入拠点の需要見込み、供出拠点の将来需要、不確実な補充、輸送費、利益率、在庫の競合用途も必要になる。Pluto7のLeaf Home事例は在庫検索を記録している。公開説明は、その後の配分をこれらの競合する影響全体と照らしてどう選ぶかを示していない。 8

『サプライチェーン入門』のより広い視点は、経済的トレードオフが計算を支配すべきであり、計画担当者による一連の解釈の末に生じるべきではない、というものだ。ホリミゼーションはさらに、業務上の失敗によって費用、制約、選択肢の欠落が判明したとき、意思決定ロジックを変更することを求める。情報を速く取得するエージェントや、変わらない評価基準に対してコードを改善するエージェントは、それだけではこの改訂を行わない。

接続されたデータから実行可能な意思決定へ

Pi.Semanticは製品、仕入先、拠点、注文などのエンティティを、リードタイム、能力、調達ルール、優先順位とともにモデル化する。Pi.Decisionは在庫調整、価格・販促シナリオ、注文の振り分け、例外に基づく承認を説明する。いずれも関連性のある業務対象や手順である。しかし説明からは、共通の金銭目的、共有資源の計算上の扱い、競合する行動を選ぶための不確実な将来状態が分からない。 2 3

専門エージェントの意見が割れたとき、この違いが重要になる。価格エージェントは需要を増やす販促を推奨し、在庫エージェントは在庫削減を、財務エージェントは資金の解放を目指すかもしれない。メッセージの交換だけでは、利益を生む妥協点を決定できない。システムには、部門をまたぐ影響も含め、代替案を一貫して価値評価する仕組みが必要である。

Pluto7の2025年5月の関税発表は、需要、在庫、財務を別々のエージェントに割り当て、A2AとMCPで接続する。この構成は企業内の協働を模倣するものだと明記されている。プロトコルは接続性を提供するが、新たな数値手法や共同最適化を実証するものではない。調査、推奨、承認という従来の順序をエージェントチームとして包装すれば、その下に労働集約的な計画プロセスを残す危険がある。 5

プラットフォームの紹介は、ERPへの自動書き戻しと、行動前に人の承認を必要とするデモの両方を説明する。Pi.Decisionは、影響の大きい意思決定をレビュー対象に挙げる。未解決の運用上の問いは介入率である。代表的な購買や配分業務のどれだけが無人で実行され、意思決定の品質はどうで、継続保守がどれだけ必要なのか。承認ボタンも「自律」という表示も答えにはならない。 2 4

デジタルツインには予測の検証が必要

意味層は現状の関係を正確に表しながら、介入の結果を誤って予測することがある。その表現を欠品、調達変更、価格調整のシミュレーションに使えば、それは多数の相互作用する将来量に関する条件付き予測になる。信頼性は、実施した行動の影響を含め、適切な予測期間でそれらの量を検証することに依存する。 2 3

Pluto7の説明は、需要と将来リードタイムの較正、供給と需要のショック間の依存関係、シミュレーション結果の誤差測定を提供していない。現在のリードタイムの欄は、仕入先の将来行動の予測ではない。シナリオを増やしても、欠落した不確実性の源や誤った経済目的は修復できない。

AlphaEvolve：エンジニアリング責任の所在

2026年8月の発表はPi Agentを完全自律と呼び、新機能をGemini Enterprise内のAlphaEvolveに帰している。また、リスクを共有するサービスと、約2%の売上成長または4%の利益率改善への道筋を宣伝する。しかし進化させたサプライチェーンアルゴリズム、評価器、従来実装との比較、こうした成果を実証する実名の導入例は示されていない。 7

Google DeepMindはAlphaEvolveを、プログラム変更を提案し、自動評価し、結果を使って次の探索を導くシステムと説明する。したがって有効性は、重要なものを測る評価器に依存する。Googleが提供するのはアルゴリズム発見技術である。Pluto7は業務問題、信頼できる将来状態モデル、経済目的、そして生成された意思決定の検証を提供しなければならない。 6

サプライチェーンで難しいエンジニアリングはここにある。評価器は、過剰在庫を許して欠品減少を評価したり、高額な欠品を見落として在庫削減を評価したりし得る。シミュレーターの誤りを悪用する戦略を高く評価することもある。評価器の点数を改善しても、業務改善が成立したとはいえない。Pluto7の宣伝はAlphaEvolveの信用を借りながら、この決定的な貢献を明らかにしていない。

適切な実証は、具体的な業務上の失敗を、定式化の改訂から経済的テストまで追うものになる。アルゴリズムが配分方針を変えるなら、どの仮定を修正し、どの競合行動を検討し、実装後にその方針がどう機能したかを示すべきである。同じ欠陥のある定式化の中を速く探索することは、ここで重要な成功ではない。

顧客事例が立証すること

Leaf Home：調査は速くなるが、計画担当者の仕事は残る

Leaf Home事例は、150を超える拠点、BigQueryに統合したデータ、計画担当者の業務上の質問に答えるエージェントを説明する。以前は何時間もの調査を要した補充の問い合わせに対し、数秒で供給元候補の拠点を返せる。説明は導入を計画担当者の能力拡張と位置付け、初期改善を報告するが、純財務収益や総作業量の推移を数値化していない。 8

これは情報収集作業のもっともらしい削減である。限界も明確だ。在庫の所在確認は補充決定の一段階にすぎない。この事例は、無人でのネットワーク配分、共有データモデルの保守作業、残った例外を確認する費用を立証していない。個々の問い合わせを高速化しても、組織は大量の問い合わせに依存したままになり得る。

California Design Den：費用全体が分からない業務成果

Pluto7はCalifornia Design Denが計画を改善しながら繰越在庫を50%以上削減したと報告する。同じ事例には、ID、課金、リソース階層、ネットワーク、ログ、セキュリティサービスというクラウド導入の詳細がある。この組み合わせはエージェントのスローガンより提供形態をよく示す。業務改善には大規模なデータ・インフラ実装が伴った。公開説明には基準値、測定期間、継続費用全体がない。 9

AB InBev：範囲が限定された過去の製造成果

Googleの事例は、2017年末の試作競争後にPluto7がビール濾過に取り組んだことを説明する。Newark醸造所の六か月分のデータがTensorFlowモデルに使われ、AB InBevは一回のフィルター運転当たりの樽量が60%増えたと報告した。他の醸造所への展開は計画として記述される。これは特定の物理プロセスへの有用な応用を示すのであって、現在の自律サプライチェーンプラットフォームを同社のネットワーク全体に実装した証拠ではない。 10

これは、LLM以前のPluto7の機械学習に実質があったことを示す最も強い証拠でもある。課題、データ、プロセス、物理的成果が特定できる。現在の企業全体に及ぶ主張にも、過去のプロジェクトの実績を遡って借りるのでなく、同じ程度に具体的な証拠が必要である。

予測精度と経済効果計算機

2020年7月の記事は「予測精度95%+」を掲げたが、それが達成水準なのか改善率なのかを明らかにせず、式、粒度、テスト期間も示さなかった。同じ記事は明確な基準と期間を勧めた後、技術の実証より変更管理が重要だと論じた。その見出しは自らの方法論上の助言を満たしていなかった。 11

M5は、省かれた解像度がなぜ重要かを示す。M5の28日間の評価について優勝した点予測を100 × (1 − WAPE)として再計算すると、商品・店舗・日単位では約24.6%、すべての商品と店舗を日別に集計すると97.9%になる。元の予測は変わらない。これは診断用の計算であって、M5の公式WRMSSEスコアでも普遍的な精度上限でもない。集計後のほぼ完璧な割合から、正しい商品と拠点に在庫が届くかはほとんど分からない。 12

現在のDemand ML資料は20%を超える精度改善を約束し、数百の外部シグナルを強調する。しかし定義済みの指標、固定した予測起点、発注期間、基準手法と同等の情報条件を備えた比較はない。新しく利用できるシグナルが予測を改善することはある。「デマンドセンシング」という名称は、その情報が意思決定期限前に届いたことや、意思決定の経済性を改善したことを証明しない。 13

プラットフォーム紹介のROI計算機には、より直接的な問題がある。そのJavaScriptは潜在便益の合計を、入力した年間売上高の2%として計算する。優先順位のスライダーは、この固定額を各用途に振り分ける。年商10億ドルの企業について公開計算を再現すると、すべてのスライダーをLimitedにしてもDisruptiveにしても2,000万ドルとなる。費用、現在の業績、利益率、実際の導入成果はこの合計を決めていない。 4

これは財務上の仮定を対話型計算として提示したものだ。期待収益の根拠にはならない。すでに効率的に運営している小売企業にも、深刻な在庫問題を抱える企業にも、それぞれの回避可能な損失を測定する前に、売上高に対して同じ便益を割り当てる。

技術の歴史：MLプロジェクトから自律性の約束へ

時期	主張または実績	評価
2017–2019年	AB InBevの濾過プロジェクトが明確な製造成果を出した。	証拠は限定された用途を裏付ける。宣伝された展開は説明上まだ将来計画だった。 10
2020年	需要予測の宣伝に説明のない95%+という数字を用いた。	統計的証拠は主張の自信ほど強くなかった。 11
2021年10月	Planning in a Box 2.0がサプライチェーンツインと「企業のサプライチェーンの頭脳」を導入した。	公開された仕組みは接続データ、モデル化、可視化を重視し、ツイン全体の予測検証はなかった。 14
2024年4月–7月	Planning in a Box 3.0がGeminiによる質問、ダッシュボード生成、編集可能なモデルを追加し、Pi Agentが続いた。	発表は具体的な作成・情報アクセス機能を示した。経済的最適化器は示さなかった。 15 16
2025年5月	関税エージェント、A2A、MCPが協調計画の説明を拡張した。	エージェント間の通信は共通の意思決定目的を立証しなかった。 5
2026年8月	AlphaEvolveと完全自律プラットフォームが主な訴求点となった。	主張された運用能力の変化には、公開された導入前後の意思決定比較がない。 7

Pluto7の統合・モデル化の仕事には連続性がある。同時に、その検証可能な仕事と主張の範囲の隔たりは広がっている。データ接続を増やすこと、対話で利用できるようにすること、エージェント調整を加えることは異なる技術変更であり、どれも以前の経済改善の約束を自動的に検証するものではない。

パートナーの継続性は、産業データ収集とPluto7のGoogle Cloud分析を結んだ2021年のLitmusとの関係に見られる。Litmusは現在も保守されたソフトウェアを公開し、2026年9月のリリースノートもある。どちらの資料も共同導入の成果を数値化していない。 28 29

ソフトウェア構成部品表

証拠と時期	構成要素と用途	帰結
2020年のマーケットプレイスガイド	アプリケーションにCompute EngineとCloud SQL、BigQueryへのアクセス、データ移動にPub/Sub、Cloud Functions、Cloud Build。 18	複数の運用サービスと認証情報がパッケージ化されたアプリケーションを支えた。
2021年のMLOpsガイド	Docker、Kubernetes、Kubeflow、Python部品、Cloud Build、ストレージ、分離した開発・本番プロジェクト。 17	配備の自動化にはコンテナ、パイプライン設定、権限、テストが必要だった。
2023年のDemand MLガイド	Compute Engine、Cloud Storage、Container Registry、Firestore、BigQuery、Vertex AI。 19 20	予測をインストーラーにまとめても、大きなクラウド環境の運用は残った。
現行プラットフォーム	BigQuery、Cortex、Vertex AI、Gemini Enterprise、エージェント調整。 1 7	データ統合とモデル運用はGoogleのサービスのライフサイクルに依存し続ける。
現在のDevOps・セキュリティ求人	インフラのコード化、配信パイプライン、監視、コンテナ、クラウドセキュリティを担当。Terraform、Docker、Kubernetesを明記。 22	同社は運用環境を構築・保守する技術者を明確に必要としている。

この一覧は、一見単純なインターフェースの下にある作業量を示す。データ同期、権限設定、モデルバージョンの配備、ジョブ監視、失敗したパイプラインの復旧である。クラウド提供元が単一でも、これらの責任は消えない。

ライフサイクルの変化はさらに仕事を生む。古い導入ガイドはDeployment Managerを使う。Googleは2026年に標準サポートを終了し、6月30日以降は新規ユーザーによるサービス有効化を停止した。既存リソースは稼働を続けられるが、過去の配備手順は移行が必要になる。現行Pi Agentの導入には、その代替経路の最新文書が必要である。 19 21

保守と総費用

現在の紹介は、限定パイロットを四週間90,000ドル、その後の三か月を月40,000ドル、安定化を月30,000ドルとする。示された四か月の安定化期間を適用すると、その段階までで330,000ドルとなり、後続料金と範囲外費用は含まれない。数値は参考額で、用途や規模拡大の前提が限定されている。ソフトウェアのインストール所要時間にかかわらず、相当規模のサービス契約である。 4

別の価格ページは、継続的なカスタマイズ、アップグレード、支援、保守、従量課金ライセンスを列挙する。Pi.Semanticには顧客のルールや関係も組み込まれる。したがって調達方針や商品階層を変えるとソフトウェア保守が発生する。誰かが意味を確定し、ロジックを更新し、影響を試験し、変更を配備しなければならない。 3 26

Pluto7はモデル監視とバージョン管理を提供し、過去の開発者ガイドは前処理と統計テスト部品を持つビルドパイプラインを示す。これらはモデル保守の有用な土台である。一方で、高額な損失を生む判断の後に業務上の定式化を修正し、その経済性を再検証することについては、公開証拠が薄い。パイプラインの修理や予測指標の改善だけとは異なる。 17 30

セキュリティ：テナントの表示でなく権限を調べる

現在のPi.Shield資料は、ID、監査証跡、不正な照会やモデルの遮断を説明する。一般的なセキュリティページはVPC Service Controls、Secret Manager、IDに基づくアクセスなどを挙げる。これらは安全な構成を支え得るが、公開説明からは実際の権限境界、エージェントコードの制限、認証情報侵害後の復旧動作が分からない。 23 24

2023年5月のDemand MLガイドははるかに具体的である。顧客に、ポート3000をインターネットアドレスへ開放し、VMにCloud APIのフルアクセスを与え、広範な管理ロールを持つサービスアカウントを作り、ダウンロードした鍵をVMに置くよう指示する。8月の自動化ガイドも広いロールと鍵ファイル方式を維持する。これらは過去の指示であり、Project IAM Admin、Service Account Admin、BigQuery Admin、Storage Adminを含む。 19 20

このような権限は、侵害されたアプリケーションや鍵が引き起こす被害を拡大する。顧客のクラウドテナント内で動いていても、アプリケーションがその中のリソースを管理できるなら被害は封じ込められない。現在のセキュリティ説明には、これらの導入初期設定を、より狭いロールと権限を限定した認証情報にどう置き換えたかという明示的な説明がない。

Glassboxの提案は、社内チームによるアルゴリズム調整とワークフロー拡張も促す。その柔軟性には、追加コードの外側にある技術的制御が必要だ。データ・ネットワークアクセスの制限、依存関係管理、隔離実行、テスト済みの本番昇格である。モデルの可視性だけでは、こうした境界は成立しない。 25

結果責任と検査権

AlphaEvolveの発表は、リスクを共有し、成果に基づくサービスを支持する。経済的に意味ある契約なら、基準値、費用、観測期間、失敗条件、救済措置を定め、予測、方針、実行の誤りを誰が直すかも規定する。発表はそうした条件を示していない。 7

公開されているPluto7の利用条件文書は、ファイル名で2019年と示され、ソリューションをベンチマークや性能指標の開発に使うことを禁じていた。ソフトウェアとその改良もPluto7に留保していた。この過去の制限は、後の透明なモデルやロックイン回避の約束と整合しにくい。納入システムを調査、試験、保持、変更する権利は、現在の契約で明示する必要がある。顧客のテナントにコードを配備しても、その権利が確定するわけではない。 27 25

経済効果の主張は、失敗し得るテストに耐えるべきである。便益を前提とする計算機、顧客ロゴ、パイロットで価値を証明するという約束は、その代わりにならない。重要な結果は、利用料、クラウド使用、統合、継続的なモデル作業、顧客側の労働を含めた後の業務改善である。

サプライチェーン評価

サプライチェーンへの理解の深さ

基準	得点
経済的な問題設定	4/10
最終成果としての意思決定	4/10
サプライチェーンに関する概念の明確さ	3/10
時代遅れの中心的教義からの脱却	3/10
KPI演出への耐性	2/10

平均：3.2/10。

経済的な問題設定 — 4/10。 費用、利益率、運転資本はエージェントの説明に現れる。しかしその共同評価は、業務上の選択を決める目的として公開されていない。 5

最終成果としての意思決定 — 4/10。 実行と書き戻しは製品提案に含まれる。最も明確な顧客の計画事例は調査の高速化を示すが、経済的に正当化された行動の選択と実行は十分に実証されていない。 2 8

サプライチェーンに関する概念の明確さ — 3/10。 意味モデルは関連するエンティティや制限を認識している。共有表現は資源獲得の競合を解決せず、意思決定の結果にある不確実性も説明しない。 3

時代遅れの中心的教義からの脱却 — 3/10。 エージェントは部門別の計画責任と例外ワークフローを再現する。インターフェースを変えても、繰り返される計画担当者の判断を再利用可能な経済ロジックで置き換えた証拠にはならない。 2 5

KPI演出への耐性 — 2/10。 精度の主張には解釈に必要な評価条件が欠け、対話型の便益推計は主要な結果を前提としている。これらの提示は、詳細な供給判断や財務収益を裏付けられない。 11 13 4

意思決定と最適化の実質

基準	得点
確率的モデル化の深さ	2/10
独自の最適化・機械学習の実質	4/10
現実の制約への対応	4/10
意思決定の自動化と労働生産性	3/10
実際の業務の複雑さへの対応力	3/10

平均：3.2/10。

確率的モデル化の深さ — 2/10。 シナリオや予測エージェントは説明されるが、需要と将来供給を共同で較正した扱いは示されない。条件付きシミュレーションの誤差とその経済的影響は、公開説明では測定されていない。 3 5

独自の最適化・機械学習の実質 — 4/10。 過去の製造分野の仕事は、具体的な機械学習応用を示す。現在のAlphaEvolveの宣伝は、Pluto7のサプライチェーン評価器とアルゴリズム上の貢献を特定していない。 10 7

現実の制約への対応 — 4/10。 モデルは能力、調達、業界構造を明示的に含む。公開文書は、エージェントが競合する行動を推奨したとき、それらの制約を同時にどう満たすかを示していない。 3

意思決定の自動化と労働生産性 — 3/10。 Leaf Homeの情報収集は高速化した。しかし無人で行われる意思決定の範囲と、残るエンジニアリング、確認、実行作業を包括的に測ったものはない。 8

実際の業務の複雑さへの対応力 — 3/10。 監視と配備パイプラインは技術的修正を支える。業務上の損失から目的と仮定を改訂し、経済的にテストした意思決定へ進む循環の実証はない。 17 30

製品とアーキテクチャの整合性

基準	得点
アーキテクチャの一貫性	5/10
システム境界の明確さ	5/10
セキュリティへの真剣さ	2/10
ソフトウェアの簡潔さと保有費用	3/10
プログラムとエージェントによる運用への適合性	5/10

平均：4.0/10。

アーキテクチャの一貫性 — 5/10。 データ、意味、意思決定、実行は共通クラウド基盤上で識別可能な役割を持つ。しかし層をまたぐ数値目的の一貫性は立証されていない。 1 2 3

システム境界の明確さ — 5/10。 顧客テナントへの配備と既存システムとの共存は明確である。顧客コード、Pluto7のサービス、クラウドサービス、後続の計画担当者の責任分担はそれほど明確でない。 7 25

セキュリティへの真剣さ — 2/10。 2023年のDemand MLガイドは、広範な管理権限を持つサービスアカウントの鍵をアプリケーションVMに置いていた。現行の制御は、検証可能な代替設定や封じ込めモデルを示さずに説明される。 19 20 23

ソフトウェアの簡潔さと保有費用 — 3/10。 複数のマネージドサービスと顧客固有ルールは継続運用を要する。公開料金で費用の一部は見えるが、持続する経済効果に対する総費用は未解決である。 4 26

プログラムとエージェントによる運用への適合性 — 5/10。 API、パイプライン、エージェント統合は自動化の接点を提供する。その存在は、信頼できる自律的な供給判断や低保守の運用を立証するものではない。 5 17

技術的透明性

基準	得点
公開技術文書	5/10
ベンダーの仲介なしでの検証可能性	4/10
移植性とロックインの可視性	3/10
導入方法の透明性	5/10
技術的主張を支える証拠の密度	3/10

平均：4.0/10。

公開技術文書 — 5/10。 配備とMLOpsのガイドは具体的なインフラと手順を公開する。文書の古さと依存先のライフサイクルが、現行エージェント基盤を検証する上での有用性を制限する。 17 19 21

ベンダーの仲介なしでの検証可能性 — 4/10。 Glassboxモデルは顧客環境内の可視性と拡張を約束する。公開された数値手法と、再現可能な現在の意思決定ベンチマークは依然としてない。 25

移植性とロックインの可視性 — 3/10。 クラウド環境を所有すれば運用アクセスは得られるが、Googleサービスへの依存と未解決のソフトウェア権利が実際の移植性を制約する。過去の条件から、納入ロジックを保持・運用する現在の権利は確定できない。 21 27

導入方法の透明性 — 5/10。 段階的導入、料金、過去のビルドパイプラインは相当な実装作業を明らかにする。業務の意味定義と経済的意思決定ロジックの保守負担は、同様には数値化されていない。 4 17

技術的主張を支える証拠の密度 — 3/10。 顧客事例は限定された業務改善を裏付ける。現在宣伝される、自己改善し企業全体に及ぶ自律性の広さは検証していない。 8 9 10

ベンダーの真摯さ

基準	得点
公開発信の技術的な真摯さ	2/10
技術ロードマップの一貫性	3/10
概念の明確さ	3/10
経済的結果への責任	2/10
エージェント型ソフトウェアの世界での競争優位	3/10