面接の当日辞退・無断欠席のおそれを応募者とのやり取りから見込み、前日の確認連絡の優先順と文面を作る

処理の起点を決める

毎日15時台に動く時間主導型トリガーを起点にします。 面接の前日の夕方に、担当者が電話をかけられる時間を残すためです。午前中に動かすと、その日の午後に日程変更の連絡が来た人が反映されません。

土日の面接がある施設は、金曜に土・日・月の3日分をまとめて出します。 翌日の分だけを出す設計にすると、週末の面接の確認が週末の当番に寄ります。

同じ日に二度動かさない仕組みも入れます。 確認リストのシートに作成日を残し、同じ日付の行があれば作り直さずに終わります。手で再実行したときに、下書きが二重にできるのを防ぎます。

入力データを集める

質を決めるのは、いちばん下の行です。 来たかどうかの記録が無ければ、点数表を作れません。当日辞退と無断欠席を分けて記録します。 当日辞退は連絡があるぶん、枠の入れ替えに間に合うことがあり、手当てのしかたが違います。

台帳から読まない列を、先に決めておきます。 生年月日、性別、国籍、住所、家族の情報は、台帳にあってもスクリプトが読み込まない設計にします（第13章）。

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

やり取りは、応募者のメールアドレスで GmailApp.search を呼んで集めます。 検索語に from: と to: でアドレスを入れ、応募日以降に絞ります。集めたスレッドから、送受信の日時と本文を取り出し、次の値を数えます。

区分の境目は、最初は上の例で始め、点数表を作り直すときに見直します。 細かく分けすぎると、1つの区分に入る過去の件数が少なくなり、点数がぶれます。

生成AIに渡すのは、応募者から届いた本文だけです。 こちらから送った定型の案内や、署名・引用の部分は外します。

点数表は、過去6か月の面接の結果から作ります。 区分ごとに「来なかった割合」（当日辞退と無断欠席の合計）を出し、全体の割合と比べて点数にします。計算はスプレッドシートの集計で足ります。

区分の境目と点数の刻みは例です。 大事なのは、どの区分が何点かを、表として誰でも読める形にしておくことです。生成AIが書き出した分類も、同じ表に1つの区分として載せ、同じ計算で点数にします。合計点が高い順に並べ、上位をA、次をB、残りをCとします。Aの人数は、その日に電話をかけられる件数で決めます。

AIへ渡す前に整形する

1. 翌日の面接の抜き出し … 台帳の面接日時が翌日（金曜は月曜まで）の行。取り消し済みの行は除く
2. アドレスの確認 … 台帳のアドレスでGmailを検索し、1通も見つからなければ「やり取りなし」とする
3. 本文の整理 … 引用部分（「>」で始まる行、「〜さんは書きました」以下）と署名を落とす
4. 個人の情報を落とす … 本文中の電話番号、住所らしい文字列を伏せ字にしてから生成AIに渡す
5. 長さの制限 … 1人あたり直近の5通まで。それより前のやり取りは数えるだけにして本文は渡さない
6. 処理済みの印 … 確認リストに出した応募者には作成日を付け、二重に下書きを作らない

検索は、開始位置と件数を指定する search(query, start, max) を使います。 スレッドの合計が大きすぎると失敗するとされているためです。骨組みは次のとおりです。

// 応募者ごとのやり取りを集め、返信までの時間を数える（骨組み）
function collectThreads(applicant) {
  const q = `(from:${applicant.email} OR to:${applicant.email}) after:${applicant.appliedYmd}`;
  const threads = GmailApp.search(q, 0, 20);
  const msgs = GmailApp.getMessagesForThreads(threads).flat()
    .sort((a, b) => a.getDate() - b.getDate());
  return msgs.map(m => ({
    fromApplicant: m.getFrom().includes(applicant.email),
    at: m.getDate(),
    body: stripQuoteAndSignature(m.getPlainBody())
  }));
}

4番目を省かないでください。 応募者は返信の中に、通勤の事情として住所や最寄り駅を書くことがあります。分類に必要なのは「通勤に不安がある」という事実だけで、住所そのものではありません。

AIに処理させる

させるのは2つです。 1つ目は、応募者の文面を決められた分類に置き換えること。2つ目は、優先度と分類に合わせた確認の文面を下書きすることです。

分類には、根拠にした文をそのまま写させます。 担当者が電話をかける前に、なぜAになったのかを、その人自身の言葉で読めるようにするためです。

3行目は、指示に書かないと起きます。 文面の言葉づかいから年代や国籍を推し量り、根拠の欄に書くことがあります。書かれた時点で、使わないと決めた情報が記録に残ります。

指示内容を固定する

あなたはホテルの採用担当を補助する立場です。
翌日に面接を控えた応募者から届いたメールの本文を読み、
下の分類に当たる表れがあるかを書き出してください。

【分類】
- other_offer ......... 他社の選考や内定に触れている
- schedule_doubt ...... 面接の日時に来られるかどうか迷いを示している
- commute_concern ..... 道順・交通手段・時間に不安を示している
- condition_question .. 時給・シフト・寮などの質問があり、こちらの回答が無い
- positive ............ 面接に前向きな言葉がある
- none ................ 上のどれにも当たらない

【厳守事項】
- 本文に書かれていることだけで判断してください。推測で分類を足さないでください。
- 1つの分類につき、根拠にした文を evidence にそのまま写してください。
  根拠の文が無い分類は書かないでください。
- 応募者の人柄、意欲、能力を評価しないでください。
- 年齢、性別、国籍、出身地、家族について推測したり書いたりしないでください。
- 来る・来ないの予想、点数、合否に関わることは書かないでください。
- 伏せ字（＊＊＊）になっている部分を復元しようとしないでください。

【応募者からの本文（新しい順、最大5通）】{messages}

下書きを作るときは、別の指示で呼びます。

次の応募者に、明日の面接の確認の連絡を作ります。
優先度が A の場合は、電話で話すことの要点を3つまでの箇条書きで。
B・C の場合は、メールの本文を作ってください。

【必ず入れること】面接の日時、施設名、場所（{access}）、持ち物、連絡先
【分類に応じて足すこと】
- commute_concern があれば、最寄り駅からの道順を入れる
- condition_question があれば、質問に答えられる担当者がいることを伝える
- schedule_doubt があれば、日程を変えられることを伝える
【書かないこと】
- 来ないことを前提にした言い方、催促や念押しの繰り返し
- 面接に来ないと不利になる、といった表現
【応募者の名前】{name} 【分類と根拠】{signals} 【優先度】{priority}

「日程を変えられることを伝える」を入れるのは、来られない人に連絡をもらうためです。 迷っている人に念押しを重ねると、黙って来ない方を選びやすくなります。前日に「行けない」と言ってもらえれば、その枠を別の応募者に回せます。

出力形式を固定する

分類はJSONで受け取ります。 Gemini API の構造化出力（response_format に mime_type として application/json と、スキーマを渡す機能）を使い、signal の選択肢を enum で固定します。

{
  "applicant_id": "",
  "signals": [
    { "signal": "other_offer | schedule_doubt | commute_concern | condition_question | positive",
      "evidence": "", "message_date": "" }
  ]
}

Apps Script から渡すスキーマは次の形です。

const schema = {
  type: 'object',
  properties: {
    applicant_id: { type: 'string' },
    signals: { type: 'array', items: {
      type: 'object',
      properties: {
        signal: { type: 'string', enum: ['other_offer','schedule_doubt',
          'commute_concern','condition_question','positive'] },
        evidence: { type: 'string' },
        message_date: { type: 'string' }
      },
      required: ['signal', 'evidence']
    } }
  },
  required: ['applicant_id', 'signals']
};

値の検査はスクリプトで行います。 構造化出力はJSONとして正しい形で返りますが、値はアプリケーション側で必ず検査するよう公式の説明にあります。evidence の文が実際に本文に含まれているかを文字列で照合し、含まれていなければその分類を捨てます。

点数と優先度は、スクリプトが確認リストに書きます。

理由の列を省かないでください。 点数だけが並ぶと、担当者は点数を信じるか無視するかのどちらかになります。理由が読めれば、電話で何を話せばよいかが分かります。

システムへ連携する

応募者台帳には書き込みません。 スクリプトが書くのは、確認リストと点数表の2つのシートだけです。来たかどうかの記録は、翌日に担当者が台帳へ入れます。

1回の実行は6分までという制限があります。翌日の面接が20件なら分類と下書きで40回の呼び出しになり、1件ずつ待つと6分に近づきます。呼び出しは fetchAll でまとめて送り、終わらなかった分は次の実行に回します。 トリガーの合計実行時間は Google Workspace のアカウントで1日6時間です。

人が確認する

人が手をかけるのは、Aの人への電話と、下書きの確認です。

1. Aの人に電話をかける … 要点を見ながら、日時と場所を確かめ、不安があれば聞きます
2. 来られないと分かったら日程を組み直す … 空いた枠は、面接を待っている別の応募者に案内します
3. B・Cの下書きを確かめて送る … 日時と場所が台帳と合っているかを必ず見ます
4. 結果の列に記入する … 電話がつながったか、日程を変えたか、辞退の連絡があったか

下書きの日時の確認を省かないでください。 日程変更の直後は、台帳とGmailの最新のやり取りが食い違っていることがあり、古い日時の確認を送ると、それが原因で来なくなります。

目標は、400件をならして1件1.5分です。 Cの人は下書きの日時を確かめて送るだけで1分かからず、Bは文面を読んで直すので2分前後です。Aの電話の時間はこの1.5分に含めていません（第10章）。

点数と担当者の感覚が違うときは、担当者の判断を優先します。 BやCの人でも、気になれば電話をかけます。そのときは結果の列に「担当者の判断で電話」と残します。 点数表を作り直すときの材料になります。

例外に対処する

1行目でAにするのは、やり取りが無いこと自体が手がかりだからです。 求人媒体の画面だけで日程が決まった人は、こちらのメールを一度も見ていない可能性があります。

記録を残す

• 確認リストの全行（点数、理由、根拠、優先度、下書き）を日付ごとに残す
• 生成AIに渡した本文（伏せ字の後）と、返ってきたJSON
• 担当者の結果の記入と、「担当者の判断で電話」の記録
• 翌日の面接の結果（来た・事前に辞退・当日辞退・無断欠席）
• 点数表の版と、作り直した日

4つ目と1つ目を突き合わせるのが、この構成のいちばん大事な記録です。 Aの人とCの人で、実際に来なかった割合がどれだけ違うかを月に1回見ます。差が無ければ、点数表が当たっていません。