はじめに
京都大学大学院医学研究科の博士課程に在籍している、産婦人科医の石田憲太郎（GitHub: iishiken）と申します。
2024年から、医療分野へのLLMの応用を研究しています。2025年度の松尾研の医療LLM開発プロジェクトに参加しました。2024年終わり頃に前身のプロジェクトがスタートした際、当時は医師メンバーが1人だったことから、医療分野のタスクの定式化や病院とのコミュニケーション、自分でのコーディングを通じて、エンジニアと医療の折衝としての役割を担いました。
本プロジェクトでは、松尾研と株式会社ABEJAの協業により、現場の業務に即したユースケース検証をいくつか行いました。今回はその中から、電子カルテからの脳卒中レジストリ構築と退院時サマリー生成について報告いたします。
そのほかのユースケース検証については、ABEJA側のテックブログで紹介されていますので、あわせてご覧ください（ABEJAのテックブログ）。
レジストリとは、臨床研究や新薬の開発の土台になる患者さんの情報がまとめられたデータベースです。
退院時サマリーは、入院中の経過を一つの文書にまとめた記録です。
どちらも、医師がカルテを読み返し、必要な情報を選び、解釈して入力することで作られています。
1人の患者さんのカルテは、しばしば数十万字から数百万字に及びます。
レジストリもサマリーも、これを人手で読み返して作るため、非常に労力がかかり、間違いも起こります。
この記事では、その作業を大規模言語モデル（LLM）でどこまで支援できるかを検証した経緯と結果を、医師と開発者の両方の立場から整理します。
この記事で書いていること
- 医師兼エンジニアとして、プロジェクトで何を担当したか
- 医療現場で、診療記録を別の目的のために作り直す作業がなぜ大変か
- 今回のタスクが、医療現場の業務の中でどこに位置づけられるか
- 医師の暗黙の判断を、LLMに渡せる規則に書き直した過程
- 評価の結果と、そこから分かった得意領域と課題
本文は、プロジェクト参加者個人の立場から、公開可能な範囲で整理したものです。
診断や治療などの医療判断をLLMに任せる検証ではなく、最終確認を医師が行うことを前提に、事務や文書作成を支援できるかを確かめた技術的な検証です。
プロジェクト全体の成果は、東京大学大学院工学系研究科のプレスリリースで公開されています。
プロジェクトでの私の役割
私の立場は、医療側と開発側のあいだに立つ「医師兼エンジニア」でした。
担当した仕事は、大きく三つに分けられます。
一つ目は、タスクの解釈です。
「カルテからレジストリを作る」という依頼は、そのままでは開発に着手できません。
どの項目を、どの記録から、どの規則で取り出すのかを決める必要があります。
私はこれまで関わった臨床研究やデータベース作成の経験をもとに、データ定義書と作成手順書のたたき台を作りました。
二つ目は、病院や医師との連携です。
作ったデータ定義書は、プロジェクトの担当者を通じて、レジストリを運用している大学病院の医師に確認してもらいました。正解データを作る段階では、アノテーションを担う医師を集める体制づくりにも関わりました。レジストリ側の日本語の項目名と、LLMが出力する英語のキーが食い違ったときは、対応表を作って両者をそろえました。開発側の「こう解釈してよいか」という問いを医師に向けた質問に直し、返ってきた答えを抽出規則やプロンプトに反映する役割を担いました。
三つ目は、実装と評価です。
患者の選定とアノテーション用の下書きの作成を担当し、評価を自動化するスクリプトと、退院時サマリーを評価する仕組みを作りました。
成果報告書に載せる集計資料の作成も担当しました。
医療現場で大変なこと
レジストリの登録は、多くの臨床医が日常的に抱えている負担です。
私自身、専門領域のがん登録のために、毎年数百人分のカルテを読み返してきました。
登録の対象となるがん種は複数あり、そのたびに一人ずつカルテを開いて、診断日、病期（がんの進行度）、治療内容を確かめて入力します。
カルテを読むこと自体は、それほど複雑な作業ではありません。
難しいのは、読んだ後に医師が下している判断で、読んだ後の解釈をデータベースに落とし込む思考のほうであると痛感しました。
退院時サマリーの作成も、同じ構造の作業です。
入院中の情報は、医師記録、看護記録、検査結果、処方の記録に分かれて残っています。退院時には、それらを探して読み、所定の項目と形式に合わせてまとめ直します。カルテに情報があることと、その情報を別の目的で使えることのあいだには隔たりがあり、医師はその隔たりを手作業で埋めています。
今回のタスクの医療現場での位置付け
脳卒中のレジストリは、患者が入院した時点で登録の対象かどうかが決まり、退院時にまとめて情報が更新されていく運用になっています。開発の初期、私たちは「まず候補をまとめて抽出し、確認してから登録する」という順序を想定していました。臨床側からこの実務の順序を指摘され、想定を見直しました。業務の流れを知らないまま作ると、技術的には動いても、現場の運用に組み込めない仕組みになります。
退院時サマリーにも、施設ごとの違いがありました。
共同研究先の医師からは、サマリーの書式は病院によってさまざまで、正解を一つに決めにくいと指摘されました。そこで、サマリーは一つの病院の書式を基準にして作ることにしました。
すべての施設の書式に合わせることを目指す前に、共通の型で何ができるかを確かめる判断です。
他の施設の書式にどこまで広げられるかは、今後の課題として残っています。
そのうえで、今回のタスクを次のように位置づけました。
| 段階 | 現在の担い手 | LLMに期待した役割 |
|---|---|---|
| 患者候補の抽出 | 医師が病名や記録から探す | 候補を絞り込み、医師の確認対象を減らす |
| レジストリ項目の入力 | 医師がカルテを読んで入力する | 項目ごとの下書きを作り、医師が確認して直す |
| 退院時サマリーの作成 | 医師が記録を読み返して書く | 構造化した情報からドラフトを作り、医師が修正する |
レジストリの項目は、実際のレジストリのスキーマを参考に、擬似的に構築しました。
実際のデータベースは1,000列を超えるため、そのまま再現するのではなく、提供された定義をもとに汎用化し、13セクション216項目にまとめています。
検証方法
医療分野の開発においては、実際の患者さんのカルテをそのまま開発環境に持ち込んで利用することはできません。
将来的には、国の指針などに沿った形で、病院内またはセキュアなクラウド環境で動かすことが望まれます。
そこで今回の検証では、事業での利用が認められた匿名加工データを調達して使いました。
対象データと処理の流れ
対象は、10病院の匿名加工電子カルテデータで約10万3,000人分の情報が格納されています。
これらにはさまざまな疾患が混じっており、まずは脳卒中患者の特定から行う必要がありました。脳血管疾患の治療で頻出する語句を検索して該当したレコード約21,300件を候補とし、LLMによる一次判定で急性期脳卒中の入院と判定された1,081件から、504件を最終的な確認の対象としました。
そのうち422件を確定症例とし、その中から選んだ300例について、医師3名（独立した2名のレビューと専門医の裁定）が正解データを作成しました。
匿名加工電子カルテデータ（10病院、約10万3,000人分）
↓ 脳血管疾患に関する語句で検索（約21,300件）
急性期脳卒中入院をLLMが一次判定（1,081件）
↓
最終確認（504件） → 確定症例（422件）
↓ 医師3名が独立レビューと専門医裁定
正解データ 300例（テスト30例、開発270例）
↓
13セクション216項目のレジストリ構造化
↓
14セクション約50項目の退院時サマリー生成
↓
医師が確認して修正
構造化では、セクションごとに専用のプロンプトを用意し、患者1名のカルテに対して複数回LLMを呼び出しました。一回の呼び出しにすべてを詰め込むより、処理を分けたほうが扱いやすくなります。
セクションごとに抽出規則を書けますし、誤りが起きた工程を切り分けやすくなるからです。
医師の暗黙の判断を、規則に書き直す
実装でいちばん時間を使ったのは、モデルの選定でもプロンプトの言い回しでもなく、項目の定義でした。
たとえば発症時刻です。
カルテには、発症時刻、最後に元気な姿が確認された時刻（最終健常確認時刻）、発見された時刻、来院した時刻が、別々の記載として残っています。脳卒中の急性期診療では、どの時刻を採るかが治療の判断に関わるため、医師は場面に応じて自然に使い分けています。
しかし、レジストリに登録する一つの発症時刻として、どれをどの優先順位で採るかを定義しなければいけません。
血圧なども同じです。
入院時、治療前、治療後で値が変わるので、どの時点の値を登録するかを決めないまま抽出を始めると、答えが安定しません。
また「欠損」と「解釈不能」の区別も重要です。
「カルテに記載がないこと」と、「不明」は、同じ欠測ではありません。
前者は記載漏れの可能性を残し、後者は確認したうえで判断できなかったことを示します。正解データを作る段階でも同じ問題が出ました。
空欄のままでは、作業者が入力を忘れたのか、カルテに記載がなかった、書いてあるが判断ができなかったのかを区別できません。欠測の表し方は項目の性質によって変わるため、項目ごとに決め、開発の途中でも何度か見直しました。
開発を進めるうちに、データそのものの性質も見えてきました。
退院時サマリーには書かれているのに、カルテの医師記録には書かれていない情報が、少なからずありました。
医師がサマリーを書くとき、医師記録以外の情報源から補っているということです。
また、ある症例ではカルテに2回分の入院が含まれており、LLMが目的の入院ではなく古い入院の記録からサマリーを作っていました。
アノテーションに参加した医師の試行評価で見つかった誤りで、「どの入院を対象とするか」を指示に明記して対応しました。
人間なら迷わない前提も、書かなければLLMには伝わりません。
最終的に、項目ごとに次の六つを決めました。
- 抽出の対象
- 根拠とする記録
- 記載が矛盾したときの優先順位
- 記載なしと不明の区別
- 出力の形式
- 医師のレビューに回す条件
この六つを決められない項目では、LLMに安定した精度で抽出させることはできません。
正解データを作るときも、評価するときも、同じ定義が必要になります。
レジストリ構造化の結果
項目単位の正解率は、最も高かったモデル（GLM-4.7）で92.2%でした。
人間の評価者2名は94.7%と95.1%で、差は約3ポイントです。
| モデル、評価者 | 全体正解率 | 正解に何らかの値がある項目 |
|---|---|---|
| 人間A | 94.7% | 82.9% |
| 人間B | 95.1% | 84.5% |
| GLM-4.7 | 92.2% | 73.8% |
| GPT-5.2 | 90.0% | 74.4% |
| gpt-oss-120b | 90.8% | 72.5% |
92.2%だけを見ると、かなりの作業を任せられそうに見えます。しかし216項目には、正解が「なし」の項目が多く含まれています。正解に何らかの値がある項目に限ると、LLMの正解率は72.5〜74.4%まで下がります。所見や治療が実際にある場面こそ、レジストリに残したい情報です。
その部分の正解率が7割台にとどまる以上、92.2%を「9割の項目は医師の確認なしで登録できる」と解釈することはできません。
一方、この結果には一定の意味があると考えています。カルテに記載のない情報をもっともらしく埋めず、「なし」として返せることは、医療記録を扱ううえで欠かせない性質です。
そのため、二つの正解率を並べて示しています。
実際、正解が「なし」の項目に限ると、GLM-4.7の正解率は95.4%で、人間の評価者（96.6%、95.4%）と同程度でした。この結果からは、LLMが「情報が存在しないこと」を正しく判断する力は高いことが示唆され、自動化可能な領域の1つであると考えています。
216項目を9つの臨床セクションに分けて見ると、難しさは一様ではありませんでした。
| セクション | GLM-4.7 | 人間平均 |
|---|---|---|
| 画像検査 | 95.8% | 91.7% |
| 診断情報 | 95.8% | 96.9% |
| 治療 | 95.7% | 96.9% |
| 転帰、合併症 | 90.6% | 93.0% |
| 危険因子 | 86.2% | 91.8% |
| 患者基本情報 | 83.3% | 93.1% |
| フォローアップ | 73.3% | 89.2% |
| 病歴、バイタル | 67.3% | 83.3% |
| 検査情報 | 57.1% | 73.8% |
診断情報や治療は人間に近い水準でした。
画像検査では、この評価条件のもとでLLMが人間平均を上回りました。
一方、病歴、バイタルと検査情報では、人間との差が大きく開きました。
項目単位でも同じ傾向でした。
選択式や有無を問う項目では高い正解率が出た一方、発症時刻は60〜67%、血圧は32〜37%、責任血管（脳梗塞の原因となった血管）の特定は38〜58%にとどまりました。
全モデルが誤った項目は261件で、評価行全体の4.3%です。
複数の病変、血圧などの数値の転記、発症時刻と来院時刻の統合、責任血管の特定が中心で、モデルを入れ替えても解決しない種類の誤りでした。
逆に、LLMが人間の評価者の見落としを補った項目も278件ありました。
人間とLLMのどちらか一方を採るより、両者を組み合わせたほうが取りこぼしは少なくなります。
誤り方の違いがレビューの設計を変える
正解率が近いモデルでも、誤り方は同じではありませんでした。
| モデル | エラー総数 | 値の取り違え | 過剰な抽出 | 抽出漏れ |
|---|---|---|---|---|
| GLM-4.7 | 474件 | 51% | 15% | 35% |
| gpt-oss-120b | 559件 | 47% | 22% | 31% |
| GPT-5.2 | 606件 | 37% | 19% | 43% |
この違いは、医師のレビューの設計に直結します。
抽出漏れは、必須項目が空欄になっていないかを機械的に調べれば見つけやすい誤りです。値の取り違えは、形式としては正しい値が入っているので、元の記録と突き合わせない限り気づけません。エラーの総数が少ないモデルでも、医師のレビューの負担まで少ないとは限りません。
追加学習モデルの比較から見えた課題
プロジェクトでは、医療データで追加学習したモデルも開発していました。
このタスクで比較すると、追加学習モデルの全体正解率は、対応するベースモデルを下回る場合が多くありました。
たとえば、gpt-oss-120bのベースモデルが90.8%だったのに対し、同じ系列の追加学習モデルは87.0%でした。追加学習モデルの中で最も高かったものでも89.5%で、これがベースモデルとの差が最も小さい例でした。
項目単位では、追加学習で正解率が上がる項目と下がる項目の両方がありました。
長いカルテから指定された情報を正確に取り出す能力を、追加学習でどう伸ばすかは、プロジェクトを通して見えてきた今後の課題です。
退院時サマリーの評価
退院時サマリーは、構造化した情報と過去のサマリーの書式をfew-shot例として入力し、14セクション約50項目のドラフトを生成しました。
30症例を対象に脳卒中の専門医が評価を行い、各症例につき3名が、正確性、ハルシネーションの抑制、読みやすさ、妥当性の四つの観点で採点しました。
総合平均が最も高かったモデル（GPT-5.2）は5点満点で4.809点でした。
読みやすさは平均4.934点（97.1%が5点）、妥当性は平均4.795点（91.6%が5点）で、どちらも満点付近に集中しており、天井効果がみられます。
その一方、モデル間の総合平均の差は最大でも0.276点だったのに対し、同じモデルに対する評価者間の差は最大0.673点ありました。モデルを入れ替えたときの差より、同じ文章を誰が採点するかによる差のほうが大きかったことになります。
文章が自然に読めることと、内容が正確であることは別の軸です。
医療現場では、読みやすい文章ほど確認しやすいとは限りません。
もっともらしい文章の中に少数の誤りが混じると、形式の崩れた出力より見逃しやすくなる場合があります。
項目別に見ると、家族歴（平均4.915点）や禁煙、飲酒の支援（4.859点）のような定型の項目は高得点で、評価者間のばらつきも小さくなりました。
一方、入院後の経過（4.337点）や抗血栓療法（4.485点）のように、時系列を統合して臨床的に判断する項目は、平均点が下がり、評価者間のばらつきも大きくなりました。
何が正しいサマリーかという基準そのものが、これらの項目では医師の間でもそろっていなかったと考えられます。ここに、サマリーという唯一の正解がないものを評価する難しさがあります。
LLM-as-a-Judgeをどう使うか
専門医による評価の手間は、症例数と評価者数の掛け算で増えていきます。
そこで、複数のLLMを評価者として使うLLM-as-a-Judgeも試しました。
LLMの評価と専門医の評価の相関はr=0.246〜0.386で、専門医の採点をそのまま置き換えられる水準ではありませんでした。
検証したLLMはいずれも専門医より厳しく採点する傾向があり、甘めより厳しめの方向に偏る傾向が目立ちました。
一方、記載すべき項目が書かれているかを確かめるチェックリスト形式の評価では、LLM評価者どうしの相関がr=0.99前後と非常に高くなりました。
網羅性を確かめる用途なら、LLMの評価は安定しているということです。
現場導入に残る課題
今回の結果は、匿名加工されたデータを使った技術的な実現可能性の評価の位置付けです。実際に運用するには、電子カルテやデータウェアハウスとの連携、欠測している情報を現場へ返す仕組み、医師がレビューしやすい画面、タスクごとのモデルの選び分けが必要です。
まとめ
今回の検証では、定型的な項目の抽出や記述について、医師のレビューを前提にした半自動化の技術的な実現可能性が示されました。
一方、時系列の統合、数値の転記、責任血管の特定のように臨床的な判断を要する項目には、規則を書いた後も課題が残りました。
医師兼エンジニアとしてこのプロジェクトに関わって、いちばん時間を使ったのは、医師が普段ほぼ無意識にしている判断を、対象、根拠、優先順位、例外、レビューの条件に分けて書き出す作業でした。
この経験から強く感じたのは、こうした設計はその分野に精通した人が担う必要があるということです。
どの判断が暗黙のうちに行われているのか、どこに例外が潜んでいるのかは、現場を知らなければ気づくことさえ難しいからです。同時に、現場の判断を、LLMや開発チームが扱える言葉に置き換える「翻訳者」の役割が、重要だと感じました。
モデルはこれからも更新されますが、人の仕事を言葉にし、何をLLMに任せ、何を人が確認するかを決める作業は、モデルが変わっても残り続けると想像しています。
私自身も、臨床と技術をつなぐ人材になれるように、医療LLM領域に取り組んでいきたいと思います。
謝辞
この成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の委託業務（JPNP25006）の結果得られたものです。
本プロジェクトは、多くの方々のご協力なしには実現しませんでした。
まず、日々の診療でお忙しいなか、規則づくりのための議論や出力のレビューに多くの時間を割いてくださった先生方に、心より感謝申し上げます。
また、データの準備や環境の整備を支えてくださった松尾研医療LLMチームの皆さまにも、深く御礼申し上げます。
最後に、この取り組みの根底には、カルテに記録を残してくださった患者さんの存在があります。
その一つひとつの記録が、より良い医療につながるよう、これからも努めてまいります。