案件と要員のマッチングを、AIではなくルールで判定している理由

Qasica のマッチングは 40 本のルールで動いています。 情報を読み取る部分には LLM を使っていますが、どの要員を提案するかの判定はルールです。 学習型も実装して比較したうえで、この形にしています。

なぜルールベースなのか

1. 理由が言えるから

営業が提案するとき、「なぜこの人なのか」を相手に説明する必要があります。 ルールなら「商流が合う・必須スキルを満たす・単価が予算内」と分解して言えます。 スコアだけが出る仕組みでは、提案の根拠になりません。

2. 間違ったときに直せるから

合わない候補が出たとき、ルールならどの条件が緩いのかを特定して直せます。 学習型は再学習が必要で、直したつもりが別のところで崩れることがあります。

3. 正解データが足りないから

学習には「この提案は正しかった」という記録が要ります。 実際の成約結果は記録されている件数が少なく、学習に使える正例がほぼありません。データが無いところで学習型を使うと、それらしいだけの結果が出ます。

足切りと加点を分ける

マッチングは 2 段階です。ここを混ぜると使えない候補が上位に来ます。

1. 足切り — 条件を満たさない組み合わせを除く。満たすか満たさないかの判定
2. 加点 — 残った候補を、合致度の高い順に並べる

スコアだけで並べると、商流が合わない要員が「スキルが完璧だから」という理由で 1 位に来ます。それは提案できないので、先に除く必要があります。

足切りに使う条件

商流・リモート比率の数字は Qasica 集計（2026年9月時点）。詳細は商流とは とリモート比率 に書いています。

加点の考え方

足切りを通った候補を、次のような観点で並べます。

• 必須スキルの合致数 — 何個満たしているか
• 歓迎スキルの合致 — 満たさなくてよいが、あると強い
• 担当できる工程の重なり — 上流から入れるか
• 役割の一致 — PM を求める案件に PG を出しても通らない
• 業務領域の一致 — 開発 / インフラ / テスト / サポート / PM・PMO などの大分類
• 経験年数 — 要求年数に対する余裕
• 情報の新しさ — 古い要員情報は稼働状況が変わっている可能性が高い

加点は減点に使いません。「AI 関連のスキルを持っている」は加点しますが、持っていないことを減点はしません。 減点にすると、その軸を持たない候補が理由もなく沈みます。

学習型を試した結果

ルールベースが最初から答えだったわけではありません。 学習型のランキング（LambdaMART / CatBoost）を実装し、 専門家の評価で比較しました。

同一案件・同一評価者の条件では、学習型は指標上わずかに上回ることがありました。 しかし明らかに無関係な候補を母集団に混ぜると、学習型は判定が崩れました。 ルールベースは同じ条件でも安定していました。

実務では、母集団は常に雑多です。だから平均的に少し良いより崩れないほうを選びました。学習型は、不適合な候補を除いた 候補集合に限って補助的に使っています。

できないこと

• 成約するかは分かりません — 条件が合うところまでです。 成約率の目安も出していません。記録されている実績が少なく、 出せる水準の数字がないためです
• 書かれていない条件は判定できません — 契約形態は案件の 57.4% にしか書かれていません。 「記載なし」は足切りせず、確認が必要な項目として残します
• 人の相性は判定できません — 面談で決まる部分は範囲外です

よくある質問

この記事について

関連記事：メールの自動取り込みの仕組み / データの取り扱い / 商流とは

資料請求・相談はこちら