SaaSの利用が広がるにつれ、入社・異動・退職のたびに各サービスのアカウントを手作業で作成・削除する負担が、情報システム部門に重くのしかかっています。サービスごとに管理画面を開いてアカウントを登録し、退職時には漏れなく止める——この繰り返しは時間がかかるうえ、消し忘れや権限の付け間違いといったミスも起こりがちです。
こうした手作業を自動化する仕組みが「自動プロビジョニング」です。人事データやID基盤の変更を起点に、各SaaSのアカウントを自動で作成・更新・停止することで、作業負荷とセキュリティリスクの両方を抑えられます。
本記事では、自動プロビジョニングとは何かという定義から、仕組み、中核となるSCIMという規格、SAMLとの役割の違い、そして自社で始めるための3つの経路までを整理します。
SCIMに対応していないSaaSをどう扱うかという現実的な論点にも触れ、読み終えたときに「自社では何から着手すればよいか」の方針が立つことを目指します。
目次
一括ダウンロードする
自動プロビジョニングとは
自動プロビジョニングとは、入社・異動・退職といった人事イベントに合わせて、SaaSや社内システムのアカウントを自動で作成・更新・削除する仕組みを指します。従来は管理者が一つひとつ手で行っていた作業を、ソフトウェアに任せられるようにするものです。
Microsoftは、Entra IDのドキュメントで自動プロビジョニングを次のように説明しています。
Microsoft Entraアプリケーション プロビジョニングとは、ユーザーがアクセスする必要があるアプリケーションでユーザー ID とロールを自動的に作成することを指します。 自動プロビジョニングには、ユーザー ID の作成に加えて、状態または役割が変化したときのユーザー ID のメンテナンスおよび削除が含まれます。
出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn
ここで押さえておきたいのは、自動プロビジョニングが「アカウントを作る」だけの仕組みではない点です。入社時の作成から、異動時の権限変更、退職時の停止まで、アカウントの一生（ライフサイクル）全体を対象にします。このうち退職にあわせてアクセスを取り消す処理は、とくに「プロビジョニング解除（デプロビジョニング）」と呼ばれます。具体的な流れは次章で解説します。
出典・参考資料（1件）
- 出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn（リンク）
手作業によるアカウント管理との違い
手作業のアカウント管理では、管理者が各サービスの管理画面にユーザーを直接追加したり、アカウント情報をまとめた表計算ファイルをアップロードしたりして対応します。Microsoftも、自動の連携コネクタを持たないアプリについては、この手動の方法で作成する必要があると説明しています。
Oktaは、手作業の負担とリスクについて次のように指摘しています。
個々のユーザープロファイル、アカウント特権、グループメンバーシップを手動で更新するのは、特に従業員がアクセスする必要がある業務アプリケーションがこれまで以上に増えている状況においては、時間のかかる作業です。
出典：プロビジョニングとは？ 自動プロビジョニングとプロビジョニング解除について｜Okta
利用するSaaSが数種類のうちは手作業でも回りますが、数十種類に増えると管理画面を往復する時間は無視できなくなります。さらに、退職者のアカウントを止め忘れる、本来与えるべきでない権限を付けてしまうといったミスは、情報漏えいにつながるリスクをはらみます。自動プロビジョニングは、この「数が増えるほど膨らむ手間とミス」を仕組みで抑える点が、手作業との最大の違いです。
出典・参考資料（2件）
自動プロビジョニングの仕組み
ここからは、自動プロビジョニングがどのように動くのかを流れで見ていきます。
自動プロビジョニングの出発点は、人事システムやID基盤（ディレクトリ）に登録された従業員情報です。この情報を「正しい状態の源」（＝アカウント情報の大元となる、信頼できるデータ）として扱い、そこで起きた変更を各SaaSへ伝えることで、アカウントの状態を最新に保ちます。Oktaは、この起点について次のように述べています。
したがって、ユーザーのプロビジョニングは、組織の人事システムで情報が追加または修正されるたびに行われます。これには、チームメンバーの追加、ロールの変更、プロモーション、部門間の異動などが含まれます。
出典：プロビジョニングとは？ 自動プロビジョニングとプロビジョニング解除について｜Okta
この起点をもとに、アカウントは次のようなライフサイクルで扱われます。
- 入社（作成）: 人事システムに従業員が登録されると、必要なSaaSにアカウントが自動で作られ、部署や役割に応じた権限が付与されます。
- 異動・昇進（更新）: 役割や所属の変更に合わせて、アクセスできる範囲や権限が自動で更新されます。
- 退職（削除・無効化）: 従業員が組織を離れると、各SaaSのアカウントが自動で停止され、離職後のアクセスを防ぎます。
人事システムやディレクトリと各SaaSをつなぐ際には、どの項目をどこに渡すかを決める「属性マッピング」を設定します。氏名やメールアドレス、部署、役職といった情報を、連携先のどの欄に対応させるかをあらかじめ定義しておくことで、情報が正しく同期されます。この項目をSaaS間で標準化し、連携をかんたんにするための規格が、次に説明するSCIMです。
出典・参考資料（2件）
SCIMとは
ここでは、自動プロビジョニングを支える中心的な規格であるSCIM（スキム）について解説します。
SCIM（System for Cross-domain Identity Management）とは、クラウドサービス間でユーザー情報をやり取りするための標準規格です。
アプリケーションごとにアカウントを操作する方法（利用する窓口やデータの持ち方）が異なると、多数のSaaSにまたがるユーザー管理は複雑になります。Microsoftは、この課題に対してSCIMが共通の仕組みを提供すると説明しています。
これらの課題に対処するため、クロスドメイン ID 管理システム (SCIM) 仕様では、アプリへの、アプリからの、およびアプリ内での移動に対し、共通のユーザー スキーマが提供されています。
出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn
技術的には、SCIMはHTTPをベースにした標準プロトコルで、ユーザーやグループの情報をJSONという形式で表してやり取りします（規格の仕様はIETFのRFC 7643・RFC 7644で定義されています）。ID基盤側がSCIMで提供される窓口（エンドポイント）に対してアカウント情報を送ることで、作成・更新・削除が連携先のSaaSに反映される、という流れです。
やり取りの窓口は、利用者を扱う /Users とグループを扱う /Groups が基本です。アカウントの作成はPOST、属性の変更や有効・無効の切り替えはPATCH、削除はDELETEというHTTPの操作で指示します。これらの操作は、連携時に発行されるアクセストークン（多くはOAuth 2.0のベアラートークン）で認証されます。
SCIMに対応したSaaSであれば、ID基盤側で一度連携を設定するだけで、個別にアカウントを手で作らずに済みます。Google WorkspaceやSlack、Salesforce、Zoomなど主要なSaaSの多くがSCIMに対応しており、自動プロビジョニングを実現するうえでの共通言語になっています。
自社で使っているSaaSが対応しているかは、利用中のID基盤（IdP）の連携カタログや、各SaaSの公式ドキュメントで確認できます。
出典・参考資料（3件）
SCIMとSAMLの違い
すでにSSO（シングルサインオン）を導入している場合、「SAML（Security Assertions Markup Language）で認証を一本化したのに、なぜ別に自動プロビジョニングが必要なのか」という疑問が浮かびます。ここでは、SCIMとSAMLの役割の違いを整理します。
結論から言うと、SCIMとSAMLは担う役割が異なり、競合するものではありません。SAMLはログイン時の「認証」を担い、SCIMはアカウントの作成・更新・削除という「同期（プロビジョニング）」を担います。Microsoftも、SSOのための標準とプロビジョニングは別の役割だと明記しています。
シングル サインオン (SSO) のために SAML や OIDC などの標準を使用しますが、アクセスのためにはユーザーをアプリにプロビジョニングする必要もあります。
出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn
以下は、SCIMとSAMLの役割を整理した比較表です。
| 項目 | SCIM | SAML |
|---|---|---|
| 主な役割 | アカウントの作成・更新・削除の同期（プロビジョニング） | ログイン時の本人確認（認証・シングルサインオン） |
| いつ働くか | 入社・異動・退職などアカウント情報が変わったとき | ユーザーがサービスにログインするとき |
| 解決する課題 | 各SaaSのアカウントを手作業で作成・削除する負担とミス | サービスごとにID・パスワードを使い分ける手間 |
SCIMとSAMLは競合するものではなく、SAMLで認証を一本化し、SCIMでアカウントの発行・停止を自動化する、という形で組み合わせて使います。
Microsoftは、SCIMを他の認証標準と併用する位置づけについても説明しています。
SCIM は、プロビジョニングに対する事実上の標準になりつつあり、SAML (Security Assertions Markup Language) や OpenID Connect (OIDC) などのフェデレーション標準と一緒に使用すると、エンドツーエンドの標準ベースのアクセス管理用ソリューションが管理者に提供されます。
出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn
なお、引用に出てくるOpenID Connect（OIDC）も、SAMLと同じくログイン認証（SSO）のための標準の一つです。SSOを入れても、その対象サービスにアカウントが存在しなければログインはできません。アカウントそのものを自動で用意・停止するのが自動プロビジョニング（SCIM）の役割であり、SSO（SAMLやOIDC）とは補い合う関係にあると理解すると分かりやすくなります。
出典・参考資料（1件）
- 出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn（リンク）
一括ダウンロードする
自動プロビジョニングの進め方（3つの経路）
ここからは、自社で自動プロビジョニングを始めるための具体的な経路を3つに分けて解説します。全体像としては、「人事システム」に入った入退社の情報が「ID基盤（IdP）」を経由して「各SaaS」へ同期される、という一本の流れが基本です。
3つの経路は、この流れのどこを起点・集約点にするか（①人事システムを起点にする／②ID基盤を集約点にしてSCIMで同期する）と、流れに乗らないSaaSをどう補うか（③未対応SaaSを棚卸しする）の違いです。どれか一つだけを選ぶというより、①と②で自動化の軸をつくり、③で漏れを補うように組み合わせるのが現実的です。
① 人事システム（HR SaaS）と連携する
1つ目は、人事システムを起点にする方法です。入社・異動・退職の情報が最初に登録されるのは人事システムなので、ここを「正しい状態の源」として各SaaSへ変更を伝えます。Microsoftも、人事システムやディレクトリの変更にもとづいてIDを最新に保つ仕組みを提供すると説明しています。
人事担当者が人事システムに入退社を入力すれば、その情報を起点にアカウントが自動で作成・停止されるため、情報システム部門が人事の動きを別途受け取って手作業する必要がなくなります。
クラウド型の人事システム（HR SaaS）の多くは、ID基盤（IdP）と連携して従業員情報を渡す仕組みを備えており、実際には①で人事システムから流した情報を、次の②のID基盤が各SaaSへ同期する、という形で組み合わせて使うのが一般的です。人事情報を大元のデータとして運用を回したい企業に向いた起点になります。
出典・参考資料（1件）
- 出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn（リンク）
② ID基盤（IdP）のSCIM連携を使う
2つ目は、ID基盤（IdP）とSaaSをSCIMで連携させる方法です。IdPにアカウント情報を集約し、そこからSCIMで各SaaSへ同期します。SCIMに対応したSaaSであれば、IdP側で連携を一度設定するだけで、アカウントの作成・停止が自動化できます。
設定の流れは、IdP側でSCIM連携を有効にし、発行されるエンドポイントとアクセストークンを連携先に渡す、というのが基本です。AWSは、IAM Identity CenterでのSCIM有効化手順を次のように案内しています。
[設定] ページで、[自動プロビジョニング] 情報ボックスを探し、[有効化] を選択します。これにより、すぐに IAM アイデンティティセンターの自動プロビジョニングが有効になり、必要なエンドポイントとアクセストークンの情報が表示されます。
出典：自動プロビジョニングを有効にする｜AWS IAM Identity Center ユーザーガイド
このように、SCIM連携では「エンドポイント」と「アクセストークン」を取得し、連携相手に設定するのが共通の作業になります。すでにIdPを導入している、あるいはこれから導入する企業に向いた経路です。
出典・参考資料（1件）
- 出典：自動プロビジョニングを有効にする｜AWS IAM Identity Center ユーザーガイド（リンク）
③ SCIM未対応のSaaSはSaaS管理ツールで棚卸し・補完する
3つ目は、SCIMに対応していないSaaSへの対処です。①②で自動化できるのはSCIMや連携コネクタを備えたSaaSに限られ、それを持たないアプリは手で作成・削除する必要があります。Microsoftも、自動の連携コネクタがないアプリは手動で作成する必要があると説明しています。
現実の企業では、SCIMに対応したSaaSと対応していないSaaSが混在します。そこで役立つのが、社内で使われているSaaSを一覧化し、アカウントの持ち主や利用状況を可視化するSaaS管理ツールです。対応・未対応を切り分けたうえで、未対応分についてはツール上からアカウントの発行・停止をまとめて行ったり、退職者の残アカウントを検知したりすることで、手作業の抜け漏れを減らせます。
①②で自動化の網をかけつつ、網から漏れるSaaSを③で棚卸しして補完する——この組み合わせが、SCIM対応状況がばらばらな現実に即した進め方になります。
出典・参考資料（1件）
- 出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn（リンク）
自動プロビジョニングを導入するメリット
ここでは、自動プロビジョニングを導入することで得られる効果を整理します。Microsoftは、自動プロビジョニングを使う一般的な動機として、効率と正確さの向上、退職時のセキュリティ強化、ポリシーの一元管理を挙げています。
- 作業負荷の削減: アカウントの作成・更新・削除が自動化され、情報システム部門が各SaaSの管理画面を往復する手間が減ります。
- 退職者アカウントの即時停止によるセキュリティ向上: 退職と同時にアカウントが止まるため、離職後も残り続けるアカウントからの不正アクセスのリスクを抑えられます。
- 人為的ミスの削減: 権限の付け間違いや削除漏れといった、手作業にともなうミスを減らせます。
Oktaは、手作業で残りがちなリスクを次のように挙げています。
たとえば、ユーザーがアクセスすべきではないシステムやデータに誤ってプロビジョニングされたり、離職後もアクセスできたりする場合にリスクが生じます。
出典：プロビジョニングとは？ 自動プロビジョニングとプロビジョニング解除について｜Okta
作業効率の改善は導入のきっかけになりやすい一方、退職者アカウントの停止漏れ防止や権限管理の正確さといったセキュリティ面の効果は、経営層やセキュリティ担当者にとっても説明しやすいメリットです。
出典・参考資料（2件）
導入・運用時の注意点
自動プロビジョニングは便利な仕組みですが、設定と運用でつまずきやすい点があります。導入前に押さえておきたい注意点を整理します。
属性マッピングの設計を丁寧に行う
ID基盤とSaaSをつなぐ際は、どの情報を連携先のどの欄に渡すかを定める属性マッピングを設定します。この対応づけを誤ると、意図しない項目が同期されたり、必要な情報が渡らなかったりします。Microsoftは、送るべきユーザーデータを定義したカスタマイズ可能な属性マッピングを利用できると説明しており、連携開始前に対応表を丁寧に設計しておくことが重要です。
SCIMのアクセストークンの期限切れに注意する
SCIM連携で使うアクセストークンには有効期限が設定されている場合があります。期限が切れると同期が止まり、アカウントの作成・削除が反映されなくなるため、期限前にトークンを更新する運用が必要です。有効期限の長さは連携先のSaaSやIdPによって異なるため、各サービスのドキュメントで確認し、更新時期を管理しておきましょう。
まずは対象を絞って段階的に導入する
すべてのSaaSを一度に自動化しようとすると、属性マッピングの設定や動作確認の負荷が一度に集中し、トラブルが起きたときの切り分けも難しくなります。まずは利用者が多い主要なSaaSなど対象を絞って連携を始め、同期が正しく動くことを確認してから範囲を広げると、運用トラブルを避けやすくなります。連携を追加するときは、既存の同期に影響が出ていないかもあわせて確認しておくと安心です。
突合キーのずれと、SaaS側での直接編集に注意する
同期では、ID基盤側とSaaS側のアカウントを同一人物と見なす突合キー（多くはメールアドレスやユーザー名）を揃えておく必要があります。これがずれると、同じ人に二重のアカウントが作られたり、更新が別人に当たったりします。
また、連携後にSaaSの管理画面で直接アカウントを編集すると、ID基盤からの同期と食い違い、意図しない上書きや不整合が起きます。編集の起点はID基盤側に統一し、特に退職・異動時の停止漏れ（残アカウント）がないかを定期的に点検しておくことが欠かせません。
出典・参考資料（1件）
- 出典：Microsoft Entra IDでの自動アプリ ユーザー プロビジョニングとは｜Microsoft Learn（リンク）
関連サービスで自動プロビジョニングを実現する
ここからは、自動プロビジョニングを実現するためのサービスを紹介します。アカウントのライフサイクル管理を担うID基盤と、SCIM未対応のSaaSまで含めて棚卸し・管理するSaaS管理ツールは、前述の進め方の受け皿になります。
| サービス名 | CloudGate UNO | マネーフォワード Admina |
|---|---|---|
| 種別・役割 | ID基盤（IDaaS） SSO・多要素認証とアカウント管理を一体で提供 | SaaS管理ツール SaaSの可視化・棚卸しとID/デバイス管理 |
| 自動プロビジョニング | ●全プランに標準搭載。アカウントの作成・更新・削除を自動化 | △SCIM未対応SaaSの棚卸し・補完が主。IDライフサイクル管理でアカウント発行・退職者アカウントの検知/削除 |
| 認証（SSO・多要素認証） | ●SSO（SAML 2.0・OpenID Connect）、多要素認証・パスキーを全プランで提供 | ×提供なし（IdPと連携して利用） |
| 主な連携・対応SaaS | Google Workspace・Microsoft 365・Salesforce 等とSSO連携 Active Directory連携はEnterprise Plus以上 | 連携SaaS 380以上 アカウント発行・削除の双方向対応は200種超 |
| 料金の目安 | 月額400〜600円/ユーザー（税抜） 初期費用は要問い合わせ／30日間の無料体験 | 50ID以下は無料 51ID以上は1IDあたり月額300円 |
| 向いている企業 | SSOとアカウント管理を国産基盤で一本化したい企業 | SCIM未対応を含むSaaSを棚卸しし、退職者アカウントの削除漏れまで防ぎたい企業 |
| 詳細情報 | 公式資料を見る | オンライン相談を予約 |
※2026年11月時点の各社公式情報にもとづく。最新の料金・機能は各社の公式サイトをご確認ください。
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNO（クラウドゲートウノ）は、株式会社インターナショナルシステムリサーチが100%自社開発する国産のID基盤（IDaaS）です。シングルサインオン・多要素認証・パスキー（FIDO2）によるパスワードレス認証・アクセス制限に加え、アカウントの作成・更新・削除を自動化するID管理（プロビジョニング・ライフサイクル管理）を一つの管理画面で提供します。
自動プロビジョニングの観点で特徴的なのは、プロビジョニング機能がすべてのプランに標準で使える点です。公式サイトでは、プロビジョニング機能・アクセス制限・パスキー対応の多要素認証などが、すべてのプランに標準搭載されていると案内されています。
SSOはSAML 2.0・OpenID Connectに対応し、認証（SSO）とアカウント管理（プロビジョニング）を同じ基盤でまとめて扱えます。
料金は、Standard Plusが1ユーザーあたり月額400円、Enterprise Plusが500円、Smart Packが600円（いずれも税抜、2026年11月時点）で、30日間の無料体験も用意されています。日本語でのサポートを提供しており、国産の基盤でSSOとアカウント管理を一本化したい企業に向いています。
出典・参考資料（2件）
2. マネーフォワード Admina（マネーフォワードｉ株式会社）
社内で使われているSaaSを従業員単位で可視化・棚卸しするのが、マネーフォワードｉ株式会社が提供するSaaS管理ツール「マネーフォワード Admina」です。入退社時のアカウント発行・停止や、シャドーIT（情報システム部門が把握していないSaaS）の検知などを一元化します。
自動プロビジョニングとの関係では、SCIMで自動化しきれないSaaSまで含めて棚卸しできる点が役立ちます。従業員マスターと連携したIDライフサイクル管理により、Adminaから直接アカウントを発行したり、退職済みアカウントを検知してボタン操作で削除したりできます。
アカウントの発行・削除の双方向に対応するSaaSは200種類を超え（2025年11月時点）、連携できるSaaS数は380以上とされています。
料金は、50ID以下であれば全機能を無料で利用でき、51ID以上は1IDあたり月額300円です。ID基盤での自動化と組み合わせ、未対応SaaSの棚卸しや退職者アカウントの削除漏れ対策まで含めて管理したい企業に向いています。
ID基盤（IDaaS）は、SSOや多要素認証とあわせてアカウント管理を担うサービスです。ほかのIDaaSも含めて機能や料金、選び方を比較検討したい場合は、以下の記事で主要サービスを詳しく整理しています。
まとめ
自動プロビジョニングは、入社・異動・退職に合わせてSaaSのアカウントを自動で作成・更新・停止する仕組みです。人事システムやID基盤を起点に変更を各SaaSへ伝え、その同期を標準化する規格がSCIMでした。SCIMはアカウントの同期、SAMLはログイン認証という役割分担であり、両者は補い合って使います。
自社で始める際は、人事システム連携・IdPのSCIM連携・SaaS管理ツールによる未対応SaaSの補完という3つの経路を、環境に応じて組み合わせるのが現実的です。まずは利用中のSaaSのSCIM対応状況を棚卸しし、自動化できるものから着手するとよいでしょう。アカウント管理の自動化を支えるサービスの資料を比較して、自社に合う進め方を具体化してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. 自動プロビジョニングとは何ですか？
A. 自動プロビジョニングとは、入社・異動・退職といった人事イベントに合わせて、SaaSや社内システムのアカウントを自動で作成・更新・削除する仕組みです。従来は管理者が各サービスの管理画面で一つひとつ手作業していたアカウント管理を、ソフトウェアに任せられるようにするものを指します。
アカウントを作るだけでなく、役割の変化に応じて権限を更新し、退職時には停止（削除・無効化）するという、アカウントの一生（ライフサイクル）全体が対象になります。退職にあわせてアクセスを取り消す処理は、とくに「プロビジョニング解除（デプロビジョニング）」と呼ばれます。
Q. SCIMとは何ですか？読み方は？
A. SCIM（スキム）とは、クラウドサービス間でユーザー情報をやり取りするための標準規格で、自動プロビジョニングを支える中心的な仕組みです。読み方は「スキム」で、System for Cross-domain Identity Management の略です。
技術的にはHTTPをベースにした標準プロトコルで、ユーザーやグループの情報をJSONという形式で表してやり取りします（仕様はIETFのRFC 7643・RFC 7644で定義）。SCIMに対応したSaaSであれば、ID基盤側で一度連携を設定するだけで、個別にアカウントを手で作らずに同期できます。
Q. SSO（SAML）を導入していれば、自動プロビジョニング（SCIM）は不要ですか？
A. SSO（SAML）を導入していても、自動プロビジョニング（SCIM）は別に必要で、両者は競合せず補い合う関係です。SAMLはログイン時の「認証」を担い、SCIMはアカウントの作成・更新・削除という「同期（プロビジョニング）」を担うため、役割が異なります。
SSOを入れても、その対象サービスにアカウントが存在しなければログインはできません。アカウントそのものを自動で用意・停止するのが自動プロビジョニング（SCIM）の役割であり、SSOで認証を一本化し、SCIMでアカウントの発行・停止を自動化する、という組み合わせで使うのが基本です。
Q. 自動プロビジョニングは人事システムとどう連携しますか？
A. 自動プロビジョニングでは、入社・異動・退職の情報が最初に登録される人事システムを「正しい状態の源」として、そこで起きた変更を各SaaSへ伝えることでアカウントの状態を最新に保ちます。
人事担当者が人事システムに入退社を入力すれば、その情報を起点にアカウントが自動で作成・停止されるため、情報システム部門が人事の動きを別途受け取って手作業する必要がなくなります。人事情報を大元のデータとする運用に向いた進め方です。
Q. SCIMに対応していないSaaSはどう管理すればよいですか？
A. SCIMに対応していないSaaSは、社内で使われているSaaSを一覧化して可視化するSaaS管理ツールで棚卸しし、ツール上からアカウントの発行・停止や退職者の残アカウント検知を行って補うのが現実的です。
SCIMや連携コネクタを持たないSaaSは、ID基盤側からの自動化の対象外で、手で作成・削除する必要があります。現実の企業ではSCIM対応・未対応のSaaSが混在するため、対応分はID基盤で自動化し、未対応分はSaaS管理ツールで棚卸しして補完する、という組み合わせが効果的です。
Q. SCIM連携で使うアクセストークンの有効期限が切れるとどうなりますか？
A. SCIM連携のアクセストークンの有効期限が切れると、同期が止まり、アカウントの作成・削除が連携先のSaaSに反映されなくなるため、期限前にトークンを更新する運用が必要です。
有効期限の長さは連携先のSaaSやIdPによって異なり、すべてのサービスに共通する決まった日数があるわけではありません。各サービスの公式ドキュメントで期限を確認し、更新時期を管理しておくことが大切です。
Q. 自動プロビジョニングは社内の誰が担当すべきですか？
A. 自動プロビジョニングは、SaaSやID基盤のアカウントを管理する情報システム部門が主体となり、入退社情報を持つ人事部門と連携して進めるのが一般的です。
アカウントの作成・停止の起点になる入退社・異動の情報は人事部門が握っているため、人事システムと情報システム部門のID管理をつなぐ設計が要になります。情シスを専任で置きにくい企業では、管理部門が兼任するケースもあります。
Q. 自動プロビジョニングは自社ではまず何から始めればよいですか？
A. 自動プロビジョニングは、まず利用中のSaaSのSCIM対応状況を棚卸しし、自動化できるものから着手するのが現実的な始め方です。
人事システム連携・ID基盤（IdP）のSCIM連携・SaaS管理ツールによる未対応SaaSの補完という3つの経路を、環境に応じて組み合わせます。すべてを一度に自動化しようとせず、導入初期は対象を絞り、連携が安定してから範囲を広げると、運用トラブルを避けやすくなります。
ID管理・SaaS管理サービスの料金・資料を一括チェック
MCB FinTechカタログでは、自動プロビジョニングに対応するID基盤やSaaS管理ツールの最新資料を無料で一括請求できます。プロビジョニング機能やSCIM対応、料金を見比べて、自社に合うサービスを検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
