導入の進め方と課題の記録|採用業務のAI活用(第8部)
1つの作業に1か月かけてAIを導入する進め方を、週ごとに解説します。AIを使った作業で起きた事例と防ぐための指示、費用の考え方、引き継ぎ、AIを入れたあとに人が担うことをまとめています。
この記事は、シリーズ「採用業務のAI活用」(全8部)の第8部です。各部の一覧はシリーズの目次にあります。内容は、HRdevが採用支援の実務で培った知見をもとにした使い方の例です。
最終回です。第1部から第7部では、AIを使い始める前の準備と、作業ごとのAIの使い方を説明してきました。第8部では、導入の一例として、1つの作業に1か月かけて取り組む進め方を共有します。あわせて、HRdevがAIを使った作業で経験した事例と、そこから得た防ぐための指示を紹介し、導入の段階で避けること、費用の考え方、引き継ぎ、AIを入れたあとに人が担うことをまとめます。1つの作業から始め、起きた課題をAIへの指示に反映し続けることをおすすめします。
1. 最初にAIを入れる作業の選び方
AIを使い始めるときは、求人票・スカウト・分析を一度に切り替えず、1つの作業だけで始めます。うまくいかなかったときに、どの作業で問題が起きたのかを突き止められるようにするためです。どの作業から始めるかは、確定した求人票があるか、判定の基準を現場と合意しているかなど、いま手元にある材料で決定します。
導入で起きやすい課題は、すべての作業を一度にAIへ切り替えようとして、どこで出来が悪くなったのかを突き止められなくなることです。求人票もスカウトも分析も同時に進めると、原因が複数の作業にまたがります。原因を突き止められる状態を保つために、最初は1つの作業から始めます。
最初の対象は、同じ作業の繰り返しが多く、間違いに気づきやすい作業から、確定した求人票や現場と合意した判定基準など、いま手元にある材料に合わせて選びます。
手元の状況 | 最初の対象 |
|---|---|
求人票が現場の回答待ちで止まっている | 現場への質問票づくり(第3部3-2) |
確定した求人票がある | スカウト文面の下書き(第5部) |
送る相手の判定基準を現場と合意している | スカウト対象の判定(第4部) |
1か月かけて試す前に30分でAIを確認する方法
2章で説明する、1つの作業を1か月かけて試す進め方に入る前に、AIがどの程度使えるかを30分ほどで確認することもできます。公開済みの求人票を、社内で利用が認められたAIに渡し、「この求人について、現場に確認すべき質問を3つ挙げてください」と頼みます。返ってきた質問のうち、実際に現場へ聞けるものを選び、使えると判断した理由と一緒に記録しておきます。
2. 1か月の取り組み方
1章で選んだ1つの作業にAIを入れ、週ごとに成果物と次の週へ進む条件を決めて進めます。1か月後に採用の責任者が、AIを使う作業をほかにも広げるか、同じ作業で検証を続けるか、手作業に戻すかを決定します。
図1 1つの作業に1か月かけて取り組む全体像

週ごとにやることと次へ進む条件を決めておき、1か月後に採用の責任者が続け方を決定します。1か月は目安です。
採用担当は、この1か月の取り組み全体のオーナーとして、管理シートとルールを用意し、進行を管理します。現場の責任者とは同じチームとして、判断の基準を決める場面で力を借ります。そのための材料は採用担当が準備し、現場の負担を下げます。
週 | 成果物 | 主な担当 | 次へ進む条件 |
|---|---|---|---|
第1週 | 管理シート | 採用担当 | 今の作業を1週間分、表に記録できた |
第2週 | ルールの文書と、全件確認の記録 | 採用担当が書き、現場の責任者が基準を確認する | 全件を人が確認し、人の決定の列に記入した |
第3週 | 追記したルール | 採用担当。基準を変更するときは現場の責任者と合意する | 同じ迷いが減った |
第4週 | 関数による確認(選択肢との一致・空欄・候補者IDの照合)と、人が確認する範囲の判断 | 採用担当。範囲を絞る判断は採用の責任者が承認する | 確認した件数と誤りが、先に決めた条件を満たした |
進め方ごとの道具の役割
ルールを書いたタブをAIに読ませ、答えをシートに書き込み、機械的に確認する作業は、進め方によって担う道具が異なります。Geminiのスキルは、チャットで呼び出す指示と資料を保存する機能です。管理シートの行ごとに答えを書き込んだり、確認の処理を全行に繰り返したりする仕組みではありません。
作業 | 進め方A | 進め方B |
|---|---|---|
ルールを読ませてAIを動かす | スプレッドシートのAI関数。AI関数はほかの関数の中に入れられず、シートの内容は範囲で渡したセルしか読まないため、ルールの全文とその行の材料を1つのセルに連結する列を作り、その列を範囲として渡す | Claude CodeやCodexが管理シートとルールのタブを読み、まとめて処理する |
答えをシートに書き込む | AI関数のセルがそのままAIの答えの列になる | Claude CodeやCodexが候補者IDの列で行を探して書き込む |
機械的な確認 | 通常の関数(選択肢との一致、空欄、候補者IDの照合)で確認する | 書き込む前の処理の中で確認し、通ったものだけを書き込む |
事前の準備 | AI関数を使える契約か、管理者に確認する | Claude CodeやCodexからスプレッドシートにつなぐ設定(第2部6章) |
求人票の原稿や長文のスカウトのように1件ずつ丁寧に作る文章は、進め方AではGeminiのスキルをチャットで呼び出して作成し、人が確認してからシートに貼り付けます。
第1週 管理シートの作成
この週はAIを使いません
対象に選んだ作業のスプレッドシートを用意します。1行を1人の候補者、または1つの求人にあて、列を「目印」「材料」「AIの答え」「人の決定」「実績」「自動計算」の6種類に分けます(第2部5章の表と同じ分け方です)。目印にはID列を使い、行番号で行を指さないようにします。
この週は、今行っている作業をそのまま表に写します。手作業のまま1週間続けてみて、足りない列があれば追加します。管理シートがないままAIから始めると、AIの答えを書き込む場所がなく、書かせた文章だけが増えていきます。
スカウト対象の判定を例にしたサンプルの管理シートを用意しました。架空の候補者8人を記録した見本で、列は6種類ごとに色分けし、IDの重複と記入漏れは関数で印が付きます。AIの答えの列は第2週まで空けておきます。ファイルメニューの「コピーを作成」で複製し、自社の作業に合わせて列を追加して使ってください。
第2週 ルールの文章化とAIの導入
全件を人が確認します
判定のルールや文面の指示を、別のタブに文章で書きます。頭のなかにある判断の基準を文章にする作業は、想像より時間がかかります。半日を見込んでください。
書けたら、AIの答えの列と人の決定の列を分けたうえで、AIを動かします(進め方ごとの道具は上の表のとおりです)。この週は全件を人が確認し、人の決定の列に記入します。AIの答えを直接上書きしないでください。判定の作業では、AIを動かす前に、確認を絞り込んでよい誤りの目標を決定しておきます(第4部6章)。
第2週の見本シートは、判定ルールのタブとAI関数の列を足した形です。AI関数には、ルールの全文とプロフィールを1つのセルに連結して渡し、区分・理由・使ったルールの版を1回の答えから関数で取り出しています。見本では、12人中4人でAIの答えと人の決定が食い違い、別の1人はAIの答えが要確認でした。食い違った4人のうち1人は、AIが区分を「区分C」のように決めた書き方と違う形で返した行です。候補者はすべて架空です。ファイルメニューの「コピーを作成」で複製して使ってください。
第3週 AIの答えと人の決定が違った原因のルールへの反映
ルールの記述が増える週です
AIの答えと人の決定が食い違った行と、AIが要確認とした行を読み返します。原因は3つに分かれます。ルールに書いていない条件で人が判断していたか、ルールの言葉があいまいでAIが別の意味に受け取ったか、人の判断のほうが誤っていたか、のどれかです。
前の2つは、ルールに追記します。HRdevの経験では、この週にルールの分量が倍近くになることがよくありました。進み具合は、AIの答えと人の決定が違う行と要確認の行が、前の週より減ったかどうかで確認します。文面づくりを対象にした場合は、人が修正した箇所を読み返し、修正した理由をルールに追記します。
第3週の見本シートは、第2週のAIの答えを値で貼り付けて残し、食い違いの原因を3つから選んで記録したうえで、ルールをv2に書き直して生成し直した形です。v2では、第2週に食い違った4人と要確認になった1人を含め、12人全員でAIの答えと人の決定が一致しました。候補者はすべて架空です。ファイルメニューの「コピーを作成」で複製して使ってください。
第4週 人が確認する範囲の絞り込み
人が確認する範囲を絞れるかを判断します
機械的な確認を作成します。AIの答えが決めた選択肢のどれかになっているか、必ず埋める列が空いていないか、書き込んだ行の候補者IDが対象と一致しているか。この3つを、関数か処理の中で確かめる形にします。文面づくりを対象にした場合は、材料が足りない箇所に付けた印(🟡など)が残っていないか、字数が上限を超えていないか、使わない言い回しが入っていないか、決まり文句とリンクが抜けていないか、面談へのお誘いが1回だけかの5つ(第5部5-2)を関数で確認し、材料にない事実が入っていないかは人が確認します。
判定の作業では、確認した件数が足り、2つの誤り(送るべき人を外した誤りと、送らない人を残した誤り)がどちらも目標を下回った場合に限り、確認を一部に絞ります。件数が足りない場合や目標に届かない場合は、全件の確認を続けます。候補者に送る文面は絞り込みの対象にせず、引き続き送る前に人が確認します。
第4週の見本シートは、機械的な確認の3列と、確認した件数・2つの誤りを目標と比べる集計のタブを足した形です。候補者はすべて架空です。ファイルメニューの「コピーを作成」で複製して使ってください。
1か月後の判断の材料は、確認した件数、誤りの内容、確認を含めた作業時間です。急ぐ場合は、第1週の管理シートの作成だけを、複数の作業で同時に進めてください。
3. 起きた事例と防ぐための指示
HRdevがAIを使った作業で経験した事例を5件紹介します。事例ごとに、起きた時期と当時使っていたモデル、どの手段で見つけたか、同じことを防ぐためにAIへの指示に入れる内容を示します。
図2 5つの事例を見つけた方法と防ぐための指示の要点

5件とも、AIの出力を別の手段(別のAI、文字起こしの原文、プログラムの計算、日付の数え直し、名義に使われた本人)と照らしたことで見つかっています。
各事例の「防ぐための指示」は、AIへの指示に入れておく内容で、事例から得た対策の例です。新しいモデルを使う場合も入れておくことを推奨します。モデルが変わっても、出力を別の手段で照らす手順がなければ、同じ種類の誤りを見つけられないためです。
事例1 一括生成でのポジションと本文の取り違え
複数のポジションの文面を1回でまとめて書かせ、ポジションごとのIDを付けて返させる仕組みで、返ってきたIDが依頼した一覧と合っているかを確かめていませんでした。バックエンドエンジニア向けの本文がデータエンジニアのIDで返ってきても、字数などの確認は通るため、そのまま書き込まれる仕組みになっていました。人は字数と言い回しを中心に確認していてポジションと本文の対応は確認の対象に入っておらず、AIも返したIDが依頼どおりかを確かめていない状態でした。別のAIによる点検で見つかり、送る前に修正しました。この事例は支援先ごとの文面をまとめて書かせた際に起きたもので、ここでは事業会社で同じ仕組みを使う場面に置き換えて説明しています。
項目 | 内容 |
|---|---|
時期 | 2026年9月 |
モデル | Claude Sonnet 5 |
見つけた方法 | 別のAIによる点検 |
防ぐための指示
「1件ごとに、依頼した一覧のIDをそのまま付け、本文の根拠にした資料(求人票や候補者の職務経歴)の一文を原文のまま添えて返してください。一覧にないIDは使わず、同じIDを2回使わないでください。」
候補者へのスカウト文をまとめて書かせる場合も同じです。IDの照合だけでは、一覧にあるID同士で本文が入れ替わった誤りは見つかりません。返ってきたIDが一覧と一致し重複がないかを関数で照合し、添えられた一文がそのIDの候補者の職務経歴にあるかも関数で確認します。
事例2 AIの要約に基づく報告の誤り
支援先向けの資料を作成している途中で、AIが会議の記録の要約にあった一行を根拠に、既に決まっていた方針と矛盾すると担当者へ報告しました。報告を受けた担当者が文字起こしの原文を確認すると、発言には前置きが付いており、要約とは逆の趣旨でした。数字も要約の段階で丸められていました。AIは要約を発言そのものとして扱い、要約の段階で発言者と前置きが落ちていることに気づいていませんでした。提出する前に修正しています。
項目 | 内容 |
|---|---|
時期 | 2026年8月 |
モデル | Claude Opus 5 |
見つけた方法 | 文字起こしの原文との照合 |
防ぐための指示
「会議の内容を根拠に使うときは、要約ではなく文字起こしの原文から、発言者と前後の文を含めて引用してください。原文で確認できない内容は「未確認」と書いてください。」
要約は話題を探すための目次として使い、言い切った内容、数字、誰の発言かは原文で確認します(第6部2-3)。
事例3 AIの集計による人数と転職回数の誤り
選考データの分析で、AIは選考を通過した人数を5名と集計しましたが、プログラムで数え直すと16名でした。1人の候補者に複数回の評価が付いたデータの構造を、AIが読み落とした結果です。同じ分析で、転職回数の平均を12.6回、最大を23回と出しました。こちらは職務経歴書に並んだプロジェクト名を、それぞれ別の会社として数えた結果です。どちらも、AIの答えをそのまま使わず、プログラムで計算した値と照らした段階で見つかりました。
項目 | 内容 |
|---|---|
時期 | 2026年8月 |
モデル | ClaudeとOpenAIのCodex(どちらでも起きました) |
見つけた方法 | プログラムで数え直した値との照合 |
防ぐための指示
「人数や平均などの数値を出すときは、数えた対象の一覧と計算の手順を併せて示してください。転職回数は、プロジェクト名ではなく在籍した会社名で集計してください。」
出てきた数字は、関数で数えた値と照らしてから使います(第7部)。
事例4 日付と曜日の不一致
作業の引き継ぎの記録に「9月5日(金)」と書かれており、AIはその曜日を前提に、平日に動くはずの処理が止まっていると報告しました。実際の9月5日は土曜日で、処理は予定どおり休んでいただけでした。周辺の記録が報告の内容と整合していたため、人もAIも曜日の記載を疑いませんでした。対象の期間の日付を、カレンダーの計算で曜日ごとに数え直した段階で判明しました。
項目 | 内容 |
|---|---|
時期 | 2026年9月 |
モデル | Claude Opus 5 |
見つけた方法 | 全期間の日付の数え直し |
防ぐための指示
「日付に曜日を付けるときは、カレンダーの計算で曜日を確認してから書いてください。確認できない場合は、曜日を書かないでください。」
候補者に面談の日程を伝える場面で同じことが起きると、やり取りが増え、候補者に確認の手間をかけることになります。
事例5 別の担当者の名義での下書きの作成
社内の連絡ツールへの投稿で、作業した本人ではなく、ツールの連携に使われていた別の担当者の名前で下書きが作られました。名義になっていた担当者が自分の下書きに気づいて対処したため、実害はありませんでした。
項目 | 内容 |
|---|---|
時期 | 2026年8月 |
モデル | Claude Opus 5 |
見つけた方法 | 名義に使われた担当者本人の確認 |
防ぐための指示
「投稿や下書きを作成する前に、使用するアカウントが作業者本人のものかを確認してください。異なる場合は作成せず、報告してください。」
指示だけでは防ぎきれないため、AIが使うアカウントを、ツールをつなぐ時点で分けておきます。候補者へのメールの下書きをAIに作らせる場合も、送り主のアカウントを取り違えると、候補者には面識のない担当者から連絡が届いたように見えます。
4. 導入の段階で避けること
次の5つは、結果の原因を切り分けられなくなるか、誤りが外へ出るおそれがあるため、導入の段階では避けます。
避けること | 起きること |
|---|---|
起こりうる課題を列挙・検証しないまま、送信、採否の判断、面接の評価をAIに任せる | 判断の根拠を誰も説明できなくなります。任せる前に確かめることは第6部6章で扱います |
管理シートを作らず、AIとの会話だけで進める | AIの答えが残らず、良くなったかどうかを比べられません |
AIの答えを確認せずに外へ出す | 誤りが、候補者や社内の関係者にそのまま届きます |
停止する条件を決めずに自動の処理を動かす | 失敗を繰り返したまま、時間と費用だけがかかります |
ルールを、運用する採用担当が触れない場所に置く | ルールが更新されなくなり、実際の運用とずれていきます |
5. 導入の費用と回収までの期間
利用料は、月額の定額制なら使う量で変わりませんが、使った量に応じて払う方式では、1回ごとに渡す情報の量によって金額が大きく変動します。ルールや資料を分けて置き、その作業に必要な部分だけを渡すと、利用料を抑えることができます。件数の集計、重複の除外、文字数の確認、条件での絞り込みのように答えが1つに決まる計算は、関数で処理すれば利用料はかかりません。AIに渡すのは、文章の読み取りや判断が必要な作業に絞ります。
人の時間は、最初にかかる時間と、毎月かかる時間に分けて記録します。
項目 | 導入前 | 導入後 |
|---|---|---|
最初にかかる時間 | なし | 管理シートとルールづくり、全件確認の時間 |
毎月の作業時間 | 作業そのものにかかる時間 | AIの実行、確認と修正、ルールの見直しにかかる時間の合計 |
利用料 | なし | 月額、または使った量に応じた金額 |
導入前と導入後の毎月の作業時間の差が、毎月生まれる余力になります。この余力と利用料を並べ、最初にかかった時間を何か月で回収できるかを確認します。
図3 仮の数字で見る導入の費用と回収までの期間

最初にかかる時間が20時間、確認と修正を含めて毎月10時間の作業が減り、利用料が月1万円、社内の時間単価が5,000円という仮定で計算しています。
担当する時間を確保できない場合は、設計や運用を外部に任せる選択もあります。その場合も、採用要件と最終判断は自社に残ります。
この章のまとめ
費用は、AIの利用料に、ルールづくりと確認・修正にかかる人の時間を加えて判断します。件数の集計や文字数の確認のように答えが1つに決まる計算は、AIに渡さず関数で処理します。
6. 担当者を増やすときの引き継ぎ
特定の担当者しか運用を把握していない状態は、ルールを文章にしてタブに残すことで解消します。
1人が作った仕組みをほかのメンバーも使えるかどうかは、ルールが文章になっているかどうかで決まります。AIとの会話の中でその都度指示を出して運用していた場合、その担当者がいなくなると、判断の基準が何も残りません。ルールがタブに書かれていれば、新しい担当者はそれを読むところから始めることができます。
担当者を増やすときは、新しい担当者にも第3週の作業を一度行ってもらってください。AIの答えと自分の判断の食い違いを読む経験がないと、ルールをどこまで信用してよいかを判断できないためです。
7. AIを入れたあとに人が担うこと
3章の5件の事例は、どれもAIの出力を別の手段と照らした段階で判明しました。ポジションと本文の取り違えは別のAIによる点検で、要約に基づく報告の誤りは文字起こしの原文で、人数の集計の誤りはプログラムの計算で、曜日の誤りは日付の数え直しで、別の担当者の名義での下書きは名義に使われた担当者本人の確認で見つかっています。ポジションと本文の取り違えでは人が字数と言い回しを中心に読んでおり、曜日の事例では人もAIも記載を疑いませんでした。どちらも、人が読むだけでは見つからない誤りです。AIを入れたあとに人が担う仕事の1つは、AIの出力を何と照らすかを、作業を始める前に決めておくことです。
誰を採用するのか、なぜ今その人が必要なのか、その人に何を任せるのかは、これからも人が決定します。AIで空いた時間を、この3つを決めるための採用要件のヒアリングと検索条件づくりに使う理由は、第2部4章で説明しています。
図4 AIで変わることと人が決定すること

図4の左側は、ここまでの章で扱ってきた変化です。右側の3つは、AIを入れるほど言葉にして書き出す必要が高まります。判断のルールを文章にする手順は2章の第2週で、募集の背景と任せる仕事を採用要件として現場から聞き出す手順は第3部3-2で扱いました。
このシリーズでは、HRdevが採用支援の実務で培った知見をもとに、AIの使い方の例を紹介しました。自社の作業や体制に合わせて、取り入れられるところから試してください。参考になれば嬉しいです。お困りの方は、ぜひお問い合わせからお気軽にご連絡ください。
シリーズ「採用業務のAI活用」の構成
永井涼平
HRdev代表
レバレジーズ、クラウドワークス等を経て2021年にHRdev創業。18年以上エンジニア採用の最前線に立ち、ログラス・MFS・SALESCORE等の支援実績を持つ。
