データを渡すことは目的を渡すことではない——ドコモ・Google・AIクローラーが示す「用途の境界」

企業がデータを受け取る場面は、以前より滑らかになりました。通信プランを申し込めば特典案内へ連携され、クラウドへ画像を置けば端末をまたいで開け、ウェブへ記事を出せば検索エンジンが見つけてくれます。生成AIも、同じデータを要約、分類、検索、学習、エージェント実行へ利用します。

ところが、便利な入口が一つになっても、利用目的まで一つにしてよいわけではありません。電話番号を契約に使うことと外部企業へ渡すこと、画像を保管することと規約違反を自動判定すること、記事を検索結果へ載せることとAI学習へ使うことは、それぞれ別の行為です。

2026年9月、NTTドコモは34万4213回線の電話番号と契約プラン名を、必要な同意を得ないままアマゾンジャパンへ提供していたと公表しました。同じ週には、日本で適法とされる漫画原稿をGoogleドライブへ保存した漫画家のアカウントが停止され、Gmailまで使えなくなった事例が詳しく報じられました。海外ではCloudflareが、検索への掲載を保ちながらAI学習だけを拒める新しい制御を発表しています。

三件は、漏えい、表現規制、ウェブ巡回という別々の話に見えます。しかし共通しているのは、「データを渡した」という一回の操作から、複数の目的と結果が自動的に連結されていることです。日本企業が次に整えるべきなのは、巨大な同意文をもう一枚増やすことではありません。取得、利用、判定、結果、救済を目的ごとに切り分け、途中の変更を追える仕組みです。

結論——一つのデータに一つの許可ではなく、用途ごとの五つの記録が必要です

データガバナンスは、個人情報か否か、社外秘か否かという分類だけでは足りなくなりました。同じデータでも、本人へのサービス提供、提携先への共有、不正検知、AI学習、検索表示、広告配信では、期待される条件と許容できる不利益が違うからです。

最低限、次の五つを一つの用途番号で結びます。

記録	残す内容	防ぎたい問題
取得	誰から、何を、いつ受け取ったか	入口の不明確さ
目的	何のために、誰が、いつまで使うか	同意の使い回し
判定	人・規則・AIのどれが何を決めたか	自動判定の不可視化
結果	共有、制限、削除、学習など何が起きたか	一操作からの影響連鎖
救済	通知、異議申立て、復旧、消去の経路	誤りが戻せない状態

重要なのは、五つを利用規約の文章だけへ閉じないことです。画面の同意項目が削除されたら目的記録と実際のデータ送信を機械的に照合します。自動判定でアカウント全体を止めるなら、対象ファイル、判定根拠、影響する別サービス、再審査先を結果記録へ残します。クローラーが検索と学習を兼ねるなら、サイト運営者が目的別に選び、実際の巡回を確認できるようにします。

以前の記事では、AIの悪用とモデル自身の越境を分ける事故台帳を整理しました。今回の焦点は事故が起きた後だけではありません。正常系に見える共有、保管、検索の時点から、用途が静かに増えることを防ぐ設計です。

ドコモの事例が示したのは、同意文より変更管理の弱点です

ITmedia NEWSの報道によると、NTTドコモは2026年4月21日から8月20日までの一部申し込みで、34万4213回線の電話番号と契約プラン名を、同意を得ないままアマゾンジャパンへ提供していました。対象はドコモ MAX、ドコモ ポイ活 MAX、ドコモ ポイ活 20、ドコモ miniの一部です。

連携の目的は、各プランに対応するAmazonプライム割引特典の案内でした。ドコモは1月20日からデータ提供許諾を取得していましたが、2月25日の同意事項見直しで、削除すべきでない項目を誤って削除したと説明しています。その後4月21日にデータ提供を開始し、8月18日に欠落を検知、20日に改修しました。アマゾンは連携情報を利用しておらず、9月12日に消去を完了したことをドコモが確認したとされています。

ここで「担当者が注意すればよかった」と結論づけると、次の事故を防げません。問題は、同意画面、送信処理、提携契約、消去確認が別々に管理され、同意項目が消えても送信開始を止められなかったことです。文章のレビューとデータ経路のレビューが分離していました。

目的別の設計なら、次の不整合を自動で止められます。

1. 外部提供の送信先には、有効な同意項目の識別子を必須にします。
2. 同意文や画面部品を削除するとき、依存する送信処理と提携機能を一覧表示します。
3. 送信開始前に、対象者数、データ項目、目的、保持期間を試験環境で照合します。
4. 同意率が急にゼロ、または取得ログがない状態で送信件数だけ増えたら自動停止します。
5. 提携先で未利用だったとしても、送信の事実、削除証跡、本人への説明を別々に残します。

同意は一度取れば終わる印鑑ではありません。画面、バックエンド、提携先、顧客向け説明が同じ版を参照し続けているかを監視する運用です。AIが規約の差分を要約しても、送信処理との対応関係を検査しなければ、文章だけ正しく、実装だけ古い状態が残ります。

AI時代の本人・意思・承認・実行を分けた記事でも、本人確認だけでは取引の正当性を説明できないと述べました。データ利用でも同じです。本人が契約した事実と、特定目的の外部提供へ同意した事実は分けて記録する必要があります。

クラウドへ置く許可と、サービス全体を止める権限は別です

もう一つの事例では、データの「保管」が「検査」と「アカウント停止」へつながりました。ITmedia NEWSの記事は、漫画家が過去の原稿をGoogleドライブへアップロードしている途中で警告を受け、再審査請求も退けられ、Googleアカウントが停止された経緯を紹介しています。保存していた原稿は日本では適法とされる一方、Googleのポリシーは児童の性的虐待素材の対象に漫画を含めています。

ここでは、日本法と民間サービスの利用規約が同じではないことが出発点です。日本から日本の作品を保存していても、サービス側が定めた広い基準で利用可否を判定します。クラウドへ預けたデータが通信中や保管中に暗号化されていても、事業者が鍵を管理する方式なら、事業者側の検査は技術的に可能です。

記事は、通信経路の暗号化、事業者が鍵を持つ保管時暗号化、利用者だけが鍵を持つエンド・ツー・エンド暗号化を区別しています。「暗号化済み」という一語だけでは、誰が内容を読めるか、何のために検査できるかまでは分かりません。利用者に必要なのは、暗号方式の名称より、検査主体、検査目的、判定後の影響範囲です。

自動検査にも証拠の境界があります。同記事は、大規模な画像分類で誤りが起こり得る参考として、Amazonが2025年に公開ウェブ上の画像や動画を学習前に走査し、約112万件を疑わしい素材として通報したものの、人手確認では99.6％が誤検知だったという別文脈の公表値を紹介しています。これはGoogleドライブの検出精度を示す数字ではなく、今回の停止が誤検知だったと直接証明するものでもありません。それでも、大量の自動分類で低い発生率の対象を探すと、誤判定の絶対数が大きくなり得る点は示します。

だからこそ、判定精度だけでなく結果の段階を設計します。

段階	可能な処置	必要な説明
検知	対象ファイルの一時保留	検知した対象と基準
確認	独立した再分類、人による限定確認	追加で見た情報と判断者
制限	共有停止、該当機能のみ停止	影響範囲と期間
重大処置	アカウント停止、外部通報	根拠、法域、他サービスへの波及
救済	異議申立て、データ返却、復旧	期限、窓口、再判定方法

ドライブ上の一ファイルに関する判定が、Gmailや認証を含むアカウント全体へ広がるなら、その連鎖自体が重要な製品仕様です。利用者はクラウド容量だけでなく、誤判定時に何を同時に失うかを選ぶことになります。企業利用なら、業務メール、共同文書、ログイン、バックアップを一つのアカウント障害へ集約しすぎていないかを確認すべきです。

検索に載ることとAI学習へ使われることも、同じ許可ではありません

ウェブ公開でも、入口は同じなのに目的が違う問題があります。サイト運営者は人に記事を見つけてもらうため、検索クローラーを受け入れます。一方、同じ取得データが生成AIの学習へ使われることには、別の判断をしたい場合があります。

Cloudflareの発表は、検索とAI学習を一つのクローラーで行う「mixed-use crawler」を問題の中心に置いています。従来はクローラーを拒否すると検索への掲載まで失い、許可すると学習も受け入れざるを得ない場合がありました。Cloudflareは、検索への発見可能性を維持しながらAI学習を拒否する設定と、目的を分ける事業者を示す「Accountable」という区分を発表しました。

同社の集計では、検索ボットをブロックするサイトは1％未満である一方、学習を止める仕組みを有効にするサイトは17％です。この差は、サイト運営者が「取得されること」全体を嫌っているのではなく、目的によって許可を分けたいことを示します。

Cloudflareが挙げる条件には、AI学習を拒否する仕組み、AI要約を拒否する仕組み、学習へ提供されたページをURL単位で確認できること、学習拒否が従来検索へ不利益を与えないことが含まれます。同社は発表時点でApple、Google、Microsoftが条件を満たす、または期限付きで対応を約束したと説明しています。これはCloudflareによる区分であり、各社の全サービスが同じ条件で動くことを意味しません。サイト側では、自分の設定と実際の巡回記録を確認する必要があります。

この考え方は、ウェブ以外にも広げられます。

• 社内文書を検索可能にしても、モデルの再学習へ使うとは限りません。
• 顧客対応を要約しても、広告対象の推定へ使うとは限りません。
• 会議音声を文字起こししても、話者識別モデルの改善へ使うとは限りません。
• 防犯映像を異常検知しても、従業員評価へ使うとは限りません。
• 購買履歴を特典提供へ使っても、信用評価へ使うとは限りません。

「AI利用に同意」という大きな箱では粗すぎます。検索、要約、推論、学習、評価、広告、外部共有を別の目的として選び、後から利用状況を見られることが必要です。

ブラウザ内AIは、用途の境界を利用者側へ戻せるか

用途を分けるには、データをどこへ送り、誰のモデルを使うかを選べる入口も重要です。MistralとMozillaの発表は、ブラウザへ開放性、プライバシー、多言語対応を持つAIを導入する提携を説明しています。両社は、地域の言語、方言、文化的文脈へ調整した仕組みと、単一企業の一方向の経路へ利用者を閉じ込めない選択肢を掲げています。

現時点の発表だけで、閲覧データが常に端末内で処理される、どの情報も学習へ使われないと断定することはできません。大切なのは「プライベート」という言葉を結論にせず、実装ごとに確認することです。

確認項目は次の通りです。

• 開いているページの本文、URL、履歴、入力内容のどこまでをAIへ渡しますか。
• 処理は端末内、ブラウザ事業者、モデル事業者のどこで行われますか。
• 一回の回答に使ったデータは、ログ、品質評価、学習へ再利用されますか。
• 既定値は無効、要求時だけ、常時有効のどれですか。
• 利用者はモデル事業者と用途を変更できますか。
• 無効化後に、過去のログや派生データはいつ消えますか。

ブラウザは、検索、業務アプリ、社内文書、個人の通信が集まる場所です。そこでAIが動くなら、便利な要約ボタンだけでなく、用途と送信先を確認する制御盤が必要です。モデルの賢さより、ページごと、プロファイルごと、仕事ごとに境界を変えられるかが長期の信頼を決めます。

日本企業は「同意を取ったか」から「用途が増えていないか」へ監査を変えます

日本企業の現場では、個人情報保護の同意文、プライバシーポリシー、委託先一覧を法務部門が管理し、API、データ基盤、AI機能を開発部門が管理していることが珍しくありません。両方が正しくても、対応関係が切れれば事故になります。

そこで、法務文書とシステム構成図の間に「用途台帳」を置きます。各用途には、次の項目を持たせます。

項目	記載例
用途番号	BENEFIT-AMZ-001
対象者	対象プラン申込者のうち明示同意者
データ	電話番号、契約プラン名
利用目的	対応特典の案内
受領者	契約で指定した外部事業者
判定	対象プランと同意ログの一致
保持	送信先を含む期限と消去証跡
禁止	広告最適化、信用評価、モデル学習への転用
停止条件	同意版欠落、対象者急増、送信先変更
救済	通知、訂正、削除、問い合わせ窓口

用途番号を、同意画面、API、データベース、監査ログ、提携契約へ共通して埋め込みます。文言が変わっても番号が残り、番号を削除すれば依存先が分かります。新しいAI機能がデータを読みたい場合も、既存権限をそのまま継承せず、新しい用途番号を申請します。

生成AIは、この台帳作成を補助できます。規約と設計書の差分を探し、同じデータ項目が別目的で使われている箇所を候補として挙げられます。ただし、AIが「似た目的」と分類したから許可を統合してはいけません。顧客が期待する結果、不利益、共有先、保持期間が違えば、別用途です。

30日で用途の境界を点検します

全システムのデータを一度に棚卸しすると、一覧だけが増えて止まりやすくなります。まず、外部共有、アカウント停止、AI学習のいずれかを含む一つの業務を選びます。

最初の10日——一つのデータを追跡します

電話番号、画像、会議録、問い合わせ文など一つを選び、取得から削除までを追います。画面で説明した目的、実際の送信先、利用したモデル、保存期間、停止時の影響を並べます。

この段階では、個人情報一覧を作り直す必要はありません。「このデータを誰が何のために使ったか」という事実の流れを一本描きます。目的が「サービス改善」だけなら、検索改善、担当者教育、AI評価、モデル学習などへ分解します。

次の10日——用途を一つ消してみます

試験環境で、外部共有の同意項目、AI学習許可、検索クローラー許可のどれか一つを無効にします。依存する処理が止まり、許可した別用途は続くかを確かめます。

全部止まるなら目的が分離されていません。何も止まらないなら、同意や設定が実装へ接続されていません。検索は続くが学習は止まる、保管は続くが共有は止まる、対象ファイルだけ保留されメールは使える、といった望む縮退を定義します。

最後の10日——誤判定と復旧を練習します

同意ログの欠落、分類器の誤検知、クローラーの目的表示違反を試験データで再現します。検知から停止、担当者への通知、本人への説明、異議申立て、復旧、派生データの消去までの時間を測ります。

特に、元データを消しても、要約、埋め込み、学習用コピー、バックアップ、提携先の派生記録が残る場合があります。「削除しました」を元ファイルの削除だけで終えず、用途ごとの派生物を確認します。

毎月見る七つの指標

用途の境界は、規約を更新した回数では測れません。実装と救済が動いているかを次の指標で見ます。

• 目的対応率：送信、学習、判定の各処理に有効な用途番号が付いている割合です。
• 未同意実行率：必要な同意ログなしで処理が動いた割合です。
• 目的追加率：開始後に説明なしで利用目的や受領者が増えた割合です。
• 影響連鎖数：一つの判定で停止・削除・制限される別機能の数です。
• 誤判定救済時間：異議受理から独立再審査、復旧までの時間です。
• 派生物消去率：元データだけでなく、コピーや要約を期限内に消去できた割合です。
• 目的別選択率：検索は許可し学習は拒否するなど、利用者が細かく選べた割合です。

七つを一つの点数へまとめないことも大切です。未同意実行がゼロでも、異議申立てに数週間かかれば信頼できません。選択肢が多くても、既定値と説明が分かりにくければ実質的な選択になりません。速度、可逆性、説明可能性を並べたまま判断します。

参考にした主な情報

• ドコモ、34万ユーザーの電話番号などAmazonに無断提供——ITmedia NEWS
• 漫画原稿のクラウド保存とGoogleアカウント停止——ITmedia NEWS
• 検索への掲載を保ちながらAI学習を拒む制御——Cloudflare
• Private, Multilingual AI Browsing——MistralとMozilla

結論——便利な入口ほど、用途の出口を細かくします

ドコモの事例では、特典案内という理解しやすい目的でも、同意画面と送信処理の版がずれれば無断提供になりました。漫画原稿の事例では、保管のために預けたデータが自動検査とアカウント全体の停止へつながりました。AIクローラーでは、検索に載せる許可が学習の許可まで兼ねる構造そのものが見直され始めています。

共通する対策は、データを囲い込むことでも、AIを全面禁止することでもありません。取得、利用、判定、結果、救済を用途番号で結び、目的を一つ止めても別の正当な目的は続けられるようにすることです。便利さと統制を二者択一にしないための設計です。

次に新しいAI機能を導入するとき、「このデータを使ってよいですか」だけで終えず、「検索、要約、学習、共有、判定のうち、どれを許し、どれを後から止められますか」と聞いてみてください。あなたの会社は、その答えを利用規約ではなく、実際のログと停止操作で示せるでしょうか。