管理しているつもりのSaaSが、いつのまにか把握しきれない数に膨れ上がっていた。情シス担当者からそんな声を聞くことが増えています。国内企業の30.7%がすでに11個以上のSaaSを利用しており、この割合は前年から約5ポイント増えています。米国に目を向けると企業1社あたりの平均導入数は112個（BetterCloud 2024年調査）に達するという報告もあります。

問題はSaaSの数そのものではありません。誰が何を使っているか把握できない状態になっていること、これがSaaSスプロールです。スプロールとは「無秩序な拡大」を意味します。

SaaSスプロールがなぜ起きるのか、5つの根本原因とそのメカニズムを体系的に整理します。原因を正確に把握することで、場当たり的な対症療法ではなく根本からの解決が見えてきます。上長や他部門へ説明する際も、原因と対策を対応づけて整理できます。

SaaSスプロールとは何か

SaaSスプロールとは、組織内でSaaSアプリケーションが管理されないまま増殖し、IT部門が全体像を把握できなくなった状態を指します。SaaSの数が多いこと自体は問題ではなく、誰が・何を・なぜ使っているかが不明瞭になっている点が問題の核心です。

SaaSスプロールとシャドーITの違い

よく混同されますが、シャドーITとSaaSスプロールは別の概念です。シャドーITはIT部門の承認を経ずに現場が独自にツールやサービスを導入する行為であり、原因側の話です。SaaSスプロールは、そうした行動が積み重なった結果として生まれる「管理できない状態」を指します。

両者は原因と結果の関係にあります。シャドーITを放置し続けた先にSaaSスプロールが生まれると考えると整理しやすいでしょう。ただし、正規承認済みのSaaSであっても、管理が追いつかなければスプロール状態に陥る点は見落とされがちです。承認の有無に関わらず、管理の実態が問われます。

日本企業のSaaS利用実態

日本国内のSaaS利用は年々拡大しており、その実態は多くの情シス担当者が想定するよりも深刻です。スマートキャンプの「SaaSに関する調査」2024年版によると、国内企業の30.7%が11個以上のSaaSを利用しており、この割合は前年から約5ポイント増加しています。利用するSaaSの数は組織規模が大きくなるほど増える傾向があります。

管理体制の分散も看過できません。株式会社SHIFTの2025年の調査では、SaaS管理を情報システム部門にすべて一元化できている企業は22%にとどまり、残る78%は情シス以外の部門でも管理しているか、管理主体が定まっていない状態でした。割り当てたものの一度も使われていないライセンスや、契約したまま放置されたSaaSも各社で確認されています。これらの数字が、SaaSスプロールが一部の企業だけの問題ではないことを示しています。

参考：「見える・減らす・広げる」で解決する、SaaS乱立時代の統合管理

参考：SaaSの導入・管理実態アンケート調査（株式会社SHIFT）

SaaSスプロールが発生する5つの根本原因

SaaSスプロールは偶発的に起きる現象ではありません。組織構造や業務慣行に由来する5つの根本原因が複合的に重なることで、雪だるま式に拡大します。それぞれのメカニズムを理解することが、有効な対策を立てるための前提です。

原因1 ― 現場のシャドーIT導入

SaaSスプロールの代表的な入り口が、IT部門の承認を経ない現場への直接導入です。クレジットカードとメールアドレスがあれば契約が完了するSaaSが増えたことで、現場担当者がIT部門を通さずにツールを使い始めるケースが急増しています。

この行動が生まれる背景には、IT部門への申請プロセスが現場のスピードについてこられないという構造的な問題があります。「申請しても2週間待たされる」「要件が合わないとして却下されることが多い」という状況では、現場が別の道を探すのは自然な結果です。企業のIT支出のうち相当な割合がIT部門の管理外で発生しているという指摘は複数の調査機関から繰り返しなされており、シャドーITが例外的な現象ではないことを物語っています。マーケティング部門のMA、営業部門の独自SFAやBIツール、人事部門のHR向けSaaSなど、業務部門ごとの独立した導入が積み重なっていきます。

原因2 ― 部門ごとの最適化志向

シャドーITとは異なり、正規の承認を経たうえで各部門が独立してSaaSを導入するケースも、スプロールの大きな原因になります。各部門がそれぞれの業務に最適なツールを選ぼうとすること自体は合理的な判断ですが、全社的な視点を持たずに意思決定するため、他部門と同機能のSaaSが重複して導入されます。

チャットツールがSlack・Teams・Chatworkと並存していたり、プロジェクト管理ツールがAsana・Notionなど複数に分散していたりするのは、その典型です。部門横断の調整コストが高い組織では、「他部門と調整するよりも自分たちで決めた方が早い」という判断が繰り返され、気づけば全社で同機能のSaaSが乱立します。組織が大きくなるほどこの傾向は強まります。

原因3 ― IT承認プロセスの形骸化

IT部門が承認プロセスを持っていても、そのプロセスが実質的に機能していない場合にもSaaSスプロールは進行します。承認時点での確認は行われていても、導入後のライフサイクル管理（契約の継続確認・解約判断・更新管理）が仕組み化されていないケースが非常に多くあります。

フリープランで試験利用を開始し、気づかぬうちに有料プランへ移行していることも珍しくありません。また「とりあえず承認する」という形式的な審査も問題です。セキュリティリスクを十分に確認しないまま承認されたSaaSが、後になってデータ漏洩の温床になる可能性があります。承認はゴールではなく管理の入口であり、その後の継続的な監視まで含めて「承認プロセス」として設計する必要があります。

原因4 ― ライセンス・権限管理の仕組み不足

SaaSを導入した後の管理が追いついていないことも、スプロールを深刻化させる主要因です。特にライセンスと権限の管理が仕組み化されていない組織では、問題が静かに蓄積します。

特に注意したいのが退職者アカウントの削除漏れです。退職した従業員のアカウントが残ったままになっているSaaSは、不正アクセスや情報漏洩のリスクに直結します。部署異動時のアクセス権限変更が適切に行われないことで、本来見えてはいけないデータにアクセスできてしまう状況も生じます。ライセンスの観点では、誰も使っていないライセンスが契約され続けるゾンビライセンスの存在が各社で確認されています。割り当てたまま実際には使われていないSaaSライセンスが相当数にのぼるという海外調査もあり、未使用ライセンスによる無駄な支出が静かに積み上がっています。

原因5 ― M&Aや組織再編による重複サービスの発生

合併・買収・分社化・組織再編といったイベントも、SaaSスプロールの重要な発生源です。異なるSaaS環境を持つ会社同士が統合される際、それぞれのSaaSが並存したまま整理されないケースが頻繁に起きます。

買収企業がSlackを使い、被買収企業がTeamsを使っていた場合、統合後も両方が維持されるという状況です。経営統合の優先度が高い局面では、SaaSの整理は後回しにされがちです。しかし、放置する期間が長くなるほど既得権益化が進み、後から統合することが困難になります。組織再編のタイミングは、SaaSの棚卸しと最適化を実施するための絶好の機会でもあります。

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

SaaSスプロールを放置すると、コスト・セキュリティ・生産性という3つの経営リスクが同時進行します。それぞれの影響範囲と被害規模を把握することが、経営層や他部門を巻き込んで対策を進めるうえでの土台になります。

リスク1 ― 無駄なコストの拡大

SaaSスプロールが引き起こすコストの無駄は、思いのほか大きな額になります。割り当てたまま実際には使われていないライセンスが相当数にのぼるという海外調査もあり、誰も使っていないライセンスへの課金は多くの組織で発生しています。

ある米国調査では、こうした未使用ライセンスによって1社あたり約2,000万円（13万5,000ドル）が無駄になっているとも報告されています。同機能のSaaSを複数部門が別々に契約していれば、そのコストは単純に積み重なります。試用アカウントが有料プランに自動移行されていることに気づかず、数カ月分の費用を払い続けるという事例も珍しくありません。SaaS管理が一元化されていない組織では、こうしたコストの無駄を発見すること自体が困難です。各部門がバラバラに契約し、IT部門が全体を把握できていなければ、費用対効果の検証もできません。

リスク2 ― セキュリティ・コンプライアンスリスクの増大

IT部門が把握していないSaaSが増えるほど、情報漏洩・不正アクセス・コンプライアンス違反のリスクが高まります。退職者のアカウントが残ったままになれば、外部から企業データにアクセスできる状態が続きます。セキュリティ審査を経ていないSaaSに機密情報が保存されれば、データが外部事業者のサーバーに置かれることになります。

ゼロトラストセキュリティの考え方が広まるなか、SaaSスプロールはその対極に位置する状態です。個人情報を扱うSaaSが適切な審査なく使われている場合、取り扱うデータや委託・国外移転の条件によっては、個人情報保護法やGDPRへの抵触リスクも生じます。セキュリティインシデントが発生した後に「把握していなかったSaaSが原因だった」となれば、情シス部門の責任問題にもなりかねません。

リスク3 ― 情報サイロ化による生産性低下

SaaSが乱立すると、データが複数のツールに分散して情報のサイロ化が起きます。プロジェクトの情報がSlackにもNotionにもメールにもあり、どれが最新か分からないという状況は、多くの職場ですでに日常茶飯事になっています。必要な情報を探すために複数ツールをまたいで検索する時間は、積み重なれば大きな機会損失です。

データ連携が取れていないSaaS同士では、同じ情報を複数のツールに手動で入力するという二重作業も生じます。転記ミスはデータ品質の低下を招き、意思決定に使うデータの信頼性を損ないます。部門間でツールが異なれば、コミュニケーションの断絶にもつながります。

参考：SaaSスプロール：課題の理解と克服方法

自社はスプロール状態か チェックリストで確認する

SaaSスプロールは段階的に進行するため、気づいたときには深刻な状態になっているケースが少なくありません。以下の10項目で、現在の自社の状況を確認してください。

当てはまる項目の数を数えてください。

• 全社で利用しているSaaSを網羅した一覧が存在しない
• IT部門が承認していないSaaSを現場が利用していると思われる
• 同じ機能を持つSaaSが2種類以上導入されている
• 退職者のアカウントを即日削除できる仕組みがない
• SaaSのライセンス費用の詳細（誰が・何のために・何ライセンス使っているか）を確認したことがない
• SaaS導入の申請・承認ルールが明文化されていないか、形骸化している
• 定期的なSaaSの棚卸しを実施していない
• 各部門がどのSaaSを契約しているか把握していない
• 新規SaaS導入時にセキュリティ審査を行っていない
• クレジットカード払いのSaaS契約がどれだけあるか把握していない

以下の判定はあくまで自己診断の目安です。3項目以上当てはまる場合は、SaaSスプロールが進行している可能性が高い状態です。6項目以上になると、コスト・セキュリティ・生産性のいずれかで深刻な問題がすでに発生しているか、発生寸前の状態と判断できます。項目が多く当てはまるほど、次のセクションで紹介する解決策の優先度が高まります。

SaaSスプロールを根本解決する5つのアプローチ

ルールを決めるだけでも、ツールを入れるだけでも、SaaSスプロールは解消されません。発生した根本原因に対応した5つのアプローチを組み合わせることで、再発しない持続的なSaaS管理体制が構築できます。ここでは原因別に「何に手を打つべきか」の全体像を示します。実務の進め方を5ステップで詳しく知りたい場合は、対策に特化した記事もあわせてご覧ください。

アプローチ1 ― 現状の全量把握（SaaS棚卸し）

全社で利用しているSaaSを一覧化するSaaS棚卸しが、すべての解決策の出発点になります。現状を正確に把握しない限り、どの対策も的外れになりかねません。

棚卸しの手法は主に3つあります。まず部門ヒアリングです。各部門の担当者にアンケートを送り、利用しているSaaSのリストを回答してもらいます。次にクレジットカード・経費精算の明細確認。SaaSは月額課金が多いため、経理と連携して支払い明細を精査することで把握できます。大企業ではネットワーク監視ツールを活用し、社内ネットワークへのアクセスログからSaaSの利用実態を把握する方法も有効です。棚卸し台帳に含める項目としては、サービス名・契約部門・月額費用・ユーザー数・利用目的・契約更新日・管理者・セキュリティ審査状況などが挙げられます。この台帳が整備されていれば、コスト最適化とセキュリティ管理の両面で活用できます。

アプローチ2 ― 導入申請・承認プロセスの整備

シャドーITを減らすには、現場が正規ルートを使いたくなる申請フローの設計が求められます。「申請が煩雑だから抜け道を使う」という状況を生まない仕組みが前提です。

まず承認のターンアラウンドタイムを短縮することが先決です。1週間以上かかる承認フローは現場の不満を高め、シャドーIT行動を促進します。原則3営業日以内を目標に、承認基準と担当者を明確化することで対応スピードを高められます。承認カテゴリを設けて軽重をつけることも効果的です。費用が月額1万円未満・個人情報を扱わない・認証がOAuthのみという条件を満たす場合は簡易承認、機密データを扱う・大人数が使う場合はセキュリティ審査必須、といった基準を設けることで、審査の質とスピードを両立できます。

アプローチ3 ― ライフサイクル管理の仕組み化

SaaSの管理は導入時だけで終わりません。利用中・契約終了・組織変更時まで継続する必要があります。特に入退社・異動に伴うアカウント管理を自動化することで、セキュリティリスクを大幅に低減できます。

入社時には必要なSaaSのアカウント作成とアクセス権限付与を自動的に行うプロビジョニングの仕組みが理想です。退職時にはその逆のデプロビジョニングを即日実施できる体制を整えます。退職者アカウントの削除漏れがなくなれば、情報漏洩リスクを構造的に下げられます。四半期ごとにSaaSの利用状況を見直す定期棚卸しのPDCAサイクルを設けることで、ゾンビライセンスの早期発見と削減が実現します。

アプローチ4 ― コスト最適化の継続実施

棚卸しの結果をもとに、実際のコスト削減に着手します。コスト最適化は一度やれば終わりではなく、定期的に繰り返す活動です。

削減の切り口は主に3つです。未使用ライセンスの特定と削除、機能が重複しているSaaSの統廃合、そして過剰なプラン契約の適正化です。10名分のライセンスを契約しているのに実際の利用者が3名であれば、ライセンスを3名分に削減するだけで即座にコストが下がります。同機能のSaaSが複数ある場合は、どれを継続してどれを廃止するかを部門横断で判断する場が必要です。各部門が既存ツールへの愛着を持っているケースでは議論に摩擦を伴いますが、全社コストと統合管理の観点から経営判断として進めることが求められます。

アプローチ5 ― SaaS管理プラットフォームの導入による自動化

一定規模以上の組織では、手動でのSaaS管理に限界があります。SaaSの数が増えるほど、スプレッドシートや台帳での管理は破綻します。SaaS管理プラットフォームの導入が、根本解決への近道です。

SaaS管理プラットフォームは、全SaaSの可視化・申請承認ワークフローの自動化・アカウントライフサイクル管理・ライセンスコストの分析レポートなどを一元的に提供します。情シス担当者が日々手作業で行っていた管理業務の大部分を自動化できるため、ガバナンスの高い状態を少ない工数で維持できます。人手で管理できる範囲を超えた組織にとって、SaaS管理プラットフォームはオプションではなく必要インフラと言えます。

JosysによるSaaSスプロール解決の実際

JosysはSaaSとデバイスを一元管理するプラットフォームです。SaaSスプロールの根本原因に直接対応した機能を備えており、情シス担当者の管理負荷を大幅に削減します。

Josysが解決する課題と機能の対応

SaaSスプロールの5つの原因に対して、Josysは次の機能で対応します。

シャドーIT対策として、ブラウザ拡張機能を活用した未承認SaaSの検出機能があります。現場が使い始めたSaaSをリアルタイムで把握できるため、シャドーITの早期発見が可能です。部門ごとの重複管理に対しては、全SaaSの一元可視化ダッシュボードを提供します。どの部門がどのSaaSを何ライセンス契約しているかを一覧で確認でき、機能重複の発見とコスト最適化の判断に活用できます。

ライフサイクル管理として、入退社時の自動プロビジョニング・デプロビジョニング機能があります。連携済みのSaaSに対して、入社時には自動でアカウントを作成し、退職時には即日アカウントを無効化します。退職者アカウントの削除漏れを仕組みとして防止できます。ライセンスコストの最適化については、利用状況に基づくライセンス最適化レポートを提供します。誰が使っていて誰が使っていないかをデータとして把握できるため、ゾンビライセンスの削除と費用削減につなげられます。

導入前後の変化

Josys導入前の典型的な状態は、IT部門が把握しているSaaSは一部に過ぎず、部門からの問い合わせ対応・アカウント管理・ライセンス確認をすべて手作業で行っているというものです。定型作業に時間を取られ、業務改善に手が回らないという声は多くの情シス担当者から聞かれます。

Josys導入後は、全SaaSの可視化により「把握していなかったSaaS」がなくなります。入退社時のアカウント操作が自動化されることで、手作業に費やしていた時間を削減できます。ライセンスの無駄が可視化されることで、コスト削減の根拠を数値で示せるようになり、経営層への報告も容易になります。

自社への適用可否を確認したい方は、まず資料からご覧ください。

5分でわかるJosys資料をダウンロードする

参考：企業がSaaSスプロールを経験している5つの兆候（Josys公式）

‍ 参考：SaaSスプロールとは何か、その課題を克服する方法（Josys公式）

まとめ

SaaSスプロールは5つの根本原因が重なって発生します。現場のシャドーIT導入、部門ごとの最適化志向、IT承認プロセスの形骸化、ライセンス・権限管理の仕組み不足、そしてM&Aや組織再編による重複サービスの発生です。これらを放置すると、コストの無駄・セキュリティリスク・生産性低下という3つの経営リスクが同時に進行します。

表面的なSaaS削減ではなく、それぞれの原因に対応した根本解決が必要です。今日から着手できる最初の一手は、全社SaaSの棚卸しです。どのSaaSが・誰によって・何のために使われているかを一覧化するだけで、問題の全体像が見えてきます。本記事のチェックリストを確認し、当てはまる項目から優先的に手を打ってください。

一定規模以上の組織では、手動管理には限界があります。Josysのようなプラットフォームを活用したSaaS管理の自動化・一元化が、スプロールの根本解決への道筋となります。実際の課題についてJosysの担当者に相談したい方は、無料デモをご利用ください。

SaaS管理の課題を相談する（無料デモ）

参考：SaaSスプロールによる無駄なコストとセキュリティリスクを減らすには（SS1LAB）

参考：クラウド時代の管理不能リスク（KAMOME SSO）