すべてを暗号化し、何も露出しない

AI パイプラインにおける生データの問題

ほとんどの AI システムはドキュメントを平文で取り込みます。PDF、JSON レコード、API レスポンスが RAG パイプラインに入った瞬間、すべてのフィールド（氏名、住所、給与、診断結果）がモデル、埋め込みストア、データベースにアクセスできる全員に読み取り可能になります。

これは理論上のリスクではありません。ベクトルストアの設定ミス一つで数百万件のレコードが露出し得ます。保存時の暗号化は、アプリケーション層がインデックス化の前にすべてを復号する場合には意味がありません。

Lemma のドキュメント暗号化

すべてのドキュメントは、システムに入る前に @lemmaoracle/sdk がクライアント側で暗号化します。Lemma のサーバーは原本を平文でも暗号文でも受け取らず、復号することもありません。

1. ホルダーの公開鍵を取得（DID またはウォレットから導出）。
2. ECDH + HKDF により共有鍵 K_doc をハイブリッド暗号化鍵として導出。
3. 生ドキュメントを AES-256-GCM で暗号化し encryptedDoc を生成。
4. 暗号化ブロブを IPFS または Ceramic にオフチェーン保存し、cid を取得。
5. docHash = SHA3-256(encryptedDoc) を計算し、オンチェーンの主キーとして使用。

以降、Lemma が扱うのは docHash と cid の2つの識別子のみです。平文がサーバー側で再構成されることはありません。encrypt 関数は、docHash、cid、ciphertext とともに使用された algorithm（デフォルト: "aes-256-gcm"）も返します。これによりホルダーは後の復号のために記録できます。

import { encrypt } from "@lemmaoracle/sdk";

const enc = await encrypt(client, {
  payload: rawDoc,
  holderKey: holderPubKey,
  algorithm: "aes-256-gcm", // オプション — デフォルトは "aes-256-gcm"
});
// enc.docHash            → ドキュメントのハッシュ（オンチェーンの主キー）
// enc.cid                → IPFS/Ceramic 上の暗号化ドキュメントの CID
// enc.ciphertext         → Base64 エンコードされた暗号化ドキュメント
// enc.algorithm          → 使用された暗号化アルゴリズム（例: "aes-256-gcm"）

AI が実際に見るもの

Lemma にクエリする AI エージェントは生のフィールドを受け取りません。代わりに検証済み属性を受け取ります。型付きで証明済みの、来歴メタデータが完備されたファクトです。生ドキュメントは暗号化されたまま残り、AI は ZK 証明と選択的開示の出力を使って作業します。

これにより、RAG パイプラインは生年月日、住所、政府発行 ID 番号を一切見ることなく「このユーザーは 18 歳以上か？」に回答できます。

docHash と CID で十分な理由

docHash は暗号化コンテンツに対する暗号学的コミットメントです。保存されたドキュメントが改ざんされればハッシュが一致しなくなります。cid はコンテンツアドレス型の識別子で、正しい鍵を持つ権限者がオリジナルを取得・復号できるようにします。

この2つの値により、Lemma は以下を実現します：

• ドキュメントの存在をオンチェーンにアンカー。
• ZK 証明と選択的開示を特定のドキュメントに紐づけ。
• 権限を持つホルダーが必要時に取得・復号。

生コンテンツが信頼境界を越えることはありません。

いつ使うか

暗号化ファーストは Lemma のデフォルトです。オプトインする必要はありません。encrypt() を呼ぶたびに docHash/cid ペアが生成され、後続のすべての操作（コミット、証明、開示、登録）は平文ではなくこれらの識別子を参照します。PII、財務記録、医療データ、または仲介者に読まれてはならないドキュメントを扱うアプリケーションであれば、これが他のすべての基盤となります。