一般的な問題と解決策

最も一般的な原因は複合キーの衝突です。2 つのレコードが同じ一意の識別子を共有している場合、一方はもう一方のレコードを上書きします。

データマッピングのフィルター条件が、表示される予定のレコードを除外する場合にも発生する可能性があります。

レポート実行の間に受理または削除された注文は、次の更新から消えますが、前日のデータから生成された例外に表示される場合があります。

新しく作成された注文は、次のデータ更新まで表示されません。

システムは製品マスターに自動的にフィルタリングされます。製品マスターファイルに存在する製品のみが予測に含まれます。ただし、入力ファイルの大部分が範囲外の場合 (行の 50% 以上など）、これはソースエクスポートを厳しくする必要があることを示します。

製品カバレッジレートを定期的に確認します。各データロードの後、売上および予測入力ファイル内の製品の割合が製品マスターと一致することを確認します。カバレッジが 80% を下回る場合は、ソースエクスポートの範囲が変更されているか、製品マスターを更新する必要があるかを調べます。

プラン入力の対象Out-of-scopeの製品は、合計が肥大化する可能性があります。EDI または SIOP ファイルに他の植物の製品が含まれている場合、総予測シグナルは必要以上に高くなります。ロードする前に、プラン入力ファイルが製品マスターと同じ製品スコープにフィルタリングされていることを確認します。

例外のタイムスタンプを確認します。1 日以上経過している場合、レコメンデーションは古くなる可能性があります。

レコメンデーションが明らかに間違っている場合 (例: はグラフに表示される大きな順序を無視する）、親指を下げてフィードバックを提供し、特定の例外をサポートチームに報告します。

影響日には、インベントリの問題がいつ始まるか (例: 在庫切れがいつ始まるか、または超過がしきい値を超えたか) が表示されます。

「Act By」の日付はリードタイムを考慮して、問題がマテリアライズされる前に行動する時間を確保する必要があります。Act By が影響日と等しい場合、リードタイムは組み込まれない可能性があります。これをサポートチームに報告してください。

範囲内の少量/非アクティブな製品が多すぎます。疎で断続的な需要を持つ製品は、どのモデルでも単純な平均を上回るのは困難です。事前処理ルールを使用して、需要履歴が意味のある製品 (需要が 6 か月以上ゼロでない製品など) に予測を絞り込みます。

古い履歴や汚染された履歴に関するトレーニング。注文履歴が何年もさかのぼる場合、古い需要パターンは現在の現実を反映していない可能性があります。トレーニング履歴を最新の 3～5 年に制限したり、異常な期間 (例: COVID) を正規化された値に置き換えたりするには、前処理ルールを検討してください。

1 回限りの注文からの需要の急増。1 つの大きな一括注文では、トレーニングデータに誤った増加傾向が生じる可能性があります。前処理ルールを使用して、異常な毎月の需要値を末尾の平均の倍数 (例: 5 倍) で制限します。

コンセンサスルールが間違った方向に適用されます。LLM エージェントはルール言語を誤って解釈する可能性があります。「27% の減少」は、引き上げとして適用される場合があります。特定の製品と月を比較して、ベースラインに対するコンセンサス出力を常に検証します。方向言語 (「27.5% 減少」) ではなく、明示的な乗算言語 (「0.725 を掛ける」) を使用します。

モデルは成長期間にトレーニングされます。最近の成長が継続していない場合、モデルは存在しなくなった傾向を推定します。

コンセンサスルールは上方調整を重ねています。予測を引き上げる複数のルール (在庫切れバイアス、トレンドブースト、季節的な引き上げ) が混在する可能性があります。アクティブなルールを確認し、それらがすべて同じ製品に適用されているかどうかを確認します。

対象範囲内の製品を削除/中止しました。需要が減少するが、まだ予測中である製品には、体系的な過剰予測が表示されます。

外部予測シグナルが組み込まれていません。計画入力 (EDI 顧客予測、SIOP 生産計画など) がロードされているが、コンセンサスルールが適用されていない場合、予測はデフォルトで統計ベースラインになります。これは、プランナーが表示する需要シグナルをキャプチャしない可能性があります。ConsensusForecast エクスポートと Forecast (ベースライン) エクスポートを比較して、コンセンサスルールが出力を実際に変更していることを確認します。同じ場合、ルールは発射されません。

アグリゲートをプルダウンするスパース製品とサイトの組み合わせ。productxsite 粒度で予測しても、多くの組み合わせの需要がゼロまたはほぼゼロである場合、モデルは非アクティブな組み合わせに対してゼロ以外の小さな予測を生成します。これらは個々に加算されるのではなく、合計予測を実際の値より下にドラッグします。前処理ルールを使用して需要履歴が不十分な組み合わせを除外するか、プラン入力で条件付きゼロフィルを使用して非アクティブな組み合わせの「予想需要なし」を明示的に通知します。

モデルは最近の成長傾向を把握していません。統計モデルは履歴データを重み付けします。ここ数か月でビジネスが大きく成長したが、モデルに数年にわたる少量の履歴がある場合、トレンドは遅れます。これは通常、モデルがより新しいデータを蓄積するため、時間の経過とともに改善されます。その間、最近の実績の過去平均を外部予測週の下限として使用するコンセンサスルールを検討してください。

Year-over-year季節性の不一致。今年の需要パターンが過去数年と異なる場合 (例: 早期の季節的な増加、新製品の発売）、モデルは異なる期間に過小予測される可能性があります。バイアス不足が、前年のパターンとは異なる特定の週または月に集中しているかどうかを確認します。

外部シグナルは短期的にのみ役立ちます。最初の数週間に顧客予測 (EDI) を組み込むコンセンサスルールがある場合、精度は短期的に大幅に向上し、ルールの適用が停止すると低下します。これは予想されます - ブレンドアプローチ (例: 外部シグナルとベースラインの 50/50 のブレンドを中期的な週) でより多くの週をカバーするようにルールを拡張することを検討してください。

ベースラインは、より長い期間で長期平均に戻ります。統計モデルは、より長い期間では自信がなくなり、履歴平均に向かう傾向があります。最近の需要が過去の平均を上回っている場合、外部週は偏りが少なくなります。これはモデルの動作であり、設定の問題ではありません。

需要の変動性により、地平線が長くなります。需要がweek-to-week性が高い場合 (変動係数 > 0.5)、完全なモデルでも、より長い期間に高いエラーが表示されます。精度評価は、最初の 3～4 週間に集中します。これは、ほとんどのオペレーションで実行可能な計画期間です。

外部シグナルが十分な製品をカバーしていない可能性があります。EDI または顧客予測は通常、製品カタログのサブセット (多くの場合 30～50%) のみを対象とします。外部シグナルのない製品は、引き続きベースラインを使用します。カバレッジレートを確認します。50% 未満の場合、集計精度への影響は制限されます。

外部信号が十分に正確ではない可能性があります。ルールで使用する前に、外部予測の精度を個別に測定します。WAPE がベースラインよりも悪い場合、WAPE を組み込むと、役に立ちません。外部シグナルが明らかに優れている特定のサイトまたは製品 (ボリューム加重 WAPE が 50% 未満など) にルールを制限することを検討してください。

外部シグナルはゼロを報告しません。多くの EDI システムは、アクティブな注文を持つ製品のレコードのみを送信します。明示的にゼロを報告するのではなく、需要がゼロの製品を除外します。コンセンサスルールに「EDI = 0 の場合、予測を 0 に設定する」と書かれている場合、ゼロレコードがないため、発生しません。外部シグナルがなく、最近の販売履歴がない製品とサイトの組み合わせについては、前処理で合成ゼロレコードを生成する必要があります。

外部信号の精度は地平線によって異なります。通常、顧客予測は翌週に最も正確で (基本的に確認された注文）、急速に低下します。外部シグナルを数週間にわたって直接使用するルールは、より長い期間の精度を損なう可能性があります。階層型アプローチを検討してください。1～3 週間は直接置き換え、4～6 週間はブレンド、7 週間以上はベースラインのみ。

ルールが優先度の高いルールによって上書きされている可能性があります。ルールは優先順位で適用されます。後のルールでは、以前のルールを元に戻すことができます。ルールの順序を確認します。

ルール条件はどの製品とも一致しない場合があります。ルールが項目メタデータにない製品属性 (product_group_id など) を参照している場合、ルールは何も一致しません。

ルール言語が誤って解釈されました。LLM エージェントは自然言語からコードを生成します。あいまいなフレーズを使用すると、予期しない結果が生じる可能性があります。できるだけ具体的かつリテラルにしてください。正確なフィールド名、明示的な乗数、クリア条件を使用します。

結合のディメンションが一致しません。コンセンサスエンジンは、ディメンション列 (製品 ID、サイト ID、日付) のベースラインにプラン入力を結合します。列名がベースラインと計画入力で異なる場合 (たとえば、ベースラインは item_id を使用し、EDI は product_id を使用する）、結合は一致せず、すべてのルールがベースラインのデフォルトにフォールスルーされます。データフロー設定のディメンションマッピングが 2 つのスキーマ間で正しくマッピングされていることを確認します。

日付形式が一致しません。ベースラインには日付が 2026-03-02 として保存され、計画入力には 2026-03-02T00:00:00.000Z として保存される場合があります。結合に完全一致が必要な場合、タイムゾーン対応の日付とタイムゾーンナイーブの日付は一致しません。結合する前に、日付列が同じ形式に変換されていることを確認します。

プラン入力がロードされていません。プラン入力ファイル (EDI、SIOP など) が正常に取り込まれたことを確認します。システム内のレコード数を確認します。プラン入力の行がゼロの場合、ファイルのロードに失敗した可能性があります。

コンセンサス forecast_id はベースライン forecast_id と一致します。両方のエクスポートが同じ forecast_id を共有する場合、コンセンサスエンジンは処理せずにベースラインの直接コピーを生成しました。これはシステムレベルの問題を示します。forecast_id と demand_plan_run_id のサポートチームにお問い合わせください。

サイト/製品フィルター条件が間違った列を参照している可能性があります。ルールに「[list] のサイトに適用」と表示されているが、生成されたコードが、存在しない列や異なる値を持つ列をチェックする場合、フィルターはすべての行をサイレントに渡すことがあります。ルールの影響を受けない特定の製品をスポットチェックして検証します。

ルールの優先順位は逆になる場合があります。ルールは、後のルールが以前のルールを上書きするチェーンとして適用されます。広範なルール (例: すべてにベースラインを使用) が特定のルール (例: これら 50 のサイトに EDI を使用) の後に適用される場合、広範なルールは特定のルールを元に戻します。ルールの説明に優先順位が明確に記述されていることを確認します。

最終的なコンセンサスステップとして四捨五入ルールを追加します。他のすべてのコンセンサスルールの後に適用される単純な「最も近い整数に丸める」ルールは、小数値をクリーンアップします。0.5 未満の値はゼロに丸められ、非常に需要の少ない組み合わせに適しています。

運用数量への四捨五入を検討してください。製品が標準パックサイズ (例: 12 ケース、パレット 48) で出荷されている場合、最も近い有効なパックサイズに丸めると、予測のユーザビリティと精度の両方が向上する可能性があります。これには、製品マスターのパックサイズデータが必要です。MOQ またはパックサイズのデータをサポートチームと共有して、このオプションを確認します。

粒度を確認します。製品レベルでは 52 週間の需要があり、個々の製品とサイトの組み合わせでは 3 週間しか需要がない場合があります。productxsite レベルで適用される最小履歴しきい値は、ほとんどの組み合わせを除外します。代わりに、しきい値を製品レベルで適用するか、しきい値を大幅に下げることを検討してください。

デプロイする前にテストします。前処理ルールをアクティブ化する前に、フィルターに合格した製品とサイトの組み合わせの数と現在の合計をカウントします。20% 以上を除外すると、ルールが過度に攻撃的になる可能性があります。寛容なしきい値から始めて、徐々に絞り込みます。