これまで私は、RPAを中心に業務自動化の支援を行ってきました。
RPAは、決められたルールに沿って画面を操作したり、データを取得・転記したりする処理には非常に向いています。
一方で、実際の業務には、
- 文章を読んで内容を理解する
- 条件との適合度を判断する
- 相手に応じて文章を作る
といった、ルールだけでは処理しづらい業務も多くあります。
今回取り組んだ採用業務も、その一つでした。
自動化したのは「書類選考」と「スカウト」
対象としたのは、主に以下の2業務です。
書類選考
応募者の職務経歴書やプロフィールを確認し、
- 採用条件に合っているか
- 書類選考を通過させるか
- どのような点を面接で確認すべきか
を判断する業務です。
スカウト
複数の求職者の中から、
- 自社の採用条件に合う人を探す
- 候補者ごとにスカウト文面を作る
- 採用媒体上で下書きを作成する
という業務です。
これらを、RPA・Gemini・n8nを組み合わせて自動化しました。
「全部AIにやらせる」のではなく、得意な処理を分担する
今回特に意識したのが、技術ごとの役割分担です。
RPAには、
- 求職者プロフィールの取得
- 職務経歴書等のデータ取得
- 採用媒体上の画面操作
- スカウト下書き作成
といった、定型的な処理を担当させました。
一方、Geminiには、
- 経歴情報の読解
- 採用条件とのマッチ度分析
- 書類選考の一次判定
- 応募者向けメッセージの生成
- 面接時に確認すべき事項の整理
- スカウト候補者の選別
- 候補者に合わせたスカウト文面の生成
といった、文章の理解や判断が必要な処理を担当させています。
そして、これら一連の処理をつなぎ、ワークフロー全体を管理しているのがn8nです。
Geminiはn8nからAPI経由で呼び出しています。
つまり、
RPA＝操作・定型処理
LLM＝読解・分析・判断・文章生成
n8n＝全体のオーケストレーション
という役割分担です。
いきなり本番導入したわけではない
生成AIを業務に導入する場合、最初から完成形を作るのは難しいと考えています。
今回も、
プロトタイプ作成
→ 実データで検証
→ 採用担当者に確認
→ フィードバック
→ プロンプト・判定条件・処理フローを改善
というサイクルを何度も回しました。
例えば、
「この経歴なら通過させたい」
「この条件はもう少し重要度を高くしたい」
「このスカウト文章だと少し機械的に見える」
といった現場からのフィードバックを受けながら、仕組みを改善していきました。
最終的には本番導入まで行い、現在も運用・保守・継続改善を行っています。
最終判断は人が行う
もう一つ重要なのが、AIに最終判断を任せていないことです。
Geminiが分析や一次判定を行いますが、最終的な合否は採用担当者が確認します。
いわゆるHuman-in-the-loopの構成です。
生成AIを業務へ導入する場合、
「どこまでAIに任せるか」
「どこから人が判断するか」
を設計することは、技術選定と同じくらい重要だと感じています。
現在は月300〜500件規模で本番運用
現在、この仕組みは本番環境で稼働しており、月間約300〜500件の応募者・求職者情報を処理しています。
従来のRPAだけでは難しかった、
非構造データを読む
→ 内容を分析する
→ 条件と照合する
→ 判断する
→ 文章を生成する
という領域まで、自動化対象を広げることができました。
この取り組みから感じたこと
今回改めて感じたのは、
「RPAかAIか」ではなく、「どの技術をどの業務に使うか」が重要
ということです。
RPAにはRPAの強みがあり、LLMにはLLMの強みがあります。
すべてを生成AIに置き換える必要はありません。
まず業務を分解し、
- ルール化できる部分
- 人間の判断が必要だった部分
- システム操作が必要な部分
を整理した上で、適切な技術を組み合わせる。
この考え方は、採用業務だけでなく、多くのバックオフィス業務や業務改革にも応用できると考えています。
今後も、単に新しいAI技術を導入するのではなく、実際の業務課題を起点に、現場で使われ続ける仕組みまで作ることを大切にしていきたいです。
