介護施設が預かる入居者の預り金で買った日用品のレシートを読み取り、出納の記録と照合して、入居者別の月次の報告を家族向けに作る

処理の起点を決める

受付のフォルダにスキャンしたファイルが保存されたことを起点にします。 Apps Script の時間主導のトリガーで、15分ごとにフォルダを見て、新しいファイルがあれば読み取りに回します。事務員が1日の終わりにスキャンするので、その日のうちに照合の結果が出ます。

処理が終わったファイルは、処理済みのフォルダに移します。 移すのは読み取りと照合が成功したときだけにします。受付のフォルダに残っている数が、そのまま未処理の数になります。

月末の報告づくりは、別のトリガーにします。 毎月1日の朝に、前月分の照合が済んだ入居者を数え、印の残っている入居者の一覧を事務員に知らせます。 報告の下書きは、印が全部消えた入居者から順に作ります。

入力データを集める

質を決めるのは、3行目の出納の記録の付け方です。 まとめ買いのとき、記録に「まとめ買い」の印と、同じ買い物の他の入居者が分かる番号が無いと、 レシートの合計と記録を組にできません。記録の表に「買い物の番号」の列を足し、まとめ買いのときは同じ番号を付けることが、最初の準備作業です。

レシートには入居者の名前がありません。 そのため、どの入居者の分かは、出納の記録の側から決めます。 レシートは日付と金額で記録に結び付け、入居者は記録に書かれた入居者とします。

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

読み取りは、Apps Script からレシートの画像を Document AI の Expense Parser に送るだけです。呼び出すときに、日本語に対応した版を指定します。

日付と金額は、正規化された値を使います。 公式の一覧では、receipt_date と total_amount などが正規化の対象の項目に挙がっています。「2026/10/05」「26.10.5」「10月5日」のような書き方の違いを、こちらでそろえずに済みます。

出納の記録は、スプレッドシートを読むだけで足ります。 照合の順は、日付が先、金額が後です。 金額から先に引くと、同じ金額の別の日の買い物と組になってしまいます。

AIへ渡す前に整形する

1. 形式の確認 … PDFか画像であることを確かめ、それ以外は事務員に戻します
2. ファイルを分ける … 1回の処理は10ページまでなので、1日分をまとめたPDFは1枚ずつに分けます
3. 1枚に複数のレシートが写っていないかの確認 … 小さなレシートを並べて1枚にスキャンしたものは、事務員に戻して撮り直してもらいます
4. 向きと濃さの確認 … 感熱紙のレシートは時間がたつと薄くなります。薄いものはスキャンの濃さを上げて取り直します
5. 手書きの領収書の振り分け … 個人商店の手書きの領収書は、読み取りの後に handwritten の印を付け、事務員が記録と組にします
6. 重複の検知 … 同じ店・同じ日付・同じ合計のレシートが既にあれば、重複の疑いとして印を付けます

4番目を軽く見ないでください。 感熱紙のレシートは、月末まで封筒に入れておくと文字が薄くなります。毎日スキャンする運用にしているのは、この理由もあります。

5番目は、読めるかどうかではなく、照合に使えるかどうかの振り分けです。 Expense Parser の対応言語の一覧では、日本語は手書きにも対応とされています。ただ、手書きの領収書は品名が「品代」とだけ書かれ、明細の行が無いことがほとんどです。 合計と日付は読めても、何を買ったかが分からないので、報告の明細にそのまま載せられません。件数が少ないので、買い物をした職員に品目を聞いて、事務員が記録と組にするほうが確実です。

6番目の重複は、スキャンのやり直しで起きます。 薄くて取り直したレシートが、前のファイルと一緒に受付のフォルダに残ると、同じ買い物が2回分として照合されます。取り直したときは、前のファイルを事務員が消すのではなく、duplicate の印で照合から外します。 どのファイルを残したかが、後から分かるようにするためです。

AIに処理させる

させるのは2つだけです。品目の名前を区分にそろえることと、照合が済んだあとの報告の下書きを作ることです。 レシートと記録の組み合わせは、Apps Script の決まった規則で行います。

右端の列が、人の手間を減らす場所です。 略称が読めないときに、AIがそれらしい商品名を作ると、家族への報告に、実際には買っていない品の名前が載ります。 読めない略称はそのまま残します。

4行目がいちばん起きやすい失敗です。 「おむつの購入が増えています」と明細から読み取って、「排せつの状態が変わったようです」と書き足すことがあります。 家族にとっては重い一文で、しかも根拠がありません。添え状に書くのは、明細と残高の事実だけにします。

指示内容を固定する

品目の区分のそろえと、報告の下書きは、別の呼び出しにします。ここでは報告の下書きの指示を示します。

あなたは介護施設の事務員として、入居者の家族へ送る預り金の月次の報告の下書きを作る立場です。
下に渡す照合済みの明細と残高だけを使って書いてください。推測で書き足さないでください。

【作るもの】
1. statement …… 出金の明細の表。日付・店名・品目（家族が読める言葉）・区分・金額
2. summary …… 前月末の残高、当月の入金、当月の出金の合計、当月末の残高
3. cover_letter …… 添え状。次の構成で、400字以内
   - あいさつ（1文）
   - 当月の入金と出金の合計、月末の残高
   - 区分ごとの出金の合計（多い順に3つまで）
   - 問い合わせ先（施設の事務室）

【厳守事項】
- 金額は、渡した明細と残高の値をそのまま使ってください。計算し直さないでください。
- 品目の略称が読めないときは、略称のまま書いてください。商品名を作らないでください。
- 入居者の体調、生活の様子、介護の内容には触れないでください。
  購入の傾向から体調や状態を推し量る文を書かないでください。
- 「〜が増えています」「〜をおすすめします」のような評価や提案を書かないでください。
- 残高が少ないことへの入金のお願いは、【入金のお願いの有無】が yes のときだけ、
  決まった一文「次回のご入金をご検討いただけますと幸いです。」を加えてください。
- 入居者と家族の名前は、渡した値をそのまま使ってください。

【入居者】{resident_name}　【送り先】{family_name}
【照合済みの明細】{matched_lines}
【残高】{balance}
【入金のお願いの有無】{deposit_request}

「推し量る文を書かない」を2通りの言い方で書いているのは、1つでは止まらないからです。 体調に触れないと書いても、「おむつの区分が先月より多くなりました」のような、事実のようで含みのある文を書きます。評価や提案を禁じる一文を足して、ようやく事実だけになります。

入金のお願いを決まった一文にしているのも同じ理由です。 AIに書かせると、残高の少なさを強く書きすぎたり、家族の負担に触れたりします。お願いをするかどうかは事務員が決め、文面は固定します。

出力形式を固定する

レシートの読み取りと照合の結果は、レシート1枚ごとに次の形で残します。

{
  "receipt_id": "",
  "scanned_on": "",
  "receipt_date": "",
  "supplier_name": "",
  "total_amount": 0,
  "confidence": 0,
  "lines": [
    { "description_raw": "", "description": "", "category": "", "amount": 0 }
  ],
  "match": {
    "status": "matched | no_record | amount_diff | bulk_mismatch | duplicate | handwritten",
    "purchase_no": "",
    "resident_ids": [],
    "ledger_rows": []
  }
}

照合のプログラムは、出納の記録の側にも印を付けます。 レシートと組にならなかった記録の行には no_receipt を付けます。

1つ目の理由は、レシートと記録の両方の側から抜けを見られることです。 レシートの側からは付け漏れが、記録の側からはレシートのなくしが見えます。片方の側だけを見ると、どちらかの抜けが見えません。

2つ目は、構造化出力で形が崩れないことです。 品目の区分のそろえは、Claude API の構造化出力で、category を区分の表の値に限ったスキーマを渡して返させます。区分の表に無い値が返ってこないので、区分ごとの合計がずれません。

3つ目は、description_raw と description を分けて持つことです。 報告にはそろえた言葉を載せ、元の略称も残すので、家族から問い合わせが来たときにレシートの文字と突き合わせられます。

システムへ連携する

出納の記録の金額と品目の列には書き込みません。 照合の印は別の列に書き、記録を直すのは、職員に確かめたうえで事務員が行います。 記録を自動で直すと、写し違いと読み違いの区別が残りません。

家族への送付も、この構成からは行いません。 下書きを報告の様式に流し込むところまでで、送るのは施設長の確認のあと、事務員が行います。 メールで送る家族の宛先は、介護ソフトの値を毎月読み直し、前月の宛先を使い回しません。

人が確認する

人が見るのは、印が matched 以外のものだけです。 matched のレシートは、入居者ごとの件数を一覧で見るだけにします。

1. no_record と no_receipt を先に見る … 付け漏れとレシートのなくしです。買い物をした職員に、翌日のうちに聞きます
2. amount_diff を見る … レシートの画像を開き、記録の金額と見比べます。写し違いなら記録を直し、直した理由を残します
3. bulk_mismatch を見る … 同じ買い物の番号の記録を並べ、誰の分がいくらだったかを職員に確かめて記録を直します
4. 報告の下書きを確かめる … 明細と残高が記録と合っているか、添え状に事実以外のことが書かれていないかを見ます
5. 施設長が確かめる … 残高の大きな動きと、家族からの問い合わせが過去にあった入居者を重点に見ます

1番目を月末まで待たないでください。 毎日読み取っているので、食い違いは翌日には分かります。 職員の記憶が新しいうちに聞けば、多くはその場で片づきます。

4番目の添え状は、必ず目で読みます。 事実以外の一文が混ざっていないかは、プログラムでは確かめきれません。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、スキャンの仕方とレシートの保管の問題です。 毎日スキャンする運用と、1枚ずつ読み取らせる設定のほうが、読み取りの工夫より効きます。

記録を残す

• 元のレシートの画像と、スキャンした日
• Document AI が返した JSON の全文（値、明細、信頼度）
• 照合の結果（match）と、そのときの出納の記録の内容
• 事務員が記録を直した記録 … どの行を、何から何に、誰に確かめて直したか
• 報告の下書きと、施設長が確かめて送った版
• 家族からの問い合わせと、そのとき示したレシート

4つ目は、預り金の管理そのものの記録です。 記録の直しが多い職員や時期が分かれば、付け方の手順を見直す材料になります。

最後の行は、報告の書き方を直す材料になります。 同じ種類の問い合わせが続くなら、明細の言葉のそろえ方か、区分の分け方に分かりにくさがあります。