最終更新日：2026年8月13日
プロジェクト概要
自社のIT人材紹介・案件仲介事業において、日々大量に届く案件・人材情報メールの自動分類と、登録人材と案件データベースとを結びつける自動マッチングの仕組みを、生成AIを組み込んだ自社システムとして構築・運用しています。メールの受信から分類、マッチング候補の生成、対象者へのメール配信までを一気通貫で自動化するバッチ処理基盤として設計しました。
課題
従来、案件・人材情報の分類や、登録人材と案件のマッチングは担当者の経験や知識に依存した手作業で行われており、処理時間のばらつきやマッチング品質の不均一さ、担当者への業務集中が課題となっていました。また、案件数・登録人材数の増加に伴い、人手だけで最適なマッチングを継続的に提案し続けることが難しくなっていました。加えて、分類処理を外部AIプラットフォーム経由で行っていた部分は、処理件数の増加とともにコスト・レスポンス制御の面で改善余地があり、自社の運用に合わせた形への見直しも必要でした。
技術的アプローチ
システムは大きく「分類パイプライン」と「マッチングパイプライン」の2つで構成されています。
分類パイプラインでは、受信した案件・人材メールを5分間隔のバッチ処理で順次取り込み、あらかじめ設計した判定基準（エリア、商流、想定単価、面談回数、必須要件など）に基づくプロンプトをもとに生成AIへ問い合わせ、地域情報・商流情報・単価・総合評価といった項目を構造化データとして抽出しています。都道府県情報から地方エリアへの変換など、AIの出力を業務で使いやすい形に整える後処理ロジックも実装しました。このパイプラインは当初、外部AIプラットフォーム経由でLLMを呼び出す構成でしたが、処理件数の増加を踏まえてコストとレスポンス品質を見直し、オープンソース系の大規模言語モデルをAPI経由で直接呼び出す構成に切り替えました。プロンプト設計やDB更新ロジックは変更せず、外部プラットフォームへの依存部分のみを置き換える形で移行しています。
マッチングパイプラインでは、平日早朝に自動起動するバッチ処理の中で、登録人材のプロフィール情報からマッチング用プロンプトを生成し、生成AI（RAGベースのマッチングエンジン）に問い合わせて案件候補を導出しています。同じ人材に同じような案件を繰り返し提案しないよう、直近一定期間内にすでに提案済みの案件を除外条件としてプロンプトに動的に追加する仕組みを組み込みました。マッチング結果はデータベースに保存したうえで、ID単位の分割処理、対象ユーザーへのメール自動送信、提案内容のスコアリングまで、複数のバッチ処理を連携させた一連のパイプラインとして構築しています。
信頼性の面では、AI応答をストリーミング形式で受信・組み立てる処理、タイムアウトやレート制限発生時の段階的なリトライ制御、データベース接続の死活監視と自動再接続、同一データを重複処理しないためのプロセスロックや処理間隔・クールダウン制御など、大量データを継続的かつ安定的に処理するための実装を随所に組み込んでいます。
- インフラ：Amazon EC2上で稼働するPHPバッチ・cron基盤
- 分類AI：オープンソース系の大規模言語モデル（API経由で直接呼び出し）
- マッチングAI：RAG（検索拡張生成）ベースのマッチングエンジン
- 信頼性設計：ストリーミング応答処理、リトライ制御、プロセスロック、重複提案の除外ロジック
成果
案件・人材情報の分類作業を自動化したことで、担当者は例外対応や最終確認・調整業務に集中できる体制を実現しました。5分間隔での継続処理により、日々発生する大量のメールデータを滞留させずに捌ける仕組みを構築し、マッチング処理についても重複提案を避ける設計により、ユーザー体験に配慮しながら効率的な案件紹介を継続できる基盤を整えました。また、外部プラットフォームへの依存度を見直したことで、処理コストの最適化と運用の安定性向上を両立しています。
まとめ
- 案件・人材メールの自動分類と、登録人材と案件の自動マッチングを、生成AIを組み込んだ自社システムとして構築・運用しています。
- 分類処理は5分間隔、マッチング処理は平日早朝のバッチという形で、継続的かつ安定的に大量データを処理する構成としています。
- 直近の提案履歴を踏まえた重複回避ロジックにより、マッチング品質とユーザー体験の両立を図っています。
- リトライ制御・接続監視・多重起動防止など、大量データを扱う本番バッチとしての信頼性を担保する実装を組み込んでいます。
- 処理件数の増加に応じて、外部AIプラットフォーム依存部分をより運用に適した構成へ継続的に見直しています。
▼ アクロビジョンについて