補助金・給付の受給資格証明

補助金・給付・各種行政サービスの受給資格を確認する立場の方へ。要件確認のために所得・世帯・属性の生データを集めると、それ自体が保管・漏洩のリスクになります。「申告された」ことと「要件を満たすと検証できる」ことは別です。

• 自治体・公共サービスで給付・補助の資格確認を担う部門
• 申請受付・審査の事務負荷と、保有する個人情報の漏洩面に課題を感じている部門
• 担当者が代わっても公平・一貫した審査を残したい組織

この業務は3つが同時に要ります。所得・属性を出さず「要件充足」を証明できること。給付主体・監査が独立に検証できること。後から改ざんできないこと。

書類収集は所得・世帯情報ごと保管され、その保管自体が漏洩面になります。3つを同時に満たすのは ZK 証明だけ。1つでも欠けてよいなら既存手段で十分です。3つが同時に要る業務だけが Lemma の領土です。

申請者が「受給要件（所得区分・居住・対象区分など）を満たす」ことだけを、証明として提示します。所得額や世帯の生データは出しません。給付主体は中身を保管せずに要件充足を検証でき、監査も同じ証明を独立に確認できます。

「IT を増やす」のではなく、人への依存とプライバシー露出を減らす便益として届きます。 （御社のどの給付・補助から始めるか、まず会話で確認できます。）

数値はいずれも目安です。

給付・審査する側（自治体・公共サービス） 生データを集めず・保管せずに要件充足を確認でき、漏洩面と審査工数を下げられます。担当者が代わっても判断の根拠が残ります。 例：添付書類の収集・保管から、要件充足の証明検証へ。

住民・事業者（申請者） 所得・世帯などの生データを出さず、必要な「要件を満たす」だけを示せます。不要に記録・通知されません。 例：開示が、書類一式の提出から1つの要件証明へ。

監査・説明責任 中身を出さずに「要件を満たす申請に給付した」を説明でき、公平性の証跡が残ります。

ある自治体が、所得区分に応じた給付の申請を受け付けているとします。要件確認のため所得証明・世帯情報を集めて保管しますが、その保管データ自体が漏洩・苦情の対象になり、担当者が代わると審査のばらつきも生まれます。

Lemma が導入されていれば、申請者は「所得区分が要件以下である」だけを証明として提示し、金額そのものは出しません。自治体は中身を保管せず要件充足を検証し、監査も同じ証明を独立に確認できます。

既存の申請・審査システムを置き換えません。資格確認の経路に、属性証明を1段挟むだけです。

• 選択的開示：BBS+ over BLS12-381 で、要件判定に必要な属性だけを提示。
• 要件の証明：「所得区分が閾値以下」等を Groth16（Circom 回路）の範囲・述語証明で。Poseidon over BN254 でコミット。
• 来歴：申請・判定を docHash と発行者署名で固定し、公平性の証跡を残す。

生データは申請者・発行元に留まり、給付主体に渡るのは「要件を満たす」という暗号的事実だけです。

• 申請者が「受給要件を満たす」ことの証明
• 判定の発生時刻と、参照属性の docHash
• 後年も不変な、判定の暗号的同一性
• 生データを保管せずに、給付主体・監査・第三者が独立検証できるトレイル

SaaS を単体で入れる話ではありません。AI 導入・データガバナンスのコンサルと PoC から入り、既存プラン月額に着地します。

1. 30分の棚卸し — 給付・補助のうち、生データ保管の負担・漏洩面が集中する資格確認を特定。
2. 証明したい判定（結果）を1〜2個に絞る — 例：「所得区分が要件以下」「対象地域の居住」。金額・世帯の中身は出しません。
3. 接続と更新の扱いを設計 — 既存の申請・審査システムとの接続方式と、資格更新・取り消しの扱い。
4. PoC（見積ベース）で1経路を実証 — 1つの給付・補助で動くことを確認。
5. 既存プラン月額に着地（目安） — Lemma Civic へ。価格は会話のなかで確認。

御社で、生データ保管の負担が最も重い1つの給付・補助を最初の30分で聞かせてください。機微情報の開示は必要ありません。