ドコモRCS「同意なし」約1.6万件、Googleに何が送られた？225件の実態と仕事用番号の守り方

ドコモのRCSで、本人が説明を受けず、第三者提供に同意していないのにメッセージを送れる状態になっていた――。2026年10月4日、NTTドコモが公表したのは、約1万6,000件に関わる手続き上の不備です。このうち225件では実際にRCSの送受信があり、Google Asia Pacificへサービス提供に必要な送受信情報が送られていました。

ここで気になるのは、「メッセージの中身までGoogleに読まれたのか」「仕事用番号で取引先と連絡している人はどうすればいいのか」という2点でしょう。

結論からいうと、ドコモは本文が暗号化され、Google Asia Pacificが内容を閲覧することはないと説明しています。ただし、本文が読めないことと、通信相手や日時などの情報が処理されないことは別問題です。通常のRCS利用でも運用に必要な情報を取り扱うことが公式に明記されています。過度に「RCSは危険」と決めつけず、本文と通信メタデータを分けて考える必要があります。

情報確認日：2026年10月8日。主な出典：ドコモの2026年10月4日付お知らせ。

約1万6,000件と225件は何が違う？ドコモRCSで起きたこと

説明・同意取得の不備: 約16,000件; 2026年9月17日～25日の一部MNP新規契約
RCSの送受信あり: 225件; 送受信に必要な情報がGoogle Asia Pacificへ送信
公表日: 2026年10月4日; NTTドコモ公式発表

約1万6,000件は説明・同意の取得手続きが欠けた契約件数で、225件はその中で実際にRCSメッセージの送受信があった件数です。両者を「1万6,000人分のメッセージがGoogleに漏れた」と言い換えるのは不正確です。

ドコモによると、2026年9月17日〜25日にドコモショップ・量販店などで他社から乗り換え（MNP新規契約）をした一部の利用者について、店頭手続きシステムの不備でRCSの重要事項説明と第三者提供同意の確認画面が表示されませんでした。それでもRCSを使える状態だったため、ドコモは10月4日に公表しました。

対象期間：2026年9月17日〜25日
説明・同意取得に不備があった契約：約16,000件
実際にRCS送受信があった件数：225件
提供パートナー：Google Asia Pacific Pte. Ltd.

ドコモは対象者について9月30日20時からRCSを順次停止し、10月4日10時から個別連絡を開始しています。対象者が改めてRCSを利用するには、案内に従って「RCS利用拒否」を解除する必要があります。RCSが急に使えなくなったからといって、端末故障と決めつけないことも実務上大切です。

ドコモの公表文は「Googleが本文を閲覧した」とは述べていません。また、外部からの不正侵入を原因とする事故でもなく、今回確認されたのは同意取得の不備です。用語を正確に分けることが、必要な対策を選ぶ第一歩になります。

出典：NTTドコモ「RCS利用における重要事項説明および第三者提供同意取得未実施に関するお知らせ」

本文は暗号化。それでもGoogleに共有される「送受信情報」とは

本文と通信メタデータは保護・処理のレイヤーが異なる
	取り扱われる対象	確認できる説明
メッセージ本文	文章・画像などの内容	ドコモは本文が暗号化され、提供パートナーが閲覧しないと説明
利用者の識別情報	電話番号・IMSI・利用状態など	ドコモのRCS個人情報取扱いに列挙
送受信情報	日時・相手先番号／ネットワーク・送受信結果など	通常のRCSサービス運営上の取扱い対象として明記

電話番号や通信日時など、サービスの配送・運営に必要な情報は、メッセージ本文の暗号化とは別に取り扱われます。ドコモのRCS提供案内は、NTTドコモとGoogle Asia Pacificが情報を利用する目的・項目を明示しています。

公式に列挙されているのは、利用者情報として電話番号・IMSI（加入者識別ID）・サービス利用状態、送受信情報として送受信日時・送受信先の電話番号やネットワーク・送受信結果・グループチャット情報などです。送受信メッセージも項目に含まれますが、ドコモは本文について暗号化され内容は閲覧しないと注記しています。

これらは、一般に通信メタデータと呼ばれる種類の情報です。たとえばチャットの本文を読めなくても、「ある番号と、どの時間帯に頻繁に連絡しているか」という関係性は、送受信情報から推測できる場合があります。これは情報の性質から導かれるリスク評価であり、今回の225件で個別の取引関係が解析・悪用された事実を示すものではありません。

他社のRCSも、「本文だけが大切」という設計ではありません。auの公式案内にはKDDIと提供パートナーによる電話番号・IMSI・相手先・日時などの取扱いが記載され、SoftBankのサービス案内からはRCSの利用条件や規約を確認できます。ただし、事業者・OS・提供方式によって規約や運用は異なります。ドコモの同意未取得という不備が他社でも発生した、という意味ではありません。

また、「225件について、列挙されたすべての情報項目が必ず個別に送信された」とまでは公開資料から確認できません。ドコモと提供パートナーの各項目の具体的な保存日数についても、今回の調査では特定できていません。

出典：ドコモ「RCS提供開始とお手続きのご案内」／ au「RCS提供対象拡大について」

「RCSが使える」と「E2EEが成立する」は別。iPhoneの対応状況も確認

AppleのiPhone向けRCS E2EEベータ対応一覧（2026年10月8日確認）
	Apple一覧への掲載	正しく読むポイント
au	E2EE RCS beta の記載あり	掲載だけですべての相手・アプリとのE2EEを保証しない
SoftBank	E2EE RCS beta の記載あり	利用条件と会話の暗号化表示を別途確認
NTTドコモ	該当のE2EE beta の記載なし	RCS本文の暗号化がすべて無い意味ではない
楽天モバイル	該当のE2EE beta の記載なし	今後の対応や他方式の保護を否定するものではない

RCSに対応しているだけでは、その会話の本文がエンドツーエンド暗号化（E2EE）されていると判断できません。RCSの本文暗号化という一般的な説明と、送受信端末だけが復号できるE2EEは、分けて確認する必要があります。

Appleのアジア太平洋のiPhoneキャリア機能一覧（2026年10月8日確認）では、日本のauとSoftBankに「End-to-end encrypted RCS messaging (beta)」の記載があります。一方、同じ表のNTT DOCOMOとRakuten Mobileには、このベータ機能の記載がありません。

これは、au・SoftBank回線なら相手や端末を問わずすべてE2EE、あるいはドコモ・楽天モバイルのRCSが一切暗号化されないという意味ではありません。Appleが掲載している機能の対応状況と、目の前の会話で暗号化が成立する条件は別です。OS・アプリ・通信事業者・相手側の対応状況を含めて確認する必要があります。

Googleメッセージなどでは、対象の会話で暗号化状態を確認できる表示が用意されています。仕事の重要情報を送る前に、利用中のアプリと端末で実際にどの方式で送信されるかを確認しましょう。SMSに切り替わっていた場合、RCSの暗号化条件は引き継がれません。

なお、電話番号が表示される緑色の吹き出しという見た目だけで暗号化を判定するのは不十分です。Appleのメッセージ種別の解説やGoogleメッセージのE2EE案内で、利用環境ごとの確認方法を押さえておくと安心です。

RCSをオフにするべき？仕事用番号なら「連絡の機密度」で選ぶ

通常の業務連絡・日程調整RCSを利用してよいが、送受信情報の取り扱いを理解する
顧客情報・契約書・認証情報など高機密E2EE成立を確認した手段や適切に保護されたファイル共有手段に切り替える
RCSをオフにしてSMSへ切り替えるSMSにE2EEはなく、送信料や機能差が生じ得ることを確認する
私用番号に仕事の連絡が集中している必要に応じて仕事用番号を別回線・eSIMで分離する

通常の取引連絡まで一律にRCSを止める必要はありません。一方、顧客の個人情報や契約上の秘密を含むやりとりを、暗号化状態が不明なメッセージ経路へそのまま載せるのも避けたいところです。

RCSは文字だけでなく写真・ファイル、グループチャット、既読確認などを利用できる反面、相手が対応していないとSMS/MMSへ切り替わる場合があります。SoftBankの公式案内では、RCSで別途データ通信料が発生し、SMS/MMSで送るとSMS/MMS送信料が発生すると明記されています。RCSの利用料金が基本無料であっても、送信方式によって暗号化・機能・通信費の前提が変わる点は見落とせません。

フリーランスや個人事業主なら、連絡手段を次の順序で決めると合理的です。

日程調整・到着連絡など、機微情報を含まないもの：RCSを利用してもよい。ただし相手に届く方式を確認する。
顧客名簿・本人確認書類・契約書など：取引先と合意したアクセス制御・共有期限のあるファイル共有や、適切に保護された業務用連絡手段へ切り替える。SMS/RCSの送信成功だけを情報管理の根拠にしない。
仕事相手を私用の連絡先や生活圏から切り分けたい：仕事用番号を別に持ち、連絡先管理・本人確認・端末紛失時の復旧手順も分離して設計する。

番号の分離は万能ではありません。同じ通信サービス上で発生するメタデータがすべて見えなくなるわけではありませんが、私用番号を多数の取引先に知らせずに済むため、公開範囲と運用を整理できます。具体的な設計はリモノアのeSIMで仕事用番号を分ける実務ガイドも参考になります。

今回のドコモの対象期間に店頭MNPした心当たりがあり、RCSが使えなくなった場合は、再設定を急ぐ前にドコモの対象者向け案内を確認してください。

より広いアカウント防衛策は、AIハッカー時代のフリーランス防衛設計で紹介しています。メッセージの方式だけでなく、認証・連絡・復旧の入口を分ける方が実務上の安心につながります。

よくある質問｜ドコモRCS・Google連携・SMSへの切替え

Q. 1万6,000件すべてのRCS本文がGoogleに渡ったのですか？

いいえ、そのような発表ではありません。約1万6,000件は説明・同意取得に不備があった契約件数です。そのうちRCSを実際に送受信した225件で、送受信に関する情報が提供パートナーへ送られました。ドコモは本文が暗号化され、内容は閲覧されないと説明しています。

Q. RCSを使うと、Googleに誰と話しているか分かるのですか？

ドコモの公式説明には、相手先電話番号・送受信日時などの送受信情報の利用が明記されています。ただし、送受信情報が具体的にどう保存・解析されるかは一律には分かりません。連絡関係の情報が処理され得ることと、実際に不適切な分析が行われたことは別です。

Q. ドコモのiPhoneでRCSは暗号化されませんか？

「ドコモのRCSは一切暗号化されない」とは断定できません。Appleの確認時点のキャリア一覧では、NTT DOCOMOにiPhoneのRCS E2EEベータ機能が掲載されていません。本文暗号化一般とE2EEを混同せず、利用端末・アプリ・相手との会話状態を確認してください。

Q. RCSをオフにすれば、プライバシー面で完全に安全ですか？

いいえ。SMSもE2EEではなく、料金や機能の面で不利になることがあります。RCS停止は選択肢の一つですが、日常連絡と機密資料のやり取りを分け、必要な情報は適切に保護された別の連絡・共有手段を使う方が目的に合います。

この記事の検証に使用した主な情報源

公開情報から確認できない点：今回の225件で実際に送信された個別フィールドの網羅的な監査結果、各情報の具体的保持期間、ドコモのiPhone向けRCS E2EEベータ対応時期、楽天モバイルの実装と第三者提供の詳細を他社と同一とする根拠。これらは推定で補っていません。