Google×Airtel、インドRCSにキャリア側スパムフィルタを直結――フィッシング抑止とプラットフォーム・ガバナンスの分水嶺です

今日の深掘りポイント

• RCSビジネスメッセージの審査・スパム検出をキャリア網のレイヤに統合することで、「ネットワーク機能としての信頼」を実装しにいく大規模実験です。
• エンドツーエンド暗号化（E2EE）の適用外であるRCSの商用メッセージ領域に、リアルタイム審査を組み込む設計は、フィッシング抑止の実効性と透明性（誤検知・アカウンタビリティ）との綱引きになります。
• インド市場の特殊性（モバイル/UPI決済の爆発的普及、A2P規制の厳格化）に最適化されたモデルは、他地域へ横展開される可能性が高く、日系企業のインド事業・越境マーケティングにも即時の運用影響が出ます。
• 攻撃者は「ブランドなりすまし＋短期決済詐欺」「AiTMでのMFA/OTP取り込み」「アグリゲータやテンプレート審査のサプライチェーン悪用」にシフトすることが予想され、防御側はRCS特有のIOC・挙動を捉える検知運用が必要です。
• 現実味と信頼性の高い動きで短期的な影響が具体化しやすい一方、制度設計（同意管理・不服申立・監査）の未整備がリスクとして残るため、CISOは技術実装とガバナンスの両輪で備えるべきです。

はじめに

Googleがインドの大手キャリアBharti Airtelと組み、RCS（Rich Communication Services）のスパム対策をキャリアのネットワークレベルでRCSエコシステムに統合する取り組みを公表しました。インドではモバイルユーザーとデジタル決済の急増に比例してスパムと詐欺が社会問題化しており、RCSのビジネスメッセージが悪用される事例も散見されます。今回の提携は、リアルタイムでの送信者検証・ビジネスメッセージ審査・ユーザーの「迷惑メッセージ拒否」設定の強化を一体化するものです。報道では、Airtelはこの種の対策で大規模なスパムコール/メッセージのブロックと詐欺損失の大幅削減を達成した実績を示しており、これをRCS領域に広げる構図です［出典: TechCrunch］。

参考情報: TechCrunch: Google looks to tackle longstanding RCS spam in India (2026-03-01)

深掘り詳細

事実関係の整理

• GoogleとAirtelは、RCSのスパム・詐欺対策をキャリア網のフィルタリングと連携させ、RCSのビジネス通信（商用メッセージ）に対してリアルタイム検査・送信者確認を適用する枠組みを示しました。とりわけ、ユーザーの「迷惑メッセージ拒否（DND）」や同意管理を尊重しながら、未承諾のプロモーションやフィッシングを抑止する狙いです［出典: TechCrunch］。
• 報道では、Airtelは過去の対策で大量のスパム遮断と詐欺損失削減を達成しており、同様のアプローチをRCSにも適用するとされています。RCSでは個人間チャットでE2EEが導入されてきた一方、ビジネスメッセージは事業者ボット/エージェントを経由するため、ネットワーク側での審査・検出の余地が残ります。今回の統合はその前提に立ったものです［出典: TechCrunch］。
• Googleは過去、インドでRCSビジネスメッセージのスパム問題を受け、一時的にプロモーション機能を停止する対応を取った経緯があり、今回の提携は恒常的な統制設計への舵切りと位置付けられます［出典: TechCrunch］。

インサイト：なぜ「キャリア直結」か、何が変わるか

• RCS特有の「表現力（画像・カルーセル等）」と「ブランド認証表示」は、正規にも攻撃にもレバレッジが大きいです。悪用側がブランドなりすましでUI/UXを装飾すれば、SMSより高いコンバージョンで資格情報や支払い情報を盗れます。従来のアプリ側スパム判定だけでは、送達経路の上流（キャリア網）にあるヒューリスティックやテレメトリを活かしきれませんでした。ネットワークレベル統合は、この「上流の文脈シグナル」を活かす設計です。
• インド市場はA2P（Application-to-Person）SMSで強い規制・審査フレーム（送信者登録、テンプレート審査、DND遵守）が整ってきました。RCSは規模が拡大する一方で、この審査・同意管理の実装が市場横断で未成熟でした。今回の統合は、A2Pで培った「事前審査・同意優先・ネットワーク側スクラビング」をRCSにも輸入する動きに見えます。
• その一方で、検閲・過剰ブロック・透明性の確保という政策的論点は重くなります。誤検知の救済、審査ロジックの開示水準、ブランドのアカウント凍結に対する不服申立てプロセスなど、プラットフォーム・キャリアの責務分担が問われます。企業側は「送信者認証」「同意証跡」「テンプレート衛生」の3点セットを整えないと、配信品質と信頼性の両面で不利益を被る可能性が高まります。
• 事象の確度と即時性は高く、既存のSMS対策の延長で片付けにくい「RCSならでは」の実務が増えます。SOC/Threat Intelには、RCS固有のIOCやURL生態系（短縮/多段リダイレクト、クラウドホスト濫用）のトラッキングが必要になります。

脅威シナリオと影響

以下は攻撃者の適応を想定した仮説で、MITRE ATT&CKに沿って記述します（技術カテゴリ名ベース、具体的な実装は複数想定があり得ます）。

• シナリオ1：RCSビジネスメッセージを装ったブランドなりすまし

  • リソース準備（Resource Development: Acquire Infrastructure/Domain）で正規風ドメインを取得、カタログ風LPを用意。
  • 初期アクセス（Phishing: Spearphishing via Service）としてRCS上で「KYC更新」「支払い確認」等のCTAを配信。
  • 実行（User Execution: Malicious Link）でユーザーをクリックさせ、資格情報やカード情報を入力誘導。
  • 認証情報悪用（Valid Accounts）によりオンラインバンキング/ECに即時ログイン、資金移転や不正購入を実行。
  • 影響：配信がネットワーク側で抑止される割合が増えても、ブランドそっくりのUIと高解像度リッチ要素でのだまし打ちは継続します。検知はURL生態系とテンプレート指紋の追跡が鍵になります。

• シナリオ2：AiTM（Adversary-in-the-Middle）でのMFA/OTP迂回

  • 初期アクセスは上記に同じ。プロキシ型フィッシングサイトでリアルタイムにセッション/OTPを中継取得（Adversary-in-the-Middle、Two-Factor Authentication Interception）。
  • 影響：UPI/ワンタイム承認の即時性を逆手に取るため、SOCは短時間での多要素認証失敗→成功の遷移や、新規デバイス紐付けの時系列相関監視が有効です。

• シナリオ3：アグリゲータ/送信プラットフォームの供給網悪用

  • 信頼関係（Trusted Relationship）を突き、RBM（RCS Business Messaging）アグリゲータのアカウント/APIキーを侵害し、正規チャネルから大量配信。
  • 影響：キャリア側フィルタは送信元信用を強く重視する可能性が高く、被害が出ると回復が難しいです。企業は自社の送信基盤に対し、鍵管理・IP許可リスト・テンプレート厳密化を即時に点検すべきです。

• シナリオ4：フィルタ回避のコンテンツ変形

  • 短縮URLの多段化、画像埋め込みのQR/テキスト化、ローカル言語スラングの変奏などでコンテンツ審査を回避（Defense Evasion: Obfuscated/Encoded Content等に相当）。
  • 影響：コンテンツ単体よりもリンク解決チェーン、最終到達ドメイン、ホスティング事業者の評判スコアを用いた行動分析の方が堅牢です。

全体影響として、キャリア統合フィルタで明白なスパムは抑制されますが、審査や同意管理の厳格化により、正規企業の配信運用（テンプレート、リンク方針、配信時間帯、セグメントの同意証跡）に対する要求水準が大きく上がります。日本企業でも、インド拠点・インド顧客向けのRCS/メッセージ施策は即時の見直しが必要です。

セキュリティ担当者のアクション

• 送信チャネルの棚卸しと可視化
  • インド向けのRCS/SMS/WhatsApp/メールを横断し、ブランド別の送信元、アグリゲータ、テンプレート、リンクドメイン（短縮含む）を在庫化します。RCSは専用に切り出し、誤配信・重複配信の経路を遮断します。
• RCSの「送信者認証」と「同意証跡」の強化
  • RBMのブランド検証とテンプレート審査の遵守を即時に確認し、短縮URLの多用を避け、自社管理ドメインかつHSTS有効のリンクに統一します。キャンペーン毎に同意取得のログ（時間・文面・オプトアウト手段）を保全します。
• 検知運用（SOC/Threat Intel）のRCS対応
  • IOC設計をRCS起点に拡張します。具体的には「RCS経由URLの最終到達TLD/ASN分布」「短縮URLの解決深度」「リダイレクト内のTDS/カウンタベース反ボット対策の有無」を定常観測し、異常スパイク時にブロックリストへ即反映します。
  • モバイル脅威防御（MTD）やエンドポイントのURL保護で、RCSアプリからの遷移も保護対象に含めます。ユーザー教育では、RCSの「認証済み表示」やブランドバッジが絶対の安全性を保証しないことを強調します。
• アグリゲータ/送信基盤のセキュア化
  • APIキーのローテーション、送信元IPの固定化、役割ベース権限制御の見直しを行い、未承認テンプレート/送信者IDの即時無効化プロセスを整備します。第三者監査証跡（ログ/署名付きイベント）を保管し、誤検知・停止時の不服申立て材料にします。
• リスク管理とガバナンス
  • キャリア/プラットフォーム側フィルタにより配信が抑止された場合のSLO（検知から切り戻しまでの時間）と代替チャネル（アプリ内/メール/コールセンター）を定義します。
  • 透明性確保に向け、キャリア/プラットフォームに対し「ブロック理由の粒度」「再審査SLA」「データ保護（内容・メタデータの取扱い）」についての説明責任を要求し、契約に盛り込みます。
• 早期に測るべきKPI（短期導入）
  • RCS起点のフィッシング報告率、RCS配信の到達率/ブロック率、テンプレート承認のリードタイム、RCS経由ドメインのインシデント関与率（メール/広告と横断比較）。これらを週次でダッシュボード化します。

参考情報

• TechCrunch: Google looks to tackle longstanding RCS spam in India—but not alone（Airtelとの統合、ネットワークレベル審査、過去のスパム問題とビジネスメッセージ停止の文脈、ブロック実績に関するデータを含みます）

本件は「RCSを安全に面白く使う」ための前進であると同時に、検知の精度・透明性・救済の3点セットをどう設計するかという、プラットフォーム・ガバナンスの難題に正面から挑む出来事でもあります。現場は、配信運用と検知運用を同時に磨きながら、制度の空白を契約とプロセスで埋めていく――そんな両利きの構えが求められる局面です。