概要
src/consumers/feedbackTriage.ts は現在、タイトル生成・要約・スパム判定・カテゴリ・
優先度・原因コンポーネントを 1 本のプロンプトで Workers AI に投げている。このうち
判定にあたる部分を TypeSafe の System One API（POST /v1/systemone、モデル
jev-latest）へ移す。
方針
TypeSafe が返すのは Choice / Score / Noul の 3 種の型付き判定のみで、文章生成は行わない
（https://docs.typesafe.ai/api）。したがって処理を 2 つに分ける。
| 出力 |
移行先 |
title / summary |
Workers AI のまま |
isSpam / category / triageLevel / component / labels |
TypeSafe |
判定を剥がすと、生成側のプロンプトは 1 行タイトルと短い要約だけになる。
triageLevel はモデルに直接聞かず、severity / breadth の Score をコード側で加重して
決める。「クラッシュ・データ消失は単独で urgent」は加重和では表現できないため、独立した
Noul のハードルールとして持つ。
動機
PUBLIC_ISSUE_MIN_CONFIDENCE = 0.7（src/consumers/feedbackTriage.ts:33）は公開リポジトリへ
スタブ Issue を立ててよいかの門だが、比較対象の componentConfidence はモデルが JSON に
自分で書いた数値である。coerceReport のコメントが「壊れた値をそのまま通すと内容を公開
すべきでないものが流出しうる」と書いているとおり、この門は現状モデルの自己申告に依存して
いる。TypeSafe の confidence は Choice の確率分布から導出されるため、門が根拠を持つように
なる。
あわせて、判定側については JSON パース失敗時の再試行（MAX_TRIAGE_ATTEMPTS）、
extractReportJson / normalizeTriageResponse / coerceReport による防御が不要になる。
残作業
- スパイクを実行し、日本語での判定品質を実測する
TYPESAFE_API_KEY=... npm run typesafe-spike（src/cli/typesafe-triage-spike.ts）fewshot.jsonl の 18 件を held-out として、isSpam / category / triageLevel /
component の一致率と、component の confidence 分布を出す- 公式ドキュメントに Jev の対応言語の記述が無く、例はすべて英語。日本語での品質は未検証
- 現行経路には同じ 18 件を few-shot として与えているため、現行の精度と並べて比較しない
- 実測値から
triageLevel の重みと閾値を決める（スパイク内の値は暫定）
PUBLIC_ISSUE_MIN_CONFIDENCE を据え置くか調整するかを、confidence 分布を見て判断する- シャドー実行 — 既存経路の挙動は変えず、TypeSafe を並行で呼んで判定差分をログに出す
- 切り替え。
looksLikeSpam の正規表現ヒューリスティックは、is_announcement_transcript
との一致が確認できるまで残す
TYPESAFE_API_KEY を .secrets.env.example と src/types.ts の Env に追加する
（scripts/put-secrets.sh は .secrets.env を汎用的に読むため変更不要）- プライバシーポリシーの改定を、切り替えと同時に公開する（TrainLCD/Website）
- 第 15 条の「内容の分類および要約のために Cloudflare, Inc. の提供する AI サービスを
利用する」を、分類 = TypeSafe AI, Inc. / 要約 = Cloudflare, Inc. に書き分ける。日英両方
- 先行公開すると、まだ存在しないデータフローを宣言することになる
- 法人名は
TypeSafe AI, Inc. を用いる。Master Customer Agreement
（https://typesafe.ai/legal/mca）と Data Processing Agreement
（https://typesafe.ai/legal/data-processing）がいずれもこの表記で、
Privacy Policy 本文の Typesafe AI, Inc. は同文書の見出しとも食い違う単独の誤記
関連
概要
src/consumers/feedbackTriage.tsは現在、タイトル生成・要約・スパム判定・カテゴリ・優先度・原因コンポーネントを 1 本のプロンプトで Workers AI に投げている。このうち
判定にあたる部分を TypeSafe の System One API（
POST /v1/systemone、モデルjev-latest）へ移す。方針
TypeSafe が返すのは Choice / Score / Noul の 3 種の型付き判定のみで、文章生成は行わない
（https://docs.typesafe.ai/api）。したがって処理を 2 つに分ける。
title/summaryisSpam/category/triageLevel/component/labels判定を剥がすと、生成側のプロンプトは 1 行タイトルと短い要約だけになる。
triageLevelはモデルに直接聞かず、severity / breadth の Score をコード側で加重して決める。「クラッシュ・データ消失は単独で urgent」は加重和では表現できないため、独立した
Noul のハードルールとして持つ。
動機
PUBLIC_ISSUE_MIN_CONFIDENCE = 0.7（src/consumers/feedbackTriage.ts:33）は公開リポジトリへスタブ Issue を立ててよいかの門だが、比較対象の
componentConfidenceはモデルが JSON に自分で書いた数値である。
coerceReportのコメントが「壊れた値をそのまま通すと内容を公開すべきでないものが流出しうる」と書いているとおり、この門は現状モデルの自己申告に依存して
いる。TypeSafe の
confidenceは Choice の確率分布から導出されるため、門が根拠を持つようになる。
あわせて、判定側については JSON パース失敗時の再試行（
MAX_TRIAGE_ATTEMPTS）、extractReportJson/normalizeTriageResponse/coerceReportによる防御が不要になる。残作業
TYPESAFE_API_KEY=... npm run typesafe-spike（src/cli/typesafe-triage-spike.ts）fewshot.jsonlの 18 件を held-out として、isSpam/category/triageLevel/componentの一致率と、componentの confidence 分布を出すtriageLevelの重みと閾値を決める（スパイク内の値は暫定）PUBLIC_ISSUE_MIN_CONFIDENCEを据え置くか調整するかを、confidence 分布を見て判断するlooksLikeSpamの正規表現ヒューリスティックは、is_announcement_transcriptとの一致が確認できるまで残す
TYPESAFE_API_KEYを.secrets.env.exampleとsrc/types.tsのEnvに追加する（
scripts/put-secrets.shは.secrets.envを汎用的に読むため変更不要）利用する」を、分類 = TypeSafe AI, Inc. / 要約 = Cloudflare, Inc. に書き分ける。日英両方
TypeSafe AI, Inc.を用いる。Master Customer Agreement（https://typesafe.ai/legal/mca）と Data Processing Agreement
（https://typesafe.ai/legal/data-processing）がいずれもこの表記で、
Privacy Policy 本文の
Typesafe AI, Inc.は同文書の見出しとも食い違う単独の誤記関連