ある会計事務所で、こんな話を伺ったことがあります。AI議事録SaaSを試したところ操作感が気に入ったので、担当者の方が個人クレジットカードで申し込み、そのまま顧問先との打ち合わせ録音をアップロードして使い始めたそうです。半年ほど経って、別件の社内点検で「このサービス、データはどこに保存されているのですか」と話題になり、利用規約を改めて読み直したところ、録音データの保存先が米国リージョン、しかもDPAは法人として締結していない状態だったことが分かりました。
これは仮想ケースですが、特定の事務所の実話ではなく、守秘の観点も踏まえて再構成した典型的な状況です。
業務にAI関連のSaaSを入れる場面で、ときどき耳にする流れです。月額数千円から始められて、申し込みから数分で動き始めるので、契約条件の確認を後回しにしやすい構造があるようです。後から「データが海外に保存されていた」「DPAを結んでいなかった」と気づくケースも、現場の会話で出てきます。
本稿では、SaaSの契約時に目を通しておきたい条項と、自社で確認できる範囲・専門家に相談したくなる範囲の線引きを、運用例の形でお伝えします。各SaaSの具体的な取扱いは2026年3月執筆時点の情報です。本文中に確認日を記載した箇所を除き、最新版は各公式ドキュメントでご確認ください。
なお本記事は士業実務における一般的な論点の紹介で、 個別事案の適法性判断・契約条項のリーガルレビューではありません。AIベンダー利用規約・AI事業者ガイドライン・各士業法は改定が続く領域なので、 実際の運用は、 所属士業会の最新指針・顧問弁護士の見解・ベンダーの最新公式規約・最新の法令テキスト (e-Gov法令検索 等) でご確認ください。
動いている状態からは見えにくい条項
SaaSの利用規約は分量が多く、UIから見えないところに重要な条項が置かれていることが多いです。事務所での実務に組み込むなら、契約時に目を通しておきたい論点として、おおむね以下のような場面が現場では出てきます。
- データの保存・処理が行われる国・地域 (= データ越境)
- 顧客データをSaaS側の機械学習や統計分析に使うかどうか
- SaaS事業者が外部委託している先 (= サブプロセッサ) の一覧と通知義務
- 事故が起きたときのSaaS事業者の責任限度 (= 賠償上限)
- サービス停止・解約時のデータ取扱い (= SLA、 データ持ち出し権、 削除権)
- DPA (= Data Processing Addendum) の有無と適用範囲
どれも 「動いている」 状態からは見えない条項です。契約時にしか目を通す機会がなく、導入後に問題が出てから規約変更を交渉できる余地はほとんど無い、というのが現場で聞く声です。
データの所在地とサブプロセッサ
クラウドサービスを使うこと自体は、必ずしもデータが海外に出ることを意味しません。一方で、海外ベンダーが提供するSaaSの場合、実態としてサーバが日本国外 (= 米国・EU・東南アジア 等) に置かれているケースが多く見られます。SaaS事業者がバックエンドで使っているクラウド (= AWS / GCP / Azure等) のリージョンが別の国に設定されていることもあります。
個人情報保護法28条では、外国にある第三者に個人データを提供する場合、原則として本人の同意が要るとされています。例外として本人同意なしで提供できるのは、提供先の国が 「個人の権利利益の保護に関し本邦と同等の水準にあると認められる」 国 (= 現状はEU・英国が指定) であるか、提供先が 「基準適合体制」 を整備している場合 (= 事業者が継続的に確認する義務あり) に限られます。個人情報保護委員会も2023年6月2日付の注意喚起で、生成AIサービスを使う場面での個人情報保護法上の論点を整理しています。
SaaS事業者は自社単独でサービスを完結させていることはまれです。インフラ (= AWS / GCP)、 メール配信、 決済、 ログ解析、AI推論APIなどを複数のサブプロセッサに業務委託している構造が一般的になっています。DPAには現行のサブプロセッサ一覧と、サブプロセッサ追加時の通知義務が定められていることが多いので、一覧の公開場所 (= 多くはベンダーのTrust Center / Sub-processorsページ)、 追加・変更時の通知タイミング (= 何日前か)、 顧客側の異議申し立て権の有無 を確認しておく運用が、現場で取られています。日本語UIのSaaSであっても、推論部分は海外のAI APIに投げている構造はAI関連サービスでは珍しくないようです。
モデル学習・データの二次利用
入力したデータが他社のモデル学習に使われるかどうかは、関連記事 「AIに入力した情報は学習されるのか」 でも扱っていますが、SaaS契約の文脈でも独立して目を通したい論点です。
主要なAIベンダーの法人向け規約では、顧客コンテンツをモデル学習に使わないことを契約レベルで明記しているケースが多いです。AnthropicのCommercial Terms (= 本稿確認時点: 2025年6月17日版) では 「Anthropic may not train models on Customer Content from Services.」 と書かれています。OpenAIもEnterprise / API向け製品について、顧客のビジネスデータを訓練に使わない方針を公式ドキュメントで示しています（2026年3月執筆時点の情報。最新は公式ドキュメントで確認）。対象プラン・確認日・個別契約 (= Enterprise / 個別BAA等) で取扱いが変わる可能性があるので、契約前には最新版を確認しておく流れが現場では取られています。
注意したいのは、AI基盤側は学習しないけれども、間に挟まるSaaS側が独自に学習・分析しているケースです。SaaS事業者が 「サービス改善のため、 入力プロンプトと出力を集計分析する」 と規約に書いている、「匿名化したうえで第三者と統計データを共有する」 条項がある、「ユーザーが明示的にフィードバックボタンを押した会話は学習対象に含める」 といった条項は、基盤AIベンダー本体の規約ではなく、SaaS事業者の規約に書かれていることがあります。SaaS規約 → 基盤AI規約 → サブプロセッサ規約と契約が三層構造になっている前提で読む、という運用を取っている事務所もあります。
賠償上限と業務停止時の救済
多くのSaaS規約には賠償上限 (= Limitation of Liability) の条項が入っています。典型的なパターンは 「直近12ヶ月に顧客が支払った料金を上限とする」 というもので、Anthropic Commercial Terms (= 本稿確認時点: 2025年6月17日版) でも、賠償責任が 「過去12ヶ月に顧客が支払ったFees」 に制限されると書かれています。対象プラン・契約日時点での内容であり、個別契約や改訂で変わる可能性があります。
月額1万円のSaaSで事故が起きて、顧問先から1000万円の損害賠償を請求された場面を考えると、12ヶ月料金上限の条項が適用されればSaaS事業者から取り戻せるのは最大でも12万円程度、という形になります。残りの金額は事務所側で負担する流れになりやすいので、契約時に自所の想定リスクと並べて確認しておく事務所もあります。
SLA (= Service Level Agreement) に稼働率の保証 (= 例: 99.9%) が書かれているSaaSもありますが、保証を下回ったときの救済はサービスクレジット (= 次月の利用料割引) が中心で、業務停止による逸失利益までは補填されないケースが多いようです。一方的なサービス終了 (= EOL) の通知期間が短い (= 例: 30日) こともあります。解約時のデータエクスポート権・保持期間が曖昧なまま運用に入っているケースも、現場の相談で出てきます。業務クリティカルなSaaSほど、止まったときに何が止まるか、止まった場面での代替手段は何か、を契約とセットで考えておく事務所もあります。
DPAの読み方
DPAは法人契約に紐づくデータ処理契約で、GDPRや日本の個人情報保護法に対応するための条項、 サブプロセッサ一覧、 データ所在地、 暗号化、 監査権限などが書かれます。士業の業務でSaaSを使う場合、DPAの締結が実務上の前提になりやすい構造があります。
DPAを読むときに、現場で目を通している項目はいくつかあります。改訂日 (= Last updated / Effective date) が書かれているか。書かれていないDPAは信用度を一段下げる、という事務所もあります。管理者 (= Controller) と処理者 (= Processor) の定義はどうなっているか。データ所在地 (= Data location / Sub-processor locations) はどこの国・地域か。保持期間と削除権はどう書かれているか。セキュリティ対策 (= Technical and Organizational Measures) の水準はどうか。インシデント通知義務の期限はどう設定されているか (= 24 〜 72時間が典型的なようです)。
Anthropicの場合、Commercial Terms本文にも 「Data submitted through the Services will be processed in accordance with the Anthropic Data Processing Addendum (DPA)」 と書かれていて、DPAを読まないと処理条件が把握できない構造になっています。
DPAは、SaaSの申込フォームから自動的に締結される場合もあれば、法人として別途締結が要るケースもあります。「個人クレジットカードでAPIキーを取得した」 段階ではDPAが締結されていないケースが現場で繰り返し出てくるので、業務利用の前に管理部門で目を通しておく事務所もあります。
アクセス権・士業会の規程・インシデント対応
契約条項は法務だけでなく、情報セキュリティと業法・倫理規程の観点からも目を通したい論点があります。
SaaS事業者の従業員・運用担当者が顧客データにアクセスできる条件 (= サポート時のみ・本人同意必要・全データ閲覧可、 等) はどうなっているか。操作ログ・監査ログがどの程度保持され、顧客側から確認できるか。SSO・MFA・IP制限などのアクセス制御機能が法人プランで提供されるか。これらは事故が起きてから確認しようとすると、契約上の根拠がなくて対応してもらえない、という形になりやすいようです。
各士業会もAI利用に関するガイドラインを順次整備しています。業務委託先 (= SaaS事業者) の選定基準、 守秘義務との整合性、 顧問先への説明・同意取得義務などについて、所属士業会の最新の指針を確認したい場面が出てきます。経産省・総務省が公表している 「AI事業者ガイドライン」 も、AIを使う事業者として目を通したい資料の一つです。
SaaS事業者から情報漏えいの通知を受けた場面では、士業事務所から顧問先への通知・個人情報保護委員会への報告が必要になることがあります。通知から何時間以内に動けるか、顧問先に説明する 「何が起きたか」 をSaaS事業者から引き出せるか、監督官庁への報告書を起こせる人員・体制があるか。事故が起きてから手順を決めるのではなく、契約時点で 「もし起きたら誰が何をするか」 を決めておく事務所もあります。
自所への当てはめの流れ
新しいSaaSを入れる場面、 既に使っているSaaSを点検する場面では、現場ではおおむね以下のような流れで進めている事務所が見られます。
最初に、規約・DPA・SLAに一度目を通します。改訂日、 データ所在地、 賠償上限、 解約時のデータ持ち出し権、 サブプロセッサ一覧 の5点を特定するところまでは、自所で完結する作業として組めることが多いようです。
次に、自所の業務との照合をします。顧問先の情報を扱う業務に組み込むかどうかで、必要な確認の深さが変わります。越境移転に該当する場合は本人同意または基準適合体制の根拠を整理し、機微度の高い業務では業法・士業会規程との照合を間に挟む事務所もあります。
最後に、締結状態の点検と運用への反映をします。DPAが法人として締結済みか (= 個人カード契約のままになっていないか)、 インシデント通知の連絡経路が記録されているか、SLA違反時の救済手順が運用に落とせているか、を契約書ベースで点検する習慣を年次の棚卸しに置いておくと、後から困りやすい場面が減るようです。
契約書を読むところまでは自所で進められることが多いです。専門家に相談するかどうかは、扱う情報の機微度を見て判断する場面が現場では多いように見えます。SaaSを業務に入れる場面では、動き始めてからでは確認できない条項が多いという構造を踏まえて、契約段階で目を通す手順を業務の流れに置いておく、というのが現場でよく取られている運用です。
関連記事
- AIに入力した情報は学習されるのか
参考
- 個人情報保護委員会 「生成AIサービスの利用に関する注意喚起等について」 (2023年6月2日): https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- Anthropic, “Commercial Terms of Service” (2025年6月17日版): https://www.anthropic.com/legal/commercial-terms
- OpenAI, “Enterprise privacy at OpenAI”: https://openai.com/enterprise-privacy/
- 経済産業省・総務省 「AI事業者ガイドライン」（Ver1.2、2026年3月31日公表）: https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
- e-Gov法令検索 「個人情報の保護に関する法律」: https://elaws.e-gov.go.jp/document?lawid=415AC0000000057