中途入社者の立ち上がりを、入社後の面談をAIとの対話で行って追い、定着のリスクを拾う

処理の起点を決める

毎週月曜に、人事システムから入社1か月・3か月に当たる人を抽出することを起点にします。月次で一括に送らず、週次で該当者だけに送る形にしてください。

理由は2つあります。1つは、入社日は月内でばらつくためです。月初に一括で送ると、入社直後の人には早すぎ、月末入社の人には遅すぎます。もう1つは、回答が集中すると人事の確認が追いつかないためです。週3名ずつなら、その週のうちに読んで面談を設定できます。

もう1つの起点として、配属先の上長からの依頼を受け付ける形も考えられます。「この人の様子が気になる」と上長が感じたときに、定例のタイミング以外でもヒアリングを走らせられます。ただしこれは、本人から見ると「上司が人事に何か言った」と受け取られる可能性があるため、運用として本人にどう伝えるかを決めてから入れてください。

入力データを集める

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

対象者リスト： 人事システムから、入社日をもとに毎週抽出します。APIがなければ、日次でエクスポートしたCSVを参照する形で足ります。リアルタイム連携は不要です。

採用時の記録： ここが、この構成の質を決めます。「面接で本人が何を期待して入ってきたか」が残っていないと、期待とのずれを聞けません。 採用管理システムに希望条件や志望動機の記録があれば取り込みます。無ければ、入社時に本人へ「入社にあたって期待していること」を3行書いてもらう運用を先に作ってください。

前回のヒアリング結果： 3か月後のヒアリングでは、1か月後に本人が挙げた引っかかりを必ず参照します。「前回こう言っていましたが、その後どうなりましたか」と聞けることが、この仕組みの価値の中心です。 毎回ゼロから聞くなら、アンケートと変わりません。

対話の記録： Copilot Studio のエージェントは、トピックの中の質問ノードで利用者に質問し、回答を変数に保持できます。対話の最後に、エージェント フローをツールとして呼び出して回答一式を SharePoint のリストへ書き出します。エージェント フローは Copilot Studio または Power Automate でつくるローコードの自動化で、ツールとして追加するとエージェントのオーケストレーターが実行時に呼び出せます。

勤怠の状況： 残業時間や休暇の取得は、立ち上がりの状況を示す材料になります。ただし「残業が多いから支援が要る」と機械的に判定しないでください。 繁忙期であれば当然の残業もあります。ここはヒアリングの結果と合わせて人が読む材料として渡すにとどめます。

AIへ渡す前に整形する

1. 対象者の除外 … 休職中の人、退職が決まっている人、すでに人事が個別に対応している人を対象から外します。退職が決まっている人にこのヒアリングを送ると、本人にも人事にも意味がありません
2. 前回の回答の要約 … 1か月後の回答が長い場合、3か月後の質問を組み立てるために要点へまとめます。全文を質問の材料に渡すと、質問が細かくなりすぎます
3. 職種別の質問セットの選択 … 営業、エンジニア、管理部門で、立ち上がりの引っかかりどころが違います。職種ごとに質問のひな形を分けます
4. 配属先の直近の変化の確認 … 対象者の配属先で組織変更や上長の交代があった場合、その情報を質問の材料に加えます。本人の問題ではなく環境の問題であることがあります

AIに処理させる

2つの工程に分けます。

質問を組み立てる工程：

一次ヒアリングを行う工程（Copilot Studio のエージェント）：

回答を整理する工程：

評価に関わる判断はさせません。 この構成のAIは、本人の能力、適性、処遇について何も判断しません。評価に使われると疑われた時点で、正直な回答は得られなくなります。

指示内容を固定する

質問を組み立てる側の指示は次のようになります。

あなたは人事のオンボーディング担当を支援する担当者です。
下の対象者について、入社後フォローのヒアリングで聞く質問を組み立ててください。

【厳守事項】
- 質問は8問前後にしてください。10問を超えないでください。
- 「慣れましたか」「どうですか」のような、はい／いいえで終わる聞き方をしないでください。
  「入社前に聞いていた業務と、実際にやっている業務で違うところはありますか」のように、
  具体的な出来事を答えられる形にしてください。
- 下の「前回のヒアリング結果」に引っかかりが記録されている場合、
  その後どうなったかを聞く質問を必ず1問入れてください。
- 能力、適性、評価に関する質問を作らないでください。
  「期待に応えられていると思いますか」のような自己評価を求める質問も禁止です。
- 他の社員についての評価を求める質問を作らないでください。
  「上司はどうですか」ではなく「困ったときに聞ける相手はいますか」と聞いてください。
- 対象者の情報にないことを前提にした質問を作らないでください。

【対象者】
{employee_context}

【前回のヒアリング結果（3か月後の場合）】
{previous_findings}

【配属先の直近の変化】
{org_changes}

対話を行う側では、Copilot Studio のトピックとして組みます。エージェントは生成オーケストレーションまたはクラシックオーケストレーションで応答するトピックを選び、トピックの中の質問ノードで利用者に質問して、回答を変数に保持します。対話の方針は次のように書きます。

【対話の方針】
- 最初に必ず次の3点を伝えてください。
  (1) 入社後の立ち上がりの様子をうかがうこと。人事評価には使わないこと
  (2) 回答は人事部が見ること。配属先の上長には、本人の同意なく共有しないこと
  (3) 5分から10分で終わること
- 回答が「特にありません」「大丈夫です」の場合、次のように1回だけ聞き直してください。
  「差し支えなければ、最近少しでも戸惑ったことがあれば教えてください」
  2回目は聞かず、次の質問へ進んでください。
- 回答を評価しないでください。「素晴らしいですね」「それは問題ですね」と返さないでください。
  「ありがとうございます」と受けて次へ進んでください。
- 助言をしないでください。「〇〇さんに相談するとよいですよ」と答えないでください。
  支援の提案は人事が行います。
- 途中でやめたいと言われたら、そこで終了してください。引き止めないでください。
- ハラスメント、健康、ハラスメント以外の法令に関わる申告が出た場合、
  それ以上掘り下げず、「人事から直接ご連絡します」と伝えて対話を終えてください。

最後の1行は必ず入れてください。 ハラスメントや健康の相談を、チャットで掘り下げてはいけません。そうした申告は、本人の同意のうえで、人が直接聞く経路へ移します。 AIに続けさせると、記録の扱いも、本人の安全も担保できなくなります。

回答を整理する側の指示は次のようになります。

下のヒアリングの記録を、4つの論点に整理してください。

【厳守事項】
- 本人が実際に書いた内容だけを根拠にしてください。
  書かれていない事情を推測で補わないでください。
- 「事実」と「本人の受け取り方」を分けて書いてください。
  「引き継ぎ資料がない」は事実、「放っておかれている気がする」は受け取り方です。
- 支援の要否（high / medium / low）には、必ず根拠になった回答を引用してください。
- 本人の能力や適性について書かないでください。
- 他の社員を名指しして、その人の問題として書かないでください。
  「特定の人物」ではなく「引き継ぎの体制」のように、仕組みの側で書いてください。
- ハラスメント、健康、法令に関わる記述があれば、内容を要約せず
  urgent_flag を true にして、原文の該当箇所だけを示してください。

【ヒアリングの記録】
{transcript}

【前回のヒアリング結果】
{previous_findings}

「他の社員を名指ししない」の1行が重要です。 これを書かないと、整理結果に「〇〇課長が教えてくれない」といった記述が残ります。その記録が回覧された時点で、本人は二度と正直に答えなくなります。 仕組みの問題として書かせることで、人事が動きやすくもなります。

出力形式を固定する

{
  "employee_id": "",
  "session_round": "1month | 3month",
  "interview_date": "",
  "completed": true,
  "findings": {
    "work_rampup": [
      { "fact": "", "perception": "", "since": "", "quote": "" }
    ],
    "relationships": [
      { "fact": "", "perception": "", "since": "", "quote": "" }
    ],
    "expectation_gap": [
      { "fact": "", "perception": "", "since": "", "quote": "" }
    ],
    "support_needed": [
      { "item": "", "who_can_act": "hr | manager | training", "quote": "" }
    ]
  },
  "previous_items_status": [
    { "item": "", "status": "resolved | unchanged | worse | not_asked" }
  ],
  "support_level": "high | medium | low",
  "support_reason": "",
  "urgent_flag": false,
  "urgent_excerpt": "",
  "answer_completeness": "high | medium | low"
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。項目が欠けたり、余計な説明文が前後に付いたりしなくなるため、そのままリストへ書き込めます。

previous_items_status が、この構成でもっとも見る価値のある項目です。1か月後に挙がった引っかかりが3か月後に unchanged のままなら、人事が手を打てていないということです。 個人の問題ではなく、受け入れの体制の問題として見えてきます。

answer_completeness は、回答が具体的だったかどうかの目安です。これが low の人は、チャットでは本音が出ないタイプかもしれません。次回は対面に切り替える、という判断ができます。

システムへ連携する

ヒアリングの結果は、SharePoint 上の Microsoft Lists（フォロー一覧）へ1回1行で書き出します。列は次の構成です。

配属先の上長への共有は、自動化しないでください。 本人が「上長には言わないでほしい」と考えている内容が含まれます。共有するかどうか、何を共有するかは、人事が本人の同意を得たうえで判断します。

人事システムへの書き戻しも行いません。この記録を人事評価のデータと同じ場所に置くと、「評価に使われる」という疑いが現実味を帯びます。 保管場所は分けてください。

人が確認する

全件、人事が読みます。自動で支援を実施したり、上長へ通知したりはしません。

理由は3つあります。1つは、支援が必要かどうかの判断が、本人の状況、配属先の事情、会社の制度を合わせて考えるものだからです。2つ目は、記録に他の社員に関わる内容が混ざるためで、これを人が見て扱いを決める必要があります。3つ目は、「人事が読んでいる」ということ自体が、本人にとっての意味を持つためです。答えたものが誰にも読まれていないと分かれば、次回から回答は形だけになります。

確認を速くするための設計が効きます。

• urgent_flag が true の行を最上部に固定する
• support_level の高い順に並べる
• previous_items_status が unchanged または worse の行に印を付ける
• 元の対話ログへ1クリックで飛べるようにする
• completed が false（途中で離脱）の行を別に集める。離脱そのものが一つの信号です

例外に対処する

記録を残す

この記録は、本人の処遇に影響しうる情報です。保存の範囲と期間を先に決めてください。

• 対話の全文（誰が、いつ、何を答えたか）
• 整理結果（4つの論点、支援の要否、根拠の引用）
• 人事が取った対応と、その日付
• 本人へ共有の可否を確認した記録
• 削除の依頼を受けた場合、その日付と処理の結果

対話の全文は、人事部の限られた担当者だけが見られる場所に置きます。 整理結果は共有してよいが原文は見せない、という段階を設けると、扱いやすくなります。

保存期間は、入社後1年程度を目安に決めてください。立ち上がりの記録を何年も持ち続ける必要はありません。 一方で、受け入れ体制の改善に使う統計（論点別の件数、unchanged の割合）は、個人が特定できない形にしたうえで残す価値があります。