採用管理システム（ATS）に履歴書をアップロードした際、なぜ人間が一度もそれを見ることなく終わってしまうのかと疑問に思ったことがあるなら、あなたはすでにAI採用におけるブラックボックス問題を理解している。ほとんどの履歴書スコアリングツールは、そのロジックをSaaSのダッシュボードや丁寧な不採用通知メールの背後に隠している。HackerRankは異なる道を選んだ。そのHiring Agentはオープンソースである。つまり、誰でもその中身を解明し、コードを追跡し、LLMがいかにしてPDFとGitHubのリンクを一つの数値へと変換するのかを正確に知ることができるのだ。ある開発者がまさにそれを実行した。彼が見つけたものは、洗練された採用フレームワークではなかった。それは、自動化がいかに容易に個人の意見を形式化してしまうかを示す鏡であった。

仕組みの裏側

そのパイプラインは、一見すると非常にシンプルだ。候補者のPDF履歴書はMarkdownに変換され、次に職歴、スキル、学歴、サイドプロジェクトのフィールドを持つ厳格なJSON構造へとパースされる。Pythonスクリプトがデータを次の段階へと運んでいくが、実際の「思考」はプロンプトの連鎖の中で行われる。各セクションには独自のプロンプトが割り当てられる。LLMは構造化されたデータを読み取り、平易な英語で書かれたスコアリングルールを適用し、成績を返す。

このアーキテクチャには重要な意味がある。実質的な処理は、巧妙なアルゴリズムや学習ループで行われているのではない。プロンプトの言い回しの中で行われているのだ。指示セット内の形容詞をいくつか変えるだけで、同じエンジニアが「強力な採用候補」から「力不足の候補」へと変わってしまう。そのことは、このツールが脆弱であることを意味すると同時に、正直であることをも意味している。ほとんどのAI採用ベンダーは、プロンプトを絶対に見せようとはしないだろう。HackerRankのプロトタイプは、履歴書のスコアリングが常にコードではなくルーブリック（評価基準）に基づいていたという真実を露呈させている。

35パーセントの暴政

最も顕著なバイアスは、採点ルーブリックの中に隠されている。オープンソースへの貢献が、合計スコアの35パーセントを占めているのだ。これは極めて大きな重みである。比較してみると、候補者の職歴、学歴、スキルセットのすべてが、残りの65パーセントを巡って、課外活動としてのコーディング活動の一片と競い合わなければならないことになる。

ルールは、その配分が示唆するものよりもさらに厳しい。個人のGitHubリポジトリはカウントされない。自分のライブラリを維持しているとしても、それがどれほど有用であっても、スコアはゼロだ。このツールは、他人のプロジェクトへの貢献のみを評価する。そのポイントを獲得するには、候補者は誰か他の人のコードベースのコミッターでなければならない。

その選好は、実質的な人口統計学的（デモグラフィック）な重みを持っている。独自のツールを維持しているエンジニアは、誰も解決していなかった問題を解決したからこそ、そうしている場合が多い。また、外部への貢献を禁じている職に就いていたり、大規模なオープンソースコミュニティが少ない地域で働いていたり、あるいは単に、業務時間外の無償のコーディングを不可能にする家族の義務を抱えていたりすることもある。プロンプトをこのように記述することで、このツールは純粋なエンジニアリング能力を測定しているのではなく、特定のコーディング文化への参加度を測定し、それを「客観性」と呼んでいるのである

LinkedInのプロフィールは、正確に1点分として扱われる。プロフィールの質でも、推薦文の数でも、職歴の深さでもない。履歴書にURLが記載されているだけで、合計点に1点が加算される。一方で、Google Summer of Code（GSoC）の参加者は5点分となる。そして、候補者がGitHubでフォークしたリポジトリを持っている場合、エージェントは自身のフォーク数が5に満たないフォークはすべて無視する。

これらのルールのひとつひとつが、静かな係数という形を借りて、声高な価値判断を下している。なぜLinkedInの存在がそもそも1点の価値を持つのか？ それは、候補者がソーシャルネットワークの入力方法を知っていることを示しているだけで、分散システムの設計ができることを示しているわけではない。なぜGSoCはLinkedInのリンクの5倍の価値があるのか？ おそらく、プロンプトの作成者がそのプログラムを尊重しているからだろう。その尊重が、今や採用方針となっている。そして、なぜフォーク数の境界線を5に引くのか？ ユーザーが10人しかいないツールであっても、ニッチながら極めて重要な問題を解決しているかもしれない。このシステムの下では、そのようなツールは存在しないも同然だ。

これらの数値は回帰分析から導き出されたものではない。個人によって選ばれたものだ。ある人は、オープンソースへの参加はエンジニアの価値の3分の1以上であると決め、別の人は、LinkedInのプロフィールは1点の価値があると決めた。それらの推測を自動化すると、それらにソフトウェアとしての権威を与えてしまうことになる。

すべてのプロンプトは偏見である

履歴書スコアリング・エージェントを構築する上で最も困難なのは、PDFの解析やAPIの呼び出しではない。何が重要かを決めることだ。スコアリング・プロンプトに含まれるすべての言葉は、何が良いエンジニアを作るのかという価値判断である。副業（サイドプロジェクト）は本業よりも重視されるべきか？ 公開コードは企業のプライベートな業務よりも重要視されるべきか？ ソーシャルメディアのプロフィールはそもそも重要なのか？ これらの問いに数学的に正しい答えなど存在しない。あるのは文化的な好みだけだ。

採用チームがこれを手動で行う場合、少なくともバイアスは、意見の相違、調整、学習が可能な多くのレビュアーに分散される。LLMがこれを行うと、一人のプロンプト・エンジニアのバイアスが、大規模に実行される再現可能な関数へと硬直化する。ツールは主観性を排除するのではない。それをアーカイブ（固定化）してしまうのだ。

フィルターではなく、鏡として利用せよ

HackerRankのHiring Agentは、プロトタイプとして理解するのが最適だ。それは初稿のように感じられるが、まさにその通りである。AI採用ツールがどのように構築されるかを知るための興味深い初期の事例ではあるが、実際の採用組織が行うような調整、テスト、多様な意見の投入が欠けている。

もしあなたが採用技術を構築しているなら、それを注意深く研究すべきだ。恣意的なルールがいかに素早く自動化されたゲートキーピングへと変貌するかを示しているからだ。もしあなたが候補者なら、これらのシステムは神託（オラクル）ではないことを忘れないでほしい。それらは自然言語で着飾ったスプレッドシートに過ぎず、プロンプトを書いた者の前提条件をそのまま引き継いでいるのだ。

これらのツールが、評価対象となるエンジニアと同じくらい厳格にバイアスのテストが行われるまでは、人間による対話を代替するのではなく、対話のための情報源として活用されるべきである。