シャドーAI: クライアントがMSPに伝えていないこと

マネージドサービスプロバイダー (MSP) は、クライアントのテクノロジー環境を理解していることが求められます。 どのエンドポイントが管理されているか、どのアプリケーションが業務に重要か、どのシステムにパッチ適用やメンテナンスが必要か、機密データがどこに存在し、誰がアクセス権を持っているかを把握していなければなりません。 しかし今日では、IT部門やMSPの関与なしに、重要なテクノロジーに関する意思決定が行われるケースが増えています。

クライアント環境において、これはさまざまな形で行われています。

• マーケティングチームが、AIデザインプラットフォームを使用してキャンペーン用のビジュアルを作成する
• 営業担当者が、顧客とのやり取りを要約するためにAIアシスタントをCRMに接続する
• 人事マネージャーが、評価のために履歴書を公開チャットボットにアップロードする
• 開発者が、AIコーディングツールを使用して会社のソースコードのトラブルシューティングを行う

上記のようなケースは、MSPがまったく気付かないうちに起きている可能性があります。

それは必ずしも、クライアントが意図的に情報を隠しているわけではありません。 実際問題として、AIの使用は高度に分散化しています。 従業員や個々の部門は、ブラウザ、クレジットカード、OAuthの承認があれば、シャドーAIと呼ばれる強力なツールにアクセスできます。そのため、ITチームやサービスプロバイダーがその存在を認識する前に、ましてや十分に評価できるようになる前に、新しいテクノロジーが組織内に導入される可能性があります。

MSPにとって、これは差し迫った問題となります。可視化されていない環境を効果的に保護することはできず、存在を把握していないものは、防御することも不可能だからです。

シャドーAIがMSPにセキュリティリスクをもたらす仕組み

承認されたITチャネル外のテクノロジーが従業員によって導入される事例が後を絶たないため、シャドーITは、組織にとって長年にわたる課題となっています。 またシャドーAIは、潜在的な漏洩リスクをさらに増大させます。 シャドーAIとして使用されるアプリケーションは、単に業務上のシステムと並存するだけではありません。機密性の高い企業データとやり取りし、当初の範囲を超えて既存のプラットフォームに接続し、ますます自律的にタスクを実行するようになっています。

最近の調査では、こうした行動がどれほど広まっているかが明らかになっています。KPMGの2025年版シャドーAIに関するレポートによると、調査対象となった米国の従業員の44%が、組織のポリシーやガイドラインに違反していると認識しながらAIを使用していたことが判明しました。 それは必ずしも悪意によるものではなく、多くの場合、利便性、スピード、効率性を重視したことによるものです。 今日の職場環境ではそうした資質がますます評価されるようになっており、従業員が反復的なタスクを自動化したり、業務パフォーマンスの向上に役立つと考えるツールを導入したりすることを後押ししています。

しかし、効率性のさらなる追求は、リスクの排除にはなりません。

MSPにとって真に懸念となるのは、認識されていない各アプリケーションが環境にもたらすものです。それはつまり、確立された監視体制の外で動作する新たな接続、権限、潜在的なアクセス経路です。

AIツールの背後に潜むアクセスと権限

AIの使用がセキュリティに及ぼす影響について、そのテクノロジーを導入する人が必ずしも把握しているわけではありません。 一見単純な接続に見える場合でも、直結するタスクをはるかに超える範囲に及ぶ権限やアクセス権が、それによって導入されることがあります。

ある従業員が、AIアプリケーションを業務プラットフォームに接続する場合を考えてみましょう。

ユーザーにとっては、「許可」ボタンをクリックするだけの簡単なプロセスかもしれません。 しかしその許可が、ファイルの取得、連絡先へのアクセス、顧客情報の操作、他のアプリケーションへの接続といった一連の権限の承認につながっている可能性があります。

こうした接続は、最初のやり取りの後も継続するため、MSPがその存在を把握していないアクセスを生じさせる可能性があります。 MSPが引き続きエンドポイントを管理し、ユーザーアカウントの安全を確保し、基盤となる業務アプリケーションを保護しているとしても、それらの間に存在する接続については把握していない可能性があります。

まさにここで、AIが、従来のシャドーITの概念を再構築し始めます。 何のアプリケーションが使用されているかということ自体は、もはや未知の要素ではなくなっています。 MSPはまた、AIサービスがアクセスできる情報、付与されている正確な権限、それを支える認証情報、そのアクセス権が現在も必要かどうかを把握する必要があります。

監視体制の不備によるこうした影響は、すでに現れ始めています。 IBMの2025年データ侵害に関する調査によると、侵害を受けた調査対象組織の63%が、AIガバナンスポリシーを策定していないか、策定を完了していなかったことが明らかになりました。 またポリシー導入済みの企業のうち、未承認AIの使用を定期的に監査しているのは34%にとどまりました。 シャドーAIの使用度が高い組織では、未承認AIの使用がほとんどない、またはまったくない組織と比べて、データ侵害によるコストが平均で$670,000高くなっていました。

AIアクセスの可視性がMSPにとって必要な理由

MSPにとって優先すべきは、クライアントによるAI使用を制御すべきかどうかではなく、その使用によって自社が保護する責任のある環境がどのように変化するかを理解することです。

チームがこれらのアプリケーションを導入するのは、実際の問題を解決し、時間のかかるタスクを簡素化できるからです。 組織レベルでも、生産性を高める技術を模索するインセンティブは、同様に強いと言えます。

より効果的な対応は、MSPがクライアントに問いかける質問を見直すことから始まります。

クライアントが正式に承認したAIアプリケーションを文書化することは良い出発点となりますが、それだけでは、全体像の一部を把握しているにすぎません。 MSPが可視化すべき事項は、次のようなものです。

• 従業員が実際に使用しているAIサービスは何か
• それらのサービスがアクセスする業務アプリケーションやデータは何か
• どのOAuth権限が付与されているか
• どのAPIキーまたはサービスアカウントがそれらの接続を可能にしているか
• それらのツールの接続後に実行が許可されている操作は何か

最も重要なのは、そのアクセス範囲がどこまで及ぶのか、そしてそのアクセスが実際に必要な範囲を超えていないか、という点を把握することです。

こうした質問をすることで、議論の焦点がポリシーの定義から実践的なリスク評価へと移行します。 承認済みAIの使用であっても、管理の不備が生じる可能性はあります。

• CRMに接続されたAIアシスタントには、本来のタスクを実行するのに必要な範囲を超えて、顧客レコードへのアクセス権が付与される可能性があります。
• また同じAIサービスであっても、ある部門では承認されたデータソースのみに制限されている一方、別の部門ではより広範なアクセスが許可されている場合があります。
• 一時的なプロジェクトのために付与されたアクセス権は、作業終了後も長期間アクティブなまま残る可能性があります。

さらに、承認されたからといって、アクセス権が適切であるとはかぎりません。

これらの変化に対応するには、たった一度調査を実施し、実態を把握するだけでは不十分です。 新しいアプリケーションが次々と登場し、既存のSaaSベンダーがAI機能の追加を続ける一方で、つい最近まで人間の直接的な関与が必要だったタスクを、自律型エージェントが実行するようになっています。 アクティビティの監視は、MSPのセキュリティレビューやクライアントとの継続的な対話において、標準的なプラクティスとすべきです。

AIディスカバリーに対して業界の注目が高まっていることは、そのニーズの緊急性を反映しています。 IT部門の承認なしに使用されている生成AIアプリケーションの特定、使用パターンの分析、アプリケーションのリスク評価、潜在的なデータ漏洩の監視を行う専用のセキュリティ機能が次々と登場しています。 社内に同等のリソースを持たない小規模な組織にとって、これはMSPが貴重な可視性と指針を提供できる分野となります。 AIディスカバリーは、クライアント環境全体の可視性を維持する上で急速に不可欠な要素となりつつあります。

AIディスカバリーを導入することで、管理者は、使用パターンの確認、未承認のアプリケーションの特定、アプリケーションのリスク評価、アクセス権限の評価、潜在的なデータ漏洩の監視を行うことができます。 これらの機能により、従来のIT監視の対象から漏れてしまう可能性のあるAIアクティビティを可視化できます。

MSPにとって、AIディスカバリーは、クライアント環境全体の可視性を維持する上で急速に不可欠な要素となりつつあります。

MSPがクライアントとともにAIガバナンスを強化する方法

ほとんどの組織にとって、こうした問題を解決することは技術面だけでなく、コミュニケーションの面でも課題となります。

従業員が、AIに関連するどのような決定がセキュリティに影響を及ぼすか、あるいはMSPの関与を必要とするかを認識していない場合、この不備はさらに広がる傾向があります。 一見すると単純なものに思えるアプリケーション、統合、部門単位の購入であっても、本来の用途をはるかに超える新たな権限、認証情報、アクセス要件をもたらす可能性があります。

MSPにとって、より強固なAIガバナンスの確立は、クライアントがAIに関連する変更をいつ、どのようにMSPに伝えるかについて明確な基準を設定することから始まります。 そうした話し合いでは、次のような質問をクライアントに問いかける必要があります。

• チームが試験的に導入している新しいAIツールは何ですか？また、それらは業務における使用が承認されていますか？
• 機密システムや業務上重要なアプリケーションにAIツールを直接接続している部門はありますか？
• これらのツールで共有されている会社、顧客、その他の機密データは何であり、送信後のデータは最終的にどこに送られますか？
• それぞれのAI統合は誰が所有しており、長期的なアクセス管理に責任を負うのは誰ですか？
• ツールの導入以降、権限の拡大や変更が行われましたか？
• 以前に承認された統合は現在も必要でしょうか？それとも、本来の業務上の必要性がなくなった後もアクセス権が残ったままになっていませんか？

こうした質問から議論を開始し、クライアント環境の変化に合わせて常に更新を重ねることで、MSPは、クライアント環境に未管理のレイヤーが新たに追加される前に、AIアクティビティを把握することができます。 さらに重要なのは、これにより、MSPはアクセス、権限、監視を疎かにすることなく、クライアントが迅速にAIの活用を進められるよう支援できることです。

目的はシンプルです。MSPは、未承認のツールが企業のデータやシステムにアクセスする前に、AIデプロイメントをリアルタイムで可視化する必要があります。

MSPがクライアント環境全体でAIアクセスを保護する方法

これまで把握されていなかったAIの使用を発見することは、問題のほんの一部を解決するにすぎません。 そうしたアクティビティが確認できたら、MSPが必要とするのは、すべてのクライアント環境でそれを一貫して管理する方法です。

AIアシスタント、統合、エージェントは、最終的には認証情報、権限、業務システムへの接続に依存しています。 これらの経路を保護し、特権を必要な範囲だけに限定し、要件の変更に応じて権限を調整する必要があります。 大規模な運用を行うMSPにとっての課題は、クライアント環境が進化する中で、複数のクライアントに対してこれらの原則を一貫して適用することです。

Keeperは、まさにそれを実現するための統合プラットフォームをMSPに提供します。 Keeperは、認証情報セキュリティ、特権アクセス、シークレット管理、エンドポイント特権管理をゼロトラスト・ゼロ知識アーキテクチャ内に統合することで、分断された別のレイヤーをセキュリティスタックに追加することなく、MSPが人間およびマシンのアイデンティティを大規模に統制できるように支援します。

最も重大なAIリスクは、MSPがすでに管理しているアプリケーションからもたらされるとは限りません。

誰も言及しようと考えなかったものから生じる可能性があります。

Keeper MSPパートナープログラムの詳細をご覧ください。クライアント環境全体において、AIの可視性の隙を解消するうえでKeeperがどのようにMSPを支援しているかをご確認いただけます。