SaaSは、導入の手軽さと拡張性の高さから、多くの企業で業務基盤として欠かせない存在になっています。Microsoft 365、Google Workspace、Slack、Notion、Salesforce、freee、SmartHR、Box、Zoomなど、部門ごとに使いやすいサービスを選べる一方で、気づけば契約数が増え、誰がどのアカウントを持ち、どの権限で利用しているのか把握しにくくなるケースも少なくありません。特に情シス部門では、入退社対応、組織変更、委託先利用、部門独自のSaaS導入が重なり、管理が後追いになりがちです。
しかし、SaaSアカウント管理を放置すると、ライセンス費用の無駄だけでなく、退職者アカウントの残存、不要な管理者権限、外部共有の放置、シャドーITによる情報漏えいリスクにつながります。そこで重要になるのが、単発の棚卸しではなく、台帳整備、権限確認、ライセンス見直し、退職者処理、自動化まで含めた継続的な管理です。本記事では、SaaSが増えすぎた会社で情シス担当者が進めたいアカウント管理の見直し術を、実務の流れに沿って解説します。
SaaS管理が複雑になる理由と放置リスク
SaaS管理が複雑になる最大の理由は、導入のハードルが低いことです。従来のオンプレミスシステムであれば、サーバー調達、ネットワーク設定、保守体制などを情シスが把握しやすい構造でした。一方でSaaSは、クレジットカードや部門予算で契約でき、管理画面からすぐにユーザーを追加できます。そのため、営業部門が商談管理ツール、マーケティング部門がMAツール、開発部門がプロジェクト管理ツールを個別に導入し、情シスの台帳に載らないまま利用が広がることがあります。
加えて、SaaSごとに権限体系が異なる点も管理を難しくします。たとえば、Slackではワークスペース管理者やゲスト、Google Workspaceでは特権管理者やグループ権限、Salesforceではプロファイルや権限セット、Notionではワークスペースオーナーやページ単位の共有設定など、確認すべき項目がそれぞれ異なります。さらに、組織変更や兼務が発生すると、本来は不要になった権限が残りやすくなります。結果として「誰が管理者なのか」「どのデータにアクセスできるのか」が見えづらくなります。
放置リスクは大きく分けて、コスト、セキュリティ、監査対応の3つです。コスト面では、退職者や異動者のライセンスが残り、毎月の固定費として積み上がります。セキュリティ面では、不要な管理者権限や外部ゲストが残ることで、誤操作や不正アクセス時の影響範囲が広がります。監査対応では、アカウント発行や権限変更の根拠を説明できず、内部統制上の指摘につながる可能性があります。まずは、SaaS管理を「契約管理」ではなく「IDと権限の継続管理」と捉えることが出発点になります。
ポイント：SaaS管理の複雑さは、ツール数だけでなく、権限体系、外部共有、部門契約、退職者処理のばらつきから生まれます。まずは全体像を見える化することが重要です。
ライセンスの無駄・退職者アカウント・権限過多の見つけ方
アカウント管理の見直しで最初に効果が出やすいのは、ライセンスの無駄の把握です。SaaSの管理画面からユーザー一覧をエクスポートし、最終ログイン日時、ライセンス種別、所属部署、メールアドレス、ステータスを確認します。たとえば、3か月以上ログインしていない有料ライセンス、部門異動後も旧部署のツールを使えるユーザー、ゲスト利用で十分なのにフルライセンスを付与しているユーザーは見直し候補になります。Microsoft 365やGoogle Workspaceのようにライセンス単価が積み上がりやすいサービスでは、数十アカウントの整理だけでも年間コストに大きな差が出ます。
退職者アカウントの確認では、人事データとの突合が欠かせません。SaaS側のユーザー一覧だけを見ても、退職済みかどうか判断できない場合があります。そのため、人事マスタ、IdP、メールアカウント、主要SaaSのユーザー一覧を比較し、退職日以降も有効なアカウントが残っていないか確認します。特に注意したいのは、個人メールで招待された外部ツール、委託先に付与したアカウント、共有ID、退職前に作成されたAPIトークンです。アカウントを停止しても、個別に発行されたトークンや外部共有リンクが残るケースがあるため、棚卸し時にあわせて確認します。
権限過多を見つけるには、管理者権限、データエクスポート権限、支払い管理権限、外部共有権限、アプリ連携権限に注目します。たとえば、過去に初期設定を担当した社員が管理者のまま残っている、部門長交代後も旧責任者が承認権限を持っている、一般ユーザーが全社データをエクスポートできる、といった状態はよくあります。まずは「管理者権限を持つユーザー一覧」を作成し、業務上必要な人だけに絞り込むことが有効です。加えて、権限変更の申請履歴と承認者を確認できるようにしておくと、監査にも対応しやすくなります。
| 確認対象 | 見つけたい状態 | 対応例 |
|---|---|---|
| ライセンス | 未利用、有料プラン過剰、重複契約 | 停止、プラン変更、契約統合 |
| 退職者アカウント | 退職後も有効、外部共有リンク残存 | 無効化、所有者変更、リンク削除 |
| 権限 | 管理者過多、承認権限残存、データ閲覧範囲過大 | 最小権限化、承認者更新、定期レビュー |
シャドーITと委託先利用を含めて確認したい管理ポイント
SaaS管理では、情シスが把握している公式ツールだけでなく、シャドーITの存在も確認する必要があります。シャドーITとは、会社の承認を得ずに部門や個人が業務利用しているクラウドサービスやアプリのことです。たとえば、無料のファイル転送サービス、個人契約のチャットツール、部署独自のタスク管理ツール、外部のAI議事録サービスなどが該当します。便利さを理由に現場で広がりやすい一方、契約条件、データ保存場所、退職時の引き継ぎ、アクセス権管理が不明確になりやすい点が問題です。
シャドーITを見つけるには、ネットワークログやSSOログだけでなく、現場ヒアリングも有効です。経費精算データにSaaSの支払いがないか、ブラウザ拡張機能やOAuth連携アプリに見慣れないサービスがないか、業務マニュアルに非公式ツール名が出てこないかを確認します。ただし、発見したサービスをすぐに禁止するだけでは、現場の反発を招きます。まずは利用目的を確認し、公式ツールで代替できるのか、契約を会社管理に移せるのか、利用禁止にすべきリスクがあるのかを判断することが大切です。
委託先や外部パートナーの利用も見落とせません。開発会社、制作会社、BPOベンダー、社労士、税理士、採用代行などにSaaSアカウントを付与している場合、契約終了後もアクセスが残ると情報漏えいリスクになります。特に、外部ユーザーが共有フォルダ、プロジェクト管理ツール、ソースコード管理、顧客管理システムにアクセスできる場合は、利用期間、権限範囲、責任者、削除日を台帳化します。加えて、メールアドレスが個人アドレスになっていないか、MFAが有効か、外部共有できる範囲が必要最小限かも確認します。
注意：シャドーITや委託先アカウントは、悪意よりも「急ぎで必要だった」「前任者から引き継いだ」という理由で残りやすい領域です。責めるよりも、会社管理に戻す仕組みを作ることが現実的です。
台帳整備から棚卸し定着までの実務フロー
SaaSアカウント管理を見直す第一歩は、台帳の整備です。台帳には、SaaS名、契約部門、管理者、利用目的、契約プラン、利用人数、認証方式、管理者権限者、外部ユーザー有無、データ区分、更新日を記録します。最初から完璧な台帳を作ろうとすると進まないため、まずは主要SaaSから始めるのが現実的です。たとえば、全社利用のMicrosoft 365やGoogle Workspace、コミュニケーション系のSlackやTeams、情報共有のNotionやConfluence、顧客情報を扱うSalesforceやHubSpotなどを優先します。
次に、棚卸しの基準日と担当者を決めます。月次で退職者アカウントを確認し、四半期ごとに管理者権限と外部ユーザーを確認し、半年または年1回で契約とライセンス数を見直す、といった頻度が考えられます。棚卸し作業では、SaaS管理画面からユーザー一覧をCSVで出力し、人事マスタやIdPのユーザー情報と照合します。照合結果は「継続」「停止」「権限変更」「確認中」のようにステータス化し、部門責任者に確認を依頼すると進めやすくなります。
棚卸しを定着させるには、申請フローと連動させることが重要です。アカウント発行、権限変更、外部ユーザー招待、ライセンス追加、契約更新の申請時に、台帳へ自動または半自動で反映される仕組みを作ります。たとえば、GoogleフォームやMicrosoft Formsで申請を受け付け、承認後にチケット管理ツールへ登録し、処理完了後に台帳を更新する流れです。さらに、退職者処理では、人事からの退職予定リストをもとに、退職日前後でアカウント停止、データ引き継ぎ、所有者変更をチェックリスト化しておきます。
| 工程 | 実施内容 | 成果物 |
|---|---|---|
| 台帳整備 | 主要SaaS、管理者、契約、権限、外部利用を記録 | SaaS管理台帳 |
| 棚卸し | ユーザー一覧と人事データ、IdP情報を突合 | 停止・変更候補リスト |
| 定着化 | 申請、承認、処理、台帳更新をワークフロー化 | 運用ルールと定期レビュー手順 |
運用負荷を減らす自動化と継続改善の進め方
SaaSアカウント管理は、人手だけで継続しようとすると負荷が高くなります。そこで、まず検討したいのがIdPやSSOの活用です。Microsoft Entra ID、Okta、Google Cloud Identityなどを使い、主要SaaSへのログインを一元化すれば、入退社時のアカウント制御やMFA適用を進めやすくなります。さらに、SCIM連携に対応したSaaSであれば、ユーザー作成、属性更新、無効化を自動化できるため、退職者アカウントの残存リスクを下げられます。
次に、通知とレポートの自動化も有効です。たとえば、30日以上ログインしていない有料ユーザー、管理者権限を持つユーザー、外部ゲスト、MFA未設定ユーザーを定期的に抽出し、情シスや部門責任者に通知します。Slack、Teams、チケット管理ツール、スプレッドシートを組み合わせるだけでも、棚卸しの抜け漏れを減らせます。加えて、契約更新日の60日前に通知を出す仕組みを作れば、利用実績を確認してから更新可否やライセンス数を判断できます。
継続改善では、運用指標を決めておくことが大切です。具体的には、未使用ライセンス数、退職者アカウント残存件数、管理者権限者数、外部ユーザー数、MFA適用率、棚卸し完了率、契約更新時の削減金額などを追います。たとえば、四半期ごとに管理者権限者を見直し、不要な権限を20件削除できた場合、セキュリティリスクを下げた成果として説明できます。また、未使用ライセンスを整理して月額費用を削減できれば、経営層にも効果を伝えやすくなります。
自動化を進めるときの確認項目
- 主要SaaSがSSOやSCIMに対応しているか
- 人事マスタとIdPの属性が正しく連携できるか
- 退職日、異動日、雇用区分を自動処理に使えるか
- 外部ユーザーや委託先アカウントの期限を管理できるか
- 自動停止前にデータ所有者変更や業務影響確認を行えるか
ただし、自動化は万能ではありません。人事データの更新が遅れたり、部門独自の例外運用が残ったりすると、誤停止や権限不足が発生する可能性があります。そのため、最初は通知やレポートの自動化から始め、処理結果を人が確認しながら段階的にアカウント作成・停止へ広げると安全です。SaaS管理の目的は、単にアカウント数を減らすことではなく、必要な人が必要な権限で、安全に業務を進められる状態を保つことです。台帳、棚卸し、権限最適化、自動化を小さく回し続けることで、SaaSが増えても管理できる情シス運用に近づけます。
セキュリティ・管理のまず読むまとめ
このカテゴリを読むなら、まずこのまとめ記事から入るのがおすすめです。
コメント