※本記事にはアフィリエイト広告（PR）を含みます。
Zoomのアカウントを、入社のたびにOktaとは別に手作業で作成していないだろうか。氏名や部署を入力し、ライセンス種別を選び、退職時には「Zoomも止めたっけ」と後から思い出す運用は、対象人数が増えるほど破綻しやすい。作成漏れは初日に会議へ入れない程度で済むが、無効化漏れは退職者のアカウントとライセンスが残り続けるという、監査で指摘されやすいリスクになる。OktaとZoomをSCIMで連携すると、この作成・更新・無効化の一連の流れをOkta側の操作だけで完結できる。本稿では情シス目線で、連携の流れと属性マッピング・ライセンス割り当ての注意点、退職者対応での無効化の考え方を整理する。
SCIMプロビジョニングとは
SCIM(System for Cross-domain Identity Management)は、IdP(Identity Provider。ここではOkta)とアプリ側(Zoomなどのサービス提供側)の間で、ユーザーやグループの情報をREST API経由でやり取りする標準仕様だ。Oktaでは連携先アプリごとにProvisioning(プロビジョニング)タブがあり、アプリ側の既存アカウントをOktaに取り込む「Import」と、Oktaのプロファイルをアプリ側に反映させる「To App」のプッシュ設定に分かれる。ZoomのSCIM連携で中心になるのは後者で、Create Users(作成)、Update User Attributes(更新)、Deactivate Users(無効化)の3アクションを個別にオン/オフする。
押さえておきたいのは、この「無効化」の多くがアカウントを物理削除するのではなく、ユーザーリソースのactive属性をfalseにするソフトデリートとして扱われる点だ。SSO(SAML/OIDC)が「本人であることの認証」を担うのに対し、SCIMは「アプリにアカウントが存在するか、有効か」というライフサイクル管理を担う。両者は独立した機能で、SSOだけ導入しアカウント管理は手作業のまま、という運用も成立するが、情シスの工数削減効果はSSOとSCIMプロビジョニングをセットで導入して初めて大きくなる。
OktaとZoomを連携する流れ
OktaにはOkta Integration Network(OIN)という、主要SaaSとの連携をテンプレート化したアプリカタログがあり、Zoomも登録されている。ゼロからカスタムSAMLアプリを作る必要はなく、カタログからZoomを選ぶのが基本の流れだ。
Okta管理コンソールのApplicationsからBrowse App Catalogを開き、「Zoom」を検索してAddする。General SettingsではZoomのバニティURL(例:example.zoom.us)のカスタム部分(例:example)をSubdomainとして入力する。SSOを併用する場合は、Sign OnタブでSAML 2.0またはOpenID Connect(OIDC)を選び、OktaのIdP情報(サインインURL・証明書・Issuerなど)をZoom側の「Advanced」>「Single Sign-On」設定画面に転記して信頼関係を確立する。SSOの有効化とプロビジョニングの有効化は独立した設定であり、SSOだけ先に導入してアカウント管理は引き続き手作業、という状態も成立する点は覚えておきたい。
プロビジョニングはProvisioningタブから有効化する。Configure API Integrationを開いてEnable API Integrationにチェックを入れ、Authenticate with Zoomをクリックすると、Zoom管理者またはオーナー権限のアカウント(例:[email protected])でのサインインを求められ、OktaとZoomの間にプロビジョニング用の連携が成立する。認証成功を確認して保存したら、To Appの設定でCreate Users・Update User Attributes・Deactivate Usersを個別に有効化し、Assignmentsタブで対象ユーザーやグループを割り当てれば、Zoom側にアカウントが自動生成される。手順や画面名は両社の管理コンソールの改版で変わることがあるため、実施前に最新のヘルプドキュメントで確認してほしい。
属性マッピングとライセンス割り当て
疎通が確認できたら、Provisioning > To App > Attribute Mappingsで、Oktaのどの属性をZoom側のどの項目に流すかを確認・調整する。氏名やメールアドレスなどの基本属性に加え、部署などのカスタム属性もマッピング対象にできる。実務上まず押さえたいのがメールアドレスの扱いで、Okta公式のZoom向けドキュメントでは、Okta側でメールアドレスを変更してもZoomへは自動反映されず、Zoom側で別途変更する必要があると明記されている。メールをキーにアカウントを突き合わせる構成では、この非対称性を運用手順に織り込んでおきたい。
ライセンス(ユーザータイプ)の割り当ても、既定の挙動を確認すべきポイントだ。Okta公式のサポート記事によれば、Zoom側の仕様変更により、Okta経由でプロビジョニングされたユーザーは既定で「Zoom Meetings Basic」として作成される(Unassignedにはならない)。Zoom UnitedやZoom Workplaceの上位プラン(通話プラン付きのBusiness Plusなど)を自動割り当てしたい場合や、逆にUnassignedにしたい場合は、プロファイルエディタでZoom固有の拡張属性を追加し、Oktaのグループ単位でプランを紐づける追加設定が必要になる。対象ユーザーはアプリ割り当て(Assignments)で「Licensed」相当になっている必要がある点も確認したい。なお、Zoom Workplace Enterprise・Enterprise+のみの利用なら既定設定のままで問題ないとされる。割り当てに使う属性値はZoomのSCIM API開発者ドキュメントで随時更新されるため、設定のたびに最新情報を参照するのが確実だ。
無効化(退職者のdeprovisioning)の考え方と注意
退職者対応でSCIM連携が最も効くのがこの場面だ。Okta公式のZoom向けドキュメントによると、OktaでユーザーをDeactivate(無効化)する、またはZoomアプリの割り当てを外す(unassign)と、いずれもZoom側のアカウントが自動的に無効化され、ユーザー管理画面では種別が「Basic (Deactivated)」のように表示される。退職日に合わせてOkta側で無効化すれば、Zoomのアカウントも連動して止まる設計だ。
実務上重要なのは、OktaにはDeactivateのほかにSuspend(一時停止)という状態もあり、育児休業や長期休職のように「戻ってくる」ケースで使うのは理にかなっているが、Okta自身のサポート情報やデベロッパーコミュニティの説明では、Suspendしただけでは連携先アプリへ無効化のリクエストは送られないとされる。Zoomアカウントまで確実に止めたいなら、Suspendではなく明示的にDeactivateする(またはアプリ割り当てを外す)必要がある。退職者対応はDeactivate、休職者対応はSuspendという運用ルールを明文化しておきたい。
また無効化は「サインインできなくする」仕組みであって、Zoom側に残るクラウド録画やチャット履歴の引き継ぎ、ライセンス費用の精算までは自動化してくれない。これらはSCIM連携とは別のタスクとして、退職手続きのチェックリストに残しておく必要がある。
つまずきやすいポイント
いきなり全社展開しない
最初からAssignmentsで「全社員」に割り当てると、属性マッピングやライセンス種別のミスが全ユーザーに波及する。まずは情シス内の小さなテストグループだけに割り当て、作成・更新・無効化の動作をひと通り確認してから段階的に対象を広げたい。
バニティURLと関連ドメインの承認状況
Zoom公式ドキュメントでは、SSOとプロビジョニングの利用には承認済みのバニティURLが前提とされ、「Associated Domain(関連ドメイン)」が未承認の場合、新規プロビジョニングされたユーザーに確認メールが送られ、本人の承諾操作が必要になるとされている。ドメイン承認の有無でオンボーディング時の体験が変わるため、事前に自社の状態を確認しておきたい。
メールアドレスは要注意属性
前述のとおり、Okta側のメールアドレス変更はZoomへ自動反映されない。姓変更やドメイン移行の際は、Zoom側の更新を手作業のタスクとして残しておかないと、SSOのログインとアカウントの紐づけがずれる原因になる。
画面名・手順は変わる前提で確認する
Okta、Zoomともに管理コンソールは継続的に改修されており、本稿で紹介した項目名やボタン位置も将来変わりうる。OktaはClassic EngineとIdentity Engineでメニュー構成が異なることもあるため、設定作業の直前に両社の最新ヘルプドキュメントを確認する習慣をつけておきたい。
プロビジョニング連携の検証には、使い捨てできるサーバー環境があると試行錯誤がしやすくなります。
まとめ
OktaとZoomのSCIM連携は、SSOのようにログイン方法を変えるものではなく、アカウントの作成・更新・無効化というライフサイクル管理を自動化する仕組みだ。OINのZoomアプリを追加し、SSOとは別にProvisioningタブでCreate・Update・Deactivateを有効化し、属性マッピングとライセンス割り当ての既定動作を確認する、という流れ自体はさほど複雑ではない。実務で差が出るのは、メールアドレスのように自動反映されない属性を把握しているか、SuspendとDeactivateを使い分ける運用ルールを持っているか、退職時にデータやライセンスの後始末までチェックリスト化できているか、といった細部だ。まずは小さな対象範囲で試し、動作を確認しながら適用範囲を広げていくことをおすすめする。
最終更新：2026年7月
