AIが療養費を理解できるように: 柔整療養費RAGを作った話

はじめに

柔道整復療養費の制度は、AIにとってかなり難しい領域です。

理由は、単に専門用語が多いからではありません。

受領委任、償還払い、負傷原因、長期・頻回、多部位、転帰、資格確認、返戻、照会、領収証、明細書、公費、自賠責、労災など、実務では複数の条件を順番に確認しながら判断する必要があります。

しかも、間違えると「少し不自然な回答」では済みません。請求可否、返戻、照会、患者説明、施術録、申請書の整合性に影響します。

そこで今回、柔整療養費についてAIが「それっぽく答える」のではなく、根拠資料に基づいて、条件・例外・判断分岐を踏まえて回答できるようにするためのRAGを開発しました。

この記事では、作ったもの、精度を高めるためにやったこと、実際の検証結果、そして今後の展望についてまとめます。

作ったもの

作ったのは、柔整療養費制度に特化したローカルRAGです。

主な構成は次の通りです。

• 厚労省資料、通知、疑義解釈Q&Aなどの公式資料を取り込む
• PDFやMarkdown化した資料をページ単位・チャンク単位で管理する
• 制度上の判断ルールをルールブック化する
• 質問に対して、該当ルールと根拠ページを検索できるようにする
• LLMに渡すプロンプトを生成する
• LLM回答が要件を満たしているか機械評価する
• レセコンの計算前チェックに接続できる構造化判断へ変換する

RAGというと「文書をベクトル化して検索する」という話になりがちですが、今回はそこだけでは足りませんでした。

目標は、単語検索ではなく、制度判断です。

たとえば、AIが次のように判断できる状態を目指しました。

• このケースは請求可能なのか
• 請求前に人間確認が必要なのか
• 健康保険ではなく労災・自賠責・自費に回すべきなのか
• 申請を分ける必要があるのか
• そもそも請求を止めるべきなのか
• その判断の根拠はどの資料・どのページにあるのか

なぜ普通のRAGでは足りなかったか

最初に感じたのは、RAGで資料を引けるだけでは、療養費の実務には足りないということです。

一般的なRAGは、質問に近い文書を検索し、それをLLMに渡して回答させます。

しかし、療養費制度では次のような問題があります。

• 根拠文書は取れているのに、判断順序を間違える
• 例外条件を落とす
• 「請求できる」と言い切ってはいけないケースで断定する
• 人間確認が必要なケースを、AIだけで処理してしまう
• 負傷原因、転帰、長期、頻回、多部位などの複合条件を見落とす
• 制度上の話とレセコン上の処理を混同する

つまり、RAGに必要だったのは「関連文書を探す力」だけではなく、「制度上どこまで判断してよいかを制御する力」でした。

精度を高めるためにやったこと

1. まずコーパスの品質を上げた

制度RAGでは、入力資料の品質がそのまま回答品質になります。

そのため、PDF抽出やOCR結果をそのまま使うのではなく、テキスト品質の補正から始めました。

最終的なコーパスでは、次のような処理を行っています。

• 752ページを保持
• 総文字数 587,105文字
• 安全な置換ルールを 2,847件適用
• 521ページに安全補正を適用
• Apple Vision OCRによるページ上書きを 126ページに適用
• OCRエラーマーカーや文字化けが残っていないことを確認

特に、制度や医学用語では1文字の誤認識が意味を変えることがあります。

たとえば、専門用語や章番号、単位、筋名、骨名などの誤認識は、RAGにとってノイズではなく、誤答の原因になります。

そのため、RAGの前段として、コーパス品質をかなり重視しました。

2. 公式資料を制度RAG用に整理した

柔整療養費については、手元資料だけでなく、現行通知、改正通知、資格確認資料、疑義解釈Q&Aなども取り込みました。

公式資料の抽出結果は次の通りです。

• 公式資料: 10件
• ページ数: 194ページ
• チャンク数: 193

取り込んだ資料には、現行通知、算定基準、支給申請書の記載要領、資格確認関連資料、令和6年改正通知、厚労省Q&Aなどが含まれます。

ここで意識したのは、単に資料をまとめることではありません。

後から評価できるように、各チャンクに「どの資料の、どのページに由来するか」を持たせました。

3. ルールブック化した

RAGで検索できるだけでは、制度判断は安定しません。

そこで、制度上の判断単位をルールとして整理しました。

各ルールには、次のような情報を持たせています。

• ルールID
• 制度領域
• 判断内容
• 根拠資料
• 根拠ページ
• 関連する実務上の注意
• 完全性ガード

これにより、AIが回答するときに「なんとなく近い文章」ではなく、「該当する制度ルール」に寄せて回答できるようにしました。

4. 回答要件を作った

さらに、質問ごとに回答要件を定義しました。

具体的には、各質問に対して次のような期待値を持たせました。

• 必ず触れるべきルールID
• 必ず含めるべき用語
• 言ってはいけない禁止回答
• 根拠ページ
• blocker / review / info の分類
• レセコン計算前チェック用の required_actions

これはかなり重要でした。

RAGの評価では「正しそうに見える回答」を人間が読むだけだと、どうしても評価が曖昧になります。

そこで、回答に必要な条件を先に構造化し、LLM回答がそれを満たしているかを機械的に確認できるようにしました。

実際の検証結果

ここからは、実際に行った検証結果です。

1000問RAG評価

制度領域ごとに作成した1000問のRAG評価では、次の結果になりました。

評価項目	結果
評価質問数	1000
Overall pass	1000/1000
Rule hit	1000/1000
Page hit	1000/1000
Complete coverage status present	1000/1000
Rule MRR	0.853
Page MRR	0.827

対象領域は、受領委任、施術録、明細書、算定基準、資格確認、長期・頻回、返戻・審査、領収証などです。

この評価では、質問に対して必要なルールと根拠ページが検索結果に含まれるかを確認しています。

実務質問110問評価

次に、より実務に近い質問セットを作りました。

これは単純な制度確認ではなく、引っかけや複合条件を含む質問です。

結果は次の通りです。

評価項目	結果
評価質問数	110
Overall pass	110/110
All required rules hit	110/110
Evidence page hit	110/110
Complete-coverage guard	110/110

評価領域は次の10領域です。

• 公費・高齢者・負担割合
• 労災・自賠責・自費混在
• 受領委任・償還払い
• 施術録・申請書・領収証・明細書
• 複合ケース
• 資格確認・保険切替
• 転帰・再開初検・負傷追加
• 返戻・照会・不正不当・監査
• 長期・頻回・多部位
• 骨折・脱臼・医師同意

このあたりから、単なる検索RAGではなく、実務判断RAGに近づいてきました。

外部LLM回答評価

検索結果を使って、外部LLMにも実際に回答させました。

今回の検証では、Grokを使って110問に回答させています。

結果は次の通りです。

評価項目	結果
評価質問数	110
Shape validation	pass
Answer requirements	110/110
Reasoning order	110/110
Overall pass	True

ここで見ているのは、単に答えが合っているかだけではありません。

以下も評価対象にしています。

• 必須の制度要件に触れているか
• 禁止回答をしていないか
• 判断順序が崩れていないか
• 人間確認が必要なケースを過剰に自動判断していないか
• 根拠と結論が対応しているか

LLMは、資料を渡すだけだとそれらしい回答を返してしまいます。

そのため、回答要件と順序評価を入れることで、「正しそうに見えるが危ない回答」を落とせるようにしました。

構造化判断評価

最終的には、チャット回答だけでなく、レセコンの計算前チェックに接続できる形も作りました。

110ケースを構造化判断に変換した結果は次の通りです。

判断	件数
block_submission	39
claim_allowed	6
review_required	56
route_other_coverage	3
split_claim	6

全体評価は 110/110 でした。

ここで重要なのは、claim_allowed が少ないことです。

実務上、AIが安易に「請求できます」と答えるのは危険です。

むしろ、多くのケースでは、請求停止、人間確認、他制度への振り分け、申請分割などを判断できることの方が重要です。

実装して分かったこと

RAGの本体は検索ではなく評価だった

今回一番大きな学びは、RAGの本体は検索ロジックだけではないということです。

もちろん、検索精度は重要です。

しかし、療養費のような制度領域では、それ以上に次が重要でした。

• 何を正解とするか
• 何を言ってはいけないか
• どの順序で判断すべきか
• どこから人間確認に戻すべきか
• 根拠ページをどう保持するか
• 評価をどう再実行可能にするか

つまり、RAGを作るというより、「AIが制度を安全に扱うための評価可能な環境」を作る作業に近かったです。

「分からない」と言える設計が必要だった

制度領域では、AIが何でも答えようとすること自体がリスクになります。

たとえば、資料上の根拠が足りない、条件が不足している、負傷原因が曖昧、保険種別が不明、転帰や再開初検の扱いが分かれそう、といったケースがあります。

このような場合に、AIが無理に結論を出すのではなく、次のように返せる必要があります。

• この情報だけでは判断できない
• 追加確認が必要
• 人間レビューが必要
• 健康保険ではなく別制度の確認が必要
• 請求前に止めるべき

これは、AIの性能を下げる話ではありません。

むしろ、実務で使うためには、過剰に答えない制御が必要でした。

チャットボットで終わらせない方がよい

療養費RAGは、チャットUIだけでも便利です。

しかし、実務で本当に価値が出るのは、レセコンや業務フローに接続したときだと思っています。

たとえば、申請前に次のようなチェックができます。

• この負傷原因で健康保険請求に進んでよいか
• 骨折・脱臼で医師同意が必要ではないか
• 長期・頻回・多部位で説明や確認が必要ではないか
• 転帰や再開初検の扱いに矛盾がないか
• 施術録、申請書、領収証、明細書の整合性が取れているか

つまり、RAGは「質問に答えるAI」だけではなく、「請求前に制度上の危険箇所を検知するAI」にできると感じました。

今後の展望

今後やりたいことは、大きく5つあります。

1. 公式資料カバレッジの継続更新

制度は変わります。

特に改正通知、様式、疑義解釈、資格確認関連の運用は、継続的に追う必要があります。

今後は、公式資料の取り込み、差分管理、ルールブック更新、評価セット更新までを定期的に回せるようにしたいです。

2. 様式・領収証・明細書まわりの強化

現時点でも評価対象には入れていますが、様式・領収証・明細書まわりは、実務上まだ強化余地が大きい領域です。

制度本文だけでなく、実際の帳票出力、記載要領、患者説明、窓口運用までつながるため、ここは今後さらに厚くしたいです。

3. レセコン計算前チェックへの接続

今回、構造化判断として次のような分岐を作りました。

• claim_allowed
• claim_blocked
• claim_split_required
• manual_review_required
• route_non_health_insurance

今後は、これをレセコンの入力チェックや月次請求前チェックに接続していきたいです。

目標は、請求後に返戻で気づくのではなく、請求前に制度上のリスクを検出することです。

4. 現場データでの検証

評価セットだけでなく、実際の施術所業務に近いデータでも検証したいです。

もちろん、個人情報や機微情報の扱いには十分な配慮が必要です。

そのうえで、匿名化したケース、架空ケース、過去の返戻パターン、照会パターンなどを使い、より実務に近い評価を増やしていきたいです。

5. AI回答から業務アクションへ

最終的には、AIが文章で説明するだけでなく、業務上の次アクションを返せるようにしたいです。

たとえば、次のような出力です。

• 申請を止める
• 施術録の追記を促す
• 保険種別を確認する
• 医師同意の有無を確認する
• 患者説明が必要な項目を出す
• 返戻リスクの理由を表示する

ここまで来ると、RAGは単なるナレッジ検索ではなく、業務支援エンジンになります。

まとめ

今回、柔整療養費RAGを作ってみて、RAGに対する見方がかなり変わりました。

RAGは、資料をAIに読ませる技術ではありません。

少なくとも制度領域では、

• どの資料を根拠にするか
• どの単位でルール化するか
• 何を正解とするか
• 何を禁止するか
• どこまでAIが判断してよいか
• どこから人間に戻すか
• その判断をどう評価し続けるか

まで含めて設計する必要があります。

今回のRAGでは、1000問の検索評価、110問の実務質問評価、外部LLM回答評価、構造化判断評価まで行い、現時点ではすべての評価で期待条件を満たしました。

もちろん、これで完成ではありません。

制度は更新されますし、実務のケースはもっと複雑です。

それでも、AIが療養費について「それっぽく答える」段階から、「根拠を持って、条件と例外を踏まえ、必要なら人間確認に戻せる」段階へ近づけたと思っています。

AIが療養費を理解できるようにする。

そのためには、RAGそのものよりも、制度を評価可能な形に分解することが重要でした。