forecasting

需要予測

予測には2つの方法があります。適切な方法を選んでください。不要なサブエージェントを使うとターンを浪費し、必要なのに使わないと予測値が不正確になります。

方法 A — 自分で計算する（コード実行）

次の条件をすべて満たす場合に使います。

• 予測期間 ≤ 14 日
• 商品の is_seasonal フラグが 0
• 商品の promo_next_month フラグが 0
• タスクでプロモーション、祝日、またはトレンドの変化に言及していない

この場合、予測は単純な移動平均です。このスキルにはそのためのスクリプトが含まれています。

python .claude/skills/forecasting/rolling_mean.py SKU-0057 14

これだけです。Bash を 1 回呼び出すだけで済み、約 200 トークンで、サブエージェントも不要です。応用したい場合は、スクリプトを読んでください（約 20 行です）。

一括処理版： 多数の SKU の在庫日数を一度に調べる必要がある場合（例：毎日の在庫不足チェック）は、ツール呼び出しをループせず、一括処理スクリプトを実行してください。

python .claude/skills/forecasting/batch_days_of_cover.py 20

在庫日数の少ない順に並べた、最も緊急性の高い SKU 20 件を JSON で返します。これは、以前のエージェントが F1 で行っていた 100 回以上の get_stock_level／get_sales_velocity 呼び出しを置き換えるものです。

方法 B — 予測サブエージェントを起動する

次の条件のいずれかに当てはまる場合に使います。

• 予測期間 > 14 日
• is_seasonal が 1
• promo_next_month が 1、またはタスクでプロモーションに言及している
• 最近の売上に明らかなトレンドの変化がある

サブエージェントを使う理由： 予測担当には、季節性やプロモーションの影響を見つけるため、90 日分の履歴すべてがコンテキスト内に必要です。これは SKU の数によっては約 90 行 × SKU 数になります。これをあなたのコンテキストに読み込むと、タスクの残りに使える領域が圧迫されます。サブエージェントは独自のコンテキストウィンドウを使って分析を行い、小さな JSON を返します。

手順： forecaster 呼び出し可能エージェントに処理を委任します。SKU、商品フラグ、予測期間だけを送り、履歴データの行は送りません。予測担当は同じ /mnt/user/data/ に Bash でアクセスできるため、独自のコンテキスト内で全履歴を使って計算します（90 行をこちらではなく、そちらに置くことが目的です）。返される {forecast_qty, confidence, method, flags} JSON は、厳密に解析してください。JSON の形式が不正な場合はエラーであり、推測で補ってはいけません。

callable_agents が利用できない場合（研究プレビュー機能です）は、自分で移動平均をインライン計算し、confidence ≤ 0.55 に設定してください。これにより、再発注ポリシーのスキルが、検証できない数値に基づいて自動発注するのではなく、担当者によるレビューにエスカレーションします。

季節カレンダー（予測値の妥当性を確認する）

アウトドア用品には強い季節性があります。予測期間が季節の境目をまたぐ場合、移動平均は季節の変化に追従できないため、方法 B を優先し、季節について言及してください。

期間	需要が伸びるカテゴリー	ベースラインとの比較
3 月～5 月	フットウェア、パック、レインシェル、トレッキングポール	1.3～1.6 倍
6 月～8 月	テント、寝具、ストーブ、浄水器	1.5～2.0 倍（需要のピークとなる四半期）
9 月～10 月	防寒ウェア、光学機器、ヘッドランプ	需要が伸びる。テント／フットウェアは減少
11 月～12 月	ギフト向け価格帯。プロモーションが最も盛ん	プロモーションのフラグを確認
1 月～2 月	需要が落ち着き、年間で最も少ない時期	棚卸しに適した時期

プロモーションへの対応

プロモーションは、発注不足の最もよくある原因です。promo_next_month=1 の場合、またはタスクでプロモーションに言及している場合：

• 移動平均だけに頼ってはいけません。これはプロモーション前の需要を示します。
• 過去の類似事例（同じ SKU で、過去 12 か月以内に実施された同程度のプロモーション）を探し、その需要増加率を使います。該当する事例がない場合、サブエージェントは flags: ["promo_uplift_uncertain"] を設定し、信頼度を 0.6 を大きく下回る値にしてください。
• 需要増加が不確かな場合は、自動発注よりもレビュー対象としてフラグを付けることを優先します。プロモーション時の過剰発注は挽回できますが、発注不足は注目が集まる時期の欠品につながります。
• プロモーションの終了日が分かっている場合は、終了後の需要減少も考慮してください。終了翌週に販売チャネルの在庫が過剰にならないようにします。

避けるべき失敗： 説明文で需要の増加を述べながら（「約 3 倍になる可能性があります」）、返す forecast_qty は増加分を反映していないベースラインの平均値のままにすることです。説明だけでなく、数値に反映してください。

結果の活用方法

{forecast_qty, confidence, flags} を再発注ポリシースキルに渡します。特に、confidence < 0.6 の場合、再発注ポリシーではエスカレーションすることになっており、自動発注はしません。 confidence や flags を省かないでください。これらは契約の一部です。

実例（Path B）

タスク：「来月のプロモーションに向けて SKU-0091 を再発注する。」→ promo_next_month=1、horizon=30 → Path B。

サブエージェントの返却値：{"forecast_qty": 2100, "confidence": 0.41, "method": "baseline_mean_no_comparable_promo", "flags": ["promo_uplift_uncertain"]}

confidence 0.41 < 0.6 → 再発注ポリシーに従い、PO は作成しません。 flags を添えて notify-templates 経由でエスカレーションし、ベースラインとして約2,100を推奨します。さらに、プロモーションによる増加が2～3倍になる可能性があり、人による判断が必要であることを記載します。