渡さずに、審査する。データを抱えずに、AI 与信を続ける

TL;DR

融資審査の現場では、本人確認・収入・反社・信用情報がすべて生データのまま、申請者から銀行へ、そして AI クレジットスコアリングや書類解析エンジンへと流れています。マスキングは値を隠す操作ですが、AI 側で復元してから審査に使う以上、結局は AI が中身を見ています。

Lemma は、AI に個人情報を渡さずに融資審査を成立させる、AI 時代の信頼基盤です。申請者のブラウザの中で「条件を満たすこと」だけが事実として証明され、AI に渡るのは生データではなく、検証可能な事実だけ。今やっている融資審査を、データを抱え込まずに続けられます。

渡さないから、流出しない。

AI に任せても、証拠が残る。

暗号的に検証可能 ≠ 開示

▸ 融資審査の現場で起きていること

融資審査は、生データを最も大量に動かす業務領域のひとつです。申請者は身分証・住民票・源泉徴収票・在籍証明・確定申告書類を提出し、銀行はそれを社内システム・与信判断モデル・反社チェック API・信用情報照会の各経路へ転記します。重複したコピーが複数のシステムに残り、保管期限の管理と削除責任が組織横断で発生します。

近年は AI による自動化が加わりました。OCR で書類を読み取り、AI クレジットスコアリングモデルが収入・属性データから返済確率を算出し、AI 書類解析エンジンが本人確認の整合性を判定します。これらの AI に投入されるのは、ほぼ常に生データです。マスキング層が挟まれるケースもありますが、判断モデル側で復元が必要なため、結局のところマスクは一時的な遮蔽にすぎません。

EU AI Act は高リスク AI 分類に融資判断を含め、国内では金融庁の AI ガバナンス検討が継続中です。「AI が私のデータをどう扱うか」を問う声も広がりました。マスキングを足すのではなく、AI が元データに触れない設計がありえないか、という問いが、現実的な選択肢として現れ始めています。

▸ マスキングと選択的開示と ZK 証明の違い

3 つの異なる発想の差を、まず明確に区別します。

アプローチ	元データの所在	AI / 受け手が見るもの	漏洩時のリスク
マスキング	受け手側にコピー	マスク済み生データ（判定時に復元が必要）	復元される / 復元される前の経路で漏れる
選択的開示	発行者側	必要属性のみ（発行者署名付き）	開示した属性そのものが漏洩しうる
ZK 証明	申請者のブラウザ内	属性に関する事実のみ（属性値は見えない）	漏洩しうる属性そのものが存在しない

マスキングは「データの可視性を制御する」操作です。選択的開示は「データの開示範囲を制御する」操作です。ZK 証明は「データを開示せずに事実を証明する」操作で、根本的に異なる発想に立ちます。

ZK 証明を支えるのは、Groth16 のような証明スキームと、Poseidon over BN254 のような ZK フレンドリーなハッシュ関数、BBS+ over BLS12-381 のような選択的開示可能な署名スキームです。これらを組み合わせると、「申請者が年収 X 円以上である」「申請者が反社データベースに該当しない」のような真偽値の事実だけを、申請者の手元から動かすことなく相手に渡せます。

▸ 融資審査の data flow、Before / After

現行の融資審査の data flow は、申請者から銀行への一方向の生データ転送と、銀行内での複数経路への複製で構成されています。書類束 → 受付システム → 与信判断モデル / 反社 API / 信用情報照会 / AI スコアリング、というように、申請者の個人情報は最低でも 4〜5 箇所のシステムに転写されます。

ZK 証明ベースの設計では、申請者のブラウザ内で属性証明が生成され、銀行に渡るのは proof と公開シグナルのみです。AI スコアリングモデルは「年収条件を満たす」「居住地条件を満たす」「反社データベースに該当しない」「信用スコアが閾値以上である」という事実だけを入力として受け取り、生データには触れません。融資判断の出力もまた ZK 証明として記録され、後日の監査で「この申請者は所定の条件を満たすと判断された」を暗号的に検証できます。

▸ 誰の何が変わるか — 利害関係者別の安心の中身

この構成が成立すると、融資審査に関わる人々の責任と不安が、それぞれ異なる形で変化します。

申請者にとっては、自分の収入・反社・信用情報が AI のどこに残るかを心配する必要がなくなります。AI 学習データに自分のデータが入り込む懸念から解放され、銀行や AI ベンダーで漏洩インシデントが起きたとしても、開示された元データがそもそも存在しないため被害が成立しません。提出するのは「条件を満たすことの証明」だけで、何を満たしたかの中身は申請者の手元を出ません。

融資担当者にとっては、書類束を開く責任、AI へ渡す責任、保管期限を管理する責任が消えます。自分の審査判断は ZK 証明として後から検証可能な形で残っており、後年の監査で説明を求められても、判断の根拠が暗号的に裏打ちされています。「あの時なぜこの判断をしたか」という記憶頼りの説明が、検証可能な記録に置き換わります。

コンプライアンス責任者にとっては、AI 関連の個人情報保護法対応のスコープが本質的に縮小します。「AI に何のデータを入力したか」を管理する難題が、構造上発生しなくなります。説明可能経営の要件が暗号証明で機械的に充足され、報告書ベースの説明から検証可能な記録へ切り替わります。

経営層にとっては、AI 起点の漏洩インシデントが、構造上起こり得ない設計に切り替わります。事後対応の reactive 体制から、設計段階で漏洩リスクを構造的に排除する proactive 体制へ。レピュテーション・規制対応・訴訟対応の総コストが下がります。

規制当局にとっては、AI が適正に判断しているかを、検証可能な ZK 証明で機械的に確認できます。AI ブラックボックスの中身を解読する代わりに、「この属性条件を満たすと AI が判断した」という事実を暗号的に検証する、新しい監督モデルが成立します。

▸ 何が効率化・自動化できるか

人々の安心の構造が変わるだけでなく、業務の効率も具体的に変化します。書類束のコピー転記が消滅し、個人情報保護法対応の対象範囲が縮小します。反社・信用情報の最小開示によって、必要以上の情報接触に伴う法的リスクが下がります。改ざんされた申請の検知が、人間の目視や複数経路の突き合わせではなく、暗号的な検証で自動化されます。

そして最も重要なことに、AI 判断の証跡そのものが ZK 証明として残るため、AI による意思決定の説明責任が、暗号証明によって機械的に支えられます。説明可能経営の文脈で長く議論されてきた「AI の判断根拠をどう示すか」という課題が、データを開示せずに判断の事実を検証可能にする、という方向で解かれます。

モデルは変わる。証明は残る。

Models change. Proofs remain.

▸ デモを試す

実際に動く融資審査の検証フローは、Lemma の demo で体験できます。demo-lemma.frame00.com の Finance シナリオに「Loan approval (valid)」と「Loan approval (tampered)」の 2 つのサンプルがあり、前者は正常な ZK 証明として検証が成立し、後者は改ざんを暗号的に検知して却下される様子が、ブラウザ内で完結して見られます。検証に使うファイルは、画面下部の表記の通り "the file never leaves your device" で、申請者のブラウザを出ずに検証が走る挙動を、そのまま確認できます。

▸ For builders / lenders

Lemma は reference architecture と検証可能なデモをもとに、PoC から始める段階です。

融資審査の AI 活用を進めながら、AI に個人情報を渡さない設計を検討中の金融機関のみなさま、与信判断モデルや LOS / CRM 統合を扱うインフラ事業者のみなさま、説明可能経営の文脈で AI ガバナンス整備を進めるコンプライアンスチームのみなさま、お話を伺わせてください。

For lenders, financial-infrastructure integrators, or compliance leads exploring privacy-preserving credit underwriting: we'd love to hear from you.

• Enterprise discovery（ホワイトペーパー DL / PoC 個別相談）: tally.so/r/EkBqDX
• Developer waitlist（Lemma API）: tally.so/r/kd0bZR

Built for decisions that matter.

▸ Resources

• Demo: demo-lemma.frame00.com （Finance / Loan approval）
• Whitepaper: AI の判断根拠を証明する設計書
• 関連記事: 金融 AI が業務の中核に入った 2026 — 判断証跡という残された層
• 関連記事: データを出さずに証明する KYC/AML
• 関連記事: 暗号証明で支える説明可能経営