書類選考をAIで自動化する｜募集要件との突き合わせと、合否を人が決めるための線引き

書類選考で時間を取られている2つの作業

応募書類の確認が追いつかないという相談は、たいてい「読む量が多い」という形で出てきます。実際に時間を取られている作業を分けると、2つあります。

1つは、書式が揃っていない書類から必要な情報を拾う作業です。職務経歴書は決まった形式がありません。時系列で並べる人、担当した案件ごとに並べる人、担当業務を箇条書きだけで書く人が混ざります。同じ「在籍期間」を読み取るだけでも、書かれている場所が毎回違います。

もう1つは、応募者どうしを比べられる形に揃える作業です。募集要件に照らしてどうかを判断するには、応募者ごとにばらばらの記述を、同じ軸の上に並べ直す必要があります。この作業は書類を読み終えてから始まるため、件数が増えるほど後ろにずれ込みます。

さらに、複数の担当者が分担していると、同じ書類でも判断が分かれます。基準が書かれていないまま各自の経験で見ているためで、応募者数が増えたから起きたことではありません。件数が増えて表面化しただけです。

自動化で減らせるのは、この2つの作業です。誰を通すかという判断そのものは減りません。ここを取り違えると、「AIが選考してくれる」という期待で始めて、出てきた結果を人事が全件読み直すことになります。

工程を分けて、どこまでを機械に渡すか決める

書類選考を工程に分解します。

応募の受付 … 応募書類のファイル、応募職種、応募経路、応募日を受け取る
読み取り … PDFやWordのファイルから文字とレイアウトを取り出す
構造化 … 学歴、職歴（会社名と在籍期間、担当した役割）、担当した業務、資格、言語などの項目に整理する
要件との突き合わせ … 募集要件を分解した評価軸ごとに、満たすか、判断できないかを判定し、根拠となる記述を書類から引用する
比較できる形への整理 … 応募者を評価軸の表に並べ、確認が必要な点を添える
人事の判断 … 通すか見送るかを決める。面接で確認する点を決める
記録 … 何を材料にどう判断したかを残す

機械に渡すのは2から5です。6は人が持ちます。7は仕組みで支えます。

読み取りから比較表の生成までを機械に渡し、通すか見送るかの判断は人事が持ちます。判断できない項目は隠さず人へ回します。

工程を分ける利点は、うまくいかないときの直し先が決まることです。職歴の抜けが多いなら2か3、要件を満たすのに落ちているなら4、担当者が結局全文を読み直しているなら5、という切り分けができます。全体を1つのプロンプトで通す作りにすると、この切り分けができません。

履歴書と職務経歴書をどう読み取るか

応募書類のファイルは、大きく2種類に分かれます。

文字情報を持つPDFやWordのファイル。 応募者が作成ソフトから書き出したもので、文字はそのまま取り出せます。問題になるのはレイアウトです。履歴書は表形式が多く、セルの区切りを無視して読むと、年月と学校名や会社名の対応が崩れます。取り出す段階で、表の行と列の関係を保持する必要があります。

紙をスキャンした画像のPDF。 指定の様式に手書きで記入したものや、印刷して押印したものが該当します。文字認識を通す必要があり、手書きの場合は誤りが増えます。

読み取り方式の選び方は AI-OCRと生成AIの違いで扱っています。書類選考で押さえる点を挙げると、次の3点です。

在籍期間の表記を正規化する。 「2019年4月〜2023年3月」「2019/04-2023/03」「平成31年4月より」が混在します。和暦、年のみの記載、「現在に至る」といった表現を、比較できる形へ変換します。ここを揃えないと、経験年数の合計が出せません。

同じ会社の中の異動を、別の職歴と数えない。 出向や社内異動を会社の移籍として扱うと、在籍期間が短く見えます。会社名と期間の連続性で判定します。

取り出さない項目を先に決める。 応募書類には、選考の判断に使わない情報も書かれています。写真、生年月日、家族に関する記載、本籍地などです。読み取りの段階で対象から外すか、構造化したあとで判定に渡さないかを決めておきます。何を渡さないかは、社内で明文化してから実装します。

募集要件を評価軸に分解する

突き合わせの質は、モデルの性能より要件の書き方で決まります。求人票の文章をそのまま渡して「合いそうか見て」と指示すると、出てくる判定が毎回変わり、なぜその判定になったのかも説明できません。

要件は3層に分けて書き下ろします。

層	中身の例	機械側の扱い
応募資格（満たさなければ選考が成立しない条件）	業務に必須の資格の保有、就労可能な状態か、勤務地の条件	満たす／満たさない／記載なしの3値で判定する
必須要件（募集職種の遂行に必要な経験）	該当する業務の経験年数、担当した業務の範囲、扱った規模	3値で判定し、根拠となる記述を必ず引用する
歓迎要件（あると望ましい条件）	隣接する領域の経験、特定のツールや手法の使用経験、語学	該当の有無を記録するだけにとどめ、点数化しない

応募資格は事実の確認に近い層です。 資格の名称が書かれているか、勤務地の条件に合うかを見ます。判定がずれにくいため、機械側の出力をそのまま材料として使えます。

必須要件は判定できる粒度まで下ろします。 「関連業務の経験がある方」では判定できません。「対象の業務に携わった期間が通算3年以上か」「その業務の主担当だったか」「複数拠点にまたがる案件を扱ったか」のように、1つの軸で1つの判定にします。粒度を下げるほど、判定が安定し、根拠の引用も具体的になります。

歓迎要件は該当の有無だけを記録します。 重み付けをして合計点を出すと、その点数が独り歩きします。歓迎要件は本来「あれば面接で聞く」ための情報なので、面接で確認する点の候補として持つ形にします。

3層に分けたら、判断できない場合の扱いも決めます。書類に記載がないことは、要件を満たさないこととは違います。この2つを同じ「×」にまとめると、書き方が不慣れなだけの応募者が要件不足として扱われます。「記載なし」を独立した値として残し、面接や追加の確認で埋める対象にします。

要件を書き下ろす作業は人事と現場が行います。ここを外部に丸投げすると、判定の基準が社内に残りません。要件は募集のたびに更新するものなので、更新できる人が社内にいることが前提になります。

複数の応募者を比べられる形に整える

評価軸ごとの判定が出たら、応募者を横に並べます。ここで作るのは、合否の一覧ではなく確認のための表です。

含める項目は次のようになります。

評価軸ごとの判定（満たす／満たさない／記載なし）
各判定の根拠となる、書類からの引用（要約ではなく原文）
引用元の位置（ファイル名とページ、可能なら該当箇所）
判定に自信が持てない項目の印
面接で確認する点の候補

総合点で並べ替えないようにします。 軸ごとの判定を合計して順位を出すと、確認の作業が「上位から順に見る」に変わります。そうなると下位に置かれた応募者の書類は開かれません。並べ替えるなら、応募日や職種のように選考の内容に踏み込まない順にします。

判定の根拠は原文の引用で持ちます。 「マネジメント経験あり」という要約だけでは、その判定が妥当かを確かめられません。「メンバー5名のチームで進行管理を担当」という記述が引用されていれば、人事はその1行を見て判定の当否を決められます。確認の速度は、根拠が原文で添えられているかどうかで変わります。

自信が持てない項目を隠さないようにします。 書類の記述が曖昧で判定できない場合、無理に判定を出すより、判断できないと出したほうが使えます。この印が付いた項目だけを先に見る運用にすると、人事の確認の順序が決まります。

読み取った内容を既存の管理表や業務システムへ流し込む形の設計は商談メモの入力をAIで自動化するでも扱っています。書類選考の場合は、採用管理システムに項目として書き戻すか、選考用の一覧として別に持つかを、既存の運用に合わせて決めます。

合否をAIに決めさせない線引き

採用は、結果が応募者の不利益になりうる領域です。契約書のレビューや請求書の処理と違い、誤った判定を後から取り消しても、応募者にとっては選考を1回失ったことになります。この性質から、線引きは他の業務より手前に置きます。

工程	機械側で確定してよいか	理由
書類から文字と項目を取り出す	確定してよい（人が原本を参照できる形で）	正解が書類の中にある
在籍期間や経験年数の計算	確定してよい	計算の規則を先に決められる
応募資格の充足（資格の記載の有無など）	確定してよい（材料として提示する）	記載の有無で確認できる
必須要件の充足の判定	材料として出す。合否には直結させない	記述の解釈が入るため
歓迎要件の評価	該当の有無のみ。点数にしない	重み付けは募集ごとに変わる
応募者の順位付け	行わない	順位が確認の順序を決めてしまう
通すか見送るかの決定	行わない	応募者に不利益が生じうる判断
見送りの連絡を出す	行わない（人の承認を経る）	誤りが取り返しにくい

表の下2行が、この記事で最も動かしにくい部分です。機械側の出力だけで見送りを確定させる経路を作らない。 全件を人が見る運用が重いなら、確認の順序や表示の仕方を変えて対処します。自動で落とす閾値を置くのとは別の解き方です。

判定に使わない情報の扱いも、ここに含めます。選考の判断材料にしない属性の情報を機械側に渡していると、直接使っていなくても、記述の解釈に影響していないと説明できません。渡さない項目を決め、その通りに実装されているかを確認できるようにしておきます。

もう1つ、運用の決めごとがあります。機械側が指摘しなかったことを、問題がない根拠にしない。 突き合わせは網羅性を保証しません。面接前に確認する項目は、機械側の出力とは別に持ちます。

なお、採用選考で取得した情報の扱いや、公正な選考の考え方については、行政が示している指針があります。仕組みを作る前に、自社の人事と法務で確認してから設計に落としてください。この記事で扱っている線引きは、その確認を置き換えるものではありません。

評価根拠を記録し、人事が確認する工程を残す

書類選考の記録は、後から説明を求められる場面があります。応募者からの問い合わせ、社内での振り返り、選考基準の見直しのいずれでも、何を材料にどう判断したかが残っていないと答えられません。

応募者1件につき残す項目は次のようになります。

応募の識別子と、応募した職種、募集要件の版
適用した評価軸の識別子と、その版
軸ごとの判定と、根拠として引用した記述
読み取りに使った書類のファイルと、実行した日時、使用したモデル
人事担当者の判断（通す／見送る／保留）と、その理由
面接へ進んだ場合、書類段階で挙がった確認事項がどう扱われたか

募集要件と評価軸に版を持たせます。 要件は募集ごとに変わり、途中でも変わります。版を上げずに書き換えると、この応募者をどの基準で見たのかが分からなくなります。版が残っていれば、「この応募は当時のこの基準で確認した」と示せます。

人の判断を機械の出力に上書きしません。 人事の判断は別のレコードとして重ねます。上書きすると、機械が何を材料として出し、人が何を決めたのかの区別がつきません。この区別が付かない記録は、説明を求められたときに使えません。

保存期間と閲覧できる範囲を先に決めます。 応募書類とその読み取り結果は個人情報です。どこに置き、誰が見られ、いつ消すかを決めてから作ります。実装のあとに決めようとすると、データが複数の場所に散らばった状態から整理することになります。

記録は説明のためだけのものではありません。人事が毎回判定を覆している評価軸は、書き方が実務に合っていないということです。人事が毎回手で補っている観点は、評価軸が足りないということです。判断の履歴を見れば、次の募集で要件をどう書き直すかが決まります。導入後に何がどう変わったかの測り方は AI導入の効果測定と投資判断で整理しています。

着手前に決めておく社内ルール

実装より先に決めておく項目があります。決めずに作り始めると、動くものができてから運用に載せられないことが分かります。

判定に渡さない情報。 選考の判断に使わない項目を列挙し、機械側へ渡さない構成にする
応募書類の保存場所と保存期間、閲覧できる人の範囲
外部のサービスへ応募書類を送る場合の可否。 社内の情報の取り扱い規程と照らして判断する。生成AIを業務で使う際の社内ルールの作り方は生成AIの社内利用ルールをどう作るかで扱っている
応募者へ説明を求められた場合に、誰が何を答えるか
募集要件と評価軸を更新する担当者。 決まっていないと、要件が古くなった時点で使われなくなる
機械側の出力と人の判断が食い違ったときの扱い。 記録に残し、評価軸の見直しに使う

最初に切り出す範囲

全職種を一度に対象にすると、要件の書き下ろしが終わりません。範囲を絞ります。

応募が多く、要件が安定している職種を1つ選びます。 募集のたびに要件が変わる職種は後回しにします。

過去に選考を終えた応募書類で走らせて比べます。 人事が実際に下した判断という比較対象があるため、評価軸の不足と、過剰に厳しい判定が同時に見えます。ここで軸を直してから、実際の応募に使います。過去の書類を検証に使うことについても、社内の取り扱い規程を確認します。

最初は読み取りと構造化までに絞る選び方もあります。 突き合わせまで一度に作らず、書類から項目を取り出して一覧にするところまでを先に動かします。効果が出るかを早く確かめられ、要件の書き下ろしを並行して進められます。

人事の確認は全件残したまま始めます。 判定の採否と、人事が手で補った観点を記録します。任せる範囲を広げるかどうかは、この記録から決めます。ただし、通すか見送るかの決定は広げる対象に含めません。

検証から本番運用までの進め方と、見積の考え方は AIエージェント開発の進め方で整理しています。書類選考は、要件を書ける人が社内にいて、その要件を更新し続ける必要がある領域です。都度外部に依頼する形では更新が止まるため、自社で作って直し続ける進め方は生成AI・AIエージェントの内製化の進め方を参照してください。

まとめ：書類選考の自動化で決めておくこと

削れるのは書式の違う書類から情報を拾う作業と、応募者を比べられる形に揃える作業で、通すかどうかの判断は減らない
工程は受付、読み取り、構造化、要件との突き合わせ、比較できる形への整理、人の判断、記録に分ける。機械に渡すのは読み取りから整理まで
履歴書は表形式が多く、行と列の関係を保ったまま読み取る。在籍期間の表記は正規化し、社内異動を移籍と数えない
募集要件は応募資格、必須要件、歓迎要件の3層に分け、1軸1判定の粒度まで下ろす。歓迎要件は点数化しない
「記載なし」を「満たさない」と別の値として残し、面接や追加の確認で埋める対象にする
比較の表は合否の一覧ではなく確認のための表にする。総合点で並べ替えず、判定の根拠は原文の引用で添える
応募者の順位付け、通すか見送るかの決定、見送りの連絡は機械側で確定させない
記録は募集要件と評価軸の版を添えて残し、人の判断は機械の出力に上書きせず別のレコードとして重ねる
判定に渡さない情報、保存期間と閲覧の範囲、要件を更新する担当者は、実装より先に決める
最初は職種を1つに絞り、過去に選考を終えた書類で答え合わせをしてから実際の応募に使う

Augueでは、書類の読み取りから判定の根拠を残す部分まで、どこまでを機械に任せどこに人の承認を置くかの設計を含めて開発に対応しています。自社の書類選考のどの工程から手を付けられるか整理したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

書類選考の自動化は、どれくらいの期間で形になりますか？

一律の期間は出せません。左右するのは開発量より、募集要件を判定できる粒度まで書き下ろす作業と、過去の応募書類で答え合わせをする作業にどれだけ人事が時間を割けるかです。判断材料にするなら、1職種分の評価軸を書く工数と、過去の選考結果と突き合わせる回数を先に見積もってください。

応募者数が少ない場合でも作る意味はありますか？

件数だけで決めないほうがよいです。月に数十件でも、複数の担当者が別々の基準で見ていて結果がばらつくなら、評価軸を明文化する過程に意味があります。逆に件数が多くても、要件が毎回変わり比較の必要がないなら、投資に見合いません。着手するかは、担当者ごとの結果のばらつきと、1件あたりの確認にかかっている時間を先に測ってから判断してください。

採用管理システム（ATS）の選考支援機能とは何が違いますか？

既製の機能は自社の評価軸に合わせられる範囲が製品ごとに決まっています。自社の要件で判定させたい、根拠の記録を自社の形式で残したいという要求が強いほど自作寄りになります。既製で足りるかは、要件を書き出したうえで製品側の設定項目と突き合わせて決めます。

応募者に対して、AIを使っていることを伝える必要はありますか？

何をどう扱うかは自社の人事と法務で決める必要があります。設計としては、伝えられる状態にしておくことをおすすめします。どの情報を何に使い、誰が最終的に決めるのかを説明できない構成は、問い合わせを受けた時点で止まります。説明できる形は記録の作りで決まります。

過去の採用実績を学習させて、活躍しそうな人を予測させるのは有効ですか？

書類選考の自動化とは別の話として扱ってください。過去の採否や評価には、当時の判断の偏りがそのまま含まれます。それを目標値にすると偏りを再生産します。まず要件との突き合わせを安定させ、予測に踏み込むかは、何を正解とするかを人事と合意できてから判断します。