乗客は乗車地点に着いているのに車が見つかりません。ドライバーは近くにいるものの、地図上の位置が少しずれています。このような状況では、テキストメッセージを送り続けるより、直接電話した方が早いことが少なくありません。

しかし、すべての乗車で乗客とドライバーの個人携帯番号同士による従来型の電話に依存すると、別の問題が生じます。乗客とドライバーは本当に互いの実際の電話番号を見る必要があるのでしょうか。乗客が海外旅行中で、従来の音声ローミング料金が高い場合はどうでしょう。通信事業者の音声サービスが混雑していてもモバイルデータ通信が利用できる場合、連絡は取れるのでしょうか。そして乗車終了後も、取引には不要になった個人的な連絡手段を双方が保持し続けるべきなのでしょうか。

アプリ内VoIP通話は、こうした課題に対する一つの解決策です。Uberが2018年にVoIP通話を導入した時点で、同プラットフォームはすでにSMS、アプリ内チャット、従来の電話通話に対応していました。VoIPは単に「通話」ボタンを一つ追加したものではありません。リアルタイム音声通信を、アプリ自身のコミュニケーション環境の中へさらに取り込む仕組みでした。

同じモデルは現在、配車、フードデリバリー、物流、遠隔医療、カスタマーサービス、モバイルワーカー向けアプリでますます重要になっています。基本的な要件は共通しています。ユーザーには即時の音声通信が必要ですが、プラットフォーム側は、そのやり取りを公衆電話網や個人電話番号の交換だけに全面依存させる必要はありません。

従来の電話通話が配車サービスに常に最適とは限らない理由

乗車中の音声通話は通常短時間ですが、非常に即時性が求められます。乗客は「東口にいます」と伝えるだけかもしれませんし、ドライバーは「そこには停められません。50メートルほど前へ進んでください」と答えるだけかもしれません。こうした会話は特定の乗車に密接に結び付いており、通常はその乗車が有効な間だけ意味を持ちます。

一方、従来の携帯電話通話では、プラットフォームは重要なリアルタイムのやり取りの一つを実質的に外部の電話システムへ委ねることになります。アプリは予約、地図、決済、乗車状況を管理していますが、ユーザーが電話番号をタップした瞬間に、やり取りがアプリを離れ、端末標準の電話アプリへ移る場合があります。

この方法は単純ですが、いくつかの構造的な制約が生じます。

• 通信上の本人識別が実際の電話番号に結び付く。 番号マスキングなどのプライバシー保護層がなければ、乗客とドライバーが互いの個人携帯番号を知ってしまう可能性があります。

• 通話が業務フローから切り離される。  乗車画面から端末標準の電話アプリへ移ると、会話と進行中の予約との直接的なつながりが弱くなります。

• 国際通話料金が予測しにくい。 自国のSIMを使用する旅行者が現地ドライバーへ電話すると、ローミング料金や国際音声通話料金が発生する場合があります。

• 利用可否が通信事業者の音声サービスに依存する。  モバイルデータ通信が利用できていても、従来の音声ネットワークに問題があれば電話を発信できないことがあります。

VoIPはこの境界を変えます。音声はインターネット接続上でIPデータとして伝送されるため、相手の電話番号を使って従来型のPSTN通話や通信事業者の音声通話を確立する必要が必ずしもありません。

アプリ内VoIPは実際にどのような問題を解決するのか

ユーザーから見ると、この機能は単なる「通話」ボタンに見えるかもしれません。しかしプラットフォーム側から見ると、VoIPは通話の確立方法だけでなく、その会話がアプリそのものとどう結び付くかも変えます。

音声は従来の電話網だけに全面依存する必要がなくなる

VoIPはインターネット接続上で音声メディアを伝送します。モバイルデータ通信やWi-Fiで十分な接続品質が確保できれば、アプリは通信事業者の従来型音声サービスだけに依存せず、リアルタイム音声セッションを確立できます。

だからといって、VoIPがあらゆる状況で自動的により高い信頼性を持つわけではありません。通話品質は依然として遅延、ジッター、パケット損失、帯域幅、ネットワーク切り替えに左右されます。VoIPが提供するのは別の通信経路です。アプリで利用可能なデータ接続がすでにあるなら、音声も同じネットワーク環境を利用できる可能性があります。

国際通信で音声ローミング料金への依存を減らせる

これは旅行用途や世界各地で展開されるモバイルアプリで特に有効です。海外で自国のSIMを使う乗客が従来の電話網経由で現地ドライバーに電話すると、ローミング料金が発生する場合があります。

アプリ内VoIP通話は主にデータ通信を使用します。旅行者が現地のモバイルデータ、国際データプラン、またはWi-Fiをすでに利用できる場合、従来の国際音声通話と同じ方式で課金される必要はありません。データ通信料が発生することはありますが、料金体系は従来の音声ローミングとは異なります。

このためVoIPは、配車、旅行プラットフォーム、ホテルサービス、国際的なカスタマーサポートに特に適しています。音声通信は維持しつつ、その伝送と課金の仕組みを従来の電話網からアプリのデータ接続へ移すことができます。

通信をアプリ内に保てる

ユーザー体験の面では、個々のプロトコルやコーデックよりも、この点の方が重要なことがよくあります。

ユーザーは乗車画面を離れたり、電話番号をコピーしたり、端末標準の電話アプリへ切り替えたりする必要がありません。乗車状況、ドライバー情報、位置情報、音声通話の入口を同じ業務フローの中に置くことができます。

製品アーキテクチャの観点では、通信はアプリに付け足された外部機能ではなく、ネイティブな業務機能になります。

通話料金の低減より電話番号のプライバシーが重要になり得る理由

数分、長くても1時間程度で終わる取引のために、恒久的な個人電話番号を公開する必要は通常ありません。

乗客とドライバーが実際に必要としているのは、進行中の乗車中に会話できることです。互いの個人的な連絡先へ恒久的にアクセスできる必要はありません。

アプリ内VoIPは、このような一時的な通信関係に適しています。プラットフォームは個人の携帯電話番号を通信先として提示する代わりに、ユーザーアカウント、乗車ID、内部セッションIDなどを使って音声セッションを確立できます。

これは特にドライバーにとって有用です。ドライバーは毎日、多くの面識のない乗客と接する可能性があります。乗車のたびに個人電話番号が公開されると、プライバシー上のリスクが長期的に積み重なります。

同じ考え方は、配達員、フィールドサービス技術者、物流担当者、オンラインコンサルタントにも当てはまります。双方にはリアルタイム通信が必要ですが、その権限には明確な業務範囲と有効期限を設けるのが理想です。

VoIPがプラットフォーム機能になるとアーキテクチャはどう変わるのか

エンジニアリングの観点では、アプリ内VoIPはモバイルクライアントにマイク入力と音声再生を追加するだけの機能ではありません。安定した運用には、アプリの背後に完全なリアルタイム通信経路が必要です。

一般的なアプリ内音声アーキテクチャは、いくつかの論理コンポーネントに分けられます。

• モバイルクライアント：  発信・着信、マイク音声の取得、相手側音声の再生、スピーカーフォンやBluetoothヘッドセット切り替えなどの端末機能を処理します。

• IDと業務ロジック：   誰が誰に電話できるかを決定します。例えば、現在有効な乗車にひも付く乗客とドライバーだけに相互通話を許可できます。

• 呼制御：   通話確立、呼出、応答、終了、セッション状態を管理します。

• メディア伝送： リアルタイム音声を伝送し、ネットワーク越え、接続状態の変化、必要に応じたメディアリレーを処理します。

• メッセージングと通知：   モバイルOSのプッシュ通知機構と連携し、アプリがバックグラウンドでも着信側が着信通知を受け取れるようにします。

このアーキテクチャに必須の単一プロトコルはありません。SIP、WebRTC、その他のリアルタイム通信フレームワークを使用できます。業務プラットフォームにとってより重要なのは、ユーザーID、乗車の認可、音声セッションをどう結び付けるかという設計です。

乗車が終了したら、プラットフォームは乗客とドライバー間の直接通信権限を取り消せます。新しい乗車が始まれば、その業務関係のために新しい通信コンテキストを作成できます。電話番号を単純に保存して公開するよりも、明確なセキュリティ境界を設けやすい方式です。

この観点から見ると、VoIPの価値は単に「電話をデジタル化する」ことではありません。メッセージ、位置情報、決済、注文状態を管理するのと同じように、アプリが音声も管理できるようになります。

実用的なモバイルVoIPには「通話できる」以上の要件がある

製品デモでは、2台のスマートフォンで会話できればVoIPは完成したように見えるかもしれません。しかし実際のモバイルネットワークはそれほど予測可能ではありません。

ユーザーはWi-Fiから4Gや5Gへ移動したり、地下駐車場に入ったり、エレベーターホールへ移動したり、ネットワークのカバレッジ境界に達したりします。遅延は変化し、パケット損失が起こり、利用可能な帯域幅も瞬間ごとに変動します。

そのため成熟したモバイルVoIPシステムでは、次のような運用能力が重視されます。

配車サービスにはもう一つ重要な課題があります。双方が屋外にいて移動していることが多い点です。ドライバーの周囲にはエンジン音、交通騒音、風切り音があり、乗客は空港、鉄道駅、混雑した道路上にいる場合があります。

こうした環境では、単に最高の音声ビットレートを追求するよりも、音声明瞭度と弱いネットワーク環境での性能の方が重要なことが多くなります。

VoIPは通信の基準を電話番号から業務上のIDへ移しつつある

長期的な製品アーキテクチャの観点で見ると、アプリ内VoIPがもたらす最も重要な変化の一つは、音声がIPで流れることそのものではありません。「誰が誰と通信できるか」を制御するロジックを、電話番号から切り離せることです。

従来の電話システムでは、電話番号が本人識別の基準であると同時にルーティング先でもあります。番号を知っていれば、通常はその番号へ発信できます。

プラットフォームはまったく異なるモデルを採用できます。あるユーザーが別のユーザーの番号を知っているから通信を許可するのではなく、両者に現在有効な業務上の関係があるため、システムが通話を許可するという考え方です。

このモデルはプラットフォーム型サービスに特に適しています。配車サービスの利用、配送タスク、物流の出荷、診療予約、サービスチケットなどを、一時的な通信セッションの認可コンテキストとして利用できます。

取引が終了すれば、通信関係も同時に終了できます。

そのためモバイルアプリにおけるVoIPの役割は、電話料金の削減だけにとどまりません。音声、メッセージング、ユーザーID、業務状態を一つの通信モデルに統合する手段をプラットフォームへ提供します。

面識のない人同士を頻繁につなぐアプリでは、この一時的で制御可能な業務主導の通信モデルは、単に別の電話番号を公開する方式よりも長期的に適したアーキテクチャになり得ます。

よくある質問

アプリ内VoIPには従来型のIP PBXが必要ですか？

必ずしも必要ではありません。企業内線やSIPエンドポイントも管理する必要がある場合はIP PBXが有用ですが、モバイルアプリは専用RTCプラットフォーム、WebRTCアーキテクチャ、クラウド通信サービスを利用することもできます。

IP PBXが必要かどうかは、アプリからSIP電話、PSTN番号、コンタクトセンター、その他の企業向け音声システムにも接続する必要があるかどうかに大きく左右されます。

アプリがバックグラウンドで動作するとVoIP通話が複雑になるのはなぜですか？

モバイルOSはバッテリーとシステムリソースを節約するため、長時間のバックグラウンド動作を制限します。そのためVoIP着信では、アプリが常時動作している前提ではなく、プッシュ通知、OS標準の通話フレームワーク、アプリ側のセッション復旧を組み合わせる必要があります。

緊急通報にVoIPだけを使うべきですか？

多くの場合、一般用途のアプリ内VoIPサービスを既存の緊急通報システムの単純な代替にすべきではありません。緊急通信では、位置情報の取り扱い、発信者識別、ネットワーク障害時の可用性、地域の規制要件などが関係する場合があります。

標準的なアプリ内VoIPは、乗客とドライバーの通話、カスタマーサポート、現場作業員同士の連絡など、業務目的の通信により適しています。

自社モバイルアプリにVoIPを追加する企業は何を最初にテストすべきですか？

テストは基本的な通話確立だけで終えるべきではありません。弱いネットワーク、Wi-Fiとモバイル回線の切り替え、バックグラウンド着信、Bluetoothヘッドセット切り替え、エコー、道路騒音、長時間通話の安定性などを早い段階で評価する必要があります。

ラボ環境では完璧に動く通話でも、ユーザーが実際のモバイルネットワーク上を移動し始めると、まったく異なる挙動を示すことがあります。