> 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/naentpuraizusbisu/zoom-node/zoom-node-deployment-field-guide/zoom-node-infrastructure-prerequisites.md).

# Zoom Node のインフラストラクチャ前提条件

このセクションでは、モジュールのインストールを含む、Zoom Node導入のためのハードウェアおよびソフトウェアの前提条件を詳しく説明します。

### <mark style="color:青;">ハイブリッドコミュニケーション基盤の構築</mark>

各導入シナリオのハードウェアおよびソフトウェアの参照情報を以下に示します。

#### サポートされるハイパーバイザー

ハイパーバイザーの互換性を理解することで、組織は既存の仮想化投資を活用しながら、Zoom Nodeの機能サポートを完全に維持できます。

| ハイパーバイザープラットフォーム             | 最小バージョン要件                        | 戦略的な導入に関する考慮事項                                              |
| ---------------------------- | -------------------------------- | ----------------------------------------------------------- |
| **VMware vSphere/ESXi**      | 6.7以上                            | 幅広い互換性を備えた業界標準の選択肢で、既存のVMwareインフラを持つエンタープライズに最適です           |
| **Proxmox VE**               | Proxmox 8.xまたは9.0.x（VMのみ/LXC非対応） | Proxmox VEとvirt-managerの両方の実装をサポートする、コスト効率に優れたオープンソースのオプション |
| **Nutanix AHV**              | AOS 6.10.xまたは7.x（VMのみ/LXC非対応）    | ハイパーコンバージドインフラ戦略を活用する組織に最適                                  |
| **Microsoft Hyper-V Server** | Hyper-V Server 2019以上            | Windows中心の環境向けのシームレスな連携                                     |
| **AWS EC2**                  | 現在のバージョン                         | Windows中心の環境向けのシームレスな連携                                     |

{% hint style="info" %}
特定のHyper-Vバージョンの検証については、Zoomサポートにお問い合わせください。
{% endhint %}

#### 仮想マシンのハードウェア仕様

以下の仕様は、標準および最小のハードウェア要件を網羅しています。

**標準の本番構成**

この構成により、エンタープライズレベルの組織は、1ノードあたり最大4つの同時Service Moduleをサポートすることで、Zoom Nodeの機能を最大限に活用できます。

| インフラストラクチャコンポーネント  | 技術仕様                                                   | ビジネスへの影響と導入の理由                            |
| ------------------ | ------------------------------------------------------ | ----------------------------------------- |
| **CPUアーキテクチャ**     | 64ビット Intel E5-2650v4 以上 @ 2.0GHz+ AMD 64ビット @ 2.0GHz+ | 高品質なユーザー体験に不可欠な、リアルタイムメディア処理機能をサポートします    |
| **仮想CPU割り当て**      | 8 vCPU                                                 | パフォーマンスを低下させることなく、複数のハイブリッドサービスを同時に運用できます |
| **メモリ割り当て**        | 16 GB RAM                                              | トランスコードやメディアルーティングを含む、メモリ集約型の処理をサポートします   |
| **ストレージのプロビジョニング** | 200 GB HDD                                             | OS、Service Module、ログ、一時的なメディア保存領域に対応します   |
| **ネットワークインターフェース** | 10 GBの仮想NIC                                            | 大量のメディア処理シナリオ中のネットワークのボトルネックを防ぎます         |

**最小実用構成**

この構成は、初期テスト、概念実証、ラボ環境、または同時使用が限られた単一サービス導入に適しています。

| インフラストラクチャコンポーネント  | 最小仕様         | 適切なユースケースと制限事項                         |
| ------------------ | ------------ | -------------------------------------- |
| **仮想CPU割り当て**      | 3 vCPU       | テスト環境、単一サービスのデプロイ                      |
| **メモリ割り当て**        | 6～8 GB RAM   | 同時接続ユーザーのサポートは限定的で、スケーリングが必要になる場合があります |
| **ストレージのプロビジョニング** | 200 GB HDD   | 必要不可欠な運用のみに対応するベーシックなストレージ             |
| **ネットワークインターフェース** | 1 GB/s 仮想NIC | 少量導入には十分です                             |

{% hint style="warning" %}
**重要なパフォーマンスに関する考慮事項**：組織は、使用パターンの拡大に応じて、最小仕様から本番用のスタンダード仕様へスケールする計画を立てる必要があります。最小仕様で本番システムを稼働させることはサポートされておらず、パフォーマンスまたはインストールの問題を引き起こす可能性が高くなります。
{% endhint %}

### <mark style="color:青;">ネットワークアーキテクチャと接続の前提条件：信頼性の高いハイブリッド通信を確保する</mark>

このセクションでは、シームレスなサービス連携と、Zoom のクラウドインフラストラクチャとの信頼性の高い通信に必要な、必須のネットワーク、IPアドレス指定、および DNS 要件について説明します。

#### 基本的なネットワーク要件

これらの交渉の余地のないネットワーク構成は、Zoom Node 実装を成功させるための基盤となります。

| ネットワーク要件          | 技術仕様                                                                                | 実装への重大な影響                                   |
| ----------------- | ----------------------------------------------------------------------------------- | ------------------------------------------- |
| **VM ネットワークタイプ**  | ブリッジ/直接 VM ネットワーク接続が必須                                                              | ハイブリッドサービスに不可欠な、クライアントから Node への直接通信を可能にします |
| **NAT 構成**        | サポートされていません - VM はハイパーバイザー NAT の背後に配置できません                                          | クライアントと Zoom Node サービス間の通信障害を防止します          |
| **インターネット接続**     | クラウドサービス連携に必要                                                                       | ハイブリッドサービス機能と管理プレーン通信を可能にします                |
| **プロキシサーバーのサポート** | Zoom Node OS 通信用にサポートされています。プロキシサポートはサービスモジュールファミリーによって異なります。モジュールのドキュメントを確認してください。 | 中継に伴う複雑さなしに、信頼性の高いクラウドサービス接続を可能にします         |
| **内部アドレス指定**      | RFC 1918 のアドレス指定を完全にサポート                                                            | 既存のエンタープライズネットワーク方式とのシームレスな連携を可能にします        |

#### IPアドレス計画マトリクス

戦略的な IPアドレス 割り当てにより、柔軟なサービス展開と将来の拡張が可能になります。

| デプロイアーキテクチャ             | IPアドレス要件                      | 実装の柔軟性と成長パス                             |
| ----------------------- | ----------------------------- | --------------------------------------- |
| **スタンダードなマルチサービス Node** | サービスごとに 1 つの固有 IP（合計最大 4 つ）   | 最大限のデプロイ柔軟性を提供し、段階的なサービス展開をサポートします      |
| **ハイブリッド WAG 実装**       | 専用 IPアドレス が 2 つ必要             | 冗長化された Web アプリケーション Gateway サービスを可能にします |
| **統合デプロイ**              | Node + プライマリモジュール用の 1 つの共有 IP | 特定の低複雑度シナリオに限定されます                      |
| **高可用性アーキテクチャ**         | 分散コンポーネント全体で複数の IP            | エンタープライズの耐障害性要件をサポートします                 |

#### DNS アーキテクチャ要件

適切な DNS 構成により、信頼性の高いサービス検出と証明書の検証が保証されます。

**重要な DNS 実装要件**

* **パブリック DNS 解決の必須要件**：すべてのZoom Nodeホスト名は、パブリックDNSインフラストラクチャ経由で名前解決される必要があります
* **スプリットホライズンDNSサポート**：外部DNSゾーンは、ZoomクラウドIPアドレス範囲向けにNodeホスト名を名前解決する必要があります
* **サバイバビリティDNSアーキテクチャ**：ローカルDNSサーバーは、インターネット障害時にもオンラインのままである必要があります
* **命名の一貫性要件**：内部ユーザーとZoomクラウドインフラストラクチャは、同一のホスト名を参照する必要があります

{% hint style="info" %}
**実装のベストプラクティス**：展開前にすべてのDNSエントリをドキュメント化して検証し、証明書および接続性の問題を阻止する。
{% endhint %}

### <mark style="color:青;">証明書管理戦略：ハイブリッド通信を保護する</mark>

このセクションでは、利用可能な証明書オプション（自動またはBYOC）の概要を示し、組織のセキュリティポリシーおよび展開アーキテクチャに合わせるための計画ガイダンスを提供します。

#### 戦略的な証明書管理オプション

| 管理方法                  | 運用モデル                  | 最適なユースケースとビジネス上の利点                                    |
| --------------------- | ---------------------- | ----------------------------------------------------- |
| **Auto PKI（推奨）**      | Zoom管理のコストによる自動登録および更新 | 運用オーバーヘッドを削減し、証明書の期限切れリスクを排除するため、ほとんどの展開に最適です         |
| **独自の証明書を持ち込む（BYOC）** | 組織が管理する公開CAの証明書        | 既存のPKIポリシーとのコンプライアンスを可能にし、成熟した証明書管理を持つエンタープライズに適しています |

#### BYOC実装要件

このセクションでは、サポートされる証明書モデルの詳細を説明し、サービス全体で安全かつスケーラブルな展開を確実にするための計画テンプレートを提供します。

**証明書タイプ選択ガイド**

| 証明書タイプ         | 技術的能力                   | 実装例                             | 展開の複雑さ            |
| -------------- | ----------------------- | ------------------------------- | ----------------- |
| **ワイルドカード証明書** | すべてのサブドメイントラフィックを暗号化します | `*.company.com` すべてのサービスをカバーします | 管理が簡素化される、推奨アプローチ |
| **マルチSAN証明書**  | 最大5つの特定ホスト名をサポートします     | サービスごとの個別FQDN                   | 包括的な事前計画が必要です     |

**マルチサービス証明書計画テンプレート**

展開前に証明書要件を計画するために、このテンプレートを使用してください：

| サービスのロール              | ホスト名（SANエントリ）                | 割り当て済みIPアドレス  | 証明書カバレッジに関する注記             |
| --------------------- | ---------------------------- | ------------- | -------------------------- |
| **Zoom Nodeプラットフォーム** | `zoom-node01.company.com`    | `10.1.50.100` | 証明書カバレッジを必要とするベースプラットフォーム  |
| **ZPLSサービス**          | `zpls.company.com`           | `10.1.50.100` | NodeプラットフォームとIPアドレスを共有できます |
| **録画サービス**            | `Zoom-recording.company.com` | `10.1.50.101` | 専用IPアドレスが必要です              |
| **ウェビナーサービス**         | `Zoom-ウェビナー.company.com`     | `10.1.50.102` | 専用IPアドレスが必要です              |
| **将来のサービススロット**       | （拡張用に予約済み）                   | 該当なし          | 展開の柔軟性を維持します               |

{% hint style="danger" %}
**重要な展開警告**スタンダードな単一ホスト証明書は、Node と単一のモジュール間で共有 IP/ホスト名を1つ使用する特定のシナリオを除き、Zoom Node と互換性がありません。
{% endhint %}

### <mark style="color:青;">サービス固有の前提条件: 高度なハイブリッド機能を有効にする</mark>

このセクションでは、AWS 環境で Zoom Node を導入するための主な前提条件について説明します。

#### AWS クラウド導入の前提条件

| AWS 要件            | 技術仕様                     | 実装の目的                   |
| ----------------- | ------------------------ | ----------------------- |
| **ワークステーション定員**   | 最小 20 GB のストレージ          | ツールのインストールとイメージ変換をサポート  |
| **AWS CLI ツール**   | 最新バージョンが必要です             | 自動デプロイワークフローを有効にします     |
| **QEMU イメージツール**  | `qemu-img` ユーティリティ       | VMDK から AMI への変換を容易にします |
| **IAM 構成**        | `vmimport` 適切なポリシーを持つロール | 安全な VM インポート操作を有効にします   |
| **S3 インフラストラクチャ** | バケット付き `vmimport` 権限     | VMイメージのステージングを提供します     |

### <mark style="color:青;">戦略的実装計画フレームワーク</mark>

このセクションでは、パフォーマンス、信頼性、およびハイブリッド環境全体での長期的な成長を計画するのに役立つ、デプロイメント プロファイルとスケーリング戦略を提供します。

#### デプロイメントのサイジングと定員計画マトリックス

組織の規模とサービス要件に基づいて、デプロイメント プロファイルを選択してください:

| デプロイメント プロファイル      | インフラストラクチャの規模 | モジュール配分戦略       | 対象ユースケース                  |
| ------------------- | ------------- | --------------- | ------------------------- |
| **パイロット/小規模オフィス**   | 1～2ノード        | 1ノードあたり1～2モジュール | 概念実証、ユーザー数500人未満          |
| **スタンダード エンタープライズ** | 3～5ノード        | 1ノードあたり2～3モジュール | 500～5,000ユーザー、マルチサイト      |
| **大規模エンタープライズ/HA**  | 6以上のノード       | 分散モジュール、地理的冗長性  | 5,000人以上のユーザー、ミッションクリティカル |

#### リソース最適化とスケーリング戦略

以下を通じてインフラ投資を最大化：

* **戦略的モジュール統合**：スタンダード仕様でノードあたり最大4モジュールを展開
* **段階的なスケーリングアプローチ**：テスト用に最小仕様から開始し、本番スタンダードまで拡張
* **サービス重要度評価**：ミッションクリティカルなサービスを専用ノードに分離
* **地理的分散計画**：耐障害性と性能のために、拠点全体にノードを展開


---

# 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/naentpuraizusbisu/zoom-node/zoom-node-deployment-field-guide/zoom-node-infrastructure-prerequisites.md?ask=<question>&goal=<endgoal>
```

`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.