応募書類を募集要件と突き合わせて一次確認の所見を作る
応募者から届いた職務経歴書と履歴書を入力に、ポジションごとの募集要件の項目を1つずつ見て、その要件について書類のどこに何と書かれているかを原文の引用付きで並べた一覧を作ります。採用担当の作業は、数ページの職務経歴書を最初から読んで要件を思い出しながら照合することから、要件ごとに並んだ引用を見て原本で裏を取ることに変わります。
- 利用ツール
- AWS Textract/Azure AI/ChatGPT/Claude/Gemini/Google Apps Script/Google Document AI/Make/n8n/Power Automate
- 対象業界
- IT・SaaS/その他/人材/医療/教育
- 対象部門
- 人事/採用
- 対象業務
- 内容確認・チェック/書類作成
- 主な課題
- 人手が足りない/属人化している/確認ミスが多い
- AIで行う処理
- 抽出
- 主な効果
- 品質標準化/対応スピード向上/属人化解消/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 求人媒体の管理画面、人材紹介会社からのメール、自社サイトのフォームに応募が入る
- 履歴書と職務経歴書(PDFまたはWord)をダウンロードし、ATSの応募者レコードに添付する
- 採用担当がそのポジションの募集要件シートを開く
- 職務経歴書を最初から読み、経験年数、担当領域、使用技術、マネジメント経験、希望条件を拾う
- 要件シートの項目と照合し、満たしている点、足りない点、面接で確かめたい点を所見としてATSのコメント欄に書く
- 現場の面接官へ回し、通過か見送りかを決める
- 見送りの場合は定型文で連絡する
- 応募書類がメール添付または媒体からのダウンロードで所定のフォルダに入る
- 自動書類の種別(履歴書/職務経歴書/ポートフォリオ)を判定し、職務経歴書を本体として扱う
- 自動応募ポジションの要件シートを読み込み、要件項目の一覧を作る
- 自動要件項目ごとに、書類の該当箇所を原文のまま引用して抜き出す
- 自動項目ごとに「記載あり/記載なし/判断できない」を付ける
- 自動選考に用いない情報(本籍地、家族、生活環境、信条など)は所見に転記せず伏せる
- 人採用担当が引用と原本を照らし、通過・見送り・保留を判断して所見を確定する
- 自動確定した所見と判断をATSへ書き戻す
各工程の詳しい説明を読む
- 求人媒体の管理画面、人材紹介会社からのメール、自社サイトのフォームに応募が入る
- 履歴書と職務経歴書(PDFまたはWord)をダウンロードし、ATSの応募者レコードに添付する
- 採用担当がそのポジションの募集要件シートを開く
- 職務経歴書を最初から読み、経験年数、担当領域、使用技術、マネジメント経験、希望条件を拾う
- 要件シートの項目と照合し、満たしている点、足りない点、面接で確かめたい点を所見としてATSのコメント欄に書く
- 現場の面接官へ回し、通過か見送りかを決める
- 見送りの場合は定型文で連絡する
問題は4つあります。
(a)書類の形がそろっていない。 求人媒体が自動生成した定型フォーマット、応募者が自分で作ったWord、PDFに書き出したもの、職務経歴書を画像でスキャンしたものが混ざります。10ページの大作もあれば、1ページに箇条書きだけのものもあります。
(b)読む深さが担当者で変わる。 経験の長い担当者は「この書き方なら実務はここまで」と読み取れますが、配属して間もない担当者は書かれた肩書をそのまま受け取ります。同じ応募者が、担当者によって通過したり見送られたりします。
(c)10ポジションの要件を覚えきれない。 並行して募集していると、要件シートを開き直しながらの作業になります。細かい必須要件を見落として、後工程の面接官から差し戻されることが起きます。
(d)応募が週明けに集中する。 金曜から日曜に応募が積み上がり、月曜に150件届くことがあります。書類選考が滞ると、応募者は他社の選考を先に進めます。滞留は辞退に直結します。
- 応募書類がメール添付または媒体からのダウンロードで所定のフォルダに入る
- 【自動】 書類の種別(履歴書/職務経歴書/ポートフォリオ)を判定し、職務経歴書を本体として扱う
- 【自動】 応募ポジションの要件シートを読み込み、要件項目の一覧を作る
- 【自動】 要件項目ごとに、書類の該当箇所を原文のまま引用して抜き出す
- 【自動】 項目ごとに「記載あり/記載なし/判断できない」を付ける
- 【自動】 選考に用いない情報(本籍地、家族、生活環境、信条など)は所見に転記せず伏せる
- 【人】 採用担当が引用と原本を照らし、通過・見送り・保留を判断して所見を確定する
- 【自動】 確定した所見と判断をATSへ書き戻す
自動化されるのは「探す」「拾う」「並べる」の3つです。これは通す価値があるかを決める工程は残します。
02今回想定するシステム構成
求人媒体 / 人材紹介のメール / 自社サイトのフォーム │ ▼【トリガー】新しいメールが届いたとき(添付あり・指定アドレス) Power Automate │ ├──▶ 添付ファイルを SharePoint の応募フォルダへ保存 │ ├──▶ 画像PDF・スキャン原稿のとき │ └─ Azure AI Document Intelligence(prebuilt-read)でテキスト化 │ ├──▶ 要件シート(ポジション別・SharePointリスト)を取得 │ └──▶ Claude API ── 要件項目ごとに引用を抜き出す(合否は出させない) │ ▼ 所見シート(要件 / 引用 / 記載あり・なし・判断できない) │ ▼【人が判断】採用担当が原本と引用を見比べて決める │ ▼ ATS へ所見と判断を書き戻す
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Claude API | OpenAI API、Gemini API |
| ワークフロー | Power Automate | Make、n8n、Google Apps Script |
| OCR | Azure AI Document Intelligence(prebuilt-read) | Google Document AI、AWS Textract |
| 保管 | SharePoint | Box、Google Drive |
| 採用管理 | 既存のATS | 各社の採用管理システム |
ATSに同種の機能が付いていないかを先に確認してください。 採用管理システムの多くは要約や候補者の整理機能を持ち始めています。すでに契約している製品で足りるなら、自前で組む必要はありません。自前で組む価値があるのは、要件シートの粒度が自社独自で、既製の評価軸に合わない場合です。
03どうやって実装するのか
処理の起点を決める
専用の受信アドレスに応募書類のメールが届いたことを起点にします。Power Automate の Office 365 Outlook コネクタには「新しいメールが届いたとき(V3)」トリガーがあり、添付ファイルの有無や差出人で絞り込めます。
人材紹介会社からの推薦メールは、この専用アドレスへ送ってもらいます。求人媒体の管理画面からのダウンロードは自動化しにくいため、当面は担当者が所定のフォルダへ保存する運用にして、フォルダにファイルが作られたことを第2のトリガーにします。ここを無理に自動化しようとすると、媒体側の画面変更のたびに壊れます。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 職務経歴書 | 経歴、担当業務、使用技術、実績 | メール添付/フォルダ |
| 履歴書 | 学歴、職歴、資格 | メール添付/フォルダ |
| 募集要件シート | ポジション別の必須要件・歓迎要件・確認したい点 | SharePointリスト |
| 応募ポジション | どの求人への応募か | メール件名/媒体の付帯情報 |
| 過去の所見の書き方 | 良い所見の例を3〜5件 | ATSからの書き出し |
データの取得方法を決める
職務経歴書: PDFとWordが大半です。Claude API はPDFを直接受け取り、本文と図表の両方を読めます。リクエスト全体で32MBまで、ページ数は1リクエストあたり600ページまで(コンテキストウィンドウが1Mトークン未満の場合は100ページまで)と公開仕様に記載があります。職務経歴書は数ページなので、この上限に当たることはまずありません。
画像として貼られたPDFやスキャン原稿: Azure AI Document Intelligence の prebuilt-read モデルでテキスト化します。このモデルは活字と手書きの両方をPDF・スキャン画像から抽出し、Word・Excel・PowerPoint・HTMLからの抽出にも対応します。単語ごとに confidence が返るので、読み取りが怪しい箇所を後段で色分けできます。
募集要件シート: ポジションごとに、必須要件と歓迎要件を1行1項目で持ちます。ここが自動化の土台です。 「Javaの実務経験3年以上」のように、書類から確かめられる粒度まで分解しておきます。「主体性がある」のような項目は書類からは確かめられないため、要件シートに置いても照合の対象から外します。
AIへ渡す前に整形する
- 書類種別の判定 … 1通のメールに履歴書・職務経歴書・ポートフォリオが混在します。ファイル名と先頭ページの見出しから種別を判定し、職務経歴書を本体として扱います
- パスワード付きPDFの検出 … 人材紹介会社からの書類はパスワード保護されていることがあります。開けないファイルは処理を止めて担当者へ通知します。Document Intelligence もパスワードロックされたPDFは事前解除が必要と明記されています
- 画像PDFの判定 … テキストが抽出できないPDFはOCRへ回します。全ページの抽出文字数が極端に少ないものを画像PDFとみなします
- 重複応募の検出 … 同じ人が複数媒体から応募することがあります。氏名とメールアドレスで既存の応募者レコードを照合し、重複なら過去の選考履歴を添えて担当者へ知らせます
- 選考に用いない情報の除去 … 本籍地、家族構成、家族の職業、住宅状況、生い立ち、信条、支持政党といった記載が書類にあった場合、後段へ渡すテキストから除きます。ここを前処理で落とすのが、後で見ていないと言える唯一の形です
AIに処理させる
役割を分けます。
OCR(Document Intelligence)にさせること: 画像PDFとスキャン原稿の文字起こし。ここは生成AIにさせません。専用モデルのほうが安定し、費用も安く済みます。
生成AI(Claude API)にさせること:
| 処理 | 内容 |
|---|---|
| 要件ごとの引用抜き出し | 要件シートの各項目について、該当する記述を原文のまま引用する |
| 充足状態の記入 | 項目ごとに「記載あり/記載なし/判断できない」を付ける |
| 経験年数の集計 | 在籍期間の記載から、要件に関わる領域の年数を合算する |
| 確認したい点の列挙 | 書類だけでは判断できず、面接で聞くべき点を並べる |
| 経歴の空白期間の指摘 | 在籍期間に空きがある箇所を事実として指摘する(理由は推測しない) |
させないこと: 合否の判定、推奨度の点数付け、他の応募者との比較、人物評価。これらを出力させると、担当者はその数字に引きずられます。出力に無ければ引きずられようがありません。
指示内容を固定する
あなたは中途採用の書類選考を支援する担当者です。
応募書類と募集要件シートを読み、要件ごとに「書類のどこに何と書かれているか」を
整理してください。合否の判断はしません。
【厳守事項】
- 合否、推奨、点数、ランクを一切出力しないでください。
「有望」「見送りが妥当」などの評価語も使わないでください。
- 書類に書かれていないことを補わないでください。
書かれていなければ status を "記載なし" にしてください。
- 各要件には必ず evidence(原文の引用)を付けてください。
引用できない場合は status を "記載なし" または "判断できない" にしてください。
- 次の情報は抽出も言及もしないでください。
本籍地・出生地、家族の職業や続柄、住宅や生活環境、資産、
信条・宗教・支持政党、労働組合への加入、健康状態、
年齢・性別・国籍を理由とする記述。
- 経験年数は、在籍期間の記載から計算した根拠を併記してください。
計算できない場合は null にしてください。
- 経歴の空白期間は事実として期間だけを書き、理由を推測しないでください。
【募集要件シート】
{requirements}
【応募書類(職務経歴書・履歴書)】
{documents}
評価語も使わないという1行が要です。 合否を出すなと指示しても、「即戦力と思われます」のような一文が混じります。それが所見欄に残ると、担当者の判断より先に結論が置かれることになります。禁止する語まで書き下してください。
出力形式を固定する
{
"position_id": "",
"requirements": [
{
"requirement_id": "",
"requirement_text": "",
"kind": "必須 | 歓迎",
"status": "記載あり | 記載なし | 判断できない",
"evidence": [
{ "quote": "", "source": "職務経歴書 p.2" }
],
"computed_years": null
}
],
"career_gaps": [
{ "from": "", "to": "", "months": 0 }
],
"questions_for_interview": [],
"excluded_content_found": false,
"ocr_low_confidence": false,
"needs_review": []
}
evidence を配列にして、引用と出典ページを対で持たせます。引用が原本のどこから来たかを示せない出力は、確認の役に立ちません。 excluded_content_found は、選考に用いない情報が書類に書かれていた場合に立てるフラグです。これが立ったときは、担当者にその旨だけを知らせ、中身は渡しません。
構造化出力を使うと、この形を毎回そろえられます。Claude API では output_config.format に type: json_schema とスキーマを渡します。ただし minimum maxLength といった数値・文字列の制約や正規表現は指定できないため、年数の範囲や引用の長さの検査は、受け取った後に自前で行う必要があります。
システムへ連携する
確定した所見をATSへ書き戻します。連携方法は3通りです。
| 方式 | 内容 |
|---|---|
| API連携 | ATSがAPIを提供していれば、確定と同時に応募者レコードへ書き込む |
| ファイル取込 | 所定のCSV形式で書き出し、ATSの取込機能で読ませる |
| 手動貼り付け | 上記が使えない場合。所見シートから担当者がコピーする |
ATSのAPIは製品によって提供範囲が大きく違います。 応募者レコードの読み取りはできても書き込みができない製品があります。この部分は利用環境に応じた個別確認が必要です。 書き込みができない場合でも、所見シートが整っていれば貼り付けの手間は十数秒で済みます。ここを理由に導入を止める必要はありません。
人が確認する
全件、人が判断します。自動化の割合を上げる運用もしません。
理由は2つあります。1つは、書類選考の結果が応募者の職業機会に直接影響することです。もう1つは、要件シートに書ける項目だけで人を評価しきれないことです。職務経歴書の書き方が不器用でも実務ができる人はいます。それを拾うのは人の仕事です。
確認を速くするための設計が重要です。
- 所見シートで、要件・引用・原本のページ番号を1行に並べる
- 「記載なし」の必須要件を上に集める(見送りの判断が速くなる)
- OCRの
confidenceが低い箇所に印を付ける - 原本のPDFをすぐ開けるリンクを行ごとに置く
これらがないと、結局は最初から読み直すことになり、削減効果が出ません。
例外に対処する
| 起きること | 対応 |
|---|---|
| 職務経歴書が添付されていない | 履歴書だけで処理せず、担当者へ差し戻す |
| パスワード付きPDFで開けない | 処理を止めて通知する。自動でパスワードを試さない |
| 画像PDFで文字が読めない | OCRへ回し、それでも confidence が低ければ従来どおり人が読む |
| 職務経歴書が外国語 | 対象外として人へ回す。訳してから照合しない(訳で意味が変わる) |
| ポートフォリオがURLだけ | URLは所見に転記するのみ。自動で開いて評価しない |
| 同一人物の再応募 | 過去の選考履歴を添えて担当者へ知らせる |
| 要件シートが未整備のポジション | 照合せず、書類の要点整理だけを出す |
| 選考に用いない情報が書かれていた | フラグだけを立て、内容は後段へ渡さない |
| 応募が週明けに集中する | キューに入れて順次処理する。同時実行数を制限する |
| 引用が原文と一致しない | 後述の検査で弾く。引用の一致は機械で確かめられます |
引用の一致検査は、必ず入れてください。出力された quote が原文テキストに文字列として存在するかを照合し、存在しなければその項目を「判断できない」に落とします。生成AIが原文にない文を引用として出す事故は、これで止まります。
記録を残す
この業務では、保存するデータそのものが個人情報です。
- 応募書類の原本(ATSの保持ポリシーに従う)
- OCRの抽出結果と
confidence - 生成AIへ渡したテキスト(選考に用いない情報を除いた後のもの)
- 出力された要件ごとの引用と充足状態
- 担当者が修正した項目と、修正前後の値
- 確定した所見と判断、判断した担当者、日時
保持期間を決めて、期限が来たら消してください。求職者の個人情報は、募集や採用の目的を達成するために必要な範囲で扱うものとされています。いつか使うかもしれないという理由で残さないでください。
修正の記録は、精度の実測値になります。「経験年数の集計はほぼ直されないが、担当領域の引用は4割直されている」と分かれば、要件シートの書き方を改めるべきだと判断できます。
04実装レベルの3段階
半自動化の時点で、8分が4分程度になります。 読む工程が「引用を見る」に置き換わるためです。本格構成にすると3分程度になりますが、下がり幅は小さくなります。残る3分は、人が原本と引用を照らして判断する時間で、ここは削りません。
05工数削減シミュレーション
導入後 400件 × 3分 ÷ 60 = 20 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 中途採用の応募が月200件以上あり、募集ポジションが5つ以上並行している企業。ポジションごとの募集要件が文書になっていて、何を満たせば次に進めるかが言語化されていること。応募書類をPDFまたはWordで受け取れていること。最終的な合否を人が判断する体制があること。
- 応募が月30件以下で、採用担当が全件を丁寧に読めている場合。募集要件が「良い人がいれば」の状態で文書化されていない場合(照合する基準が無いと自動化の対象が無い)。AIに合否そのものを判定させたい場合。書類選考をせず全員と面接する方針の企業。
07最小構成で試す方法
- 直近の応募から職務経歴書を20件用意する(通過・見送りが混ざるように選ぶ)
- 1つのポジションの募集要件シートを、1行1項目に整える
- 生成AIの画面に、要件シートと職務経歴書を貼り、上記のプロンプトを与える
- 出力された引用が、原本に本当に書かれているかを1件ずつ目で確かめる
- 20件のうち、全要件の引用が正しかったのが何件かを数える
この検証は必ずやってください。 引用が原文と食い違う出力を見抜けないまま運用すると、書かれていない経験を根拠に通過させることになります。
判断の目安は次のとおりです。
| 引用が全て正しかった件数 | 判断 |
|---|---|
| 18件以上(9割以上) | 自動化する価値がある。引用一致検査を入れれば運用に乗る |
| 14〜17件 | 要件シートの粒度が粗い可能性が高い。項目を分解してから測り直す |
| 13件以下 | 書類の形式が荒すぎる。OCRの精度を先に確かめる |
要件シートを整える作業は、AIを使う前にやる価値があります。書類選考の基準が言語化されていないことが、属人化の本当の原因であることは珍しくありません。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 出力に評価語が混じる | 禁止語を明示する。出力後に評価語の有無を機械で検査して弾く |
| 引用が原文にない | quote を原文テキストへ文字列照合する。一致しなければ「判断できない」に落とす |
| 要件が抽象的で照合できない | 「主体性がある」等は照合の対象から外す。書類で確かめられる項目だけを扱う |
| 経験年数が水増しされる | 在籍期間の記載から計算させ、計算根拠を併記させる。自己申告の年数をそのまま使わない |
| 画像PDFで精度が落ちる | OCRへ回し、confidence が低いものは人が読む分岐を作る |
| 選考に用いない情報が出力に混じる | 前処理で除く。後段のフィルタだけに頼らない |
| 担当者がAIの整理を鵜呑みにする | 原本へのリンクを所見シートの各行に置く。引用だけで判断できない設計にする |
| ATSに書き戻せない | 貼り付け運用に切り替える。ここで導入を止めない |
| ポジションが増えるたびに要件シートが必要 | ひな形を用意し、求人票の作成と同時に整える運用にする |
| 応募者から選考方法を尋ねられる | 何をAIにさせ、何を人が決めたかを説明できる形にしておく |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 氏名、生年月日、連絡先、学歴、職歴、現職の勤務先と年収。応募者の個人情報そのものであり、書類によっては健康状態など取り扱いに配慮を要する情報が含まれます。
- 選考に用いない情報を入れない … 本籍地、家族、生活環境、信条、支持政党といった情報は、そもそも収集が認められないものとされています。書類に書かれていたとしても、後段へ渡さない設計にしてください。厚生労働省は、職業安定法第5条の5および指針(平成11年労働省告示第141号)により、社会的差別の原因となるおそれのある個人情報は原則として収集が認められないとしています
- 外部AIへの入力可否 … 応募書類を外部サービスへ送ることになります。自社の個人情報の取扱いに関する公表内容と整合するかを確認してください。応募者への利用目的の通知に、選考事務の補助として外部サービスを用いることを含めるかどうかを、法務と相談してください
- 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます。応募書類は再利用されて困る情報の典型です
- アクセス権限 … 所見シートと原本の保管場所を、採用担当と当該ポジションの面接官に限定します。全社員が見られる場所に置かないでください
- 自動実行してよい範囲 … 合否の判定、見送りの自動連絡、選考結果に触れる自動返信は、自動化しないでください。運用が安定してもここは変えません
- 保持期間 … 不採用者の書類をいつまで持つかを決め、期限で消します。次の募集での再検討を理由に残す場合は、その旨を応募者に伝えた範囲でのみ行ってください
誤りが起きた場合のリスクは、書かれていない経験を根拠にした通過、必須要件の見落としによる見送り、そして選考に用いてはならない情報が判断に混じることです。最後の1つは、工数の問題ではなく公正な採用選考の問題になります。判断した担当者と日時のログを必ず残し、後から説明できる状態にしてください。
10まず何から始めるか
1週目:要件シートを1ポジション分だけ整える
もっとも応募の多いポジションを1つ選び、必須要件と歓迎要件を1行1項目に分解します。書類から確かめられるかどうかだけを基準に取捨してください。 ここが整わないと、この先の工程は動きません。
2週目:引用の正しさを測る
そのポジションの直近20件で、生成AIの画面から引用を出させ、原本と一致するかを数えます。9割以上ならば進めます。届かない場合は、要件の粒度を疑ってください。
3〜4週目:半自動化を作る
メール監視から所見シートの出力までを作り、採用担当1名が2週間使います。8分が何分になるかを実測します。ATS連携はまだ作りません。
2か月目以降: 削減効果が確認できたら、引用一致検査とATSへの書き戻しを実装し、残りのポジションの要件シートを整えます。並行して、応募者への利用目的の通知が現状の運用と合っているかを、法務と人事責任者に確認してください。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Claude API がPDFを直接受け取り、本文・図・表を読めること。リクエスト全体で32MBまで、1リクエストあたり600ページまで(コンテキストウィンドウが1Mトークン未満の場合は100ページまで)。パスワードや暗号化のない標準PDFであること | Claude Docs: PDF support | 2026-09-11 |
構造化出力が output_config.format に type: json_schema とスキーマを指定する形であること。claude-opus-5 claude-sonnet-5 等が対応。minimum maxLength 等の数値・文字列の制約や正規表現は未対応 | Claude Docs: Structured outputs | 2026-09-11 |
Azure AI Document Intelligence の prebuilt-read が、PDF・スキャン画像から活字と手書きの両方を抽出し、Word・Excel・PowerPoint・HTMLにも対応すること。単語ごとに confidence を返すこと。パスワードロックされたPDFは事前に解除が必要なこと | Microsoft Learn: Read model | 2026-09-11 |
| Office 365 Outlook コネクタに「新しいメールが届いたとき(V3)」トリガーと「Draft an email message」アクションがあること | Microsoft Learn: Office 365 Outlook connector | 2026-09-11 |
| 採用選考は応募者の基本的人権を尊重し、適性・能力に基づいた基準で行うこと。職業安定法第5条の5および指針(平成11年労働省告示第141号)により、社会的差別の原因となるおそれのある個人情報は原則として収集が認められないこと | 厚生労働省:公正な採用選考の基本 | 2026-09-11 |
ATSへの書き戻し方式(API/CSV取込/手動)は製品によって異なります。この部分は利用環境に応じた個別確認が必要です。 応募者の個人情報の取扱いと利用目的の通知については、自社の運用が要件を満たすかを法務および人事責任者に確認してください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0033)についてのご相談はこちらから。
