人事AIエージェントに、何を任せてはいけないか
「採用は人間」「勤怠はAI」のように、業務名で境界を引くと設計を誤ります。 同じ採用業務でも、候補者情報の整理と、採用可否の最終判断では意味が違います。決めるべきなのは、AIに任せない業務ではなく、人が保持する意思決定権です。
「この業務はAIに任せない」では、境界が粗すぎる
人事AIエージェントの設計でよく起きるのが、「評価はセンシティブだから人」「問い合わせは定型だからAI」と業務名で線を引くことです。しかし、実際の人事業務は一つの業務の中に、情報収集、事実確認、候補生成、判断、承認、システム更新、本人通知といった異なるアクションが並びます。
たとえば人事評価でも、過去の目標・実績・フィードバックを集めて論点を整理する部分はAgentが担えます。一方、評価基準そのものを決めたり、個人の処遇を最終確定したりする行為は、組織の価値判断と説明責任を伴います。同じ「評価業務」でも任せ方は同じではありません。
業務名だけで分けるため、自動化できる作業まで人に残り、逆に業務内の重大判断が見落とされます。
アクションを分解し、判断の性質ごとにAgent実行・提案・Human Approval・人間判断を配置します。
AIに任せてはいけないのは「業務」ではなく、人が説明責任を持つべき意思決定権である。
これは「重要なことは全部人間がやる」という意味ではありません。むしろ、人が保持する判断を狭く明確にすることで、その前後の作業をAgentへ大きく移せるようになります。
意思決定を「収集・提案・決定・ルール変更」の4層に分ける
人とAgentの境界を考えるときは、業務フローをそのまま眺めるより、各アクションがどの意思決定層にあるかを分ける方が明確です。HR Agent Labでは、以下の4層で整理します。
Level 1と2をAgentへ寄せても、人の判断権は失われません。逆に、人がLevel 3と4に集中できれば、AI活用は単なる作業代行ではなく「判断材料が揃った状態をAgentがつくり、人が必要な判断だけを行う」業務設計へ変わります。
前回の記事で整理したHuman-in-the-loopの停止条件は、このLevel 2からLevel 3へ移る箇所に配置する設計と捉えると分かりやすくなります。
人が保持すべきなのは、4種類の「判断権」
すべてのLevel 3を永久に人へ固定する必要はありません。影響が小さく、規則が明確で、可逆的かつ権限が明示された処理なら、Agentの自動実行へ移せます。一方、次の4種類は人が意思決定権を保持することを基本に考えます。
何を良い評価とするか、どこまで例外を認めるか、どのリスクを許容するか。これは既存ルールの適用ではなく、組織の価値基準そのものを決める行為です。
雇用・処遇・配置など、本人への影響が大きく、説明責任を伴う最終判断です。Agentは情報整理や候補提示を担えても、判断主体まで自動で移すかは別途ガバナンスが必要です。
規程に該当条文がない、複数ルールが衝突する、事実関係が曖昧なケースでは「ルールを適用する」のではなく、どう解釈するかを決める必要があります。
会社名義の確定回答、権限を伴うシステム変更、機密情報の開示などは、内容だけでなく「誰がその行為をしてよいか」が重要です。
Microsoft Learnは、人・金銭・コンプライアンスへ影響する行為や元に戻しにくい行為ではHuman Approvalを設計し、機微・曖昧なケースは人へ引き継ぐことを推奨しています。NIST AI RMF Coreも、人とAIの役割・責任やHuman oversightを定義・文書化することを示しています。ここからHR Agent Labでは、単なる「人の確認有無」ではなく、意思決定権そのものを設計対象として整理しています。
人事業務は「Agentが準備し、人が決め、Agentが続ける」に分解できる
人事で重要なのは、センシティブな業務をAIから丸ごと外すことではありません。重大判断の前後にある作業をAgentへ移し、人が判断した後は再びAgentが処理を続けられるようにします。
この考え方は、AIが最終判断をしないから価値が低い、という発想とは逆です。人の判断に必要な事実・選択肢・リスクを揃え、判断後の登録・通知・記録までAgentが継続すれば、人が担当するのは本当に人が持つべき意思決定だけになります。
「任せない判断」を決めたら、その前後はできるだけAgentへ移す
Human-in-the-loopを設けると、人間の確認工程が増えて自動化効果が落ちるように見えます。しかし、設計すべきなのは「人が確認する画面」ではなく、人へ渡すまでにAgentがどこまで準備し、判断後にどこから自動再開するかです。
- 必要データと規程を集める
- 事実と推測を分ける
- 候補・代替案・リスクを並べる
- 何を判断してほしいかを一つに絞る
- 判断根拠をCaseへ残す
- 価値基準を選ぶ
- 重大な結果を承認・否認する
- 例外の解釈を決める
- 組織としての確定判断をする
- 必要ならルール変更を指示する
- approve / reject / revise
- 例外の扱い
- 追加条件
- 必要な説明
- システム更新
- 通知・依頼
- 後続タスク生成
- 結果確認
- 監査証跡の記録
Human Approvalを「人に仕事を戻す場所」にしない。人が判断したら、Agentがその結果を受け取って自動再開する。
Agentには「何をできるか」だけでなく「何を決めてよいか」を持たせる
実装では、ツール権限だけを絞っても十分ではありません。Agentがアクセスできる機能と、Agentが自律的に確定してよい意思決定は別物です。たとえば人事マスタ更新APIへ接続できても、すべての項目変更をAgentが自動確定してよいとは限りません。
read / draft / recommend / approve / execute / change-policy を分け、Agentがどこまで進めるかを明示します。
API・RPA・メール送信等の技術権限と、業務上の承認権限を別々に管理します。
判断対象、事実、根拠規程、未確定事項、候補、影響、推奨案を構造化し、人が再調査しなくても判断できる状態をつくります。
承認・否認・修正・追加情報要求の各結果から、どのステップへ戻るかを状態として実装します。
Agentの提案、人の判断、理由、実行結果を同じCase IDや処理IDへ紐づけます。
MicrosoftのAI agent shared responsibility modelでは、データ、Agent identityと最小権限、行為のAuthorization、Human oversight、ガバナンスは利用組織が保持する責任として整理されています。Agentに「できること」を増やすほど、誰が何を決めてよいかを明示する必要があります。
最初に作るのはAIユースケース一覧ではなく「意思決定権インベントリ」
人事AIエージェントを設計するとき、機能一覧から始めると「問い合わせ回答」「勤怠チェック」「異動支援」といった大きな単位になります。代わりに、業務内のアクションを並べ、それぞれについて誰が意思決定権を持つかを整理します。
収集、照合、候補生成、判断、承認、更新、通知、完了確認まで分けます。
収集・整理 / 提案・準備 / 決定・承認 / ルール変更のどこに該当するかを付与します。
価値基準、重大影響、例外解釈、Authorityのどれか。理由が曖昧なら、本当に人が必要かを再検討します。
人へ渡すEvidence Packと、判断後にAgentが再開する後続処理を決めます。
この整理をしたうえで、影響度・可逆性・不確実性・権限によるHuman-in-the-loop設計を重ねると、どこを自動実行し、どこをHuman Approvalにし、どこを例外引継ぎにするかまで落とせます。技術実装の順序は人事AIエージェントの実装方法で整理しています。
参考情報・出典
以下は記事の判断軸を検討するために参照した一次情報です。各国・地域の法令適用は業務・地域・利用方法によって異なるため、本文では個別法令を一般化せず、HR Agent Labの設計原則と外部ガイダンスを分けて記載しています。