Contents
結論と推奨（導入要点）
ここでは短く結論と、実務で優先すべき対応を示します。早く意思決定したい担当者は、まず以下を確認してください。
- 補助ツールとしての位置付けで導入すること。単独で完全な防御を期待しないでください。
- 通知アクセスのみで十分なケースと、デフォルトSMSアプリ化が必要なケースを分けて評価してください。
- 法務・コンプライアンスとプライバシーの事前確認を必須とし、パイロットで誤検出率と検出カバレッジを定量評価してください。
Whoscallとは：概要とSMS発信元識別の仕組み
Whoscallの基本的な役割と、識別に用いる技術要素をまとめます。実務では「何を頼りに識別しているか」を理解することが重要です。
提供元・対応OS・主な機能
WhoscallはGogolookが提供する番号識別サービスです。番号DB、ユーザー通報、機械学習を組み合わせて判定します。主な機能は以下です。
- SMS識別（発信元ラベリング、スパム判定）
- スパムブロックや自動振分け機能
- クラウド連携の番号データベースと通報基盤
- 通知やメッセージ上での番号表示（OSに依存）
- ユーザー通報とベンダーへのフィードバック機能
公式情報: https://whoscall.com/ja（参照: 2026-05-16）
公式プライバシーポリシー（通報時に何が送信されるかを確認）: https://whoscall.com/ja/privacy（参照: 2026-05-16）
主要競合との比較
簡潔に、実務で比較すべき観点を示します。選定時は自社要件に照らして評価してください。
| 比較項目 | Whoscall | Truecaller | Hiya |
|---|---|---|---|
| 地域カバレッジ | 日本・台湾で実運用の実績あり | グローバルなユーザーベースが大きい | グローバル、キャリア連携あり |
| 企業向け制御 | キャリア連携例あり（要確認） | エンタープライズ機能あり | 企業向けAPIあり |
| 権限要件 | 通知アクセス中心。SMS権限は限定的に必要な場合あり | 通知/デフォルト切替を伴う場合あり | 同上 |
| プライバシーの見え方 | 公式ポリシーで確認必須 | ポリシーを比較して評価 | ポリシーを比較して評価 |
競合の公式サイト（参照: 2026-05-16）: https://www.truecaller.com/、https://hiya.com/
Androidでの導入・運用手順（実務向け）
Androidは権限種類とOSバージョン差が運用に影響します。ここでは設定フローと実務での注意点を示します。
インストールと初期セットアップ
以下は一般的な流れです。機種やOSで表記が変わる点に注意してください。
- Google PlayからWhoscallをインストールします。最新版を選びます。
- アプリを起動し初回の案内に従います。設定案内が表示されます。
- 通知アクセス（Notification access）を許可します。設定→アプリと通知→特別なアプリアクセス→通知へのアクセス等で設定します。
- アプリ内でSMSフィルタや自動ブロックを有効にします。必要に応じて実機で動作確認を行います。
- デフォルトSMSアプリに切り替える場合は影響範囲を事前に評価します（後述の法務注意参照）。
※ 手順はOSバージョンやメーカーカスタマイズで表示が異なります。実機で確認を行ってください。
権限と法務注意点
権限取得は技術面だけでなく法務面の検討が必要です。権限の与え方でユーザー情報の取り扱いが変わります。
- 通知アクセスは通知の内容を読み取るため、本文が含まれる場合もあります。
- SMS読み取り権限やデフォルトSMS化は本文へのアクセスを伴います。これらはGoogle Playのポリシーで制限されます。公式ポリシー: https://support.google.com/googleplay/android-developer/answer/9047303（参照: 2026-05-16）
- 企業導入では法務・個人情報保護部門の承認を必須にし、利用目的と同意を明確にしてください。デフォルトSMSアプリ化は特に慎重に判断してください。
権限と設定のポイント（通知アクセスとSMS権限の違い）
ここでは技術的な違いと運用上の判断基準を示します。
- 通知アクセスのみ: 通知のテキストや送信元情報からスコアリングが可能です。権限が比較的限定的です。
- SMS権限（読み取り）: メッセージ本文全体へアクセスできます。高精度な解析が可能ですが、プライバシー負荷が大きくなります。
- 運用判断: まず通知アクセスで検証し、必要性が明確な場合のみSMS権限を拡張することを推奨します。
運用時の注意（デフォルトSMSアプリ・バッテリー最適化）
運用でよく起きる問題と対処をまとめます。
- デフォルトSMS化の影響範囲をテストする（他アプリとの互換性、バックアップ等）。
- 省電力設定でアプリが制限される機種があるため、例外設定（バッテリー最適化の除外）を検証する。
- マルチSIM、ショートコード、海外SMS挙動は機種依存で差が出るため、代表機種での検証を行う。
- BYOD運用では同意運用とMDMによる設定管理を併用し、権限付与のログを残す。
iPhone（iOS）での導入・運用手順（実務向け）
iOSはサンドボックスや拡張機能の制約があり、Androidと同じ設計はできません。ここではiOS固有の注意点を説明します。
インストールとMessage Filter（SMSフィルタ）の有効化
iOSでの基本的な導入手順は次の通りです。
- App StoreからWhoscallをインストールします。
- 設定アプリでMessage Filter（メッセージのフィルタ）拡張を有効にします。表記や場所はiOSのバージョンで異なります。
- バックグラウンド更新や通知の設定を確認します。
手順の詳細はAppleのサポートページを参照してください。Appleサポート（フィルタ関連）: https://support.apple.com/ja-jp/guide/iphone/iph3f8f0bf1/ios（参照: 2026-05-16）
iOS特有の制約と表示の違い
iOS上での挙動を整理します。
- サードパーティのフィルタはサンドボックスで動作します。アクセスは限定的です。
- Messagesアプリでは迷惑判定メッセージが別タブへ振り分けられることが多く、Androidのような詳細オーバーレイは少ないです。
- 自動削除や高度なメッセージ管理は制限されます。判定結果の反映に時間差が出る場合があります。
プライバシーと留意点（iOS）
iOSでのフィルタは設計上プライバシーを重視していますが、ベンダー実装に差があります。
- フィルタ拡張がどのデータをクラウドに送るかはベンダーに依存します。ベンダーのプライバシーポリシーで必ず確認してください。
- 企業導入ではBYODポリシーに従い、端末情報やメッセージメタデータの扱いを明確にしてください。
受信時の見え方と実務的対応フロー
受信表示の見え方はOSと設定で変わります。ここでは現場での即対応フローと記録方式を提示します。
表示ラベルの読み方と即時対応判断基準
判定ラベルの扱い方と初動判断基準を示します。
- Android: 通知やメッセージ画面に「スパム」などのラベルが表示される場合があります。表示の有無で即時対応を使い分けます。
- iOS: 未知の差出人や迷惑フォルダへ振り分けられることが多いです。
- 即時判断基準: 金銭要求、OTPやログイン誘導、URLリンクの添付は高リスクです。疑わしい場合は開かず、社内確認またはキャリア窓口へ相談してください。
対応テンプレート（通報／キャリア連絡／社内報告）
通報や報告に使える統一フォーマットの例を示します。記録項目を揃えることで後続対応が速くなります。
- アプリ通報（備考欄の書式例）
- 受信日時: YYYY/MM/DD HH:MM
- 送信元: +81-90-XXXX-XXXX（可能な形式）
- 本文抜粋: "本文の抜粋（必要最小限）"
- Whoscall判定: スパム／要確認
-
端末: 機種名、OSバージョン（任意）
-
携帯キャリアへの報告（メール等の要旨）
件名: 迷惑SMS通報
本文に受信日時・送信元・本文抜粋・端末情報を記載します。 -
社内セキュリティ報告（要点）
件名、受信日時、送信元、本文要約、Whoscallの判定、推奨対応（注意喚起など）を簡潔に記載します。
証拠はテキスト保存が原則です。スクリーンショットは必要に応じ社内規程で扱いを定めてください。
識別精度・限界とトラブルシューティング／運用ガイド（企業向け含む）
ツール導入にあたって「どの程度信頼できるか」を定量で評価する方法と、運用で起きる代表的なトラブル対応を示します。
識別が難しいケースと誤検出対策
識別が難しい主要ケースと対応例を列挙します。
- 送信元偽装（なりすまし）や番号マスク化：通報とキャリア照会で裏取りする。
- ショートコード・共有送信元ID：送信元の透明化を相手事業者へ要求する。
- 海外送信や番号再利用：地域カバレッジを明示したベンダー情報で補う。
- 対策: ホワイトリスト運用、ユーザー通報の活用、定期的な誤検出レビューを行う。
定量的な評価方法とKPI例
導入前後に定量評価を行うための指標と計測方法を示します。
- 基本指標（例）
- 検出カバレッジ（Recall）= 検知されたスパム件数 / 実際のスパム総件数
- 精度（Precision）= 正しくスパムと判定された件数 / 判定をスパムとした総件数
- 誤検出率（False Positive Rate）= 誤ってスパム判定した正常メッセージ / 正常メッセージ総数
-
検出レイテンシ（秒）= 受信から判定までの平均時間
-
目安（企業導入での参考値）
- 誤検出率: 1%未満を目指す（業務影響が大きい場合）
-
検出カバレッジ: 70〜90%を想定（送信元偽装などで下がる）
-
計測方法（サンプル案）
- パイロット期間: 2週間〜1ヶ月、代表端末数: 50〜200台（業務規模に応じて拡張）
- 手順: 受信ログを収集し、手動で正解ラベル付けを行う。上記指標を算出する。
（例）1000件中スパム実数200件、検知180件→検出カバレッジ=90%。正常800件中誤検出8件→誤検出率=1%。
トラブルシューティングと企業導入チェックリスト（まとめ）
導入・トラブル時のチェックリストを簡潔に示します。
- アプリとOSが最新版か確認する。
- Androidは通知アクセス、iOSはMessage Filterの有効化を確認する。
- バッテリー最適化設定や省電力機能でアプリが制限されていないか確認する。
- 誤検出が続く場合は事例を収集し、ベンダーと共有して改善を依頼する。
- 法務・個人情報保護部門によるベンダー評価とDPA（データ処理契約）を整備する。
- パイロット運用でKPIを測定し、許容値を定める。
プライバシー・セキュリティに関する確認項目
通報や判定で何が送信されるかは必ず確認してください。チェックリストを示します。
- 通報時に送られる項目（例）: 受信日時、送信元番号、本文抜粋、端末モデル、OSバージョン。
- 送信データの匿名化／ハッシュ化の有無を確認する。
- データ保持期間と削除ポリシーを確認する。
- 第三者提供・国際移転の有無と処理拠点を確認する。
- DPAやデータ処理に関するSLA（応答時間、ログ提供）を契約で規定する。
ベンダーのプライバシーポリシーやサポート窓口でこれらを確認し、必要なら法務チェックを依頼してください。
参考リンク（公式と検証先）
導入判断に際して必ず確認すべき公式ページや検証参考を列挙します。各リンクは参照日を併記しています。
- Whoscall 公式サイト（製品情報／サポート）: https://whoscall.com/ja（参照: 2026-05-16）
- Whoscall プライバシーポリシー（通報時のデータ取り扱い確認）: https://whoscall.com/ja/privacy（参照: 2026-05-16）
- Google Play デベロッパーポリシー（SMS・通話ログ権限）: https://support.google.com/googleplay/android-developer/answer/9047303（参照: 2026-05-16）
- Apple サポート（メッセージのフィルタ／未知の差出人をフィルタ）: https://support.apple.com/ja-jp/guide/iphone/iph3f8f0bf1/ios（参照: 2026-05-16）
- 楽天モバイルのWhoscall案内（キャリア連携の例）: https://network.mobile.rakuten.co.jp/guide/whoscall/（参照: 2026-05-16）
- 参考レビュー（第三者記事、更新日を確認の上で参照）: https://www.bousaid.com/20250429_whoscall/（参照: 2026-05-16）
上記のうち特にプライバシーポリシーとGoogle Playの権限ポリシーは導入前に必ず確認してください。
まとめ（導入アクションの要点）
導入前に実務担当が最低限実施すべきことを箇条書きで示します。
- 目的の明確化: 防御の役割と期待値を定義する。
- 権限方針: 通知アクセスのみか、デフォルトSMS化を行うかを決める（法務合意必須）。
- パイロット設計: 代表端末で2週間〜1ヶ月のパイロットを実施し、誤検出率・検出カバレッジを定量評価する。
- プライバシー確認: ベンダーのプライバシーポリシー、データ保持、第三者提供を契約で明確化する。
- 運用ルールと教育: 社内報告フローとユーザー向け注意喚起を整備する。
以上を踏まえ、まずは小規模なパイロットで数値を取り、許容できる運用ルールを定めてから本格導入に進んでください。