はじめに

ABEJAは、さくらインターネット株式会社ら関係10機関とともに、NEDOが推進する「日本語版医療特化型LLMの社会実装に向けた安全性検証・実証」事業に参画しました。医療特化型LLMの開発を軸に、ユースケース検証や事業化を進める取り組みです。ABEJAは、学習用データの調達、ユースケースの具体化、アプリケーション開発といった実行面を担当しました。

本記事では、そのユースケース検証の1つ、ローカル検査マスターのJLAC11コードへの変換（マッピング）を紹介します。アルゴリズムの検証からアプリ実装まで、どんな課題があり、LLMをどう活用したのかをお伝えします。

背景：なぜ医療データの「標準化」が必要なのか

電子カルテに代表される医療データを、医療機関をまたいで共有・二次利用できれば、その価値は大きいものになります。患者ごとに最適化された医療はもちろん、研究開発やAIモデル構築にも活きます。しかし電子カルテはベンダーごとにデータ形式が異なり、施設をまたいだ連携は長らく困難でした。

この壁を越える国の取り組みが「電子カルテ情報共有サービス」です。HL7 FHIRという国際標準規格でデータを標準化し、全国の医療機関間で診療情報を共有できるようにするもので、2026年度冬ごろの全国運用開始に向けて整備が進んでいます（執筆時点）。

私たちが着目したのは、このサービスの中で「検査情報」と「感染症」（※）のデータをHL7 FHIRへ変換する処理です。検査情報をFHIRの標準形式（リソース）に変換するには、その前提として各検査項目を標準コードのJLAC11（日本臨床検査医学会が定める臨床検査項目分類コードの最新版）に対応づける必要があります。JLAC11へのマッピングなしに、FHIR形式への変換は成立しません。単純なフォーマット変換に見えて、実際は表記ゆれ、単位・基準値の扱い、検体や手法による粒度差など、泥臭く調整が必要な課題が山積みです。

（※）ここでの「感染症」は、HIVやB型・C型肝炎など診療上特に重要な感染症の検査情報を指します。データの性質は検査情報と共通するため、本記事では両者をまとめて「検査情報」と呼びます。

とくに検査領域では、各医療機関が独自の「院内コード（ハウスコード）」で検査項目を管理していることが多く、ここがマッピングの大きな課題になります。同じ「血糖」でも、施設ごとに別のコードや名称が使われ、統一されていません。

ここで大事にしたのは、単なる自動変換ではなく、レビュー担当者が判断できる出力（候補・確信度・根拠）を出すことです。完全自動化は目指さず、人間の判断を支援する設計にしました。

扱うデータの概観

マッピングに登場するデータは、マッピング先（標準コード体系）とマッピング元（医療機関のデータ）に分かれます。

JLAC11コードとは（マッピング先の標準コード体系）

なぜマッピングが難しいのか。それは、マッピング先であるJLAC11コードの構造を知ると見えてきます。

JLAC11は臨床検査の標準コード体系で、1つの検査を5要素の組み合わせで一意に表します。

測定物（分析物）: 何を測るか（カルシウム、アルブミン、グルコースなど）
識別: 定性/定量の区別など
材料: 何から測るか（血清、尿、髄液など）
測定法: 測定物に対する測定方法・測定系
結果単位: 結果の表現（mg/dL、U/Lなど）

この5要素を連結した17桁がJLAC11コードです。「血糖」（測定物はグルコース）の例はこちらのようになります。

測定物	識別	材料	測定法	結果単位
C4001	0000	250	033	85
グルコース	なし	血清	(概ね)試薬に対応	mg/dL

標準コード側でも、材料が血清か尿か、どの試薬で測ったかによって別コードになります。とくにやっかいなのが「測定法」です。これは酵素法・電極法のような一般的な手法分類ではなく、市販の検査試薬（測定系）ごとに割り当てられた固有コードです。コードを一意に決めるには、最終的にどの試薬を使ったかまで分かる必要がある、これがマッピング最大の難所につながります。

この対応関係を引くための参照表が付番コード表です。日本臨床検査医学会の検査項目コード委員会が公開し、JLACセンターも参照する、市販試薬とJLAC11コードの対応辞書にあたります。試薬さえ特定できれば候補は一気に絞れますが、後述のとおり試薬情報が得られないケースが多いのが悩みどころです。

なお、付番コード表を含むJLAC11関連マスタは継続的に更新されます。実運用では、参照したマスタの正式名称・版・取得日・対象範囲を明示して扱う必要があります。

医療機関側のデータ（マッピング元のデータ）

マッピング元となる医療機関のデータには、いくつかの難しさがあります。

1つは、保存形態が施設ごとに違うことです。同じ「検査マスター」でも、カラムもテーブル構造もコード体系も異なります。テーブル同士をどのキーで結合できるかも、ER図を読み解いてようやく分かることがあり、受け取ってすぐ使えるとは限りません。

もう1つは、データの取り出しに調整が要ることです。電子カルテからのエクスポート制約、検査室システムと電子カルテの分断、IT部門や検査部門との調整など、「技術的にはできるはず」と「実際に手元に来る」の間にはギャップがあります。

検査マスター

医療機関が管理する検査項目の一覧です。持っている情報は施設によって差が大きく、試薬マスタと紐づいているケースもあれば、検査名称中心のケースもあります。

以下は説明用の架空例です（院内コード・検査名称は架空、対応するJLAC11コードは付番コード表に収録された実値）。

院内コード	検査名称	材料	JLAC11コード（付番コード表より）
EX-00201	グルコース（血糖）	血清	C4001-0000-250-033-85
EX-00201	グルコース（血糖）	血漿	C4001-0000-240-033-85
EX-00201	グルコース（血糖）	尿	C4001-0000-100-033-85

ポイントは、院内コードとJLAC11コードで粒度が違うことです。院内コードは「グルコース（血糖）」を1コードでまとめて管理しますが、JLAC11は材料や測定法ごとにコードが分かれます。上の例では同じ EX-00201 に材料違いの複数レコードがあり、それぞれ別のJLAC11コードを当てる必要があります。院内コード1つにJLAC11コードがN個対応する「1対N」の関係であり、単純な変換テーブルでは済みません。

同じ試薬（測定法コード 033）でグルコースを測ったケースで、変わるのは中央の材料コードだけです（血清:250 / 血漿:240 / 尿:100）。院内コードで1つだった「グルコース（血糖）」が、標準コードでは材料ごとに別々の17桁に展開されます。

この粒度差は、単に複雑というだけの話ではありません。日常業務を回すだけなら、院内コードの粒度で足りる施設もあります。それでもJLAC11の細かい粒度に展開するのは、医療機関横断の二次利用を見据えているからです。院内業務では明示的に管理されない区分まで補い、標準粒度に合わせて取り込む作業であり、ここがマッピングの難しさをいっそう際立たせます。

試薬マスタ

使用している試薬の一覧で、JLAC11コード特定の最有力の手がかりです。ただし、電子カルテではなく検査室システムで管理されていたり、外部委託先にしか情報がなかったりと、取得が難しいデータでもあります。

検査名称	試薬名	装置名	JLAC11コード（付番コード表より）
尿蛋白（定性）	Comburテスト	-	C1002-0000-100-074-02
白血球数	-	Alinity h システム	B1002-0000-211-569-G1
ヘモグロビン	-	Alinity h システム	B1004-0000-211-569-55

これは検査名称・試薬名・装置名・JLAC11コードまで揃った、比較的リッチな例です。実際には、試薬名と検査名称が別システムにあり、両者の紐づけ（どの検査でどの試薬を使うか）が存在しないケースもあります。

理想は、要素を最も確実に絞れる試薬・検査機器情報を起点にすることです。しかし、それが常に手に入るとは限りません。そこで今回は、試薬・機器情報があればそれを軸に絞り込み、なければ多くの施設で得やすい「検査名称」を手がかりに候補を出す、という両にらみのアプローチをとりました。次章で具体的な処理フローを説明します。

アプローチ：試薬・検査機器情報を起点にしたマッピング

有識者・先行医療機関へのヒアリング

設計にあたっては、まずJLAC11に詳しい有識者や、すでに対応を進めている医療機関にヒアリングしました。机上でアルゴリズムを考える前に、標準化の実務で何が効き、何が難所になるのかを押さえるためです。

なぜ「試薬・検査機器情報」を起点にするのか

ヒアリングと公開情報から見えてきたのは、試薬・検査機器の情報を起点にすれば、JLAC11コードの多くの要素を一意に決められるということでした。

理由は前章で触れたJLAC11の構造にあります。第4要素の測定法コードは、個々の検査試薬（体外診断用医薬品）や検査機器に紐づく固有コードです。医療データ活用基盤整備機構（IDIAL）のJLACセンターも、JLAC11コードは「検査項目 × 体外診断用医薬品の商品名（または検体検査用医療機器の販売名）× 材料 × 結果単位」で特定されると整理しています（出典：医療データ活用基盤整備機構 JLACセンター「JLAC11コード」https://www.idial.or.jp/jlac_eleven.html ）。

どの試薬・機器で測ったかが分かれば、測定物・材料・測定法・結果単位をかなりの精度で絞れます。検査名称だけからコード全体を推測するより、はるかに確実です。そこで今回は、この試薬・検査機器情報を軸にマッピングを設計しました。

システムフローの全体像

採用した処理フローが次の図です。

左端が入力データで、「病院データ」と「外部データ」に分かれます。

病院データ：検査マスターの検査項目名称、体外診断薬・検査機器の一覧
外部データ：PMDA（医薬品医療機器総合機構）のデータベース、JLACセンターの付番コード表

処理は、2つの経路が合流する形です。

試薬・機器からJLAC検査名称候補を絞り込む経路：病院の検査試薬・検査機器一覧をPMDAデータベースで検索し、承認・認証・届出番号を特定します。その番号を付番コード表で変換し、対応するJLAC検査名称にたどり着きます。試薬・機器が特定できれば多くの要素が絞れるため、確度の高い土台になります。
検査名称をLLMで突合する経路：病院側の検査項目名称と、上で得たJLAC検査名称をLLMが突合し、変換候補を出します。院内独自の名称とJLAC側の付番コード表に記載されている名称は文字列として一致しないことが多く、この「名寄せ」にLLMが効きます。

2経路を経て、LLMが「JLAC11コード候補」を出力します。ポイントは、候補をそのまま最終結果にせず、人のレビューを挟んで確定する設計にしたことです。

なぜ完全自動化ではなく「人の判断」を挟むのか

最終確定に人手を挟むのは、病院固有の情報が残るからです。ヒアリングでも、次のようなケースが確定を難しくすると分かりました。

1つの試薬・機器が複数の検査に対応する：候補は絞れても、その施設でどの検査に使うかは運用次第
利用単位が標準と異なる：結果単位コードの確定には、その施設が実際に返す単位の確認が要る

こうした「その施設でしか分からない情報」が残るため、LLMは確度の高い候補提示に徹し、最終判断はレビュー担当者に委ねる構成にしました。前段の「完全自動化ではなく人間の判断を支援する」方針を、そのまま処理フローに落とし込んだ形です。

試薬・機器からJLAC検査名称候補を絞り込む2つの方法

候補の絞り込みをどう実装したか。入力データの状況に応じて、2つの方法を用意しました。

方法1：検査名称ベース（ファジーマッチング）

医療機関側の検査名称や試薬名をクエリに、付番コード表の販売名称と文字列類似度でマッチングして候補を絞る方法です。類似度には、レーベンシュタイン距離（2つの文字列を一致させるのに必要な編集回数を距離とする指標）ベースのファジーマッチングを使います。

マッチングのキーには、検査名称より試薬名を優先します。付番コード表側の販売名称は製品名で表記が安定しており、検査名称より揺れが少なく、文字列類似度と相性がよいためです。前処理として全角・半角の統一、記号削除、小文字化といった正規化を挟み、表記揺れを吸収します。

試薬名リストが得られれば、それを付番コード表の販売名称と直接マッチングできます。試薬名がなく検査名称しかない場合は、検査名称同士をLLMで突合して候補を出します。当然、試薬名がある場合とない場合では、絞り込みやすさに差が出ます。

この方法の強みは、バッチ処理できることです。試薬名・検査名称のリストをまとめて受け取れば、全項目の候補生成を一括で回せます。1件ずつ処理する手間がなく、医療機関側の負担も小さいため、初期検証や大量項目の一括マッピングに向きます。

方法2：バーコードベース（GS1-128スキャン）

方法1は、試薬・検査機器の一覧が整備されていることが前提です。しかし施設によっては、一覧がない、あるいは検査マスターと紐づいていないこともあります。その場合の方法が、試薬・機器のバーコードから情報を取得し、JLAC11の同定に必要な情報を現場で補うアプローチです。

バーコードを読むのは一見遠回りですが、バーコードは試薬の箱や機器そのものに物理的に付いており、検査室の担当者なら容易にアクセスできます。整備された一覧がなくても、現物さえあれば情報を引き出せる。この「現場での取得しやすさ」も、ヒアリングで有効だと確認できた点です。

処理の流れはこうです。

バーコード読み取り：試薬・機器のバーコード（GS1-128）をスマートフォンでスキャンし、GS1コードを取得する
外部マスタ参照：識別子をキーにPMDA（医薬品医療機器総合機構）などを検索し、承認・認証・届出番号などの手がかりを得る
付番コード表の絞り込み：得た番号で付番コード表をフィルタし、候補を絞る
LLMによる候補提示：絞った候補の順位・確信度・根拠をLLMが提示する

強みは、承認・認証・届出番号という強い手がかりで絞れることです。方法1のファジーマッチングより表記揺れに影響されにくく、候補を絞りやすくなります。「スキャン → 候補提示 → 人が確認」の流れをそのままUIに落とし込みやすく、現場運用との親和性も高い方法です。

2つの方法の使い分け

方法1は負担が小さく一括処理向きですが、一覧の整備が前提で、表記揺れの影響を受け候補を絞りきれないことがあります。方法2は一覧がなくても現場で補え、候補を強く絞れますが、スキャン運用のハードルがあります。どちらか一方が万能ではなく、施設のデータ整備状況（一覧の有無、バーコードへのアクセス可否）に応じて使い分ける、あるいは併用するのが現実的です。

検査名称をLLMで突合する精度の評価

評価の観点

本事業で開発した医療LLMで、JLAC11マッピングの精度を検証しました。データは、参画医療機関である東京科学大学・国際医療福祉大学・藤田医科大学から提供いただいたものを使用しました。精度検証は、医療LLM開発を行った東京大学・東京科学大学にて実施いただきました。表はLLM突合段階の正解率を示しており、LLMへの入力情報からは断定できない要素があるため、LLMが正解を含む候補を提示できれば正解としています。

検証結果

表：本事業の追加学習モデルの精度(※括弧内の数値はベースモデルとの差分を表す)

モデル	藤田医科大学	国際医療福祉大学	東京科学大学
Weblab-MedLLM-GLM-4.7（thinking）	72.0%（+4.0）	70.4%（+5.6）	80.3%（+9.8）
Weblab-MedLLM-Qwen3-235B-Instruct	70.0%（+2.0）	63.0%（+11.1）	52.5%（+16.4）
Weblab-MedLLM-GLM-4.7	70.0%（+2.0）	68.5%（+3.7）	65.6%（-4.9）
medical-swallow-gpt-oss-120b	64.0%（+2.0）	71.7%（+5.7）	78.7%（+1.7）
Weblab-MedLLM-gpt-oss-120b	58.0%（-4.0）	58.5%（-7.5）	53.3%（-23.7）
medical-qwen-32B	53.5%	38.0%	37.5%
Weblab-MedLLM-Qwen3-235B-Thinking	2.0%（-66.0）	9.3%（-42.6）	11.5%（-24.6）

ベースモデルによる差はあるものの、おおむね70〜80%の正解率で候補を提示できました。また、医療特化の追加学習によって精度が改善することも確認できました。

アプリ評価

マッピングのアルゴリズムを、現場で使えるアプリケーションとして実装しました。ここでは、想定業務フローと実際の画面を紹介します。

アプリを使った想定業務フロー

マッピングは処理単体で完結せず、医療機関の担当者とアプリ運営者（今回の場合はABEJA）側の運営が関わる一連の業務です。アプリは、この業務フロー全体を支えます。全体像は次の図のとおりです。

登場するのは4つのプレイヤーでシステム管理者（電子カルテ／検査システム側の担当）、検査技師（アプリを操作するユーザー）、アプリ（医療LLMを搭載したもの）、アプリ運営（ABEJA）となります。処理は左から右へ、「準備」「採番」「反映」の3フェーズで進みます。

① アプリ利用の準備

必要なデータを揃える段階です。システム管理者が自院の検査マスターから検査項目の名称一覧を出力し、検査技師が診断薬（バーコード）や検査機器の一覧を用意します。これらはアプリのバックエンドに取り込まれます。あわせて、ABEJA側が外部データ（JLAC付番コード表・PMDAデータベース）を入力します。前章の「病院データ」と「外部データ」が、ここで出そろいます。

② アプリの操作による採番

候補を出す段階です。検査技師が診断薬一覧を入力する、またはバーコードを読み取ると、アプリが検査マスターとJLAC11コード候補を突き合わせて出力します。前章の「方法1」「方法2」が、実際のアプリ操作として現れる部分です。出た候補は自動確定せず、検査技師が人手でチェック・修正して最終化します。「人の判断を挟む」設計が、そのまま業務フローに組み込まれています。最終結果は、アプリがアウトプットファイルとして出力します。

③ 検査システムへの反映

システム管理者が、アウトプットファイルをもとに自院システム上でJLAC11コードの紐づけ入力・改修を行います。これで、院内の検査マスターに標準コードが対応づけられます。

ただし、今回検証でアプリが対応できるのは②までとなります。③については電子カルテや検査システムのベンダーなどと協力して別途体制を組む必要があります

アプリの画面と機能

ABEJAは、このマッピングをWebアプリケーションとして開発しました。スマートフォンやPCのブラウザから操作できます。ここでは、「方法2：バーコードベース」の流れに沿って画面を紹介します。

① バーコードの撮影

スマートフォンのカメラで、検査試薬のバーコードを撮影します。検査室の試薬の現物さえあれば情報を取得できるため、整備された試薬一覧が手元になくても始められます。

② 検査名称の選択

続いて、院内の検査名称一覧から、対象の検査名称を選びます。ここで1点補足します。前章の精度検証では試薬・機器情報を起点に絞り込む流れで説明しましたが、実際のアプリでは検査名称の選択を先に行います。理由は2つあります。

1つは応答時間とコストです。先に検査名称で絞ることで、LLMへの入力トークンを抑え、応答時間とコストを削減できます。もう1つは現場の使いやすさです。ヒアリングでは、検査担当者は試薬と検査名称を紐づけて覚えているため、検査名称を先に入力するほうがスムーズだという声が得られました。この現場感覚を反映しています。

③ 候補の提示と確定

候補提示画面に、候補となるJLAC11コードが表示されます。アプリユーザーが確認して確定し、必要に応じて編集もできます。「候補を自動確定せず、人の判断で最終化する」設計が、この画面で操作として現れます。

なお、1件ずつバーコードを撮影するほか、検査機器や試薬の一覧をスプレッドシートでまとめて一括アップロードすることも可能です。

振り返り

アルゴリズムからアプリ実装まで紹介してきました。最後に、得られた気づきと、取り組みの前提となる制約を振り返ります。

データが揃わない現実との向き合い方

理想は、試薬名・材料・測定法・承認番号などをすべて入力に使い、候補を絞り込むことです。しかし実際には、試薬情報が分散している（あるいはデータとして存在しない）、電子カルテのエクスポートに制約があるといった事情でデータが揃わないことがあります。

さらに、データが取れても、それを日常的に入力・更新する運用が現場にとって無理のないものでなければ定着しません。精度を追うほど入力項目が増え、現場の負担は上がります。このバランスをどこで取るかが、本プロジェクトで最も悩んだ点でした。

スコープの制限

今回のマッピングは、付番コード表に収録された項目が前提です。裏を返せば、コードがまだ存在しない検査・試薬は、そもそも候補を提示できません。これは、アルゴリズムやモデル精度とは別の前提側の制約です。

背景には、JLAC11のコード整備が現在進行中であることがあります。JLAC11は中央付番（※※）の方式で、コード自体の整備が進んでいる最中です。そのため、市販の試薬・機器すべてが付番コード表に載っているわけではなく、収録範囲には限りがあります。

（※※）中央付番とは、各医療機関が独自にコードを割り振るのではなく、コードの制定・維持管理を担う中央の主体（JLAC11では日本臨床検査医学会検査項目コード委員会）が、試薬・機器に対応するコードを一元的に付番していく方式です。施設ごとに番号がばらつかず標準として揃う一方、対象を1つずつ整備するため、網羅には時間がかかります。

もっとも、付番コード表は現在も整備が進む対象であり、収録範囲は今後拡充される見込みです。現時点で候補を出せない項目も、コード整備の進展にあわせて、本アプローチのカバー範囲は広がっていくと考えられます。

ドメイン有識者へのヒアリングの重要性

検討初期にJLACセンターの有識者へヒアリングできたことは、プロジェクト全体で非常に大きかったと感じています。JLAC11コードの設計思想や、現場でコードがどう運用されているかを、実装・検証の前に直接伺えたことで、課題整理とアプローチの方針決めが格段にスムーズになりました。「電子カルテの入力・連携部分の落とし穴」や「バーコードで解けるはずなのにデータが取れない」といった、コードだけ見ていては気づけない実装以前のリスクを早期に認識できたのも、このヒアリングのおかげです。

まとめ

医療検査コードの標準化という課題に対し、検査名称ベースのファジーマッチングとバーコードベースの外部マスタ参照という2つのアプローチを設計し、LLMと組み合わせた候補提示システムとして実装しました。

完全自動化ではなく、人間のレビューを支援する設計が、現時点では現実的
データの品質・可用性がボトルネックになりやすく、アルゴリズムだけでは解けない問題が多い
精度の追求よりも、現場が無理なく使える形であることを優先した

医療データの標準化は地味ですが、医療機関横断のデータ共有・二次利用の基盤となる重要なテーマです。今後はアプリケーション評価のフィードバックも踏まえ、実運用に向けたマッピング支援の仕組みを磨いていきます。

参考リンク

謝辞

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

ABEJA Tech Blog

中の人の興味のある情報を発信していきます

院内検査マスターをJLAC11へマッピング — NEDO医療LLMプロジェクトでのユースケース検証