Lemma FAQ—
AI のための信頼インフラ.

Lemma は AI のための信頼インフラ (信頼基盤) です。AI が読み取るデータ、AI の判断、AI エージェントの権限、規制属性を、暗号学的に証明可能にする 1 つのレイヤー。具体的には 4 つの軸 (来歴 / 検証可能 AI / エージェント権限 / 規制属性) として構成されます。

AI システムが参照し推論するデータが信頼できる情報源から来ており、改ざんされていないことを検証可能にすることを意味します。

Verifiable AI は、すべての判断の根拠を事後的に検証できる AI システムです。

既存の RAG システムには、取得したデータが正確かどうか、誰が発行したかを確認する仕組みがありません。

Lemma は RAG レイヤーで動作しモデル非依存で、加えてエージェントが外部システムへ作用する際の権限・来歴の証明にも及びます (→ セクション 5)。

AI ゲートウェイは API アクセスを管理しますが、データの来歴を証明しません。Lemma は永続的な記録付きの暗号学的証明を提供します。

信頼インフラとしての Lemma を構成する 4 つの軸です: 来歴証明 (P1) / 検証可能 AI (P2) / エージェント権限証明 (P3) / 規制属性証明 (P4)。別個の製品ではなく、1 つの基盤を 4 つの軸で説明します。

課題ベースで選びます。データの出所を証明したい → P1、AI の判断根拠を後から証明したい → P2、AI エージェントの操作権限を証明したい → P3、規制属性を生データを渡さず証明したい → P4。各柱に対応する実事案は Critical Brief で扱っています。

Lemma は生の個人情報を AI に渡しません。AI が扱うのは AES-GCM で暗号化された docHash と CID のみです。

ゼロ知識証明は、基礎データを明かさずに条件が満たされていることを証明します。

AI が必要な属性のみを提示し、それ以上は開示しないことです。

規制が生 PII の収集・保管を要求する設計では、保管データそのものが漏洩面になります。実例として KYC データの内部漏洩事案 (Critical Brief、Coinbase KYC 等) がこの構造を示しています。Lemma は属性を証明として渡し、生 PII の蓄積を構造的に縮小します。

文書のコミットメント、スキーマ、発行者情報、ZK 検証結果がブロックチェーンに記録されます。

監査対応、コンプライアンス報告、インシデント調査において、AI がどのデータを根拠に使用したかを事後的に証明できます。

透かしは標識を成果物に埋め込む detection 的手法で、統計的に剥離・偽造され得ます (Critical Brief、SynthID reverse-engineering 等で実証)。暗号的来歴は成果物の外側に証明を置き、信号空間の中に「鍵」を残さない点で異なります。

エージェントが外部システムへ作用する各操作について、「誰が」「どの権限で」「どの操作を」要求したかを独立検証可能な証明として固定できます。背景として、AI エージェントが攻撃工程の大半を自律実行した事案も報告されています (Critical Brief、GTG-1002 等)。

エージェント基盤の認証・権限の検証層に関わる事案を Critical Brief で扱っています (Starlette/BadHost、PocketOS 等)。技術的な実装方針は P3 ページ「エージェント権限証明」を参照してください。

規制属性 (KYC 通過、許可された jurisdiction、サンクション非該当、年齢等) を、検証側が生データを保管しないまま暗号証明 (ZK 属性証明) として受領する設計です。詳細は P4 ページ「規制属性証明」、適用例は KYC/AML 選択的開示ユースケース。

公共部門の AI 判断の検証・認可の証跡に関わる事案を Critical Brief で扱っています (Williams FRT 誤認逮捕等)。提供形態は Lemma Civic。SIer 経由の導入を想定しています。

Lemma が発行する threat intelligence brief。AI 時代の信頼層に関わる事案 (サイバー攻撃 incident + 非攻撃のリスク事象) を構造化分析し、検出層では届かない構造的 gap と Lemma の応答層を示す reference 集です。CSO・アナリスト・規制実務者向け。

来歴 (ブリッジ / サプライチェーン / AI 生成物)、検証可能 AI (誤判定 / 透かし)、エージェント権限 (自律攻撃 / MCP)、規制属性 (KYC 漏洩) を横断。Pillar 別・Category 別アーカイブから辿れます。

いいえ。公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません (各 Brief の「Brief 配布について」参照)。

スキーマは AI が知識をどのように検索しクラスタリングするかをモデル化し、属性を型付き定義と正規化で表現します。

検索すると属性データに完全な来歴証明が付いて返されます。

Dashboard の API keys タブで新しいキーを作成し、旧キーと並行してデプロイしてください。トラフィックが新キーに切り替わったら旧キーを revoke します。revoke は即時かつグローバルに反映されるので、切り替えの重なり時間を確保してから revoke するのが安全です。

workers API (workers.lemma.workers.dev) に対して、@lemmaoracle/sdk 経由または直接 HTTP でプログラマティックに登録します。Dashboard はスコープから読み取って表示するだけで、作成用 UI フォームはありません。Dashboard Quickstart ガイドが SDK 経由の流れを最後まで通します。

発行者 ID、データ構造の完全性、ZK 証明のサーキットと生成方法、オンチェーンの永続的記録の 4 つの要素が暗号的に証明可能になります。

不要です。Lemma はブロックチェーンをバックエンドの記録インフラとして使用しますが、開発者がスマートコントラクトを直接操作する必要はありません。

検出は受信側が「何を accept するか」自体を変えません。検出 (異常検知・監視) と事前証明 (attestation) は代替ではなく補完関係にあります。詳細は detection-is-not-proof essay、実証は Critical Brief 各号の §5。既存検出ベンダーを否定せず役割分担として描きます。

詳細はお問い合わせください。データ所在地、コンプライアンス制約、既存インフラとの統合を考慮した構成をご提案します。

暗号化と鍵管理、ZKP の監査可能性、来歴証明の永続性の 3 つの分野から始めてください。

はい。Lemma の核心はまさに「個人情報を AI に渡さずに、必要な事実だけを証明付きで渡す」ことです。原本データ（氏名・住所・契約内容など）は AI の context に入らず、検証可能な事実（claim と ZK 証明）だけが流れます。原本は社内システムに暗号化のまま留まり、AI のログ・キャッシュにも残りません。

Lemma の選択的開示構造（disclosed / hidden）は、個人情報保護法の「利用目的の特定」「最小限の取扱い」原則と構造的に整合します。AI に渡る属性は「年齢 = 18 以上」「居住 = JP」など必要最小限に絞り、本人特定可能な情報は原本に留めます。具体的な適合設計は Discovery Call で個別にご相談ください。

Lemma 導入後、AI が受け取るのは証明 object（claim と ZK 証明）のみで、原本データは AI の context window に入りません。これにより、AI のログ・キャッシュに原本が残らず、AI モデル提供企業にも原本が共有されず、AI 経路でのデータ漏洩リスクが構造的に解消されます。「AI に渡す情報自体を変える」ことで、漏洩を防ぐ前提から解放されます。

不要です。PoC は業務シナリオ単位で進めます。Lemma 側で原本データを受け取ることはなく、お客様の社内システムに Lemma SDK を組み込み、原本は社内に保持したまま証明発行を構築します。Lemma チーム・SDK が原本データに触れる構造的可能性がありません。

ありません。別会社です。本サイトの Lemma は FRAME00, Inc. による、AI のための信頼インフラです — データ来歴・AI 判断・エージェント権限・規制属性の暗号証明。料金をお探しの場合: Trust402 Explorer は無料で始められます。エンタープライズプランはお問い合わせベースです。

別会社の別プロダクトで、関係はありません。LemmaX は Web3 企業向けにセキュアでコンプライアントな決済インフラと支援サービスを提供する fintech プラットフォームです。本サイトの Lemma（FRAME00, Inc.）は AI のための信頼インフラ — データ来歴・AI 判断・エージェント権限・規制属性を、原本を出さずゼロ知識証明で検証するレイヤで、決済サービスではありません。製品は Trust402・Seal から試せます。