飲食のフランチャイズ本部が加盟店から毎月届く報告（売上・人・困りごと）を要約し、スーパーバイザーの訪問の論点を店ごとに作る

処理の起点を決める

毎月6営業日目の朝に1回動かします。 報告の締切が5営業日目なので、その翌朝です。届いていない店があっても待たずに動かします。 未提出の店は要約の対象から外し、別に一覧にします。

未提出の店の扱いが、この起点の設計の要です。 未提出のまま要約を作らずにいると、その店はスーパーバイザーの一覧から消えたように見えます。 未提出の一覧を訪問予定表の先頭に出し、報告が無いこと自体を訪問の論点にします。

締切を過ぎて届いた報告は、届いた日の夜にその店の分だけを追加のバッチで投げます。 1店でも同じ仕組みで流せるので、締切後の扱いを別に作る必要がありません。

入力データを集める

質を決めるのは、いちばん下の一覧です。 オーナーが「求人を出しても応募が無い」と書いたとき、本部に採用の支援策があることを知らなければ、AIは「採用の状況を確認する」という一般的な論点しか出せません。 支援策の一覧があれば、「本部の採用支援（求人原稿の代行）の案内」という具体的な論点になります。

前回の訪問の記録は、論点を続けるために渡します。 前回「仕込みの手順を見直す」と話した店なら、今月の報告でそれがどうなったかを最初に確かめるのが自然な順序です。

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

報告は、加盟店ポータルの月次報告の書き出し機能で、当月分を CSV にして取り出します。取り出すのは自由記述を含む全欄です。 POS の実績は、本部の POS 集計から店コードで引きます。

報告と POS の突き合わせは、店コードで行います。 店名で突き合わせると、同じオーナーの2店目・3店目で取り違えます。

計算した差は、数値として AI に渡します。 「前年比 −12.3％」と渡し、AI にはその数値を言い換えずに使わせます。 AIに売上の数値を渡して前年比を計算させると、桁や符号を取り違えることがあり、取り違えた数字が論点の根拠として訪問の場に出ていきます。

AIへ渡す前に整形する

1. 未提出の店の切り出し … 当月の報告が無い店を一覧にし、要約の対象から外します
2. 報告と POS の差の計算 … 売上と客数について、報告の値と POS の値の差を出し、一定の割合を超えたら印を付けます。どこからを食い違いとするかは本部で決めます
3. 前月比・前年比の計算 … POS の値で計算します。開店から13か月に満たない店は前年比を空にします
4. 自由記述の個人名の置き換え … スタッフの氏名や、客の名前が書かれていたら記号に置き換えます。論点に要るのは「店長が辞める」という事実で、誰かではありません
5. 長すぎる自由記述の扱い … 極端に長いものは切らずに渡し、要約の長さだけを指定します。切ると、最後に書かれた本題が落ちます
6. custom_id の付与 … 店コードと年月をつないで付けます。使える文字は英数字・ハイフン・アンダースコアで、1〜64文字とされているため、店コードに記号が含まれるなら置き換えます

2番目の印は、AI の要約より先にスーパーバイザーの目に入るようにします。 報告の売上が POS より大きく多い店は、報告の書き間違いか、POS を通らない売上があるかのどちらかで、どちらも訪問で確かめる事柄です。

4番目は、アルバイトのスタッフに高校生が含まれうることも理由です。 スタッフの個人の情報は、本部ではなく加盟店の雇用の話であり、本部の側で要約に残す必要がありません。

AIに処理させる

させるのは、店ごとに次の5つを返すことです。

論点の案を3つまでに絞るのは、訪問の時間が限られているからです。 10個並べると、スーパーバイザーは結局自分の経験で選び直し、論点が人によって違う状態に戻ります。

協議の申し入れを論点から外すのは、第1章で書いた理由です。 公正取引委員会の考え方は、本部が営業時間の短縮を合意すれば認めるとしているのに、加盟者からの協議を正当な理由なく一方的に拒み、従前の営業時間を受け入れさせることを、優越的地位の濫用になりうる行為として挙げています。訪問の論点として「営業時間は契約どおりで」と書かれた案が出ると、スーパーバイザーはそのまま話しかねません。

3行目は、論点の案の言い回しに出ます。 「原価率が高いので発注を減らすよう指導する」と書かれた案は、本部が仕入の数量を指示する形に読めます。 論点は「原価率の上昇の理由を一緒に確かめる」のように、確かめる形で書かせます。

指示内容を固定する

あなたは飲食のフランチャイズ本部で、加盟店の月次の報告を読み、
スーパーバイザーが訪問の前に読む要約と論点の案を作る担当です。

【入力】
店の属性：{store_profile}
今月の報告（数値と自由記述）：{report}
計算済みの数値（前月比・前年比・報告と POS の差）：{metrics}
前回の訪問の論点とその後のメモ：{last_visit}
本部の支援策の一覧：{support_menu}

【作るもの】
1. summary：自由記述3欄を合わせた今月の状況。3〜5文。
2. links：自由記述の記述と、計算済みの数値の動きの組み合わせ。
3. agenda：次の訪問の論点の案を3つまで。
   前回の論点の続きがあれば1つ目に置く。
   各論点に、根拠の記述の写しと、関係する数値を添える。
   本部の支援策に当てはまるものがあれば、その名前を添える。
4. requests：本部の部署に届けるべき要望。原文の写しと宛先の候補。
5. negotiation：営業時間、見切り販売・値引き、仕入の数量、
   契約の条件に関わる申し入れや相談があれば、原文の写しを入れる。

【厳守事項】
- 数値は計算済みの値をそのまま使ってください。計算し直したり、
  丸めたり、符号を変えたりしないでください。
- 自由記述に書かれていない事情を推測で足さないでください。
  書かれていなければ「報告に記載なし」としてください。
- negotiation に入れたものは agenda に入れないでください。
  答え方や方針も書かないでください。
- 論点は「確かめる」「一緒に考える」形で書いてください。
  仕入の数量や値引きを指示する形、営業時間を契約どおりに
  求める形で書かないでください。
- オーナーやスタッフの人柄、能力についての評価を書かないでください。
- 記号に置き換えた名前を元に戻そうとしないでください。
- 根拠の写しは、報告の文をそのまま写してください。

「negotiation に入れたものは agenda に入れない」を書かないと、両方に入ります。 営業時間の相談は困りごとでもあるので、論点の案の1つ目に「深夜営業の継続について説明する」と出てきます。 それを防ぐのがこの一文です。

「報告に記載なし」を明記するのは、空欄を埋めさせないためです。 自由記述が1行の店ほど、AIは数値から事情を推して要約を膨らませます。1行しか書かれていないこと自体が、スーパーバイザーにとっての情報です。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは output_config.format に type: "json_schema" で渡します。

{
  "store_code": "",
  "month": "",
  "summary": "",
  "links": [
    { "remark_quote": "", "metric": "", "metric_value": "" }
  ],
  "agenda": [
    { "order": 1, "topic": "", "remark_quote": "", "metric": "",
      "continues_last_visit": true, "support_menu_item": "" }
  ],
  "requests": [
    { "quote": "", "department_candidate": "" }
  ],
  "negotiation": [
    { "category": "business_hours | markdown | order_quantity | contract | other",
      "quote": "" }
  ]
}

1つ目の理由は、振り分けが機械でできることです。 agenda は訪問予定表へ、requests は各部署の受付の一覧へ、negotiation は店舗運営部の責任者へ。読み手ごとに別の場所へ届きます。

2つ目は、agenda の件数を受け取った側で確かめられることです。 構造化出力のスキーマでは配列の minItems は 0 と 1 しか使えないとされ、「3つまで」をスキーマで縛れません。 4つ以上返ってきたら、order の小さい順に3つを残します。

3つ目は、metric_value を計算した値と照合できることです。 AIが書いた数値が、渡した計算済みの値の中にあるかをプログラムで確かめます。無ければ、AIが計算し直したか書き換えたかのどちらかで、その論点に印を付けます。

システムへ連携する

バッチの状態は、一定の間隔で照会します。 処理の状態が in_progress から ended に変われば結果が揃っています。結果は店ごとに成功・エラー・期限切れなどの種別付きで返るため、成功したものだけを振り分け、それ以外は再投入の一覧に回します。

本部への要望の宛先の候補は、部署の一覧から選ばせます。 自由に書かせると「商品開発」「メニュー企画」「商品部」のように同じ部署が別の名前で出てきて、受付の一覧に振り分けられません。宛先に使える部署名を入力で渡し、その中から選ばせて、当てはまらなければ「店舗運営部」に寄せます。

訪問予定表には、AI の結果を別の列に書き込みます。 スーパーバイザーが自分で書くメモの列とは分け、どこまでがAIの案で、どこからが人の判断かを列で区別します。

人が確認する

スーパーバイザーが読むのは、受け持ち20店の要約と論点の案です。 報告の原文は、印の付いた店と、気になった店だけ開きます。

1. 未提出の店と、報告と POS の食い違いの印を先に見る … どちらも訪問で確かめる事柄です
2. 論点の案を読んで、話す論点を決める … 案をそのまま使っても、入れ替えてもかまいません。入れ替えたら理由を一言残します
3. 「数値要確認」「引用要確認」の印がある論点は、原文と数値を開いて確かめる
4. 協議の申し入れは自分で答えない … 店舗運営部の責任者に届いていることを確かめ、訪問では「本部で受けて検討している」ことを伝えます

受け持ちが替わった月は、前任の論点を必ず読みます。 訪問予定表には前任が決めた論点と入れ替えの理由が残っているので、新しいスーパーバイザーは、要約と一緒にそれを読むだけで前任の続きから始められます。 第3章の（b）で書いた引き継ぎの切れ目を、ここで埋めます。

店舗運営部の責任者は、協議の申し入れの一覧を毎月必ず見ます。 受けた日、誰が対応するか、結果をこの一覧に記録します。一覧に残っていれば、本部として協議に応じたかどうかを後から説明できます。

目標は、240件をならして1件12分です。 要約と論点の案を読むのが数分、印の付いた店の原文を開くのが十数分という想定で、原文を開く店が多い月は、報告の様式か、計算の閾値を見直します。

例外に対処する

8行目は、バッチの流れとは別に作ります。 報告に「お客様が体調を崩したと連絡があった」とあれば、月次の要約を待っている時間はありません。 報告が届いた時点で、決めた言葉を含むものを規則で拾い、担当へ回します。

記録を残す

• 当月の報告の原文と、取り出した日時
• 計算した数値（前月比・前年比・報告と POS の差）と、計算に使った POS の値
• バッチの番号、店ごとの custom_id、結果の種別、返ってきたJSONの全文
• 照合の結果（数値要確認・引用要確認の印）
• スーパーバイザーが決めた論点と、AIの案から入れ替えた理由
• 協議の申し入れの一覧と、受けた日・対応者・結果

3つ目は、バッチの結果が29日で取り出せなくなるため、自社の側に必ず残します。 公式のページは、バッチの要求と応答のデータを作成から最大29日保存するとしています。後から「AIが何と書いたか」を確かめる手段は、自社の保存だけになります。

最後の行は、ほかの記録と別の扱いにします。 協議の申し入れへの対応は、加盟店との関係で後から説明を求められうる記録です。保存の期間を、契約の書類と同じ考え方で決めておきます。