当社は、SES事業における案件情報と技術者情報の突合作業を対象に、ローカルLLMを用いた日次の自動マッチングシステムを開発いたしました。本稿では、その構成および設計上の判断についてご紹介いたします。

背景

案件情報は送付元ごとに書式が統一されておらず、必須スキルが箇条書きで整理されている場合もあれば、文章中に条件が記載されている場合もあります。技術者のスキルシートについても同様です。

これらを担当者が読み取って突合する運用では、対象件数の増加に比例して工数が増加し、条件に適合する組み合わせを見落とす可能性も高まります。当社は、この突合作業を自動化の対象と位置づけました。

ローカルLLMを選択した理由

第一に、取り扱うデータの性質によるものです。技術者の経歴および単価、取引先よりお預かりした案件情報は、いずれも社外への送信を前提としていない情報です。外部APIを利用する構成では、送信先の利用規約およびデータ保持方針を継続的に確認する必要が生じます。処理を自社設備内で完結させることにより、この論点は発生いたしません。

第二に、費用の予見可能性です。全組み合わせを日次で突合する処理では入力トークン量が大きくなり、従量課金では月額費用の見積りが困難となります。自社設備で稼働させる場合、費用は電力費が主となり、処理件数の増加に対して費用が急激に変動することはありません。

なお本処理は始業前のバッチとして実行するため、応答時間に対する制約が緩やかである点も、本構成を選択した理由の一つです。

システム構成

  • 常駐デーモン:TypeScript(Node.js、node-cron、pm2)
  • 推論基盤:Ollama、Qwen3.6:27B
  • GPU:GeForce RTX 3090(VRAM 24GB)1枚
  • LLMゲートウェイ:Nitro(Cloudflare Tunnel 経由)
  • 管理画面:Nuxt 4(Vercel)
  • データストア:PostgreSQL

メールの取込からマッチングまでを担う常駐デーモンと、結果を参照する管理画面との間に、直接のHTTP通信はありません。両者は同一のPostgreSQLを参照する構成としており、GPUを搭載した設備を外部に公開する必要がありません。

非同期ジョブ方式による長時間推論への対応

27Bのモデルを単一のGPUで稼働させた場合、1回の推論に数分を要することがあります。一方、経路上のプロキシは100秒で接続を切断いたします。同期的なリクエスト・レスポンス方式では、応答の受信前に接続が切断されることとなります。

そこで、ゲートウェイをジョブの受付と結果の取得に分離する方式へ変更いたしました。

ローカルLLM呼び出しの流れ。core から Cloudflare Tunnel 経由で Nitro のジョブキューに投入し、1.5秒間隔でポーリングして結果を取得する

ジョブの投入時には受付IDのみを返却し、以降は1.5秒間隔で完了状態を照会いたします。個々の通信が短時間で完了するため、推論に要する時間の長短にかかわらず切断は発生いたしません。

GPUは1枚のみであることから、推論の呼び出しは1本に直列化しております。あわせて、本バッチが投入するジョブには低い優先度を設定し、対話的な利用を優先する構成といたしました。

ハードフィルタとスコアリングの分離

本システムにおいて最も重視した設計上の判断です。

LLMの役割は、書式の定まっていない文章から所定の項目を抽出する処理に限定しております。案件情報からは必須スキル、経験年数、単価レンジ、稼働形態、勤務地、開始時期を、スキルシートからは同一の語彙により技術者情報を抽出いたします。

組み合わせの絞り込みは、LLMを介さない決定的な判定により実施いたします。

  • 同一の企業から送付された案件と技術者を突合しないこと
  • 希望単価が案件の上限額(許容幅5万円を含む)の範囲内であること
  • 年齢および国籍の条件を満たすこと
  • スキル分野に重複が存在すること

上記を通過した組み合わせのみをLLMに渡し、0〜100の適合スコアおよび簡潔な根拠を生成させております。全件をLLMに読み込ませて順位付けを行わせる構成を採用しなかったのは、処理量の問題に加え、順位の根拠を説明できなくなるためです。

また、判定に必要な情報が欠落している場合は、通過させる方向に判定しております。文章からの抽出は完全ではなく、情報を取得できなかったことのみを理由に候補を除外した場合の損失が大きいと判断したためです。絞り込みを緩和する代わりに、判定の内訳を保存し、管理画面上で根拠として表示する構成といたしました。

運用

早朝にバッチ処理を実行し、始業時点で候補の一覧が生成されている状態としております。最終的な提案先の判断は担当者が行い、本システムが担うのは候補の抽出および提示までです。

提案メールの下書き機能も備えておりますが、こちらはLLMを使用せず、登録済みの項目から定型により生成しております。出力が一定であるほうが確認が容易であり、費用も発生しないためです。

適用が見込まれる業務

本構成はSES事業に限定されるものではありません。書式の定まらない文書が日次で多数到着し、それらを保有するデータと突合する業務であれば、同様の考え方を適用いただけます。求人と応募者、仕入案内と在庫、問い合わせと過去の回答事例などが該当いたします。

とりわけ、取り扱うデータの機密性が高く外部サービスの利用が困難であり、かつ処理量が大きく従量課金では費用の見積りが難しい場合において、自社設備で稼働させるローカルLLMは現実的な選択肢となります。

お問い合わせ

当社では、こうしたシステムの設計、構築、および導入後の運用までを一貫してお引き受けしております。ローカルLLMの導入をご検討されている場合、または社内に閉じた形でのAI活用をご検討されている場合は、適用可否のご判断の段階からご相談を承っております。

お気軽にお問い合わせください。