> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/kn/architecture-and-design/bcdr-whitepaper.md). # ビジネス継続性と災害復旧ホワイトペーパー ## **はじめに** Zoomは、単一の統合プラットフォームを通じて、AIファーストのUnified Communications as a Service（UCaaS）およびContact Center as a Service（CCaaS）を提供しています。このドキュメントでは、Zoomのクラス最高のサービスと製品を支えるイノベーションとアーキテクチャについて詳しく説明し、UCaaSとCCaaS全体でエンドユーザーとITに一貫性があり、安全で管理しやすいエクスペリエンスを提供する方法を解説します。 ## **経験に基づく構築** Zoomのクラウドファーストのビジョンは、組織が従来のオンプレミスシステムのコストと複雑さを超えて移行するのに役立ちます。老朽化したスタックに機能を追加するのではなく、クライアント、メディアサービス、会議室システムにわたるフルスタックエンジニアリングに投資し、エンドツーエンドの品質、回復力、使いやすさを、一つのまとまりあるプラットフォームとして最適化してきました。その基盤となるのは、各OSのネイティブUXを活用する、プラットフォーム間で共通のコードベースを持つシングルクライアント戦略です。 このクラウドファーストのアプローチは、Zoom Workplaceアプリに表れています。これは、ユーザーにMeetings、チャット、Phone、コンタクトセンター、Events、Webinars、Rooms、ホワイトボード、Canvasなどへの一元的なアクセスを提供する、単一のモダンなアプリケーションです。アクセスはライセンスによって管理されるため、IT部門は個別のインストーラーの寄せ集めを展開したり、競合するクライアントバージョンを管理したりすることなく、製品や機能を有効または無効にできます。 IT部門にとって、このモデルはオーバーヘッドを削減します。購入、ラック搭載、パッチ適用が必要なサーバーが減り、維持すべき個別対応の統合が減り、オンプレミスインフラの稼働維持に専任チーム全体を置く必要もありません。定員、更新、セキュリティの改善はクラウドから提供されるため、管理者はメンテナンスではなく、ポリシー、導入、成果に集中できます。 ## リアルタイムメディアのアーキテクチャと回復力 以下のセクションでは、クラス最高のリアルタイムメディアエクスペリエンスを実現するためのZoomの設計アプローチについて説明します。 ### Zoom Meetings、Webinars、Events 当社のアーキテクチャの基盤は、実際のネットワーク状況とポリシーに基づいて最適な経路を選択するインテリジェントなトランスポート層です。利用可能な場合はUDPを使用し、より制限の厳しい環境ではTCP/TLS（HTTPS/443を含む）へシームレスにフォールバックします。画面共有では、可能な限り滑らかな動きを実現するためにReliable UDPを使用し、必要に応じて自動的にフォールバックします。ミーティング、ウェビナー、またはイベントに接続中、Zoom Workplaceアプリは、遅延を最小限に抑えるため、位置情報に基づいて最寄りのオンラインリソースへ誘導されます。組織のポリシーまたはパフォーマンス上必要な場合、トラフィックは専用リンクを介してZoomのグローバルバックボーンを通り、異なるデータセンターへ送られることがあります。
Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers.

Zoomのミーティング、ウェビナー、およびイベントのアクティブ-アクティブ アーキテクチャと設計の概要。

次へのレイヤーは、リアルタイムのネットワークおよびデバイスの状態に適応する反応型の品質・サービス・レイヤーです。帯域幅、パケット損失、遅延、ジッターを監視し、ローカルのCPU使用率、メモリ、ネットワークI/Oも収集します。これらのシグナルは、品質と信頼性を維持するために適切な適応アクションを上位レイヤーが取るように促します。 Zoomのカスタムで適応型のコーデックは、セッション層でリアルタイム性能に最適化されています。周囲のアルゴリズムは、デバイスとネットワークの条件に合わせてフレームレートと解像度を継続的に最適化します。条件が許可する限り最良の体験を提供するために、Zoomは複数の同時ストリームを使用し、Zoom Workplace アプリが最適なレイヤーを動的に選択します。効率的な圧縮のおかげで、セッションは約45%までのパケット損失があっても使用可能なままです。そのような場合は、会話を明瞭に保つために、ビデオよりもオーディオが優先されます。マルチストリームのアプローチは、オーディオとビデオを送受信する各参加者の能力に応じて帯域幅も調整します。 Zoomの分散型会議レイヤーは、サーバー側でのトランスコーディングやミキシングを行わない、サブスクリプションベースのスイッチングを使用しています。従来のサービスでは、ストリームをトランスコードしてミックスすることが多く、CPUとメモリのオーバーヘッドが増加します。当社のスイッチング方式は、リソース使用量を削減し、効率的にスケールできるよう設計されています。参加者は、地理的位置に基づいて最寄りのデータセンターにルーティングされ、最も負荷の低いサーバーに割り当てられます。参加者が同じ場所にいる場合は、効率化のため同じサーバーにまとめることができます。このアーキテクチャは、柔軟なオンプレミスおよびハイブリッド展開をサポートし、大企業向けにカスケード型のトラフィック経路を提供します。 会議サーバーは当社のMMR（マルチメディア・ルーター）であり、各MMRは「Meeting Zone」にグループ化されています。Zone ControllersはすべてのMMRを管理し、各Meeting Zoneごとに、そのステータスをGlobal Cloud Controllerに報告します。Meeting Zonesは各データセンターごとに、まったく同一のアーキテクチャで複製されており、各リージョンで追加の定員を得るために、必要に応じてゾーンをすぐに追加できます。3つの層（MMR、Zoom Controller、Global Cloud Controller）は、異なる場所でのリソースのバランスを取るために使用されます。会議に参加者が2名だけの場合、Zoomは優れた速度と信頼性のためにピアツーピア接続を利用できます。これらすべてにより、Zoomは会議サービスの可用性99.9%の稼働（稼働率）を維持し、信頼できるビデオ会議体験を提供できます。 ### Zoom Phone Zoom Phoneはクラウド上に、そしてクラウド向けに構築されており、当社のZoom MeetingsおよびWebinars製品ですでに利用可能な、実証済みのオーディオ品質の調整機能を活用しています。Zoomのアーキテクチャには冗長性と回復力が組み込まれているため、非常に高可用性のソリューションとなっており、最大規模の組織のニーズでさえ満たせるように拡張できます。 Zoom Phone は、さまざまなネットワーク環境にわたって信頼性の高い接続を実現するために、インテリジェントなトランスポート機構を利用しています。メディアについては、オンラインの場合は UDP 上の SRTP を使用し、TCP/TLS へシームレスにフォールバックします。さらに、適応ビットレートとパケット損失の軽減により、低品質な環境でもオーディオ品質を維持します。接続については、通話を最寄りのオンライン SIP Zone にルーティングして遅延を最小限に抑え、必要に応じてデータセンター間で自動フェイルオーバーを行います。
Diagram showing a Zoom Phone device connected to a primary data center, with a secondary connection to an additional data center for failover events.

Zoom Phoneのアクティブ-アクティブアーキテクチャ

Zoom は各データセンターに冗長化されたセッション境界コントローラー（SBC）を備えており、クライアントとキャリアの通信を保護しています。これらのキャリアグレード SBC により、最小規模の お客様の声 からグローバル企業まで、幅広い組織が容易に アクセス できます。ロードバランサーは SIP ベースの通信を Zoom の通話スイッチにリダイレクトし、通話量を均等に分散します。この分散により、登録のピーク時や 通話中 の多い時間帯でも、ユーザーはスムーズな体験を得られます。 通話スイッチは、Zoom Phoneの中核となる通話制御です。これらのスケーラブルなコンポーネントは、PBXの基本機能をサポートするだけでなく、テレメトリデータをZoom Phoneダッシュボードに提供し、Zoom Phoneの通話をZoom Meetingsに昇格させる機能などを有効にします。
A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center

データセンター内でホストされる、ハードウェアおよびSIPゾーン向けのアクティブ-アクティブアーキテクチャ

Zoom Workplaceアプリは独自ロジックを活用して、アプリの帯域幅、パケット損失、遅延、ジッターを監視するとともに、アプリのCPU使用率、メモリー、ネットワークI/Oも収集します。この技術は通話を積極的に監視し、ネットワーク環境が悪い状況を克服するためにリアルタイムで調整を行うことで、さまざまなネットワーク環境や異なるデバイスに対して、優れた通話品質と信頼性を提供します。 Zoom Phoneダッシュボードは、リアルタイムおよび履歴のクオリティオブサービスデータに加え、利用状況と採用の指標、通話ログ、ならびにノマディック緊急通報サービスに関連する指標を取得します。Zoomは各通話を自動的に平均オピニオン評点 (MOS) で評価し、IT管理者がネットワークを通過するすべての通話のパフォーマンスを追跡し、潜在的なネットワーク関連の問題を切り分けられるようにします。
### Zoom コンタクトセンター Zoom Phoneと同様に、Zoom コンタクトセンターのアクティブ-アクティブアーキテクチャは、オムニチャネル環境全体で耐障害性と冗長性を提供するのに役立ちます。Zoom MeetingsとZoom Phoneサービスで実績のあるアーキテクチャを基盤に、コンタクトセンターはリアルタイム通信機能とWeb機能をシームレスに統合し、エージェントチームとお客様の双方にメリットのある直感的なインターフェースを実現します。 各データセンターには、相互接続された同一の2つのセッション開始プロトコル (SIP) ゾーンがあります。SIPゾーンにより、インターネット経由で音声通話の発着信が可能になり、各ゾーンには独立した継続性を確保するための専用ハードウェアとサービスが備わっています。データセンター内では、ロードバランサーが両方のSIPゾーン間で通話を均等に分散します。通話は通話スイッチのクラスタ間で分散され、そこではコールルーティング、セットアップ、切断などのさまざまな機能が担当されます。 通話スイッチから、通話は各ゾーン内のSBCに接続され、そこからZoomの基盤となるプロバイダー・ネットワーク、またはお客様が提供するキャリアへ接続され、通話が最終目的地に到達するまでPSTNルーティングが行われます。SBC、ロードバランサー、および通話スイッチには、耐障害性のために待機中の冗長ハードウェアが追加されています。 Zoom コンタクトセンターの音声は、Zoom Phoneと同じクライアント適応およびトランスポート動作の恩恵を受けます。UDPがオンラインの場合はTCP/TLSにフォールバックし、制約のあるネットワークでもオーディオはクリアに保たれます。ビデオおよびデジタルチャネルでは、このサービスはZoomのリアルタイムメディア基盤とクラウドの耐障害性を活用し、一貫した品質とフェイルオーバーを実現します。 #### コブラウズ Zoomコンタクトセンターのコブラウズサービスは、中核となるZoomコンタクトセンターサービスとは分離されたインフラストラクチャ上で稼働します。セッションが開始されると、ソフトウェア開発キット（SDK）は双方向通信のためにコブラウジング・ハブ・サーバー（CHS）への永続的なWebSocket接続を確立します。トラフィックは、レイテンシーを低減するために地理的位置に基づいて最寄りのオンラインのデータセンターへルーティングされます。このサービスは、CHSノード全体で動的な負荷分散を行うステートレスな分散アーキテクチャを使用し、クラウド、ハイブリッド、およびオンプレミスのデプロイメントモデル全体での弾力的なスケーリングをサポートします。 セッションの継続性を維持するために、接続が中断された場合、SDKは正常なCHSノードに自動的に再接続し、最小限の中断でデータセンター間のフェイルオーバーを行えます。継続的な健全性監視と、Zoomのより広範なアクティブ-アクティブのレジリエンシーアプローチを組み合わせることで、このアーキテクチャはエンタープライズ環境向けに、信頼性と拡張性に優れたコブラウジングのパフォーマンスを提供するよう設計されています。

データセンター内でホストされるコブラウズSDKゾーン向けのアクティブ-アクティブアーキテクチャ

## **ハイブリッドおよびオンプレミスのデプロイメント向けZoom Node** [Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) は、データセンターのリソースをZoomのクラウドと接続するクラウド管理型ハイブリッドプラットフォームであり、オンプレミスにZoomサービスモジュール（ワークロード）をデプロイし、Zoomウェブポータルから管理できます。レジリエンシーの点で注目されるモジュールは、Zoom Meetings HybridとZoom Phone Local Survivability（ZPLS）の2つです。 [Zoom Meetings Hybrid](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) は、シグナリング、管理者、およびポリシーをZoomクラウドに維持したまま、内部参加者向けのリアルタイムメディアをローカルNode経由でルーティングし、Zoomのデータセンターに到達できなくなった場合に備えたローカルのサバイバビリティオプションも含まれています。内部ユーザーは低レイテンシーの経路とインターネット出口トラフィックの削減を得られ、外部参加者は通常どおりクラウド経由で参加できます。必要に応じて、アカウントにローカルキャプチャ用のRecording コネクタを追加することもでき、ローカルの定員がオンラインでない場合は自動的にクラウドへフェイルオーバーします。
Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud.

Zoom Meetings Hybrid Moduleは、ローカル
ネットワーク内のユーザーがHybrid MMRに接続し、クラウドへカスケードする仕組みを示します。

[Zoom Phone Local Survivability](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) (ZPLS) は、WANまたはプロバイダ経路が停止した場合でも、サイトでコア通話をオンラインに保ちます。電話機はローカルに登録され、内線通話は継続し、構成されている場合は、重要な発信通話をオンプレミスのPSTN経路を通じて維持できます。接続が戻ると、サービスは自動的に通常のクラウド運用に戻ります。
Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability.

Zoom Phone Local Surviability は、PSTNおよび
サイト間接続に対する複数のフェールバックシナリオを、サービスに影響を及ぼすイベントが発生した場合にサポートします。

## **グローバルに分散したデータセンターと冗長性** Zoom は、世界中の複数の相互接続されたデータセンターにブローカーと通信サーバーを分散配置しています。当社は、帯域幅、レイテンシー、災害復旧分離の観点からお客様の声向けのパフォーマンスを最適化するため、データセンターとインターネットサービスプロバイダー（ISP）を継続的に評価しています。当社のデータセンターは、ISPキャリア中立で、物理セキュリティ、冗長電源、上位ISPおよびピアリングパートナーへの同時アクセスを提供する安全なコロケーション施設に設置されています。また、地域要件または定員要件が必要となる場合には、パブリッククラウドプロバイダー上で一部の展開を行っています。当社のコロケーション施設は、完全な冗長性と迅速なフェイルオーバー機能を備えたフォールトトレラントアーキテクチャで構築されています。Zoom は動的に通信サーバーの負荷分散を行い、最も応答時間のよいデータセンターへ新しいセッションを自動的に移動します。 これらの施設は、物理層におけるレジリエンスも考慮して設計されています。各コロケーション施設は、N+1冗長構成と、コンポーネント障害や物理的危険が発生しても施設の稼働を維持することを目的とした一連の環境制御を備えています: * 温度および湿度の制御 * コンポーネント障害に対応できるようにスケールされ、完全に冗長化された電源システム * 耐障害性のある非常照明 * 防火対策 * 水害対策 データセンターには、N、N+1、または2Nといった無停電電源装置（UPS）の冗長モデルや、N+1設計を用いた発電機の冗長構成が含まれ、電源の保守およびテストは該当するデータセンタープロバイダーが担当します。Zoom がクラウド インフラストラクチャの一部をホストするために AWS を使用している場合、AWS の管理策の存在および運用は、外部サービス監査人の報告書を通じて Zoom のセキュリティチームが毎年レビューします。特定された例外は AWS と協議され、Zoom のシステムまたはデータにリスクを提示する場合は Zoom の経営陣へエスカレーションされます。

Zoomの世界各地の商用データセンター所在地（2026年9月）

## **定員** Zoom は、成長するビジネスに対応し、ピーク時の利用要件を満たすために、インフラストラクチャのあらゆる側面で 50% の余剰定員を維持しています。現在および将来の顧客ニーズに基づき、サービスを提供し拡張できると確信しています。 ## **ビジネス継続性と災害復旧** 通常条件下での信頼性は物語の一部にすぎません。同様に重要なのは、何か問題が起きたときにプラットフォームがどのように動作するかです。自然災害、電源や施設の障害、サイバーインシデント、ネットワーク停止、ハードウェア障害などの中断は、あらゆるグローバルサービスにとって避けられない現実であり、Zoom のレジリエンスは、これらの事象に備え、耐え、回復する方法にあります。そのレジリエンスは、異なるものの相互に連結した4つの層に支えられており、それぞれが中断の前、最中、後の異なる時点で機能します: * **高可用性** — 単一障害点を排除することで、障害が発生する前にその発生可能性と影響を低減するアーキテクチャ層です。 * **ビジネス継続性** — 中断が実際に発生した際に、重要なビジネス機能を稼働し続ける運用層です。 * **災害復旧** — 影響を受けた技術システムとサービスを、混乱を引き起こすイベントの後に通常運用へ戻す復旧レイヤーです。 * **テスト** — これらの実践が機能することを確認し、継続的改善のための学びを明らかにする検証レイヤーです。 これらのレイヤーは相互に積み重なっています。高可用性は復旧が必要になる頻度を下げ、ビジネス継続はその間に何を稼働させ続けるかを管理し、災害復旧は影響を受けたものを復元し、テストは全体を検証します。このドキュメント全体で説明されているアーキテクチャ — アクティブ-アクティブのデータセンター、地理位置情報ベースのルーティング、自動フェイルオーバー、N+1デプロイメント — は、実際の高可用性レイヤーです。以下のセクションでは、残りの3つを説明します。 ### 高可用性 高可用性とは、継続的な運用と最小限のダウンタイムを支援することを目的としたシステムおよびサービスの設計を指し、重大な障害点を最小化または排除することを目標に、Zoom のシステムに組み込まれています。サービスはデータセンター全体の障害に耐えられるように設計されており、障害が発生すると自動化プロセスがトラフィックを影響を受けた領域から移動させます。コアアプリケーションは N+1スタンダードに基づいて展開されているため、データセンターが利用不能になっても、残存サイトへトラフィックをロードバランスするのに十分な定員が残ります。この設計思想は、通信プラットフォームが依存するシステム一式全体に及びます。つまり、冗長化された設備、テレフォニー基盤、インターネットおよび LAN 接続、セキュリティ基盤、リレーショナルデータベースシステム、大容量ストレージ、バックアップ、ハードウェア、そして関連する定員管理および保守の実践です。これにより、いずれか単一のコンポーネント、システム、または設備が故障しても、サービスの喪失にはつながりません。 ### ビジネス継続性 Zoom のビジネス継続計画は、業務に対する障害の影響を最小化し、資産を保護し、お客様やステークホルダーに対する重要なサービスを維持するよう設計されています。まず保持または復旧しなければならないビジネス機能、それらの機能が依存する人員、技術、ベンダー、職場リソース、そしてそれらの依存関係が妨げられた場合の潜在的な影響を特定します。これにより、通常運用が影響を受けたとき、特に複数の機能やリソースに同時に対応が必要な場合でも、Zoom は対応と復旧を体系的に調整するための基盤を得られます。 この計画の基盤となるのがビジネス影響分析（BIA）であり、Zoom が重要なビジネス機能に対する障害の潜在的影響を特定・評価するために用いる体系的なプロセスです。Zoom は、重要な機能について少なくとも年1回、または重要なビジネスプロセスに重大な変更があった場合に BIA を実施します。この分析は、次の4つの主要な構成要素をカバーします： 1. **重要なビジネス機能の特定** — Zoom の運用に不可欠な主要プロセスをドキュメント化し、それらの依存関係および相互依存関係を特定すること。 2. **影響評価** — 各機能に対する混乱の潜在的な影響を評価し、財務損失、業務停止、法的・規制上の影響、評判への損害を考慮する。 3. **リソース要件** — 復旧を支援するために必要な人員、テクノロジー、施設、および第三者サービスを特定し、それらの可用性と十分性を評価する。 4. **復旧作業の優先順位付け** — その影響と設定された復旧目標に基づいて重要機能の復旧順序を決め、最も重要な機能を最初に回復するようにする。 ### 災害復旧 Zoomは、製品全体にわたる年次テストを通じて、災害復旧機能を定期的に検証しています。同社は、混乱後に重要なシステムおよびサービスを復旧するための手順、復旧戦略、役割と責任、および通信プロトコルを定義した、正式な文書化済みの災害復旧計画（DRP）を維持しています。ZoomのDRPは、停電、ネットワーク接続の喪失、ハードウェア障害、自然災害、その他の混乱事象、さらには施設全体の障害を含む、またはそれに至る可能性のあるさまざまな災害シナリオに対処するよう設計されています。災害復旧を統括する情報セキュリティ基準は、文書化され、承認され、周知され、少なくとも年1回見直されています。 クラウドサービスのために専用のホット復旧サイトを維持する代わりに、Zoomは冗長アーキテクチャ、複数拠点のデータセンター、およびAWS、OCI、GCPを含む複数のクラウドプロバイダーに依存して継続性を支えています。プラットフォームレベルでは、復旧パターンはサービス種別によって異なります: * **Webクラスタおよび非リアルタイム通信** AWSの高可用性インフラをマルチリージョンのアクティブ・アクティブ構成で使用し、DNSレコードを利用してデータセンター間のフェイルオーバーを有効にし、各データセンター内で複製機能を持つ複数のコンポーネントを含みます。 * **地域のデータセンターとリアルタイム通信** 地理的に分散したTier 3以上のプロバイダー全体でアクティブ-アクティブ構成で稼働し、各地域のデータセンター内には冗長かつレジリエントなコンポーネントと接続性があり、多様なキャリアが接続性を支え、リージョン間のフェイルオーバーでは再接続が必要になります。 Zoomの文書化された復旧戦略には、影響を受けたリージョンからトラフィックまたはサービスを切り替えるリージョンフェイルオーバーと、ソフトウェアまたはデプロイ関連の問題から回復するために、サービスを以前に正常であることが確認された環境またはデプロイ状態に戻すブルーグリーンデプロイによるロールバックが含まれます。 これらの戦略は、定義された復旧目標に照らして測定されます。復旧時間目標 (RTO) — 障害後にサービスを復旧するまでの目標時間 — は5分未満を目標としています。復旧ポイント目標 (RPO) — 許容されるデータ損失量の目標 — はデータ損失ゼロを目標としており、複数のアベイラビリティゾーンにわたるクラウドに保存されたデータの複製によって支えられています。これらの目標は、サービス保証として機能するのではなく、Zoomの設計とテストに反映されています。 効果的なデータのバックアップと復元はこのアプローチの中核を成す要素であり、重要な情報を保護して、障害が発生した場合に復元できるようにし、事業継続を維持します。Zoomは、完全な災害復旧計画や詳細なテスト結果を外部には共有していません。これらの資料には、社内の機密性の高い機密業務情報が含まれているためです。以下を参照してください。 [Zoomのトラストセンター](https://www.zoom.com/en/trust/legal-compliance/) 公開されているドキュメントの詳細については。 ### テスト Zoomは、第三者監査人によって実施される年次の机上演習およびフェイルオーバーテストを通じて、復旧手順を検証しています。このテストにより、対応および復旧プロセスが意図どおりに機能することが確認され、ギャップが特定され、得られた教訓を通じた継続的な改善が支えられます。テストは、Zoom Meetings、Zoom Phone、Zoom コンタクトセンター、Zoom Virtual Agent、Zoom Rooms、Zoom Events、ホワイトボード、ワークスペース予約、RTC ゲートウェイおよびテレフォニーゲートウェイなど、プラットフォーム全体にわたる幅広い製品およびサービス領域を対象としてきました。本ドキュメント全体で説明している冗長なアクティブ-アクティブアーキテクチャと組み合わせたこの多層的アプローチは、幅広い障害条件下でも Zoom のサービスを利用可能かつ復旧可能に保つよう設計されています。 ## **結論** Zoom の信頼性は、クラウドファーストのサービス設計、適応型メディアルーティング、冗長なグローバルインフラストラクチャ、定員計画、そして正式な事業継続および災害復旧の実践を組み合わせた多層アーキテクチャによって支えられています。Zoom Meetings、Zoom Phone、コンタクトセンター、Zoom Node、世界各地のデータセンター、および関連サービス全体にわたり、Zoom のプラットフォームは、多様なネットワーク、リージョン、デバイス、デプロイモデルにまたがって一貫した通信を支援するよう設計されています。 日々のサービス品質をサポートするのと同じ設計原則は、大規模環境でのレジリエンスもサポートします。アクティブ-アクティブアーキテクチャ、インテリジェントなルーティング、適応型トランスポート、冗長化された設備、復旧計画、バックアップ手順、定期的なテストが連携し、運用上の事象が発生した際に、重要なサービスの維持と復旧をサポートします。 顧客とITチームにとって、このアプローチは、信頼性の高いコミュニケーション、運用の継続性、そしてUCaaSおよびCCaaS環境全体で管理しやすいエンタープライズ展開のために設計されたプラットフォームを提供します。 *Jakob Ganschow と Sam Azimipour による執筆* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/ja/kn/architecture-and-design/bcdr-whitepaper.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.