# Jevの導入｜契約・データの取り扱いで確認することと、業務システムへの組み込み方

> Jevを会社で導入する前に、情シス・法務が確認すること(入力データの学習利用、保存、データの所在、再委託先、SOC 2、賠償の上限、クレジットの失効)をTypeSafe AIの規約から整理。あわせて、業務システムへの組み込みの設計パターン、内製と外注の判断基準を解説します(2026-09-30時点)。

発行: 株式会社ウェステリア(https://westeria.jp) / カテゴリ: Jev(判断特化AIモデル) / 出典: https://westeria.jp/guide/jev-integration/

Jevを試してみて筋がよさそうだ、となったあとに出てくるのが「既存の業務システムにどう組み込むか」という問題です。判定モデルを呼ぶこと自体は難しくありませんが、確信度で分岐させる設計、低い確信度の受け皿、仕様変更への備えを考えないと、動くけれど運用できないものができあがります。その手前には、契約とデータの取り扱いの確認もあります。この記事では、2026-09-30時点で確認できる情報をもとに、導入の前に情シス・法務が確認すること、組み込みの設計パターン、発注前に決めておくことを整理します。

仕様確認・更新日: 2026-09-30

## 結論

- TypeSafe AIの規約では、入力したデータをAIの学習に使わないと明記されています。一方、データの処理と保存は米国で、保存期間の日数は公開されていません。賠償の上限は直前12か月の支払額と50ドルの大きいほうです(2026-09-30に確認)。機密情報や個人情報を送る前に、この条件でよいかを社内で決める必要があります
- 入手経路は、TypeSafe AIの公式API(2026-09-20から誰でも登録可。クレジットの購入が必要)のほか、Cloudflare・Vercel AI Gatewayなどのゲートウェイ経由があります。経路を差し替えられる作りにしておくと切り替えが効きます
- 設計の要点は3つです。判断をAPI境界として切り出すこと、LLMと役割分担させること、確信度が低いときのフォールバックを先に決めることです
- 公開から日が浅く、仕様変更のリスクがあります。基幹業務にいきなり載せず、判断の呼び出し部分を差し替え可能な形にしておくのが現実的です

## 導入の前に、情シス・法務が確認すること

Jevを業務で使うと、問い合わせの本文や申請の内容といった自社のデータを、TypeSafe AIのサーバーへ送ることになります。試す段階では気にならなくても、本番のデータを流す前には、情シスや法務の確認が要ります。TypeSafe AIが公開している規約とトラストセンターから、確認の対象になる項目を抜き出しました(2026-09-30に確認)。

| 確認する項目 | 公開情報でわかること | 出どころ |
| --- | --- | --- |
| 入力したデータの学習への利用 | 入力をAIモデルの学習や微調整に使わない。顧客のデータを学習用のデータに含めるには、顧客の事前の同意が要る | プライバシーポリシー、基本契約 4.1 |
| データの保存期間 | 日数は公開されていない。「サービスの提供に合理的に必要な期間」保存するとされている | プライバシーポリシー |
| データの所在 | 米国。日本の拠点や、地域を選ぶ設定は公開情報にない | プライバシーポリシー |
| 再委託先 | 6社で、すべて米国。AWS(保存と処理)、Modal・Nebius・CoreWeave(処理のみで保存しない)、Slack・Google Workspace(サポートの連絡)。追加するときは事前に通知があり、15日以内に異議を出せる | トラストセンター、データ処理契約 3.2 |
| 第三者による監査 | SOC 2 Type II(2026)の報告書がある。閲覧は申請制 | トラストセンター |
| 事故が起きたときの通知 | 顧客の個人データへの不正なアクセスなどを認識してから72時間以内 | データ処理契約 5.2 |
| 稼働の保証 | 中断や誤りがないことは保証しない。稼働率の数値の保証は、公開されている契約では確認できなかった | 基本契約 9.3 |
| 賠償の上限 | 直前12か月に支払った額(支払う義務のある額を含む)と、50ドルの大きいほう | 基本契約 12.2 |
| 購入したクレジット | 購入から12か月で失効する。契約が終わったとき、使っていない前払い分を返金する義務はない | 基本契約 8.2、10.3 |
| 禁止されている使い方 | 出力を使って別のモデルを学習させること、競合する製品を開発すること、単独のサービスとして再提供すること | 基本契約 2.3 |
| 社名・ロゴの掲載 | TypeSafe AIは、顧客の社名やロゴを顧客一覧などに使える。書面で求めれば止められる | 基本契約 16.4 |
| 準拠法 | 米国カリフォルニア州法 | 基本契約 16.2 |

※基本契約はMaster Customer Agreement、データ処理契約はData Processing Addendumを指します。規約は英語で、改定されることがあります(基本契約は2026-09-23に更新)。ここに挙げたのは要点で、契約の判断は原文で行ってください。

読み違えやすいのは、学習に使わないことと、保存しないことが別だという点です。規約が約束しているのは前者です。保存期間の日数は公開されていないので、保存を避けたいデータを扱うなら、保存しない扱い(ゼロデータ保持)ができるかをTypeSafe AIに個別に問い合わせることになります。窓口は privacy@typesafe.ai です。

個人情報を含むデータを送る場合は、米国の事業者に処理を任せる形になります。本人の同意や社内規程の扱いがどうなるかは、送るデータと処理のしかたで変わるので、法務に確認してください。最初の検証は、個人名や連絡先を取り除いたデータで始めるのが安全です。

金額の面で影響が大きいのは、賠償の上限です。Jevは単価が安いので、月の支払いが数百円なら、12か月分を足しても50ドルに届きません。その場合の上限は50ドルです。誤った判断で損害が出ても、提供元に求められる額はその範囲です。間違いの影響が大きい判断は、人の確認を残す前提で設計してください。

ゲートウェイ(Vercel、Cloudflareなど)を経由する場合は、契約の相手と請求元がそのサービスになり、データもそこを通ります。上の表に加えて、ゲートウェイ側の規約も確認の対象になります。

仕様の出典: [TypeSafe AI「Privacy Policy」(最終更新 2025-11-19)](https://typesafe.ai/legal/privacy-policy)
仕様の出典: [TypeSafe AI「Master Customer Agreement」(最終更新 2026-09-23)](https://typesafe.ai/legal/mca)
仕様の出典: [TypeSafe AI「Data Processing Addendum」(最終更新 2026-04-24)](https://typesafe.ai/legal/data-processing)
仕様の出典: [TypeSafe AI Trust Center](https://trust.typesafe.ai/)

## まず入手経路を決める

TypeSafe AIの公式APIは、2026-09-15の発表時点では順番待ち(ウェイトリスト)制でしたが、2026-09-20(米国時間)から誰でも登録できるようになりました。新規登録の受付はいったん止まり、2026-09-27(米国時間)に再開しています。再開後は新規登録の無料クレジットが一時停止になっており、使うにはコンソールでクレジットを購入します(2026-09-30時点)。エンドポイントは /v1/systemone、既定のモデル指定は jev-latest とされています。

公式API以外の経路も、発表直後から広がっています。2026-09時点で確認できる範囲では、Vercel AI Gatewayが2026-09-16から提供を開始し、Cloudflare Workers AIでも typesafe/jev として利用できるほか、OpenRouter経由での利用も報告されています。すでに使っているクラウドやゲートウェイがあるなら、そちらから触るほうが早く検証を始められます。

設計上の含意は一つです。どの経路を使うにせよ、Jevを呼ぶ部分をアプリケーションから切り離し、経路を差し替えられる形にしておくことです。発表から日が浅く、提供条件も価格も変わりうる段階なので、1箇所を書き換えれば経路を切り替えられる構造にしておく価値があります。

## 組み込みの基本形——判断をAPI境界として切り出す

既存の業務システムにJevを入れるとき、最初に決めるのは「どこを判断として切り出すか」です。現在の処理の中で、人が目視で仕分けしている箇所、条件分岐が複雑化して手に負えなくなっているルールの箇所が候補になります。

実装としては、その判断を一つの内部APIとして定義します。入力は判断に必要な情報だけ、出力は選択結果と確信度、という形です。呼び出し側はJevを直接知らず、この内部APIだけを見ます。この境界を引いておくと、あとからJevをルールベースに戻す、LLMに変える、複数を組み合わせるといった変更が、呼び出し側に波及しません。

入力の設計も押さえておきます。発表時点(2026-09)の仕様では、入力はテキストのみで、文字列・JSONオブジェクト・テキストの配列を受け付けるとされています。第三者の解説記事では1リクエストあたり64kトークン程度の上限が報告されていますが、この種の数値は変わりうるため、実装前に公式ドキュメントで確認してください。既存システムのレコードをそのまま投げるのではなく、判断に必要な項目だけを整形して渡す作りにしておくと、上限にもコストにも効きます。

## LLMとの併用パイプライン

Jevは文章を生成しません。そのため、実務のパイプラインではLLMと組み合わせる構成が多くなります。役割分担のさせ方には、いくつかの定番パターンがあります。

前段に置くパターンがもっとも素直です。入ってきた大量の入力をJevで仕分けし、対応が必要な一部だけをLLMに渡します。LLMの呼び出し回数が減るため、コストと待ち時間の両方に効きます。問い合わせの振り分けから返信文の下書きまでを一気通貫でやる場合がこれに当たります。

後段に置くパターンもあります。LLMやエージェントが生成した結果を、Jevで検証・採点する形です。出力が要件を満たしているか、公開してよい内容かといった判定を、安価で速いモデルに任せます。LLMの出力チェックを別のLLMにやらせると費用も時間もかさむため、判定だけならJevに寄せる価値があります。

エージェントのループの中に置くパターンもあります。次にどの処理を呼ぶか、続けるか止めるかといった分岐を、毎回LLMに考えさせるのではなくJevに判定させる構成です。ループが長いほど効果が出ますが、判断を誤ったときにループ全体が狂うため、確信度の扱いは慎重に設計してください。

| パターン | 構成 | 効きどころ |
| --- | --- | --- |
| 前段仕分け | Jevで分類 → 必要な分だけLLM | 入力件数が多く、LLM処理が必要なのは一部のとき |
| 後段検証 | LLMが生成 → Jevで採点・可否判定 | 出力チェックをLLMにやらせるとコストが重いとき |
| ループ内分岐 | エージェントの分岐判断をJevに委譲 | 分岐が多く、毎回LLMを呼ぶと遅いとき |
| ルールとの併用 | ルールで確定 → 残りをJev → 残りを人間 | 既存のルールベースがすでに動いているとき |

## フォールバックを先に決める

組み込みで最も見落とされるのが、確信度が低かったときの受け皿です。Jevは確信度を返しますが、その数字をどう使うかは設計する側の責任です。閾値を下回ったものをどこに流すかを決めないまま実装すると、保留の山ができます。

フォールバック先の候補は3つです。LLMに回して詳しく判断させる、既存のルールベース処理に戻す、人間のレビューキューに積む。どれを選ぶかで全体のコスト構造が変わります。

ここで注意したいのが、フォールバックの処理単位です。発表後に公開された本番ログでの検証記事では、Jev単体の処理費は既存処理の約96%減だったにもかかわらず、保留分を既存処理に戻す部分がバッチ単位で動くため、全体では約4.1%増になったと報告されています。単価の安いモデルに置き換えても、保留の戻し方が悪いと全体は安くなりません。組み込み設計では、モデルの単価より「保留の戻し方」を先に決めてください。

併せて、障害時の挙動も決めておきます。APIが応答しない、タイムアウトする、レート制限に当たるといった場合に、処理を止めるのか、既定値で通すのか、人間に回すのか。判定を業務フローの途中に挟む以上、この設計を省くと止まったときに業務も止まります。

## 公開から日が浅い段階で本番に載せるときの注意

正直にお伝えすると、発表から数日〜数週間の段階で本番の基幹業務に載せるのは早いと考えます。理由は3つあります。

第一に仕様変更のリスクです。公開から日が浅いモデルは、バージョンが上がれば挙動が変わる可能性があります。確信度の分布が変われば、せっかく調整した閾値が合わなくなります。モデルのバージョンを固定して使うか、バージョンが上がったときに再検証する手順を運用に組み込んでおく必要があります。

第二にベンダーロックインです。判断ロジックをJevの選択肢設計に密結合させてしまうと、提供条件が変わったときに逃げ道がなくなります。内部APIとして境界を引いておく、他の手段でも同じ判断ができる形にしておく、といった備えが有効です。ゲートウェイ経由の選択肢が複数ある点は、この意味では有利に働きます。

第三に情報の少なさです。発表時点(2026-09)では日本語の公式ドキュメントや解説は限られており、運用のノウハウも世の中に蓄積されていません。トラブルが起きたときに参照できる先が少ない状態で基幹業務を任せるのは、技術的な問題というより運用上の問題になります。まずは業務の一部、止まっても代替手段で回せる範囲から始めてください。

## 内製するか、外注するか

Jevの呼び出し自体はAPIを叩くだけなので、社内にエンジニアがいれば試すところまでは自力でできます。判断が分かれるのは、その先の「業務に載せる」部分です。

内製で足りるのは、検証の範囲が狭く、対象システムが自社の管理下にあり、失敗しても業務が止まらないケースです。まずは社内の1業務で試す、という段階であれば外注する必要はありません。

外注を検討する価値があるのは、判断の切り出し方そのものから設計が必要な場合、既存の基幹システムや業務フローに手を入れる必要がある場合、精度検証の設計を含めて第三者の目で組みたい場合です。とくに「どの業務に当てはめるか」「どう測るか」を間違えると、実装が正しくても成果が出ません。

ウェステリアはAIネイティブの開発を受託している会社です。Jevのような発表直後の技術については、いきなり開発を請けるのではなく、対象業務の洗い出しと、過去データでの精度・コスト検証から入ることをおすすめしています。無料のヒアリングを承っているので、「自社のこの業務に使えるか」の段階からご相談ください。検証の結果、Jevではなく既存のルールベースやLLMのほうが適していると判断した場合は、そのようにお伝えします。

- 対象業務を1つに絞り、過去データで正答率と確信度の分布を測る
- 閾値を仮置きして、自動化率と人間に残る件数を計算する
- 保留のフォールバック先と処理単位を決め、全体コストを試算する
- 判断部分を内部APIとして切り出し、経路とモデルを差し替え可能にする
- 止まったときの挙動と、モデル更新時の再検証手順を運用に組み込む

## よくある質問

### Jevに入力したデータは、AIの学習に使われますか?

TypeSafe AIのプライバシーポリシーは、入力をAIモデルの学習や微調整に使わないとしています。基本契約でも、顧客のデータを学習用のデータに含めるには顧客の事前の同意が要ると定めています(2026-09-30に確認)。ただし、学習に使わないことと保存しないことは別で、保存期間の日数は公開されていません。

### Jevに送ったデータは、どこで処理されますか?

米国です。TypeSafe AIのサービスは米国で運用されており、トラストセンターに載っている再委託先6社(AWS、Modal、Nebius、CoreWeave、Slack、Google Workspace)もすべて米国です(2026-09-30に確認)。日本の拠点や、地域を選ぶ設定は公開情報にありません。

### Jevを使うには承認や順番待ちが必要ですか?

不要です。公式APIは2026-09-20(米国時間)から誰でも登録できます。2026-09-27の登録再開から新規登録の無料クレジットは一時停止になっており、使うにはクレジットの購入が要ります(2026-09-30時点)。Cloudflare Workers AIやVercel AI Gatewayなどのゲートウェイ経由でも使えます。

### 既存の業務システムを作り替える必要がありますか?

多くの場合は不要です。現在人が仕分けしている箇所や、複雑化したルール分岐の箇所を内部APIとして切り出し、そこからJevを呼ぶ形にすれば、既存システム本体に大きく手を入れずに始められます。

### 本番で使って大丈夫ですか?

公開から日が浅いため、基幹業務にいきなり載せるのは早いと考えます。止まっても代替手段で回せる範囲から始め、モデルのバージョンを固定し、更新時に再検証する手順を用意してから範囲を広げてください。

### 開発期間と費用の目安はどのくらいですか?

対象業務と既存システムの状態で大きく変わるため一律にはお答えできませんが、まずは1業務に絞った精度検証から始める形が一般的です。検証で見込みが立ってから実装の規模を決めるほうが、結果的に無駄が出ません。具体的な見積もりは無料のヒアリングでお出ししています。

### コストが本当に下がるか、事前にわかりますか?

過去データで試算すれば、ある程度の見当はつきます。ただしJev単体の単価ではなく、確信度が低かった分をどこに戻すか、その処理がどの単位で動くかまで含めて計算してください。ここを見落とすと全体では安くならないことがあります。

## 関連ページ

- https://westeria.jp/guide/jev/
- https://westeria.jp/guide/jev-usage/
- https://westeria.jp/guide/jev-pricing/
- https://westeria.jp/guide/generative-ai-integration/

---

株式会社ウェステリアは、AIネイティブな開発スタイルでソフトウェア開発と業務自動化を行う会社です。初回1時間の無料ヒアリングを受け付けています: https://westeria.jp/#contact