「先月から営業部が新しいプロジェクト管理ツールを使い始めたらしい。マーケティング部は別のツールを先月末に契約していた。しかも両方とも、全社共通で契約している類似ツールがすでにある」

情シス担当者なら、こうした状況に心当たりがあるのではないでしょうか。部門ごとに必要なツールを独自に調達し、気づけば社内のSaaSが際限なく増えている——これがSaaSスプロールの実態です。

コスト面での無駄はもちろん、退職者アカウントの放置、データの部門間分散、セキュリティ設定の不均一といった問題も複合的に発生します。「どこから手をつければいいかわからない」と感じている情シス担当者は少なくありません。

この記事では、SaaSスプロールが発生する構造的な原因を整理したうえで、情シスが実務で取り組める具体的な対策を5つのステップで解説します。ツールを選定する際の判断基準も示しますので、自社の状況に合った対応策の検討にお役立てください。

SaaSスプロールとは何か

SaaSスプロールとは、組織内でSaaSアプリケーションが全社的な管理・統制なしに無秩序に増殖し、情シスが全容を把握できなくなっている状態のことです。「sprawl（スプロール）」はもともと都市が無計画に拡大していく現象を指す英語で、SaaSの乱立状態をこれになぞらえた言葉として使われています。

問題はツールそのものにあるのではありません。全体を見渡す視点がないまま、各部門・各個人が個別最適でSaaSを導入し続けることで生まれる状態です。現場が業務効率を求めてツールを選ぶのは自然な行動です。しかしその積み重ねが、組織全体の非効率・リスク・コスト増大につながります。

野良SaaS・重複SaaSとの関係

SaaSスプロールの文脈では、「野良SaaS」と「重複SaaS」という2つの問題が混在しています。

• 野良SaaS: IT部門の承認を経ずに導入・利用されているSaaSです。フリーミアムプランで個人が使い始めたもの、部門長の判断でまとめて契約されたもの、外部パートナーに勧められて試験導入されたまま継続されているものなどが含まれます。情シスの把握外にあるため、セキュリティ設定の確認もアクセス権管理もできません。
• 重複SaaS: 実質的に同じ機能を持つSaaSが複数部門で別々に契約されている状態です。プロジェクト管理ツールがAsana、Backlog、Jiraの3種類、ビデオ会議ツールがZoom、Teams、Webexが混在——こうした状況がこれに当たります。コストの重複だけでなく、データが分散してチーム間の連携が難しくなる問題も生じます。

SaaSスプロールは、野良SaaSと重複SaaSが複合的に存在することで深刻化します。どちらか一方だけでなく、両方の観点から実態を把握することが重要です。

関連記事：野良SaaSとは｜発生原因・3つのリスク・情シスが取るべき管理対策を解説

シャドーITとの違い

SaaSスプロールと混同されやすい概念に「シャドーIT」があります。シャドーITはIT部門が把握・管理していないIT全般を指す広い概念であり、ハードウェア（私用スマートフォン、USBメモリなど）、デスクトップアプリ、クラウドサービスすべてを含みます。

SaaSスプロールはそのうちSaaSの増殖に焦点を当てた概念です。野良SaaSはシャドーITの中のSaaS部分に相当します。近年はハードウェアよりもSaaS経由のリスクが急増しているため、シャドーIT対策においてもSaaSスプロールへの対応が中心的なテーマになっています。

関連記事：シャドーITとは｜リスク・検出方法・対策 完全ガイド

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

SaaSスプロールは、従業員の不注意や悪意から生まれるのではなく、組織的な構造要因から発生します。「申請ルールを徹底してください」という通達を出すだけでは根本解決になりません。原因を正確に理解することが、実効性のある対策の前提です。

原因1: SaaS導入のハードルが極端に低い

従来のオンプレミスソフトウェアは、IT部門の関与なしに導入することが現実的に難しい構造でした。しかしSaaSはメールアドレスとクレジットカードさえあれば即日利用でき、フリーミアムプランではカードすら不要な場合があります。

現場の担当者が「ちょっと試してみよう」と始めたツールが、いつの間にか部門全体に広がり、有料プランに移行している——こうした流れは、SaaSそのものの低摩擦な設計によって起こります。現場を責めることより、この構造を前提とした管理体制を作ることが現実的なアプローチです。

原因2: 部門ごとの「個別最適」志向

各部門はそれぞれの業務効率を最大化しようとします。全社共通ツールが自分たちのワークフローに合っていなければ、部門に適したツールを独自に導入することは、現場からすれば合理的な判断です。

この「個別最適」の積み重ねが「全体最適」の欠如を生みます。情シスが全社の標準ツールを整備しても、現場のニーズに応えられていなければ、水面下での別ツール導入は続きます。SaaS標準化の際に現場の意見を取り入れることが、スプロール再発の防止につながります。

原因3: SaaSの棚卸しと更新管理の仕組みがない

SaaSは契約・更新・解約のサイクルが速く、人事異動や組織再編に合わせて不要になるケースも多いです。しかし棚卸しの仕組みがなければ、使われていないライセンスへの課金が続き、退職者のアカウントが残り続けます。

年間契約で更新日が来るたびに自動更新される設定になっていると、誰も使っていないサービスに年間数十万円が流出するケースも起きます。管理の仕組みを持たない組織ほど、こうした「ゴーストライセンス」が積み上がります。

原因4: M&Aやグループ会社統合時の対応漏れ

企業の合併・買収・分社化が起きると、異なる環境で育ってきたSaaSスタックが一度に合流します。このタイミングで棚卸しと統合作業を行わないと、重複するSaaSが両社に残り続けます。また、グループ会社ごとに異なるIT管理体制を持つ企業では、ホールディングス視点でのSaaS全体把握ができていないことが多く、スプロールが深刻化しやすい環境です。

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

SaaSスプロールをそのまま放置した場合、コスト・セキュリティ・運用の3つの側面で問題が表面化します。それぞれ独立したリスクではなく、相互に連鎖して問題を複雑にする点が特徴です。

リスク1: コストの無駄と透明性の欠如

最も直接的に表れるリスクがコストです。使われていないライセンス（ゴーストライセンス）、同一機能の重複契約、退職者分のアカウントへの課金が積み重なります。Gartnerは、SaaSライフサイクルを集中管理・統制できていない組織は、未活用のライセンスや重複ツールにより2027年までにSaaS支出を少なくとも25%過剰に支払うと予測しています。

さらに問題なのは「コストが把握できていない」こと自体です。契約が各部門に分散していると、IT支出の全体像を把握して経営層に報告することが困難になります。予算管理の透明性を保てない状態は、次年度の予算計画にも悪影響を及ぼします。

リスク2: IDライフサイクル管理の破綻

SaaSスプロールが進むと、ID管理が急速に複雑化します。情シスが把握していないSaaSは、入社・異動・退職に合わせたアカウント管理の対象に含めることができません。

特に深刻なのが退職者アカウントの問題です。退職時に主要SaaSのアカウントを削除したとしても、IT部門が把握していない野良SaaSのアカウントはそのまま残ります。元社員がアクセス可能な状態のまま業務データが残り続けるケースは、情報漏えいリスクとして見過ごせません。

人事異動時のアクセス権変更も、把握しきれていないSaaSについては対応が漏れます。「以前の部署の権限でデータにアクセスできてしまう」という最小権限の原則違反が、広範囲にわたって発生しているケースもあります。

リスク3: セキュリティ設定の不均一とデータ分散

IT部門が関与せずに導入されたSaaSは、多要素認証（MFA）の設定状況、データの保存場所・保存期間、外部との共有設定など、セキュリティに関わる項目を情シスが確認できていません。

あるSaaSではMFAが義務化されているのに、野良SaaSでは各自の設定に任されており、パスワードのみで業務データにアクセスできてしまう——こうした設定の不均一が、攻撃者に悪用されやすい穴を生みます。データ分散の問題も深刻です。各部門が異なるSaaSにデータを保存していると、インシデント発生時に「あのデータはどのSaaSに入っていたか」という状況が生まれ、対応を大幅に遅らせます。

参考：Gartner Magic Quadrant for SaaS Management Platforms（Gartner予測の解説）

SaaSスプロール対策の5ステップ

SaaSスプロールへの対策は、一度実施すれば完了するものではなく、継続的なガバナンスを構築するプロセスです。以下の5ステップを順に進めることで、現状把握から再発防止まで体系的に対応できます。

ステップ1: 全社のSaaS利用実態を把握する（可視化）

対策の出発点は「何が使われているかを知ること」です。情シスが管理していると思っているSaaSの数と、実際に社内で使われているSaaSの数には、多くの企業で大きなギャップがあります。まずそのギャップを可視化します。

複数の調査で、情シスが把握している数を大きく上回るSaaSが社内で稼働している実態が報告されています。把握漏れの多くは、部門が個別に契約した有料SaaSやフリープランのツールです。まず実態を知ることなしに、適切な対策を打つことはできません。

可視化の4つの方法

• 方法A: 社内アンケート・ヒアリング
• 全社または部門ごとにアンケートを実施し、業務で使っているSaaSをすべて申告してもらいます。「情シスに申請してあるもの」に限定せず、「業務で使っているもの全て」と明示することが重要です。ただし、自己申告に頼るため申告漏れが出やすい方法でもあります。後述の方法と組み合わせることで精度が上がります。
• 方法B: クレジットカード・経費精算データの確認
• 法人クレジットカードや部門経費の支払い履歴を確認すると、サブスクリプション形式のSaaS契約を把握できます。特に部門経費で処理されているものや、個人立替で精算されているものは、アンケートでは見逃されやすい層です。
• 方法C: SSOログの確認
• Okta、Microsoft Entra ID（旧Azure AD）、Google WorkspaceのSSOログを確認すると、IdPを経由して認証されているSaaSの利用状況を把握できます。ただし、SSOに接続されていない野良SaaSはここには現れないため、これだけでは不十分です。
• 方法D: SaaS管理ツールによる自動検出
• SaaS管理専門のツールを使うと、ブラウザ拡張やAPIを通じて手作業では把握しにくいSaaSも自動的に検出できます。可視化の精度と網羅性を高める上で、最も効率的なアプローチです。

把握した情報を台帳に整理する

収集した情報は、以下の項目を含む台帳（スプレッドシートまたはSaaS管理ツール）に整理します。

この台帳がSaaS管理の「ソース・オブ・トゥルース（唯一の正しい情報源）」になります。最初から完璧を目指す必要はありません。まず全社のSaaSを洗い出すことを優先し、詳細情報は段階的に補完していく進め方が現実的です。

関連記事：SaaS棚卸しのやり方｜情シスが実践する手順・チェックリスト・ツール活用の完全ガイド

ステップ2: SaaSを仕分けて優先度を決める（整理・判断）

把握した全SaaSをそのまま管理し続けようとすると、工数が膨大になります。重要性とリスクに応じて仕分けを行い、対応優先度を決めます。

仕分けの4つの判断軸

• 継続（公認化）: 業務上の必要性が高く、セキュリティ要件も満たせると判断したSaaSは、情シスが正式に承認し管理対象に加えます。野良SaaSであったものも、この工程で「公認SaaS」に移行します。全社共通ツールがない機能領域を補完しているものは、部門公認ツールとして承認することが現実적です。
• 統合（重複解消）: 同一機能のSaaSが複数存在する場合、どれかに統一します。利用ユーザー数、データ移行のしやすさ、コスト、全社SSOへの接続可否などを比較して、残すものを選定します。統合にあたっては、利用部門への十分な移行期間の提供と、データ移行サポートが不可欠です。
• 廃止（解約・移行）: 利用実態がない、または代替ツールに移行可能なSaaSは解約します。ゴーストライセンスもこのタイミングで整理します。解約前にデータのエクスポートが必要なサービスは、データ保全の手順を先に確認します。
• 様子見（モニタリング）: 利用状況が不明確、または対応優先度が低いSaaSは、一定期間モニタリングして判断します。いきなり廃止すると現場の業務に支障が出るリスクがある場合は、まず利用状況を測定してから判断します。

リスクスコアで優先度を決める

すべてのSaaSに同じ優先度で対応することは現実的ではありません。以下の観点でリスクスコアを設定し、高スコアのものから対応します。

• 個人情報・機密情報を扱っているか
• 情シスが未承認のまま有料契約しているか
• 退職者・異動者のアカウントが残っている可能性があるか
• MFA・SSOが設定されていないか
• 利用部門の人数が多いか（影響範囲が大きいか）

ステップ3: SaaS導入ルール・ガバナンス体制を整備する（再発防止）

現状の問題を解消しても、新しいSaaSが同じ状況で増え続ければスプロールは再発します。SaaSスプロール対策の核心は「今後も同じ問題が起きない仕組みを作ること」にあります。

SaaS導入ポリシーの策定

SaaSの導入に関するルールを明文化し、全社に周知します。ポリシーに含めるべき主要項目は以下のとおりです。

• 導入申請が必要なSaaSの範囲（無料プランも含むか、個人利用は除くかなど）
• 申請フローと承認権限（情シスのみ承認、または部門長＋情シスなど）
• 承認基準（セキュリティ要件、データ保存場所、コスト上限など）
• 承認後の管理責任（部門管理者の設定、定期報告など）
• 違反時の対応方針

ポリシーは現場が守れる現実的な内容にすることが重要です。過度に厳格なルールは形骸化するか、現場の反感を買って水面下での導入を促進する逆効果を生みます。「報告すれば使えるケースも多い」という体験を現場に作ることが、ルール遵守のモチベーションになります。

承認フローの整備

ポリシーだけでなく、申請・承認のプロセス自体を使いやすい形で整備します。申請フォームがわかりにくい、審査期間が長すぎるといった状況は「申請を避けて勝手に使う」選択を促します。

承認フローには以下を含めます。

• 申請フォーム（SaaS名・利用目的・利用人数・費用・データ保存内容を入力）
• 標準審査期間の明示（例：営業日3日以内に回答）
• 承認後の情シス台帳への登録プロセス
• 代替ツールの提案（既存ツールで代替可能な場合の案内）

定期的な棚卸しの仕組み化

SaaS管理は一度実施すれば終わりではなく、継続的な更新が必要です。半年に一度または年に一度、全社規模の棚卸しを定期実施するスケジュールを確立します。四半期ごとに利用状況レポートを確認し、コストの増減・新規SaaSの追加・未使用ライセンスの解約を判断するサイクルも組み込みます。

定期棚卸しのタイミングとして最も有効なのは、期末・期初の予算見直し時期です。棚卸し結果を翌年度のIT予算計画に直接反映できるため、経営層への報告と予算獲得にも活用できます。

ステップ4: IDライフサイクル管理を整備する（セキュリティ強化）

SaaSスプロールによって最も深刻化するセキュリティリスクが、IDライフサイクル管理（JMLプロセス：Joiner/Mover/Leaver）の破綻です。管理対象のSaaSが増えるほど、入社・異動・退職に合わせたアカウント管理の漏れが生じやすくなります。

JMLプロセスとSaaS管理の統合

• 入社時（Joiner）: 新入社員・中途入社者のSaaSアカウントを、人事情報の登録と連動して自動的に作成・付与できる仕組みを整備します。職種・所属部門ごとに必要なSaaSのセットを事前に定義しておくことで、対応漏れを防ぎます。
• 異動時（Mover）: 部署異動・役職変更に合わせて、SaaSのアクセス権限を適切に変更します。前の部門のデータへのアクセスが残り続けることは、最小権限の原則に反します。人事システムからの変更通知をトリガーに、SaaSのアクセス権変更を自動処理できると理想的です。
• 退職時（Leaver）: 退職が確定した段階で、全管理SaaSのアカウント無効化・削除を確実に行います。退職後もアカウントが有効なまま残ることは、情報漏えいの直接的なリスクです。退職処理のチェックリストにSaaSアカウントの一覧を含め、漏れなく対応します。

SSO・SCIMによる自動化

手動でのID管理には限界があります。SaaSの数が増えるほど、人手での管理は現実的でなくなります。IDプロビジョニングの自動化には、SSOとSCIMの組み合わせが有効です。

• SSO（シングルサインオン）: Okta、Microsoft Entra ID、Google Workspaceなどのアイデンティティプロバイダー（IdP）を中心に、各SaaSへのアクセスを一元管理します。IdPで認証することで個々のSaaSのパスワード管理が不要になり、セキュリティと利便性を両立できます。
• SCIM（System for Cross-domain Identity Management）: IdPとSaaS間でユーザー情報を自動同期するプロトコルです。IdPでユーザーを作成・変更・削除するだけで、SCIM対応のSaaSにその変更が自動的に反映されます。入社・異動・退職の処理をIdP側で行えば、連携SaaSのアカウントも自動的に追随します。

SSO・SCIMに対応していないSaaSは、個別に管理フローを作成する必要があります。この対応工数を考慮すると、新規SaaS導入の審査基準に「SSO・SCIM対応」を含めることが、長期的な管理コスト低減につながります。

関連記事：SaaSガバナンス強化方法｜情シスが構築する管理体制と実践ステップ

ステップ5: SaaS管理ツールで継続的に管理する（自動化・最適化）

ステップ1〜4をスプレッドシートと手作業で運用することは可能です。しかし、管理するSaaSが50種類を超えてくると現実的に限界が生じます。SaaS管理ツール（SMP：SaaS Management Platform）の導入で、可視化・棚卸し・ID管理の多くを自動化できます。

SaaS管理ツールの主な機能

SaaS管理ツールが持つ代表的な機能は以下のとおりです。

SaaS管理ツール選定時の5つの基準

• 基準1: SaaSの検出精度と網羅性
• SSOログだけでなく、ブラウザ拡張やAPIを通じた検出にも対応しているか確認します。SSO連携されていない野良SaaSを発見できるかどうかが、可視化の精度を大きく左右します。
• 基準2: IdPおよびITシステムとの連携
• Okta、Microsoft Entra ID、Google Workspaceなど、自社が使っているIdPとの連携深度を確認します。HRシステム（人事システム）や既存のIT資産管理ツールとの連携が可能かどうかも重要です。
• 基準3: デバイス管理との統合
• SaaS管理に加えてデバイス（PC・スマートフォン・タブレット）の管理も一元化できると、情シスの管理工数を大幅に削減できます。SaaSとデバイスを別々のツールで管理している場合、入退社時に両方の対応をそれぞれ行う必要があり、漏れが生じやすくなります。
• 基準4: 運用に必要な手間の少なさ
• 自動化の精度が高く、管理者の手作業を最小化できるか確認します。実際の運用シナリオを想定したデモを依頼し、自動化の範囲を具体的に確認することをお勧めします。
• 基準5: 自社規模・成長フェーズへの適合性
• 従業員数100名規模と1,000名規模では、必要な機能と投資対効果が異なります。現在の規模だけでなく、今後の成長を見越した拡張性も確認します。小規模での試験導入から始められるプランがあるか、ライセンス形態が柔軟かどうかも確認ポイントです。

SaaSスプロール対策にJosysを活用する

JosysはSaaSとデバイスを一元管理するITデバイス＆SaaS統合管理クラウドです。SaaSスプロール対策の観点では、以下の点で情シスの業務を直接的に支援します。

• 社内SaaSの可視化と台帳管理
• Josysは社内で使われているSaaSを自動的に検出し、ライセンス数・利用者・コスト・契約更新日などを一元的に管理できます。スプレッドシートによる手作業の台帳管理と異なり、情報が常に最新の状態に保たれます。
• 入退社・異動に連動したアカウント管理
• 人事システムやIdPとの連携を通じて、入社・異動・退職時のSaaSアカウントのプロビジョニング・デプロビジョニングを自動化できます。退職者アカウントの削除漏れを防ぎ、管理工数を大幅に削減します。
• SaaSとデバイスの統合管理
• SaaS管理だけでなく、PCやスマートフォンなどのデバイス管理も同一プラットフォームで行えます。「誰が・どのデバイスで・どのSaaSを使っているか」を一元的に把握できるため、入退社時の対応漏れも防ぎやすくなります。

SaaSスプロールの現状確認から始めたい方へ、まずJosysの機能と活用事例を資料でご確認いただけます。

Josys資料ダウンロード（無料）

SaaSスプロール対策を進める際の注意点

対策を実施する際に、事前に把握しておくべき現実的な注意点を整理します。

現場との合意形成を怠らない

SaaSスプロールの原因の多くが現場の業務ニーズから来ているため、「禁止・廃止・申請義務化」だけを押し付けると反発が生じます。現場が「このルールに従うメリットがある」と感じられるコミュニケーションが必要です。

申請ルールを設けると同時に「代替として使えるツール」を案内すること、承認スピードを上げて現場を待たせないこと、廃止するSaaSについては移行支援を提供すること、といった配慮が有効です。

一度で完璧を目指さない

全社のSaaSを一度に把握・整理・管理しようとすると、工数が膨大になり途中で止まるリスクがあります。まず特定部門から始めて手順を確立し、段階的に全社展開するアプローチのほうが現実的です。初回の棚卸しは精度より網羅性を優先し、台帳を作ることを最初のゴールにします。

生成AI系SaaSへの対応を早める

ChatGPT、Claude、Gemini、Perplexityなどの生成AIサービスを個人アカウントで業務利用するケースが広がっています。社内情報や顧客データが生成AIに入力されるリスクは、他のSaaSと比較しても影響範囲が広いため、生成AI利用ポリシーの策定を優先的に進めることをお勧めします。

関連記事：生成AIのセキュリティリスクと情シスが取るべき対策

まとめ

SaaSスプロールは、SaaSが業務インフラとして定着した現代において多くの企業が直面している構造的な課題です。個々の従業員の不注意から起きるのではなく、SaaS導入の低摩擦化と部門ごとの個別最適という組織的な力学から生まれます。

対策は5つのステップで体系的に進めることができます。

1. 全社のSaaS利用実態を可視化する
2. SaaSを仕分けて優先度を決める
3. 導入ルール・ガバナンス体制を整備する
4. IDライフサイクル管理（JMLプロセス）を整備する
5. SaaS管理ツールで継続的に管理・最適化する

重要なのは、対策を一度で完結させようとするのではなく、継続的に改善するサイクルを作ることです。棚卸し → 整理 → ルール整備 → 運用 → 次の棚卸しというサイクルを回し続けることで、SaaSスプロールの再発を防ぎながらITガバナンスの成熟度を高めていけます。

まずは現状のSaaS利用実態の把握から始めることをお勧めします。

SaaS管理の課題を具体的に相談したい方へ、Josysのデモ環境で、SaaS一元管理の操作感を実際にご確認いただけます。

デモを予約する（無料）

よくある質問

最後に、SaaSスプロール対策を検討する情シス担当者からよく寄せられる疑問を整理します。実務で判断に迷いやすいポイントをまとめました。

SaaSスプロールとシャドーITは同じですか？

厳密には異なります。シャドーITはIT部門が把握していないIT全般（ハードウェア・ソフトウェア・クラウドサービスを含む）を指す広い概念です。SaaSスプロールはその中でもSaaSアプリケーションが無秩序に増殖している状態に特化した言葉です。現代においては、シャドーITの主要な問題がSaaSスプロールに集中しているため、両者はほぼ同義で使われることも多くなっています。

SaaSスプロール対策はどこから始めればいいですか？

まず「現状把握（可視化）」から始めることをお勧めします。全社でどのSaaSが使われているかを把握しないまま対策を進めると、対応漏れが生じます。社内アンケート、クレジットカード明細の確認、SSOログの分析などを組み合わせて、まず全社のSaaSリストを作成することが最初のステップです。

フリープランのSaaSも管理対象にする必要がありますか？

はい、管理対象に含めることをお勧めします。フリープランでも、業務データが保存されるSaaSは情報漏えいリスクを持ちます。フリープランが有料プランにアップグレードされると、情シスが気づかないまま費用が発生するケースもあります。ただし、申請・承認フローを業務負荷にならない程度に簡略化することで、現場の遵守率を高めることが重要です。

SaaS管理ツールを導入するタイミングはいつですか？

スプレッドシートでの管理が現実的に運用できている間は、ツール導入を急ぐ必要はありません。管理するSaaSが50種類を超えてきた、入退社の対応が月に複数件発生している、棚卸しに多大な工数がかかっているといった状況が出てきたら、ツール導入を検討するタイミングです。解決したい課題を明確にしてから選定することが、導入後の満足度を高めます。