最終確認日：2026年8月22日
実装パターン解説：以下は人事の書類選考業務でよくある構造をもとに一般化した実装パターンです。特定の企業の実績数値ではありません。自社の採用基準・労働関連法規に照らして適用してください。
人事の書類選考は、応募者ごとに職務経歴書・履歴書のフォーマットが異なり、必須要件・歓迎要件との突き合わせ、評価表への転記、面接官への引き継ぎメモ作成といった一連の整理作業が発生します。応募者数が多い求人ほど、この整理作業に多くの時間が割かれ、実際の評価に使う時間が圧迫されがちです。
Claude Codeは、合否判定そのものを代替するのではなく、応募書類のテキストデータを読み込み、必須要件との突き合わせ、経歴の要約、評価表フォーマットへの転記、面接準備メモの草案作成をコードとして実装する用途に向いています。合否判定・評価そのものの最終決定は採用担当者・面接官が行う前提です。
書類選考が採用担当者の負担になる理由
応募書類は職務経歴書のフォーマットが応募者ごとに異なり、経験年数や保有スキルの表記もばらつきます。また、求人ごとに必須要件・歓迎要件が異なるため、同じ応募者でも求人によって評価の観点が変わります。この「非構造化データを求人要件に合わせて再整理する」作業に時間がかかり、応募者数が多い時期には選考のボトルネックになりやすい領域です。
実装の前提とスコープ
| フェーズ | 対象 | Claude Codeの役割 | 人（採用担当者・面接官）が担う判断 |
|---|---|---|---|
| データ整形 | 職務経歴書・履歴書のテキストデータ | 経歴情報の構造化スクリプト | 抽出結果の正確性確認 |
| 要件突き合わせ | 必須要件・歓迎要件とのマッチング | キーワード・条件ベースの突き合わせ | マッチ度の解釈、例外判断 |
| 評価表転記 | 社内評価フォーマットへの転記 | 転記スクリプトの生成 | 評価点数そのものの決定 |
| 面接準備メモ | 経歴サマリと質問候補 | 要約・質問候補の草案生成 | 実際の質問内容の選定 |
Claude Codeへの指示例（プロンプト）
採用選考の実装では、公平性を担保する観点から評価基準を明確化して伝えることが重要です。以下は実装で使えるプロンプト例です。
1. 「以下は職務経歴書のテキストと、求人の必須要件・歓迎要件
リストです。経歴から関連する経験年数・スキルを抽出し、要件
との一致度を機械的に算出するスクリプトを書いてください。
氏名・年齢・性別などの属性はマッチング処理に含めないで
ください。」
2. 「抽出した経歴情報を、社内の評価表フォーマット（列定義を
渡します）に転記するスクリプトを書いてください。評価点数
そのものは出力せず、事実情報の転記にとどめてください。」
3. 「経歴の要約を200字程度で生成し、面接で深掘りすべきと
思われる質問候補を3つ提示してください。これは面接官が
参考にする草案であり、実際の質問選定は面接官が行う前提で
あることを明記してください。」
4. 「求人ごとの応募者数・書類通過率・面接設定率を集計する
レポート生成スクリプトを書いてください。個人が特定される
情報は含めないでください。」
5. 「このスクリプトの実装にあたり、必須要件の解釈や評価基準に
不明な点があれば、実装前に質問してください。仮定した点は
コメントに明記してください。」段階的導入のロードマップ
Phase 1（1〜2ヶ月）: 1求人分の応募データを対象に、要件突き合わせと評価表転記を読み取り専用で検証し、既存の採用担当者の判断と突き合わせます。
Phase 2（3〜4ヶ月）: 精度が安定した段階で複数求人に対象を広げ、面接準備メモの草案生成を追加します。合否判定は引き続き人が行います。
Phase 3（5〜8ヶ月）: 求人別の選考状況レポートの自動生成、採用管理システムとのデータ連携（読み取り専用）まで対象を広げます。
【要注意】よくある失敗パターンと回避策
失敗1：合否判定そのものをAIに任せてしまう
❌ 要件マッチ度のスコアだけで自動的に合否を決定する
⭕ マッチ度はあくまで一次情報とし、合否判定は採用担当者・面接官が行う
採用選考は経歴以外の要素（ポテンシャル、カルチャーフィットなど）も考慮する専門判断であり、AIが確定させてよい領域ではありません。
失敗2：属性情報をマッチング処理に含めてしまう
❌ 氏名・年齢・性別・出身校などをマッチングの判断材料に含める
⭕ 職務経験・スキル・資格など、職務関連性の高い情報だけを扱う
労働関連法規や公平な採用選考の観点から、属性情報を評価に用いることは避ける必要があります。
失敗3：応募者の個人情報をそのまま検証データに使う
❌ 実際の応募者の氏名・連絡先を含むデータで検証する
⭕ ダミーデータで動作確認してから本番データに適用する
応募書類には個人情報が多く含まれるため、検証段階では必ず匿名化します。
失敗4：面接準備メモの質問候補をそのまま使い、深掘りをしない
❌ AIが生成した質問候補をそのまま面接で使う
⭕ 候補を参考にしつつ、面接官が経歴の背景や志望動機を踏まえて質問を調整する
定型的な質問だけでは、応募者の実態を把握しきれない場合があります。
効果の考え方（試算モデル）
正直にお伝えすると、削減効果は応募者数、求人件数、既存の選考フローの整備状況によって変わるため、一律の削減率は提示できません。ここでは考え方の枠組みだけを示します。
例えば「1求人あたり月50件の応募があり、1件の書類確認・評価表転記に平均10分かかっている」という想定モデルを置くと、月あたりの作業は約8時間相当になります（あくまで試算のための仮の数値です）。要件突き合わせや転記のような機械的な部分をコード化できれば、採用担当者の作業は「評価の質を高めること」に振り向けられます。実際の削減時間は、Phase 1の並行運用期間に自社のデータで実測することを推奨します。
公平性と個人情報の扱い
採用選考では、性別・年齢・出身などによる不当な差別を避ける公平性の担保が重要です。マッチング処理に用いる情報は職務関連性の高いものに限定し、属性情報は評価に含めない設計にしてください。個人情報の取り扱いに関する最新の考え方は個人情報保護委員会の公式情報、情報セキュリティの実務対応はIPAの公式情報を参照することをおすすめします。労働関連法規に関する具体的な判断は、社会保険労務士や弁護士などの専門家に相談してください。
公式ソース
関連して読む記事
FAQ
Claude Codeに本番更新まで任せてよいですか？
初期段階では任せず、読み取り専用と人の承認を挟む設計にします。合否判定の最終決定は必ず採用担当者・面接官が行います。
個人情報を含むデータで検証できますか？
検証時は匿名化し、必要最小限のサンプルだけを使います。
最初に自動化するなら何が安全ですか？
経歴情報の構造化や評価表への転記など、読み取り中心の処理が安全です。合否判定は最後まで人が担います。
効果はどう測りますか？
書類確認・転記にかかる時間、選考のリードタイム、面接設定までの日数で測ります。一律の削減率を仮定せず、自社のデータで実測することが重要です。
公平な選考は担保できますか？
マッチング処理に用いる情報を職務関連性の高いものに限定し、属性情報を評価に含めない設計にすることで、一定の配慮は可能です。ただし最終的な公平性の担保は運用ルールと人の判断に依存します。
既存の採用管理システムを置き換える必要がありますか？
通常は置き換えず、既存システムからのエクスポートデータを読み込む周辺処理として組み込みます。
中途採用と新卒採用で使い方は変わりますか？
中途採用は職務経験のマッチングが中心になりやすく、新卒採用はポテンシャル評価の比重が高くなるため、評価基準の設計を分けて検討することをおすすめします。
