人材紹介会社との定例の打合せの Teams の記録から、職種ごとの推薦の状況・依頼事項・宿題を要約し、エージェント管理表の更新案を作る

処理の起点を決める

打合せが終わり、文字起こしが保存されたことを起点にします。 会議の後に Copilot に質問するには、文字起こしが必要とされています。文字起こしを開始し忘れた打合せは、この構成に乗りません。

文字起こしの開始を忘れないように、採用担当に当てる会議ポリシーで Copilot の設定を「On with saved transcript required」にします。 これが既定の値で、主催者の会議オプションの Copilot が「会議中と会議後」に固定され、主催者は変えられないとされています。採用担当が主催する定例はすべてこのポリシーの下で作られます。

動かすのは採用担当の手作業です。 打合せの終了を検知して自動で要約を作る仕組みは作りません。打合せの後15分以内に、会議のチャットの Copilot に決めた指示を送る、という運用の決まりにします。隔週の定例は曜日と時刻が決まっているので、採用担当の予定表に打合せの直後15分の枠を毎回取っておきます。

打合せの冒頭で、文字起こしを開始することをエージェントの担当者に伝えます。 社外の参加者にとっては、自社の会話が相手の会社の記録に残ることになります。伝えてから開始する、を定例の最初の手順にします。 断られた場合の扱いは例外処理に書きます。

入力データを集める

質を決めるのは、2行目の議題の一覧です。 Teams 会議の Copilot は、文字起こしがある場合、会議の24時間前までのチャットを文字起こしとあわせて材料にするとされています。前日のうちに貼るのは、この範囲に入れるためです。 2日前に貼ると範囲から外れます。

議題の一覧は、たとえば次のように貼ります。

【10/8 定例（A社）議題　職種4件】
BE-02 バックエンドエンジニア（決済）　前回の依頼：想定年収の幅を伝え直す
CS-01 カスタマーサクセス　前回の依頼：英語の要件を外した旨の周知
SL-03 法人営業（製造業向け）　前回の依頼：なし
DS-01 データアナリスト　新規に依頼

冒頭に職種の件数を書いておくのは、拾い漏れを数で見つけるためです。 議題の一覧の件数と、要約の職種の行数がそろえば、話した職種がすべて拾われたと分かります。

4つ目の職種コード表が、言い換えを吸収します。 打合せでは「決済のほう」「BEの2つ目」「サーバーサイド」のように、同じ求人がいくつもの呼び方で話されます。職種コード表に社内とエージェントの呼び方の言い換えを並べておけば、要約が職種コードにそろいます。

議題の一覧にも打合せの中でも、候補者の氏名は使いません。 推薦された候補者は採用管理の仕組みの受付番号で呼びます。文字起こしに残る個人名が減り、聞き違いも減ります。

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

会議の Copilot は、打合せの後に会議のチャットか「まとめ」のタブから開けます。 応答には、使った情報源が示されるとされています。要約の各行に付いた引用から、文字起こしの該当箇所に戻れます。

エージェント管理表は、リスト自体のURLで指定します。 サイトを指定しても、そのサイトのリストは含まれないとされています。リストの共有のリンクから、絞り込みやグループ化をしていないリストそのもののURLを取って貼ります。

リストの列の値は、できるだけ選択肢で固定します。 職種コードは選択肢、依頼事項の状態は「依頼中・回答済み・取り下げ」、宿題の持ち主は「自社・エージェント」と決めておけば、更新案の値もその言葉で出ます。 自由入力の列だと、更新案と現在の値の比べようがありません。

AIへ渡す前に整形する

1. 定例の主催者を採用担当にそろえる … エージェント側の招待で開いている定例を、自社主催の予定に作り直します
2. 議題の一覧を前日に会議のチャットへ貼る … 職種コード・求人名・前回の依頼事項の3つを並べます
3. 冒頭で文字起こしの開始を伝え、話す職種の件数を言う … 「今日は4件です」
4. 終わりに依頼事項と宿題を読み上げる … 持ち主・内容・期限を一文で言います
5. 管理表の行を最新にしておく … 新しく任せた求人の行を、打合せの前に足しておきます

どれも、打合せの進め方の決まりです。 システムの前処理ではなく、人が打合せの前と中で行う前処理です。この構成では、ここを整えるほうが指示文を工夫するより効きます。

4番目の読み上げは、慣れるまで採用担当が言い直します。 エージェントの担当者が「承知しました、確認します」で終えたら、採用担当が「では、BE-02の推薦2名の希望年収を、御社から来週水曜までに、でよろしいですか」と受けます。数回の定例で、エージェントの担当者の側から同じ形で言うようになります。

1番目を省くと、この構成は始まりません。 エージェントの担当者が慣れている会議の仕組みから自社の Teams に移ってもらうことになるので、最初の定例で一度だけ理由を説明します。 「打合せの記録をきちんと取り、頼んだことの返事を追えるようにするため」で十分です。

AIに処理させる

させるのは、打合せで言葉にされたことを職種ごとに並べ替えて要約し、管理表と比べることだけです。

2行目の「候補者の反応の傾向」は、個人ではなく職種の単位で要約させます。 「BE-02の候補者は、想定年収の上限を気にする人が多い」は職種の話として残し、受付番号の付いた個人の事情は書かせません。 個人の事情は採用管理の仕組みの候補者の記録に残すものです。

宿題の持ち主がいちばん大事です。 「確認しておきます」の発言者がエージェントの担当者なら、宿題の持ち主はエージェントです。ただし、採用担当が「では御社で」と受けた場合と、エージェントが自発的に言った場合で、文字起こしの見え方が違います。 発言者と、受けた側の返事の両方が無ければ「持ち主が不明」にさせます。

指示内容を固定する

会議のチャットの Copilot に送る指示（要約）

この打合せの文字起こしと会議のチャットだけを見て、
職種ごとに要約してください。

【拾うもの】
- 職種コードごとに：推薦した人数、選考中の人数、辞退、
  エージェントが伝えた候補者の反応の傾向（職種の単位で）。
- 依頼事項：自社がエージェントに頼んだ内容と期限。
- 宿題：持ち主（自社／エージェント）、内容、期限。
- 議題の一覧の「前回の依頼」に返事があったか。

【厳守事項】
- 職種は議題の一覧の職種コードで特定してください。
  特定できない話は「職種不明」の欄に入れてください。
- 数字は発言されたものだけを書いてください。計算や推定をしないでください。
- 宿題の持ち主は、発言者と相手の返事から分かるものだけを書いてください。
  分からなければ「持ち主が不明」としてください。
- 候補者の氏名、年齢、家族、出身地、健康、宗教、思想など、
  採否に関係のない事項は書かないでください。
  そのような発言があった場合は、時刻だけを最後の「注意」に書いてください。
- 各行に、根拠にした発言の時刻を付けてください。

エージェント管理用のエージェントの指示（比較）

あなたは採用担当を手伝い、人材紹介会社との打合せの要約を
エージェント管理表と比べて、更新案を作る立場です。

【入力】採用担当が貼る、打合せの要約（会議の Copilot が作ったもの）
【知識】エージェント管理表（リスト）、職種コード表、要約の様式

【厳守事項】
- 管理表の行は、エージェント名と職種コードの組で特定してください。
- 現在の値と要約の値が違う列だけを並べてください。
  同じ値の列は出さないでください。
- 要約に無いことを、管理表の値から推し量って書き足さないでください。
- 管理表の「依頼中」の依頼事項のうち、要約で返事が無いものを
  「返事の無い依頼」として、依頼した日とともに並べてください。
- 管理表を書き換えないでください。メールも送らないでください。

【出力】
1. 管理表の更新案（エージェント名／職種コード／列／現在の値／更新後の値／根拠の時刻）
2. 返事の無い依頼（職種コード／依頼の内容／依頼した日）
3. エージェントへの依頼事項のメールの下書き（宛先の担当者名は空欄）
4. 社内の宿題の一覧（持ち主／内容／期限）

比較の指示は、エージェントの指示として Agent Builder に書いておきます。 採用担当は要約を貼って「更新案を作って」と頼むだけにします。要約の指示も、採用グループの共有のメモに置き、4名が同じ文を貼ります。 人によって指示が変わると、第3章の（d）の粒度の違いがそのまま戻ってきます。

「計算や推定をしない」を要約の指示に入れているのは、推薦数のためです。 「先週2名、今週も1名お出しして」を「今月3名」とまとめると、月をまたいでいた場合に管理表の数字が狂います。 発言された数字だけを書かせ、合計は人が出します。

出力形式を固定する

要約も更新案も、表の形で返させます。 この構成ではシステムへの自動登録をしないため、JSON ではなく、採用担当が読んで直しやすい表を出力の形にします。

【職種ごとの要約（A社 10/8）】
| 職種コード | 推薦 | 選考中 | 候補者の反応の傾向 | 根拠の時刻 |
| BE-02 | 2名 | 1名 | 想定年収の上限を気にする人が多い | 00:04:10 |
| CS-01 | 0名 | 0名 | 英語の要件を外した旨は周知済み | 00:11:30 |
| DS-01 | 言及なし | 言及なし | － | － |

【依頼事項・宿題】
| 持ち主 | 内容 | 期限 | 根拠の時刻 |
| エージェント | BE-02 推薦2名の希望年収を確認 | 10/14 | 00:26:05 |
| 自社 | DS-01 の求人票を送る | 10/10 | 00:27:20 |
| 持ち主が不明 | SL-03 の面接日程の候補 | － | 00:19:40 |

【管理表の更新案】
| エージェント | 職種コード | 列 | 現在の値 | 更新後の値 | 根拠の時刻 |
| A社 | BE-02 | 今月の推薦数 | 1 | 3 | 00:04:10 |
| A社 | CS-01 | 依頼事項の状態 | 依頼中 | 回答済み | 00:11:30 |

1つ目の理由は、根拠の時刻で文字起こしに戻れることです。 採用担当は時刻から該当の発言を開き、数字と持ち主が本当に言葉にされたかを確かめます。

2つ目は、「持ち主が不明」が独立した行になることです。 第3章の（c）を防ぐために、持ち主の決まらなかった宿題を目に見える形で残します。 この行は、次の定例の冒頭で最初に片付ける議題になります。

3つ目は、更新案が「変わる列だけ」であることです。 4職種の打合せでも、管理表を書き換えるのは数か所です。全行を出すと、どこを直すのかを探す手間が戻ってきます。

システムへ連携する

依頼事項のメールは、下書きを採用担当が直してから送ります。 下書きには、職種コードごとの依頼の内容と期限だけを並べ、宛先の担当者名と挨拶は採用担当が書き足します。 社外へ出る文面なので、AIの文面をそのまま送らない決まりにします。

エージェントへのメールに、他社の名前や他社の推薦の状況を書きません。 管理表には12社分の行がありますが、A社へのメールに載せてよいのは A社の行だけです。 下書きの指示にもこの点を書き、採用担当の確認でも見ます。

この構成には、自動で書き込む連携がありません。 管理表の更新も、依頼事項のメールも、宿題の連絡も、採用担当が確かめてから行います。難易度を★1にとどめている理由がここにあります。

人が確認する

1. 職種の件数を突き合わせる … 議題の一覧の件数と、要約の行数が合っているかを見ます
2. 数字の行を時刻で確かめる … 推薦数と選考中の人数は、全件、根拠の時刻の発言を開いて確かめます
3. 宿題の持ち主を確かめる … 「持ち主が不明」の行は、採用担当の記憶で決めず、エージェントに一文で確かめます
4. 依頼のメールの下書きを直す … 他社の情報が混ざっていないかを見てから送ります
5. 更新案を管理表に反映する … 確かめた行だけを書き換えます

確認は、社外に出るものから先にします。 依頼のメールは、送った後では取り消せません。 管理表の更新は社内の記録なので、誤りに気づけば直せます。

3番目を省かないでください。 持ち主の決まらない宿題を採用担当が自分の側に引き取ると、本来エージェントが動くはずだった確認を、自社で抱えることになります。 逆に、エージェントの側に付ければ、エージェントは頼まれた覚えのない宿題を受け取ります。

目標は、1回の打合せあたり確認と反映を合わせて15分です。 要約を時刻で確かめるのに7分、更新案の反映に5分、メールの下書きの手直しに3分という配分です。

例外に対処する

1行目は、最初の数回で必ず起きます。 社外の会議で記録を取られることに慣れていない担当者もいます。断られた打合せを無理に記録しない、を先に決めておきます。 記録の目的を説明して、次回から同意してもらえれば十分です。

記録を残す

• 打合せの文字起こしと録画（会議の記録の保存先と期限の設定に従う）
• 会議の Copilot が作った要約と、エージェントが作った更新案の原文
• 採用担当が直した箇所 … どの行を、なぜ直したか
• 確定した管理表の更新の日時と、送った依頼のメール
• 返事の無い依頼の一覧の推移（エージェントごと）

直しの記録は、簡単な表で足ります。 エージェント名、日付、職種コード、直した列、直す前、直した後、理由（数字の誤り／持ち主の誤り／職種の取り違え）の列です。月に一度見れば、どの種類の誤りが多いかが分かります。

5つ目の推移は、採用の責任者がエージェントと話す材料になります。 依頼への返事が毎回遅れるエージェントがあれば、それは担当者の負荷か、依頼の仕方の問題です。AIの評価ではなく、事実の記録として渡します。