--- title: "SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装を解説" url: "https://www.issoh.co.jp/tech/details/15876/" published: 2026-07-29 updated: 2026-10-05 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 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だけ先に載せても、退職者アカウントの残留という本来の課題は解けません。自前実装ではなくSaaS側へ寄せる場合の費用と分岐点は[WorkOSとは：SSOとSCIMを外部化するB2B SaaS向け認証基盤](https://www.issoh.co.jp/tech/details/17295/)で扱っています。AWSのアイデンティティソースとして外部IdPを繋ぐ場合の同期設計は[AWS IAM Identity Centerの導入手順](https://www.issoh.co.jp/tech/details/15900/)で整理しています。 実装の難所はプロトコルの理解ではなく、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選定を開発視点で解説](https://www.issoh.co.jp/tech/details/15821/)で整理しているため、本記事は在籍状態の同期に絞ります。 ### JITプロビジョニングが退職者のアカウントを消せない構造的な理由 SAMLにはJIT（Just-In-Time）プロビジョニングという簡易な代替手段があります。初回ログイン時にアサーションの属性からアカウントを作る方式で、導入コストは低い。JITとSCIMの分担を含む連携全体の設計は[フェデレーション認証のIdPとSPの信頼設計と属性連携](https://www.issoh.co.jp/tech/details/16413/)で扱っています。作成だけなら実際に足ります。 穴が空くのは解約側です。JITはログインというイベントに紐づいて動くため、ログインしなくなった人には何も起きません。退職から数か月経ってもSaaS側にアカウントが残り、ユーザー数課金が計上され続けます。さらに厄介なのは、SSO経由でなくローカルパスワードやAPIトークンで直接入れる経路が残っている場合。IdPの無効化はここに届きません。SCIMは退職を検知した側から`active`を`false`にするPATCHを投げるため、この経路ごと塞げます。認証フローの詳細は[SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説](https://www.issoh.co.jp/tech/details/13299/)を参照してください。 ## SCIM 2.0のリソースモデルと、実装が必要になるエンドポイントの範囲 ### Users・Groups・Schemasなど6つのエンドポイントの役割分担 RFCは複数のエンドポイントを定義していますが、全部を最初から作る必要はありません。Microsoft Learnも「`/User` エンドポイントから始めて広げればよい」という順序を示しています。 | エンドポイント | 役割 | 実装の優先度 | | --------------------- | ----------- | ----------- | | Users | ユーザーのCRUD | 必須 | | Groups | グループとメンバー管理 | 要件次第 | | Schemas | 対応属性の検出 | 拡張属性を持つなら必要 | | ServiceProviderConfig | 対応機能の広告 | 早めに用意する | | ResourceTypes | リソース種別のメタ情報 | 早めに用意する | | Bulk | 一括操作 | 後回しでよい | `/Bulk`を後回しにできる根拠は明確です。Microsoft Learnは2026年7月時点の記述で「現在 SCIM /Bulk はサポートされていません」と明言しており、大きなグループのメンバー更新も1件ずつのPATCHで届きます。サーバーやクラウドリソースまで含む広義のプロビジョニングとの用語整理は[プロビジョニングとは？サーバー・ユーザー・クラウドの種類と自動化(IaC)の判断まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13376/)にまとめました。 ### 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年版】](https://www.issoh.co.jp/tech/details/3163/)にまとめています。 ### 検疫に落ちたジョブが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投資を回収する側の機能になります。接続先となるSaaS側でSCIMを有効にする手順は、[Bitwardenを組織で導入する手順](https://www.issoh.co.jp/tech/details/17356/)に実例をまとめています。 逆に、次のいずれかに当てはまるなら見送るべきです。 - 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管理システム開発](https://www.issoh.co.jp/service/system/identity/)のように認証・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クライアントを実装したシステムであれば何でも構いません。人事システムから直接リクエストを送る構成も成立します。人事データを起点に各システムへSCIMで配る国産製品の例は[Keyspiderとは：国産ID管理の連携方式と自社システムをつなぐ実装手順](https://www.issoh.co.jp/tech/details/18103/)で扱っています。ただし実務では、Entra IDやOktaといったIdPがクライアント実装、属性マッピング、再試行、ログ記録をまとめて引き受けるため、自前でクライアントを書く選択が合理的になる場面は限られる。IdPを持たない組織がSCIM対応SaaSだけを増やしても、同期を起動する主体がいないので自動化は動きません。同期の起点となるIDaaSの守備範囲と選定の考え方は[IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携](https://www.issoh.co.jp/tech/details/16401/)にまとめています。 ### SCIMで同期できる属性はどこまでですか？ コアスキーマの`userName`、`name`、`emails`、`phoneNumbers`、`active`などに加え、エンタープライズ拡張の`employeeNumber`、`department`、`costCenter`、`manager`が標準です。制約もあり、複数値属性の`type`サブ属性は重複できません。同じ`work`種別のメールアドレスを2つ持つ設計は通らないということです。 ### プロビジョニングが反映されるまでどのくらいかかりますか？ 初回の一括同期と、その後の差分同期で性質が変わります。Entraの公式な目安では、初期サイクルは対象数×0.01分から対象数×0.08分の範囲。その後は増分サイクルがアプリごとに定義された間隔で回り続けます。急ぐ場合はオンデマンドプロビジョニングで個別ユーザーを即時同期できます。反映が明らかに遅いときは、ジョブが検疫状態に落ちて頻度が1日1回まで下がっていないかを確認してください。 ## 関連記事 - [シングルサインオン（SSO）とは？4つの実現方式と実装・IdP選定を開発視点で解説](https://www.issoh.co.jp/tech/details/15821/)：SCIMと組み合わせる認証側の設計です - [SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説](https://www.issoh.co.jp/tech/details/13299/)：JITプロビジョニングの前提になる認証フローです - [プロビジョニングとは？サーバー・ユーザー・クラウドの種類と自動化(IaC)の判断まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13376/)：サーバーやクラウドを含む広義の用語整理です - [Microsoft Entra ID（旧Azure AD）とは？読み方・Azure AD/Active Directoryとの違い・機能・料金を解説【2026年版】](https://www.issoh.co.jp/tech/details/3163/)：SCIMクライアント側となるIdPの全体像です - [認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】](https://www.issoh.co.jp/column/details/13631/)：ID管理全体の中でのSCIMの位置づけです --- 出典: [SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装を解説]()（株式会社一創）