「シャドーIT」という言葉自体は耳にしたことがある担当者は多いはずです。しかし、いざ経営層から「自社のシャドーIT の現状を報告して」と求められたとき、対策の情報が「従業員個人の私物端末・SaaS利用」の話に偏りすぎていて、業務委託先や外注先まで含めた実務にどう落とし込めばよいのか判断が難しい、と感じたことはないでしょうか。
近年は SaaS の急増、生成AI の業務利用、外部委託の常態化が同時に進行しており、自社の情報システム部門が把握できていない IT 利用は、社内だけでなく委託先・外注先にも広がっています。ガートナージャパンの2026年6月調査では、7割超の国内企業がシャドーAI への有効な対策を取れていないと回答しています(日経クロステック)。管理の空白は、確実に広がっています。
発注者にとって難しいのは、社内従業員は就業規則やガイドラインで統制できても、委託先の従業員が使うツールや端末は「相手側の統制ルール」に依存する点です。それでもインシデントが起きれば、監督責任を問われるのは発注元です。
本記事では、シャドーIT の基本定義と類似概念との違いを整理したうえで、発注者に固有の4つのリスク・実例パターンを解説します。そのうえで、発注者が明日から着手できる5ステップの管理方法と、委託契約に盛り込むべき条項の雛形まで、経営層に説明できる形で提示します。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法(特定受託事業者に係る取引の適正化等に関する法律)」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
シャドーITとは|発注者にとっての意味と類似概念との違い
シャドーIT は「企業の情報システム部門が把握・許可していない IT の利用」を指す用語です。従業員個人の私物端末利用の話として語られることが多い一方、発注者の視点では自社外にも管理対象を広げて考える必要があります。まずは定義と類似概念の違いを整理します。
シャドーITの一般的な定義
シャドーIT とは、企業の情報システム部門が把握・許可していないハードウェア・ソフトウェア・クラウドサービスが、業務で利用されている状態のことです。私物のスマートフォン・PC を業務メールの確認に使う、無料のオンラインストレージにファイルを保管する、業務チャットに個人の LINE を使う、といった行為が典型例です。
シャドーIT の本質的な問題は「利用そのもの」ではなく、「情報システム部門が存在を把握していないため、リスクがコントロールできない」点にあります。使っている本人に悪意がなくても、パッチ未適用の端末・弱いパスワード・退職者アカウントの放置など、統制の外にある IT はセキュリティ上の弱点になります。
発注者にとってのシャドーIT(自社+委託先+外注先の3層)
発注者の立場では、シャドーIT を次の3層で捉える必要があります。
- 第1層:自社従業員のシャドーIT — 従業員個人が私物端末・無許可 SaaS・無許可の生成AI を業務で利用するケース
- 第2層:業務委託先のシャドーIT — バックオフィス業務・データ入力・カスタマーサポート等を委託した先の作業者が、私物 PC や個人アカウントの SaaS で発注元の情報を扱うケース
- 第3層:システム開発外注先のシャドーIT — 開発を委託したベンダーやフリーランスが、承認外の OSS ライブラリ・SaaS ツール・生成AI コーディングアシスタントを開発工程で利用するケース
自社従業員向けの情報セキュリティ研修や MDM(モバイルデバイス管理)だけでは、第2層・第3層に対策が届きません。発注者は3層すべてを可視化する必要があります。
BYOD・サンクションIT・シャドーAIとの違い
シャドーIT の周辺には、混同されやすい用語がいくつかあります。それぞれ「情報システム部門の関与度」が異なる概念として整理しておくと、社内説明で混乱を招きません。
用語 | 定義 | 情報システム部門の関与 |
|---|---|---|
シャドーIT | 情報システム部門が把握・許可していない IT 利用 | なし(無許可) |
BYOD | 従業員の私物端末を、社内ルールに基づいて業務利用する制度 | あり(許可・管理) |
サンクションIT | 情報システム部門が正式に承認・提供する IT | あり(承認・調達) |
シャドーAI | シャドーIT のうち、生成AI に関するもの | なし(無許可) |
BYOD は「私物端末利用」という点でシャドーIT と混同されがちですが、決定的な違いは情報システム部門による管理の有無です。BYOD 制度下で MDM を導入していれば、それはシャドーIT ではなくサンクション IT に近い扱いになります。
シャドーAI はシャドーIT の派生概念として近年注目されている領域です。生成AI サービスの多くはブラウザから即座に利用でき、無料枠が提供されているため、従業員個人が業務資料を無許可でアップロードしてしまうリスクが高くなっています。
シャドーITが発注者にもたらす4つのリスク

シャドーIT が引き起こすリスクは、一般的に「情報漏洩」「不正アクセス」「マルウェア感染」「コンプライアンス違反」の4つに分類されます。ここでは、それぞれのリスクが発注者の立場で顕在化したときにどう表れるかに焦点を当てて説明します。
情報漏洩・機密情報の流出(委託先の私物PC・SaaS利用経由の実例)
もっとも切実なのが情報漏洩です。発注者が委託先に渡した顧客情報や設計情報が、委託先作業者の私物 PC や個人アカウントの SaaS を経由して外部に流出する事故は繰り返し発生しています。
たとえば富士フイルムビジネスイノベーションが紹介する事例では、外部委託コンサルタントの私物 PC がマルウェアに感染し、発注元の機密情報が漏洩する事故が報告されています(富士フイルムビジネスイノベーション)。
シャドーAI 起点の情報漏洩も急増しています。IBM の「Cost of a Data Breach Report 2025」は、シャドーAI を独立カテゴリとして分析し、世界のデータ侵害の20%がシャドーAI に起因していると報告しました。同レポートでは AI モデルまたは AI アプリケーションの侵害を経験した組織が全体の13%に上り、そのうち97%が適切な AI アクセス制御を導入していなかったと報告されています(IBM Newsroom)。委託先の従業員が業務資料を生成AI に貼り付けて要約させる、といった行為も情報漏洩の入口になります。
不正アクセス・アカウント乗っ取り
情報システム部門が把握していない SaaS アカウントは、多要素認証(MFA)の設定漏れや、パスワード使い回しによる不正アクセスの温床になります。委託先の担当者が個人契約で使っている SaaS の場合、退職・契約終了後もアカウントが放置され、乗っ取られたときの検知が遅れます。
発注元にとって深刻なのは、乗っ取られたアカウントに発注元の情報が保存されている場合です。委託先個人のアカウントであっても、そこに含まれるデータの管理責任は発注元に及ぶことがあります。
マルウェア感染とサプライチェーン攻撃への波及
無許可の端末・ソフトウェアはパッチ管理が疎かになりがちで、マルウェア感染の温床になります。委託先の1台の私物 PC がランサムウェアに感染すれば、発注元とやり取りしているファイルを丸ごと暗号化されるおそれがあります。
さらに近年増えているのが「サプライチェーン攻撃」です。攻撃者は本命の大企業を直接狙わず、セキュリティ対策が手薄な取引先・委託先を踏み台にします。委託先のシャドーIT は、発注者を狙う攻撃者にとって恰好の侵入経路になり得ます。委託先を経由した情報漏洩が起きたときの発注者側の責任範囲と初動対応については、委託先で情報漏洩が起きたときの初動対応も参考にしてください。
コンプライアンス違反・監督責任
個人情報保護法・改正個人情報保護法では、委託先が個人データを取り扱う場合、委託元は委託先に対して「必要かつ適切な監督」を行う義務を負います(個人情報保護法第25条)。委託先が無許可の SaaS で個人データを扱っていたことが判明した場合、監督義務違反として発注元が指導・勧告の対象となる可能性があります。
多層下請け構造の中では、この監督責任が形骸化しやすくなります。多重下請け特有のリスクは多重下請け構造のリスクにも整理しています。委託先が再委託先を使う場合、シャドーIT の管理が再委託先まで及んでいるかを確認する体制が必要です。
シャドーITが発生する原因|発注者側の見落としがち3ポイント
シャドーIT がなぜ発生するのかを理解しないと、対策は表面的なものにとどまります。特に発注者が見落としがちなのが、委託先まわりの構造的要因です。
業務効率化のニーズと公式ITの使いづらさ
もっとも根本的な原因は、公式に提供されている IT が業務のスピードに追いついていないことです。稟議・情報システム部門への申請・セキュリティレビューといったプロセスが数週間かかるとき、現場は目の前の締め切りを優先して「使いやすい無料 SaaS」を勝手に導入します。
シャドーIT を「怠慢」や「規律違反」として断罪しても、根本原因は解決しません。むしろ「なぜ公式の IT では業務が回らないのか」というフィードバックとして受け止め、正規ツールの整備を早める材料にする視点が必要です。
リモートワーク・複数拠点環境の広がり
コロナ禍以降に定着したリモートワークは、シャドーIT の温床でもあります。オフィスの回線ではなく自宅の Wi-Fi、会社支給ではなく私物のプリンタ・ディスプレイ、会議には個人契約のツール…と、統制の効かない環境で業務が行われる場面が増えました。
複数拠点・複数プロジェクトが並行する組織では、それぞれの現場が独自に SaaS を導入しがちで、部門をまたいだ棚卸しがなければ本社の情報システム部門は実態を把握できません。
委託先・外注先の管理体制の空白
発注者ならではの盲点が、委託先の内部統制です。発注元が自社従業員向けに厳格なガイドラインを整備していても、委託先の作業者に対しては「委託先のルールに任せる」形になっていることが少なくありません。
とくにフリーランスや小規模ベンダーへの委託では、相手側に情報セキュリティ体制が確立されていないケースがあります。契約書上は「善良な管理者の注意義務」と書いてあっても、実際に何を使っているかまでは把握できないのが実態です。この管理体制の空白を埋めるには、契約段階でのセキュリティ条項の取り決めと、契約締結後の継続的なモニタリングの両輪が不可欠です。
SaaS・生成AI(シャドーAI)の急速な普及
生成AI の登場は、シャドーIT の景色を一変させました。総務省の令和7年版情報通信白書によれば、日本企業で何らかの業務に生成AI を利用していると回答した割合は55.2%に上ります(総務省 令和7年版情報通信白書)。中国95.8%、米国90.6%、ドイツ90.3%と比較すればまだ低いものの、業務利用の裾野は急速に広がっています。
一方で、PwC Japan「生成AIに関する実態調査2025春」では、日本の従業員で「過去1年間に業務にAIを活用した」との回答が35%にとどまり、グローバル平均54%を大きく下回っています(PwC Japan)。企業としての正式導入が遅れている状況では、現場の担当者が個人契約の生成AI サービスをブラウザから利用するインセンティブが強く働きます。発注者がシャドーAI を放置すれば、委託先を含めた業務データが海外の LLM 事業者の学習素材として吸い上げられるリスクを抱え込むことになります。
発注者が押さえるべきシャドーITの実例パターン

シャドーIT の議論を抽象論に留めず、発注者の現場に落とし込むために、3つのカテゴリで実例パターンを整理します。それぞれのパターンで発注者が取れる打ち手の方向性も添えます。
自社内で発生するシャドーIT(従業員のSaaS/生成AI利用)
もっとも一般的なのが、自社従業員によるパターンです。
- 部門長の判断で無料版のオンラインストレージ(Google Drive・Dropbox の個人アカウント)に顧客資料を保管する
- 個人契約の ChatGPT に議事録の要約を任せ、社外秘の会議内容をそのまま貼り付ける
- 社内で使えないタスク管理ツールの代わりに、部門独自で Notion 個人プランを契約する
- 転職を控えた社員が、自分のスキル証明用に業務データを私物 PC に持ち出す
打ち手の方向性は「棚卸し → 正式化 or 禁止」の二択です。業務上必要と判断されたものは会社契約で正式化し、代替が用意できるものは無許可利用を明確に禁じます。
業務委託先で発生するシャドーIT(私物PC・個人アカウント経由)
バックオフィス業務・カスタマーサポート・データ入力・翻訳といった業務委託では、委託先が私物 PC や個人アカウントで発注元の情報を扱うケースが目立ちます。
- 委託先のフリーランスが、発注元の顧客リストを自分の Gmail に転送して作業する
- 業務を再委託された孫請け作業者が、無料版の翻訳サイトに機密文書を貼り付けて処理する
- 委託先のスタッフが、退職後も個人 Google アカウントに発注元のドライブ共有権限を残したまま放置する
打ち手の方向性は「契約条項での禁止 + アクセス権限の即時剥奪 + 定期監査」の3点セットです。とくに退職・契約終了時のアカウント整理は、発注者が委託先に義務づけるべき最優先項目です。
システム開発外注先で発生するシャドーIT(開発環境・OSS・生成AI利用)
システム開発の外注では、シャドーIT のリスクが技術的なレイヤーに広がります。
- 開発ベンダーが承認外の OSS ライブラリを組み込み、ライセンス違反や脆弱性を発注元プロダクトに持ち込む
- 開発者が本番相当のデータをローカル PC にダウンロードしてデバッグする
- コーディングアシスタント(生成AI)に発注元のソースコードを貼り付け、外部サービスに送信する
- 検証環境として個人アカウントのクラウドサービスを立て、そこに実データを流し込む
打ち手の方向性は「開発規約の明文化 + 使用ツールの事前承認制 + ソースコード送信を伴う AI 利用の明示的可否」の3点です。技術的統制と契約上の統制を両輪で組み立てる必要があります。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法(特定受託事業者に係る取引の適正化等に関する法律)」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
発注者が今すぐ取り組めるシャドーIT管理方法5ステップ

ここからは、発注者が明日から着手できる5ステップの管理方法を提示します。「実態把握 → ガイドライン → 代替提供 → 契約 → 継続監査」の順で進めることで、経営層への説明も一貫した骨子で行えます。
ステップ1|自社と委託先のIT利用実態を棚卸する
まず着手すべきは、自社と委託先の IT 利用実態を可視化することです。技術的な統制ツールを入れる前に、現状を把握しなければ対策の優先順位が決まりません。
サマリ:自社の全部門と主要委託先に対して、業務で利用中の SaaS・生成AI・端末・アカウントを台帳化します。完璧を目指さず、まずは月内に「主要 SaaS 上位30個」を洗い出す粒度で構いません。
チェックポイント:
- クレジットカード・経費明細から支払いのある SaaS を抽出したか
- 各部門長にヒアリングし、無料版で使っているツールも把握したか
- 主要委託先に「業務で使っているツール・端末」の申告を依頼したか
- 生成AI サービス(ChatGPT・Copilot・Gemini 等)の利用有無を明確に問うたか
ステップ2|利用可能ツールのホワイトリストとガイドラインを整備する
実態が見えたら、次は「何を許可し、何を禁止するか」を明文化します。
サマリ:業務で利用してよい SaaS・生成AI サービスを「ホワイトリスト」として明示し、それ以外の利用を原則禁止するガイドラインを整備します。禁止だけでは現場が反発するため、「新しいツールを使いたい場合の申請プロセス」もセットで設計します。
チェックポイント:
- ホワイトリストは「業務目的」で整理されているか(例:文書共有はこのツール、議事録要約はこの生成AI)
- 例外申請のフローと標準リードタイム(例:3営業日以内に判定)を明記したか
- 委託先にも同ガイドラインを適用する旨を明記したか
- 違反時の対応(是正指導・アカウント停止など)を段階的に整理したか
ステップ3|業務に必要なツールを公式に提供・代替する
シャドーIT の根本原因は、多くの場合「公式に提供されているツールが業務ニーズに合わない」ことです。禁止だけで運用するのは長期的には破綻します。
サマリ:現場が個別に契約している SaaS のうち、業務上必要と判断できるものは会社契約に切り替え、公式提供に組み込みます。使いにくい社内システムは、業務効率化の観点から改修計画を立てます。生成AI については企業版契約(データを学習に使わないプラン)への集約が有効です。
チェックポイント:
- 会社契約への切り替えで、個人契約分を停止できるプロセスを設計したか
- 生成AI について、企業版契約や社内向けチャットボットを提供したか
- 業務効率のフィードバックを情報システム部門に集約する経路があるか
ステップ4|業務委託契約にシャドーIT禁止・報告義務条項を組み込む
自社従業員向けの対策だけでは、委託先層のシャドーIT はカバーできません。業務委託契約の中でシャドーIT を明示的に禁止し、報告義務を課します。
サマリ:契約書・NDA・情報セキュリティ覚書に「発注者の事前承認なくして SaaS・生成AI に発注元の情報を入力しないこと」「私物端末利用の禁止または限定条件」「インシデント発生時の即時報告義務」「監査権限」の4点を組み込みます。詳しい条項例は次のセクションで扱います。
チェックポイント:
- 新規契約に上記条項が組み込まれているか(テンプレート化されているか)
- 既存契約についても、覚書として同等の取り決めを追加したか
- 再委託の場合、再委託先まで同等の義務が及ぶ条項になっているか
- 契約書の改定履歴・承認日を管理台帳に記録したか
ステップ5|モニタリング・監査の仕組みを継続運用する
契約を結んだだけでは、実態は変わりません。継続的なモニタリングと定期監査によって、契約の実効性を担保します。
サマリ:ネットワーク・エンドポイントのログから未承認 SaaS への通信を可視化する仕組み、委託先に対する年次または半期ごとの自己申告レビュー、インシデント報告経路の周知など、複数レイヤーで継続監視を行います。すべてを一度に整備する必要はなく、実態把握で見つかった大きな穴から順に埋めていきます。
チェックポイント:
- 未承認 SaaS への通信を検知する仕組み(CASB や DNS ログ分析)を段階的に導入したか
- 委託先への年次自己申告レビュー(利用ツール・端末・アカウント状況)を仕組み化したか
- インシデント発生時の一次窓口・エスカレーション経路が全委託先に周知されているか
- 監査結果を経営層に半期ごとに報告する枠組みがあるか
中長期で構築するシャドーIT管理体制と最新動向
5ステップの初動が回り始めたら、技術的な統制の強化と、シャドーAI 時代への対応を段階的に加えていきます。ここではロードマップとして位置づけ、いきなり全てを導入する必要はない点を強調します。
IT資産管理ツール・MDMによる可視化
IT 資産管理ツールは、社内 PC にインストールされているソフトウェア・接続されているクラウドサービスを一元的に可視化する仕組みです。MDM(モバイルデバイス管理)は、スマートフォン・タブレットに対して同様の可視化・制御を行います。
これらは自社デバイスに閉じたコントロールが中心ですが、まずは「自社の第1層」から可視化を進めるうえで確実な打ち手です。中堅・中小企業向けにはクラウド型で導入しやすい製品が増えており、初期投資を抑えて始められます。
CASB・SSO/IDaaSによるSaaSアクセス制御
CASB(Cloud Access Security Broker)は、社員がアクセスする SaaS を可視化・統制するためのゲートウェイです。SSO(シングルサインオン)・IDaaS(Identity as a Service)は、SaaS へのログインを一元管理する仕組みで、承認外 SaaS への個人アカウントログインを検知・遮断する土台になります。
これらは自社ネットワーク経由のアクセスに強く働きますが、委託先の環境からのアクセスは統制しにくい点に注意が必要です。委託先の管理は契約と自己申告レビューで補完します。
企業版生成AIの提供とシャドーAI対策
シャドーAI 対策の基本は「業務ニーズを満たす企業版 AI を提供すること」です。データを学習に使わない契約プラン、社内知識をベースにした RAG(検索拡張生成)型チャットボット、業務システムに組み込まれた AI アシスタントなど、選択肢は増えています。
企業版 AI を公式提供したうえで、個人契約 AI への業務データ入力を明確に禁止する運用が現実的です。委託先に対しても、企業版 AI の利用を条件付きで許可し、無料版を含む個人契約 AI の使用禁止を契約で定めます。生成AI 全般のセキュリティリスクとガイドライン整備の考え方は、生成AIのセキュリティリスクも参考になります。
継続的な従業員・委託先教育
技術的統制は「抜け穴を塞ぐ」役割を果たしますが、抜け穴を作らせないためには教育が不可欠です。年1回のセキュリティ研修に加え、生成AI の業務利用に関する短時間の勉強会・委託先向けの説明会を定期的に開催すると効果的です。
教育のポイントは「なぜ禁止するのか」を業務目線で伝えることです。「情報漏洩したら会社が困る」という抽象論より、「その情報が漏れたら顧客との契約が解除される」といった具体的な影響を伝えるほうが、現場の行動変容につながります。
発注者が委託先と結ぶべき契約上の取り決め

ここまで繰り返し触れてきた「委託契約でのシャドーIT 禁止条項」は、発注者の管理体制の中核を担う要素です。具体的にどのような条項を盛り込むべきか、実務的な視点で整理します。
業務委託契約に盛り込むべきセキュリティ条項
業務委託契約または情報セキュリティ覚書には、次のような条項を含めることを推奨します。
- 利用ツールの事前承認義務:受託者は、本業務で発注者の情報を扱う SaaS・クラウドサービス・生成AI サービスについて、事前に発注者の書面による承認を得るものとする
- 私物端末利用の禁止または限定:受託者は、原則として業務専用に管理された端末を用いる。私物端末の利用を認める場合の条件(MDM 導入・パスコード設定・暗号化・監査応諾等)を明記する
- 生成AI 利用に関する取り決め:受託者は、発注者の情報を生成AI サービスに入力する場合、事前承認の対象範囲・データ入力可否・学習利用の可否について発注者の指示に従うものとする
- 再委託時の同等義務:受託者が本業務の一部を再委託する場合、再委託先に対しても本条項と同等の義務を課すものとする
これらの条項をチェックリスト化しておくと、契約書レビュー時に漏れなく確認できます。多重下請け構造での監督責任の及び方については多重下請け構造のリスクも併せて参照してください。
秘密保持契約(NDA)とシャドーIT
NDA(秘密保持契約)は情報の取り扱いを規律する契約ですが、旧来型の NDA では「シャドーIT を経由した情報流出」を想定した文言が入っていないことが多くあります。次の観点で NDA を見直します。
- 秘密情報の「保管場所」を、発注者が承認した環境に限定する条項が入っているか
- 「秘密情報を第三者のクラウドサービスに保管・処理する場合、事前承認を要する」旨が明記されているか
- 契約終了時のデータ返却・破棄義務が、クラウド上のデータも対象にしているか
- 違反時の損害賠償額の予定または上限が、実損に対して妥当な水準か
NDA の改定は既存契約先にも遡って求めることが望ましく、少なくとも重要な取引先については、覚書の追加で対応します。
インシデント発生時の責任分担と報告フロー
シャドーIT 起点のインシデントが起きたとき、対応のスピードが被害の大きさを左右します。契約で報告フローと責任分担を事前に決めておくと、初動が滑らかになります。
- 報告義務の時限:受託者は、情報セキュリティインシデントを認識した場合、原則として認識後24時間以内に発注者に第一報を入れるものとする
- 一次窓口の指定:発注者・受託者ともに、インシデント連絡の一次窓口担当者を契約書に記載する
- 調査協力義務:受託者は、発注者が実施する原因調査・影響範囲特定に協力するものとする
- 公表・監督官庁報告の主導権:外部公表・監督官庁への報告は、原則として発注者の判断で主導するものとする
- 費用負担の原則:シャドーIT 起点のインシデントで受託者の故意・重過失が原因の場合、対応費用は受託者負担とする
これらの条項は、単に責任を委託先に押し付ける目的ではなく、「発注元・委託先双方が同じ手順で動けるようにする」ためのものと位置づけると、契約交渉の場でも合意を得やすくなります。
まとめ|発注者視点でシャドーIT対策を始めるための優先順位
シャドーIT の対策情報は世の中に多く出回っていますが、発注者の立場から自社と委託先の両方をカバーする形で整理された情報は多くありません。本記事の内容を「経営層に説明できる3ステップ」に集約すると、次のようになります。
- 第1優先:実態把握 — 自社・委託先を含めた IT 利用の棚卸しを、まずは主要 SaaS 上位30個の粒度で完了させる
- 第2優先:ガイドライン + 契約条項 — ホワイトリスト方式のガイドラインを整備し、業務委託契約・NDA にシャドーIT 禁止・報告義務条項を組み込む
- 第3優先:技術統制の順次導入 — IT 資産管理・MDM から始め、CASB・SSO/IDaaS へと段階的に拡張。並行して企業版生成AI を提供する
いきなり CASB のような高度なツールを導入しても、実態把握とガイドライン整備が伴わなければ運用は形骸化します。順序を守り、経営層への報告も「実態把握 → 契約 → 技術統制」の順で提示することが、限られた予算と体制の中で成果を出す鍵となります。
シャドーIT 対策は「一度整備すれば終わり」ではなく、SaaS・生成AI の新サービスが出続ける限り継続的な運用が求められる領域です。半期ごとの棚卸しと契約見直しをルーチン化することで、管理の空白が広がり続ける状態を防いでいきましょう。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法(特定受託事業者に係る取引の適正化等に関する法律)」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 委託先のシャドーITまで自社が責任を負う必要があるのですか?
個人情報保護法第25条により、委託元には委託先への「必要かつ適切な監督」義務があり、私物端末やSaaS経由の事故でも責任は発注元に及びます。委託先任せにせず、契約条項と定期的な監査の両輪で自社が主体的に管理する体制を整えてください。
- 予算や体制が限られている場合、何から着手すればよいですか?
CASBやMDMなどの技術的統制を先に導入するのではなく、自社と主要委託先の利用実態の棚卸しから始めてください。専任担当者がいなくても、部門長へのヒアリングと支払い明細の確認だけで、主要SaaS上位30個程度の粒度なら優先的に手当てすべき穴を洗い出せます。
- 既存の業務委託契約にシャドーIT対策の条項を追加できますか?
覚書として追加できます。新規契約へのテンプレート組み込みと並行し、重要な既存取引先には契約更新を待たず情報セキュリティ覚書を締結し、事前承認義務・報告義務などを優先度の高い順に同等に課していくことをお勧めします。
- 小規模なフリーランスへの委託でも同じ管理を求めるべきですか?
契約規模に応じた濃淡は必要ですが、事前承認義務・報告義務といった最低限の条項は規模を問わず設定すべきです。相手の統制体制が薄い場合は、発注元側の監査頻度を高めたり、利用ツールを限定したチェックリストを渡したりして補うのが現実的です。
- シャドーITとシャドーAIは別々に対策を検討すべきですか?
シャドーAIはシャドーITの一部であり、棚卸し・ガイドライン・契約・監査という基本枠組みは共通です。ただし無料枠で即座に使える点が特有のため、企業版AIの提供とデータ入力可否の明確化を優先して上乗せしてください。



