Media > AI活用ユースケース > 総務 > 調剤薬局にFAXで届く処方箋を読み取り、薬品名・用量・日数を受付データにそろえ、薬歴と照らした重複と用量の確認点を薬剤師へ返す

調剤薬局にFAXで届く処方箋を読み取り、薬品名・用量・日数を受付データにそろえ、薬歴と照らした重複と用量の確認点を薬剤師へ返す

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

FAXで先に届く処方箋を読み取り、薬品名・規格・用量・用法・日数を医薬品マスタにそろえた受付データの下書きにします。あわせて、その患者の薬歴と照らし、同じ成分の重複や前回からの用量の変化を「確認点」として薬剤師に返します。

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

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

導入前(Before)
  1. FAX複合機から処方箋を印刷し、受付のトレーに置く
  2. 医療事務が1枚ずつ見て、患者を請求システムで探し、受付を作る
  3. 処方の行ごとに、薬品名を医薬品マスタから選び、用量・用法・日数を入力する
  4. 薬剤師が受付の内容とFAXを見比べ、読み違いが無いかを確かめる
  5. 薬剤師が電子薬歴を開き、前回までの処方と見比べて、重複や用量の変化を探す
  6. 気になる点があれば、医療機関に問い合わせる
  7. 薬をそろえ、原本が届いたらFAXと原本が同じ内容かを照らし、薬を渡す
導入後(After)
  1. 自動FAX複合機が受信した画像を、店舗ごとの受信フォルダにPDFで保存する
  2. 自動数分おきの処理が新しいPDFを見つけ、OCRを呼ぶ
  3. 自動OCRが文字と表のセル、文字ごとの信頼度を返す
  4. 自動生成AIが、読み取り結果から患者・医療機関・処方の行を項目に分ける
  5. 自動処方の行を医薬品マスタに照らし、候補が1つに決まるかを確かめる
  6. 自動患者を請求システムの患者一覧で探し、薬歴の直近の処方を取り出す
  7. 自動同じ成分の薬が日数内で残っていないか、前回から1日量が変わっていないかを並べる
  8. 自動受付データの下書きと確認点を、店舗の受付画面の一覧に出す
  9. 人医療事務が `要確認` の行だけをFAXの画像で見て直し、受付を作る
  10. 人薬剤師が確認点を見て、必要なら医療機関へ問い合わせる
  11. 【人/自動】 原本が届いたら、原本をスキャンして読み取り、FAXの下書きとの違いを並べる
  12. 人薬剤師が違いを確かめ、薬を渡す
各工程の詳しい説明を読む
  1. FAX複合機から処方箋を印刷し、受付のトレーに置く
  2. 医療事務が1枚ずつ見て、患者を請求システムで探し、受付を作る
  3. 処方の行ごとに、薬品名を医薬品マスタから選び、用量・用法・日数を入力する
  4. 薬剤師が受付の内容とFAXを見比べ、読み違いが無いかを確かめる
  5. 薬剤師が電子薬歴を開き、前回までの処方と見比べて、重複や用量の変化を探す
  6. 気になる点があれば、医療機関に問い合わせる
  7. 薬をそろえ、原本が届いたらFAXと原本が同じ内容かを照らし、薬を渡す

(a)FAXの文字が粗い。 送り手の機械と回線によって、細い文字はかすれ、小数点は消えます。「0.5mg」が「05mg」に見え、「1日2回」が「1日3回」に見えることがあります。 医療事務は読めない文字のたびに手を止め、薬剤師に聞きに行きます。

(b)薬品名の選び間違い。 医薬品マスタで名前の先頭を打って候補から選ぶとき、似た名前の薬や同じ薬の別の規格が隣に並びます。 選び間違えた1行は、4番目の見比べで薬剤師が拾うしかありません。

(c)薬歴を見る時間が後ろに押される。 5番目は薬剤師にしかできない作業ですが、入力が終わるまで始められません。 施設のFAXがまとめて届く日は、薬歴を開くのが夕方になります。

(d)原本との照合が目視。 FAXと原本が同じ内容かを見る7番目は、行数の多い処方ほど時間がかかり、見落としも起きます。

  1. 【自動】 FAX複合機が受信した画像を、店舗ごとの受信フォルダにPDFで保存する
  2. 【自動】 数分おきの処理が新しいPDFを見つけ、OCRを呼ぶ
  3. 【自動】 OCRが文字と表のセル、文字ごとの信頼度を返す
  4. 【自動】 生成AIが、読み取り結果から患者・医療機関・処方の行を項目に分ける
  5. 【自動】 処方の行を医薬品マスタに照らし、候補が1つに決まるかを確かめる
  6. 【自動】 患者を請求システムの患者一覧で探し、薬歴の直近の処方を取り出す
  7. 【自動】 同じ成分の薬が日数内で残っていないか、前回から1日量が変わっていないかを並べる
  8. 【自動】 受付データの下書きと確認点を、店舗の受付画面の一覧に出す
  9. 【人】 医療事務が 要確認 の行だけをFAXの画像で見て直し、受付を作る
  10. 【人】 薬剤師が確認点を見て、必要なら医療機関へ問い合わせる
  11. 【人/自動】 原本が届いたら、原本をスキャンして読み取り、FAXの下書きとの違いを並べる
  12. 【人】 薬剤師が違いを確かめ、薬を渡す

9番目と10番目が、この設計の分かれ目です。 医療事務が開くのは読み取りやマスタの照合で決まらなかった行だけ、薬剤師が見るのは確認点の付いた行だけです。全行を人がFAXと見比べる設計にすると、90.0時間はほとんど減りません。

11番目は、通知が求める確認を機械で支えるものです。 厚生労働省の通知は、FAXなどで電送する方法を、電送されたものと処方箋の原本が同一の内容かの確認が容易なものに限るとしています。照合の結論は薬剤師が出し、機械は違いの候補を並べるだけです。

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

構成図
処方箋のFAX(診療所・自宅・介護施設から)
   ▼【トリガー】受信フォルダへのPDF保存(数分おきに確認)
Azure AI Document Intelligence(レイアウトモデル)
   │   文字・表のセル・信頼度
   ▼
Claude API ── 患者・医療機関・処方の行を項目に分ける(読むだけ、補わない)
   ▼
照合のスクリプト
   ├─ 医薬品マスタ(候補が1つに決まるか)
   ├─ 患者一覧(患者が1人に決まるか)
   └─ 電子薬歴の直近の処方(同じ成分の残り日数/1日量の変化)
   ▼
受付の一覧 ──▶【医療事務】要確認の行を直して受付を作る
          └─▶【薬剤師】確認点を見て、疑義照会の要否を決める
   ▼
原本の到着 ──▶ 原本を読み取り、FAXの下書きとの違いを並べる ──▶【薬剤師】
役割想定する製品代替候補
OCRAzure AI Document Intelligence(レイアウトモデル)Google Document AI(Enterprise Document OCR)
生成AIClaude API(処方の行の項目分け)OpenAI API、Gemini API
集計Python(医薬品マスタ・薬歴との照合、原本との差分)Google Apps Script
受付既存の調剤報酬の請求システム-

請求システムと電子薬歴は、新しく足すものではありません。 この構成からは書き込まず、取り出すのは医薬品マスタ、患者一覧、直近の処方だけです。 取り出し方は使っている製品によって違い、データの書き出し機能がある製品なら定時の書き出しを使い、無い製品ではこの部分が利用環境に応じた個別実装になります。 難易度を★4にしている理由の大半がここです。

土台になるのは、Azure AI Document Intelligence のレイアウトモデルです。 テキスト、テーブル、選択マーク、ドキュメント構造を抽出するモデルで、単語ごとに content と confidence が返ります。 処方箋の処方欄は表の形をとることが多く、表のセルには行と列のインデックスが付いて返るので、1行の処方を1組として扱えます。

日本語は印刷・手書きともに対応しています。 公式の言語サポートの表では、レイアウトモデルの印刷テキストと手書きテキストの両方に日本語(ja)が含まれています。診療所が手書きで書き足した注記も読める前提で組めます。

入力の条件がFAXでは効いてきます。 抽出できるテキストの最小の高さは、1024 × 768 ピクセルの画像で12ピクセルで、150dpiで約8ポイントの文字に当たります。FAXの画像は解像度が低く、小さな文字や小数点がこの下限に近づきます。 読み取りの信頼度を確定の条件にするのは、このためです。

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

Step1

処理の起点を決める

受信フォルダへのPDFの保存を起点にし、数分おきに新しいファイルを確かめます。 受信した画像をフォルダへ転送できる機種なら、店舗ごとの受信フォルダに保存するところまでを複合機の設定で済ませます。 できない機種では、受信したPDFを担当者が保存します。

1日数回のまとめ処理にはしません。 施設のFAXがまとまって届く日に、まとめて処理すると薬剤師が確認点を見るのが遅れ、第3章の(c)がそのまま残ります。 1枚ずつ流し、受付の一覧に順に並べます。

処理を終えたPDFは処理済みフォルダへ移し、移すのは受付の一覧に載せ終えたときだけにします。 受信フォルダに残っている数が、未処理の数です。原本が届いたときの読み取りは、受付の一覧で「原本到着」を押したときに動かします。

Step2

入力データを集める

データ中身取得元
処方箋のFAX患者の氏名・生年月日・保険の情報、医療機関と医師、交付日、処方の行(薬品名・規格・用量・用法・日数)、備考受信フォルダのPDF
読み取り結果文字、表のセル(行と列)、単語ごとの信頼度、手書きのスタイルAzure AI Document Intelligence
医薬品マスタ医薬品コード、販売名、一般名、成分、規格、剤形、「1日最大量」の登録(あれば)請求システムの書き出し
患者一覧患者番号、氏名、生年月日、施設の入居者かどうか請求システムの書き出し
直近の処方患者ごとの直近の処方の医薬品コード、1日量、日数、調剤日電子薬歴の書き出し
原本のスキャン原本が届いたときに読み取る店舗の複合機

質を決めるのは、医薬品マスタの成分の列です。 重複の確認は「同じ成分か」で行うため、販売名だけのマスタでは、先発品と後発品、一般名で書かれた処方の重なりを見つけられません。

「1日最大量」の列は、登録がある薬だけを照らします。 登録の無い薬について用量の確認点を出さないのは、基準の無いところで機械が「多い」「少ない」を言わないためです。

Step3

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

FAX: 複合機の転送設定で、受信のたびにPDFを受信フォルダに置きます。ファイル名に店舗コードと受信日時を入れます。 送り元の番号が取れる機種なら、ファイル名に含めておくと医療機関の特定が楽になります。

OCRの呼び出し: モデルIDは prebuilt-layout です。使うのは次の3つです。

取るものどこから何に使うか
単語と行pages の words(content、confidence、polygon)と lines文字と信頼度、画像の切り抜き位置
表とセルtables の cells(rowIndex、columnIndex、content)処方の1行を1組として扱う
手書きの判定styles の isHandwritten印字の処方と手書きの追記を分ける

手書きの判定を使うのは、追記を目立たせるためです。 印字された処方の横に「1T→2T」のように手で書き足されたものは、医師の訂正なのか、受け取った側の書き込みなのかを人が確かめる必要があります。

請求システムと電子薬歴: 定時の書き出しで、医薬品マスタと患者一覧は1日1回、直近の処方は1時間ごとに取ります。書き込みはせず、読むだけです。

Step4

AIへ渡す前に整形する

  1. ページの分割 … 1回の受信に複数の処方箋が入っていれば、ページごとに分けます。施設のFAXは複数の入居者の処方が続けて届きます
  2. 送り状の取り分け … 施設のFAXの1枚目に付く送り状は、処方箋の固定の文言が無いので取り分けます
  3. 向きの補正 … pages の angle で傾きを補正してから、表の位置を扱います
  4. 信頼度の低い文字の印付け … 単語ごとの confidence がしきい値を下回るものに印を付けます。数字と小数点を含む単語は、しきい値を高めにします
  5. 患者の照合 … 氏名と生年月日の両方で患者一覧を引きます。片方だけが一致する、同姓同名がいるときは確定させません
  6. 重複受信の検知 … 同じ患者・同じ交付日・同じ医療機関のFAXが続けて届いたら、両方を残して並べます。送り直しなのか、別の処方なのかは人が決めます

4番目のしきい値を数字で分けるのは、読み違えたときの害が違うからです。 患者の住所の1文字と、用量の小数点の1つでは、後者の読み違いのほうが重い結果につながります。

Step5

AIに処理させる

この構成には2つのAI処理が入ります。1つ目はOCRで、文字と信頼度を返します。2つ目は生成AIで、読み取り結果を「患者」「医療機関」「処方の行」の項目に分けます。医薬品マスタとの照合、薬歴との比べ合わせは、どちらのAIにもさせず、スクリプトで行います。

見るもの判定の仕方判断できないときの扱い
処方の行の項目分け生成AIが薬品名・規格・用量・用法・日数に分ける項目に分けられない行は unparsed
文字の確からしさOCRの単語ごとの信頼度しきい値未満の単語を含む行は low_confidence
医薬品マスタとの照合販売名・一般名と規格が1つの医薬品コードに決まるか候補が複数なら ambiguous、無ければ not_found
重複直近の処方に同じ成分があり、日数がまだ残っているか薬歴に成分が無ければ照らさない
用量の変化前回の1日量との違い、最大量の登録との比べ合わせ登録が無ければ最大量は照らさない

生成AIには、項目に分けることだけをさせます。 薬品名の候補を「たぶんこの薬」と寄せること、読めない数字を前回の処方から埋めることはさせません。照合はマスタという決まった表との一致で行い、決まらなければ人に回します。

させないこと理由
疑わしい点があるかの判断薬剤師の職務。AIの結論が判断の代わりに読まれる
読めない文字を前回の処方から埋める処方の変更が、前回と同じに書き換わる
似た名前の薬への寄せ選び間違いを機械が再現する
用量の妥当性の評価患者の状態を知らないまま「多い」と言わない
処方の変更の提案医師の同意なく変更して調剤してはならない

2行目がいちばん起きやすい失敗です。 施設の定期処方は前回と同じことが多く、読めない数字を前回の値で埋めると、たいていは合っています。 しかし、合わなかった1回が、医師が用量を変えた回です。

Step6

指示内容を固定する

あなたは調剤薬局の受付で、FAXで届いた処方箋の読み取り結果を整理する立場です。
OCRが返した文字と表のセルだけを使い、項目に分けてください。
薬の選択、処方の妥当性、疑わしい点の有無は判断しません。

【分ける項目】
- patient: 氏名、生年月日、性別
- institution: 医療機関名、医師名
- issue_date: 交付年月日
- lines: 処方の1行ごとに
    drug_text   … 薬品名の文字列(書かれたとおり。一般名の印も含める)
    strength    … 規格(例:5mg)
    dose_text   … 用量の文字列(例:1回1錠)
    usage_text  … 用法の文字列(例:1日2回朝夕食後)
    days        … 日数または回数
    source_cells… 根拠にした表のセルの位置(行・列)
- notes: 備考欄の記載、手書きで追記された文字列

【厳守事項】
- 書かれていない値は空文字にしてください。他の行、前回の処方、
  一般的な用法から埋めないでください。
- 数字、小数点、単位は書かれたとおりに写してください。
  「05」を「0.5」に直す、単位を補うことをしないでください。
  読めない文字は □ にしてください。
- 薬品名を別の名前に言い換えない、似た薬の名前に直さないでください。
- 1つのセルに2つの薬が書かれているように見えるときは、行を分けず、
  split_suspected を true にしてください。
- 手書きで追記された文字列は、印字の値を書き換えずに notes に入れてください。
- 処方箋でない書類(送り状、お知らせ)は、document_type に種類を書き、
  項目を空にしてください。

【読み取り結果】{ocr_result}

「05を0.5に直さない」を具体的に書くのは、生成AIがそれを親切として行うからです。 0.5mgと5mgの両方の規格がある薬では、直した値がもっともらしく見えるほど、人の確認をすり抜けます。 小数点が見えないなら、見えないまま low_confidence で人に回します。

手書きの追記を notes に分けるのも同じ理由です。 印字の「1T」と手書きの「2T」のどちらが有効かは、医療機関に確かめないと決まりません。

一般名で書かれた処方の扱いも、指示に入れておきます。 一般名の印が付いた行は、販売名ではなく成分と規格で書かれています。生成AIには印も含めて書かれたとおりに写させ、どの販売名を使うかは医薬品マスタの成分の列で候補を出したうえで人が選びます。 生成AIが特定の販売名を書き入れると、店舗の在庫や患者の希望と関係なく、薬が決まったように見えてしまいます。

Step7

出力形式を固定する

処方箋1枚ごとに、次の形のJSONを作ります。 lines の項目までは生成AIが返し、match と checkpoints は照合のスクリプトが付けます。

{
  "fax_id": "S02-20261007-1014-p3",
  "document_type": "prescription",
  "patient": { "name": "", "birth_date": "", "patient_no": "", "resolved": true },
  "institution": { "name": "", "doctor": "" },
  "issue_date": "2026-10-07",
  "lines": [
    { "line_no": 1, "drug_text": "", "strength": "", "dose_text": "",
      "usage_text": "", "days": "", "min_confidence": 0.93,
      "match": { "status": "matched | ambiguous | not_found",
                 "drug_code": "", "candidates": [] },
      "flags": ["low_confidence", "handwritten_note", "split_suspected"] }
  ],
  "checkpoints": [
    { "line_no": 1, "type": "same_ingredient_active | daily_dose_changed | over_registered_max",
      "fact": "直近の処方(2026-09-30調剤、28日分)に同じ成分あり" }
  ],
  "notes": ""
}

生成AIの部分は構造化出力で受け取ります。Claude API では output_config の format に type: "json_schema" とスキーマを指定し、返るJSONがスキーマに沿うことが保証されます。 項目の抜けや型の違いで後段が止まることがなくなります。

ただし、スキーマで書けないことがあります。 数値の範囲の制約と文字列の長さの制約は使えません。用量や日数が妥当な範囲かは、スキーマではなく照合のスクリプトで扱います。

checkpoints には事実だけを書きます。 「重複投与の疑い」ではなく「直近の処方に同じ成分あり、残り日数あり」と書きます。疑いという言葉を機械が使うと、薬剤師の判断の前に結論があるように読めるからです。

Step8

システムへ連携する

つなぎ先方式内容
FAX複合機受信画像のフォルダ転送PDFの取得
Azure AI Document IntelligenceAPI呼び出し(prebuilt-layout)文字、表、信頼度
Claude APIAPI呼び出し処方の行の項目分け
請求システム定時の書き出しを読む医薬品マスタ、患者一覧
電子薬歴定時の書き出しを読む直近の処方
受付の一覧店舗の画面への表示下書きと確認点

請求システムにも電子薬歴にも書き込みません。 受付を作るのは医療事務、薬歴を書くのは薬剤師で、機械が書いた受付や薬歴が混ざると、誰が確かめたのかが記録から分からなくなります。 受付の一覧から請求システムへの入力は、医療事務が一覧を見ながら行います。取り込みの機能がある製品なら、一覧で確定した行だけを取り込む形にします。

Step9

人が確認する

医療事務が見るのは match が matched 以外の行と、flags の付いた行だけです。 それ以外の行は、一覧で薬品名と用量を流し見て受付を作ります。

  1. low_confidence の行 … FAXの画像の該当部分を切り抜いて表示し、文字を読み直します。読めなければ医療機関に確かめます
  2. ambiguous と not_found の行 … 候補から選ぶか、マスタに無い薬なら薬剤師に回します
  3. handwritten_note の行 … 追記の意味を薬剤師に回します
  4. 確認点(薬剤師) … checkpoints の事実を見て、薬歴の画面で前後を確かめ、問い合わせの要否を決めます
  5. 原本の照合(薬剤師) … 原本とFAXの下書きの違いの一覧を見て、原本の画像で確かめます

4番目で薬剤師が見るのは、AIの結論ではなく事実の並びです。 単語には多角形の座標が付いて返るので、確認点の付いた行の画像を切り抜き、薬歴の直近の処方と並べて表示します。

施設のFAXの束は、入居者ごとに分けて一覧に並べます。 1回の受信で10人分の処方が届いても、一覧では10枚の処方箋として扱い、確認点の付いた入居者を上に出します。 束のまま1件として扱うと、確認点の無い入居者の処方まで薬剤師の手元で止まります。

目標は、900枚をならして1枚2分です。 確認が要る行を含む処方箋が3割前後という想定で、それより多い月は、FAXの送り元のどこかの画質が落ちているか、医薬品マスタの成分の列が欠けています。

Step10

例外に対処する

起きること対応
患者が1人に決まらない(同姓同名、生年月日の読み違い)確定させずに一覧へ。似た患者に当てない
新しい患者で患者一覧にいない受付で新規に作るまで薬歴を照らさない
薬がマスタで決まらないambiguous / not_found。候補から人が選ぶ
用量や日数の数字が読めないlow_confidence。前回の処方で埋めない。 医療機関に確かめる
同じ処方のFAXが2回届いた両方を並べ、送り直しか別の処方かを人が決める
原本とFAXの内容が違う違いの一覧を薬剤師へ。原本を正として扱うかは薬剤師が決める
原本が届かないまま日数が過ぎた一覧に「原本未着」を出し、患者や施設に連絡する
処方箋でない書類が混ざるdocument_type で取り分け、受付に戻す
OCRや生成AIが応答しない受信フォルダに残す。処理済みへ移すのは成功時だけ。 手入力の流れに戻せるようにする

最後の行は、薬局では特に大事です。 機械が止まっても患者は来ます。受信フォルダに残ったFAXを、従来どおり印刷して手で受け付けられる状態を保っておきます。

Step11

記録を残す

  • 受信したFAXのPDFと、受信日時・送り元
  • OCRが返したJSONの全文
  • 生成AIに渡した読み取り結果と、返った項目分け
  • 照合の結果(match、checkpoints)と、そのとき使った医薬品マスタと薬歴の書き出しの日時
  • 人が直した項目と、直す前後の値
  • 原本の読み取り結果と、FAXとの違いの一覧、薬剤師の確認の記録

4つ目で書き出しの日時を残すのは、薬歴が刻々と変わるためです。 確認点が出なかった処方について後から問われたとき、その時点の薬歴に何が載っていたかが分からないと、照合の漏れなのか薬歴の反映の遅れなのかを区別できません。

04実装レベルの3段階

最小構成:患者の情報を塗ったFAXを手でAIの画面に貼り、処方欄を表にさせる / 処方欄の読み取り
半自動化:上記+OCRのAPIと生成AIで項目に分け、医薬品マスタに照らして受付の一覧に下書きを出す / 読み取り、項目分け、マスタの照合
本格構成:上記+電子薬歴と照らした確認点、原本との差分の一覧 / 上記+重複と用量の変化の並べ出し、原本照合の支援

最小構成では件数がさばけません。 1枚ずつ貼るので、月900枚には使えません。確かめるための段階です。 半自動化で、1枚6分が4分程度になります。 受付の入力とFAXとの見比べが減りますが、薬剤師が薬歴を開いて探す作業と原本の照合が残ります。 本格構成で2分になり、この段階が本記事の想定です。 差が大きいのは、薬歴との照らし合わせと原本との照合が、どちらも1行ずつの目視だからです。

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

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

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

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

AI活用について相談する

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

向いている
  1. 複数の医療機関から処方箋のFAXが届く面分業型の調剤薬局や、数店舗を運営する薬局で、FAXを見ながら受付の事務担当が薬品名と用量を手で入力し、薬剤師が薬歴を開いて重複や用量の変化を探している場合。在宅の患者や施設の入居者の処方がFAXで先に届き、原本があとから来る運用がある場合。
向いていない
  1. FAXの事前送付がほとんど無く、患者が処方箋の原本を持参して受け付ける薬局。電子処方箋での受付が大半で、紙やFAXの処方を読む必要が少ない場合。なお、処方の内容に疑わしい点があるかの判断と疑義照会は薬剤師の職務であり、この構成では代替できません。

07最小構成で試す方法

  1. 先月受けたFAXの処方箋から30枚を選ぶ(施設の多行の処方と、読みにくかったものを含める)
  2. 患者の氏名・生年月日・保険の情報を黒く塗った画像を作る
  3. 手元のAIサービスの画面に1枚ずつ貼り、次のように指示する
  4. 「この処方箋の処方欄を、1行ごとに薬品名・規格・用量・用法・日数の表にしてください。読めない文字は □ にしてください。数字や単位を直したり補ったりしないでください」
  5. 出てきた表を、当時の受付の入力と1行ずつ見比べる

2番目を省かないでください。 試す段階で患者の情報を外部のサービスに出す必要はありません。見たいのは処方欄が読めるかどうかだけです。

出てきた内容判断
処方の行がほぼ正しく表になったOCRのAPIとマスタの照合に進む
小数点や単位を補って書き直した指示で直る。本番では信頼度で人に回す
特定の送り元のFAXだけ読めない送り元の機械か回線の問題。 送り方の相談が先
手書きの処方が読めない手書きの多い医療機関は、当面は手入力の流れに残す

3行目はよく出ます。 読めないFAXは、受付の担当者も読めていなかったものです。AIを入れる前に、送り元に送り方を相談するきっかけになります。

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

問題対策
小数点が消えて「05mg」になる数字を含む単語の信頼度のしきい値を高めにし、人に回す
生成AIが単位や小数点を補う補うことを禁じ、OCRの文字列と生成AIの値を機械で突き合わせる
読めない値を前回の処方で埋める埋めない。 医療機関に確かめる
似た名前の薬に寄せてしまうマスタとの完全一致で照合し、決まらなければ候補を並べる
一般名の処方と販売名の薬歴が重ならない成分の列で照合する
確認点が多すぎて薬剤師が見なくなる最大量の照合は登録のある薬だけにし、種類ごとの件数を毎週数える
確認点に「疑い」と書いてしまう事実だけを書く。 判断の言葉を使わない
手書きの追記を印字の値で上書きするnotes に分け、医療機関に確かめる
施設のFAXに複数の入居者が続くページで分け、患者の照合を1枚ずつ行う
機械が止まると受付が止まる手入力の流れに戻せる状態を残す

上の3行が、この構成の失敗のほとんどです。 どれも「読めない数字を、もっともらしい数字にする」という同じ形をしています。読めないものは読めないまま人に渡す、という一点を守れるかで、運用に乗るかが決まります。

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

この構成で扱うデータ: 患者の氏名・生年月日・保険の情報、処方の内容、薬歴。病歴や服薬の情報を含む、要配慮個人情報です。

  1. 疑義の判断をAIに渡さない … 薬剤師法は、処方箋中に疑わしい点があるときは医師に問い合わせて確かめた後でなければ調剤してはならないと定めています。確認点は事実の並びにとどめ、判断の言葉を使わない設計にしてください
  2. 処方を変えない … 同じく薬剤師法は、医師の同意を得た場合を除き、処方箋に記載された医薬品を変更して調剤してはならないと定めています。生成AIに代わりの薬や用量を提案させないでください
  3. 生成AIに渡す範囲を絞る … 項目分けに要るのは処方欄と備考です。患者の氏名と保険の情報の領域は、OCRの結果から除いて生成AIに渡す設計にできます。 患者の照合はスクリプトの側で行います
  4. クラウドの契約を確かめる … OCRには処方箋の画像全体を渡すため、患者の情報がサービス側に渡ります。データの所在地、入力を学習に使わない契約か、医療情報の安全管理の社内の基準に合うかを、導入前に確かめてください
  5. 原本との照合を省かない … 厚生労働省の通知は、FAXなどで電送されたものと処方箋の原本が同一の内容かの確認が容易な方法に限るとしています。FAXの下書きで薬をそろえても、渡す前の原本の確認は薬剤師が行います
  6. 人が直した記録を残す … 読み取りの値を人が直した記録は、後から「誰がこの値にしたか」を説明する根拠になります

誤りが起きた場合のリスクは、読み違えた用量や薬品名のまま受付データが作られることと、確認点が出るべき処方で出ないことの2つです。 前者は読めない数字を埋めると起き、後者は成分の列が欠けたマスタで照らすと起きます。どちらも設計で防げるので、そこは最初から守ります。

10まず何から始めるか

1週目:医薬品マスタと薬歴の書き出しを確かめる

請求システムの医薬品マスタに成分の列があるか、電子薬歴から患者ごとの直近の処方を医薬品コードと1日量で書き出せるかを確かめます。ここが取れなければ、本格構成の確認点は作れません。 製品の提供元に書き出しの方法を問い合わせます。

2週目:30枚で試す

患者の情報を塗ったFAXを30枚、手元のAIサービスに貼り、処方欄を表にさせます。小数点や単位を補っていないかを最優先で見ます。 読めない送り元が特定できたら、送り方の相談を始めます。

3週目:しきい値と確認点の種類を決める

数字を含む単語のしきい値、確認点の種類(同じ成分の残り日数、1日量の変化、最大量の登録との比べ合わせ)を、薬剤師と一緒に決めます。 確認点を増やしすぎないことが大事です。

4週目:受信フォルダから受付の一覧までをつなぐ

1店舗で、FAXの受信から医薬品マスタの照合、受付の一覧への下書きの表示までを組みます。この時点では薬歴との照合を入れず、読み取りと照合の精度だけを見ます。

2か月目: 電子薬歴の書き出しをつなぎ、確認点を出します。確認点の種類ごとの件数と、薬剤師が問い合わせに進んだ件数を毎週数えます。3か月目以降: 原本との差分の一覧を足し、残りの2店舗に広げます。施設のFAXがまとまって届く日にも、薬剤師が確認点をその日の午前のうちに見られている状態で、この構成は完成です。


11関連ユースケース

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

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

技術仕様確認日:2026-10-07/最終更新:2026-10-07
確認した内容情報源確認日
レイアウトモデルがテキスト、テーブル、選択マーク、ドキュメント構造を抽出すること。単語ごとに content と confidence、境界の多角形が返ること。表のセルに行と列のインデックスが含まれること。手書きのスタイルが styles に返ること。pages に回転の角度が含まれること。テキストの最小の高さが1024 × 768の画像で12ピクセル(150dpiで約8ポイント)であること。Free レベルでは最初の2ページのみが処理されること。モデルIDが prebuilt-layout であることMicrosoft Learn: ドキュメント レイアウト分析2026-10-07
レイアウトモデルの印刷テキストと手書きテキストの対応言語に日本語(ja)が含まれることMicrosoft Learn: 読み取りとレイアウトの言語サポート2026-10-07
患者等が調剤を希望する薬局へFAXで処方内容を電送し、薬局を来訪して処方箋と引換えに薬剤の交付を受ける場合の扱い。電送の方法は、電送されたものから処方内容を容易に確認でき、処方箋の原本と同一の内容かの確認が容易なものに限られること(平成26年2月5日 薬食総発0205第1号)厚生労働省: 電子メール等による処方内容の電送等について2026-10-07
薬剤師は医師等の同意を得た場合を除き処方箋に記載された医薬品を変更して調剤してはならないこと(第23条第2項)。処方箋中に疑わしい点があるときは、交付した医師等に問い合わせて確かめた後でなければ調剤してはならないこと(第24条)e-Gov 法令API: 薬剤師法2026-10-07
構造化出力が output_config の format に type: "json_schema" を指定して有効になること。スキーマに沿った応答が保証されること。数値の制約と文字列の長さの制約がサポートされないことClaude Docs: Structured outputs2026-10-07

医療情報を外部のクラウドで扱う際の安全管理の基準は、自社の方針と関係するガイドラインによります。この部分は薬局の管理者と情報システムの担当への確認が必要です。

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

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

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

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