介護施設で薬局から毎月届く薬剤情報提供書を読み取り、利用者ごとの服薬一覧を更新して、追加・中止・用量変更を看護職員に知らせる

処理の起点を決める

事務の担当者が書面を取込フォルダに保存することを起点にします。 薬局から届いた書面は利用者ごとに分け、スキャンしたファイルの名前を「利用者ID_薬局コード_受取日」にします。Apps Script の時間主導型トリガーが10分おきに取込フォルダを見ます。

1回の実行で処理する枚数に上限を置きます。 Apps Script の1回の実行は6分までなので、1回に8枚までとし、残りは次の実行に回します。 定期の処方が届く日は百枚を超えることがあり、上限を置かないと途中で止まった実行が同じ書面を二度読みます。処理済みのフォルダへ移すのは、突き合わせの結果を書き出し終えたときだけにします。

1日の実行の合計時間にも上限があります。 公式の割り当てでは、トリガーの実行時間の合計は個人のアカウントで1日90分、Google Workspace で1日6時間です。定期の処方の日に詰まらないよう、Workspace のアカウントで動かす前提にします。

入力データを集める

質を決めるのは、いちばん下の2つです。 薬品の対応表が無ければ、書き方が違うだけの薬がすべて added になります。処方元の一覧が無ければ、ある薬局の書面に別の医療機関の薬が載っていないのは当たり前だ、ということを機械が知りません。

前月の服薬一覧には「処方元」の列を足します。 いまの一覧に無ければ、これが最初の準備作業です。not_in_document を出すかどうかは、同じ処方元の書面に載っていないときだけに絞るからです。

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

読み取りは、Apps Script から Document AI の処理の API を呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

数字の欄は、信頼度を欄ごとに見ます。 「5mg」と「0.5mg」、「1錠」と「7錠」の違いは、1文字の読み違いで生まれます。規格と1回量の欄の中で、基準を下回る文字が1つでもあれば low_confidence を付けます。 行全体の平均で見ると、1文字の読み違いが埋もれます。

利用者の氏名と住所は、ここで Apps Script が伏せます。 ファイル名の利用者IDで一覧と結び付けるので、生成AIに氏名を渡す理由がありません。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、TIFF、JPEG、PNG などです。スキャナの設定をPDFに固定します
2. 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。規格の小さな数字を読むため、300dpiで取ります
3. ページ数の確認 … Form Parser の同期の処理は15ページまでです。1人分の書面が15ページを超えることはまれですが、まとめてスキャンしたものは利用者ごとに分けます
4. 向きの確認 … 横向きの書面は向きを直します
5. 薬の写真の扱い … 書面に薬の写真が並ぶ書式は、写真の部分を読み取りの対象から外しません。表の構造を崩さないため、ページはそのまま渡します
6. 重複の確認 … 同じ利用者・同じ薬局・同じ調剤日のファイルが既にあれば、二重に読まずに印を付けます

2番目を軽く見ないでください。 規格の「.」（小数点）は、解像度が足りないと最初に消える文字です。「0.5mg」が「05mg」や「5mg」と読まれると、10倍の量の薬として一覧に載ります。 低い解像度の書面を読ませて low_confidence を並べるより、最初に取り直すほうが確実です。

AIに処理させる

させるのは、表の各行を項目に分けることだけです。 薬品名をそろえる判断、前月との違いの判断、処方の適否の判断はさせません。

用法を言い換えないことを、表に明記しています。 「分3毎食後」を「1日3回朝昼夕食後」に直すのは、規則でできます。AIが直すと、直したという事実が記録に残りません。 そろえるのは Apps Script の対応表の仕事にします。

2行目がいちばん起きやすい失敗です。 読み取りが「05mg」と返したとき、AIは前後から考えて「0.5mg」に直したがります。直した値が正しくても、直したという事実が消えれば、人はその欄を確かめません。 直すのは人で、AIには読めた文字のまま返させ、信頼度で印を付けます。

指示内容を固定する

あなたは介護施設で、薬局から届いた薬剤情報提供書の表を、
項目に分けて書き写す立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 表の各行を、1つの薬ごとに次の項目に分けてください。
   薬品名、規格、剤形、1回量、1日の回数と用法、日数または回数
2. 1つの薬が2段以上に分かれて書かれている場合は、1つの行にまとめてください。
3. 注意事項欄や表の外に、薬の中止・変更・追加について書かれた文があれば、
   その文をそのまま写し、どの薬品名についての文かを書いてください。
4. 調剤日、処方元の医療機関名、薬局名が書かれていれば写してください。
5. 読み取り結果の中の [MASKED] は伏せた値です。そのままにしてください。

【厳守事項】
- 文字は書かれたものをそのまま入れてください。
  規格と1回量は、数字・小数点・単位を1文字も直さないでください。
  不自然に見える数字でも、読み取り結果の文字のまま写してください。
- 用法は書かれた表記のまま写し、別の言い方に言い換えないでください。
- 商品名を一般名に、一般名を商品名に言い換えないでください。
- 書かれていない項目は空にしてください。ほかの行や薬品名から推し量らないでください。
- この書面に載っていない薬について、何も書かないでください。
  中止されたかどうかを推し量らないでください。
- 処方の量や飲み合わせが適切かどうかについて、何も書かないでください。
- evidence には、各行の根拠にした文字列をそのまま写してください。

【読み取り結果（表、キーと値の組、全文。氏名・住所は伏せてあります）】{ocr_result}

「この書面に載っていない薬について何も書かない」を入れるのは、AIが親切に補うからです。 何も言わなければ、前月の一覧を見せていないのに「降圧薬は今回含まれていません」のような一言を添えることがあります。載っていないことの意味を決めるのは、処方元の一覧と規則です。

「飲み合わせについて書かない」も同じ理由です。 「併用注意」のような一言があると、看護職員はそれが誰の判断なのか分からないまま読みます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、output_config.format に json_schema の形でスキーマを渡すと、制約付きのデコードでスキーマに従う応答を返すとされています。enum と required を使え、オブジェクトの additionalProperties は false にする必要があります。

{
  "dispensed_date": "",
  "prescriber": "",
  "pharmacy": "",
  "items": [
    {
      "drug_name": "",
      "strength": "",
      "form": "",
      "dose": "",
      "usage": "",
      "days": "",
      "evidence": ""
    }
  ],
  "change_notes": [
    { "drug_name": "", "note": "" }
  ]
}

信頼度はこのJSONに入れません。 欄ごとの信頼度は Document AI の応答から Apps Script が直接取り、evidence の文字列の位置と突き合わせて付けます。AIに信頼度を書かせると、それらしい数字を書きます。

前月との違いは、Apps Script が規則で付けます。

この表が、出力を分けた理由です。 AIが返すのは書面に書かれたことだけで、前月と比べてどうかは一覧、同じ薬かは対応表、値が確かかは信頼度という別々の物差しで状態を決めます。対応表を直せば、AIを呼び直さずに判定だけをやり直せます。

not_in_document は、臨時の書面からは出しません。 臨時の処方の書面に定期の薬が載っていないのは当たり前で、ここで not_in_document を出すと、看護職員が毎回同じ確認をすることになります。 定期か臨時かは、ファイル名と処方元の一覧から Apps Script が決めます。

システムへ連携する

服薬一覧への書き込みは、看護職員の承認を条件にします。 確認用シートに「承認」の列を置き、承認の印が付いた行だけを、次の実行で一覧に反映します。 承認の前に一覧が変わると、配薬の担当者が確認前の内容を見ることになります。

変更点の掲示用シートは、申し送りの代わりではありません。 夜勤の介護職員が勤務の始めに開く一覧として置き、口頭の申し送りは今までどおり続けます。 掲示用シートには、反映した日時と承認した看護職員の名前を並べます。

人が確認する

看護職員が見るのは、continued 以外の行だけです。 continued は件数を流し見るだけにします。全行を書面と見比べる設計にすると、第10章の20.0時間には収まりません。

1. low_confidence の欄を書面と見比べる … 規格と1回量は1文字ずつ見ます。読めなければ薬局に確かめます
2. stop_stated と not_in_document を確かめる … 前者は書面の記載を読み、後者は消す前に薬局か処方元に問い合わせます
3. added・dose_changed・usage_changed を確かめる … 書面と見比べ、承認の印を付けます
4. 対応表に無い書き方を登録する … 書き方違いの同じ薬だった場合は、対応表に1行足します

2番目を省かないでください。 not_in_document の薬を確認せずに一覧から消すと、飲み続けるはずの薬が配薬から外れます。 問い合わせて中止と分かったときだけ消し、問い合わせの記録を残します。

目標は、300件をならして1件4分です。 前月と違う行が出る書面は3割前後という想定で、それより多い月は、対応表の不足か、薬局の書式の変更を疑います。

例外に対処する

5行目を自動で直さないでください。 ファイル名と書面の氏名が違うのは、多くは分けるときの取り違えです。別の利用者の一覧と突き合わせると、存在しない変更が大量に出ます。 照合の前に止めるのがいちばん安全です。

記録を残す

• 元の書面のファイルと、利用者ID・薬局コード・受取日・取込の日時
• Document AI が返した Document のJSONの全文
• Claude API に渡した伏せた後の読み取り結果と、返ってきたJSON
• Apps Script が付けた行ごとの状態と、そのとき使った対応表の版
• 看護職員が承認した日時と担当者、承認しなかった行とその理由
• not_in_document について問い合わせた先、日時、答え

4つ目で対応表の版を残すのは、表が毎月育つためです。 先月 added だった薬が今月は continued になるのは、対応表に行が足されたからかもしれません。版が残っていないと、判定の違いが書面の違いなのか表の違いなのか分かりません。

最後の行は、薬局との相談の材料になります。 同じ薬局で not_in_document が続くなら、定期の書面の出し方を相談します。