従業員が入社するたびに、情シス担当者はSlack・Zoom・Salesforce・Notionといった各SaaSの管理画面に個別ログインし、アカウントを一つひとつ手作業で作成する必要があります。退職時には全SaaSのアカウントを漏れなく削除しなければならず、1件の削除漏れがセキュリティインシデントに直結するリスクをはらんでいます。従業員数が500名を超え、利用SaaSが数十種類に及ぶ企業では、この作業は担当者の工数を大きく圧迫する慢性的な課題となっています。

SCIMという規格を使えば、こうした作業を自動化できます。SCIMはユーザーアカウント情報をシステム間で標準的な方法で転送するためのプロトコルであり、IDaaS（Identity as a Service）やSMP（SaaS Management Platform）が「SCIM連携」を謳う際の技術的な根拠になっています。SCIMを活用すると、人事システムで入社情報を登録するだけで、連携している全SaaSにアカウントが自動作成されます。退職処理も同様に、一元操作で全SaaSのアクセスを即時無効化できます。

先に要点を4つに整理します。

• SCIMは、IDaaSなどのID管理側から各SaaSへユーザー情報を送り、アカウントの作成・更新・削除を自動同期させるための標準規格です。最新バージョンはSCIM 2.0で、IETFのRFC 7642／7643／7644として仕様が公開されています
• 認証を担うSAMLやOIDCとは役割が異なります。SCIMで「アカウントと権限を用意する」、SAMLやOIDCで「ログインさせる」という組み合わせが、2026年時点の標準的な構成です
• SCIMを機能させるには送信元となるIDaaSが必要です。IDaaSを導入していない場合や、SCIM非対応のSaaSが残る場合はSMP（SaaS管理プラットフォーム）で補完します
• 主要SaaSの多くはSCIM 2.0に対応していますが、利用条件が上位プランに限定されているケースが多く、導入前のプラン確認が欠かせません

SCIMとは何か

SCIMは、異なるシステム間でユーザーアカウント情報を自動同期するための標準規格です。ここでは定義・目的・関連規格との違いを整理します。

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はこの問題を解決するために設計された規格であり、ユーザー情報の「共通言語」として機能します。

規格として標準化されている点が、実務上の価値につながります。SaaSごとに独自APIを叩く連携では、SaaS側がAPI仕様を変えるたびに自社の作り込みを直す必要があります。SCIM対応のSaaSであればIDaaS側の設定作業だけで連携が成立するため、対象SaaSが増えても運用の型が崩れません。

SAMLとの違い、SSOとの組み合わせ

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 7642 - SCIM: Definitions, Overview, Concepts, and Requirements 参考: RFC 7644 - System for Cross-domain Identity Management: Protocol 参考: IETF SCIMワーキンググループ

SCIMが解決する課題

SCIMが注目される背景には、SaaS時代特有のアカウント管理の煩雑さがあります。入社・退職・異動のそれぞれのシーンで発生する課題を具体的に見ていきます。

入社時のアカウント作成漏れと初動遅延

従業員が入社する際、情シス担当者はHRシステムから入社情報を受け取り、各SaaSの管理画面でアカウントを個別に作成する必要があります。利用SaaSが20種類あれば20回のログインと設定作業が発生します。この作業には数時間から半日程度かかることも珍しくなく、入社初日に業務を開始できないという初動遅延が生じやすい状況です。また、対応が複数人に分担されている場合、一部のSaaSでアカウント作成が漏れるリスクがあります。

厄介なのは、この負荷が繁忙期に集中する点です。4月や10月のように入社が重なる月は、同じ手順を人数分繰り返すあいだ他の問い合わせ対応が止まり、情シス全体の応答速度が落ちます。自動化の範囲を検討する際は、入退社時のSaaSアカウント自動化の仕組みとツール比較も併せて確認しておくと判断しやすくなります。

退職時のアカウント削除漏れによるセキュリティリスク

退職時はさらに問題が深刻です。退職者のアカウントを全SaaSから確実に削除・無効化しなければなりませんが、利用SaaSの種類が多い企業では一部のSaaSで削除漏れが発生するケースが報告されています。退職者が元の会社のSaaSアカウントにアクセスできる状態が続くことは、情報漏洩や不正アクセスのリスクに直結します。

IPA（情報処理推進機構）の「組織における内部不正防止ガイドライン」でも、退職者のアカウントとアクセス権を速やかに削除・無効化することは、内部不正を防ぐための基本的な管理項目として挙げられています。手動管理では確実性に限界があり、仕組みとしての自動化が求められます。

この論点は、認証情報の流出という角度からも重要度が上がっています。Josysが2026年に225社を対象に実施した調査では、99%の企業で自社の認証情報がダークウェブ等に流出していることが確認されました。認証情報はいずれ漏れるという前提に立つなら、防御の要は「使われる可能性のあるアカウントを残さないこと」です。具体的な進め方は退職時のアカウント削除手順で確認できます。

総務省の情報セキュリティガイドラインでも、退職者のアクセス権限管理は情報セキュリティ上の重要な管理項目として位置づけられています。手動管理では確実性に限界があり、仕組みとしての自動化が求められます。

異動時のロール・権限変更の複雑さ

部署異動や役職変更の際には、旧部門のアクセス権限を削除し、新部門の権限を付与するという二重の作業が発生します。SaaSごとに権限の概念やロール設定が異なるため、適切な権限設定には各SaaSへの深い理解が必要です。設定ミスや対応遅延により、旧部門の機密情報への継続的なアクセスが発生したり、新業務に必要なツールが使えないという問題が生じます。

実務で漏れやすいのは、権限の付与ではなく剥奪のほうです。新部門で必要な権限が足りなければ本人から申告が上がりますが、旧部門の権限が残っていても誰も困らないため指摘が入りません。その結果、在籍年数が長い従業員ほど不要な権限が積み上がる、権限の肥大化が起こります。

SCIMによる解決の全体像

SCIMを導入すると、IDaaSでユーザー情報を変更するだけで、連携している全SaaSに変更が自動反映されます。入社情報の登録から連携SaaSへのアカウント作成まで、人手を介さずに短時間で完結します。退職処理も一元操作で連携SaaSのアクセスを自動無効化でき、削除漏れリスクを大幅に低減できます（実際の反映速度や対象範囲はSaaS・IdPの同期設定に依存します）。

参考: IPA「組織における内部不正防止ガイドライン」

SCIMプロビジョニングの仕組み

SCIMがどのように動作するか、プロビジョニングの概念とフローを詳しく説明します。

プロビジョニングとデプロビジョニング

プロビジョニング（Provisioning）とは、ユーザーがシステムを利用できるようにアカウントを作成・設定することを指します。具体的には、アカウントの新規作成、初期パスワードの設定、アクセス権限の付与、所属グループへの追加などが含まれます。

デプロビジョニング（Deprovisioning）はその逆で、ユーザーのアカウントを無効化・削除し、アクセス権限を剥奪することです。退職者処理の文脈では特に重要な概念です。

JIT（Just-in-Time）プロビジョニングとの違いも押さえておきましょう。JITプロビジョニングはユーザーが初めてサービスにログインした際に自動的にアカウントを作成する仕組みです。SAMLやOIDCベースのSSOと組み合わせて使用されることが多く、「使ったときに作る」という考え方です。一方SCIMは事前にアカウントを作成・管理するため、ログイン前からアカウントの存在と権限設定が保証されています。未使用アカウントの一覧管理やデプロビジョニングの確実性という観点では、SCIMによる事前プロビジョニングのほうが管理の透明性が高い状態を維持できます。

SCIMの動作フロー

SCIMの動作は、IDプロバイダー（IdP）が主体となってSaaSに変更を伝達するプッシュ型の仕組みです。

基本的な動作フローは次のとおりです。

1. 人事システムまたは管理者がIDaaSでユーザー情報を変更する（入社登録・退職処理・情報更新など）
2. IDaaSのSCIMエンジンが変更を検知し、SCIM APIを通じて接続されているSaaSにHTTPリクエストを送信する
3. SaaS側のSCIMエンドポイントがリクエストを受け取り、ユーザーアカウントを自動的に作成・更新・削除する
4. 処理結果がIDaaSに返送され、同期状態が記録される

この仕組みにより、IDaaS側で一度操作するだけで、SCIM連携しているすべてのSaaSに変更が自動伝播します。

SCIMはREST APIを使用しており、主なHTTPメソッドとその役割は以下のとおりです。

ただし、DELETEを実装せず、activeフラグをfalseに更新する形でのみ利用停止を受け付けるSaaSもあります。この場合はアカウントが無効化されてもライセンスの割り当てが残ることがあり、コスト面の棚卸しは別途必要です。SaaSごとにどちらの実装なのかは、連携前に確認しておきたいポイントです。

SCIMで同期できる情報

SCIMで同期できるユーザー属性（スキーマ）は、RFC 7643で標準定義されています。主な同期対象は次のとおりです。

氏名（姓・名・表示名）、メールアドレス、ユーザー名、電話番号といった基本的なユーザー情報に加え、部署名、役職、所属組織（会社名）などの組織情報を同期できます。また、アカウントの有効化・無効化状態（activeフラグ）も同期対象であり、退職者処理ではこの属性をfalseに設定することでアカウントを無効化できます。

グループ情報も同期対象です。Active Directoryのグループや組織内のチーム構造をSaaS側に反映させることで、グループ単位でのアクセス権限管理が可能になります。

カスタム属性（Enterprise User Extension）を使えば、標準スキーマに含まれない独自の属性（社員番号、雇用形態、入社日など）も同期対象に追加できます。

設計時にとくに注意したいのが、同期のキーになる属性です。SCIMではuserNameが一意識別子として扱われることが多く、ここがIdP側とSaaS側で食い違うと、既存アカウントが更新されずに別アカウントが新規作成されます。運用開始前に、userNameにメールアドレスを入れるのか社員IDを入れるのかを決め、全SaaSで揃えておく必要があります。

参考: RFC 7643 - System for Cross-domain Identity Management: Core Schema

SCIM連携の前提：IDaaSが必要な理由

SCIMを活用した自動化を実現するには、SCIMの「送信元」となるシステムが必要です。その役割を担うのがIDaaS（Identity as a Service）です。

IDaaSがSCIMの制御タワーになる

SCIMはプロトコルであり、それ自体がシステムを動かすわけではありません。SCIMを使って各SaaSにユーザー情報を送信するための「制御タワー」が必要であり、その役割を担うのがIDaaS（Identity as a Service）です。

表的なIDaaSとしてはMicrosoft Entra ID（旧Azure AD）、Okta、Google Workspace（Cloud Identity）などがあります。これらのIDaaSはSCIMプロビジョニング機能を標準搭載しており、管理画面から各SaaSとのSCIM連携設定を行うことができます。

典型的な3層連携の構成は次のとおりです。

• 第1層：人事システム（SmartHR、HRMOS、カオナビ等）で入社・退職・異動情報を管理
• 第2層：IDaaS（Okta、Microsoft Entra ID等）でユーザーの一元管理とSCIM送信を担当
• 第3層：各SaaS（Slack、Zoom、Salesforce等）がSCIM受信側として自動同期を実行

人事システムとIDaaSの連携方法はSCIMとは別のAPIやCSVインポートで行われることが多く、IDaaSがユーザー情報のハブとして機能することで、個々のSaaSとの接続をSCIMで標準化できます。

この3層構成で最初に決めるべきは、どの層を「正」とするかです。人事システムを唯一の起点とし、IDaaSはそれを受けて配信する役割に限定します。この線引きが曖昧なままIDaaS側でも手動でユーザーを作れる状態を残すと、人事データに存在しないアカウントが増え、棚卸しのたびに突合作業が発生します。

IDaaSがない場合の対応：SMPの活用

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の対象外になるものが必ず残ります。SCIMで自動化できるものはSCIMで、残りはSMPのAPI連携や申請ワークフローで受け止める。この二段構えを前提に設計しておくと、一部のSaaSだけ手作業が残って結局漏れるという状態を避けられます。

参考: Microsoft Learn「Microsoft Entra ID でのアプリのユーザープロビジョニングとは」 参考: Okta Developer「SCIM の概要」

SCIM対応SaaSの確認方法と連携設定

実際にSCIM連携を進めるにあたり、対象SaaSがSCIMに対応しているかどうかを確認し、設定を進める手順を解説します。

主要SaaSのSCIM対応状況

多くの主要SaaSはSCIM 2.0に対応しています。よく利用されるSaaSの対応状況を以下に示します。

注意が必要なのは、SCIM対応がプランによって制限されているSaaSが多い点です。導入前に各SaaSの料金プランとSCIM対応要件を確認することが重要です。

上の表は2026年時点で公開されている各SaaSの管理者向けドキュメントをもとにした整理です。利用条件はプラン改定に伴って変わるため、導入判断は必ず契約中のプランと最新ドキュメントで確認してください。とくに「SSOは下位プランで使えるがSCIMは上位プランのみ」という条件設定は珍しくないため、SSOが使えているからSCIMも使えるはずという前提での見積もりは避けたほうが安全です。

SCIM対応の確認方法

対象SaaSがSCIM対応しているかどうかを確認する最も確実な方法は、そのSaaSの管理者向けドキュメントを参照することです。多くのSaaSでは「SCIM provisioning」「User provisioning」「Automatic provisioning」といったキーワードで検索すると、SCIM設定に関するドキュメントを見つけられます。

また、利用しているIDaaS（OktaやMicrosoft Entra ID）のアプリカタログを参照する方法も有効です。IdPのアプリカタログに掲載されているSaaSは、そのIdPとのSCIM連携が検証済みであることが多く、設定手順もガイドとして提供されています。

見落としがちなのが、対応している操作の範囲です。SCIM対応と書かれていても、実装は作成と更新までで、削除やグループ同期は対象外というケースがあります。棚卸しでは対象SaaSごとに次の4点を埋めていくと判断しやすくなります。

• 作成（POST）に対応しているか
• 更新（PUT／PATCH）に対応しているか
• 利用停止がDELETEなのかactive=falseなのか
• グループ同期に対応しているか、入れ子グループを展開できるか

これが埋まった時点で、SCIMだけで完結するSaaS・部分的にしか自動化できないSaaS・手作業を残すSaaSの3つに仕分けができます。

連携設定のポイントと注意事項

SCIM連携の設定は一般的に次の手順で進めます。

1. SaaS側で管理者権限によりSCIMプロビジョニングを有効化する（多くの場合、上位プランの契約が前提になります） 2. SCIMエンドポイントURL（末尾が /scim/v2 のような形式のURL）とベアラートークン（APIキー）を発行・取得する 3. IdP側で対象アプリのプロビジョニング設定画面を開き、取得したエンドポイントURLとトークンを登録して接続テストを実行する 4. 同期するユーザー属性（フィールドマッピング）を設定し、userName、emails、name.givenName／name.familyName、activeといった必須属性が両者で正しく対応しているかを確認する 5. 同期対象のスコープ（全ユーザーか特定グループか）を決める。初回は小さなテストグループに限定するほうが安全です 6. テストユーザー1名で「作成」「属性更新」「無効化」の3パターンを検証し、SaaS側に意図どおり反映されるかを確認する 7. 本番適用後はプロビジョニングログを定期的に確認し、エラーが蓄積していないかを監視する

よくあるトラブルとしては、フィールドマッピングのミスによる同期エラーが挙げられます。IdP側の属性名とSaaS側の属性名が一致していない場合、ユーザー情報が正しく反映されません。また、SaaS側の必須フィールドに値が設定されていない場合もエラーが発生します。設定後は必ずテストユーザーで動作確認を行い、本番運用前にエラーのないことを確認することが推奨されます。

運用が始まってから顕在化しやすい問題も、あらかじめ把握しておくと対処が早くなります。

• ベアラートークンの有効期限切れ：失効すると同期が止まりますが管理画面上でエラーが目立たず、後日の棚卸しで初めて気づくことがあります。期限を台帳で管理し、更新をタスク化しておく
• 一意識別子の不一致：userNameやexternalIdの設計がSaaSごとにずれていると、重複アカウントが作られます。連携開始前に既存アカウントとの突合を済ませておく
• 属性の上書き：IdPをマスタにすると、SaaS側で個別に設定していた表示名や部署情報が上書きされます。SaaS側の運用ルールと衝突しないか事前に確認する
• 同期の遅延：反映がIdPのスケジュール実行に依存する実装もあるため、退職処理のように即時性が必要な操作は手動での即時同期手段も確保しておく

いずれも、対象SaaSを一度に増やさず、影響範囲の小さいSaaSから順に本番適用することで発見しやすくなります。

参考: Microsoft Learn「SCIM を使用してユーザーとグループをプロビジョニングする」 参考: Okta Developer「SCIM プロビジョニング統合の概要」

JosysのSCIM連携による自動化

Josysは、IDaaSとのSCIM連携を活用したSaaSプロビジョニングの自動化を実現するSaaS管理プラットフォームです。

Access AutomationによるSCIM自動プロビジョニング

Josysの「Access Automation」機能は、SCIMを活用したSaaSアカウントの自動プロビジョニング・デプロビジョニングを実現します。人事システムからの入社・退職・異動情報をトリガーとして、Josysが自動的に対象SaaSのアカウント作成・削除・権限変更を実行します。

従来、情シス担当者が手作業で行っていた「入社時の各SaaS個別設定」「退職時の全SaaSアカウント削除確認」「異動時の権限変更」といった作業が、設定ルールに基づいて自動化されます。作業ミスや対応漏れのリスクを排除しつつ、担当者の工数を大幅に削減できます。

Microsoft Entra ID・Okta・Google WorkspaceとのIDaaS連携

JosysはMicrosoft Entra ID（旧Azure AD）、Okta、Google Workspace（Cloud Identity）といった主要IDaaSとのSCIM連携に対応しています。これらのIDaaSをすでに導入している企業では、Josysを連携させることで既存のアイデンティティ管理の仕組みを活かしながら、SaaS管理の自動化を追加できます。

IDaaSとJosysを組み合わせた場合、IDaaSでユーザー情報が変更される（または人事システムからIDaaSに変更が伝播する）と、Josysの連携機能を通じて、登録されている各SaaSへの操作が自動的に実行されます。情シス担当者はJosysの管理画面でプロビジョニング状況を一元的に確認できます。

350以上のSaaSへの対応と柔軟な連携設計

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）など、情シスが管理する幅広いカテゴリをカバーしています。

連携対応は31カテゴリにわたり、国内外1,000社以上に導入されています。SCIM対応SaaSと非対応SaaSが混在した状態でも、自動化の対象を一つのプラットフォームで管理できる点が、IDaaS単体での運用との違いです。

人事システムとの自動トリガー連携

Josysは主要な人事システムとの連携にも対応しています。SmartHR、HRMOS、カオナビなどのHRシステムから入退社・異動情報を受け取り、その情報をトリガーとしてプロビジョニング処理を自動実行します。

この仕組みにより、人事担当者がHRシステムで退職手続きを完了させると、情シスへの別途連絡なしに各SaaSのアカウント停止が自動実行されるフローが実現します。人事・情シスの連携コストが削減され、対応のタイムラグも解消されます。

入退社・異動の対応時間を大幅短縮

Josysを活用したSCIM自動化の導入前後の変化を整理すると次のようになります。

月に複数名の入退社・異動がある企業では、情シスの工数削減効果は非常に大きくなります。また、退職者アカウントの即時無効化によるセキュリティリスクの低減も重要な導入効果です。

導入企業ではIT関連工数を最大50%、ITコストを最大75%削減した事例が報告されています。工数削減の内訳には、入退社処理そのものの短縮に加えて、どのSaaSにアカウントが残っているか分からない状態を解消したことで棚卸しや監査対応の時間が減る効果も含まれます。

Josysの製品概要を5分で理解する資料をダウンロードする

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との連携を通じて、入退社・異動にかかる情シスの運用コストを大幅に削減します。

今すぐ着手できる優先アクションは次の3点です。

1. 利用SaaSの棚卸しとSCIM対応の仕分け：SaaSごとに作成・更新・削除・グループ同期のどこまで対応しているかを整理し、自動化できる範囲を確定させる
2. マスタの一元化：人事システムを唯一の起点と定め、IDaaS側での手動ユーザー作成を運用ルールで止める
3. 退職処理からの適用：効果とリスク低減が最も大きいデプロビジョニングを最初の対象にし、影響範囲の小さいSaaSから順に本番適用する

SCIM連携は一度設定すれば終わりではなく、SaaSの追加・プラン変更・トークン更新に合わせて維持していく運用です。まずは対象SaaSの棚卸しから着手することが、確実な第一歩になります。