ドメインをスキーマとして定義する

スキーマが重要な理由

スキーマがなければ、あるドキュメントの「温度」フィールドは摂氏かもしれないし、別のドキュメントでは華氏かもしれません。「年齢」フィールドはあるレコードでは整数、別のレコードでは生年月日かもしれません。ZK 証明は曖昧なデータでは機能しません — 型付きで正規化された、比較の定義が明確な属性空間が必要です。

Lemma のスキーマは、ドメインごとに生データの形状、正規化データの形状、そして一方を他方に変換する方法を正確に定義することでこれを解決します。

スキーマの定義

スキーマは3つの部分で構成されます：

1. Raw 型 — 元ドキュメントの形状。
2. Norm 型 — コミットメントと証明に使用される正規化属性空間。
3. normalize 関数 — Raw から Norm への変換。

import { define, schemas } from "@lemmaoracle/sdk";

type UserKycRaw = { age: number; country: string };
type UserKycNorm = { age_bucket: "adult" | "minor"; country: string };

// 1. スキーマメタデータを取得（id + NormalizeArtifact を含む）
const schemaMeta = await schemas.getById(client, "user-kyc-v1");

// 2. WASM をダウンロード、SHA-256 を検証、インスタンス化、登録
const userKycSchema = await define<UserKycRaw, UserKycNorm>(schemaMeta);

この id はシステム全体で参照されます — prepare、documents.register、回路メタデータ、attributes.query。生データから証明、クエリ結果までを結びつけるユニークキーです。

正規化が鍵となる設計判断

normalize 関数は検証済み属性の粒度を決定します。温度を例にすると：

• 3つのバケット（cold/mild/hot）に分ける — 不可逆だがプライバシー保護性が高い。
• 正確な値をそのまま渡す — バケット化なし、プライバシーは低い。

これはドメイン固有の設計判断です。Lemma は正しい粒度を規定しません — それを正確に定義するツールを提供し、ZK 証明とコミットメントが選択した正規化空間上で動作することを保証します。

ジェネレーター：データの起源を文書化

スキーマは属性空間を定義します。ジェネレーターは生ドキュメントがどのように生成されるか — どのスクリプト、どの入力、どの外部 API — を定義します。

generator_id とそのハッシュは ZK の公開入力に含まれるため、すべての検証済み属性はスキーマや回路だけでなく、元データを生成した正確なプロセスまで追跡できます。

回路が全体像を完成させる

スキーマがデータを正規化し、ジェネレーターがデータを生成し、回路が正規化・コミット済みデータ上の述語を証明します。この3つのコンポーネントが、完全で監査可能なチェーンを形成します：

ジェネレーター → 生ドキュメント → スキーマ → 正規化属性 → コミットメント → 回路 → 証明

利用者が検証済み属性をクエリすると、レスポンスには3つの ID すべて — schemaId、generatorId、circuitId — が含まれ、推論の全チェーンが透明です。

設計による拡張性

スキーマ、ジェネレーター、回路は同じパターンで登録されます：メタデータはサーバー側レジストリに、アーティファクト（wasm、zkey）は IPFS/HTTPS に保存され、ID は他の API から参照されます。新しいドメインを追加するには、スキーマを登録して normalize 関数を作成するだけです。回路とジェネレーターは必要に応じて追加できます。コアプロトコルの変更は不要です。