3行要約
- Googleがインド最大手キャリアAirtelと提携し、RCSメッセージのスパムをネットワーク層で自動遮断する仕組みを導入した。
- 従来のデバイス側（オンデバイス）での検知に加え、キャリアのインフラを通る段階でAIがリアルタイム解析を行う多層防御へ移行。
- メッセージングの信頼性回復により企業のA2P市場は健全化するが、一方でAIによる通信監視とプライバシーの境界線が議論の的となる。
何が起きたのか
Googleがインドにおいて、通信大手Bharti Airtelと組み、RCS（Rich Communication Services）のスパム対策を「キャリアレベル」で統合しました。これまでGoogleメッセージが行ってきたスパムフィルタリングは、主にAndroid端末内の「オンデバイスAI」に依存していましたが、今回はその防衛線をキャリアの通信網にまで引き上げたのが最大の違いです。
なぜ今、インドでこれが必要なのか。理由は単純で、インドのRCS市場が既に「スパムの温床」として機能不全に陥りかけていたからです。インドでは2024年頃から企業によるRCS広告が爆発的に増加し、ユーザーの元には1日に何十件もの一方的な勧誘メッセージが届く事態が常態化していました。中には公式アカウントを装ったフィッシング詐欺も含まれており、プラットフォームとしての信頼性は地に落ちていたと言っても過言ではありません。
私は以前、インドのオフショア開発拠点とやり取りする中で、現地のメンバーが「RCSは通知をオフにするのが当たり前」と話していたのを覚えています。本来、SMSをリッチ化し、WhatsAppやiMessageに対抗するはずだったRCSが、ただの「高性能な迷惑メール送受信機」になっていた。この現状を打破するために、Googleはついに自社のAI技術をサードパーティであるキャリアのネットワークコアへ直接注入する決断を下しました。
このニュースは、単なる一地域のセキュリティアップデートではありません。Googleが世界最大のAndroid市場であるインドを「AIフィルタリングの実験場」とし、成功すれば全世界のJibe（GoogleのRCSプラットフォーム）採用キャリアへ横展開する布石です。
技術的に何が新しいのか
今回の発表で最も注目すべきは、フィルタリングの「レイヤー」が変わったことです。これまでの仕組みと、今回導入された「キャリア・インテグレーテッド・フィルタリング」の構造的な違いを整理します。
従来：オンデバイスAIによる事後処理
従来は、メッセージが一度端末に届いてから、OS側の「Messages AI」が内容をスキャンしていました。この方式のメリットはプライバシーの保護ですが、デメリットは「端末に届いてしまうこと」です。通知が一瞬表示されたり、ストレージを消費したり、あるいはOSのバージョンが古い端末では検知が機能しなかったりする課題がありました。
今回：キャリア・ネットワーク層での事前遮断
今回の提携では、Airtelのメッセージングゲートウェイ（SMSC/MMSCのRCS版）にGoogleのAIモデルが組み込まれています。メッセージがユーザーの端末に送信される手前の段階で、送信元の振る舞い、メタデータ、メッセージのハッシュ値、送信頻度などをリアルタイムで解析します。
具体的には、以下のようなパラメータがキャリア層で評価されていると推測されます。
- Velocity Check（速度検知）: 同一IPまたは同一送信元IDから、短時間に数万件のユニークな受信者へ送信されていないか。
- Identity Reputation: 送信元の検証済みRCSエージェント（VAP）の履歴。
- Behavioral Heuristics: リンクのクリック誘導パターンや、過去にスパム報告を受けた文面との類似性。
ここで技術的な疑問が出るはずです。「エンドツーエンド暗号化（E2EE）されているメッセージを、どうやってキャリアが検知するのか」という点です。Googleのドキュメントや今回のTechCrunchの報道を読み解く限り、キャリアは「コンテンツの中身（本文）」を読んでいるのではなく、暗号化されていない「メタデータ」と「送信パターンの統計」を用いています。
もし私がこのシステムを実装するなら、メッセージ本文そのものを解析するのではなく、送信元の「挙動」をベクトル化して、正常な企業アカウントの振る舞いから外れたものを異常検知（アノマリ検知）するモデルをVertex AIなどで構築し、エッジ推論としてキャリアのゲートウェイに配置します。これにより、プライバシーを維持したまま、スパムの90%以上をユーザーに届く前に「無効化」することが可能になります。
数字で見る競合比較
RCSのスパム対策が、他OSや他サービスと比べてどの程度の位置にいるのかを比較します。
| 項目 | 今回のGoogle×Airtel | Apple iMessage | WhatsApp (Meta) | 従来のSMS |
|---|---|---|---|---|
| 検知レイヤー | キャリア + デバイス | デバイスのみ | サーバー(Meta) | キャリア(限定的) |
| AI検知精度 | 99%以上 (推定) | 中程度 | 高 (通報ベース) | 低 |
| 対応コスト | 無料 (キャリア負担) | 無料 | 無料 | 有料/オプション |
| 送信元認証 | RBMによる厳格認証 | Apple ID | 電話番号認証 | ほぼなし |
| プライバシー | メタデータ解析 | 完全E2EE | サーバー解析(一部) | 平文(キャリア閲覧可) |
この表から分かる通り、Googleの狙いは「WhatsApp並みのサーバーサイド検知能力を、キャリアという分散したインフラ上で実現すること」にあります。WhatsAppはMetaが中央集権的に全てのメッセージを管理しているため、スパム対策が非常に容易です。一方、RCSは「キャリアの連合体」であるため、対策がバラバラでした。今回のAirtelとの提携は、分散型ネットワークに中央集権型の強力なAIエンジンを持ち込むという、ハイブリッドなアプローチです。
実務者目線で言えば、この「キャリアレベルでの遮断」が始まると、誤検知（False Positive）が発生した際の影響が甚大です。一企業の正規のマーケティングメッセージが、キャリアの判断で一斉にドロップされるリスクがある。これは、開発者にとって新たな「デリバビリティ（到達率）」の戦いが始まることを意味します。
開発者が今すぐやるべきこと
もしあなたがRCS Business Messaging (RBM) を使ったサービスを開発している、あるいは今後検討しているなら、ただ「APIを叩く」だけのフェーズは終わりました。以下の3点に即座に取り組むべきです。
1. 送信ドメインとエージェントの「認証済みステータス」の再確認
GoogleのVerified SMSやRBMの認証済みロゴが表示されるだけでは不十分です。今後はキャリア側のホワイトリストに含まれる必要があります。具体的には、パートナーシップを結んでいるアグリゲーター（通信仲介業者）に対し、Airtelなどのキャリア層で「スパムフラグ」が立っていないか、配信成功率のログを詳細に分析する仕組みを構築してください。
2. 送信頻度とユーザー反応のリアルタイム・モニタリング
キャリアレベルのAIは「ユーザーからのブロック率」を最も嫌います。従来のメールマーケティング以上に、RCSでは「オプトアウト（配信停止）」が容易です。APIを通じて「ユーザーが通報した」というシグナルを受け取れる場合は、その瞬間にそのユーザーへの送信を停止するだけでなく、送信内容の類似度を下げるといった「AI検知回避」のロジック（正当な意味での最適化）を組み込む必要があります。
3. RCSからWebへのシームレスな遷移設計
キャリアのフィルタリングが厳しくなればなるほど、メッセージ内に「怪しい短縮URL」を入れる行為はリスクになります。Googleメッセージ内の「リッチカード」や「提案ボタン」をフル活用し、URLを直接書かずにアクションを定義する設計に切り替えてください。ネイティブなアクションを利用することで、キャリア側のAIに「これはプロトコルに準拠した正当なビジネス利用である」と認識させやすくなります。
私の見解
正直に言って、この対策は「ようやく重い腰を上げたか」という感想です。私は仕事柄、多くのAIツールや通信プロトコルを触っていますが、ここ数年のRCS、特にインドや東南アジアでの荒れ方は目を覆いたくなる惨状でした。GoogleがiMessageへの対応をAppleに迫り、ようやく実現させた一方で、足元のAndroidユーザーがスパムの嵐に晒されている状況は、プラットフォーマーとしての怠慢だったと言わざるを得ません。
今回の「キャリア層でのAI統合」は、技術的には非常に強力です。RTX 4090を2枚挿してローカルLLMを動かしている身からすれば、端末側の小さなモデルで必死にスキャンするよりも、キャリアの大規模なトラフィックデータを学習した巨大なモデルで、ネットワークの入り口を閉じる方が圧倒的に効率的であることは明白です。
しかし、私が懸念しているのは「AIによる通信の自由の侵害」です。スパム対策という名目であれば、世論は歓迎するでしょう。しかし、キャリアのゲートウェイにGoogleの解析エンジンが居座るということは、事実上、全てのメッセージのメタデータがGoogleのアルゴリズムによって選別されることを意味します。「何がスパムで、何がそうでないか」の定義をGoogleとキャリアが独占する構造は、少し不気味です。
結論として、今回の動きは「RCSをビジネスプラットフォームとして復活させるための劇薬」です。短期的にはユーザー体験は劇的に向上しますが、開発者にとっては、GoogleのAIに「気に入られる」ようなメッセージングを強いられる、新たな制限の時代の始まりでもあります。
よくある質問
Q1: このスパム対策でメッセージの受信が遅くなることはありますか？
理論上は数ミリ秒の遅延が発生しますが、キャリアのゲートウェイに最適化されたAI推論エンジン（TPUや高速な推論チップ）が導入されているため、人間が体感できるほどの遅延はありません。むしろスパムが減ることで、アプリの処理負荷は軽減されます。
Q2: 日本のキャリアでも同様の仕組みが導入される可能性はありますか？
十分にあります。日本には「＋メッセージ」というRCSベースのサービスがありますが、GoogleメッセージのRCS採用も進んでいます。今回のインドでの成果（スパム削減率の数字）次第では、Googleは日本のキャリアに対してもJibeプラットフォームへの統合を提案するでしょう。
Q3: サードパーティのSMSアプリを使っている場合も保護されますか？
キャリアレベル（ネットワーク層）での遮断であれば、どのアプリを使っていてもスパムメッセージは届かなくなります。ただし、GoogleのAIモデルと密接に連携しているGoogleメッセージアプリを使うのが、最も高い保護効果を得られる設計になっているはずです。
