面接が終わっても評価を入力していない面接官を毎日洗い出し、面接メモの要点を添えて入力を促すメッセージを Teams で送る

処理の起点を決める

平日の毎朝8時に1回動かします。 面接が終わるたびに動かす設計にはしません。面接直後は面接官がまだ次の会議に向かっている時間で、終わった直後に届く催促は読まれずに流れます。 朝の始業前に、前日までの分をまとめて届けます。

段階は、面接の終了日時からの経過時間で決めます。

24時間・48時間・72時間は、社内の決まりから逆算した値です。 「翌営業日まで」を守れていれば1回目は届きません。週末をはさむときは営業日で数えます。 金曜の面接に土曜の朝の催促が届くと、決まりを守っている面接官まで催促されます。

同じ段階の催促は二度送りません。催促の記録のリストに、その面接のその段階の行があれば飛ばします。

入力データを集める

質を決めるのは、面接メモです。 メモが空なら、要点は作れません。その場合は要約を飛ばし、催促だけを送ります。 メモが無いこと自体を採用担当への情報として記録に残します。

評価の観点は、要約の並べ方に使います。 職種ごとの評価項目の名前を渡すと、メモの要点をその項目の順に並べられます。面接官は評価シートを上から埋めるので、要点の順番が合っていると書きやすくなります。 観点に当てはまらない要点は「その他」にまとめます。

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

面接予定のリストは Get items で読みます。フィルター クエリは次のとおりです。

EvaluationStatus eq '未入力' and InterviewEnd lt '@{addHours(utcNow(), -24)}'

比べる時刻のタイムゾーンをそろえます。 utcNow() は UTC を返すので、日本時間の値と混ぜると9時間ずれて催促が早く届きます。 最初に数件で確かめます。

面接官の列は、ユーザーの列にしておきます。 名前の文字列だと、同姓の社員や表記ゆれで送り先を誤ります。ユーザーの列ならメールアドレスが取れ、それをそのまま Teams の受信者に使えます。

AIへ渡す前に整形する

1. 面接中止の除外 … 評価の状態が「面接中止」の行は対象から外します
2. 営業日の換算 … 土日と会社の休日をはさむ場合、経過時間を営業日で数え直します。休日の一覧はリストで持ちます
3. 面接官ごとの分け方 … 複数の面接官がいる面接は、まだ入力していない面接官だけを対象にします
4. メモの長さの確認 … 空なら要約を飛ばし、極端に短い（1〜2行）ときは要約せずそのまま添えます
5. 候補者の連絡先の除去 … メモに電話番号やメールアドレスが書かれていれば、渡す前に伏せます
6. 二重送信の確認 … 催促の記録に同じ面接・同じ段階の行があれば、その行は飛ばします

3番目を軽く見ないでください。 二次面接は2名で行うことが多く、片方は入力済みで片方が未入力、という状態がよくあります。面接の行単位で見ると、入力済みの面接官にまで催促が届きます。 面接評価のリストを面接IDと面接官で引き、入力の無い人だけを残します。

4番目で短いメモを要約しないのは、要約するほうが長くなるからです。 「技術力は十分、チーム経験少なめ」の1行は、そのまま渡せば足ります。

AIに処理させる

させるのは、面接メモを、評価を書くための思い出しの材料に並べ替えることだけです。

4行目は、厚生労働省の公正採用選考特設サイトが挙げる事項に沿います。 本人に責任のない事項（本籍・出生地、家族、住宅状況、生活環境・家庭環境）と、本来自由であるべき事項（宗教、支持政党、人生観・生活信条、尊敬する人物、思想、労働組合や社会運動、購読新聞・雑誌・愛読書）を、面接でたずねるなどして把握することは就職差別につながるおそれがあるとされています。メモにそれが残っていたら、要約には載せず、採用担当に「メモの記載を確認してください」と知らせます。

1行目がいちばん起きやすい失敗です。 「要点をまとめて」とだけ指示すると、最後に「総じて次の選考に進める水準と考えられます」と結びます。面接官は忙しいほど、その一文を評価欄に写します。

5行目で催促の文面をAIに書かせないのも、同じ考えです。 文面は毎回同じほうが、面接官は読み飛ばしてすぐ要点に目が行きます。AIの出力はメッセージの中の「要点」の枠にだけ入れます。

指示内容を固定する

あなたは採用担当の補助として、面接官が面接中に書いたメモを、
面接官本人が評価を書くときの思い出しの材料に並べ替えます。
評価をするのは面接官です。あなたは評価をしません。

【入力】
- 面接メモ：{memo}
- 応募職種：{job_title}
- 選考の段階：{stage}
- 評価の観点（この順に並べる）：{criteria}

【してほしいこと】
1. メモに書かれている事実だけを、短い文で抜き出してください。
   1つの要点は40字以内にしてください。
2. 要点を評価の観点ごとに振り分けてください。
   どれにも当てはまらないものは「その他」に入れてください。
3. メモに「要確認」「次回」「？」などで残された、確かめていない事項を
   open_questions に入れてください。
4. 同じ日の別の候補者と区別するための手がかりを1つ書いてください。
   メモに書かれた話題から選んでください。

【厳守事項】
- 評価の点数、合否、次の選考に進めるべきかを書かないでください。
- 「優秀」「積極的」「物足りない」などの評語は、メモにその語が
  書かれている場合だけ、そのまま写してください。言い換えないでください。
- メモに書かれていない事実を補わないでください。
  記載がなければ書かないでください。
- 次の事項に触れる記載がメモにあれば、その内容を要点に入れず、
  sensitive_flag を true にし、sensitive_topic に該当する区分名だけを書いてください：
  本籍・出生地、家族、住宅状況、生活環境・家庭環境、宗教、支持政党、
  人生観・生活信条、尊敬する人物、思想、労働組合・社会運動、
  購読新聞・雑誌・愛読書、健康・病歴。
- 候補者の電話番号・メールアドレス・住所は書かないでください。
- 回答に JSON マークダウンを含めないでください。

「評価をしません」を冒頭と厳守事項の2か所に書いています。 1か所だけだと、要点の最後に「総合的には」と結論を足します。禁じるのは結論の言い方ではなく、結論を出すことそのものです。

評語を「その語が書かれている場合だけ写す」にしているのは、面接官の言葉を残すためです。 メモに「積極的」と書いたのは面接官本人で、それを写すのは評価の代わりにはなりません。AIが別の評語に言い換えると、面接官が書いていない評価が生まれます。

最後の1行は、公式ドキュメントのFAQにある対処です。 モデルが JSON をマークダウンで囲むと形式の検証が通らないことがあり、この一文を足すよう案内されています。

出力形式を固定する

プロンプトの出力を JSON にし、次の形の例を渡して形式を「カスタム」で保存します。

{
  "memo_status": "summarized",
  "key_points": [
    { "criterion": "技術力", "point": "" },
    { "criterion": "その他", "point": "" }
  ],
  "open_questions": [ { "question": "" } ],
  "distinguishing_cue": "",
  "sensitive_flag": false,
  "sensitive_topic": ""
}

memo_status は summarized ／ too_short ／ empty のどれかです。too_short と empty はフローの前処理で決め、AIは呼びません。

1つ目の理由は、要点と印を別の行き先に分けられることです。 key_points と open_questions は面接官へのメッセージに入れ、sensitive_flag は採用担当のチャネルにだけ出します。文章1本で返ってくると、印の部分だけを面接官から隠すことができません。

2つ目は、形式が固定されることです。 公式ドキュメントでは、プロンプトを保存すると最新の自動検出の形式または定義したカスタムの形式がロックされ、フローで使うときは保存された形式が使われるとされています。毎朝同じ形で返ってくるので、メッセージの組み立てが壊れません。

注意が1つあります。 公式ドキュメントの制限事項に、フィールドのキーの無い JSON（["abc", "def"] のような配列）はサポートされないとあります。open_questions を文字列の配列にせず、{ "question": "" } の配列にしているのはこのためです。

Teams に送るメッセージは、フローの側で次の形に組み立てます。

【評価の入力をお願いします】（1回目）
次の面接の評価がまだ入っていません。

■ 山田 太郎さん／バックエンドエンジニア／二次面接
  10月6日 14:00〜15:00（手がかり：前職の決済基盤の移行の話）
  メモの要点
  ・技術力：Go で決済の API を3年担当
  ・チーム：5名のチームでレビューの取りまとめ
  まだ確かめていないこと
  ・転居の可否ではなく、勤務地の希望（次回確認とメモ）
  → 評価の入力先：（リンク）

面接メモの要点は、あなたのメモを並べ直したものです。
評価はご自身の言葉でお書きください。

最後の2行は毎回入れる定型文です。 要点がAIの作ったものであることと、評価は面接官が書くことを、届くたびに思い出してもらいます。

システムへ連携する

面接評価のリストには書き込みません。 この構成が出すのは催促までで、評価の行を作るのは面接官本人です。 下書きの評価を自動で作る仕組みを足すと、第7章の「させないこと」の1行目がそのまま崩れます。

Teams のフロー ボットには、送れる量の上限があります。 公式ドキュメントでは、フロー ボットの操作は接続あたり300秒で25回とされています。面接官ごとに1通にまとめれば、1日の送信は多くても数十通で、それでも25通を超える日は、送信の間に待ちを入れます。

Teams の管理センターで、Workflows のアプリが許可されている必要があります。 公式ドキュメントでは、これらのアクションは Workflows（旧 Power Automate）のアプリが使えて、管理センターで「許可」になっていることが前提とされています。最初に情報システムの担当に確かめます。

採用担当への通知をプライベート チャネルにしないでください。 公式ドキュメントでは、プライベート チャネルへのメッセージの投稿は現在サポートされていないとされています。標準のチャネルで、採用グループのメンバーだけのチームに置きます。

人が確認する

1回目と2回目の催促は、人の確認を経ずに送ります。 送り先は社内の面接官で、中身は本人が書いたメモの並べ替えです。ここを毎回人が確認すると、催促が朝のうちに届かなくなります。

人が見るのは、次の2つだけです。

1. 72時間を超えたもの … 採用担当のチャネルに、面接官名・未入力の件数・これまでの催促の日時が届きます。ここから先は、面接官の上長への相談か、候補者への日程の連絡を人が決めます
2. 配慮すべき事項の印が付いたもの … 要約には載せていないので、面接官には届いていません。 採用担当がメモの記載を見て、面接の進め方について面接官と話します

2番目を省かないでください。 印が付いたということは、面接の中でその話題が出たということです。評価から外すだけでなく、次の面接で同じことが起きないようにするのが採用担当の仕事です。

1か月に一度、要約を抜き取りで見ます。 10件ほどを選び、メモと要約を並べて、評語の言い換えやメモに無い事実が混ざっていないかを確かめます。混ざっていれば、プロンプトの厳守事項を足します。

例外に対処する

上から4行目までは、AIではなくリストの運用の問題です。 中止の入力漏れや面接官の不在は、催促が届いてから分かることが多く、最初の1か月は採用担当のチャネルに回る件数が多めに出ます。 その件数を見て、リストの入力の決まりを直します。

最後の行は、朝8時の前後に評価を入れた面接官に催促が届くのを防ぎます。 取り出しから送信までに数分かかるので、送る直前に1行だけ読み直します。

記録を残す

• 催促の記録（面接ID、面接官、段階、送った日時、memo_status）
• AIが返した JSON の全文（要約、確かめていない事項、配慮事項の印）
• 配慮事項の印が付いた面接と、採用担当の対応
• 評価が入った日時（面接の終了から何時間かかったか）
• 72時間を超えて採用担当に回った面接と、その後の対応

4つ目が、この構成の効き目を測る数字です。 面接の終了から評価が入るまでの時間を、導入の前と後で比べます。催促の件数が減ることより、この時間が短くなることのほうが、候補者を待たせないことに直結します。

催促の記録は、面接官を責める材料にしないでください。 遅れやすい面接官が分かれば、面接の後に入力の時間を空けた日程にするなど、組み方の側で直せることがあります。 保存期間は、応募者の個人情報の保存期間に合わせて決めます。