# 児童手当認定請求書 スキャン一次審査 — 営業・デモガイド

## これは何か（1分説明）

紙で提出された**認定請求書（様式第二号）のスキャン画像をアップロードするだけ**で、①VLMによる記載内容の忠実な転記 → ②児童手当法・施行規則・令和6年10月改正資料のナレッジ検索 → ③4観点の一次審査 → ④判定結果まとめ（審査メモ＋申請者への連絡文案）まで一気通貫で実行するワークフローです。既存の「児童手当認定請求事前レビュー」（テキスト貼り付け版）の**入口を実務の紙申請に合わせて拡張**したものです。

- 転記は「書かれていることだけ」: 空欄=（記載なし）／読めない字=（判読不能・要目視確認）／個人番号は**有無のみ**転記
- 審査はテキスト版と同じ建付け: 全判定に[根拠: 文書名]タグ、末尾に「最終判断は職員」固定文言
- 出力は2つ: `transcription`（転記全文＝データ化成果物）と `result`（審査メモ＝判定結果まとめ）

## 実務調査の結果（2026-07-30、この設計の根拠）

児童手当の認定請求が自治体に届く経路を調べた結果:

| 経路 | 実態 | 本WFでの扱い |
|---|---|---|
| **紙（窓口・郵送）** | 主流。様式は自治体サイトのPDFを印刷して手書き記入（[目黒区](https://www.city.meguro.tokyo.jp/kosodateshien/kusei/onlineservice/jidoteateninteiseikyusyo.html)・[杉並区](https://www.city.suginami.tokyo.jp/s053/shinseisho/8682.html)等）。一部自治体はExcel様式も配布（[生駒市](https://www.city.ikoma.lg.jp/0000000629.html)等） | **本WFの対象**。スキャン画像をアップロード→VLM転記 |
| **電子申請（マイナポータル/ぴったりサービス）** | 児童手当は子育てワンストップの対象手続。申請データは**ZIP内のXML/CSV（レイアウト定義済み）**として申請管理システムに届く（[総務省 申請管理システム標準仕様書](https://www.soumu.go.jp/main_content/000944061.pdf)） | すでに構造化済みのため転記不要。**テキスト版UCにそのまま流す** |
| **AI-OCRの実運用** | 豊橋市（児童手当現況届）、板橋区（保育課で年間約1,480時間削減）、久慈市など**実運用フェーズ**（[自治体通信](https://www.jt-tsushin.jp/articles/service/casestudy_ai-ocr_case)等） | 本WFのVLM転記は既存AI-OCR製品の置き換え/補完に相当。転記+審査を1本にできるのがDify側の強み |

→ **「upload→一次審査→判定結果まとめ」を自動化すべきは紙スキャンのルート**、が調査の結論。

## ワークフロー構成

```
start（スキャン画像 file-list[最大5枚] + 申請種別 + 窓口聴取メモ）
  → vlm1: 認定請求書スキャンの転記（gpt-4o vision, detail=high, temp=0.1）
  → kr1:  児童手当法・施行規則・改正資料のナレッジ検索（query=転記全文, top_k=10）
  → llm2: 認定請求の一次審査（gpt-5-mini, 4観点+月額試算+連絡文案, 根拠タグ必須）
  → end:  transcription（転記） + result（審査メモ）
```

### モデル選定の理由（gpt-4o転記＋gpt-5-mini審査）

- **転記=gpt-4o**: ここは「目」の仕事。手書きの日本語帳票を読むにはvision性能が強いモデルが必須で、gpt-4oは日本語帳票読み取りの実績が最も安定（会計VLM系バンドルと同じパターン）。転記は推論不要の「忠実な書き写し」（temp=0.1）で、**入口の読み間違いは後段全部を汚染する**ため、ここだけは読み取り精度優先
- **審査=gpt-5-mini**: ここは「頭」の仕事だが一次スクリーニングで足りる。転記＋法令RAGのテキスト推論であり、15日特例の日付検算・施行規則の号番号特定まで5-miniで再現できることをE2Eで確認済み。建付けが「一次スクリーニング＋根拠タグ＋最終判断は職員」なのでモデルの役割は判断の下書き — **約100秒・数円/件**でデモ量産・実運用の回転に耐える
- **分業のメリット**: 読み取り（高精度vision）と判断（安価reasoning）をノードで分けると、各工程に最適なモデル・温度を選べてコストと精度の両取りになる。Difyはノード単位でモデル差し替え可能なので、閉域要件なら審査ノードをローカルLLMに差し替える提案も同じ構成のまま可能（研究会資料P30「AI利用環境の3分類」への接続ポイント）

## デモの流れ（見どころ）

1. **サンプル1（山田家・不備あり）** `sample_scans/scan_case1_yamada.png` をアップロード → 手書き風の紙様式から、口座が配偶者名義／請求者の個人番号欄が空欄／添付書類欄が全て未チェック、をVLMが読み取り、審査で「差戻し文案」まで出る
2. **見どころ①**: 転記(`transcription`)が様式の項目立てそのままに出る — **AI-OCR製品なしでデータ化と審査が1本で動く**
3. **見どころ②**: 窓口聴取メモ（転入日6/28）と画像の請求日(7/22)を突き合わせて**15日特例の期限超過を日付検算**、「8月分から」と断定
4. **サンプル2（佐藤家・添付完備）** → 添付書類のチェック3つを読み取り、「不備なし」＋月額40,000円＋認定見込み案内文案
5. クロージング: 「紙のまま止まっていた審査工程が、スキャナ1台とこのWFで一次審査まで自動化できます。電子申請(ぴったりサービス)のデータはテキスト版に流せば同じ審査が動きます」

## 総務省・自治体AX研究会 資料との対応

- 資料2-2 **P8 手続フローの「AI活用②（申請内容の自動読取）+ ③（審査補助）」を1本のワークフローで実装**したもの（テキスト版は③のみ）
- P13 横展開マッピング「児童手当」列の「申請書類の記載漏れ・添付不備の確認」を、**書類画像そのもの**を入口にして実行
- 大阪市実証（P17、通勤届の申請内容チェック 約40%短縮）と同型で、対象を児童手当の紙申請に置き換えた先取り

## 申請書トリガ・デモ（フォルダ監視の常駐ワーカー）

「申請書が来たら自動で動く」を見せる場合は `scripts/jidoteate_intake_watcher.py` を使う:

```bash
DIFY_LOCAL_CONSOLE_URL=http://localhost/console/api \
DIFY_LOCAL_WORKFLOW_URL=http://localhost/v1 \
DIFY_LOCAL_BASE_URL=http://localhost \
python scripts/jidoteate_intake_watcher.py        # 起動時にKB+WFを自動セットアップ
```

- `demo_intake/01_受付/` にスキャン画像を**置くだけ**で、検知→アップロード→VLM転記→法令RAG一次審査が自動実行され、`02_審査済み/` に 審査メモ（Markdown+HTML）と転記全文が出力されてブラウザが開く（約1分/件）
- 同名の `.txt`（例: `申請_山田.png` + `申請_山田.txt`）は「窓口聴取メモ」として審査に渡される（15日特例の転入日など）
- Ctrl+C で終了時に app+KB を自動削除（`--keep` で残す）。`--once` は1件で終了（検証用）
- **語り口**: 「複合機のスキャン保存フォルダを監視するだけの構成です。Difyにトリガ機構は不要で、この小さなワーカー（約100行）がService APIを叩きます。本番では申請管理システムからのAPI連携・メール添付・ぴったりサービスの申請データ着信に同じ形で差し替えられます」
- E2E検証済（2026-07-30, local）: 投入→65秒で審査メモHTML出力、テスト後クリーンアップまで確認
- 実録画あり: `docs/videos/gov-jidoteate-intake.mp4`（2分6秒ノーカット・山田家サンプル。投入→約2秒で検知→101秒で審査完了→審査メモがブラウザ自動表示。スライドHTML/PPTXの07ページに組込済み）

## 既知の制約（Dify 1.13.3）

- start変数と features の両方に `allowed_file_upload_methods` を明記済み＝**file欄ウィジェット非描画バグの回避**（会議資料レビューで確立したパターン）
- **webapp（公開デモページ）経由のfile-list実行は既知バグの影響を受けうる**ため、デモは Studio の「テスト実行」または Service API 経由を推奨。E2E は API 経由で検証済み
- PDFスキャンは現状対象外（Difyのvisionは画像のみ）。実務では「複合機でPNG/JPEG出力」または前段でPDF→画像変換を想定。document-extractor による電子PDF/Excel対応は v2 候補

## 運用メモ

- サンプルは全て架空データ（○○市・実在しない人物）。様式画像の欄外にも「デモ用架空データ」の注記を印字済み。個人番号欄のダミー数字は転記プロンプト側で「有無のみ転記」として番号自体を扱わない
- KBの正本は `knowledge/*.txt`（テキスト版バンドルと同一の5文書、全ファイル冒頭に出典URL・取得日）
- E2E: `DIFY_LOCAL_CONSOLE_URL=http://localhost/console/api DIFY_LOCAL_WORKFLOW_URL=http://localhost/v1 DIFY_LOCAL_BASE_URL=http://localhost python scripts/test_jidoteate_scan_review.py`（KB作成→import→アップロード→2ケース実行→app+KB削除まで自己完結）
- サンプル画像の再生成: HTML様式（印字=明朝／記入=クレー体）をヘッドレスChromeで1240×1754pxスクリーンショット