問題提起
金融機関では、人材の組織間移動が日常的に発生します。出向、業務委託、代理店パートナー、ジョイントベンチャー──いずれの場合も、移動する従業員は出元と受け入れ先の両方で有効な認証情報を持ち、両組織の顧客データへの正当なアクセス権を持ちます。
このとき、信頼境界は構造的に曖昧になります：
- アクセス自体は正当に見える：従業員は有効な認証情報で正規のシステムにアクセスする
- アクセスログは変更可能：両組織がログを通常のデータベースに保存しており、暗号的な完全性保証がない
- 共有証明レイヤがない：出元と受け入れ先は、相手のログを独立に検証する手段を持たない
- 抑止力が弱い：従業員は「ログは争える」ことを知っており、心理的抑止力が機能しない
問題が発覚した時──顧客の苦情、規制当局の監査、内部通報──両組織は何がいつアクセスされたかを正確に証明できません。互いの非難、規制上の罰則、レピュテーションの毀損が同時に起きます。
規制側の圧力は強まっています。改正個人情報保護法、金融庁のサイバーセキュリティガイドライン、AIガバナンス指針、GDPR域外適用、各国データ保護法──いずれも「ログがある」から「改ざんされていない根拠が証明できる」へ要求が移っています。
検出はすでに存在します（DLP・SIEM）。欠けているのは、検出された出来事が改ざん不能な事実として残るレイヤです。
シナリオ
MetLife Japan 2026 のインシデントは、この構造的ギャップを露呈した実例です。生命保険会社が代理店パートナー（地方銀行・証券会社）の店舗に従業員を出向させ、両社のチャネルで保険商品を販売する中で、出向従業員が36の代理店パートナーから2,476件の顧客記録を持ち出しました。
Lemma 導入前 — インシデントの展開
| 段階 | 起きたこと | 検知できなかった理由 |
|---|---|---|
| アクセス | 出向従業員が両社のシステムにまたがって2,476件の顧客レコードを照会 | アクセスは正当に見える。従業員は有効な認証情報を持つ |
| 収集 | 個人端末・USB・クラウドストレージにデータをコピー | ログは変更可能で、組織ごとに分断されている |
| 持ち出し | 新たな雇用先または売却先にデータを移送 | 組織を跨ぐ統一された監査証跡が存在しない |
| 発覚 | 数ヶ月後、顧客の苦情と当局の監査により発覚 | アクセスログが改ざんされている可能性。元のアクセスパターンの暗号的証明がない |
| 対応 | 何がいつアクセスされたかを正確に証明できない | 相互の非難、両組織への規制処分 |
根本原因は単純です。信頼境界が曖昧な状態を、変更可能なログで運用していたこと。
Lemma 導入後 — 同じシナリオでの違い
各組織のCRM・データベースとユーザーの間に Lemma 認証ゲートウェイ が配置されます。すべてのデータアクセス要求がZK認証を生成します：
proof(user_id_hash, record_id_hash, timestamp, access_type)
レコード内容を明かさずに、誰がいつ何にアクセスしたかだけが暗号的に固定されます。認証はオンチェーン（またはコミットメントルート）に固定され、構成上改ざん検知可能になります。
| 段階 | Lemma 導入時の挙動 |
|---|---|
| アクセス | 各照会がZK認証を生成、タイムスタンプ付きでコミット |
| 収集試行 | 異常パターン（量・タイミング）はDLPがフラグ。Lemma認証はどのレコードがアクセスされたかを正確に証明 |
| 抑止 | 従業員は「すべてのアクセスが暗号的に証明される」ことを認識。心理的抑止力が機能 |
| 発覚 | 両組織が即座に改ざん不能な共有証明を提示。紛争の余地なし |
| 規制対応 | 金融庁が証拠を要求。検証可能な認証セットを数時間でエクスポート |
| 指標 | Lemma なし | Lemma あり |
|---|---|---|
| 異常アクセスの検知時間 | 数週間〜数ヶ月 | リアルタイム（DLP） + 暗号的証明（Lemma） |
| アクセスログの争議可能性 | 高い | ほぼゼロ |
| 規制監査の準備時間 | 数週間（手動ログ集約） | 数時間（認証セットのエクスポート） |
| 組織間の責任のなすりつけ | 相互否定 | 共有された否認できない証明 |
| 内部脅威の抑止力 | 低い（「私はおそらく否定できる」） | 高い（「すべてが暗号的に証明される」） |
アーキテクチャ
Lemmaの4つの暗号レイヤが、組織間データアクセスのライフサイクルに対応します。
1. ENCRYPT ─ アクセス内容の不可触性
Lemma 認証ゲートウェイは、データの中身を一度も保存・検査しません。CRMやデータベースに対するクエリと結果は、Lemmaの境界を通り抜けるだけ。AES-GCMで暗号化されたペイロードは元のシステムに留まります。
2. PROVE ─ ZK アクセス認証の生成
ゲートウェイがすべての読み取り・クエリを傍受し、アクセスイベントごとに次のZK認証を生成します：
proof(user_id_hash, record_id_hash, timestamp, access_type)
ユーザー識別子もレコード識別子もハッシュ化されており、認証それ自体からは個人情報が露出しません。認証はローカルのコミットメントツリーに集約されます。
3. DISCLOSE ─ ステークホルダ別の検証可能性
各当事者が独立に検証できます：
- 出元組織：「従業員Xが日付D1〜D2の間にレコード[1..N]にアクセスした」
- 受け入れ組織：「同じ従業員が出向中に当方のレコード[M..P]にアクセスした」
- 規制当局：「両組織の認証は一貫性があり、改ざん検知可能である」
DLP/SIEMが異常をフラグした時点で、Lemmaから検証済みアクセスレポートを要求できます。インシデントは初めて、否認できない証拠を持つことになります。
4. PROVENANCE ─ コミットメントルートのオンチェーン固定
すべての認証のコミットメントルートが定期的にオンチェーンに固定されます。任意の当事者が、特定の時間に認証が生成され、変更されていないことを検証可能。機密データはオンチェーン上にありません──コミットメントのみ。これにより、規制対応・紛争解決・事後フォレンジクスが、データを開示せずに成立します。
証明される事実
Lemmaが金融データ流出防止で暗号的に保証する事実は以下です：
- 各アクセスイベントの実行者・対象レコード・時刻・アクセス種別
- アクセスログの改ざん不能性
- 組織を跨いだアクセス証跡の一貫性
- データ内容の非開示性──認証自体からPIIは漏れない
- 規制当局による独立検証の可能性
- 出元組織・受け入れ組織・当局の三者で共有可能な真実レイヤ
- 内部脅威に対する暗号的抑止力
証明する準備はできましたか？
ユースケースについてお聞かせください。1営業日以内にご返信いたします。