経験・行動面接

例えば次のように話します（架空の例）。「解約の予測モデルで AUC は高かったのに、クーポンを送る A/B テストでは解約率に差が出ませんでした。予測のログと結果を突き合わせると、上位の人は何をしても解約する人が多く、クーポンでは止められないと分かりました。」

「そこで、予測する対象を『解約するか』から『クーポンで解約が減るか』に変え、過去のランダムな配布のデータで学習し直しました。再度のテストでは同じ配布数で解約率が下がりました。」のように、原因をどう切り分けたか（リーク・学習と推論のずれ・指標と目的のずれを順に確かめた）を具体的に話し、最後に「施策に使うモデルは効果で評価する」と仕組みにした学びで締めます。

例えば（架空の例）、PdM は「クリック率が上がったので全員に出したい」、私は「購入率が下がっている」と意見が分かれたことがあります。まず相手の目的を確かめると、PdM の目標は回遊の増加でした。そこで、主な指標を何にするかを、売上につながる購入率に置き、クリック率は補助の指標にする案を、過去のテストの数字を見せながら提案しました。

結果として、購入率を落とさずにクリック率を上げる改良版を作ってもう一度テストすることで合意しました。ポイントは、どちらが正しいかを争うのではなく、事前に決める指標とガードレールをそろえる場を作ったことです。以後、テストの前に1枚の計画書で合意する手順をチームに入れました。

例えば（架空の例）、問い合わせの振り分けを ML で自動化したいという相談を受けたとき、まず今の振り分けを分析しました。全体の8割が、件名にある10個ほどのキーワードで正しく振り分けられると分かり、ラベル付きのデータもほとんどありませんでした。

そこで、まずルールで8割を自動化し、残りを人が振り分ける形を提案しました。ML を入れる場合の、ラベル付け・学習・監視の手間と、増える精度の見込みを比べた結果です。ルールで出したあと、人が振り分けた結果がラベルとして溜まったので、半年後に残りの2割に ML を使う判断をしました。ML ありきではなく、基準のやり方と費用対効果で決めたことを伝えます。

例えば（架空の例）、問い合わせの分類に、LLM の API を使うか、自分たちで小さなモデルを学習するかで迷いました。比較の軸を、精度・1件あたりの費用・レイテンシ・データを外部に出せるか・運用の手間、と先に決め、同じ評価データで両方を小さく試しました。

結果は、精度は API がやや上、費用は月の件数では自前のモデルが1桁安く、レイテンシも自前が速い、でした。そこで、件数の多い分類は API の出力を教師にして小さなモデルを学習し（蒸留）、迷うものだけ API に回す形にしました。決めた理由と比べた数字は設計の記録に残し、件数や価格が変わったら見直す条件も書きました。

応募先の事業とデータに具体的に触れ、自分の経験がどこで効くかをつなげて答えます。例えば（架空の例）、「御社の物流のサービスは、配送の記録という大量で質の高いデータがあり、需要予測や到着時間の予測が事業の費用に直結していると記事で知りました。私はこれまで需要予測のモデルを作り、本番の運用と監視まで担当してきたので、その経験を活かせると考えています。」

続けて、「今の職場では分析の試作で終わることが多く、モデルを本番で改善し続けるところまで担当したい、というのが転職の理由です」のように、退職理由と志望動機を1本の線にします。最後に、入社後に最初に取り組みたいこと（例：予測の監視の仕組みづくり）を一言添えると、具体的に考えていることが伝わります。