同じ候補者を5人に見せると、5通りの結論が返る
人物評価には、評価者の経験・直感・好みが強く影響します。面接官が違えば候補者の見え方も変わり、組織として一貫した判断軸を持つことは簡単ではありません。
採用判断のばらつきを、組織として説明できる形に変えたい。
あるスタートアップの創業者からこのようなご相談を受け、LLM（大規模言語モデル）で人物評価を行う SaaS の立ち上げに、CTO 代行・PdM として企画段階から伴走しました。
個人情報を扱う以上、避けて通れない問い
LLM で人物評価を行えば、入力には候補者の個人情報がほぼ必ず含まれます。そのため議論は、技術選定よりも先に、契約と法務から始まりました。
論点は、大きく3つに分かれます。
- データを漏らさないこと：保管・通信・アクセスをどう守るかという、情報セキュリティの基本
- AI の学習に使ってよいかどうか：候補者から預かった情報を AI モデルの学習材料として使ってよいかという、契約と倫理の判断
- 顧客企業同士のデータが混ざらないこと：複数の顧客企業が1つのサービスを共有するうえで、設計に欠かせない条件
2つ目の「AI の学習に使ってよいか」は、技術だけでは決められません。顧客企業や案件によって方針が分かれるため、案件ごとに切り替えられる設計を要件としました。
設計の自由度は、最初の段階で大きく狭まりました。限られた選択肢の中で何を選ぶかが、この後のコストを左右します。
安全とコストを、設計で両立させる
ここからは設計の話ですが、技術の細部には立ち入らず、どちらの方向を選んだかに絞って説明します。
顧客企業同士のデータが混ざらない構成には、大きく2つの作り方があります。
- A：顧客企業ごとに、システムを丸ごと分ける — 最も安全に見える反面、運用コストが顧客企業の数に比例して膨らみます
- B：1つのシステムを共有し、顧客企業同士のデータが混ざらない仕組みを設計に組み込む — A と同等の安全性を保ちながら、コストは企業数が増えてもほぼ一定です
Kmetric は B を選びました。
顧客企業同士のデータが混ざらない仕組みを、共通基盤に組み込む
B のように1つのシステム（共通基盤）を共有すると、すべての顧客企業のデータ・権限・操作の記録が同じ場所に置かれ、入り混じるおそれがあります。そこで、システム自身が「誰が・どの顧客企業の・どのデータに触れたのか」を常に把握している状態を、設計の前提にしました。
追跡できないアクセス経路を1本も残さないことを徹底しました。その結果、共通基盤の上で運用しても、顧客企業のあいだで情報が混ざる余地はなくなりました。
共通基盤に集約したことで、顧客企業の数が増えてもインフラの規模はほぼ一定に収まっています。これが、後の60%圧縮の大きな要因になりました。
AI を、案件と評価軸ごとに使い分ける
評価に使う AI モデルを案件ごとに差し替えられるようにし、1つの案件の中でも評価軸ごとに選べる形にしました。
判断の難しい評価軸には精度の高い AI、定型的な確認で済む評価軸には速くて安価な AI を使う、という使い分けです。
AI は世代交代が早い領域です。新しいモデルが出るたびに案件単位で乗り換えられるようにしておけば、サービス全体を作り直さずに、性能とコストを見直し続けられます。
評価軸ごとに AI を選び分け、ランニングコストを細かく抑えられることが、運用フェーズで大きな差になります。精度の高い AI を使う評価軸を1つ減らすだけでも、月々の AI 費用は目に見えて変わります。
2ヶ月で本番リリース、運用コストを初期見積もりから60%圧縮
ここまでの判断の成果は、2つの数字に表れました。
- 2ヶ月で本番リリース
- 運用コストを初期見積もりから60%圧縮
圧縮を支えたのは特殊な最適化技術ではなく、最初の設計判断でした。2ヶ月という速度は、立ち上げと運用を一人が担う体制によるものです。
60%は、設計段階の2つの選択から生まれた
圧縮につながった判断は、次の2つです。
- 最もコストのかさむ「企業ごとに分ける」設計を最初に避け、共通基盤に集約しました。そのため、顧客企業が増えてもインフラは膨らみませんでした。
- AI モデルを案件ごと・評価軸ごとに使い分けられるようにしたことで、精度とコストのバランスを細かく調整できました。
どちらも個別に見れば派手な工夫ではありません。両方が組み合わさってはじめて、初期見積もりとの差が大きく開きました。設計上の選択が、運用フェーズの数字に直結した案件です。
2ヶ月での本番リリースを支えたのは、判断の速さだった
LLM で個人情報を扱う案件は、契約・法務・セキュリティのレビューに時間がかかりがちです。それでも2ヶ月で本番に乗せられたのは、CTO 代行・PdM として、立ち上げと運用の両方を一人で担ったからです。
担当した範囲は、次の通りです。
- 開発体制の編成と進行管理
- マーケティング戦略・マネタイズ設計（広告出稿を含む）
- 共通基盤の権限設計と、顧客企業へのアカウント発行の責任
判断のたびに承認を待つ必要がない体制にしたため、要件・仕様・設計・運用の方針をその場で確定できました。言い換えれば、どこを節約し、どこに投資するかを、経営判断と一体で決められたということです。
役割を分けて引き継ぎを重ねていれば、2ヶ月での本番リリースも、60%の圧縮も難しかったはずです。
立ち上げから運用までを一人に任せ、技術判断を経営判断と切り離さない。
