> 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/account-and-endpoint-management/scim-guide.md). # Entra IDとOktaのためのSCIMフィールドガイド Entra IDまたはOktaとZoomの間でカスタムSCIMマッピングを作成するためのガイド ## 概要 Zoom の SCIM2 API は、ライセンス、製品の利用権、ロール、リージョン、およびサービスごとの設定を制御する多数のユーザー属性を公開しています。Microsoft Entra ID と Okta の両方に用意されている標準のプロビジョニング統合では、これらのうちごく一部しかマッピングされません。ユーザーの作成、更新、無効化には十分ですが、Zoom Phone のサイト、コンタクトセンターのパッケージ、Revenue Accelerator のロール、あるいは Zoom がサポートするその他数十種類の属性をプロビジョニングするには不十分です。 このガイドでは、 *任意の* Zoom SCIM 属性をプロビジョニング構成に追加するための再利用可能な手順を説明します。1つの属性だけを個別に文書化するのではなく、管理者が Zoom の SCIM2 API リファレンスで属性を確認し、製品固有の記事の公開を待たずに個別に設定できるよう、その背後にあるモデルを解説します。 ### このガイドの使い方 まずは [**SCIM 属性を理解する**](#understanding-scim-attributes) から始まる序章と、それに続くセクション――前提条件、ディレクトリデータ、参考シナリオ、Zoom 側の認証――をお読みください。これらは、どのアイデンティティ プロバイダー（IdP）を使用する場合でも適用されます。その後、使用している方に応じて Microsoft Entra ID または Okta のセクションを進めてください。各セクションは、最初の設定手順から認証、実例まで完結しているため、行き来する必要はありません。 このガイドの土台となる SSO と SCIM の基本概念については、 [SSO フィールドガイド](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide)、その [Entra ID 向けの Zoom SSO とプロビジョニングの記事](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121)、そしてその [Okta 向けの Zoom SSO 記事](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0063256). {% hint style="danger" %} **警告** 誤設定されたプロビジョニングは、すでに使用中のライセンスの削除を含め、既存のユーザーに影響を及ぼします。本番環境に適用する前に、すべての変更を単一のテストユーザーで検証してください。 {% endhint %} ### **SCIM を使用するための前提条件** このセクションのすべては、ID プロバイダーに関係なく適用されます。ID プロバイダー固有の手順に進む前に、これをお読みください。 #### 両方のID プロバイダーに共通する要件 * 承認済みのビジネス、教育機関、またはエンタープライズのZoomアカウント [バニティURL](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0061540) * Zoomアカウントオーナーまたは管理者権限 * [シングルサインオン（SSO）](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060673) Zoomアカウントで有効になっている * A [確認済みの関連ドメイン](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0066259) Zoomアカウント上で、プロビジョニングされるユーザーのメールドメインと一致する * SCIMプロビジョニングは、IDプロバイダーとZoomの間で既に確立されている * 割り当てられるZoomライセンス、プラン、アドオン、または設定オブジェクトは、既に存在し、Zoomアカウント上でオンラインでなければなりません 各セクションの冒頭に、IDプロバイダー固有の要件が記載されています。 #### 両方のIDプロバイダーに共通する制限 * SCIMは既存のエンタイトルメントのみを割り当てます。SCIMが参照するオブジェクトを作成することはできません。セクションを参照してください [**高度なマッピングを試す前に、SCIMが参照できるように、Zoom側のオブジェクトが存在している必要があります**](#before-attempting-advanced-mapping-zoom-side-objects-must-exist-before-scim-can-reference-them) 以下。 * 一部の属性は、ユーザーごとに1つの値しか受け付けません。Zoom Phoneの通話プランがその一例です — Customer Engagement Pack のようなアドオン パッケージは、SCIM経由でプロビジョニングできません。 * この `userType` 属性は、Zoomによって廃止予定として文書化されています。 ## **はじめに** ### **SCIM 属性を理解する** Zoom SCIM 属性がどのように構成されているかを理解している管理者は、Zoom がサポートする任意の属性を設定することができます。レシピに従う管理者は、そのレシピで説明されている属性だけを設定することができます。このセクションでは、その構成について説明します。属性をデータソースにマッピングする話は後で、ID プロバイダーのセクションで扱います。 #### すべての属性には、名前空間、名前、データ型、および許可された値があります 完全な、動作する例から始めましょう。以下は、ユーザーを Zoom Phone サイトに割り当てるための識別子です: ``` urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhoneSite ``` この属性には4つのプロパティが関係しています。そのうち2つは上の行に表示されています。残りの2つはAPIリファレンスから来ており、後でアイデンティティプロバイダーの別の場所に入力されます。ここでは当面、2つに注目しています。つまり、その **名前空間** そしてその **名前**.
プロパティ例から抽出機能
名前空間urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー設定が属するスキーマをZoomに伝え、ほぼすべてのZoom製品およびライセンス属性の共有ベースとして機能します。識別子の前半としてZoomに渡されます。
名前zoomPhoneSite書き込まれる特定のZoom設定、ここではユーザーのZoom Phone サイトを識別します。識別子の後半としてZoomに渡されます。大文字と小文字が区別されます。
データ型文字列属性が保持する値の種類をIDプロバイダーに伝え、正しく保存および書式設定されるようにします。識別子の一部としては渡されず、次のように個別に宣言されます 型 Entra ID 内、または データ型 Okta 内。
許可される値LON-01、Zoom Phone のサイト名実際にユーザーに適用される設定。一部の属性では自由記述、他の属性では固定のセット — エッセンシャル, プレミアム、または エリート たとえば、Zoom コンタクトセンター用です。プロビジョニング時に Zoom に渡され、識別子ではなくマッピングによって提供されます。
{% hint style="danger" %} **警告** Zoom は複数のユーザー拡張名前空間を公開しています。製品の構成およびライセンス属性は `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー`、これはこのガイド全体で使用する名前空間です。スタンダードなエンタープライズ フィールド、たとえば `部署`, `マネージャー`、および `コストセンター` 使用します `urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー`。3つ目は、 `urn:us:zoom:scim:schemas:extension:1.0:ZoomUser`、APIレスポンスで返されるログインタイプ情報を保持し、プロビジョニング中に設定されるものではありません。誤った名前空間に基づいて作成された属性は、IDプロバイダーでは受け入れられますが、Zoomでは静かに無視されます。 {% endhint %} #### 必要な属性をSCIM2 APIリファレンスで見つけてください この [SCIM2 APIリファレンス](https://developers.zoom.us/docs/api/scim2/#tag/user/post/scim2/Users) は、Zoomがプロビジョニング中に受け入れるすべての内容の公式一覧です。重要なのは次の2つの操作です: **ユーザーを作成** と **ユーザーを更新**. 主に次を参照してください **ユーザーを更新**。作成は1人につき1回ですが、属性の変更は継続的に発生します — オフィス移転、プラン変更、ロール変更、退職 — そのため、時間の経過とともにプロビジョニングが実際に行うことの大半は更新です。 **ユーザーを更新** また、削除値も文書化しています **ユーザーを作成** 含める理由がない項目もあります。たとえば、設定 `zoomPhoneCallingPlan` へ `-1` ユーザーからすべての通話プランを削除するため。 属性を見つけるには: * SCIM2 API リファレンスを開き、 **ユーザーを更新**. * リクエスト本文で、対象の `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー` オブジェクト。 このガイドで扱うすべての属性はその中に一覧表示されています。 * 名前で属性を見つけ、その値をレコーディングする **データ型** およびその **許可される値**. * それと併せて説明を読んでください。説明には、属性名からは推測できない動作が含まれています — `zoomPhoneExtNumber` に設定すると `0` 自動的に内線が割り当てられます、 `zoomPhoneCallingPlan` に設定すると `-1` すべての通話プランを削除し、 `zoomPhoneNumber` は、Zoomアカウント内で既に未割り当ての番号を参照している必要があります。 #### 識別子の組み立て: 親、コロン、子 その中に記載されているすべて `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー` オブジェクトは **子ども** そのものです。オブジェクト自体は **親**。識別子を構築するとは、親に名前を付け、コロンを追加し、次に子を追加することです: ``` 親 urn:ietf:params:scim:schemas:extension:zoom:1.0:User コロン ： 子 zoomPhoneSite 識別子 urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhoneサイト ``` それが構成のすべてです。Zoom に問い合わせるためのルックアップテーブルはなく、生成するものもありません。識別子は、すでに持っている 2 つのものをコロンでつないだだけです。 #### 親は同じままで、変わるのは子だけです 親が固定されているため、2 番目、5 番目、15 番目の属性を設定するのも、別の子を追加するだけで同じ操作です: ``` ベース（親） urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー Zoom Phone サイト urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhoneサイト Zoom Phone 番号 urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhone番号 Zoom Phone 内線番号 urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhone内線番号 Zoom Phone 通話プラン urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhone通話プラン ``` 同じ親が、他のすべての Zoom 製品を持ちます。製品がそうであっても、この構成は何も変わりません: ``` コンタクトセンター パッケージ urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomContactCenterPackage Revenue Accelerator ロール urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomRevenueAcceleratorRole 職場バンドル urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomWorkplace Zoom Docs urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomDocs ``` したがって、親は一度だけ把握します。以後、新しい属性を設定するときにAPI リファレンスで確認するのは、子要素名、そのデータ型、および許可される値の3つだけです。 親と子を組み立てられるなら、この構成の最も難しい部分はもう越えています。残るのは、各値をどこから取得するかをアイデンティティ プロバイダーに伝えることです。これは後に続く Entra ID と Okta のセクションで説明します。また、どの属性から先に取り組むかを決めることも必要で、こちらは次へ説明します。 #### マッピングの2種類: ベーシックと高度 すべての属性が同じリスクを伴うわけではなく、何かを設定する前にそれらを整理しておく価値があります。 このガイドは用語を借用しています **ベーシック** と **詳細** ～からの [SSO フィールドガイド](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide)、これは SAML 応答マッピングに対して同じ線引きを行います。これらの用語は **Zoom が到着時の値に対して何を行うか**、属性を設定するのがどれほど難しいかではありません。仕組み上、この2つは同一です。どちらも同じ **ユーザーを更新** リクエスト本文で文書化され、どちらも同じ親:子の構成で作成され、Entra ID と Okta で同じ手順で宣言およびマッピングされます。 * **ベーシック マッピング** テキストをユーザーのプロフィールに書き込みます。Zoom は値を送信されたとおりに正確に保存し、いかなるものとも照合しません。 * **高度なマッピング** アカウントに対してクレームを行います。Zoom は値を受け取り、一致するオブジェクト、または購入済みプランの空き席を探します。そしてその検索は失敗することがあります。
ベーシック マッピング高度なマッピング
値が何であるかユーザーのプロフィールに保存されたテキストZoom 内のオブジェクトへのポインタ、または購入済みシートに対するクレーム
例部署, タイトル, コストセンターzoomPhoneSite, zoomContactCenterRole, zoomWorkplace
親最上位、またはエンタープライズ拡張Zoom 拡張
Zoom における前提条件なしオブジェクトが存在しているか、席が空いている必要があります
値が間違っている場合プロフィールに誤ったテキストが表示される属性は拒否されるか、黙って無視されます
この区別が2つの実務上の判断を左右します。それは **Zoom で最初に構築しなければならないもの** — ベーシックなマッピングでは何もなく、高度なものではかなり多くなる可能性があり —、そしてそれは **ミスのコスト**. 誤った部署は、プロフィール上の見た目だけのエラーです。誤ったサイト名や利用できないライセンス枠は、ユーザーに動作する電話を持てない、または採用時に使用するために割り当てられた製品を使えない状態にし、本番環境では、すでに権限を持っていた人からその権限を取り除いてしまうことがあります。 その結果の違いがあるため、以下ではこの2つは別々に扱います。 #### ベーシック マッピング: プロフィール情報 ベーシック マッピングは、ユーザーのZoomプロフィールの説明フィールドに値を設定します。Zoomは各値を送信されたとおりに正確に保存し、既存のオブジェクトと照合することはないため、事前にZoom側で何かを作成しておく必要も、値が間違っていても壊れるものもありません。 **主要な識別フィールドは、通常すでにマッピング済みです。** `ユーザー名`, `name.名`, `name.姓`, `表示名`、および `メールアドレス` リクエスト本文の最上位にあり、親要素はまったくありません。Entra ID と Okta の両方の統合は、追加設定なしでそれらをマッピングします。再構築するのではなく、検証してください。 `タイトル`, `電話番号`、および `ロケール` トップレベルでもありますが、追加が必要かもしれません。 **エンタープライズのフィールドは2番目の親を使用します。** 構文は変更されない — 変更されるのは親だけです: ``` ベース（親） urn:ietf:params:scim:schemas:extension:enterprise:2.0:User 部署 urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー:department コストセンター urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter 従業員番号 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber 組織 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization マネージャー urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー:manager ``` SCIM を通じて部門とコストセンターを設定する際に、SAML マッピングは不要になりました。 {% hint style="info" %} **推奨** まず1つのベーシック属性をマッピングしてください— `部署` 有力な候補であり、〜として検討されます **シナリオ 0** 参照シナリオで — そして、Zoom 拡張機能で何かを構成する前に、単一のテストユーザーに対してエンドツーエンドで実行してください。A `部署` Zoom のプロフィールに正しく表示される値は、スキーマ宣言、マッピング、スコープ、およびプロビジョニングログを読み取る能力を証明します。続くすべての高度な属性は、設定方法ではなく、参照先が異なるだけです。 {% endhint %} #### 高度なマッピング: 製品構成と利用権 高度なマッピングでは、ユーザーが持てる対象が割り当てられます。たとえば、Zoom Phone のサイトと通話プラン、コンタクトセンターのロールとパッケージ、Workplace バンドル、Revenue Accelerator セグメントです。これらの属性は、このガイド全体で使用される Zoom拡張親の下にあります。 重要なのは、これらの値は保存されず、 **解決されます**。Zoomでは、送信した値を受け取り、一致するオブジェクトまたは利用可能な席を探します。基本マッピングがプロファイルにテキストを書き込むのに対し、高度なマッピングはアカウントの設定とインベントリに対する要求を行い、その要求は失敗することがあります。 そのため、このガイドでは前提条件に1つの節を充てています。すべての高度な属性は、まずZoomウェブポータルで何かが作成または購入されていることに依存しており、失敗時の挙動は、役職名のスペルミスよりもかなり容赦がありません。 #### すべての設定に共通する3つのレイヤー どの属性でも、どのIDプロバイダーでも、作業は同じ3つのレイヤーです。異なるのは、各コントロールの配置だけです。
レイヤー目的Microsoft Entra IDOkta
1. 宣言その属性がZoomアプリケーションに存在することをIDプロバイダーに伝え、マッピング対象として利用可能にします。手順1手順1
2. マッピング値の取得元を定義します。手順2手順2～3
3. スコープこの設定をどのユーザーに適用するか、いつ実行するかを決定します。手順3～5手順4～5
このパターンを理解すれば、5個目や15個目の属性を追加することは、まったく同じ3つのレイヤーの繰り返しであり、新しいプロジェクトではありません。 #### Entra と Okta では、値の由来が異なります これは、2つの経路の間で最も影響の大きいアーキテクチャ上の違いであり、同じビジネス要件が Entra と Okta で異なる設定になる理由を説明しています。 * **Entra ID は、ユーザーオブジェクトの属性からのみ値を取得します。** 値はユーザー上のフィールド、つまり既存のディレクトリフィールドまたは専用設計の拡張属性から取得される必要があります。ディレクトリ値と Zoom 値が同じ文字列でない場合、それらを変換する式が必要です。 * **Okta は、ユーザープロファイルまたはグループ割り当てのいずれからでも値を取得できます。** 属性を **属性タイプ: グループ** と宣言すると、その値をグループに1回設定して、すべてのメンバーに継承させることができます。設定が組織構造に従う場合、変換ロジックは完全に不要になります。 どちらの方法も普遍的に優れているわけではありませんが、結果として設定は異なります。 ### **Zoom側の事前設定要件** #### 高度なマッピングを試す前に、SCIMが参照できるように、Zoom側のオブジェクトが存在している必要があります SCIM は割り当て機構であり、作成機構ではありません。これは、ユーザーをZoomアカウント上にすでに存在する設定に接続し、 **できません** ユーザーに代わってその設定を作成することは 高度なマッピング属性の大部分は **参照**です。送信した値は、Zoom に既に存在するオブジェクト、つまりサイト、ロール、テンプレート、購入済みプラン、特定の電話番号または内線番号に解決されることが期待されます。すべてに共通するルールは1つです： > 属性が何かを指す場合、その対象はすでに存在していなければならず、送信された内容とまったく同じ表記でなければならず、また、有限のプールを使う場合は未使用の定員が必要です。 参照先オブジェクトが存在しない場合、SCIM はそれを作成もリクエストのキューイングもしません。属性は、プロビジョニングログに返されたエラーとともに完全に失敗するか、あるいは静かに破棄されます。Zoom はペイロードを受け入れ、何も適用せず、成功を報告します。 以下の各節では、各製品ごとに前提条件を分けて、構成手順のナビゲーションパスとサポート記事を示します。まずアカウントレベルの注意事項を読み、その後、プロビジョニングする予定の各製品の節を確認してください。 #### アカウントレベルの前提条件は、どの製品をプロビジョニングする前にも適用されます このガイドの冒頭に記載されているアカウント要件 — バニティURL、SSO、SCIM 承認、および確認済みの関連ドメイン — は、以降のすべての属性の前提条件です。これら4つはすべて、 **高度な** → **セキュリティ** / **シングルサインオン（SSO）** / **関連ドメイン**を参照してください。 [Zoom + Microsoft Entra ID の SSO/SCIM 設定](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121). さらに2点、明示しておく価値があります： * **席を購入することは、割り当てることと同じではありません。** SCIM が割り当てを行いますが、まず席が存在していなければなりません。参照： [ユーザーへの Zoom ライセンスの割り当てまたは削除](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064911). * **席は、要求されている正確なプランに属していなければなりません。** その特定のプランに空き席がない場合、たとえアカウント内の別のプランに余剰の定員が表示されていても、ライセンス属性の送信は失敗します。 #### Zoom Phone Zoom Phone には、参照属性のセットが最も多く含まれています。これは、Zoom Phoneユーザーが、事前購入または事前構築された複数のインフラ要素から組み立てられるためです。 | 属性 | すでに存在していなければならないもの | 作成方法 | | -------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Zoom Phone ライセンス自体 | 利用可能な Zoom Phone の席 — 以下のものを接続する前提となる権利。 | 事前に購入します。参照： [Zoom Phone ライセンスの購入と割り当て](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077929). | | `zoomPhoneSite` | 送信される値とまったく同じ名前のサイト。属性を省略すると、複数のサイトが有効になった時点でデフォルトで存在するアカウントのメインサイトが割り当てられます。 | 管理センター → 製品の設定 → 電話システム → 会社情報 → **サイトを追加**、または **インポート** による一括作成。参照： [複数のサイトの管理](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). | | `zoomPhoneNumber` | アカウントに購入またはポートされた、現在未割り当ての電話番号。他のユーザー、コールキュー、または自動受付がすでに保持している電話番号は再利用できません。 | 管理センター → 製品の設定 → 番号 → 電話番号。ここで購入またはポートし、対象の番号は未割り当てのままにして、SCIM がそれを取得できるようにします。参照： [Number Management を使用して電話番号を管理する](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0074457) と [電話番号の管理](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060212). | | `zoomPhoneExtNumber` （特定の値のみ） | 3～6桁の内線番号で、まだ使用されていないもの。送信時には不要です `0`、これにより割り当てはZoomに委任されます。 | 管理センター → 製品の設定 → 電話システム → ユーザーと部屋 → 内線番号を保持しているオブジェクトを選択 → **プロフィール** → **内線番号** → **編集**。参照： [電話ユーザー設定の変更](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069338). | | `zoomPhoneCallingPlan` | 購入済みで、利用可能な定員があり、その正確なプランコードで参照される通話プラン。 | 事前に購入します。参照： [Zoom Phone ライセンスの購入と割り当て](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077929) と [電話ユーザーの管理](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069309)。プランコードは [Zoom Phone 通話プランのリファレンス](https://developers.zoom.us/docs/api/references/phone-calling-plans/)、または `型` として [通話プランの一覧](https://developers.zoom.us/docs/api/references/phone-calling-plans/) API によって、利用可能な席数とともに返されます。 | | `zoomPhoneCallingPlanSubscription` （複数サブスクリプションのアカウントのみ） | 同じプランに対してアカウントが複数のサブスクリプションを持っている場合に、そのプランが参照すべき特定のサブスクリプション。 | プランと請求 → サブスクリプション管理。 | **内線番号プールは、ユーザーだけでなくオブジェクトの種類全体で共有されます。** コールキュー、自動受付、共有回線グループ、共用エリア電話はすべて、同じ範囲から内線番号を消費します。これは、「内線番号がすでに使用中です」エラーの最も一般的な原因です。管理者がユーザー一覧だけを確認すると、その内線番号は空いているように見えるからです。 **ポート済みの番号は、ポートが完了するまで割り当てできません。** 番号はアカウント内に存在し、かつ未割り当てである必要があります。ポートを開始しても、どちらの条件も満たされません。 **サイトが最も一般的な障害要因です** 作成には独自の要件があるためです。サイトの住所は緊急通話サービスの基盤となるため、実在する住所データベースに照らして検証されます。架空の住所と郵便番号の組み合わせは、検証エラーにより拒否されます。サイトを一括インポートする場合、自動受付列には次の値が必要です `はい` インターフェースに表示されるラベルテキストではありません。また、発信者ID名は主に米国とカナダに適用され、検証エラーが発生する場合は空白のままにできます。 #### Zoom コンタクトセンター コンタクトセンターのプロビジョニングは、ロールとテンプレートに基づいて行われます。個々の属性は既存のコンタクトセンターオブジェクトに解決される必要があり、テンプレートには専用のSCIM属性がない設定が含まれます。 | 属性 | すでに存在していなければならないもの | 作成方法 | | ------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `zoomContactCenterPackage` | パッケージ — `エッセンシャル`, `プレミアム`、または `エリート` — 未使用のシートを含めて購入済みです。 | 事前に購入してください。Premiumでは、追加パッケージを先に購入するためにZoomサポートへの連絡が必要になる場合があります。以下を参照してください [Zoom コンタクトセンターのユーザー設定の変更](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060874). | | `zoomContactCenterAddonsPlan` | 購入済みで定員を持つアドオンプラン。 | 事前に購入してください。アカウントプランと請求情報。 | | `zoomContactCenterRole` | スタンダードまたはカスタムのロールを、正確な名前で指定します。省略すると、デフォルトで存在するデフォルトのエージェントロールが割り当てられます。 | コンタクトセンター管理 → ロール → **追加** → 権限を設定する → **保存**。参照： [Zoom コンタクトセンターのロールの管理](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0061941). | | `zoomContactCenterRegion` | リージョン。省略すると、設定が必要なアカウントのメインリージョンが割り当てられます。 | コンタクトセンター管理 → 環境設定 → リージョン → **リージョンを追加** → 名前を入力し、SIPゾーンを選択する → **追加**。参照： [Zoom コンタクトセンターのリージョンの管理](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0057668). | | `zoomContactCenterUserTemplate` | 正確な名前のユーザーテンプレート。追加タイプのテンプレートはユーザー作成時に適用され、更新タイプのテンプレートは更新時に適用されます。 | コンタクトセンター管理 → ユーザー → テンプレート → **テンプレートを追加** → 選択 **追加** → ロール、パッケージ、キュー、スキルを設定する → **追加**。参照： [Zoom コンタクトセンターのユーザー設定テンプレートの管理](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077757). | {% hint style="danger" %} **警告** リージョンを作成する前に、Zoomサポートによってコンタクトセンターのリージョン機能を有効にする必要があります。また、各ユーザーは必ず1つのリージョンに属します。これはセルフサービスで切り替えられる設定ではなくサポートリクエストであるため、複数リージョンへの展開を予定している場合は早めに依頼してください。 {% endhint %} **受信トレイ、キュー、スキルにはSCIM属性がありません。** これらをプロビジョニングするには、コンタクトセンター管理で事前に作成し、ユーザーテンプレートに関連付けて、そのテンプレートを次を通じて割り当てます `zoomContactCenterUserTemplate`。したがって、これらは次の前提条件になります *テンプレート* 個々のユーザーではなく、— 要件の変更に応じて維持する唯一のオブジェクトもテンプレートになります。
オブジェクト作成方法
キューコンタクトセンター管理 → キュー → キューを追加 → 名前、チャネル、エージェント → 保存。参照： Zoom コンタクトセンターのキューの管理.
スキルコンタクトセンター管理 → スキル → カテゴリを選択する → スキルを追加 → 名前 → 追加。参照： スキルとスキルカテゴリの管理.
受信トレイコンタクトセンター管理 → 受信トレイ → 受信トレイを追加。参照： Zoom コンタクトセンターの受信トレイの管理.
**テンプレートと個別属性の両方が指定されている場合、個別値が優先されます。** テンプレートを併せて送信する `zoomContactCenterRole` とは、ロール属性がテンプレートのロール設定より優先されることを意味するため、参照先のロールとテンプレートの両方が存在している必要があります。 #### Zoom Revenue Accelerator | 属性 | すでに存在していなければならないもの | 作成方法 | | ------------------------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `zoomRevenueAcceleratorPlan` と `zoomRevenueAcceleratorSubscription` | オンラインの座席がある購入済みの ZRA プランまたはサブスクリプション。 | 事前に購入してください。アカウントプランと請求情報。 | | `zoomRevenueAcceleratorRole` | ロール、スタンダード、またはカスタム — たとえば `営業マネージャー` — 正確にその名前で。 | ユーザー管理 → ロール → **Revenue Accelerator** タブ → **+ ロールを追加** → 名前と説明 → **追加** → 権限を設定する → **変更を保存**。参照： [Zoom Revenue Accelerator ロール管理の使用](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0059285). | | `zoomRevenueAcceleratorSegment` | ユーザーが所属するセグメント。 | Revenue Accelerator 管理者設定。 | | `zoomRevenueAcceleratorRegion` | 地域 — たとえば、 `米国`. | Revenue Accelerator 管理者設定。 | #### Zoom Workplace ライセンスとアカウントのロール 上記の3つの製品を超えて、標準ユーザーレコードには、同じルールに従うロールとライセンスの参照が含まれます。 | 属性 | すでに存在していなければならないもの | 作成方法 | | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `ロール[]` (`値` / `表示`) | 正確に指定されたアカウント ロール。ロールはSCIMによって参照され、SCIMによって作成されることはありません。 | ユーザー管理 → ロール → **ロールを追加** → 名前と説明 → 権限を設定する。参照 [ロール管理の使用](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064983). | | `zoomWorkplace` およびその他のライセンスまたはアドオン属性 — ホワイトボード、Scheduler、Clips Plus、翻訳版字幕、ワークフォース管理、品質管理、コンプライアンス管理、CX Insights、AI営業アシスト、およびそれらの `...サブスクリプション` 対応するもの | 未使用の席数で購入された、対応するバンドルまたはアドオン。 | プランと請求 → プラン管理 → プランを編集 → ライセンス数を増やす。参照 [アカウントとアドオンのアップグレード](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0063375). | | `ログインタイプ` (`SSO` / `仕事用メールアドレス`）、の下に `urn:us:zoom:scim:schemas:extension:1.0:ZoomUser` | アカウントに設定された SSO、SSO ログインタイプ用。 | 詳細設定 → [シングルサインオン（SSO）](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121). | ライセンスまたはアドオンの属性では、名前を付ける対象のオブジェクトはありませんが、前提条件の効果は同じです。つまり、その特定のプールにオンラインの席がなければ、割り当ては失敗します。 #### 前提条件のない属性 すべてのベーシックなマッピング属性が該当します。これは、次の項で扱うとおりです **ベーシック マッピング: プロフィール情報** — Zoom はそれらの値をそのまま保存し、既存のオブジェクトに照らして検証することはありません。Zoom 拡張機能の下にある 2 つの属性も同じように動作します: * **自動委任された値** — `zoomPhoneExtNumber` として送信される `0`、Zoom が拡張機能自体を割り当てる場合。 * **アカウントのカスタム属性** — その `{customAttribute}` 任意の文字列を送信するフィールド。 **デフォルト化された参照** は中間的なケースです。省略すると `zoomPhoneSite`, `zoomContactCenterRole`、または `zoomContactCenterRegion` それぞれメインのサイト、デフォルトの Agent ロール、そしてメインリージョンにフォールバックします。それらのデフォルトはそれ自体が存在している必要があり、デフォルトでは存在します。 **グループは一部例外です。** グループのプロビジョニングが有効な場合、SCIM はまだ存在しない Zoom グループを、ソースのグループ名を入力どおりにそのまま使って作成します。このグループには製品構成は一切適用されず、メンバーだけが含まれます。Zoom Phone ポリシー、通話権限、その他のグループ レベルの設定は、グループが表示された後に、引き続き ユーザー管理 → グループ管理 で構成する必要があります。 {% hint style="info" %} **推奨** 属性マッピング作業を開始する前に、Zoom 側の構築を、それ自体の承認が必要な前提フェーズとして扱い、完了と確認を済ませておいてください。サイト、番号、プラン、ロール、テンプレートは、アイデンティティ プロバイダーの構成とは別のチームが所有していることが多く、プロビジョニング テスト中に不足しているオブジェクトを見つけると、事前にその存在を確認するよりもはるかに大きなコストがかかります。 {% endhint %} ### **ディレクトリ データの準備** SCIM はソースに含まれる内容をそのまま送信します。検証、正規化、修正は行いません。属性をマッピングする前に、対象のソースについて次の 3 つを確認してください: * **対象範囲内のすべてのユーザーに対して値が設定されます。** 未入力のフィールドは何も送信せず、または設定されたデフォルトを送信します。 * **その値は、形式と大文字・小文字の表記が一貫しています。** 両方のIDプロバイダーにおける比較ロジックは厳密に一致します。 * **その値は、Zoom が期待する値と完全に一致します。** Zoom は、サイト名、ロール名、またはプラン値をあいまい一致で照合しません。 既存のフィールドでこの3条件すべてを満たせない場合、この連携のために意図的に値が設定された専用設計の属性の方が、他のシステムも書き込むフィールドを流用するよりも持続可能です。 {% hint style="info" %} **推奨** IDプロバイダーの設定に手を付ける前に、信頼できる情報源を決めてください。失敗したSCIM導入の大半は、プロビジョニングの問題として現れているディレクトリデータの問題です。 {% endhint %} ### **参考シナリオ** このガイド全体では、4つのシナリオを使用します。それらのビジネス要件とZoom 側の前提条件は、IDプロバイダーに関係なく同じであるため、ここで一度だけ定義します。各IDプロバイダー固有のセクションの最後では、そのプラットフォームで4つすべてを実装する方法を示します。 #### シナリオ0: 部門、最初のベーシックなマッピングとして ユーザーの部署は、ディレクトリから取得された情報として、ユーザーのZoomプロフィールに表示されるはずです。これは、最初のエンドツーエンドテストとして以前推奨されたベーシックなマッピングであり、手順を両方のアイデンティティプロバイダーのセクションで実施するためにここに含まれています。 **Zoom側の前提条件。** ありません。Zoom は送信された値をそのまま保存し、既存のオブジェクトと照合して検証することはありません。 **属性。** 親は以下の3つのシナリオとは異なることに注意してください— `部署` エンタープライズ拡張機能の下にあり、Zoom拡張機能の下ではありません。 | 属性 | 型 | メモ | | ------------------------------------------------------------- | --- | ---------------------------------------------------------------- | | `urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー:部署` | 文字列 | 自由テキスト。両方のIDプロバイダーにはすでに `部署` ユーザープロファイル上のフィールドなので、新しいソース属性は不要です。 | **なぜここから始めるのか。** Zoomプロファイルに部門値が正しく表示されれば、スキーマ宣言、マッピング、スコープ、そしてプロビジョニングログを読み取る能力が証明されます。ライセンスや電話設定を危険にさらすことなく、です。以下の各高度なシナリオは、属性がどこを指しているかだけが異なります。 **まず、すでにマッピングされているか確認してください。** デフォルトのマッピングは Entra ID と Okta で異なり、両ベンダーが Zoom 連携を更新すると、それらは変更されます。既存の一覧を次で確認してください **プロビジョニング** → **マッピング** Entra で、または **Zoom 属性マッピング** と **未マッピングの属性を表示** Oktaで有効になっています。もし `部署` すでにマッピングされている場合は、重複として宣言するのではなく検証してください — そして、代わりに属性を一から設定したい場合は、 `コストセンター`, `組織`、および `社員番号` 同じ親の下にあり、同じように動作します。 #### シナリオ 1: Zoom Phone サイトと内線番号の自動割り当て ユーザーは、オフィスに基づいて適切な Zoom Phone サイトに配置され、管理者の介入なしに内線番号を受け取る必要があります。 **Zoom側の前提条件** サイトはすでに存在している必要があります。配下に作成してください **管理者センター** → **製品設定** → **電話システム** → **会社情報** → **サイトを追加**、または一括で次を通じて **インポート**。サイトの住所は、緊急通話サービスをサポートしているため、実在する住所データベースと照合して検証されます。そのため、架空の住所と郵便番号の組み合わせは検証に失敗します。 **属性。** どちらも名前空間を取ります `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:` その後に名前が続きます。 | 属性 | 型 | メモ | | -------------------- | --- | -------------------------- | | `zoomPhoneSite` | 文字列 | Zoom サイト名と1文字ずつ一致する必要があります | | `zoomPhoneExtNumber` | 文字列 | `0` 自動割り当てをトリガーします | **値が重要な理由 `0` 重要です。** Zoom は、ユーザーではなく通話キューや自動受付に割り当てられている内線番号も含め、どの内線番号がすでに使用中かを把握している唯一のシステムです。割り当てを Zoom に委任すると、プロビジョニング失敗の一分類全体を排除できます。代わりにディレクトリから内線番号を取得するのは、既存の内線番号を保持することが重要な移行中には適切ですが、マッピングは `0` 移行が完了したら、将来参加するユーザーがディレクトリデータが無期限に維持されることに依存しないようにするためです。 {% hint style="info" %} **注記** Zoom Phone アカウントのデフォルト サイトは通常、正確に `メイン サイト`、下に表示される **管理者センター** → **製品設定** → **電話システム** → **会社情報**。信頼する前に、特定のアカウントの名前を確認してください。名前は変更できます。 {% endhint %} #### シナリオ 2: 国ごとに異なる Zoom Phone 通話プラン 多国籍の組織は、個別の Zoom Phone 通話プランを購入しており、各ユーザーが自国に合ったプランを受け取る必要があります。 **Zoom側の前提条件。** 通話プランはすでに購入され、アカウントでオンラインになっている必要があります。プランの値は次に記載されています [Zoom Phone 通話プランのリファレンス](https://developers.zoom.us/docs/api/references/phone-calling-plans/). **属性。** `zoomPhoneCallingPlan` （文字列）。 **正しいプランコードを取得する方法。** `zoomPhoneCallingPlan` 数値のプランコードを受け取り、プラン名は受け取りません。取得する最も確実な方法は [通話プランの一覧](https://developers.zoom.us/docs/api/references/phone-calling-plans/) API は、各プランの `名前`、その `型` — あなたがマップするコード — とその `契約済み` と `オンライン` 座席数。したがって、1回の通話でプランの存在を確認し、送信する値を示し、割り当てるための定員があることを検証します。 Zoomウェブポータルでは表示名のみが表示され、コードは表示されないため、ポータルだけで作業する管理者は、その表示名を使って次のものを翻訳する必要があります。 [Zoom Phone 通話プランのリファレンス](https://developers.zoom.us/docs/api/references/phone-calling-plans/) — たとえば、 `UNLIMITED_PLAN_US_CA` です `200` と `UNLIMITED_PLAN_GB_IE` です `202`。参照資料にはポータルの文言ではなく定数名が記載されているため、正確なテキストではなく、プランの特性 — 地域、および従量制か無制限か — で一致を確認してください。 別途、Zoom の SCIM2 API リファレンスには、請求プラン名として次のようなものが示されています `phone_calling_usca_monthly_unlimited` その例のペイロードにあります。その識別子は、 *購入* サブスクリプションを購入するためのものであり、ユーザーにプランを割り当てるためのものではありません。プランがどのサブスクリプションを参照するかを指定する必要がある場合は、それは `zoomPhoneCallingPlanSubscription`. **理由 `-1` フォールバックとして使用されます。** SCIM2 リファレンス文書では `-1` すべての通話プランを削除する値として説明されています。これを一致しないユーザーに使用すると、値をまったく送信しない場合の曖昧さではなく、プランが割り当てられないという決定的で目に見える結果になります。また、ユーザーを削除せずに通話権限を解除するためのすっきりした方法も提供します。 #### シナリオ 3: Zoom コンタクトセンター パッケージ、ロール、リージョン コンタクトセンターのエージェントは、オンボーディングの時点で正しい ZCC パッケージとロールを割り当てられるべきであり、事後に手動で設定されるべきではありません。このシナリオは、この方法が製品に依存しないことを示しています。手順自体は変わらず、変わるのは属性名と許可される値だけです。 | 属性 | 型 | 許可される値 | | -------------------------- | --- | ------------------------------------------- | | `zoomContactCenterPackage` | 文字列 | `エッセンシャル`, `プレミアム`, `エリート` | | `zoomContactCenterRole` | 文字列 | 任意の ZCC ロール名。デフォルトは `エージェント` 省略した場合。 | | `zoomContactCenterRegion` | 文字列 | 構成済みの任意の ZCC リージョン。省略した場合はメインリージョンがデフォルトです。 | **属性を意図的に省略する場合。** 退出 `zoomContactCenterRegion` 単一リージョンのデプロイメントでは未マッピングのままにします。Zoom のドキュメントに記載されたデフォルトがすでに正しいためです。デフォルトが正しい属性をマッピングするより、省略する方が望ましいです。マッピングはすべて保守上の負担になります。 **運用上の注意。** SCIM2リファレンスにも記載されています `zoomContactCenterUserTemplate`、これは事前構築された ZCC テンプレートを適用します。追加型テンプレートはユーザー作成時に適用され、更新型テンプレートは更新時に適用されます。テンプレートと個々の属性値の両方が同じリクエストで指定された場合は、個々の値が優先されます。ZCC の設定が複雑で、多数の個別の属性マッピングにわたって維持するのが手に負えなくなるほどであれば、テンプレートの利用を検討する価値があります。 ### **Zoom側の認証とよくあるエラー** 各 ID プロバイダーにはそれぞれ独自のログがあり、各 ID プロバイダーのステップ 6 に記載されています。下記の Zoom 側のログは両方で同一であり、Zoom が実際に受信した内容の確定レコーディングです。 #### Zoom App Marketplace 通話ログは、完全なリクエストとレスポンスのやり取りを表示します 1. Zoomウェブポータルにアカウントオーナーとしてサインインします。 2. 〜へ移動 [**Zoom App Marketplace**](https://marketplace.zoom.us/) → **管理** → **アカウント上のアプリ**. 3. ID プロバイダー接続を表すアプリケーションを選択してください。Entra では通常、 **Azure Identity** または同様の名称です。 4. 開いてください **通話ログ** タブ。 5. 使用 **エンドポイントで検索**、または日付範囲、メソッド、ステータスのフィルターを使用して、関連する通話を見つけます。 6. 展開するには行を選択します。 7. 確認 `requestBody` 送信された内容を正確に確認するには、 `レスポンス` Zoom が返した内容を、生成された Zoom ユーザー ID を含めて正確に確認するには、 `httpStatus`、および結果として得られた属性セットを確認します。 Zoom は最新の 100 件の API リクエストログを保持しているため、失敗の原因は後続のプロビジョニング作業で上書きされる前に、速やかに調査してください。 #### 一般的なプロビジョニング エラーとその原因
コードメッセージ原因と解決策
400アカウントでシングルサインオン（SSO）が有効になっていません。SSO は SCIM の前提条件です。まず、Zoomアカウントで SSO を有効にする必要があり、SSO を設定する必要があります。
400ユーザーは非アクティブかロックされています。対象のZoomユーザーは現在の状態では更新できません。Zoomウェブポータルでアカウントの状態を修正してください。
403権限が不十分なため、リクエストは拒否されました: "ユーザー:編集"。SCIM 接続の背後にある認証情報には、必要なスコープがありません。オーナーまたは管理者のアカウントで接続を再認可してください。
404ユーザーは存在しません。アイデンティティプロバイダーは、ユーザーを既存の Zoom ユーザーに関連付けませんでした。一致する属性とユーザー名の形式を確認してください。
409メールドメインがアカウントに関連付けられたドメインと一致しません。ユーザーのメールドメインはZoomアカウントに関連付けられていません。プロビジョニングする前に、そのドメインを関連付けて確認してください。
409有料ユーザーは追加できません。要求された種類のライセンスはオンラインではありません。アカウントに空き定員があるか、ユーザーをベーシックとしてプロビジョニングしてください。
409[bundle name]ではこれ以上ユーザーを作成できません。特定のバンドルには残りの席がありません。Workplace ビジネスプラス、エンタープライズ プレミア、プロ プラス、および教育機関向けの同等プランに適用されます。
429リクエストが多すぎます。プロビジョニングがZoomのレート制限を超えました。複数のサイクルにわたって続く場合は調査してください。
#### ある失敗モードではエラーがまったく発生しません Zoomが受け入れるものの何にも対応しない値 — 末尾にスペースがあるサイト名や、Zoomで後から名前変更されたロール名など — は、構文上は受け入れられても何にも適用されない場合があります。この発生はログエントリで示されません。同じ問題のプラットフォーム固有のバリエーションはステップ6で扱います。 {% hint style="info" %} **注記** Zoom と ID プロバイダーがユーザーの構成について食い違う場合は、ID プロバイダーを正として扱い、そこで値を修正してください。Zoomウェブポータルで直接編集すると、次のプロビジョニング イベントで上書きされる状態になり、根本的な問題の診断が難しくなります。 {% endhint %} ## **Entra ID で SCIM を構成する** #### Entra ID の追加要件 * エンタープライズ アプリケーションへのアクセスを持つ Entra ID 管理者権限 * ユーザーが使用するメール ドメインが、Entra ID テナントでカスタム ドメインとして検証済みであること #### Entra ID の追加の制限事項 * 属性マッピングのソースは Entra のみ *ユーザー オブジェクト* 属性。セキュリティ グループは Zoom 属性に値を直接供給できません。グループ メンバーシップが制御するのは範囲であり、値ではありません。 * 増分プロビジョニングのサイクルは約 40 分ごとに実行されます。プロビジョニングを有効にしても、変更はすぐには反映されません。 * この `コラボレーション` の値 `userType` Entra ID では、Microsoft 固有の制限によりサポートされていません。 {% hint style="info" %} **注記** スタンダードのプロビジョニング構成は、次のいずれかから実行できます `entra.microsoft.com` または `portal.azure.com`。ただし、手順 1 で使用するスキーマ エディターにアクセスできるのは、Azure Portal の URL に次のものを `forceSchemaEditorEnabled` パラメーターを追加した場合のみです。このフラグは、影響を及ぼしません `entra.microsoft.com`。この部分のすべての手順では、構成の途中でポータルを切り替えないように、手順 1 の Azure Portal リンクを使用してください。 {% endhint %} ### 手順 1: Zoom アプリケーション スキーマで属性を宣言する 属性の宣言は、属性ごとに 1 回だけ行う操作です。マッピングを構成する前に、使用する予定のすべての属性を宣言し、手順 2 でそれらのすべてのターゲットがオンラインになっているようにしてください。 1. スキーマ エディターの URL を使用して Azure Portal にサインインしてください: `https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true#home` 2. 下 **Azure サービス**、選択してください **Microsoft Entra ID**. 3. 左側のナビゲーション メニューの下にある **管理**、クリック **エンタープライズ アプリケーション**. 4. アプリケーションの一覧で、Zoom アプリケーションをクリックします。\ **注記**: アプリケーション名は、アプリケーションが作成されたときに Entra 管理者によって定義されます。多くの場合、次のように名付けられます **Zoom** または **Zoom SSO**、ただしテナントによって異なる場合があります。 5. 左側のナビゲーション メニューの下にある **管理**、クリック **プロビジョニング**.\ **注記**: Azure は現在、2 つのレイアウトのいずれかを表示します。従来の画面では、選択 **属性マッピングの編集** の **プロビジョニングの管理**。新しい体験では、ページは1つの **概要** タブ; 選択 **プロビジョニング** 左側のメニューから再度。どちらの経路でも同じ目的地に到着します。 6. クリックする **マッピング** ドロップダウン、次にクリック **Microsoft Entra ID ユーザーをプロビジョニングする**.\ **注記**： レガシー命名をまだ表示しているテナントでは、このオプションは次のように表示されます **Azure Active Directory ユーザーのプロビジョニング**. 7. 左下隅で、次を選択 **詳細オプションを表示** チェックボックス。 8. クリック **Zoom の属性リストを編集**. 9. 最初の空行までスクロールし、以下を入力してください: * **名前**: 完全な属性文字列を入力してください。たとえば `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhoneSite` * **型**: 選択 **文字列** または **ブール値**、SCIM2 API リファレンスに記載されたデータ型に一致するようにします。 10. 追加の各属性について手順 9 を繰り返します。 11. 左上隅で、クリック **保存**. {% hint style="warning" %} **ご注意** 属性名は大文字と小文字が区別され、API リファレンスと完全に一致している必要があります。 `zoomPhoneSite` は有効です; `zoomphonesite` と `ZoomPhoneSite` は有効ではありません。大文字と小文字を誤った属性は、エラーなしでスキーマエディターに受け入れられ、Zoom API では静かに失敗します。 次のようにドキュメント化されている属性については `真偽値`, **文字列** マップされたソースがリテラルテキストを提供している場合は、これも有効です `真` または `偽`。選択する **文字列** ソースが Entra 拡張属性で、テキストを格納する場合には、こちらの方が実用的であることが多いです。 {% endhint %} ### 手順 2: ディレクトリ ソースを属性にマップする Entra ID では 3 つのマッピングの種類が用意されており、その中から選ぶことは構成における最も重要な決定です。
マッピングの種類使用する場面動作
直接Entra のフィールドには、Zoom が期待する正確な値がすでに入っています。ソース値をそのまま変更せずに通します。
定数対象範囲内のすべてのユーザーに同じ値が適用されます。プロビジョニングされた各ユーザーに固定値を送信します。
式値は、ユーザー属性によって導出、変換、または変化させる必要があります。ソース フィールドに対して式を評価し、その結果を送信します。
**マッピングを作成するには:** 1. に戻る **プロビジョニング** → **マッピング** → **Microsoft Entra ID ユーザーをプロビジョニングする**. 2. 左下隅で、 **新しいマッピングを追加**. 3. 選択したタイプに従ってマッピングを設定する — 下のガイダンスを参照してください。 4. クリックする **ターゲット属性** ドロップダウンを開き、手順 1 で宣言した属性を選択します。 5. クリックする **この属性を使用してオブジェクトを照合する** ドロップダウンを開き、選択 **いいえ**.\ **注記**: カスタム Zoom 属性は構成値であり、ID 照合キーではありません。Entra ユーザーと Zoom ユーザーを関連付ける属性、通常は `ユーザー名` — は **はい**. 6. クリックする **このマッピングを適用** ドロップダウンを開き、選択 **常に**に設定すると、値は作成時とその後の更新時の両方に適用されます。 7. クリック **OK**. 8. 各属性について繰り返し、次に **保存** ページ上部の **属性マッピング** ページ。 #### 直接マッピングは、既存のフィールドを変換せずにそのまま通します * **マッピングの種類**: **直接** * **ソース属性**: 値がすでに Zoom の期待値と文字単位で一致している Entra のフィールド * **null 時のデフォルト値（オプション）**: ソース フィールドが空の場合に適用されるフォールバック 直接マッピングは最も壊れにくい選択肢であり、ディレクトリ データで対応できるなら、どこでも優先すべきです。もし `physicalDeliveryOfficeName` — として表示され、 **オフィスの位置情報** Entra のユーザー プロファイルに表示される — には Zoom Phone のサイト名と文字どおり一致する値がすでに含まれている場合、直接マッピングしてもロジックはまったく不要です。 {% hint style="info" icon="lightbulb" %} **ヒント** 入力する **null 時のデフォルト値** 、ソース値が欠けていることで失敗や意図しない結果が発生する場合にいつでも。デフォルト値として `メイン サイト` サイト マッピングでは、オフィスの位置情報がないユーザーでも未定義の状態に陥るのではなく、正常にプロビジョニングされます。 {% endhint %} #### 定数マッピングは、対象範囲内の全体に 1 つの値を適用します * **マッピングの種類**: **定数** * **定数値**: 送信する固定値 定数マッピングは単一構成の展開に適しており、いくつかの Zoom 固有の動作の基盤でもあります。 `zoomPhoneExtNumber` を `0` に定数として設定すると、Zoom に対してユーザーのサイト内で次にオンラインの内線を割り当てるよう指示し、内線の衝突を完全になくします。 #### 式マッピングは、プロビジョニング時に値を変換または導出します * **マッピングの種類**: **式** * **式**：ネストされた `IIF()` 1つ以上のソース属性を評価するステートメント ディレクトリ値とZoom値が同一の文字列でない場合は常に、式のマッピングが必要です： ``` IIF([officeLocation]="London","LON-01", IIF([officeLocation]="Manchester","MAN-01", "メインサイト")) ``` {% hint style="danger" %} **警告** 式は、大文字・小文字を含め、入力されたとおりにテキストを正確に比較します。 `GB` と `gb` は異なる値であり、同様に `イギリス` と `イギリス`。比較に失敗してもエラーは発生せず、デフォルト分岐に流れ、ユーザーは誤った構成で気付かれないままプロビジョニングされます。 {% endhint %} ソース値を `ToUpper()` そして、大文字のリテラルと比較して、大文字・小文字の不一致をなくします： ``` IIF(ToUpper([country])="GB","202", IIF(ToUpper([country])="UNITED KINGDOM","202", "-1")) ``` #### ソースフィールドの形式は、Entraユーザーの作成方法によって異なります これは、見た目は正しいのに、ユーザー全体で一貫しない動作をする式マッピングの最も一般的な原因です。 * **使用位置情報** は、Microsoft によって、常に有効な ISO 3166-1 alpha-2 コードを含むことが強制されており、たとえば `GB`、これはライセンスと機能の利用可否を制御するためです。このフィールドは信頼できます。 * **国または地域** そのような制約はなく、内容は作成方法に依存します。Entra 管理ポータルの GUI で作成されたユーザーは、完全な国名のドロップダウンから選択するため、このフィールドには通常 `イギリス`。CSV インポートまたは PowerShell で作成されたユーザーには通常 `GB` — 強制ではなく、慣例としてです。 ユーザーが複数の方法で作成されているテナントでは、 `国` 一貫した形式にはなりません。式を作成する前にフィールドを標準化するか、上記のように両方の形式を明示的にテストしてください。 ### 手順 3: ユーザーとグループをプロビジョニング対象に含める 割り当てによって、構成がどのユーザーに影響するかが決まります。アプリケーションの割り当て範囲外のユーザーは、どのマッピングの影響も受けないため、割り当てはロールアウト時の主要な安全制御になります。 1. 移動先 **Microsoft Entra ID** → **エンタープライズ アプリケーション** → お使いのZoomアプリケーション → **ユーザーとグループ**. 2. クリック **ユーザー/グループを追加**. 3. 下 **ユーザーとグループ**、対象のユーザーまたはセキュリティ グループを選択します。 4. 下 **ロールを選択**、適切なロールを選択します。 5. クリック **割り当てる**. 実際には、重要なのは 2 つのロール値だけです。次のような他のオプションは、 **法人** と **プロ** は、段階的に廃止されつつある旧名称であるか、まれなシナリオ向けです。
ロール効果
ベーシック有償ミーティングライセンスなしでユーザーをプロビジョニングします。Zoom Phone 通話プランのようなカスタム属性が有償エンタイトルメントの割り当てを担う場合に、これを選択します。
ライセンスユーザーZoomアカウントの デフォルト ライセンスプラン（例：Zoom Workplace エンタープライズ Plus）。この画面では特定のバンドルを選択できません。デフォルトはZoom側で設定されます。
このロールの選択は、プロビジョニングされるカスタム属性の数にかかわらず、アプリケーションに追加される各ユーザーまたはグループに1回適用されます。 **EntraグループをZoomグループとしてプロビジョニングするには**（デフォルトでは無効になっています）： 1. 移動先 **プロビジョニング** → **マッピング** を選択し、 **Microsoft Entra IDグループのプロビジョニング**. 2. 切り替える **有効** へ **はい**. 3. デフォルトのマッピングが設定されていることを確認します： `表示名` → `表示名`、および `メンバー` → `メンバー`. 4. クリック **保存**. 5. に戻る **ユーザーとグループ** 個々のメンバーだけでなく、グループ自体がアプリケーションに割り当てられていることを確認します。グループのプロビジョニングでは、直接割り当てられたグループのみが処理されます。 {% hint style="warning" %} **注意：SCIMがグループに対して行うことと行わないこと** 一致する名前のZoomグループがまだ存在しない場合、SCIMはEntraグループの `表示名` 入力どおりの名前で作成します。このグループはメンバー付きで作成されますが、 **製品設定はありません**。管理者は引き続き **ユーザー管理** → **グループ管理** をZoomウェブポータルで開き、意図した設定（グループレベルのZoom Phoneポリシー、発信権限、その他の製品設定）を適用する必要があります。SCIMはグループの存在とメンバーシップをプロビジョニングしますが、そのグループがZoom内で何を行うかは定義しません。 {% endhint %} ### ステップ4：オンデマンド プロビジョニングで検証する **オンデマンド プロビジョニング** は、次とは独立して実行されます： **プロビジョニングの状態** の切り替え。このため、検証にはこれが適切なツールです。このステップを含め、ここまでのすべてのステップは、プロビジョニングをオフのまま完了できます。 1. 移動先 **プロビジョニング** → **プロビジョニングの概要**. 2. クリック **オンデマンド プロビジョニング**. 3. 単一のテストユーザーを検索して選択し、次をクリックします： **プロビジョニング**. 4. 結果を確認します。Entraは、すべてのプロビジョニングイベントで実行する4つのステージを報告します： **インポート**, **スコープ内かどうかを判定**, **照合**、および **プロビジョニング** — それぞれ個別に展開できます。 5. 表示される属性値が意図どおりであることを確認します。 6. Zoomウェブポータルにサインインし、設定が適用されたことを確認します。 {% hint style="info" %} **推奨** 対象母集団の中で最も *難しい* ケース（海外のユーザー、別の方法で作成されたユーザー、またはソースフィールドが空のユーザー）を表すユーザーで検証します。単純なケースだけを対象としたテストでは、ステップ2で説明した障害モードは明らかになりません。 {% endhint %} ### ステップ5：継続的なプロビジョニングを有効にする プロビジョニングを有効にすると、スコープ内のすべてのユーザーに対して設定が本番環境で有効になります。まずステップ1～4を完了し、検証してください。 1. 移動先 **Microsoft Entra ID** → **エンタープライズ アプリケーション** → お使いのZoomアプリケーション → **プロビジョニング** → **プロビジョニング**. 2. 切り替える **プロビジョニングの状態** へ **オン**. 3. クリック **保存**. 最初のサイクルには約40分かかる場合があります。その後の増分サイクルは約40分間隔で実行されます。新規参加者、属性の変更、非アクティブ化は即時ではなく、そのスケジュールに従って同期されます。 ### ステップ6：Entraのプロビジョニングログを使用して確認する 1. 移動先 **Microsoft Entra ID** → **エンタープライズ アプリケーション** → お使いのZoomアプリケーション → **監視** → **プロビジョニングログ**. 2. テストユーザーを検索またはフィルターし、関連するイベントを選択します。詳細ビューは4つのタブで開きます： **ステップ**, **トラブルシューティングと推奨事項**, **変更されたプロパティ**、および **概要**. 3. 確認する **概要** アクションが成功したか失敗したかを確認するために。 4. 失敗した場合は、開く **トラブルシューティングと推奨事項**、これは、試行されたアクション、影響を受けたユーザー プリンシパル名、および — の下に表示します **詳細** — Zoom の API によって返されたエラーコードと完全なエラーメッセージ。 これは、マッピング画面を調べるよりも信頼性が高い。マッピングが意図して生成するものではなく、送信されたリテラル値を表示するためです。Entra ログが結論に至らない場合は、下に説明されている Zoom App Marketplace の通話ログへ移動してください **Zoom側の認証とよくあるエラー**、これは生のリクエストとレスポンスのやり取りを表示します。 #### Entra ID におけるオンボーディングとオフボーディングの動作 * スコープは主要な安全制御です。アプリケーションの割り当てスコープ外のユーザーは、この構成内のいかなるマッピングによっても変更されることはありません。 * Entra でユーザーを無効化するか、スコープから削除すると、プロビジョニングが自動的に解除され、オフボーディングの流れが完結します。 * すべての失敗は、それに対応するログエントリを生成します — ただし、前述のサイレント失敗に関する注意点があります。 ### ステップ 7: Entra ID で参照シナリオを適用する シナリオ、前提条件、属性定義は [**参照シナリオ**](#reference-scenarios) セクションにあります。ここでは Entra のマッピングのみを示します。 **シナリオ 0 — 部署。** ステップ 1 で、 `urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー:部署` として宣言する **文字列**、エンタープライズ名前空間を使用し、Zoom 側ではないことに注意してください。これを次のようにマップします **直接** Entra から `部署` フィールド。不要 **null 時のデフォルト値** 必要ありません — 空のソースフィールドは単に何も送信せず、Zoom 側のオブジェクトが存在する必要もありません。 **シナリオ 1 — Zoom Phone サイトと自動内線番号。** マップ `zoomPhoneSite` として宣言する **直接** から `physicalDeliveryOfficeName`、および **null 時のデフォルト値** に設定すると `メイン サイト`。マップ `zoomPhoneExtNumber` として宣言する **定数** の値で `0` 既存の内線番号構成を移行している場合を除きます。オフィスの位置情報が Zoom サイト名と完全に一致しない場合は、別の値を代用してください。 **式** ステップ 2 で示されている形式のマッピング。 **シナリオ 2 — 国ごとに異なる通話プラン。** Entra は グループ から値を取得できないため、式が必要です。これを追加の `IIF()` 国ごとにレイヤーを追加し、ステップ 2 で説明されている alpha-2 形式と全文形式の両方をアカウントに入れて考慮します: ``` IIF(ToUpper([country])="GB","202", IIF(ToUpper([country])="UNITED KINGDOM","202", IIF(ToUpper([country])="US","200", IIF(ToUpper([country])="UNITED STATES","200", "-1")))) ``` 通話プラン属性が有料の権利を割り当てる場合は、選択 **ベーシック** ではなく **ライセンスユーザー** ステップ 3 で。選択すると **ライセンスユーザー** さらにアカウントのデフォルトのライセンスが適用されるため、意図した商業上の結果にならない場合があります。 **シナリオ 3 — コンタクトセンター パッケージ、ロール、地域。** マップ `zoomContactCenterPackage` 〜を伴う **式** エージェントの階層を区別するディレクトリ フィールドによって駆動され、 `zoomContactCenterRole` として宣言する **直接** ロール名を保持するフィールドから。退出 `zoomContactCenterRegion` 単一リージョンのデプロイでは未マッピングのままにします。 ## **Okta を使用した SCIM の設定** #### Okta の追加要件 * Profile Editor へのアクセス権を持つ Okta 管理者権限 #### Okta の追加制限 * ユーザーが同じ属性に対して競合する値を提供する複数のグループに属している場合、優先度が最も高いグループの値のみが送信されます。手順 5 を参照してください。 {% hint style="warning" %} **注意: 2つのプロファイル、2つの目的** ここで重要なのは、Okta が重要となる 2 つの異なるプロファイルを保持しており、この分離を理解すると最初の混乱の大半を防げることです。その **Okta ユーザープロファイル** は、値が *保存される* ディレクトリ内の人物に対してです。その **Zoom ユーザー アプリケーション プロファイル** は、値が *送信された* Zoom に送信され、その属性には SCIM の外部名と名前空間が含まれます。ユーザーごとの構成にはその両方に加え、それらを接続中のマッピングが必要です。グループ レベルの構成にはアプリケーション プロファイル属性のみが必要で、値はグループ割り当てに設定されます。 {% endhint %} ### 手順 1: Zoom アプリケーション ユーザープロファイルで属性を宣言する これは、実際に値を Zoom に送信する属性です。これを宣言するのは、属性ごとに1回限りの操作です。 1. Oktaの管理コンソールにサインインします。 2. 左側のナビゲーションメニューで、クリック **アプリケーション**、次にクリック **アプリケーション**. 3. 下 **ステータス**、クリック **アクティブ**. 4. クリックする **Zoom** アプリケーション。\ **注記**：アプリケーション名は、アプリケーションが作成されるときにOkta 管理者によって定義されます。多くの場合、 **Zoom**、ただしテナントによって異なる場合があります。 5. クリックする **プロビジョニング** タブ。 6. 下 **Zoom 属性マッピング**、クリック **プロファイルエディターに移動**. 7. 下 **属性**、クリック **+ 属性を追加**. 8. 以下を完了してください: * **データ型**: 選択 **文字列** または **真偽値**、SCIM2 API リファレンスに一致するようにしてください。 * **表示名**: 属性名を入力してください。たとえば `zoomPhoneSite`. * **変数名**: 同じ名前を入力してください。 * **外部名**: Zoom に記載されているとおりに属性名を正確に入力してください。たとえば `zoomPhoneSite`. * **外部名前空間**: 入力 `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomPhoneSite` * **説明** (オプション): この属性が存在する理由と、その値の出所をレコーディングします。 * **属性の種類**: 選択 **個人用** ユーザーごとの値の場合、または **グループ** グループメンバーシップを通じて継承される値の場合。 9. クリック **保存**、または **保存して別のものを追加**. {% hint style="danger" %} **警告** External name と External namespace の両方が正しくなければなりません。Zoom の公開ガイダンスでは、External namespace は完全な URN と指定されています *含む* 属性名 — たとえば `urn:ietf:params:scim:schemas:extension:zoom:1.0:ユーザー:zoomRevenueAcceleratorRole` — 名前空間のみではなく。これは一般的なSCIMの慣例とは異なります。上記の形式に従ってください。これは、Zoomが動作するものとして文書化している構成を反映しているためです。 属性名は全体を通して大文字・小文字を区別します。大文字・小文字が誤っている属性でも、Profile Editor ではエラーなしで受け入れられ、Zoom API では静かに失敗します。 {% endhint %} ### 手順 2: Okta ユーザープロファイルにソース属性を作成する 値がユーザーごとに保持される場合は、この手順を完了してください。すべてのユーザーで値が同一である場合、または代わりにグループレベルで提供される場合は、これをスキップしてください。 1. 左側のナビゲーションメニューで、クリック **ディレクトリ**、次にクリック **プロフィールエディタ**. 2. クリックする **ユーザー** タブ。 3. ～内の **ユーザー** ボックスで、～の下にある **フィルター**、クリック **すべて**. 4. ～の右側にある **Okta**で、～をクリックします **ユーザー** プロファイル。 5. 下 **属性**、クリック **+ 属性を追加**. 6. 以下を完了してください: * **データ型**：ステップ1で宣言したZoom属性と一致させます。 * **表示名** と **変数名**：たとえば、次のような名前を入力します `zoomPhoneSite`. * **列挙型** （オプション）：選択 **列挙された値のリストを定義する** Zoom属性が固定された値のセットのみを受け入れる場合。 * **属性が必須** （オプション）：選択 **はい** 対象範囲内のすべてのユーザーが値を持つ必要がある場合。 7. クリック **保存**. {% hint style="info" icon="lightbulb" %} **ヒント** Oktaユーザープロファイル属性とZoomアプリケーションプロファイル属性には同じ名前を使用します。Oktaでは必須ではありませんが、名前を一致させることでマッピングリストが自己文書化され、属性数の増加に伴うトラブルシューティング時間を大幅に短縮できます。 {% endhint %} 次を使用します **列挙型** Zoomが固定値セットを文書化している場合は常にこのオプションを使用します。たとえば、コンタクトセンターのパッケージ、Workplaceバンドルコード、Revenue Acceleratorプラン値などです。入力時点でフィールドを制約することで、タイプミスが、数週間後に権限不足として判明するサイレントなプロビジョニング障害になることを防止します。 ### ステップ3：ソース属性をZoom属性にマッピングする 1. 移動先 **アプリケーション** → **アプリケーション** → **アクティブ** → ～ **Zoom** アプリケーション。 2. クリックする **プロビジョニング** タブ。 3. 下 **Zoom 属性マッピング**で、ステップ1で宣言した属性を見つけ、その右側にある編集アイコンをクリックします。\ **注記**：属性が表示されない場合は、次をクリックします **未マッピングの属性を表示**. 4. クリックする **属性値** ドロップダウンを開き、選択 **Oktaプロファイルからマッピング**. 5. 次を表示するソースドロップダウンをクリックし、 `login | string` （デフォルト）から、ステップ2で作成したOktaユーザープロファイル属性を選択します。 6. 選択 **作成および更新**.\ **注記**: **作成のみ** は、Zoomユーザーが最初にプロビジョニングされたときに値を適用し、その後は適用しません。初回割り当て後に上書きすべきでない値については慎重にこれを選択し、 **作成および更新** それ以外の場合はすべてこれを選択し、ディレクトリの変更が反映されるようにします。 7. クリック **保存**. 8. 各属性について繰り返します。 {% hint style="warning" %} **注意：値の導出または変換** Okta値とZoom値が同じ文字列ではない場合、 **属性値** フィールドでは、条件付きロジックおよび文字列関数をサポートするOkta Expression Languageも使用できます。式の構文と利用可能な関数はOktaのリリースによって異なります。次を使用して単一のテストユーザーに対して式を検証してください **プレビュー** より広く適用する前に、サポートされている関数についてはOktaの最新のExpression Languageドキュメントを参照してください。 変換が単純で値セットが小さい場合は、Zoom値をOkta属性に列挙リストとして直接定義するか、ステップ5のようにグループレベル属性を使用するほうが、通常は式を使用するよりも保守しやすくなります。 {% endhint %} ### ステップ4：アプリケーションへのプロビジョニングを有効にする 属性マッピングは、対応するプロビジョニング操作が有効になるまで効果を発揮しません。ステップ5で値を割り当てる前に有効にしてください。 1. 移動先 **アプリケーション** → **アプリケーション** → **アクティブ** → ～ **Zoom** アプリケーション。 2. クリックする **プロビジョニング** タブ。 3. 下 **アプリへのプロビジョニング**、クリック **編集**. 4. 以下で説明する設定を有効にしてから、次をクリックします **保存**. | 設定 | 効果 | | ------------- | --------------------------------------------------------------------------------------------------------- | | **ユーザーを作成** | Oktaでユーザーにアプリケーションが割り当てられると、Zoomでユーザーを作成またはリンクします。 | | **ユーザー属性を更新** | アプリケーションが割り当てられると、Zoom内のユーザー属性を更新します。以降のOktaユーザープロファイルへの変更により、Zoom内の対応する値が自動的に上書きされます。 | | **ユーザーを無効化** | Oktaでアプリケーションの割り当てが解除されたとき、またはOktaアカウントが無効化されたときに、Zoomアカウントを無効化します。アプリケーションを再度割り当てることで、アカウントを再アクティブ化できます。 | {% hint style="danger" %} **警告** **ユーザー属性を更新** カスタム属性マッピングを既存のユーザーに反映させるために必要なものです。これがないと、マッピングはユーザー作成時にのみ適用され、その後のOktaでの変更はZoomに反映されません。 {% endhint %} ### ステップ 5: ユーザーまたはグループに値を割り当てる **個々のユーザーに値を割り当てるには:** 1. 移動先 **ディレクトリ** → **ユーザー** そして、ユーザーの名前をクリックします。 2. クリックする **プロフィール** タブ、次にクリック **編集**. 3. ステップ 2 で作成した属性に、Zoomが想定する値を入力します。 4. クリック **保存**. 値はすぐに送信されます。同じ変更を広く適用する前に、Zoomウェブポータルで結果を確認してください。 **グループに値を割り当てるには** — 設定が組織構造に従う、よりスケーラブルなパターン： 1. Step 1 で属性が宣言されていることを確認します **属性タイプ: グループ**。 もしそれが **個人用**として宣言されていた場合は、対象のグループ プロファイルに対して Step 1 を繰り返し、グループレベルの同等項目を定義します **Zoom ユーザー** のプロファイル配下 **ディレクトリ** → **プロフィールエディタ** → **ユーザー** → **すべて**、 **グループ** を属性タイプとして選択します。 2. 移動先 **ディレクトリ** → **グループ** → ～ **すべて** タブ、次にクリック **グループを追加**. 3. 入力 **名前** およびオプション **説明**、次にクリック **保存**. 4. グループを開いて、次をクリック **アプリケーション** タブ。 5. クリック **アプリケーションを割り当てる**、次にクリック **割り当てる** の右側に **Zoom** アプリケーション。 6. グループ レベルの属性に、すべてのメンバーに適用する値を入力してください。 7. クリック **保存して戻る**、次にクリック **完了**. 8. グループの **ユーザー** タブ、次にクリック **人を割り当てる**. 9. 名、主要メールアドレス、またはユーザー名でユーザーを検索し、各項目の横にある追加ボタンをクリックします。 10. クリック **完了**. メンバーはグループの属性値を自動的に継承します。後から追加されたユーザーは参加時にそれらを継承するため、このパターンは一度きりの移行作業ではなく、継続的なオンボーディングに適しています。 #### グループ優先度は、ユーザーが複数のグループに属している場合の競合する値を解決します ユーザーが同じ属性に値を提供する複数のグループのメンバーである場合、Okta は最も優先度の高いグループの値を送信します。 1. 移動先 **アプリケーション** → **アプリケーション** → **アクティブ** → ～ **Zoom** アプリケーション。 2. クリックする **割り当て** タブ。 3. 下 **フィルター**、クリック **グループ**. 4. グループを意図した順序にドラッグ＆ドロップします。 {% hint style="info" %} **推奨** グループは、最も限定的なものから最も一般的なものへ順序付けます。そうすると、特定のサイトやロールなどの狭い範囲のグループが、広範な包括グループより優先されます。この順序を逆にすると、一般的なグループがすべての個別グループを上書きし、通常は全体に同じ意図しない設定が適用される形で現れます。 {% endhint %} ### ステップ 6: Okta System Log を使用して確認します 1. 移動先 **レポート** → **システムログ**. 2. 対象ユーザーまたはZoomアプリケーションでフィルターし、時間範囲をプロビジョニング試行に絞り込みます。 3. 該当するイベントを開き、結果と下流のアプリケーションから返されたエラーを含む詳細を確認してください。 未解決のプロビジョニングの失敗も、Zoomアプリケーションの **プロビジョニング** タブ。Oktaログが判定できない場合は、次の「Zoom App Marketplace」通話ログに記載されている内容に進んでください。 **Zoom側の認証とよくあるエラー**、これは生のリクエストとレスポンスのやり取りを表示します。 {% hint style="warning" %} **注意: Okta固有のサイレント失敗** Zoom ユーザープロファイルで宣言された属性だが、マッピングされていない、またはマッピングなしで **ユーザー属性を更新** ステップ4で有効にされている場合、マッピング一覧に表示されたまま何も送信しません。エラーは発生しません。値が Zoom に届かず、System Log に対応するイベントがまったく表示されない場合は、さらに調査する前にマッピングとプロビジョニング設定を確認してください。 {% endhint %} #### Okta におけるオンボーディングとオフボーディングの動作 * Scope は主要な安全制御です。Okta で Zoom アプリケーションが割り当てられていないユーザーは、この構成内のどのマッピングによっても変更されることはありません。 * 〜の場合 **ユーザーを無効化** 有効にすると、アプリケーションの割り当てを解除するか、Oktaアカウントを無効化すると、Zoomアカウントが自動的に無効化されます。 * アプリケーションを再割り当てすると、以前に無効化されたZoomアカウントが再度有効になり、グループメンバーシップが退職者や復職者を管理する有効な仕組みになります。 ### ステップ7: Oktaで参照シナリオを適用する シナリオ、前提条件、属性定義は [**参照シナリオ**](#reference-scenarios) セクション。ここではOktaの設定のみを示します。 **シナリオ 0 — 部署。** ステップ1では、属性を **表示名** と **変数名** `部署`, **外部名** `部署`、および **外部名前空間** `urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー`。使用します **属性タイプ: 個人**。Oktaのベースユーザープロファイルにはすでに `部署` 属性が含まれているため、ステップ2は省略できます—ステップ3でそれから直接マッピングし、 **作成および更新**. {% hint style="warning" %} **注意: エンタープライズ拡張属性の名前空間形式** ステップ1のWARNINGでは、属性名をExternal名前空間に追加するというZoomの慣例について説明しています。このガイダンスは、Zoom拡張配下の属性について文書化されています。 `部署` 標準SCIMエンタープライズ拡張に属しており、Oktaの通常の動作では、上に示したように、名前空間と外部名を別々のフィールドに保持します。値がZoomに届かない場合は、末尾に追加した形式 — を試してください。 `urn:ietf:params:scim:schemas:extension:エンタープライズ:2.0:ユーザー:部署` — そして、どの形式がMarketplaceのコールログで成功したかを確認してください。 {% endhint %} **代替案（もし） `部署` はすでにマッピングされています。** 以下のいずれも同じように動作し、同じ親の下にあり、前提条件はありません — 両方の **外部名** および名前空間で属性名を置き換え、Oktaプロファイルにまだ対応するソース属性がない場合は、ステップ2で一致するソース属性を追加します: | 属性 | メモ | | --------- | ------------------------------------------------------------------------------------------ | | `コストセンター` | ビジネスフィールド。ユーザーごとに異なるため、誤った値が目立ちます | | `組織` | 多くの場合、すべてのユーザーで同一のため、誤りに気づきにくくなります | | `社員番号` | すでにIDフィールドとしてマッピングされていることが多いので、宣言する前に確認してください | | `代名詞` | 〜配下にあります **Zoom** エンタープライズのものではなく拡張に属するため、このガイドの他のすべてのシナリオと同じ名前空間を使用し、上記の形式に関する問題を完全に回避します | **シナリオ 1 — Zoom Phone サイトと自動内線番号。** 宣言する `zoomPhoneSite` と **属性タイプ: グループ** そして各サイトのOktaグループにその値を設定します。これによりグループメンバーシップがサイトを直接決定し、変換ロジックは不要です。宣言する `zoomPhoneExtNumber` を、デフォルト値が `0` 既存の拡張設定を移行している場合を除きます。 **シナリオ 2 — 国ごとに異なる通話プラン。** 宣言する `zoomPhoneCallingPlan` と **属性タイプ: グループ** また、通話プランの地域ごとにグループを1つ作成し、各グループのZoomアプリケーション割り当てにプラン値を設定します。ユーザーはメンバーシップを通じて正しいプランを継承し、Oktaに保存される値はZoomが期待する正確な値になります。これにより、構成は次の場所からも可視化および監査可能になります **割り当て** タブ、または基盤となるディレクトリデータの入力方法に不整合があっても影響を受けません。〜を保持するグループは `-1` ユーザーを削除せずに通話権限を解除するための簡潔な方法を提供します。 **シナリオ 3 — コンタクトセンター パッケージ、ロール、地域。** 宣言する `zoomContactCenterPackage` 3つの許可された値に制約された列挙属性として宣言し、無効なパッケージが入力されることを防ぎます。宣言する `zoomContactCenterRole` グループレベルの属性として宣言します。ロールは一般にチーム構造に従うためです。退出 `zoomContactCenterRegion` 単一リージョンのデプロイでは未マッピングのままにします。 ## トラブルシューティング ### エラー #### ユーザーが存在しないか、このアカウントに属していません このエラーは、対象ユーザーのメールアドレスのプロビジョニングが、既存のアカウントがすでに存在するために失敗した場合に発生します。Zoom 管理者は、ユーザーに直接連絡し、ユーザーをアカウントに手動で招待することが推奨されます。

プロビジョニング エラーの例。

#### 有料ユーザーを追加できません このエラーは、アカウント内のライセンスが不足している場合に SCIM がユーザーのプロビジョニングを試みると発生します。エラーを解決するには、ユーザーをベーシックユーザーとしてプロビジョニングするか、ライセンスをプロビジョニング用にオンラインにする必要があります。

プロビジョニング エラーの例。

### SCIM ログを使用してユーザープロビジョニングをトラブルシューティングする Zoom は最新の 100 件の API リクエストログを [Zoom Marketplace](https://marketplace.zoom.us/)。Zoom 管理者は、これらのログを使用して、プロビジョニング API を通じて送受信されている情報を確認できます。ログにアクセスするには、Zoom 管理者として Zoom Marketplace にサインインし、 **管理**。次のページで、選択 **通話ログ** の **個人用アプリ管理**。そこから、エントリをクリックして API ログを展開し、内容を確認します。 次の画像は、参照用にユーザーの ID とライセンス属性を強調表示した SCIM ユーザープロビジョニングリクエストの例を示しています。

SCIM ユーザープロビジョニングリクエストの例。

レスポンスマッピングと同様に、Zoom はプロビジョニングリクエストで ID プロバイダーから送信された情報のみを適用できます。これらのログを使用して、ユーザー ID とライセンス属性が ID プロバイダーから送信されていることを確認してください。期待される情報がこれらのアサーションに含まれていない場合は、サポートについて ID プロバイダーに連絡してください。 --- # 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/account-and-endpoint-management/scim-guide.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.