採用AIは、データの前提から考える。
ServiceNow×Findemを、日本企業でどう生かすか。

採用からマネジメントまで、
4つのAssistantを限定提供。

ServiceNowは2026年11月4日、HR Service Delivery向けのProductivity Assistantsを紹介しました。新たなHiring Assistantを加え、EmployeeWorksの中で人事と管理職の仕事を支援する構成です。^[1]

出典：[1]。HRBPは、人事面から事業部門の人材課題を支援するHR Business Partnerを指します。

ServiceNowとFindemが統合し、タレントインテリジェンスと採用を強化

今回の発表では、Findemの人材インサイトと採用機能を、ServiceNowのTalent Insights AssistantとHiring Assistantへ統合することが明示されています。Findemが持つ外部の人材情報を、人事や採用担当者が使うServiceNow上の体験へ取り込む構成です。^[1]

Hiring Assistantでは、Findemが職務要件に沿った候補者探索、スクリーニング・評価、資格確認を担い、管理職が面接と判断へ時間を使えるよう支援します。Talent Insights Assistantでは、FindemのTalent Graphが人材市場への回答を支えます。採用対象の市場や人材の移動を把握し、後継者の検討にも外部の情報を使う、という位置付けです。^[1]

Deloitteは、人事変革から導入・データ整備等を支援する役割です。4つのAssistantはいずれもControlled Availability、つまり提供対象や条件を限定した段階です。^[1]

採用から入社までの、どこを担うのか

採用は候補者を見つけて終わりではありません。一般的な業務を次の7段階に分けると、今回の統合が厚くする場所と、それ以外の業務が見えます。

1. 採用計画・要件定義：必要な役割、スキル、人数、予算を決める。
2. 採用要求・募集準備：募集を申請し、要件・条件・進め方を確定する。
3. ソーシング・接点形成：候補者を探し、応募や面談につながる接点を作る。
4. 書類確認・面接・評価：経験や資格を確認し、面接を通じて適合性を判断する。
5. 採否判断・オファー：採用するか、どの条件を提示するかを決める。
6. 承諾・入社手続き：意思確認、必要書類、雇用条件等の手続きを進める。
7. 入社準備・受け入れ：端末、アカウント、配属、上長との初期の対話を整える。

◎：公式説明された機能・対象範囲を工程へ配置。Hiring Assistantの「採用要求〜オファー」は全体の支援範囲であり、各工程の細かな処理をすべて標準で実行するとの意味ではありません。△：公式の役割を踏まえたNumberの配置・業務設計例。—：今回の発表でその工程の担当を示していないもの。機能が存在しないという断定ではありません。出典：[1]。

4つのAssistantは工程ごとに一対一で担当する仕組みではなく、管理職、人事担当、経営・人材戦略側という役割から仕事を支援する構成です。

Findemを支えるのは、人材データと公開職歴の文化

Findemは、外部の職歴・スキル情報と、自社のATS・CRMをつなぎ、候補者探索、関係管理、人材市場の分析を支える基盤です。既存の採用管理システムを補完し、蓄積した情報を採用活動と判断へ使う仕組みと捉えると分かりやすいでしょう。^[2][4]

背景として注目したいのは、米国ではホワイトカラーを中心に、LinkedInへ職歴やスキルを載せ、自分の専門性を示す文化が広がっていることです。LinkedInの米国レポートは、同国内に2億5,200万人超のメンバーがいると説明しています。登録者数は職歴公開率そのものではありませんが、職業上の情報を共有する場の広がりを示します。^[5]

私は、こうした公開キャリア情報の蓄積が、外部データから人材像を捉えるサービスを支える前提の一つだと考えます。日本企業は、同じ職歴公開の広がりを当然の前提にせず、自社が採りたい職種・人材で情報がそろうかを確認する必要があります。利用可能なデータは法令や情報源の規約にも左右されますが、まずはデータがどこに、どのような形で蓄積されるかという文化の違いが重要です。

AIの活用で、
データドリブンの採用は加速する。

私は、今回の発表の価値を、採用計画から逆算し、必要な活動量を確保しながら、結果を見て改善する採用を進めやすくする点に見ています。外部の人材情報、社内の採用実績、各工程の進捗がつながれば、経験や感覚だけに頼らず、どこで何を変えるべきかを検討できます。

採用計画を、工程ごとの必要数へ分解する

採用目標から、必要なオファー数、面接数、候補者との接点数を逆算します。たとえば「必要なオファー数＝目標入社数÷オファーから入社への遷移率」のように、一つ前の工程へ戻って必要数を見積もります。これは固定の答えではなく、職種、採用経路、時期ごとの実績から更新する計画です。

図：Numberの採用運営モデル。製品の標準ダッシュボードや保証された導入効果を示すものではありません。

遷移率の管理と、傾向分析を改善へつなぐ

接点から返信、面接からオファー、オファーから入社へ。工程ごとの遷移率を見れば、単に候補者数が少ないのか、要件と対象がずれているのか、選考中の待ち時間や提示条件に問題があるのか、調べるべき場所が見えてきます。

AIには、採用経路や職種ごとの違い、辞退理由の傾向、進捗の停滞を整理し、改善仮説を作る支援が期待できます。率を比べるときは、集計対象と期間をそろえ、まだ選考中の案件を未達と混同しないことも必要です。差が見つかっただけで原因を断定せず、現場の記録と照合します。

生産性を上げ、計画に見合う試行回数を確保する

必要な接点数が分かっても、担当者が候補者の情報整理や転記、文案作成、日程調整に追われていれば、活動量を確保できません。私は、AIやRPAによってこうした各業務の生産性を高め、採用計画に対して十分な試行回数を実行できる体制へ近づけることに意味があると考えます。

試行回数とは、無差別に大量の連絡を送ることではなく、要件に合う候補者へ適切な提案を届け、反応と選考結果から学べる接点を積み重ねることです。候補者数や面接担当者の余力にも制約があるため、自動化だけで活動量や採用成果が保証されるわけではありません。

日本企業では、分散した採用データを
計画と改善につなぐ。

日本企業への適用では、海外と同じ外部人材データ基盤を作ることを出発点にする必要はありません。私は、自社が利用する採用媒体、人材紹介会社、過去の応募者、リファラルの情報を、同じ採用計画に対して比較できる状態にすることから始められると考えます。

媒体・紹介会社をまたいで、同じ工程を追う

媒体ではスカウト数、人材紹介会社では推薦数、社内では面接数だけを見ていると、どこが入社につながったのかを追いにくくなります。経路ごとの入口の違いを残しつつ、書類確認、面接、オファー、承諾、入社という共通の工程へ対応付けます。

表：Numberの管理設計例。媒体ごとに同じデータを取得できるとは限らず、契約上利用可能な情報を対象とします。

AIとRPAは、採用担当者の実行余力を生むために使う

契約上利用できるAPIや出力データがあれば登録・更新をつなぎ、許可された画面操作をRPAで補う方法も検討できます。AIは求人・スカウト文案の作成、記録の要約、辞退理由の分類、傾向分析などを支援します。ServiceNowは、その情報を使う依頼・承認・担当者のタスクをつなぐ基盤として位置付けられます。

先に各媒体や採用管理システムの既存機能を使う選択もあります。たとえば、ビズリーチにもAIによるスカウト文面作成支援があり、すべてを新たに構築する必要はありません。^[3]

計画未達の原因によって、投資先は変わる

調整負担で必要な活動量を実行できていない企業なら、自動化に検討価値があります。活動量は十分でも遷移率が低いなら、求人要件、候補者との接点、選考体験、提示条件の見直しが先かもしれません。採用数が少なく現状で支障がなければ、新たな基盤への投資を急がない判断もできます。

自社で運用するために、
まず整えること。

まず一つの職種・採用経路で、目標数、各工程の遷移率、実行できる活動量を照らし合わせます。媒体や紹介会社との接点を含め、許可された情報を受け取り、整理し、担当へ渡す仕事から考えます。新しい採用基盤の購入だけが選択肢ではありません。

表：Numberの設計例。特定の媒体でRPA操作が許可されていることや、ServiceNowの標準機能・連携提供を示すものではありません。

RPAは決めた手順の転記や画面操作、AIは文章・情報の整理など、それぞれの得意な作業を担います。APIが使えるなら、その方法も比較します。媒体の規約や権限を超える取得・自動送信を前提にせず、RPAの画面変更対応や保守費用も投資判断に含めます。

まず一つの採用経路で、流れと責任を見えるようにする

自社の媒体検索か、人材紹介会社からの紹介か、過去の応募者への再接点か。経路を一つ選び、情報の出どころ、利用目的・期間、保存先、参照できる人、更新する人を整理します。各工程の状態と集計基準をそろえ、どの記録を誰が残すかを決めます。そのうえで、計画に必要な活動量を妨げている作業を見つけ、小さく試します。

ServiceNowには、これらの依頼・確認・承認・状態をつなぐ役割を持たせる設計が考えられます。既存の採用管理システムを正本に残す場合も、識別子と更新責任を定めます。候補者の評価・採否判断と、作業の自動化は分けます。

採用件数や調整負担が小さければ、新たな基盤やRPAへの投資を急がない選択もあります。海外の構成を再現する前に、自社が使える情報と、自動化したい仕事を特定する。AI・RPAで実行余力を生み、遷移率と傾向を見て活動を変える。私は、その循環を回すために日本企業の採用AIを考えたいと思います。