飲食チェーンの店長がフォームで出す営業日報を、数字は Apps Script で集計し、コメントは AI で要約して、エリアマネージャーの週次・月次の報告と気になる店の一覧にする

処理の起点を決める

トリガーは3つ置きます。 1つ目は、フォームの回答先のスプレッドシートに付ける、送信のたびに動くトリガーです。Apps Script のインストール型のトリガーには、フォームそのものに付けるものと、回答先のスプレッドシートに付けるものの2つの版があるとされています。処理は、数字の欄の形の確認と、事故やけがを思わせる語の確認だけに絞ります。

2つ目は、毎週月曜の朝5時台に動く時間主導型のトリガーで、前週の月曜から日曜までを対象にします。3つ目は、毎月2日の朝に動く時間主導型のトリガーで、前月分の月次の報告を作ります。時間主導型のトリガーは毎分から月に1回までの間隔で動かせ、公式のページでは、9時に設定すると9時から10時のあいだのどこかで動くとされています。深夜に閉店する店の日曜の日報が出そろってから動くよう、月曜の早朝に置きます。

インストール型のトリガーは、作った人のアカウントで動きます。 公式のページにそう書かれており、Gmail の下書きもそのアカウントのメールボックスにできます。そこで、送信のたびのトリガーと月次のトリガーは店舗運営部の共用のアカウントで作り、週次のトリガーだけは、エリアマネージャーが自分のアカウントで自分のエリアの分を作ります。 週次の報告の下書きが、本人の Gmail に営業部長あてでできるようにするためです。エリアマネージャーが替わるときは、トリガーの作り直しを引き継ぎの手順に入れます。 トリガーが失敗すると、作った人に失敗のまとめのメールが届きます。

入力データを集める

質を決めるのは、店舗台帳の定休日です。 日報が出ていない日を数えるとき、定休日と臨時休業を除かないと、休みの日まで「日報の抜け」と出ます。 臨時休業はエリアマネージャーが台帳の欄に入れます。

前週の確定版を持つのは、「続いている話」を拾うためです。 前週に本部へ依頼した製氷機の修理が、今週のコメントにまだ出てくるなら、依頼が片づいていないということです。 確定版の「本部への依頼」の欄を、今週の要約と並べて出します。

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

シートは範囲を一度に読み、スクリプトの中で店舗コードをキーにまとめます。 36店×7日で250件ほどなので量は多くありませんが、1行ずつ読むと遅くなります。営業日は、フォームの送信日時ではなく日報の「営業日」の欄で決めます。 深夜0時を回ってから出された日報が翌日の扱いにならないようにするためです。

送信のたびのトリガーでは、フォームの送信のイベントの値を使います。 公式のページでは、スプレッドシートのフォームの送信のイベントには、質問の名前と回答の組（namedValues）や、スプレッドシートの並びどおりの回答（values）が入るとされ、例では1つの回答も配列で返っています。値は配列の1つ目を取り出して使います。

AIへ渡す前に整形する

1. 数字の欄の形の確認 … 売上・客数・人件費の時間が数として読めるか、0や空でないか。送信のたびに確かめ、おかしければ店長に打ち直しを頼む知らせを出します
2. 重複の除去 … 同じ店・同じ営業日の日報が2件あれば、後に出たほうを使い、前のほうに印を付けます
3. 出ていない日の数え上げ … 店舗台帳の定休日と臨時休業を除いて、日報の無い営業日を数えます
4. 週の指標の計算 … 売上の合計、予算比、客数、客単価、人件費率（人件費の時間×店の平均時給÷売上）、廃棄率、苦情の件数を出します
5. 印を付ける … 指標の幅のシートの規則に照らし、外れた指標に印と理由を付けます
6. 伏せ字 … コメントの中のスタッフの名前と呼び名を【スタッフ】に、電話番号やメールアドレスを【連絡先】に置き換えます
7. コメントの並べ方 … 1日ずつ「営業日｜曜日｜コメント」の1行にし、日付の順に並べます

4番目の人件費率に使う平均時給は、店舗台帳に店ごとに持たせます。 日報には時間しか書かれないためで、エリアマネージャーが見ている物差しをそのまま計算に写します。 計算の式は報告の欄外に書き、営業部長が同じ式で読めるようにします。

6番目を省かないでください。 店長のコメントには「【スタッフ】が今週で辞める」「【スタッフ】の遅刻が続いた」のような、働く人の事情が書かれます。 アルバイトには学生も多く、その名前を外のサービスに渡す理由はありません。

AIに処理させる

させるのは、1店1週間分のコメントを、決まった話題ごとに要約し、本部への依頼を書き出すことです。

話題ごとに、根拠にした営業日を付けさせます。 同じ話が火曜と木曜に出ていれば、1つの要約にまとめ、日付を2つ付けさせます。 1日ずつ読んでいると気づきにくい「続いている話」が、ここで見えるようになります。

本部への依頼は、ほかの話題と分けて書き出させます。 営業部長が週の会議で手を打つのは、主にここです。本文に埋もれると拾い漏れるという第3章の（c）を、出力の形で防ぎます。

2行目と3行目は、とくに強く禁じます。 「店長のコメントが短く、意欲の低下がうかがえる」のような一文は、要約を頼むと出てきやすいものです。店長の評価は人事の判断につながるので、要約の段階で書かせません。

指示内容を固定する

あなたは飲食チェーンの店舗運営部で、エリアマネージャーが週次の報告を
書くのを手伝う担当です。以下は1つの店の1週間分の営業日報のコメントです。
このコメントだけを使って、話題ごとに要約してください。

【話題】
staffing（人手）／equipment（設備）／supply（食材・仕入）／
customer（お客様の声）／business（売場・営業）／hq_request（本部への依頼）

【書き方】
- topics：話題ごとに、出来事を1〜3文で要約する。
    同じ出来事が複数の日に出ていれば1つにまとめ、dates にすべての営業日を入れる。
    その話題の記述が無ければ、その話題は入れない。
- hq_requests：本部に動いてほしいと書かれていることを、1件ずつ書き出す。
    何を、誰に（分かれば）、いつまでに（書かれていれば）を、書かれたとおりに。
- positives：お客様にほめられたこと、うまくいったことを2つまで。
- 文は「〜があった」「〜と書かれている」のように、出来事として書く。

【厳守事項】
- 金額・人数・時間・割合などの数字を書かないでください。
  コメントに数字が書かれていても、要約に写さないでください。
- 店や店長、スタッフを評価する言葉（意欲、怠慢、優秀、問題がある等）を
  使わないでください。
- スタッフの退職・欠勤・遅刻の理由を推し量らないでください。
- コメントに書かれていない出来事を補わないでください。
- 対策や打ち手を提案しないでください。
- 【スタッフ】【連絡先】の記号はそのまま使い、人物を推測しないでください。
- 食品の事故、けが、火災、警察への連絡を思わせる記述があれば、
  要約に含めたうえで urgent_dates にその営業日を入れてください。

【店の区分】{store_type}
【前週に本部へ依頼した事項】{last_week_requests}
【コメントの一覧】{comments}

数字を「写さない」とまで書いているのは、コメントの中にも数字があるからです。 「予約が20組入った」と書かれていると、要約に写します。写した数字は、スクリプトが計算した表の数字と並んで報告に載り、どちらが正しいのか分からなくなります。 数字の出どころを表の側だけにします。

前週の依頼を渡しているのは、続いているかどうかを書かせるためではありません。 今週のコメントに同じ設備や同じ依頼が出てきたとき、同じ話として1つにまとめやすくするためです。続いているかどうかの印は、スクリプトが前週の確定版と話題を突き合わせて付けます。

出力形式を固定する

OpenAI API の Responses API で、構造化出力を使って次の形の JSON を受け取ります。 公式のページでは、text.format に type: "json_schema" と strict: true を指定する書き方が示されています。

{
  "store_code": "S-118",
  "week": "2026-10-19",
  "topics": [
    { "topic": "equipment", "summary": "", "dates": ["2026-10-20", "2026-10-22"] }
  ],
  "hq_requests": [ { "request": "", "dates": ["2026-10-22"] } ],
  "positives": [ { "text": "", "dates": [] } ],
  "urgent_dates": [],
  "needs_review": ""
}

1つ目の理由は、日付をスクリプトで検算できることです。

最後の行は、公式のページの記述から来ます。 公式のページでは、拒否はスキーマに従うとは限らないため、応答に refusal という項目が入るとされています。拒否が返った店は、要約を作らずにコメントの原文をそのまま下書きに添えます。 また、出力の上限に達したときは応答の status が incomplete になるとされているので、その場合もやり直すか確認待ちにします。

2つ目の理由は、話題の順に報告の様式へ差し込めることです。 店ごとの欄は、数字の表、印、本部への依頼、話題ごとの要約、ほめられたことの順に並べ、営業部長がどの店でも同じ場所を見れば同じことが分かるようにします。

システムへ連携する

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げず、応答を返すとされています。応答のコードを見て、混み合いなら時間をおいてやり直し、続けて失敗した店は要約なしで下書きを作ります。 要約が無くても数字の表は出せるので、報告そのものは止めません。 API キーはスクリプトのプロパティに置きます。公式のページでは、スクリプトのプロパティはそのスクリプトの利用者全員で共有され、スクリプトの間では共有されないとされています。

Gmail は下書きまでです。 createDraft は宛先・件名・本文のほか、HTML の本文、差出人の表示名、返信先などを指定して下書きを作れるとされています。数字の表は HTML の本文で表にし、 返信先は店舗運営部の共用のアドレスにします。このメソッドを使うには https://mail.google.com/ のスコープの承認が要るとされています。

確定版は、エリアマネージャーが送ったメールから写すのではなく、確認の一覧の「送った」欄に印を付けた時点の内容を写します。 送ったメールを読み取る処理を足すより、印を付けるほうが壊れにくいからです。

人が確認する

9店分の下書きを、エリアマネージャーが全部読みます。 下書きは1通に9店分が並び、冒頭に「数字で印の付いた店」と「本部への依頼」がまとまっています。

1. 至急の知らせと urgent_dates を先に見る … 店長に電話で状況を確かめたかを確かめます
2. 数字で印の付いた店を見る … 印の理由を読み、自分が店で見たことと合っているかを考えて一言を足します
3. 本部への依頼を確かめる … 抜けている依頼、すでに片づいた依頼がないか。前週から続いている依頼には期限を書きます
4. 話題ごとの要約を流し読む … 要約の日付から、気になるものだけ元のコメントを開きます
5. 直して送る … 送ったら確認の一覧に印を付けます

2番目が、この構成でエリアマネージャーにしかできない仕事です。 予算比が割れていても、近くの道路工事のせいだと店で聞いていれば、報告に書く一言が変わります。数字の印は規則で出ますが、その意味を書くのは店を回っている人です。

1店5分を目安にします。 印の付いた店と依頼の多い店に時間を使い、落ち着いている店は流し読みで終えます。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分で、トリガーで動かした合計の実行時間は Google Workspace のアカウントで1日6時間です。36店分の要約は1回で終わることが多いものの、混み合いのやり直しが重なると6分に近づくので、エリアごとに9店ずつ作り、残りは1回きりのトリガーで続きを作ります。 トリガーはユーザー・スクリプトごとに20個までとされているので、続きのトリガーは動いたら消します。

記録を残す

• 実行の日時、対象の週、店ごとの日報の件数と未提出の日
• 店ごとの週の指標と、付けた印と理由（計算に使った値と式）
• AI に渡したコメントの一覧（伏せ字の後）と、AI が返した JSON の全文
• 検査の結果と、確認待ちにした理由
• 至急の知らせを出した日時と、その日報
• エリアマネージャーが直して送った確定版

2つ目で計算に使った値と式を残すのは、第3章の（b）を繰り返さないためです。 営業部長が数字に疑問を持ったとき、日報のどの欄の値から、どの式で出したかをすぐに示せます。

最後の確定版が、月次の報告の材料になります。 月次の報告は、4週分の確定版と、月の数字の集計から作ります。AI の要約ではなく、エリアマネージャーが直した後の版をもとにするので、月次で同じ直しを繰り返さずに済みます。