自治体の介護保険の担当課に毎月届く住宅改修の事前申請書・見積書・理由書を読み取り、工事の種類と金額を支給の要件と限度額に照らして、不足書類と確認点を拾う

処理の起点を決める

スキャンした書類が、Cloud Storage の申請番号のフォルダに保存されたことを起点にします。 窓口で受け取った書類はその場でスキャンし、郵送のものは開封した日にスキャンします。

読み取りはファイルが届くたびに行い、台帳の案と不足の判定は「受付完了」の操作で行います。 窓口で書類が後から追加されることがあり、最初の1枚で「理由書が不足」と出すと、翌日持参される書類と行き違います。 受付の担当が、その申請の書類をすべてスキャンし終えたところで受付完了を押します。

同じ人の申請が続けて届くこともあります。 浴室とトイレを別々の時期に改修する場合です。被保険者番号で過去の申請を引き、限度額の残りは直前の申請の分を差し引いてから出します。 事前の確認を終えて工事を待っている申請の額も、まだ支給の実績には載っていないので、審査の台帳の「確認済み・未支給」の額を足して差し引きます。 ここを抜くと、同じ月に2件出た申請の両方が限度額の内に見えます。

入力データを集める

質を決めるのは、いちばん下の判断の記録です。 「浴槽の交換」「給湯器の交換」「手すりの取付けに伴う壁の補強」のように、担当者が過去に対象・対象外と判断した明細の言い方と理由を一覧にしておくと、AIの当てはめの根拠になります。第3章の（c）の「人によって違う線」を、この一覧でそろえます。

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

すべてのファイルを Enterprise Document OCR に通し、申請書・理由書・見積書は Form Parser にも通します。

理由書の工事の種別は、□に印を付ける形と、文字で書く形があります。 □の形ならチェックボックスとして取り、印が付いているか（valueType が filled か unfilled か）で読みます。ただし公式の説明では、検出したチェックボックスに対応するキーが無いことがあるとされています。キーが取れなかった□は、位置から様式の項目に当てます。

支給の実績は、業務システムの照会の機能か、日次で出力されるデータから読みます。 業務システムに外部から読める仕組みが無い場合は、日次の出力ファイルを Cloud Storage に置く運用にします。

AIへ渡す前に整形する

1. 形式とサイズの確認 … オンライン処理は1ファイル40MBまでです。超えるものはバッチ処理に回します
2. ページ数の確認 … Form Parser のオンライン処理は15ページまでです。写真を何枚も貼った資料で超えるものは、写真のページを分けて Enterprise Document OCR だけに通します
3. 画素数の確認 … 画像は1ページ4,000万画素までです
4. 書類の分割 … 窓口で1つのPDFにまとめてスキャンしたものは、表紙の文字から書類ごとに分けます
5. 写真のページの扱い … 改修前後の写真は文字が少ないので、撮影日の書き込みと箇所の説明だけを読みます

4番目が、窓口の運用で最も手間を減らせるところです。 書類ごとに分けてスキャンしてもらえば分割は要りません。最初の数か月は分割の処理を持ち、窓口の運用が定着したら外します。

5番目で写真を読み込みすぎないのも、意図してのことです。 改修前の写真には室内の様子や家族の持ち物が写ります。この構成で写真から取るのは、撮影日と箇所の書き込みだけにし、写真の中身の判断は担当者が画面で行います。撮影日が読めない写真は、事前申請の段階では印を付けるだけにとどめ、事後の申請で撮影日の分かる写真がそろっているかを見ます。

AIに処理させる

最後の行がいちばん起きやすい失敗です。 「浴室改修工事 一式 25万円」の内訳を聞くと、AIは手すりと段差の解消に金額を割り振ってそれらしい内訳を作ります。その数字が台帳に載れば、事業者に内訳を求めるという本来の照会が消えます。

判断の記録は、AIに「答え」としてではなく「参考」として渡します。 同じ「床の張替え」でも、滑りの防止のための材料の変更なのか、傷んだ床の取り替えなのかで扱いが変わります。言い方が一致しても、理由書に書かれた目的と合わなければ unknown に残すように指示し、参考にした行の番号を必ず返させます。担当者はその番号から、過去の判断の理由をすぐに読めます。

指示内容を固定する

あなたは市の介護保険課で、住宅改修の事前申請の書類を確認する担当の補助です。
見積書の明細を、介護保険の住宅改修の種類に当てはめます。
書類に書かれていることだけを根拠にしてください。推測で埋めないでください。

【住宅改修の種類】
1 手すりの取付け
2 段差の解消
3 滑りの防止及び移動の円滑化等のための床又は通路面の材料の変更
4 引き戸等への扉の取替え
5 洋式便器等への便器の取替え
6 その他前各号の住宅改修に付帯して必要となる住宅改修

【明細ごとの category の選び方】
- 1〜6 ........ 上の種類に当たると読める
- excluded? ... 上のどれにも当たらない工事に読める（対象外の候補）
- bundled ..... 複数の工事が1行にまとまっていて、分けないと判断できない
- unknown ..... 書き方から判断できない

【厳守事項】
- 判断の記録に同じ言い方があれば、それに従い ref に行番号を書いてください。
- 6（付帯工事）は、どの種類に付帯するかを related に書けるときだけ選んでください。
- 一式の行の金額を、工事ごとに割り振らないでください。bundled にしてください。
- 保険給付として適当か、支給できるかは書かないでください。
- 金額の合計や限度額の計算をしないでください。
- 品質の点数が0.5未満の領域から読んだ行は status を unreadable にしてください。
- 各行に、見積書の行の文字列をそのまま evidence に写してください。

【理由書に書かれた工事の種別】{reason_form_types}
【判断の記録（言い方・判断・理由）】{decision_log}
【見積書の読み取り結果（行ごと、品質の点数付き）】{estimate_rows}

「6は、どの種類に付帯するかを書けるときだけ」を入れているのは、6が逃げ道になりやすいからです。 何も言わないと、当てはめに迷った行が「その他付帯」に集まります。付帯する先を書かせることで、迷った行は unknown に残ります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude の構造化出力（output_config.format に json_schema を指定）を使い、項目の名前と型を固定します。

{
  "application_id": "JK-2026-0912",
  "insured_no": "",
  "documents": [
    { "file": "scan_0001.pdf", "pages": [2, 3], "doc_type": "estimate" }
  ],
  "estimate_lines": [
    { "line_no": 4, "place": "浴室", "text": "浴室用手すり I型 600mm 取付",
      "amount_text": "28,600", "category": "1",
      "related": "", "ref": "D-012", "status": "ok | unreadable",
      "evidence": "浴室用手すり I型 600mm 取付 1 28,600" }
  ],
  "cost_breakdown": { "material": "", "labor": "", "overhead": "", "total": "" },
  "reason_form": { "author_role": "", "types": ["1", "2"] }
}

1つ目の理由は、category に「1〜6」以外の値を持てることです。 excluded?、bundled、unknown を分けることで、担当者が見るべき行が種類ごとに並びます。

2つ目は、cost_breakdown で内訳の区分の有無を見られることです。 厚生労働省の通知では、見積もりは材料費、施工費、諸経費等を適切に区分したものとされています。3つのどれかが空なら、関数が印を付けます。

3つ目は、金額を文字列で受けることです。 構造化出力では数値の範囲や文字数の制約は使えないとされているため、数値への変換と検算は関数で行います。

関数が規則で付ける印は、次のとおりです。

システムへ連携する

業務システムには書き込みません。 支給の決定は、事後の申請の後に担当者が業務システムで行います。この構成が関わるのは、事前の確認の段階だけです。

人が確認する

1. scope_check の行を画像で見る … 対象外の候補とまとめ書きの行は、見積書の画像で中身を確かめます
2. reason_mismatch を見る … 理由書と見積書のどちらが足りないのかを確かめ、照会先を決めます
3. over_limit を見る … 要介護の段階が3段階以上上がった、転居したなど、限度額がもう一度設定される事情がないかを業務システムで確かめます
4. 照会の文案を直して送る … 事業者とケアマネジャーに照会します
5. 確認の結果を教示する … 被保険者に結果を伝えます。事後の支給の決定とは異なることも合わせて説明します

1件あたり8分を目安にします。 印の無い申請は台帳の案の流し読みで数分、scope_check のある申請は見積書を読み直すので10分を超えます。ならして8分です。

3番目を規則にしていないのは、意図してのことです。 限度額がもう一度設定される条件は通知で決まっていますが、着工の時点の要介護状態区分と比べる必要があり、認定の変更の途中にある申請では判断が分かれます。 関数は印を付けるまでにし、担当者が確かめます。

例外に対処する

6行目は、通知で扱いが決まっている場面です。 一の住宅に複数の被保険者がいる場合、限度額は被保険者ごとに管理され、共用の居室の床材の変更などは、いずれか一方だけが申請するとされています。関数は同じ住所の申請を並べて示すまでにします。どちらの申請に共用の箇所を含めるかは、世帯とケアマネジャーに確かめて担当者が決めます。

記録を残す

• 届いた書類の原本と、受付の日時・経路（窓口／郵送）
• Document AI が返した結果の全文と、Claude が返したJSON、使った指示の版
• 関数が付けた印と、そのとき使った判断の記録・必要書類の一覧の版
• 担当者が当てはめを直した記録 … どの明細を、どの種類から何に変えたか、その理由
• 照会の内容と回答、教示した日と内容

4つ目は、判断の記録に戻して育てます。 理由まで残すのが要点です。 担当者が直した言い方を判断の記録に足すと、翌月から同じ言い方の明細で迷わなくなり、担当者による線の違いも減ります。