「気づいたら部署の誰かが月額制のクラウドサービスを勝手に契約していた」「インシデントが起きて初めて未承認のSaaSを使っていたことが発覚した」——こうした経験を持つ情シス担当者は少なくありません。シャドーITとはは、情シスが把握・承認していないSaaSやクラウドサービスを従業員が独自に使っている状態を指し、セキュリティリスクと管理コストの両面で情シスを悩ませ続けています。

この記事では、シャドーITに直面した情シス担当者が「何から手をつければいいか」を迷わないよう、検出・リスク評価・ポリシー整備・代替手段提供・継続監視という5つのステップに整理して、具体的な実践手順を解説します。

情シスが直面するシャドーITの実態

対応策の前に、まず「今どんな状況に置かれているか」を正確に把握することが大切です。状況の把握なしに対策を設計すると、実態に合わないルールや過度な制限が生まれ、現場との摩擦だけが残るリスクがあります。

どこで・誰が・何を使っているのか

シャドーITが発生しやすい場所と、よく使われるツールのパターンを知っておくと、初動の調査が格段に効率的になります。特定の部門・ツールカテゴリに集中していることが多く、そこから調査を始めると実態把握のスピードが上がります。

よく見られるシャドーIT利用パターン:

• 営業部門：個人Dropbox・Googleドライブに顧客資料を保存、個人LINEで社外とやりとり
• マーケティング部門：個人アカウントのCanva・Notionで制作物を管理
• エンジニア：個人アカウントのGitHub・Slackで開発コードを管理
• 管理部門：無料版のChatGPTで業務文書を処理

シャドーIT リスクで詳しく解説していますが、これらのツールには情報漏洩・契約上の問題・ライセンス違反という3つのリスクが共通して存在します。特に個人アカウントで使われているサービスは、退職後もアクセスが継続するリスクがあります。

調査の初動として有効なのは「コストがかかっているSaaSを経費データから洗い出す」ことです。月額1,000〜5,000円のサブスクリプション費用は個人経費で申請されやすく、積み重なると無視できない規模になります。まず経理部門と連携して、SaaS関連の経費一覧を取得することを最初の一手とすることを推奨します。

発覚するタイミングの多くはインシデント後

シャドーITが発覚する典型的なパターンは、以下の3つです。いずれも「問題が起きてから気づく」パターンであり、対応のコストが高い状態です。

1. セキュリティインシデントの調査中: データ漏洩や不審なアクセスを調査していて、未承認ツールの使用が判明
2. 退職者のアカウント棚卸し: 退職者のSaaSアカウント一覧を整理しようとしたら、情シスが知らないサービスが大量に出てくる
3. 監査・コンプライアンス対応時: 外部監査や内部統制の確認作業でシャドーIT利用が表面化

いずれも「問題が起きてから気づく」パターンです。対応の出発点を「インシデント後の対処」から「予防的な把握・管理」に変えることが、情シスの業務を楽にする最短ルートになります。

インシデント後に発覚するシャドーITは、長期間にわたって利用されていることが多く、対応が複雑になります。データが大量に外部サービスに保存された後での発覚は、削除対応・影響範囲の特定・当事者へのヒアリングなど、多くの工数が必要です。予防的な把握を継続することで、こうした事後対応コストを削減できます。

シャドーITが生まれる根本的な理由

シャドーITは「ルールを破ろうとしている社員」が生み出すものではなく、「業務上の必要性が正規ルートで満たされない」という構造的な問題から生まれます。

よくある原因として「情シスへの申請から承認まで時間がかかりすぎる」「公式ツールが業務のニーズに合っていない」「そもそも申請方法を知らない」という3つが挙げられます。この構造を理解せずに「禁止・監視・罰則」だけで対応しようとすると、現場との信頼関係が損なわれ、より巧妙な形でシャドーITが継続されます。

参考URL: https://notepm.jp/blog/15165

シャドーIT対応の全体フロー（5ステップ）

シャドーIT対応は5つのステップで体系的に進めることができます。一度に完璧を目指すより、優先度の高いステップから着手して、段階的に精度を上げていく方が現実的です。完璧な状態を目指して着手を遅らせるより、現状から一歩進めることの方が、組織のセキュリティにとって価値があります。

ステップ概要と優先順位の考え方

‍

Step1とStep2は「今何があるかを知る」ための緊急対応フェーズです。Step3〜4は「再発を防ぐ仕組みを作る」予防フェーズ。Step5は「継続的に管理する状態を維持する」運用フェーズです。

この5ステップは1回で完了するものではなく、繰り返し実施するサイクルとして設計します。新しいSaaSは毎月登場するため、「一度やって終わり」の対応では半年後には元の状態に戻ります。継続的なサイクルとして組織に定着させることが、シャドーIT対応の本質的な目標です。

Step1｜現状の可視化――シャドーITを発見する

対応の第一歩は、「何が使われているかを知ること」です。複数の方法を組み合わせることで、より正確な実態把握ができます。どの手法も一長一短があるため、自社の環境（テレワーク比率・既存のIT基盤・予算）に合わせた組み合わせを選ぶことが重要です。

ネットワークログ・プロキシ解析

社内ネットワークを経由したアクセスについては、プロキシサーバーやファイアウォールのアクセスログが有効なデータソースになります。主要なSaaSサービスのドメインへのアクセスを集計すると、情シスが把握していないサービスが浮かび上がってくることがあります。

具体的なアプローチとしては、Webフィルタリングシステムのカテゴリ別レポートを参照し、「クラウドストレージ」「コラボレーション」「AI/機械学習」カテゴリへのアクセスを確認します。時間帯・部署別のアクセスパターンを分析し、業務外とみられる利用を特定することも有効です。またDNSログを確認し、既知のSaaSドメイン以外への継続的なアクセスを調査します。

注意点: リモートワーク環境や個人のモバイル回線経由の利用はこの方法では捕捉できません。ネットワーク監視は「会社ネットワーク経由の利用」に限定された手法であることを念頭に置いてください。テレワーク比率の高い組織では、この手法単独では実態の半分程度しか捉えられない場合があります。

経費データ・クレジットカード明細の確認

経理部門と連携して、SaaSサービス関連の支出を確認することも有効です。月額1,000〜5,000円程度のクラウドサービスは、経費精算の段階では情シスに情報が届かないまま継続されやすいためです。

確認ポイントとして、法人クレジットカードの明細で「software」「subscription」「cloud」等のキーワードを含む取引を抽出します。経費精算システムの備考欄・摘要欄に含まれるサービス名を抽出することや、部署の小口精算や仮払い精算に含まれるIT関連支出を確認することも重要です。

この手法の特徴は、ネットワークログでは捕捉できないケース（VPN未使用・個人デバイスからのアクセス）でも、費用が発生していれば発見できる点です。ただし、個人費用で負担して経費申請していないケースは見えません。

従業員アンケートによる実態調査

技術的なログ分析と並行して、匿名性を担保した従業員アンケートも有効です。「業務効率化のために自分で調べて使い始めたツールがある」という従業員は、アンケートであれば正直に回答してくれることが多くあります。

アンケート設計のポイントとして、回答の匿名性を明記し、申告が懲罰につながらないことを伝えることが最重要です。「業務で使っているクラウドサービス・AIツールを記入してください」と具体的に問うことで、漠然とした回答を防ぎます。「IT申請を出したが却下・保留になった経験がある」かどうかも聞くと、承認プロセスの問題点が見えてきます。

アンケートの回収率を高めるために、部門長経由で依頼する・回答期限を短く設定する（3〜5営業日）・回答状況を可視化する（部門別の回収率を公開するなど）といった工夫が有効です。

IDプロバイダーとSSOアプリの確認

Microsoft Entra ID（旧Azure AD）・Okta・Google Workspaceなどのアイデンティティプロバイダーを導入している場合は、SSO連携済みのアプリ一覧が「情シスが承認に関わったSaaS」の近似リストとして使えます。このリストにある一方で台帳に登録されていないSaaSが、管理の網羅性の問題を示します。

逆に、SSO未連携で使われているSaaSは、IDプロバイダーのリストには出てきません。これが「承認済みのSaaSよりリスクが高い」可能性を示す指標になります。

シャドーIT 検出 方法では、より詳細な検出手法を解説しています。

参考URL: https://admina.moneyforward.com/jp/blog/shadow-it-detection

Step2｜リスク評価――発見したツールを分類する

シャドーITが発見されたら、すべてを即座に「禁止」とするのではなく、リスクに応じた分類を行います。全件対応しようとすると情シスのリソースが枯渇するため、優先順位の明確化が重要です。

危険度スコアリングの考え方

発見したシャドーITを以下の観点でスコアリングします。スコアリングの基準を事前に文書化しておくことで、個人の判断に依存しない一貫した評価が可能になります。

合計スコアが8点以上は高優先度で対応、5〜7点は中優先度で計画的に対応、4点以下は低優先度として棚卸し対象に留める、という形で運用すると判断が属人化しにくくなります。

スコアリング以外に追加で確認すべきポイントとして、「そのSaaSのベンダーがSOC 2認証を取得しているか」「利用規約にデータの学習利用・第三者提供に関する記述があるか」の2点があります。特に生成AIサービスの場合、無料プランでは入力データがAIの学習に使われる可能性があるため、顧客情報や機密情報の入力を伴う利用は高リスクと判断します。

公認・黙認・禁止の三分類

リスク評価の結果を受けて、各ツールを3つに分類します。

公認（ホワイトリスト化）: セキュリティ要件を満たす形での正式契約に移行するか、現状利用を情シスが把握した上で承認する。低リスクかつ業務上の有用性が高いツールが対象です。公認化することで、情シスが適切なセキュリティ設定・アクセス権管理・更新日管理ができるようになります。

黙認（条件付き継続）: 即時の対応は不要だが、利用者に対して情シスへの申請を促し、次回契約更新時に正式承認プロセスを経るよう誘導する。「機密情報は入力しない」「ユーザー数を現状以上に増やさない」といった条件を設定することが多いです。

禁止（即時対応）: 個人情報・顧客機密情報を扱っているケース、または契約条件がセキュリティポリシーと明確に矛盾するケースは即時利用停止を指示する。禁止する際は代替手段を同時に案内することが、現場の反発を抑えるために重要です。

リスク評価を誰が行うか

リスク評価は情シスだけで判断するのではなく、セキュリティ担当・法務・場合によっては経営層と連携して進めることを推奨します。個人情報を扱うSaaSのリスク評価は法務の視点が必要ですし、コスト判断には経営層の意思決定が必要になる場合があります。「情シスが全部判断する」という体制だと、承認プロセスがボトルネックになり、結果的にシャドーITを促進します。

Step3｜ポリシー整備――ルールを明文化する

「なぜこれが禁止なのか」「どうすれば使えるのか」が従業員に伝らないポリシーは形骸化します。現場が実際に守れるポリシー設計が重要です。作りすぎて誰も読まないポリシーより、シンプルで実際に参照されるポリシーの方が価値があります。

AI・SaaS利用ポリシーの必須記載事項

情シス部門が策定するSaaS・AIツール利用ポリシーには、最低限以下の項目を盛り込む必要があります。

1. 目的と対象範囲: このポリシーが何のためにあり、誰に適用されるか
2. 利用申請フロー: どこに申請すれば使えるようになるか、審査の期間目安
3. ホワイトリスト（承認済みツール一覧）: 今すぐ使えるツールを明示
4. 入力禁止情報の定義: 個人情報・顧客情報・財務情報・ソースコード等の具体的カテゴリ
5. 違反時の対応フロー: 報告先・是正手順・懲罰ではなく教育主軸であることの明示
6. 定期見直しのサイクル: ポリシーがいつ更新されるか（年1回以上を推奨）

ポリシーの「違反時対応」については、懲罰的な内容にしないことが重要です。「シャドーITを使っていることを申告したら処罰される」という認識が広まると、申告を恐れた従業員が隠蔽する方向に向かい、実態把握がより困難になります。「申告してくれれば一緒に解決策を探す」という姿勢を明示することが、情シスと現場の信頼関係構築につながります。

SaaS利用ポリシーの具体的な記述例

抽象的なポリシーは守られません。具体的な記述の例として、以下のような形式が有効です。

個人アカウントのクラウドストレージに関する記述例:

「業務で作成したファイル・資料・データは、会社が契約・管理するストレージ（Box・SharePoint等）にのみ保存してください。個人アカウントのDropbox・Google Drive・iCloudへの業務データの保存は禁止します。理由は、退職後もアクセスが継続するリスクと、個人アカウントのセキュリティ設定を情シスで管理できないためです。」

生成AIサービスに関する記述例:

「生成AIサービス（ChatGPT・Claude・Gemini等）は、会社が契約する企業向けプランのみ利用可能です。無料の個人アカウントへの業務情報の入力は禁止します。特に、顧客名・顧客情報・個人情報・社外秘情報・財務情報・ソースコードを含む文書の入力は禁止します。」

現場が守れるポリシー設計のポイント

ポリシーを作っても守られなければ意味がありません。現場が守りやすいポリシーには、共通した特徴があります。

シンプルさ: A4用紙1〜2枚に収まる要点のまとめを作り、詳細は別途詳細版に誘導する構造にする。「何が禁止か」「何が許可か」「申請方法はどこか」の3点が30秒で分かる設計が理想です。

代替手段がセットになっている: 「これは禁止」だけでなく「代わりにこれを使ってください」が必ずセットで記載されている。代替手段のない禁止令は、現場の業務効率を下げるだけです。

申請の敷居が低い: フォーム1枚、返答は5営業日以内、のような具体的な基準があると現場は動きやすい。

経営層のサインがある: 情シス単独のルールより、経営者・CISOが承認した全社ポリシーにする方が現場への浸透度が上がる。経営層の名前でポリシーが配布されることで、「情シスが個人的に言っているルール」ではなく「会社のルール」として認識されます。

参考URL: https://www.lumapps.jp/blog/shadow-it/

Step4｜代替手段の提供――正規ツールへの誘導

シャドーITが発生する根本原因は、「業務に必要なツールが正規ルートで手に入らない」ことです。ポリシーを整えるだけでなく、現場のニーズを満たす公式ツールを提供することが再発防止の核心になります。禁止と代替提供は必ずセットで実施します。

ニーズを殺さない承認プロセスの短縮

承認プロセスが遅いと、待てない従業員がシャドーIT化します。承認フローの改善として有効なのは以下の3点です。

ファストトラック審査の導入: 低リスク（データを扱わない・無料・ユーザー数少）のツールは、セキュリティチェックリストへの自己回答だけで当日承認できる仕組みにする。3〜5問のチェックリストを満たせば即日承認、という運用により、低リスクなSaaSに関する情シスの審査工数を大幅に削減できます。

定期承認会議の設置: 月1回の「ツール承認デー」を設けることで、申請が積み上がらずに処理できる。申請者は「いつ結論が出るか」が分かるため、待ち時間の不透明感からくるシャドーIT化を防ぎます。

申請テンプレートの標準化: 申請者が何を書けばいいか迷わないよう、テンプレートを用意する。「何のために使うか・誰が使うか・どんなデータを扱うか」の3点を記載するだけでよいシンプルな設計が望ましい。情シスが判断に必要な情報が最初から揃っていれば、往復確認のやり取りが減り承認スピードが上がります。

部門別のよくあるニーズと対応ツール

シャドーITが発生しやすい部門と、よく見られるニーズを把握した上で、代替ツールを準備します。

代替ツールを提示する際は、「情シスが勝手に選んで押し付ける」ではなく、「現場担当者が試用した上で合意した」という形を作ることが定着率に影響します。パイロットユーザーとして現場担当者を巻き込むことを推奨します。

公式SaaS・AIツールの整備

シャドーAI対策として特に重要なのは、情シスが審査・承認した生成AIツールを正式に提供することです。無料の個人版を禁止するだけでは、従業員のニーズは消えません。

• Microsoft 365 Copilot（企業版）: 入力データがMicrosoftの学習に使われない形での企業向け契約
• ChatGPT Enterprise / Team: OpenAIの企業向けプランで入力データの学習利用をオフ設定可能
• Google Workspace 向け Gemini（企業版）: Googleのデータ処理条件を企業向けに適用

シャドーAIとはでも触れているように、AIツール特有の情報漏洩リスクは「禁止」ではなく「企業版への移行」によって解決する方向性が、現場の生産性と安全性を両立します。

移行支援のコミュニケーション設計

代替ツールを用意しただけでは、従業員は慣れたシャドーITを使い続けます。移行を促すコミュニケーション設計が必要です。

まず、移行する理由とメリットを明確に伝えます。「これが禁止だから使えなくなった」ではなく「セキュリティが強化された公式版が使えるようになった」という前向きなメッセージで伝えることが大切です。次に、移行先ツールの操作方法をレクチャーする機会を設けます。使い方が分からないまま移行を求めても、現場は動きません。30分の説明会や操作マニュアルの提供が、移行促進に効果的です。

Step5｜継続監視と定期棚卸し

一度対応を終えても、新しいシャドーITは常に生まれ続けます。「やりきった」と思った瞬間から、また蓄積が始まります。継続的な監視体制を整えることで、シャドーIT管理を持続可能なものにします。

定期棚卸しのサイクル設計

シャドーITの棚卸しは、最低でも四半期に一度実施することを推奨します。

四半期棚卸しの内容:

1. 前回調査以降に新たに利用されているSaaSの確認（ネットワークログ・経費データ）
2. 承認済みツールの利用状況確認（使われなくなったツールのライセンス削減）
3. 退職者・異動者のアカウント残存確認
4. 新しいAIツールのリスク評価と分類更新

四半期棚卸しは2〜3時間程度で完了できる軽量な作業として設計することが、継続可能な運用の鍵です。前回の台帳をベースに「差分のみを確認する」アプローチを取ることで、毎回ゼロから調査する手間を省けます。

年1回の大規模棚卸し（全SaaSの総点検・コスト最適化・ポリシー見直し）と、四半期ごとの軽量確認（新規発見・退職者対応・ライセンス確認）を組み合わせるサイクルが、多くの情シスチームに適しています。

SaaS棚卸し やり方では、SaaS棚卸しの具体的な手順を詳しく解説しています。

継続監視に必要なアラート設計

人力での定期チェックに加えて、「変化が起きた時に自動で通知される」仕組みを作ることで、次の四半期を待たずに新しいシャドーITを発見できます。

設定を推奨するアラートの例:

• ネットワークログで新規の外部SaaSドメインへの大量アクセスが発生した
• 経費データに新しいSaaS関連の支出が記録された
• IDプロバイダーに新しいアプリが追加されたが台帳に未登録

これらのアラートをメール・Slack等で自動受信する仕組みを整えておくと、棚卸しのサイクルの間に発生したシャドーITを早期に発見できます。

SaaS管理ツールを使った継続監視

手動での棚卸しには限界があります。特に従業員規模が大きくなるにつれ、スプレッドシートによる管理は属人化・陳腐化が避けられません。

SaaS可視化とはの観点で言えば、SaaS管理プラットフォームを使った「常時監視状態」が、情シスの工数を最小化しながらシャドーITを継続的に把握する唯一の現実的な方法です。

参考URL: https://service.qac.jp/sapo-topi/BPO/internal-Itsystem/S/shadowIT

シャドーIT対応でよくある失敗と対処法

5つのステップを理解しても、実際の対応では同じ失敗が繰り返されます。代表的なパターンと対処法を整理します。

「禁止だけして代替を用意しなかった」

最も多い失敗パターンです。禁止令を出しても現場のニーズはなくならず、別のシャドーITを探す・使い方をより慎重に隠す、という結果になります。

対処法は単純で、「禁止と代替手段の提供はセット」というルールを情シス内で徹底することです。禁止を判断した段階で、代替手段の案内が完成していることを条件にします。

「一律禁止で現場と対立した」

高リスクの一部SaaSに対する対応を「全部禁止」に拡大した場合、業務への影響が大きくなり情シスへの不信感が高まります。業務効率を下げる情シスというレッテルを貼られると、以後の対策協力が得にくくなります。

対処法は、リスク評価に基づいた分類（公認・黙認・禁止）を徹底し、業務上の必要性が高いものはリスク低減策を条件とした条件付き許可を検討することです。

「ポリシーを作ったが誰も読まなかった」

ポリシーを作成・配布しても、実際に参照されなければ意味がありません。過度に詳細なポリシーは「存在は知っているが読んだことはない」という状態になりがちです。

対処法は、ポリシーの「1枚サマリー版」を作成し、主要なルールを箇条書き5〜10点で示すことです。入社時研修への組み込みと、年1〜2回の全社周知がポリシーの実効性を維持します。

「対応してもすぐ新しいシャドーITが生まれた」

シャドーITへの対応を完了した後も、新しいSaaSが登場するたびにシャドーITが発生します。「対応して終わり」という考え方そのものが失敗の原因です。

対処法は、シャドーIT対応を「一時的なプロジェクト」ではなく「継続的な運用プロセス」として位置づけることです。四半期棚卸しと継続監視の仕組みを整え、定常業務として組み込みます。

シャドーITをゼロに近づけるジョーシスの活用方法

5つのステップを手動で回すと、情シス担当者の工数が膨大になります。ジョーシス（Josys）を活用することで、特に「可視化」と「継続監視」の部分を大幅に自動化できます。

未承認SaaSの自動検出

ジョーシスは、ブラウザ拡張機能とIDプロバイダー連携を組み合わせることで、従業員が業務で使っているすべてのSaaSを自動的に検出し、ダッシュボードに一覧表示します。

この機能により、Step1「現状の可視化」がほぼリアルタイムで継続実行されます。情シス担当者がログを手動で分析する必要がなくなり、検出漏れのリスクも大幅に低減します。SaaS管理とはの一部として、シャドーIT管理を体系的に位置づけることができます。

入退社時のデプロビジョニング自動化

シャドーITの問題として特に深刻なのが、退職者のアカウントが未承認ツールに残り続けるケースです。ジョーシスの自動デプロビジョニング機能を使うと、退職・異動時に承認済みSaaSのアカウントを一括で無効化できます。

シャドーIT化していたサービスについても、ジョーシスがアカウントを検出している場合は同様に処理の対象にできるため、退職者によるデータアクセスリスクを最小化できます。100種類以上のSaaSとの連携に対応しており、人事システムとの連動で退職手続きと同時にアカウント停止が完了します。

参考URL: https://josys.com/jp/blog/2024-06-27-manage-shadow-it-with-the-josys-browser-extension

まとめ

シャドーIT対応は「禁止して終わり」ではなく、発見・評価・ポリシー整備・代替手段提供・継続監視という5つのステップを継続的に回す仕組みを作ることが本質です。

情シス担当者にとって最も難しいのは「完璧を目指さない」という割り切りかもしれません。すべてのシャドーITを即座に撲滅しようとすると、現場との摩擦が大きくなりすぎます。高リスクなものから順に対処しながら、現場が使いやすい公式ツールを整えていく——この段階的なアプローチが、長続きするシャドーIT対策の基本です。

シャドーITのリスク詳細についてはシャドーIT リスクを、シャドーAIへの具体的な対応については[内部リンク: シャドーAIとは]を併せてご覧ください。

Josys 資料ダウンロード

シャドーITの自動検出からSaaS一元管理まで、Josysの機能詳細と導入事例を資料でご確認いただけます。

Josys 製品資料をダウンロードする