HackerRankがそのATSをオープンソース化しました。私の履歴書は90/100のスコアを獲得しました。あれ、74？いや、88。

2026年6月29日原文(danunparsed.com)

概要

HackerRankのオープンソースATS 「hiring-agent」の注目度急上昇
LLMによるスコアの非決定性 と評価基準の曖昧さが問題
技術スキルは安定評価 だが、プロジェクトや経験値評価は一貫性に欠ける
スコア配分が偏っており、実力あるエンジニアが不利になる可能性
AIによる履歴書スクリーニング導入時の注意喚起

HackerRankのオープンソースATS「hiring-agent」の実態

GitHubで公開されているATS 「hiring-agent」がLinkedInやRedditで話題
PDF履歴書をテキスト化し、LLM（gemma3:4bなど）で6カテゴリ抽出
- 基本情報、職歴、学歴、スキル、プロジェクト、受賞歴
- GitHubプロファイルや主要リポジトリも自動取得・追加
全情報をLLMに投入し、100点満点＋20点のボーナス方式でスコア化
- オープンソース貢献：35点
- 個人プロジェクト：30点
- 職務経験：25点
- 技術スキル：10点
- ボーナス：最大20点（スタートアップ経験、ポートフォリオ、技術ブログ等）

スコアの非決定性と評価の一貫性問題

同じ履歴書・同じコマンドでもスコアが大幅に変動
- 例：90点→デバッグ出力削除後74点、ループ実行で66～99点までバラつき
- カットラインを85点に設定すると、65%の確率で不合格
技術スキルはチェックリスト方式でほぼ安定（98/100回で8/10点）
プロジェクト評価は大きく変動
- LLMが判断するたびに「実装力が足りない」「本番導入経験あり」と結果が揺れる
- Temperature 0.1でも非決定性が解消しない（0でも同様）
- GitHub Issueでも同様の報告（温度0で連続してスコアがバラバラ）
Geminiモデルは分布がやや安定（48～64点）だが、カットライン次第で不合格率高いまま
オープンソース貢献スコアは安定化したが、プロジェクトは依然としてノイズ多い

職務経験評価の無意味さ

職務経験（25点満点）は毎回25点で一貫
- インターン1回の古い履歴書でも25/25点
- シニアエンジニアでも同じ
評価プロンプトが2行のみで、具体的な基準や例がない
- ルーブリックや基準点が存在しないため、経験値評価が機能していない

LLMによる評価の限界と実運用上のリスク

LLMは構造化データ抽出やスキルチェックには有効
プロジェクトや経験値の定量評価には不向き
- 「雰囲気チェック」しかできず、HRが避けてきた属人的判断に逆戻り
スコア配分の偏り
- オープンソース＋プロジェクトで65%を占めるため、実績あるエンジニアが不利
- GitHubに成果がない優秀なエンジニアが過小評価されるリスク
AIスクリーニング導入時は慎重な運用が必要
- フィルタリング精度ではなく、単なるランダム除外の危険性
- 不合格通知が「運が悪かった」としか伝わらない状況

テンプレートと仕様の補足

resume_evaluation_criteria.jinjaテンプレートが職種に依存しない設計
- 実際には「Software Intern」等の記述があるが、スコアリングはポジション非依存
コミット履歴から見て、2025年10月以前からOSS化されていた可能性

結論とエンジニアへの提言

AIによる履歴書評価ツールの導入・運用には細心の注意が必要
- 評価基準の設計・モデルの特性理解が不可欠
- 本質的な人材評価には人間の目が依然として重要
単なる自動フィルタリングに頼ると、優秀な人材の見逃しや不公平な選考につながる危険性

Hackerたちの意見

私は65%の確率で失敗する。同じ履歴書なのに、運が違う。数年間、技術職の採用プロセスを担当してきた者としては、実際にこれは素晴らしい数字だと思う。こう言うのは客観的に嫌だけど、事実だから仕方ない。努力なしで技術者を次のステージに進める確率が35%？特定のドメインに関するスクリーニング質問を含めても、1時間に100人以上の応募者を見たことがある。それが1時間で35人の「スクリーニングされた」応募者だ。正当な候補者が除外された？はい。必要な人数の35倍の候補者プールがある？残念ながら、そう。応募者の数が非常に多いから、AIが関与していない場合、次のステージに進む確率は実際にかなり悪化する。もしすぐに（AIボットを使って）応募しなかったら、あなたの前には50人以上がいるし、もし彼らがあなたの履歴書にたどり着いたとしても、疲れ切った技術リーダーがいる。紹介ボーナスが存在するのには理由がある。

└

本当にそうなの？それとも、履歴書が一度も人間の目に触れずに無視される確率が65%で、適格な候補者を見つける可能性を同じように減少させているの？履歴書の流れを減少させるゲートは、その減少が質に関連している場合にのみ有用だよ。そうでなければ、採用プロセスを引き延ばすだけだし、最終的に採用基準を下げる原因にもなる。

└

10年以上の経験があるS3エンジニアをGitHubのリポジトリを持つインターンよりも低く評価するって部分を除いて。

└

そういうことなら、君に売りたい事前選考システムがあるよ。最先端の技術を使って、応募の中からほんの1%のベストなものだけを通すんだ。*私たちの独自の、非公開で非決定論的な指標によると、Math.randomかもしれないし、そうじゃないかもしれないけどね。

└

パイプラインを最適化する方法はもっとあると思うよ。役職に対して、君やチームが確実に処理できる応募数に基づいて制限を設けるのがいいかも。もっと必要なら、応募の新たな波を受け付けるために役職を開放すればいいんじゃない？

└

だから、論理的な解決策は、候補者が連絡先情報に少しずつ変化をつけた複数の応募を提出することだね。「ジョン・シュミット」、「ジョン・J・シュミット」、「ジョン・J・J・シュミット」、「ジョン・ジェイコブ・J・シュミット」、「J・J・ジンガルハイマー・シュミット」とかさ。

多くの人がLLMが純粋に確率的なプロセスで動いていることを理解していないのは驚きだね。こういう詳細な記事を見ると嬉しい。今、仕事を探しているんだけど、これが最近コールバックがもらえない理由かもしれない。履歴書がLLMのブラックホールに捨てられて、誰もその仕組みを本当に知らない。著者はこう言ってる：> 温度0.1 — 低い、モデルを決定論的な出力に向けるはずだ。これは正しくない（そして、後で温度を0に設定したときに簡単に触れられている）。温度は「決定論的」なスイッチではなく、サンプリング分布に影響を与えるものなんだ（それがより「スパイキー」になるけど、依然として分布である）。

└

修正されることを望むけど、この種の自動履歴書フィルタリングは違法だと思う。決して起こらないとは言わないけど、私の理解では一般的ではない。

└

一つの結果に全ての確率質量が集中している分布は決定論的だから、原則として温度を0に設定すれば決定論的な出力が得られるはず。いくつかの理由でそうならないこともあるけど、著者がローカルモデルを実行したときには当てはまらないと思う。

└

より尖った分布は、分布を決定論的に近づけるんだよね。でも、それがポイントじゃない。貪欲な（決定論的な）デコーディングでも、入力に対して予測できない反応をするブラックボックスなんだ。一つの単語を入れ替えるだけで、スコアが変わることもあるしね。

└

「驚くべきことに、多くの人がLLMが純粋に確率的なプロセスで動いていることを理解していない…私は20年間AIを勉強してきた。これに追加すべきことは、『驚くべきことに、多くの人がLLMが純粋に確率的なプロセスで動いていることを理解していない - そして人間の思考もそうだ。人々は、ただ天気が違うだけで同じ結論に達するわけではない。さらに悪いことに、人間の思考では、ほとんどの人がこれが現実だとは思っていないし、一部の人々はその考えに対抗しようとする。もちろん、天気によって変わるけどね。」

もうこのジョークを採用してもいいかもね。運が悪い人を雇いたくないから、履歴書の半分を盲目的に捨てるってやつ。

Hacker Newsで議論の続きを見る

ハクソク