マッチング精度60%→85%。「AIに全部やらせない」判断で開発期間を半分にした記録

この連載「実装ノート」は、実際のプロジェクトの記録です。解説記事ではないので、一般論は書きません。守秘義務の観点から支援先は業種カテゴリで表記し、数値は公開許可のあるもののみ記載しています。

現場で起きていたこと

支援先はAIスカウト・AIマッチング機能を持つ人材領域のSaaSを立ち上げている事業者です。求職者と求人のマッチングやスカウト文面の生成にAIを使う構想はあったものの、「どこまでAIに任せていいプロダクトなのか」の判断がつかず、開発着手前の段階で足踏みしていました。

市場調査を進めると、既存のマッチングは精度が安定せず、的外れなスカウトが候補者・企業双方の信頼を損なっている実態が見えてきました。精度を上げること自体が目的化しがちな領域ですが、精度だけを追うとブラックボックス化し、「なぜこの人にスカウトが飛んだのか」を誰も説明できないプロダクトになるリスクがありました。

最初に決めたこと ── AIに「何をやらせないか」

ここでも設計の出発点は、AIに任せる範囲ではなく任せない範囲を先に決めることでした。マッチング〜スカウトの一連の処理を、性質の違う3種類に分解しています。

• 生成AIに任せる：職務要件や候補者プロフィールといった自然文からの特徴抽出、候補者ごとに合わせたスカウト文面のドラフト生成。「読んで、書く」仕事
• 決定的なコードに任せる：必須要件（資格・稼働条件など）による除外条件の判定、スコアリングの根幹ロジックとその再現性の担保。「基準どおりに、必ず同じ判定をする」仕事
• 人に残す：生成AIが作ったマッチング結果・スカウト文面の最終レビュー、精度評価とチューニング方針の意思決定。マッチングの結果は候補者のキャリアと企業の採用に直結するため、最後の説明責任は人が持つ設計にした

生成AIには「候補を提案する・文章を作る」役割だけを持たせ、「誰を落とすか」を決める必須要件の判定はルールベースの外に出さない。これが、このプロダクトの骨格です。

作ったもの

市場調査・競合分析からプロダクトのコアバリューとMVPスコープを定義し、要件定義書・画面仕様を整備したうえで、LLM APIを組み込んだ機能のスクラッチ実装まで一気通貫で担当しました。「作るものを決める」フェーズと実装フェーズを同一人物が担当したため、要件の引き継ぎロスが発生せず、当初6ヶ月を見込んでいた開発を3ヶ月に短縮してβ版をリリースしています。

処理の流れとしては、一般的なマッチングシステムと同様、求人票・求職者情報の入力からスカウト文面の生成までを一本のパイプラインで処理する構成です。どこにルールベースを置き、どこに生成AIを置いたかを図にするとこうなります。

ポイントは3〜5の並びです。必須要件による除外（3）は生成AIを経由させずルールベースで先に絞り込み、そのうえで生成AIにスコアリングの補助をさせ（4）、最後にもう一度ルールベースの補正とプロンプトのチューニングでスコアを安定させています（5）。生成AIを「間に挟む」形にすることで、暴走しても両側のルールベースが受け止められる構成にしました。

補足すると、これはAIチャットに毎回指示を打ち込んで文面を作ったり候補者を探したりする使い方ではありません。求人票・求職者情報が入力された時点で、STEP2〜5はシステムの中で自動的に処理され、人が手を動かすのはSTEP6のレビューだけです。生成AIの呼び出しはAPI経由で業務フローの中に組み込まれていて、担当者が都度プロンプトを考えて打つ工程は存在しません。

つまずいた場所

順調だったわけではありません。記録に残っている範囲で、判断を変えた箇所を書きます。

マッチ度判定の結果が、同じような条件の候補者でも安定しませんでした。判定材料の一つに求職者ヒアリング結果を使っていたのですが、これが担当者ごとに書き方の異なる自由記述のメモ、つまり非構造化データのままモデルに渡っていたことが大きな原因でした。同じ内容でも書き方が違うだけで特徴の抽出のされ方が変わり、スコアがぶれます。

そこで、ヒアリング結果を項目ごとに整理した構造化データへ加工する前処理を挟みました。そのうえで、スコアリングのロジック自体はルールベースの補正を効かせつつ、生成AIに渡すプロンプトの側もチューニングを重ねる、という両面からの調整で、ようやくブレを最小限に抑えられています。マッチング精度が60%から85%まで上がったのは、この「入力データを整える」地味な作業を挟んだことが大きいというのが実感です。

数字

• 開発期間：当初想定6ヶ月 → 実際3ヶ月でβ版リリース（市場調査から実装まで一人で担当）
• マッチング精度：60% → 85%に改善
• 事業成果：初年度で半期売上1,000万円規模
• 担当範囲：市場調査・戦略策定・要件定義・スクラッチ実装（プロダクトリード／開発ディレクション）

この案件から言えること

候補者を探してスカウト文面を作るだけなら、AIチャットに都度指示を出しても今すぐできます。ただそれは「AIを使った」で終わり、案件が来るたびに人がAIを操作する手間が残ります。この案件の価値は、そこではありません。AIの呼び出しを業務フローそのものに組み込み、人が意識して操作しなくても日々の処理としてシームレスに回る仕組みにしたことにあります。マッチング精度の60%→85%も、その仕組みの中で初めて意味を持つ数字です。

「AIマッチング」と聞くと、精度を上げること自体がゴールに見えますが、実際に運用に乗せて説明責任を持てる仕組みにするには、何を生成AIに預け、何を基準として外に出さないかを先に決める必要があります。精度は、その設計の上で初めて安全に上げられるものでした。

もう一つ、この案件で学んだのは「AIに何を任せるか」以前に、AIに渡すデータの形が精度を左右するということです。過去の非構造化データをそのまま流用せず、構造化する一手間を挟めるかどうかで、同じモデル・同じプロンプトでも結果が変わります。

この構造はマッチング・スカウトに限りません。「都度AIに指示を出す」段階で止めるか、「業務フローに組み込んでシームレスに使える」段階まで持っていくか。誰が見ても同じ基準で動くルールを挟めるか、入力データを整える一手間を惜しまないか。この3つが、AIプロダクトを安心して育てられるかどうかの分かれ目になります。

関連：プロダクト開発（MVP）（サービス詳細） ／ 実績・支援事例