退職者と選考辞退者へのヒアリングをAIとの対話で行い、理由を集計する

処理の起点を決める

退職の申し出が人事システムに登録されたとき、または選考辞退が採用管理システムに記録されたときが起点です。

退職者については、最終出社日の2週間前に案内を送ります。直前だと引き継ぎで手一杯です。

選考辞退者については、辞退の連絡を受けた当日に送ります。日が経つほど回答率が下がります。

半自動化では、次を追加します。

• 回答がないまま期限が近づいたら、1回だけ再案内する
• 月末に集計を自動で作る

再案内は1回までにしてください。 何度も送ると、「答えさせられている」と受け取られます。 回答は任意です。

入力データを集める

「設問の一覧」を先に作ってください。

聞く順番が結果を左右します。最初に重い質問をすると、そこで離脱します。

「答えたくなければ飛ばせる」ことを、設問ごとに明示してください。 飛ばせない設問があると、そこで対話全体が終わります。

「回答の区分」は人事が作ります。AIに作らせないでください。 自社の課題に合った粒度でなければ、集計しても使えません。

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

対話の実施： Microsoft Copilot Studio でエージェントを作り、Teams の1対1のチャットとして提供します。

Copilot Studio のエージェントを Teams で使えるようにするには、少なくとも1回はエージェントを公開（発行）したうえで、Teams と Microsoft 365 Copilot のチャネルに接続します。 提供の方法は3通りあります。

モバイルで回答してもらうなら、アプリストアへの掲載が必要です。 インストールリンクは Teams のモバイルアプリでは使えません。退職を考えている人が、会社のPCの前でこれに答えるとは限りません。 ここは設計の分かれ目です。

1対1のチャットで提供してください。 Teams のグループチャットやチャネルでは、SharePoint などエンドユーザー認証を必要とするナレッジソースを使えません。 これは意図しないデータの漏えいを防ぐための設計上の制限です。そもそもこの用途でグループチャットに置く理由はありません。

組織外の個人が使えないよう、セキュリティ設定を有効にしてください。 社内従業員向けのエージェントでは必須です。

回答の分類： 対話の記録を Claude API に渡し、社内の区分に分類させます。対話とは別の処理として分けてください。 対話の最中に分類させると、分類を意識した応答になります。

最小構成では、Claude のプロジェクトを使います。 プロジェクトに設問票と区分の定義をアップロードしておけば、そのプロジェクト内の会話で読ませられます。回答を貼って分類させるだけで始められます。

AIへ渡す前に整形する

1. 氏名の除去 … 対話の記録から氏名を外します。分類には不要です
2. 属性の付与 … 部門、職種、在籍年数、雇用区分を付けます
3. 選考情報の付与 … 辞退者には、辞退した選考段階と経過日数を付けます
4. 少人数部門のまとめ … 在籍3名以下の部門は、上位の組織単位にまとめます
5. 個人が特定される記述の確認 … 「私の担当していた◯◯の案件で」のような記述に印を付けます

4番目と5番目が、この構成でもっとも重要な前処理です。

「匿名で集計します」と案内しておきながら、部門別の集計で1人しかいない部門の欄に回答が並べば、匿名ではありません。 集計の単位を先に決めてください。「3名未満の区分は表示しない」を原則にしてください。

AIに処理させる

AIに次のことをさせないでください。

「引き止めをさせない」ことが、この構成で最も重要な制約です。 ヒアリングの場で説得が始まれば、次からは誰も本当のことを話しません。 一度失った信頼は戻りません。

「特定の個人への評価を誘導しない」も必ず入れてください。 「上司の対応に問題がありましたか」と聞けば、名指しの回答が集まります。 その記録の扱いは、人事にとって非常に難しいものになります。設問は「職場の環境について感じていたこと」までにとどめてください。

「2回以上掘り下げない」を必ず指定してください。 掘り下げは1回までです。それ以上は尋問になります。

指示内容を固定する

対話側（Copilot Studio のエージェントへの指示）：

あなたは、退職または選考辞退の理由を聞き取る担当者です。
設問の一覧に沿って、1問ずつ質問してください。

【厳守事項】
- 引き止めや翻意の説得をしないでください。
  「考え直す余地はありませんか」と聞かないでください。
- 会社の説明や反論をしないでください。
  「その制度はこういう理由で」と返さないでください。
- 特定の個人について聞かないでください。
  「誰が」「どの上司が」と尋ねないでください。
  相手が個人名を挙げた場合も、それ以上は掘り下げないでください。
- 回答を評価しないでください。
  「素晴らしいご意見です」「それは問題ですね」と返さないでください。
  受け止めたことだけを短く返してください。
- 「答えたくない」「次へ」と言われたら、理由を聞かずに次の設問へ進んでください。
- 掘り下げは、1つの設問につき1回までにしてください。
  抽象的な回答でも、2回以上は聞き返さないでください。
- 相手の感情を推し量った発言をしないでください。
  「おつらかったですね」と書かないでください。
- 途中でやめたいと言われたら、そこで終了してください。
  最後まで答えるよう促さないでください。
- 最後に必ず、人事と直接話したいかを尋ねてください。

【設問の一覧】
{question_list}

【最初のメッセージ】
この聞き取りは任意です。答えたくない質問は「次へ」とお伝えください。
いつでも終了できます。内容は職場の改善のために集計され、
個人が特定される形では共有されません。

分類側（Claude API への指示）：

あなたは、退職・辞退の理由を分類する担当者です。
対話の記録を、社内の区分に当てはめてください。

【厳守事項】
- 本人が述べていない理由を推定しないでください。
  述べられた内容だけから分類してください。
- 区分に当てはまらない回答は、"その他" にし、
  unclassified に原文をそのまま入れてください。
  近い区分に寄せないでください。
- 感情や不満の度合いを点数化しないでください。
- 個人名・チーム名が含まれる記述は、
  contains_identifiable を true にしてください。
  内容を書き換えないでください。
- 分類の根拠として、対話のどの発言を見たかを
  quoted_text に入れてください。

【回答の区分】
{category_definitions}

【対話の記録】
{transcript}

分ける理由は、対話と分類で求めるふるまいが逆だからです。 対話では評価も判定もしません。分類では区分に当てはめます。同じ指示で両方をやらせると、対話の最中に分類が漏れます。

出力形式を固定する

対話の記録は、設問ごとに分けて保存します。

{
  "response_id": "",
  "type": "退職 | 選考辞退",
  "attributes": {
    "department_group": "",
    "job_family": "",
    "tenure_band": "",
    "employment_type": "",
    "selection_stage": ""
  },
  "answers": [
    {
      "question_id": "",
      "answered": true,
      "skipped": false,
      "text": "",
      "follow_up_used": false
    }
  ],
  "completed": true,
  "aborted_at": "",
  "wants_hr_meeting": false
}

分類の出力：

{
  "response_id": "",
  "primary_category": "",
  "secondary_categories": [],
  "unclassified": [],
  "key_points": [],
  "quoted_text": "",
  "contains_identifiable": false,
  "confidence": "high | medium | low"
}

skipped と aborted_at を必ず記録してください。 どの設問で飛ばされたか、どこでやめられたかは、設問そのものの評価に使えます。 特定の設問で離脱が集中していれば、その設問が悪いということです。

wants_hr_meeting は、人が対応すべき唯一の即時項目です。 ここが true のものは、その日のうちに人事へ通知してください。

contains_identifiable が true のものは、集計から外すのではなく、閲覧範囲を絞って残します。 内容を書き換えないでください。書き換えると、何があったか分からなくなります。

点数や総合スコアは持たせません。 「不満度」のような数字があると、人はその数字だけを見ます。

システムへ連携する

最小構成では連携はありません。設問票をメールで送り、回答を生成AIのプロジェクトで分類します。

半自動化では、次をつなぎます。

人事システムへ退職理由を自動で書き込まないでください。 人事システムの退職理由は、会社としての公式な記録です。本人の申告と、このヒアリングの結果は別のものです。混ぜないでください。

上長への自動共有を絶対に行わないでください。 「あなたの部下がこう答えました」という通知は、この仕組みを一度で終わらせます。

人が確認する

対話の記録の確認は、必ず人事が行います。

2番目を必ず設計に入れてください。 ハラスメント、安全衛生上の問題、違法行為をうかがわせる記述が出た場合、これは集計の対象ではありません。 社内の通報窓口の手順へ回してください。「毎月の集計に含めて終わり」にしてはいけません。

この点は、対象者にも事前に伝えてください。 「重大な内容については、別の手順で対応することがあります」と案内に書いておかないと、匿名だと信じて話した内容が扱われることになります。

例外に対処する

記録を残す

• 対話の記録（設問ごと、氏名を除いたもの）
• 飛ばされた設問、途中終了した位置
• 分類結果と、その根拠となる発言
• 人事が分類を修正した内容と、修正前後
• wants_hr_meeting への対応記録
• 月次の集計結果
• 設問と区分の変更履歴

設問と区分の変更履歴を必ず残してください。 設問を変えれば、集計の連続性は切れます。「いつ設問を変えたか」が分からないと、傾向の変化が設問の変化なのか実態の変化なのか判断できません。

保存期間を定めてください。 退職者の対話記録を無期限に残す理由はありません。集計に必要な期間（例：3年）を定め、原文はその後に削除する設計にしてください。

閲覧範囲を限定してください。 人事の担当者と、指定された責任者だけが読める状態にします。部門長が読める設計にしないでください。