前回の記事では、AWSのグローバルAIハッカソン「10,000 AIdeas Competition」で作った VetVoice について、開発体験を中心に書きました。
今回は、VetVoice の中身である「音声メモを診療記録に変換するパイプライン設計」を、1枚の図にまとめました。
何を作ったか
VetVoice は、牛を診る獣医師向けの音声入力診療記録システムです。
牛舎や農場で獣医師がスマートフォンに残した音声メモをもとに、あとで確認・修正できる診療記録ドラフトを作ることを目指しています。
なぜLLM一発では安定しなかったか
最初は、音声認識で得られたテキストをそのままLLMに渡し、診療記録を作らせることも試しました。
しかし、現場の音声には専門用語、略語、言い直し、口語表現、音声認識の誤変換が多く含まれます。
たとえば、獣医療の文脈では「子宮」と言っているのに、音声認識では「地球」と書き起こされることがあります。こうした入力をそのままLLMに渡すと、存在しない情報を補ったり、未確認の内容を断定したりすることがあります。人間だとそんな間違いはないと思うところで間違います。
必要なのは「それっぽい文章」ではなく、「根拠を確認できる構造化されたドラフト」でした。そのため、一発変換ではなく、段階ごとに役割を分ける設計にしました。
7つの処理に分けた
VetVoice では、処理を大きく7つに分けました。
- 書き起こし — 音声をテキストに変換する。「子宮」が「地球」になるような専門用語の誤変換が起きる
- 略語展開 — 現場の略語を正式名称に展開する。「AI」が人工知能ではなく人工授精を指すように、ドメインで意味が変わるためLLMには任せない
- 正規化 — 音声認識の誤変換を補正する。同じ語が毎回違う形で壊れるため、カスタム語彙だけでは対処しきれない
- 構造化抽出 — LLMを使い、非定型な音声メモから所見・病名・処置などを分類する。ただし出力は必ず構造化データにし、自然文をそのまま信じない
- マスタ照合 — 口語表現を業務上の正式名称に接続する。似た名前の誤確定が業務に影響するため、確信度が低いものは「未確認」として人間に委ねる
- テンプレート選択 — 診療内容に応じた記録形式を選ぶ。なぜそのテンプレートが選ばれたか説明できるよう、LLMではなくルールベースにしている
- 診療記録ドラフト生成 — LLMを使い、構造化データを読みやすい記録に整える。ただし出力をバリデーションし、問題があれば再生成、それでも直らなければLLMを使わないフォールバックに切り替える
LLMを使うのは4と7だけ。それ以外は辞書、ルール、マスタ照合、バリデーションで支えています。
モデルに関しては、４ではClaude Haiku 4.5を7にはAmazon Nova Liteを使用しています。
Bedorkに乗っているモデルですとほかのモデルも色々と組み合わせて試したのですが、低価格で安定した出力をだせるのがこの組み合わせということで採用しました。
なぜフォールバックを用意したか
7のドラフト生成では、LLMが構造化データにない処置を書いたり、未確認の病名を断定したりすることがあります。
VetVoiceは獣医師の下書きアプリなので、病名が明示的に入力されない場合は断定しないというプロセスをとっています。なぜならば獣医師以外が病名を診断することは獣医師法でも明確に違法あるといわれているのと、病名をAIが断定して誤診になることを避けたかったためです。
バリデーションで検出し、再生成を試みますが、それでも直らない場合はLLMを使わず構造化データから機械的に記録を組み立てます。文章としては不自然になりますが、嘘は書きません。
業務システムでは、自然な文章であることよりも、事実と異なる内容を出さないことの方が重要です。特に診療記録では、この優先順位はかなり重要だと考えています。
作ってみて分かったこと
AIツールを使うと、コードやパイプラインの実装はかなり速くなります。
ただし、「どこで何が壊れるか」は、実際の音声を流してみないと分かりませんでした。
獣医師がどう話すか、どんな略語を使うか、音声認識がどう誤変換するか。こうした知識はネットに載っていないし、LLMの学習データにも含まれていません。
壊れた箇所を直すのに必要なのは、より賢いモデルではなく、ドメインの知識でした。
どこまでをAIに任せ、どこからを人間のドメイン知識で担保するか。その境界を設計することが、現場で使えるAIアプリケーションを作るうえで一番重要だと感じました。