「このツール、チームで使い始めてるんですが申請必要ですか?」

情シス担当者なら、こんな質問を受けたことが一度はあるはずです。しかも申請の連絡が来るのはまだましなほうで、実際には何も報告がないまま業務でSaaSが使われているケースが大半です。Google Workspace上で知らない連携アプリが有効になっていて初めて気づく、というのもよくある話です。

部門が自分たちの判断でSaaSを導入するのは、悪意があるわけではありません。「プロジェクト管理ツールが足りない」「このデザインツールを試してみたい」といった現場の素直なニーズから始まるケースがほとんどです。フリーミアムプランがあれば、クレジットカードも不要で即日使い始められます。

ただし、IT部門の承認を経ていないSaaSは、セキュリティ・コスト・コンプライアンスのいずれの面でも組織にとってのリスク要因になります。この状態を指す言葉が「野良SaaS」です。

野良SaaSは一部の先進的な企業だけの話ではありません。SaaSが業務インフラとして当たり前になった今、従業員500名以上の中堅企業であれば、情シスが把握していないSaaSが数十種類単位で存在していても不思議ではない状況です。

この記事では、野良SaaSの定義から発生原因・リスク・具体的な管理方法まで、情シス担当者が実務で使える形で整理します。

先に要点をまとめます。

• 野良SaaSとは、IT部門の承認を経ずに従業員や部門の判断で使われているSaaSのこと。シャドーIT全体のうち、SaaSに絞った概念にあたる
• 発生原因は従業員のモラルではなく構造にある。申請フローの遅さ・フリーミアム・リモートワーク・生成AIの普及が重なって生まれる
• リスクはセキュリティ・コスト・コンプライアンスの3方向。急所は退職者アカウントの残存と、生成AIサービスへの機密情報入力
• 対処は検出→分類・評価→ポリシー整備→モニタリングの4ステップ。禁止一辺倒では見えない場所へ潜伏するだけで解決しない
• 記事後半に、四半期の棚卸しでそのまま使える確認項目を12項目のチェックリストとして掲載している

野良SaaSとは何か

野良SaaSとは、IT部門の承認・管理を経ずに、従業員または部門の判断で導入・利用されているSaaSのことです。組織の公式なITガバナンスの管理外にあるという意味で「野良」という言葉が使われています。

シャドーITとの違いと関係性

野良SaaSを理解する上で、まず「シャドーIT」との関係を整理しておくことが重要です。

シャドーITとは、IT部門が把握・管理していないIT全般を指します。個人が持ち込んだUSBメモリ、私用スマートフォンを使った業務データのやり取り、無断インストールされたデスクトップアプリ、そして野良SaaSも含まれます。シャドーITは概念としてより広く、ハードウェア・ソフトウェア・クラウドサービスを問わず「IT部門の管理外にあるもの」全体を指す言葉です。

野良SaaSはシャドーITの一形態であり、その中でもSaaSに特化した概念です。「シャドーSaaS」と呼ばれることもありますが、意味はほぼ同義です。

関係を整理すると以下のようになります。

シャドーITという大きな概念の中に、野良SaaSが含まれる形です。近年はハードウェアのシャドーITよりもSaaS経由のリスクが増加しているため、野良SaaSへの対応が情シスにとって優先度の高い課題になっています。

シャドーIT全体の定義や分類から確認したい場合は、シャドーITとは何かを整理した記事を先に読むと全体像がつかめます。本記事は、その中でも個々のSaaS単位で起きる問題に絞って掘り下げます。管理対象が「持ち込まれた物」ではなく「契約されたサービス」になる点が、シャドーIT一般との実務上の最大の違いです。

「野良」という言葉が示す状態

野良という表現は、管理・統制が及んでいないという状態を直感的に表しています。飼い主のいない野良猫と同様に、組織の管理下に置かれていないという意味合いです。悪意を持って導入されたというわけではなく、あくまで管理状態の問題として捉えることが重要です。

野良SaaSの発生形態

野良SaaSには代表的な発生パターンがあります。

個人が無料プランで使い始めるケースは最も多い形態です。フリーミアムモデルのSaaSは登録から利用開始まで数分で完了するため、申請という発想自体が生まれにくい状況があります。

部門がまとめて有料プランを契約するケースもあります。予算執行の権限がある部門長が、利便性を優先してIT部門への相談なしに契約を進めてしまうパターンです。

個人クレジットカードで支払いが行われているケースは、経費精算の申請で初めて発覚することがあります。この場合、IT部門が気づくまでに相当な時間がかかることがほとんどです。

野良システム・野良クラウド・野良アカウントとの違い

「野良」を冠する言葉は複数あり、実務では混同されがちです。指している対象を先に整理しておくと、社内で議論するときの認識ズレを防げます。

• 野良システム: 部門が独自に開発・運用しているシステム全般。Excelマクロ、Accessで作った台帳、業務委託先に作らせた小規模なWebアプリなど、自作物やオンプレミス環境も含まれます
• 野良クラウド: IT部門の管理外で使われているクラウドサービス全般。SaaSに加え、個人アカウントで立てたIaaS/PaaS環境（検証用のサーバーなど）も含まれます
• 野良SaaS: 野良クラウドのうち、SaaSに限定したもの。本記事が扱う範囲です
• 野良アカウント: サービス単位ではなくアカウント単位で管理外になっているもの。承認済みSaaSの中に残っている退職者アカウントや、部門で共有されている共用アカウントが該当します

野良システムは「作ってしまったもの」、野良SaaSと野良クラウドは「契約してしまったもの」、野良アカウントは「消し忘れたもの」と捉えると区別しやすくなります。

対処の順番としては、野良SaaSから着手する組織が多くなります。自作システムは作れる人が限られる一方、SaaSはブラウザとメールアドレスさえあれば誰でも増やせるため、放置したときの増え方が最も速いためです。IaaS/PaaSまで含めた広い範囲を確認したい場合は、野良クラウドのリスクと検出方法も併せて参照してください。

野良SaaSになりやすいSaaSのカテゴリ

野良SaaSは、どのカテゴリでも均等に発生するわけではありません。野良化しやすいサービスには、無料で始められる・1人でも使える・業務データを持ち込みやすいという3つの条件が共通しています。

見落としやすいのは、SaaS本体の申請がないまま、SSO連携やOAuth連携の形で入り込むケースです。Google WorkspaceやMicrosoft 365のアカウントで「このアプリにアクセスを許可」を押した時点で、そのアプリはメール・カレンダー・ファイルの読み取り権限を持ちます。従業員の感覚ではログインボタンを押しただけですが、管理上は新しいSaaSが1種類増えたのと同じ状態です。検出のプロセスには、連携アプリの一覧確認を必ず含めてください。

野良SaaSが発生する原因

野良SaaSは従業員のモラル問題として片付けられることがありますが、実態は組織的な構造要因から生まれています。現場の担当者も悪意を持って動いているわけではなく、業務上の必要性に素直に対応しているだけであることがほとんどです。

ビジネスのスピードに申請フローが追いつかない

現代の業務環境では、新しいツールへの需要が発生してから導入までのリードタイムが問題になっています。IT部門への申請、審査、調達、展開というプロセスを経ると、数週間から数ヶ月かかることも珍しくありません。プロジェクトの締め切りが目前に迫っている状況では、現場が独自に動いてしまうのは避けがたい面があります。

フリーミアムモデルが導入の敷居を下げている

Notion、Slack、Figma、ChatGPT、Canvaといった主要なSaaSの多くは、無料で使い始められるフリーミアムプランを持っています。個人の判断で登録し、業務に組み込んでしまうまでのプロセスに一切の手続きが発生しません。SaaSの普及によって「まず試してみる」という行動が標準化した結果、申請という概念が薄れていきます。

IT部門への申請手続きが煩雑に感じられる

申請フォームの項目が多い、承認まで時間がかかる、用途を詳しく説明する必要がある、といった手続き上の摩擦も野良SaaSの温床になります。申請フローが現場のニーズに対して重すぎると感じられると、従業員は自己解決の方向に向かいます。

リモートワークの普及でIT部門の目が届きにくくなった

オフィス勤務が中心の時代であれば、IT部門が管理するネットワーク内でのアクセスログから使われているサービスを把握することもできました。しかしリモートワークの普及以降、自宅回線や個人のモバイル回線経由でSaaSが利用されるケースが増え、IT部門による把握が構造的に困難になっています。

生成AIの普及で「野良AI」という新しい問題が加わった

2023年以降のChatGPTブームを契機に、生成AI系サービスが業務に浸透しました。ChatGPT、Claude、Gemini、Perplexityなどを個人のアカウントで使い、業務上の情報や社内文書の内容を入力してしまうケースが急増しています。シャドーAIとも呼ばれるこの問題は、機密情報漏えいの観点から野良SaaSの中でも特に対応が急がれるカテゴリです。

生成AI固有のリスク構造や検出の難しさは、シャドーAIとは何かを解説した記事で詳しく扱っています。従来のSaaSと違い、業務システムに接続しないまま単体で機密情報が流出しうる点が、対応を急ぐべき理由です。

参考：テレワークにおけるセキュリティ確保（総務省）

野良SaaSが引き起こすリスク

野良SaaSが存在すること自体が直ちに問題を引き起こすわけではありませんが、リスクを管理されないまま放置することで、情報漏えい・コスト超過・監査対応の失敗という三つの問題が発生しやすくなります。

セキュリティリスク

IT部門がセキュリティ評価を行っていないサービスに、業務上の機密情報が入力されるリスクは深刻です。SOC 2認定を持つかどうか、データ処理地はどこか、転送時・保存時の暗号化が適切か、といった観点での評価なしに使われているサービスは、情報の管理状態が保証されていません。

アカウント管理の問題も見逃せません。IT部門が把握していないSaaSには、個人のメールアドレスでアカウントが作成されていることが多く、退職後もアカウントが残存するリスクがあります。組織のデータにアクセスできる状態が退職後も続いている場合、インシデントにつながりかねません。

パスワードの使い回しも問題です。個人管理のアカウントでは、単純なパスワードや他サービスと同一のパスワードが設定されている可能性があります。シングルサインオン（SSO）の管理外にあるため、ID・パスワードの一元管理もできません。

ジョーシスが2026年に225社を対象に実施した調査では、99%の企業で自社に関係する認証情報がダークウェブなどに流出していることが確認されました。認証情報の流出をゼロにする前提で対策を組むのではなく、どのSaaSにどのアカウントが存在するかを把握し、不要なものを閉じておくという発想の切り替えが必要になります。IT部門が存在を知らないSaaSのアカウントは、この「閉じる」判断の対象にすら入りません。

加えて、管理外のSaaSでは多要素認証（MFA）の設定状況も確認できません。SSOとMFAという二重の防御がどちらも効いていないアカウントが社内に何個あるのかを答えられない状態は、監査でもセキュリティ評価でも指摘されやすい論点です。

コストリスク

IT部門が全体像を把握していない状況では、同一機能のSaaSが部門ごとに別々に契約されるケースが発生します。A部門はNotionを使い、B部門はConfluenceを使い、C部門はCacooを使っている、といった状態です。まとめて調達すれば得られるボリュームディスカウントの機会も失われます。

使われなくなったSaaSへの課金継続も、情シスが全体を把握していなければ発見できません。担当者が退職した後もサブスクリプションが継続している、プロジェクト終了後もチームアカウントが残っているといったケースが積み重なると、無駄なSaaSコストが相当額になります。

従業員500名以上の中堅企業では、こうした重複・無駄なSaaSコストが年間数百万円規模になることも珍しくありません。

見落とされやすいのは、承認済みSaaSの内側に紛れ込んだ余剰ライセンスです。部門が独自に席数を追加し、担当者が異動した後も戻していないケースは、契約自体は正規のSaaSであるため棚卸しの対象から漏れがちです。SaaSコストの点検は「契約しているサービスの一覧」ではなく「誰がどのサービスに実際にログインしているか」の単位で行う必要があります。

コンプライアンスリスク

J-SOX（金融商品取引法に基づく内部統制）やISMS（ISO/IEC 27001）への対応においては、IT資産の管理状況を証跡として残すことが求められます。IT部門が把握していないSaaSが存在する状況では、監査人からの問い合わせに対応できない可能性があります。

個人情報保護法の観点では、個人情報の処理を委託する先（SaaS事業者）を把握・管理する義務が委託元の企業に生じます。野良SaaSに顧客情報や従業員情報が入力されている場合、この義務を果たしていない状態になります。

サービス規約違反のリスクも存在します。多くのSaaSは企業向けプランと個人向けプランを分けており、個人プランでの業務利用を規約で禁止しているケースがあります。違反が発覚した場合、アカウント停止や法的問題に発展する可能性もゼロではありません。

監査対応で実務的に負担が大きいのは、指摘そのものよりも証跡の再構築です。「利用中のクラウドサービスの一覧と、それぞれのアクセス権保有者を提出してください」と求められたとき、野良SaaSが存在する状態では一覧の完全性を説明できません。棚卸しの結果を毎回スプレッドシートで手集計している組織では、この確認作業だけで数週間を要することもあります。日常的に台帳が最新化されている状態を作れているかどうかが、監査対応の負荷を大きく左右します。

参考：個人情報の保護に関する法律についてのガイドライン（通則編）（個人情報保護委員会）

野良SaaSの実態データ

野良SaaSがどの程度の規模で存在しているか、実態を示すデータを確認しておきます。

SaaS管理ツールベンダー各社のレポートによると、企業のIT部門が管理対象として把握しているSaaSの数と、実際に従業員が業務で使用しているSaaSの数には大きな乖離があることが示されています。IT部門が「20種類」と把握しているケースでも、実際には数倍のSaaSが利用されているという状況は珍しくありません。

従業員数が増えるほど、この乖離は大きくなる傾向があります。部門数が増え、各部門が独自の判断で動く機会が増えるためです。500名以上の中堅企業では、IT部門が公式に管理しているSaaSが数十種類であっても、実際には100種類以上のSaaSが利用されているケースが報告されています。

生成AIサービスの普及が、この問題をさらに加速させています。ChatGPTをはじめとする生成AIサービスは、2023年以降に急速に業務利用が浸透しました。多くの場合、IT部門への届け出なしに個人アカウントで利用が開始されています。

Productiv 2024年データによると、平均的なエンタープライズ企業のSaaSポートフォリオは342アプリに達しており、そのうち48%がITチームの管理外にある未管理のSaaSという状況が報告されています。情シス担当者が直面している現実を示す数字です。

これらの数字の受け止め方として重要なのは、管理外の比率がおおむね半分前後に達するという点です。棚卸しの計画を立てるときは、現在の台帳に載っている種類数の数倍が出てくる前提で工数を見積もっておくと、初回の検出結果を前に手が止まる事態を避けられます。実際に検出ツールを導入した初回スキャンでは、想定を大きく超える種類数が可視化されるケースがほとんどです。

同時に、検出された数の多さ自体を問題視しないことも重要です。数が多い状態は、現場が業務改善のために動いてきた結果でもあります。管理すべきは数ではなく、リスクの高いサービスに機密情報が置かれていないかという中身のほうです。

国内企業のクラウドサービス利用そのものの広がりについては、総務省の通信利用動向調査でも毎年の推移が公表されています。利用が一般化した分だけ、管理対象として捕捉しなければならないサービスも増えているという関係にあります。

参考：通信利用動向調査（総務省）

野良SaaSを管理・統制する方法

野良SaaSへの対応は「禁止する」だけでは機能しません。禁止だけを打ち出すと、現場との摩擦が生まれ、より見えにくい場所に潜伏するだけです。現場のニーズを理解した上で、申請・承認の仕組みを整備し、継続的に管理できる体制を作ることが重要です。

具体的には、検出・分類・ポリシー整備・モニタリングという四つのステップで進めることが有効です。

Step1: 現状の把握（検出）

まず現状を正確に把握することから始めます。把握していない問題には対処できないためです。

SaaS管理ツールのブラウザ拡張を活用すると、従業員が業務中にアクセスしているWebアプリケーションを網羅的に検出できます。IT部門が認識していなかったSaaSが大量に可視化されることが多く、最初の棚卸しでインパクトのある数字が出ることは珍しくありません。

ネットワークログの分析も有効な手段です。社内ネットワーク経由のアクセスログから、アクセス先のドメインを分析することで、どのサービスが使われているかを特定できます。ただし、リモートワーク環境では個人回線経由のアクセスは捕捉できないという限界があります。

現場へのヒアリングも並行して行うことが推奨されます。ツールでは把握しきれない使い方や、導入背景のニーズを理解するためです。禁止の文脈ではなく「把握・支援の文脈」でヒアリングすることで、現場の協力を得やすくなります。

初回の検出では、次の4つのソースを突き合わせると精度が上がります。それぞれ取りこぼす範囲が違うためです。

1. ブラウザ拡張による利用ログ: リモート環境も含めて、実際にアクセスされたWebアプリを押さえる
2. SSO・IdPのログイン履歴: SSO連携済みのSaaSと、その利用者を確定させる
3. 経費精算・請求データ: 個人クレジットカード払いや部門契約の有料SaaSを洗い出す
4. Google Workspace・Microsoft 365の連携アプリ一覧: OAuth連携で権限を持っているアプリを特定する

棚卸しの進め方をより詳しく確認したい場合は、SaaS棚卸しの手順とチェックリストを参照してください。

Step2: 分類と評価

検出されたSaaSを全て禁止するのではなく、リスクに応じて分類・評価します。

承認可能なSaaSは、セキュリティ基準を満たしており、業務上の有用性も認められるものです。こうしたSaaSは公式に承認し、適切な条件のもとで利用を継続させることが合理的です。

評価の基準としては、SOC 2 Type IIやISO 27001等のセキュリティ認証の有無、データ処理地（国内外・クラウドサーバの所在地）、個人情報保護法の観点での適切性、提供企業の信頼性といった項目が挙げられます。

評価の結果、業務上のニーズは理解できるが、リスクが高いと判断されるSaaSについては、代替ツールを提案しながら移行を促す対応が現実的です。現場のニーズを否定せず、より安全な手段を示すことで、摩擦を最小化できます。

分類の粒度は、承認・条件付き承認・非承認・禁止の4段階に落とすと運用しやすくなります。「顧客の個人情報を入力しない前提で利用可」といった条件付き承認の枠を用意しておくと、白黒の二択では判断できないサービスを保留のまま放置せずに済みます。

判断が割れやすいのは、無料プランのまま業務で使われているSaaSです。無料プランは監査ログの出力やアクセス権の管理機能が制限されていることが多く、機能面では業務要件を満たしていても、統制の観点では要件を満たさないケースがあります。この場合は「有料プランへ切り替えたうえで承認する」という判断が、現場の利便性と統制の両立につながります。

Step3: ガバナンスポリシーの整備

現状把握と評価を経た上で、ガバナンスの仕組みを整備します。

SaaS申請・承認フローを構築することが最初のステップです。申請から承認までのプロセスをシンプルに設計し、現場が「申請する気になる」レベルの手続きにすることが重要です。プロセスが重すぎると、また野良化が進みます。

承認済みSaaSのリスト（ホワイトリスト）を整備・公開することも効果的です。「どのツールは使っていいか」が明確であれば、現場が迷う場面が減ります。使用可能なSaaSのカタログをポータルサイト等で提供している企業では、自己解決率が上がる傾向があります。

禁止SaaSについても明確に定義します。生成AIサービスへの業務情報入力の禁止、個人クレジットカードでの契約禁止といったルールを、背景理由とともに説明することが徹底を促します。

ポリシーは文書を作った時点では機能しません。申請窓口・禁止事項・違反が判明したときの扱いを1枚に集約し、入社時研修と定期のリマインドで届ける経路まで設計しておく必要があります。従業員から見て「どこに何を申請すればよいか」が3クリック以内でわかる状態が目安です。

生成AIについては、SaaS全般のポリシーとは別に個別のポリシーを用意する企業が増えています。入力禁止情報の定義・利用可能なサービスの列挙・ログの扱いといった項目が必要になるため、生成AI利用ポリシーの作り方で必要項目とテンプレートを整理しています。

Step4: 継続的なモニタリング

ポリシーを整備しても、一度きりの対応では効果が持続しません。定期的な棚卸しと継続的なモニタリングの仕組みが必要です。

定期的なSaaS棚卸しは、最低でも四半期に一度実施することが推奨されます。承認済みSaaSの中でも、使われなくなったものをライセンス削減の対象として特定することもコスト管理に直結します。

新規SaaS利用のアラート設定により、未承認のSaaSが使用された時点で通知を受け取れる体制を整えると、問題の早期発見につながります。事後的に発覚するよりも、発生時点で対処できることがリスク低減において大きな差を生みます。

モニタリングを続けるうえで現実的な負荷になるのは、検出結果の一次判断です。新しく検出されたSaaSを毎回IT部門が調べ直すのではなく、承認済みリストと禁止リストに自動照合し、どちらにも該当しないものだけを人が確認する運用にすると、目視の対象を大きく圧縮できます。

もう一つ有効なのが、入退社のプロセスにSaaS棚卸しを組み込むことです。退職手続きのチェックリストに「本人が利用していたSaaSの一覧確認とアカウント停止」を入れておけば、野良アカウントの残存を発生源で止められます。棚卸しを独立したイベントとして年数回実施するより、日常の業務フローに埋め込むほうが精度は安定します。

野良SaaS棚卸しチェックリスト

四半期ごとの棚卸しでそのまま使える確認項目を整理しました。自社の状況に応じて項目を足し引きしてご利用ください。

すべてを一度に完璧に埋める必要はありません。初回は1〜4の項目だけでも、対応すべき優先度の高いリスクが見えてきます。回を重ねるごとに確認範囲を広げていくほうが、運用として定着しやすくなります。

参考：中小企業の情報セキュリティ対策ガイドライン（IPA）

JosysによるシャドーSaaS・野良SaaS管理

ジョーシスは、SaaS・デバイス・アクセス権限を一元管理するAI駆動型のアイデンティティガバナンスプラットフォームです。野良SaaSへの対応において、特にSaaS Discoveryの機能が直接的に役立ちます。

ブラウザ上のSaaS利用を可視化

ジョーシスのSaaS Discovery機能は、ブラウザ拡張機能を通じて従業員が業務中にアクセスしたWebアプリケーションを自動的に検出します。IT部門が認識していない野良SaaSを含め、ブラウザ上のSaaS利用を可視化することができます。

従来のネットワークログ分析とは異なり、リモートワーク環境でも機能する点が特徴です。自宅回線や外出先のモバイル回線経由のアクセスも捕捉できるため、現代の働き方に対応した検出が可能です。

未承認SaaSへのアラートとポリシー設定

検出されたSaaSのうち、未承認のものについては自動的にアラートが発報される仕組みを設定できます。IT部門が毎日ログを確認する手間なく、問題のある状態が発生した時点で通知を受け取ることができます。

禁止SaaSや要注意SaaSのポリシー設定も可能で、生成AIサービスなどリスクの高いカテゴリに対して優先度の高い管理を行えます。

Access Requestsによる申請フローの一本化

ジョーシスのAccess Requests機能を使うことで、従業員がSaaSの利用申請をセルフサービスで行えるポータルを構築できます。従業員側の申請の手間を減らしながら、IT部門側では承認フローを標準化できます。

「申請が面倒だから」野良化するという問題に対して、申請体験そのものを改善するアプローチです。承認済みSaaSのカタログ提供と組み合わせることで、現場が自己解決しながらガバナンスの範囲内に収まる状態を作り出せます。

一元管理ダッシュボードによるリスク可視化

ジョーシスの管理画面では、検出されたSaaSのリスクスコア、承認状況、利用者数、コスト情報を一元的に確認できます。IT部門の担当者が手作業でスプレッドシートを管理する状態から脱却し、常に最新の状態を把握できる環境を整えることができます。

国内外1,000社以上の導入実績があり、AnkerグループではITコストを75%削減、MyBestではSaaS管理コストを70%削減、Sales MarkerではIT工数を約50%削減した事例が公開されています。いずれも共通しているのは、可視化によって「使っていないもの」と「管理外にあるもの」を切り分けた点です。

参考：SaaSディスカバリー（Josys公式サイト）

参考：Ankerグループの導入事例（コスト75%削減）

参考：Sales Markerの導入事例（IT資産の可視化と運用効率化）

まとめ

野良SaaSは、現場の業務ニーズとIT管理体制のギャップから生まれる現象です。禁止だけを打ち出しても、より見えにくい場所での利用が続くだけで、根本的な解決にはなりません。

情シスとして取れる現実的なアプローチは、まず現状を正確に把握することから始まります。SaaS管理ツールを活用して全体像を可視化し、リスクベースで評価・分類した上で、現場が使いやすいガバナンスの仕組みを整備することが、野良SaaS問題を実質的に解決する道筋です。

可視化なしに管理はできません。どのSaaSが使われているかを把握することが、全ての対策の出発点です。ジョーシスのSaaS Discoveryは、その第一歩を支援するための機能として設計されています。

野良SaaS・シャドーITの可視化・管理にご関心がある情シス担当者の方は、まずは資料のダウンロードや無料デモのご相談からお気軽にお問い合わせください。

よくある質問

野良SaaSに関してよくいただく質問をまとめました。

野良SaaSとシャドーITは何が違うのですか？

シャドーITはIT部門が把握・管理していないIT全般（ハードウェア・ソフトウェア・クラウドサービスを含む）を指す広い概念です。野良SaaSはその中でもSaaS（クラウドサービス）に限定した概念で、シャドーITの一形態にあたります。「シャドーSaaS」と呼ばれることもあります。

野良SaaSと野良システムはどう違うのですか？

野良システムは、部門が独自に開発・運用しているシステム全般を指します。Excelマクロ、Accessで作成した台帳、委託先に作らせた小規模なWebアプリなど、自作物やオンプレミス環境も含まれます。野良SaaSは外部事業者が提供するクラウドサービスを無承認で契約・利用している状態です。前者は「作ってしまったもの」、後者は「契約してしまったもの」という違いがあり、対処法も異なります。野良システムは属人化の解消と引き継ぎ、野良SaaSは検出とアカウント統制が中心になります。

野良SaaSを完全に禁止することはできますか？

フリーミアムモデルが普及した現在、完全な禁止は現実的ではありません。禁止だけを打ち出すと、より見えにくい場所に潜伏するだけです。現場のニーズを理解した上で申請・承認フローを整備し、承認済みSaaSのカタログを公開して「使いやすいガバナンス」を構築することが実効性のある対策です。

野良SaaSの検出にはどんな方法がありますか？

主な検出方法は3つです。①SaaS管理ツールのブラウザ拡張で従業員がアクセスするWebアプリを自動検出する方法、②社内ネットワークのアクセスログを分析する方法、③現場へのヒアリングです。リモートワーク環境ではネットワークログだけでは把握できないため、ブラウザ拡張を活用したツールが特に有効です。

野良SaaSの棚卸しはどのくらいの頻度で行うべきですか？

最低でも四半期に一度が目安です。ただし、期末にまとめて実施する方式では、期中に増えた分の把握が遅れます。新規SaaSの検出時にアラートで通知を受け取る仕組みと、四半期ごとの棚卸しを組み合わせる形が現実的です。加えて、入退社の手続きにアカウント確認を組み込んでおくと、野良アカウントの残存を発生源で防げます。

検出のためにブラウザ拡張を配布すると従業員の抵抗はありませんか？

監視されるという受け取り方をされないよう、目的と取得範囲を事前に説明することが前提になります。実務では「業務で必要なツールを正式に使えるようにするための調査であること」「取得するのは業務利用しているサービスの情報であり、個人の閲覧履歴を評価に使うものではないこと」を明示する方法が取られます。導入時に労使での合意形成や社内規程の整備が必要になる場合もあるため、法務・人事と連携して進めてください。

野良SaaSによるセキュリティインシデントはどんな形で起きますか？

代表的なケースは、退職した従業員のアカウントが残存して組織のデータへのアクセスが継続するケース、業務上の機密情報が未評価のサービスに入力されてデータ管理外になるケース、個人パスワード使い回しによる不正アクセスの3パターンです。特に生成AI系サービスへの機密情報入力は、情報漏えいリスクとして急速に注目されています。

中小規模の企業でも野良SaaS管理は必要ですか？

従業員規模に関わらず、SaaSを業務で利用している企業であれば野良SaaSは発生します。特に従業員100〜500名規模の中堅企業では、IT担当者が少ない一方で各部門が独自に動きやすく、野良SaaSが生まれやすい環境です。J-SOXやISMSの審査対象になる前から管理体制を整えておくことが、監査対応の観点でも重要です。

Josysで野良SaaSを可視化・管理する

事例によってはIT工数を最大50%・ITコストを最大75%削減したケースがあります。（効果は個社の状況により異なります）

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

無料デモを申し込む