HR Agent Lab›人事AIエージェントとは›Human-in-the-loop設計

HUMAN-IN-THE-LOOP DESIGN

人事AIエージェントは、どこで人間に戻すべきか

Human-in-the-loop（AIの処理途中に人間の判断・承認を入れる設計）は、すべてを人がチェックすることではありません。 人事AIエージェントでは、Agentが実行するアクションごとに「そのまま進める」「承認を待つ」「人間へ引き継ぐ」の条件を決めます。

最終確認：2026-09-08対象：人事企画・HRIS・AI / DX担当者

要点人間を残す「業務」を決めるのではなく、影響度・可逆性・不確実性・権限を見て、Agentが実行する「アクション単位」で停止条件を設計する。

Human-in-the-loopは「全部を人が確認する」設計ではない

AIエージェントが業務を進めるとき、人間をどこに残すかは重要です。しかし、すべての判断・実行を人が確認する設計では、Agentが本人への確認、システム更新、再確認まで準備しても、結局は人事担当者が毎回ボタンを押すことになります。これでは自動化できるのは作業準備までです。

逆に、すべてをAgentへ任せるのも適切ではありません。人事業務には、従業員への影響が大きい処理、元に戻しにくい更新、規程だけでは判断できない例外、権限上人間の承認が必要な操作があります。

したがって、Human-in-the-loopは「人間が見るか／見ないか」の二択ではなく、どの条件ならAgentが継続し、どの条件なら人間を呼ぶかを事前に設計することと捉える方が実務的です。

避けたい設計全件Human Approval

Agentが標準ケースまで毎回停止する。安全に見える一方で、人事担当者の確認待ちが新しいボトルネックになる。

目指す設計条件付きHuman-in-the-loop

標準処理はAgentが進め、高影響・不可逆・曖昧・権限外のアクションだけを止める。

外部ガイダンスとの整合

Microsoftは、Agentが人・金銭・コンプライアンスに影響する、または元に戻しにくいアクションを行う場合にHuman Approvalを求め、曖昧・センシティブなケースは人へルーティングする考え方を示しています。Microsoft Learn — Apply responsible AI ↗

HR AGENT LABの設計原則

Human-in-the-loopの単位は「業務」ではなく「アクション」。同じ業務の中でも、自動実行・承認・例外引継ぎを分ける。

どこで人間に戻すかは、4つの観点で決める

停止条件を「重要そうだから人に見せる」と曖昧に決めると、運用開始後にHuman Approvalが増え続けます。そこで、各アクションを影響度・可逆性・不確実性・権限の4観点で見ます。

01 · IMPACT影響度

その処理が従業員の雇用、評価、処遇、給与、権利、アクセス権などへどの程度影響するか。影響が大きいほど人間を残す理由が強くなる。

02 · REVERSIBILITY可逆性

誤った場合に簡単に元へ戻せるか。通知文の下書きと、給与確定・アカウント削除では必要な統制が異なる。

03 · UNCERTAINTY不確実性

必要情報が揃っているか、規程やルールが一意に判断できるか、情報同士が矛盾していないか。曖昧なら承認ではなく判断そのものを人へ戻す。

04 · AUTHORITY権限

Agentにそのアクションを実行する権限を与えるべきか。業務上の権限分離や職務権限上、人間の承認が必要なら自動実行させない。

「Agent全体」ではなく「Action単位」でGateを選ぶ

Microsoftの公式AI Agent Runbooksでも、レビュー／承認GateはAgent全体で一律に決めず、アクションごとに意図的に選ぶパターンが示されています。誤った場合の影響に応じて、通知・事前確認・人間が実行・必須レビューを使い分ける考え方です。Microsoft — Human-in-the-Loop Review and Approval ↗

4つをスコア化すること自体が目的ではない

重要なのは、各アクションで「なぜ止めるのか」を説明できることです。4観点を一律の点数にすると、実際には異なるリスクを一つの数字へ潰してしまいます。たとえば影響度は低くても、規程上Agentに更新権限を持たせない操作ならHuman Approvalが必要です。

POINT

停止条件は「AIの自信度」だけで決めない。業務影響・戻せるか・判断の曖昧さ・実行権限を分けて見る。

処理は「自動実行・承認・例外引継ぎ」の3つに分ける

4観点を見た後は、Agentの次アクションを3つのモードへ落とします。ここで重要なのは、Human ApprovalとHuman Escalationを同じものとして扱わないことです。

MODE AAgentが自動実行

標準ルールで一意に決まる
影響が限定的
誤っても修正できる
Agentに実行権限を付与してよい

MODE BHuman Approval

何を実行するかは決まっている
影響が大きい、または戻しにくい
最終実行権限を人に残したい
人は「実行してよいか」を確認する

MODE C人間へ例外引継ぎ

規程だけでは決まらない
必要情報が矛盾・不足している
複数の妥当な選択肢がある
人が「何をすべきか」を判断する

承認と例外引継ぎを分ける

たとえば、住所変更後のHRIS更新内容がすべて確定しているが、更新権限上Human Approvalが必要なケースでは、人が再度内容を考える必要はありません。一方、本人申告の勤務地と人事システム上の異動予定勤務地が矛盾している場合は、何を登録すべきか自体が決まっていません。後者は承認ではなく例外判断です。

実装上も分離できる

Microsoft Agent Frameworkでは、承認が必要なToolを呼び出す際にワークフローを一時停止し、人間の応答後に再開するパターンが示されています。Microsoft Learn — Human-in-the-loop workflow ↗

人事業務では、同じプロセスの中に3つのモードが混在する

「勤怠はAgent向き」「評価は人間向き」と業務単位で分けるだけでは粗すぎます。人事業務は一つのプロセスの中に、情報収集、標準判定、通知、システム更新、高影響判断、例外処理が混在するからです。

アクション例

Agent自動実行

Human Approval

例外引継ぎ

勤怠締め

打刻漏れ検知、本人確認、催促、修正後再確認

例外的な締め処理など権限上承認が必要な操作

規程外の勤務、情報矛盾、判断基準のない例外

従業員情報変更

必要項目の回収、整合チェック、低リスクな標準更新

影響の大きいマスタ更新、不可逆な処理

申告内容と既存情報が矛盾し、正しい状態を確定できない場合

評価・処遇

情報収集、データ整理、評価材料の提示

補助的な処理の実行承認

評価・処遇等の重要判断は人間中心とし、Agentは判断材料の準備に留める

人間に残すのは「最後の1クリック」ではない

Human-in-the-loopの設計が悪いと、人事担当者にはAgentが集めた大量の情報と「承認してください」だけが渡されます。良い引継ぎでは、Agentが標準処理をできるところまで終えたうえで、何が確定していて、何が矛盾し、何を判断すれば業務が再開するかを限定して渡します。

公開事例で具体化する場合は、Johnson ControlsのHR支援Caseのように、標準的な問い合わせ・手続きはデジタル接点から業務へつなぎ、複雑なケースを人事へ引き継ぐ構造を見ると、回答AIと業務Agentの境界を理解しやすくなります。

POINT

人間へ戻すときも、Agentの仕事を止めない。確定済み処理を先に進め、未解決の判断だけを人間へ切り出す。

Human-in-the-loopはUIではなく、Agentの状態遷移として実装する

Human Approvalボタンを画面に置くだけでは、Human-in-the-loopを実装したことにはなりません。Agent側に「なぜ停止したか」「誰の応答を待っているか」「応答後にどこから再開するか」を状態として持たせる必要があります。

従業員情報変更Agentの例

1情報収集既存情報と本人申告を取得

2整合確認標準ルールで矛盾を検知

3人間判断勤務地矛盾だけを人事へ戻す

4Agent再開回答を受けて残処理を実行

5完了更新結果を再確認してClose

停止理由をコード化する

`approval_required`、`policy_gap`、`conflicting_data`、`insufficient_information`など、なぜ止まったかを状態として区別する。

承認はTool / Action単位に付ける

Agent全体を「承認あり」にせず、どのTool実行の直前に人間が必要かを定義する。

人間へ渡す情報を最小化する

処理履歴を全部見せるのではなく、判断に必要な事実、根拠、未解決論点、選択肢をまとめる。

承認後は自動再開する

人間が承認した後に、残りの標準処理を再び手作業で進めさせない。Agentが次の状態へ進む。

証跡を残す

停止理由、参照情報、Agentの提案、人間の判断、実行したTool、結果をCase IDに紐づける。

ガバナンスとの接続

NIST AI RMFは、AIリスクを設計・開発・利用・評価のライフサイクルへ組み込む考え方を示しています。Human-in-the-loopも単独のUI機能ではなく、権限、監査、テスト、運用を含むリスク管理の一部として設計する必要があります。NIST — AI RMF 1.0 ↗

設計は「どの業務を人に残すか」ではなく、実行アクションの棚卸しから始める

Human-in-the-loopを後付けすると、「念のため承認」が増えます。Agent設計の段階で、業務フローに含まれる実行アクションを列挙し、それぞれを4観点で見て処理モードを決めます。

業務ゴールを決める

「問い合わせに答える」ではなく「必要手続きを完了する」など、Agentがどこまで責任を持つかを決める。

アクションを分解する

照会、判定、依頼、通知、起票、更新、承認要求、完了確認まで、Agentが実行する単位に分ける。

4観点で停止条件を決める

影響度・可逆性・不確実性・権限を見て、自動実行、Human Approval、例外引継ぎを決める。

例外シナリオでテストする

標準ケースだけでなく、情報不足、データ矛盾、規程外、高影響操作で正しく停止・再開できるか確認する。

MicrosoftのAI Agent Shared Responsibility Modelでも、組織側が保持する責任として、Agent identity、最小権限、アクションの認可、どの操作に人間の監督を入れるかが整理されています。Microsoft Azure — AI agent shared responsibility model ↗

また、生成AIを含むAIシステムのリスク管理では、Human-in-the-loopだけを単独で強化しても十分ではありません。NISTのGenerative AI Profileも、リスク管理を設計・開発・利用・評価へ横断的に組み込む考え方を示しています。NIST — Generative AI Profile ↗

結論

Human-in-the-loopは「人間を残す思想」ではなく、Agentが安全に仕事を進めるための停止・引継ぎ・再開の設計である。