Jevはエンタープライズで使えるか｜規約とDPAを条文で読む

こんにちは、株式会社TIMEWELLの濱本です。

WARPの受講生を見ていて、最近ひとつ気になっていることがあります。新しいAIのAPIを触るのは速い。 記事を読んで、キーを取って、サンプルを動かすところまで30分もかかりません。

そのあと、社内で「これ、うちのデータ入れて大丈夫なんですか」と聞かれて止まります。規約を読んでいないからです。

この記事では、当社が実際に使っているJev（TypeSafe AI）を題材に、規約を一次情報で読んで、どこまでなら使えるかの線を引きます。Jevの話であると同時に、SaaSの規約をどう読むかの型の話でもあります。

先に要点です。

• 公開されている利用規約は「サイト」向けだけ。 API有償利用の条件は書かれていない
• 学習には使われない。これはプライバシーポリシーに明文があり、確認しやすい
• データは全部アメリカ。サブプロセッサは4社で、日本リージョンの選択肢は公開情報に無い
• 保持期間が日数で書かれていない。 ここがいちばん弱い
• SOC 2 Type II はある。ただしレポートは申請制
• 「動く」と「使える」は別。採用の判断には、公開されていない書面を取りに行く必要がある

まず、規約が4か所に分かれています

読まれない最大の理由が、これだと思っています。1か所にまとまっていません。

文書	場所	最終更新
利用規約	typesafe.ai/terms	2026年9月19日
プライバシーポリシー	typesafe.ai/privacy-policy	2025年11月19日
データ処理追加条項（DPA）	typesafe.ai/data-processing	2026年4月24日
トラストセンター	trust.typesafe.ai	随時更新

そして重要なのですが、技術ドキュメント（docs.typesafe.ai）には、データの扱いが一切書かれていません。 索引を見てもAPIの使い方とSDKだけです。開発者がドキュメントだけを読んで実装すると、規約に一度も触れずに本番まで行けてしまいます。

これは TypeSafe に限った話ではありません。技術ドキュメントと法務文書が別のサイトに分かれているのが普通で、そこが確認漏れの温床になります。読むべき場所を先に4つ押さえる。これが型の1つ目です。

落とし穴: 公開規約は「サイト」向けだけです

ここがこの記事で一番伝えたいところです。

typesafe.ai/terms を開くと、責任制限の条項にこう書いてあります。

TO THE FULLEST EXTENT PERMITTED BY LAW, THE AGGREGATE LIABILITY OF THE TYPESAFE ENTITIES TO YOU FOR ALL CLAIMS ARISING OUT OF OR RELATING TO THE USE OF OR ANY INABILITY TO ACCESS OR USE ANY PORTION OF THE SITE OR OTHERWISE UNDER THESE TERMS, WHETHER IN CONTRACT, TORT, OR OTHERWISE, IS LIMITED TO $100 USD.

責任の上限が100ドル。これだけ見ると、多くの会社の稟議は通りません。

ですが、早合点してはいけません。 同じ規約の定義を見ると、「Site」は https://typesafe.ai とそのサブドメインを指すと限定されています。そして冒頭に、TypeSafeの製品やサービスについて別途契約を締結した場合はその契約が優先する旨が書かれています¹。

つまり、この100ドルはウェブサイトを閲覧したことに起因する請求の上限であって、APIを有償で使うときの責任範囲ではありません。有償利用の条件は別契約にあり、その契約は公開されていません。

ここから2つのことが言えます。

1つ目。「$100が上限だから使えない」は、読み違えです。 条文の適用範囲を見ずに数字だけ拾うと、こうなります。

2つ目。だからといって安心はできません。 有償利用の責任範囲が公開情報から読み取れない、というのが正確な状態です。分からないなら、聞くしかありません。

規約を読むときは、まず適用範囲の定義を見る。 数字は後です。これが型の2つ目です。

学習に使われるか: 明文で「使わない」と書いてあります

ここは分かりやすい部分です。プライバシーポリシーに、APIから送信されるデータについて明確な記載があります²。

収集対象として「prompts, data, instructions, and other input」が挙げられたうえで、次の2つが書かれています。

• お客様のプロンプトその他のInputで、AIまたは機械学習モデルの学習およびファインチューニングを行わない
• サービスプロバイダー以外の第三者にInputを開示しない

生成AIの社内利用で最初に問われるのが「入れたデータが学習に使われませんか」なので、ここが明文になっているのは実務上ありがたい。稟議の資料に、そのまま引用できます。

ただし注意点があります。「学習に使わない」と「保存しない」は別の話です。 学習に使わなくても、ログとして残っていれば、それは社内に説明すべき事実です。次に見ます。

弱い部分: 保持期間が日数で書かれていません

正直に書きます。ここがいちばん弱いと思っています。

プライバシーポリシーの保持に関する記述は、「サービスを提供するために合理的に必要な期間、またはその他事業上・商業上の目的を支える範囲で」保持する、という趣旨です²。DPAのほうも「処理の目的を考慮し、適用法令に従って必要な期間」となっています³。

どちらも日数が書かれていません。 「30日で削除します」「ゼロデータ保持を選べます」といった、具体的な約束が公開情報には無い状態です。

ひとつ補強材料があります。トラストセンターに掲載されている統制の一覧に、「Customer data deleted upon leaving」（顧客データは契約終了時に削除）という項目があり、あわせて「Data retention procedures established」「Data classification policy established」も載っています⁴。SOC 2の監査対象になっている統制なので、手続き自体は存在していることになります。

それでも、社内規程で「入力データの保持期間を明示できること」を条件にしている会社では、これだけでは足りません。 その場合は、書面で日数を取りに行く必要があります。

データはどこにあるか: 全部アメリカです

プライバシーポリシーに「サービスは米国内でホストされている」とあります²。そしてトラストセンターにサブプロセッサが4社、所在地つきで公開されています⁴。

サブプロセッサ	役割	所在	記載されている扱い
Amazon Web Services	クラウド	米国	ライブリクエストの顧客情報を、AWS内のデータベース、キャッシュ、計算ノードで保存・処理
Modal	AIインフラ	米国	顧客のAIプロンプトを計算ノードで処理するが保存はしない
Slack	社内連携、顧客対応	米国	サポート用チャンネル等を通じて顧客情報が扱われうる
Google Workspace	社内連携、顧客対応	米国	メールや文書を通じて顧客情報が扱われうる

Modalの記載が具体的で、参考になります。 「処理するが保存しない」と役割ごとに書き分けているので、プロンプトが推論の計算ノードに残らないことは読み取れます。一方でAWSについては「保存・処理」と書かれているため、どこかには残るという理解が自然です。

日本リージョンの選択肢は、公開情報の範囲では見当たりません。 国内保管が要件の案件では、この時点で線が引かれます。当社がZEROCKでAWS国内サーバーを前提にしているのも、この要件がある顧客が実際にいるからです。

なお、EEAおよび英国からの移転には**標準契約条項（SCC）**が用意されています。EU向けは委員会実施決定2021/914のモジュール2（管理者から処理者）、英国向けは国際データ移転付属書（B1.0版）です³。日本の個人情報保護法の観点では、米国への越境移転として、移転先の制度に関する情報提供と本人同意の整理が別途必要になります。

DPAは実用的な内容です

データ処理追加条項は、形だけのものではなく、実務で使える内容が入っていました³。

• 顧客が管理者、TypeSafeが処理者という役割の明記
• 侵害通知は、認識してから72時間以内
• 12か月に1回、顧客による監査を認める（顧客負担、営業時間内）
• 新しいサブプロセッサの起用前に事前通知、顧客は15日以内に異議を申し立てられる
• サブプロセッサには、TypeSafe自身の義務と実質的に同程度の保護義務を課す

72時間通知と年1回の監査権は、エンタープライズのDPAとして標準的な水準です。サブプロセッサの15日異議は、実際に運用するなら通知の受け取り先を社内で決めておく必要があります。 気づかないうちに期限が過ぎるのが、よくある失敗です。

SOC 2 Type II はあります。ただしレポートは申請制

トラストセンターに SOC 2 Type II（2026年） が掲載されています⁴。統制はインフラセキュリティ20項目、組織セキュリティ13項目、プロダクトセキュリティ4項目などに分かれて公開されています。

ただし、レポートそのものは「Request access」の先にあります。 これは一般的な運用で、当社のISO/IEC 27001の登録証も同じように、必要な相手にお見せする形にしています。

ここで大事なのは、バッジがあることと、レポートを読んだことは違うという点です。米国のエンタープライズ購買では監査人の意見書そのものを求められます。採用の判断をするなら、請求して中身を読んでください。 除外事項や例外指摘が書いてあるのは、バッジではなくレポートのほうです。

準拠法はデラウェア州です

利用規約の準拠法はデラウェア州法、専属的管轄もデラウェア州の州裁判所および連邦裁判所です¹。仲裁条項があり、30日以内のオプトアウトが認められています。

日本企業が紛争時に米国で争うのは現実的ではありません。とはいえ、海外SaaSではこれが標準で、これを理由に不採用にすると使えるものがほとんど無くなります。争えないことを前提に、影響範囲を絞るのが実務的な判断だと思います。

判定: どこまでなら使えるか

条文を読んだうえで、私の線の引き方を書きます。

使ってよいと考える範囲。 公開情報、自社が作成した文章、社内の公開資料の分類。当社が記事1,852本をJevで分類したのがこれに当たります。既に世に出ている記事の本文なので、米国のサーバーを通っても実害がありません。

条件つきで使える範囲。 顧客名や取引条件を伏せたうえでの、業務データの分類。伏せ字にする処理を、送る前に自分のコードで行うことが条件です。プロンプトに入れてから「学習には使われないから大丈夫」と考えるのは順序が逆です。

書面を取るまで使わない範囲。 個人情報、顧客から預かったデータ、図面や設計情報などの営業秘密。保持期間が日数で示されていない以上、ここは止めておくべきだと考えています。

使えない範囲。 国内保管が契約上の要件になっている案件。公開情報の範囲では、日本リージョンの選択肢がありません。

採用前に取りに行くべき書面

公開情報だけでは埋まらない項目を並べます。トラストセンターの申請フォームか、営業窓口から請求できます。

1. API有償利用に適用される契約書そのもの。 責任制限、補償、解約条件。公開規約はサイト向けなので、ここが本体です
2. Inputの保持期間を日数で示したもの。 ゼロデータ保持の選択肢があるかも含めて
3. SOC 2 Type IIレポートの実物。 対象期間、除外事項、例外指摘
4. SLAと稼働率の定義。 公開情報には稼働率のコミットメントが見当たりません
5. データ所在地の選択肢。 日本、またはEUを選べるか

この5点は、Jevに限らず海外のAI APIを採用するときの共通項です。そのまま社内のチェックリストとして使えます。

読まないことのコストは、後から来ます

最後に、WARPの受講生に伝えていることを書きます。

規約を読まずに進めても、しばらくは何も起きません。 動くし、速いし、成果も出ます。問題が出るのは、社内の監査や、顧客からのセキュリティチェックシートや、インシデントが起きたときです。そのときに「読んでいませんでした」は通りません。

そして読むのは、思われているほど大変ではありません。この記事で見た範囲は、4つのページを開いて30分です。書いてあることと、書いていないことが分かれば、それで線は引けます。

大事なのは、「書いていない」を「問題ない」と読み替えないことです。保持期間が書かれていないのは、保持しないという意味ではありません。書いていないなら、聞く。それだけです。

当社のWARPでは、AI導入の研修で、手順よりも判断の基準に時間を使うようにしています。ツールは変わりますが、規約の読み方は残るからです。自社の現在地を測りたい方は、AIリテラシー診断から始めてみてください。

なお、当社はJevを実際に業務で使っています。ここに書いたのは批判ではなく、使う側が自分で線を引くための読解です。公開されている情報は、他社と比べて整理されているほうだと思います。DPAがきちんと用意され、サブプロセッサが役割と所在地つきで公開されているのは、そう多くありません。

まとめ

• 規約は4か所に分かれている。 技術ドキュメントには一切書かれていない
• 公開されている利用規約は「サイト」向けだけ。 $100の責任上限はサイト利用の話で、API有償利用の条件ではない
• 学習には使われない。 プライバシーポリシーに明文がある
• データは全部アメリカ。サブプロセッサ4社、日本リージョンの選択肢は公開情報に無い
• 保持期間が日数で書かれていない。 ここがいちばん弱い
• DPAは実用的（SCC、72時間通知、年1回監査、サブプロセッサ15日異議）
• SOC 2 Type II はあるが、レポートは申請制。バッジではなく中身を読む
• 採用前に取りに行くべき書面は5点。これは海外AI APIの共通項

自社でどこまで使ってよいかの線引きや、社内規程への落とし込みのご相談は、お問い合わせからどうぞ。

なお本記事は法的助言ではありません。個別の判断は顧問弁護士および自社の情報セキュリティ責任者にご確認ください。規約は改定されるため、採用の判断時には必ず最新版を直接ご確認ください。

参考文献

Footnotes

1. Terms of Use（TypeSafe AI、2026年9月19日最終更新）。「Site」の定義が https://typesafe.ai およびそのサブドメインに限定されていること、製品・サービスについて別途契約を締結した場合は当該契約が優先する旨、責任の総額が100米ドルに制限される旨、準拠法がデラウェア州法であり同州の裁判所を専属的管轄とする旨は、いずれも同規約による。2026年9月20日に確認 ↩ ↩²

2. Privacy Policy（TypeSafe AI、2025年11月19日最終更新）。Inputを学習およびファインチューニングに使用しない旨、サービスプロバイダー以外の第三者にInputを開示しない旨、サービスが米国内でホストされている旨、保持期間の記述は同ポリシーによる。2026年9月20日に確認 ↩ ↩² ↩³

3. Data Processing Addendum（TypeSafe AI、2026年4月24日最終更新）。管理者・処理者の役割、EU標準契約条項（委員会実施決定2021/914のモジュール2）および英国国際データ移転付属書（B1.0版）、72時間以内の侵害通知、12か月に1回の監査権、サブプロセッサの事前通知と15日以内の異議申立ては同DPAによる。2026年9月20日に確認 ↩ ↩² ↩³

4. Trust Center（TypeSafe AI）。SOC 2 Type II（2026年）の掲載、レポートが申請制であること、サブプロセッサ4社（Amazon Web Services、Modal、Slack、Google Workspace）の役割・所在地・扱いの記載、統制一覧に「Customer data deleted upon leaving」等が含まれることは同トラストセンターによる。2026年9月20日に閲覧 ↩ ↩² ↩³