「社内のSaaSが増えすぎて、誰が何を使っているかもう追えない」という声は、情シス担当者の間で年々大きくなっています。スマートキャンプの2025年の調査では、SaaSを利用しているビジネスパーソン1,500人のうち33.0%が、勤務先で11種類以上のSaaSを使っていると回答しました。従業員数が多い企業ほど利用数が増える傾向も示されています。

しかし問題は種類の多さではありません。管理と統制が追いつかないまま増殖し続けていることが、コストの垂れ流し、セキュリティの穴、ガバナンスの崩壊を同時に引き起こします。

SaaSスプロールの定義、シャドーITやデータスプロールとの違い、発生原因とリスク、段階的な対策までを、情シス担当者が実践できる形で整理しました。まずは次の5つの兆候で自社の状態を確かめてください。3つ以上当てはまるなら、スプロールはすでに進んでいます。

• 全社のSaaSをリストアップできない
• 退職者のアカウントが残っているかわからない
• 同一用途のSaaSが複数部門に存在する
• 誰が承認したかわからないSaaS契約がある
• SaaS費用の総額を即答できない

それぞれの確かめ方は、後半の「自社がSaaSスプロール状態か確認する5つの兆候」で解説しています。

SaaSスプロールとは何か

SaaSスプロールとは、企業内のSaaSが全社的な管理・統制のないまま各部門の判断で無秩序に増殖し、誰が何を使っているか把握できなくなった状態です。定義を正確に理解することで、シャドーITとの混同も解消できます。

SaaSスプロールの定義

スプロールはもともと都市計画の用語で、市街地が無秩序に郊外へ広がっていく現象を指します。SaaSスプロールはこの言葉をIT管理の文脈に転用したものです。

注意すべき点は、SaaSの数が多いこと自体は問題ではないということです。50種類のSaaSを使っていても完全に管理されているならスプロールではなく、10種類でも誰も把握していなければスプロール状態に該当します。管理の欠如が本質であり、契約したことさえ知らないSaaSが存在するという状態がスプロールの核心です。

シャドーITとの違い

シャドーITはIT部門が把握していない未承認の機器・ソフトウェア・クラウドサービス全般を指す広い概念で、個人デバイスの持ち込みやUSB利用なども含まれます。

SaaSスプロールはSaaSに特化した現象で、情シスが承認した上で導入したSaaSも含む点が異なります。承認済みであっても、その後の利用状況・コスト・アカウント管理が追いついていなければスプロールの問題に含まれます。両者の関係としては、シャドーITの拡大がSaaSスプロールを加速させるという相互作用があります。

関連記事：シャドーITとは？BYODとの違い・具体例と対策

SaaSスプロールと混同されやすい関連用語

「スプロール」という言葉は、SaaS以外の文脈でも使われます。混同を避けるために、関連する用語との違いを整理しておきましょう。

• データスプロール: 組織内のデータが複数のシステム・ストレージに分散し、所在や重複を把握できなくなる状態。SaaSスプロールが進むと各SaaSにデータが散在するため、データスプロールの一因にもなります。
• クラウドスプロール: SaaSに限らず、IaaS・PaaSを含むクラウドリソース全体が管理不能に拡大する状態。SaaSスプロールはこのうちSaaS領域に着目した概念です。
• ツールスプロール: 業務ツール全般が乱立する状態を指す広い表現で、SaaSスプロールとほぼ同義で使われることもあります。

いずれも「無秩序な拡大によって全体像を把握できなくなる」という共通点があります。SaaSスプロールはその中でも、業務の中心を占めるSaaSに焦点を当てた課題です。

データスプロールとの違いと関係

データスプロールは、データが複数のシステムやストレージに分散し、どこに何があるか、どれが最新かを把握できなくなった状態です。SaaSスプロールが増えすぎたSaaSを管理できない問題であるのに対し、データスプロールは散らばったデータを管理できない問題で、前者が後者を引き起こす関係にあります。

SaaSを1つ増やすたびに、エクスポートしたCSVや共有リンク、連携先へのコピーといったデータの置き場所も増えていきます。管理台帳に「どのSaaSにどのデータが入っているか」の列を加えておくと、SaaSスプロールとデータスプロールを同じ台帳で追えます。

SaaSスプロールが発生する4つの原因

SaaSスプロールはほぼ例外なく意図せず発生します。背景にある構造的な原因を把握することが、根本的な対策への入り口になります。原因ごとの根本解決策はSaaSスプロールの原因5つと根本解決策で詳しく解説しています。

原因①　現場主導のSaaS導入

各部門の担当者がIT部門を介さずにSaaSを導入できる環境が、スプロールの最も根本的な原因です。SaaSはインターネット環境とクレジットカードがあれば即日から利用を開始できるため、営業部門が商談管理ツールを、マーケティング部門がメール配信ツールを、人事部門がHRツールを、それぞれ独自の判断で契約するケースが日常的に起きています。

業務効率化への意欲が高い現場ほどこのパターンに陥りやすいという皮肉があります。既存のツールでは不十分だと感じた担当者が試用を始め、便利だからそのまま使い続けるというごく自然な判断の積み重ねが、情シスが把握しきれない規模のスプロールを生み出します。

原因②　承認プロセスの不備

新規SaaS導入時の申請・承認フローが存在しないか、存在しても形骸化している状態が第二の原因です。フリープランで試用を始めてそのまま有料プランに移行した、チームで使い始めていつの間にか部門全体に広がったというケースでは、情シスへの届け出が行われないまま契約が確定します。

承認プロセスが厳しすぎると現場が回避行動をとり、緩すぎると何でも通ってしまいます。どちらのケースでも、情シスの関与なしにSaaSが増え続ける構造が維持されます。

原因③　組織の成長・合併・買収

組織が拡大するにつれて部門数が増え、各部門が独自のSaaSセットを持つようになります。M&Aによる組織統合は特に深刻なスプロールを引き起こします。買収先が使っていたSaaSが持ち込まれ、既存のSaaSと機能が重複するケースが多発します。

統合後の整理を先送りにしているうちに、両社のSaaSが並行稼働し続け、コストと管理負担が二重になります。組織統合のフェーズでSaaS棚卸しを計画に組み込まない場合、このリスクは特に高くなります。

原因④　退職・異動後のアカウント放置

担当者の退職や異動が発生した後も、契約や利用状況が引き継がれないまま放置されるケースが多く発生します。退職者が管理していたSaaSは担当者がいなくなった後も自動更新され続け、気づかれないまま何ヶ月も費用が発生します。このような誰も管理していないSaaSをゾンビSaaSと呼ぶことがあります。

退職者のアカウントが削除されずに残るゾンビアカウント問題も同時に発生します。コストの無駄であるだけでなく、後述するセキュリティリスクの直接的な原因になります。

SaaSスプロールが引き起こす3つのリスク

管理されないまま放置されたSaaSは、コスト・セキュリティ・ガバナンスの三方向から組織にダメージを与えます。それぞれのリスクの深刻さを確認します。

リスク①　コストの無駄（ゾンビコスト）

最も可視化しやすいリスクがコストの無駄です。未使用ライセンスへの惰性課金、同一用途のSaaSが複数部門で重複契約されているケース、担当者退職後に誰も解約しないゾンビSaaSへの支出が積み重なります。

個々の金額は少額でも、数十種類のSaaSに未使用ライセンスが少しずつ散在すると、年間では無視できない額の無駄になります。年間契約型のSaaSは自動更新のタイミングを逃すと一年分の費用が発生するため、更新前の見直しが不可欠です。適切な管理があれば避けられたコストが、管理不在によって垂れ流され続けます。コストへの影響を統計データで確かめたい方はSaaSスプロールのコスト影響と対策を参照してください。

リスク②　セキュリティの穴

退職者アカウントの放置が最大のセキュリティリスクです。SmartHRの調査では、情報システム部門の58.0%が退職者アカウントの不正利用を懸念していると回答しています。アカウントが残ったままになると、元従業員本人による不正アクセスのリスクに加え、パスワードが流出した場合に第三者が悪用する経路にもなります。

情シスが把握していないシャドーITのSaaSは、セキュリティ設定が施されていないまま業務データが流れる状態になりやすく、ISMSやGDPRなどのコンプライアンス要件を満たさないSaaSが野放しになれば監査・認証の取得にも影響が出ます。どのSaaSにどのデータが格納されているかさえ把握できなければ、インシデント発生時の影響範囲の特定も困難になります。

関連記事：SaaSセキュリティとは？基本的な考え方とリスク・対策

リスク③　ガバナンスとID管理の崩壊

誰がどのSaaSにどの権限でアクセスできるかを把握できない状態は、ITガバナンスが機能していないことを示します。SaaSスプロールが進むと各SaaSのアカウント管理が現場担当者に委ねられ、権限設定が属人化します。異動や組織変更があっても適切な権限変更が行われず、必要以上のアクセス権を持ったままの従業員が発生します。

監査対応では「全SaaS利用状況の一覧を提出してください」という要求に即座に答えられなくなります。ISMSの管理策には情報資産の目録づくりが含まれ、J-SOXのIT全般統制でもアクセス権の管理が評価されるため、SaaSの利用状況が記録されていないと審査や評価の場面で説明に困ります。

関連記事：SaaSガバナンスとは？5つの構成要素と構築4ステップ

自社がSaaSスプロール状態か確認する5つの兆候

次の5つの兆候のうち3つ以上当てはまる場合、SaaSスプロールがすでに進行していると判断できます。現状確認のチェックリストとして活用してください。

兆候① 全社のSaaSをリストアップできない

自社で今いくつのSaaSを使っているかという問いに即答できない場合、可視化が不十分です。利用中のSaaSを網羅したリストが存在しないか、存在しても最新の状態に保たれていない状態はスプロールの典型的なサインです。把握できていないSaaSは管理の対象にできません。

兆候② 退職者のアカウントが残っているかわからない

直近1年間に退職・異動した従業員のSaaSアカウントが適切に削除・変更されているかを確認できない場合、アカウント管理が機能していません。削除されているはずだという認識は、確認できていないことと同義です。ゾンビアカウントはコストとセキュリティの両面でリスクになります。

兆候③ 同一用途のSaaSが複数部門に存在する

ビデオ会議ツールが営業部門ではZoom、全社ではGoogle Meet、別の部門ではMicrosoft Teamsというように、同一用途のSaaSが複数並立しているケースはスプロールの典型例です。重複契約の整理だけでも大きなコスト削減効果が見込めますが、そのためには実態の可視化が前提になります。重複の洗い出し方は重複SaaSの見つけ方で4つの手順に分けて解説しています。

兆候④ 誰が承認したかわからないSaaS契約がある

経費精算や社内請求書を確認すると、誰がいつ承認して契約したのか追えないSaaSが出てくる場合は要注意です。情シスの承認プロセスを経ずに現場が独自に契約したSaaSが含まれている可能性が高く、セキュリティ審査なしに業務データが流れている状態を意味します。

兆候⑤ SaaS費用の総額を即答できない

毎月・毎年のSaaS関連支出の合計金額をすぐに答えられない場合、コスト管理が機能していません。部門ごとの費用も統合されておらず、IT予算全体におけるSaaSの占める割合が不明な状態は、管理に大きな改善余地があることを示しています。

SaaSスプロールを防ぐ・解消する3段階の対策

SaaSスプロールへの対応は予防・現状把握・継続管理の3段階で進めます。すでにスプロールが発生している場合は現状把握から着手し、予防の仕組みを並行して整えます。各段階の詳しい手順とツールの選び方はSaaSスプロール対策の5ステップにまとめています。

第1段階　予防（新規導入フローの整備）

スプロールを防ぐ最も確実な手段は、新規SaaSの導入に情シスが必ず関与する仕組みを作ることです。申請なしに導入を開始できる状態を放置する限り、スプロールは止まりません。

情シスへの申請を必須とする新規SaaS導入フローを策定し、どのような場合に申請が必要か、承認の基準と担当者、申請から回答までの目安期間を明文化して全社に周知します。承認フローが遅すぎると現場が回避行動をとるため、迅速な回答体制を同時に整えることが重要です。承認済みSaaSのリストを公開しておくことで、重複導入を事前に防ぐ効果もあります。試用を開始した時点でのライセンス登録を義務化すれば、フリープランから始まるSaaSも把握できます。

第2段階　現状把握（棚卸しの実施）

スプロールがすでに発生している場合、まず現状を把握することが先決です。部門ごとのヒアリング・アンケート、経費精算やクレジットカード明細からのSaaS支出の抽出、IDプロバイダーや通信ログを活用した利用サービスの検出、IT資産管理ツールによる自動スキャン、という四つの手法を組み合わせることで、シャドーITを含めた全体像に近づけます。

収集した情報はサービス名・利用部門・用途・月額または年額コスト・契約更新日・管理担当者・ライセンス数・実利用人数を必須項目として管理台帳にまとめます。棚卸し後はコスト上位のSaaSやセキュリティリスクが高いSaaSから優先的に対処します。

関連記事：SaaS棚卸しのやり方｜実査の5手順とチェックリスト

第3段階　継続管理（仕組みと自動化）

現状を把握した後は、継続的な管理サイクルを確立します。管理台帳はSaaSの追加・変更・解約のたびに更新し、四半期に1回の定期レビューを実施します。一度整えたら終わりではなく、SaaS環境の変化に合わせて常に最新の状態を保つことが前提です。

入退社連動のアカウント管理の仕組みを整えることが特に効果的です。入社時には必要なSaaSへのアカウント一括発行、退職・異動時には全SaaSのアカウント変更・削除を人事システムと連動して実行します。SaaSの数や利用者が増えて手作業での管理が回らなくなってきたら、SaaS管理プラットフォームを活用して自動検出・一元可視化・アカウント管理の自動化を実現することも選択肢になります。

関連記事：SaaS管理プラットフォーム（SaaS管理ツール）とは？機能と選び方

SaaSスプロール解消をJosysで実現する

手動での棚卸しと台帳管理は出発点として有効ですが、SaaSの数が増えるにつれて限界が来ます。Josysは、企業内の認証情報を統合管理するAI駆動のアイデンティティセキュリティ基盤です。ITデバイスとSaaSの統合管理を出発点に、スプロール解消に必要な棚卸し・アカウント管理・ライセンスの見直しを1つの画面で進められます。

スプロールの自動検出と可視化

JosysのSaaS Discoveryは、ログイン・ブラウザ活動から社内で使われているSaaSを検出し、情シスが把握していなかったSaaSを洗い出します。ヒアリングやアンケートだけに頼らずに、利用の実態をつかめます。

検出されたSaaSを管理台帳と突き合わせると、台帳に載っていなかったSaaSと、その利用者・利用頻度を確認できます。新しく使われ始めたSaaSも、次の棚卸しを待たずに把握できます。

関連記事：SaaS可視化とは｜クラウド可視化との違いと5ステップ

ゾンビアカウント・ゾンビSaaSの排除

Josysは人事情報と連携し、入社・退職・異動のタイミングに合わせて、連携しているSaaSのアカウントの付与・停止を自動で実行します。連携の対象外のSaaSは管理台帳をもとに手作業の対応漏れがないかを確認する運用と組み合わせることで、退職者のアカウントが知らないうちに残り続けるリスクを仕組みで減らせます。

SaaS Insightsの自動ライセンスレビューで使われていないライセンスを見つけて見直せるため、ゾンビSaaSへの惰性課金を止めながらコスト最適化を進められます。Josysは2021年のサービス開始以来、国内外1,000社以上に導入されており、事例によってはIT工数を最大50%削減したケースもあります。Sales Markerでは、Josysの導入によりIT工数を約50%削減しました。

事例：マイベストが把握しきれなかったSaaSを洗い出した方法

商品比較サービス「mybest」を運営する株式会社マイベスト（従業員約300名）は、専任の情シス担当者を置かず、アシスタントのアルバイトを含む3人で情シス業務を担っています。メインで稼働するSaaSは60種類程度、部署単位やスポットでの利用を含めると90〜100種類にのぼり、ヒアリングとスプレッドシートで台帳を作っても更新が追いつかない状態でした。

Josysの導入後は、定期的なヒアリングでも把握できなかったSaaSを検知できるようになりました。ある部署から新しいSaaSを使いたいと相談を受けた際に、別の部署がすでに使っているとわかり、業務フローに関わるSaaSは全社で管理すると判断できた例もあります。アカウント関連の管理にかかっていた時間は月20〜23時間から6時間に減り、約7割の削減につながりました。

参考：株式会社マイベストの導入事例｜ジョーシス

自社のSaaSスプロールの状況を確かめるところから始めたい方は、資料ダウンロードまたは無料デモをご利用ください。

5分でわかるJosys（資料ダウンロード）

無料デモを予約する

SaaSスプロールに関するよくある質問

SaaSスプロールとシャドーITはどう違いますか

シャドーITはIT部門が把握していない未承認のIT利用全般を指す広い概念で、個人デバイスやUSBなども含みます。SaaSスプロールはSaaSに特化した現象で、情シスが承認して導入したSaaSであっても、その後の管理が追いつかなければ含まれる点が異なります。シャドーITの拡大はSaaSスプロールを加速させる要因の一つです。

SaaSが何種類を超えるとスプロールと呼ばれますか

特定の種類数で線引きされるものではありません。50種類を管理できていればスプロールではなく、10種類でも誰も把握していなければスプロール状態です。本質は数ではなく、全社的な管理・統制が効いているかどうかにあります。

SaaSスプロールの対策は何から始めるべきですか

すでにスプロールが起きている場合は、現状把握（棚卸し）から着手します。前述の5つの兆候で自社の状況を確認し、3つ以上当てはまる場合はSaaS・コスト・アカウントの全体像を洗い出すことが最初の一歩です。並行して、新規導入時に情シスが関与する予防の仕組みを整えます。

データスプロールとの違いは何ですか

データスプロールはデータが複数のシステムに分散して把握できなくなる状態を指すのに対し、SaaSスプロールはSaaSそのものの増殖・管理不全を指します。SaaSスプロールが進むと各SaaSにデータが分散するため、結果としてデータスプロールを引き起こす関係にあります。

まとめ

SaaSスプロールとは、企業内のSaaSが全社的な管理・統制なしに各部門の判断で無秩序に増殖し、誰が何を使っているか把握できなくなった状態です。コストの垂れ流し、セキュリティの穴、ガバナンスの崩壊という三つのリスクが同時進行するため、問題を認識した時点で対策を始めることが重要です。

押さえておくべきポイントを三点に絞ります。

1. SaaSスプロールの本質は数の多さではなく、管理できていない状態にある
2. 発生原因は現場主導の導入・承認プロセスの不備・組織の成長・アカウント放置の四つ
3. 対策は予防・現状把握・継続管理の3段階で、スプロールが起きていれば棚卸しから始める

まず取り組むべきは、前述した5つの兆候で自社の現状を確認することです。三つ以上当てはまる場合は、棚卸しを実施して全体像の把握から始めてください。

• SaaS管理とは？機能・メリットと選び方
• SaaSスプロール対策｜情シスが実践する5ステップと解消ツール選定ガイド
• SaaSスプロールの原因5つと根本解決策
• SaaS棚卸し やり方
• SaaSガバナンスとは
• シャドーITとは

参考情報

• IBM「SaaSスプロールとは」
• SS1LAB「SaaSスプロールによる無駄なコストとセキュリティリスクを減らすには」
• TechTarget「野良SaaS増え過ぎ問題でID管理がカオス化」
• SmartHR SaaS管理実態調査
• スマートキャンプ「SaaSの利用に関する調査」2025年版｜BOXIL Magazine