診療報酬チェックAI「正答率100%」を実現した実装戦略——ナレッジ分離とローカルLLMの組み合わせ

「AI導入したが、点数判定が間違える」

医療DX導入を進める医療機関なら、必ず直面する課題です。

その原因のほとんどは、AIが根拠なく自信満々に答えていることです。

診療報酬の判定は「合ってるか・間違ってるか」で済みません。査定対象、減額対象になれば、その医療機関の経営に直結します。だからこそ、AIの精度は100%を目指す必要があります。

初期段階：76.7%の精度の壁

最初は、診療報酬の点数・施設基準・算定条件をすべて一つのナレッジベースに入れて、LLMに聞いていました。

結果は正答率76.7%。30件のテストケースのうち、7件が間違えました。

その間違いは、パターン化していました：

• CEA（腫瘍マーカー）の判定が外れる：「加算」と「算定」を混同
• 期日の計算が外れる：ハルシネーション（根拠のない回答）
• 施設基準の相互作用を誤解：複数の基準が組み合わさるケースで誤判定

これらは、AIの性能の問題ではなく、「何を覚えさせるか」「どう構造化するか」の設計の問題でした。

実装戦略1：ナレッジベースを分離する

診療報酬には多くの関連項目があります：

• 算定ルール（点数・条件・期限）
• 腫瘍マーカー算定規則（疾患別対象/非対象）
• 施設基準の詳細（人員・設備・その他基準）

これらを一つに混ぜると、LLMが「関連性のない情報」までを判定に使ってしまい、矛盾が生じます。

対策：Difyのコンテキスト設定で、ナレッジベースを分離

① 腫瘍マーカー算定ルール（独立したナレッジベース）
② 診療報酬チェックAI_令和8年改定（メインナレッジベース）

CEA（腫瘍マーカー）の質問のときだけ①を参照させ、通常の加算判定では②のみを使う。

実装戦略2：テストケースで期待値を厳密に定義する

76.7%の失敗のうち、3件は「期日計算」でした。

初期設定では、期待値を「加算3」とだけ書いていました。修正版では、なぜそれが正答なのか、その根拠まで期待値に含めました。

【修正前】期待値：「加算3」

【修正後】期待値：「加算3（10点）算定可」
根拠：「2027年4月施行のため、3月時点では加算1・2の条件が
　　　 効力を持たない。施行前は全て加算3」

期待値に根拠を含めることで、AIの誤りだけでなく「なぜ誤ったか」も把握できるようになりました。これにより、改善サイクルが大幅に速くなります。

実装戦略3：Pythonコードノードで確定的に判定ロジックを実装する

いくら精密にしても、LLMに判定させると「知識」や学習データの影響で結果が不安定になります。だから、判定ロジック自体をPythonコードノードで実装しました。

コンポーネント	役割	特徴
Pythonコードノード	ICD-10判定・フラグ計算	確定的判定・知識影響なし
qwen2.5:7b（ローカル）	判定結果の文章化	判定値は変更不可・理由説明のみ

実装フロー

入力（患者ID・病名・検査値）
  ↓
[Pythonコードノード]
  • ICD-10コードで対象疾患判定
  • 除外条件チェック（1型糖尿病など）
  • 「疑い」「経過観察中」など確定診断待機キーワード検出
  • 判定フラグを確定
  ↓
[qwen2.5:7bノード]
  • Pythonからの判定フラグを受け取る
  • テンプレートに判定値を直接埋め込み（LLMが変更不可）
  • 判定理由と根拠を文章化
  ↓
出力（判定結果 + 説明文）

この設計により、30件すべてを自動検証でき、正答率100%を確認できました。

「知らない」と言える設計が信頼を生む

ここまで読んで気づくことは、AIの「性能向上」ではなく「制約を厳しくする」ことで精度が上がったということです。

医療現場で信頼されるAIは、「全部知ってるAI」ではなく「知らないことは正直に『原文確認を』と答えるAI」です。

診療報酬のようなクリティカルな業務こそ、AIは謙虚であるべき。100%を目指すなら、AIの「できることの範囲」を徹底的に限定する。これが実装の現場で学んだ最大の教訓です。