2026.04.07
Human Impact
旅行・公共サービスにおける検証済み属性
導入
空港のチェックインカウンターに立つたびに、こう思う人は少なくないはずです。「なぜ私は何度も同じ書類を出し続けなければならないのか。」パスポート、ビザ、ホテルの予約確認、ワクチン接種証明——それぞれの窓口が、それぞれの判断でデータを要求します。情報は何度もコピーされ、何箇所にも保存されます。しかしそのどこかで漏洩が起きても、あなたには知る術がありません。
公共サービスの現場も同様です。給付金の申請、行政手続き、社会保障資格の確認——「本当に資格があるか」を証明するために、申請者は所得証明・住民票・医療情報を何枚も束ねて窓口に持ち込みます。担当者はそれをコピーし、別システムに転記します。この非効率と、データが拡散するリスクは、構造的に温存されています。
Lemmaが提案するのは、第三の選択肢——「本人確認データを共有せず、検証された事実だけを流通させる」というアプローチです。
旅行体験の現実：KYCは何度繰り返されるか
現代の旅行者は、一回の渡航で複数回の身元確認に直面します。
航空会社のチェックイン、出入国管理、ホテルのフロント、レンタカー会社、ビザ申請機関——それぞれが独立したKYC（顧客確認）プロセスを持ち、同じ情報を別々に収集します。欧州連合が2023年に実施した調査によると、ビジネス渡航者の平均的な一回の出張で、同一の個人情報が6〜9箇所の異なる機関に提出されているとされます。
この冗長性は、コストとリスクを同時に生み出します。
- 事業者コスト：KYC業務は金融機関で年間約1,000億ドル規模の費用がかかるとされ、ホスピタリティ産業でも相応のコストが発生しています
- 利用者負担：書類の準備・提出に要する時間と手間
- データ漏洩リスク：保存箇所が増えるほど、攻撃対象面が広がります
ホテルは宿泊客のパスポートコピーを数年間保管することを規制上求められるケースがあります。その情報が本当に必要なのは「宿泊資格があるか」という一点だけであるにもかかわらず。
公共給付の資格証明問題
行政の現場では、もう一つの構造問題が存在します。「本当にその給付を受ける資格があるか」の確認です。
低所得世帯向け支援、医療費補助、児童手当——これらの給付には、受給資格を継続的に確認する仕組みが必要です。しかし現状のアプローチは、申請者に過剰な情報提出を求めます。所得証明は銀行口座の詳細を含み、世帯構成の証明は家族全員の個人情報を含む場合があります。
行政機関にとっても、この情報の保管・管理・更新は大きな運用負担です。日本では2025年度のマイナポータル活用推進施策として、各種証明書のデジタル化が進んでいますが、「情報を集約する」アプローチ自体のリスクは変わっていません。集約されたデータは、一度の侵害で大量流出するリスクを内包します。
Lemmaによる検証済み属性フロー
Lemmaのアプローチは、「証明すべき事実」と「その根拠となる生データ」を切り離します。
旅行ビザの例で考えてみましょう。
従来のフロー：
申請者 → パスポートコピー＋財務証明＋渡航履歴 → 大使館 → 審査 → ビザ発行
（生データが複数箇所に保存される）
Lemmaのフロー：
申請者の属性発行機関（銀行・政府機関）
→ ZK証明を生成：「残高が閾値以上」「過去5年で不法滞在歴なし」「有効なパスポート保有」
→ 申請者がこの証明を大使館に提出
→ 大使館は証明の真偽のみを検証（実際の残高・渡航歴は受け取らない）
→ 条件を満たした証明であればビザ発行
（生データは申請者のデバイスに留まり、外部には出ない）
ホテルのKYCも同様です。「本人がこのパスポートの正規保有者であり、成人である」という検証済み属性があれば、パスポートの全ページコピーは不要になります。フロントスタッフがパスポートを手に取り、複写機にかける必要がなくなります。
実装シナリオ：ある都市の一日
2028年、Aさんは東京から訪れた海外旅行者です。
朝、ホテルのチェックインで、フロントは「Verifiable Credentials対応」のタブレット端末をAさんに向けます。Aさんのスマートフォンには、出発前に本国の政府機関が発行した検証済み属性が格納されています。「成人であること」「犯罪歴がないこと」「旅行保険が有効であること」——これらのZK証明が、ワンタップでホテルのシステムに送信されます。
ホテルのシステムはLemma Oracleを通じて証明を検証します。結果はシンプルです：「すべての条件を満たしています」。チェックインは2分で完了します。Aさんのパスポート番号も、国籍も、生年月日の正確な値も、ホテルのデータベースには存在しません。
昼、Aさんは市内の美術館でシニア割引を利用しようとします。財布から証明書を探す必要はありません。同じスマートフォンから「年齢が65歳以上であること」の属性証明を提示するだけです。受付担当者は数字を見ません。証明が「有効」か「無効」かだけを確認します。
夕方、空港に向かうAさんは出国審査でも同じ仕組みに遭遇します。属性が自動的に照合され、問題がなければゲートが開きます。書類を広げ、スタンプを押してもらう必要がありません。
この体験を支えるのは、属性が「証明可能な単位」として設計されているという事実です。
プライバシーと利便性の両立
「便利になるとデータが抜かれる」という感覚は、多くのデジタルサービスが作り出してきたトレードオフです。ポイントカードに登録すれば購買データが取得される。アプリを使えば位置情報が収集される。便利さの対価として、プライバシーを差し出す——この構造を当然のものとして受け入れてきました。
Lemmaの検証済み属性は、このトレードオフを解体します。
| 場面 | 従来のアプローチ | 検証済み属性のアプローチ |
|---|---|---|
| ホテルKYC | パスポートコピーをデータベースに保存 | 「成人・犯罪歴なし」の証明のみ、生データなし |
| ビザ申請 | 財務情報・渡航履歴を大使館に提出 | 条件適合の証明のみ、具体的数値は非開示 |
| 公共給付確認 | 所得証明・世帯情報を毎回提出 | 「所得が閾値以下」の属性証明を自動更新 |
| 年齢確認 | 生年月日を開示 | 「成人である/シニアである」の二値証明 |
| 医療費補助 | 病歴・診断書を複数機関に提出 | 「該当疾患を有する」という証明のみ流通 |
利便性は上がります。確認は速くなります。しかし、流通するのは生データではなく「条件を満たしているという事実」だけです。
規制当局にとっても、このモデルは有効です。「審査した」という証明ログがオンチェーンに残るため、監査への対応は従来より容易になります。不正受給の検知も、証明の整合性チェックとして自動化できます。
まとめ
旅行者が毎回同じ書類を提出し続ける構造は、技術的な必然ではありません。設計上の選択です。公共給付の申請者が所得の詳細を行政に開示しなければ資格証明できない現状も、同様です。
Lemmaの検証済み属性が提示するのは、「データを出さなくても、信頼は構築できる」という命題です。旅行体験の効率化にとどまらず、行政DX・公共サービスの設計思想そのものを問い直す契機になりうる技術です。
「確認したい事実」と「その根拠データ」を切り離す——この発想の転換が、プライバシーと利便性を同時に実現する出発点になります。
Lemmaの検証済み属性アーキテクチャに関心をお持ちの旅行・公共サービス・行政DX担当者の方へ
ホワイトペーパーおよびデモは近日公開予定です。現在は一部のパートナー企業・自治体を対象に優先案内を実施しています。
