コンプライアンス · SOC 2 · 監査 · スナップショット 2026-09-28
JevにSOC 2はある？正直な現状と購買チェックリスト
Jev と SOC 2 への直接の回答——2026 年 10 月時点で公開報告書はなし——に加え、法務文書が実際にカバーする範囲、信頼サービス基準へのマッピング、調達前に実行すべきベンダーレビューのチェックリスト。
TL;DR
ありません。TypeSafe の法務文書に関する 2026-09-28 の時点で、Jev には公開された SOC 2（Type I・Type II いずれも）報告書も ISO 27001 証明書もありません。実際に存在するのは契約レベルの実質です：SCC を含む DPA、72 時間以内の侵害通知条項、15 日間の異議申立て期間付きサブプロセッサ一覧、年次セキュリティ監査、「学習に使わない」コミットメント、そして申請できるエンタープライズ零データ保持。したがって：下のチェックリストを実行し、判断ごとの監査証拠を自分で生成し、データプレーンの管理が譲れないならワイヤ互換の代替をセルフホストしてください。
事実スナップショット 2026-09-28（当サイトのデータプライバシーガイドと共通）：開発者ドキュメント索引にセキュリティやコンプライアンスのページはなく、法務インデックス・DPA・プライバシーポリシーは直接通読しました。このページは公開されている AICPA の信頼サービス基準をその記録に対応付けたもの——エンジニアリングの視点であり、コンプライアンスの判定でも法的助言でもありません。信頼ページは変動するため、依存前に trust.typesafe.ai をご自身で確認してください。
JevにSOC 2はある？直接の回答
調達担当が本当に問うてくる問いに、マーケティングではなく文書から答えます。
公開済み——監査に関わる記録
- 実質のある DPA：EU SCC（モジュール 2、処理者として行動する場合はモジュール 3も）、英国アデンダム、「72 時間以内」の侵害通知、セキュリティ監査「12 か月につき 1 回を超えない」。
- trust.typesafe.ai/subprocessors のサブプロセッサ一覧と 15 日間の異議申立て期間——署名日に保存し、期間をカレンダーに入れる。
- プライバシーポリシーの学習不使用コミットメント：「お客様のプロンプトその他の入力を用いて AI や機械学習モデルを学習・微調整することはありません。」
- エンタープライズ零データ保持（ZDR）は法務インデックス自体に公示。窓口は sales@typesafe.ai。
公式な場所には何も公開されていないもの
- いずれのタイプの SOC 2 報告書もない——ベンダーリスクファイルに添付するものが存在しません。
- ISO 27001 証明書がなく、法務文書に認証に関する記述も一切ない。
- 監査範囲の説明・監査人名・ブリッジレターがない——つなぐ対象そのものがない。
- ホスト型エンドポイントについて、公開された SLA・暗号化仕様・ペネトレーションテスト要約がない。
購買側がすべきこと
- sales@typesafe.ai に直接メールし、現在の監査・認証ロードマップを尋ねる——そして依存する回答はすべて、署名する DPA に書き込む。
- trust.typesafe.ai が今日何を表示しているかを自分で確認する。当サイトのスナップショットは 2026-09-28 であり、信頼ページは動きます。
- 証拠を自分で生成する：本番の判断をすべて記録し（下のレコード schema）、監査人には持っていないベンダー PDF ではなく自分のログを抽出してもらう。
- 規制や顧客契約が認証済みベンダーを要求するなら、ホスト型 Jev を補完的統制のケースとして扱う——か、データプレーンをセルフホストする。
SOC 2 基準と Jev 記録のマッピング
5 つの信頼サービス基準ファミリーを、購買側が実際に指し示せるもの——公開文書と公表済み契約のみ——で採点します。
| 基準ファミリー | 記録が与えるもの | 状態 |
|---|---|---|
| Security (common criteria) | 契約レベルの実質のみ：DPA にはセキュリティ監査「12 か月につき 1 回を超えない」、15 日間の異議申立て期間付きサブプロセッサ一覧、72 時間以内の侵害通知が明記されています。監査報告書自体は非公開です。 | 契約レベル |
| Availability | 確認した文書には記載なし：ホスト型エンドポイントについて、公開された SLA・稼働率目標・ステータスページのコミットメントがありません。公式記録が最も少ない分野です。 | 記載なし |
| Processing integrity | API 仕様そのものが証拠です：単発リクエストは確率分布・信頼度・トークン使用量付きの型付き回答を返します。判断の間に入りうる生成ステップがありません。バージョンごとの決定性は文書化された挙動であり、認証されたプロセスではありません。 | 文書あり |
| Confidentiality | プライバシーポリシーは入力をモデル学習に使わないと明言し、エンタープライズ向けゼロデータリテンション（ZDR）が法務インデックスに公示されています。暗号化の詳細・鍵管理・アクセス制御は非公開です。 | 契約レベル |
| Privacy | DPA には EU SCC（モジュール 2、処理者として行動する場合はモジュール 3も）と英国アデンダム、サブプロセッサ一覧、「必要な期間」の保持が明記され、プライバシーポリシーは国外訪問者のデータを米国へ移転すると開示しています。GDPR のデータ主体の権利セクションはポリシーにありません。 | 契約レベル |
エンジニアリングの視点であり、コンプライアンスの判定ではありません：契約条項はプロセスの存在証明であって、統制が機能している証明ではありません。「文書あり」とは API リファレンスがその挙動を記述していることで、監査人がテストしたことを意味しません。このマッピングは TypeSafe のホスト型エンドポイントが対象です。オープンソース代替にはそれぞれの（通常はより弱い）記録があり——laya.studio 自身の FAQ は「現時点で ISO 27001 のような正式な認証はない」と明記しています。
チェックリストがベンダーに求める意思決定ログのスキーマを、まず自分で作る意思決定モデルはチャットアシスタントより監査しやすい理由
認証の問いが開いたままの間に、リスク委員会に提示できる「監査サーフェス」の議論。
チャット LLM はプロンプトを生成テキストに変えるため、あらゆる監査問いが生成の失敗モードを引き継ぎます：何を言ったか、なぜか、何を省いたか？Jev の呼び出しには監査対象となる生成ステップがありません——応答は、リクエストで自分が定義した criteria の上に、確率分布・信頼度・トークン使用量付きの型付き回答として返ります。
リクエストサーフェスは小さく完全に可読です：model、state、questions。自分が名付けた question キーは「基盤モデルに送られず、推論にも使われない」と文書化されており、内部の語彙は自分側の境界内に留まります。セッションや会話オブジェクトはなく、各呼び出しが独立しているため、判断ごとのロギングは後付けではなく自然に成立します。
だから正直な立場はこうです：アーキテクチャは証拠を安くし、認証は証拠を他人の仕事にする。後者が変わるまで、前者をやり切る。
// One record per production decision — the evidence you own
{
"ts": "2026-10-31T09:14:22.481Z",
"decision_id": "dec_01JA8...",
"model": "jev-latest",
"endpoint": "https://api.typesafe.ai/v1/evaluate",
"state_digest": "sha256:9f2c…", // hash of the input, not the input
"question": "route", // your key — not model-facing
"answer": "billing",
"probabilities": { "billing": 0.94, "technical": 0.05, "account": 0.01 },
"confidence": 0.92,
"latency_ms": 147,
"usage": { "input_tokens": 212, "output_tokens": 84 },
"policy": { "threshold": 0.80, "on_low": "human_review" },
"outcome": "auto|escalated" // filled by your gateway afterwards
}本番の判断ごとに JSON レコードを 1 件、ゲートウェイが書きます：state は本文ではなくハッシュで保存し、判断時のゲートポリシーを残し、結果パス（自動かエスカレーションか）を後から書き込みます。半年分のこのログは、「このシステムがどう動くか」という問いに Type I 報告書より雄弁に答えます。完全な schema と保持方針は意思決定監査ログのレシピへ。
型付き判断が生成テキストと異なる挙動を示す理由ベンダーレビューのチェックリスト
Jev を本番データに触れさせる前に済ませる 8 項目——ほとんどは数分、2 つだけメールが必要です。
法務文書 3 点（法務インデックス、DPA、プライバシーポリシー）を通読する——短く、そしてそれこそが公式記録だからです。
sales@typesafe.ai に現在の認証状況とロードマップを尋ねる；回答は日付付きで記録する。
セキュリティホワイトペーパーやアーキテクチャ概要を求める；存在しなければ、それ自体が一つの知見です。
データを保持させられないなら ZDR を書面にする——法務インデックスに公示があっても、拘束力は署名済み DPA から生まれます。
署名日に trust.typesafe.ai/subprocessors を保存し、15 日間の異議申立て期間をカレンダーに入れる。
侵害通知の時計（「72 時間以内」）と、自分側の通知受領者を確認する。
本番のモデルバージョンを固定し監査ログに記録する——決定性の主張はバージョンごとに成立します。
退路を先に決める：来四半期、調達がホスト型 Jev を否認したらこの機能はどうなるか？（定番の答えはセルフホスト代替です。）
項目 1・5・6・7 は今日の公開文書だけで検証できます；項目 2・3・4 は 2 通のメールとその返信；項目 8 はコンプライアンスではなくプロダクトの決定です。
依存する前に、API 仕様を自分の手で検証する待たずに今日から出せる補完的統制
報告書が無いことで生じる隙間を狭める 4 つの統制——すべてベンダーではなく自分の手元にあります。
送信前に最小化する
PII 最小化ミドルウェアは、保持・漏えい・差押えの対象になるデータ面を縮小します。ペイロードに直接識別子がなければ、ほとんどのデータ問題はより小さな問題になります。
越境移転を明示的にゲートする
プライバシーポリシーは国外訪問者のデータを米国へ移転すると開示しています。より厳しいデータ所在地要件があるなら、ルーティング判断とその根拠の記録は、慣行ではなく型付きゲートであるべきです。
データプレーンをセルフホストする
顧客契約がデータプレーンに認証済みベンダーを要求する場合、ワイヤ互換のオープン代替（Laya、Kev、JevK5 など）はプロトコルを保ったまま、証拠責任を自分で管理するインフラへ移せます。切り替え前に精度トレードオフを確認してください。
順序が重要です：まず最小化と記録（どのシナリオでも効きます）、次にデータ所在地のゲート、最後にデータプレーンの移転を検討する——オープンモデルは独立ベンチマークで依然としてホスト型に後れを取っています。
データプレーンの管理が譲れないとき：セルフホスト・マトリクス購買担当が実際に問う SOC 2 の質問
Jev に SOC 2 認証はありますか？
TypeSafe の法務文書に関する 2026-09-28 の時点で、公開されていません。SOC 2 Type I・Type II の報告書も、ISO 27001 証明書も、法務インデックス・DPA・プライバシーポリシーに認証に関する記述もありません。実際に存在する監査関連の実質は契約レベルです：SCC、72 時間以内の侵害通知、年次セキュリティ監査、サブプロセッサ一覧、エンタープライズ ZDR。最新の状況は sales@typesafe.ai に尋ねてください——そして trust.typesafe.ai はご自身で確認を。信頼ページは動きます。
ベンダーポリシーが SOC 2 を要求する場合、Jev は使えますか？
ポリシーに補完的統制の経路があるか次第です。多くのベンダーリスクプログラムは、契約上の保障（DPA には実質のある条項があります）、自前の監査ログ（判断ごとのレコード）、データ最小化、文書化された退路を受け入れます。認証を無条件に要求するポリシーなら、ホスト型 Jev は今日その門を通れません——セルフホスト代替が現実的な選択肢です。あるいは TypeSafe のロードマップ回答を待ちます。
SOC 2 と ISO 27001 は同じものですか？
違います。SOC 2 はサービス組織の統制に対する AICPA の証明報告書で、期間型（Type II）と時点型（Type I）があります；ISO 27001 は情報セキュリティマネジメントシステムの認証可能な国際規格です。購買側はしばしばどちらかを受け入れます——しかし Jev はどちらも公表していないため、ここで重要なのは違いではなくロードマップの問いです。
Jev のアーキテクチャはどんな SOC 2 証拠を集めやすくしますか？
判断ごとの証拠です：確率分布・信頼度・トークン使用量付きの型付き回答が、自分が定義した criteria の上に返ります。独自のログ（タイムスタンプ、state ハッシュ、question キー、回答、信頼度、ポリシーしきい値、結果パス）を重ねれば、数か月後でも本番の任意の判断を再構成できます。生成しない応答なので、監査インタビューで説明すべき自由テキストの挙動が存在しません。
エンタープライズ零データ保持（ZDR）は SOC 2 の代わりになりますか？
なりません——答える問いが違います。ZDR はベンダーが処理後に何を保持するかを限界づけます；SOC 2 は統制が期間にわたって機能したかを報告します。両方欲しいもので、今日書面にできるのは ZDR の方です。sales@typesafe.ai 経由で、ランディングページではなく署名済み DPA に結び付けてください。
オープンソースの Jev 代替に認証はありますか？
概してありません——しかもある一家自身がそう明言しています：laya.studio の FAQ は「現時点で ISO 27001 のような正式な認証はない」と明記しています。セルフホストは責任の所在（自分になる）を変えるのであって、証明書の有無を変えるのではありません。チームがセルフホストするのはデータプレーン管理のためであって、コンプライアンス書類のためではありません。独立ベンチマークでの精度差（最良のオープン ≈0.704 に対しホスト型 0.966）が受け入れるトレードです。
TypeSafe は認証を取るのでしょうか？待つべきですか？
分かりません——確認した文書にロードマップは公表されておらず、だからこそチェックリストは「尋ねて記録する」ことを求めます。当サイトの見解：このページの統制（最小化・記録・ゲート・退路）は、ロードマップがどうであれ出荷する価値があります。GDPR 第 22 条や DPIA の義務は、どんな証明書も代わりに果たしてくれないからです。