Whoscall法人向けガイド：2026年の機能・比較と導入手順

要点まとめ

ここでは本記事の重要ポイントだけを短く示します。Whoscallの法人向けはSaaS/API/カスタム契約の形態があり、機能や料金はプランにより異なります。PoCでは識別精度（Precision/Recall）・API遅延・SLAを重点検証し、公式リリースの出典（タイトル／公開日／適用プラン）を必ず確認してください。

• 提供形態：SaaS・API・エンタープライズ（カスタム契約）が中心で、適用範囲はプラン差あり。
• 主要検証項目：識別精度、誤検知影響、APIレイテンシ、ログ出力の粒度。
• 2026年の機能強化：一部報道でAI精度改善やSMS要約が報じられているが、以下の公式確認手順で裏取りすること。
• 実務テンプレ：RFP項目、PoC評価表、法務チェックリスト（DPA/越境転送）を本文で提供。

記事の構成と読みどころ

この記事は「概要→プラン比較→技術要件→セキュリティ／法務→導入手順→チェックリスト」の順に整理しています。読み飛ばす場合は要点まとめと導入前チェックリスト、PoC評価テンプレを先に参照してください。各セクションは実務で使える箇条や表を中心に構成しています。

Whoscall法人向けサービスの概要

法人向けサービスの基本的な提供形態と代表的な機能を整理します。実際の名称や機能はベンダー見積りや契約条件で異なるため、詳細は必ず提供元の公式資料で確認してください。

提供形態の概観

以下は法人向けで一般的に提供される形態の例です。プラン名や適用範囲はベンダー提示の見積りで確認する必要があります。

• SaaS（管理コンソール＋端末/アプリで利用）
• API / ライセンス（番号照会API、Webhook連携等で自社システムへ組込み）
• エンタープライズ向けカスタム契約（専用SLA、専任窓口、オンプレ接続等）

主な機能（代表）

法人で期待される機能群の例を列挙します。機能の提供可否や対象プランはベンダーにより異なります。

• 着信識別（番号の分類・発信者表示）
• 迷惑電話（スパム／詐欺）ブロックとポリシー管理（ホワイト／ブラックリスト）
• SMS検知・要約（言語対応はプランにより異なる）
• 番号照会API（単発・バッチ）
• 管理コンソール（権限管理、ログ・レポート、アラート）
• Webhook/APIによる通知・監査ログ出力

2026年の主要アップデート（報道ベースと公式確認の手順）

報道ベースで出回っている情報と、公式発表の確認方法を分けて説明します。報道は有益だが、契約やPoCに反映する前に必ず公式リリースの一次情報で裏取りしてください。

報道ベースの内容（非公式まとめ）

以下は技術系メディアや個人ブログで報じられている要素の非公式まとめです。ブランド表記や機能対象は記事ごとに異なるため、決定には公式資料の添付を必須にしてください。

• AIを用いた識別精度の向上（報道例あり）。適用プラン・時期は未確認。
• SMS本文の検知および要約表示機能の導入報道。言語対応・要約精度は要確認。
• API強化（バッチ照会やWebhook改善）に関する言及。レート制限・料金体系はプラン依存。

上記は非公式まとめです。報道や技術解説を参考にする場合は「公式リリースのURL／タイトル／公開日／適用プラン」を必ずRFPに添付してもらってください。

公式リリースの確認手順

公式情報を一次ソースで確認する手順を示します。RFPや見積り比較の際に、ベンダーにこの情報を明示的に要求してください。

1. 公式出典を要求する：リリースノートのURL、リリースタイトル、公開日、該当プラン（例：Enterprise/Business）を提示してもらう。
2. 変更ログを確認する：新機能の説明、既存機能への影響、ロールアウト日と段階（ベータ／一般提供）を確認する。
3. 適用条件を確認する：「どのプランにいつから適用か」「追加料金の有無」「既存契約への反映方法」を明確にする。
4. リリース日をRFPに記載する：発表日と参照日を記録し、比較表に併記する（出典の信頼性を担保するため）。

公式確認が得られない場合は、その報道情報は「非公式」と明記して評価から除外または条件付き評価にしてください。

法人向けプランの種類と料金体系：見積り時のチェックポイント

見積りを短時間で比較するための着眼点とRFPに必須で含めるべき情報を示します。金額はベンダー提示で変動するため提示しません。

プラン別の想定特徴

プラン種別ごとの一般的な違いを整理します。実提供は各ベンダーの提示条件により異なります。

• エンタープライズ：専用SLA、専任担当、カスタム統合、導入支援が充実する傾向。
• ビジネス／チーム：管理コンソール中心で標準APIを提供、サポートは一般的。
• API／ライセンス：従量課金でAPIコール単価が発生し、開発組込向けの契約が中心。

料金体系の概要と見積り時の確認項目

見積りには複数の要素が含まれる点に注意してください。見積り時に明確化すべき項目を列挙します。

• 初期費用（導入支援・設定）
• 月額ライセンス（管理者／端末数ベース）
• 従量課金（API呼び出し、番号照会、SMS解析件数等）
• サポートオプション（24/7対応、専任窓口）
• データ保持・ログエクスポートの追加費用

RFPに含める必須情報（テンプレ例）

RFPでベンダーに提示することで比較可能になる必須情報の項目です。以下はRFPにコピペできるCSV形式の簡易テンプレです。

上記テンプレをRFPに含め、ベンダーからの回答に「公式リリースの出典（URL／公開日）」の添付を必須にしてください。

機能比較と技術要件（実務目線）

実運用で差が出る評価軸とPoC設計を示します。評価では、定量指標とログの粒度を重視してください。

評価項目（比較表に含めるべき要素）

比較表でスコア化すべき主要項目です。判定に使うデータは同一条件で集めて比較します。

• 着信識別精度（Precision／Recall）と誤検知の業務影響度
• ブロック運用の柔軟性（組織単位のポリシー、白／黒リスト運用）
• SMS検知・要約の言語対応と要約品質（日本語は特に検証）
• 番号照会APIのレイテンシ（平均応答時間）・スループット・レート制限
• 管理コンソールの権限管理（RBAC）と操作性
• ログ項目（通話ID／タイムスタンプ／判定理由／モデルスコア）と出力形式（CSV/JSON）

PoCでの評価方法（推奨設計）

PoCは実トラフィックまたは過去ログによる短期検証を推奨します。以下は評価項目と測定方法の例です。数値はあくまで推奨例です。

上表の精度閾値は業務での推奨例に過ぎません。閾値設定時は次の点に注意してください。

• 計測定義を明確にする（正例／負例の定義、ラベル付け基準）
• サンプル数の確保：詐欺やスパムの正例が少ない場合、少なくとも数百〜千件の陽性事例を集めることを推奨します（目安）。統計的に±3%程度の誤差に抑えるには、陽性事例の数が影響します。
• ログ要件：判定理由（ルールID／モデルスコア）を必ず出力させ、オフラインで再検証可能にしてください。

測定に用いる基本式は次の通りです。検証データは人手で正解ラベルを付けてください。

• Precision = TP / (TP + FP)
• Recall = TP / (TP + FN)

技術連携のチェックポイント（PBX/CRM/SSO/API）

統合設計で確認すべき具体項目を整理します。事前の不一致は導入遅延や追加コストの主因になります。

PBX/CTI連携

PBXやCTIとの接続方式や既存システムとの親和性を確認してください。

• 連携方式：SIPトランク、CTI API、専用コネクタの有無を確認する。
• 同時接続：ピークトラフィック時の同時接続数対応を確認する。
• エラー処理：Webhookの再試行やエラーハンドリング仕様を確認する。

CRM／業務システム連携

CRMやチケット管理へのイベント連携要件を明確にしてください。

• サポート対象：Salesforce、Zendesk等の事前確認。イベント（着信／判定）送信の有無。
• 書き込み権限：通話履歴や判定結果をCRMに書き込む際の認証・権限を確認する。

認証・API仕様

認証方式や運用面での運用負担を確認します。

• 認証：OAuth2（Client Credentials）／APIキー／SAML等の対応有無。
• Webhook：署名検証、再試行ポリシー、冪等性の仕様確認。
• テスト環境：ステージングキー／テストトラフィックの提供可否。

セキュリティ・プライバシーとサポート／SLAの比較

セキュリティとサポートは法人導入での重要な差別化要因です。契約締結前に公式資料（監査報告やDPA）で裏取りしてください。

セキュリティ評価の主要項目

データ取り扱いに関する主要ポイントを整理します。RFPで明示的に回答を求めてください。

• データ収集範囲：収集する項目（発信者情報、通話メタデータ、SMS本文等）を確認する。
• 保持・削除ポリシー：保存期間、削除手順、エクスポート方法を定義してもらう。
• 暗号化：転送（TLS）と保管（AES等）の方式と鍵管理を確認する。
• アクセス制御：RBACの粒度、管理者操作の監査ログを確認する。
• 脆弱性管理：定期ペネトレーションテストや脆弱性スキャンの実施有無を確認する。
• インシデント対応：通知手順、RTO（復旧時間目標）／RPO（復旧データ損失許容）を確認する。

法令・規格対応

法規制対応や監査報告書の提出可否を確認してください。越境転送の扱いは特に重要です。

• 個人情報保護法（日本）／GDPRへの適合性を確認する。
• DPA（Data Processing Agreement）締結の可否と主要条項を確認する。
• データ居住性：国内データセンタの利用可否を明確にする。
• 監査報告：ISO27001／SOC2等の提出可否を契約前に確認する。

サポート体制・SLAの確認ポイント

SLAやサポート仕様は契約書で明確にする必要があります。以下は必須確認項目です。

• サポートチャネルと対応時間（例：平日9–17時、24/7等）
• 障害区分（P1/P2等）に対する応答時間・復旧目標（数値は契約で明示）
• SLA違反時の補償（運用クレジット等）とエスカレーション経路
• 専任窓口の有無とオンボーディング支援の範囲

SLA数値やセキュリティ証明は必ず契約書や公式監査資料で裏取りしてください（ここでの注意喚起は本文中の他箇所での重複を避けるために統合しています）。

法務・プライバシー：確認用質問テンプレ（法務レビュー向け）

法務レビューで使える具体的な質問と、DPAや契約条項で要求すべき内容のテンプレを示します。法的判断は社内法務および弁護士にて最終確認してください。

DPA／データ処理に関する質問

以下をベンダーに書面で回答・契約条項で確約させてください。

• DPAを締結するか（YES/NO）。締結する場合はドラフトを提示してもらう。
• データ処理の目的とカテゴリー（処理対象データの明細）。
• サブプロセッサ（下請）一覧と変更時の通知・同意方法。
• データ保持期間・削除手順・復旧方針（RPO）。
• 暗号化方式と鍵管理の責任分界点。

サンプル条項（例）：「ベンダーは本サービスにより取得した個人データを、契約で定めた目的の範囲内でのみ処理し、サブプロセッサの追加がある場合は事前に書面で通知するものとする。」

越境転送とデータ居住性

• データが国外転送される場合の法的根拠（SCC/適切な保護措置）を示してもらう。
• 国内データセンタ利用が必要な場合はその旨を契約に明記する。
• ログやテキスト（SMS本文等）に個人識別情報が含まれる場合の処理方法を確認する。

ログ・監査資料の提供

• 監査報告（ISO27001、SOC2）の最新版をNDA下で提供可能か確認する。
• ペネトレーションテスト結果や脆弱性対応履歴の開示範囲を確認する。
• インシデント発生時の通知期間（例：72時間以内）を契約で定める。

導入手順・運用フローとROIの測定方法

導入はPoC→評価→本番移行の段階を踏むことを推奨します。ROIは定量指標に基づき、導入目的に紐づけて算出してください。

PoCの標準的な進め方（フェーズ）

以下は一般的なPoCフェーズと目安期間です。規模により前後します。

• 目的定義（KPI設定）：1週間。
• データ準備（ログ抽出、サンプル作成）：1週間。
• テスト設計（シナリオ、計測項目）：1週間。
• 実行：2〜4週間（規模による）。
• 評価・レビュー：1週間。
• 本番移行計画の策定：2週間程度。

想定導入期間と社内体制（目安）

導入規模に応じた目安と必要な社内リソースを示します。

• 小規模（管理コンソール中心）：4〜8週間。
• 中〜大規模（CTI/CRM連携含む）：8〜16週間以上。
• 必要リソース：プロジェクトマネージャ、CTIエンジニア、セキュリティ担当、運用担当、現場責任者。

ROIと効果測定の指標サンプル（算出テンプレ）

ROIは目的に応じて定義します。算出テンプレの例を示します。

• 詐欺被害削減額 = 減少件数 × 平均被害額
• 対応工数削減 = 削減対応件数 × 平均対応時間（時間） × 人件費単価（円/時間）
• CS改善効果 = NPS/CSATの改善 × 平均顧客価値（LTV）の向上

上記はテンプレ例です。実数は社内の実績値で置き換えてください。

導入前チェックリスト・比較表（印刷・コピー用）

導入候補を短時間で比較するためのシンプル表とチェックリストを提供します。表はコピーして社内共有してください。

シンプル比較表（主要項目）

比較の起点となる主要項目を示します。PoCで閾値を決定してください。

上表は社内で優先度付けして比較候補を絞るためのテンプレです。

導入前評価チェックリスト（最低ライン）

導入前に合意すべき項目を簡潔に列挙します。

• PoCでの合格基準（精度・遅延・可用性）を定義済みか
• 見積り項目（初期/月額/従量/追加）が明確に開示されているか
• APIレート制限と超過時の課金条件を確認済みか
• データ保持・削除ポリシーとDPA締結の可否を確認済みか
• セキュリティ証明（ISO27001/SOC2等）の提示を受けたか
• 最低契約期間・解約条件（データ引き渡し）を確認済みか

競合サービスとの比較フレーム（優先順位付け）

優先度付けの一例です。業務要件に応じて重みを付けて合計スコアで候補を絞ってください。

• クリティカル（必須）：セキュリティ認証、SLA、法令対応
• 重要（高）：識別精度、PBX/CRM連携の容易さ、API性能
• 参照（中）：管理画面、レポート項目、サポートチャネル

契約時の注意点（実務チェック）

契約締結時に必ず確認・合意すべき事項を列挙します。

• 最低利用期間、更新・解約条件、データの引き渡し方法
• ログ・判定データの所有権とエクスポート権限
• データ削除の手順と残存データの保証（証跡）
• 機能保証とバージョンアップ方針（互換性と廃止時の対応）
• SLA違反時の補償範囲（クレジット・免責）
• DPA・NDAの締結可否と責任範囲（補償条項）

よくある質問（FAQ）

以下は導入時によく出る質問と実務的な回答例です。

Q: PoC期間はどれくらい必要ですか？
A: 目安は実トラフィックで2〜4週間。過去ログを併用すると効率的です。

Q: APIレート制限の緩和は交渉できますか？
A: 多くはプランや追加料金で対応可能です。見積り時に想定トラフィックを提示して交渉してください。

Q: 誤検知で業務に支障が出た場合の対応は？
A: ホワイトリスト運用、閾値調整、SLAでの対応手順を事前に定義しておくことが重要です。

用語定義（略語と表記の統一）

本稿では主要略語を定義し、同義語の表記を統一して記載しています。契約文書や社内資料でも以下の定義で揃えることを推奨します。

主な略語

• PBX：Private Branch Exchange（構内電話交換機）。社内電話インフラを指します。
• CTI：Computer Telephony Integration（CTI）。電話とコンピュータの統合機能を指します。
• SSO：Single Sign-On（単一サインオン）。認証連携方式を指します。
• RBAC：Role-Based Access Control（役割ベースのアクセス制御）。
• RFP：Request for Proposal（提案依頼書）。
• DPA：Data Processing Agreement（データ処理契約）。
• GDPR：EU一般データ保護規則。
• PII：Personally Identifiable Information（個人を識別できる情報）。
• RTO/RPO：復旧時間目標／復旧許容データ損失量。
• API：Application Programming Interface。
• Webhook：イベント通知用のHTTPコールバック機構。

表記の統一例：本稿では「端末」と記載する場合、モバイル端末／デスクトップ／ソフトフォン等を含む端的な意味で使用しています。

まとめ

• Whoscall法人向けはSaaS／API／カスタム契約の形態があり、機能・価格はプランにより異なります。
• 2026年の機能強化に関する報道は存在するものの、決定的な判断には公式リリース（タイトル・公開日・適用プラン）での裏取りが必須です。
• PoCでは識別精度（Precision／Recall）、API遅延、可用性を明確に計測し、判定根拠（ルールID／モデルスコア）をログ化してもらうことが重要です。
• RFPには想定トラフィック、連携システム、PoC条件、データ居住性・DPA要件を必ず含め、ベンダーに公式出典の提示を求めてください。
• 法務チェックではDPA、越境転送、サブプロセッサ一覧、監査報告（ISO／SOC等）を必ず確認してください。

参考として、報道や技術系記事を参照する際は「サイト名／記事タイトル／公開日／参照日」を記録し、公式リリースの一次ソースと併記する運用ルールを設けることを推奨します。