採用のエントリーフォームの志望動機と自己PRを応募者ごとに要約し、面接官が事前に読む1枚にそろえて届ける

処理の起点を決める

起点は2つあります。 1つ目は、回答のスプレッドシートに置くフォームの送信のトリガーです。応募が届いたその場で要約を作るので、採用課が面接の日程を決めるころには要約ができています。

2つ目は、1時間ごとの時間主導型のトリガーです。回答のシートで採用課が「確認済み」の印を付けた応募者のうち、まだ文書を作っていないものを拾い、1枚の文書を作って店長に知らせます。印を付けた瞬間に動かさないのは、採用課が要約を直している途中で文書ができてしまうのを避けるためです。 1時間あれば、直しは終わっています。

フォームの送信のトリガーで失敗したときは、その行に「要約未作成」と書き、時間主導型のトリガーが次の回にもう一度作ります。 失敗の概要はメールでも届きます。

応募は、求人の広告を出した直後の夜に集中します。 同時に何十件も届くと、フォームの送信のトリガーも同時に動きます。1件ずつ独立して動くので処理そのものは問題ありませんが、要約を書き込む列を行の番号で決めておかないと、別の応募者の行に書き込むおそれがあります。 書き込み先は、イベントの range が指す行に限ります。

入力データを集める

AIに渡すのは、志望動機・自己PR・職歴の欄と、希望の職種の説明だけです。 氏名、生年月日、住所、電話番号、メールアドレスは渡しません。要約に名前は要らず、応募の番号で行と結び付けられます。

職種の説明を渡すのは、面接で確かめたい点を職務に結び付けるためです。 鮮魚の担当を希望する応募者の「確かめたい点」は、自己PRのどの経験が鮮魚の仕事に関わるかで決まります。職種の説明が無いと、確かめたい点が人柄の話に流れます。

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

フォームの送信のトリガーのイベントから、namedValues で質問の名前ごとに値を取ります。列の位置で取らないのは、フォームの質問を足したり並べ替えたりすると、列がずれるからです。 質問の名前が変わったときに気づけるよう、必要な名前が見つからなければ処理を止めて採用課に知らせます。

Claude API の鍵はスクリプト プロパティに置き、UrlFetchApp で呼びます。 muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、送り直すかを決めます。

AIへ渡す前に整形する

1. 空欄と字数の確認 … 志望動機と自己PRがどちらも空なら、AIに渡さず「記載なし」とします。どちらかが50字未満なら、要約せず原文をそのまま載せます
2. 連絡先の除去 … 自由記述の中に書かれた電話番号・メールアドレス・URLを、正規表現で「（連絡先）」に置き換えます
3. 氏名の除去 … 応募者の氏名が本文に出てくれば「応募者」に置き換えます
4. 職種の説明の添付 … 希望の職種の説明を、職種の設定のシートから引いて添えます
5. 重複の確認 … 同じメールアドレスから30日以内に2回目の応募があれば印を付け、要約は新しいほうだけで作ります
6. 文字の整え … 全角と半角の英数字、連続した改行と空白をそろえます。原文の欄に載せる文章は整える前のものを使います

2番目と3番目は、志望動機の中の連絡先や氏名をAIに渡さないための処理です。 「詳しくは私のブログ（URL）をご覧ください」のように、自由記述に個人を特定できる情報が書かれることがあります。要約には要らない情報なので、渡す前に消します。 消した数はログに残し、原文の欄にはそのまま載せます。

1番目で短い文章を要約しないのは、短い文章を要約すると、AIが言葉を足すからです。 「接客が好きです」の1行を要約させると、「接客を通じてお客様に喜ばれることにやりがいを感じている」のような、本人が書いていない文になります。50字未満は原文のほうが正確です。

AIに処理させる

させるのは3つです。 決まった項目への要約、職務に関係の無い記載の有無の見分け、面接で確かめたい点の候補です。

最後の行で、中身は書かせません。 「家族に関する記載あり」という区分だけを返させ、何が書かれていたかは要約にも区分にも残しません。 採用課はその区分を見て、原文の該当箇所を自分で確かめます。区分の並びは、厚生労働省が就職差別につながるおそれがあるとして挙げる事項に合わせています。

要約から外すだけでは足りません。 確かめたい点の候補にも、それらの事項に触れる問いを出させません。「ご家族の介護との両立は大丈夫ですか」は、志望動機に書かれていても、面接で聞くべきではない問いです。 勤務の条件を確かめたいなら、「希望の勤務の曜日と時間帯を教えてください」のように、本人の働き方だけを問う形にします。

いちばん起きやすい失敗は3行目です。 自己PRに「アルバイトで売場を任されていました」とだけあると、AIは「売場の運営や在庫の管理の経験がある」と広げて書きがちです。面接官はそれを前提に聞き、応募者は書いていないことを聞かれます。

指示内容を固定する

あなたは小売業の採用課で、面接官が事前に読む資料を作る立場です。
応募者がエントリーフォームに書いた志望動機・自己PR・職歴を、決まった項目に要約してください。
応募者を評価するのではなく、面接で本人の言葉を確かめるための材料を作ります。

【項目】
1. reasons: 志望の理由（なぜ当社か、なぜこの職種か）を最大3つ
2. connection: 当社・店舗との接点として本人が書いたこと
3. strengths: 本人が挙げた強みを最大3つ。それぞれ裏づけとして書かれた経験を添える
4. questions: 面接で確かめたい点を最大3つ。希望の職種の仕事と、本人が書いた経験を結び付ける問いにする
5. sensitive_categories: 職務に関係の無い記載があれば、その区分だけを挙げる

【厳守事項】
- 本人が書いていないことを足さないでください。経験の規模や期間を推測で補わないでください。
- 書かれていない項目は null にしてください。
- 各項目の evidence には、元にした文を原文からそのまま写してください。
- 合否、点数、順位、人柄や性格の評価を書かないでください。
- 文章の上手下手に触れないでください。
- 次の事項に関する記載は、要約にも evidence にも questions にも入れないでください。
  区分の名前だけを sensitive_categories に入れてください。
  family（家族の職業・続柄・健康・病歴・学歴・収入など）/ domicile（本籍・出生地）/
  housing（住宅の状況）/ living_env（生活環境・家庭環境）/ religion / politics /
  beliefs（人生観・思想）/ respected_person / reading（購読紙・愛読書）/
  union_movement（労働組合・社会運動）/ health
- questions に、上の事項に触れる問いを出さないでください。働き方の条件は、本人の希望する曜日・時間・勤務地だけを問う形にしてください。

【希望の職種と仕事の説明】{job_description}
【職歴】{career}
【志望動機】{motivation}
【自己PR】{self_pr}

区分の名前を英語の記号で列挙しているのは、スキーマの enum と同じにするためです。 指示の文とスキーマの選択肢が一致していれば、区分の付け方がぶれません。

「questions に、上の事項に触れる問いを出さない」を別の行に書くのが要点です。 要約から外すことだけを指示すると、AIは確かめたい点のほうで「ご家族のご理解は得られていますか」と拾い直すことがあります。

出力形式を固定する

次の形のJSONで受け取ります。 sensitive_categories の要素は区分を enum で列挙します。

{
  "application_id": "E-2026-10-0412",
  "reasons": [
    { "text": "地元の店舗で長く買い物をしてきた", "evidence": "" }
  ],
  "connection": { "text": "", "evidence": "" },
  "strengths": [
    { "text": "", "experience": "", "evidence": "" }
  ],
  "questions": [
    { "text": "", "linked_strength": 0 }
  ],
  "sensitive_categories": ["family"]
}

1つ目の理由は、evidence を原文と照らせることです。 スクリプトは各 evidence の文字列が、渡した原文に実際に含まれているかを確かめます。含まれていなければ、その項目を消し、採用課の確認の欄に「根拠の照合に失敗」と書きます。 本人が書いていない言い回しの混入は、ここで止まります。

2つ目は、sensitive_categories が空でない応募者を、シートで目立たせられることです。 採用課はその応募者だけ原文を開き、要約や確かめたい点にその事項が漏れていないかを見ます。スクリプトも、要約の文に「父」「母」「家族」「宗教」などの語が含まれていないかを照らし、含まれていれば確認済みの印を付けられないようにします。

3つ目は、項目の数をスクリプトで確かめられることです。 reasons、strengths、questions が4つ以上なら、先頭の3つだけを使います。数の制約はスキーマに書けないので、受け取った後で切ります。

1枚の文書には、次の順で並べます。

システムへ連携する

フォームの回答そのものには手を入れません。 要約は横の列に書き、原文は残します。店長に付けるのは閲覧の権限だけで、編集はさせません。

店長への知らせのメールには、応募者の氏名も要約も書きません。 書くのは応募の番号、面接の日時と店舗、文書のリンクだけです。メールは転送されやすく、本文に要約を書くと、権限を外した後もメールの中に残ります。 中身は権限を付け外しできる文書の側にだけ置きます。

文書は、応募者ごとに面接の月のフォルダに作ります。 フォルダ単位で保存の期間を決められるので、消す日が来たときに月のフォルダごとに確かめられます。

人が確認する

1. sensitive_categories のある応募者を先に見る … 原文の該当箇所を確かめ、要約と確かめたい点に漏れていないかを見ます。1枚の原文の欄で、その箇所を伏せるかを決めます
2. 根拠の照合に失敗した応募者を見る … 消えた項目を、原文から採用課が書き足すかを決めます
3. 残りの要約を流し読む … 原文と比べて、強みの経験が膨らんでいないかを見ます
4. 確認済みの印を付ける … 印の無い応募者の文書は作られません
5. 面接が終わったら権限を外す … 店長の閲覧の権限は、面接の結果が届いた時点で外します

1番目の「伏せる」は、応募者の文章を書き換えることではありません。 文書の原文の欄でその段落を「（採用課で確認済みのため省略）」とし、回答のシートの原文はそのまま残します。

目標は、360件をならして1件2分です。 区分の無い応募者は要約を流し読んで印を付けるだけ、区分のある応募者は原文を開くので数分、という想定です。

例外に対処する

6行目の語の照合は、取りこぼしを前提にした二重目の網です。 「実家の店を手伝ってきた」のように、家族の語を使わずに家族の事情を書く文章もあります。語の照合で止まらなくても、sensitive_categories が空でない応募者は採用課が原文を開くので、そこで拾います。

応答の拒否は、志望動機に病歴や心身の事情が詳しく書かれているときに起きることがあります。 その応募者は採用課が手で申し送りを書き、健康に関する記載を面接官に渡さない扱いを確かめます。

記録を残す

• 応募の番号、要約を作った日時、渡した字数
• 要約の結果と sensitive_categories
• 根拠の照合に失敗した項目と、採用課が直した記録
• 確認した担当者と日時、原文の欄で伏せた段落の有無
• 文書を作った日時、閲覧の権限を付けた店長と、外した日時

採用課が直した記録が、指示を直す材料になります。 強みの経験を膨らませた直しが多いなら、指示の「推測で補わない」が効いていません。

sensitive_categories の区分ごとの件数も月ごとに数えます。 特定の区分が多いなら、フォームの欄の説明か、採用サイトの文言が応募者にそれを書かせている可能性があります。ログに残すのは区分と件数だけで、該当した文章は残しません。