
従業員が入社するたびに、情シス担当者は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(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はこの問題を解決するために設計された規格であり、ユーザー情報の「共通言語」として機能します。
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 2.0はREST APIベースのアーキテクチャを採用しており、JSONフォーマットでデータを転送します。これにより、さまざまなSaaSが標準的な方法でSCIMに対応することが容易になっています。
参考: RFC 7644 - System for Cross-domain Identity Management: Protocol
SCIMが注目される背景には、SaaS時代特有のアカウント管理の煩雑さがあります。入社・退職・異動のそれぞれのシーンで発生する課題を具体的に見ていきます。

従業員が入社する際、情シス担当者はHRシステムから入社情報を受け取り、各SaaSの管理画面でアカウントを個別に作成する必要があります。利用SaaSが20種類あれば20回のログインと設定作業が発生します。この作業には数時間から半日程度かかることも珍しくなく、入社初日に業務を開始できないという初動遅延が生じやすい状況です。また、対応が複数人に分担されている場合、一部のSaaSでアカウント作成が漏れるリスクがあります。
退職時はさらに問題が深刻です。退職者のアカウントを全SaaSから確実に削除・無効化しなければなりませんが、利用SaaSの種類が多い企業では一部のSaaSで削除漏れが発生するケースが報告されています。退職者が元の会社のSaaSアカウントにアクセスできる状態が続くことは、情報漏洩や不正アクセスのリスクに直結します。
総務省の情報セキュリティガイドラインでも、退職者のアクセス権限管理は情報セキュリティ上の重要な管理項目として位置づけられています。手動管理では確実性に限界があり、仕組みとしての自動化が求められます。
部署異動や役職変更の際には、旧部門のアクセス権限を削除し、新部門の権限を付与するという二重の作業が発生します。SaaSごとに権限の概念やロール設定が異なるため、適切な権限設定には各SaaSへの深い理解が必要です。設定ミスや対応遅延により、旧部門の機密情報への継続的なアクセスが発生したり、新業務に必要なツールが使えないという問題が生じます。
SCIMを導入すると、IDaaSでユーザー情報を変更するだけで、連携している全SaaSに変更が自動反映されます。入社情報の登録から連携SaaSへのアカウント作成まで、人手を介さずに短時間で完結します。退職処理も一元操作で連携SaaSのアクセスを自動無効化でき、削除漏れリスクを大幅に低減できます(実際の反映速度や対象範囲はSaaS・IdPの同期設定に依存します)。
SCIMがどのように動作するか、プロビジョニングの概念とフローを詳しく説明します。
プロビジョニング(Provisioning)とは、ユーザーがシステムを利用できるようにアカウントを作成・設定することを指します。具体的には、アカウントの新規作成、初期パスワードの設定、アクセス権限の付与、所属グループへの追加などが含まれます。
デプロビジョニング(Deprovisioning)はその逆で、ユーザーのアカウントを無効化・削除し、アクセス権限を剥奪することです。退職者処理の文脈では特に重要な概念です。
JIT(Just-in-Time)プロビジョニングとの違いも押さえておきましょう。JITプロビジョニングはユーザーが初めてサービスにログインした際に自動的にアカウントを作成する仕組みです。SAMLやOIDCベースのSSOと組み合わせて使用されることが多く、「使ったときに作る」という考え方です。一方SCIMは事前にアカウントを作成・管理するため、ログイン前からアカウントの存在と権限設定が保証されています。未使用アカウントの一覧管理やデプロビジョニングの確実性という観点では、SCIMによる事前プロビジョニングのほうが管理の透明性が高い状態を維持できます。
SCIMの動作は、IDプロバイダー(IdP)が主体となってSaaSに変更を伝達するプッシュ型の仕組みです。

基本的な動作フローは次のとおりです。
この仕組みにより、IDaaS側で一度操作するだけで、SCIM連携しているすべてのSaaSに変更が自動伝播します。
SCIMはREST APIを使用しており、主なHTTPメソッドとその役割は以下のとおりです。
SCIMで同期できるユーザー属性(スキーマ)は、RFC 7643で標準定義されています。主な同期対象は次のとおりです。
氏名(姓・名・表示名)、メールアドレス、ユーザー名、電話番号といった基本的なユーザー情報に加え、部署名、役職、所属組織(会社名)などの組織情報を同期できます。また、アカウントの有効化・無効化状態(activeフラグ)も同期対象であり、退職者処理ではこの属性をfalseに設定することでアカウントを無効化できます。
グループ情報も同期対象です。Active Directoryのグループや組織内のチーム構造をSaaS側に反映させることで、グループ単位でのアクセス権限管理が可能になります。
カスタム属性(Enterprise User Extension)を使えば、標準スキーマに含まれない独自の属性(社員番号、雇用形態、入社日など)も同期対象に追加できます。
SCIMを活用した自動化を実現するには、SCIMの「送信元」となるシステムが必要です。その役割を担うのが通常はIDaaSです。

SCIMはプロトコルであり、それ自体がシステムを動かすわけではありません。SCIMを使って各SaaSにユーザー情報を送信するための「制御タワー」が必要であり、その役割を担うのがIDaaS(Identity as a Service)です。
代表的なIDaaSとしてはMicrosoft Entra ID(旧Azure AD)、Okta、Google Workspace(Cloud Identity)などがあります。これらのIDaaSはSCIMプロビジョニング機能を標準搭載しており、管理画面から各SaaSとのSCIM連携設定を行うことができます。
典型的な3層連携の構成は次のとおりです。
人事システムとIDaaSの連携方法はSCIMとは別のAPIやCSVインポートで行われることが多く、IDaaSがユーザー情報のハブとして機能することで、個々のSaaSとの接続をSCIMで標準化できます。
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 2.0に対応しています。よく利用されるSaaSの対応状況を以下に示します。
注意が必要なのは、SCIM対応がプランによって制限されているSaaSが多い点です。導入前に各SaaSの料金プランと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は、IDaaSとのSCIM連携を活用したSaaSプロビジョニングの自動化を実現するSaaS管理プラットフォームです。

Josysの「Access Automation」機能は、SCIMを活用したSaaSアカウントの自動プロビジョニング・デプロビジョニングを実現します。人事システムからの入社・退職・異動情報をトリガーとして、Josysが自動的に対象SaaSのアカウント作成・削除・権限変更を実行します。
従来、情シス担当者が手作業で行っていた「入社時の各SaaS個別設定」「退職時の全SaaSアカウント削除確認」「異動時の権限変更」といった作業が、設定ルールに基づいて自動化されます。作業ミスや対応漏れのリスクを排除しつつ、担当者の工数を大幅に削減できます。
JosysはMicrosoft Entra ID(旧Azure AD)、Okta、Google Workspace(Cloud Identity)といった主要IDaaSとのSCIM連携に対応しています。これらのIDaaSをすでに導入している企業では、Josysを連携させることで既存のアイデンティティ管理の仕組みを活かしながら、SaaS管理の自動化を追加できます。
IDaaSとJosysを組み合わせた場合、IDaaSでユーザー情報が変更される(または人事システムからIDaaSに変更が伝播する)と、Josysの連携機能を通じて、登録されている各SaaSへの操作が自動的に実行されます。情シス担当者はJosysの管理画面でプロビジョニング状況を一元的に確認できます。
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は、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連携の設定を段階的に進めることで、大きなリスクなく自動化の恩恵を受けることができます。
Sign-up for a 14-day free trial and transform your IT operations.
