>
>
最終更新日
【監修：情シス歴15年のID管理スペシャリスト】企業内で複数のSaaS利用が当たり前となる中、入退社時のアカウント管理（プロビジョニング）を自動化する「SCIM」への関心が高まっています。本記事では、SCIMプロビジョニングの仕組みから、SAMLとの違い、Google WorkspaceやOktaなどのIdPとの具体的な連携事例まで、情シス担当者が押さえておくべきポイントをわかりやすく解説します。
SCIMとは
この記事でわかること
SCIMプロビジョニングの仕組みと必要性
SCIMとSAMLの明確な役割の違い
自社へのSCIM導入を判断する基準と具体的な手順
SCIM（System for Cross-domain Identity Management）は、様々なドメイン間でユーザID情報のやりとりを自動化する際に使用される規格です。 インターネット技術の標準化機関であるIETF（Internet Engineering Task Force）によって標準化されたこの規格により、従来のIDデータ交換手法の問題を解決し、多くの利点を得られます。
SCIMが求められた背景
クラウド化により増加した複数システムのアカウントを一元管理するため、標準化されたプロトコルが必要とされました。
SCIMが規格化された背景には、クラウドベースのITシステムの普及、Active Directoryの限界、情報セキュリティの問題等が存在します。 例えば、ある企業がSalesforceやGoogle Workspaceなど複数のサービスを活用している場合、それぞれ異なるアカウントを使わざるを得ない状況が発生し、複数の利用者認証情報を管理する必要が生じていました。複数サービスのアカウントをバラバラに管理する手間を解消するため、SCIMが標準規格として整備されました。
シングルサインオンを実現するには
SSO（認証）機能だけではカバーできない、安全なID管理（プロビジョニング）を自動化できるSCIMが並行して求められました。
異なるドメイン間でのID・パスワード管理はセキュリティ対策が必須です。SAMLはSSO（認証）を目的としたプロトコルであり、プロビジョニング（アカウント同期）には対応していません。その欠けていた機能を補う規格としてSCIMが策定されました。また通信プロトコル（データ形式）も異なり、SAMLはXMLベース、SCIMはJSONベースで構成されています。
シングルサインオンの問題点
認証は一度で済んでも、各システムごとに個別のアカウント登録が必要という運用上の課題が残っていました。
シングルサインオンでは、複数のシステムを一度の認証で利用できるようになりましたが、SSOで認証は一本化できても、各サービスへのアカウント登録は依然として個別に必要でした。人事情報が変わった際の更新作業も手動のままで、管理者の負担は残り続けていました。
SCIMプロビジョニングとは
SCIMプロビジョニングとは、従業員の入退社や異動に伴うクラウドアカウントの作成・変更・削除を、IdPから各クラウドサービス（SP）へ自動で同期する仕組みです。
企業においてSaaSの利用が増加する中、アカウントの管理を手作業で行うことは限界を迎えています。「scimプロビジョニングとは」具体的に何をするのかというと、人事システム等で従業員情報を更新した際、連携先のSaaS（SlackやSalesforceなど）のアカウントを自動で追加したり、不要になったアカウントを即座に停止したりする一連の処理のことです。
よくある失敗パターンとして、手動管理の抜け漏れにより退職者のアカウントが各SaaSに放置される「幽霊アカウント」問題があります。退職者IDの残存は重大なセキュリティリスクとなります。さらに、使われていないアカウントにライセンス費用を支払い続ける無駄なコストも発生します。scim プロビジョニングを導入することで、これらのリスクと無駄を根絶できます。
SCIMプロビジョニング導入の判断フロー
企業の規模や利用するSaaSの数に応じて、手動管理からIDaaSを活用した自動化へと移行すべきです。
情シス部門では一般的に、以下の基準で自動化を検討します。
従業員50名未満: 手動管理（ただし、定期的な棚卸しルール化が必須）
従業員50〜300名: 頻繁に利用する主要SaaSから優先してscimプロビジョニングを導入
従業員300名超またはSaaS10個以上: IDaaSを用いた完全自動化が必須（PC1台・1アカウントあたりの設定工数は平均1〜2時間かかるとされ、手作業による業務逼迫を防ぐため）
▲ SCIMプロビジョニングによるアカウント自動処理の流れ
SCIMの仕組み
SCIMは、HTTPプロトコルと軽量なJSONデータ形式を利用して、システム間でユーザー情報を安全かつ迅速に自動同期します。
SCIMのアーキテクチャは、ID情報を管理する「IdP（IDプロバイダー）」から、ID情報を受け取りサービスを提供する「SP（サービスプロバイダー）」へ、変更内容を送信するクライアント・サーバーモデルで構成されます。RESTful APIをベースにしているため、クラウドサービス間の連携に最適化されています。
SCIMの通信形式
HTTPSを採用することで、企業のファイアウォール環境下でもセキュアな通信を確保します。
SCIMは、インターネットで広く使われるHTTPを通信形式として採用しており、多くの場合、企業のファイアウォール制限下でも問題なく動作します。 また、HTTPSを使用するため、ユーザID認証情報を、安全に受け渡すことができます。
JSON＋HTTPで認証情報をやり取り
軽量なテキストデータであるJSON形式を利用することで、幅広いシステムとの高い互換性を実現します。
SCIMは、JSON形式の利用者認証情報をHTTPを使ってIdP（Identity Provider）やSP（Service Provider）間で共有することで、IDプロビジョニングの自動化を可能にします。 JSONはテキストベースの軽量なデータ形式で、主要なプログラミング言語のほぼすべてで標準サポートされているため、システム間の互換性が高いのが特徴です。
ユーザーID情報の変更も自動的に同期
IdPでの変更が即座に各サービスへ反映され、退職者のアカウント放置によるセキュリティリスクを防ぎます。
SCIMを利用することで、IdPとSP間で利用者認証情報の作成、更新、削除が自動的に同期され、効率的なID管理ができます。 これにより、退職者や異動者のアカウントの更新忘れ等のセキュリティリスクの軽減が可能です。
SCIMプロトコルとSCIMトークン（OAuth等）の仕組み
OAuth 2.0を利用したSCIMトークンにより、不正アクセスを防ぎながら安全に情報を連携します。
scimプロトコルは、APIを通じてユーザーの追加や削除といった指示を安全に伝達するための通信ルールです。しかし、誰でもこのAPIを操作できる状態ではセキュリティ上問題があります。そこで、システム間の認証手段として「SCIMトークン」が用いられます。一般的に、SCIMトークンには「OAuth 2.0のベアラートークン（Bearer Token）」が推奨されており、これにより「本当に許可されたIdPからのリクエストか」をSP側が確実に検証します。平易に言えば、scimプロトコルが「情報の運び手」であり、SCIMトークンが「通行証」の役割を果たしています。
▲ SCIMのシステムアーキテクチャと通信の仕組み
SCIMの特徴
SCIMは、IETFによって標準化されたWeb APIとして動作し、自社独自の属性（スキーマ）を追加できる拡張性の高さが特徴です。
標準化されたユーザー管理の仕組み
RFCによって厳密に定義された規格であり、ベンダーを問わず相互接続が容易です。
SCIMは、IETFによって標準化されたネットワーク技術と連携が容易な規格のため、広く知られています。 以下のRFCによって、SCIMの仕様が詳細に定義されています。
RFC7642: 定義、概要、概念、要件やユースケース
RFC7643: コアスキーマ
RFC7644: プロトコル
WebAPIとして使えるためのポイント
ユーザー情報の追加や削除をAPI操作で完結でき、開発・連携のハードルを下げます。
SCIMは、利用者情報における様々な操作（追加、削除など）をAPIとしてWebサーバーに実装する事が可能です。 SCIMではWebAPIとして活用できるように以下の3つの要素が使用されます。
ネットワーク上に公開されたサーバーのベースID（例：https://scim.auth.iij.jp/scim/v2/Users/12345）
リソースタイプ（User,Group,Selfなど）
アカウントIDに適した識別子
また、WebAPIを利用する際はOAuth2.0による認証が推奨されます。 その為、利用する際は前もってアクセストークンなどを手に入れておく必要があります。
スキーマを拡張できる
SCIMは標準規格としてスキーマ（データベース構造）が搭載されています。そのため、SCIMではWebAPIを通じてスキーマを拡張することが可能です。 データベースの属性を決定したり、拡張したスキーマでの変更も同期されるのがSCIMの特徴です。
SCIMとSAMLの役割の違い
SCIMは「アカウント情報の同期」を担当し、SAMLは「ログイン時の認証」を担当するという明確な役割分担があります。
SCIMとSAMLは異なる役割を持つプロトコルです。
SCIMがIDプロビジョニング*に焦点を当てているのに対して、SAMLはフェデレーション（一度認証されれば許可されたすべてのサービスやシステムが使用可能）実現することを目的としています。
これらの違いを理解し、適切なプロトコルを用いることで、効率的な運用を実現することが可能です。 *システムやサービスの需要に応じて、サーバーやネットワークなどのITインフラ設備を調達・設定することを「プロビジョニング」と呼びます。
SCIMとSAMLは競合するものではなく、役割が異なります。SAMLは「一度のログインで複数サービスを使える（SSO）」ための認証プロトコル、SCIMは「アカウント自体を自動作成・削除する」プロビジョニングプロトコルです。両者を組み合わせることで、セキュリティと利便性を両立できます。
SCIMを利用するメリットとは
アクセス権の一元管理によるセキュリティ強化と、管理工数の大幅な削減が主なメリットです。
認可を強化できる
従業員の権限変更が自動で反映され、不適切なアクセスを即座に遮断できます。
SCIMを利用することで、アクセス権の一元的な管理と自動化されたIDプロビジョニングが実現され、「認可」が強化されます。たとえば部署異動の際、IdPでグループを変更するだけで連携先SaaS全体の権限が即時更新されます。アクセス権の過剰付与や取り忘れを構造的に防げます。
管理者の負担を軽減できる
手作業でのアカウント登録や削除業務がなくなり、内部監査への対応も容易になります。
SCIMを利用することで、管理者はアカウント管理に関する負担を軽減できます。月次の棚卸し作業や監査対応の工数も削減できるため、少人数の情シス体制でも運用が回りやすくなります。
▲ SCIMとSAMLの役割の違い
SCIMを利用できるクラウドサービスとは
主要なクラウドサービスやIdPの多くがSCIM連携をサポートしており、すぐに自動化設定を始められます。
SCIMはID管理の負担を減らす便利な規格であり、すでにいくつかの主要クラウドサービスで利用が可能です。
主要SaaSは概ねSCIM対応済みですが、国産SaaSや中小ベンダー製品では非対応のケースもあるため、導入前に各サービスの仕様を確認してください。
SCIMが利用できるクラウドサービスは以下の通りです。
Google Workspace
Salesforce
Azure AD/Microsoft365
Slack
SAP
IdP（Google WorkspaceやOkta等）でのSCIM連携ユースケース
Google WorkspaceやOktaなどのIdPを中心としたSCIM連携を構築することで、数百人規模のアカウント管理工数を劇的に削減できます。
近年、idp scim連携のユースケースとして注目されるのが、主要なIdPを起点とする構成です。多くの企業で以下のような仕組みが採用されています。
Google WorkspaceをIdPとした連携（google scim）: GoogleをIdPとして設定し、従業員が入社した際にGoogle上でアカウントを作ると、SCIMプロビジョニングによって連携先のSlackやSalesforceのアカウントが自動生成されます。管理者はGoogleの画面を操作するだけで済みます。
Oktaを利用した高度な連携: 数千名規模の企業では、Oktaの統合ディレクトリをハブとして各SaaSへ属性情報（部署や役職など）を即時同期します。これにより、アカウント権限の変更作業が自動化されます。例えば、人事システムをマスター情報とし、Oktaを介して各種SaaSへ入退社・異動情報をシームレスに伝達するプロビジョニングフローを構築することが可能です。
SCIMが利用できるID管理システムとは
近年のID管理システムやIDaaSの多くはSCIMに対応しており、導入効果を最大化できます。
多くのIDaaS・ID管理システムはSCIMに標準対応しており、設定画面からSCIMエンドポイントとトークンを登録するだけで連携を始められます。
よくある質問
SCIMとは？
SCIMは、クラウドサービス間でユーザーアカウントの作成や削除（プロビジョニング）を自動化するための標準規格です。システム間でのID管理の手間と、退職者のアカウント消し忘れといったセキュリティリスクを大幅に削減します。
SCIMとSAMLの違いは何ですか？
SCIMはアカウントの作成や情報同期を行う「プロビジョニング」のプロトコルです。一方、SAMLは一度のログインで複数サービスを利用可能にする「認証（シングルサインオン）」のプロトコルです。
SCIMに対応していないSaaSはどうすればよいか？
SCIM非対応のSaaS（一部の国産ツールなど）については、IDaaSが提供する独自のプロビジョニングAPIを利用するか、CSVのインポート機能による手動/半自動の運用を組み合わせるのが一般的です。導入前に各SaaSの仕様を確認しましょう。
まとめ
SaaSの利用拡大に伴い、従業員のアカウント管理を手作業で行うことは、業務効率の低下だけでなく重大な情報漏えいのリスクを招きます。SCIMプロビジョニングとSAML認証を適切に組み合わせることで、安全で効率的なアクセス環境の構築が可能です。明日から取り組める最初の一歩として、まずは自社で利用しているSaaSのアカウント数と、毎月発生している入退社に伴う設定工数の棚卸しを実施してください。月10時間以上の工数が発生している場合は、SCIMに対応したID管理システムやIDaaSの導入を検討すべきタイミングです。
【SCIM導入に向けたチェックリスト】
✅ 自社で利用中のSaaS一覧とアカウント数を棚卸しした
✅ 月次の入退社に伴うアカウント設定工数を計測した
✅ 主要SaaSのSCIM対応状況を確認した
✅ 毎月の手作業の工数が多い場合、IDaaSの選定・比較を開始した
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
橋爪兼続
ライトハウスコンサルタント代表。2013年海上保安大学校本科第Ⅲ群（情報通信課程）卒業。巡視船主任通信士を歴任し、退職後、大手私鉄の鉄道運行の基幹システムの保守に従事。一般社団法人情報処理安全確保支援士会の前身団体である情報処理安全確保支援士会の発起人。情報処理安全確保支援士(第000049号)。
