はじめに
書類選考、消耗していませんか？
「この人、スキルは合ってるけど実績が薄い気がする」
「さっきと同じ基準で判断できているか自信がない」
「30枚読み終わる頃には最初の候補者の印象が薄れている」
「採用基準を聞かれても、うまく言語化できない」
エンジニア採用の書類選考は、判断基準がブレやすく、属人化しやすい業務です。特にEMが採用も兼任している場合、1日に何十枚もの職務経歴書を読みながら、同時に開発チームのマネジメントもこなさなければなりません。
この記事では、Claude Code（AI）を使って書類選考を構造化・効率化する方法を完全ガイドとして紹介します。
AIに最終判断を任せるのではなく、「採用哲学の言語化」「一次仕分け」「候補者サマリー生成」をAIに任せることで、本来EMが集中すべき「判断」の質を上げることが目的です。
なぜ書類選考はブレるのか
まず問題の構造を整理します。書類選考がブレる原因は主に3つです。
① 評価基準が頭の中にしかない
「なんとなくこういう人がほしい」という感覚はあっても、言語化されていない。結果として、評価者によって判断が変わる。
② 読む順番・疲労による揺れ
最初の10枚と最後の10枚では、同じ職務経歴書でも印象が変わる。人間の集中力は有限です。
③ 全体を俯瞰できない
1枚1枚を読んでいくと、候補者全体のレベル感を比較しにくい。「さっきの人と比べてどうか」が判断しにくい。
Claude Codeを使うことで、これらの課題に対してアプローチできます。
全体像：何をAIに任せて、何を人間がやるか
最初に全体の役割分担を明確にしておきます。
| やること | 誰がやるか |
|---|---|
| 採用要件・評価軸の定義 | 人間（EMと採用担当） |
| 評価ルーブリックの言語化 | Claude Codeとの対話で作る |
| 職務経歴書の読み込み・構造化 | Claude Code |
| A/B/Cの初期分類 | Claude Code |
| 候補者サマリーの生成 | Claude Code |
| B（迷い候補者）の最終判断 | 人間（EM・採用担当） |
| 面接可否の決定 | 人間（EM・採用担当） |
AIは「整理・仕分け・サマリー生成」を担当し、人間は「判断」に集中します。
ステップ①：採用哲学をClaude Codeと言語化する
最初にやるべきことは、評価基準を頭の中から取り出すことです。
これをClaude Codeとの対話でやるのがポイントです。
自分で書こうとすると「なんとなく書けない」「言語化しにくい」と詰まりがちですが、AIに質問してもらうことで引き出されます。
Claude Codeへの依頼文（コピペで使えます）
ミドルエンジニア（3〜7年）の書類選考用の評価ルーブリックを
一緒に作りたいと思っています。
以下の進め方でお願いします：
1. 評価軸ごとに私に質問して、私の採用哲学を引き出す
2. 「重視するのはA・B・C・Dのどれですか？」という選択式で聞く
3. 全軸が終わったらルーブリックをMarkdownの表でまとめる
まず最初の軸「技術力・スキルマッチ」から始めてください。
この対話を通じて出てくるのは、単なる評価基準ではなく「あなたの採用哲学」です。
ステップ②：評価ルーブリックを完成させる
対話を経て、評価ルーブリックを完成させます。
以下は実際に作成したミドルエンジニア向けルーブリックの例です。
評価スコア定義
| 記号 | 意味 |
|---|---|
| ◎ | 明確に確認できる |
| ○ | ある程度読み取れる |
| △ | 薄い・不明確 |
| × | NGシグナルあり |
軸①「技術力・スキルマッチ」（配点：高）
| 評価ポイント | ◎ | ○ | △/× |
|---|---|---|---|
| スタック一致度 | 要件の主要技術が一致 | 隣接技術の経験あり | まったく重ならない |
| 幅広さ | バックエンド＋インフラ＋設計まで触れている | 1〜2領域に深い | 1技術のみ |
| 設計・アーキテクチャ経験 | 設計主導の記述あり | 設計に参加した記述あり | 実装のみ |
特例ルール
AI活用経験（GitHub Copilot・Claude等を業務で活用）が明記されている場合、スキルミスマッチを1段階緩和してOK。
理由：AIネイティブなエンジニアは、慣れていない技術スタックへのキャッチアップが速い傾向がある。
軸②「成果・実績の質」（配点：高）
| 評価ポイント | ◎ | ○ | × |
|---|---|---|---|
| 数値化 | 「○○%改善」「月△△万PV」など定量記述あり | 「大幅に改善」など定性表現 | 数値も手応えも書かれていない |
| 課題→施策→結果の構造 | 3つすべて明示 | 一部しか書かれていない | 「携わりました」止まり |
| チームへの影響 | チームの変化・行動変容が書かれている | 自分の成果のみ | 記述なし |
| 技術難易度・規模感 | 大規模または複雑な課題への言及あり | 平均的な規模感が読める | 判断できない |
| 自分自身の変化 | 「この経験で○○を学んだ」等の内省あり | なんとなく読み取れる | 変化への言及なし |
即NGシグナル
- 主語が「チーム」のみで自分の関与が不明
- 在籍期間の割に記述が1〜2項目
- スキルシートが技術用語の箇条書きのみ
軸③「成長・学習姿勢」
| 評価ポイント | ◎ | ○ | △ |
|---|---|---|---|
| 業務外の技術活動 | 副業・OSS・個人開発の記述あり | 過去にあった | 記述なし |
| 自己研鑽 | 資格取得・社外勉強会への参加あり | 取り組み中の記述あり | 記述なし |
| AI・新技術への言及 | 業務でAIツールを活用している | 関心がある・試している | 言及なし |
NGシグナル
自己PR・志望動機が薄い。「自分を語れない人は内省習慣が弱い」と読む。
軸④「自律性・推進力」
| 評価ポイント | ◎ | ○ | △ |
|---|---|---|---|
| 主語が「私が」 | 「私が提案し」「私が設計した」が明確 | 読み取れる場面がある | すべて「チームで」 |
| 改善・提案の記述 | 現状課題を見つけて自発的に動いたエピソードあり | 関与した記述あり | 受け身の記述のみ |
| リード・主導の記述 | PJリード・技術リードの経験が明記 | サブリード・支援役として記載 | 記述なし |
注意
この軸は書類では判断しにくい。△でも他軸が高ければ面接で深掘りする。
「自律性は書類より面接で見る軸」と割り切ってOK。
軸⑤「定着リスク」
| シグナル | 対応 |
|---|---|
| 2年以内の離職が3社以上 | 面接必須。理由が納得できなければNG |
| 経歴のストーリーがバラバラ（業種・職種・言語に一貫性なし） | 面接で「この変遷の意図」を確認する |
| 志望動機が「貴社の○○に惹かれました」のみ | 能動性・解像度を面接で確認 |
定着リスクは原則「即NG」ではなく、他軸を評価した上で面接で深掘りする。
ステップ③：職務経歴書をClaude Codeに渡す
ルーブリックができたら、実際に書類選考をClaude Codeに任せます。
プロンプトテンプレート（コピペで使えます）
以下のルーブリックで、職務経歴書を評価してください。
【出力形式】
候補者シートとして以下の形式でまとめてください：
- 推薦度（A/B/C）と一言理由
- 経験サマリー（3行以内）
- 強み（ルーブリック対比）
- 気になる点
- AI・新技術への言及
- 面接で確認すべきこと
---
【ルーブリック】
（ここに完成したルーブリックを貼る）
---
【職務経歴書】
（ここに候補者の職務経歴書テキストを貼る）
ステップ④：候補者シートを受け取って判断する
Claude Codeはこのような「候補者シート」を出力します。
【候補者A】
推薦度：A（通過推薦）
■ 経験サマリー
- Java 5年・バックエンドメイン。直近はAPI設計〜実装を主導。
- チームのCI/CD整備を自発的に提案・導入した実績あり。
- 現職でGitHub Copilotを日常的に活用。
■ 強み（ルーブリック対比）
- 軸①：スタック一致◎、設計経験○
- 軸②：「レスポンスタイム40%改善」など数値記述◎、課題→施策→結果の構造◎
- 軸③：副業（個人開発）の記述あり、AIツール活用◎
- 軸④：「私が提案し」という主語の記述が3箇所◎
■ 気になる点
- 直近2社の在籍が1.5年・2年と短め → 面接で確認推奨
■ 面接で確認すべきこと
- 短期離職の背景（ネガティブな理由か・前向きな理由か）
- 設計経験の具体的な範囲と規模感
ステップ⑤：A/B/C判定で仕分ける
候補者シートをもとに、3段階で仕分けます。
| 判定 | 基準 | 対応 |
|---|---|---|
| A（通過推薦） | 軸①②が◎〜○ かつ 軸③④にプラスシグナルあり | サマリーを流し読みして承認 |
| B（迷い） | 1〜2軸が△だが他軸が高い／定着リスクあるが高ポテンシャル | 自分で職務経歴書を読んで最終判断 |
| C（不通過） | 軸①②に×あり かつ補完するプラスシグナルがない | スキップ（定期的に妥当性を確認） |
運用のコツは「Bだけ自分で読む」ことです。
30枚の書類があったとして、AとCはClaude Codeの判断を参考にするだけでOK。EMが職務経歴書を直接読むのはBの候補者だけに絞れます。
複数候補者を一括処理するプロンプト
候補者が複数いる場合は、まとめて依頼することもできます。
以下のルーブリックで、複数の候補者の職務経歴書を評価してください。
【出力形式】
1. 候補者ごとの候補者シート（前述の形式）
2. 最後に一覧表でA/B/Cをまとめる
【ルーブリック】
（ルーブリックを貼る）
【候補者1 - 田中さん】
（職務経歴書テキスト）
【候補者2 - 佐藤さん】
（職務経歴書テキスト）
（以下、同様に続ける）
チームへの展開：採用基準の共有ツールとして使う
このルーブリックは、個人の効率化だけでなく、採用チーム全体の基準を揃えるドキュメントとしても機能します。
活用シーン
- 新しい採用担当者へのオンボーディング資料として
- 面接官が複数いる場合の評価基準の統一
- 採用振り返りで「なぜこの人を通したか」を説明するエビデンス
- ポジションが変わるたびに軸を調整するベースドキュメント
ルーブリックを共有することで、「あの人はよかった」「あの人はなぜ落としたの？」という感覚的な議論が、構造的な議論に変わります。
よくある疑問
Q. 最終的な判断はAIがしていいの？
A. してはいけません。AIは「整理」と「仕分けの補助」だけです。合否の決定は必ず人間が行ってください。AIの判断は参考情報であり、責任の所在を明確にするためにも最終判断者は人間である必要があります。
Q. 個人情報が心配
A. 職務経歴書には氏名・住所・連絡先などの個人情報が含まれます。社内のセキュリティポリシーを確認し、会社が契約しているAIサービスを使ってください。個人情報を取り除いた形で渡す（匿名化）のも有効です。
Q. AIの評価精度はどのくらい？
A. ルーブリックの質に依存します。評価軸が曖昧だとAIの判断もブレます。逆に言えば、評価軸を明確にすればするほど精度は上がります。最初は「Cと判断されたが実は合っていた」ケースを人間がチェックしてキャリブレーションしていくのがおすすめです。
Q. 毎回ルーブリックを貼るのが面倒
A. Claude Codeを使っていれば、プロジェクト内にルーブリックファイルを置いておくだけでOKです。「このルーブリックで評価して」と言えばファイルを読み込んでくれます。
注意点まとめ
- 最終判断は必ず人間が行う（AIは補助）
- 個人情報の取り扱いに注意（社内のセキュリティポリシーを確認）
- ルーブリックは定期的に更新する（採用基準は変わる）
- C判定の妥当性を定期的に人間が確認する（見落としの防止）
- チームで使うなら、ルーブリックの認識合わせを先に行う
まとめ
| ステップ | やること |
|---|---|
| ①採用哲学の言語化 | Claude Codeと対話してルーブリックを作る |
| ②ルーブリックの完成 | 5軸で評価基準を明文化する |
| ③書類の読み込み | 職務経歴書テキストをClaude Codeに渡す |
| ④候補者シートの受け取り | AIが生成したサマリーを確認する |
| ⑤A/B/C判定で仕分け | Bだけ自分で直接読んで判断する |
書類選考の目的は「良い人材を見落とさないこと」です。
AIに任せるのは「判断」ではなく「整理」。
その整理をうまく使うことで、EMや採用担当は本当に大事な「判断」に集中できます。
最初は「ルーブリックを作る」だけでも十分です。
採用基準が言語化されるだけで、チームの採用の質は大きく変わります。
おまけ：今すぐ使えるルーブリックテンプレート
# エンジニア書類選考ルーブリック（ミドル・3〜7年）
## 評価スコア：◎明確 / ○おおむね / △薄い / ×NGあり
## 軸①技術力・スキルマッチ
- スタック一致度：
- 幅広さ（設計・インフラ含む）：
- 設計・アーキテクチャ経験：
- AI活用経験（加点）：
## 軸②成果・実績の質
- 数値化されているか：
- 課題→施策→結果の構造：
- チームへの影響：
- 自分自身の変化・学び：
## 軸③成長・学習姿勢
- 業務外の技術活動：
- 自己研鑽（資格・勉強会）：
- AI・新技術への言及：
## 軸④自律性・推進力
- 主語が「私が」か：
- 改善・提案のエピソード：
- リード・主導の記述：
## 軸⑤定着リスク
- 短期離職のパターン：
- 経歴のストーリー一貫性：
- 志望動機の解像度：
## 総合判定
判定：A / B / C
理由：
面接で確認すること：
このテンプレートをClaude Codeに渡すか、採用チームに共有して、今日から使ってみてください。