こんにちは、ウォンテッドリーでソフトウェアエンジニアをしている市古（@sora_ichigo_x）です。現在は Visit Sourcing Agent Squad でスカウトの新機能「AIエージェントモード」の開発を担当しています。

はじめに

「AIエージェントモード」は 2025年11月にリリースされたスカウトの新機能で、候補者探しの一部を AI で自動化することができます。

ウォンテッドリーでは2024年2月に 「スキル・プロフィール生成機能」 （スキル診断結果からAIがプロフィールを自動生成）をリリースしていますが、あれから1年以上が経ち、生成 AI を取り巻く技術・運用環境は大きく変わりました。今回はその変化を踏まえ、あらためて「どう設計すべきか」をゼロから判断する必要がありました。

本記事ではAIエージェントモードを開発する中で、特に「どのようにして AI に候補者リスト生成を任せ、かつ安全に運用できるように設計したか」をお話しします。

何を、なぜ作るのか

今回の開発で掲げた目的とミッションは次の通りです。

"ソーシング工数を削減するため、ソーシングを AI で自動化する"

Wantedly のスカウト機能におけるソーシング工数とは、スカウト対象となる候補者を探索・選定するための作業を指します。この工数は採用担当者の業務全体に占める割合が大きく、候補者探索に時間を取られることで、本来送れたはずのスカウトが送れない、候補者とのコミュニケーションに十分な時間を割けない、といった課題が存在していました。

AI エージェントモードは、採用担当者が採用要件を入力するだけで、AI がソーシング計画を生成し、候補者を自動リスト化する体験を提供します。この機能では、これまで採用担当が時間をかけて行っていた「採用要件の整理・検索・候補者選定」の一連の作業を AI が自動化することで、ソーシングに割いていた工数を大幅に削減し、担当者が本来注力すべきコミュニケーションにリソースを戻すことを目指しています。

どうやって AI に候補者リストを作成させるか

AI が候補者リストを作成する際の問題点

採用要件を入力すると、AIが候補者リストを作成する。これを実現するには一定工夫が必要です。

まず一番シンプルなやり方は次の通りです（シンプルと言っても、ステップ3ではツール呼び出しをサポートしたりとやることは多いですが...）。

1. 採用担当がチャットに「こんな人が欲しい」と入力する
2. バックエンドが LLM に条件プロンプトを送信する
3. LLMが「こういう条件で検索して、こういう人をリスト化しました」と返す
4. 結果を UI に表示する

しかし、このやり方にはいくつかの問題があります。

• 入力の揺れに弱く、意図しない検索条件を生成する（誤動作リスク）
• 検索処理に間違いがあったときにどの判断が間違ったのか追跡できない（説明責任）
• LLM の推論バイアスを事後検証しずらい（バイアス）

採用領域においては、ソーシングの信頼性はユーザーのキャリアと企業の信用に直結するため、これらは許容できない問題です。そこで採用したのがヒューマン・イン・ザ・ループという考え方です。

ヒューマン・イン・ザ・ループ（Human-in-the-Loop, HITL）

ヒューマン・イン・ザ・ループとは "AI や自動化システムの中に意図的に人間の判断ステップを組み込む設計思想" のことです。その必要性は次の3点に集約されます。

1. 安全性... 途中で人間がブレーキを踏めるようにすることで致命的な誤動作を防ぐ
2. 説明可能性... 「なぜこう判断したか」を人が追える形で残す
3. 信頼性... AIが常に正しいという前提を置かず、人間が最終判断を握れるようにする

例えば、Wantedly の AI エージェントモードにおいて、このヒューマン・イン・ザ・ループの考え方を取り入れると前述のやり方を次のように変えることができます。

1. 採用担当がチャット「こんな人が欲しい」と入力する
2. バックエンドが LLM に条件プロンプトを送信する
3. LLMが「こういう条件で検索する予定です」というソーシング計画を提示する
4. 人間がソーシング計画を確認・修正・承認する
5. バックエンドがソーシング計画の指示に従って候補者リストを作成する
6. 結果を UI に表示する

AI が生成した検索条件・判断材料を一度人間がレビューするため、安全性と説明責任を確保できます（以下はソーシング計画の表示例）。

ソーシング計画をどう作るか

LLM に与えられた最も重要なゴールは「ソーシング計画」を作成することです。その過程では、LLM が検索 API 呼び出しを通じて候補者数を確認し、候補者数が少なければ条件を再調整するといった“思考のループ”を実行します。

重要なのはここで複数のトレードオフが発生することです。

• 挙動の一貫性（毎回同じ、あるいは近い結果を返せるか）
• 説明可能性（なぜそのプランになったかを追えるか）
• テスト容易性（ユニットテスト / E2E テストが書けるか）
• セキュリティ（意図しない API 呼び出しなどが起きないか）
• コスト予測性（LLMコスト・API呼び出し回数をコントロールできるか）
• 汎用性（異なるユースケースに応じた最適化を AI が自律的に行えるか）
• 拡張性（エージェント性を段階的に増やしていけるか）

これらを踏まえ、実現方式は次の 2 つが候補になりました。

1. LLM にツールを渡し、ソーシング計画作成までのフロー全体を任せる（モデル駆動）
2. ソーシング計画作成までのフロー制御はプログラムがにぎり、LLMは部分的に利用する（ワークフロー型）

結論として、今回採用したのは 2 (ワークフロー型) です。特に現段階では以下の判断が意思決定の理由となりました。

• ソーシング計画作成の手順自体は高度ではなく、LLM に全委任する必要性が薄い
• LLM の業務フローからの逸脱を必要以上に広げないため、挙動のばらつきを局所化できる
• ステップが明確に分かれるため、失敗時の再実行・追跡性が高い

懸念を上げるとしたら、会話性や汎用性を重視するユースケースではモデル駆動の方が有利というメリットはあります。しかしBtoB 領域で候補者リスト化という明確な業務目標がある環境下では会話性や汎用性が求められるケースは稀であり、また実装次第では後から部分的にモデル駆動へ移行することも可能と判断し、ここでは 1 (モデル駆動) を選ばないリスクを許容しています。

さいごに

本記事で解説したのは、AI エージェントモードの初期設計フェーズにおける設計方針です。実際の本番環境では、これに加えて以下が必要になります。

• LLM の長時間実行に耐えるワークフロー設計
• LLM 出力の検証と安全ガードレール
• セキュリティ的に望ましくない入出力の検知
• 例外処理・再試行ロジック
• オブザーバビリティの確保

これらの詳細はチームメンバーが今後ブログで紹介してくれる予定です。興味があればそちらもぜひご覧ください。