> 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のクラウドファーストのビジョンは、組織がレガシーなオンプレミスシステムのコストと複雑さを超えて進むのに役立ちます。老朽化したスタックに機能を追加するのではなく、クライアント、メディアサービス、ルームシステムにわたるフルスタックエンジニアリングに投資し、エンドツーエンドの品質、レジリエンシー、使いやすさを1つの一貫したプラットフォームとして最適化してきました。その基盤となるのは、各OSのネイティブUXを活用し、プラットフォーム間で共通のコードベースを使用する単一クライアント戦略です。 このクラウドファーストのアプローチは、Zoom Workplace アプリに表れています。これは、ユーザーにMeetings、チャット、Phone、コンタクトセンター、Events、ウェビナー、Rooms、ホワイトボード、Canvasなどへの一元化されたアクセスを提供する、単一のモダンなアプリケーションです。アクセスはライセンスによって管理されるため、ITは個別のインストーラーを寄せ集めて展開したり、競合するクライアントバージョンを管理したりすることなく、製品や機能をオンまたはオフにできます。 ITにとって、このモデルは運用負荷を軽減します。購入、設置、パッチ適用が必要なサーバーが減り、保守すべき個別対応の統合も減り、オンプレミスインフラの稼働維持に専任チーム全体を割り当てる必要もありません。定員、更新、およびセキュリティの改善はクラウドから提供されるため、管理者は保守ではなく、ポリシー、導入、成果に注力できます。 ## リアルタイムメディアのアーキテクチャとレジリエンシー 以下のセクションでは、クラス最高のリアルタイムメディア体験を有効にするためのZoomの設計アプローチについて説明します。 ### Zoom Meetings、ウェビナー、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のミーティング、ウェビナー、Eventsにおけるアクティブ-アクティブアーキテクチャと設計の概要。

次のレイヤーは、リアルタイムのネットワークおよびデバイスの状態に適応する、リアクティブなサービス品質レイヤーです。帯域幅、パケット損失、レイテンシー、ジッターを監視し、ローカルのCPU使用率、メモリ、ネットワークI/Oも収集します。これらのシグナルは上位レイヤーに通知され、品質と信頼性を維持するために適切な適応型アクションを実行します。 セッションレイヤーにあるZoom独自の適応型コーデックは、リアルタイムのパフォーマンス向けに調整されています。周辺のアルゴリズムは、デバイスとネットワークの状態に合わせてフレームレートと解像度を継続的に最適化します。状況が許す限り最良の体験を提供するため、Zoomは複数の同時ストリームを使用し、Zoom Workplace アプリは最適なレイヤーを動的に選択します。効率的な圧縮により、パケット損失が最大約45%の場合でもセッションは利用可能な状態を維持します。このような場合、会話を明瞭に保つため、ビデオよりもオーディオが優先されます。マルチストリームのアプローチでは、各参加者のオーディオとビデオの送受信能力に応じて帯域幅も調整されます。 Zoomの分散型会議レイヤーでは、サーバー側でのトランスコーディングやミキシングを行わない、サブスクリプションベースのスイッチングを使用します。従来のサービスでは、ストリームのトランスコーディングとミキシングによってCPUおよびメモリのオーバーヘッドが増加することがよくありますが、当社のスイッチングアプローチは、リソース使用量を削減し、効率的に拡張できるよう設計されています。参加者は地理的位置に基づいて最も近いデータセンターにルーティングされ、負荷が最も低いサーバーに割り当てられます。出席者が同じ場所にいる場合は、効率化のために同じサーバー上でグループ化できます。このアーキテクチャは、柔軟なオンプレミスおよびハイブリッド展開をサポートし、大企業向けにカスケード型トラフィックパスを提供します。 ミーティングサーバーは当社のMMR（マルチメディアルーター）であり、各MMRは「ミーティングゾーン」にグループ化されています。ゾーンコントローラはすべてのMMRを管理し、各ミーティングゾーンのステータスをグローバルクラウドコントローラに報告します。ミーティングゾーンは、まったく同じアーキテクチャで各データセンターに複製されており、各リージョンで定員を追加するために必要に応じてゾーンを簡単に追加できます。3つのレイヤー（MMR、Zoom コントローラ、グローバルクラウドコントローラ）は、異なる場所にあるリソースのバランスを取るために使用されます。ミーティングの参加者が2人だけの場合、Zoomは優れた速度と信頼性を実現するためにピアツーピア接続を利用できます。これらすべてにより、Zoomは99.9%の稼働率でミーティングサービスの可用性を維持し、信頼性の高いビデオ会議体験を提供できます。 ### Zoom Phone Zoom Phoneは、クラウド上でクラウド向けに構築されており、当社のZoom MeetingsおよびWebinars製品ですでに利用可能な、実績のあるオーディオ品質適応機能を使用しています。Zoomのアーキテクチャには冗長性と耐障害性が組み込まれており、最大規模の組織のニーズにも対応できる、拡張性に優れた高可用性ソリューションを実現します。 Zoom Phoneは、多様なネットワーク環境で信頼性の高い接続を実現するために、インテリジェントなトランスポートメカニズムを利用します。メディアには、利用可能な場合はUDP経由のSRTPを使用し、TCP/TLSへのシームレスなフォールバックに加え、劣悪な条件下でもオーディオ品質を維持するための適応型ビットレートとパケット損失軽減機能を使用します。接続については、レイテンシーを最小限に抑えるために通話を最も近い利用可能なSIPゾーンにルーティングし、必要に応じてデータセンター間で自動フェイルオーバーを行います。
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ミーティングに昇格させるような機能を有効にします。
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およびPhoneサービスで実証済みのアーキテクチャを基盤に、コンタクトセンターはリアルタイム通信機能とWeb機能をシームレスに統合し、エージェントチームとお客様の声の双方にメリットをもたらす直感的なインターフェースを実現します。 各データセンターには、同一で相互接続された2つのSession Initiation Protocol（SIP）ゾーンがあります。SIPゾーンでは、インターネット経由で音声通話の発信と受信が可能で、各ゾーンには独立した継続性のための専用ハードウェアとサービスが備わっています。データセンター内では、ロードバランサーが2つのSIPゾーン間で通話を均等に分散します。通話は通話スイッチのクラスターに分散され、そこではコールルーティング、セットアップ、切断などのさまざまな機能が担われます。 通話スイッチから、通話は各ゾーン内のSBCに接続されます。SBCは、通話が最終目的地に到達するまで、Zoomの基盤となるプロバイダーネットワークまたはお客様提供のキャリアのいずれかに接続し、PSTNルーティングを行います。SBC、ロードバランサー、通話スイッチには、レジリエンスのために待機中の冗長ハードウェアが補完されています。 Zoom コンタクトセンターの音声は、Zoom Phoneと同じクライアント適応およびトランスポート動作の恩恵を受けます。UDPがオンラインで使える場合は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 Service Modules（ワークロード）をオンプレミスに導入し、Zoomウェブポータルから管理できるようにします。耐障害性の面では、Zoom Meetings Hybrid と Zoom Phone Local Survivability（ZPLS）の2つのモジュールが際立っています。 [Zoom Meetings ハイブリッド](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) 内部参加者向けのリアルタイムメディアをローカルのNode経由でルーティングし、シグナリング、管理者、ポリシーはZoomクラウドに残したままにします。また、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モジュールは、ローカル
ネットワークのユーザーがHybrid MMRに接続し、クラウドへカスケードする様子を示します。

[Zoom Phone ローカル耐障害性](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商用データセンター所在地（2024年11月）

## **定員** Zoomは、成長するビジネスに対応し、ピーク時の利用要件を満たすため、インフラのあらゆる側面で50%の余剰定員を維持しています。私たちは、現在および将来のお客様のニーズに基づいて、サービスの提供と拡張を行う能力に自信を持っています。 ## **ビジネス継続性と災害復旧** 通常時の信頼性は物語の一部にすぎません。同様に重要なのは、何か問題が起きたときにプラットフォームがどのように動作するかです。自然災害、電源や施設の障害、サイバーインシデント、ネットワーク障害、ハードウェア障害などの混乱は、あらゆるグローバルサービスにとって避けられない現実であり、Zoomのレジリエンスは、こうした事象に対してどのように準備し、耐え、回復するかに由来します。そのレジリエンスは、異なるものの相互に連結した4つの層に支えられており、それぞれが障害の前、最中、後の異なる時点で機能しています： * **高可用性** — 障害が発生する前に、単一障害点を排除することで、障害の発生可能性と影響を低減するアーキテクチャ層。 * **ビジネス継続性** — 障害が実際に発生したときに、重要なビジネス機能を稼働し続けさせる運用層。 * **災害復旧** — 影響を受けたテクノロジー システムとサービスを、障害イベントの後に通常運用へ戻す復旧層。 * **テスト** — これらの実践が機能していることを確認し、継続的改善のための学びを洗い出す検証層。 これらの層は互いに積み重なっています。高可用性は必要となる復旧の頻度を下げ、ビジネス継続性はその間も稼働し続けるものを管理し、災害復旧は影響を受けたものを復元し、テストは全体を検証します。このドキュメント全体で説明されているアーキテクチャ — アクティブ-アクティブ データセンター、地理情報に基づくルーティング、自動フェイルオーバー、N+1 デプロイメント — は、実際には高可用性レイヤーです。以下の節では残りの3つを説明します。 ### 高可用性 高可用性とは、継続稼働と最小限のダウンタイムを支えることを意図したシステムおよびサービス設計を指し、Zoomのシステムには、重大な障害点を最小化または排除する目的で組み込まれています。サービスはデータセンター全体の停止に耐えられるよう設計されており、障害が発生すると自動化プロセスがトラフィックを影響を受けた領域から迂回させます。コアアプリケーションはN+1 スタンダードで展開されるため、データセンターが利用不能になっても、残存サイトへトラフィックを負荷分散するのに十分な定員が残ります。この設計思想は、通信プラットフォームが依存するシステム一式全体に及びます。すなわち、冗長化された施設、テレフォニー インフラ、インターネットおよび LAN 接続、セキュリティ インフラ、リレーショナル データベース システム、大容量ストレージ、バックアップ、ハードウェア、そしてそれらに関連する定員管理および保守の実践です。これにより、いずれか1つのコンポーネント、システム、または施設が故障しても、サービスの喪失にはつながりません。 ### ビジネス継続性 Zoomのビジネス継続計画は、中断が業務に及ぼす影響を最小限に抑え、資産を保護し、お客様とステークホルダーにとって不可欠なサービスを維持するよう設計されています。どのビジネス機能を最優先で維持または復旧する必要があるか、その機能が依存する人員、技術、ベンダー、職場リソースは何か、さらにそれらの依存関係が中断された場合に生じる潜在的な影響を特定します。これにより、通常の業務が影響を受けた際、特に複数の機能やリソースに同時に対応が必要な場合に、Zoomは対応と復旧を調整するための体系的な基盤を得られます。 この計画の基盤となるのは、ビジネス影響分析（BIA）です。これは、Zoomが重要なビジネス機能に対する中断の潜在的影響を特定し評価するために用いる体系的なプロセスです。Zoomは、重要な機能に対して少なくとも年1回、または重要なビジネスプロセスに重大な変更があった際にBIAを実施します。この分析は、次の4つの主要な要素を対象としています: 1. **重要なビジネス機能の特定** — Zoomの業務に不可欠な主要プロセスを文書化し、それらの間の依存関係および相互依存関係を特定します。 2. **影響評価** — 各機能に対する中断の潜在的影響を評価し、財務損失、業務停止時間、法的・規制上の影響、評判の毀損を考慮します。 3. **必要リソース** — 復旧を支援するために必要な要員、技術、施設、第三者サービスを特定し、その可用性と十分性を評価します。 4. **復旧活動の優先順位付け** — 影響度と定められた復旧目標に基づいて重要な機能の復旧順序を決定し、最も重要な機能が最初に復旧されるようにします。 ### 災害復旧 Zoomは、各製品に対する年次テストを通じて、災害復旧機能を定期的に検証しています。同社は、障害発生後に重要なシステムとサービスを復旧するための手順を定義した、正式な文書化済みの災害復旧計画（DRP）を維持しており、そこには復旧戦略、役割と責任、通信手順が含まれます。ZoomのDRPは、停電、ネットワーク接続の喪失、ハードウェア障害、自然災害、その他の妨害イベント、さらには施設全体の障害に至るまで、1つ以上を含み得るさまざまな災害シナリオに対応するよう設計されています。災害復旧を管理する情報セキュリティ基準は文書化され、承認され、周知され、少なくとも年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 の信頼性は、クラウドファーストのサービス設計、適応型メディア ルーティング、冗長なグローバル インフラストラクチャ、定員計画、そして正式なビジネス継続および災害復旧の取り組みを組み合わせた多層アーキテクチャによって支えられています。Meetings、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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.