受注残と商談の進み具合から、今月と来月の売上の着地を見込む

処理の起点を決める

月末の夜に1回、月初の第2営業日に1回動かします。 月末の夜は、その月の最後の状態を保管するためです。翌朝になると営業が完了予定日を更新し始め、月末時点の見込みが残りません。 この保管が、翌月以降の「見込み日のずれ」の材料になります。

月初の第2営業日の実行は、前月の売上実績が締まった後の再計算です。営業部門のExcelが届くのはこの後なので、機械の見込みのほうが先にそろいます。

入力データを集める

質を決めるのは、下から2つ目のスナップショットです。 商談管理に残っているのは「今の状態」だけで、先月末にその商談がどの段階にあり、完了予定日がいつだったかは、上書きされて消えています。 段階ごとの受注率も見込み日のずれも、過去の月末時点の状態と、その後の結果を突き合わせて初めて数えられます。

まだ保管していなければ、今月から始めてください。 段階の変更履歴が残っていれば、過去の月末時点の状態を組み立て直せます。無ければ半年ほど保管をためる間、受注率だけを使います。

営業部門の見込みには、商談IDの列を足してもらいます。 金額だけのExcelでは、どの案件が機械と営業で扱いが違うのかを突き合わせられません。

データの取得方法を決める

CSVは pandas.read_csv で読み込みます。公式の説明では、encoding で読み込みの文字コード（例として 'utf-8'）を、dtype で列ごとの型を指定できます。商談IDや受注番号は、dtype で文字列として読みます。 数値として読むと、先頭の0が消えて突き合わせに失敗します。

日付の列は、読み込んだ後に確かめます。 parse_dates で日付として読む列を指定できますが、解釈できない値や時差の混在があると、その列は変換されずに文字列のまま返ると説明されています。エラーにならずに型だけが違う状態で進むので、読み込み直後に型を確かめ、日付でなければ止めます。

いちばん下の行を忘れがちです。 保守や部品の売上は、商談管理に載らないまま立ちます。入れないと、機械の見込みは毎月同じ額だけ低く出ます。 過去の同じ月と直近3か月の実績から、製品群ごとに別枠で置きます。

AIへ渡す前に整形する

1. 型と件数の確認 … 日付・金額・IDの型を確かめ、前月と比べて件数が大きく変わっていないかを見ます
2. 重複の除去 … 同じ商談IDの行が複数あれば、最終更新日が新しいほうを残します
3. 受注残と商談の重なりの除去 … 受注済みで受注残に移った商談は、見込み分から外します。二重に数えると着地が膨らみます
4. 完了予定日が過去の商談の扱い … 月末時点で完了予定日を過ぎたまま未完了の商談は、「放置」として別に数えます
5. 段階の名前のそろえ … 事業部ごとに段階の名前が違えば、対応表で共通の段階に置き換えます
6. 通貨の換算 … 外貨建ての商談と受注残は、社内の換算レートで円にします。レートは計算結果と一緒に残します

集計は3つの数字だけです。 次のように、事業部と段階ごとに過去の月末時点の商談を分けて数えます。

# 過去24か月の月末スナップショット（未完了だった商談）と、その後の結果を結合したもの
hist = snap.merge(outcome, on="opp_id", how="left")

# ① 段階ごとの受注率：その段階にあった商談のうち、後で受注したものの割合
win = hist.groupby(["division", "stage"], dropna=False).agg(
    n=("opp_id", "size"), won=("is_won", "sum"))
win["rate"] = win["won"] / win["n"]

# ② 見込み日のずれ：受注した商談の「受注日 − その月末時点の完了予定日」（日数）
hist["slip_days"] = (hist["won_date"] - hist["close_date_at_snap"]).dt.days

# ③ 受注から計上までの日数：製品群ごと
lag = sales.groupby("product_group")["lag_days"]

件数が少ないグループは、全社の同じ段階の値に置き換えます。 件数が30件に満たない組み合わせでは、1件の受注で受注率が大きく動きます。置き換えたことは fallback の印で結果に残します。

着地のレンジは、くり返し計算で出します。 未完了の商談ごとに、受注するかを受注率で、いつ受注するかを見込み日のずれの過去の分布から、いつ計上されるかを受注から計上までの日数の分布から、それぞれ抽選します。これを2,000回くり返し、月ごとに合計した2,000通りの着地から、quantile で下側10％点・中央値・上側90％点を取ります。 確定分と商談に載らない売上は、その上に足します。

前月の見込みとの差は、案件ごとに分解します。 前月末と今月末のスナップショットを商談IDで突き合わせ、案件ごとの期待値（金額に受注率と月内に計上される確率をかけたもの）の変化を、「新規」「段階が進んだ」「段階が戻った」「完了予定日が延びた」「金額が変わった」「受注」「失注」の7つに振り分けます。説明文の材料は、この表だけです。

AIに処理させる

させるのは、計算済みの数字を読んで、差の説明文と、会議で聞く案件への質問文を書くことだけです。

3行目がいちばん起きやすい失敗です。 完了予定日が延びた案件について、何も言わなければ「顧客側の予算承認が遅れたため」のような、もっともらしい理由を書きます。入力には理由が無いので、それは作文です。 経営会議でその一文が事実として扱われると、事業部は存在しない理由に答えることになります。

指示内容を固定する

あなたは経営企画部で、月次の売上着地見込みの資料を作る立場です。
渡すのは、統計の計算で出した見込みと、その内訳です。
数字はすべて計算済みです。あなたは説明文と質問文だけを書いてください。

【書くもの】
1. change_summary：前月の見込みから今回の見込みへの変化の説明（3〜5文）
   - 内訳表の寄与の絶対値が大きい順に、3件までの案件を取り上げる
   - 各案件について、案件ID、区分、寄与額を書く
2. gap_summary：営業部門の見込みと機械の見込みの差の説明（2〜4文）
   - 営業部門が今月に入れ、機械の月内確率が低い案件を、案件IDで挙げる
3. questions：聞く案件ごとの質問文（1案件につき1問）
   - はい・いいえ、または日付で答えられる形にする
   - 例：「案件A-1024の検収は今月中に完了する予定ですか」
4. firmness_note：確定分の割合が0.5未満の場合だけ、数字の固さについて1文

【厳守事項】
- 数字は、入力にある値だけをそのまま使ってください。
  足し算・引き算・割合の計算をして新しい数字を作らないでください。
- 金額は入力と同じ単位（百万円）で、同じ桁で書いてください。丸めないでください。
- 案件が動いた理由を推測しないでください。入力の reason 欄が空なら、
  理由は書かず、questions で事業部に聞いてください。
- 営業部門の見込みを「甘い」「楽観的」などと評価しないでください。
  差があるという事実と、その差を生んでいる案件だけを書いてください。
- 担当者の名前、顧客の名前を書かないでください。案件IDだけを使ってください。
- 「受注できる」「失注する」と断定しないでください。確率は入力の値のまま示してください。
- fallback が true の段階を使っている案件は、「過去の件数が少ないため全社の値で計算」と添えてください。
- 入力に無い案件を取り上げないでください。

【対象】{division} ／ {product_group} ／ 対象月 {target_month}
【今回の見込み】{forecast}
【前月時点の見込み】{prev_forecast}
【差の内訳表】{bridge}
【営業部門の見込み】{sales_forecast}
【規則で選ばれた聞く案件】{ask_list}

「計算をして新しい数字を作らない」を明記しないと、差額を自分で計算して書きます。 計算が合っていても、入力に無い数字は後段の照合で見分けられません。照合できる状態を保つために、使ってよい数字を入力の値に限ります。

出力形式を固定する

次の形のJSONで受け取ります。 数字の欄は Python が埋め、文章の欄だけを Claude API が埋めます。

{
  "division": "搬送機器事業部",
  "product_group": "コンベヤ",
  "target_month": "2026-10",
  "forecast": {
    "committed": 182.4,
    "pipeline_p10": 21.0,
    "pipeline_p50": 48.6,
    "pipeline_p90": 77.3,
    "non_pipeline": 35.2,
    "landing_p10": 238.6,
    "landing_p50": 266.2,
    "landing_p90": 294.9
  },
  "prev_landing_p50": 291.5,
  "sales_forecast": 305.0,
  "bridge": [
    { "opp_id": "A-1024", "category": "close_date_pushed", "impact": -18.2,
      "win_rate": 0.62, "in_month_prob": 0.35, "fallback": false, "reason": "" }
  ],
  "ask_list": ["A-1024", "A-0987"],
  "text": {
    "change_summary": "",
    "gap_summary": "",
    "questions": [ { "opp_id": "A-1024", "question": "" } ],
    "firmness_note": ""
  }
}

1つ目の理由は、数字と文章を別の層に置けることです。 Claude API に渡すスキーマは text の部分だけです。 公式の説明では、構造化出力のスキーマはオブジェクトの additionalProperties を false にする必要があり、数値の範囲や文字列の長さの制約は対応していません。文の数や長さの上限は、スキーマではなく受け取った後の Python の検査で見ます。

2つ目は、表のいちばん下の行の照合ができることです。 説明文から数字と案件IDを正規表現で抜き出し、forecast と bridge の値と1つずつ突き合わせます。1つでも見つからない数字があれば、その組み合わせの説明文は差し戻して書き直させます。

システムへ連携する

商談管理にも販売管理にも書き込みません。 機械の見込みを商談の確度の欄に書き戻すと、営業が入れた確度と区別がつかなくなります。営業の見込みと機械の見込みは、別々に残すから比べられます。

人が確認する

経営企画が開くのは、差の大きい組み合わせだけです。 40の組み合わせのうち、次のどれかに当たるものを先頭に並べます。

1. 営業部門の見込みが、機械の見込みの下側10％点から上側90％点の外にある … 差の理由を会議で確かめます
2. 前月の見込みからの差が大きい … 内訳表の上位の案件を見ます
3. 確定分の割合が小さい … 数字が商談しだいで、幅も広い組み合わせです
4. fallback の案件が見込みの多くを占める … 過去の件数が足りず、全社の値で代用しています

残りの組み合わせは、表で数字を流し見て終わりにします。 全部を開く設計にすると、第10章の14.0時間には収まりません。

説明文で確かめるのは、推測が入っていないかです。 数字の照合は機械が済ませていますが、「顧客の事情により」のような理由の作文は、数字の照合では捕まりません。入力の reason が空の案件について、理由らしい言葉が書かれていれば消します。

例外に対処する

4行目の大口案件を、確率で割り引いて混ぜないでください。 1件の受注で着地が大きく動く組み合わせでは、期待値はどちらの結果にも当たらない数字になります。「受注すればこの額、しなければこの額」と2つ示すほうが、会議での判断に使えます。

記録を残す

• 月末ごとの商談スナップショットと、受注残・売上実績の書き出しの原本
• 集計に使った期間、件数の下限、段階の対応表、換算レート、くり返し計算の回数と乱数の種
• 組み合わせごとの forecast と bridge、ask_list を選んだ条件
• Claude API に渡した入力と、返ってきた text、照合の結果
• 経営企画が説明文を直した記録 … どの文を、どう直したか
• 月が締まった後の実績と、各時点の見込みの差 … 機械と営業の両方について

2つ目で乱数の種まで残すのは、同じ数字を再現するためです。 種が無いと、会議の後に「あのときの見込み」を出し直せません。

最後の行が、この構成を直していく材料です。 実績が締まるたびに、機械の見込みの中央値が実績からどれだけ外れ、実績が下側10％点から上側90％点の幅に入ったかを数えます。幅に入る月が少なければ、受注率か見込み日のずれの集計期間が合っていません。