その日に面接がある面接官へ、候補者ごとの応募書類の要点・前の選考の評価・確かめるべき点を1通にまとめて毎朝送る

処理の起点を決める

トリガーは2つです。 夕方のトリガーは timeBased()・everyDays(1)・atHour(18) で作り、翌日の面接の要約を作ります。朝のトリガーは atHour(7) で作り、当日の予定を見直して送ります。土日と会社の休日は、休日の一覧のシートを見て、スクリプトの最初で何もせずに終わります。

要約を夕方に作るのは、実行時間と失敗に備えるためです。 公式の割り当てでは、1回の実行は6分までです。1日8件の面接について、PDFを読ませて要約を作ると、1件に数十秒かかります。朝にまとめて作ると、6分に近づき、失敗したときに面接に間に合いません。 夕方に作っておけば、失敗しても採用チームが退勤前に気づけます。

夕方より後に入った面接は、朝のトリガーで拾います。 朝の見直しで、setTag() の印の無い予定を見つけたら、その場で要約を作ってから送ります。当日の朝に入れた面接や、当日の昼の面接の予定が午前中に入ったときは、採用チームがメニューから「この面接だけ送る」を実行します。

同じ候補者・同じ段階の要約は、作り直しません。 面接の日時が変わっただけなら、要約のシートの行をそのまま使います。前の段階の評価が後から追加されたときだけ、作り直します。 評価の更新日時を要約のシートに持たせ、台帳の評価の更新日時と比べます。

入力データを集める

質を決めるのは、前の段階の評価の「次の面接で確かめてほしい点」の欄です。 この欄が書かれていれば、要約の「確かめるべき点」は前の面接官の言葉から始まります。空欄が多いと、要約は書類の読み取りだけで確かめる点を作ることになり、前の面接官の意図がつながりません。 欄の説明に「1つは書いてください」と添えるだけで、つながり方は変わります。

職種の求める要件を渡すのは、経歴の要点の並べ方をそろえるためです。 要件に関係する経歴から並べるので、面接官によって見ている経歴が違う、という第3章の（c）が減ります。

評価の面接官の名前は渡しません。 「一次（開発部の管理職）」のように段階と役職だけを渡します。次の面接官が、前の面接官の人柄で評価を読み替えないようにするためです。

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

処理は、次の順で行います。

1. 翌日の「【面接】」で始まる予定を取り、名前から候補者の番号・段階・職種を取る
2. 台帳で選考の状態を見て、辞退・見送りなら要約を作らず採用チームに知らせる
3. 要約のシートに同じ候補者・段階の行があり、評価の更新が無ければ使い回す
4. 候補者のフォルダからPDFを取り、合計の大きさとページ数を確かめる
5. 前の段階の評価を、段階と役職を付けて並べる（名前は外す）
6. Claude API を呼び、JSON を受け取る
7. 根拠のページ番号がPDFのページ数の範囲にあるかを確かめる
8. 要約のシートに書き、予定に setTag() で印を付ける
9. 適性と関係のない記述の印があれば、採用チームにだけ知らせる

4番目で大きさを確かめるのは、PDFの制限のためです。 1回の要求は32MBまでなので、スキャンの画像が重い書類は、採用チームが圧縮して置き直すよう知らせ、要約は作らずにリンクだけで送ります。

AIへ渡す前に整形する

1. 予定の名前を正規化する … 全角と半角、「二次」と「2次」の表記をそろえ、候補者の番号を取り出します
2. 社外の招待者を外す … 招待者のうち、面接官の一覧に無いアドレス（候補者本人など）には送りません
3. 評価から名前を外す … 段階と役職だけを残します
4. 要件を職種で引く … 職種の要件のシートから、応募の職種の必須と歓迎の要件を取ります
5. パスワード付きのPDFを除く … 開けないPDFは渡さず、採用チームに知らせます

2番目を省かないでください。 面接の予定には、オンラインの面接のために候補者本人を招待していることがあります。招待者の全員に送ると、候補者に自分の評価の要約が届きます。 送り先は、必ず面接官の一覧と突き合わせて決めます。

3番目で名前を外しても、役職は残します。 「一次（開発部の管理職）」と「一次（人事部）」では、同じ「懸念あり」でも見ている点が違うからです。役職は評価の読み方の手がかりになりますが、名前は手がかりではなく先入観になります。 面接官が前の面接官に直接聞きたいときは、採用チームに頼んでつないでもらう運用にします。

AIに処理させる

させるのは、応募書類と前の段階の評価を読み、面接官が面接の前に知っておくべきことを、3つの欄に要約することです。

確かめるべき点は、出どころを必ず付けさせます。 前の面接官の持ち越し事項なら carried_over、書類で分からない点なら document_gap です。面接官は、前の面接官から頼まれた点を先に確かめられます。

3行目が、この構成でいちばん守るべきことです。 書類に「実家の家業を継ぐ予定だったが」「家族の転勤で」と書かれていると、AIは経歴の流れとして要約に入れがちです。家族や出身地に関わる記述は要約に入れず、excluded_notice に「書類に家族に関する記述あり」とだけ返させます。 中身は写させません。

指示内容を固定する

あなたは会社の採用チームで、面接官が面接の前に読む要約を作る担当です。
合否の判断はしません。面接で何を聞くかも決めません。

【入力】
- 応募書類（履歴書・職務経歴書のPDF）
- 応募の職種と、その必須・歓迎の要件
- 今回の面接の段階
- 前の段階の評価（段階と面接官の役職、総合の評価、良かった点、懸念、
  次の面接で確かめてほしい点）

【してほしいこと】
1. 経歴の要点：要件に関係する経歴を3〜5つ、各60字以内で。
   根拠のページ番号を必ず付ける
2. 前の評価の要点：段階ごとに、良かった点と懸念を各1〜2文で
3. 確かめるべき点：前の評価の「次の面接で確かめてほしい点」を先に、
   書類から分からない点を後に、合わせて5つまで。
   出どころを carried_over か document_gap で示す

【厳守事項】
- 書類に書かれていない経歴、年数、役割を推測しないでください。
  分からないことは「書類からは分からない」としてください。
- 次の事項に関わる記述は、要約のどの欄にも書かないでください。
  本籍・出生地、家族、住宅状況、生活環境・家庭環境、宗教、
  人生観・生活信条、思想、購読新聞・雑誌・愛読書、支持政党、
  尊敬する人物、労働組合・社会運動、健康・病歴。
  書類にこれらの記述があれば、excluded_notice に
  「書類に〇〇に関する記述あり」とだけ書いてください。中身は写さないでください。
- 合否の見込み、推薦、質問の文を書かないでください。
- 前の評価を強めたり弱めたりしないでください。書かれた評価の範囲で要約してください。

【応募の職種と要件】{requirements}
【今回の段階】{stage}
【前の段階の評価】{evaluations}

事項を列挙しているのは、「差別につながる事項」と書くだけではAIが範囲を決められないからです。 厚生労働省のページの14事項から、書類に書かれうるものを並べ、健康・病歴を足しています。 列挙が無いと、AIは「家族の転勤」を経歴の流れとして必要な情報だと判断して要約に入れます。

「中身は写さない」も大事です。 何の記述があったかを詳しく書けば、それ自体が面接官に届く情報になります。採用チームへの知らせは種類だけにし、必要なら採用チームが書類を見ます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "candidate_no": "",
  "stage": "",
  "career_points": [
    { "text": "", "pages": [0] }
  ],
  "evaluation_points": [
    { "stage": "", "role": "", "strength": "", "concern": "" }
  ],
  "check_points": [
    { "text": "", "source": "carried_over | document_gap" }
  ],
  "excluded_notice": [""]
}

スキーマでは source を enum で縛り、オブジェクトに additionalProperties: false を付けます。pages の番号がPDFのページ数の範囲にあるかは、受け取ったあとにスクリプトで確かめます。 範囲外の番号が付いた要点は、メールに載せる前に落とします。

理由の1つ目は、面接官ごとの1通に束ねやすいことです。 候補者ごとの JSON を、面接官ごとに開始の時刻の順で並べるだけで1通ができます。束ね方はスクリプトの側で決めるので、メールの体裁を後から変えても要約は作り直しません。

2つ目は、excluded_notice を別の宛先に分けられることです。 この欄は面接官へのメールには載せず、採用チームへの知らせにだけ使います。 自由文の要約の中に混ざっていると、分けられません。

面接官に届くメールは、次の形です。

【本日の面接 3件】10月13日（火）
■ 10:00〜11:00　C-0412　二次　バックエンドエンジニア　［会議のリンク］
  経歴の要点
   ・決済のバックエンドを5年、うち2年はチームの技術の責任者（p.2）
   ・社内の監視の仕組みの立ち上げを担当（p.3）
  前の評価
   ・一次（開発部の管理職）：設計の説明は具体的。懸念は大規模の運用の経験
  確かめるべき点
   ・同時アクセスの多い環境の運用の経験の深さ［一次からの持ち越し］
   ・直近の1年の役割（書類からは分からない）
  書類：［PDFのリンク］　評価シート：［フォームのリンク］
■ 14:00〜15:00　C-0398　一次　カスタマーサクセス …
※ 要約は準備の材料です。書類と違う点があれば書類を正としてください。

システムへ連携する

API キーはスクリプトのプロパティに置き、スクリプトの編集の権限は採用チームに絞ります。 公式の割り当てでは、URL Fetch の呼び出しは Google Workspace のアカウントで1日10万回、メールの宛先は1日1,500で、1日に十数通を送るこの構成では余裕があります。

候補者台帳と評価には書き込みません。 要約は要約のシートにだけ書きます。評価シートに要約を書き戻すと、次の段階の面接官が、AIの要約を前の面接官の評価として読んでしまいます。

人が確認する

1. 採用チームが、夕方の知らせを見る … 適性と関係のない記述があった候補者、要約が作れなかった候補者、辞退・見送りの候補者の予定が残っているものを確かめます
2. 書類の記述は、面接官に伝えない … excluded_notice の候補者は、面接官のメールにはそのまま要約を載せ、記述があったことは採用チームの中で扱います
3. 面接官は、要約と書類が違えば書類を正とする … 違いに気づいたら、採用チームに返信で知らせます
4. 採用チームは、違いの知らせを要約のシートに記録する … 月に一度、どんな違いが多いかを見ます

目標は、160件をならして1件3分です。 面接官が1通を読むのに1件あたり2分、気になる点で書類の該当ページを開くのに1分です。要約が作れなかった面接は、今までどおり書類を開くので12分かかります。

例外に対処する

6行目の面接官の差し替えは、朝の見直しでしか拾えません。 夕方の時点の招待者で宛先を決めてしまうと、差し替えられた面接官に前の日の分が届き、新しい面接官には何も届きません。 宛先は必ず朝の招待者で決めます。

4行目は、前の日の夕方に気づければ間に合います。 一次の面接が当日の夕方にあり、翌朝に二次がある、という日程では、評価の入力が翌朝の送信に間に合いません。採用チームは夕方の知らせで「未入力」を見て、一次の面接官に入力を頼みます。

記録を残す

• 要約のシート：候補者、段階、要約の JSON、作った日時、使った評価の更新日時
• 送ったメールの日時、宛先、載せた候補者の番号
• excluded_notice が出た候補者と、採用チームが確かめた日時
• 要約と書類の違いの知らせ
• AIの呼び出しの失敗の記録

要約のシートの保存の期間は、候補者台帳と同じ決まりにします。 選考が終わった候補者の要約は、台帳の削除の決まりに合わせて消します。要約だけが残り続けると、不採用の候補者の情報を必要以上に持つことになります。