0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

医師から見たJLAC11:検査データ標準化の課題と、LLMによる支援の可能性

0
Last updated at Posted at 2026-10-26

はじめに

はじめまして、長谷部です。耳鼻咽喉科・頭頸部外科の専門医で、病院の情報システム部門にも所属しており、医療に関わるさまざまなAIの研究に取り組んでいます。

松尾研の講座とコンペティションへの参加をきっかけに、短い期間ではありますが松尾研医療LLMプロジェクトに関わりました。私はあくまで医師であり、LLMの専門家ではありませんが、医療チームの一員として参加し、素晴らしい方々とともに貴重な経験をすることができました。その間に担当したユースケースの1つが「血液検査などの検査項目を標準コードへ対応付ける」というもので、本記事ではそこで得られた知見を共有します。

このユースケースのシステムはABEJAのチームとともに取り組んだもので、システムの全体設計やアプリ、評価結果はABEJAのテックブログ記事にまとめられています。私はその中で精度検証を担当しました。本記事では、医師・病院の情報システム部門の立場から見たJLAC11の解説と課題、そして精度検証で工夫した点を中心に紹介します。

概要

同じ検体検査でも、施設ごとに異なる名称や独自のコードが使われています。たとえば同じ検査が「AST」「GOT」「AST(血清)」などと登録され、検体材料、測定法、試薬、報告単位も施設や時期によって異なることがあります。
複数施設の検査データを共有・分析するには、こうした院内項目を標準コードへ対応付ける必要があります。今回のプロジェクトでは、病院の検査マスターから17桁のJLAC11コードの候補を提示するシステムを、国内3医療機関のデータを用いて複数のLLMで検証しました。

本記事では、次の点を中心に紹介します。

  • 検体検査のバラツキと、JLAC10からJLAC11までの標準化の経緯
  • JLAC11コードの意味と、試薬の違いが臨床的に持つ意味
  • 検査名だけではJLAC11コードが決まらない理由
  • 精度検証で工夫した点
  • 実運用と普及へ向けた課題、医療DXの中での今後の重要性

検体検査の実情

医療機関では診療にあたってさまざまな検査を行いますが、その中に血液検査、尿検査、髄液検査など「検体検査」と呼ばれるものがあります。病気になったことがない方でも、健康診断などで馴染み深い検査だと思います。

どこの病院で検査を受けても大体似たような項目が並びますが、細かく見ると施設ごとにかなり違いがあります。

名称が異なる

例を挙げればキリがありませんが、「赤血球/RBC」「尿素窒素/BUN」「AST/GOT」「LD/LDH」などです。医師であれば大抵慣れていますが、研修医の頃は結構戸惑ったものです。

単位が異なる

特に血算(全血球計算:CBC)は施設によって違うことが多い印象です。現在の勤務先では赤血球が $5.00 \times 10^{12}$/L のように表示されますが、$500 \times 10^{10}$/L や $500 \times 10^{4}/\mu$L のように表示する施設も多いのではないでしょうか。

測定法が異なる

分かりやすいのは血糖値でしょうか。病院で採血して検査室で測る血糖値と、家庭でも計測できる指先に小さな針を刺して測る簡易血糖測定器の血糖値は、同じ「血糖値」でも測定法が異なります。前者は自動分析装置で測定し、後者は電極で測定します。簡易測定器は手軽に測れるという利点がありますが、誤差が大きいので解析の際に常に同列に扱うことはできません。

標準化へ向けたこれまでの取り組み

前項で挙げたバラツキは、単一施設であればほぼ問題になりません。しかし、複数施設で情報を共有したり、検査データを研究に用いたりする場合には問題になります。そのため、検査項目コードの標準化は古くから進められてきました。主な経緯を整理すると、次のようになります。

時期 出来事
1960年代 日本で臨床検査項目分類コードの検討が始まる
1997年 第10回改訂版であるJLAC10が公表される
2016年 JLAC11の初版が公表される
2025年以降 電子カルテ情報共有サービスや医療DXでの二次利用を見据え、JLAC11を標準仕様へ位置づける動きが進む

歴史は古いのですが、中心的な役割を担ってきたのは1997年から使用されているJLAC10です。電子カルテが普及した時期でもあるため、それに合わせて普及したのではないかと推測します。

JLAC10が果たした役割と、残った課題

JLAC10は、「分析物(5桁)・識別(4桁)・材料(3桁)・測定法(3桁)・結果識別(2桁)」の5要素、最大17桁で構成されます(各要素の詳細は、後述のJLAC11との比較表で示します)。依頼時には原則として最初の4要素、結果報告時には結果識別を加えた5要素を使います。検査名だけでなく、検体材料、測定法、結果の表現を分けて記述できる点はJLAC10の強みでした。

一方で、JLAC10には長年指摘されてきた課題もあります。

① 組み合わせの自由度が高い
5要素を施設側で組み合わせる設計は表現力が高い反面、担当者や施設によって材料・測定法・結果識別の選び方が変わりやすくなります。同じ検査に別のコードが付いたり、逆に別の検査に同じコードが付いたりする事例が、医薬品安全対策のためのデータ標準化でも報告されています。

② コードに単位が含まれない
JLAC10の末尾2桁は「結果識別」であり、単位ではありません。そのため、JLAC10コードが一致しても、数値をそのまま施設間で比較できるとは限りません。前項で述べた赤血球の例のように、単位が違えば同じ数値でも意味が変わります。

③ マッピングに専門知識が必要
特に材料コードと測定法コードの判断には、臨床検査とJLACの双方の知識が必要です。

これらはJLAC11ですべて解決されたわけではありませんが、少なくとも改善はされています。

JLAC11で何が変わったか

JLAC11はJLAC10の課題を踏まえて策定されており、目的も追加されています。

JLAC10の目的:医療機関同士の情報交換(一次利用)

臨床検査項目分類コードは、医療情報システムの普及や医療機関同士の情報交換を円滑に行うため、医療情報システムが標準的に使う検査項目コードとして設定されたものです。つまり、診療の現場でシステム間・施設間をつなぐ「共通の項目コード」が出発点です。

JLAC11の目的:検査データの二次利用

一方、JLAC10は施設間の情報交換という観点ではそれほど普及しませんでした。その間に、特定健診や生活習慣病などで集めた検査データの分析や、MID-NETによる副作用情報の分析といった二次利用のニーズが生まれました。そこで学会は、検査データの二次利用に有効に使えることを主目的として、JLAC11の開発に着手しています。

JLACセンターは、JLAC11の主目的を「急速に発展する医療DXにおいて検査データの2次利用ができること」と説明しています。

コード構成の変化

JLAC11も17桁・5要素ですが、各要素の意味は次のように変わりました。ASTを例に、JLAC10とJLAC11のコードを並べます。

第1要素
(5桁)
第2要素
(4桁)
第3要素
(3桁)
第4要素
(3桁)
第5要素
(2桁)
JLAC10 3B035 0000 023 272 01
分析物 識別
(※1)
材料
(※2)
測定法
測定法分類のコード
結果識別
(※3)
JLAC11 C2008 0000 250 035 F7
測定物
先頭文字は英字
識別
(※1)と(※3)から構成
材料
(※2)をさらに細分化
測定法
測定物に紐づく固有のコード
体外診断用医薬品の場合
測定法×商品名で特定
結果単位
結果の値の単位
AST - 血清 Lタイプワコー
AST・J2
U/L

JLAC11コード「C2008-0000-250-035-F7」は、「AST(検査項目)の血清を(材料)としてLタイプワコー AST・J2(試薬)を用いて定量測定した(U/L)結果値」を意味します。

JLAC11コードは、次の情報の組み合わせで特定されます。

 検査項目   ×   体外診断用医薬品の商品名   または   検体検査用医療機器の販売名   ×   材料   ×   結果単位 

JLAC10とJLAC11は要素名が同じでも分類コードが異なります。分類コードの設計が異なるため、JLAC10とJLAC11は1対1に対応しません。JLAC11コードからは相当するJLAC10コードを特定できますが、逆は不可能です。

出典:JLACセンター「JLAC11コードについて」の図・本文をもとに作成

実務上、特に重要な変更は次の2点です。

  1. 測定法コードが、試薬まで含めた測定系を表すようになった
    JLAC10の測定法は方法の分類に近いものでしたが、JLAC11では試薬まで含めて識別するため、同じASTでも試薬が違えば別コードになります。そのぶん細分化されますが、使用している試薬さえ同定できれば一意に定まり、担当者間でのブレがなくなります。
  2. 末尾2桁が、結果識別から結果単位へ変わった
    単位がコードに含まれるため、単位が異なっていても「どう変換すればよいか」まで分かり、解析の際に手動で単位を修正する必要がなくなります。

一方で細分化されるため、「実質的には同じ検査として扱ってよいのに、違うコードになっている」という状況が発生します。そのため多施設で統合して解析する場合は、コードをそのまま用いるのではなく、グループ化して扱うなどの工夫が必要です。

試薬の違いは臨床的にどのくらい問題になるのか

では、試薬が違うとどのくらい困るのでしょうか。これは検査項目によってまったく異なります。臨床の立場から、代表的な例を挙げます。

検査項目 試薬・測定法による違い 多施設で統合するときの扱い
AST・ALTなど JSCC標準化対応法が普及しており、試薬が違っても測定値の差は小さい 試薬違いのコードをまとめて扱いやすい
ALP・LD 2020年4月に、JSCC法からIFCC法への切り替えが始まった。ALPは測定値・基準範囲ともにJSCC法のおよそ1/3になった(LDは基準範囲は据え置きだが、検体によっては値が変わる) 特にALPは、測定法を区別しないと施設間だけでなく同じ施設の時系列でも値が比較できない
D-ダイマー 試薬間の標準化が進んでおらず、同じ検体でも試薬によって測定値が大きく異なる 数値をそのまま比較するのは危険。試薬ごとに扱う必要がある
トロポニンI メーカーごとにアッセイが異なり、心筋梗塞診断のカットオフ値もアッセイごとに異なる 数値の単純比較は不可。「カットオフ超えか」などに変換して扱う必要がある

つまり、JLAC11の細分化は「やりすぎ」なのではなく、D-ダイマーやトロポニンのような項目では臨床的に必要な区別です。一方でAST・ALTのような項目では、細分化されたコードを解析時にまとめ直す必要があります。

どのコード同士なら同じものとしてまとめてよいかは、コード体系を見ているだけでは分かりません。試薬の標準化状況や臨床での使われ方を知らないと判断できないため、多施設データを統合するときには、臨床検査技師や医師などの知見を入れてグループ化のルールを決めることが重要です。

JLAC10からJLAC11は一意に決められない

前述のとおり、既存のJLAC10コードだけでJLAC11を決めることはできません。院内マスターに戻り、少なくとも検体材料、試薬・測定法、結果単位を改めて確認する必要があります。院内マスターに検査名と単位はあっても、試薬販売名、承認・認証番号、測定装置が含まれないことも多いので、その場合は別途、発注管理システムなどから取得する必要があります。

公開範囲も、まだ全検査を網羅しているわけではありません。2026年9月時点の公式JLAC11 17桁コード一覧は、電子カルテ情報共有サービス対象の検査43項目と感染症5項目が中心です。厚生労働省も、JLAC11は検査頻度ベースではおおむねカバーしているものの、検査種類ベースでは十分ではないと指摘しています。

評価対象を院内の全検査へ広げると、モデルの選択以前に、正解コード自体が未整備というケースが混在します。私も数か月の検証期間中に、最新のコード一覧への更新作業を2〜3回行いました。

システムの概要と、精度検証で工夫したこと

システム全体の流れ

システムは、試薬・検査機器の情報を起点にJLAC11コードの候補を絞り込み、医療特化LLMが院内の検査項目名称と突き合わせて候補を提示し、最終的には人が確認して確定する、という流れです。試薬の特定には、試薬名の文字列照合(ファジーマッチング)と、試薬のバーコードからPMDAのデータベースで承認・認証・届出番号を引く方法の2つが用意されています。詳細はABEJAの記事をご覧ください。

私が担当したのは、このシステムのLLMによる突合部分を、3施設のデータと複数のモデルで評価する精度検証です。ここからは、その中で工夫した点を紹介します。

1. 病院ごとのデータ形式を吸収する

検証対象となった3施設では、ファイル名、シート名、ローカルコード、検査名称の列がそれぞれ異なっていました。
そこで、施設ごとの設定をデータローダーへ分離し、後段の処理では次のような共通形式を扱えるようにしました。

{
    "local_code": "施設内の検査コード",
    "test_name": "正規化した検査名称",
    "reagent_name": "試薬販売名",
    "correct_jlac11": "評価用の正解コード",
}

2. 複数の推論基盤とモデルを同じ手順で評価する

外部APIとプロジェクト内の推論サーバーを、同じインターフェースから呼び出せるようにしました。
長時間の評価では、通信障害やレート制限、推論サーバーの一時停止が起こります。そこで、項目ごとに途中経過を保存して中断後は続きから再開できるようにし、レート制限時は待機して再試行する仕組みを入れました。これにより、一部の処理が止まっても評価を最初からやり直さずに済みます。
また、LLMの応答は常に安定するとは限らず、JSONの前後に説明文が付く、出力例の雛形をそのまま返す、thinkingモデルで回答欄が空になるといった崩れが起こります。そのため、JSONの抽出・整形や再試行の処理を入れ、thinkingを抑制する設定も加えました。生の応答と解析結果は保存しておき、異常時に原因を追えるようにしています。

3. 不一致がどこで生じたかを切り分ける

正解率だけを見ても、どこを改善すべきかは分かりません。そこで、不正解を次の3種類に分けました。

分類 状況 見直す対象
① コード表への未収載 正解コードが、評価に使用したJLAC付帯コード表に存在しない コード表の版・公開範囲、正解データ
② 候補絞り込みの漏れ 正解コードは付帯コード表に存在するが、候補絞り込みで除外された ファジーマッチングの閾値、表記正規化、試薬との対応付け
③ LLMの選択ミス 正解コードが候補に含まれているのに、LLMが別のコードを選んだ プロンプト、候補に含める情報、モデル選択

①はLLMの選択ミスではありません。コード表の版や公開範囲、正解データ自体を確認する必要があります。
さらに、17桁コードを「測定物・識別・材料・測定法・結果単位」に分解し、どの要素で誤ったかを確認できるようにしました。

精度検証から見えたこと

モデルごと・施設ごとの正解率は、ABEJAの記事に掲載されています。ここでは、検証を通じて重要だと感じた点を紹介します。

施設による差が大きい

同じモデルでも、施設によって正解率に大きな差が見られました。
原因として、院内名称の付け方、試薬情報の充実度、ローカルコードの構造、正解データの整備状況の違いが考えられます。1施設で高い精度が得られても、別施設へそのまま適用できるとは限りません。

thinkingモデルが常に有利とは限らない

一部のthinkingモデルでは、推論が長く続いてJSON形式の回答に到達しないケースがありました。
この結果から、構造化された候補選択では、医学知識だけでなく、指示追従、簡潔な出力、JSONの安定性、推論モードの設定が性能を左右することが分かりました。

医療LLMプロジェクトで試作したLLMは成績が良かった

医療LLMプロジェクトで開発したモデルは、元になったベースモデルを上回る正解率を示しました。検査名称には日本独自の略称が用いられている場合もあり、日本語の医療に特化して学習したモデルだと、その解釈がうまくいったのではないかと考えています。

実運用へ向けた今後の課題

今回の検証から、実運用へ向けて次の課題が明確になりました。

入力不足を無理に推定しない

検査名だけで材料や測定法を判断できない場合、モデルに推測させるべきではありません。「追加情報が必要」として人手確認へ送る仕組みが必要です。

JLAC11コードの付番は、毎日行う作業ではありません。ただし、一度やれば終わりというわけでもありません。JLAC11の測定法コードは試薬に紐づくため、試薬や測定機器を変更するたびに付番し直す必要があります。検査室では、コスト、供給、性能などの理由で試薬の切り替えは珍しくありません。
つまり付番は「頻度は低いが、試薬変更のたびに発生し続ける作業」です。たまにしか発生しない作業は担当者にノウハウが残りにくく、担当者が替われば判断基準もぶれやすくなります。こうした作業こそ、候補の提示と根拠の整理を支援するツールが役に立つ場面だと考えています。

運用にあたっては、速度より正確性を第一とし、候補とした理由も提示したうえで、あくまで人間の判断を補助するという位置づけにすべきです。試薬の変更履歴と付番結果を対応付けて残しておけば、過去データとの連続性を確認するときにも役立ちます。

そもそも使ってもらえるのか

これは本システムの課題ではなく、それ以前の課題なのですが、JLAC11コードを使う明確なメリットは、現状では医療機関にはほとんどありません。医療機関ごとに独自のマスターが存在しており、通常業務はそれだけで十分だからです。私自身も、本プロジェクトに関わるまでJLACコードの存在を知りませんでした。電子カルテで日常的に目にするものではないからです。

臨床研究においても検査項目は絞って収集することが多く、人手で多施設データを突合しているケースがほとんどかと思います。医療連携においても紙ベース(紹介状)でのやり取りが圧倒的に多く、そもそも検査結果をデータとしてやり取りする仕組みが普及していません。しかし、後述するように標準化は極めて重要だと考えます。

医療DXの進展で、対応付け作業はさらに重要になる

前半で述べた「多施設になると困る」という問題は、制度の整備によって現実の課題になりつつあります。国はいま、医療データを施設の外で活用する仕組みを急速に整えています。

1つは電子カルテ情報共有サービスです。全国の医療機関で傷病名、アレルギー、検査結果などを共有する仕組みで、傷病名にはICD10対応標準病名マスター、検査にはJLAC10またはJLAC11が採用されています。つまり、院内のデータを標準コードに対応付けていなければ、そもそもこの仕組みに乗れません。

もう1つは次世代医療基盤法です。医療機関から集めた医療情報を、国の認定を受けた事業者が加工し、研究開発に提供する仕組みを定めた法律で、2018年に施行されました。2024年4月の改正法施行では、データの改変を最小限に抑えた「仮名加工医療情報」が創設され、NDB(レセプト情報・特定健診等情報データベース)などの公的データベースとの連結解析も可能になりました。私自身も、研究の一環として近いうちに解析を進めてみたいと考えています。多施設のデータを集めて解析する以上、施設ごとにバラバラなコードのままでは、どれだけデータが集まっても正しく比較・統合できません。

データを共有・活用する制度が整うほど、その入口である「院内データを標準コードへ正しく対応付ける作業」の重要性は増していきます。一方で、この作業の負担は非常に重いため、LLMを使ってこの作業を支援することは、医療データ利活用の土台づくりとして、今後ますます重要になると考えています。

所感

JLAC11、普及すると良いですね。私の施設ではどうなっているでしょうか。ちょっとマスターを覗いてみましょう。
image.png
……JLAC10のみでJLAC11は未付番です。まだまだ普及にはほど遠いかもしれません。余計なことを言うと「じゃあお前がやれ」と言われそう。
検査部によるとJLAC10はほぼ全ての検査項目に対して付番が可能なのに対して、JLAC11ではまだそこまでカバー出来ていないというのも一因のようです。

まとめ

JLAC11は試薬まで含めてコードが決まるため、院内の検査マスターを対応付けるには、検査名だけでなく試薬・材料・単位まで確認する必要があります。そのため、LLMにコードを生成させるのではなく、候補を絞り込んだうえで人の判断を支援する設計が重要です。

私は精度検証を担当し、3施設の異なるデータ形式の共通化、複数の推論基盤とモデルを比較できる評価基盤の構築、エラー原因の切り分けを行いました。その過程で、次の知見を得ました。

  • 施設ごとのデータ設計が精度に大きく影響する
  • モデル性能だけでなく、構造化出力の安定性が重要である
  • 誤りを「マスター」「検索」「選択」の問題に分けて考える必要がある
  • 実運用では、入力情報が不足する項目を人手確認へ回す設計が必要である

また医師の立場からは、試薬の違いが持つ臨床的な意味や、試薬変更のたびに付番が必要になる運用面の課題を踏まえて、標準化を進めていく必要があると感じました。

医療データの標準化という高い目標に向けて、少しでも寄与できたら嬉しいです。

参考資料

謝辞

この成果は、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)の委託業務(JPNP25006)の結果得られたものです。

また、松尾研医療LLMプロジェクト、株式会社ABEJAをはじめ、関わったすべての方々に深く御礼申し上げます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?