人事チャットボットからAIエージェントへの移行方法
人事チャットボットからAIエージェントへ移行する際は、FAQを捨てて作り直すのではなく、既存の回答資産を残しながら、申請受付、情報確認、システム更新、処理状況の管理を追加します。この記事では、移行を「回答・受付・反映・完了」の4段階で捉え、実装時に詰まりやすい6つの論点を整理します。
チャットボットとAgentの処理範囲を比較する
人事チャットボットが住所変更フォームを案内した時点で完了するのは、情報提供です。その後には、社員による入力、人事による不足項目の確認、担当システムへの登録、反映結果の確認が残ります。
Agent化の設計対象は、この回答後の工程です。モデルの回答性能に加えて、どの処理まで担当し、何をもって完了とし、未処理を誰が追跡するかを定義する必要があります。HR Agent Labでは、担当範囲を次の4段階で整理します。これは製品の成熟度ランキングではなく、業務設計のための独自の整理です。
根拠となる規程や申請先を案内した状態。本人が知りたいだけなら、ここが完了です。
対象者、変更内容、適用日、必要情報を確認し、追跡できる受付番号を発行した状態。まだシステム反映は終わっていません。
更新要求を送っただけではなく、登録結果を読み戻した状態。別システムの反映待ちがあれば、案件は継続します。
あらかじめ対象としたすべての処理・確認・通知が終了した状態。何を対象外にしたかも利用者に示します。
利用者には、現在の処理状態を「回答・受付・反映・完了」のいずれかで表示する。
チャットボットにもシステム操作を備えたものがあり、Agentもチャット画面から使えます。名称や画面形式では区別できません。担当する処理範囲と、処理結果の確認方法を比較する必要があります。全体像は人事AIエージェントとはで整理しています。
問い合わせを3種類に分類して実行範囲を決める
すべてのFAQをAgentへ置き換える必要はありません。最初に、問い合わせの目的を「知りたい」「手続きを進めたい」「判断してほしい」に分けます。同じ「住所変更」という言葉でも、必要な対応は変わります。
- 根拠・条件・申請先を回答する
- 実行依頼と取り違えない
- 回答だけで目的を満たせる
- 必要情報と実行意思を確認する
- 許可された処理を進める
- 反映と残作業を追跡する
- 事実・根拠・未確定点を整理する
- 判断権限を持つ人へ渡す
- 回答後の標準処理を再開する
手順が固定され、入力も揃う処理なら、既存フォームやワークフローの改善で済むこともあります。自然文の依頼から必要処理を選ぶ、途中の回答に応じて段取りを変える、といった部分でAgentを使い、確定した更新処理は既存の仕組みに任せます。
Microsoftの公式設計資料でも、知識参照とTool／Connectorを分け、厳密な実行が必要な部分には決定的なフローを使う構成が示されています。Microsoft Learnの設計資料 ↗
住所変更を例に処理フローを設計する
以下は製品の実績や特定企業の運用ではなく、架空の住所変更手続きを使った設計例です。対象を「本人が依頼した住所を人事マスタへ反映し、必要な後続処理を確認する」と限定します。
不足情報がある場合は案件を保留する
適用日が未入力なら、Agentが本人へ確認します。その間は「本人の回答待ち」として、次の確認期限を記録します。本人が後から回答したときに、最初から説明し直させず、同じ案件へ戻れるようにします。
例外判断だけを人事へ引き継ぐ
本人申告と既存情報に矛盾があり標準ルールでは決められない場合、Agentは双方の値、参照した根拠、未解決点を整理して人事へ渡します。人事が判断した後は、その判断に従って残りの処理を再開します。停止条件そのものの設計はHuman-in-the-loopの記事を参照してください。
APIへの送信と業務完了を分ける
人事マスタへの要求送信後に応答が途切れた場合、「失敗」と決めつけて再送すると二重処理につながります。まず受付番号などで処理結果を照会し、確認できるまで「結果確認待ち」として扱います。給与側など対象に含めた後続連携が未反映なら、「人事マスタ反映済み・後続連携待ち」と表示します。
Agentは回答生成に加えて、案件の保留、再開、結果確認、完了判定を管理する。
既存FAQに案件管理とシステム操作を追加する
既存のFAQや規程は、回答の根拠として引き続き使えます。ただし、文章を検索できることと、その文章から安全に業務を実行できることは別です。実行に必要な項目は、既存手順や申請書から整理し、曖昧な部分を業務責任者に確認します。
規程の版・適用対象・有効日を管理する。必須項目、期限、承認条件は検索結果や会話だけに持たせない。
案件ID、現在状態、待っている相手、期限、次の処理、完了条件を保持する。会話終了と案件終了を分ける。
本人情報照会、変更申請、結果確認などに操作を限定する。認証・対象者・権限は接続先でも検証する。
送信結果と反映結果を分ける。タイムアウト時の照会、二重処理防止、人の判断後の再開を決める。
実装時に対応すべき6つの課題
FAQ回答では、正しい情報を返せるかが中心でした。手続きを実行するAgentでは、同じ依頼を二度処理しないこと、中断した案件を再開できること、誰の権限で何を変更したかを記録することも必要です。実装時には、次の課題に対応します。
「住所を変えたい」が方法の質問か実行依頼かは文面だけで決まりません。対象者、変更前後の値、適用日を型のある入力へ変換し、実行直前に本人へ確認します。
本人の回答待ちは数日続くことがあります。チャット履歴だけに状態を置かず、案件ID、現在状態、期限、次に許可された処理を永続化します。
更新後にAPI応答だけが途切れると、単純な再送は二重処理を起こします。依頼ごとの一意キー、処理状況の照会、更新結果の読み戻しを用意します。
本人として会話できても、すべての人事データを更新してよいとは限りません。実行時にも対象者、操作、データ項目ごとに権限を検証し、接続権限を絞ります。
会話全文だけを渡すと、人が状況を読み直すことになります。確認済み事実、参照規程、実行履歴、未解決点、次に可能な処理を構造化して引き継ぎます。
検索で古い規程が見つかると、回答だけでなく実行条件も誤ります。案件が参照した版を記録し、実行時点で有効性を再確認します。
Microsoftの公式資料では、人への引継ぎで会話履歴と変数を渡せることが示されています。一方、何を案件の正本として残し、判断後にどの処理から再開するかは、導入側で設計する必要があります。またAzureのRetry patternは、応答だけが失われた非冪等な処理を再試行すると、操作が複数回実行され得ると説明しています。Microsoft Learn：人への引継ぎ ↗／Azure Architecture Center：Retry pattern ↗
「会話が自然だから、正しく登録できるはず」とは扱いません。Agentに実行権限を与える範囲と、人が保持する判断権限を分けます。詳しくは人が保持すべき意思決定権、接続方式や権限・監査は実装方法で確認できます。
公開事例で確認できる実装範囲
Johnson Controls：TeamsからWorkdayの操作につなぐ
Moveworksが公表したJohnson Controlsの事例では、OmniをMicrosoft Teamsへ組み込み、Workdayなどと連携しています。休暇申請・残高確認・承認、人の担当者への引継ぎなどが紹介されています。ここで確認できるのは、問い合わせの入口を既存の業務操作へ接続する構成です。Moveworksによる公開事例 ↗
個々の処理の承認条件や、すべての後続処理の完了判定までは、この公開情報からは確定できません。本記事の4つの境界や住所変更例は、同社の実装を再現したものではありません。HR Agent LabのCase解説も参照できます。
Microsoft HR：人事担当者のケース処理を支援する
Microsoftの公式事例では、Dynamics 365 Customer ServiceのCopilotが、ケース要約、メール下書き、ナレッジ支援を担っています。これは人事担当者がケースを扱うための支援であり、「すべての問い合わせを自律的に完了する」ことを示す事例としては扱いません。Microsoftの公式事例 ↗
標準手続きはAgentが実行し、例外判断は人が担当する。人の判断後はAgentが残りの処理を再開する。
最初の対象業務を1種類選んで評価する
問い合わせ件数だけでは、Agent化の優先度を決められません。回答だけで完了する問い合わせと、入力、確認、転記、催促が発生する問い合わせでは、削減できる人事担当者の作業量が異なります。
社員の再入力、人事の転記、他部門への依頼、未回答の催促を、一つの問い合わせ種別で追います。
対象システム、必要な後続処理、対象外、人に戻す条件を明文化します。標準ルールと実行権限が定まる範囲から始めます。
情報不足、本人の未回答、システム応答不明、承認否認を含め、誤って「完了」とせず、適切に再開・終了できるか確認します。
同じ問い合わせ種別で、完了までの時間、人が触った時間、再問い合わせ、誤った完了扱いを比較します。回答件数と手続き完了件数は分けて数えます。
たとえば回答率が高くなっても、後で人事が同じ内容を転記し続けていれば、手続きの負荷は残っています。逆に複雑な案件で人への引継ぎが増えても、事実確認が済み、判断後にAgentが処理を再開するなら、人の負担が下がる可能性があります。
回答後の残作業を特定し、Agent、既存システム、人事担当者の処理範囲を定義する。
人事問い合わせ・手続きAgentを試す → 不足情報の回収、待ち、例外、後続処理の流れを公開デモで確認できます。公開デモの動作は、自社システムへの本番接続を保証するものではありません。
問い合わせだけでなく、規程・手続き・Employee Self-Serviceを含む労務領域全体から検討する場合は、労務AIエージェントのDomain HubでUse Caseと実在Caseを整理しています。
参考情報・一次情報
公開情報の事実説明には本文中から出典を付けています。4つの完了境界、住所変更例、移行手順はHR Agent Labの設計提案です。確認日：2026-09-09。