AIエージェントに人事業務を渡すとき｜渡してはいけない4つ

AIエージェントに人事業務を渡す話が、検討の段階に入ってきました。問い合わせ対応、日程調整、書類の不備チェック、月次レポートの作成。どれも人事の時間を実際に食っている仕事です。

生成AIとの違いは、答えるだけでなく実行することです。メールを送る、システムに書き込む、次の処理を起動する。この違いが、設計で気をつける場所を変えます。

この記事では、人事業務を渡せるものと渡せないものに分け、渡してはいけない4つを挙げます。数字はCapLeadのデモで使っているサンプルデータ（架空のグループ「サンライズHD」12社・従業員8,420名）です。実在の企業のデータではありません。

AIエージェントに人事業務を渡すと、何が変わるか

生成AIに人事業務を任せるとき、出力は文章でした。おかしければ人が直せます。

AIエージェントは違います。判断した結果として、外向きの動作をします。送信済みのメールは取り消せません。書き込まれた等級は、誰かが気づくまで正しい値として扱われます。

もうひとつの違いは速度です。人が一件ずつ処理していれば、途中でおかしいと気づく機会があります。エージェントは百件を数分で処理します。間違いも同じ速さで広がります。

だから設計の重心は「精度を上げる」ことより「間違えたときに何が起きるか」に移ります。実行する前に止まる場所をどこに置くか、という設計です。

判断の基準はひとつで足ります。その処理が間違っていたとき、取り消せるか、そして誰かが気づくか。両方に「はい」と答えられる処理は渡して構いません。どちらかが「いいえ」なら、手前に人を置きます。業務の重要度ではなく、可逆性と可視性で切ってください。

人事業務を3層に分ける

渡せるかどうかは、業務の種類ではなく層で決まります。

読む層は、範囲の制御さえ効いていれば渡して問題になりません。下書き層は、人の承認を必ず挟みます。実行層だけが、設計の手間をかける価値がある場所です。

人事の時間を実際に食っているのは、多くの場合この読む層です。数字を集める、資料の形にそろえる、問い合わせに答える。ここを渡すだけで効果は出ますし、事故は起きにくい。実行層まで広げないと意味がない、という前提は置かないでください。

自社の業務を分類するときは、業務名ではなく動詞で書き出すと早く進みます。「採用管理」ではなく「応募書類の不備を確認する」「候補者に日程候補を送る」「選考結果をシステムに記録する」。動詞にすると、どれが読む層でどれが実行層かは迷いません。

よくある失敗は、この3層を1つの業務として渡してしまうことです。「月次レポートを作って関係者に送って」は、読む・下書き・実行の3つが1本につながっています。送信の手前で必ず止まる形に切り分けてください。

渡してはいけない4つ

1. 人の処遇が決まる判断。 昇進、評価の確定、契約更新の可否。案を出させることと、決めさせることは別です。決定の主体は人のままにして、その判断に使った材料と比較集団を記録します。
2. 少人数の区分を含む出力。 「研究所の部長級の女性」のような区分は該当者が数名になります。エージェントが要約文を書けば、画面で非表示にしていても本文に現れます。しきい値は生成の側にも効かせてください。
3. 社外への送信。 取引先や応募者への連絡は、文面が正しくても宛先を間違えれば事故になります。社外向けは下書きまでにしておくのが無難です。
4. 定義が固定されていない指標の計算。 分母が決まっていない指標をエージェントに計算させると、実行のたびに違う数字が出ます。しかも毎回それらしい説明がつきます。

4つに共通するのは、間違いが後から取り消せないか、気づけないかのどちらかだという点です。取り消せて気づけるものは、渡して構いません。

この4つは、禁止事項として掲げるより、例外の手続きとして書いておくほうが運用に乗ります。どうしても渡したい場面は出てきます。そのとき誰が承認し、どの記録を残すかを先に決めておけば、現場が黙って回避する事態を防げます。

サンプルデータで見る：同じ指示、違う相手

範囲の制御が効いているとはどういうことか、具体例で見ます。

「今月の人事サマリーを各社の責任者に送って」という同じ指示を、サンプルデータのグループで実行した場合です。同じテンプレート、同じ配信設定で、描画の時点で宛先ごとのスコープが適用されます。

3通とも同じ指示から生成されています。違うのは、誰が受け取るかによって読める範囲が変わることです。プロンプトに「このデータは見せないで」と書く方式ではありません。書き忘れれば漏れるからです。

この方式の利点は、指示を書く人が範囲を意識しなくてよくなることです。書き手が気をつける仕組みは、書き手が増えると壊れます。受け取る人の権限で描画が変わるなら、指示は業務の中身だけを書けば足ります。

比較の集団も同じ扱いにします。サンプルデータでは、上位10%を全体順位で取ると女性の該当率は8.9%、男性は15.4%。同性内で取ると女性12.1%、男性12.4%でほぼ同じになります。エージェントに候補者を挙げさせるなら、どちらの集団で順位をつけるかを基盤側で固定してください。考え方は「次世代リーダー候補の選抜で女性が少なくなる理由」で扱いました。

権限は、指示ではなく基盤側に置く

設計の分かれ目はここです。誰が何を見てよいかを、プロンプトに書くのか、データ基盤の設定として持つのか。

プロンプトに書く方式は、最初は動きます。ただ、指示を書く人が増えると必ずほころびます。担当者が変わったとき、急ぎの依頼で一文が抜けたとき、テンプレートを誰かが複製したとき。人の注意力に依存する仕組みは、忙しい時期に壊れます。

基盤側に置けば、指示がどう書かれても範囲は変わりません。エージェントが見られるものは、その実行者が見てよいものだけになります。

あわせて、実行の記録を残してください。いつ、どのデータを、どの定義で読んで、誰に何を送ったか。後から説明を求められたときに答えられるのは、この記録があるときだけです。

記録は監査のためだけのものではありません。出力がおかしいと気づいたとき、原因がデータなのか定義なのか指示なのかを切り分ける手がかりになります。記録がないと、切り分けに時間がかかり、そのあいだ運用を止めることになります。

よくある失敗

• 実行まで一気に自動化する。 送信の直前に人が承認する形にしておけば、事故の大半は防げます。省ける手間の割に、失うものが大きい設計です。
• テストを少人数で回して本番に広げる。 少人数では出なかった区分が、全社では出ます。少人数区分の非表示は、本番の規模で試してください。
• エラーだけを監視する。 エージェントの怖い失敗は、エラーを出さずに完了する処理です。出力の内容を抜き取りで見るより、読ませた範囲と定義を監視するほうが効きます。
• 指標の定義を渡さずに計算させる。 離職率ひとつでも、分母の取り方で数字が変わります。定義の置き方は「離職率の計算方法」にまとめました。
• やり直しの手順を決めずに始める。 誤って送った、誤って書き込んだときに、誰が止めて誰が訂正するかを先に決めておきます。決めていないと、事故のときに止めるまでの時間が延びます。
• 予兆の検知をそのまま通知に流す。 離職の予兆のような出力は、本人や上司に伝わった時点で影響が出ます。誰に何を通知するかは、検知の精度とは別に決めてください。扱いは「離職の予兆をデータで捉える」で触れています。

Floraの支援：実行の手前で、範囲と根拠を固定する

Flora株式会社の「CapLead」は、グループ各社の人事・人的資本のデータを一つの基盤で管理し、指標ごとの定義を版で固定して、元ファイルの行まで遡れる出典を残します。同じ配信設定・同じテンプレートでも、描画の時点で受け取る人のスコープが適用されます。人数の少ない区分は、画面にも書き出しにもメール本文にも出ません。

エージェントに何を渡すにせよ、その手前で必要になるのはこの部分です。まず30分、貴社グループで自動化したい業務をお聞かせください。

まとめ

AIエージェントに人事業務を渡すときの設計は、精度の話ではなく、間違えたときに何が起きるかの話です。読む・下書き・実行の3層に分け、実行層だけに手間をかけてください。

渡してはいけないのは、処遇が決まる判断、少人数区分を含む出力、社外への送信、定義の固定されていない指標の計算です。判断の基準は業務の重要度ではなく、取り消せるかと、誰かが気づくかの2つです。そして誰が何を見てよいかは、プロンプトではなくデータ基盤側に置きます。公表する数字の定義については「女性管理職比率の公表」も参考になります。

--- CTA: 30分ヒアリング（無償）を申し込む → /ja/caplead