人材発掘のための新機能「COMPANY Bizmatch」
大手法人向け統合人事システム「COMPANY」シリーズは、給与計算や勤怠管理はもちろん、雇用手続管理、ID管理、タレントマネジメントなど従業員の入社から退職まで、あらゆる人事労務を網羅している。約1,200法人グループで採用されており、管理している人事データは約540万（※1）人以上。大手法人（※2）の約3社に1社（WHI調べ）が採用しているほど、人事管理の老舗かつ定番となるシステムだ。
※1 2024年12月末時点
※2 従業員数3,000人以上の法人
「COMPANY」は1996年の誕生以来、業務の効率化から人事戦略を実現するための機能やサービスを拡大し続けている。2025年7月末より、「COMPANY Talent Management」シリーズに生成AIを用いた人材発掘・マッチング機能「COMPANY Bizmatch」が新たに加わった。
例えば「海外事業のプロジェクトリーダー候補になる成長志向の強い人」「海外のカスタマーサポート担当で、英語が堪能、プログラミングのスキルがある人」など、ざっくりとしたイメージを自然言語で検索でき、検索対象を絞ることも可能だ。検索結果一覧では、マッチした理由も添えて出力する。
新機能開発では、最初にプレーンなHTMLベースのプロトタイプ、後にベータ版、リリース版へと段階を経て改善を加えていった。実際のデータで検証していく段階になると検索精度が課題となり、改善を重ねた。続いてベータ版ではデータ不足への対応、コスト可視化に取り組んだ。順を追って詳しくみていこう。
検索精度を改善するための課題に対応
「COMPANY Bizmatch」では、生成AIを2つの方向性で利用している。1つはあらかじめ登録されている従業員データ（資格、免許、業務経験、研修受講歴、評価結果、キャリアプラン申告など）から、従業員それぞれの特徴をとらえた要約文を生成する。もう1つは検索文と、各社員の要約文とのマッチ度を判断し、判断理由となる文章も生成する。
当初のアーキテクチャは下図の通り。ユーザーからのリクエスト（左上）に対して、既存のタレントマネジメントステップの背後に追加された生成AI機能のアーキテクチャがある。
左側（Step Functions summarizer）が要約文作成だ。従業員データを取得し、LLMで要約文を作成し、作成した要約文をベクトルに変換してデータベースに保存する。右側が検索ロジックだ。検索文をベクトル変換し、データベースに対してベクトル検索を実施して1,000人程度に絞り、個別にマッチ度を判定。そして、マッチ理由をLLMで作成する。なお使用しているモデルはAmazon BedrockでのClaudeやCohereのエンベッドモデルとなる。
このアーキテクチャでベータ版までたどり着いたものの、実際のデータで使用してみると検索精度で課題に直面した。原因はいくつかあり、それぞれ対応することで改善していった。
1点目は数字の扱い。生成AIは数字の扱いが得意ではないため、「30代」のようなキーワードで検索しようとすると精度が低い。そこで数字で検索する時は生成AIやベクトル検索は使わず、従来のルールベースを使用する。
2点目は要約文を作成する段階で失われる情報があること。そこで経歴など要約しないカテゴリ（項目）を作成し、そのまま生成AIに渡す。
3点目は真逆の意味も引っかかってしまうこと。例えば「情報セキュリティに強い人」を検索しようとすると、ベクトル検索では「情報セキュリティに強い人」だけではなく「情報セキュリティに弱い人」も引っかかってしまうことがあった。そこで強みのベクトルだけ集めたカラムを作るなど、ベクトルを作る単位を変えた。
4点目は意図をうまく解釈できないこと。例えば「英語が得意な人」を検索したい場合、具体的にはTOEIC 700点以上の社員を拾いたいケースを想定する。しかし、ベクトル検索やLLMリランキングで該当者を絞り込んでいく段階で高い精度が出せず、該当者がこぼれ落ちてしまっていた。当初はベクトルを作る時の文章を短くする（チャンキング）とか、クエリ拡張やハイブリッド検索などを試したものの、「ベクトル検索に期待しすぎたところがありました」と吉田氏は言う。最終的にはベクトル検索（RAG）をやめて、すべてLLMで処理することに変えた。
検索精度を改善したら、次にコストと安定化の課題が浮上
検索精度は改善されたものの、生成AIへのリクエストが増えることにより、コストと安定化という新たな課題が生じた。
コストは比較した結果、当時（2025年1月）最安のGemini 1.5 Flashを選択した。状況が刻々と変わるので時期により他モデルが最適になる可能性もある。比較したのは提供元、価格、精度、同時実行数、加えて顧客のデータを使うためデータをモデル学習のために利用されるかどうかなどだ。
安定化は、生成AIモデルの呼び出しのクオーターを超えないようにコントロールするような対策を施した。大量の検索が同時発生すると処理があふれてしまうため、まずはキューイングして非同期処理したのと、（クオーターとなる）1分間に1,000件を効率的に扱えるように並列処理を組んだ。またエラーが生じた場合でもリトライできるようにした。
改善後のアーキテクチャは、検索実行部分がStep Functionsとして増えて、呼び出しているモデルがVertex AI Geminiとなっている。
吉田氏は「検索精度はある程度自信が持てる状態になりました。RAG（ベクトル検索）は高速に動作するので非常に便利ですが、要件次第で使うかどうかは判断が必要です」と指摘する。
いいAI機能でもデータがなければうまく動かない
いざ実務で使おうとすると、今度は検索したいデータがそもそも登録されていない問題に遭遇した。例えば本人の志向や希望も加味して検索したいが、「異動OK」のフラグはあっても、具体的に何をしたいかの情報がない。あるいは実務経験に応じて検索したいが、大まかな仕事内容しか分からず細かいタスクレベルの情報がない。
データを増やすための解決策の1つとして、従業員が自らデータを登録したくなるような機能を開発することにした。従業員それぞれのための「マイページ」にて過去の経験や今後の希望についての入力をうながす機能だ。入力した内容に応じて、AIがマッチする学習コンテンツを提示。目標となるロールモデルを登録していれば「こういうスキルをつけるといい。こういう経験を積むとよい」と提案してくれる。情報を登録することで従業員は有益な情報を受け取ることができるため、入力を促せる。もともと従業員の情報収集に苦労している企業は多いため、この機能はお客さまからも好評だった。
入力された情報に対するサジェストにも生成AIを使用している。ロールモデルに関するサジェストでは、対象の従業員の要約とロールモデルに指定された従業員の要約を取得し、Geminiに与えてどのようなスキルをつけたほうがいいかを生成させる。
吉田氏は「よいAI機能を作っても、データがなければうまく動きません。データを集めるための工夫はAI機能を作る上では必須です」と強調する。
AIコスト可視化はクラウドベンダーが用意している機能を活用
お客さまの利用が増えてくると、クラウド費用のなかで生成AIコストが占める割合が増えてきた。「COMPANY Talent Management」シリーズはマルチテナント構成なので全体でかかるコストしか分からなかったが、ビジネス側からの「テナントごとの生成AIコストを知りたい」という要求に対応する必要が出てきた。
この問題の対処は比較的シンプルに解決できる。AWSならAmazon Bedrockのアプリケーション推論プロファイルを使う。テナントごとのコスト配分タグを追加すると、マネジメントコンソールでテナントIDごとにかかったコストを表示できる。Googleも似たような形で、ラベルを使うことでテナントごとのコスト配分タグを追加すると、コンソールでコストを表示できる。
最後に吉田氏は、「生成AIをとりまく環境は日々進化しています。特にモデル選定の部分は状況が変化していて、現時点ではベストな選択は別にあるかもしれませんが、あくまで事例として参考になれば幸いです」と述べ、セッションを締めくくった。
