2026年10月、カラオケの第一興商は約872万件の顧客情報が漏えいした可能性があると発表しました。侵入されたのは同社のシステムではありません。業務を委託していた会社の、社員1人のパソコンです。同じ月、ビューカードは約403万件のメールアドレスが流出した可能性を公表しました。こちらも、原因は自社ではなく利用していた外部のメール配信サービス側の不正アクセスでした。自社が無傷でも、顧客情報は漏れる。この構造は、システム開発を外部に頼むすべての会社に関係します。
いま起きていることを、公表資料のとおりに並べる
第一興商の発表によれば、委託先である日本コロムビアグループの社員のパソコンがマルウェアに感染し、そのパソコンには委託業務のために顧客の氏名・性別・生年月日・メールアドレス・電話番号が一時的に保存されていました。感染の判明が10月1〜2日、委託先から第一興商への報告が10月5日、公表が10月8日。対象は顧客約863万件と従業員約9万件で、第一興商自身のシステムへの影響はないとされています。
出典: 第一興商「委託先における個人情報漏えいの可能性に関するお知らせとお詫び」（2026年10月8日）
ビューカードの発表では、利用している外部のメール配信サービスで不正アクセスがあり、約403万件のメールアドレスが閲覧・取得された可能性があるとされています。氏名・住所・電話番号・カード番号は漏えいの可能性がないと明記されています。
出典: ビューカード「外部サービスへの不正アクセスによるメールアドレス漏えいの可能性について」（2026年10月9日）
規模がさらに大きいのがKDDIの件です。KDDIがISP事業者向けに開発したメールシステムに、組み込まれていた第三者製ソフトウェアの脆弱性を突いた不正アクセスがあり、メールアドレス12,231,954件、うちパスワード7,616,173件が漏えいしました。不正アクセスの開始が5月16日、KDDIが侵入を確認したのが6月17日で、脆弱性は確認時点でソフトウェアの開発元も把握していないものでした。被害を受けたのはKDDIのシステムを使っていたISPの利用者で、au・UQ mobile・au one netのメールは別の設備のため対象外です。
出典: KDDI「ISP事業者向けメールシステムへの不正アクセスに関するご報告」（2026年7月6日、7月21日更新）
3件に共通するのは、顧客が情報を預けた会社と、情報が漏れた場所が違うことです。第一興商の顧客は日本コロムビアグループを知りません。ビューカードの会員はメール配信サービスの名前を知りません。ISPの利用者は、メールの裏側がKDDI製で、その中に第三者のソフトが入っていることを知りません。それでも、お詫びを出すのは顧客が名前を知っている会社です。
責任の線と、データの線は一致しない
個人情報保護法のうえでは、業務を委託した側に委託先の監督義務があります。つまり法律上の責任の線は、はっきり委託元に引かれています。問題は、データが実際にどこにあるかという線のほうが、責任の線よりずっと長く伸びていることです。
自社のサーバーにしかないつもりのデータは、委託先の作業用パソコンにコピーされ、メール配信のために外部サービスへ渡され、その外部サービスはさらに別のクラウド事業者の上で動いています。どこか1か所が破られれば漏れる。しかも破られた場所ほど、委託元からは見えません。第一興商の場合、委託先の感染判明から委託元への報告まで3日かかっています。見えない場所で起きたことは、知るのも遅れます。
ここから引ける教訓は「委託するな」ではありません。委託しなければ回らない業務は多く、外部サービスを使わずにメールを大量配信するのは現実的ではありません。引けるのは、データの線を短くするという方向です。
線を短くする3つの方法
渡さない。委託先に顧客データを渡す前に、本当に全項目が要るかを問い直します。第一興商のケースで一時保存されていたのは氏名・性別・生年月日・メール・電話番号でした。もし委託業務がメール配信だけなら、必要なのはメールアドレスと、せいぜい宛名です。生年月日や電話番号を渡す理由がないなら、渡さない。渡していなければ、漏れようがありません。
残さない。作業が終わったデータは委託先の端末から消す、という約束を契約に書き、実際に消えたことを確認する仕組みを持ちます。「一時的に保存していた」という表現は、裏返せば消す運用が決まっていなかったか、決まっていても守られていなかったことを意味します。残っていなければ、感染しても漏れません。
分ける。外部サービスに渡すデータは、そのサービスが必要とする最小限に絞ります。ビューカードの件で漏れたのがメールアドレスだけで済んだのは、配信サービスに氏名やカード番号を渡していなかったからです。これは被害を小さくした設計判断として評価できます。何をどこに置くかを分けておけば、1か所が破られても全部は失いません。
開発を外部に頼むときに、確認しておくこと
私たちは開発会社なので、ここからは自分たちが受ける側の話も含めて書きます。発注側が開発会社に聞くべきことは、セキュリティ対策の一覧ではなく、データがどこを通るかです。次の5つを聞いてみてください。
- 本番のデータを、開発や検証のために持ち出しますか。持ち出すなら、どの項目を、どこに、いつまで置くのか。本来は、本番データを使わずに済む仕組み（ダミーデータ、マスキング）があるかどうかで答えが変わります。
- 作業用の端末に、顧客データが残る場面はありますか。第一興商の件がまさにこれです。残る場面があるなら、消す手順と確認方法を聞いてください。
- 外部のサービスを、どこで使っていますか。メール配信、ログ収集、エラー監視、AIのAPI。開発会社が便利に使っている外部サービスに、御社の顧客データが流れていないか。流れているなら、そのサービスの所在と契約を確認します。
- 組み込んでいる他社製の部品を、把握していますか。KDDIの件は、自社開発のシステムに組み込んだ第三者製ソフトウェアの脆弱性でした。何が入っているかの一覧（SBOMと呼ばれます）を出せるかどうかは、把握しているかどうかとほぼ同じ意味です。
- 何か起きたとき、何日以内に御社へ報告しますか。個人情報保護委員会への報告は、発覚から速報が3〜5日以内、確報が30日以内です。委託先からの報告が遅れれば、委託元の報告も遅れます。報告までの日数を契約で決めておくべき理由です。
この5つに具体的に答えられる開発会社は、データの線を自分で把握しています。答えが「セキュリティには気をつけています」であれば、把握していません。開発会社の選び方に、この観点は見積書とは別に加えておく価値があります。
AIで開発する時代に、この問題はどう変わるか
AIを使った開発では、外部サービスの数が増えます。AIのAPI、コードを置く場所、自動テストを回す環境。便利な部品を組み合わせて速く作る分、データが通る場所も増えます。つまり、データの線は放っておくと長くなる方向にあります。
だから、速く作る前に決めることがあります。顧客データをAIに読ませるのか、読ませるなら何を、どのサービスで。開発中に本番データを触らない前提を守れるか。私たちがお客さまの現場にチームを置く形にこだわっている理由のひとつもここにあります。データを持ち出して自社で作るのではなく、データのある場所で作れば、線は伸びません。
まとめ——漏れた場所ではなく、置いた場所を数える
委託先から漏れた、外部サービスから漏れた、組み込んだ部品から漏れた。この秋の事例は、どれも「自社のサーバーは無事だった」会社の事例です。防御を自社の中で完結させても、データが外にある限り、守れる範囲はそこまでです。
やるべきことは、漏れた場所を責めることではなく、自社の顧客データがいま何か所に置かれているかを数えることです。数えてみて、理由を説明できない置き場所があれば、そこから消す。それが、この構造に対して発注側ができる、いちばん確実な対策です。
データの線を短くする考え方をログイン機能に当てはめ、パスワードやセッションの生の値を持たないように作った見本を、passkey-auth-starter としてコードと解説つきで公開しています。
御社のデータが、いま何か所にあるか。
JumpStackは、お客さまの現場にAIチームを配置するFDEを軸に、課題の定義から実装・運用までをご一緒しています。データを持ち出さずに作る進め方や、いま使っているシステムのデータの線の棚卸しから、ご相談ください。
データの置き場所を相談する