履歴書PDFをAIで採点するOSS「Hiring Agent」の仕組み

エンジニア採用の現場では、候補者の履歴書を数十枚〜数百枚規模で読み込み、技術スキル・OSS 活動・実務経験といった複数の観点で評価する作業が日常的に発生します。一方で、この作業は人手と主観に強く依存しており、評価基準のブレやスクリーニングの工数増加が課題になりやすい領域です。

近年は AI 採点ツールも複数登場していますが、商用 SaaS は予算面・データ持ち出し面で導入のハードルが高く、また「なぜそのスコアになったのか」が説明できない、いわゆるブラックボックス問題も指摘されてきました。社内で履歴書 PDF を AI に処理させたいというニーズはあっても、自前で構築するには評価ルーブリックの設計から GitHub プロフィールの解析、LLM の選定までやることが多すぎるのが実情です。

そうした中で 2026 年 6 月、HackerRank が履歴書評価エージェントを OSS として公開しました。それが本記事で取り上げる Hiring Agent（リポジトリ識別子: interviewstreet/hiring-agent）です。MIT ライセンスで公開されており、ローカル LLM（Ollama）でフルローカル実行できる点が、データ保護要件のある採用業務との相性で注目されています。

本記事では、Hiring Agent の概要・アーキテクチャ・評価ロジック・対応 LLM・類似 OSS との違い・自社採用業務への組み込み判断ポイントまでを、公式 README とリポジトリメタデータに基づいて整理します。「自社に採用すべきか」「類似 OSS とどう違うか」「メンテナンス状況は健全か」を判断するための材料として活用してください。

なお、本記事は実機での動作検証ではなく、公式ドキュメント（README）と GitHub リポジトリのメタデータに基づくドキュメントベースの解説です。

Hiring Agent とは

Hiring Agent は、HackerRank（GitHub の組織名は interviewstreet、HackerRank の旧社名でありそのまま GitHub Org 識別子として残っています）が公開した、履歴書 PDF を AI で解析・採点するためのオープンソースエージェントです。公式リポジトリは interviewstreet/hiring-agent で公開されています。

リポジトリの基本情報は以下のとおりです（数値は本記事執筆時点のリポジトリメタデータより）。

archived・fork ともに false であり、HackerRank（interviewstreet Org）が継続して公開・更新している現役のオリジナル OSS です。直近 push が 2026-06-22 と新しく、コードフリーズ状態ではない点も、初見で評価する際の安心材料になります。

解決しようとしている課題

Hiring Agent が想定する課題は、リリース時の公開情報および README の Overview から読み取ると、大きく次の 3 点に整理できます。

• 数百件単位の履歴書を読み込むスクリーニング工数（manual labor required to parse hundreds of resumes）
• スコアだけを返してくる商用 AI ツールにありがちな「コンテキストなしの採点」問題（proprietary AI tools that provide a score without context）
• 評価の不透明さと、評価軸を社内で説明できないことによる採用判断の主観バイアス

これらに対して Hiring Agent は、評価カテゴリごとのスコアと併せて根拠（evidence）・ボーナス・減点までを出力する「説明可能（explainable）な履歴書評価」を打ち出しています（参考: aitoolly の紹介記事）。

Hiring Agent のアーキテクチャ

Hiring Agent は、履歴書 PDF を入力に取り、最終的に評価レポートと CSV 行を出力するパイプラインで構成されています。公式の README の「Architecture」セクションに記載されたフローを 5 ステップに整理すると以下のとおりです。

パイプライン全体像

1. PDF → Markdown 変換: pymupdf_rag.py が PDF ページを Markdown 風テキストへ変換する
2. セクション単位の LLM 抽出: pdf.py が prompts/templates 配下の Jinja テンプレートを使い、履歴書のセクションごとに LLM を呼び出して構造化 JSON を取り出す
3. GitHub による補強: github.py が候補者の GitHub プロフィール・リポジトリを取得し、プロジェクトを分類した上で「最小コミット数の閾値を満たすトップ 7 件」を LLM に選定させる
4. 公平性制約付き評価: evaluator.py が公平性を担保したルーブリックに基づき厳格にスコアリングする
5. オーケストレーション: score.py がエンドツーエンドのパイプラインを実行し、DEVELOPMENT_MODE=True のときは中間 JSON のキャッシュと CSV エクスポートも行う

履歴書テキストだけでなく GitHub プロフィールが必須補強として組み込まれている点が、後述する類似 OSS との大きな違いです。エンジニア採用に最適化された評価フローと言えます。

主要モジュール

README の「Key modules」セクションで示されている主要モジュールは以下のとおりです（出典: https://github.com/interviewstreet/hiring-agent/blob/main/README.md）。

プロンプトは prompts/ 配下の Jinja テンプレートとして分離されているため、評価軸を自社向けにカスタマイズしたい場合でも、コア実装に手を入れずテンプレートだけ差し替える運用が想定できます。

評価ロジックと公平性の設計

Hiring Agent の評価ロジックの中核は、README の「How it works」セクションで示されているカテゴリ別スコアリングです。

4 つの評価カテゴリ

README の「Evaluation」セクションで定義されている評価カテゴリは以下の 4 つです。

• open_source: OSS への貢献
• self_projects: 自分でつくっている個人プロジェクト
• production: 本番運用された実務経験
• technical_skills: 技術スキル

これらに加え、ボーナス（bonus）・減点（deductions）・各スコアの根拠を示す説明（evidence）を出力する設計になっています。スコアだけを単独で返すのではなく、「なぜそのスコアになったか」の根拠を必ず添えるという方針が、Hiring Agent の説明可能性（explainability）を担保する仕組みです。

GitHub プロジェクト 7 件選定ロジック

エンジニア採用向け OSS としての特徴がはっきり出ているのが、GitHub プロジェクトの選定ロジックです。

README の「Architecture」フローによれば、github.py は候補者の GitHub プロフィールから公開リポジトリを取得し、プロジェクトを分類した上で、最小コミット数の閾値を満たす上位 7 件を LLM に選定させる設計になっています（出典: https://github.com/interviewstreet/hiring-agent/blob/main/README.md）。

すべてのリポジトリを LLM に投げ込むのではなく、コミット閾値で機械的にフィルタしてから LLM に意味的な分類・選定を委ねる構成です。トークンコストの最適化と評価の安定性の両面に効きやすい設計と読み取れます。

公平性と説明可能性の設計思想

Hiring Agent は単なる採点ツールではなく、HackerRank のリリース文脈で「explainability as a mandatory feature（説明可能性を必須機能として扱う）」という設計思想を打ち出しています。プロンプトテンプレートの中で公平性に関する制約（fairness constraints）を表現することで、特定の属性に依存しない採点を志向しているとされています（参考: aitoolly の紹介記事）。

evidence と fairness constraints が同居している点は、商用のブラックボックス型 AI 採点ツールに対して、自社の採用判断ログとして説明可能性を確保したい組織にとって大きな魅力になります。

対応する LLM バックエンド（Ollama / Gemini）

Hiring Agent は、ローカル実行可能な Ollama と Google Gemini の 2 系統の LLM バックエンドに対応しています。

環境変数と provider マッピング

README の「Configuration」セクションでは、以下の環境変数で LLM プロバイダーを切り替える構成が示されています（出典: https://github.com/interviewstreet/hiring-agent/blob/main/README.md）。

また config.py には DEVELOPMENT_MODE フラグがあり、有効化すると中間 JSON のキャッシュと CSV エクスポートが有効化される、と README に記載されています。

CLI の起動方法も README に明記されており、抜粋すると以下のとおりです。

$ python score.py /path/to/resume.pdf

出典: https://github.com/interviewstreet/hiring-agent/blob/main/README.md

Ollama によるローカル運用と Gemini の使い分け

Ollama を使えば、履歴書 PDF の解析から評価までを自社のローカル環境（あるいは社内ネットワーク内）で完結させられます。履歴書という個人情報の塊を外部 API に送らずに済む点は、データ保護要件のある採用業務で特に大きな意味を持ちます。

一方、評価精度や処理速度を優先したい場合、特に GitHub 連携を含めて多数のサンプルを処理したい場合は、Gemini 系の大規模モデルを LLM_PROVIDER=gemini で切り替える選択肢が現実的です。前提条件として、README には Python 3.11+（リポジトリの .python-version は 3.11.13 で pin）と、Ollama または Gemini API のいずれかのバックエンドが必要であることが明記されています。

整理すると、運用パターンは概ね次のように切り分けられます。

• PoC / 内部利用: Ollama + 小型モデル（例: gemma3:4b）。データを社外に出さない構成。
• 本番採用: Ollama + より大きなモデル、または Gemini。スループットと精度を優先。

類似 OSS との比較

履歴書スクリーニング系の AI ツールは複数の OSS が登場しています。本セクションでは、Hiring Agent と立ち位置が近い 2 件と、HackerRank ルーブリックを参考にした第三者実装 1 件を取り上げ、初見でも違いを見極められるよう比較します。

ats-screener との差分（求職者向け vs 採用側向け）

sunnypatell/ats-screener は、Workday・Taleo・iCIMS・Greenhouse・Lever・SuccessFactors という 6 種類のエンタープライズ ATS の挙動をシミュレートし、それぞれに対するスコアと改善提案を返すツールです。

主な違いは次のとおりです。

• 想定ユーザー: ats-screener は 求職者向け（ATS チェッカー代替）、Hiring Agent は 採用側向け（候補者スコアリング）
• 評価ロジック: ats-screener は既存 ATS の互換性をシミュレート、Hiring Agent は独自の HackerRank ルーブリックで採点
• GitHub シグナル: ats-screener は未使用、Hiring Agent は GitHub プロフィール・リポジトリを必須補強として利用
• 出力: ats-screener は ATS プラットフォーム別スコア＋改善提案、Hiring Agent は単一の評価結果＋カテゴリ別スコア＋evidence

「履歴書 OSS」とひとくくりにされやすい両者ですが、そもそも対象ユーザーが正反対である点を押さえる必要があります。

End-To-End-Resume-ATS-Tracking-LLM-Project-With-Google-Gemini-Pro との差分（JD 必須 vs 非依存）

praj2408/End-To-End-Resume-ATS-Tracking-LLM-Project-With-Google-Gemini-Pro は、求人票（JD）と履歴書を Google Gemini Pro で突き合わせ、マッチ率・欠落キーワード・候補者プロファイル要約を返す採用担当者向けツールです。

主な違いは次のとおりです。

• 評価軸: こちらは JD 適合度（求人票必須）、Hiring Agent は JD 非依存の客観評価
• GitHub シグナル: こちらはなし（履歴書テキストのみ）、Hiring Agent は GitHub を必須補強として利用
• LLM の選択肢: こちらは Gemini Pro 単一、Hiring Agent は Ollama / Gemini を切替可能でローカル運用にも対応
• スコアの粒度: こちらはマッチ率と欠落キーワード、Hiring Agent はカテゴリ別スコア + bonus / deduction + evidence

求人票ごとの適合度を見たいケースでは JD ベースが向いていますが、「候補者本人のエンジニア活動の質を継続的に評価したい」用途では Hiring Agent の方が直接的です。

補足: HackerRank ルーブリックを参考にした第三者実装

todddong/hackerrank-resume-ats は、HackerRank の採用ルーブリックを参考に、Open Source / Projects / Production Experience / Technical Skills の 4 軸で履歴書を採点する第三者実装です。

評価軸そのものは Hiring Agent と類似していますが、Hiring Agent は HackerRank（interviewstreet）が公式に公開している実装であり、評価ルーブリックの出所が明確である点で位置づけが異なります。

比較表

採用業務に組み込むときの検討ポイント

ここまでの情報をベースに、自社の採用業務に Hiring Agent を組み込むかどうかを判断するうえで、特に確認しておきたいポイントを整理します。

データ保護・ローカル運用の現実性

履歴書には氏名・連絡先・職歴・学歴など個人情報が密に含まれます。日本国内では個人情報保護法・GDPR 同等の社内規程を持つ企業も増えており、履歴書データをクラウド型の汎用 LLM API に送ることは社内承認が下りないケースがしばしばあります。

Hiring Agent はデフォルトプロバイダーが Ollama で、ローカルマシン（または社内ネットワーク内のサーバー）で完結する構成を取れる点が、この観点での最大の利点です。「データを外に出さずに AI 採点を試したい」ニーズに対する第一候補になりやすい OSS と言えます。

メンテナンス状況の客観評価

「自社で採用する OSS としてメンテナンスは健全か」を判断する客観指標を、リポジトリメタデータから整理すると以下のとおりです。

• スター数 3,256、フォーク数 709（2026 年 6 月時点）
• 直近 push: 2026-06-22（本記事執筆時点で直近）
• ライセンス: MIT
• archived: false（運用継続中）、fork: false（オリジナルリポジトリ）
• 運営元: HackerRank（interviewstreet Org）

加えて、Issue の状況は Issues 一覧 から最新の数値を確認できます。本記事執筆時点では Open issues が 248 件と、リリース直後に流入したフィードバックがそのまま積まれている状態でした。Issue 数の絶対値そのものよりも、直近 push の継続性（コードが更新され続けているか）と Issue へのリアクションを併せて確認するのが現実的な評価方法です。

「数千スター級・ライセンス明確・公式 OSS・直近活発」という条件は揃っているため、初見の評価としては PoC 投資に値する水準 にあると整理できます。

国内採用業務への適用上の留意点

国内のエンジニア採用に組み込む際、念頭に置いておきたい点として次の 2 つがあります。

• 日本語履歴書フォーマット: README の説明はあくまで英語履歴書を前提とした構造化を主眼としているため、日本の履歴書・職務経歴書フォーマットでの精度は別途検証が必要
• GitHub 活動が薄い候補者: GitHub プロフィールが必須補強となる設計上、業務系・SIer 系のエンジニアなど GitHub 公開活動が薄い候補者の場合、open_source カテゴリのスコアが必然的に低くなる傾向が考えられる

後者については、prompts/ 配下のテンプレートを差し替えてカテゴリの重み付けを調整したり、自社の評価方針に合わせたルーブリックに書き換えたりすることで吸収できる余地があります。

カスタマイズと拡張のしやすさ

Hiring Agent はプロンプトを prompts/ 配下に Jinja テンプレートで分離しており、また LLM プロバイダーは models.py / llm_utils.py でインターフェース抽象化されています。これにより、

• 評価ルーブリックを自社向けに書き換える
• プロバイダーを追加する（Ollama・Gemini 以外のバックエンドへの拡張）
• 中間 JSON のキャッシュ機構（DEVELOPMENT_MODE）を本番運用に転用する

といった改修を、コア実装に深く踏み込まずに実施できる構造になっています。社内 PoC 後に「自社評価エージェント」として育てていく前提でも、無理のないアーキテクチャです。

まとめ

Hiring Agent は、HackerRank が 2026 年 6 月に公開した履歴書評価 OSS で、PDF を Markdown 化し、セクション単位で LLM 抽出を行い、GitHub シグナルで補強した上で、カテゴリ別スコアと evidence を出力する説明可能な AI 採点パイプラインです。MIT ライセンスで公開されており、Ollama によるフルローカル運用にも対応しているため、データ保護要件の厳しい採用業務との親和性が高い OSS です。

冒頭で提示した「初見エンジニアの意思決定支援」として、本記事で扱った 3 つの問いに対する暫定的な答えは次のように整理できます。

• 自社に採用すべきか: PoC 段階で Ollama + 小型モデルを使い、社内のサンプル履歴書に対してカテゴリスコアと evidence の妥当性を確認する流れが現実的。データ保護要件が厳しい組織ほど第一候補に入れやすい
• 類似 OSS とどう違うか: ats-screener は求職者向け、Resume-ATS-Tracking-Gemini-Pro は JD 必須型。Hiring Agent は 採用側向けかつ JD 非依存で GitHub シグナルを必須補強として持つ点が決定的差分
• メンテナンス状況は健全か: スター 3,256・フォーク 709・直近 push 2026-06-22・MIT・HackerRank 公式と、初見の客観指標は良好。Issue の動きは継続的に観測する前提

次のアクションとして、まず公式の README を精読し、prompts/templates/ 配下の Jinja テンプレートを眺めることで、評価ルーブリックの具体像と自社向けカスタマイズの可否を素早く判断できます。そのうえで PoC を組むか、別 OSS と再比較するかを決めていく流れが、本記事の想定読者にとって最短ルートになるはずです。