オンプレミス導入環境での Cisco Collaboration 12.0 エンタープライ ズ向け

Unified CM のサイジング

Unified CM については、簡易サイジングのガイダンスで最大 10,000 ユーザおよび 10,000 デバイスの展開に対応できます。Unified CM は、異なる仮定条件やコール処理ペアの追加によってより多くのユーザおよびデバイスをサポートしますが、これはこの章で示す簡易サイジングのガイダンスの範囲外です。 C：表 9-2 に、簡易サイジング展開を示します。これらの展開に対して行われた仮定については、この表の後で説明します。展開環境内のユーザまたはエンドポイントの数が C：表 9-2 示す値の範囲外である場合や、個々の展開の要件が仮定条件の範囲外である場合は、これらの簡易サイジング展開を使用せずに、 https://www.cisco.com/go/srnd で提供される Cisco Collaboration SRND の最新版の サイジング に関する章と、次で提供される Unified CM 製品ドキュメントに記載されている通常のサイジング手順を実行してください。

https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/tsd-products-support-series-home.html

C：表 9-2 では、ユーザとデバイス（のどちらか大きい方）の最大数に基づいてサイジングしています。たとえば、5,000 人のユーザと 1 ユーザあたり平均 2 個のデバイス（ユーザごとにデスクの電話とソフトフォン モードの Jabber クライアントがある場合など）を含む展開では、合計で 10,000 個のデバイスがあるため、7 ノードの展開が必要です。

これらの簡易サイジング展開では、UCS サーバで消費されるリソース全体を最適化するため、7,500 ユーザの仮想マシン設定（OVA テンプレート）が使用されます。この OVA テンプレートには、UC のパフォーマンスを最大限に引き出す CPU プラットフォーム（Cisco Business Edition 7000 など）が必要です。このテンプレートは Business Edition 6000 などではサポートされません。これらの OVA 仮想マシン構成テンプレートおよびプラットフォーム要件の詳細については、 https://www.cisco.com/go/virtualized-collaboration のドキュメントを参照してください。

7,500 ユーザの OVA テンプレートを使用して展開された Unified CM コール処理ペアは、一定の条件下で最大 7,500 人のユーザをサポートできます。しかし、この設計では Unified CM に追加の負荷がかかる仮定条件を使用します。たとえば、シングル ナンバー リーチ用のリモート接続先プロファイルを使って各ユーザを構成できること、各ユーザがエクステンション モビリティを使用できること、各エンドポイントを CTI で制御できること、いくつかの共有回線が構成されていること、モバイル アクセスやリモート アクセスが有効であることなどを仮定します。したがって、 C：表 9-2 に示したように、Unified CM コール処理ペアあたりの容量は減少します。次に、簡易サイジング モデルで使用される仮定条件について詳しく説明します。

Unified CM の仮定条件

C：表 9-2 に示した 2 つの簡易サイジング展開には、次の仮定条件が適用されます。

• ユーザあたりの最繁時呼数（BHCA）が平均 4 個以下。BHCA とは、最繁時のコール試行の数です。
• デバイスあたりの DN が平均 2 個以下です。
• メディアおよび SIP シグナリング暗号化は、この Unified CM の簡易サイジングを変更せずに有効にできます。
• コール処理サブスクライバ ペアあたりの共有回線が最大 500 回線で、各回線が平均 3 個以下のデバイスによって共有されます。
• Unified CM（ソフトフォン モード）に登録される Jabber クライアントの数をデバイスの制限に照らしてカウントする必要があります。
• パーティションが最大 3,000 個、コーリング サーチ スペース（CSS）が最大 6,000 個、クラスタあたりのトランスレーション パターンが最大 12,000 個です。
• Unified CM クラスタごとに、ルート パターンが最大 1,000 個、ルート リストが最大 1,000 個、ルート グループが最大 2,100 個。Unified CM コール処理ペアごとに、ハント パイロットが最大 100 個、ハント リストが最大 100 個、サーキュラーおよびシーケンシャル回線グループが最大 50 個（回線グループあたりのメンバー数は平均 5）、ブロードキャスト回線グループが最大 50 個（回線グループあたりのメンバー数は平均 10）です。
• Unified CM コール処理ペアごとに、CTI ポートが最大 500 個、CTI ルート ポイントが最大 100 個です。
• 複数の Unified CM クラスタを展開するときは、GDPR/ILS が有効になっています。
• エクステンション モビリティ（EM）：すべてのユーザが EM を使用できますが、クラスタ間のエクステンション モビリティ（EMCC）ユーザは存在しません。1 分あたり最大 250 回の EM ログイン/ログアウトがサポートされています。（この簡易サイジングでは、EM サービスが 1 つの Unified CM ノードで有効になっていることを前提としています。）
• Unified CM のメディア リソース：この設計では、Unified CM ソフトウェア会議ブリッジ（ソフトウェア CFB）と Unified CM メディア ターミネーション ポイント（MTP）は使用できません。代わりに、Cisco Meeting Server と Cisco IOS ベースの MTP を使用します。
• モビリティ ユーザあたりのリモート接続先またはモビリティ ID が平均 1 個以下。たとえば、5,000 ユーザを含む展開では、最大 5,000 個のリモート接続先またはモビリティ ID が存在します。
• Active Directory と同期するユーザが最大 40,000 人（ただし、コールの発着信を行うアクティブ ユーザは、 C：表 9-2 から選択する簡易サイジング展開に応じて最大 5,000 人または 10,000 人）です。
• Unified CM コール処理ペアあたりの同時アクティブ コール（会議セッションと会議以外のセッション）が最大 1,500 個。たとえば、すべてのコールが会議コールで、1 つの会議の平均参加者数が 10 人の場合、この設計では Unified CM コール処理ペアあたり最大 150 個の会議コールがあると仮定します。
• Unified CM コール処理ペアあたりのコール数/秒（CPS）が最大 15 個です。

この他、Cisco Collaboration ソリューションに適用可能な容量制限や、『 Cisco Collaboration SRND 』の最新版および製品ドキュメントに記載されている容量制限も適用されます。次に例を示します。

• コンピュータ テレフォニー インテグレーション（CTI）：すべてのデバイスを CTI で使用できます（デバイスあたり最大 5 回線、同じ CTI デバイスを監視する J/TAPI アプリケーションが最大 5 個）。
• アナンシエータ：Unified CM コール処理ペアあたり 48 個。保留音（MoH）：コール処理ペアあたりの同時 MoH セッションが 250 個です。アナンシエータや同時 MoH セッションの数が多い場合は、スタンドアロンの Unified CM サブスクライバを MoH サーバとして展開します。
• ゲートウェイ：クラスタあたり最大 2,100 個です。
• ロケーションとリージョン：リージョンを追加するときには、[オーディオコーデック設定リスト（Audio Codec Preference List）] と [音声およびセッション ビットレート（Audio and Session Bit Rate）] の値として [システム デフォルトの使用（Use System Default）] を選択します。個々のリージョンについてこれらの値をデフォルトから変更すると、サーバの初期化とパブリッシャのアップグレードにかかる時間に影響します。合計 2,000 のリージョンを使用する場合、最大 200 リージョンでデフォルト以外の値を使用するように変更できます。合計 1,000 以下のリージョンを使用する場合、そのうち最大 500 のリージョンでデフォルト以外の値を使用するように変更できます。最大 2,000 のロケーションがサポートされており、ロケーションにはリージョンのような使用制限はありません。

IM と Presence のサイジング

IM and Presence については、簡易サイジングのガイダンスで最大 15,000 ユーザまたは 15,000 のログイン Jabber エンドポイントの展開に対応できます。 C：表 9-3 に、簡易サイジング展開を示します。展開環境内のユーザ数またはログイン Jabber エンドポイントの数が C：表 9-3 に示す値の範囲外である場合は、これらの簡易サイジング展開を使用せずに、『 Cisco Collaboration SRND 』の最新版の サイジング に関する章および製品ドキュメントに記載されている通常のサイジング手順を実行してください。

たとえば、展開環境のユーザ数が 5,000 であり、各ユーザが平均して 2 つの Jabber エンドポイントに同時にログオンする場合、キャパシティは 10,000 ログイン Jabber エンドポイントで制限されます。したがって、この展開環境では 15,000 ユーザの OVA テンプレートを使用する 1 つの IM and Presence ペアが必要です。 C：表 9-3 に示す 2 つの OVA 仮想マシン設定テンプレートには、Unified Communications のパフォーマンスを最大限に引き出す CPU プラットフォーム（Cisco Business Edition 7000 など）が必要です。これらの OVA 仮想マシン設定テンプレートおよびプラットフォーム要件の詳細については、 https://www.cisco.com/go/virtualized-collaboration で入手可能なドキュメントを参照してください。

2 つの IM and Presence ノードは、一方のノードに障害が発生した場合に冗長性を提供するため、ペアとして展開されます。

SRST のサイジング

Survivable Remote Site Telephony（SRST）モードの Cisco サービス統合型ルータ（ISR）でサポートされる電話機および DN の数は、プラットフォームによって異なります。 C：表 9-4 キャパシティの例が提供されます。その他の SRST プラットフォームに関する情報（必要な DRAM とフラッシュ メモリの量を含む）については、次のリンク先にある Cisco Unified SRST のドキュメントを参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/unified-survivable-remote-site-telephony/products-device-support-tables-list.html

会議ポートの使用ガイドライン

音声およびビデオ会議のサイジングは、お客様、お客様のユーザ ベース、およびお客様の会議手順に関する個別の詳細に大きく依存します。この項のガイドラインを会議展開のサイジングの基本として使用できますが、ユーザとポートの比率は展開環境と組織の要件によって大きく異なります。

C：表 9-5 に、会議リソース要件を計画する最初の段階で推奨される比率を示します。これらの数は、展開されるエンドポイントの機能、代替の音声会議（Cisco Webex など）の可用性、および会議の作成と参加におけるユーザの快適度によって大きく変化します。最初に、次の式を使ってポートの要件を計算します。

• 音声ポート = 50 + (<number of users> / 9)
• ビデオ ポート = 8 + (<number of users> / 15)

C：表 9-5 に示した数は、スケジュールされた会議とスケジュールされていない会議のどちらにも使用できます。スケジュールされた会議については、お客様が既存の使用状況データを使って、同時会議の使用量についてより明確な結論を出すことが期待されます。

お客様が行う会議のタイプを理解することで、必要なポートの数をより正確に特定できます。ポートの総数は次の式で計算できます。

ポートの総数 = <Average number of participants in a meeting> X <Concurrent meetings>

たとえば、ユーザが 3,000 人の場合、 C：表 9-5 では 208 ポートを推奨しています。これにより、たとえば、会議あたり平均 3 人の参加者と 69 個の同時会議、または会議あたり平均 6 人の参加者と 34 個の同時会議に対応できます。推奨されるポート数をこのように評価することで、ポートの総数が展開環境に対して十分なものかどうかを簡単に判定できます。

検討すべきもう 1 つの重要な点は、予想される最大の会議サイズです。ほとんどの場合、最大の会議はオールハンズ ミーティング タイプです。たとえば、お客様のユーザ数が 1,000 人でも、全員参加のテレプレゼンス会議で 96 個のシステムを結合する必要がある場合は、推奨値の 75 ポートでは間に合いません。

Cisco Meeting Server プラットフォームのサイジング

Cisco Meeting Server は、会議のサポートや拡張性が異なる複数のモデルおよびプラットフォームで使用可能です。 C：表 9-6 に、企業展開で推奨される Cisco Meeting Server プラットフォームと、関連するノードあたりのポート容量を示します。この数値は、非暗号化および暗号化メディアおよびシグナリングで有効です。Cisco Meeting Server のクラスタリング、その他の Cisco Meeting Server プラットフォーム、またはその他のビデオおよびデータ チャネル解像度の詳細については、次のリンク先にある『 Cisco Meeting Server and Cisco Meeting App Data Sheet 』を参照してください。

https://www.cisco.com/c/en/us/products/conferencing/meeting-server/datasheet-listing.html

他にも留意すべき事項があります。たとえば、Cisco Meeting Server ではノードあたり各会議で最大 450 の参加者をサポートしています。この容量を増加するには、Cisco Meeting Server ノードを追加します。

Cisco TelePresence Management Suite（TMS）

Cisco TMS については、 C：表 9-7 に示す 2 つの簡易サイジング展開をお勧めします。TMS には他にも可能な展開がありますが、このガイドでは説明しません。たとえば、TMS、TMSXE、および Microsoft SQL のすべてのコンポーネントを同じ仮想マシンに配置する単一サーバ展開については、冗長性が提供されないため、ここでは説明しません。

C：表 9-7 に示した 2 つの展開では、高可用性が提供されます。冗長ノードは、拡張性ではなく回復力を確保するために展開されます。プライマリ ノードとバックアップ ノードに単一の仮想 IP アドレスを提供するロード バランサも必要です。

Cisco TMS のパフォーマンスとスケーリングに影響を与えるその他の要因として、次が挙げられます。

• Cisco TMS Web インターフェイスにアクセスするユーザの数。
• スケジュールまたは監視されている会議の同時開催。
• 複数の拡張機能またはカスタム クライアントによる Cisco TMS Booking API（TMSBA）の同時使用。ブッキングのスループットは、Cisco TMS の [新しい会議（New Conference）] ページを含むすべてのスケジューリング インターフェイスで共有されます。

Cisco TMS のサイジングの詳細については、次の場所にある『 Cisco TelePresence Management Suite Installation and Upgrade Guide 』を参照してください。

https://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-tms/products-installation-guides-list.html

Cisco Meeting Management Suite

Cisco Meeting Management Suite には、Cisco Meeting Server の Call Bridge 数、すべての Call Bridge のピーク時に開始されたコール レッグの数、および会議管理にログインしているユーザ数に応じて、2つの VM 設定が同時に提供されます。詳細については、以下で提供される最新バージョンの Cisco Meeting Management インスタレーションおよび設定ガイド を参照してください。

https://www.cisco.com/c/en/us/support/conferencing/meeting-management/products-installation-guides-list.html

Cisco Expressway のサイジング

C：表 9-8 中規模 OVA テンプレートを使用する際、特定の時点で 1 つの Expressway ノードで処理可能な最大容量が表示されます。

Expressway ノードはクラスタに編成されており、冗長性と高いスケーラビリティを提供します。このドキュメントで説明する推奨クラスタ構成は、2、3、または 6 ノードのクラスタからなります。 C：表 9-9 に、推奨される展開のクラスタ容量を示しますすべての展開モデルが冗長性に対応していることに注意してください。2 ノードまたは 3 ノードのクラスタでは、1 つのノードに障害が発生してもクラスタ容量に影響しません（N+1 冗長性）。6 ノードのフル クラスタでは、2 つのノードに障害が発生してもクラスタ容量に影響しません（N+2 冗長性）。

クラスタ容量と冗長性レベルの関係をさらに理解するため、次の例では、中規模 OVA テンプレートを使用して通常動作中およびフェールオーバー後のビデオ容量を分析します。

ノードあたりの最大ビデオ コール容量は 100 セッションです。回復力のない展開における 3 ノードのクラスタでは、クラスタのビデオ コール容量は 300 ですが、1 つのノードに障害が発生した場合はその 1/3 に減少します。推奨される高可用性の 3 ノード クラスタでは、3 ノードのいずれかに障害が発生した場合に回復力を提供し、クラスタ容量を維持するため、ビデオ セッション容量が 200 に制限されます。通常の操作では、ビデオ コールの負荷がクラスタ全体で分散され、各ノードが約 66 のビデオ コールを処理します。1 つのノードで障害が発生すると、残りのノードで 200 ビデオ セッションすべてを処理でき（各ノードで 100 のビデオ セッションを処理できるため）、クラスタ容量が維持されます。

注 その他、2 つの OVA テンプレート、小規模 OVAテンプレートおよび 大規模 OVAテンプレートが提供されます。小規模 OVA テンプレートは、Cisco Business Edition 6000M または 6000H で実行される設計です。大規模 OVA テンプレートは Cisco Business Edition 7000 ではサポートされておらじ、特定のハードウェアでのみで限定して提供されています。また、Cisco Expressway CE1200 のハードウェア アプライアンスを使用するオプションもあります。詳細については、https://www.cisco.com/go/virtualized-collaboration のドキュメントを参照してください。

C：表 9-9 に示した Expressway の簡易サイジング展開には、次の仮定条件が適用されます。

• すべてのビデオ コールが暗号化されています。すべてのビデオ コールの平均コール レートは 768 kbps です。たとえば、ビデオ コールの半分が 384 kbps で、残りの半分が 1152 kbps です。
• すべての音声コールが暗号化され、すべての音声コールの平均帯域幅は 64 kbps です。
• 中規模 OVA テンプレートを使った仮想マシンでは、コール レートはノードあたり最大 5 コール/秒（cps）です。

Cisco Expressway をクラスタ化する場合は、次のガイドラインが適用されます。

• Expressway クラスタは最大 6 ノードをサポートします（クラスタ容量はノード容量の最
  大 4 倍）。
• Expressway-E ノードと Expressway-C ノードは別個にクラスタ化されます。Expressway-E クラスタは Expressway-E ノードのみで構成され、Expressway-C クラスタは Expressway-C ノードのみで構成されます。
• Expressway のピアは、Expressway-E クラスタと Expressway-C クラスタで同じ数だけ展開する必要があります。たとえば、3 ノードの Expressway-E クラスタは、3 ノードの Expressway-C クラスタとともに展開する必要があります。
• Expressway-E クラスタと Expressway-C クラスタの各ペア間およびペア内のすべてのノードの容量は、同じである必要があります。たとえば、Expressway-E クラスタ内または対応する Expressway-C クラスタ内の他のノードが中規模 OVA テンプレートを使用している場合は、小規模 OVA テンプレートを使用する Expressway-E ノードを展開してはいけません。
• Expressway-E クラスタと Expressway-C クラスタのペアは、ノード容量がすべてのノードで同じであるかぎり、アプライアンスで実行されるノードまたは仮想マシンとして実行されるノードを組み合わせて構成できます。
• 複数の Expressway-E および Expressway-C クラスタを展開して、容量を増やすことができます。

Expressway に詳細については、次の場所にある『 Cisco Expressway Administrator Guide 』を参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-maintenance-guides-list.html

Cisco Expressway のサイジング例

ある企業では、6,000 人のユーザがいて、平均 1,000 人のユーザが常に出張しています。常にモバイル ユーザの 80% がモバイルおよびリモート アクセスを必要としています。このケースでは、800 人（1,000 人の 80%）が同時登録できるように Expressway をサイジングする必要があります。

さらに、モバイル ユーザの 10% が同時にコールを行います。これらのユーザの 5% が Expressway 経由でコールし、残りの 5% が携帯電話ネットワーク経由でコールするため、Expressway に対する同時コール数は 40（800 の 5%）です。

社内ネットワークでは、ユーザの 1% が同時に Business-to-Business（B2B）コールを行います。これによって、50 個（（6,000 - 1,000）の 1%）のコールが追加されます。

このケースでは、800 個の同時登録と 90 個の同時コール（40 + +50）をサポートするようにクラスタをサイジングする必要があります。

C：表 9-8 に示すように、中規模 OVA テンプレートは最大 100 個の同時コールと 2,500 個の同時登録をサポートします。したがって、中規模 OVA テンプレートを使用する 2 ノードで構成される Expressway-C クラスタと、やはり中規模 OVA テンプレートを使用する 2 ノードで構成される Expressway-E クラスタを展開することができます。 C：表 9-9 の展開 1 で示したように、各 Expressway サーバ ノードは 800 個の登録と 90 個のコールをすべて同時に管理できます。クラスタ化が必要とされる理由は、2 つの Expressway ノードのいずれかが停止した場合に、もう一方のノードがすべてのトラフィックを処理できるためです。通常の状況では、Expressway-C クラスタと Expressway-E クラスタの 2 つのノード間でコールと登録の負荷が分散されます。

この例では、しばらくすると Business-to-Business（B2B）コールが 1% から 3% に増加します。そこで、90 個ではなく 190 個（40 + +150）の同時コールに対応する必要があります。中規模 OVA テンプレートの最大処理量は 100 コールなので、この場合は大規模なクラスタを展開する必要があります。 C：表 9-9 に示すように、展開 2 によって、1 つのサーバに障害が発生しても 200 個の同時コールに対応できます。したがって、この例の管理者は、Expressway-C および Expressway-E クラスタにもう 1 つの中規模 OVA ノードを追加して、クラスタあたり合計 3 ノードを展開します。

Cisco Unified Border Element のサイジング

Cisco Unified Border Element は広範囲のシスコ ルーティング プラットフォームでサポートされます。これには、Cisco 4400 シリーズのサービス統合型ルータ（ISR）や Cisco 1000 シリーズのアグリゲーション サービス ルータ（ASR）が含まれます。また、Cisco Unified Border Element は、次のプラットフォームで冗長性を提供します。

• Cisco ISR プラットフォームでは、アクティブ コールのシグナリングとメディアの両方の保護を含むボックスツーボックス冗長性を提供できます。
• Cisco ASR プラットフォームでは、アクティブ コールのメディアとシグナリングの保護（ステートフル フェールオーバー）を含むインボックス冗長性またはボックスツーボックス冗長性を提供できます。

C：表 9-10 では、いくつかのプラットフォームについて容量の例を示します。この表には、エンドツーエンド PSTN SIP 間コールの最大数に対応する SIP トランク セッションの最大数を示します。これにより、メディアおよびシグナリングを暗号化しない場合の制限と、RTP/SRTP インターワーキング（トラフィックが社内ネットワーク内部で暗号化され、SIP サービス プロバイダーへの接続では暗号化されない）の制限が決定します。その他のプラットフォームや、必要な DRAM とフラッシュ メモリの量などの詳細については、次の場所にある『 Cisco Unified Border Element Data Sheet 』および『 Cisco Unified Border Element and Gatekeeper Ordering Guide 』を参照してください。

https://www.cisco.com/c/en/us/products/unified-communications/unified-border-element/datasheet-listing.html

Cisco Unified Border Element のサイジング例

企業に 10,000 のユーザが存在し、社内ネットワークでメディアおよびシグナリング暗号化が有効になっています。最繁時にはユーザの 10% が同時にコールを行います。ユーザの 8% は外部の接続先にコールし、残りのユーザは内線コールに関与しています。電気通信業者とこの企業はすべてのコールに G.711 を使用できることで合意しているため、トランスコードは必要ありません。この展開では、800 個の SIP セッション（10,000 人の 8%）が必要です。 C：表 9-10 に示すように、Cisco 4451-X ISR では暗号化により最大 1,400 個のセッションをサポートできます。したがって、この例では 2 つの Cisco 4451-X ISR を展開でき、1 つをアクティブ、もう 1 つをスタンバイとして使用することで冗長性を確保できます。

Cisco Prime Collaboration Provisioning

この設計における Cisco Prime Collaboration プロビジョニングの推奨される展開は、1 つのノードで構成されています。この展開には冗長ノードはありません。代わりに、Cisco Prime Collaboration プロビジョニング仮想マシンをバックアップします。

このガイドには、エンドポイントの数に基づく Cisco Prime Collaboration プロビジョニングの 2 種類のサイジング展開が記載されています。これらの展開を C：表 9-12 に示します。Cisco Prime Collaboration プロビジョニングには他にも可能な展開がありますが、このガイドでは説明しません。その他の可能な展開については、『 Cisco Collaboration System 11.x SRND 』の最新版および Cisco Prime Collaboration プロビジョニング 製品ドキュメントを参照してください。

Cisco Prime Collaboration Deployment

Cisco Prime Collaboration Deployment は 1 つのノードとして展開されます。この展開には冗長ノードはありません。代わりに、Prime Collaboration Deployment 仮想マシンをバックアップします。1 つの Cisco Prime Collaboration Deployment ノードでサポートできる展開のサイズに制限はありません。

冗長性の考慮

ハードウェア プラットフォームに高い冗長性がある場合でも、ハードウェアの冗長性を考慮することをお勧めします。たとえば、C：図 9-1 の例で示すように、プライマリ アプリケーションとバックアップ アプリケーションの仮想マシンを同じ UCS サーバに展開しないでください。代わりに、ホストの障害発生時に冗長性を提供するため、プライマリとバックアップの仮想マシンを異なるサーバに展開してください。

プラットフォーム

仮想化を使用して展開される製品には、Cisco Business Edition 7000 が最適なソリューションとして考えられます。このソリューションは、簡単に発注して展開することができ、VMware vSphere Hypervisor (ESXi) が事前にインストールされています。Business Edition 7000 にはCisco Collaboration ソフトウェア セットが事前にロードされており、またCisco Collaboration
アプリケーションの一部も事前にインストールされています。