stcc-mcp — 電話トリアージ階級：ルールで決定的に計算、0.6B は判定基準だけを照合

問診記録を入れると、L1–L5 階級 + 処置文言 + 根拠の逐条引用 + 不足している判定基準が出る。 階級分けは決定的ルールエンジンが計算する（225 件の STCC プロトコル / 849 分岐 / 4,168 件の判定基準、パッケージに同梱）、 Qwen3-0.6B は一つのことだけを答える：与えられた記録と一つの判定基準に対して、yes / no / unknown。

モデルは分岐を選ばない、階級を決めない、処置文言を生成しない、tool call もしない。

⚠️ 救急トリアージシステムではない、診断もしない、医師の代わりにはなれない。L1–L5 は処置の階段 （救急車を呼ぶ / 直ちに受診 / 今日中に受診 / 2 日以内の外来 / 自宅観察）。緊急時は 120 番へ。

3 ステップで動かす

pip install stcc-mcp                                       # 或 uvx stcc-mcp …
ollama pull hf.co/chenhaodev/stcc-checker-0.6b-GGUF:Q8_0   # 640MB 核对器
stcc-mcp doctor                                            # 自检：索引 / Ollama / 模型
stcc-mcp triage --protocol Chest_Pain.md "$(cat 记录.txt)"

常駐ゼロ、Docker ゼロ、非接続。純標準ライブラリ、サードパーティ依存なし。

初回実行で大概率 tier: L1 + certain: false が出る —— これは正しい

普通の問診記録を入れると、最緊急階級と unresolved のリストが出やすい。誤りではない： エンジンはある分岐の全条件が no のときだけそれを排除でき、実際の問診では一つの分岐の判定基準を全部聞き切ることはない。 例えば軽症の発熱記録で看護師が意識/項部硬直/発疹を聞いたが、脱水徴候は聞いていない （排尿減少、眼窩陥没、皮膚ツルゴール低下、口渇）。するとその分岐は排除できず、出力はその分岐の階級上限に留まる。

unresolved とは「これを追加で聞けば階級を絞り込める」リストのこと。 回答を記録に補って再実行すると、 unresolved は単調に短くなる；しかし階級はある分岐が完全に排除されたときだけ下がる—— 実測では同じ発熱記録に脱水徴候を補うと unresolved は 8→2 になったが、階級は L1 のままだった。 なぜなら残った主幹（高齢者または免疫低下者…脱水所見： のような途中までの文）について照合器が unknown を返したからだ。 このとき動かすべきは下の閾値ツマミであって、問い続けることではない。詳細は境界 ①②。

エージェントに接続する（Claude Code / 任意の MCP client）：

pip install "stcc-mcp[mcp]" && stcc-mcp serve               # stdio MCP

Ollama は MCP をサポートしないが、この形態では問題にならない：小モデルは tool call を一切しない、 オーケストレーション層が Ollama（HTTP）とルールエンジン（プロセス内）をそれぞれ呼ぶだけで、両者は互いに知らない。 0.6B の自律 tool-calling は既知の弱点だが、このアーキテクチャは設計上それを回避している。

Related MCP server: Quellgeist

出力

階級から行動へのマッピングはあなたのオーケストレーション層が決める；本パッケージは階級と処置文言だけを提供する。

no の判定閾値は一つのツマミ

--no-threshold（デフォルト 0.63）：P(no) ≥ τ ⇒ no、それ以外は yes/unknown の大きい方を採用。 同じモデルをリリース分布（n=3225）で評価したときの全体の取舍曲線：

同じ発熱問診記録で、τ だけ変える：

$ stcc-mcp triage --protocol Fever_Adult.md --no-threshold 0.63 "$(cat 记录.txt)"
  tier L1 · 拨打救护车        · unresolved 2
$ stcc-mcp triage --protocol Fever_Adult.md --no-threshold 0.40 "$(cat 记录.txt)"
  tier L3 · 2小时内接受医疗护理 · unresolved 5

τ を下げると、照合器は「聞いたが否定された」基準を no と判定しやすくなる ⇒ 分岐が排除される ⇒ 階級が下がる。 これはモデルを賢くするのではなく、同じ取舍曲線上で動作点を移動させているだけ——代償として見逃しリスクが上がる。

false_no（成立すべきなのに no と判定）が本当の危険——偽の no は真の分岐を安全な収束から排除してしまう。 no を減らしすぎると過剰診断になるだけだが、それはコストの問題に過ぎない。 デフォルト値は dev セット上で false_no ≤ 0.0036 を満たすように選定（dev は正例 495 件のみ、分解能 0.0020、 系統的に保守側に偏っている）。だから「最適値」は一つに固定せず、曲線ごと提示する。あなたのコスト行列に合わせて点を選べばよい。 再現：python -m scripts.threshold_sweep --model <m> --split <s> --collect --report。

🔴 既知の境界（使う前に必ず読む）

① 入力は「プロトコルに従って問診済みの記録」でなければならない。素の主訴ではない。 短い主訴では unknown 率 94%；実際のリッチな対話（IMCS-21、748 字 / 40 往復）でも 88%。 原因は STCC の前置分岐が急症レッドフラグ（窒息、チアノーゼ、無反応）をふるいにかけるためで、 自然発生のコーパスは定義上これらの状況を含まず、医師も尋ねない——これは選択効果であり、コーパスを変えても消えない。

② 実際の問診で一つの分岐の全基準を聞き切ることはない。だから階級はその分岐の上限に留まる。 これは worst_case が正しく働いている証拠だが、上限の緩さは問診の網羅性で完全に決まる。

③ worst_case の安全性は「偽の no を出さない」ことを前提にしている。 出力は現在の証拠で排除できない最緊急の階級（ある分岐は全条件が no のときだけ排除される）、 したがって過小トリアージは恒常的にゼロ、証拠が一つ増えるごとに no が一つ増えれば単調に階級が下がる（この 2 つの不変条件は tests/ が守っている）。 情報が足りないときは「全員救急車」に退化する——これは設計上の意図（過小トリアージ 10·d² vs 過大トリアージ d の非対称な損失）。

④ 階級分け自体は silver 基準：分岐ごとの正解は強モデルが作成し人間が校正したが、最終的な金基準は実地の看護師判断が欠けている。

unknown がなぜ第一級の状態なのか

STCC の分岐意味論は「この分岐のいずれかの条件がはいなら命中；全部がいいえなら次へ」。 "言及なし" ≠ "否定された"：前者は追加質問を引き起こすべきであり、後者だけが分岐を進める。 unknown を no に潰すことは偽の陰性を捏造する**に等しく、エンジンを誤った分岐へ導く。

判定基準テキスト

索引内の判定基準は1 件ずつ独立に書き直した版（5,214 / 5,214）。純粋な閾値と単一の医学用語 （「咳嗽」「体温>100.4°F」）は事実どおり保持。書き直しは 3 つの関門を通る： 数値/否定/長さ/類似の形式チェック、oracle 再生で原版とビット単位で一致、下流 checker の指標が低下しないこと。

開発

uv sync
uv run pytest -q                        # 27 条回归
uv run python -m scripts.mcp_selfcheck  # oracle 回放 4,168 条判据，<1 秒

scripts/mcp_selfcheck.py はエンジンの忠実度セルフチェック：各判定基準を 1 件ずつ yes にし、他は全て no にして、 エンジンが到達する分岐と処置を照合する。これはモデル評価ではない——不一致があればコンパイルか評価ロジックに穴がある。

モデル

chenhaodev/stcc-checker-0.6b-GGUF （Q8_0 / Q4_K_M）。判定基準単位の false_no 0.0024、遅延中央値 ~250ms、エンドツーエンド 1.25s/件。

Apache-2.0.