プライバシー · データフローとコンプライアンス · 2026-09-28 検証

Jev のデータプライバシー:公式の記録と、送るデータを減らす方法

1 回の Jev 呼び出しはあなたの state を送り、型付きの判断を返します。TypeSafe がデータ保持とデータ駐留について何を文書化し、何を契約に委ねているのか。さらに今日から導入できる PII 最小化ミドルウェアを解説します。

結論から

Jev の開発者ドキュメントにプライバシーやデータ駐留のページはありません。実質の記録は法務文書の側にあります。SCCs と副処理者リスト、72 時間の侵害通知を備えた DPA、プロンプトを学習に使わないコミットメントを明記したプライバシーポリシー、申請すれば使えるエンタープライズ向けゼロデータ保持。保持期間は「必要な間」で、数値はありません。だから、送る前に最小化し(下の PII ミドルウェア)、保持の確約を署名済み DPA に書き込み、コンプライアンスは自分のプロセスとして運用すること。Jev の回答は人間の経路の後ろにある補助であって、自動的な裁定ではありません。

事実のスナップショット 2026-09-28:開発者ドキュメントのインデックス(docs.typesafe.ai/llms.txt)にプライバシー・セキュリティ・データ駐留のページはありません。HTTP リファレンス、System One のコンセプトページ、3 つの法務文書(DPA、プライバシーポリシー、マスターカスタマーアグリーメント)を直接読みました。laya.studio の記述はすべて同社自身のマーケティングで、当サイトは検証していません。本ページは法助言ではありません。

1 回の Jev 呼び出しが実際に送るもの

この API のプライバシー上の露出は、すべてリクエストボディの中にあります。そしてリクエストボディは、完全にあなたが組み立てるものです。

リクエスト項目何を運ぶかプライバシーの読み解き
statestring | object | array——評価対象のコンテンツ。テキスト、チャットログ、アプリの状態。呼び出しのプライバシー上の露出は、ここに集約されます。ここに置いたものはそのまま境界の外へ出ていき、ドキュメントは自動的なフィールド除去を説明していません。最小化はリクエストの前に、自分側で行うものです。
modelモデル ID。例:"jev-latest"。個人データではありません。
questions名前を付けられるマップです。各質問はタイプ(noul / choice / score)、instructions、criteria を宣言します。choice の選択肢は 1 設問最大 255 個。質問文はあなたの書くコピーです。そして criteria のラベルもコンテンツです。「Billing — sarah.miller@acmecorp.com」のようなラベルはリクエスト内で漏えます。ラベルにはカテゴリだけを書き、個別事案の詳細は入れないこと。
question keysquestions マップのキー(例:"route")。回答は同じキーで返ります。ドキュメント上はモデルに送られないと明記されています。キー "is not sent to the underlying model and is not used in inference."
Authorization headerBearer API キー。コンテンツではなく資格情報です。呼び出しを認証するだけのもの。サーバー側に置き、漏れたらローテーション——どの API キーと同じ規律です。

HTTP リファレンスに基づきます。レスポンスは質問のキー名で回答を返します。choice か score には確率分布と信頼度、noul は 0〜1 の値。加えて input_tokens と output_tokens を報告する usage オブジェクトが付きます。モデルに向かう内容は上の 2 つのフィールドに尽き、キー名はモデルに送られないと文書化されています。

Jev の 1 回の呼び出し vs チャット LLM の 1 ターン:構造的な違い

観点Jev の 1 回の呼び出しチャット LLM の 1 ターン
Request1 回の自己完結した呼び出し:state + questions。ドキュメントされたリクエストにセッションや会話オブジェクトはなく、文脈はすべて送る内容の中にあります。会話です。ターンがセッション内に蓄積し、毎ターン、それまでの文脈をプロバイダーに再送します。
Response質問ごとに型付きの回答。選ばれた選択肢またはスコア、その確率分布、そしてそこから導かれる信頼度——「生成テキストではなく、型付きの判断と確率」。停止条件に達するまでトークンを逐次生成するテキスト。プロンプトから書き上げられる新しい文章です。
What that means for privacyリクエストこそが露出のすべてです。state を縮めれば露出も縮まる。あなたのデータから回答文が生成されることはなく、会話を続けるために蓄積すべきものもありません。プロバイダーはあなたの文脈を受け取り、派生的な文章を返します。会話機能では、各製品自身のデータ管理方針に従って、セッション文脈がプロバイダー側に保持される可能性があります。
リクエストが実際に何を送るのか、動くサンプルで確かめる

公式の記録:あるもの、ないもの

調達の会話のための正直な基準線。開発者ドキュメントは沈黙し、法務文書は沈黙していません。

文書化されている——引用できる

  • 法務インデックス docs.typesafe.ai/legal.md が 3 文書へリンクします。データ処理契約(DPA。"how we process customer data on your behalf, including data retention" と説明)、プライバシーポリシー、マスターカスタマーアグリーメント。
  • プライバシーポリシーにある学習しないコミットメント:"We will not train or fine tune any artificial intelligence or machine learning models on your prompts or other Input."
  • 中身のある DPA。移転には EU の SCCs(Module 2。あなたが処理者なら Module 3 も)と UK アドエンダム。副処理者リストは trust.typesafe.ai/subprocessors で、新規には 15 日の異議申立て期間。侵害通知は "within 72 hours"。セキュリティ監査は "no more than once every 12 months"。準拠法はアイルランド法で、スイスの紛争はスイスの裁判所へ。
  • エンタープライズ向けゼロデータ保持(ZDR)の選択肢。法務インデックス自体に告知があり、窓口は sales@typesafe.ai。

公式のどこにも書かれていないこと

  • 開発者ドキュメントのインデックスに、プライバシー・セキュリティ・データ駐留のページは存在しません。2026-09-28 に docs.typesafe.ai/llms.txt で確認。
  • 保持期間の数値がありません。DPA はデータを "for as long as necessary taking into account the purpose of the Processing" 保持するとだけ。原則であって期間ではありません。
  • リージョン一覧、データ駐留の切り替え、データフロー図はありません。プライバシーポリシーは、当該地域からの訪問者のデータは "to the U.S. for storage and processing" へ移転されると述べています。
  • これらの文書に公表された認証(SOC 2、ISO 27001)はなく、プライバシーポリシーに GDPR のデータ主体の権利セクションもありません。DPA が詳細を trust.typesafe.ai に委ねているので、依存する前に今何が示されているか確認してください。

調達側が実際にすべきこと

  • 調達の前に 3 つの法務文書を通読する。短い文書であり、そして実際の記録だからです。
  • sales@typesafe.ai にメールして ZDR とセキュリティホワイトペーパーを求め、依拠する答えはすべて署名済み DPA に書き込む。
  • 署名日に trust.typesafe.ai/subprocessors のスナップショットを取り、新しい副処理者のための 15 日の異議期間をカレンダーに入れる。
  • 保持が契約になるまで、リクエストボディは保持されうるものとして設計する。次セクションのミドルウェアはまさにそのためのものです。
TypeSafe の法務インデックスを開く(docs.typesafe.ai/legal.md)
データフロー節で要約したエンドポイントとプロトコルの全体

PII 最小化:送り出す前にペイロードを小さくする

完全に自分で制御できる唯一の手段。そして本ページの中心にあるエンジニアリングパターンです。

state 文字列こそが唯一の要となる表面で、それはあなたの制御下にあります。分類型の質問——このチケットをどのキューへ、この返信の点数は、この取引をフラグすべきか——は、誰が言ったかではなく、テキストが何を言っているかで決まります。請求キューを決めるのは「二重請求」という内容であって、sarah.miller@acmecorp.com ではありません。最小化はこの隙間に住みます。呼び出し前に直接識別子を剥ぎ取れば、判断から漏れる個人情報はもうありません。

2 つの細部が、これを化粧ではなく仕組みにします。第一に、相関が必要な場所では削除ではなく仮名化。顧客 ID のソルト付きハッシュなら、識別子そのものは外に出さないまま、自分側の分析の結合は保てます。第二に、API リファレンスの文書化された分担を思い出すこと。質問のキー名はモデルに向かいませんが、state と自分で書く criteria の文は向かいます。カテゴリは criteria に、事案の内容は state に、それ以外は何も。

マスキング前——識別子が飛んでいる状態
// BEFORE — the whole ticket, identifiers included
{
  "model": "jev-latest",
  "state": "Ticket #4821 from sarah.miller@acmecorp.com
    (card on file 4024 0071 1748 2930):
    'I was charged twice for my September subscription
    and I want a refund now.'",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Route this support ticket to the right queue",
      "criteria": {
        "billing": "Payment, refunds, duplicate charges",
        "technical": "Bugs, errors, outages",
        "account": "Login, access, account changes"
      }
    }
  }
}
マスキング後——同じ判断、より少ない露出
// AFTER — same decision surface, zero direct identifiers
{
  "model": "jev-latest",
  "state": "Support ticket: customer reports a duplicate
    charge for the September subscription and requests
    a refund.",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Route this support ticket to the right queue",
      "criteria": {
        "billing": "Payment, refunds, duplicate charges",
        "technical": "Bugs, errors, outages",
        "account": "Login, access, account changes"
      }
    }
  }
}

ルーティングの判断には違いが分かりません。どちらのペイロードも、同じ意味について同じ質問をしているからです。メールアドレスもカード番号もチケット番号も、判断には何も貢献していません。追加されたのはあなたの法的リスクだけです。

TypeScript で state を最小化する

typescript
typescript
// lib/pii-minimize.ts — redact direct identifiers before the Jev call.
// A routing decision keys off what the ticket SAYS, not who said it:
// queue "billing" does not need a name, an email, or a card number.

const PATTERNS: [RegExp, string][] = [
  [/[\w.+-]+@[\w-]+\.[\w.]+/g, '[email]'],
  [/\b(?:\d[ -]*?){13,16}\b/g, '[card]'],
  [/\+?\d[\d\s().-]{7,}\d/g, '[phone]'],
];

// Salted FNV-1a: the same customer id maps to the same stable token, so
// decisions stay correlatable in YOUR logs while the identifier itself
// never leaves your system.
function pseudonym(value: string): string {
  const input = value + (process.env.PSEUDONYM_SALT ?? '');
  let h = 2166136261;
  for (let i = 0; i < input.length; i++) {
    h ^= input.charCodeAt(i);
    h = Math.imul(h, 16777619);
  }
  return 'cust_' + (h >>> 0).toString(36);
}

export function minimizeState(state: string): string {
  let out = state.replace(/customer[ _#]?\d+/gi, (m) => pseudonym(m));
  for (const [pattern, tag] of PATTERNS) out = out.replace(pattern, tag);
  return out;
}

// Usage — one line before the existing call:
//   const state = minimizeState(rawTicketBody);
//   await evaluate({ model: 'jev-latest', state, questions });

これらの正規表現はあくまで例示であり、コンプライアンス管理ではありません。典型的な直接識別子は捕らえますが、文脈型の PII(文章として書かれた住所、自由記述の健康情報)は見逃します。規制対象のトラフィックでは、本物の検出器(Microsoft Presidio など)を通すか、state を構造化済みの許可リストのフィールドに限定してから、出力を信頼してください。

Python で state を最小化する

python
python
# pii_minimize.py — redact direct identifiers before the Jev call.
import hashlib
import hmac
import os
import re

PATTERNS = [
    (re.compile(r"[\w.+-]+@[\w-]+\.[\w.]+"), "[email]"),
    (re.compile(r"\b(?:\d[ -]*?){13,16}\b"), "[card]"),
    (re.compile(r"\+?\d[\d\s().-]{7,}\d"), "[phone]"),
]
CUSTOMER = re.compile(r"customer[ _#]?\d+", re.IGNORECASE)
_SALT = os.environ.get("PSEUDONYM_SALT", "").encode()


def _pseudonym(match: re.Match) -> str:
    # Salted HMAC: the same customer id maps to the same stable token in
    # YOUR logs; the identifier itself never leaves your system.
    digest = hmac.new(_SALT, match.group(0).encode(), hashlib.sha256).hexdigest()
    return "cust_" + digest[:10]


def minimize_state(state: str) -> str:
    state = CUSTOMER.sub(_pseudonym, state)
    for pattern, tag in PATTERNS:
        state = pattern.sub(tag, state)
    return state


# Usage — one line before the existing call:
#   state = minimize_state(raw_ticket_body)
#   client.evaluate(model="jev-latest", state=state, questions=questions)

PSEUDONYM_SALT は秘密に、かつ固定で。ローテーションすると同一顧客の新旧トークンの対応が壊れます。TypeScript 版と同じ注意も当てはまります。正規表現は出発点であって、コンプライアンス管理ではありません。

PII が集まる代表的ユースケース:サポートチケットのルーティング

データ駐留:文書化された現実と 4 つの選択肢

Jev の処理はどこで起きるのか、契約はそれをどう扱うのか、そして足りないときに何をすべきか。

開発者ドキュメントにリージョンを尋ねても、何も見つかりません。リージョン一覧も、データ駐留の切り替えも、データロケーションのページもない。あるのはアーキテクチャではなく法務の実装です。DPA は EU の SCCs(Module 2。処理者として行動するなら Module 3)と UK アドエンダムで移転を扱い、準拠法はアイルランド、スイスの紛争はスイスの裁判所。プライバシーポリシーは、当該地域からの訪問者については "you are transferring your personal data outside of those regions to the U.S. for storage and processing" と述べています。併せて読めば、米国ベースの処理フットプリントが、国際移転向けの契約足場の上に載っている構図です。

それでデータ駐留の要件が満たせないなら、今日時点で 4 つの選択肢があります。公式かつ契約的なものが 1 つ、サードパーティのホスト型が 1 つ、アーキテクチャ的なものが 2 つ。いずれも前セクションの最小化ミドルウェアと重ねられます。ペイロードを先に小さくしておけば、下流の選択肢はすべて安くなります。

エンタープライズ向けゼロデータ保持(公式)

法務インデックスには、TypeSafe が "offer[s] zero data retention (ZDR) for enterprise customers" とあります。「何も保持しない」のための公式の手段です。セールスが管理する商談ベースの取り決めなので、sales@typesafe.ai に連絡し、確約を署名済みの DPA に書き込みましょう。ウェブページの記載を鵜呑みにするのではありません。

サードパーティのワイヤ互換ホスティング(laya.studio)

オープンソースの Laya モデルをホストする独立系サービスが、まさにこの角度を売りにしています。"Answered on GPUs in Switzerland. Nothing you send is stored."、Swiss-only モード、AWS チューリッヒ(eu-central-2)のアカウントデータ、x-laya-region レスポンスヘッダー、メタデータ 30 日のゼロコンテンツ保持。これらはすべて同社自身のマーケティングであり、当サイトは検証していません。しかも同社のページ自体が「今日時点で ISO 27001 などの正式認証は取得していない」と明かし、Jev とは「精度と信頼度のセマンティクスが異なる」と認めています。候補であって結論ではありません。個人データを流す前に、自分で検証を。

オープンな判断モデルをセルフホストする

Jev 本体はセルフホストできません。クローズドウェイトで、公開された重みがありません。できるのはオープン代替です。Laya(Apache-2.0)は pip で入り、laya-serve が同じ /v1/systemone を話すので、既存の SDK 呼び出しは base URL を変えるだけで動きます。代償は精度です。独立系 49 タスクベンチマークで、最強のオープンモデルは約 0.704、Jev は 0.966。完全なマトリクスは /self-hosted-jev へ。

自分の境界に設置する最小化ゲートウェイ

TypeSafe は残し、越境するものを縮めます。前セクションのミドルウェアを出口で回し、各 state から意味上の最小限だけを出す——氏名もメールもなく、相関が必要なところはソルト付き仮名。上のすべての選択肢と重ねられ、しかもそれらと違って、コストは関数 1 個で調達サイクルではありません。

4 つの選択肢のどれも、コントローラーとしてのあなたの義務を消してはくれません。どれを選ぶにせよ、次セクションの DPIA で比較すべきです。その比較自体が、審査に耐える文書になります。

セルフホストの完全マトリクス——10 ルートと最低ハードウェア

GDPR / DSGVO の視点

コンプライアンスはあなたの処理に付随するプロセスです。モデルやベンダーの属性ではありません。

抽象的な意味で「GDPR 準拠」なモデルは存在しないし、本ページは Jev が準拠する/しないとも言いません。GDPR が実際に問うのは、あなたの利用に合法的な根拠があるか、データを最小化しているか、権利を尊重しているか、重大な判断を見直せる状態にあるか、です。型付き判断 API にとって、こうした要件はむしろ好都合です。判断は補助であり、入力はあなたが最小化でき、人のレビュー経路は研究課題ではなくルーティングの規則で済みます。

Jev そのものについての誠実な記述は、すでに上で述べたとおりです。コントローラー-プロセッサーの DPA と SCCs は存在する。認証はこれらの文書に公表されていない。保持期間は、あなたの契約が数値を与えるまで、数値を持たない。あなた側の半分の方程式を、下の 4 つのチェックポイントで埋めてください。

判断システムのための 4 つのチェックポイント

Art. 6 — lawful basis

チケットをどのキューに入れるかの判断も処理です。法的根拠(契約の履行や正当な利益が一般的な候補)を明示し、最初の呼び出しの前に、監査の後ではなく、文書化してください。

Art. 5 — data minimization

前セクションのミドルウェアは、この原則をコードにしたものです。判断に氏名が要らないなら、氏名は「適切で、関連し、必要な範囲に限定された」データではありません。意味上の最小限を送ることです。

Art. 22 — automated decisions

法的効果または同様に重大な影響をもつ完全自動の判断には、追加の義務が伴います。実務の型は、Jev の回答を信頼度ゲートの後ろにある補助として扱うこと。低信頼度は人間へ回し、その経路をプロダクトの中で見える形に保ってください。

Art. 35 — DPIA

自動化された手段による個人のデータの体系的評価は、典型的な DPIA のトリガーです。ロールアウト前に下のチェックリストを通し、スコープが変わったらもう一度。

まさにこの種のシステムのための DPIA チェックリスト

  • 目的:この API があなたのために行う判断を 1 つだけ書き下す(ルーティング / 採点 / 承認)。それ以上広げない。
  • データ:最小化の後に state 文字列へ届くフィールドをすべて列挙し、1 つずつ理由を書く。
  • 必要性:判断は仮名化した入力で回せないか。上のミドルウェアを入れた後は、通常「回せる」。その結論を記録する。
  • 代替案:ホスト型 Jev と 4 つのデータ駐留の選択肢を比較する。その比較自体が DPIA の材料です。
  • 人の経路:人へエスカレーションする信頼度のしきい値を定義し、仮の事例ではなく実事例で試す。
  • ベンダー記録:署名済み DPA、副処理者リストのスナップショット、ZDR の往復文書を 1 つのフォルダに。
  • 再レビュー:次の見直しを予定に入れる。公式の記録は変わります。本ページは 2026-09-28 のスナップショットに基づく。

このセクションは、公開されている GDPR の概念を判断システムに当てはめたものです。エンジニアリングの視点での整理であって、法助言ではありません。TypeSafe と提携・承認の関係もありません。拘束力のある答えには、DPO または顧問弁護士を関与させ、その結論を契約に書き込んでください。

型付き判断と生成テキスト——プライバシーの表面の裏にあるモデル挙動

Jev のデータプライバシー:よくある質問

Jev は私のデータを保存しますか?

開発者ドキュメントは何も答えていません。保持のページがないからです。したがって拘束力を持つのは法務文書です。DPA は顧客の個人データを "for as long as necessary taking into account the purpose of the Processing" 保持し、プライバシーポリシーは "as long as reasonably necessary to provide you with the Services" とし、法がより長い保持を求めない限り請求で削除に応じます。どちらも数値を出しません。TypeSafe はエンタープライズ向けにゼロデータ保持(ZDR)も提供しています。sales@typesafe.ai に連絡し、それに依存する前に、確約を署名済みの DPA に書き込んでください。

Jev は GDPR に準拠していますか?

どのベンダーも抽象的な意味で「GDPR 準拠」ではありません。コンプライアンスはモデルではなく、あなたの処理に付随します。ベンダー側であるもの:EU の SCCs(UK アドエンダム付き)を含むコントローラー-プロセッサーの DPA、15 日の異議期間付きの副処理者リスト、72 時間の侵害通知と年次監査の条項、準拠法アイルランド。ないもの:公表された認証、プライバシーポリシーのデータ主体の権利セクション。あなたはコントローラーのままです。合法的な根拠を明示し、最小化し、重大な判断には人の経路を残す。その上で全体像を DPO に確認してもらってください。

Jev はセルフホストできますか?

できません。Jev 本体はホスト型のクローズドウェイト API で、公開された重みもオフラインモードもなく、マスターカスタマーアグリーメントはその出力から類似品を作ることを制限しています。ホストできるのは周囲のオープンなエコシステムです。Laya(Apache-2.0)のようなモデルは laya-serve 経由で同じ /v1/systemone のリクエスト形状を受け付けるので、既存の SDK 呼び出しは base URL を変えるだけで動き続けます。代償は精度です。独立系 49 タスクベンチマークで、最強のオープンモデルは約 0.704、Jev は 0.966。完全なマトリクスはセルフホスト Jev のページにあります。

Jev は私のプロンプトで学習しますか?

プライバシーポリシーはこうコミットしています:"We will not train or fine tune any artificial intelligence or machine learning models on your prompts or other Input." これはベンダー自身の公表したコミットメントです。引用しつつ、契約にも釘を打ってください。エンタープライズ契約と ZDR の取り決めこそ、この種の約束が宣言でなくなる場所です。調達プロセスがポリシーの 1 文以上を求めるなら、DPA の交渉はまさにそのためにあります。

呼び出しに含まれる PII はどうすれば?

要となる表面はあなたが制御できます。state 文字列です。文書化されたリクエストにセッションや会話オブジェクトはなく、質問のキー名は明示的にモデルへ送られない。つまり露出は、あなたが書く state と criteria の文に尽きます。直接識別子を除去し、顧客 ID はソルト付きハッシュで仮名化し、カテゴリは criteria に、事案の詳細は入れない。上のミドルウェアがこれを呼び出し前の 1 行で行います。

データ処理者は誰ですか?

自分の顧客のために判断を下す目的で API を呼ぶなら、あなたがコントローラーで、TypeSafe があなたの処理者です。公表されている DPA はコントローラー-プロセッサーの契約(SCC Module 2。あなた自身が処理者として行動する場合には Module 3)。副処理者は trust.typesafe.ai/subprocessors に一覧され、新規には 15 日の異議申立て期間があり、TypeSafe はその行為について責任を負い続けます。役割は利用の仕方で入れ替わり得るので、帰属はウェブページから推論せず、自分の契約で確認してください。