利用中のSaaSから届く規約・プライバシーポリシー・データ処理契約の改定通知を集め、自社の利用条件への影響を判定して確認一覧にする

処理の起点を決める

Gmail で「規約改定」のラベルが付いたことを起点にします。 ラベルは Gmail のフィルタで自動で付けます。フィルタの条件は次の2つを OR でつなぎます。

• 送信元のドメイン … 台帳にあるSaaSのドメインの一覧
• 件名や本文の言葉 … 「利用規約」「プライバシーポリシー」「データ処理」「改定」「更新」「Terms」「Privacy」「DPA」「Subprocessor」

取りこぼしを、広告のメールが混ざるより重く見ます。 フィルタを広めに作るので、新機能の案内やセミナーの案内にもラベルが付きます。それは AI の判定で not_a_change として落とします（後述）。逆に、フィルタを狭くして改定通知を落とすと、後からは見つけられません。

各部署の担当者に届いたものは、共有アドレスへの転送で集めます。 転送されたメールにもフィルタが効き、ラベルが付きます。フィルタに掛からなかったものは、情報システムの担当者が手でラベルを付ければ同じ流れに乗ります。 ラベルが付いたときに動くトリガーを選んだのは、この手作業の入口を残すためです。

入力データを集める

質を決めるのは、自社の条件の列です。 たとえば次のように、SaaSごとに書きます。

この表を書くのが、この構成でいちばん大事な準備です。 条件が書かれていなければ、AIは「何とぶつかるか」を判定できません。条件の列が空のSaaSは、判定せずに needs_review に回します。

データの取得方法を決める

Zapier の Gmail のトリガーが、ラベルの付いたメールの件名、送信元、本文を取り出します。台帳はGoogle スプレッドシートの行の検索で引きます。

転送されたメールの送信元に注意してください。 転送されたメールの送信元は、転送した社員のアドレスになります。本文の中の「From:」の行から元の送信元を取り出してから台帳を引きます。 これをしないと、転送されたものがすべて「台帳に無いSaaS」になります。

リンク先の新しい規約の本文は、この段階では取りに行きません。 規約のページはサービスごとに作りが違い、一律に本文を取り出すのは難しいためです。通知の本文だけで判定できないものは insufficient_info にして、人が原文を開きます。

AIへ渡す前に整形する

1. 元の送信元の取り出し … 転送されたものは、本文から元の送信元と件名を取り出します
2. 台帳の照合 … 送信元のドメインで台帳を引きます。見つからなければ unregistered として人に回します
3. 本文の整形 … HTMLの装飾、配信停止の案内、署名、フッターの住所を落とします
4. 言語の確認 … 英文の通知もそのまま渡します。判定の結果は日本語で返させます
5. 長さの確認 … 決めた文字数を超える本文は、先頭から切り詰め、truncated の印を付けます
6. 重複の確認 … 同じSaaSから同じ件名のものが直近にあれば、二重に判定しません

2番目の unregistered は、それ自体が成果です。 台帳に無いSaaSから改定通知が届いたということは、どこかの部署が情報システムの知らないSaaSを使っているということです。判定の対象から外さず、台帳に足すかどうかを人が決めます。

5番目の truncated が付いたものは、判定が no_impact でも人の確認に回します。 切り詰めた後ろの部分に、保存場所の話が書かれているかもしれないためです。

AIに処理させる

させるのは、4つの観点ごとに、通知に何が書かれているかを判定し、自社の条件とぶつかるかを判定することです。

mention が not_mentioned のとき、impact は必ず insufficient_info にします。 通知に書かれていないことは、変わっていないことの証拠になりません。「書かれていないから影響なし」という判定を、指示で禁じます。 no_impact にできるのは、通知の中にその観点について変わらない、または自社の条件の範囲内に収まる、と読める記述があるときだけです。

ほかに、次の3つを取り出させます。

• 改定の種類 … 利用規約／プライバシーポリシー／データ処理契約／再委託先の一覧／その他／改定ではない
• 効力発生日 … 通知に書かれていれば日付。書かれていなければ空
• 同意・拒否の手続き … 「継続して利用した場合は同意したものとみなす」「期日までに申し出れば解約できる」などの記述と期日

3行目が、いちばん起きやすい失敗です。 「プライバシーポリシーを更新しました。主な変更点は問い合わせ先の変更です」という通知を渡すと、4つの観点がすべて no_impact で返ってきます。 「主な変更点」以外が変わっていないとは書かれていません。

指示内容を固定する

あなたは情報システム部で、利用中のSaaSから届いた規約の改定通知を
点検する立場です。通知の本文だけを見て判定してください。
推測で補わないでください。

【見る観点】
1. data_location ...... データの保存場所（国・地域、データセンター）
2. ai_training ........ 預けたデータを事業者のAIの学習に使うか
3. subprocessing ...... 再委託、再委託先の追加・変更
4. pricing_termination  料金、自動更新、解約の条件と予告期間

【mention の選び方】
- changed ........ その観点について変更があると書かれている
- not_mentioned .. その観点について何も書かれていない
- unclear ........ 触れているが、何がどう変わるか読み取れない

【impact の選び方】
- conflict .......... 変更後の内容が、自社の条件に反する
- needs_review ...... 変更があり、自社の条件に反するかどうか決められない
- no_impact ......... 変わらない、または自社の条件の範囲内と読める記述がある
- insufficient_info . 通知の本文からは判定できない

【厳守事項】
- mention が not_mentioned なら、impact は必ず insufficient_info にしてください。
  書かれていないことを、変わっていないこととして扱わないでください。
- 「主な変更点」「主な改定内容」と書かれていても、
  そこに挙がっていない観点を no_impact にしないでください。
- 迷ったときに no_impact を選ばないでください。
- 自社の条件は、与えられた文言のとおりに使ってください。
  緩めたり厳しくしたりしないでください。
- 効力発生日は、本文に書かれている日付だけを入れてください。
  書かれていなければ空にしてください。
- evidence には、判定の根拠にした本文の文をそのまま写してください。
  英文の場合は原文のまま写し、reason を日本語で書いてください。
- 同意すべきか、解約すべきか、法的に有効かは書かないでください。
- 改定の通知でない場合（新機能の案内、セミナーの案内など）は、
  doc_type を not_a_change にし、観点の判定をしないでください。

【サービス名】{service_name}
【預けているデータの区分】{data_class}
【自社の条件】{our_conditions}
【通知の本文】{notice_body}

「主な変更点に挙がっていない観点を no_impact にしない」を明記しないと、要約を信じます。 通知の本文に「主な変更点」の箇条書きがあると、モデルはそれを改定の全体として読みます。事業者が要点として挙げなかったことを、自社にとっての要点ではないと決めつけないための一文です。

出力形式を固定する

AI by Zapier の出力フィールドで、次の項目を定義します。 出力フィールドを定義しないと、ひとまとまりの文章で返ってきます。項目ごとに型を決め、必ず返す項目には印を付けます。

{
  "service_name": "",
  "doc_type": "terms | privacy_policy | dpa | subprocessor_list | other | not_a_change",
  "effective_date": "",
  "consent_mechanism": "",
  "opt_out_deadline": "",
  "checks": {
    "data_location":       { "mention": "", "impact": "", "evidence": "", "reason": "" },
    "ai_training":         { "mention": "", "impact": "", "evidence": "", "reason": "" },
    "subprocessing":       { "mention": "", "impact": "", "evidence": "", "reason": "" },
    "pricing_termination": { "mention": "", "impact": "", "evidence": "", "reason": "" }
  }
}

出力フィールドは入れ子にしにくいので、実際には data_location_mention、data_location_impact のように平らな項目名で16項目を並べます。

1つ目の理由は、回し先を規則で決められることです。 Paths by Zapier で、次のように分岐させます。

Paths は条件ごとに分岐を作り、1つの分岐のグループに最大10本まで置け、どの条件にも当たらないときに走る予備の分岐も1本置けるとされています。予備の分岐は needs_review に回します。 どの条件にも当たらないのは、出力が崩れたときだからです。

注意点が1つあります。 Paths では、条件が当たる分岐が複数あると、すべてが左から順に走るとされています。上の表の条件は、重ならないように書きます。重なると、同じ通知が確認一覧に2行入ります。

2つ目は、opt_out_deadline で期日の漏れが防げることです。 確認一覧を期日の近い順に並べ、期日の2週間前になっても判断の欄が空のものを、Slack で知らせます。

システムへ連携する

台帳へは書き込みません。 unregistered のSaaSを台帳に足すか、自社の条件を書き換えるかは、人が決めます。判定の結果で台帳の物差しが変わると、次の判定の根拠が分からなくなるためです。

SaaSの管理画面での同意や解約の操作も、この構成ではしません。 判定から先の操作は、法務の判断を受けて管理者が行います。

人が確認する

人が原文を開くのは、conflict と insufficient_info のものです。 needs_review は、根拠の文を読んで足りれば原文を開きません。no_impact は週に1回、一覧で流し見ます。

1. conflict を先に見る … 情報システムの担当者が原文の該当箇所を確かめ、法務へ回します
2. 法務が判断する … 同意して使い続けるか、利用部署に注意を出すか、解約や別のサービスへの移行を検討するかを決め、確認一覧の判断の欄に書きます
3. insufficient_info の原文を読む … リンク先の新しい規約を開き、4つの観点を確かめます。確かめた結果は、確認一覧の同じ行に書き足します
4. unregistered を台帳に足すかを決める … 利用している部署を確かめ、台帳に足すなら自社の条件まで書きます

3番目を省かないでください。 insufficient_info は、AIが判定をあきらめたのではなく、通知だけでは判定できないことを判定した結果です。 ここを読まないなら、この構成を入れる前と何も変わりません。

目標は、40件をならして1件9分です。 原文を開くのは半分前後という想定です。insufficient_info が多すぎる月は、通知の本文が短いSaaSが多いということで、そのSaaSは通知ではなく規約のページそのものを定期的に見る運用に切り替えます。

例外に対処する

記録を残す

• 改定通知のメール（Gmail に残る。ラベルで検索できる）
• 確認一覧の1行：受信日、サービス名、改定の種類、効力発生日、期日、4つの観点の判定、根拠の文、回し先
• 判定のときに使った自社の条件の文言
• 人の確認の結果：原文を読んだ人と日付、法務の判断、利用部署への連絡
• unregistered から台帳に足したSaaSの記録

3つ目で「そのときの条件の文言」を残すのは、条件が後から変わるためです。 自社の方針で「AI学習への利用」の条件を厳しくすると、過去の no_impact の意味が変わります。当時の物差しが残っていないと、どこまで見直せばよいかが決まりません。