Media > AI活用ユースケース > 総務 > クリニックで手書きされる初診問診票を読み取り、電子カルテに貼る下書きにそろえて、空欄とアレルギーの記載を確認に回す

クリニックで手書きされる初診問診票を読み取り、電子カルテに貼る下書きにそろえて、空欄とアレルギーの記載を確認に回す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

初診の患者が待合で手書きした問診票を読み取り、主訴・既往歴・服薬・アレルギーを電子カルテの問診欄に貼れる下書きにそろえます。空欄と読めない欄は受付へ、アレルギーの記載は医師・看護師へ回します。

サマリー
生成AI
ChatGPT/Claude/Gemini
AIサービス
Azure AI/Google Document AI
連携・自動化
Python
対象業界
医療
対象部門
総務
対象業務
データ入力・転記/内容確認・チェック
主な課題
人手が足りない/入力作業が多い/確認ミスが多い
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/対応スピード向上/工数削減
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
90h/月
AI導入後
30h/月
想定削減
67%
年間削減
720h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 受付で初診の患者に問診票とボールペンを渡し、待合で記入してもらう
  2. 書き終わった問診票を受け取り、受付が表面と裏面をざっと見る
  3. 空欄があれば、その場で患者に声をかけて書き足してもらう
  4. 電子カルテの患者を開き、主訴・既往歴・服薬・アレルギーを問診欄へ打ち直す
  5. アレルギーに記載があれば、付箋に書いて診察室へのファイルに貼る
  6. 混雑している時間帯は打ち直しをあきらめ、スキャンした画像を電子カルテに貼る
  7. 問診票の紙は、その日の終わりに院内の保管箱へ入れる
導入後(After)
  1. 人受付で患者番号のラベルを印刷して問診票に貼り、患者に渡す
  2. 人書き終わった問診票を受け取り、ドキュメントスキャナで両面を読み込む
  3. 自動保存先フォルダへの保存をきっかけに処理が動き、画像の品質と患者番号を確かめる
  4. 自動Google Document AI が欄・チェック欄・文字を読み取り、信頼度を返す
  5. 自動問診票の版ごとの「欄の地図」と照らし、欄ごとに `filled` / `blank` / `unreadable` / `checked_none` を付ける
  6. 自動Claude API が主訴・既往歴・服薬・アレルギーを電子カルテの問診欄の形にそろえる(アレルギーは原文のまま)
  7. 自動空欄と判読不能の欄を受付の確認画面へ、アレルギーの記載を診察室の確認画面へ出す
  8. 人受付が空欄の欄だけを患者に聞き、確認画面に書き足す
  9. 人受付が下書きを画面で見比べ、電子カルテの問診欄へ貼る
  10. 人医師・看護師が診察の前にアレルギーの欄を原本の画像と見比べる
各工程の詳しい説明を読む
  1. 受付で初診の患者に問診票とボールペンを渡し、待合で記入してもらう
  2. 書き終わった問診票を受け取り、受付が表面と裏面をざっと見る
  3. 空欄があれば、その場で患者に声をかけて書き足してもらう
  4. 電子カルテの患者を開き、主訴・既往歴・服薬・アレルギーを問診欄へ打ち直す
  5. アレルギーに記載があれば、付箋に書いて診察室へのファイルに貼る
  6. 混雑している時間帯は打ち直しをあきらめ、スキャンした画像を電子カルテに貼る
  7. 問診票の紙は、その日の終わりに院内の保管箱へ入れる

(a)空欄に気づくのが診察室になる。 2番目の「ざっと見る」は、混雑すると問診票を受け取るだけになります。裏面のアレルギーの欄が空欄のまま診察室に入り、医師が患者に聞き直すことになります。 医師の数分は、受付の数分より高くつきます。

(b)「なし」と空欄の区別が書き写しで消える。 電子カルテに打ち直すとき、アレルギーの欄が空欄のものを「なし」と入れてしまうことがあります。一度「なし」と入ると、次の受診からはそれが前提になります。 書き写しの誤りの中で、いちばん後まで残る型です。

(c)手書きの薬の名前が崩れる。 服薬中の薬は、お薬手帳を見ながら書く人もいれば、記憶で書く人もいます。崩れた字の薬の名前を受付が推測で打つと、似た名前の別の薬になります。 受付は薬の名前を判断する立場にありません。

(d)画像で貼ったものは検索できない。 6番目の画像は、その日の診察には足ります。しかし再診のたびに、アレルギーを探す人が画像を開くことになります。

  1. 【人】 受付で患者番号のラベルを印刷して問診票に貼り、患者に渡す
  2. 【人】 書き終わった問診票を受け取り、ドキュメントスキャナで両面を読み込む
  3. 【自動】 保存先フォルダへの保存をきっかけに処理が動き、画像の品質と患者番号を確かめる
  4. 【自動】 Google Document AI が欄・チェック欄・文字を読み取り、信頼度を返す
  5. 【自動】 問診票の版ごとの「欄の地図」と照らし、欄ごとに filled / blank / unreadable / checked_none を付ける
  6. 【自動】 Claude API が主訴・既往歴・服薬・アレルギーを電子カルテの問診欄の形にそろえる(アレルギーは原文のまま)
  7. 【自動】 空欄と判読不能の欄を受付の確認画面へ、アレルギーの記載を診察室の確認画面へ出す
  8. 【人】 受付が空欄の欄だけを患者に聞き、確認画面に書き足す
  9. 【人】 受付が下書きを画面で見比べ、電子カルテの問診欄へ貼る
  10. 【人】 医師・看護師が診察の前にアレルギーの欄を原本の画像と見比べる

5番目がこの構成の分かれ目です。 「欄が空いているか」を生成AIに判断させず、問診票の版ごとに欄の位置を決めておき、その範囲に文字があるかで決めます。 自院の問診票は様式が決まっているので、これができます。

8番目で、受付が患者に聞くのは空欄の欄だけです。 1枚ずつ全部を見直すのではなく、確認画面に赤く出た欄だけを、患者がまだ待合にいるうちに聞きます。 診察室での聞き直しが、待合での一言に変わります。

9番目の貼り付けは人が行います。 電子カルテへ自動で書き込む構成にはしません。理由は第7章の「システム連携」で書きます。

02今回想定するシステム構成

構成図
初診の問診票(A4両面・手書き、患者番号のラベル付き)
   │  受付のドキュメントスキャナで両面を読み込む
   ▼【トリガー】院内の保存先フォルダへの保存
Python ── 患者番号のラベルを読み、画像の品質を確かめる
   ▼
Google Document AI(Form Parser)
   │   欄の名前と値、チェック欄の丸、表
   ▼
Google Document AI(Enterprise Document OCR)
   │   文字ごとの信頼度、画像の品質スコア
   ▼
Python ── 欄の地図と照合(filled / blank / unreadable / checked_none)
   ▼
Claude API ── 主訴・既往歴・服薬・アレルギーを問診欄の形にそろえる(構造化出力)
   ▼
確認画面(受付:空欄と判読不能/診察室:アレルギー)
   ▼
【人が確認して電子カルテの問診欄へ貼る】
役割想定する製品代替候補
OCRGoogle Document AI(Form Parser、Enterprise Document OCR)Azure AI Document Intelligence
生成AIClaude API(問診欄の形へのそろえ、主訴の短い言い換え)Gemini API、OpenAI API
差異計算Python(欄の地図との照合、空欄と判読不能の判定、アレルギーの印)確認画面側の判定の規則
連携Python(保存先フォルダの監視、確認画面への書き出し)院内の既存の連携の仕組み
保管院内の共有フォルダ(問診票の原本のスキャン)電子カルテの画像の保管

電子カルテはいまのものを使います。 クラウド型の電子カルテに、外から問診欄へ書き込む口があるかは製品ごとに違います。この構成では書き込みを前提にせず、確認画面からコピーして貼る形にします。 取り込みの機能があれば、後から足せます。

OCRに Google Document AI を選ぶのは、日本語の手書きに対応したプロセッサが2つそろうからです。 Form Parser と Enterprise Document OCR はどちらも一般提供(GA)で、対応言語の表で日本語に手書きの対応が付いています。

Form Parser は、欄の名前と値の組、表、チェック欄を取り出します。 チェック欄は valueType が filled_checkbox か unfilled_checkbox で返ります。既往歴の「高血圧・糖尿病・喘息…」に丸が付いているかを、文字ではなく印として受け取れます。

一方で、Form Parser の公式ページには、空欄の値を持つ欄(白紙の様式など)を確実には解析できないと書かれています。 空欄を見つけたいこの業務では、そのまま頼れません。だから空欄の判定を、欄の名前と値の組ではなく、欄の地図の側に置きます。

Enterprise Document OCR を重ねるのは、文字ごとの信頼度と画像の品質のためです。 enableSymbol を有効にすると1文字ずつの信頼度が返り、画像の品質スコアは0から1で返って、0.5を下回るとぼけ・暗さ・薄さ・文字の小ささなど8種類の理由が付きます。

生成AIに Claude API を選ぶのは、構造化出力が一般提供になっているからです。 output_config.format に type: "json_schema" とスキーマを渡すと、スキーマどおりのJSONで返ります。

03どうやって実装するのか

Step1

処理の起点を決める

スキャナが院内の保存先フォルダにPDFを書き出したことを起点にします。 受付のドキュメントスキャナは、ボタン1つで両面を読み、決まったフォルダへ保存する設定にしておきます。受付がファイル名を付ける作業はなくします。

監視は Python の常駐の処理で行い、新しいファイルを見つけたら1枚ずつすぐに動かします。 まとめて処理する定時実行にはしません。患者が待合にいるうちに空欄を聞くには、スキャンから確認画面に出るまでを数分に収める必要があるからです。

処理が終わったファイルは処理済みフォルダへ移し、移すのは成功したときだけにします。 保存先フォルダに残っている数が、そのまま確認画面に出ていない問診票の数です。受付の画面の隅にこの数を出しておくと、止まっていることにすぐ気づけます。

Step2

入力データを集める

データ中身取得元
問診票のスキャンA4両面のPDF。受付の院とスキャンの時刻院内の保存先フォルダ
患者番号受付で印刷して問診票に貼ったラベルの番号問診票の右上のラベル
読み取り結果欄の名前と値、チェック欄の印、文字ごとの信頼度、画像の品質スコアGoogle Document AI
欄の地図問診票の版ごとの、欄の名前・ページ・範囲の座標・種類(自由記述/チェック)自院で作る定義のファイル
問診欄の型電子カルテの問診欄の見出しと並び自院で決めた写し

質を決めるのは下の2つです。 欄の地図が無ければ空欄を見つけられず、問診欄の型が無ければ、院ごと・人ごとに貼り方がばらばらになります。どちらも1回作れば、版を変えるまで使えます。

患者番号のラベルは、紙の問診票と電子カルテの患者を結ぶ唯一の手がかりです。 名前で突き合わせると、同姓同名と読み違いで別の患者に貼る事故が起きえます。ラベルの番号で結び、名前は確認のためだけに使います。

Step3

データの取得方法を決める

  1. 患者番号を読む … 右上のラベルの範囲を読み、受付の当日の初診の一覧と照らします
  2. Form Parser を呼ぶ … 両面2ページをまとめて送ります。同期の処理は15ページまでなので、1枚の問診票は収まります
  3. Enterprise Document OCR を呼ぶ … enableSymbol と画像の品質スコアを有効にし、languageHints に日本語を入れます
  4. 欄の地図と重ねる … 各欄の範囲に入る文字とチェック欄の印を、ページと座標で集めます
取るものどこから何に使うか
欄の名前と値、信頼度pages[].formFields[] の fieldName と fieldValue自由記述の値の候補
チェック欄の印formFields の valueType(filled_checkbox / unfilled_checkbox)既往歴とアレルギーの「なし/あり」
文字ごとの信頼度pages[].symbols[]薬の名前のどの文字が崩れているか
画像の品質スコア品質のスコアと、0.5未満のときの理由スキャンし直すかの判断
文字の位置各要素の layout の textAnchor と座標欄の地図の範囲に入るかの判定

座標を使うときの注意が1つあります。 公式ページによると、値が0の座標はJSONから省かれます。 ページの左端や上端に接する点は、キーそのものが無いことがあるので、無いキーを0として読む処理を最初に入れておきます。

Step4

AIへ渡す前に整形する

  1. ラベルの確認 … 患者番号が読めない、当日の初診の一覧に無いものは処理を止め、受付へ戻します
  2. ページ数と向きの確認 … 2ページであること、上下が逆でないことを確かめます
  3. 画像の品質の確認 … 品質スコアが0.5を下回り、理由に defect_blurry や defect_faint があるものはスキャンし直しに回します
  4. 解像度の確認 … 公式ページはスキャンを最低200dpi、300dpi以上が一般に最も良い結果になるとしています。スキャナの設定を300dpiに固定します
  5. 圧縮の確認 … JPEGのような非可逆の形式でファイルを小さくすると精度が落ちうるとされています。スキャナの「高圧縮」の設定を使いません
  6. 版の判定 … 問診票の右下に印刷した版の番号を読み、使う欄の地図を選びます

4番目と5番目は、最初に1回決めれば終わる設定です。 それでも書くのは、スキャナの既定の設定が「小さいファイル」になっていることが多いからです。手書きの薄い鉛筆の字は、圧縮でいちばん先に消えます。

6番目の版の判定は省略しないでください。 問診票の欄の位置は、版を改めるたびに少しずつ動きます。古い版の地図で新しい版を読むと、隣の欄の文字を拾います。

Step5

AIに処理させる

処理を2段に分けます。 欄が空いているかどうかは、Python が欄の地図と読み取り結果で決めます。Claude API にさせるのは、その結果を受け取ってからの、問診欄の形へのそろえだけです。

欄判定(Python)Claude API にさせること
主訴・症状の始まり範囲に文字があるか書かれた言葉を残し、問診欄の「主訴」「現病歴」に分ける
既往歴(チェック)各項目の印印の付いた病名を並べる。印の無いものを「なし」としない
既往歴(自由記述)範囲に文字があるか書かれたまま写す
服薬中の薬範囲に文字があるか、文字ごとの信頼度薬ごとに行を分ける。名前は書かれたまま。低信頼の文字に印
アレルギー(なし/ありの印)印の状態状態をそのまま返す
アレルギー(内容)範囲に文字があるか原文のまま写す。 要約・分類をしない
妊娠・授乳、喫煙・飲酒印の状態状態をそのまま返す

欄ごとの状態は4つです。 filled は範囲に文字がある、blank は範囲に文字も印も無い、unreadable は文字はあるが信頼度が低い、checked_none は「なし」に印がある。blank と checked_none を混ぜないことが、この構成の目的そのものです。

させないこと理由
空欄を「なし」で埋める第3章の(b)。聞き直すべき欄が消える
薬の名前を直す・補う崩れた字をそれらしい薬に寄せると、別の薬になる
アレルギーの要約・分類医師が見たいのは、何で何が起きたかの原文
症状からの病名の推定診断は医師の仕事
信頼度の付け直しOCRが返した値をそのまま使う

2行目がいちばん起きやすい失敗です。 生成AIは、崩れた字を「よく知られた薬の名前」に寄せて読む傾向があります。名前を直すことを禁じ、信頼度の低い文字を含む名前には印を付けて、人に回します。

Step6

指示内容を固定する

あなたはクリニックの受付で、手書きの問診票を電子カルテの問診欄に貼る
下書きにそろえる担当です。診断や医学的な判断は一切しません。

【入力】
- 欄ごとの判定結果(Python が欄の地図から付けたもの)
  status: filled / blank / unreadable / checked_none
- 欄ごとの読み取り文字列と、文字ごとの信頼度
- 問診欄の型(見出しと並び)

【厳守事項】
- status が blank の欄は、出力でも blank のままにしてください。
  「なし」「特記なし」と書かないでください。
- status が checked_none の欄だけを「なし」としてください。
- 既往歴のチェック欄は、印が付いているものだけを並べてください。
  印の無い病名を「なし」として並べないでください。
- 薬の名前は、読み取られた文字列をそのまま写してください。
  似た薬の名前に直す、一般名に置き換える、規格を補うことをしないでください。
  信頼度が0.8未満の文字を含む名前は low_confidence を true にしてください。
- アレルギーの内容は、原文をそのまま allergy_text に写してください。
  要約、言い換え、「薬剤アレルギー」などの分類をしないでください。
- 主訴は、患者が書いた言葉を残してください。病名に置き換えないでください。
  現病歴には、症状の始まりと経過として書かれた部分だけを入れてください。
- 書かれていないことを補わないでください。読めない部分は「判読不能」とし、
  前後から推測して埋めないでください。
- 問診票でない書類と判断した場合は、document_type に種類を書き、
  他の項目を空にしてください。

【欄ごとの判定結果】{field_status}
【読み取り結果】{ocr_text_by_field}
【問診欄の型】{chart_template}

「blank を blank のまま」を最初に置くのは、生成AIが空欄を嫌うからです。 何も言わなければ、整った下書きを作ろうとして「特記なし」と埋めます。整っていることより、空いていることが分かるほうがこの業務では大事です。

信頼度の0.8という値は、最初の1か月で見直す仮の値です。 自院の問診票と患者の字で、低すぎれば受付の確認が増え、高すぎれば崩れた名前が通ります。決め方は第8章の試し方で書きます。

Step7

出力形式を固定する

次の形のJSONで受け取ります。

{
  "patient_no": "",
  "form_version": "",
  "document_type": "questionnaire",
  "chief_complaint": { "status": "filled", "text": "" },
  "present_illness": { "status": "filled", "text": "" },
  "past_history_checked": [""],
  "past_history_text": { "status": "blank", "text": "" },
  "medications": [
    { "name_as_written": "", "low_confidence": false }
  ],
  "allergy": {
    "status": "filled | blank | unreadable | checked_none",
    "allergy_text": ""
  },
  "pregnancy": "yes | no | blank",
  "smoking": "yes | no | blank",
  "blank_fields": [""],
  "unreadable_fields": [""]
}

1つ目の理由は、空欄の一覧をそのまま受付の画面に出せることです。 blank_fields と unreadable_fields を並べれば、受付が患者に聞く欄の一覧になります。人が問診票を見直して探す必要がありません。

2つ目は、status を enum で縛れることです。 Claude API の構造化出力は enum に対応しているので、4つの状態以外の値が入りません。「たぶんなし」のような曖昧な値が、そもそも返ってきません。 なお、minimum のような数値の制約には対応していないため、信頼度の範囲の確認は Python の側で行います。

3つ目は、アレルギーを allergy_text という1つの原文の欄に置けることです。 診察室の確認画面では、この欄を原本の画像の該当部分と並べて出します。医師・看護師は、画像を探さずに原文と画像を見比べられます。

確認画面には、電子カルテの問診欄の型に並べ替えた文章も出します。

問診欄の見出し入るもの
主訴chief_complaint.text
現病歴present_illness.text
既往歴past_history_checked と past_history_text
内服薬medications を1行ずつ(低信頼のものに[要確認])
アレルギーallergy_text を原文のまま。blank なら[未記入・要聴取]
Step8

システムへ連携する

つなぎ先方式内容
院内の保存先フォルダPython の監視スキャンの保存を検知する
Google Document AIAPI呼び出しForm Parser と Enterprise Document OCR
Claude APIAPI呼び出し(構造化出力)問診欄の形へのそろえ
確認画面院内のWebの画面受付用(空欄・判読不能)と診察室用(アレルギー)
電子カルテ人のコピーと貼り付け確認の済んだ下書きを問診欄へ

電子カルテへ自動で書き込まないのは、患者の取り違えを人の目で止めるためです。 ラベルの番号で結んでいても、ラベルの貼り間違いは起きえます。貼る直前に、受付が電子カルテの患者名と問診票の氏名を見比べる工程を残します。

確認画面は、院の端末から院内でだけ開ける作りにします。 問診票の画像と下書きが並ぶ画面なので、外から開けないことを前提にします。

Step9

人が確認する

  1. 受付:空欄と判読不能の欄を患者に聞く … 確認画面に赤く出た欄だけを、待合にいるうちに聞いて書き足します
  2. 受付:低信頼の薬の名前を確かめる … お薬手帳があれば手帳で、無ければ患者に聞きます。推測で直しません
  3. 受付:患者名を見比べて電子カルテへ貼る … 問診票の氏名と電子カルテの患者を見比べてから貼ります
  4. 医師・看護師:アレルギーの欄を原本と見比べる … 診察の前に、原文と画像を並べて見ます
  5. 直したら記録する … どの欄を、何から何へ直したかを残します

4番目を省かないでください。 アレルギーの内容は、読み取りの誤りがそのまま処方の誤りにつながりうる欄です。確認するのは受付ではなく、医師・看護師です。

目標は、900枚をならして1枚2分です。 空欄も低信頼も無い問診票は、受付が見比べて貼るだけで1分足らずです。空欄が多い問診票の聞き取りが、平均を引き上げます。

Step10

例外に対処する

起きること対応
患者番号のラベルが読めない・無い処理を止めて受付へ戻す。名前で突き合わせない
画像の品質スコアが0.5未満理由を受付の画面に出し、スキャンし直す
片面しか読み込まれていない2ページでないものは止め、両面で読み直す
版の番号が読めない・地図が無い欄の判定をせず、全欄を unreadable として受付へ
患者がチェック欄の外に丸を書いた印として拾えず blank になる。受付が画像で確かめる
欄の外への書き込み(余白のメモ)地図の範囲外の文字として別に出し、受付が扱いを決める
問診票でない書類が混ざるdocument_type を見て、処理をせず受付へ戻す
外国語での記入読み取った文字列をそのまま出し、受付が通訳の手配を判断
Document AI や Claude API が応答しない保存先フォルダに残す。受付はこれまでどおり紙で進める

最後の行は、仕組みが止まっても診療を止めないための決まりです。 確認画面が出なくても、問診票の紙は受付の手元にあります。止まったときは、これまでの打ち直しに戻ればよいので、受付が慌てる理由がありません。

5行目は、最初の月にいちばん多く出る例外です。 患者は丸を欄の外にはみ出して書き、斜線やレ点で答えることもあります。問診票の様式を、丸を付ける欄を大きくした版に改めるほうが、読み取りを工夫するより効きます。

Step11

記録を残す

  • 問診票のスキャンの原本と、スキャンした院・時刻・受付の担当
  • Document AI が返したJSONの全文と、画像の品質スコア
  • 欄ごとの判定(filled / blank / unreadable / checked_none)と、使った欄の地図の版
  • Claude API の出力と、電子カルテに貼った最終の文章
  • 人が直した記録 … どの欄を、何から何へ直したか
  • 空欄を患者に聞いた記録と、聞いた結果

3つ目で欄の地図の版を残すのは、地図を直したときに過去の判定を説明するためです。 地図を変えると同じ問診票でも判定が変わるため、どの版で判定したかが無いと、誤りの原因が地図か読み取りか分かりません。

5つ目は、問診票の様式を見直す材料になります。 同じ欄で直しが続くなら、その欄の書き方の説明か、欄の大きさに問題があります。

04実装レベルの3段階

最小構成:塗りつぶした問診票を手で読み取りにかけ、下書きを手元のAIサービスで作る / 1枚ごとの読み取りと下書き
半自動化:上記+欄の地図で空欄と判読不能を判定し、受付の確認画面に出す / 読み取り、空欄の判定、確認画面
本格構成:上記+スキャンの保存を起点に自動で動かし、診察室向けにアレルギーの欄を出し、直しの記録を残す / 問診票の受け取りから確認画面までの全体

最小構成は、空欄と印がどこまで拾えるかを確かめる段階です。 1枚ずつ貼るので、混雑した受付では使えません。 半自動化で、1枚6分が3分程度になります。 打ち直しは無くなりますが、スキャンの後に受付が処理を手で始め、アレルギーの申し送りも付箋のままです。本格構成で2分になり、この段階が本記事の想定です。 差は、保存から確認画面までの待ち時間と、診察室への申し送りが自動になることです。 3院に一度に広げないでください。 1院で1か月回し、欄の地図と様式の直しを済ませてから残りの2院に広げます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
6 名
月間件数
900 件
1件あたり現在時間
6 分
1件あたり導入後時間
2 分
現在  900件 × 6分 ÷ 60 = 90 時間/月
導入後 900件 × 2分 ÷ 60 = 30 時間/月
月間削減時間
60h
削減率
67%
年間削減時間
720h
年間金額換算(時間単価2,600円)
187万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 初診の患者に紙の問診票を書いてもらい、受付や医療クラークが電子カルテの問診欄に打ち直しているか、スキャンした画像を貼るだけで文字として残せていない診療所・クリニック。複数の院で同じ版の問診票を使っており、月に数百枚の初診がある医療法人。待合で書かれた問診票の空欄に診察の直前まで気づかず、聞き直しが診察室で起きている場合。
向いていない
  1. 問診をタブレットやWeb問診ですでに受けており、紙の問診票がほとんど残っていない場合。初診が月に数十件で、受付が書き写しても負担になっていない場合。問診の内容から診断や検査の要否を判断させたい場合、この構成では代替できません。アレルギーの有無や重さの判断は医師・看護師が行います。

07最小構成で試す方法

  1. 過去の初診の問診票から30枚を選ぶ(空欄があったもの、アレルギーの記載があったもの、字が崩れたものを必ず入れる)
  2. 患者の氏名・生年月日・住所の部分を黒く塗りつぶしてからスキャンする
  3. Document AI の Form Parser を管理画面から試し、チェック欄の印と自由記述がどう返るかを見る
  4. 読み取り結果を手元のAIサービスに貼り、「空欄は空欄のまま、薬の名前とアレルギーは書かれたまま写して、問診欄の形にそろえてください」と指示する
  5. 出てきた下書きを、当時電子カルテに打ち直した内容と突き合わせる

2番目の塗りつぶしは、試す段階でも省かないでください。

出てきた内容判断
空欄が空欄のまま出て、印も正しく拾えた欄の地図と確認画面を作る段階に進む
空欄を「なし」で埋めた指示の書き方で直る。構成は有効
薬の名前を別の薬に直した指示と信頼度の印で直る。0.8の値をこの30枚で決める
チェック欄の印がほとんど拾えない様式の丸の欄が小さすぎる。 様式の見直しが先

信頼度の線は、この30枚で決めます。 当時の正しい名前と食い違った薬の名前が、どの信頼度以下に集まるかを見ます。

08実装時につまずきやすいポイント

問題対策
空欄が「なし」「特記なし」で埋まる空欄の判定を Python に置き、指示でも明記する
空欄が欄の名前と値の組から拾えないForm Parser は空欄の値を確実には解析できない。欄の地図で判定する
薬の名前が似た別の薬に直る名前を直すことを禁じ、文字ごとの信頼度で印を付ける
アレルギーが要約される原文の欄を分けて持ち、要約を禁じる
チェック欄の丸がはみ出して拾えない様式の丸の欄を大きくする。読み取りより様式を直す
ラジオボタン型の欄が読めないForm Parser のチェック欄の読み取りはラジオボタンに対応しない。四角のチェック欄の様式にする
古い版の問診票が混ざる版の番号を印刷し、版ごとの地図を選ぶ
圧縮でうすい字が消える300dpi、非可逆の高圧縮を使わない
座標のキーが無くて処理が落ちる0の座標はJSONから省かれる。無いキーを0として読む
ラベルの貼り間違いで別の患者に貼る自動で書き込まず、貼る前に氏名を見比べる
確認画面が混雑時に見られない受付の画面の隅に未確認の件数を出す
外国語の記入読み取った文字列をそのまま出し、通訳の手配は受付が判断

上の2行が、この構成の失敗のほとんどです。 どちらも「空欄が空欄として残らない」という同じ結果になります。空欄を見つけるのは生成AIではなく欄の地図の仕事、と分けておくかで決まります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 患者の氏名・生年月日・住所、主訴と症状、既往歴、服薬中の薬、アレルギー、妊娠・授乳の有無です。いずれも病歴に関わる個人の情報で、外部のサービスへ送る範囲と方法は院の規程で決める必要があります。

  1. 外部のサービスの利用を、院の安全管理の規程に沿って決める … 厚生労働省のページには医療情報システムの安全管理に関するガイドライン第7.0版が掲載されています。OCRと生成AIを使う前に、院の情報管理の担当とこのガイドラインに沿って、委託先として扱えるかを確かめます
  2. 生成AIに送るのは、問診の欄の文字だけにする … 氏名・生年月日・住所の欄は欄の地図で分かっているので、Claude API には送りません。 患者番号で結び直します
  3. データの保持の条件を確かめる … Claude API の構造化出力はゼロデータ保持(ZDR)の対象とされています。院の契約で何が保持されるかを、使い始める前に確かめます
  4. 診断や医学的な判断をさせない … 主訴を病名に置き換えない、アレルギーの重さを判定しない。この構成が出すのは、書かれていたことの写しです
  5. 電子カルテへ自動で書き込まない … 患者の取り違えは、問診票の誤りの中でいちばん影響が大きい誤りです。貼る前の見比べを人に残します
  6. 紙の原本の扱いを決めておく … スキャンを原本とするか、紙を残すかを院の規程で決めます。電子カルテに貼った下書きと、原本の画像の両方をたどれるようにします

誤りが起きた場合のリスクは、空欄を「なし」として残すことと、薬やアレルギーの名前を別のものに写すことの2つです。 どちらも、読み取った文字を変えないという1つの決まりで防ぎます。

10まず何から始めるか

1週目:問診票の版をそろえる

3院で使っている問診票を集め、版の番号を右下に印刷した1つの版にそろえます。 あわせて、チェック欄を四角の枠に、丸を付ける欄を大きくします。様式を直すのは、読み取りの工夫より先です。

2週目:30枚で試す

過去の問診票から30枚を選び、氏名などを塗りつぶしてから読み取りにかけます。空欄が空欄のまま残るか、薬の名前が直されていないかを最優先で見ます。 信頼度の線もこの30枚で決めます。

3週目:欄の地図を作る

新しい版の問診票について、欄ごとの範囲と種類を定義します。主訴・既往歴・服薬・アレルギーの欄から作り、氏名などの欄は「送らない欄」として印を付けます。

4週目:1院で確認画面まで動かす

1院のスキャナの保存先を監視し、確認画面に空欄の一覧と下書きが出るところまで作ります。この時点では診察室の画面は作らず、受付の画面だけで回します。

2か月目: 診察室向けのアレルギーの画面と、直しの記録を足します。空欄の件数と、受付が直した欄を毎週数えます。3か月目以降: 残りの2院に広げ、1枚6分が何分になったかを実測します。欄の地図の直しが止まり、診察室での聞き直しが減った時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-06/最終更新:2026-10-07
確認した内容情報源確認日
Enterprise Document OCR と Form Parser が一般提供(GA)であること。両プロセッサの対応言語の表で日本語(ja)に手書きの対応が付いていること。同期の処理のページの上限が15であることGoogle Cloud: Processor list2026-10-06
Form Parser がキーと値のペア、表、選択マーク(チェックボックス)、汎用のフィールド、テキストを取り出すこと。空欄の値を持つキーと値のペア(白紙の様式など)を確実には解析できないこと。チェックボックスのモデルがラジオボタンの解析に対応しないこと。表は行や列をまたぐセルの無い単純な表が対象であることGoogle Cloud: Form Parser2026-10-06
enableSymbol で1文字ずつのデータが返ること。画像の品質スコアが0から1で返り、0.5を下回るとぼけ・ノイズ・暗さ・薄さ・文字の小ささ・文書の切れ・文字の切れ・反射の8種類の理由が返ること。languageHints を指定できることGoogle Cloud: Enterprise Document OCR2026-10-06
欄が formFields の fieldName と fieldValue で返り、信頼度が付くこと。チェックボックスが valueType の filled_checkbox / unfilled_checkbox で返ること。textAnchor が本文の startIndex と endIndex で位置を指すこと。値が0の座標がJSONから省かれることGoogle Cloud: Handle the processing response2026-10-06
対応する形式が PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などであること。スキャンは最低200dpi、300dpi以上が一般に最も良い結果になるとされていること。非可逆の形式でファイルを小さくすると画質と精度が落ちうることGoogle Cloud: Supported files2026-10-06
構造化出力が一般提供で、output_config.format に type: "json_schema" を指定して使うこと。enum に対応し、minimum などの数値の制約に対応しないこと。オブジェクトに additionalProperties: false が必要なこと。ゼロデータ保持(ZDR)の対象とされていることClaude Docs: Structured outputs2026-10-06
医療機関等向けのページに「医療情報システムの安全管理に関するガイドライン 第7.0版」が掲載され、医療情報システムの安全管理やe-文書法等への対応のため技術的及び運用管理上の対策を示した文書とされていること厚生労働省: 電子カルテ情報共有サービス(医療機関等向け)2026-10-06

外部のサービスの利用の可否、アレルギーや服薬の情報の扱いは、院の医療情報の安全管理の規程と医師の判断に従ってください。 本記事は Google Cloud、Claude Docs、厚生労働省のページで確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0594)についてのご相談はこちらから。

AI活用について相談する
目次