シャドーITのリスクを社内説明するためのFAQ｜情シスが押さえるべき対策と進め方

シャドーITは、「現場が勝手に危険なことをしている」という問題ではありません。業務上の必要性と、会社が用意したIT環境の使いやすさに差があるときに起こりやすい、管理上の課題です。

情シスが社内説明を行う際は、「禁止するかどうか」から入るのではなく、次のような具体的な論点に置き換えると伝わりやすくなります。

• どの情報を扱っているのか
• 誰が契約・管理しているのか
• 退職者や異動者のアカウントを削除できるのか
• 利用ログを確認できるのか
• 障害や情報漏えい時に対応できるのか
• 取引先や監査に説明できるのか

経営層には「シャドーITはサイバーセキュリティだけでなく、経営・業務継続上のリスクである」と説明します。一方、現場部門には「安全に使えるサービスと申請ルートを整備するためのルール」と伝えることが重要です。

本記事では、IPAやNISTなどの公開情報を参考に、国内企業の情報システム担当者が社内説明に活用しやすいFAQ形式で、シャドーITのリスクと対策を整理します。

シャドーITとは

シャドーITとは、情報システム部門やセキュリティ担当部門の承認、台帳登録、設定確認などを経ずに、部門や個人が業務で利用しているIT機器・クラウドサービス・SaaS・生成AI・ファイル共有サービス・チャット・業務アプリなどを指す実務上の呼び方です。

法令上厳密に定義された用語ではありませんが、組織の管理プロセスから外れたIT利用を説明するために広く使われています。

情シスが問題視するのは、単に「知らないツールがある」ことではありません。重要なのは、次の情報が把握できなくなることです。

• 契約者・管理者
• 保存・入力されている情報
• 外部共有の範囲
• アカウントや権限
• 利用ログ
• 解約時のデータ返却
• 障害・インシデント時の対応
• 退職者・異動者へのアクセス制御

すでに業務で使われているサービスを一方的に停止すると、業務への影響が大きくなる場合があります。まずは利用目的、扱う情報、管理責任者、代替手段を確認し、リスクの高いものから是正することが現実的です。

「危険だから使わないでください」とだけ説明すると、現場には業務妨害のように受け止められる可能性があります。

リスクを業務影響に置き換えて説明すると、経営層・法務・総務・現場部門が共通の視点で議論しやすくなります。

シャドーITの本質は、ツール名そのものではありません。IT資産、データ、アカウント、契約、運用責任が、組織の管理プロセスから外れることです。

FAQ①: シャドーITはなぜ今、経営リスクとして説明すべきですか

クラウド、SaaS、外部委託、リモートワーク、部門主導のデジタル活用が広がり、企業活動が社外のサービスに依存しているためです。

一見すると単なるツール利用でも、次の問題につながる可能性があります。

• 情報漏えい
• 業務停止
• 取引先への影響
• 契約違反
• 監査対応の不備
• インシデント時の初動遅延

IPAは「中小企業の情報セキュリティ対策ガイドライン」第4.0版で、サイバー攻撃による被害が情報漏えいにとどまらず、事業活動の停止にまで及ぶことや、サプライチェーン全体での対策が必要であることを示しています。 ipa.go.jp

そのため、シャドーIT対策は情シスだけのルール整備ではありません。経営判断、業務継続、取引先からの信頼、社内統制に関わる経営課題として扱う必要があります。

FAQ②: 便利なSaaSを使うこと自体が問題なのですか？

問題は、SaaSを使うこと自体ではありません。

利用目的、入力データ、契約、権限、ログ、解約時のデータの扱いが確認されないまま、重要業務に組み込まれることが問題です。

たとえば、次のようなケースがあります。

• 営業部門が商談メモを外部AIサービスへ入力する
• 採用担当者が候補者情報を無料フォームで収集する
• 開発部門が個人アカウントでコードを共有する
• 製造部門が独自にIoT機器を導入する

これらは業務改善を目的に始まることが多く、必ずしも悪意があるわけではありません。しかし、個人情報、顧客秘密、設計情報、認証情報などを扱うと、会社としての管理責任が発生します。

IPAのプラクティス・ナビにも、製造部門で導入したIoT機器がシャドーIT化した事例が掲載されています。情報システム部門の関与が不十分なまま外部ネットワークへ接続されると、セキュリティ要件の検討漏れにつながる可能性があります。 ipa.go.jp

重要なのは「使うな」ではなく、「通常のシステム導入と同じ確認を行う」ことです。

• データ分類
• 接続先
• 管理者
• 認証方式
• ログ
• 障害時対応
• 退職者対応

これらを確認できる仕組みを整えれば、現場の改善スピードとセキュリティを両立できます。

FAQ③: シャドーITで最初に確認すべき項目は何ですか

ツールの数ではなく、業務影響の大きい利用から確認します。

特に、次の条件に該当するものは優先度が高くなります。

• 重要情報を扱っている
• 外部共有を行っている
• 日常業務が依存している
• 管理者が一人しかいない
• 個人契約で利用している
• 退職者のアカウントを削除できない

社内説明では、次の順番で確認すると対立を避けやすくなります。

1. 何の業務で使っているか
2. どの情報を入力・保存しているか
3. 社外の誰と共有しているか
4. 誰が契約し、管理しているか
5. 退職・異動時にアカウントを削除できるか
6. ログ、バックアップ、データ出力が可能か
7. 障害時の代替手段があるか

NISTのCybersecurity Framework 2.0は、サイバーセキュリティリスク管理を「Govern、Identify、Protect、Detect、Respond、Recover」の6機能で整理しています。 nist.gov

シャドーIT対策では、まず「何があるのか」を把握するIdentifyが出発点です。資産台帳にないSaaSは、認証統制、ログ監視、復旧計画の対象から漏れる可能性があります。

調査には、次の情報を組み合わせます。

• 社内アンケート
• 経費精算データ
• IdP・SSO連携状況
• DNS・プロキシログ
• CASB・SASEの情報
• EDR・MDMの情報
• ブラウザ拡張機能
• エンドポイント管理情報

FAQ④: 経営層にはどのように説明すればよいですか

経営層には、個別ツールの危険性よりも、意思決定に必要な論点へ変換して説明します。具体的には、リスクの大きさ、許容可能な水準、投資判断、責任分担、取引先説明、インシデント時の初動です。

NISTのCSF 2.0は、業種や規模、成熟度を問わず、組織がサイバーセキュリティの取り組みを理解、評価、優先順位付け、コミュニケーションするための分類を提供すると説明しています。Source: NIST CSF 2.0

情シスから経営層へは、次のように短くまとめると伝わります。

• 現在、部門が個別に使っているSaaSや外部サービスがあり、台帳化されていないものがあります。
• その一部は、顧客情報、個人情報、業務上重要な資料を扱っている可能性があります。
• 現状では、退職者アカウント、外部共有、ログ取得、障害時対応、解約時のデータ回収を一元的に確認できません。
• 全面禁止ではなく、利用申請、情報分類、認証連携、例外承認、定期棚卸しの仕組みを作ることで、現場の利便性とリスク低減を両立できます。

この説明では「どのサービスが悪いか」ではなく、「会社として説明できる管理状態か」に焦点を置いています。経営層には、承認フローの整備、予算、利用可能サービスの標準化、部門責任者の協力を決めてもらう必要があります。

FAQ⑤: 現場部門にはどう説明すると反発されにくいですか

現場には「禁止したい」ではなく、「安全に使える選択肢を増やしたい」と説明します。

シャドーITが生まれる背景には、次のような事情があります。

• 公式ツールが使いにくい
• 申請先が分からない
• 承認に時間がかかる
• 部門固有の業務に合わない
• 無料ツールの方が導入しやすい

説明は次の順番で行います。

• 業務上の困りごとを聞く
• ツールを責めず、利用目的を確認する
• 扱う情報を確認する
• 禁止・条件付き利用・承認済みを分類する
• 代替ツールと申請ルートを示す
• 例外利用の条件と期限を決める

たとえば、次のようなルールです。

• 公開情報だけを扱うメモ用途は条件付きで利用可能
• 顧客情報は承認済みCRMまたは契約済みSaaSに限定
• 生成AIには公開情報と許可された文書だけを入力
• 個人情報を扱うサービスは事前審査を必須化
• 外部API連携は申請制にする

また、情シス側の対応期限も重要です。申請しても長期間返答がなければ、現場は別のサービスを使い始めます。

• 簡易審査：3営業日以内
• 重要情報を扱う審査：法務・セキュリティ確認を含めて10営業日以内
• 緊急時：期限付きの暫定承認

このように、現場の業務速度に合ったルールを設計することが、実効性のあるシャドーIT対策につながります。

FAQ⑥: シャドーIT対策はどこまで技術で解決できますか

技術によって利用実態を発見し、一定の統制を行うことは可能です。しかし、技術だけでは解決できません。

活用できる情報・仕組みには、次のようなものがあります。

• CASB
• SASE
• SWG
• DNSログ
• EDR
• MDM
• IdP
• SSO
• 経費精算データ

一方で、次の判断には人とプロセスが必要です。

• 何の目的で使っているのか
• どの情報を扱うのか
• 誰が契約責任を負うのか
• 例外利用を認めるのか
• 現場にどの代替手段を提供するのか

NIST SP 800-207は、ネットワーク境界だけに依存せず、ユーザー、資産、リソースを中心に安全性を判断するゼロトラストの考え方を示しています。 csrc.nist.gov

シャドーIT対策でも、社内ネットワークに接続しているかどうかだけで判断してはいけません。

• 誰が
• どの端末から
• どのサービスへ
• どのデータに
• どの権限で

アクセスしているのかを確認することが重要です。

監視ツールを導入した後は、発見したサービスを即座に停止するのではなく、情報分類、代替手段、例外承認の流れへ接続しましょう。

FAQ⑦: すぐに禁止すべきシャドーITはありますか

あります。ただし、「未承認だから」という理由だけでなく、扱う情報と業務影響を踏まえて判断します。

次のような利用は、停止または即時是正の候補です。

• 個人情報、顧客情報、機密資料、認証情報を契約未確認のサービスへ保存している
• 退職者や委託先がアクセスできる状態にある
• 個人アカウントや個人カードで重要業務を運用している
• 外部共有リンクの範囲が広すぎる
• 入力データの学習利用や第三者提供の条件が不明
• 障害時にデータを取り出せない
• サービス停止が業務停止に直結する

ただし、即時停止によって業務停止が起きる場合は、暫定措置を講じます。

• 外部共有を停止する
• 重要情報の新規投入を止める
• 管理者を複数名にする
• 承認済み環境へデータを退避する
• 期限付きの例外承認に切り替える
• 代替サービスへの移行計画を作成する

禁止基準は事前に文書化しておくことが重要です。

• 機密情報を扱う
• 外部共有がある
• 退職者アカウントを削除できない
• 利用ログを取得できない
• 契約主体が不明

このような客観的条件を示せば、情シスの判断が恣意的に見えることを防げます。

FAQ⑧: 社内ルールはどの程度細かく作ればよいですか

最初から細かすぎるルールを作ると、現場で運用されません。

まずは、次の7項目を押さえます。

1. 利用申請
2. 情報分類
3. 承認済みサービス一覧
4. 例外承認
5. 定期棚卸し
6. 退職・異動時のアカウント管理
7. インシデント時の連絡

IPAの中小企業向けガイドラインでも、経営者が認識すべき方針と、社内で対策を実践するための手順が整理されています。 ipa.go.jp

重要なのは、ルールを作って終わりにしないことです。申請のしやすさ、回答速度、例外の扱い、承認済みサービスの更新を継続的に改善しましょう。

FAQ⑨: 生成AIやノーコードツールもシャドーITに含めるべきですか？

含めるべきです。

生成AI、ノーコード、ローコード、オンライン自動化ツールは、短時間で業務改善できる一方、次の管理が難しくなります。

• 入力データ
• 外部連携
• 権限
• 作成物の管理
• 利用ログ
• 所有者変更
• 退職者対応

生成AIでは、入力可能な情報を分類することが重要です。

• 公開情報
• 社内情報
• 個人情報
• 顧客契約情報
• ソースコード
• 認証情報

これらを同じ扱いにしてはいけません。

ノーコードツールでは、部門が作成したアプリが日次処理や顧客対応などの重要業務に組み込まれるケースがあります。作成者が異動・退職すると、仕様や管理方法が分からなくなることもあります。

そのため、次のような利用区分を設けます。

• 公開情報のみ：条件付きで利用可
• 社内情報：承認済み環境のみ
• 個人情報・顧客秘密：事前審査
• 外部API連携：申請必須
• 重要業務に利用するアプリ：レビュー必須

部門が作成するアプリには、複数管理者の設定、データ保存先の明確化、退職時の所有権移管も求めます。

FAQ⑩: 情シスは何から始めればよいですか

最初の30日で完璧な統制を目指す必要はありません。まずは、会社として説明できる現状把握を行います。

1. 経営層へ、シャドーITを経営・業務継続リスクとして説明する
2. 各部門へ利用中サービスの棚卸しを依頼する
3. 経費精算、IdP、DNS、プロキシ、EDRなどの既存情報を確認する
4. サービスを「承認済み」「条件付き」「要確認」「停止候補」に分類する
5. 重要情報を扱うサービスから契約・権限・ログ・バックアップを確認する
6. 申請フォームと承認済みサービス一覧を公開する
7. 四半期ごとの棚卸しと例外承認の見直しを予定化する

この進め方なら、現場にも「正直に申告すると処罰される」ではなく、「安全に使える状態へ移行するための確認」と説明できます。

情シスは、すべてを禁止する管理者ではなく、業務部門が必要なITを安全に選べる環境を設計する役割を担います。

まとめ：シャドーITは「禁止」ではなく「管理可能な状態」へ移行する

シャドーITの本質的なリスクは、未承認ツールそのものではありません。

会社が管理すべき次の要素が見えなくなることです。

• 情報
• 契約
• アカウント
• 権限
• ログ
• 復旧手段
• 説明責任

経営層には、シャドーITを経営・業務継続リスクとして説明します。現場部門には、禁止ではなく、安全に使えるサービスと申請しやすいルールを提示します。

技術的な検知・制御に加えて、資産台帳、情報分類、承認済みサービス一覧、例外承認、退職者対応、定期棚卸しまで運用することで、シャドーITは「見つけて止める対象」から「管理可能な業務IT」へ移行できます。

まずは、部門ごとの利用実態を把握し、重要情報を扱うサービスから優先順位を付けて確認しましょう。

InfiniCore株式会社では、社内で利用されているクラウドサービスやSaaSの状況を確認し、情報漏えい・権限管理・契約・ログ・退職者対応などの観点から、改善すべきポイントを整理するセキュリティ診断を提供しています。

「どのサービスが使われているか分からない」「申告されていないSaaSを把握したい」「社内ルールの優先順位を決めたい」という企業は、まず現状を可視化することから始めてみませんか。