店舗の日次売上から月の途中で月末の着地を店舗ごとに見込み、予算との差と理由の候補を経営企画に出す

処理の起点を決める

時間主導型のトリガーを毎朝7時台に1つ置きます。 POSの夜間の出力が終わったあとに動くよう、出力の終わる時刻を確かめて決めます。時間主導型のトリガーは、指定した時間帯の中で動く時刻が少しずれます。

毎朝やるのは、CSVの取り込みだけです。 見込みの計算と Gemini API の呼び出しは、10日・15日・20日・25日の朝だけ行います。その4日が土日に当たる場合も、曜日にかかわらず同じ日に動かします。 地区の責任者が週明けに一覧を見る運用でも、計算の時点はそろえておきます。

見込みを出す日は、処理を3つに分けます。 7時台に取り込み、7時半からの実行で75店舗の見込みと幅を計算し、8時からの実行で幅の外の店舗について Gemini API を呼びます。どこまで終わったかをスクリプト プロパティに残し、6分を超えそうなら次の実行で続きから始めます。

CSVが届いていない朝は、見込みを出しません。 前日分が欠けたまま計算すると、累計が1日分少なくなり、全店舗が予算に届かない側に振れます。 届いていなければ、Chat に「CSV未着」とだけ知らせて止まります。

入力データを集める

AIに渡すのは、幅の外の店舗の数字と、販促の予定と、店舗メモだけです。 生の日次の実績をすべて渡すことはしません。スクリプトが前年比や構成比に計算し直したものを渡します。

店舗メモが、理由の候補の質を決めます。 「15日から近くにドラッグストアが開店」と書いてあれば、AIは日用品の前年比の落ち込みと結び付けられます。メモが無ければ、AIは数字の動きしか言えません。 メモに無い外の事情を、AIに推測させることはしません。

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

POSのCSVは、共有ドライブのフォルダから読みます。フォルダの中のファイルを一覧にし、未処理のものを開いて中身を文字列として取り出します。POSの仕組みが出すCSVの文字コードがUTF-8でない場合は、文字コードを指定して取り出します。 Blob から文字列を取り出すときに文字コードを指定できます。取り出した文字列は、CSVを2次元の配列にする関数（Utilities.parseCsv）で表の形にします。

前年の日は「364日前」で取ります。 364日はちょうど52週なので、曜日が必ずそろいます。 前年の同じ日付で取ると曜日がずれ、土日の数の違いがそのまま見込みの誤差になります。

取り込んだCSVは、処理済みのフォルダへ移します。 移すのは蓄積のシートへの書き込みが終わったときだけにします。フォルダに残っているファイルの数が、そのまま未処理の数になります。

AIへ渡す前に整形する

1. 取り込みの確認 … 前日分が全75店舗そろっているかを数えます。欠けた店舗は「未着」とし、その店舗の見込みは出しません
2. 異常値の確認 … 売上が0の日、前年比が10倍を超える日に印を付けます。休業日か、POSの不具合かを店舗メモで確かめます
3. 着地の見込みの計算 … 今月の実績の累計に、残りの日ごとの「364日前の売上 × 補正率」を足します。補正率は、直近14日の実績を、その364日前の14日の実績で割ったものです
4. 販促のずれの調整 … 前年の364日前がチラシの日で、今年の同じ日がチラシでない場合（またはその逆）は、前年の通常の同じ曜日の平均で置き換えます
5. 新店・改装店の扱い … 前年の実績が無い店舗は、直近4週の同じ曜日の平均で見込みます。この店舗には「前年なし」の印を付けます
6. 見込みの幅の計算 … 過去12か月の同じ日付の時点での、見込みと実際の着地のずれの率を店舗ごとに並べ、その中央値と最大を幅にします
7. 店舗の区分け … 予算が幅の下限より上なら「幅の外で下」、幅の中なら「幅の中」、上限より下なら「幅の外で上」とします
8. AIへ渡す数字の計算 … 幅の外の店舗について、客数・客単価・部門別売上の前年比と、月の前半と後半の前年比の違いを計算します

3番目から7番目は、すべてスクリプトの式です。 この記事が「予測」と呼んでいるのは、この式で出す着地と幅のことです。式は単純ですが、毎回同じ答えが出ること、過去のずれで確かさを示せることが、担当者の手計算との違いです。

6番目の幅は、運用を始めてから育ちます。 最初の月は過去の見込みの記録が無いため、過去12か月の実績から「その時点で同じ式を使っていたら」の見込みを計算し直して作ります。 蓄積のシートに前年分があれば、さかのぼって計算できます。

AIに処理させる

させるのは、幅の外の店舗について、予算との差の理由の候補を数字の根拠付きで並べ、店長に確かめる点を書くことです。

理由の候補には、必ず根拠にした数字の項目名を付けさせます。 「日用品の前年比が15日以降 82％に落ちた（部門別前年比・後半）」のように、入力のどの数字から言っているかを1つずつ書かせます。 根拠の無い候補は、スクリプトの側で一覧から外します。

2行目がいちばん起きやすい失敗です。 客数が落ちている店舗について、AIは「天候不順の影響と考えられる」と書きがちです。入力に天候の情報が無い以上、それは確かめようのない推測で、一覧に並ぶと事実のように読まれます。 店舗メモに無い外の事情は、「確かめる点」の側に質問として書かせます。

指示内容を固定する

あなたは小売チェーンの経営企画部で、月の途中の店舗の売上を分析する立場です。
着地の見込みと幅は、すでに決まった式で計算されています。
あなたの役割は、予算との差について、理由の候補と、店長に確かめる点を出すことです。

【入力（店舗ごと）】
- 着地の見込み、見込みの幅、予算、予算との差、区分（幅の外で下／上）
- 客数・客単価の前年比（月の累計、前半、後半）
- 部門別売上の前年比と構成比（月の累計、前半、後半）
- この店舗と地区の販促の予定（今年と前年）
- 店舗メモ（休業、営業時間の変更、近くの出店など）

【してほしいこと】
1. 差が客数と客単価のどちらから来ていそうかを書いてください。
2. 差に効いている部門を、最大3つ挙げてください。
3. 理由の候補を最大3つ、根拠にした入力の項目名と数字を付けて書いてください。
4. 店長に確かめる点を2〜3個、質問の形で書いてください。

【厳守事項】
- 着地の見込み、幅、予算、差の金額を計算し直したり、修正したりしないでください。
- 入力に無い事情（天候、景気、競合の動き、地域の行事など）を、
  理由の候補として書かないでください。必要なら「確かめる点」に質問として書いてください。
- 理由の候補には、必ず evidence に入力の項目名と数字を書いてください。
  evidence を書けない候補は出さないでください。
- 店舗メモに書かれた事情を使うときは、source を "store_memo" にしてください。
- 予算を変えるべきか、店長の対応が良いか悪いかを書かないでください。
- 打ち手を決めないでください。
- 数字の動きが小さく、理由を絞れないときは "no_clear_driver" を true にしてください。

【店舗ごとの入力】{stores}

「入力に無い事情を書かない」と「確かめる点に質問として書く」を対にしているのが要点です。 禁じるだけだと、AIは天候の話を言い換えて別の欄に入れてきます。出口を用意すると、推測は質問の形に落ち着きます。 店長が「その週は大雨でした」と答えれば、それが確かめられた理由になります。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力を使い、response_format に mime_type を application/json、schema に下の形のスキーマを入れて渡します。

{
  "store_code": "S041",
  "driver_split": "customers | basket | both | unclear",
  "key_departments": ["日用品", "一般食品"],
  "reason_candidates": [
    {
      "text": "",
      "evidence": [{ "field": "dept_yoy_second_half.日用品", "value": "0.82" }],
      "source": "numbers | store_memo | promo_calendar"
    }
  ],
  "questions_for_store": ["", ""],
  "no_clear_driver": false
}

1つ目の理由は、evidence をスクリプトで照合できることです。 field に書かれた項目名が入力に本当にあり、value が入力の数字と一致するかをスクリプトが確かめます。一致しない候補は一覧から外し、「根拠不一致」として記録します。 構造化出力は JSON の形を守りますが、値の正しさはアプリケーションで確かめるよう、公式の説明にもあります。

2つ目は、source で理由の出どころを分けられることです。 数字の動きだけから言っている候補と、店舗メモや販促の予定に基づく候補では、地区の責任者が受け取る重さが違います。 一覧では source ごとに印を変えます。

3つ目は、no_clear_driver で「分からない」を正式な答えにできることです。 幅の外でも、客数・客単価・部門のどれも小さく動いているだけの店舗があります。無理に理由を作らせず、「はっきりした要因なし」と一覧に出し、店長への質問だけを残します。

システムへ連携する

UrlFetchApp.fetch() は、method に post、contentType に JSON、headers に API キー、payload に要求の本文を入れて呼びます。muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答を返します。 状態コードを見て、その店舗を次の実行で再試行するかを決めます。

API キーと Webhook の URL は、コードに書かずスクリプト プロパティに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されます。スクリプトの編集権限は経営企画の担当者に限ります。 Webhook の URL を知っていれば誰でもスペースに投稿できるため、外へ出さないようにします。

Chat に送るのは、件数と一覧へのリンクだけです。 「幅の外で下 9店舗、幅の外で上 4店舗、CSV未着 0店舗」のように書き、店舗ごとの金額は載せません。 スペースの参加者が増えても、数字が広がらないようにします。

人が確認する

経営企画の担当者が見るのは、見込みの一覧の「幅の外」の行です。 幅の中の店舗は、件数と見込みの合計を確かめるだけにします。

1. 取り込みの状態を見る … 未着の店舗、異常値の印が付いた店舗がないか。ここがおかしければ、見込みを送りません
2. 幅の外の店舗の理由の候補を読む … 根拠の数字が一覧の数字と合っているか、候補が店舗メモと矛盾していないかを見ます
3. 候補を直す・消す … 担当者が知っている事情（本部の販促の変更など）があれば足し、当たっていない候補は消します
4. 確かめる点を地区の責任者向けに整える … 店長に聞く質問を、地区の言葉に直します
5. 送る … 地区の責任者と営業部長に一覧を送ります

理由の候補は「候補」の見出しのまま送ります。 地区の責任者が店長に確かめて、初めて理由になります。確かめた結果は、店舗メモのシートに地区の責任者が書き足します。 次の時点の見込みでは、その事情がAIの入力に入ります。

目標は、75店舗をならして1店舗2分です。 幅の外の店舗は1回に10〜15店舗という想定で、それより多い回は、式の補正率が外れているか、全社的な販促の変更が反映されていないかを先に疑います。

例外に対処する

7行目の扱いが大事です。 Gemini API が止まった朝でも、見込みの数字と幅は式で出ているので、一覧は予定どおり出せます。 理由の候補が無い一覧でも、地区の責任者は幅の外の店舗を知ることができます。

記録を残す

• 取り込んだCSVのファイル名と取り込んだ日時、店舗ごとの行数
• 各時点（10日・15日・20日・25日）の店舗ごとの見込み・幅・区分と、そのとき使った式の版
• 月末の実際の着地と、各時点の見込みとのずれ
• AIに渡した入力と、返ってきたJSONの全文
• 根拠不一致で外した候補
• 経営企画が直した・消した候補と、地区の責任者が店舗メモに書き足した確かめた結果

3つ目が、次の月の幅になります。 各時点の見込みと実際のずれを店舗ごとに積み上げ、過去12か月分を使って幅を計算します。 ずれが毎月同じ向きに出る店舗があれば、式の補正率の取り方を見直す材料にもなります。

最後の行は、理由の候補の当たり外れを振り返る材料です。 経営企画が消した候補が多い型（たとえば「客単価の下落」ばかりが外れる）があれば、指示か入力の数字の作り方を直します。