更新の時期が来る定期契約を毎月洗い出して、案内と条件変更の説明文を作る

処理の起点を決める

毎月1日の時刻主導トリガーを起点にします。 月初に対象を確定させ、その月の連絡をまとめて始める形です。

トリガーはプログラムから作れます。ScriptApp.newTrigger がトリガービルダーを返し、そこに条件をつないで create() します。

ScriptApp.newTrigger("myFunction").timeBased().everyHours(6).create();
ScriptApp.newTrigger("myFunction").forSpreadsheet(ss).onOpen().create();

時刻主導トリガーは毎分から月1回までの頻度を指定できるので、月単位の頻度を同じ形で組み立てます。 前述のとおり実行時刻は若干ランダム化されることがあるため、「1日の何時に動いたか」を前提にした処理を書かないでください。

トリガーが失敗したときは、失敗を知らせるメールが届きます。 送信元は [email protected] で、メールにはトリガーを無効にするリンクと、スクリプトを編集して不具合を直すためのリンクが含まれます。トリガーがアクティブな間は、この通知の頻度を調整できます。

ただし、気づく仕組みを通知メールだけに頼らないでください。 月1回しか動かない処理は、1回止まると1か月分の連絡が丸ごと抜けます。下書きが0件だった月を検知する処理を、別に入れてください。

インストール可能なトリガーには承認が必要です。 スプレッドシート、Gmail、外部への通信を使うため、設定した人のアカウントで承認を済ませておきます。承認した人のアカウントで実行されるので、退職や異動で止まります。 個人ではなく、運用用のアカウントで設定してください。

入力データを集める

この構成の質を決めるのは、契約台帳の列の整備です。 更新日と金額だけでは足りず、予告期間、更新方式、前回の案内日を列として持つことが前提になります。

改定の説明の型も、先に用意する必要があります。 「原材料費の上昇」「保守体制の拡充」「サービス範囲の変更」のように、全社で認めた説明を数種類そろえ、どの契約にどれを当てるかを決めておきます。 ここをAIに書かせると、会社として言っていない理由が文面に出ます。

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

契約台帳： Apps Script からスプレッドシートを直接読み、更新日が当月1日から2か月後までの範囲にある行を抽出します。「2か月以内」にするのは、予告期間の長い契約に間に合わせるためです。 予告期間が60日の契約があるなら、それより早く連絡を始める必要があります。

利用実績： 保守の管理システムに契約番号で照会します。APIがあればそこから、無ければ月次のCSV出力を取り込んで突き合わせます。後者でかまいません。 月1回しか動かない処理なので、リアルタイム性は不要です。

前回の案内の履歴： 台帳の履歴列から読みます。Gmail を検索して過去のやり取りを探す方式にはしません。 検索条件が担当者ごとに違い、結果が安定しないためです。送信の記録を台帳に書き戻しておけば、翌年は履歴列だけで足ります。

価格表と説明文の型： スプレッドシートの別シートに置きます。担当者が中身を見て直せることが重要なので、スクリプトの中に書き込まないでください。

AIへ渡す前に整形する

1. 対象の絞り込み … 更新日が2か月以内でも、すでに解約の申し出を受けている契約、今期で終了が決まっている契約は台帳の状態列で除きます
2. 予告期間からの逆算 … 更新日から予告期間を引いた日を「連絡の期限」として計算します。この日を過ぎている契約は、下書きの先頭に警告を付けて上に出します
3. 改定の判定 … 価格表と現在の金額を突き合わせ、改定の有無と改定額、改定率を機械で計算します。この計算はAIにさせません
4. 利用実績の集計 … 出動回数と対応内容を契約期間に合わせて集計します。期間の切り方で数が変わるので、ここも機械で計算します
5. 担当者の割り当て … 台帳の担当者列から、下書きを入れるアカウントを決めます。空欄の契約はカスタマーサポートの共通アカウントに寄せます
6. 要注意の印 … 直近に苦情の記録がある契約、改定率が一定以上の契約に印を付けます。下書きを作る前に付け、確認の順番を決めるのに使います

AIに処理させる

AIにさせるのは、そろえた材料を案内文の日本語にすることだけです。 数を数えることも、金額を計算することも、更新の可否を判断することもさせません。

案内文に入れる要素と、その出どころは次のとおりです。

3行目の「使ってもらえた事実」を入れることが、この構成の中心です。 同じ改定率でも、「この1年で8回お伺いし、うち3回は当日中に復旧しました」が添えてあるかどうかで受け取られ方が変わります。値上げの案内を、取引の振り返りに変えるのがねらいです。

ただし、この数値をAIに作らせてはいけません。 システムから取った値をそのまま渡し、プロンプトで「渡した数値以外の数を書かない」と縛ります。 ここが崩れると、顧客に誤った実績を送る仕組みになります。

AIに任せるのは次の範囲です。

指示内容を固定する

あなたは保守契約の更新案内を作る担当者を支援する立場です。
渡す契約情報と利用実績をもとに、更新案内のメールの下書きを作ってください。
このメールは担当者が読んで直したうえで、担当者自身が送信します。

【厳守事項】
- 渡した数値以外の数を、本文に書かないでください。
  出動回数、稼働率、金額、改定額、期間は、渡した値をそのまま使ってください。
  四捨五入も、単位の変換も、概算への言い換えもしないでください。
- 渡した情報に記載がない項目は、不明として扱ってください。
  「おそらくこうだろう」という補いをしないでください。
  文面に必要だが情報が足りない場合は、本文に書かず
  needs_human_attention の理由に「〇〇の情報が不足」と書いてください。
- 価格改定の理由は、渡した説明文の型に書かれている内容だけを使ってください。
  型にない理由（他社の動向、今後の見通しなど）を足さないでください。
- 更新するかどうか、解約されそうかどうかの判断を書かないでください。
  「ぜひご継続ください」のような要請も入れないでください。
- 解約の手続きや期限について、渡した契約条項に書かれていない条件を書かないでください。
- 本文で使った数値は、すべて facts_used に
  「項目名・使った値・出どころ」の形で列挙してください。
  本文に出てくる数値と facts_used の数が一致しない状態にしないでください。
- 謝罪、値引きの示唆、次回の条件の約束を書かないでください。

【契約情報】
{contract}

【更新後の条件と改定の有無】
{renewal_terms}

【利用実績（保守の管理システムの値）】
{usage_facts}

【価格改定の説明文の型】
{price_change_template}

【前回の案内の履歴】
{previous_notice}

【要注意の印】
{attention_flags}

「渡した数値以外の数を書かない」が、いちばん効く制約です。 実績の数字は顧客が自分で分かっていることなので、ずれると即座に信用を失います。 「8回」が「10回程度」と言い換えられるだけで、案内の意味が反転します。

「更新するかどうかの判断を書かない」も必要です。 「ぜひご継続ください」のような要請が入ると、条件の連絡が営業の働きかけに変わります。継続のお願いをするかどうかは、担当者が顧客との関係を見て決めることです。

出力形式を固定する

{
  "contract_id": "",
  "renewal_type": "same_terms | price_change | terms_change | non_renewal_candidate",
  "subject": "",
  "body": "",
  "facts_used": [
    { "item": "", "value": "", "source": "" }
  ],
  "needs_human_attention": { "flag": false, "reason": "" }
}

文面をそのまま返させず、構造化した形にする理由は2つあります。

1つ目は、確認を速くするためです。 facts_used に「本文で使った数値と、その出どころ」を列挙させると、担当者は本文を読みながら、その数字が台帳のどの値かを1秒で照合できます。 本文だけを渡されると、数字ごとに元のシステムを開くことになり、確認の時間が元の8分に戻ります。

2つ目は、下書きを仕分けるためです。 renewal_type があると、改定ありの契約だけを先に確認する順番が付けられます。needs_human_attention が真の下書きは、上長が先に読む運用にできます。

renewal_type の non_renewal_candidate は、「更新しない見込み」とAIが判断した印ではありません。 台帳の状態と要注意の印から機械で付けた値で、担当者が先に目を通すべき契約を上に出すためのものです。

システムへ連携する

Gmail への書き出しは createDraft までです。 sendEmail は使いません。下書きに入れておけば、担当者は普段どおりの画面で直して送れます。 専用の確認画面を作らずに済むのが、この方式の利点です。

書き戻しは台帳への送信記録だけにします。 基幹システムや会計システムへの反映はこの構成の範囲外で、更新が確定したあとの処理はこれまでどおりの手順で行います。

人が確認する

全件、人が確認します。確認せずに送る設計にしません。

確認の順番を、次のように決めます。

1. 連絡の期限を過ぎている契約（予告期間からの逆算で判定したもの）
2. needs_human_attention が真の契約
3. renewal_type が price_change の契約
4. それ以外

確認の作業は3つです。

• facts_used の数値が、台帳とシステムの値と合っているかを見る（本文の数字を1つずつ追わない）
• 改定の説明が、会社として言ってよい内容になっているかを見る
• その顧客との関係を踏まえて、言い回しを直す

3つ目は機械にできません。前回揉めた顧客、担当者が代わったばかりの顧客では、同じ文面が違う意味になります。 ここに時間を使えるようにするのが、この構成の目的です。

確認にかかる時間の目標は、1件8分（確認5分＋修正3分）です。 それ以上かかるなら、facts_used の粒度が粗いか、説明文の型が足りていません。

例外に対処する

最後の行は仕組みで持ってください。 本文の数値を機械で拾い、facts_used の値と照合するだけの処理です。プロンプトの制約は必ずすり抜けるので、出力の側でも見ます。

記録を残す

• 抽出した対象契約の一覧（何件を対象にしたか、除外した契約とその理由）
• AIに渡した材料（契約情報、利用実績、説明文の型）
• AIが返した下書きと facts_used
• 人が直した箇所と、直した内容
• 送信した日時、宛先、送信した担当者
• 顧客からの返答（更新、条件の相談、解約の申し出）と、その日付

4つ目を残すと、この構成の弱点が見えます。 同じ種類の直しが毎月繰り返されているなら、プロンプトか説明文の型を直せます。「毎回、冒頭の挨拶を書き直している」なら、型のほうが業務に合っていません。

6つ目は、翌年のための記録です。 更新の結果を台帳に戻しておくと、次の年は「前回は条件の相談があった」という前提から案内を始められます。