SCIMプロビジョニング：なぜ多くの企業がデプロビジョニングで失敗するのか

SCIMとは何か

SCIM は「System for Cross-domain Identity Management」の略称です。これはオープン標準（スキーマはRFC 7643、プロトコルはRFC 7644で定義）であり、システム間でIDデータを移動させるためのREST APIを規定しています。主要なIdPはすべてバージョン2.0を採用しています。

その概念は、略称よりもシンプルです。IdPがクライアント、ダウンストリームのアプリケーションがサーバーとなります。IdPはユーザーやグループのリストを保持しており、そのリストに変更があった際にHTTPリクエストを送信して通知します。

SCIMは2つのリソースコレクションを定義しており、プロトコル全体がこれに基づいています：

また、ライフサイクルは通常のHTTPメソッドに対応しています：

最後から2番目の行が重要です。SCIMには、以下のことを伝えるための標準的かつ直接的な方法があります。 このユーザーのアクセス権を削除する このシグナルは、IT部門が管理するスプレッドシートではなく、人事システム（HR-fed identity）など、退職情報が記録される場所から発信されます。

SCIMはSSOではない：その違いの重要性

SSOはログイン時に次の問いに答えます： この人物は本人か？SAMLアサーションやOIDCトークンが届くと、アプリケーションがそれを検証し、セッションを開始します。

SCIMは継続的に次の問いに答えます： この人物はここに存在すべきか？これはログインの有無に関わらず、独自のスケジュールで実行されます。

この2つのギャップこそが最大の問題です。JIT（Just-in-Time）アカウント作成のみでSSOを運用していると、IdPは正面玄関を守るだけで、背後のアカウントは蓄積され続けます。IdPでユーザーを無効化すればログインは防げますが、アカウントオブジェクトは残ったままです。それに関連付けられたロールやメンバーシップ、そしてAIプラットフォームで特に問題となるAPIキーやサービストークンもそのまま保持されてしまいます。

なぜデプロビジョニングで失敗するのか

オンボーディングの失敗は目立ちますが、オフボーディングの失敗は静かに進行します。この非対称性が、これまで私たちが目にしてきたアクセスレビューにおける指摘事項のほとんどを説明しています。

本来持つべきでないアクセス権について、不満を言う人はいません。 プロビジョニングに不具合があれば、新しいエンジニアが20分以内にチャネルへ通知します。しかし、デプロビジョニングに不具合があっても、対象者はすでに退職しています。フィードバックループが存在しないため、監査人が調査するまで欠陥は放置されたままになります。

手動のオフボーディングチェックリストは形骸化します。 チェックリストは、SaaSツールが8つしかない段階で作成されます。2年後には60個に増えていても、チェックリストには8つしか記載されていないままです。

滞留時間は長くなります。 問題を表面化させる仕組みがないため、放置されたアカウントは通常数ヶ月単位で存在し続け、監査やインシデント発生時という、最も発覚してほしくないタイミングで露呈します。

AIプラットフォームにおいて、放置されたアカウントは単なるログイン情報以上の意味を持ちます。 古いユーザーレコードが、モデルプロバイダーの認証情報、MCPサーバーへのアクセス権、デプロイされたワークロード、そして長期間有効なAPIキーに紐付いている可能性があります。ブラウザセッションは自動的に期限切れになりますが、プログラムによる認証情報はそうではありません。これが、 AIゲートウェイにおけるAPI認証とRBAC が、キーベースではなくIDベースでなければならない理由です。所有者のいないキーは、誰も取り消すことのないキーとなってしまいます。

SCIMは人手を介するプロセスを排除します。退職はIdPで一度記録されるだけで、それが外部へと伝播します。

SCIM vs JIT vs 招待制：どのプロビジョニングモードを採用すべきか

TrueFoundryは3つのプロビジョニングモードをサポートしており、テナントは一度にそのうちの1つを使用します。これは、多くのチームがSCIMを検討する際に、実際には解決しようとしている意思決定です。

この表から3つのことが導き出されます。

JITは軽量版のSCIMではありません。 それはSCIMの半分、つまり「可視化される半分」に過ぎません。新しいメンバーが必要とするアカウント作成には、設定不要でうまく機能します。しかし、退職者の対応については何も行いません。もしJITを選択する理由が「オフボーディングは手動で対応するから」というものであれば、その手順を誰が責任を持って管理し、どのように監査するのかを正直に書き出してみてください。

招待制は劣った選択肢ではなく、異なる選択肢です。 IdPに登録されていないパートナー企業の契約社員に対しては、招待が適切なメカニズムです。問題は、それを本来 IdPに登録されている はずの従業員に対して使用することです。それをしてしまうと、管理者が、すでにコストを払って導入しているシステムの「手動レプリカ」として機能せざるを得なくなります。

グループ同期は、多くの人が過小評価している項目です。 ユーザー作成の自動化は、採用時の数分間の手間を省くものです。一方、グループ同期は、時間の経過とともに認可を正しく維持するためのものであり、一度限りのコストではなく継続的なコストとなります。

チームが陥りやすい間違い

SSOをプロビジョニング解除と見なすこと。 これは最もよくある間違いですが、理解できるものでもあります。IdPでユーザーを無効にすれば、新しいログインはブロックされるからです。しかし、それだけではアカウントやグループメンバーシップ、保持している認証情報は削除されません。玄関の鍵をかけることと、アカウントを閉鎖することは別物です。

同期に失敗しても通知されないグループ名。 すべてのプロビジョニングシステムには命名規則がありますが、IdPのグループ名は、その規則を知らない人によって付けられることがほとんどです。「ML Platform — Prod (EMEA)」というグループ名にはスペース、エムダッシュ、括弧が含まれており、ダウンストリームで有効なチーム名として認識されません。この失敗は静かに進行します。ユーザーは同期されてもグループは同期されず、チームが空である理由を誰かが尋ねるまで、誰もその事実に気づきません。

SCIMが個人の持つすべての権限に適用されると思い込むこと。 SCIMはユーザーとグループメンバーシップを同期しますが、特定のリソースに対してグループ外で直接付与された権限については関知しません。チームからメンバーを削除しても、直接付与された権限は残ります。「なぜこの人がまだ閲覧できるのか」という問いに対する最も一般的な回答がこれです。

SCIMトークンの管理が不適切、または保存されていないこと。 Bearerトークンは一度しか表示されません。チームはそれをIdPに貼り付けてタブを閉じ、コピーを保存し忘れることがあります。これ自体は新しいトークンを生成すれば解決しますが、古いトークンが無効になるため、IdP側も更新するまでプロビジョニングが停止してしまいます。タブを閉じる前に、必ずシークレットマネージャーに保存してください。

Want to see the lifecycle end to end?

Spin up a TrueFoundry tenant, wire up your IdP, and watch a group become a team.

Get started free

TrueFoundryにおけるSCIMプロビジョニングの仕組み

TrueFoundryは、OIDCおよびSAML v2 SSO構成の両方でSCIMをサポートしています。プロビジョニングを構成する前に、SSOが正常に動作している必要があります。SCIMのURLとトークンは、別の統合機能ではなく、SSO構成内に存在します。

ステップ 1 — SSOの構成

Platform → Settings → SSO に移動し、 Platform → Settings → SSOEnabled をオンにして、プロバイダーを選択し、 EnabledOIDC を選択します。 OIDC または SAML v2。

OIDCの場合は、クライアントID、クライアントシークレット、発行者URLを入力します。IdP側のコールバックURLは常に https://login.truefoundry.com/oauth2/callback となります。SAMLの場合は、IdPのSSO URLとX.509署名証明書を入力し、保存後に戻って以下の情報を取得します。 コールバックURL および 発行者 TrueFoundryが生成したこれらの値をIdPに貼り付けます。

後で時間を節約するためのヒント：IdPを設定する際、email、sub、groupsという名前のクレームを出力するようにしてください。これらはTrueFoundryのデフォルト値であるため、IdP側で属性をエイリアス設定しておけば、詳細設定フィールドを操作する必要がなくなります。

ステップ 2 — SCIMを有効にする

「 設定 → セキュリティとアクセス → プロビジョニング 」に移動し、 SCIMを選択します。ここには3つのプロビジョニングモードすべてが集約されており、いずれかを選択することでテナントのライフサイクルモデルが決定されます。

ステップ 3 — SCIMベースURLをコピーする

保存済みのSSO設定を展開すると、SCIM URLとその他のメタデータが表示されます。これがIdPから呼び出される値です。

ステップ4 — SCIMトークンの生成

をクリックします。 鍵アイコン SSO設定の横にある鍵アイコンをクリックして、SCIM認証トークンを生成します。

パスワードと同様に扱ってください。トークンは作成時にのみ表示されます。紛失した場合は再生成が必要となり、以前のトークンは無効になります。

ステップ5 — IdPの設定

IdPのプロビジョニング設定で、 ベースURL （IdPによっては「テナントURL」と表記されます）にSCIM URLを設定し、 認証 を「Bearer Token」に設定して、SCIMトークンを値として貼り付けます。次に、IdPでユーザーとグループを割り当て、プロビジョニングを開始します。数分以内に、ユーザーとチームがTrueFoundryに表示されます。

IdPグループがチームになる — ここが重要なポイントです

SCIMに関する解説の多くはユーザー同期で終わりますが、それは半分に過ぎません。このようなプラットフォームでSCIMを実行する理由は、 グループ同期にあります。なぜなら、グループこそが権限管理の基盤だからです。

テナントでSCIMが設定されると、IdPからプッシュされたすべてのグループが自動的にTrueFoundryのチームになります。IdPグループにメンバーを追加すればチームに参加し、削除すればチームから外れます。

同期されたチームは、他の点では通常のチームと変わりません。リソースへのアクセス権の付与、テナントレベルのロール割り当て、IDプロバイダーのクレームマッピングの設定などが可能です。

権限の割り当ては過剰になりやすいため、役割分担を明確にしてください。SCIMはチームの権限を決定するものではありません。管理者が一度、意図的にチームにロールを付与します。SCIMが自動化するのは メンバーシップであり、権限はチームに付随するため、現在のメンバーシップがそのまま現在の有効な権限セットを意味します。認可設計は一度行えば、その後の変動はIdPに任せることができます。

命名には制約があります。IdPのグループ名がそのままチーム名となるため、使用できるのは英数字、ハイフン、アンダースコアのみで、最大 36文字までとなります。プロビジョニングを有効にする前に、IdP側でグループ名を変更してください。

具体例：MLプラットフォームチームの契約社員

手動ステップを明記した、ライフサイクルの全体像です。

初回セットアップ（手動） 管理者が「ml-platform-contractors」というIdPグループを作成します（小文字、ハイフン使用、23文字で要件を満たしています）。SCIMがこれをプッシュすると、TrueFoundry上に同名のチームが作成されます。管理者はそのチームに必要な権限（関連するモデルプロバイダーアカウント、2つのMCPサーバーへのユーザーアクセス権など）のみを付与します。これで認可設計は完了です。

オンボーディング（自動） 契約社員が入社すると、人事プロビジョニングによってその社員が「ml-platform-contractors」に追加されます。SCIMがTrueFoundryユーザーを作成し、チームに追加します。社員がSSOでログインすると、チームに付与された通りのアクセス権が適用されます。チケットを発行する必要はありません。

スコープ変更（自動） 3ヶ月後、契約社員が別のプロジェクトに異動することになりました。担当者が「ml-platform-contractors」からその社員を削除し、別のグループに追加すると、SCIMが両方のチームを調整します。チームメンバーシップの変更に伴いモデルプロバイダーへのアクセス権は自動的に消失し、管理者がTrueFoundryを操作する必要はありません。

オフボーディング（自動） 契約が終了し、IdPのレコードが無効化されます。SCIMがTrueFoundryのユーザーを非アクティブに設定するため、認証フローで拒否されます。TrueFoundryのリストを確認し忘れていても、アカウントは即座に使用できなくなります。

唯一の手動作業。 その契約者に、チーム外の単一のシークレットグループなど、直接何らかの権限が付与されていた場合、その権限はIdP経由ではないため存続します。無効化によってログインはブロックされますが、権限の記録は誰かが削除するまで残ります。アクセスレビューのプロセスにこれを組み込んでください。これは、以下の全体で見られるのと同じパターンです。 エンタープライズMCPのアクセス制御：継承された権限と直接付与された権限は組み合わさるため、一方を削除してももう一方は削除されません。

Ready to make your IdP the source of truth?

Configure SSO, switch on SCIM, and let group membership drive access.

Start free on TrueFoundry

知っておくべき注意点

Entra IDおよびOktaの場合、SCIMにはSAMLが必要です。 機能マトリックスでは、SCIM全般においてSSOは「推奨」とされていますが、広く導入されている主要な2つのIdPでは、プロビジョニングガイドがSAML構成に依存しています。EntraやOktaでOIDCを設定した後にSCIMを利用しようとすると、再設定が必要になります。

テナントごとに1つのプロビジョニングモードのみ。 同じテナント内で、従業員にはSCIM、契約者には招待制というように、両方のスイッチを切り替えて運用することはできません。IdPに含まれていないユーザーを追加する必要がある場合は、 ユーザーを招待 フローを アクセス > ユーザー から利用できます。SSOユーザーに対してこれを使用する際は、 パスワードを設定するためのメールを送信 チェックボックスはオフのままにしてください。設定すべきパスワードは存在しないためです。

無効化と削除は異なる操作です。 無効化はログインをブロックするもので、SCIMによって実行されます。ユーザーの完全な削除は管理者が個別に行う操作であり、TrueFoundryでは、ユーザーがすべてのリソースおよびチームから明示的に削除されるまで、削除は許可されません。この保護機能により、権限が残っている状態でIDが削除されるのを防ぎます。

専用のプロビジョニングページはv0.143で導入されました。 以前のバージョンでは、SCIMはSSOフォーム内で設定されていました。設定値は同じですが、画面構成が異なります。

関連資料

• AIゲートウェイにおけるAPI認証とRBAC — ゲートウェイリクエストにID情報を引き継ぐ仕組み
• MCPアクセス制御：MCPゲートウェイによるAIエージェントの保護 — SCIMで作成されたチームが実際にどのような権限を持つのか
• エンタープライズ向けMCPアクセス制御 — 組織規模における直接付与と継承による権限付与の比較
• AIガバナンスフレームワーク — プロビジョニングが広範な管理体制の中で果たす役割
• MCPセキュリティ — 厳格なID管理の背後にある脅威モデル

結論

SCIMプロビジョニングは、導入時のデモ映えの良さから、オンボーディングの文脈で語られがちです。しかし、真の価値はその出口戦略にあります。退職時のアカウント削除（デプロビジョニング）は、チケットも苦情もアラートも発生しないため、見落とされがちな失敗の温床です。これを解決する唯一の恒久的な手段は、退職情報を把握している唯一のシステムから、自動的に削除処理を伝播させることです。

TrueFoundryでは、3つの設定と1つの設計判断だけでこれを実現します。SCIMを有効にし、ベースURLをコピーしてトークンを生成し、各グループのチームに許可する操作を一度定義するだけです。あとは組織図に基づいてアクセスモデルが自動的に維持され、不要になったアカウントは自動的に削除されます。これこそが、成長し続ける企業において唯一機能するオフボーディングのプロセスです。

Set up SCIM provisioning on TrueFoundry

Free to start