約束ではなく、測定で。
Klornが公開する数値と、それぞれの出どころ、そしてそれぞれからは分からないこと。ここで挙げるセットとスクリプトはすべて公開リポジトリにあります。
3つの数値と、その出どころ
- ≥90%緊急メールの再現率、CIの下限
合成ゲートセットで緊急メールの再現率を90%未満に下げる分類器の変更は、ビルドを失敗させます。
出典：eval-floors.ts - 95.5%Silentの適合率
手作業でラベル付けした実メールのセットで測定：KlornがSilentに振り分けた22通のうち、21通がsilentとラベル付けされていました。2026-08-26に3回実行し、毎回同じ結果でした。
出典：eval/README.md - 0承認のない操作
送信・完全削除・外部アドレスへの転送は承認を待ち、送り出した内容のハッシュに紐づいた記録を残します。自分で作った自動返信ルールも、その承認として扱われます。
コードで強制：attention-floor.ts
代表的な正解率は掲げていません。実メールのセットはMeetingとInfoのレーンができる前のもので、ラベルは3つのレーンしか使っていません。そのため残りの2つは採点できず、5つすべてに合わせてラベルを付け直す必要があります。付け直すまでは、このセットから代表的な正解率は引用しません。上のSilentの適合率も同じセットによるもので、同じ制約があります。
評価の進め方
リポジトリにあるセット
packages/api/eval/には2つのセットがあります。実メールのセット（real-eval-set.json）は、手作業でラベル付けし個人データを取り除いた実際のメール53通です。合成ゲートセット（judge-eval-set.json）は、個人データを含まない架空のメール56通です。
ランナー
packages/apiでpnpm eval:realを実行すると、実メールのセットで分類器を採点します。pnpm eval:judgeは合成セットで同じことを行います。
CIのゲート
分類器を変更するプルリクエストでは、合成ゲートセットをモデルに通し、3つの下限を強制します。全体で80%、緊急メールの再現率90%、Silentの適合率90%です。どれかひとつでも下回れば失敗します。フォークからのプルリクエストのようにジョブにモデルキーがない場合は、合格扱いにせず、通知を出してスキップします。
2つ目のチェックはモデルを必要とせず、CIのテストを実行するたびに走ります。ルールベースの高速経路とキーワードによるフォールバックが同じセットで70%に達すること、見逃した緊急メールがSilentではなくQueueに落ちること、そしてマーケティングメールが決して緊急と判定されないことを確かめます。
実メールのセットも同じプルリクエストで採点しますが、レポートとしてだけです。緊急レーンにラベル付けされたメールは4通しかなく、90%の下限に意味を持たせるには少なすぎます。
2026-10-14にリポジトリと照合して確認しました。間違いがあればお知らせください。