Atlassianは貴社のJiraデータでAIを学習させているのか?8月17日に変わること

Jira、Confluence、またはJira Service Managementのサイトを管理されている方には、Atlassianからすでに「データ提供(data contribution)」に関する新しい設定について案内メールが届いているかもしれません。ここでは、それが実際に何を意味するのか、そして2026年8月17日までに何をすべきかを解説します。

変更点: Atlassianは、Atlassian Administration(Security → Data contribution)内に組織レベルの制御機能を展開します。これは、貴社のメタデータやアプリ内コンテンツが、Jira、Confluence、JSM、および連携するPlatformアプリ全体でAtlassianのAIモデルの学習やAI機能の改善に利用されるかどうかを管理するものです。2026年8月17日以降、Atlassianはこれらの設定内容に従ってデータの利用を開始します。設定は貴社が構成したものであれ、デフォルトのままであれ、それに基づいて運用されます。

多くの管理者が見落としがちな点: この件に関する制御権は、契約しているプランの階層によって完全に決まります。メタデータの提供を完全にオプトアウトできるのは、Cloud Enterpriseの顧客のみです。それ以外のすべての階層——Free、Standard、Premium——では、メタデータが自動的に提供され、これをオフに切り替える方法はありません。プランの階層にかかわらず通常制御できるのは、アプリ内コンテンツです。設定自体を完全にオフにはできなくても、特定のConfluenceスペース、Jiraプロジェクト、Teamwork Graphコネクタをデータ提供の対象から除外することは可能です。

実際に行うべきこと: Atlassian Administration → Security → Data contributionにアクセスし、すでに何が設定されているかを確認してください。組織の最上位で有効なプランを確認します(これによってデフォルト設定が決まります——組織内のどこか一箇所にでもEnterpriseライセンスが存在すれば、組織全体の計算が変わります)。組織が顧客データ、規制対象情報、またはデータ処理契約の対象となる情報を扱っている場合は、デフォルトのまま引き継ぐのではなく、特定のプロジェクトやスペースを除外すべきかどうかを意図的に判断してください。

これは1つのプラットフォームにおける1つの設定にすぎません。もし貴社がSlack、Notion、GitHub、Salesforce、その他数多くの連携SaaSツールも運用しているなら、それぞれのツールが静かに、同じ種類の判断を貴社に代わって下しています——目に見えるトグルがあるものもあれば、Slackの非生成的ML学習のようにトグル自体が存在せず、メールでのオプトアウトしかできないものもあります。実質的な設定、実質的な期限、実質的な影響が、誰も確認担当に割り当てられていない管理画面の奥に埋もれている——このパターンこそ、8200.devのコネクタが自動的に可視化するために作られたものです。しかも今週たまたまメールを送ってきた1つのプラットフォームだけでなく、貴社が連携しているすべてのプラットフォームにわたって対応します。

誰にも割り当てられていなかった判断

Atlassianの話から少し離れて、この問題の全体像を見てみましょう。同じ構造が至る所で繰り返されているからです。

AI機能を構築するすべてのSaaSベンダーは、同じ問いに直面しています。「どの顧客データからモデルを学習させてよいのか」という問いです。各ベンダーはこれに異なる形で答え、異なる場所でその答えを公表し、顧客に異なる程度の制御権を与えています。

• Slackは、デフォルトで顧客のメッセージやコンテンツを、プラットフォームレベルの非生成的な機械学習モデル(検索ランキング、レコメンデーションなど)の学習に利用します。ワークスペース設定内には管理者用のトグルはどこにも存在せず、オプトアウトするにはワークスペースオーナーがSlackのフィードバック用アドレスにメールで依頼する必要があります。
• Dropboxは「サードパーティAI」という設定を公開していますが、そのデフォルト値はアカウントの所在地によって異なります。米国のアカウントはデフォルトでオン、EU、英国、カナダではデフォルトでオフです。Dropboxの同一プランを契約している2つの組織が、正反対の設定になっていても、そのことに気づかない場合があります。
• GitHubは、プランによって線引きを行っています。BusinessおよびEnterpriseの顧客データは契約上モデル学習から除外される一方、下位プランはより広範な製品規約の対象となります。同じ組織であっても、プランを移行することで設定の実態が黙って変わる可能性があります。
• Salesforce、Zendesk、Intercomはそれぞれ独自のデフォルト設定と独自のオプトアウト方法を持っています——Setupページであったり、サポートチケットであったり、ワークスペース設定であったりします。
• Google Workspace、Microsoft 365、Notion、Boxはこれとは対照的な立場です。これらは契約上、顧客コンテンツをモデル学習に利用しないことを約束しているため、そもそもトグルが不要です。これは本質的に異なる立場と言えますが、それでも貴社はそのことを把握し、監査人に対して根拠を示せる状態にしておく必要があります。

これらすべてに共通する点にご注目ください。「現在、自組織は学習用データを提供しているか」を問い合わせられるAPIを公開しているベンダーは1つもありません。 この立場は契約書の中に、メールの中に、地域ごとのデフォルト設定の中に、プランの階層の中に存在しています。それは実在し、実質的な影響をもたらすものでありながら、貴社のセキュリティチームが目にするどのダッシュボードにも映らないのです。

「誰かが確認するはずだ」という前提が統制策として機能しない理由はここにあります。確認すべき場所自体が存在しないのです。判断はベンダーが選んだ内容にそのまま委ねられ、そしてベンダーは自らの都合でその選択を行っています。

これがコンプライアンスにとって意味すること

貴社がSOC 2レポートを保有していたり、ISO 27001の取得を目指していたり、GDPRの下で個人データを処理していたりする場合、データ提供に関するこの問いは些末な話ではなく、既存の義務の中に直接組み込まれるものです。

データ処理契約(DPA)は、処理者が貴社のデータを利用してよい目的を定めています。ベンダーが貴社のコンテンツでAIモデルを学習させることは、それ自体が1つの*目的*です。もし顧客とのDPAで「データはサービス提供のために利用される」と約束しているのに、連携している一部のプラットフォームが同じデータを静かにモデル学習に流用しているとすれば、下流で約束した内容と上流で許可している内容との間に生じるギャップを埋める責任は、貴社側にあり、ベンダー側にはありません。

監査人はすでにこの点を直接的に問い始めています。ベンダーリスクに関する質問票には、「サブプロセッサのいずれかが貴社のデータをAIモデルの学習に利用していないか、そしてそれをどのように把握しているか」といった趣旨の質問が現れます。防御可能な回答には2つの要素が必要です。1つは*立場*(どのプラットフォームがデータを提供し、どのプラットフォームが契約上除外されているか)、もう1つは*判断の記録*(誰がいつレビューし、何を選択したか)です。「一度も確認していない」という回答だけが唯一の誤りです。AIガバナンスに関して監査人が今後何を求めるかについては、2026年にAIガバナンスで監査人が実際に求めるもので全般的に取り上げていますが、データ提供の扱いはまさにそのレビューにおける標準的なチェック項目になりつつあります。

朗報もあります。これは、修正コストが本当に低いという点で、コンプライアンス項目の中でも稀な部類に入ります。アーキテクチャを作り直す必要はありません。必要なのは、設定を*見つけ*、目的を持って*判断し*、その*判断を記録すること*だけです。

8月17日に向けた管理者向けチェックリスト

Atlassianの期限までに実施すべき具体的な手順を、他のすべてのプラットフォームにも適用できるよう一般化した形で示します。

1. 対象範囲を棚卸しする。 貴社のコンテンツやメタデータが実際に存在するSaaSプラットフォームを、Atlassianに限らずすべて洗い出してください。顧客データ、規制対象データ、NDAの対象となる情報が含まれていれば、それは対象範囲に入ります。
2. 各プラットフォームのデータ提供に関する立場を確認する。 Atlassianの場合はAdministration → Security → Data contributionです。他のプラットフォームでは、設定ページであったり、サポートチケットであったり、メールによるオプトアウトであったり、あるいは制御手段が一切ない契約条項であったりします。
3. プランの階層を確認する。 立場がプランに依存するプラットフォームでは、契約中のプランを確認してください。Atlassianでは、組織内で有効な最上位プランが、組織内すべてのデフォルト設定を決定します。GitHubでは、プランの階層によって契約上の除外が適用されるかどうかが決まります。
4. 意図を持って判断する。 オプトインを選ぶことは正当な選択肢です——より優れたAI機能という実質的な利点があります。問題となるのは提供そのものではなく、*誰も判断していない*まま提供が行われることです。機微な情報を含むプロジェクトやスペースは除外した上で、それ以外については判断に基づき許容するという選択肢もあります。
5. 判断を記録する。 日付入りのメモ——誰がレビューし、何を設定し、なぜそうしたか——があれば、静かなデフォルト設定を監査人に提示できるガバナンスの証拠に変えることができます。
6. 定期的に再確認する。 ベンダーはデフォルト設定を変更し、AI機能を追加し、設定項目を移動させます。2026年に一度レビューした立場は、2027年に管理されている立場とは限りません。

このリストが「誰かが責任を持って担当すべき仕事」に見えるとすれば、それはその通りです。この問題の正直な実態は、*繰り返し発生し、複数プラットフォームにまたがり、地味である*という点にあります。まさに、人の記憶に依存すると静かに形骸化していく類の統制策です。

8200.devがこれを自動的に可視化する仕組み

8200.devは現在、連携しているすべてのプラットフォームについて、AI学習に関する立場の検出結果を提示します。Jira、Slack、Dropbox、GitHub、Salesforce、その他対応しているプラットフォームを連携すると、スキャンは共有設定や権限に関する検出結果と並んで、そのベンダーがデフォルトで貴社のデータをAI学習に利用しているか、オプトアウトや契約上の保証がどこにあるか、その立場が最後にいつ確認されたかを提示します。デフォルトでオプトインとなっているプラットフォームは判断を求める検出結果として、契約上安全なプラットフォームは監査人に提示できる証明として、それぞれ表示されます。

プラットフォームが別の軸でAPIから読み取り可能なAIポリシーを公開している場合は、その内容をライブで確認します。GitHubコネクタは組織のCopilotパブリックコードマッチングポリシーを読み取り、GCPコネクタはVertex AIが組織のポリシーによる制約を受けずに稼働していないかを確認します。すべての検出結果には段階的な修復手順が付属しており、チェック機能の全カタログは機能ページでご覧いただけます。

重要なのは、AI機能自体が危険だということではありません。重要なのは、*データ提供はデフォルトではなく、判断であるべきだ*ということです——8月17日を控えたAtlassianにおいても、貴社がすでに運用している他のすべてのプラットフォームにおいても同様です。この判断を手作業で記憶する代わりに自動的に可視化したいとお考えでしたら、料金プランを見るから、数分で最初のプラットフォームを連携できます。