911という番号は変わっておらず、緊急通報センターも稼働していましたが、一部の利用者は緊急通報を完了できませんでした。
2026年9月17日、カナダの一部地域で911サービスの断続的な障害が報告され、一部の無線通信およびVoIP利用者に影響しました。ノバスコシア州の緊急管理当局は、問題が州の911システムそのものではなく、通信事業者のネットワークに関係しているとみられると説明しました。911につながりにくい住民には、固定電話、Wi-Fi通話、別の通信事業者のネットワーク、または公表されている代替の緊急連絡先を利用するよう案内されました。
この事例は、見落とされやすい通信上のリスクを示しています。有効な緊急番号、登録済みのSIP電話、正常に稼働するIP PBX、運用中の911受信センターがそろっていても、緊急通報が必ず正常に成立するとは限りません。利用者が"911"をダイヤルしてからオペレーターが応答するまで、通話はローカル端末、アクセスネットワーク、通信事業者のインフラ、緊急通報ルーティング、公共安全の受信システムを経由する場合があります。その経路上のどこか1か所で障害が起きても、救助要請が中断される可能性があります。
サービス障害が明らかにしたエンドツーエンド通話経路の問題
発信者にとって911は3桁の番号にすぎません。しかしネットワーク側から見ると、複数の管理領域と技術領域を横断するリアルタイム通信経路です。
企業のVoIP電話を例に考えます。利用者が911をダイヤルすると、まず通話がローカル端末から外へ出る必要があります。企業のIP PBX、クラウド音声プラットフォーム、またはSIPトランクサービスは、それを緊急通報として認識し、設定済みの緊急通報ポリシーに従ってルーティングしなければなりません。その後、通信事業者が適切な緊急サービスネットワークへ通話を引き渡し、最終的にその地域を担当する公共安全応答拠点(PSAP)へ届けます。
各レイヤーは異なるシステムや組織によって管理されているため、障害の現れ方も異なります。ローカルネットワークの問題ではSIP登録失敗やメディア損失が起こることがあります。通信事業者側の問題では、通話拒否、タイムアウト、誤ったPSAPへの接続が発生する可能性があります。緊急サービスネットワークの問題は、通話の配送や処理方法に影響します。ただし利用者から見れば、いずれも同じように「911につながらない」という結果に見えることがあります。
カナダで発生した断続的な障害が特に参考になるのは、初期情報が州の911プラットフォームの故障ではなく、通信事業者ネットワークの問題を示していたためです。つまり企業側でPBX、SBC、インターネット接続が正常に動作していることを確認できても、緊急通報の失敗可能性を完全には排除できません。通信事業者と911ネットワークの間のルーティング経路も、エンドツーエンドの緊急通報可用性を構成する一部です。

VoIP緊急通報のリスクはインターネット障害だけではない
VoIPの信頼性を語る際、よくある懸念の一つが「インターネットが止まれば電話も使えなくなる」というものです。これは確かにリスクですが、911に関しては問題の一部にすぎません。
企業内のすべてが正常に見えることもあります。SIP電話は登録済みと表示され、内線同士の通話もでき、通常の外線通話も成立しているかもしれません。それでも911専用ルート、上位の通信事業者、または緊急サービスとの相互接続が利用できなければ、緊急通報は失敗する可能性があります。2026年9月のカナダの事例はこの依存関係を示しています。企業内の機器には明確なアラームがなくても、問題が通信事業者ネットワークのさらに上流に存在する場合があります。
もう一つのリスクは、電話の識別情報と物理的な所在地との関係です。通常の業務通話では主に「相手に連絡できるか」が重要ですが、緊急通報では「救援要員をどこへ派遣するか」も正しく判断できなければなりません。固定のオフィス電話は通常場所が変わりませんが、ソフトフォン、リモート勤務者、ノマディックVoIP利用者は、同じ企業アカウントを使いながら異なるインターネット接続からログインすることがあります。
従業員が今日はオフィス、明日は自宅、翌週は別の都市のホテルで仕事をすることもあります。緊急通報位置情報が常にオフィス住所に固定されていると、通話そのものは911システムに正常に入っても、PSAPが受信する位置情報が実際の緊急現場と一致しない可能性があります。指令業務では、この不一致によって警察、消防、救急の到着が遅れるおそれがあります。
したがって、VoIP緊急通報には少なくとも3つの独立した可用性要素があります。
通話到達性:911への通話を実際に確立できるか。
通話ルーティング:通話が正しい緊急サービス経路に入り、その場所を担当するPSAPへ届くか。
位置精度:PSAPが受信する位置情報が実際の緊急現場と一致しているか。
これらのいずれかで障害が起きれば、緊急通報の有効性が低下する可能性があります。
第2の緊急経路は同じ障害領域を避けるべき
ノバスコシア州の障害時に案内された代替手段は典型的です。固定電話、Wi-Fi通話、別の通信事業者のネットワーク、公表された代替緊急番号などです。いずれも同じ原則に基づいています。主経路が利用できない場合、同じ障害点に依存しない可能性のある別経路を用意します。
企業や公共施設では、この原則を明確な設計ルールにする必要があります。バックアップ経路の価値は、単に端末を増やすことではなく、主経路との共通依存を減らすことにあります。
一般的な例を考えます。ある施設が光ファイバーのインターネット回線、クラウドIP PBX、通信事業者AのSIPトランクを使用しています。その「バックアップ電話」が、同じスイッチ、同じインターネット回線、同じ音声通信事業者に接続された別のSIP電話にすぎないとします。端末は1台増えましたが、耐障害性はほとんど向上しません。光回線障害、通信事業者Aの障害、クラウドプラットフォーム障害が起きれば、両方の電話が同時に影響を受ける可能性があります。
より有効な第2経路は、異なる技術領域またはネットワーク領域から用意する必要があります。たとえば次のような方法があります。
主VoIP経路とは独立した携帯音声端末を確保し、必要に応じて主SIPトランク提供事業者とは異なる通信事業者を使用する。
制御室やセキュリティセンターに、複数の携帯通信事業者による通信サービスを用意する。
技術面と商用面の条件が許す場合、独立した通信事業者経由の固定音声経路を維持する。
911が利用できない場合の補助手段として、地域の警察、消防、医療機関が公表する直接の緊急連絡先を維持する。
産業施設や重要インフラでは、現場の緊急調整用として無線、SIPインターコム、またはローカル指令通信を維持する。
端末が異なるからといって、通信経路まで独立しているとは限りません。携帯電話がWi-Fi通話へ切り替わると無線アクセス方式は変わりますが、通話は同じ通信事業者のコアネットワークや同じ緊急通報インフラの一部を通る可能性があります。障害を本当に迂回できるかどうかは、障害の発生箇所によって決まります。
そのため緊急通信計画は、単純なバックアップ端末一覧だけでは不十分です。各通話経路について、通信事業者、インターネット回線、PBX、SBC、緊急ルーティングへの依存関係を整理し、共通する単一障害点を特定できるようにする必要があります。

企業の緊急通報計画では番号・場所・人を管理する必要がある
技術的な第2経路を用意しても、さらに問題が残ります。誰がそれを使うのか、いつ使うのか、そして利用者は何をすべきかをどう把握するのか、という点です。
多くの組織ではすでに、消防署の電話番号、警備室の番号、医療緊急連絡先、社内緊急内線などを管理しています。しかし、その情報が緊急対応マニュアルの37ページにしか記載されていなければ、強い緊張を伴う状況で従業員がすぐに見つけるのは困難です。
制御室、受付、セキュリティセンター、危険区域の当直場所、その他の重要ポジションでは、代替連絡先を固定された緊急通報計画に組み込む必要があります。通信機器の横に掲示したり、指令インターフェースに組み込んだりできます。変更内容は一元管理し、各番号の用途と対象エリアを明確にしておく必要があります。
位置管理は、複数拠点を持つ組織で特に重要です。本社向けに設計した911設定をすべての支店へそのままコピーすることはできません。ニューヨークのオフィスにあるSIP電話とロサンゼルスの倉庫にあるSIP電話が同じクラウドPBXへ登録されていても、それぞれの実際の設置場所に合った緊急通報位置情報が必要です。設定を誤ると、通話が誤ったPSAPへ送られたり、事故現場から数百マイル離れた住所が提示されたりする可能性があります。
ソフトフォンは利用者が移動するため、さらに扱いが難しくなります。同じ従業員が同じ企業IDを維持したまま、オフィス、自宅、別の都市から業務を行うことがあります。通常の通話なら同じ企業番号を使い続けられますが、緊急通報ではすべての利用者が常に本社にいると仮定できません。
したがって、位置情報を更新する仕組みが必要です。プラットフォームや規制要件に応じて、利用者による確認、ネットワークベースの位置情報、その他の対応方式を使って端末と現在位置を関連付けます。
内部通知も設計に含めるべきです。複数回線電話システムから誰かが911へ発信した場合、現場の警備、受付、当直担当者が誰が緊急通報を行い、どの場所から発信したかを把握できれば有効です。警察、消防、救急隊を入口で迎え、正しい建物、階、作業区域へ案内できます。多くのIP PBXやクラウド通信プラットフォームは、この目的のための緊急通報通知機能を何らかの形でサポートしています。
代替緊急番号は事前確認が必要
公表された代替緊急番号は、911サービスに障害があるときの実用的な選択肢になります。ただし企業にとっては、番号を壁に貼るだけで信頼できる緊急経路になるわけではありません。
各代替番号について、管理主体と利用範囲を明確にする必要があります。どの機関が管理しているのか。どの地域を担当しているのか。24時間対応しているのか。番号変更時は誰が更新するのか。どの従業員が利用を許可され、または利用を求められているのか。外線発信プレフィックスや特別なルーティングが必要か、といった点です。
企業のダイヤルプランは見落とされやすい技術項目です。一部の電話システムでは外線発信のために"9"を先にダイヤルする必要があります。別のシステムでは独自の短縮番号、番号変換、SIPルーティングルールが使われます。事故時に従業員が公表された緊急番号を入力した場合、PBXは想定どおりにその番号をルーティングできなければなりません。通常のサービスクラス制限、呼受付制御、不正利用防止ポリシーによって緊急連絡先が意図せずブロックされないようにする必要があります。
一方で、緊急連絡先を誤操作しやすいショートカットに割り当てるべきでもありません。緊急ではない通話を繰り返すと緊急サービスのリソースを消費し、実際のサービス障害中には特に大きな支障になります。
カナダの障害時には、サービス復旧を確認する目的だけで911へ電話しないよう住民に明確に案内されました。同じ原則は企業にも当てはまります。緊急通報テストは計画的かつ管理された形で実施し、実際の障害中に稼働中の911サービスへ繰り返し発信するべきではありません。
より適切なのは、音声サービス事業者、システムインテグレーター、適用される公共安全手順と連携してテストする方法、またはプラットフォームが提供するテスト機能を使って緊急通報位置情報、発信者番号、ルーティング動作を検証する方法です。対応している場合、テストサービスを利用すれば、実際の911運用に不要な負荷をかけずに緊急通報設定を確認できます。
受入試験は911が1回つながっただけで終わらせない
新しいVoIPシステムの運用開始時に、1台のオフィス電話から1回だけ緊急通報を行って接続を確認しても、証明できることはごく限られています。その時点の条件、その端末、その経路において、通話が緊急応答先へ到達できたことを示すだけです。
より完全な緊急通報の受入プロセスでは、異なる拠点、端末タイプ、障害条件を対象にする必要があります。
固定SIP電話では、電話の識別情報と物理位置が一致していることを確認します。リモートのソフトフォンでは、利用者が移動した際に位置管理プロセスが正しく機能するかをテストします。複数拠点システムでは、各施設からの通話が適切な地域の緊急サービスへ関連付けられることを確認します。複数の通信事業者またはSIPトランクがある場合、主経路が停止したときに911通話がどうなるかも定義する必要があります。自動でフェイルオーバーするのか、手動操作が必要なのか、代替経路では通話を完了できないのかを明確にします。
制御された障害シミュレーションは、コミッショニングで最も価値の高い項目の一つでありながら、見落とされやすい項目でもあります。主SIPトランクが利用できない場合の通常通話と緊急通報の動作、バックアップWANへ切り替わった後も緊急ルートが有効か、主PBXからバックアップサーバーへフェイルオーバーした後も緊急通報位置情報、発信者番号、ルーティングポリシーが維持されるかを検証できます。
代替通信手段も個別に検証する必要があります。端末にオンラインと表示されているだけでは、緊急通報を完了できる証明にはなりません。携帯電波の状態、通信事業者のエリア、SIMの状態、アカウント状態はいずれも実運用上の可用性に影響します。
実用的な受入チェックリストには、次のような項目を含められます。
各固定端末の緊急通報位置情報が物理的な設置場所と一致しているか。
異なる拠点からの通話が正しい地域の緊急サービスエリアに関連付けられているか。
主通信事業者が停止した後も独立した緊急連絡経路が利用できるか。
バックアップWANまたはSIPサーバーへのフェイルオーバー後も911ルーティングが正しいか。
地域の代替緊急番号が最新で、企業システムから正常に発信できるか。
重要ポジションの担当者が911につながらない場合の対応を理解しているか。
緊急通報が行われた際、警備または当直担当者へ適時に通知されるか。
ソフトフォン利用者が勤務場所を変更した際、緊急通報位置情報が更新されるか。
この断続的な911障害から得られる教訓は、VoIPが緊急通報に適さないということではありません。IP通信では、従来の電話では実現しにくい柔軟なルーティング、位置管理、緊急通知、複数のフェイルオーバー手段を提供できます。ただし、これらの機能は障害条件下で検証されて初めて、信頼できる緊急通信システムの一部になります。
最も危険な緊急通報設計の一つは、バックアップ機能がまったくないシステムではありません。独立したバックアップがあると全員が思い込んでいるにもかかわらず、実際の事故で主経路とバックアップ経路が同じ障害点を共有していたと判明するシステムです。

よくある質問
IP PBXが正常でも911が失敗するのはなぜですか?
IP PBXは緊急通報経路の一部分にすぎません。911通話は、SIPトランク、音声通信事業者、緊急通報ルーティングネットワーク、PSAPにも依存する場合があります。企業電話システムが正常でも、通信事業者と緊急サービスの間の全区間が利用可能であることを証明するものではありません。カナダの断続的な911障害は、ローカルシステムが稼働し続けていても、より上流の問題が緊急通報に影響し得る例です。
911サービスが停止した場合、Wi-Fi通話は信頼できるバックアップになりますか?
Wi-Fi通話は、携帯無線アクセスネットワークが利用できない、または品質が低下している場合に別のアクセス手段を提供できます。ただし障害を実際に迂回できるかは、問題がどこにあるかによって決まります。通信事業者のコアネットワークや緊急通報ルーティング基盤に問題がある場合、Wi-Fi通話も同じシステムの一部に依存している可能性があります。そのため、自動的に独立した第2の911経路とみなすのではなく、より広い緊急通信計画の一つの選択肢として扱う方が適切です。
企業ではバックアップ用の携帯電話1台で十分ですか?
バックアップ電話が主通信経路と同じ通信事業者や同じ障害領域を共有しているかによります。主VoIPシステムがSIPトランクに通信事業者Aを使い、バックアップ携帯電話も通信事業者Aを使っている場合、通信事業者側の緊急通報障害が両方に影響する可能性があります。重要施設では、バックアップ手段が本当に別の通信事業者、アクセスネットワーク、または通話経路を利用しているか確認する必要があります。
VoIP緊急通報設定で特に見落とされやすい項目は何ですか?
緊急通報位置情報は代表的な弱点です。複数拠点、リモートワーク、ソフトフォン環境では、企業IDは利用者とともに移動しても、物理的な緊急位置は独立して変化します。組織は、端末ID、緊急通報位置情報、利用者の実際の位置を一致させるプロセスを持つ必要があります。そうでなければ、緊急通報が正常に成立しても、救援要員が誤った住所へ派遣される可能性があります。
Becke Telcomは、IP PBXシステム、SIP電話、音声ゲートウェイ、SBC、ユニファイドコミュニケーション機器を提供し、企業、複数拠点、重要施設向けに主系・予備系の音声経路、ネットワーク冗長化、緊急通信アクセスのソリューションを提供しています。