モデル評価設計入門 — 「精度が高いのに使えない」を防ぐ7つの問い

「検証データでAccuracy 98%」と聞くと、良いモデルに見えます。しかし不良率1%の検査で、すべてを正常と返すだけでもAccuracyは99%です。数字が間違っているのではありません。答えたい問いと指標がずれているのです[2]。

モデル評価は、学習後に指標を選ぶ作業ではありません。この記事では、何を予測し、誰がどう使い、どの誤りをどこまで許すかから、データ分割、指標、しきい値、運用監視までを一つの評価設計として組み立てます。

何の意思決定を支えるのか

最初の問いは「どの指標を使うか」ではなく、「予測の後に何が起きるか」です。モデルの出力が同じ二値分類でも、使い方によって評価は変わります。

利用場面	モデルの出力後	重い誤り	見るべきもの
外観検査	異常品を人が再検査	欠陥の見逃し	Recall、欠陥別Recall、再検査率
スパム隔離	メールを自動で隠す	正常メールの隔離	Precision、False Positive Rate
離反予測	対象顧客へ施策を打つ	施策枠の浪費	Precision@k、施策後の増分
需要予測	発注量を決める	欠品と廃棄	金額加重誤差、欠品率、廃棄率

モデル指標が良くても、業務指標が改善するとは限りません。GoogleのMLプロジェクト指針も、ビジネス指標とモデル指標を別に定義し、その接続を早期に確認する必要を指摘しています[1]。

評価設計の出発点として、次を一文にします。

このモデルは、誰が、いつ、何を決めるために使い、誤ると何が起きるか。

この一文が書けない段階では、F1を小数第3位まで比べても意味は薄いと考えます。

評価データは本番を模擬しているか

ランダム分割は便利ですが、現実の利用条件を壊すことがあります。評価データは「未知データ」ではなく、本番で遭遇する未知の作り方に合わせて分割します。

同じ個体をまたがせない

同じ患者、顧客、製品、設備、文書の断片が学習とテストに入ると、モデルは個体固有の特徴を覚えられます。画像をランダム分割するのではなく製品ID単位、ログ行ではなくユーザーID単位で分けます。scikit-learnではGroupKFoldやStratifiedGroupKFoldがこの目的に使えます[3]。

未来を過去に混ぜない

将来予測では、未来のデータで学習して過去を当てる分割は本番を再現しません。古い期間で学習し、新しい期間で評価します。時系列データに通常のK-foldを使うと近接時点の相関が混ざるため、TimeSeriesSplitのような時間順の分割が必要です[3]。

前処理も分割の内側に置く

全データで標準化の平均を計算する、欠損補完器を全件でfitする、特徴選択をテスト込みで行う。これらもデータリークです。前処理、特徴作成、校正までを学習側だけでfitし、その固定済み処理を評価側へ適用します。

どの誤りが高くつくのか

Accuracyは、False PositiveとFalse Negativeを同じ1件として数えます。しかし現場のコストは非対称です。外観検査なら見逃しは不良流出、過検出は再検査工数です。MVTec ADの異常検知ハンズオンでも、この非対称性がしきい値設計に直結します。

分類指標は、誤りの意味に合わせて選びます[2]。

指標	答える問い	注意点
Recall	実際の陽性をどれだけ拾ったか	過検出が多くても高くできる
Precision	陽性判定のうち本当に陽性はいくつか	見逃しが多くても高くできる
F1	PrecisionとRecallの調和平均	両誤りを同程度に扱う前提が隠れる
ROC-AUC	全しきい値での順位づけ能力	極端な不均衡では運用感とずれることがある
PR-AUC	陽性クラスを中心にした順位づけ	陽性率の異なるデータ間で単純比較しにくい

主指標を1つ決めたら、制約も置きます。たとえば「Recall最大化、ただしPrecision 70%以上」「再検査率5%以下で欠陥Recallを最大化」のように書くと、モデル選択と運用条件がつながります。

しきい値を誰がどう決めるのか

0.5は確率の見た目が切りのよい数字にすぎず、業務上の最適値ではありません。しきい値は、検証データ上で次のコストを最小化する点として考えられます。

総コスト = 見逃し件数 × 見逃し単価 + 過検出件数 × 確認単価

実務では単価を完全に金額化できないこともあります。その場合は、次の順で決めます。

1. 絶対に下回れないRecallや安全条件を置く
2. 条件を満たす範囲でPrecision、処理件数、費用を比較する
3. 検証データでしきい値を固定する
4. 最後に、一度だけテストデータで成績を測る

テストデータを見ながらしきい値を調整すると、テストが検証データへ変わります。最終テストを守ることは、モデルの一般化性能を測るための基本です。

スコアを確率として信じてよいか

予測スコア0.8が「同様の100件中、およそ80件が陽性」を意味するとは限りません。順位づけが上手なモデルでも、確率が過信気味・弱気なことがあります。

確率に基づいて、人手確認の優先順位、期待損失、在庫量を決めるなら校正を評価します。calibration curveで予測確率と実際の発生率を比べ、Brier scoreやlog lossも確認します。校正器はモデル学習データとは独立したデータでfitする必要があります[4]。

一方、単に上位100件を並べる用途なら、校正よりランキング指標が直接的です。出力を何に使うかで、必要な品質は変わります。

平均の裏で誰に失敗しているか

全体F1が同じでも、特定条件だけ壊れるモデルがあります。次のスライスを、利用条件に合わせて事前に決めます。

• データ取得元、機器、拠点、品種
• 時間帯、曜日、季節、導入前後
• 入力の長さ、画質、欠損の有無
• 頻出クラスと希少クラス、既知欠陥と新規欠陥

ただし、細かく切るほど件数は減ります。5件中1件の誤りと、5,000件中1,000件の誤りを同じ20%として扱わず、件数と信頼区間を併記します。改善幅が評価データの揺らぎより小さいなら、「改善した」と断定せず追加データを集めます。

教師データが足りないときの戦い方で扱ったデータ拡張も、評価側へ適用してはいけません。テスト分布を都合よく加工すると、現実の失敗が見えなくなります。

オフライン評価の後に何を見るか

オフライン評価は出荷判定の一部です。本番では、モデル単体だけでなくシステムを監視します。本番MLの成熟度を扱ったML Test Scoreも、データ、モデル、インフラのテストと監視を一体で求めています[5]。

層	出荷前	本番後
データ	スキーマ、欠損、範囲、リーク	入力分布、欠損率、未知カテゴリ
モデル	主指標、制約、スライス、校正	スコア分布、遅延ラベルでの性能
運用	人が処理できる件数、失敗時の導線	再検査率、上書き率、保留件数
業務	目的指標との接続	売上、欠品、不良流出、工数など

ラベルがすぐ返らない場合でも、入力特徴や予測スコアの分布は監視できます。ただし、分布変化は性能低下の代理信号であり、性能低下そのものではありません。ラベルが返った時点で、実性能と照合します。

まとめ

• 評価は指標選びではなく、モデルが支える意思決定の設計から始める
• データ分割は、個体・時間・前処理を含めて本番の未知を再現する
• 主指標に加え、許容条件と誤りコストを定義する
• しきい値は検証データで決め、最終テストを調整に使わない
• 確率を意思決定に使うなら校正を確認し、平均だけでなく重要スライスを見る
• 出荷後はデータ、モデル、運用、業務の4層を監視する

まず手元の評価レポートに、「この予測の後に誰が何をするか」と「最も高くつく誤りは何か」の2行を足してください。評価指標の選び方が、そこから変わります。