学歴・在籍照合 ── 学修歴・在籍/卒業
応募者を、発行者（学校）が持つ学歴・在籍の事実と照合し、「要件を満たす」という結果だけを受け取ります。成績・証明書の原本は発行者の管理下に残るので、原本の提出・保管に伴う漏洩リスクと、学校への照会待ちを、構造的に取り除けます。
学歴・在籍の照合を担う採用・審査部門の方へ
証明書の原本を提出させて真偽を確認するか、学校へ照会するかの二択になっています。保管すれば責任と漏洩を抱える。照会すれば、待ち時間が発生します。この二択を、照合の結果だけを渡す証明で解消します。
-
採用・編入で学歴・在籍を確認する企業 HR・教育機関
-
応募資格を審査する部門、学歴確認を外部に委託している部門
-
学修歴・修了・資格を発行する大学・教育機関・資格/検定団体
原本を渡さず、「結果の証明」だけを渡す。
現場の照合は増えない。相手の確認が変わる。
- 在籍・卒業の記録
- 成績
- 学籍の個人情報
- 学位・課程
- 卒業／在籍の別
- 取得の時期
- 卒業している
- 在籍中である
リンクを開くだけ。アカウントもキーも要らない
「証明書一式」から「判定結果（原本 0 文字）」へ。
証明書の原本を提出させ、保管し、偽造かどうかを目視で確かめる
「卒業している」「在籍中である」の判定事実のみ
Lemma の核心メカニズム
- 原本は外に出さない
成績・学籍の個人情報は発行者（学校）内に留まる。渡さないので、保管の責任と漏洩のリスクが動かない。
- 渡すのは「判定結果」だけ
「卒業している」「在籍中である」という事実のみを、約 200 バイトの ZK 証明として発行する。
- 相手はリンクを開くだけ
採用も委託元もアカウント作成は不要。学校への照会を待たずに「いつ・誰が・改ざんなく発行したか」を自力で確かめられる。
詳しい仕組みを読む
Lemma は、照合を行った発行者（大学・学校）が、照合の結果を「述語(predicate)」として暗号的に発行する構造を提供します。「卒業している」「在籍中である」のような結果が、独立した属性証明として発行されます。元データ（成績・学籍の個人情報）は発行者の管理下に留まり、検証側に渡るのは結果の ZK 証明だけです。
受け取った側（採用・審査部門・委託元）は、原本に触らずに「学歴・在籍が要件を満たすか」を照合＝独立に検証できます。提示のたびに発行元へ照会する必要はありません。選択的開示は W3C VC 2.0 / に整合し、Originator Profile 等の標準化の動きとも接続します。照合が「いつ・誰の発行で・改ざんなく」行われたかは来歴アンカー(docHash)から後年も遡れます。
（御社のどの証明書・資格から始めるか、まず会話で確認できます。）
なぜ、いままでのやり方では足りないのか。
「原本を渡さず照合する」「独立検証」「書き換えの検知」の 3 つが同時に要る業務こそが Lemma の領域です。
| 手段 | 原本を渡さず照合 | 独立検証 | 書き換えを検知 | そのままだと |
|---|---|---|---|---|
| アクセス制御・権限管理 | △ | ✗ | ✗ | 社内の誰かが直せた、という疑いが残る |
| マスキング / 黒塗りで提出 | △ | ✗ | ✗ | 黒塗りの手間が増え、元の記録の真正性は示せない |
| 暗号化して保管・送付 | ✓ | ✗ | ✗ | 相手が確かめるには、結局開示が要る |
| Lemma（ZK 証明）唯一 3 つ揃う | ✓ | ✓ | ✓ | 相手がリンクを開くだけで確かめられる |
実装イメージと、導入の流れ。
開示範囲・保存期間の設計から PoC、本番運用まで伴走します。
まずは、30分のヒアリングから。
御社で、発行・確認の負荷が最も重い1つの証明書・資格を最初の30分で聞かせてください。機微情報（個人情報や機密情報）の開示は必要ありません。
お探しの業界・課題に合わせた事例が見つかります
課題や業種から業務ユースケースを探す（全36件） →