造花・観葉植物のレンタル会社が交換の予定表から、お客様ごとの交換の日の案内のメールを Apps Script と Gemini で作り、入館の申請と休業日の食い違いを先に拾う

処理の起点を決める

毎週木曜の朝に1回動かします。 時間主導型のトリガーで onWeekDay(ScriptApp.WeekDay.THURSDAY) と atHour(7) を指定します。公式の説明では、atHour() の例は「5時〜6時の間に動く」と書かれ、nearMinute() を指定しないと分はランダムに決まります。 7時台のどこかで動き、担当が出勤する9時までに終わっていればよい作りにします。

木曜にしているのは、入館の申請の締切から逆算したためです。 「3営業日前まで」のビルで翌週の月曜に交換するなら、お客様は前の週の水曜までに申請を出す必要があり、木曜の案内ではもう間に合いません。 そうした予定は判定で「要電話」に回ります。月曜と火曜の交換が多いビルのお客様が増えたら、配送の担当に予定表の確定を前の週の月曜に早めてもらい、トリガーも火曜に移します。

水曜に予定表の確定が遅れた週のために、メニューからも動かせるようにします。 スプレッドシートに結び付けたスクリプトの onOpen で、SpreadsheetApp.getUi().createMenu() に「翌週の案内を作る」と「印の付いた下書きを送る」の2つを足します。公式は、メニューを作れるのは結び付けたスクリプトだけとしています。

トリガーは、業務課の共用のアカウントで作ります。 インストール型のトリガーは作った人のアカウントで動くとされ、担当個人のアカウントで作ると、下書きがその担当の Gmail に入ります。 失敗すると所有者に「Summary of failures for Apps Script」のメールが届くので、受信箱を見る当番を決めます。

入力データを集める

質を決めるのは、ビルの決まりの表とお客様の台帳の休業日です。 ビルの決まりが無ければ、入館の申請の締切を計算できません。臨時の休みの日が台帳に入っていなければ、年末年始や改装の休みに交換を入れてしまいます。 お客様から休みの連絡を受けた担当が、その場で台帳に入れる決まりにします。

品種の表の説明は、会社の植物の担当が書いた文だけにします。 1品種につき2文ほどで、「明るい日陰を好みます。エアコンの風が直接当たらない場所に置いてください」のように書きます。AIはこの文の言い回しを整えるだけで、中身を足しません。

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

すべて同じスプレッドシートの中にあるので、Apps Script のスプレッドシートのサービスで読むだけです。

判定は次の規則で行います。

入館の締切に間に合わない予定は、メールにしません。 締切を過ぎてからメールで頼むと、お客様は申請を出せないまま当日を迎えます。担当がお客様に電話し、申請が間に合うか、日を変えるかを決めます。

営業日の数え方は、会社の休日の表で決めます。 土日と祝日を除いて数え、ビルによって土曜を営業日とするところは、ビルの決まりの表に印を持たせます。

AIへ渡す前に整形する

1. 確定の印で絞る … 確定の印が無い予定は外し、確認の一覧に「予定未確定」と出します
2. 判定する … 上の表の4つの判定を順に当て、引っかかった予定を分けます
3. お客様ごとに束ねる … 同じお客様の同じ週の予定（観葉植物と造花の両方など）は1通にまとめます
4. 日付を整える … 交換の日を M月d日（曜日）、時間帯を「午前（9時〜12時）」のような会社の決まりの言い方にします。曜日は Apps Script が日付から計算します
5. 申請に要る事項をそろえる … ビルの決まりの表から、そのビルで要る事項（入館者の名前・車両の番号など）を並べます
6. 記号に置き換える … 会社名を {{会社名}}、担当者を {{担当者}}、交換の日を {{交換日}}、時間帯を {{時間帯}}、スタッフを {{スタッフ}}、車両を {{車両番号}} に置き換えます

2番目を案内の作成より前に置くことが大事です。 案内を作ってから判定すると、引っかかった予定の下書きが Gmail に残り、誤って送られることがあります。引っかかった予定は、そもそも下書きを作りません。

3番目で1通にまとめるのは、同じ週に2回訪問するお客様のためです。 観葉植物の定期の交換と造花の季節の入れ替えが別の日になることがあり、2通に分けるとお客様が入館の申請を片方しか出さないことがあります。 1通に2つの日を箇条で書き、記号に _1 _2 の番号を付けます。

AIに処理させる

させるのは、記号の入った交換の事実と植物の説明から、案内のメールの件名と本文を作ることだけです。

造花と生きた植物で、紹介の書き方を分けます。 品種の表の「造花か生きた植物か」の列を事実の束に入れ、造花なら季節の飾りの趣旨を、生きた植物なら品種の表の置き場所の注意を書かせます。造花に「日当たりのよい場所に」と書くと、お客様は本物の植物だと思って水をかけます。

2行目がいちばん起きやすい失敗です。 AIは親切に「週に1回、土の表面が乾いたら水をあげてください」と書き足します。レンタルの観葉植物は会社のスタッフが手入れするので、お客様に水やりを頼むと、水のやり過ぎで根が傷みます。 書いてよいのは品種の表の文だけです。

指示内容を固定する

あなたは観葉植物・造花のレンタル会社の業務課の担当として、
お客様に送る交換の日の案内のメールを書きます。
渡す「事実の束」だけを使って書いてください。

【書き方】
- 宛名は {{会社名}} {{担当者}} 様 と書いてください。
- 日付・曜日・時間帯は、事実の束の記号（{{交換日_1}} {{時間帯_1}} など）をそのまま置いてください。
  数字で日付や時刻を書かないでください。曜日も書かないでください。
- 訪問が2つ以上あるときは、番号の順に箇条を分け、箇条1には _1 の記号だけを使ってください。
- entry_items が空でないときは、「入館のお手続きのお願い」の段落を置き、
  entry_items にある事項を並べ、値は {{スタッフ_1}} {{車両番号_1}} の記号で書いてください。
- plants にある植物は、description の文を意味を変えずに整えて紹介してください。
  description に無いことは書かないでください。
- 作業の種類が regular のときは「定期のお手入れと交換」、seasonal のときは「季節の入れ替え」と書いてください。
- 最後に、ご都合が悪いときは返信か電話でお知らせいただくよう、一文でお願いしてください。

【書かないこと】
- 水やり・肥料・日当たりなど、description に無い育て方の助言
- 料金・追加の費用
- 「日の変更はいつでも承ります」のような請け合い

【notes】
事実の束の中で食い違って見えるもの、文面を書くのに足りないものがあれば、
notes に短く書いてください。無ければ空の配列にしてください。

【事実の束】{facts_json}

「水やりを書かない」を具体的に名指ししないと、植物の紹介の流れで必ずと言ってよいほど書かれます。 「description に無いことは書かない」だけでは、AIは水やりを一般的な常識と受け取って足します。

出力形式を固定する

Gemini API の Interactions の構造化出力で、次の形の JSON を受け取ります。 公式の説明では、/v1beta/interactions への要求で response_format に type: "text"、mime_type: "application/json" と schema を指定します。

{
  "subject": "観葉植物の交換のご案内（{{交換日_1}}）",
  "body": "{{会社名}}\n{{担当者}} 様\n\nいつもご利用いただきありがとうございます。…\n\n1. {{交換日_1}} {{時間帯_1}} 定期のお手入れと交換\n\n入館のお手続きのお願い\n・入館者：{{スタッフ_1}}\n・車両の番号：{{車両番号_1}}\n…",
  "placeholders_used": ["{{会社名}}", "{{担当者}}", "{{交換日_1}}", "{{時間帯_1}}", "{{スタッフ_1}}", "{{車両番号_1}}"],
  "notes": []
}

構造化出力を使う理由は、件名と本文と使った記号を別の項目で受け取り、placeholders_used を事実の束の記号と突き合わせられることです。 入館の申請の段落で {{車両番号_1}} が抜けていれば、検査で止まります。

文字数の制約は、スキーマに書いても効きません。 公式は、minLength・maxLength は制約として守られず、エラーにならずに要求の段階で外されるとしています。本文の長さは Apps Script で見ます。

入出力を保存させないため、要求に store: false を入れます。 公式は、Interactions の既定では入出力を保存し、有料の枠で55日、無料の枠で1日保持するとしています。会話を続ける機能は要らないので、保存を止めても困りません。

Apps Script の検査は次のとおりです。

4行目が、育て方の書き足しの網です。 品種の表の説明にある言葉を除いて、育て方に関わる言葉が本文に出たら止めます。

システムへ連携する

下書きを作ったら、その ID を確認の一覧に書きます。 公式の説明では、GmailDraft は getId() で ID を返し、send() で送れます。メニューの「印の付いた下書きを送る」は、送る印のある行の ID の下書きだけを送ります。 送った行には送った日時を書き、同じ下書きを二度送らないようにします。

送る数は1日に数十通です。 メールの宛先の数には1日の上限（個人のアカウントで100、Workspace で1,500）がありますが、この構成の数では届きません。 気をつけるのは1回の実行が6分までという上限のほうで、処理した予定に印を付け、止まったら続きから動く作りにします。Gemini API の鍵はスクリプトのプロパティに置きます。

人が確認する

1. 「配送へ戻す」と「要電話」から片付ける … 休業日・時間帯に当たった予定は配送の担当へ、入館の締切に間に合わない予定はお客様へ電話します
2. 「要確認」の下書きを開いて直す … 記号の抜け、日付の食い違い、育て方の書き足し、notes のあるもの
3. 確認の一覧を流し見る … 引っかからなかった下書きは、お客様・交換の日・植物の名前を一覧で見ます
4. 送る印を付けて、メニューから送る

3番目を省かないでください。 検査は記号と言葉を見ていますが、予定表のお客様番号そのものを入れ違えていれば、正しく置き換えた別のお客様の交換の日が届きます。 一覧でお客様と交換の日の組み合わせに見覚えがあるかを見ます。

目標は、480件をならして1件2分です。 引っかからなかった下書きは一覧で数十秒、「要確認」は数分かかります。

例外に対処する

3行目を軽く見ないでください。 決まりの表に無いビルを「申請不要」と扱うと、申請の要るビルで当日に入れません。 分からないものは案内を止めます。

記録を残す

• 実行の日時、読んだ予定の数、判定で引っかかった予定と理由、作った下書きの数
• お客様ごとの事実の束（記号に置き換えた後のもの）と、Gemini が返した JSON
• 検査の結果と、下書きの ID、送る印を付けた人、送った日時
• 担当が下書きを直したかどうかと、直した箇所の種類
• 交換の当日に入れなかった訪問と、その理由（休業・入館・時間）

4つ目の直した箇所は、プロンプトと品種の表を直す材料になります。 担当が同じ品種の紹介の言い回しを毎回直しているなら、品種の表の説明の文そのものを書き直す合図です。

最後の行が、判定の規則を直す材料になります。 判定を通ったのに当日に入れなかった訪問があれば、台帳の休業日かビルの決まりの表に、足りない決まりがあります。