利用者の介護保険被保険者証と負担割合証のコピーを読み取り、請求マスタの要介護度・認定期間・負担割合を更新して、期限が近い利用者の一覧を作る

処理の起点を決める

共有フォルダの「受付」にファイルが追加されたことを起点にします。 事業所の職員は、証のコピーを取ったらすぐに入れます。月末にまとめて処理すると、入力漏れが請求に間に合わないという今の問題がそのまま残ります。

ファイルの名前に利用者を書いてもらう運用は取りません。名前の付け方は事業所ごとにばらつき、誤りも起きます。 利用者の特定は、証に印字された被保険者番号で行います。

処理が終わったファイルは「処理済み」へ移し、撮り直しの候補は「撮り直し」へ移します。 移すのは処理が成功したときだけにします。「受付」に残っているファイルの数が、そのまま未処理の数になります。

期限の一覧は、別のきっかけで動かします。 毎週月曜の朝に、請求マスタの日付から期限が近い利用者を拾い直します。証の読み取りが無い週でも、期限は近づくからです。

入力データを集める

質を決めるのは、請求マスタの書き出しの鮮度です。 差分は「いまのマスタの値」と比べて出すので、書き出しが古いと、すでに入力済みの変更が差分として出てきます。 介護ソフトから利用者情報を書き出すのを、毎朝の決まった作業にします。

被保険者証の欄の並びは、全国でほぼ共通の様式です。 ただし、写真では折り目や指で欄が隠れることがあり、コピーが複数の画像に分かれて届くこともあります。 同じ時刻に同じ事業所から入った画像は、1件の証として束ねます。

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

処理はオンライン（同期）の要求で、1件ずつ送ります。 オンラインの要求は、Form Parser も Enterprise Document OCR も15ページまで、ファイルの大きさは40MBまでです。証のコピーは1件で数ページなので、この範囲に収まります。夏の負担割合証の入れ替えのように件数が増える時期は、バッチの要求（Enterprise Document OCR は500ページまで、Form Parser は100ページまで）に切り替えます。

負担割合証の適用期間は、表として取ります。 途中で割合が変わった証では、「適用期間」と「利用者負担の割合」の組が複数行に並びます。表として取れなかったときは、全文から生成AIに行を数えさせ、行の数を必ず返させます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDFであることを確かめます。スマートフォンの HEIC は JPEG に変換します
2. 束ねる … 同じ事業所から10分以内に入った画像を1件の候補として束ねます。束ね方が怪しいものは、被保険者番号が読み取れてから確定させます
3. 品質の確認 … 品質スコアが0.5を下回り、ぼけ、切れ、反射が返ったページは、撮り直しの候補にします
4. 向きの補正 … 横向きや逆さまの写真を、読み取りの前に回転させます
5. 重複の確認 … 同じ被保険者番号、同じ証の種類、同じ交付年月日のものが直近にあれば、既処理として印を付けます

3番目を軽く見ないでください。 証の写真は、テーブルの上で斜めに撮られ、照明が反射し、指が欄にかかります。品質の足りない画像を読み取りに進めると、認定の有効期間の日付を1文字読み違えるだけで、期限の一覧が1年ずれます。 撮り直しは、事業所の職員がその場でできるうちに頼むのがいちばん早く済みます。

撮り直しの依頼には、不具合の種類を添えます。 「反射」と返ったなら照明の位置を変える、「書類の切れ」なら全体が入るように撮る、と直し方が具体的に伝わります。

AIに処理させる

させるのは、証の種類を判定し、決めた項目を取り出し、読み取りの迷いを正直に返すことです。

最後の行が、この構成でいちばん大事な区別です。 給付制限の欄は空欄なのがふつうで、記載があれば請求の扱いが変わります。 「空欄」と「読めない」を混ぜると、記載のある証を空欄として通すか、空欄の証をすべて人に回すかのどちらかになります。Form Parser は値が空の組を確実には取れないので、 全文の該当箇所を生成AIに読ませて判定させます。

4行目で和暦を変換させないのは、変換の誤りを防ぐためです。 「令和8年10月31日」を西暦に直す作業は、Python の表で行えば誤りが起きません。生成AIには、書かれている文字をそのまま返させます。

4行目がいちばん起きやすい失敗です。 請求マスタの値を一緒に渡すと、AIは読めなかった欄をマスタの値で埋め、差分が無いという結果を返します。 読み取りの段階では、マスタの値を渡しません。比べるのは後段の Python です。

指示内容を固定する

あなたは介護事業所の請求担当として、利用者の保険証のコピーを読み取る立場です。
OCRが返した全文と、項目の名前と値の組だけを見て答えてください。推測で埋めないでください。

【やること】
1. 書類の種類を判定してください（被保険者証／負担割合証／それ以外）。
2. 書類の種類に応じて、決められた項目を取り出してください。
3. 負担割合証では、適用期間と利用者負担の割合の組を、書かれている行の数だけ返してください。
   行の数（period_count）を必ず返してください。

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- blank ........ 欄はあるが、値が書かれていない
- unreadable ... 文字は検出されているが、値として確定できない
- ambiguous .... 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 書かれている文字を、そのまま value に入れてください。
  和暦を西暦に直さないでください。数字の桁を補わないでください。
- 被保険者番号や日付の一部が読めない場合、読めた部分だけで埋めず unreadable にしてください。
- 給付制限の欄は、空欄なら blank、読めなければ unreadable です。
  空欄かどうか分からないときに blank を選ばないでください。
- 要介護状態区分は、要支援1・要支援2・要介護1〜5の表記のまま返してください。
- 書類が被保険者証でも負担割合証でもない場合は、項目を取り出さず document_type に種類を書いてください。
- 複数の利用者の証が1つの画像に写っている場合は、multiple_persons を true にしてください。

【OCRの全文】{ocr_text}
【項目の名前と値の組】{kv_pairs}
【表】{tables}

「行の数を必ず返す」を指示しないと、負担割合証の2行目が落ちます。 適用期間が2つ並んだ証を渡すと、AIは多くの場合、目立つほうの1行だけを返します。行の数を別の項目で返させれば、Python で「行の数と返した組の数が合うか」を照合できます。 第3章の（c）の見落としを、機械で止められます。

「空欄か分からないときに blank を選ばない」も同じ理由です。 何も言わなければ、検出された文字が無い欄を blank にします。文字が無いのか、写っていないのかは別のことです。

出力形式を固定する

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

{
  "file_ids": [""],
  "document_type": "insured_card | copay_card | other | unknown",
  "multiple_persons": false,
  "insured_no": { "value": "", "status": "ok | blank | unreadable | ambiguous" },
  "insurer_no": { "value": "", "status": "" },
  "care_level": { "value": "", "status": "" },
  "cert_period": { "start": "", "end": "", "status": "" },
  "benefit_restriction": { "value": "", "status": "" },
  "copay_periods": [
    { "ratio": "", "start": "", "end": "", "status": "" }
  ],
  "period_count": 0
}

Gemini API には、この形の JSON Schema を渡して、その形に沿った出力を返させます。 公式の説明でも、出力が構文として正しいJSONであっても、値はアプリケーションの側で必ず検証するよう求められています。

1つ目の理由は、読み取りと差分を別の層に置けることです。 このJSONはAIが埋め、請求マスタとの比較は Python が行います。Python は和暦を西暦に直し、被保険者番号で利用者を特定し、項目ごとに same ／ changed ／ new を付けます。

2つ目は、期限の計算を同じデータから行えることです。 認定の有効期間の終わりと、負担割合の適用期間の終わりを西暦に直し、今日からの日数で期限の一覧を作ります。 一覧の区切り（たとえば90日以内、60日以内）は法人で決めます。

3つ目は、status があることで承認が速くなることです。 請求担当は、ok のものは値を流し見て承認し、それ以外の項目だけを画像で確かめます。

システムへ連携する

介護ソフトへは、直接書き込みません。 取り込みファイルを作り、請求担当が中身を見てから取り込みます。 承認と取り込みのあいだに人が入ることで、取り込みの直前に別の担当者が手で入力していた、という重なりにも気づけます。

期限の一覧は、事業所ごとに分けて置きます。 ケアマネジャーや管理者は、自分の事業所の利用者だけを見れば足ります。他の事業所の利用者の情報が見える一覧にはしません。

人が確認する

請求担当が見る順番を、差分の扱いで決めておきます。

1. needs_human を先に見る … 画像で該当の欄を確かめます。多くは撮り直しの依頼で解決します
2. retro_check を見る … 遡りがある差分です。証の原本の確認と、過去の請求の調整が要るかを検討します
3. auto_ready を承認する … 値を一覧で読み、画像の該当箇所と並べて確かめます。特に負担割合は、必ず画像で見ます
4. 取り込みファイルを介護ソフトに取り込む … 取り込んだ件数と、承認した件数が合うかを確かめます
5. 判定を覆したら記録する … どの項目を、どの値に直したかを残します

3番目で負担割合を必ず画像で見るのは、誤りの影響がいちばん大きいからです。 1割と2割を取り違えると、利用者への請求額が倍か半分になります。読み取りの信頼度が高くても、この1項目だけは目で確かめる運用にします。

2番目の判断は、請求担当の仕事です。 杉並区の事業者向けの案内では、遡って負担割合が変わった場合、事業者は利用者との差額の調整と、国保連への介護給付費の過誤の再請求を行う必要があるとされています。この構成は、その候補を漏れなく拾うところまでを受け持ちます。

例外に対処する

2行目で氏名を使わないのは、同姓同名がいるからです。 700名の利用者がいれば、同じ読みの氏名は珍しくありません。利用者の特定を誤ると、別の人の負担割合を書き換えます。

最初の行が、件数のいちばん多い例外です。 どれもAIの問題ではなく、証の撮り方の問題です。 撮り方の手引きを1枚作って事業所に配るほうが、読み取りの設定をいじるより効きます。

記録を残す

• 証のコピーの原本の画像と、受け取った日時・事業所
• OCRが返した結果（品質スコア、全文、項目の名前と値の組、表、信頼度）
• 生成AIが返したJSONの全文と、使ったモデルの名前
• 比較に使った請求マスタの書き出しの日時と、差分の内容
• 承認した人、承認した日時、承認の前に直した項目と値
• 介護ソフトに取り込んだ日時と件数
• 撮り直しを依頼した日時と、不具合の種類、撮り直された画像との対応

4つ目で「比較に使ったマスタの日時」を残すのは、差分の意味が後から変わるためです。 手入力と取り込みが重なったとき、どちらが先だったかが分からないと、誤った値がどこから入ったかを追えません。

最後の行は、事業所への手引きを直す材料になります。 特定の事業所で「反射」が続くなら、撮る場所の照明に理由があります。