人材紹介会社のWebの登録フォームに届く求職者の経歴と希望を要約し、初回面談の準備メモと確認したい点をキャリアアドバイザーに送る

処理の起点を決める

登録フォームの送信を、Make の Custom webhook で受けます。 フォームの送信先に Make が発行する URL を設定し、送信のたびに中身が届くようにします。Webhook のリクエストは、クエリの値と本文が1つのまとまり（バンドル）としてシナリオに渡されます。

台帳への行の追加（Watch New Rows）を起点にしない理由は、速さです。 スプレッドシートの新しい行を見張る方式は、一定の間隔で確かめに行く形になります。登録から2営業日以内に面談という約束を守るには、登録の直後に準備メモが担当の手元にあるほうがよいので、送信と同時に動く Webhook を選びます。

1件ごとに動かします。 夜間や休日の登録も、その場で準備メモを作り、翌営業日の朝にはアドバイザーの Slack に届いている状態にします。

Webhook のキューには上限があります。 月あたりのクレジットの量に応じて1つの Webhook のキューに置ける件数が決まり、最大で10,000件です。シナリオを止めている間に登録がたまっても、上限までは失われずに残ります。

入力データを集める

AIに渡さないものを先に決めます。 氏名、生年月日、連絡先は、要約にも問いにも要りません。Claude に渡すのは、職歴・学歴・資格・希望条件・ご要望の欄だけにし、年齢が必要な観点（若手向けの求人の対象かなど）は、ワークフローの側で年齢の区分にしてから渡します。

質を決めるのは、確認したい点の観点の一覧です。 経験の長いアドバイザーが面談で必ず確かめていることを、「期間に3か月以上の切れ目がある」「希望年収が現年収より3割以上高い」のように、条件の形で書き出します。 これが (b) のばらつきをそろえる作業そのものです。

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

台帳と担当表を探すのは、Make の Google Sheets の Search Rows のモジュールです。探す条件を指定し、AND と OR で条件を組み合わせられます。1回の実行で返す件数の上限も設定できるので、過去の登録を探すときは新しいものから数件に絞ります。

過去の登録が見つかったときは、前回の面談の記録の有無だけを添えます。 前回の記録の中身を Claude に渡すと、前回の面談で聞いたことと今回の登録が混ざった要約になります。 前回の記録はアドバイザーが台帳で直接読みます。

担当表に希望職種が無いときは、事務の担当に回します。 「営業事務とマーケティング」のように2つの職種を書く登録もあり、どちらを優先するかは担当表の側で決めておきます。

AIへ渡す前に整形する

1. AIに渡す欄を絞る … 氏名・生年月日・連絡先を除いた欄だけを、Claude へのまとまりにします
2. 年齢の区分にする … 生年月日は渡さず、必要な観点のためだけに区分にします
3. 欄の名前を付ける … 「【職歴】」「【希望年収】」のように、欄ごとに見出しを付けてつなげます
4. 空の欄を明示する … 空の欄は「（記入なし）」と書いて渡し、書かれていないことをAIが見分けられるようにします
5. ご要望の欄の確認 … ご要望に、家族・出身・信条などの記述があっても、そのまま渡し、指示の側で準備メモに写さないよう止めます
6. 重複の確認 … 同じ連絡先から24時間以内に同じ内容が届いていれば、二度目は準備メモを作りません

4番目を省くと、「現年収」が空の登録で、AIが希望年収から現年収を推し量って書きます。 空の欄は空のまま渡すのではなく、空であることを文字で伝えます。

5番目で欄を消さないのは、消すとご要望の中の仕事の希望まで消えるからです。 1つの文の中に「親の介護があるので残業の少ない職場を」と書かれていれば、残業の少ない職場という希望は残し、介護の事情は準備メモに写さない、という扱いが要ります。これは指示で止めます。

AIに処理させる

させるのは、4つの塊を作ることです。

右端の列が大事です。 職歴の期間を年月に直すとき、「3年ほど」を「2021年4月〜2024年3月」と書いてしまうと、後で面談の記録と食い違います。 書かれた期間があいまいなら、あいまいなまま写し、確認したい点に「在籍期間の年月」を挙げます。

3行目がいちばん気をつけるところです。 職歴に切れ目があると、AIは「ご家族の事情か、ご病気か」と理由の候補を挙げがちです。問いは「この期間について、差し支えない範囲でお聞かせください」の形にそろえ、理由の候補を書かせません。

指示内容を固定する

あなたは人材紹介会社のキャリアアドバイザーが、初回の面談の前に読む準備メモを作る立場です。
次の登録内容だけを根拠にしてください。書かれていないことを補わないでください。

【作るもの】
1. career_timeline：会社ごとに、在籍期間・職種・雇用形態を古い順に並べる
   期間があいまいな場合（「3年ほど」など）は、年月に直さず書かれたまま写す
2. experience_summary：担当した業務、扱った商材や仕組み、役割を3〜5行で
3. preferences：希望職種、希望年収、希望勤務地、転職の希望時期、働き方の希望
   書かれていない項目は「記入なし」とする
4. check_points：次の観点に当たる箇所について、面談で聞く問いを作る
   {check_rules}
   観点に当たらない場合は挙げない

【問いの作り方】
- 期間の切れ目については「この期間について、差し支えない範囲でお聞かせください」
  という形だけにしてください。理由の候補を挙げないでください。
- 問いは、仕事の経験と希望条件に関することだけにしてください。

【厳守事項】
- 求職者を評価する言葉（向いている、経験が浅い、転職が多い など）を書かないでください。
- 紹介できる求人や、採用の見込みを書かないでください。
- 家族、出身地、本籍、国籍、宗教、思想・信条、労働組合、健康状態に関することは、
  登録内容に書かれていても、準備メモのどこにも写さないでください。
  書かれていた場合は has_sensitive を true にするだけにしてください。
- 経験や資格を、職種から想像して足さないでください。
- 「（記入なし）」の欄を、他の欄から推し量って埋めないでください。
- JSONだけを返してください。説明の文を付けないでください。

【年齢の区分】{age_band}
【登録内容】{registration_text}

has_sensitive を置くのは、写さないことと、気づかないことを分けるためです。 写すなと言うだけでは、AIは要約の中で言い換えて残すことがあります。フラグにだけ立てさせ、中身はどこにも書かせない形にすると、アドバイザーは「登録内容の原文に触れてはいけない記述がある」ことだけを知った状態で面談に入れます。

「JSONだけを返す」も外せません。 前置きの文が付くと、後段の Parse JSON が失敗します。

出力形式を固定する

{
  "career_timeline": [
    { "company": "", "period": "", "role": "", "employment": "" }
  ],
  "experience_summary": "",
  "preferences": {
    "job": "", "salary": "", "location": "", "timing": "", "work_style": ""
  },
  "check_points": [
    { "rule": "期間の切れ目", "evidence": "", "question": "" }
  ],
  "has_sensitive": false
}

受け取った文字列は、Make の JSON アプリの Parse JSON で項目に分けます。 Parse JSON はデータ構造（data structure）で JSON の形を定め、各項目を後のモジュールでそのまま使えるようにします。 データ構造を先に作らなくても、一度モジュールを動かせば、渡された JSON から Make が構造を組み立てます。

1つ目の理由は、準備メモのシートの列にそのまま書き込めることです。 時系列、要約、希望条件、確認したい点を別々の列に入れれば、アドバイザーは台帳の上で必要な列だけを見られます。

2つ目は、check_points に evidence を持たせていることです。 問いだけでなく、登録内容のどの記述からその問いが出たかを原文のまま並べます。アドバイザーは原文を探さずに、問いが妥当かを確かめられます。

3つ目は、has_sensitive で扱いを分けられることです。 true のときは、Slack の通知に「原文に配慮の要る記述あり。面談で触れないこと」とだけ添えます。

準備メモのシートの列は、次のとおりです。

システムへ連携する

Router は、1つの流れを条件ごとの複数の道に分けます。 道は同時ではなく順に処理され、1つ目の道を終えてから2つ目に進みます。 順番は自分で決められ、どの条件にも当たらないものを受ける予備の道（fallback route）は最後に処理されます。 Parse JSON が失敗したものを予備の道で受け、事務の担当に原文のまま回します。

Slack は、担当のアドバイザーへのダイレクトメッセージで送ります。 部署のチャンネルに送ると、担当でないアドバイザーにまで求職者の経歴が流れます。 送るのは要点（職歴の会社数と期間、希望職種、確認したい点の数）と台帳へのリンクだけにし、本文に経歴の全文を書きません。

【新規登録】登録番号 R-20261007-0123（10/7 21:14）
担当：〇〇さん　初回面談の目安：10/9 まで
職歴：3社・通算 約9年（最新：法人営業）
希望：営業企画／年収 記入あり／勤務地 都内／時期 3か月以内
確認したい点：3件（期間の切れ目 1、年収の差 1、在籍期間の年月 1）
準備メモ：台帳の「準備メモ」シートの該当行

通知には、確認したい点の件数だけを出し、問いの中身は出しません。 通知の文面は、移動中の端末の画面などで人目に触れやすいものです。問いの中身は、台帳を開いた人だけが読めるようにします。

人が確認する

1. 準備メモを原文と見比べる … 時系列の期間と会社名が原文と合っているかを確かめます
2. 確認したい点を足し引きする … 観点に当たらなかったが聞きたいことを足し、不要な問いを消します
3. has_sensitive が true のときは原文を読む … 面談で触れないことを確かめ、準備メモに写っていないかも見ます
4. 面談の後に、確認したい点の答えを台帳に書く … 準備メモの列ではなく、台帳の面談の記録に書きます

1番目を省かないでください。 期間の読み違いは、推薦の書類まで引き継がれると、求人企業に誤った経歴を伝えることになります。 準備メモは下ごしらえで、記録の元ではありません。

目標は、400件をならして1件6分です。 要約が原文と合っていれば数分で確かめ終わり、時系列が複雑な登録や、確認したい点を書き足す登録に時間を使います。

例外に対処する

上から2行目が、件数のいちばん多い例外です。 「3年ほど」「数か月」のような書き方は珍しくなく、ここを年月に直さないと決めておくことが、準備メモの信頼を保ちます。

記録を残す

• 登録の番号と、Claude に渡したまとまり（氏名・連絡先を除いたもの）
• Claude が返した JSON の全文
• 準備メモのシートの行と、アドバイザーが確認した日時、足し引きした問い
• has_sensitive が立った件の数（中身は残さない）
• 予備の道に入った件と、その理由

3つ目を残すのは、観点の一覧を直すためです。 アドバイザーが毎回足している問いがあれば、それは観点の一覧に足すべきものです。 毎回消している問いがあれば、観点の条件が広すぎます。

準備メモのシートにも保存の期間を決めます。 指針は、収集目的に照らして保管する必要がなくなった個人情報を破棄・削除するための措置を求めています。面談が終わり、台帳の面談の記録に必要なことを書いた準備メモは、決めた期間で消します。