採用AIエージェント 『リクルタAI』 をささえる 「攻め」 の開発サイクルと 「守り」 の品質保証
こんにちは、Algomatic Works の宮脇（@catshun_）と申します。
本記事では、先日 Algomatic Works がリリースした採用支援AIエージェント『リクルタAI』の開発について、その裏側を紹介します 🙌
AIエージェントの話は、以前こちらでちょこっと紹介したので、以下のブログをご参照ください！
採用支援AIエージェントをリリースしました
先日、Algomatic Works から企業の採用を支援する AIエージェント『リクルタAI ダイレクト採用』をリリースしました。
『リクルタAI』は、採用業務に特化した 垂直型AIエージェント で、現在『書類選考』『ダイレクト採用』を支援するサービスを展開しています。
1-1. リクルタAI の特徴について
今回リリースした『リクルタAI ダイレクト採用』には、次のような特徴があります。
企業の採用担当者は「カレンダーをあけて待っているだけ」で、求める人材との面談機会を獲得できる。
候補者は、転職したいタイミングで 採用方針や採用担当者の想いが反映された 1to1メッセージ を受け取ることができる。
1-2. リクルタAI をささえる現役人事
現在のリクルタAIは、弊社ではたらく現役人事がおもに運用しています。
連絡窓口として顧客とコミュニケーションをとり、顧客の要件を汲みとってプロンプトに落とし込み、AI の生成内容について評価サイクルを回すところまで、その大半を（エンジニアではなく）現役人事が行なっています。
顧客からみると「カレンダーをあけて待っているだけ」に見えますが、じつは 裏では現役人事とAIエージェントが協働して採用を代行 しています。
ーーー 現役人事もプロンプトをつくる
今でこそプロンプト構築は一部自動化されましたが、はじめの頃は CHRO の高橋（@hiroyuki_takh）をふくめた現役人事の方々が、頭を抱えながらもエンジニアと伴走してくれており、積極的にプロンプト構築にも手伝ってくれていました。
業務で使える品質をAIで出すのはとても難しいです。プロンプトをつくるにしても、言語モデルに関する知識、解きたいタスクに関するドメイン知識どちらも必要になります。
リクルタAIでは、依存性注入のようなイメージで、プロンプトを基盤部分と変数部分に分けており、プロンプト知識を要する骨組みをエンジニア、採用担当者の想い・採用に関するドメイン知識を反映する肉付けを現役人事が担当する ように管理しています。
1-3. リクルタAI は現役人事からの信頼で 『メガシンカ』 する
現役人事とAIエージェントが協働で採用代行しているとお伝えしましたが、自動運転のレベル分け でいうと レベル3-4 のイメージです。
レベル3 … システムが全てのタスクを実施するが、重要な意思決定が必要なポイントで現役人事が適切に対応
レベル4 … 特定条件下においてシステムが全てのタスクを実施
顧客の要求は時間とともに変化する ものです。自社の採用要件について企業内で共通言語化し採用プロセスを回しながら評価するのはとても時間がかかります。そのため弊社の現役人事が、採用代行として 採用プロセスを実際に回しながら顧客と伴走して採用要件の言語化を行なっています。
要件が定まっていない期間中は、たとえ募集内容に意向を示す候補者であっても、AIが勝手にスカウトを送ってしまっては困ります。
そのためリクルタAIでは、重要な意思決定が必要なポイントで現役人事が介入する ようにしています。介入頻度がかぎりなくゼロに近づき、現役人事とリクルタAIが強い信頼で結ばれてはじめて、リクルタAIはレベル4に『メガシンカ』します。
「進化を超えた進化」とされるメガシンカは、その限界を超えた「ポケモンの進化」である。身体が成長し新たな姿となるのではなく、トレーナーと強い絆で結ばれたポケモンに、ある特定条件下のみで発現し、その後はそれ以前の姿へ戻る。そして、メガシンカを遂げたポケモンは、通常進化ではあり得ないパワーを発揮することができるようになる という。
雑談. AIエージェントにおける 『ハサミギロチン戦法』 と 『メガシンカ』
これは COO の高橋（@dory111111）と話すのですが、AIエージェントによる業務代行は『ハサミギロチン』のような特性 を持つとよいと思っています。
カイロスの持つ「ハサミギロチン」は、およそ3回に1回の確率で相手を「ひんし」にするクリティカルな攻撃をくりだしますが、AIエージェントも同様であるべきという主張です。
AIエージェントにおいては、命中率100%であっても 常に出力補正が必要になるのであれば、業務代行は現実的ではない と思います。この場合『AIエージェント』ではなく『AIアシスタント』とよばれます。
AIエージェントによる業務代行を目指すのであれば、まずは命中率が低くてもクリティカルな出力を生成できるシステムが必要 です。これを実現した上で命中率を徐々に上げていきます。
弊社ではこれを『ハサミギロチン戦法』と呼んでいます。
また重要なのは、自動運転における特定レベルを実現するのではなく、レベル間を柔軟に行き来できるシステムを目指す ことです。つまり、時々メガシンカして『メガカイロス』になれる余地を設けることが必要です。
というのも、顧客からの要求は時間とともに変化し、またAIシステムは時間とともに ドリフト が発生します。また可用性の観点からも、システム障害が発生した場合にレベルを落として稼働率を担保することが重要です。
そのため、AIエージェントは『ハサミギロチン』のような特性を持ったメガカイロスのような存在を目指すとよいと思います（責任は負いかねます）。
業務代行を実現するための 『攻め』 と 『守り』
AIエージェントによる業務代行を実現するためには、タスクの遂行性能を改善するだけでは不十分です。
ここからは開発の裏話として、リクルタAIがどのように業務代行を実現したのかについて、以下の2つの視点からお話しします：
「攻め」 タスクを完遂するための性能改善
「守り」 意図しない挙動を防ぐ制御システムの強化
LLM の生成品質を向上する 『攻め』 の開発
前半の「攻めの開発」では、MLOps文脈で言及される機械学習プロジェクトの開発サイクルについて取り上げ、Inner- / Middle- / Outer- ループそれぞれで心がけていた点を紹介します。
攻-1. 効果的にすばやく改善サイクルを回す
機械学習プロジェクトでは、モデル開発から本番運用までの各プロセスについて、一般的に３つの段階で改善ループが実施されます。
MLOps と LLMOps では、単位ごとのプロセスや改善サイクルの段階が異なりますが、基本的に上記のループ構造については共通していると思います。
リクルタAIは 改善サイクルを回しながらリーンなものづくりを実現 してきました。エンジニアや PM が休日返上で、チーム一丸となって膨大な量の候補者リストアップ・スカウトを手作業でやりきったこともありました。
攻-2. 【Inner Loop】 ハサミギロチン戦法を目指した PM との二人三脚
Inner Loop の改善は、初期段階でのモデル選択やプロンプト調整など、即時性のある改善を指します。開発者はプロンプトを入力し、モデルの出力を確認して、その場で調整を行うことで改善サイクルを回します。
リクルタAIの Inner Loop は、PMの帆苅（@k_hokari_biz）と二人三脚で行いました。私が判別できない生成内容に対して、ほぼリアルタイムにフィードバックをもらい、改善された生成内容を再びフィードバックしてもらう、という体制です。
フィードバックは現役人事の方からヒアリングした内容と照らしあわせて行っています。採用における表面化されない経験則を、帆苅がビジュアル言語として構造化し、私がタスク指示や制約条件等に落とし込んでいます。
攻-3. 【Middle Loop】 命中率を上げるための運用体制の整備
Middle Loop は、Inner Loop で得られた局所的な知見をもとに、システム全体や特定のユースケースに合わせた調整・最適化を行う中間的なサイクルです。ここでは顧客ごとにカスタマイズを行うための改善サイクルを回します。
Inner Loop で作成したプロンプトは、LLM サイドの知見を多くとりこんだことでスパゲッティプロンプトと化していたため、現役人事にプロンプト設定を引き継ぐには、とてもハードルが高い状態でした。
そのため Middle Loop では、現役人事の負担を減らすべく、誰であっても質の高い生成内容を獲得できるようプロンプトの簡素化に取り組みました。
具体的には、属人化された項目に対して、依存関係を考慮したうえで設定項目を個別に切り出し、さらに現役人事への依存度が高い設定項目は LLM を用いて半自動的に設定できるようにしました。
すべての顧客でカスタマイズできることを目指していたため、汎用的なプロンプトを獲得するまで、何度も Inner-/Middle- Loop を行ったり来たりして、ようやく安定して稼働できるプロンプトに辿りつきました。
攻-4. 【Outer Loop】 メガカイロス化に向けた評価サイクルの統合
Outer Loop は、システムの長期的な健全性と信頼性を維持するための運用面での改善サイクルを指します。運用時のモニタリング、ユーザフィードバックの反映、定期的なシステムアップデートが含まれます。
運用時のリクルタAIの課題は2つありました。
正解がないコールドスタートな状態でプロジェクトが開始されるので、初期プロンプト設定から要件達成ラインに到達するまでの時間を短くする 必要がある
顧客の要求は時間とともに変化するので、顧客とのヒアリング内容を反映させる 必要がある
Outer Loop では、2つの課題を解決すべく、現役人事が運用時にシステムを改善できる2つの枠組みを整備しました。
初期プロンプト設定時に運用環境上で現役人事が即座にフィードバックを反映できるような Inner-Loop を回すための機能
運用時に現役人事が記述したコメントに基づいて、顧客（採用担当者）のフィードバックをシステムに反映する機能
また言語生成タスク1つとっても、その要求は複雑で多岐にわたるため、「こういうことを書いてほしい」「これは書かないでほしい」という 包含要求と除外要求の選好極性に応じて対応方針を分ける ことにしました。
包含要求はプロジェクト開始時に要件として定まっていることが多い一方で、除外要求については実際に運用してみてはじめて明らかになることが多いです。
2. の機能を実装することにより、これまで 同一のプロンプトに共存していた包含要求と除外要求を切り分けて、Inner Loop と Outer Loop の異なる時間軸で改善する ようにしました。
これによりプロンプト修正による破壊的変更の影響を抑えつつ、変更容易性を確保できるようになりました。
LLM の生成誤りを排除する 『守り』 の開発
後半の「守りの開発」では、AIエージェントが意図しない挙動を防ぐための防御システムについてお話しします。実際「守りの開発」は「攻めの開発」以上に多くの時間をかけてきました。
守-1. AIエージェントから実行権限を剥奪する条件
AIエージェントは環境に自ら作用できる分、推論や行動が発生する各ポイントでは、その内容をモニタリングできるようにする必要があります。
リクルタAIでは 設計段階からログレベルや対応方針などについて事前定義 しており、ログ設計書やリスク管理表として記述しています。意図しない挙動が生じた場合、アラートを発動させるようにして AIエージェントから実行権限を一時的に剥奪し、エンジニアがデバッグ対応します。
守-2. 予測される行動範囲をガードレールで囲い込む
AIエージェントの思考・行動範囲は、ヒトが「指示可能」「予測可能」な範囲に限定されるべき だと思います。すなわち意図しない方向に進んでいる場合はそれを「観測可能」にする必要があります。
リクルタAI では、意図しない方向に進んでいないかをチェックするため、ゲートキーパー層・ナレッジアンカー層におけるガードレールを特に慎重に作り込んでいます。具体的には、静的なプロパティチェックに加え、LLM-as-a-judge によるソフトな判定などのチェック機構を設けています。
LLM を用いたガードレールでは、望ましい文章を生成しているかどうかを複数の観点から審査することが重要になります。すべての審査を通過した生成内容のみを最終出力とする ことで、チェック漏れを極力なくし、より安心して利用できるコンテンツをユーザに提示します。
守-3. 信頼のおける審査員を採用する
たとえば RAG の評価でよく使用される Ragas では、正解判定に LLM を審査員として採用していますが、プロンプト をよく見てみると、すごく単純で正解の判定記述がモデルに依存しやすくなっていることが分かります。
# https://github.com/explodinggradients/ragas/blob/main/src/ragas/prompt/pydantic_prompt.py#L72-L86
f"{self.instruction}\n"
+ self._generate_output_signature()
+ "\n"
+ self._generate_examples()
+ "\n-----------------------------\n"
+ "\nNow perform the same with the following input\n"
+ (
"input: " + data.model_dump_json(indent=4, exclude_none=True) + "\n"
if data is not None
else "Input: (None)\n"
)
+ "Output: "Given question, answer and context verify if the context was useful in arriving at the given answer. Give verdict as "1" if useful and "0" if not with json output.
→ 何をもって useful であると判断するかはモデルの解釈に依存される
Ragas による審査方法が適していない訳ではありませんが、リクルタAIが目指しているのはモデル性能に依存した審査ではありません。
信頼できる LLM-as-a-judge を行うためにはバラツキのない審査員の採用 が必要です。審査員に与える指示は、一意に解釈される内容にするべきです。
そこで審査員の判定におけるバラツキを測定するための評価セットを一から手作業でアノテーションして構築することにしました。
ここでは能動学習におけるサンプリングのような設定で、実際のデータ分布を考慮しつつ、多様性・不確実性を確保しながら慎重に作成しました。
審査員を含む LLM の性能改善では、データ・モデル・評価の3点が重要となります。なかでも「評価」は後回しにされがちですが、個人的には モデルの予測誤りを正しく修正できるか が特に重要になると思います。
評価セットのアノテーションはいくら慎重に行ったとしても、その日の体調にすら左右されてしまいます。そのため審査員が誤った解答にはすべて目を通し、正しく誤り訂正できるよう心がけました。
守-4. 評価がうまくいっても実環境で正常稼働するとは限らない
評価セットで高い性能が示されたとしても、実環境で正常に動作するとは限りません。というのも、評価セットは入力文のすべてのスタイルを網羅しているわけではないためです。
リクルタAIでは少しでもバグを減らせるように、審査員である LLM に対して動作検証を実施してバグ要素を洗い出し ています。
具体的には入力文に対して、実際の運用環境で想定されうる摂動を加えた場合に、審査員からの出力が期待されるものとなるかチェックしています。
もちろん評価や動作検証を行っただけでは完全に信頼できる防御システムをつくったとは言い切れません。開発チームでは Outer Loop による改善サイクルを回しながら継続的に性能改善を行っていくつもりです。
おわりに
本記事ではリクルタAIの開発の裏側についてお話しました！
リクルタAIの問い合わせは、以下のページより受け付けております。興味を持った方がいましたらぜひお問い合わせください！
生成AI領域にしぼった転職エージェントを始動しました
Algomatic グループでは、生成AI領域への転職を考えている方と並走してキャリア相談や転職相談をおこなう転職エージェントサービス『.AI CAREER』を展開しています。
転職を考えている方、AI人材を募集している企業の皆様、ぜひこちらからご確認ください 🙏
全方位積極採用中です 🙌
Algomatic では、逆境も熱狂に変えられる方を積極採用しています！技術やヒトに誠意ある情熱を注げる方、ぜひ一緒に事業を大きくしていきましょう！
