# 児童手当認定請求 事前レビュー（審査補助） — 営業・デモガイド

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

市区町村の児童手当担当課で、提出された**認定請求書（様式第二号）を職員が審査する前のAI一次チェック**を行うワークフローです。請求書の記載内容（AI-OCRの読取結果を想定したテキスト）を貼り付けると、**児童手当法・施行規則・令和6年10月改正資料**をナレッジ検索で参照し、①形式不備 ②添付書類の要否 ③受給資格・請求者適格 ④支給額試算・支給開始月 の4観点で審査メモを生成。**申請者への差戻し文案／認定見込み案内文案**まで出します。

- すべての判定に **[根拠: 文書名] タグ**が付く（ハルシネーション対策・行政の理由提示要請への対応）
- 記載にない事実は推測せず**「記載なし・要確認」**として職員に引き継ぐ
- 末尾に**「最終判断は職員」**の固定文言（Human-in-the-Loopの建付け）

## 総務省・自治体AX研究会 資料との対応（デモの正当性）

総務省「地方自治体におけるAIトランスフォーメーションに関する研究会」（第1回・令和8年7月9日）事務局提出資料に、本デモの位置づけがそのまま書かれています。

| 研究会資料の記載 | 本ワークフローでの実装 |
|---|---|
| 資料2-2 P13 横展開マッピング「児童手当」列: 申請書類の記載漏れ、添付不備をAIにより確認 | 「判定サマリー」「不備・要確認事項」セクション（施行規則第1条の4第2項の号番号まで特定） |
| 同: 支給可否、支給額の一次スクリーニング（**その後職員による確認**） | 「受給資格の一次見解」「支給月額の試算」＋末尾の職員最終判断文言 |
| 同: 認定通知等のAIによる自動生成 | 「申請者への連絡文案」（差戻し文案／認定見込み案内） |
| P8 手続フローの「AI活用③（審査補助）」 | 本WFそのもの（申請受付と基幹システムの間の審査工程を補助） |
| P15-16 ワークフロー型AIエージェント（①形式確認②内容確認③決裁準備、タスク単位で検証しやすくガバナンス確保・部品化で他業務再利用） | Difyワークフロー＝事前設定された手順を実行するワークフロー型。ノード単位で挙動を検証・監査可能 |
| P30 AI利用環境の3分類（クラウド／閉域／オンプレミス） | Difyはself-hosted可能（本デモ環境もself-hosted）。閉域・オンプレ要件に対応できる |
| P32 ガバメントAI「源内」: 知識ベース＝法令の逐条解説・審査マニュアル等 | 同じ思想。KB＝児童手当法・施行規則・改正資料・審査実務（実在資料から編纂・出典明記） |
| P17 大阪市実証: 申請内容チェック・認定可否判定サポートで業務時間 約40%短縮 | 同型のユースケース（通勤届→児童手当に置き換えたもの） |

※ 研究会の実証フィールドは住民基本台帳（浜松市）と生活保護（神戸市）。本デモは**その成果を他業務（児童手当）へ横展開するとどうなるか**を先取りで見せるもの、という語り口が刺さります。

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

1. **サンプル1（不備あり）**を実行 → 口座が配偶者名義／個人番号未記載／別居の長男（20歳・大学生）の確認書・住民票が未添付／請求者がパートの母で配偶者が会社員（生計中心者の疑義）／転入から15日特例の期限超過、が根拠条文付きで一覧化される
2. **見どころ①**: 支給月額の試算が「確認書がある場合 40,000円／ない場合 20,000円」と両パターン提示される — **令和6年改正の第3子カウント（22歳年度末までの兄姉等）**を書類1枚が左右する、審査実務のリアル
3. **見どころ②**: 差戻し文案がそのまま送れる体裁で出る（不足書類と根拠規定・提出期限・支給開始月への影響つき）
4. **サンプル2（添付完備）**を実行 → 「不備なし」＋月額40,000円（高1=1万円＋2歳の第3子=3万円）＋認定見込み案内文案
5. クロージング: 「例規・要綱のKBを差し替えるだけで、児童扶養手当・介護保険・子ども医療費助成にも同じ型で展開できます」

## 建付けの説明（聞かれたら）

- **AIに審査（行政処分）をさせるのか？** → させません。総務省行政管理局の整理（令和5年度検討会）どおり、行政処分には理由の提示が必要で、AIが十分な理由提示をできない限り職員の関与が必要。本WFは一次スクリーニングに徹し、全判定に根拠タグを付けて**職員が理由を検証できる状態**で引き継ぎます。
- **個人情報は？** → デモは架空データ（○○市・ダミー人物）のみ。実運用ではself-hosted（閉域・オンプレ）構成が可能で、自治体情報セキュリティポリシーガイドラインの機密性分類に応じた環境設計を提案できます。
- **精度は？** → 記載のない事実は推測しない設計＋根拠タグ必須＋職員最終確認前提。京都府実証（研究会資料P18）のような**視点別の並列審査＋結果突合**をv2として構想済み（Difyならノード追加で実装可能）。

## 横展開ストーリー（クロージング用）

- 標準化対象20事務の申請審査は同じ型（形式チェック→要件確認→一次判定→通知文案）。**KBと審査観点プロンプトの差し替え**で、児童扶養手当・介護保険・保育認定・子ども医療費助成（都道府県要綱＋市条例ベース）へ展開可能
- 例規は1,741自治体で異なる → 当社のデモ量産パイプライン（Demo Farm）は**自治体ごとのKB差し替え版を自動生成・検証**できる
- 東京都「A1（えいいち）」（研究会資料P34: ノーコード生成AI基盤・都内53自治体・LGWAN-ASP提供準備完了）が示すとおり、**職員が自分で作れる基盤＋業務アプリ**という提供形態は行政で現実に動き始めている

## 運用メモ

- 入力はテキスト貼り付け（AI-OCR読取結果を想定）。file型入力は使わない設計（Dify webappのfile型UI既知バグ回避＋LGWAN環境でのOCR連携を別工程に分離する想定）
- デモURL発行: ダッシュボードの「即時デプロイ」から（KB自動作成→dataset_id注入→import）
- KBの正本は `knowledge/*.txt`（全ファイル冒頭に出典URL・取得日を明記）