COLUMN
コラム
2026年10月09日
データ漏洩のリスクを回避。ローカルLLM×AI駆動開発のリアル。
1. 2026年、情報漏洩のニュースが止まらない
「また、情報漏洩か」——2026年に入ってから、そう感じるニュースに何度も出会っていないでしょうか。データ漏洩のリスクは、もはや一部の企業だけの問題ではなくなっています。ローカルLLMを使った情報漏洩対策が注目される背景には、こうした報道の積み重ねがあります。
直近の事例を振り返るだけでも、その規模の大きさに驚かされます。KDDIは2026年7月、複数のISP事業者に提供するメールシステムが不正アクセスを受け、約1,223万件のメールアドレスと約762万件のパスワードが流出したことを公表しました。原因はシステムに存在した未知のソフトウェア脆弱性で、総務省は暗号化対策の不備や公表までに22日を要した対応の遅れを問題視し、行政指導を行っています。
政府機関も例外ではありません。デジタル庁が運用するガバメントソリューションサービス（GSS）では、保守運用担当者のアカウントが悪用され、VPNの脆弱性を突かれたことで約24.6万件の個人情報が流出した可能性があると2026年9月に公表されました。「ゼロトラスト」を掲げる基盤であっても、委託先や保守アカウントという"人の通り道"は防ぎきれなかったのです。
アサヒグループホールディングスも、2025年9月のサイバー攻撃に関する調査を継続しており、2026年7月には取引先関係者の情報約37.8万件を追加公表し、漏えいのおそれがある総件数は約230万件に拡大しています。1件の攻撃が、1年近く経っても被害範囲を広げ続けるケースがあることを示しています。
2. 漏洩の原因は「攻撃」だけじゃない。委託先・人的ミスという構造問題
情報漏洩というと「外部からの攻撃」をイメージしがちですが、実態はもっと複雑です。個人情報保護委員会が公表した令和7年度の年次報告によれば、民間事業者における個人データの漏えい等報告は17,139件にのぼり、行政機関からの漏えいは前年の1,951件から2,278件へ増加しました。その背景として、ランサムウェアによるサイバー攻撃が相次いだことが指摘されています。
さらに見過ごせないのが、人的要因による漏洩です。2026年4月には、東京海上日動火災保険・三井住友海上火災保険・あいおいニッセイ同和損害保険の損保大手3社からトヨタ自動車に出向していた社員が、組織表や会議議事録、従業員・取引先関係者の個人情報を長年にわたり出向元に持ち出していたことが報じられました。出向という働き方そのものが「情報の帰属や責任の線引きを曖昧にしやすい」構造を持つことが、問題の根底にあると指摘されています。
つまり情報漏洩は、「攻撃を受けるかどうか」だけの問題ではなく、委託先・取引先・出向者といった自社の管理が及びにくい経路から起きる構造的なリスクだということです。この構造を理解しないまま対策を講じても、次の漏洩は別の経路からやってきます。
AI駆動開発伴走セミナーでは、こうした情報管理の構造的課題を踏まえたうえで、安全にAIを活用しながら開発生産性を高める実践的な進め方を学ぶことができます。
3. 生成AIの活用自体が、新しい漏洩経路になっている
ここまでの事例はいずれも「既存の情報システム」が舞台でしたが、もう一つ急速に存在感を増しているリスク経路があります。生成AIの業務活用です。
NTTデータの調査によると、生成AIを全社的に利用している企業では「社内の機密情報（個人情報含む）が生成AIに入力され、それが外部に漏えいする」という懸念が59.9%で最多の回答となりました。実際に、機密情報を含むプロンプトの54%が無料版のサービスに入力されているというデータもあり、懸念と実態のギャップが浮き彫りになっています。
この懸念は机上の空論ではありません。生成AIの情報漏洩リスクを分析した記事では、大手電機メーカーの従業員がChatGPTにソースコードや会議資料などの社内機密情報を入力し、情報漏洩につながった事例が報告されています。クラウド型の生成AIは、入力データが外部サーバーに送信される仕組みであるため、設定によっては入力内容がモデル改善に利用され、意図せず機密情報が外部に渡ってしまう可能性があるのです。
AI駆動開発の現場ではさらに注意が必要です。AI駆動開発特有のセキュリティリスクを整理した解説では、AIコーディングアシスタントは公開ファイルと非公開ファイルを自動的に区別できず、作業ディレクトリ内の機密情報やハードコードされたシークレットをそのまま読み込んでしまう可能性があると指摘されています。便利に使っているつもりのAIコーディングツールが、気づかぬうちに社内の機密情報をクラウドへ送り出す窓口になりかねません。
つまり、「生成AIを使うこと」自体が、委託先や出向者と同じように、自社の目が届きにくい新しい漏洩経路になりつつあるということです。
4. ローカルLLM×AI駆動開発なら、データを外に出さずにAIを使える
「情報漏洩が怖いから、生成AIの活用を諦める」——これは本末転倒です。実は今、この二者択一を回避する選択肢が現実的になっています。それがローカルLLMです。
ローカルLLMの企業導入動向を解説した記事によれば、NVIDIAの最新世代GPUや、DeepSeek・Llama 4といった高性能なオープンソースモデルの台頭により、自社環境でLLMを運用するハードルは着実に下がっています。ローカルLLMは自社のサーバーやオンプレミス環境で動作するため、クラウドAPIにデータを送信する必要がなく、機密情報を外部に出さずにAIを活用できる点が最大の特徴です。金融・医療・製造・公共といった、セキュリティ要件の厳しい業界を中心に導入検討が増えているのも、この構造的な安心感があるからです。
AIエージェント基盤であるCaptain.AIも、クラウドLLMとローカルLLMの両対応を前提に設計されており、機密データを扱う業務ではローカルLLMに切り替えて安全に運用するという選択ができます。
そしてHexabaseは、情報漏洩のリスクを抱えたまま生成AIの活用を迷う開発現場に向けて、新しいサービス「ローカルLLM×AI駆動開発」を提供しています。社外にデータを一切出さない環境で、コーディングAIによる開発支援を受けられる仕組みです。「クラウドに預けないと使えない」という常識を変え、データ主権を保ったままAI駆動開発の生産性向上を実現できます。
なお、ローカルLLM自体は自社環境に置くとしても、コードのビルド・テスト・デプロイを回す検証環境まで自前で構えるのは負担が大きいものです。クラウド型のマネージドコンテナサービスとして検証環境で選ばれる「Kubo」なら、月額8,800円〜という価格でKubernetes環境をすぐに構築でき、機密データを扱わないCI/CDパイプラインの検証環境を素早く整えられます。
5. まとめ
2026年に報じられた情報漏洩の数々は、サイバー攻撃・委託先経由・人的ミスという複数の経路から起きており、どの企業にも無関係ではいられない構造的なリスクであることを示しています。そこに生成AIの業務活用という新しい経路が加わりつつある今、「使うか、守るか」の二者択一から抜け出すことが求められています。
クラウドに依存せず、データを自社に留めたままAIを活用する——ローカルLLM×AI駆動開発は、そのための現実的な一歩です。データの主権を手元に残しながらAIと向き合う企業が、これからの開発現場の標準になっていくはずです。
自社の開発環境へのローカルLLM導入を検討している方は、無料相談で気軽に話を聞いてみてください。
こちらの記事もあわせてお読みください