存在しないAIオプトアウト:17のSaaSプラットフォームを調査してわかったこと

あなたのビジネスが接続しているすべてのSaaSプラットフォームは、今この瞬間も、あなたのコンテンツを他社のAIモデルの学習に使うかどうかを静かに決定しています。私たちは8200.devのコネクタライブラリにある17のプラットフォームすべてを調査し、それぞれが実際にどのように扱っているのかを確認しました——管理者用のトグルスイッチが見つかることを期待していましたが、実際にはほとんど見つかりませんでした。

以下がその調査結果です。Slackは初期設定ですべてのワークスペースを非生成モデルの学習対象に含めており、管理コンソールのどこにもトグルは存在しません。オプトアウトするには、ワークスペースのオーナーが特定の件名を付けて[email protected]にメールを送る必要があり、後から確認できる記録はどこにも残りません。Salesforceには実際に設定項目がありますが、それはSetup内の目立たない場所にあるEinstein GPTのトグルで、ほとんどの管理者はそれを探すべきだと知りません——さらに、エディションによってはサポートケースを起こさないとそこにたどり着けないこともあります。Zendeskの場合はサポートチケットを起こすのみで、それ以上の方法はありません。IntercomのFin AIにはワークスペース単位のオプトアウトがありますが、それはUI上にのみ存在し、APIには存在しません——管理コンソールの外側にいる人間には、それが実際に設定されているかどうかを確認するすべがありません。

Dropboxは最も興味深いケースです。米国のアカウントは初期設定でサードパーティのAI機能にオプトインされていますが、EU、英国、カナダのアカウントは初期設定でオプトアウトされています。同じ製品、同じ会社でありながら、アカウントの登録地域によって初期設定が正反対になっており、ほとんどのチームはどちらが自分たちに適用されているのかを確認したことがありません。WhatsApp Businessも地域によって扱いが異なります。EU、英国、ブラジルでは異議申し立てフォームが用意されていますが、それ以外の地域には、そもそも操作できるレバー自体が存在しません。

一方で、コンテンツを一切学習に利用しないと契約上明確に約束しているプラットフォームも本当に存在します——それは設定項目ではなく、契約上のコミットメントです。Google Workspace、Microsoft 365、Box、Notion、GCPはすべてこれに該当します。これは安心材料ではありますが、自社の管理コンソールをクリックして回るだけでは確認できない事柄でもあります——ほとんどの人が1ページ目より先を読まないデータ処理契約書に埋め込まれたこのコミットメントについて、あなたはベンダーの言葉を信じるしかないのです。

これら全体を通じて見えてくるパターンは、JiraといくつかのAI機能関連のトグル(GitHub Copilotの公開コードマッチング設定、GCP Vertexの組織ポリシー)を除けば、APIに問い合わせて明確な答えを得られる場所がほとんどないということです。だからこそ、これはプラットフォームごとに、手作業で、一度きちんと確認する必要があります——そして新しいプラットフォームを接続するたびに自動的にフラグを立てる仕組みが必要なのです。チームの誰かがすでに細かい規約を読んでくれていると信じるのではなく。

「誰かが確認すべき」がひそかに機能不全に陥る理由

この問題がくすぶり続けるのは、怠慢が原因ではありません。通常の統制手法——担当者を割り当て、確認するよう指示する——には、そもそも向ける先がないからです。

もう一度上記のリストを見直してみると、どの項目にも共通点があることに気づきます。その方針は、ダッシュボードでは見えない場所に存在しているのです。契約条項の中に。登録時に設定される地域ごとの初期設定の中に。前回の調達更新時に変わったプラン階層の中に。書き送らなければならないメールアドレスの中に。これらのプラットフォームのどれをとっても、セキュリティチームが本当に知りたい問い——*自社は今この瞬間、学習データを提供しているのか、そしてそれは意図的に決定されたことなのか?*——に答えてくれる単一の画面は存在しません。

そのため、確認作業は先送りされ、やがて忘れられ、最終的には引き継がれていきます。初期設定は、放置されることで勝ち残ります。そしてその初期設定は、あなたのデータ処理義務のためではなく、ベンダー自身のAIロードマップを最適化するために書かれたものです。これは、Atlassian Jiraの8月17日変更で何が変わるのかで1つのプラットフォームについて取り上げたのと同じ構図です——ただし、今回は1つのプラットフォームだけの話ではありません。接続されているすべてのツールが、それぞれ独自のタイミングで、独自の隠れた場所で、独自のバージョンの決定を下しているのです。

これは興味本位の話ではなく、コンプライアンス上の問題です

もし御社がSOC 2レポートを保有していたり、ISO 27001の取得を目指していたり、GDPRのもとで個人データを処理していたりするなら、データの学習利用は、すでに負っている義務に直結する問題となります。

データ処理契約(DPA)は、御社のデータがどのような目的で利用されうるかを記述しています。サードパーティのAIモデルを学習させることは、1つの目的です。もし顧客とのDPAで「データはサービス提供のために利用される」と定めているのに、接続している一部のプラットフォームがその同じデータをひそかにモデル学習に投入しているとしたら、下流で約束したことと上流で許可していることとの間のギャップを埋めるのは御社の責任であり、ベンダーの責任ではありません。監査人はすでにこの点について直接尋ね始めており、たいていは「サブプロセッサのいずれかが御社のデータでAIを学習させていないか、それをどう把握しているか」といった形の質問です。防御可能な答えには2つの要素が必要です。方針(どのプラットフォームがデータを提供しており、どれが契約上除外されているか)と、決定の記録(誰が、いつレビューし、何を選んだか)です。「確認したことがない」だけは、完全に失格となる唯一の回答です。レビュアーが今何を求めているかについては、2026年に監査人がAIガバナンスに実際に求めるもので取り上げました。データの学習利用は、まさにそのレビューにおいて標準的な確認項目になりつつあります。

今すぐ実施する価値のある一回限りの監査

朗報は、これがガバナンス項目の中でも珍しく、対策が本当に安価に済む類のものだということです。アーキテクチャの再設計は一切不要です。必要なのは、設定項目を見つけ、意図を持って決定し、その決定を記録に残すことだけです。具体的には次の通りです。

1. 対象範囲を棚卸しする。 御社のコンテンツやメタデータが実際に存在するすべてのSaaSプラットフォームをリストアップします。顧客データ、規制対象データ、NDAの対象となるものが含まれていれば、それは対象範囲内です——今週メールを送ってきたツールだけではありません。
2. 各プラットフォームの方針を確認する。 設定ページの場合もあれば、サポートチケットの場合、メールでのオプトアウトの場合、あるいは統制手段が一切ない契約条項の場合もあります。それがどこにあるかを記録します。
3. プラン階層を確認する。 複数のプラットフォームでは、方針がプラン階層に依存します——GitHubはBusinessおよびEnterpriseのデータを学習対象から除外していますが、下位プランはより広範な規約の対象となり、プランの移行によって方針が知らぬ間に切り替わることがあります。
4. 意図を持って決定する。 オプトインすること自体は正当な選択でありえます。優れたAI機能は実際に利益をもたらします。問題となる失敗の形は「データが提供されること」自体ではなく、「誰も決定していないのにデータが提供されること」です。機微な情報は除外し、それがあなたの判断であれば、残りはそのまま進めて構いません。
5. 記録に残し、定期的に再確認する。 日付入りの記録があれば、静かな初期設定はガバナンスの証跡へと変わります。そして、ベンダーは初期設定を頻繁に変更するため、一度レビューした方針は「管理されている方針」とは言えません。

このリストを率直に表現するなら、*繰り返し発生し、複数プラットフォームにまたがり、地味な作業*です——つまり、人間の記憶に頼っていると必ず崩れていくタイプの統制です。

自社でこの確認を実施した結果

2026年7月31日、私たちは自社のAtlassian組織の管理コンソールを開き、上記の5つのステップを実際に実行しました。この結果を正確に報告することには意味があります。両面の結果が出たからです。

組織レベルの制御は、すでにオフになっていました。Atlassian Administration → Security → Data contributionでは、製品ごとではなく組織全体で1つのON/OFF選択肢が用意されており、私たちの設定はOffで、含めるリストも空でした。つまり、選択的に再度オプトインされている項目は何もありませんでした。修正すべき点はありません。これは、良い初期設定、あるいは以前になされた良い決定の姿と言えます。

しかし、その制御項目の真下には、こう印字された一文があります。*「メタデータは常に提供されます。」* 私たちが設定したスイッチが管理するのは、アプリ内コンテンツ——人々がチケットやページに書き込む内容——です。メタデータはその対象外であり、私たちのプランでは、メタデータに関する制御項目自体が一切用意されていません。私たちのJiraサブスクリプションはPremiumであり、メタデータの完全なオプトアウトはCloud Enterpriseの機能です。すべての管理画面に表示されるバナーには、この変更が発効する日付——2026年8月17日——が記されています。

つまり、有料プランですでに意図的な選択を行っていた組織であっても、完全にオプトアウトすることはできなかったのです。そしてそれを知る唯一の方法は、特に見直す理由のなかった設定ページに書かれた1行の本文を読むことでした。一方、BitbucketとTrelloは別途課金される仕組みで、このページの対象外に完全に位置しています。それらの方針がどうなっているかは、別の画面での別の確認事項です。

これはAtlassianを批判するものでは全くありません。むしろAtlassianは少なくとも制御項目を表に出し、制限事項を明確に述べ、日付を公表しています。これはこの記事の主張を、私たち自身に対して実証したものです。決定とその限界は、どのダッシュボードにも表示されない場所に存在しており、「オフにした」ことは「提供していない」ことと同じではないのです。

8200.devがこれをどう自動的に可視化するか

8200.devは現在、接続されたすべてのプラットフォームについてAI学習方針に関する所見を提示します。Slack、Dropbox、Salesforce、GitHub、その他対応するプラットフォームのいずれかを接続すると、スキャンは共有設定や権限に関する所見と並んで、そのベンダーが初期設定でデータをAI学習に利用しているかどうか、オプトアウトや契約上の保証がどこにあるか、その方針が最後にいつ確認されたかを教えてくれます。初期設定でオプトインとなっているプラットフォームは、判断を要する所見として表示され、契約上安全であることが確認されたプラットフォームは、監査人に提示できる証明として表示されます。

隣接する軸でAPIから読み取り可能なポリシーを公開しているプラットフォームについては、リアルタイムで確認を行います。GitHubコネクタは組織のCopilot公開コードマッチング設定を読み取り、GCPコネクタはVertex AIが組織ポリシーによる制約なしで実行されている場合にフラグを立てます。すべての所見には、段階的な是正手順のプレイブックが付属しており、チェック項目の全カタログは機能ページに掲載されています。

ここでの論点は、AI機能自体が危険だということではありません——多くの機能は有効にする価値があります。論点は、御社がすでに利用しているすべてのプラットフォームにおいて、データの学習利用は初期設定ではなく、意図的な決定であるべきだということです。手動で記憶しておくのではなく、自動的に可視化されるほうがよいとお考えであれば、プランと料金をご覧いただき、最初のプラットフォームを数分で接続してみてください。