AIネイティブなワークフローで採用書類スクリーニングを再構築した方法

この記事は、ある小さな実験についての話だ。Notion上の採用データベースをClaude Codeに接続し、100体超のAIエージェントを並列でディスパッチするダイナミックワークフローを実行した。各エージェントが履歴書を読み込み、一貫したルーブリックに照らして採点し、互いの判断をクロスチェックすることで、すぐに実行に移せるランク付けされたショートリストを生成したのだ。

全体のコストは**$65**で、115人の候補者に対して約13分で完了した。だが、コスト以上に興味深かったのは、この過程で浮かび上がってきた方法論上の問いだった。1体のエージェントではなく艦隊のように多数のエージェントを使うべきはどんなときか、AIによるスコアのインフレをどう防ぐか、そして機械が実際に実行できる形に「優秀さ」をエンコードするとはどういうことか。

1. ダイナミックワークフローとは何か

まずは概念から始めよう。これこそが、以降のすべての土台となるものだからだ。

今日のAI利用のほとんどは、プロンプトと返信というパターンに沿っている。メッセージを送り、回答を受け取り、それを繰り返す。これは単発のタスクにはうまく機能するが、115個のオブジェクトに対して同じことをしようとすると途端に厄介になる。115回コピー＆ペーストを繰り返すか、あるいは1つの会話に逐次処理を依頼するかのどちらかになるが、後者は進むにつれて遅く、ノイズも増えていく。

ダイナミックワークフローはこれとは異なるモデルだ。AIエージェントの艦隊をオーケストレーションするコードである。 その特徴は次のとおりだ。

• 決定論的な制御フローとAIの判断を分離する。 ループ、ディスパッチ、集計、クォータの強制はコードが担当する（再現可能で監査可能）。一方、主観的な判断（この履歴書は十分に強いか？）はAIエージェントに委ねる。
• ファンアウト並列処理。 1回の parallel(...) 呼び出しで、数十から数百体もの独立したエージェントを同時に立ち上げられる。各エージェントは互いを汚染することなく、自分の担当分だけに取り組む。
• 多段階パイプライン。 ある段階の出力が次の段階に渡される。段階と段階の間のフィルタリング、ランク付け、重複排除はコードが処理する。
• 構造化された出力。 各エージェントは、フリーフォームのチャットテキストではなく、スキーマに準拠したJSONを返す。これにより、下流のコードが直接それを消費できる。

たとえるなら、1つの会話は1人の専門家に午後いっぱい相談するようなものだ。ダイナミックワークフローは、125人のレビューパネルを編成し、各メンバーにルーブリックと候補者ファイルを1部ずつ渡し、すべてのレビューを並列で実行し、上位の結果をクロスチェックして、ランク付けされたリストへと集計するようなものである。しかも、その編成・ディスパッチ・集計のロジックがスクリプトに組み込まれているのだ。

履歴書スクリーニングは、このパターンにぴったり当てはまる。大量、統一された基準、主観的判断、公平性の要件という条件がそろっているからだ。

より深い技術的な入門としては、こちらを参照してほしい： A harness for every task: dynamic workflows in Claude Code

2. 採用ワークフロー：目標と設計

課題

私たちには具体的な悩みがあった。Notionの採用データベースに「初期レビュー」ステータスの候補者が100人以上も滞留していて、基準のドリフトなしに手作業で処理する現実的な方法がなかったのだ。80人目の履歴書に適用する基準が、5人目に適用した基準とまったく同じであることは、ほぼあり得ない。

私が検証したかったのは、ある1つの具体的なアイデアだった。「AIエージェント時代における優秀さとはどういうものか」を、機械が実行可能で人間が読めるルーブリックへと抽象化し、115人の候補者全員を同じキャリブレーションで通すことはできるか？

目標は、明確にAIに採用判断をさせることではなかった。目標は次の2つだ。

1. 115人の候補者を、ランク付けされた根拠付きのショートリストへと圧縮し、人間の注意が本当にそれに値する人々に向かうようにする。
2. 基準を透明かつ反復可能にする。出力が間違っていたら、変えるのはコードや勘ではなく、Markdownファイルである。

3つの重要な設計判断

判断1：基準とコードを完全に分離する

評価基準は、ワークフローのコードに埋め込むのではなく、独立したMarkdownファイル（criteria/）に置いた。技術者でないチームメンバーを含め、誰でもこれらのファイルを編集することでスクリーニングの挙動を変えられる。

criteria/
├── 00-philosophy.md          Overall philosophy: what we're hiring for + the "raise the bar" rule
├── 01-pedigree.md            Strong academic / early foundation    (weight 20%)
├── 02-ai-agent-fluency.md    AI-native capability                  (weight 35%)
├── 03-grit-problem-solving.md  Problem-solving & overcoming difficulty  (weight 30%)
├── 04-talent-lens.md         Top-talent signal                     (weight 15%)
└── scoring.md                Scoring formula + grade bands + 5% quota rule

これら4つの次元が、私たちの**「AIエージェント時代における優秀さの基準 v0.1」**だ。それぞれの背後にある考え方は次のとおり。

• AIネイティブな能力に最も高い比重（35%）を置く。 2026年において、ある人がClaude Codeのようなエージェント型ツールを、自分の仕事のあり方の中核として本当に使いこなしているかどうかは、生産性の大きな分水嶺となる。私たちはキーワードの詰め込みを特に減点する。検証可能なプロジェクトの証拠なしに「Claude Code」と列挙するだけでは、弱いシグナルとして扱う。
• 問題解決の確かな証拠（30%）。 私たちは「傷跡」を探す。ゼロから独力で作り上げたもの、現実の障害を乗り越えた物語であって、チュートリアルレベルの再現ではない。
• 強固な基礎（20%）。 学歴は地力としてのポテンシャルの代理指標として機能する。あくまでシグナルであって、必須要件ではない。難関大学の学位と凡庸なアウトプットの組み合わせは減点され、名のある肩書きはないが実際に世に出した成果のある独学のビルダーは加点される。
• トップ人材のシグナル（15%）。 この次元は意図的に主観的にしてある。プロンプトはこう問いかける。Anthropicのようなチームや、Muskのような創業者が、すぐにでも声をかけたくなる相手か？ ほかの3次元では捉えきれない、主体性・センス・スピード感を捉えるための次元だ。

判断2：「バーを上げる」をスローガンではなくハードな制約としてエンコードする

scoring.md には、固い規則が含まれている。最上位ティア（S）に到達できる候補者は、全プールの5%以下でなければならない。 すべての採点が完了したあと、コードはグローバルな上限を適用する。たとえ技術的にはSレンジに入る候補者が多数いたとしても、上位5%だけが通過を許される。これは、既知の失敗モードに真っ向から対抗するものだ。AIの採点は本質的に甘い。 ハードな制約がなければ、AIはプールの半分を「優秀」と評価してしまう。

判断3：水増しスコアを捕まえるための敵対的レビューを加える

採点だけでは不十分だ。1体の採点エージェントは、印象的に聞こえるキーワード——「トップジャーナルに掲載」「独自のフレームワークを構築」——に引きずられかねない。そこで、上位にランクされた候補者は二度目のパスを通過する。「悪魔の代弁者」エージェントのパネルだ。その明示的な役割は、「この人物は最上位ティアの評価に値する」という主張に反論することであり、証拠が十分に裏付けていない箇所ではどこでもスコアを押し下げる。

ワークフロー

セットアップ 📋 Notion採用データベース — Notion CLI pull → 候補者1人につき構造化データファイル1つ

AI フェーズ1：採点（115体のエージェントを並列実行）

• 6つの基準MDファイル＋その候補者のデータファイルを読み込む
• GitHub / ポートフォリオのリンクを実際に訪問して証拠を検証する
• 構造化JSONを出力：4次元のスコア＋理由付け＋ハイライト＋リスクフラグ

Code 決定論的な統合

• 加重合計を計算する
• グローバルにランクソートし、5%クォータの枠数を算出する
• 敵対的レビューのキューに入れる上位候補者を選抜する

AI フェーズ2：敵対的レビュー（エージェントを並列実行）

• 「悪魔の代弁者」のペルソナが各上位候補者をレビューする
• 最上位ティアの認定に反論する
• 証拠が不十分な箇所でスコアを押し下げる

Code 決定論的な評決

• キャリブレーション済みのスコアで再ソートする
• 5%のハードキャップを強制する
• 最終的なグレードバンドを割り当てる：S / A / B / C / D

出力：ランク付けされたレポート 候補者ごとのスコア、理由付け、敵対的レビューの評決を含む構造化Markdown

青の段階（採点／レビュー）はAI。グレーの段階（統合／評決）はコードだ。 この分割は意図的なものである。数学的なもの——重み付け、ランク付け、クォータの強制——はすべて再現性のためにコードに回し、判断を要するもの——この人物は十分に強いか？——はAIに回す。

3. 観察したこと：結果とインサイト

以下の候補者はすべて匿名化してある。氏名や個人を特定できる詳細ではなく、取り組んだ仕事の種類について記述する。

何を実行したか

分布

5%のクォータ（5枠）はまったく使われなかった。 誰かをブロックしたのはクォータではなく、絶対スコアのしきい値だった。独力でAバンドの下限を超えた者はいなかった。なぜそれが実は有用なシグナルなのかについては、後述する。

ランキング上位はどんな顔ぶれだったか（匿名）

例外なく、最上位にランクされた候補者は、実際にエージェントを作ったことのある人々だった。AIについて聞きかじっただけの人ではない。

• #1： ある大学院生で、Claude Code風のマルチエージェント・ワークベンチをゼロから構築した人物。エージェントのメインループ、ツール呼び出しのパース、コンテキスト圧縮、サブエージェントの生成、セーフティゲートまで含まれていた。すべて検証可能なコードであって、説明文ではない。
• #2： 別の大学院生で、実際に公開アクセス可能なマルチエージェントシステム（垂直ドメイン向けアプリケーション）をデプロイしており、その上に学術的なアウトプットを積み重ねていた。
• さらに下位には、Goでエージェントのオーケストレーションエンジンをゼロから書いた人物、Claude Codeのアーキテクチャを研究して軽量なコーディングエージェントを世に出した人物、AIツールを全面的に使って7日間でローカルLLM搭載のゲームを独力で作り上げた人物などがいた。

彼らに共通していたもの： その強いシグナルは、ほぼ例外なく履歴書の本文には現れていなかった。それはGitHubのリポジトリやポートフォリオの中にあった。だからこそ、各採点エージェントには、履歴書のテキストを読むだけでなく、リンクを実際に訪問して証拠を検証するよう指示していたのだ。

3つのインサイト

インサイト1：敵対的レビューは水増しスコアを実際に捕まえた

最も明白な例は、上位2人の候補者だった。採点フェーズのあと、両者とも加重合計が82点前後で、Aバンドに押し込まれ、Sのしきい値をかすめるだけのスコアだった。敵対的レビューのあと、両者とも75点前後に着地し、その理由は非常に具体的だった。

「検証可能なマルチエージェント・ワークベンチを構築した——AIネイティブな能力は確かなシグナルだ。だがこのプロジェクトは作られてから約3週間、コントリビューターは1人、スター0、テストなし。概念的には再実装であって、独自の問題解決ではない。学位の一行を除けば、裏付けとなる証拠がほぼ皆無：確かなハイポテンシャル候補者ではあるが、卓越してはいない。」

「本物の、検証可能なAIネイティブなビルダーだ。だが主張されているトップジャーナルへの掲載は、リクルーターのメモにのみ現れており、独立に検証可能な出典がない。コアシステムのバックエンドは非公開で、個人としての貢献を確認できない。検証されていない学術的資格を使って最上位ティアを狙うのは、キーワード駆動のスコアインフレだ。」

これこそが、この設計が意図していたことだ。これらの候補者を切り捨てたのではない——証拠が実際に裏付けられる水準までスコアを引き戻したのである。 1体の採点エージェントは舞い上がってしまうことがある。それに反論することを役割とする別のエージェントパネルが、そのインフレを確実にしぼませてくれる。

インサイト2：S:0 / A:0 はバグではない——鏡である

最初の直感は、バーの設定が間違っていたのではないかと問うことだ。だが、プールを正直に見つめてみると——

• かなりの割合の候補者は、履歴書が非常にスカスカだった。重要な次元（AIの経験、検証可能な成果）がただ単に欠落していた。
• Agent Engineer職への応募者の多くは、エージェント型ツールを使った証拠がゼロで、GitHubのリンクもなかった。
• プールにはリクルーターのビジネスメールやLinkedInのシステム通知も含まれていた。これらは無関係だと正しく識別され、0点が付けられたのだが、図らずも私たちの採用データベースがクリーニングを必要としていることを露わにした。

言い換えれば、厳格なルーブリックが、シグナルとノイズをきれいに分離した。 本物のビルダー（上位6人）と「達成のある何でも屋」（中位ティア）は、明確に異なる場所に収まった。それこそが狙いだ——全員を水増しするくらいなら、数人を取りこぼすほうがいい。

これはまた、議論する価値のあるオープンな問いも浮かび上がらせる。現在のAバンドのしきい値（78点）は、強いGitHubの実績はあるがまだ職務経歴のない学生の候補者にとって、厳しすぎるのではないか？ 興味深いことに、敵対的レビューのエージェント自身が、上位2人を「ハイポテンシャル候補者」と評していた——にもかかわらず、加重スコアは彼らをBバンドにとどめた。ハイポテンシャルな若手キャリアの候補者に対してそのしきい値を緩めるべきかどうかは、Bグループからの実際の面接の質を見たうえで下すのが最善の判断だ。 朗報は、その変更が1つのMarkdownファイルの中の1つの数字だということ。コードは不要だ。

インサイト3：「基準をコードとして書く」と、意見の対立が生産的になる

採用基準についての会話は、たいてい曖昧なまま終わる——「やる気のある人がほしい」「自分で考えて切り拓ける人」。このルーブリックは、重みとアンカーとなる具体例とともに書き下されているため、会話はすぐに具体的になる。「AIの能力は35%にすべきか、40%にすべきか？」「名門の学位を持たない突出したビルダーは、実際どれだけ加点されるべきか？」「クォータは5%にすべきか、8%にすべきか？」——あらゆる意見の対立が、Markdownファイル内の特定の一行に対応していて、それは変更でき、バージョン管理でき、議論できる。 基準は、毎回のミーティングで唱え直す合意ではなく、メンテナンスしていく資産になるのだ。

4. コストとROI

正確な支出

私たちはClaude Opus 4.8（最上位ティア）を使った。トークンカテゴリ別の正確な内訳は次のとおり。

これは候補者1人あたり、おおよそ$0.57という計算になる。

直感に反する発見：キャッシュ書き込みが最大の費目

自然な思い込みとしては、115体のエージェントが全員同じ6つの基準ファイルを読んでいるのだから、プロンプトキャッシュが大いに役立つはずだ、と考えてしまう。実際には、期待するような形では役立たない。

プロンプトキャッシュは、プレフィックスの完全一致で機能し、各エージェントのセッションは独立している。125体のエージェントは125個の独立したセッションを意味し——それぞれが異なるタスク記述（異なる候補者データ）を持つ——ため、エージェントAが書き込んだキャッシュは、エージェントBがヒットさせることができない。キャッシュが役立つのは、各エージェント自身のマルチターン実行の中だ（基準を読む → GitHubを訪問 → ポートフォリオを訪問 → 出力、という各ラウンドで、それ以前の内容を読み直す）。

これはアーキテクチャ上のトレードオフを明らかにする。ファンアウト並列処理はキャッシュ書き込みコストを倍増させる（すべてのエージェントが自前のキャッシュを構築する）が、その代わりに、互いを汚染しない隔離された判断が手に入り、逐次処理における二次的なコンテキストの累積が解消される。判断品質に敏感なタスクにとって、そのトレードオフは支払う価値がある。

ROIをどう捉えるか

手作業のレビューとの直接比較：採用担当者が履歴書を1部ていねいに読み、GitHubを確認し、メモを書く——控えめに見積もっても候補者1人あたり5〜10分。115人分なら、10〜19時間の集中作業となり、しかもその間ずっと基準がドリフトしていく。

このワークフローが提供したのは次のとおり。

だが、より重要なROIは注意配分にある。それは人間の焦点を、明らかに不適合な83人の候補者から引き離し、上位の6人の本物のビルダーへと向け直したことだ。それこそが、初期スクリーニングが成し得る最も価値の高いことである。

もっと安くできるか？

できる。だがおそらく、その必要はない。もしこれが高頻度・大量の運用（毎日数百人の候補者）になったなら、現実的な最適化は次のようになるだろう。

• 採点フェーズにはSonnetを使い、Opusは敵対的レビューだけに使う——品質の低下を最小限に抑えつつ、おそらく70〜80%のコスト削減になる。
• あるいは、ざっくりした一次パスには安価なモデルを使い、その後、上位ティアの詳細な評価にOpusを使う。

だが採用は、低頻度で、ハイステークスで、取り返しがつきにくい。完全な監査可能性と反復可能な基準を備えてパイプライン全体を処理するのが$65なら、結論は明白だ。最良のモデルを使え。わずかなコスト削減のために判断品質を犠牲にするな。

全体像

この実験で本当にワクワクするのは、「AIが履歴書をスクリーニングできる」という点ではない——それは新しいアイデアではない。ワクワクするのは、ダイナミックワークフローというモデル——AIエージェントの艦隊をオーケストレーションするコード——が、ある種のカテゴリの仕事を、はじめて構造化可能・再現可能・反復可能にするという点だ。

採用は単なる入口にすぎない。同じパターン——読めるファイルとしての基準＋ファンアウト並列評価＋敵対的レビュー＋決定論的な集計——は、一貫した大量の主観的判断を下す必要があるあらゆる領域に転用できる。コンテンツモデレーション、コードレビュー、ユーザーフィードバックのトリアージ、競合分析、デューデリジェンス。

このルーブリックはv0.1だ。完璧ではない。だがそれは今や、バージョン管理され、議論でき、改善できる資産になった——誰かの頭の中に住む暗黙の合意ではなく。その転換こそが、どの個別の結果よりも、この実験が本当に問おうとしていたことなのである。