【2026年最新】自動医療コーディング支援｜Claude Code実装ガイド

手順直行型：この記事では、医療機関の開発チームが「自動医療コーディング」をいきなり本番自動化するのではなく、Claude Codeで候補提示・根拠表示・人間承認までを安全に作る実装パターンを整理します。

医療コーディングの文脈では、「AIで自動化できますか？」という問いが先に立ちがちです。でも、実装側が最初に決めるべきなのはモデル性能ではなく、責任境界です。ICD-10やDPCに関わる判断は、請求・統計・診療記録・監査に波及します。AIが候補を出すことと、組織として正式コードを確定することは別物です。

Claude Codeは、既存リポジトリを読み、テストを書き、CLIや設定ファイルをまたいで変更できる開発支援ツールです。Anthropic公式ドキュメントでは、Claude Codeがターミナル内で動き、コードベースを理解しながら編集・テスト・コマンド実行を支援する開発環境として説明されています。だからこそ本記事では、医療AIモデルそのものを作る話ではなく、医療コーディング支援システムを安全に実装するためのコード設計に絞ります。

正直に言うと、この領域で「AIだけで返戻率を何％下げる」といった断定を書くのは危険です。この記事では架空のベンチマーク数字を置きません。代わりに、厚生労働省が公開するICD-10準拠の統計分類や診断群分類（DPC）点数表を参照し、公式情報をどうアプリケーション設計に落とすかを扱います。

自動医療コーディングを「候補提示」に限定する理由

最初の設計判断は、AIの出力を「確定コード」ではなく「候補コード」にすることです。医療コーディングでは、同じ診療記録を読んでも、診療目的、主病名、併存症、手術・処置、入院経過、施設内ルールによって判断が変わります。コード候補を一つ出すだけなら簡単に見えますが、実務で必要なのは、なぜその候補になったのか、どの情報が不足しているのか、誰がいつ承認したのかを追えることです。

この考え方は、Claude Codeの使い方にも合っています。Claude Codeに「システム全体を作って」と丸投げするのではなく、入力正規化、候補生成、根拠抽出、レビューUI、監査ログ、テストのように小さく分けて実装します。各段階で人間がレビューできるようにすると、医療領域のYMYLリスクを下げられます。

確定ではなく候補にする

候補提示の画面では、AIが出したコード、根拠になった記述、参照した分類表、信頼度の代わりに「不足情報」を表示します。信頼度スコアだけを見せると、利用者が数字に引っ張られます。医療現場では、スコアよりも「この候補を採用するために何を確認すべきか」が大事です。

人間承認をデータモデルに入れる

承認者、承認時刻、差戻し理由、修正前後のコードをデータベースに残します。ここを後付けにすると、監査対応が難しくなります。最初のスキーマからレビュー状態を持たせるのが安全です。

PHIを入力に入れない前提で始める

氏名、住所、電話番号、患者ID、生年月日などの個人情報は、実装検証の段階では入れません。匿名化済みのサンプル、または合成データでワークフローを確認します。実データ連携は、組織の個人情報保護規程、委託契約、アクセス制御、監査要件を確認した後に検討してください。

最小アーキテクチャ：Claude Codeに作らせる5つの境界

自動医療コーディング支援の最小構成は、巨大なAIアプリではありません。むしろ、境界をはっきり分けた小さなサービス群にすると、Claude Codeでテストしながら進めやすくなります。ここでは、院内SEやSaaS開発者が最初に作るべき5つの境界を示します。

1. 入力正規化レイヤー

入力は、退院サマリ、診療録要約、手術記録、検査要約などを想定します。ただし本番データではなく、匿名化または合成データから始めます。入力正規化レイヤーでは、本文、日付範囲、診療科、入院・外来の区分、抽出対象の語句を分けます。Claude Codeには、このレイヤーの型定義とユニットテストから作らせます。

type CodingInput = {{
  encounterType: 'inpatient' | 'outpatient';
  department: string;
  anonymizedSummary: string;
  procedureNotes?: string;
  labSummary?: string;
  sourceDocumentIds: string[];
}};

この型に患者名や患者IDを入れないことがポイントです。どうしても内部IDが必要な場合は、アプリ内でランダムなレビューIDに置き換え、外部モデルに送るデータとは分離します。

2. 参照マスター取り込みレイヤー

厚生労働省は「疾病、傷害及び死因の統計分類」（ICD-10準拠）を公開しています。また診断群分類（DPC）点数表も公開されています。記事執筆時点で参照できる公式情報は、アプリに直接ハードコードするのではなく、バージョン付きの参照マスターとして取り込みます。更新日、取得元URL、ファイルハッシュを保存しておくと、後から「どの分類表を見て候補を出したか」を説明できます。

type ReferenceVersion = {{
  sourceName: 'MHLW_ICD10' | 'MHLW_DPC';
  sourceUrl: string;
  fetchedAt: string;
  sha256: string;
  effectiveLabel: string;
}};

Claude Codeには、取り込みスクリプトと差分検出テストを作らせます。分類表が更新されたときに、候補ロジックだけでなくテストデータも更新対象になるためです。

3. 候補生成レイヤー

候補生成では、AIに直接「正しいコードを選んで」と頼みません。まずルールベース検索で候補を数件に絞り、次にClaudeへ「候補ごとの差分説明」を作らせます。これにより、モデルが存在しないコードを作るリスクを下げられます。

async function proposeCodes(input: CodingInput): Promise<CodingCandidate[]> {{
  const lexicalCandidates = await searchReferenceMaster(input.anonymizedSummary);
  const ranked = await explainCandidateDifferences(input, lexicalCandidates);
  return ranked.map(candidate => ({
    ...candidate,
    status: 'needs_human_review',
  }));
}}

候補リストには、コード、分類名、根拠文、反証になり得る記述、不足情報を入れます。ここで「自動確定」フラグを作らないことが重要です。

4. レビューUIレイヤー

レビューUIでは、候補を採用・修正・差戻しできるようにします。採用ボタンの横には、根拠文と参照マスターのバージョンを表示します。差戻し時には「情報不足」「候補範囲が広すぎる」「記録との不一致」「院内ルール確認」のような理由を選択できると、後からプロンプト改善に使えます。

5. 監査ログレイヤー

監査ログは、医療領域の実装で最も後回しにされがちですが、最初に作るべきです。入力本文の全文をログに残すのではなく、レビューID、参照マスター、候補、承認者、差戻し理由、操作時刻を記録します。ログに個人情報を入れない設計にすれば、開発・検証環境でも扱いやすくなります。

type CodingAuditLog = {{
  reviewId: string;
  action: 'proposed' | 'approved' | 'rejected' | 'edited';
  candidateCode?: string;
  referenceVersionId: string;
  actorRole: 'system' | 'coder' | 'physician' | 'admin';
  reason?: string;
  createdAt: string;
}};

Claude Codeに渡すプロンプト設計

Claude Codeを業務導入するエンジニアにとって、重要なのは「良いプロンプトを一発で書くこと」ではありません。仕様、制約、禁止事項、テスト条件をプロンプトに入れ、生成されたコードをすぐにテストで検証できる状態にすることです。医療コーディング支援では、特に禁止事項を明確にします。

プロンプト1：データモデルを先に作る

医療コーディング支援ツールのTypeScript型を作ってください。
前提：これは想定シナリオで、実患者データは扱いません。
禁止：患者名、患者ID、生年月日、住所、電話番号を型に含めないでください。
必要：入力、候補、レビュー状態、監査ログ、参照マスターのバージョンを分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。

最初に型を作ると、後続のAPI、UI、テストが安定します。Claude Codeには、ファイル配置も含めて提案させます。

プロンプト2：参照マスターの取り込みテスト

ICD/DPC参照マスターを取り込むためのimporterを作ってください。
要件：sourceUrl、fetchedAt、sha256、effectiveLabelを保存すること。
禁止：参照データをコード内にベタ書きしないこと。
テスト：同じファイルを取り込んだ場合は同じsha256になること、更新された場合は差分検出できること。
仮定した点は必ず「仮定」と明記してください。

分類表は更新されます。取り込み時点の証跡を持たないと、後から再現できません。

プロンプト3：候補生成を確定処理にしない

候補生成APIを実装してください。
入力：匿名化済みsummaryと参照マスター検索結果。
出力：最大5件の候補、根拠文、不足情報、反証になり得る記述。
重要：最終コードを確定しないでください。statusは必ずneeds_human_reviewにしてください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

「statusは必ずneeds_human_review」と明示すると、AIが勝手に自動承認フローを作るのを防ぎやすくなります。

プロンプト4：レビューUIのアクセシビリティ

レビューUIのReactコンポーネントを作ってください。
表示：候補コード、分類名、根拠文、参照マスターのバージョン、不足情報。
操作：採用、修正、差戻し。
差戻し理由：情報不足、記録との不一致、候補範囲が広すぎる、院内ルール確認。
注意：採用ボタンだけを目立たせず、差戻しと修正を同等に扱ってください。

医療領域のUIでは、採用を急がせるデザインを避けます。レビューのしやすさと差戻しやすさを同じくらい重視します。

プロンプト5：監査ログのテスト

監査ログのユニットテストを書いてください。
確認したいこと：
1. proposed/approved/rejected/editedがすべて記録される
2. actorRoleが必須になる
3. referenceVersionIdが空なら保存できない
4. ログ本文に患者名・住所・電話番号らしき文字列が混入した場合はエラーにする
不足している情報があれば、最初に質問してから作業を開始してください。

テストでは、個人情報らしき文字列を雑に検出するだけでは十分ではありません。ただし、初期段階のガードとして「ログに入れてはいけない」という思想をコード化する価値があります。

プロンプト6：Claude Codeの権限設定レビュー

このリポジトリのClaude Code設定をレビューしてください。
確認：危険なシェルコマンドがallowされていないか、外部送信を伴うコマンドが無制限になっていないか、医療データを含むディレクトリを読みに行く設定がないか。
出力：危険度、理由、修正案、テスト方法。
注意：設定を変更する前に差分案を提示してください。

AnthropicのClaude Codeセキュリティ関連ドキュメントでは、権限ベースの設計や設定管理が重要なテーマとして扱われています。医療系リポジトリでは、便利さよりも「どこまで読めるか」「何を実行できるか」を先に絞るべきです。

実装ステップ：ローカル検証からレビュー運用まで

ここからは、実際に開発チームが着手する順番です。ポイントは、AI部分を最後に差し込むことです。最初からLLM呼び出しを入れると、テストが不安定になり、責任境界も曖昧になります。

Step 1：合成データだけでE2Eを作る

まず、実患者データを一切使わず、合成データでE2Eを作ります。合成データには、疾患名、処置名、検査所見のような一般的な要素は入れますが、個人を識別できる情報は入れません。E2Eで確認するのは、候補が出ることではなく、候補がレビュー待ちになり、承認・差戻し・監査ログが通ることです。

Step 2：参照マスターを固定バージョン化する

次に、ICD-10やDPC参照データの取り込みを固定バージョン化します。更新のたびに自動で本番へ反映するのではなく、差分をレビューしてから採用します。これにより、突然候補が変わる問題を防げます。

Step 3：ルールベース候補を先に作る

AI呼び出しの前に、キーワード検索や正規化辞書で候補を絞ります。完全一致、同義語、表記揺れ、否定表現を分けて処理します。Claude Codeには、まずこのルール部分のテストを作らせると進めやすいです。

Step 4：LLMは説明と差分整理に使う

LLMは、候補の差分説明、根拠文の抽出、不足情報の明示に使います。「コードを決める」よりも「レビューしやすくする」役割に寄せると、安全性と運用性のバランスが取れます。

Step 5：レビュー結果を改善ループに戻す

差戻し理由を集計すると、どこで候補生成が弱いか見えてきます。たとえば「情報不足」が多いなら入力フォームを改善し、「候補範囲が広すぎる」が多いなら参照マスター検索を改善します。ここでも、実測成果として外部に断定するのではなく、社内改善指標として扱います。

セキュリティ設計：Claude Code導入前に決めること

医療系の開発リポジトリでClaude Codeを使う場合、最初に権限とデータ境界を決めます。Anthropicのセキュリティ関連ドキュメントでは、Claude Codeの権限、設定、実行環境に関する考え方が示されています。実務では、公式ドキュメントを確認したうえで、自組織の規程に合わせて制限を追加してください。

読み取り可能なディレクトリを絞る

Claude Codeに読ませるのは、アプリケーションコード、テスト、サンプルデータ、ドキュメントに限定します。実データ、バックアップ、ログ、エクスポートCSV、添付ファイル置き場を同じリポジトリに混ぜるのは避けます。

コマンド実行を許可制にする

テスト実行や型チェックは許可しつつ、外部送信、データ削除、マイグレーション、本番接続は許可制にします。便利だからといって広い権限を与えると、医療データを扱う開発では事故時の説明が難しくなります。

ログに個人情報を残さない

アプリケーションログ、Claude Codeの作業ログ、CIログ、監査ログは別物です。どのログに何を残すかを最初に決めます。監査ログにはレビュー操作を残し、個人情報そのものは残さない設計にします。

オンプレ・自己ホスト表現を過信しない

「自己ホストだから安全」「院内ネットワークだから漏えいしない」とは書けません。ネットワーク構成、認証、権限、ログ、委託先、バックアップ、端末管理まで含めて確認が必要です。自己ホスト型の考え方は、既存記事の 医療機関のシステム開発を自己ホスト型Claude Codeで完結させた実装事例 も参考になります。

既存レセプト点検記事との違い

claudecode-cases.comには、すでに 医療レセプト点検をClaude Codeで自動化 する記事があります。本記事はそこから一段手前の「コード候補をどう作り、どうレビューするか」に焦点を当てています。レセプト点検は請求内容の整合性を見るワークフローですが、自動医療コーディング支援は、病名・処置・分類候補の根拠を整理するワークフローです。

レセプト点検は整合性チェック

レセプト点検では、算定ルール、記載漏れ、併算定、疑義の洗い出しが中心になります。すでに請求データがある前提で、矛盾や不足を見つける発想です。

医療コーディング支援は分類候補の根拠整理

医療コーディング支援では、記録から候補を挙げ、根拠を示し、確認事項を明示します。最終判断は人間が行うため、レビューUIと監査ログが中心になります。

共通するのは「AIに確定させない」設計

どちらにも共通するのは、AIを最終判断者にしないことです。Claude Codeは実装を速める道具ですが、医療・請求・コンプライアンスの責任を肩代わりするものではありません。

よくある失敗パターンと回避策

ここでは、Claude Codeで医療コーディング支援を作るときに起こりやすい失敗を整理します。どれも、プロンプトの言い回しだけでなく、設計で防ぐべき問題です。

失敗1：AIに「正解コード」を直接出させる

❌「この診療録から正しいDPCコードを出して」
⭕「候補コードを最大5件出し、根拠文、不足情報、反証になり得る記述を併記して」

最初から正解を求めると、レビュー者が根拠を追いにくくなります。候補と理由を分けるだけで、運用の安全性が上がります。

失敗2：分類表をコードにベタ書きする

❌ 参照コードをソース内の配列に直接貼る。
⭕ 取得元URL、取得日、ハッシュ、適用ラベルを持つ参照マスターとして管理する。

公式情報は更新されます。バージョン管理なしに実装すると、後で再現できません。

失敗3：レビューUIを承認ボタン中心にする

❌ 採用ボタンだけを大きく表示する。
⭕ 修正、差戻し、不足情報確認を同じ導線で表示する。

医療領域では、急いで承認するUIよりも、迷ったときに差戻せるUIが大事です。

失敗4：ログに本文を丸ごと残す

❌ 入力全文を監査ログに保存する。
⭕ レビューID、候補コード、参照バージョン、操作、理由だけを保存する。

ログは便利ですが、個人情報を増殖させる場所にもなります。何を残さないかを決めることが重要です。

導入ロードマップ：PoCから本番前レビューまで

PoCでは、いきなり医事部門全体に展開しません。まずは開発チーム内で、合成データ、固定参照マスター、レビューUI、監査ログを通します。その後、関係部門と一緒に評価観点を決めます。評価観点は「正答率」だけではなく、根拠の追いやすさ、差戻し理由の分類、レビュー時間のばらつき、不足情報の見つけやすさなどに分けます。

PoCの完了条件

• 合成データだけで候補提示から差戻しまで通る
• 参照マスターのバージョンが記録される
• 監査ログに個人情報が入らない
• 承認・修正・差戻しの操作がすべてテストされている
• Claude Codeの権限設定がレビューされている

本番前に確認すること

本番連携の前には、個人情報保護、委託契約、アクセス権、ログ保存期間、バックアップ、障害時対応、手動運用への切り戻しを確認します。必要に応じて、法務、情報セキュリティ、医療情報管理部門、外部専門家に相談してください。AIは補助ツールであり、最終判断者ではありません。

運用後の改善指標

運用後は、外部公開用の派手な成果数字よりも、内部改善に使える指標を見ます。たとえば、差戻し理由の分布、参照マスター更新後の候補変化、レビュー待ち滞留件数、監査ログ不備の件数などです。これらは組織内の品質改善に役立ちますが、外部に成果として出す場合は測定方法と母数を明示する必要があります。

テスト戦略：AI出力よりワークフローを検証する

自動医療コーディング支援のテストでは、特定のサンプルに対して候補コードが一つ一致しただけでは不十分です。モデル出力は更新や入力表現で変わり得ます。固定すべきなのは、候補が参照マスターに存在すること、根拠が入力文書の範囲を指すこと、不足情報が空のまま自動承認されないこと、レビュー操作が必ず監査ログへ残ることです。つまり、AIの文章そのものではなく、システムが守る契約をテストします。

契約テストで候補の形を固定する

候補生成APIにはJSON Schemaを用意し、code、label、evidence、missingInformation、referenceVersionId、statusを必須にします。codeが参照マスターに存在しない場合、referenceVersionIdが空の場合、statusがapprovedになっている場合はエラーにします。Claude Codeには、成功ケースより先に失敗ケースを書かせると、仕様の抜けを見つけやすくなります。

describe('coding candidate contract', () => {
  it('rejects a code absent from the pinned reference master', async () => {
    const result = validateCandidate(unknownCodeCandidate);
    expect(result.success).toBe(false);
  });

  it('never accepts an automatically approved candidate', async () => {
    const result = validateCandidate(autoApprovedCandidate);
    expect(result.success).toBe(false);
  });
});

否定表現と時間軸をテストする

診療記録には「疑い」「否定」「既往」「家族歴」「検査中」「退院時には改善」のような文脈があります。単純なキーワード一致では誤った候補が上位に来ます。合成データには、肯定文だけでなく、否定文、過去歴、除外診断、検査待ちを含めます。候補生成が文脈を無視した場合に、レビュー画面の反証欄へ該当文が出ることを確認します。

スナップショットだけに頼らない

LLM出力全文のスナップショットテストは、表現の揺れで壊れやすく、重要な不具合を見落とすことがあります。候補数の上限、参照コードの存在、根拠文の出典位置、不足情報の有無、レビュー待ち状態といった構造を検証してください。説明文の自然さは、人間レビュー用の評価セットで別に確認します。

回帰評価セットを小さく保つ

初期の回帰評価セットは、網羅性よりも失敗モードの多様性を重視します。表記揺れ、略語、複数候補、否定、既往歴、情報不足、参照マスター外の語を含む合成ケースを用意します。各ケースには唯一の正解を置くのではなく、「許容候補」「出してはいけない候補」「追加確認事項」を定義します。これなら、AIを最終判断者にせず品質変化を追えます。

障害対応と切り戻しを先に設計する

本番運用を検討するなら、モデルや外部サービスが利用できない場面を正常系として設計します。候補生成が失敗しても、受付済みデータを失わず、人間が従来手順へ戻れる必要があります。医療現場では「AIが止まったので業務も止まる」構成を避け、支援機能を無効化してもレビュー作業を継続できるようにします。

タイムアウト時は手動キューへ送る

タイムアウト、レート制限、参照マスター不整合、出力形式エラーを分けて記録します。再試行は回数と間隔を制限し、失敗が続く場合は手動レビューキューへ送ります。画面には、AI候補がないことを明示し、古い候補を最新結果のように表示しないでください。

参照マスターを一つ前へ戻せるようにする

新しい参照マスターを取り込む際は、差分レビューとステージング検証を行います。不具合が見つかった場合に、アプリケーションの再デプロイなしで一つ前のreferenceVersionIdへ戻せると安全です。切り戻し後も、どのレビュー案件が新旧どちらの参照版を使ったかを監査ログから追えるようにします。

プロンプト変更もリリース対象にする

プロンプトは運用メモではなく、システムの挙動を変える構成要素です。Gitで差分管理し、変更理由、評価結果、承認者を残します。Claude Codeにプロンプトを修正させる場合も、いきなり本番へ入れず、回帰評価セットとレビューUIで確認します。コード、参照マスター、プロンプトの3つを別々にバージョン管理すると、障害原因を切り分けやすくなります。

インシデント時の確認順序をREADMEに置く

候補が不適切だった場合は、入力の匿名化、参照マスターの版、ルール検索結果、LLM説明、レビュー操作、最終確定者の順に確認します。誰か一人の操作ミスとして片付けず、システムのどの境界で防げたかを見ます。個人情報や診療判断に関わる可能性がある場合は、所属組織のインシデント対応手順に従い、情報セキュリティ・法務・医療情報管理の担当者へ連携してください。

実装チェックリスト

最後に、開発チームがそのまま使えるチェックリストを置きます。Claude CodeにこのチェックリストをREADMEへ反映させると、レビュー観点が揃いやすくなります。

• 入力型に患者名・患者ID・住所・電話番号が入っていない
• 参照マスターに取得元URL、取得日時、ハッシュがある
• 候補生成APIのstatusが必ずneeds_human_reviewになる
• 候補ごとに根拠文、不足情報、反証になり得る記述がある
• レビューUIに採用・修正・差戻しがある
• 差戻し理由が構造化されている
• 監査ログに参照マスターのバージョンIDがある
• Claude Codeのコマンド権限が必要最小限になっている
• 本番データを使う前に組織の規程・契約・セキュリティレビューを通している

要点の整理と次の一歩

自動医療コーディング支援は、AIに医療判断を任せるプロジェクトではありません。Claude Codeで価値が出るのは、コード候補の生成そのものよりも、参照マスター、テスト、レビューUI、監査ログを一貫して実装できる点です。まずは合成データだけで、候補提示から人間承認までの小さな流れを作ってください。

次の一歩は、既存リポジトリに「データ境界」「参照マスター」「レビュー状態」「監査ログ」の4つがあるかを確認することです。足りない場合は、この記事のプロンプトを使ってClaude Codeに差分案を作らせ、テストから入るのが安全です。

参考にした一次情報・関連資料

• Anthropic Claude Code overview
• Anthropic Claude Code security
• Anthropic Claude Code settings
• 厚生労働省 ICD-10準拠の統計分類
• 厚生労働省 診断群分類（DPC）点数表

関連して、Claude Codeの医療領域の設計は 医療機関の自己ホスト型環境の記事、レセプト点検の観点は 医療レセプト点検の記事、権限境界の考え方は DLP対応のClaude Code推論フック実装ガイド も合わせて確認してください。