LLMの医療応用は、いま医療AIでもっとも動きの速い領域です。診察音声からのカルテ下書き、紹介状・退院サマリの作成支援、院内規程やガイドラインの検索——「文書仕事」の多い医療現場とLLMの相性は抜群です。
一方で、医療はもっともらしい嘘(ハルシネーション)のコストが最大級に高いドメインでもあります。存在しない論文の引用、実在しない薬剤用量、それらが自信満々の文体で出力される——この性質を放置したままプロダクトにすることはできません。
この記事では、医療LLMアプリを設計するときに使える6つの設計パターンを、実装の観点から紹介します。
前提: どのユースケースを選ぶかで難易度が決まる
パターンの前に、そもそもの選定基準です。LLMの医療応用は「間違いの検出しやすさ」で難易度が桁違いに変わります。
| ユースケース | 誤りの検出しやすさ | リスク |
|---|---|---|
| 診察音声からのカルテ下書き | ◎(話者本人がすぐ検証できる) | 低〜中 |
| 文書の要約・形式変換(紹介状の下書き等) | ○(元文書と突き合わせ可能) | 中 |
| 規程・ガイドライン検索(RAG) | ○(出典を提示できる) | 中 |
| 医学的な質問への自由回答 | ✕(検証に専門知識が必要) | 高 |
| 診断・治療方針の推奨 | ✕✕(そもそも規制対象になり得る) | 最高 |
「生成した内容を、その場で人間が検証できるか」が最重要の設計変数です。下2つに手を出すなら、それはもう「LLMアプリ開発」ではなく「医療機器開発」だと考えてください(参考: SaMD入門)。
パターン1: Groundingの強制 — 「根拠がなければ答えない」
もっとも効果が大きい基本パターンです。モデルの内部知識に自由に答えさせるのではなく、検索で取得した文書(コンテキスト)だけを根拠に回答させ、根拠を示せない場合は回答を拒否させます。
実装の要点は3つあります。
システムプロンプトの骨子(抜粋):
- 回答は必ず <documents> 内の記述のみを根拠とすること
- 各主張の末尾に、根拠となる文書IDを [doc-3] の形式で付けること
- <documents> から答えが導けない場合は、推測せず
「提供された資料からは回答できません」とだけ返すこと- 引用IDを機械検証する。出力中の
[doc-N]を正規表現で抽出し、実際に渡した文書IDと突き合わせる。存在しないIDを引用したら、その回答は破棄して再生成 or エラーにする。 - 「わからない」を正解として扱う。回答拒否率をKPIで罰すると、現場は「なんでも答えるモデル」に寄っていきます。拒否は安全装置が働いた成功例です。
- 検索品質に投資する。ハルシネーションの多くは「検索が外れているのに無理やり答える」ときに起きます。RAGの品質は生成よりも検索で決まります。
パターン2: 構造化出力 + ドメイン検証
自由文ではなくJSONなどの構造化出力にすると、出力を「テキスト」ではなく「データ」として検証できるようになります。
例えば退院サマリの下書き生成なら:
{
"diagnoses": [
{"name": "2型糖尿病", "icd10": "E11.9", "source_span": "..."}
],
"medications": [
{"name": "メトホルミン", "dose": "500mg", "frequency": "1日2回",
"source_span": "..."}
],
"confidence_notes": ["投与期間の記載が元文書に見つからない"]
}構造化することで、次のような決定的(deterministic)な検証層を挟めます。
- ICD-10コードが実在するかをマスタと照合する
- 薬剤名を医薬品マスタと照合し、表記ゆれを正規化する
source_span(元文書のどこから抽出したか)が実際に元文書に存在するかを文字列照合する- 数値(用量など)が元文書に出現しない場合はフラグを立てる
「LLMの出力をLLMだけで検証しない」のが肝です。マスタ照合・文字列照合のような枯れた技術こそが、最後の砦になります。
パターン3: Draft-only原則(Human-in-the-loop)
医療文書生成の現実解は、LLMの出力を常に「下書き」として扱い、資格を持つ人間の確認・承認を必須にすることです。
UI設計にまで落とすと、次のような工夫になります。
- 生成文書は「下書き」ステータスで作成され、承認操作なしには確定できない
- 元データ(音声書き起こし・元カルテ)と生成結果を並べて表示し、突き合わせを最短動線にする
- LLMが自信のない箇所(パターン2の
confidence_notes)をハイライト表示する - 「承認した人間」を記録する(監査証跡)
注意すべきは自動化バイアス(automation bias)——人間は精度の高いシステムほど確認が雑になります。「下書きの9割が正しい」状態が一番危険で、確認作業が形骸化します。確認箇所を絞って提示する(全文チェックではなく差分・低信頼箇所チェックにする)など、人間の注意資源を設計するところまでがこのパターンです。
パターン4: 入出力ガードレール
モデル本体の前後に、独立した検査層を置きます。
入力側:
- 個人情報のマスキング(氏名・患者ID・連絡先を検出し、仮名に置換してからLLMに渡す)
- 外部LLM APIを使う場合は、そもそも何を送ってよいかのデータ分類ポリシーを決める(院内規程・ベンダー契約と整合させる)
出力側:
- 用途外出力の検出(文書作成支援ツールが診断的な断定や治療推奨を出し始めたらブロック)
- 禁忌表現・断定表現のリント(「〜と診断されます」→「〜の記載があります」)
- 出力に含まれる患者識別子の漏えいチェック
ガードレールは「1つの巨大プロンプトで全部やる」より、小さな検査を直列に並べる方が保守しやすく、テストも書きやすくなります。
パターン5: 評価パイプライン — 「雰囲気で改善しない」
医療LLMアプリの改善で一番やってはいけないのが、「プロンプトを変えたら、なんとなく良くなった気がする」という運用です。
最低限そろえたいのは次の3点です。
- ゴールデンデータセット: 代表的な入力と期待出力のペアを数十〜数百件。診療科・文書タイプ・エッジケース(略語だらけ、複数疾患、記載欠損)を含める。
- 自動評価: 機械検証できる項目(引用の実在性、必須項目の充足、マスタ照合の通過率)+LLM-as-judge(忠実性: 元文書にない情報を足していないか)。
- 専門家レビューのサンプリング: 自動評価は網羅性の担保、専門家レビューは妥当性の担保。全件は無理でも、定期的なサンプリングレビューと、現場からの誤り報告ルートは必須。
プロンプト・モデル・検索設定の変更は、必ずこのパイプラインを通してから本番に出す——ソフトウェアのCIと同じ規律を、LLMにも適用します。
パターン6: ログと監査可能性
医療では「あとから説明できること」自体が要件です。
- 生成のトレーサビリティ: どの入力・どのプロンプトバージョン・どのモデルバージョン・どの検索結果から、この出力が生まれたかを記録する
- 人間の関与の記録: 誰がいつ確認・修正・承認したか
- 修正の差分: 人間がLLMの下書きをどう直したかは、そのまま改善用データセットになる(現場の修正が多い箇所=モデルの弱点)
このログ設計は、将来プロダクトが医療機器該当性の議論になったときにも、品質管理の実績として効いてきます。
まとめ — 6パターンの使いどころ
| パターン | 効果 | 実装コスト |
|---|---|---|
| 1. Grounding強制 | ハルシネーションの大幅削減 | 中(RAG基盤が必要) |
| 2. 構造化出力+検証 | 誤りの機械検出 | 小〜中 |
| 3. Draft-only原則 | 最終安全弁 | 小(ただしUI設計が本体) |
| 4. ガードレール | 用途逸脱・情報漏えい防止 | 小 |
| 5. 評価パイプライン | 改善の再現性 | 中 |
| 6. ログと監査 | 説明可能性・継続改善 | 小 |
すべてに共通する思想は、「LLMを信頼しないことを前提に、システム全体で信頼を作る」です。モデルの性能が上がっても、この設計思想の価値は下がりません——むしろ「うまくいっているように見える」時間が長くなるほど、検証層の価値は上がります。