2 つのデータベース、意図的に
ほとんどの LLM アプリケーションはリクエスト毎に 1 レコードを書き込む — タイムスタンプ、モデル、トークン、コスト、プロンプト、レスポンス、終了理由 — すべて 1 行に。それは当然のことに見えます。ガバナンスを真剣に受け止める必要のあるシステムにとっても間違っています。
SchneeAI は当初からデータを 2 つのストアに分割:
- Usage Ledger — 運用メタデータ。誰がどのモデルをいつ呼び出し、トークン数、コスト。ダッシュボード用にインデックスされ高速にクエリ可能。数年間保持。
- Vault — raw プロンプトと出力コンテンツ。アプリケーション層で暗号化。別のアクセス制御。別の保持。
同じインタラクションがそれぞれのストアに、不透明な識別子でリンクされた行を持ちます。Usage Ledger は「インタラクションが発生した」ことを伝える。Vault は「何が言われたか」を伝える。それらは同じ関心事ではありません。
分割する理由
3 つの理由。
1. 異なるオーディエンス、異なるアクセス
運用メタデータは頻繁に読まれる — ダッシュボード、課金、アラート、レイテンシをデバッグするオンコールエンジニアによって。運用チーム内で高速でインデックスされ、広くアクセス可能である必要。
raw コンテンツは稀に読まれる — インシデント調査、カスタマーサポートエスカレーション、データセット構築。読まれるとき、アクセスは重要 — ユーザーコンテンツを見るということ。それは意図的で、スコープされ、ログされ、レビューされるべき。
両方が同じテーブルにあると、そのテーブルはすべてにジョインされる。カジュアルなレイテンシクエリが、列がそこにあるというだけで raw プロンプトを引っ張る。デバッグスクリプトが列を選ぶより簡単だからと行をファイルにダンプ。1 年以内に raw コンテンツは至る所に。
分割によって、安全なパスがデフォルトパスに。Usage Ledger がほとんどの質問に答える。Vault に触れるのは別の決断。
2. 異なる保持
運用メタデータは長い有用寿命を持つ — トレンド分析のために数年間集計するかもしれない。5 年の保持ウィンドウは合理的。
raw コンテンツは異なる計算。保持する毎に、侵害で暴露され、召喚され、ユーザーが期待しない方法で使われる可能性がある日。保持はユースケースが許す限り短く — ほとんどのインタラクションは週や月、コンプライアンスや価値が要求する場合にのみ長く。
両方が同じテーブルにあると、保持はある数字になり — その数字はより長寿命のユースケースを満たすもの。メタデータがそこにある必要があるため、raw コンテンツは過保持に。
分割によって、保持をデータクラス毎に構成可能に。Usage Ledger は何年も集計指標を保持。Vault は月単位で raw コンテンツを保持し、構成されたウィンドウ後に自動消去。
3. 異なる脅威モデル
運用メタデータは機密 — 利用パターンを明らかにしうる — しかし raw コンテンツとは同じではない。漏洩した Usage Ledger 行は「このテナントが 15 時に GPT-4 を 2,000 トークン呼んだ」ことを伝える。漏洩した Vault エントリはユーザーが実際に言ったことを伝える。
2 つは異なる防御に値する。メタデータは強いアクセス制御と監査ログ。コンテンツはプロバイダー管理の保存時暗号化の上にアプリケーション層暗号化、テナントスコープに結びついた鍵管理。
同じテーブルを共有すると、防御は平均化される。分割することでそれぞれが必要なものを得る。
Vault の構築方法
Vault は 2 つのピース:
- オブジェクトストレージ (S3 互換、リファレンスデプロイでは R2) — 暗号化されたコンテンツブロブを保持。
- PostgreSQL メタデータテーブル — ストレージポインタ、暗号化鍵参照、テナントスコープ、保持クラス、アクセス監査を保持。
書き込みは上流 LLM 呼び出しが返ってきた後、インタラクションの第 2 トランザクション内で発生:
Tx2:
利用イベントをコスト/トークンで更新
クレジット予約を決済
予算カウンタを決済
raw コンテンツを Vault に (暗号化) 書き込み
監査イベント書き込み
outbox メッセージをエンキュー
commit
暗号化はアプリケーション層 — テナント毎のデータ暗号化鍵 (DEK) がゲートウェイを離れる前にコンテンツをラップ。DEK 自体は KMS に保存された鍵暗号化鍵 (KEK) でラップ。ストレージ内のオブジェクトは両層がなければ不透明。
読み取りは別の API サーフェスを経由。呼び出し元のアイデンティティとテナントスコープがチェックされ、アクセス理由が記録され、コンテンツが復号される前に監査イベントが書かれる。ほとんどのプロダクションパスは Vault から読まない — Usage Ledger から読む。
第一級の関心事としての保持
Vault の保持はデータクラス毎に構成可能。出荷時のデフォルト:
| データクラス | 目安の保持 | 理由 |
|---|---|---|
| アクティブな顧客インタラクション | 2–3 年 | Dataset Builder 経由の調査のみ |
| 調査 / マスキング済みデータセット | 3–5 年 | 分析と評価 |
| トレーニング適格データセット | 3–5 年 | 同意・マスキング・レビュー後のみ |
| モデル来歴 | 5 年以上 | 監査目的 |
バックグラウンドの保持ワーカーがスケジュールで Vault を歩く。アイテムのウィンドウが閉じると、ワーカーは同じトランザクションでオブジェクトストレージブロブとメタデータ行を削除。「ソフトデリートして忘れる」パターンはない — ウィンドウが閉じたら、コンテンツは消える。
顧客はより短いウィンドウを構成可能。ワーカーはより短い設定を尊重。
アクセス監査
すべての Vault アクセスは監査イベント。「誰が何を読んだか」だけでなく、「何の理由で」も。理由は API 契約の一部 — 呼び出し元は目的コード (incident-investigation、support-escalation、dataset-build、compliance-review) を供給し、監査イベントがそれを捕捉。
これらのイベント自体が監査ウィンドウ (5 年以上) で保持。レビュー可能 — ガバナンスチームは誰が何をいつなぜアクセスしたかを見られる。異常なアクセスパターン自体が検出可能。
これは機能ではありません。Vault 設計が意味をなす唯一の方法。Vault を構築してアクセスを監査しなければ、ターゲットを構築したことになる。
Vault が間違っているとき
Vault 設計にはコストがある。各インタラクションは 1 つではなく 2 つの書き込み。メタデータテーブルとオブジェクトストアを運用。鍵管理も独自の関心事。
プロトタイプには過剰。小規模チームの内部ツールには過剰。単一テナントのトラフィックを処理しコンプライアンスレビューに直面しないシステムには過剰。
しかし「内部ツール」から「コンプライアンス義務を持つマルチテナントプラットフォーム」への道は人が考えるより短い。コンテンツをメタデータから分離しておけばよかったと願う時点は、通常、そうするのが安かった時点の 6 ヶ月後。
Vault は、いずれにせよ構築するものを、より早く。
持ち帰るべきこと
今日 LLM アプリケーションを構築しているなら:
- コンテンツを今メタデータから分離。 メタデータストアが同じデータベースでも、テーブルとアクセスパスを分ける。
- コンテンツをテナント毎の鍵で暗号化。 クラウドプロバイダーを信頼しないからではなく、データが取りう未来のすべてのパスを信頼しないから。
- 保持を明示的に。 数字を選ぶ。必要と思うより短く。ユースケースが要求するときに長く、デフォルトでではなく。
- すべてのコンテンツ読み取りを監査。 コンテンツの読み取りがシステムでカジュアルなら、セキュリティ問題ではなくガバナンス問題がある。
どれも難しくない。すべて、後よりも前の方が簡単。
Vault は SchneeAI が構築された中核のプリミティブのひとつ。プロダクト概要を読んで AI Gateway や PromptOps との組み合わせを確認するか、raw 保持の必要性について会話を始めてください。