ブログ

警察庁の集計（令和7年版警察白書）によれば、2024年に国内で確認されたランサムウェア被害のうち、侵入経路が判明した有効回答100件中55件（55.0%）が「VPN機器からの侵入」でした（警察庁, 2025年）。「VPNを通しているから安全」――その前提そのものが、いま大きく揺らいでいます。クラウドAIや会議SaaSの利用が急速に広がる一方で、機密情報を外部のインフラに預けることには、契約や暗号化だけでは解決できない構造的なリスクがいくつも存在します。本稿では、その中でも見落とされがちな4つを整理します。

背景：AI活用が進むほど、大企業ほど"線引き"を進めている

総務省『令和7年版 情報通信白書』によれば、生成AIの業務利用について大企業の26.1%が「全社的に積極的に活用する方針」、29.6%が「活用する領域を限定する方針」、5.4%が「活用しない方針」と回答しています（総務省, 2025年7月）。つまり大企業の約3社に1社が、「使う／使わない」ではなく「どこまでなら使えるか」の線引きを進めているということです。問いは、もはや「AIを使うか否か」ではなく、「どのデータを外に出さずに済ませるか」へと移っています。

その背景には、漏洩事故の高止まりと大型化があります。東京商工リサーチが2026年1月に公表した最新の『2025年「上場企業の個人情報漏えい・事故」調査』によれば、2025年の事故件数は180件（前年比4.7%減）と高水準で推移する一方、漏えい・紛失した個人情報は3,063万人分（前年比93.1%増）と再び拡大しました。前年（2024年）は事故件数189件（過去最多）・漏えい人数1,586万人分でしたが、件数こそ微減したものの、1件あたりの規模が大型化している傾向が読み取れます（東京商工リサーチ, 2026年1月 / 2025年1月）。原因別ではウイルス感染・不正アクセスが100件超で全体の半数以上を占め、攻撃型の漏洩が主流になっています。「うちは大丈夫」という認識は、もう統計に支えられていません。

本論：見落とされがちな4つの構造的リスク

RISK 01 ／ 暗号通信の"前提"は永遠ではない

1つ目は、暗号通信そのものへの過信です。TLSの実装脆弱性や証明書の不正取得による中間者攻撃は、いまも継続的に報告されています。さらに近年議論されているのが「Harvest Now, Decrypt Later（HNDL）」と呼ばれる攻撃シナリオで、現在の暗号通信を保存しておき、将来の量子計算機が実用化されたタイミングで遡って復号する、という考え方です。米国NISTは2024年8月に、ポスト量子暗号の最初の標準としてFIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）を正式公開し、移行を呼びかけています（NIST, 2024年8月）。「いま暗号化しているから安全」という安心感は、時間軸を伸ばすほど揺らぐと考えるのが自然です。

RISK 02 ／ 借りている倉庫には"合鍵"がある

クラウドにデータを預けるということは、自社のデータを「借りている倉庫」に保管するのと同じ構図です。倉庫の管理会社は盗難防止策を何重にも講じていますが、それでも倉庫の合鍵を持つ人間がゼロになるわけではありません。大手クラウド事業者は、保守担当者のアクセスを契約・職掌分離・暗号化・監査ログによって極めて強く制限しています。それでも「物理的に不可能」になるわけではありません。ルート権限を持つSRE（Site Reliability Engineer：大規模インフラの信頼性を担う運用エンジニア）、KMS（Key Management Service：暗号鍵の管理サービス）の運用担当者、そして法的命令――米国のCLOUD Act（Clarifying Lawful Overseas Use of Data Act, 2018年成立）は、米国法の及ぶ事業者に対し、その管理下（custody and control）にあるデータについて、合法的な命令に基づく提出義務の考え方を明確化したもので、事業者の管轄範囲そのものを変えるものではないと米司法省は説明しています（U.S. Department of Justice, 2019年4月）。他人のインフラに預ける限り、データに技術的・法的に触れ得る人間の数は、ゼロにはなりません。なお、鍵管理を自社側に寄せる設計（Google WorkspaceのCSE、Google CloudのCMEK/EKM、AWSの外部鍵ストアXKSなど）を併用すれば、この残余リスクを相当程度まで縮小することは可能です。ただし運用負荷・可用性・機能制限とのトレードオフがあるため、守るデータの重要度に応じた設計判断が必要になります。

図2. 社内の機密データがクラウドAI／会議SaaSに渡るまでの流路イメージ

RISK 03 ／ 会議・議事録SaaSも"相手のクラウド"

3つ目は、見落とされがちな会議システムです。Web会議サービスが提供する録画・文字起こし・AI要約機能は、いずれも事業者のインフラ上にデータを保存する構造を持ちます。つまり、標準構成で利用する限り、事業者側の運用担当者が技術的にアクセスし得る構造はRISK 02と共通しています。

ただし、すべてのSaaSが同じ設計というわけではありません。たとえばZoomはエンドツーエンド暗号化（E2EE）を有効にすると、AI Companion・クラウド録画・ライブ文字起こしなどの便利機能が使えなくなるという明確なトレードオフを示しています。Microsoft 365にはCustomer Lockboxがあり、Microsoft側のコンテンツアクセスに組織の事前承認を必須にできます。Google MeetもCSE（クライアントサイド暗号化）を併用すればメディアをGoogle側でも復号できない構成にすることが可能です。つまり「利便性を取るか、統制を取るか」は選べるのですが、標準設定のまま使う場合は利便性に寄った構成になります。

経営会議、人事評価、M&A交渉、法務相談――これらの音声がどこに保存され、誰が触れ得るのかを、契約書だけから読み解くのは容易ではありません。会議の機密度に応じて、どの機能を有効にし、どこを制限するかという運用設計が重要です。

RISK 04 ／ クラウドAIを支える接続経路も"突破"されている

4つ目は、クラウドAIやSaaSへの接続を支える境界装置そのものの脆弱性です。警察庁の集計（令和7年版警察白書、2024年中の有効回答100件）では、ランサムウェア感染で侵入経路が判明したケースのうちVPN機器からの侵入が55件（55.0%）、リモートデスクトップ経由が31件（31.0%）と、テレワーク関連の経路だけで86%を占めます（警察庁, 2025年）。背景には、Fortinet FortiOS/FortiProxy の境界外書き込み（out-of-bounds write）脆弱性 CVE-2024-21762（CVSS 9.8、CISA KEV登録）や、Ivanti Connect Secure のゼロデイ脆弱性 CVE-2023-46805 / CVE-2024-21887 など、VPN装置そのものに高深刻度の脆弱性が連続して見つかっている事実があります（CISA KEV／Fortinet PSIRT, 2024年）。内閣サイバーセキュリティセンター（NISC、現・内閣官房サイバー安全保障体制整備準備室 NCO）は「サイバー攻撃を受けた組織における対応についてのガイダンス」（2022年3月）のなかでネットワーク貫通型攻撃への対応を整理しており、IPAも「情報セキュリティ10大脅威 2025」でこの脅威カテゴリを主要項目として取り上げています（IPA, 2025年1月）。「境界の中は安全」という前提は、もはや単独では成立しません。

図1. ランサムウェア感染経路の内訳（出典：警察庁「令和7年版警察白書」2025年）

一度漏れたら取り返せない情報の例

4つのリスクをふまえると、クラウドAIや会議SaaSに「そのまま」乗せてよいとは言いきれない情報があることが見えてきます。

領域	典型的な情報	漏洩した場合の主な影響
経営会議	業績見通し、投資判断、組織再編	株価変動、インサイダー疑義、損害賠償
人事評価・採用	個人情報、評価コメント、労務問題	個人情報保護法違反、ブランド毀損
知財・研究開発	出願前の発明、設計データ、ノウハウ	技術流出、先行優位の喪失
M&A・契約交渉	候補企業、条件、デューデリ資料	交渉破談、市場混乱
顧客機密・行政情報	顧客リスト、住民情報、機微情報	契約違反、刑事責任、信頼失墜

これらは「削除を要請したから大丈夫」では済まない情報です。暗号化、VPN、SaaSの契約は重要な防御層ではあるものの、それぞれに今回見たような構造的な弱点があります。重ね合わせれば確率は下がりますが、ゼロにはなりません。

まとめ：問題は"事業者の怠慢"ではなく"預けている構造"そのもの

本稿で見た4つのリスクは、特定の事業者の怠慢や、特定の脆弱性に紐づくものではありません。HNDL、CLOUD Act、SaaS事業者のアクセス、VPN貫通――いずれも「機密データを外部のインフラに預けて、境界をネットワーク機器で守る」という構造そのものから生まれています。だからこそ、契約や設定の追加だけでは根本的に解決しないケースがあります。

なお、クラウドAI事業者もこの構造的課題に手をこまねいているわけではありません。OpenAIはBusiness/Enterprise/APIプランのデータを既定で学習に使用しないとし、保持期間の制御も提供しています。Anthropicも商用提供物において入出力データを既定で学習に使用しない方針です。Microsoft、Google、AWSはそれぞれ顧客管理鍵（CMEK）やCustomer Lockbox、CSEといった仕組みで、事業者側のアクセスを制限する設計オプションを用意しています。ただし、こうした低減策を活かすためには、サービスごとの契約条件・設定項目・機能トレードオフを正確に理解した上で、自社の機密度に応じた設計判断を行う必要があります。

では、AIによる業務改善を諦める必要があるかというと、そんなことはありません。クラウドAIの統制機能を最大限に活用するのが一つの選択肢であり、もう一つは発想を変えて、「データを境界の外に出さない」前提でAIを動かすという選択肢です。後者のアプローチは「ローカルLLM」と呼ばれ、ここ数年で急速に実用域に入ってきました。次回は、その構造的なリスク回避策としてのローカルLLMを詳しく整理します。

ご相談ください

Link T&Bでは、ローカルLLM環境の構築・運用、社内文書検索（RAG）との連携、AI利用ポリシーの設計まで一貫してご支援しています。機密情報を扱うAI活用を安全に進めたい方は、ITソリューション事業のページをご覧ください。個別のご相談はお問い合わせから承ります。

関連記事

クラウドAIのデータは本当に安全か？ — ローカルLLMという選択肢 ／ 金融庁が規制強化する多要素認証とは？ — MFAの仕組みと対応のポイント ／ 中小企業のセキュリティ対策入門 — 今すぐ始められるセキュリティ対策