導入：SaaSへの不正アクセスが「利用企業の問題」になる時代

2026年10月、企業向けSaaSへの不正アクセスを起点に、そのサービスを使う企業が相次いで個人情報の漏えい等を公表しました。

コミュニティプラットフォーム「Commune」では、利用企業が運営する会員コミュニティの情報が影響を受けました。たとえばLINEヤフーは、同社サービス内のコミュニティ機能を使う1,750名の情報が第三者に閲覧・取得された「可能性がある」と公表し、不正利用や二次被害は現時点で確認されていないとしています。同社は10月6日にコミューン社から連絡を受けたと説明しています。

ノーコードWeb制作サービス「Studio」では、9月30日から10月1日にかけて不正アクセスがあり、10月14日の対処完了までクラウド環境内のデータが外部から取得できる状態にあったとされています。Studio社は、実際に取得された事実は確認できていないものの、取得されたものとみなして対応すると説明しています。同サービスのフォームを使っていた東北電力フロンティアは、10月16日にStudio社から連絡を受け、延べ182件の問い合わせ情報が漏洩した「可能性」があると公表しました。

ここで注目したいのは、不正アクセスを受けたのが利用企業が使う外部SaaSであったという点です。たとえばLINEヤフーは、本件との関連で自社システムへの不正アクセスは確認されていないと説明しています。それでも利用企業は、自ら事実を公表し、本人対応を行い、個人情報保護委員会への報告を検討する立場に置かれました。外部SaaSへの不正アクセスだけで、利用企業自身に法的・事業上の対応が必要となり得るということです。

技術的な防御を主に担うのは、情報システム部門やセキュリティ部門です。一方で、事故が起きたときに「誰が、何を、いつまでに、どの根拠で」行うのかを整理するのは法務の重要な役割です。両部門が分担しながら協力しなければ、実効性のある対応体制はつくれません。

本記事が問うのは、次の一点です。

第1章：SaaSの選定基準は「安全性」から「事故後の対応能力」にも広がる

これまでSaaSの選定では、機能、価格、稼働率、セキュリティ認証の有無が主な評価軸でした。今回の一連の事案を見ると、これに加えて「事故が起きたときに、どれだけ速く、どれだけ詳しく、利用企業に情報を渡せるか」が評価軸として重みを増していくと考えるのが自然です。

報道では、セキュリティ専門家が、ログを遡って提供できる期間や情報開示の程度など、透明性・追跡性がSaaS事業者に一層求められるようになるとの見方を示しています（ITmedia NEWS、2026年10月21日）。

もっとも、社会全体で選定基準の変化がすでに起きていると断定できる段階ではありません。ただ、利用企業の側から見ると、SaaS事業者の情報提供能力は、自社が法令上の判断を行えるかどうかを直接左右します。その意味で、「事故後の対応能力」を選定時に確認しておく合理性は十分にあります。

第2章：最重要｜事故発生時に情報を取得できる契約になっているか

2-1事故の通知義務――「速やかに」だけで足りるか

まず押さえるべきは、SaaS事業者の契約上の通知義務と、利用企業の法令上の報告義務は別物だという点です。

個人情報保護法第26条第1項は、要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正の目的をもって行われたおそれがある行為による場合、本人の数が1,000人を超える場合など、施行規則第7条が定める事態（漏えい等の「おそれ」がある場合を含む）について、個人情報取扱事業者に委員会への報告を義務付けています。報告は速報と確報の二段階で、委員会は速報の目安を発覚日から3〜5日以内、確報を30日以内（不正の目的によるおそれがある場合は60日以内）としています。

不正アクセスによる場合は、件数が少なくても報告対象になり得ます。東北電力フロンティアの延べ182件の事案でも、同社は個人情報保護委員会への報告を含め必要な手続を進めるとしています。

また、不正の目的によるおそれがある事態（規則第7条第3号）では、すでに個人データとなっているものだけでなく、事業者が取得しようとしている個人情報で、個人データとして取り扱うことが予定されているものも対象に含まれます。ガイドラインは、不正行為の相手方に、事業者が利用している第三者のサービスの提供者も含まれるとしています。Webフォームのように、データベースに取り込む前の入力情報を外部サービスで受け付けている場合も、この点を意識しておく必要があります。

期限の起算点は、事業者が報告対象事態を「知った」時点です。ガイドライン（通則編3-5-3-3）は、法人の場合はいずれかの部署が知った時点を基準とするとしています。委託先から通知を受ける場面では、委託元は通常、遅くとも通知を受けた時点で報告対象事態を知ったことになるとされています（同3-5-3-5）。「遅くとも」ですから、それより前に、たとえば現場部門が事業者からのメールやサービスの異常に気づいた時点で、すでに「知った」と評価される可能性もあります。社内でSaaS事業者からの連絡を法務・情報システム部門にすぐ集約する経路も、契約と並んで重要になります。

とはいえ、利用企業が事態を知るきっかけの多くは、SaaS事業者からの連絡です。だからこそ、契約上の通知条項には次の観点が必要です。

• 通知対象の定義：「漏えい」に限定せず、「不正アクセスその他のセキュリティ事故が発生し、又はそのおそれがあると合理的に判断したとき」まで含める。法令上の報告対象が「おそれ」を含む以上、確定を待つ条項では利用企業の判断が遅れます。
• 通知期限：「速やかに」は解釈の幅が広く、事業者内部の確認が終わるまで通知されない余地を残します。「認知後○時間以内」と具体化するのが望ましいところです。24時間や72時間とする例が考えられますが、事業者にとって初動の負担は大きく、交渉では「その時点で判明している事項の第一報」に限定するなどの調整が現実的です。

2-2ログの保存・提供――なぜ法務が関心を持つのか

ログは技術部門の関心事と思われがちですが、法務にとっては次の三つの判断の基礎資料です。

1. 影響範囲の特定：どのデータに、いつから、どの程度アクセスされたか。報告・本人通知の対象を決める前提です。
2. 原因と責任の評価：事業者の契約違反の有無、自社の設定・運用に問題がなかったかを検討する材料です。
3. 証拠保全：取引先・本人との紛争や、事業者への請求を検討する場合の証拠となります。

契約では、保存対象（認証ログ、管理操作ログ、データアクセスログ等）、保存期間、提供の条件と形式を定めます。マルチテナント型SaaSでは、生ログに他の利用企業の情報が含まれるため、全面的な提供は難しいのが通常です。その場合は「自社テナントに関する抽出結果」や「調査報告書の形での提供」を代替案とします。

契約上のログ提供が難しい場合は、管理画面からの監査ログ取得機能、ログのエクスポートや外部連携機能、上位プランでの保存期間延長など、サービス機能として何が使えるかを確認し、利用企業側でも記録を保持しておくことが重要です。

2-3調査協力・継続報告――初報だけでは判断できない

初報で分かるのは、多くの場合「不正アクセスがあったらしい」という程度です。しかし利用企業が確報や本人通知を行うには、対象データの項目、対象期間、影響人数、原因、二次被害の有無、再発防止策が必要です。今回のStudioの事案でも、対象件数や二次被害の有無は続報でお知らせするとされていました。

そこで契約では、調査の進展に応じた継続報告義務と、利用企業からの合理的な質問への回答義務を定めておきます。

SaaS事業者自身がクラウド基盤や外部サービスを利用している場合、事故がさらにその先で起きることもあります。再委託先・サブプロセッサで事故が起きた場合にも、SaaS事業者が通知・協力義務を負うことを明記し、通知ルートが途切れないようにします。

なお、委託元・委託先の双方が報告義務を負う場面で、委託先が委託元に所定の事項を通知したときは、委託先の報告義務は免除されます（法第26条第1項ただし書、規則第9条）。また今回のStudioの事案では、同社が個人情報保護委員会と協議し、利用企業の選択により連名で報告する方法が示されました。こうした対応は事案ごとの調整であり、一般的な取扱いとして当然に期待できるものではない点に注意が必要です。

2-4契約で確保すべき内容と、現実の交渉可能性

大手SaaSの利用規約は定型約款として運用され、個別変更に応じないことが多いのが実情です。その場合でも、評価の対象は契約条項だけではありません。

• セキュリティホワイトペーパーやインシデント対応方針の記載
• データ処理契約（DPA）など、規約とは別に締結できる附属文書の有無
• 管理者機能（監査ログ、アクセス制御、多要素認証の強制）
• サポートプランごとの連絡体制

これらを総合して「事故時に何が手に入るか」を見積もります。それでも不足する場合は、重要情報の投入制限、データのバックアップ、代替サービスの確保など、利用方法の側でリスクを調整します。

第3章：自社がSaaSに預けている情報を把握できているか

3-1契約見直しの前提としての「情報の棚卸し」

通知条項を整えても、どのSaaSに何を預けているかが分からなければ、事故時に影響を判断できません。ただし、IT資産管理全般を法務が担うという意味ではありません。

• 情報システム部門：利用中のサービスの把握、技術的設定、ログ機能の確認
• 各利用部門：どのような情報を投入しているかの把握
• 法務部門：契約条件の確認、法的義務の整理、重要度に応じた審査基準の設定

対象は個人データに限りません。取引先から預かった秘密情報、契約交渉資料、未公表の事業情報も、漏えいすれば秘密保持義務違反や事業上の損失につながります。

3-2重要SaaSの選別と優先順位

すべてのSaaSを同じ深さで見直すのは現実的ではありません。①情報の機密性、②情報量、③事故時の影響（本人・取引先・事業継続）の三つの観点から重要SaaSを選び、そこから契約確認を始めます。新規導入時の法務審査基準も、この区分に合わせて見直すと運用しやすくなります。

3-3個人情報保護法第25条とSaaS利用の関係

SaaSに個人データを保存すれば、常に「委託」（法第27条第5項第1号）に当たり、第25条の委託先監督義務が生じるわけではありません。整理の出発点は、SaaS事業者が利用企業の個人データを「取り扱う」かどうかです。

(1) 事業者が個人データを取り扱わないこととなっている場合

個人情報保護委員会のQ&A（Q7-53）は、判断基準を「保存している電子データに個人データが含まれているか」ではなく、「クラウドサービス提供事業者が個人データを取り扱うこととなっているか」に置いています。取り扱わないこととなっている場合は個人データの提供に当たらず、第25条の監督義務も課されません。その例として、契約条項で事業者が保存された個人データを取り扱わない旨が定められ、適切にアクセス制御が行われている場合等が挙げられています。

ただし、この場合も利用企業は、自ら果たすべき安全管理措置（法第23条）の一環として、適切な安全管理措置を講じる必要があります（Q7-54）。なお、「取り扱わないこととなっている」か否かは、契約の文言だけでなく実態も踏まえて判断され得ることが、委員会の過去の注意喚起からもうかがえます。

(2) 事業者が個人データを取り扱い、委託に当たる場合

フォームの受付・保存やサポート対応のように、事業者が利用企業の個人データを取り扱う場合、それが利用目的の達成に必要な範囲内で業務を委ねるものであれば委託に当たります。このとき、利用企業には自社の安全管理措置義務（第23条）に加えて、委託先監督義務（第25条）が課されます。第25条は第23条に代わるものではありません。ガイドライン（通則編3-4-4）は、委託元が自ら講ずべき安全管理措置と同等の措置が委託先で講じられるよう、適切な委託先の選定、委託契約の締結、委託先における取扱状況の把握を求めています。本記事で扱う通知・報告・ログ提供の条項は、この「委託契約の締結」と「取扱状況の把握」を実際に機能させる手段でもあります。

(3) 事業者が個人データを取り扱うが、委託の範囲を超える場合

事業者が個人データを取り扱うからといって、当然に委託になるわけではありません。委託先は委託された業務の範囲内でのみ利用企業と一体として扱われ、それ以外に個人データを取り扱うことはできません（通則編3-6-3(1)）。利用規約上、事業者が預かったデータを自社のサービス開発・分析など自らの目的でも利用する定めがある場合は、委託の範囲を超えるものとして、第三者提供（第27条第1項）の規律を検討する必要があります。規約のデータ利用条項は、この観点からも確認しておくべき箇所です。

いずれの場合でも、事故時に何が起きたかを把握する手段を確保しておく必要性は変わりません。

第4章：SaaSの緊急停止を契約上どう扱うべきか

重大な脆弱性が見つかった場合、事業者がサービスを一時停止して修正することは、利用企業の情報を守るためにも合理的な判断です。実際、今回の一連の事案の後にも、複数のサービスが緊急メンテナンスを実施しています。

一方、従来のSLAは主に可用性を約束するもので、セキュリティ上の停止をどう扱うかは明確でないことが少なくありません。契約上は、次の点を整理しておきます。

• SLAとの関係：セキュリティ上の緊急停止を計画停止・SLA算定から除外するか、除外する場合の条件
• 停止前後の情報提供：停止の理由、影響範囲、復旧見通し、データへの影響の有無
• 免責の範囲：停止自体を正当化する条項と、停止を招いた原因（事業者側の脆弱性管理の不備等）についての責任を免除する条項は区別する
• 長期化した場合：一定期間を超える停止での解約権、データの返還・エクスポート、移行支援

強調したいのは、セキュリティ上の停止を認めることと、事業者の責任を無条件に免除することは別であるという点です。停止条項に広い免責文言が付いている場合、停止に至った原因まで免責される読み方をされないか、確認が必要です。あわせて、主要なSaaSが数日止まった場合に業務をどう継続するかを、事業継続計画（BCP）の中で確認しておくと、契約条件の重みづけも判断しやすくなります。

結論：法務が今週から始められる3つのこと

最後に、すぐに着手できる行動を三つ挙げます。

1. 1
   契約を確認する重要なSaaS契約を3件選び、事故通知・ログ提供・調査協力の条項を確認する。 規約、DPA、セキュリティ文書をあわせて読み、「事故時に何が、いつ手に入るか」を一枚にまとめます。
2. 2
   情報を把握する情報システム部門と協力して、そのSaaSに保存している重要情報と事故時の影響を把握する。 個人データの有無、件数、取引先秘密情報の有無、停止時の業務影響を確認します。
3. 3
   審査基準を改める新規SaaS導入時の契約審査チェックリストを改定する。 本記事の5項目を追加し、重要度に応じて確認の深さを変えます。

SaaSの事故を法務部門だけで防ぐことはできません。法務の役割は、関係部門と連携し、事故が起きたときに会社が必要な判断を期限内に行える状態をつくっておくことにあります。