SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装を解説

SCIM（System for Cross-domain Identity Management）は、IDプロバイダー側で起きた入社・異動・退職を、SaaSや業務システムのアカウントへ自動的に反映させるためのREST APIの標準です。JSONでユーザーを表現し、/Users や /Groups といった決まったエンドポイントに対してPOST・PATCH・DELETEを投げる。それだけの仕組みで組織間のアカウント同期が成立します。

この記事では、自社サービスにSCIMエンドポイントを実装する立場、あるいはIdPと業務システムをつなぐ立場の実装者に向けて、RFCが定める範囲、SAMLとの責務の分かれ目、Entra IDにつないだときに出る非準拠、自前実装を見送るべき条件までを整理します。

まとめ｜SCIMを自前実装するかどうかを分ける3つの判断材料

判断材料は3つです。第1に、SSO（SAMLまたはOIDC）が既に動いているか。第2に、顧客テナントあたりのユーザー数が数百人規模で、入退社が毎月発生するか。第3に、自社のデータモデルがuserNameの一意性をテナント内で保証できるか。この3つがそろわない状態でSCIMだけ先に載せても、退職者アカウントの残留という本来の課題は解けません。

実装の難所はプロトコルの理解ではなく、IdP側の実装差にあります。RFC 7644に忠実なサーバーを書いてもEntra IDにはつながらないことがある。仕様の全域を実装するより、接続先のIdPが実際に送ってくるリクエストの形を先に確定させるほうが早い。

SCIM（クロスドメインID管理）の定義と、SSOだけでは閉じないアカウント管理の穴

RFC 7643と7644が定めるユーザー表現とRESTプロトコルの守備範囲

SCIM 2.0の実体は3本のRFCです。RFC 7642が定義とユースケース（Informational）、RFC 7643がコアスキーマ、RFC 7644がプロトコルを担い、いずれも2015年9月にIETFから公開されました。スキーマ側はUserとGroupの属性名と型を固定し、プロトコル側はHTTPメソッドの対応付け、フィルタ構文、エラー応答の形を決めています。

「クロスドメイン」が指すのは、管理主体の異なるシステム間でIDを運ぶことです。同一システム内のユーザー登録処理は対象外。前身のSCIM 1.1はIETFのワーキンググループ発足前に作られた別物で、スキーマURNもエンドポイント構成も2.0と互換性がありません。

認証を担うSAML・OIDCと、在籍状態を運ぶSCIMの責務分界

SAMLやOIDCが動くのはログインの瞬間だけです。IdPが本人性と属性をアサーションやIDトークンで伝え、サービス側がそれを受けてセッションを張る。ここで運ばれるのは認証結果であって、組織におけるその人の在籍状態ではありません。

SCIMが担当するのは、ログインしていない時間帯を含む在籍期間の全体です。人事システムで退職処理が走った瞬間、その人はもうログインしてこないため、認証プロトコルには何の情報も流れません。アカウントを止めるには、IdPから能動的に無効化を送るしかない。この通知路がSCIMです。認証側の設計はシングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説で整理しているため、本記事は在籍状態の同期に絞ります。

JITプロビジョニングが退職者のアカウントを消せない構造的な理由

SAMLにはJIT（Just-In-Time）プロビジョニングという簡易な代替手段があります。初回ログイン時にアサーションの属性からアカウントを作る方式で、導入コストは低い。作成だけなら実際に足ります。

穴が空くのは解約側です。JITはログインというイベントに紐づいて動くため、ログインしなくなった人には何も起きません。退職から数か月経ってもSaaS側にアカウントが残り、ユーザー数課金が計上され続けます。さらに厄介なのは、SSO経由でなくローカルパスワードやAPIトークンで直接入れる経路が残っている場合。IdPの無効化はここに届きません。SCIMは退職を検知した側からactiveをfalseにするPATCHを投げるため、この経路ごと塞げます。認証フローの詳細はSAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説を参照してください。

SCIM 2.0のリソースモデルと、実装が必要になるエンドポイントの範囲

Users・Groups・Schemasなど6つのエンドポイントの役割分担

RFCは複数のエンドポイントを定義していますが、全部を最初から作る必要はありません。Microsoft Learnも「/User エンドポイントから始めて広げればよい」という順序を示しています。

/Bulkを後回しにできる根拠は明確です。Microsoft Learnは2026年7月時点の記述で「現在 SCIM /Bulk はサポートされていません」と明言しており、大きなグループのメンバー更新も1件ずつのPATCHで届きます。サーバーやクラウドリソースまで含む広義のプロビジョニングとの用語整理はプロビジョニングとは？サーバー・ユーザー・クラウドの種類と自動化(IaC)の判断まで実装者向けに解説にまとめました。

userName・externalId・idが担う一意性とactiveが表す在籍状態

4つの属性の役割を取り違えると、あとから直しにくい設計になります。idはサービスプロバイダー側が採番する不変の識別子で、IdPはこれをキャッシュして以降の全操作に使う。externalIdはIdP側の識別子を預かる箱、userNameは一意なログイン識別子、activeは在籍状態を表す真偽値です。

Entraと接続するなら制約が2つ増えます。メンバー0件のListResponseを除くすべての応答にidを含めること。そして、受け取った値を受け取った形のまま保存することです。公式ドキュメントは電話番号を例に挙げ、55555555555で送られた値を+5 (555) 555-5555の形で保存したり返したりしてはならないと書いています。整形は親切のつもりでも、次の同期で差分と判定され続けます。

enterprise拡張と独自スキーマURNで社員番号や部署を運ぶ設計

コアスキーマだけでは人事情報が足りません。RFC 7643はエンタープライズ拡張を用意しており、URNはurn:ietf:params:scim:schemas:extension:enterprise:2.0:Userです。ここにemployeeNumber、department、costCenter、division、managerが入ります。独自属性はカスタムスキーマURNを定義して足せます。

注意点は入れ子の深さ。3つ以上のサブ属性を持つ複合属性へのデータ流入は、Entraからはサポートされません。人事情報を深い階層に設計すると、そこだけ手動運用に落ちます。

PATCH・フィルタ・ページングという、SCIM実装で最初に詰まる仕様の実際

activeをfalseにする無効化リクエストとopの大文字小文字の揺れ

SCIMで最も頻度が高い操作は、ユーザーの無効化です。RFC 7644のセクション3.5.2に沿えば、opは小文字のreplace、valueは真偽値のfalseになります。ところがEntraの既定動作はopがReplace、値は文字列の"False"。

公式ドキュメントはこれをSCIM 2.0準拠の課題として一覧に載せ、テナントURLにaadOptscim062020というフラグを付ければ準拠形へ切り替わると案内しています。旧動作へ戻すためのフラグAzureAdScimPatch2017も併記済み。受け側の設計判断はひとつに決まります。文字列の"False"と真偽値のfalseの両方を受理し、opは大文字小文字を区別せずに処理する。RFC自体がopをcase-insensitiveとして扱う立場なので、厳格に弾く理由がありません。

filterはeqとandだけ通ればよいという実装範囲の現実的な線引き

SCIMのフィルタ構文はco（含む）、sw（前方一致）、pr（存在）、比較演算子まで用意されています。全部を実装すると、パーサーだけで相応の工数になる。

実際に必要な範囲は狭いものです。Microsoft Learnは「Microsoft Entra専用では、次の演算子を使用します: eq、and」と明示しています。条件が1つ付きます。一意性の判定に使う属性はすべてフィルタで引ける必要があり、userNameとemails[type eq "work"].valueの両方で一意性を評価する設計なら、両方に応答しなければなりません。グループを扱うならexcludedAttributes=membersへの対応と、displayNameのテナント内一意性も要件に入ります。後者はSCIM仕様ではなくEntra統合側の要求です。

startIndex方式とRFC 9865のカーソル方式のどちらを実装するか

RFC 7644のページングはstartIndexとcountによる1始まりのインデックス方式です。実装は素直ですが、数万件規模のテーブルでOFFSETが深くなると応答が目に見えて遅くなります。

2025年10月公開のRFC 9865は、代替としてカーソル方式を標準化しました。cursorとcountをクエリパラメータに、nextCursorとpreviousCursorを応答属性に加え、対応状況は/ServiceProviderConfigで広告します。インデックス方式との併存も単独採用も仕様上は可能。判断は明快です。2026年7月時点では、まずインデックス方式を実装し、カーソル方式は併設にとどめる。EntraやOktaを含む主要なSCIMクライアントはstartIndex前提で実装されており、カーソルのみでは相互運用が成立しません。

409 uniquenessと429、返し方を先に決めるべきエラー応答の設計

エラー応答はurn:ietf:params:scim:api:messages:2.0:Errorというスキーマで返します。IdP側はステータスコードとscimTypeで挙動を分けるため、設計を後回しにすると原因不明の同期停止として跳ね返ってきます。

• 409（uniqueness）：既存と同じuserNameでPOSTされたとき。IdPはこれを見て作成から更新へ切り替える
• 429：レート制限。制限をかけること自体は許容されている
• 400（invalidFilter）：未対応のフィルタを受けたとき。黙って全件返すより明示的に拒否するほうが安全

公式ドキュメントが求めているのは、無効な値を「分かりやすく実行可能なエラーメッセージ」で拒否することです。IdP側の管理者はプロビジョニングログしか見られないため、メッセージの質がそのまま復旧時間になります。

Microsoft Entra IDとの接続で表面化する非準拠と、運用側の落とし穴

URLのルートにscimを含めるというEntra固有の要件と互換フラグ

実装が仕様どおりでも、URLの形で弾かれることがあります。Entraはエンドポイントのルートにscimが含まれていることを要求する。慣例的な/scim/v2というベースパスはここに由来します。

接続時の前提も押さえておきます。HTTPSが必須、すべての応答のヘッダーはcontent-type: application/scim+json、認証はベアラートークン1本です。管理画面の「テスト接続」ではランダムなユーザーとグループを取得するリクエストが飛ぶため、空のデータベースでもListResponseを正しく返せないと設定を保存できません。IdP側の全体像はMicrosoft Entra ID（旧Azure AD）とは？読み方・Azure AD/Active Directoryとの違い・機能・料金を解説【2026年版】にまとめています。

検疫に落ちたジョブが1日1回に間引かれ4週間で無効化される流れ

接続後の事故で最も静かに進行するのが検疫（quarantine）です。管理者資格情報の失効などでターゲットへの呼び出しがほぼ全て失敗し続けると、プロビジョニングジョブは検疫状態に入ります。

起きることは2段階。まず増分サイクルの頻度が徐々に落ち、最終的に1日1回まで間引かれる。次に、検疫にとどまる期間が4週間を超えるとジョブ自体が無効化されます。対策は設定時に済ませるのが確実で、プロビジョニングのプロパティで通知用メールアドレスを登録し、エラー時のメール通知にチェックを入れておきます。ここを空欄のまま本番に出すと、退職者の無効化が1か月止まっていても誰も気づきません。

30日後に飛んでくる物理削除と、無効化だけ実装した場合の齟齬

削除のセマンティクスは二段構えです。Entra ID側でユーザーが論理削除（ごみ箱行き）されると、activeをfalseにする更新リクエストが届く。テナントから完全に削除されるのは30日後で、この時点でDELETEリクエストが送られます。

齟齬が出るのは、無効化だけ実装してDELETEを未対応にしたケースです。30日後に届くDELETEがエラーになり、そのユーザーは再試行対象として残り続けます。公式ドキュメントも「論理的な削除と物理的な削除の両方を常にサポートしてください」と明記しており、理由は誤って無効化された場合に顧客が回復できるようにするためだと添えています。割り当て解除やスコープ外への移動でも無効化は発生するため、active=falseのユーザーもGETで返す実装が必要です。応答から消してよいのは完全削除のときだけ。

SCIM対応と書かれていても1.1や独自仕様のことがある確認の手順

ベンダーの機能一覧にある「SCIM対応」という記述は、そのまま信じない前提で読みます。Microsoft LearnのSlackプロビジョニングチュートリアルには「ギャラリーアプリケーションは、SlackのSCIM v1サーバーと連携するようにカスタマイズされています」と書かれており、カスタムアプリやBYOAでの統合はサポート対象外。2.0のクライアントを向けても動きません。

同じページには実装差の具体例も並びます。SlackのuserNameは21文字未満かつ一意である必要があり、照合に使えるのはuserNameとemailのみ。displayNameに@が含まれるとプロビジョニングログにAttributeValidationFailedが記録されます。確認すべきは4点。対応バージョンが2.0か、照合に使える属性は何か、対応するフィルタ演算子は何か、削除は論理と物理のどちらが届くか。この4点への回答がベンダーから返らないなら、接続検証の工数を多めに見積もる合図です。

2026年時点の仕様拡張と、SCIMを自前実装する条件・見送る条件の線引き

RFC 9865・9944・9967という2025年以降の3つの仕様拡張

2015年で止まっていたSCIMは、2025年以降に動きを再開しています。IETFのSCIMワーキンググループから3本のProposed Standardが出ました。RFC 9865（2025年10月）がカーソルページング、RFC 9944（2026年5月）がデバイススキーマ拡張、RFC 9967（2026年5月）がSecurity Event Tokens（SET）のプロファイルです。

実装への影響が大きいのはRFC 9967でしょう。SCIMのサービスプロバイダーと受信側がSETで非同期にメッセージを交換する枠組みを定め、リソース変更の通知と追跡用のSet-Txnレスポンスヘッダーを規定しています。定期ポーリングに頼らず変更を監視できる方向です。ただし採用判断は保留が妥当。2026年7月時点では対応した主要IdPの実装が出そろっておらず、先行実装は投資回収の見込みが立ちません。まずは/ServiceProviderConfigで自らの対応状況を正しく広告する土台を固めます。

AIエージェントをSCIMで管理する個人ドラフトの現在地と扱い方

SCIMワーキンググループには、AIエージェントにIDライフサイクルを与える提案が複数出ています。draft-wzdk-scim-agent-resource-00（2026年6月5日）がAIエージェントリソース拡張、draft-kushwaha-scim-agent-governance-00（2026年7月27日）がエージェントのガバナンス拡張です。

扱いは慎重にすべき段階です。どちらも版数は-00で、WG採択前の個人提出という位置づけ。仕様は今後変わりますし、消える可能性もあります。実装は時期尚早と判断してよい。ただし設計への含意は拾えます。UserとGroup以外のリソースタイプが増える方向は、デバイススキーマ拡張がRFC化された事実からも読み取れる。/ResourceTypesを後付けしにくい形で実装すると、リソース追加のたびに設計をやり直すことになります。

自社SaaSにSCIMを載せる条件と、載せない方がよい3つの場面

載せる判断が立つのは、次の3つがそろったときです。エンタープライズ顧客との商談でIdP連携が要件化している。1テナント数百ユーザー規模で入退社が月次で発生している。SSOが既に稼働している。この状態なら、SCIMは既存のSSO投資を回収する側の機能になります。

逆に、次のいずれかに当てはまるなら見送るべきです。

• SSOが未実装：認証の統合がないままアカウントだけ自動生成しても、ログイン経路が分散して統制は効かない。SSOを先に入れる
• 顧客あたり数十ユーザーで年間の入退社が数人規模：CSVインポートと管理画面での手動無効化で足りる。実装と受け入れ検証の工数が回収できない
• 1ユーザーが複数テナントに所属するデータモデル：userNameのテナント内一意性を保証できず、409を返すべき場面と200を返すべき場面が確定しない。先にデータモデルを直す

実装前に通しておく受け入れテストの順番と、外部委託の線引き方

検証は順番が決まっています。まずPOST /Usersで201が返り、続くGETのフィルタ検索で同じ値が返ること。次に同じuserNameで再度POSTして409になること。3番目にPATCHでactiveをfalseにし、そのユーザーがGETで返り続けること。4番目にDELETEを流し、以後の取得で消えていること。ここまでをcurlで通してから、Entra側の「テスト接続」、オンデマンドプロビジョニングでの1人検証、少人数を割り当てた初期サイクルへ広げます。初期サイクルの所要時間は、割り当て済みユーザーとグループを同期する構成なら最小で対象数×0.01分、最大で対象数×0.08分というのが公式の目安。1,000件なら10分から80分の幅です。

外部に任せる線引きは、自社のユーザーモデルをどこまで触るかで決まります。エンドポイントの実装だけなら内製でも収まりますが、テナント設計や既存の会員データベースの構造にまで手が入るなら別の仕事です。ユーザー管理基盤の設計から見直すなら、会員管理システム開発のように認証・ID管理を含めて設計を引き受ける形での相談が現実的な選択肢になります。

よくある質問

SCIMの導入検討でよく挙がる質問を、実装判断に直結する5つに絞って回答します。

SCIMとSAMLの違いは何ですか？

担当する時間帯が違います。SAMLはログインの瞬間にIdPからサービス側へ認証結果を渡すプロトコル。SCIMはログインの有無と関係なく、アカウントの作成・属性更新・無効化・削除を能動的に送るプロトコルです。両者は競合せず、SSOで認証を統合したうえでSCIMでライフサイクルを同期する組み合わせが標準的な構成になります。

SCIM 1.1と2.0に互換性はありますか？

ありません。1.1はIETFのワーキンググループ発足前に作られた仕様で、スキーマURNもエンドポイントの構成も2.0とは異なります。Microsoft LearnのSlackプロビジョニングチュートリアルの記載どおり、2026年時点でも1.x系で動いているサービスは残っています。ベンダーが「SCIM対応」とだけ書いている場合、まず対応バージョンの確認から入ってください。

SCIM連携にIDaaSやIdPは必須ですか？

プロトコル上は、SCIMクライアントを実装したシステムであれば何でも構いません。人事システムから直接リクエストを送る構成も成立します。ただし実務では、Entra IDやOktaといったIdPがクライアント実装、属性マッピング、再試行、ログ記録をまとめて引き受けるため、自前でクライアントを書く選択が合理的になる場面は限られる。IdPを持たない組織がSCIM対応SaaSだけを増やしても、同期を起動する主体がいないので自動化は動きません。

SCIMで同期できる属性はどこまでですか？

コアスキーマのuserName、name、emails、phoneNumbers、activeなどに加え、エンタープライズ拡張のemployeeNumber、department、costCenter、managerが標準です。制約もあり、複数値属性のtypeサブ属性は重複できません。同じwork種別のメールアドレスを2つ持つ設計は通らないということです。

プロビジョニングが反映されるまでどのくらいかかりますか？

初回の一括同期と、その後の差分同期で性質が変わります。Entraの公式な目安では、初期サイクルは対象数×0.01分から対象数×0.08分の範囲。その後は増分サイクルがアプリごとに定義された間隔で回り続けます。急ぐ場合はオンデマンドプロビジョニングで個別ユーザーを即時同期できます。反映が明らかに遅いときは、ジョブが検疫状態に落ちて頻度が1日1回まで下がっていないかを確認してください。

関連記事

• シングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説：SCIMと組み合わせる認証側の設計です
• SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説：JITプロビジョニングの前提になる認証フローです
• プロビジョニングとは？サーバー・ユーザー・クラウドの種類と自動化(IaC)の判断まで実装者向けに解説：サーバーやクラウドを含む広義の用語整理です
• Microsoft Entra ID（旧Azure AD）とは？読み方・Azure AD/Active Directoryとの違い・機能・料金を解説【2026年版】：SCIMクライアント側となるIdPの全体像です
• 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】：ID管理全体の中でのSCIMの位置づけです