業務ユースケース — 検証可能 AI
プロンプトインジェクションを、見せずに検知する。
不可視 Unicode や隠しコマンドで「人が見た入力」と「AI が読む入力」がずれる prompt-injection を検知します。Lemma が入力の normalized 形を hash 化し、人が意図した入力と AI が受け取った入力の visible_eq を runtime に検証するため、content を開示せずに改ざんを検知できます。
01 · 課題認識
推進担当の、3 つの声。
- AI 開発・運用
「不可視文字・隠しコマンドによる prompt 改ざんを、検知する仕組みが欲しい」
- セキュリティ
「ユーザー入力経由の AI 攻撃を、構造的に防ぐ層が要る」
- コンプライアンス
「AI が処理した入力が、ユーザーが意図したものと一致することを証明したい」
02 · 変化
原本を渡すか、事実だけを渡すか。
現場の手は増えない。相手の確認が変わる。
① 現場は、保存するだけ。
- いつもの操作
- 記録を入力して、保存
- 保存と同時に
- 証明が付く（裏で API 連携）
- 記録の本文
- 送信されない
② 相手は、リンクを開くだけ。
改ざんされていません
NOT TAMPERED
- 証明された事実
- 「人が見た入力 = AI が読む入力」の整合性
- プロンプト・入力 content の中身
- 表示されない
- ログイン・キー
- 不要
なぜ Lemma か
- 本文は出さない — 記録の本文（個人情報・機微データ）は送信も開示もしません。
- 相手が独立に検証 — 受け取った側はリンクを開くだけ。アカウントもキーも不要です。
- 書き換えは検知 — 1文字の書き換えも、検証の時点で一致しなくなります。
入力を normalized form（Unicode NFC、空白・不可視文字の扱いを定義）に変換し、その指紋をコミットします。推論の前段で「人が意図した入力」と「AI が受け取る入力」の visibleEq を runtime で検証し、一致しなければ実行前に止めます。入力 content を開示せずに、改ざんが無かったことを独立に検証できます。
技術詳細を見る ↗03 · 選定基準
なぜ、いままでのやり方では足りないのか。
「中身を出さず渡す」「独立検証」「書き換えの検知」の 3 つが同時に要る業務こそが Lemma の領域です。
| 手段 | 中身を出さず渡す | 独立検証 | 書き換えを検知 | そのままだと |
|---|---|---|---|---|
| アクセス制御・権限管理 | △ | ✗ | ✗ | 社内の誰かが直せた、という疑いが残る |
| マスキング / 黒塗りで提出 | △ | ✗ | ✗ | 黒塗りの手間が増え、元の記録の真正性は示せない |
| 暗号化して保管・送付 | ✓ | ✗ | ✗ | 相手が確かめるには、結局開示が要る |
| WAF / 入力監視のみ | △ | ✗ | ✗ | 検知・記録止まりで、相手が独立に確かめられない |
| Lemma（ZK 証明）唯一 3 つ揃う | ✓ | ✓ | ✓ | 相手がリンクを開くだけで確かめられる |
04 · 進め方
実装イメージと、導入の流れ。
示すこと「人が見た入力 = AI が読む入力」の整合性
出さないものプロンプト・入力 content の中身
送るものハッシュのみ
記録の本文送信されません
発行しました 0x68d4…9f01
改ざんされていません
NOT TAMPERED
署名の一致改ざんの有無発行者
開示範囲・保存期間の設計から PoC、本番運用まで伴走します。
まずは、30分のヒアリングから。
「ユーザー入力経由の AI 攻撃が不安」な業務を 1 つ、最初の 30 分で聞かせてください。入力 content の開示は不要です。
お探しの業界・課題に合わせた事例が見つかります
課題や業種から業務ユースケースを探す（全36件） →