医療資料をクラウドAIへ送らず、ローカルOCRから始めた理由

診断書や明細書を確認し、傷病名や通院日数などを整理する業務が人手に依存していました。

資料には要配慮個人情報が含まれます。そのため、この案件では「どのクラウドAIを使うか」より先に、元データを外部AIや外部サーバーへ送らない構成を条件にしました。

選んだのは、ローカル環境でPDFや画像を取り込み、OCRと定型項目の抽出で初期整理を支援する方法です。

必要だったのは文章生成ではなく、確認前の整理だった

変更前は、診断書や明細書を一つずつ確認し、必要な情報を人が整理していました。

対象になったのは、次のような作業です。

• PDFや画像を開く
• 傷病名などの必要項目を探す
• 通院日数や対象期間を整理する
• 資料ごとの要点をまとめる

ここで重かったのは、文章を新しく作ることではありません。複数の資料から必要項目を拾い、確認できる状態へ並べる工程です。

この違いから、生成AIによる自由な要約より、OCR、項目抽出、期間集計を先に実装する方針になりました。

外部送信しないことを設計条件にした

この案件では、元のPDFや画像を外部AI・外部サーバーへ送らない前提で構成しています。

これは「ローカルなら完全に安全」という意味ではありません。法令適合性や端末全体の安全性を保証するものでもありません。

確認できる事実は、処理対象の元データを外部へ送信しない構成を選んだことです。

ローカル処理でも、端末の管理、ファイルの保管場所、利用者の権限、バックアップなど、別の確認事項は残ります。今回の設計判断は、それらを含む安全性全体の断定ではなく、外部送信を避けるという制約への対応です。

実装した4つの処理

実装範囲は、資料の初期整理に絞りました。

1. PDF・画像の取り込み

対象資料をローカル環境で読み込みます。元データをクラウドへアップロードする前提にはしていません。

2. OCR

画像として保存された文字を読み取り、後続の抽出に使える形へ変換します。

3. 定型フォーマットからの項目抽出

書式がある程度決まっていることを前提に、必要な項目を整理します。自由な文章から何でも判断させる設計ではありません。

4. 期間集計と要点整理

通院日数や対象期間などを集計し、最終確認しやすい形へまとめます。

最終判断は人間が行います。ツールの役割は、資料を読まなくてよい状態にすることではなく、人が確認する前の整理をそろえることです。

ローカル処理だけで足りると断定はしていない

この案件では、定型資料から必要項目を整理する範囲にローカル処理を使いました。

一方、書式の揺れが大きい資料や、文脈に基づく判断が必要な作業まで同じ方法で対応できるとは確認できていません。

また、導入前後の処理時間や、確認漏れが何件減ったかという実測値もありません。そのため、速度や精度の改善率は記載しません。

確認できているのは、外部送信しない前提で、OCR、項目抽出、期間集計、要点整理の流れを構築したことです。

この判断が合う範囲

同じ考え方を検討できるのは、次の条件がある業務です。

• 元データを外部サービスへ送らない要件がある
• PDFや画像の書式がある程度決まっている
• 欲しい結果が、自由な生成より項目の抽出と集計である
• 最終確認を人間が行える

条件が違えば、同じ構成が最適とは限りません。まず資料の種類と外部送信の可否を確認し、その後に使う技術を決めます。

案件の公開範囲は、匿名事例「医療資料整理をローカルで進める支援ツール」にまとめています。

まとめ

この案件では、AIを使うこと自体を出発点にしませんでした。

診断書や明細書に要配慮個人情報が含まれ、元データを外部へ送らない条件があったため、ローカルOCRと定型項目の抽出から始めました。

生成AIかローカル処理かを先に決めるのではなく、実際の資料、必要な出力、外部送信の制約を確認してから技術を選ぶという判断です。