プライバシー設定
このサイトでは、第三者のウェブサイト追跡技術を使用して、当社のサービスを提供および継続的に改善し、ユーザーの興味に応じた広告を表示します。同意します。また、将来的に有効となる限り、いつでも同意を取り消したり、変更したりすることができます。
拒否
[すべて承認]
すべての記事

SCIMとは|SaaSプロビジョニング自動化の仕組み・活用方法をわかりやすく解説

共有
コピー

従業員が入社するたびに、情シス担当者はSlack・Zoom・Salesforce・Notionといった各SaaSの管理画面に個別ログインし、アカウントを一つひとつ手作業で作成する必要があります。退職時には全SaaSのアカウントを漏れなく削除しなければならず、1件の削除漏れがセキュリティインシデントに直結するリスクをはらんでいます。従業員数が500名を超え、利用SaaSが数十種類に及ぶ企業では、この作業は担当者の工数を大きく圧迫する慢性的な課題となっています。

SCIMという規格を使えば、こうした作業を自動化できます。SCIMはユーザーアカウント情報をシステム間で標準的な方法で転送するためのプロトコルであり、IDaaS(Identity as a Service)やSMP(SaaS Management Platform)が「SCIM連携」を謳う際の技術的な根拠になっています。SCIMを活用すると、人事システムで入社情報を登録するだけで、連携している全SaaSにアカウントが自動作成されます。退職処理も同様に、一元操作で全SaaSのアクセスを即時無効化できます。

本記事では、SCIMの定義・仕組み・解決できる課題から、IDaaSとの組み合わせ方、SCIM対応SaaSの確認方法、Josysを活用した実践的な自動化の進め方まで、情シス部門の担当者に向けてわかりやすく解説します。

SCIMとは何か

SCIMは、異なるシステム間でユーザーアカウント情報を自動同期するための標準規格です。ここでは定義・目的・関連規格との違いを整理します。

SCIMの定義と目的

SCIM(System for Cross-domain Identity Management:システム間クロスドメインアイデンティティ管理)は、異なるシステム間でユーザー情報やグループ情報を標準化された形式で転送・同期するためのオープンプロトコルです。IETF(Internet Engineering Task Force)によってRFC 7642(概念・ユースケース)、RFC 7643(コアスキーマ)、RFC 7644(プロトコル)として定義されており、現在の最新バージョンはSCIM 2.0です。

SCIMが生まれた背景には、SaaSの急増があります。2010年代以降、企業が利用するSaaSの種類が急速に増加し、それぞれのSaaSが独自の形式でユーザー情報を管理するようになりました。その結果、人事異動のたびに各SaaSへの個別操作が発生し、管理コストとセキュリティリスクが増大していきました。SCIMはこの問題を解決するために設計された規格であり、ユーザー情報の「共通言語」として機能します。

SAMLとの違い、SSOとの組み合わせ

SCIMを理解する上で、SAML(Security Assertion Markup Language)およびSSO(シングルサインオン)との違いを整理しておくことが重要です。

SAML(Security Assertion Markup Language)は認証・認可に関する情報を交換するための規格です。ユーザーが「誰であるか」を証明するためのトークンを発行し、複数のサービスへのシングルサインオンを実現します。一方SCIMは、ユーザーアカウントの「作成・更新・削除」という情報そのものの同期を担います。SAMLが「ドアを開ける鍵の仕組み」だとすれば、SCIMは「どのドアの鍵を誰に渡すかを管理する仕組み」と理解できます。

SSOとSCIMは補完的な関係にあります。SSOによってユーザーは一度のログインで複数SaaSにアクセスできますが、SSOの手段にはSCIM事前プロビジョニング以外にも、初回ログイン時にアカウントを作成するJIT(Just-in-Time)プロビジョニングや手動作成など複数あります。SCIMを使うとログイン前にアカウント・権限を事前に管理できるため、JITよりも統制・一覧管理がしやすい点が利点です。SCIMでアカウントをプロビジョニング(作成・設定)し、SAMLやOIDCでSSOを実現する、という組み合わせが現在の標準的な構成です。

規格 主な役割 タイミング
SCIM ユーザー情報の同期(作成・更新・削除) アカウント管理時
SAML 認証情報の交換(SSO) ログイン時
OIDC 認証・認可(OAuth 2.0ベースのSSO) ログイン時

SCIM 2.0はREST APIベースのアーキテクチャを採用しており、JSONフォーマットでデータを転送します。これにより、さまざまなSaaSが標準的な方法でSCIMに対応することが容易になっています。

参考: RFC 7644 - System for Cross-domain Identity Management: Protocol

SCIMが解決する課題

SCIMが注目される背景には、SaaS時代特有のアカウント管理の煩雑さがあります。入社・退職・異動のそれぞれのシーンで発生する課題を具体的に見ていきます。

入社時のアカウント作成漏れと初動遅延

従業員が入社する際、情シス担当者はHRシステムから入社情報を受け取り、各SaaSの管理画面でアカウントを個別に作成する必要があります。利用SaaSが20種類あれば20回のログインと設定作業が発生します。この作業には数時間から半日程度かかることも珍しくなく、入社初日に業務を開始できないという初動遅延が生じやすい状況です。また、対応が複数人に分担されている場合、一部のSaaSでアカウント作成が漏れるリスクがあります。

退職時のアカウント削除漏れによるセキュリティリスク

退職時はさらに問題が深刻です。退職者のアカウントを全SaaSから確実に削除・無効化しなければなりませんが、利用SaaSの種類が多い企業では一部のSaaSで削除漏れが発生するケースが報告されています。退職者が元の会社のSaaSアカウントにアクセスできる状態が続くことは、情報漏洩や不正アクセスのリスクに直結します。

総務省の情報セキュリティガイドラインでも、退職者のアクセス権限管理は情報セキュリティ上の重要な管理項目として位置づけられています。手動管理では確実性に限界があり、仕組みとしての自動化が求められます。

異動時のロール・権限変更の複雑さ

部署異動や役職変更の際には、旧部門のアクセス権限を削除し、新部門の権限を付与するという二重の作業が発生します。SaaSごとに権限の概念やロール設定が異なるため、適切な権限設定には各SaaSへの深い理解が必要です。設定ミスや対応遅延により、旧部門の機密情報への継続的なアクセスが発生したり、新業務に必要なツールが使えないという問題が生じます。

SCIMによる解決の全体像

SCIMを導入すると、IDaaSでユーザー情報を変更するだけで、連携している全SaaSに変更が自動反映されます。入社情報の登録から連携SaaSへのアカウント作成まで、人手を介さずに短時間で完結します。退職処理も一元操作で連携SaaSのアクセスを自動無効化でき、削除漏れリスクを大幅に低減できます(実際の反映速度や対象範囲はSaaS・IdPの同期設定に依存します)。

SCIMプロビジョニングの仕組み

SCIMがどのように動作するか、プロビジョニングの概念とフローを詳しく説明します。

プロビジョニングとデプロビジョニング

プロビジョニング(Provisioning)とは、ユーザーがシステムを利用できるようにアカウントを作成・設定することを指します。具体的には、アカウントの新規作成、初期パスワードの設定、アクセス権限の付与、所属グループへの追加などが含まれます。

デプロビジョニング(Deprovisioning)はその逆で、ユーザーのアカウントを無効化・削除し、アクセス権限を剥奪することです。退職者処理の文脈では特に重要な概念です。

JIT(Just-in-Time)プロビジョニングとの違いも押さえておきましょう。JITプロビジョニングはユーザーが初めてサービスにログインした際に自動的にアカウントを作成する仕組みです。SAMLやOIDCベースのSSOと組み合わせて使用されることが多く、「使ったときに作る」という考え方です。一方SCIMは事前にアカウントを作成・管理するため、ログイン前からアカウントの存在と権限設定が保証されています。未使用アカウントの一覧管理やデプロビジョニングの確実性という観点では、SCIMによる事前プロビジョニングのほうが管理の透明性が高い状態を維持できます。

SCIMの動作フロー

SCIMの動作は、IDプロバイダー(IdP)が主体となってSaaSに変更を伝達するプッシュ型の仕組みです。

基本的な動作フローは次のとおりです。

  1. 人事システムまたは管理者がIDaaSでユーザー情報を変更する(入社登録・退職処理・情報更新など)
  2. IDaaSのSCIMエンジンが変更を検知し、SCIM APIを通じて接続されているSaaSにHTTPリクエストを送信する
  3. SaaS側のSCIMエンドポイントがリクエストを受け取り、ユーザーアカウントを自動的に作成・更新・削除する
  4. 処理結果がIDaaSに返送され、同期状態が記録される

この仕組みにより、IDaaS側で一度操作するだけで、SCIM連携しているすべてのSaaSに変更が自動伝播します。

SCIMはREST APIを使用しており、主なHTTPメソッドとその役割は以下のとおりです。

HTTPメソッド SCIM操作 内容
POST Create ユーザー・グループの新規作成
GET Read ユーザー情報の取得・一覧取得
PUT / PATCH Update ユーザー情報の更新・部分更新
DELETE Delete ユーザー・グループの削除

SCIMで同期できる情報

SCIMで同期できるユーザー属性(スキーマ)は、RFC 7643で標準定義されています。主な同期対象は次のとおりです。

氏名(姓・名・表示名)、メールアドレス、ユーザー名、電話番号といった基本的なユーザー情報に加え、部署名、役職、所属組織(会社名)などの組織情報を同期できます。また、アカウントの有効化・無効化状態(activeフラグ)も同期対象であり、退職者処理ではこの属性をfalseに設定することでアカウントを無効化できます。

グループ情報も同期対象です。Active Directoryのグループや組織内のチーム構造をSaaS側に反映させることで、グループ単位でのアクセス権限管理が可能になります。

カスタム属性(Enterprise User Extension)を使えば、標準スキーマに含まれない独自の属性(社員番号、雇用形態、入社日など)も同期対象に追加できます。

SCIM連携の前提:IDaaSが必要な理由

SCIMを活用した自動化を実現するには、SCIMの「送信元」となるシステムが必要です。その役割を担うのが通常はIDaaSです。

IDaaSがSCIMの制御タワーになる

SCIMはプロトコルであり、それ自体がシステムを動かすわけではありません。SCIMを使って各SaaSにユーザー情報を送信するための「制御タワー」が必要であり、その役割を担うのがIDaaS(Identity as a Service)です。

代表的なIDaaSとしてはMicrosoft Entra ID(旧Azure AD)、Okta、Google Workspace(Cloud Identity)などがあります。これらのIDaaSはSCIMプロビジョニング機能を標準搭載しており、管理画面から各SaaSとのSCIM連携設定を行うことができます。

典型的な3層連携の構成は次のとおりです。

  • 第1層:人事システム(SmartHR、HRMOS、カオナビ等)で入社・退職・異動情報を管理
  • 第2層:IDaaS(Okta、Microsoft Entra ID等)でユーザーの一元管理とSCIM送信を担当
  • 第3層:各SaaS(Slack、Zoom、Salesforce等)がSCIM受信側として自動同期を実行

人事システムとIDaaSの連携方法はSCIMとは別のAPIやCSVインポートで行われることが多く、IDaaSがユーザー情報のハブとして機能することで、個々のSaaSとの接続をSCIMで標準化できます。

IDaaSがない場合の対応:SMPの活用

IDaaSを導入していない企業や、IDaaSとは別の経路でSCIM連携を実現したい場合には、SMP(SaaS Management Platform)が有効な選択肢になります。SMPはSaaSの棚卸しや利用状況管理を主機能としますが、上位製品ではSCIMプロビジョニング機能を内包しているものがあります。

SMPとIDaaSの役割分担を整理すると、IDaaSは「認証・認可の一元管理とSCIM送信」を担い、SMPは「SaaS利用状況の可視化・ライセンス管理・プロビジョニングの補完」を担うという関係です。IDaaSとSMPを組み合わせて使用することで、SCIM対応しているSaaSはIDaaS経由で、非対応SaaSはSMPの機能で補完するといった柔軟な自動化が実現できます。

SCIM対応SaaSの確認方法と連携設定

実際にSCIM連携を進めるにあたり、対象SaaSがSCIMに対応しているかどうかを確認し、設定を進める手順を解説します。

主要SaaSのSCIM対応状況

多くの主要SaaSはSCIM 2.0に対応しています。よく利用されるSaaSの対応状況を以下に示します。

SaaS SCIM対応 備考
Slack 対応 Business+プラン以上
Zoom 対応 Business以上のプランで利用可能
Salesforce 対応 Identity Connect等が必要なケースあり
Notion 対応 Enterpriseプランで利用可能
GitHub 対応 Enterprise Cloudで利用可能
Google Workspace 対応 SCIM受信側としての利用も可能
Microsoft 365 対応 Entra ID経由で標準対応
Box 対応 Business以上で利用可能
Dropbox Business 対応 Business以上で利用可能

注意が必要なのは、SCIM対応がプランによって制限されているSaaSが多い点です。導入前に各SaaSの料金プランとSCIM対応要件を確認することが重要です。

SCIM対応の確認方法

対象SaaSがSCIM対応しているかどうかを確認する最も確実な方法は、そのSaaSの管理者向けドキュメントを参照することです。多くのSaaSでは「SCIM provisioning」「User provisioning」「Automatic provisioning」といったキーワードで検索すると、SCIM設定に関するドキュメントを見つけられます。

また、利用しているIDaaS(OktaやMicrosoft Entra ID)のアプリカタログを参照する方法も有効です。IdPのアプリカタログに掲載されているSaaSは、そのIdPとのSCIM連携が検証済みであることが多く、設定手順もガイドとして提供されています。

連携設定のポイントと注意事項

SCIM連携の設定は一般的に次の手順で進めます。

まずSaaS側で管理者権限によりSCIM設定を有効にし、SCIMエンドポイントURL(例:https://api.example.com/scim/v2)とベアラートークン(APIキー)を取得します。次にIdP側でそのSaaSの連携設定画面を開き、取得したエンドポイントURLとトークンを入力してSCIM連携を有効化します。その後、同期するユーザー属性(フィールドマッピング)を設定し、テストユーザーでプロビジョニングが正常に動作するか確認します。

よくあるトラブルとしては、フィールドマッピングのミスによる同期エラーが挙げられます。IdP側の属性名とSaaS側の属性名が一致していない場合、ユーザー情報が正しく反映されません。また、SaaS側の必須フィールドに値が設定されていない場合もエラーが発生します。設定後は必ずテストユーザーで動作確認を行い、本番運用前にエラーのないことを確認することが推奨されます。

JosysのSCIM連携による自動化

Josysは、IDaaSとのSCIM連携を活用したSaaSプロビジョニングの自動化を実現するSaaS管理プラットフォームです。

Access AutomationによるSCIM自動プロビジョニング

Josysの「Access Automation」機能は、SCIMを活用したSaaSアカウントの自動プロビジョニング・デプロビジョニングを実現します。人事システムからの入社・退職・異動情報をトリガーとして、Josysが自動的に対象SaaSのアカウント作成・削除・権限変更を実行します。

従来、情シス担当者が手作業で行っていた「入社時の各SaaS個別設定」「退職時の全SaaSアカウント削除確認」「異動時の権限変更」といった作業が、設定ルールに基づいて自動化されます。作業ミスや対応漏れのリスクを排除しつつ、担当者の工数を大幅に削減できます。

Microsoft Entra ID・Okta・Google WorkspaceとのIDaaS連携

JosysはMicrosoft Entra ID(旧Azure AD)、Okta、Google Workspace(Cloud Identity)といった主要IDaaSとのSCIM連携に対応しています。これらのIDaaSをすでに導入している企業では、Josysを連携させることで既存のアイデンティティ管理の仕組みを活かしながら、SaaS管理の自動化を追加できます。

IDaaSとJosysを組み合わせた場合、IDaaSでユーザー情報が変更される(または人事システムからIDaaSに変更が伝播する)と、Josysの連携機能を通じて、登録されている各SaaSへの操作が自動的に実行されます。情シス担当者はJosysの管理画面でプロビジョニング状況を一元的に確認できます。

350以上のSaaSへの対応と柔軟な連携設計

Josysは350以上のSaaSとの連携に対応しています。SCIM対応しているSaaSはSCIM経由で自動プロビジョニングを実行し、SCIM非対応のSaaSについても独自のAPI連携やRPA的なアプローチで自動化を補完します。これにより、企業が利用する多様なSaaSを一元的に管理し、対象アプリ・条件に応じて自動化範囲を広げることが可能です。

連携SaaSの例としては、コミュニケーションツール(Slack、Microsoft Teams、Zoom)、ドキュメント管理(Notion、Confluence、Google Workspace)、CRM・SFA(Salesforce、HubSpot)、開発ツール(GitHub、Jira)など、情シスが管理する幅広いカテゴリをカバーしています。

人事システムとの自動トリガー連携

Josysは主要な人事システムとの連携にも対応しています。SmartHR、HRMOS、カオナビなどのHRシステムから入退社・異動情報を受け取り、その情報をトリガーとしてプロビジョニング処理を自動実行します。

この仕組みにより、人事担当者がHRシステムで退職手続きを完了させると、情シスへの別途連絡なしに各SaaSのアカウント停止が自動実行されるフローが実現します。人事・情シスの連携コストが削減され、対応のタイムラグも解消されます。

入退社・異動の対応時間を大幅短縮

Josysを活用したSCIM自動化の導入前後の変化を整理すると次のようになります。

業務 導入前(手動) 導入後(Josys+SCIM)
入社時アカウント作成 20〜30分/人(SaaS数に比例) 数分以内(自動実行)
退職時アカウント削除 20〜30分/人(確認作業含む) 短時間(自動実行)
異動時権限変更 部門ごとに個別設定(複数SaaS) ルール変更で自動反映
対応漏れのリスク 人的ミスによる漏れが発生 自動化により大幅に低減

月に複数名の入退社・異動がある企業では、情シスの工数削減効果は非常に大きくなります。また、退職者アカウントの即時無効化によるセキュリティリスクの低減も重要な導入効果です。

Josysの製品概要を5分で理解する資料をダウンロードする

Josysの無料デモを予約して、自社の課題に合うかを確認する

まとめ

SCIMは、SaaS時代の入退社・異動アカウント管理を自動化するための標準規格です。RFC 7642/7643/7644で定義されたSCIM 2.0は、IDaaSとSaaSの間でユーザー情報を標準的な方法で転送・同期することを可能にし、手動管理に伴う工数・ミス・セキュリティリスクを大幅に低減します。

SCIMの活用には「人事システム→IDaaS→SCIM→各SaaS」という3層連携の構成が基本となります。IDaaSがユーザー情報のハブとして機能し、SCIMプロトコルを通じて各SaaSに変更を自動伝達することで、「人がアカウントを手作業で管理しない」状態を実現できます。

SCIMのみでは対応できないSaaSや細かなワークフローの自動化には、JosysのようなSaaS管理プラットフォームを組み合わせることで、より包括的な自動化が実現します。Josysは350以上のSaaSへの対応と主要IDaaSとの連携を通じて、入退社・異動にかかる情シスの運用コストを大幅に削減します。

アカウント管理の自動化に取り組む際は、まず現在の利用SaaSとIDaaSの状況を棚卸しし、SCIM対応可能なSaaSの範囲を確認することから始めることをお勧めします。その上でSCIM連携の設定を段階的に進めることで、大きなリスクなく自動化の恩恵を受けることができます。

Questions? Answers.

No items found.
No items found.