ホーム / ML / 第6部面接の実践

第6部面接の実践・第13章

ML システム設計・実技の面接

★★★ 必須10トピック・面接 6問

まとめクイズ面接ではこう聞かれる（6問）

ML システム設計の面接は「正しいモデルを当てる試験」ではない。要件をそろえ、指標とラベルを決め、本番で動いて劣化に気づけるところまで、理由を説明しながら一通り設計できるかが見られる。

13.1ML システム設計の進め方（答え方の型）

用語★★★ 必須

ひとことで

「おすすめ機能を設計して」に、目的・指標・データ・モデル・推論・評価・監視の順で答える。

ML システム設計の面接では、「EC サイトのおすすめ機能を設計してください」のような広いお題が出ます。いきなりモデルの名前を答えるのではなく、目的から順に、全体を一通り設計できるかと、各所での判断の理由が見られます。

ML システム設計の答え方の型

答え方の型：

順番	話すこと（おすすめの例）
1. 目的と要件	何を増やしたいか（購入・視聴時間）。利用者数・商品数・レイテンシの目標（例：200ms 以内）。まず質問して前提をそろえる
2. 指標	オンラインの指標（購入率・売上）とオフラインの指標（Recall@K・NDCG）、ガードレール指標
3. データとラベル	クリック・購入の記録をラベルにする。表示されたのに選ばれなかったものを負例に。表示の偏りに注意
4. 特徴量	ユーザー（過去の行動）・商品（カテゴリ・人気）・文脈（時間・端末）。リアルタイムの特徴量が要るか
5. モデル	2段構え：候補の生成（埋め込みの近さで数百件に絞る）→ 並べ替え（勾配ブースティングやニューラルネット）。まずは人気順のベースライン
6. 推論	候補はバッチ、並べ替えはオンライン。キャッシュ・代わりの答え
7. 評価	オフラインで比べてから A/B テスト
8. 監視と改善	ドリフト・予測の分布・再学習の間隔・新しい商品や新しいユーザー（コールドスタート）への対応

時間（45分の例）	すること
〜5分	目的・要件・規模を質問してそろえる
〜10分	指標（オンライン・オフライン・ガードレール）を決める
〜25分	データ・特徴量・モデル・推論の全体図を一通り
〜40分	面接官が興味を持った所を深掘り
残り	監視・改善・リスク（バイアス・費用）

コツ：最初の数分で質問して前提をそろえ、全体の図を一通り描いてから、面接官が興味を持った部分を深く掘ります。各所で「A と B があり、今回は〇〇なので A にします」と選んだ理由を言うと評価されます。バイアスやプライバシー、費用にも一言触れると、本番を考えていることが伝わります。

普通のシステム設計面接の進め方は SRE の解説で

面接ではこう答える

ML システム設計の面接では、いきなりモデルの名前を答えず、目的と要件、指標、データとラベル、特徴量、モデル、推論、評価、監視と改善、の順に全体を一通り設計します。最初の数分で質問して前提をそろえ、全体の図を描いてから、面接官が興味を持った部分を深く掘ります。各所で「A と B があり、今回は〇〇なので A にします」と選んだ理由を言い、最後に監視やバイアス、費用にも触れます。

MLとの関わりML エンジニアの面接で最も差がつく形式で、実務の設計レビューの進め方とも同じです。

13.2要件確認で聞くこと

★★★ 必須

分類	質問の例
目的	何を増やしたい・減らしたいか（購入・視聴時間・不正の損失）。今はどう解いているか
規模	利用者数・対象（商品・文書）の数・1日の予測の回数・ピーク
レイテンシ	何ミリ秒以内に返す必要があるか。事前に計算してよいか
正解	何をラベルにできるか。正解が分かるまでどれくらいかかるか
誤りのコスト	見逃しと誤検知のどちらが重いか。人の確認は入るか
鮮度	新しい商品・新しい利用者・最近の行動をどれだけ早く反映すべきか
制約	個人情報・説明が必要か・予算・既存のデータ基盤

全部を聞く必要はありません。設計を大きく変える質問（規模・レイテンシ・誤りのコスト）を先に聞き、答えがなければ「〜と仮定します」と口に出して進めます。

13.3見積もりで使う数字

★★★ 必須

項目	目安・計算
1日の秒数	約 86,400 秒（概算では 10万秒）
1日 1億回の予測	平均約 1,200 QPS。ピークは平均の 2〜5 倍で見積もる
埋め込みのメモリ	件数 × 次元 × 4 バイト（32ビット）。1億件 × 768次元 ≈ 約 300GB → 量子化や分割を考える
候補のキャッシュ	1,000万人 × 候補 100件 × ID 8 バイト ≈ 約 8GB
特徴量の取得	KVS から 1〜数 ms。1リクエストで何十回も取ると積み上がる
LLM の重み	16ビットで 1パラメーター約 2 バイト（7B で約 14GB）
ラベル	陽性 0.1% で 1日 100万件なら、陽性は1日約 1,000件

見積もりは桁が合えば十分です。数字そのものより、「だから全件をメモリに載せられない」「だから候補を絞ってから並べ替える」のように設計の判断につなげることが評価されます。

13.4よく出るお題と要点

★★★ 必須

お題	押さえる要点
商品・動画の推薦	候補の生成と並べ替えの2段・表示の偏り・コールドスタート・多様性
検索の並べ替え	クエリと文書の特徴量・クリックの位置の偏り・NDCG・レイテンシ
広告のクリック予測	確率の正確さ（キャリブレーション）・大量の ID の特徴量・入札との関係
不正検知	不均衡・遅れて届く正解・ドリフト・判定の段階分け・フィードバックループ
需要予測	時系列の分け方・階層（店×商品）・欠品で見えない需要・予測の幅
有害な投稿の検出	人の確認との組み合わせ・言語や画像・攻撃者の適応・誤検知の救済
社内文書の質問応答（RAG）	権限・チャンク・ハイブリッド検索・検索と生成を分けた評価・費用
ETA（到着時間）の予測	回帰の指標・リアルタイムの特徴量（交通）・外れたときの体験

13.5回答例：EC サイトの推薦

★★★ 必須

推薦の回答例の全体図

段	話すこと（例）
目的と要件	トップページの「あなたへのおすすめ」。目的は購入。利用者 1,000万人・商品 100万件・200ms 以内と仮定
指標	オンライン：購入率・1人あたり売上。オフライン：Recall@K（候補）・NDCG（並べ替え）。ガードレール：レイテンシ・多様性
データ	閲覧・カート・購入のログ。表示されたのに選ばれなかったものを負例に。表示の位置の偏りに注意
候補の生成	協調フィルタリングや2つの塔のモデルで利用者と商品の埋め込みを作り、近い商品を数百件。人気・最近見た商品の似たものも足す
並べ替え	利用者・商品・文脈の特徴量で購入の確率を予測（GBDT から始める）
推論	候補は夜のバッチで KVS に保存。並べ替えは表示のときにオンライン。間に合わなければ人気順
コールドスタート	新しい利用者は人気・地域・最初のクリックから。新しい商品は内容（カテゴリ・説明文の埋め込み）から
評価と監視	オフラインで比べてから A/B テスト。人気の商品ばかりになるループを探索の枠で防ぐ

13.6回答例：決済の不正検知

★★★ 必須

不正検知の回答例：判定を3段に分ける

段	話すこと（例）
要件	カード決済の不正。判定は数百 ms 以内。見逃しは損失、誤検知は売上の機会損失と問い合わせ
指標	PR-AUC・上位の適合率。ビジネスでは防いだ損失額と、止めた正常な取引の数
ラベル	チャージバックや調査の結果。数週間遅れて届く
特徴量	直近の回数（5分・1時間）・普段との違い（金額・場所・時間帯）・端末・新しい配送先
モデル	GBDT から。不均衡なのでクラスの重み。ルール（明らかな不正）と組み合わせる
推論	オンライン。リアルタイムの集計はストリームで更新しオンラインのストアへ
運用	手口が変わるのでドリフトを監視し、定期的に再学習。止めた取引の一部で正解を得る仕組み

13.7回答例：社内文書の質問応答（RAG）

★★★ 必須

社内文書の RAG の回答例の全体図

段	話すこと（例）
要件	社員 5,000人・文書 10万件・毎日更新。部署ごとに見られる文書が違う。誤答の影響は中程度
指標	検索：Recall@5。生成：根拠に沿った正答率。運用：解決率・人への引き継ぎ率・1件あたりの費用
取り込み	見出しで分割・文書名と更新日を付ける・古い版を除く・差分で更新
検索	ベクトル＋キーワードのハイブリッド。権限はメタデータの条件で検索の段階で除く
生成	資料にないことは分からないと答える指示。引用元を表示。出力の形式を検証
評価	実際の質問から評価データを作り、変更のたびに自動で流す
安全・費用	プロンプトインジェクション対策・個人情報のマスク・小さいモデルへの振り分け・キャッシュ

13.8深掘りで聞かれやすい観点

★★★ 必須

観点	聞かれ方の例	答えの要点
ラベルの偏り	表示されなかった商品の扱いは？	表示の偏り・探索の枠・位置の補正
コールドスタート	新しい商品・利用者はどうする？	内容の特徴量・人気・ルールで補う
リーク	その特徴量は予測の時点で手に入る？	基準日・point-in-time の結合
学習と推論のずれ	オンラインの特徴量は学習でどう再現する？	同じ定義・推論時の値のログ
規模	件数が 100倍になったら？	候補を絞る・近似の索引・分割・バッチへ寄せる
障害	推論のサーバーが落ちたら？	代わりの答え・タイムアウト
ドリフト	半年後に精度が落ちたら？	監視・再学習・評価ゲート
公平性・リスク	特定の利用者に不利にならない？	区分ごとの評価・人の確認

13.9コーディング・実技の面接

★★★ 必須

ML エンジニアのコーディング面接は、一般的なアルゴリズムの問題に加えて、データを扱うコードがよく出ます。

出題の種類	例	こつ
アルゴリズム	配列・ハッシュ・ソート・ヒープ（上位 K 件）	計算量を口に出す。上位 K 件はヒープで O(n log K)
pandas・SQL	ユーザーごとの「その注文より前の回数」・期間の集計・結合	未来の行を含めない。groupby と shift・ウィンドウ関数
指標の実装	適合率・再現率・AUC・NDCG を自分で書く	境界（0 で割る・同点）を確かめる
簡単なモデル	ロジスティック回帰・k-means を NumPy で	式と更新の手順を説明しながら書く
ML のコードの改善	リークのある学習コードを直す	分ける前の前処理・時間の分け方を探す

def precision_recall(y_true, y_pred):
    tp = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 1)
    fp = sum(1 for t, p in zip(y_true, y_pred) if t == 0 and p == 1)
    fn = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 0)
    precision = tp / (tp + fp) if tp + fp else 0.0
    recall = tp / (tp + fn) if tp + fn else 0.0
    return precision, recall

書く前に入力と出力の例を確かめ、まず素直な解を書いてから改善します。テストの例を自分で2〜3個流して見せると評価が上がります。

13.10よくある失敗

★★★ 必須

失敗	なぜ評価が下がるか
いきなりモデルの名前から話す	目的と指標を決めずに手段を選んでいる
ベースラインを出さない	改善を測る基準がなく、ML が要るかも判断していない
オフラインの指標だけで終わる	ビジネスの指標・A/B テストとのつながりがない
ラベルの作り方を話さない	ML の設計で一番難しい所を飛ばしている
推論の速さ・費用を考えない	本番で動かない設計になっている
監視と再学習を話さない	出した後に劣化することを想定していない
一人で話し続ける	面接官のヒントや関心を拾えない

この章のまとめ

🖨 まとめシート（印刷・PDF）

目的 → 指標 → データ → 特徴量 → モデル → 推論 → 評価 → 監視の順で一通り設計する
見積もりは桁が合えば十分。数字を設計の判断につなげる
ラベルの作り方・リーク・本番での劣化まで話すと差がつく

ML システム設計の進め方（答え方の型）：「おすすめ機能を設計して」に、目的・指標・データ・モデル・推論・評価・監視の順で答える。

この章のクイズ

問題数苦手を優先

面接ではこう聞かれる

用語の説明（1問）も含める

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1EC サイトの商品ページに出す「この商品を見た人へのおすすめ」を設計してください。

模範回答

まず目的と規模を確かめます。目的は購入の増加、商品は100万件、表示は 100ms 以内、と仮定します。指標は、オンラインでは推薦枠経由の購入率、オフラインでは Recall@K と NDCG、ガードレールとしてレイテンシと、同じカテゴリばかりにならないかを見ます。ベースラインは「同じカテゴリの人気順」です。

構成は2段にします。候補は、同じセッションで一緒に見られた・買われた商品の共起と、商品説明の埋め込みの近さから数百件を夜のバッチで作り、商品 ID ごとに KVS に保存します。表示のときは、利用者の直近の閲覧や価格帯を特徴量にして GBDT で並べ替えます。新しい商品は共起がないので、埋め込みの近さで候補に入れます。在庫切れの除外はルールで行い、推論が間に合わなければ候補の順のまま返します。最後に A/B テストで確かめ、表示されたものばかり選ばれる偏りを探索の枠で抑えます。

深掘りされたら

新しい商品が候補に入らない問題をどう解決しますか？
オフラインの NDCG は上がったのに購入率が変わりません。どう考えますか？

見られているポイント要件と指標の確認・候補と並べ替えの2段・コールドスタート・評価のつなぎ

Q2検索結果の並べ替え（ランキング）のモデルを設計してください。

模範回答

前提として、EC のキーワード検索で、まずキーワード検索エンジンで候補を数百件取り、その並べ替えを ML で行う、と置きます。ラベルはクリックと購入のログから作り、購入を強い正例にします。ただし上位に出たものほどクリックされる位置の偏りがあるので、表示の位置を特徴量に入れて推論では固定する、一部の順位を入れ替えて偏りを測る、などで補正します。

特徴量は、クエリと商品の一致度（キーワードの一致・埋め込みの近さ）、商品の人気と評価、価格、利用者の好みです。モデルは LambdaMART などの GBDT のランキング用の学習から始め、指標は NDCG@10 をオフラインで、検索経由の購入率と「結果なし」「すぐ検索し直した」割合をオンラインで見ます。レイテンシの予算が小さいので、重い特徴量は事前計算し、並べ替える件数を上位 100件程度に絞ります。

深掘りされたら

クリックのログだけで学習すると、何が問題になりますか？
検索語が少ない新しい商品は、どう上位に出しますか？

見られているポイントラベルの作り方と位置の偏り・ランキングの指標・レイテンシの予算

Q3小売チェーンの「店舗×商品」ごとの需要予測を設計してください。

模範回答

まず使われ方を確かめます。発注に使うなら、何日先を、どの粒度（日・週）で、いつまでに出す必要があるかです。ここでは毎晩、翌週の日ごとの販売数を全店舗×全商品で出すバッチ推論と置きます。指標は、商品ごとの規模が違うので割合の誤差を見ますが、売上 0 の日があるので MAPE ではなく、全体の誤差の合計を実績の合計で割る指標や、欠品と廃棄の金額で評価します。

分け方は時系列で、過去で学習し次の期間でテストするウォークフォワードにします。特徴量は、曜日・祝日・天気・販促・価格・過去の販売の移動平均です。モデルは全店舗×商品を1つの GBDT で学習するのが扱いやすいです。注意点は、欠品の日の販売数は需要より少ないこと（本当の需要が見えない）と、新商品・新店舗です。発注では予測の幅も大事なので、分位点の予測も出します。

深掘りされたら

欠品していた日のデータは、どう扱いますか？
新しく出店した店舗の予測はどうしますか？

見られているポイント使われ方の確認・時系列の分け方・指標の選び方・欠品の偏り

Q41日1億回の予測を返すオンライン推論の基盤を、どう見積もって設計しますか？

模範回答

まず QPS を出します。1億 ÷ 約 86,400 秒で平均約 1,200 QPS、ピークを平均の3倍として約 3,600 QPS を目標にします。次に1台が処理できる量を、負荷試験で測ります。仮に GBDT を CPU で動かし、1台 500 QPS を p99 の目標内で返せるなら、ピークで8台、余裕と1つのゾーンが落ちる分を見て 12台程度、と見積もります。

レイテンシの予算は区間に分け、特徴量の取得をまとめて1回にする、前処理を共通のライブラリにする、などで守ります。モデルの版をレジストリから読み込み、起動時にウォームアップし、オートスケールは同時実行数か待ち行列の長さで行います。タイムアウトしたら代わりの答えを返し、予測ログは非同期で送ります。GPU が要る大きなモデルなら、ダイナミックバッチングで1台の処理量を上げる前提で台数を出し直します。

深掘りされたら

p99 だけが目標を超えます。何を調べますか？
GPU を使う場合、見積もりの何が変わりますか？

見られているポイント見積もりの手順・負荷試験の数字から台数を出す・可用性とフォールバック

Q5注文の表から、各注文の時点で「その利用者のそれまでの注文回数」と「直前3回の平均金額」を pandas で作ってください。

模範回答

まず利用者と注文時刻で並べ替え、利用者ごとにグループにします。それまでの注文回数は、グループの中での通し番号 groupby('user_id').cumcount() で、0 から始まるので「自分より前の件数」がそのまま出ます。直前3回の平均は、金額を1行ずらしてから移動平均をとります。df.groupby('user_id')['total'].transform(lambda s: s.shift(1).rolling(3, min_periods=1).mean()) のように、shift(1) で今の行を含めないのがポイントです。

今の行を含めると、今の注文の金額という答えに近い情報が特徴量に入ってリークになります。最初の注文は平均が欠損になるので、欠損のまま渡すか、フラグを付けます。書いたあとに、2人分・数行の小さな表で値を手計算と比べて確かめます。同じことは SQL のウィンドウ関数で ROWS BETWEEN 3 PRECEDING AND 1 PRECEDING としても書けます。

深掘りされたら

同じ時刻に複数の注文があったら、どう扱いますか？
この特徴量を推論のときにどう計算しますか？

見られているポイント今の行を含めないこと（リーク）への意識・確かめ方

Q6SNS の有害な投稿（誹謗中傷・スパム）を見つける仕組みを設計してください。

模範回答

まず方針を確かめます。何を有害とするかの規約、投稿前に止めるか後から消すか、誤って消したときの救済です。ここでは、投稿後すぐにスコアを付け、高いものは自動で非表示、中くらいは人の確認の列に入れる、と置きます。指標は、人の確認の結果を正解にした適合率と再現率、確認の待ち時間、利用者からの異議で覆った割合です。

モデルは文章の分類で、事前学習済みの言語モデルを自社のラベルで調整します。軽いモデルで全件を判定し、迷うものだけ大きいモデルや LLM で見直すと費用を抑えられます。攻撃者は言い回しを変えて適応するので、人の確認の結果を毎週学習データに足し、新しい手口を評価データにも入れます。ラベル付けの指示書と一致率の管理、方言や特定の属性への偏り（公平性）の評価も、最初から設計に入れます。

深掘りされたら

人の確認が追いつかないときは、どうしますか？
新しい言い回しのすり抜けに、どう早く気づきますか？

見られているポイント方針と人の確認の組み合わせ・ラベルの運用・攻撃者の適応・公平性