01モデルは解釈する、決定はコードが行う
LLMに「重篤かどうか」を答えさせてはいません。LLMがするのは、ICH E2A の各基準に該当する記述が本文にあるかを引用付きで挙げることだけです。そこから重篤／要確認／非重篤を決めるのは決定的なコードです。この分離のおかげで、安全性の性質を「祈る」のではなくテストで証明できます。実際、どんなモデル出力を与えても過小評価が起きないことを網羅的に検証しています。
ケーススタディ
安全性情報のトリアージを、根拠を捨てずに速くする
医薬品安全性監視（PV）の一次評価を支援するアシスタントです。有害事象報告を読み、重篤性・既知性・因果関係の評価案を出典付きで作り、人が承認します。判断を置き換えるのではなく、判断に必要な材料を整えることを目的にしています。
デモを触る →何が難しいのか
安全性業務では、届いた報告ひとつひとつについて「企業として重篤と評価するか」「添付文書に記載のある事象か」「因果関係を否定できるか」を判断し、該当すれば期限内に規制当局へ報告します。件数は多く、期限は短く、判断材料は非構造のテキストです。
この領域には強い非対称性があります。過大評価のコストは工数だが、過小評価のコストは報告漏れです。重篤かつ未知の事象を見落とせば、規制上も臨床上も実害につながります。したがって「迷ったら安全側」が設計原則になります。
そして一番難しいのは、判断材料が報告欄ではなく経過文にしかないケースです。「報告上は非重篤のめまい」でも、経過に「転倒して骨折、入院」と書かれていれば、企業評価は入院を根拠に重篤になります。これは定型項目の抽出では拾えません。
設計上の判断
「LLMに評価させる」のではなく、LLMに何をさせないかを決めることが設計の中心でした。
02迷いは黙って解決せず、人に上げる
確信が持てない場合の既定値を安全側に倒しています。重篤性は「要確認」、因果は「否定できない」、既知性は一致が確実でなければ「未知」扱い。要確認は非重篤に丸めず、根拠を添えてレビュー対象として浮上させます。
03評価してよい症例かを、評価の前に決める
自社品が関与しない症例は、評価を実行せず対象外として止めます。「とりあえず評価して注記する」ではありません。企業評価は自社品スコープが前提であり、前提を満たさないものに判定を出すこと自体が誤りだからです。
04モデルはステップごとに選ぶ
全ステップを同じモデルで回してはいません。経過文からの帰属判断（重篤性・因果）は難しいので高性能モデル、定型的な転記やコード化は安価なモデル。これは推測ではなく、ステップ単位で測った結果に基づいています。費用も実行ごとに実測して画面に出しており、1症例あたり約$0.03〜0.04・15〜18秒、うち費用の約85%は高性能モデルを使う2つの判定です。評価対象外の症例はゲートで止まるので$0です。
05オンプレ版を測り、望まない結果を報告した
機微な症例データを外に出さないローカル実行を検証しました。結果はどのローカル7〜8Bモデルも安全性の不変条件を保てないというもので、いずれも重篤事象を見落としました。そのため全ローカル化は見送り、転記・コード化のみローカル、臨床判断はクラウドという構成を採用しています。出したかった結論ではありませんが、測って出た結論です。
06人手のレビューが次の症例に効く
レビュアーが「医学的に重要」と判断したコードはリストに昇格し、以後の症例で自動的に重篤と判定されます。承認された症例は判例として蓄積し、次回以降の判定と食い違えば警告します。ただし過去データは安全側にしか動かさず、単独で重篤を決めることはありません。
07英語でも読めるが、モデルの出力は書き換えない
英語話者にも1症例を追えるよう、画面・判定の語彙・MedDRA用語は英語化しました。一方、症例本文とモデルの判定根拠は日本語のままです。パイプラインと評価が日本語で作られており、根拠を訳せばモデル呼び出しが増えるうえ、監査の証拠そのものを書き換えることになるからです。画面が「Needs review」と表示しても送る値は「要確認」であることを、テストで保証しています。
測った結果
正解データ（gold）を用意し、評価ハーネスで採点しています。最重要指標は精度ではなく、過小評価がゼロであることです。3回の反復実行と、未知症例（ホールドアウト）でも確認しました。
0
過小評価（重篤度・因果・既知性）— 本評価・反復・ホールドアウトのすべてで
100%
MedDRA コード付与（56語のデモ用語集で測定。単一LLMでは29%）
83–91%
重篤度一致（複数回の評価の範囲。不一致は安全側の過大評価）
2/2
評価対象外の症例を評価前に停止
$0.03–0.04
1症例あたりの実測費用（15〜18秒）
188
自動テスト（バックエンド181・E2E 7）
この数字の限界
症例数はごく少なく（合成7症例、評価対象は5症例・23事象）、正解データはLLMで起案したものを、システムを作った私自身がPV実務の観点で修正した形です。自分で作った基準に自分のシステムが一致している部分が残るため、外部の独立した評価とは言えません。
症例は合成データで、実務の報告より整っています。実際の報告は記述が乱れ、情報が欠け、書式も揃いません。実行ごとのばらつきは3回の反復で測ったのみで、信頼区間は出していません。
MedDRAのコード化は、ライセンス製品であるMedDRAそのものではなく、56語の架空のデモ用語集で測っています。本物のMedDRAはPTだけで約2.7万語あり、100%は「検索して候補から選ぶ仕組みが動く」ことを示すにとどまります。単一LLMの29%は、正解データに本物のコードが入っていた時点の測定で、現在のリポジトリでは再現できません。
「過去症例のフィードバックで精度が上がる」は実証できませんでした。未知症例では判例は何も変えず、以前見えた改善は初期データに依存したものだったと、ホールドアウトで分かりました。
したがって、ここで示せているのは「精度が高い」ことではなく、安全側の不変条件が保たれていることと、それを測る手順があることです。
どう作ったか
PV実務の経験はありますが、Webフロントエンドやクラウドの実務経験はありません。この部分はAIを使って自走して構築しました。隠す意図はなく、むしろそこが示したい能力の一部です。
ただし「動いたからよし」にはしていません。重要な判断はすべて設計判断記録（ADR）として、根拠となる再現可能な実験とセットで残しています。読めば、なぜその選択をしたかを追跡できます。
自分で一行ずつ書いていないコードを信用しないための手当もしています。フロントエンドの型はバックエンドのモデルと自動で突き合わせ、ズレたらテストが落ちます。安全性の不変条件も同様にテストで固定しました。自分の目で保証できない層は、機械で保証するという方針です。
画面も同じ考え方で、実際のブラウザでレビュアーの操作を通すテストがあります。バックエンドは本物の応答を録画して再生するので無料・決定的で、承認時に送る内容が本物のバックエンドの受理した内容と一致することを日英両方で確かめます。テストを書いたら、わざとコードを壊して本当に失敗するかも確認しています。
次にやること
- 独立した評価者による正解データの作成（現在の循環性を断つため）、より乱れた実務に近い症例での検証、反復回数を増やした信頼区間つきの測定。
- 重篤性判断で唯一クラウドに依存している部分を、より大きなローカルモデルで置き換えられるかの検証。
- レビュー中の症例・判例を再デプロイ後も残す永続化（現在のデモではコンテナ内にあり、デプロイで消えます）。
本プロジェクトで使用している症例・添付文書はすべて本プロジェクト用に作成した架空のデータで、実際の患者情報は含みません。MedDRAは含まず、コード化には架空のデモ用語集（コード DEMO-xxxx）を使っています。MedDRA®はICHの登録商標です。