市場調査に戻る
Pigmentは、財務計画と業務計画のアプリケーションを構築するクラウドプラットフォームです。ユーザーは多次元データ、数式、予測、シナリオ、報告、ワークフローを定義します。サプライチェーン向け機能は、需要、在庫、能力、販売・操業計画を扱い、財務計画とも接続します。AIエージェントが分析とモデル構築を支援します。(1, 9, 25)
サプライチェーン総合スコア：6.1/10。
| 評価軸 | スコア |
|---|---|
| サプライチェーンへの理解の深さ | 5.2/10 |
| 意思決定と最適化の実質 | 5.4/10 |
| 製品とアーキテクチャの整合性 | 7.0/10 |
| 技術的透明性 | 6.8/10 |
| ベンダーの真剣さ | 6.2/10 |
Pigmentの最も強い貢献は、モデルそのものを維持する能力を高めつつあるツールを備えた、プログラム可能な計画環境です。文書では、予測手法、本番環境の保護策、障害の発生経路、オープンソース部品をめぐる相当な技術開発を公開しています。しかしサプライチェーンにとって中心的な限界は残ります。柔軟なモデルと迅速なシナリオ準備は、需要と供給の同時不確実性のもとで動く経済的意思決定エンジンを実証するものではありません。Planner Agentは、今も公開ロードマップ上の機能です。(3, 9, 15, 17, 25)
Pigmentは、生成されたPythonを封じ込め、ユーザーの代理操作に読み取り専用を強制する方法を説明しています。同時に、アプリケーションレベルでは懸念の残る挙動も文書化しています。数式の変更がアクセス制御を変えること、モデルの編集が恒久的になり得ること、新しいAI機能の一部が標準のデプロイ工程から外れることです。(9, 10, 14, 15, 16)
PigmentとLokadの比較
Pigmentは、企業が独自の計画アプリケーションを構築するためのツールを提供します。何を予測し、どの数式でつなぎ、どのシナリオを比較し、どの計画を承認するかは顧客が決めます。Lokadのサプライチェーン最適化は、不確実性のもとで業務上の意思決定を計算し、その経済価値で順位付けすることを中心としています。サプライチェーンサイエンティストが、それらの判断に必要な数値モデルとデータ準備を維持します。大枠の設計思想は、Introduction to Supply Chainに示されています。(1, 9)
部品の購買では、Pigmentは需要予測、部品表、現在庫、リードタイムの仮定、購買計算を接続できます。Cheerzは、そのようなアプリケーションを説明しています。より難しいのは、仕入先からの到着、需要、歩留まり、資金の別の使途が不確実なとき、どれだけ買うべきかという問題です。Lokadのアプローチは、起こり得る結果に経済的帰結を割り当て、利用可能な行動をまとめて評価します。Pigmentが提供するのは、その論理の相当部分をさらに設計し検証する必要があるモデリング環境です。(7, 29)
PigmentのModeler Agentは、数式とモデルの構築を自動化することで導入費用を削減できます。しかし、数式を速く作れることは、それが正しい事業目的を表現している証明にはなりません。生産性の検証では、レビュー、回帰確認、実務上の追跡まで含めて、顧客チームがより少ない総労力で意思決定モデルを安全に改訂し改善できるかを問う必要があります。(9, 26)
数値モデル：経済的意思決定に先立つ予測とシナリオ
在庫計算はプログラム可能だが、最適化の方法論が付属するわけではない
Pigmentは、期首在庫、補充入荷、期末在庫を時間軸でつなぐ在庫例など、複数ブロックにまたがる反復計算を文書化しています。現在のPREVIOUSOF機構は、共通の反復次元を使う構成で、最大十個の指標を扱えます。顧客の論理を表すための有用な計算部品です。(29)
しかし、それらが経済的な問題設定を選ぶわけではありません。在庫方程式が正しくても、補充ルールは代替、期限切れ、仕入先の不規則な納品、希少な資本の機会費用を無視しているかもしれません。次元や数式を増やしても、対応する行動の選択肢が自動で増えるわけではありません。Holimizationで説明するように、重要な改善は、既存の前提の中でより精密に計算することではなく、モデルが考慮する範囲を変えることかもしれません。
公開されているサプライチェーン向け提案は、接続された計画と迅速なシナリオ比較を重視します。これにより、能力や購買の影響を部門横断で調べられます。一方、競合する業務行動を期待経済収益で順位付けする標準の目的関数や、需要、リードタイム、能力の不確実性をまとめて評価する標準手法は明らかにしていません。その作業は、アプリケーション設計の大きな部分として残っています。(1, 5, 29)
予測の開示には有用な定量情報がある
PigmentのPredictions機能は、基準予測と95%予測区間の下限・上限を出力します。AutoMLによる選択は、履歴の最後の20%に対するMASEを用い、系列ごとに複数モデルを評価します。文書化された選択肢にはAutoETS、Chronos-2、Prophet、より単純な手法があり、Chronos-2は顧客固有のファインチューニングなしで使われます。(2, 3)
公開ベンチマークは、季節ナイーブ予測を基準とする誤差尺度MASEを用いています。
| ベンチマーク | Chronos-2の平均MASE | 季節ナイーブ基準 |
|---|---|---|
| 月次、予測期間12か月 | 1.102 | 1.000 |
| 週次、予測期間52週 | 0.900 | 1.000 |
| 日次、予測期間365日 | 0.718 | 1.000 |
データセットは一般的な事業指標、とりわけ財務上の売上系列を重視し、顧客データは含みません。同じ比較で、月次のTimesFM 2.5は0.981です。したがってChronos-2は、この月次テストではナイーブ基準に負けています。周辺の文章が広く優れた性能をうたっていても、この結果は変わりません。これらの数値をSKU・拠点単位の補充に移したり、正しい予測の割合と解釈したりすることはできません。(3)
予測区間は不確実性に関する有用な情報ですが、名目上の95%被覆率は95%の予測精度ではありません。在庫判断では、行動に影響する諸量の、検証された同時分布が必要です。個々の系列の周辺区間だけでは、製品間で相関する需要、不確実な仕入先リードタイム、その結果生じる欠品費用を定められません。Pigmentの公開文書は、これらの不確実性を行動価値の計算にまとめているとは示していません。(2, 5)
外部要因は予測に役立っても介入を説明するとは限らない
Pigmentは、最大十個の外部要因指標を受け付けます。データは過去と将来の両方の期間を少なくとも90%カバーする必要があり、欠測値は補完されます。グレンジャー検定は最大五個のラグを調べ、p値が0.005を下回ると要因を選びます。Prophetは対応する影響係数を示せますが、文書ではChronos-2やAutoML向けの係数は提供していません。(4)
マーケティング変数が売上予測に役立つのは、マーケティングチームがすでに需要について何かを知っているからかもしれません。それだけでは、企業が支出を変えた場合に何が起きるかは分かりません。同様に、将来の天候や競合価格も、事前に既知でない限り予測対象です。それらの不確実性と、元の意思決定時点で利用できたかどうかが重要です。文書化された選別手順は、販促の因果的最適化や不確実性の同時伝播を実証しません。(4)
Pigmentの2026年8月のサプライチェーン記事は、範囲を持つ予測を明確に支持し、リードタイムの変動を認めています。しかし、それ以前の匿名小売企業の事例では、合意した単一の需要数値と、目標達成のためのシナリオを中心に計画しています。プラットフォームはどちらのやり方にも対応できます。不確実性が判断に反映されるか、合意計画に圧縮されるかは、顧客の方法論によって決まります。(5, 6)
エージェントの生産性：実質的な進歩はモデルの構築にある
モデル構築は高速化しても、検証は必要なまま
Modeler Agentは、ブロック、数式、次元、カレンダーを作成・編集します。2026年10月の文書には、Ask、Build、Plan & Buildモードが記載され、削除以外は任意で自動承認できます。変更は恒久的で、アプリケーション履歴上では開始したメンバーに帰属します。(9)
Pigmentは、新しい指標と数式の70%をエージェントが作成していると報告しています。また、Unilever North Americaの間接費アプリケーションを25日で構築・稼働させたとし、代替案の推定四〜六か月と比較しています。これは財務計画での構築速度に関する証拠です。比較には、実測した反実仮想、欠陥率、その後の保守労力、サプライチェーンの意思決定結果はありません。(26)
モデル保守は、定義のすり合わせ、依存関係の追跡、数式の修正、報告の再構築といった高額な専門作業を要します。エージェントはその仕事を減らせます。経済的利益は、生成されたコードや数式の比率ではなく、できたアプリケーションの品質と寿命に依存します。不要な指標が大量にあれば、生産性ではなく保守負担が増えます。
日々の計画には大きな人的要素が残る
Cheerzは、月次の業務計画サイクルを一週間から一日未満に短縮し、在庫を30%削減したと報告しています。購買アプリケーションは在庫システムから日次データを取り込み、準備した部品表を通じて部品をモデル化します。Danoneの乳児用ミルクと医療栄養の計画事例では、入力が予定どおり届くことを条件に、戦略計画の準備作業が二週間から一日に短縮されたとしています。専用のS&OP・戦略モデルはStatera Consultingと三か月で構築しました。(7, 8)
これらの事例は、意味のある業務量削減を示しています。ただし分母は特定のプロセスであり、業務判断を正しく保つための総費用ではありません。Cheerzが述べるように、集約が速くなれば計画サイクルを増やせます。レビューを頻繁にすれば反応は速くなっても、同じ人間の承認とモデル修正に依存し続けることはあります。どちらも、顧客業務全体の自律補充を実証してはいません。(7, 8)
MCPは接続機能であり、モデル変更ツールは別に評価すべき
PigmentのMCPサーバーはユーザーを認証し、既存の権限を適用し、ブロックをAIアクセスから除外できるようにしています。10月のツール変更履歴には、生データ取得、依存関係の調査、性能調査が含まれ、取得データの順位付けと閾値処理は現在、外部AIツール側で実行されます。(11, 28)
接続機能だけなら、少ない労力で実装できる連携であり、サプライチェーン意思決定エンジンの証拠ではありません。ユーザーの質問と報告の流れを外部アシスタントに移しても、基盤となる手動の運営モデルは残ります。Pigmentのより実質的なエージェント開発は、制御された実行と文書化されたツールを使って、アプリケーションを変更・維持する部分にあります。自律的な経済計画については、依然として提供済み機能の証拠がありません。(9, 15, 25)
セキュリティアーキテクチャとモデルを安全に変える費用
生成Pythonは敵対的なコードとして扱われる
Pigmentの2026年6月の技術記事は、Analyst Agentが生成するPythonの実行環境を説明しています。専用ワーカー、実行ごとの分離、ネットワーク遮断、認証情報をマウントしない構成、資源制限、読み取り専用のルートファイルシステム、使い捨ての一時ストレージ、gVisorを用います。各サンドボックスポッドは一回の実行を担当します。記事は、正規表現によるチェックを十分な安全境界とみなす考えを明確に退けています。(15)
大規模データでは、信頼されたサービスがデータを取得してサンドボックスへ送り、サンドボックスにクラウド認証情報を渡さない状態を維持します。悪意あるプロンプト、安全でない生成コード、偶発的な情報漏えいへの、実質的な設計上の対応です。安全性は生成プログラムの外で強制されます。記事は、調べて試験できる具体的なアーキテクチャを提示しています。(15)
別の4月の記事は、管理者による代理操作を説明します。署名された読み取り専用状態がAPIミドルウェアに届き、全エンドポイントがそうしたセッションを許可するか宣言しなければなりません。独自のビルド時解析器が、宣言の欠落を拒否します。これにより、新規エンドポイントが気付かれないまま制御を回避する危険を減らせます。ただし保証は、許可するエンドポイントの正しい分類に依存します。あらゆる書き込みをデータベース側で禁止する仕組みではありません。(16)
数式の権限がデータの権限を損なうことがある
Pigmentは、セキュリティ管理権限を持たないモデル作成者でも、アクセスルールで使われる数式を変えることで制限データを公開してしまう経路を文書化しています。対策は、影響を受けるブロックを、セキュリティ権限のあるユーザーだけがアクセスできるSecurity Folderに置くことです。記事は当初、信頼できるモデル作成者を推奨し、その後、この技術的な分離を説明しています。(14)
モデルコードがセキュリティ方針の定義に参加するため、この仕組みは重要です。したがって封じ込めは、最終的なアクセス権指標だけでなく、権限を計算する依存関係全体を覆う必要があります。モデルの進化に伴い、これらを正しく特定して保護する作業は継続的な設定業務になります。エージェントが変更を速く書くほど、この境界は重要になります。プロンプトを入力する人を信頼しても、生成された変更すべてが安全になるわけではありません。(14)
デプロイと復旧には重大な例外がある
PigmentのTest & Deployは、構造変更と本番利用を分離しますが、データは一般に環境間で同期されません。文書は、本番のアクセスルールに緊急変更を加えても、開発側で繰り返さなければ次のデプロイで上書きされると警告しています。また、上書き入力を無効にしている場合、数式のデプロイが既存の入力を破棄し得るとも警告します。レビューと試験を要する具体的な障害経路です。(13)
Modelerの文書は現在、Test & Deployで管理されるアプリケーションをAskモードに制限しています。そのため、統制されたアプリケーション運用では、宣伝されるモデル書き換え能力が制限されます。新しい生成インターフェース機能FramesもTest & Deployには対応せず、作成者は複製、改良、公開という手順を取ります。(9, 10)
Framesには、文書化された実行境界があります。Pigmentの公開作成仕様は、不透明なオリジンを持つサンドボックス化iframe内でJavaScriptを実行し、ネットワーク、外部コード読み込み、ブラウザストレージ、親へのアクセスを遮断すると説明します。宣言済みのデータソースと書き込み先が、モデルとのやり取りを仲介します。一方、製品文書は、セキュリティ権限を持つユーザーによる書き込み確認ダイアログの無効化を認めています。ブラウザ分離はコードに伴う危険を減らしますが、許可された書き込みの業務上の意味を検証しません。(10, 12)
ブロックの復旧も、取り消しコマンドより複雑です。文書化された手順では通常、過去七日分の日次バックアップを使い、ブロックを新しいオブジェクトとして復元し、当初はアプリケーション管理者だけにアクセスを制限します。データを稼働中モデルへ戻すには、コピーや数式による突き合わせが必要な場合があります。これは復旧時の不用意な広範囲公開を防ぎますが、誤ったモデル変更の後には相応の復元作業が残ります。(19)
ソフトウェア構成部品と保有・運用費用
| 層 | 開示された構成要素 | 証拠 |
|---|---|---|
| アプリケーション | Linux上のC# ASP.NET Core、Goサービス、ReactとTypeScriptのインターフェース | 現行のSRE求人が本番スタックを明示しています。(18) |
| データとメッセージング | Cloud SQLおよびCloudNativePGによるPostgreSQL、SingleStore、Elasticsearch、RabbitMQ、Temporal | 同じ求人が、これらを稼働中のプラットフォーム部品として挙げています。(18) |
| インフラ | Google Kubernetes Engine、Terraform、ArgoCD、Istio、Vault | 現在のインフラ担当業務です。(18) |
| Predictions | Python、Dask、Google Cloud Storage、Avro転送 | 2025年9月の技術アーキテクチャです。(17) |
| エージェント分析 | 2024年の設計におけるLangGraph/LangChain、2026年に文書化された堅牢化Python実行サービス | 日付のある技術説明です。(15, 23) |
相当な規模のソフトウェア群です。複数のデータシステム、キュー、ワークフローサービス、サービスメッシュ、分散予測実行環境は、更新、可観測性、アクセス制御、障害復旧の責任を生みます。費用面の問いは、各層が顧客へ実際に提供する能力によって自らの費用を正当化できるかです。Pigmentは、こうした技術維持責任について珍しく有用な証拠を提供しますが、維持されるサプライチェーン判断一件当たり、または比較可能な処理負荷当たりの費用は示していません。
Daskの記事は、旧予測サービスが単一マシンの資源を使い切ったと説明します。後継は、クラウドストレージを介してデータを準備し、処理を分散します。Pigmentは、200を超えるワーカーが割り当てられたままになる自動スケーリングの不具合に遭遇し、修正パッチを提供し、ワーカー終了と生成済みサブタスクの取り消しに独自処理を追加しました。これは、取り込んだオープンソースの名前を宣伝するだけを超えた技術開発であり、そうした依存関係が生む保守費用の具体例でもあります。(17)
Pythonサンドボックスには、もう一つ明示された費用があります。起動遅延を抑えるため、事前起動した予備ポッドを割り当てたままにします。記事は起動をおよそ一〜二秒とし、その代償として未使用能力への支払いを挙げています。この時間は実行開始までであり、サプライチェーン最適化全体の計算時間ではありません。(15)
顧客設定には別の費用が加わります。数式の依存関係、セキュリティルール、シナリオ定義、インポート、生成インターフェースのすべてに維持責任が必要です。またPredictionsは、計算した系列数に応じて年間契約の利用枠を消費し、結果を削除したり期限切れにしたりしても枠は戻りません。したがって、頻繁な再計算と実験には、計算やレビューの労力とは別に商業上の費用が伴います。(2, 9, 13)
Pigmentのセキュリティページは、複数ゾーンでの運用と、最大24時間のデータ損失を伴う六時間の試験済み災害復旧目標を明記しています。明示された復旧目標です。それでも、モデル損傷や誤ったインポートの後に計画チームが信頼できる判断を再開する速さは、アプリケーションレベルの復元と突き合わせによって決まります。(19, 20)
技術の歴史とロードマップの整合性
| 時期 | 公開された進展 | 評価 |
|---|---|---|
| 2020–2021年 | 2020年12月にシリーズA、2021年11月に7,300万ドルのシリーズBを実施しました。製品は表計算中心の共同計画を置き換えようとしていました。 | 初期の提案は、モデリングと共有事業データを中心にしていました。(21) |
| 2023年5月 | Pigment AIが会話型アクセスと迅速な事業分析を発表しました。 | 生成AIへの位置付けはChatGPT登場後であり、その後の提供実績で評価すべきです。(22) |
| 2024年10月 | 技術記事が、LangGraphの分析エージェント、ツール利用、人とのやり取り、試験の難しさを説明しました。 | 記事は、求められていない広範な事業最適化助言を、分析エージェントの担当範囲の不具合として扱いました。(23) |
| 2025年3月 | Analyst、Modeler、Plannerを、非公開試験中のロードマップとして発表しました。 | 三つの役割の発表は、三つの一般提供製品を意味しませんでした。(24) |
| 2025年9月 | 分散予測アーキテクチャと依存関係の問題を文書化しました。 | 具体的な実装作業と障害対応が見えます。(17) |
| 2026年3月–10月 | Modelerを提供し、封じ込めと代理操作の設計を公開し、モデル構築での利用状況を報告しました。 | 実際の提供が生産性という方向性を裏付けます。(9, 15, 16, 26) |
| 2026年10月–11月 | 2.5億ドルのシリーズEを発表しましたが、Plannerはまだロードマップ上にあります。 | 資金調達は、提供済みの業務意思決定能力に残る不足を埋めません。(25, 27) |
開発履歴には、提供済みの能力と、それらが生んだ技術問題の公開記録があります。未完成のPlannerは重要です。経済的に妥当な業務行動を推奨することこそ、このレビューに最も直接関わる能力だからです。(9, 15, 17, 25)
概念上の緊張は、人が計画を作り議論するのを助けるプラットフォームと、よりよい行動を継続的に計算するシステムの間にあります。Pigment自身の顧客事例は、認識の一致、シナリオの探索、より有効な計画会議を重視しています。最近の不確実性に関する指針は、単一数値の計画論より優れていますが、その指針と、検証された業務意思決定ルールをつなぐ技術的関係はまだ確立されていません。(5, 6, 8)
経済的な説明責任
Cheerzの在庫削減と、実名で報告された計画時間の短縮は、購入者が調べられる具体的成果です。しかし、プロセス頻度の変化、マスターデータの改善、コンサルタントの作業、新しく構築された計画モデルから、Pigmentの寄与を切り分けてはいません。数式に対する責任がアプリケーション作成者にあるため、その切り分けは特に重要です。(7, 8)
真剣な受け入れ試験は、合意した基準値と失敗修正の明確な責任のもと、導入した意思決定ロジックを実現結果に結び付けるべきです。ソフトウェアが正常に動き、入力が時間どおり届き、広く利用されていても、補充ルールが経済的に悪いことはあります。Pigmentの公開事例は、その場合の救済措置を定義せず、有害な業務提案を問題の再定式化と将来に向けた再試験まで追跡した例も示しません。ソフトウェア変更の制御は、この作業を支援しますが、経済評価そのものは提供しません。(8, 13, 19)
サプライチェーンスコア
サプライチェーンへの理解の深さ
| 評価項目 | スコア |
|---|---|
| 経済的な問題設定 | 5/10 |
| 最終的な意思決定出力 | 5/10 |
| サプライチェーンに関する概念の明確さ | 6/10 |
| 時代遅れの中心的教義からの自由度 | 4/10 |
| 見せかけのKPIへの耐性 | 6/10 |
平均：5.2/10。
経済的な問題設定 — 5/10。 財務量と業務量は一つのモデルを共有できます。不確実な供給と需要の経済的帰結全体を扱い、行動を順位付けする標準目的は実証されていません。(1, 5, 29)
最終的な意思決定出力 — 5/10。 顧客は購買や在庫のアプリケーションを作りますが、主要な出力は引き続き計画とシナリオです。専用のPlanner能力はまだロードマップ上にあります。(7, 25)
サプライチェーンに関する概念の明確さ — 6/10。 最近の指針は不確実な需要と供給を認めています。その不確実性を、経済価値をまとめて評価した業務選択へ変換する公開実装証拠は弱いままです。(4, 5)
時代遅れの中心的教義からの自由度 — 4/10。 合意計画、目標のすり合わせ、人による繰り返しのシナリオ確認が、顧客導入の中心に残ります。これらを速く実行しても、方法論上の限界は置き換わりません。(6, 8)
見せかけのKPIへの耐性 — 6/10。 予測ベンチマークは定義された誤差を使い、負けた結果も開示します。生産性の主張には特定できる作業範囲がありますが、エージェント生成の広い指標や推定代替案は、経済的純価値の証拠としては限定的です。(3, 7, 26)
意思決定と最適化の実質
| 評価項目 | スコア |
|---|---|
| 確率的モデリングの深さ | 5/10 |
| 独自性のある最適化・機械学習の実質 | 6/10 |
| 現実の制約への対応 | 5/10 |
| 意思決定の自動化と労働生産性 | 6/10 |
| 実際の業務複雑性に対する強靱さ | 5/10 |
平均：5.4/10。
確率的モデリングの深さ — 5/10。 予測区間と不確実性の明示的議論は、純粋な点予測より前進しています。同時較正や、需要・供給の意思決定への伝播は示されていません。(2, 5)
独自性のある最適化・機械学習の実質 — 6/10。 予測選択、計算モデリング、モデル構築エージェントには調べられる仕組みがあります。オープンソースモデルの統合と柔軟な数式だけでは、独自のサプライチェーン最適化を実証しません。(3, 9, 17, 29)
現実の制約への対応 — 5/10。 次元モデルや顧客作成の部品計算は、業務の細部を表せます。行動空間、制約、経済的近似の品質は、アプリケーションごとの設計に依存します。(7, 29)
意思決定の自動化と労働生産性 — 6/10。 作業削減とモデル構築の高速化には実質があります。検証や例外対応を含む、運用と改善の総労働量は測られていません。(7, 8, 26)
実際の業務複雑性に対する強靱さ — 5/10。 モデル検査、デプロイ、復元は修正を支えます。経済的失敗から意思決定問題の改訂と再試験へ至る循環の実証が不足しています。(9, 13, 19)
製品とアーキテクチャの整合性
| 評価項目 | スコア |
|---|---|
| アーキテクチャの一貫性 | 8/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真剣さ | 8/10 |
| ソフトウェアの簡潔さと保有・運用費用 | 4/10 |
| プログラムおよびエージェント支援による運用との適合性 | 8/10 |
平均：7.0/10。
アーキテクチャの一貫性 — 8/10。 計算、分析、モデル編集が、明示的な計画オブジェクトを共有します。新しいインターフェースと編集機能には、既存のデプロイライフサイクルに対する例外が残ります。(9, 10, 13)
システム境界の明確さ — 7/10。 文書は、モデル論理、生成インターフェース、外部ツール、実行サービスを区別しています。重要な制御のいくつかは、顧客設定や製品モードに依存します。(10, 11, 12, 15)
セキュリティへの真剣さ — 8/10。 公開された実行環境とAPIの制御は、具体的な脅威経路に対し、生成コードの外で境界を強制します。数式から導かれる権限とデプロイ例外には、重大な設定リスクが残ります。(13, 14, 15, 16)
ソフトウェアの簡潔さと保有・運用費用 — 4/10。 プラットフォームは多数の状態保持・オーケストレーション部品を維持します。文書化された能力と依存関係の問題は、その保守費用を具体化しますが、顧客単位の総保有費用は定量化されていません。(17, 18)
プログラムおよびエージェント支援による運用との適合性 — 8/10。 エージェントはモデルを調査・変更でき、生成コードには明確な実行境界があります。統制された本番変更と自律的な経済評価は、そこまで完成していません。(9, 12, 15, 28)
技術的透明性
| 評価項目 | スコア |
|---|---|
| 公開技術文書 | 8/10 |
| ベンダーの仲介なしでの検証可能性 | 6/10 |
| 移植性とロックインの可視性 | 5/10 |
| 導入方法の透明性 | 8/10 |
| 技術的主張を支える証拠の密度 | 7/10 |
平均：6.8/10。
公開技術文書 — 8/10。 詳細な製品・技術資料が、仕組み、限界、既知の障害経路を公開しています。それでも現在の本番挙動を、文書だけから独立して再現することはできません。(3, 13, 15, 17)
ベンダーの仲介なしでの検証可能性 — 6/10。 公開数式、インターフェース、ベンチマーク表により、意味のある技術検証が可能です。顧客成果や、ホストされた計算環境全体を再現するには、さらにアクセスが必要です。(3, 7, 12, 29)
移植性とロックインの可視性 — 5/10。 公開された連携・エージェントインターフェースはアクセス性を高めます。顧客アプリケーションは、Pigment固有の次元、数式、権限、ワークフローに依存し、その移行費用は確立されていません。(9, 12, 13, 29)
導入方法の透明性 — 8/10。 デプロイ、復旧、モデリング制御、実名の導入作業は詳しく記載されています。継続作業の全体と経済的受け入れ基準は、あまり見えません。(8, 9, 13, 19)
技術的主張を支える証拠の密度 — 7/10。 技術開示は、主張を具体的な実装や欠陥に結び付けています。サプライチェーン自動化と純経済便益については、プラットフォーム機構より評価証拠が薄い状況です。(7, 15, 17, 25)
ベンダーの真剣さ
| 評価項目 | スコア |
|---|---|
| 公開発信の技術的な真剣さ | 6/10 |
| 技術ロードマップの整合性 | 7/10 |
| 概念の明確さ | 6/10 |
| 経済的な説明責任 | 5/10 |
| エージェント型ソフトウェアの世界での競争力の持続性 | 7/10 |
平均：6.2/10。
公開発信の技術的な真剣さ — 6/10。 技術記事は、難しい開発課題と安全上の限界を認めています。AI生産性の広い表現は、提示された狭いベンチマークや導入範囲を時に超えます。(3, 15, 17, 26)
技術ロードマップの整合性 — 7/10。 共同モデリングから分析・モデル構築エージェントへの展開には、確認できる提供実績があります。Plannerがロードマップに残ることで、最も重要なサプライチェーンの約束が未完成のままです。(21, 22, 23, 24, 25)
概念の明確さ — 6/10。 Pigmentは、モデルの構築と維持が計画の生産性を制約することを認識しています。公開された運営モデルでは、合意予測と手動のシナリオ選択を経済的な意思決定ルールへ置き換える点が、まだ明確ではありません。(5, 6, 9)
経済的な説明責任 — 5/10。 実名事例は、具体的な便益と導入作業を報告します。顧客が構築する判断ロジックの検証責任や、低い収益に対する救済措置は、そこで解決されていません。(7, 8, 26)
エージェント型ソフトウェアの世界での競争力の持続性 — 7/10。 統制された計算環境とモデル変更ツールは、会話型アクセスだけより持続的な価値を提供します。残る課題は、アプリケーションを速く構築することで、より少ない総労力でよりよい反復的意思決定を生めると実証することです。(9, 13, 15, 28)
出典
[1] サプライチェーン計画（SCP）ソフトウェア | Pigment
サプライチェーン計画（SCP）ソフトウェア | Pigment。現行ページ、2026年11月4日閲覧。製品範囲と接続された計画。
機械学習による予測。2026-05-13、2026年11月4日閲覧。区間、予測ワークフロー、契約利用枠。
予測モデルを選択する。2026-05-05、現行本文、2026年11月4日閲覧。モデル選択と公開ベンチマーク表。
予測に外部要因を使う。現行ページ、2026年11月4日閲覧。要因選別、完全性の規則、影響係数。
[5] 需要と予測が不確実でも信頼できるサプライチェーン計画を維持する
需要と予測が不確実でも信頼できるサプライチェーン計画を維持する。2026-08-07、更新2026-09-03、2026年11月4日閲覧。需要範囲と供給の変動。
[6] ファッション小売企業がPigmentでサプライチェーンを変革した方法
ファッション小売企業がPigmentでサプライチェーンを変革した方法。日付なし、2026年11月4日閲覧。匿名導入、合意予測、シナリオ運用。
[7] CheerzがPigmentで在庫水準を30%削減した方法
CheerzがPigmentで在庫水準を30%削減した方法。日付なし、2026年11月4日閲覧。実名の在庫・業務量成果とアプリケーション構築。
[8] DanoneがPigmentで需要計画を変革した方法
DanoneがPigmentで需要計画を変革した方法。日付なし、2026年11月4日閲覧。実名の戦略計画導入と条件付きの時間削減。
Modeler Agentを実行する。2026-03-04、更新2026-10-19、2026年11月4日閲覧。運用モード、恒久的編集、権限、デプロイ制限。
Framesで体験を作成する。現行ページ、2026年11月4日閲覧。公開ワークフロー、書き込み確認、デプロイの限界。
MCPサーバー。2026-03-06、更新2026-11-02、2026年11月4日閲覧。認証、データアクセス、外部クライアント連携。
[12] Pigment Framesの構築：公開エージェント指示
Pigment Framesの構築：公開エージェント指示。現行ページ、2026年11月4日閲覧。生成JavaScriptとサンドボックス制限に関するベンダー作成の公開仕様。
[13] Pigment機能のTest & Deployを理解する
Pigment機能のTest & Deployを理解する。2026-03-05、更新2026-10-01、2026年11月4日閲覧。環境の挙動、本番の上書き、セキュリティルールのデプロイ。
[14] Security Folderを使い、信頼に依存しないモデリングとデータ保護を実現する
Security Folderを使い、信頼に依存しないモデリングとデータ保護を実現する。2025-08-22、2026年11月4日閲覧。文書化された数式経由の公開経路と対策。
[15] LLM生成コードの実行をサンドボックス化する | Pigment技術ブログ
LLM生成コードの実行をサンドボックス化する | Pigment技術ブログ。2026-06-10、2026年11月4日閲覧。脅威モデル、本番実行環境の分離、データセット転送、能力費用。
[16] 正しく設計した代理操作：トークン、読み取り専用保証、監査証跡 | Pigment技術ブログ
正しく設計した代理操作：トークン、読み取り専用保証、監査証跡 | Pigment技術ブログ。2026-04-08、2026年11月4日閲覧。APIでの強制とビルド時の網羅性確認。
[17] Daskで予測パイプラインを高速化した方法 | Pigment技術ブログ
Daskで予測パイプラインを高速化した方法 | Pigment技術ブログ。2025-09-02、2026年11月4日閲覧。分散予測アーキテクチャと依存関係の修正。
[18] Senior SRE — Pigmentの公開求人
Senior SRE — Pigmentの公開求人。現行情報、公開Lever APIから取得、2026年11月4日閲覧。公開Lever求人APIから取得した、明示的な本番スタック。
バックアップからブロックを復元する。更新2025-11-10、2026年11月4日閲覧。復元範囲、アクセス制限、突き合わせ。
[20] SOC2 Type 2認証のデータ安全性 | Pigment
SOC2 Type 2認証のデータ安全性 | Pigment。現行ページ、2026年11月4日閲覧。災害復旧目標とインフラ範囲。
[21] Pigmentが7,300万ドルのシリーズBを発表
Pigmentが7,300万ドルのシリーズBを発表。2021-11-15、2026年11月4日閲覧。当初の計画製品構想と初期資金調達の歴史。
[22] Pigment AIでより迅速かつ賢い事業分析を提供へ
Pigment AIでより迅速かつ賢い事業分析を提供へ。2023-05-03、2026年11月4日閲覧。最初の生成AI発表。
[23] Pigmentのデータ分析向けエージェント型AI | Pigment技術ブログ
Pigmentのデータ分析向けエージェント型AI | Pigment技術ブログ。2024-10-31、2026年11月4日閲覧。日付のあるエージェント実装と限界。
[24] AIエージェント：Pigmentが再び企業計画を変える方法
AIエージェント：Pigmentが再び企業計画を変える方法。2025-03-25、更新2026-09-03、2026年11月4日閲覧。三つのエージェントの発表と非公開試験の状況。
Pigmentの企業計画ロードマップ：次は何か。現行ページ、2026年11月4日閲覧。提供済み能力と未完了のロードマップ項目。
[26] 統一、構築、自動化：Pigmentのエージェント型計画の枠組み
統一、構築、自動化：Pigmentのエージェント型計画の枠組み。2026-10-08、2026年11月4日閲覧。モデル構築の利用報告とUnileverアプリケーションの例。
[27] Pigmentが評価額23億ドルで2.5億ドルを調達
Pigmentが評価額23億ドルで2.5億ドルを調達。2026-10-21、2026年11月4日閲覧。現在の資金調達発表。
ツールとスキルの変更履歴。2026-10-15、更新2026-11-03、2026年11月4日閲覧。外部エージェントツールの担当範囲に関する最近の変更。
[29] PREVIOUSOFによる複数ブロック間の反復計算
PREVIOUSOFによる複数ブロック間の反復計算。現行ページ、2026年11月4日閲覧。在庫の反復計算例と計算上の限界。