大阪公立大学の約17万人分漏えいから考える｜委託先に残った「移行データ」を消させる仕組み

はじめに
何が起きたのか
なぜ移行データは委託先に残ってしまうのか
発注側が持つべき仕組み
まとめ
参考

はじめに

2026年11月13日、大阪公立大学が、10月に起きた情報基盤システムの大規模障害について第6報を公表しました。保守・運用を委託している日本電気株式会社（NEC）が管理するクラウドストレージから、学生・教職員など約17万名分の個人情報が漏えいしたという内容です。

注目すべきは、漏えいした情報の多くが、2021年度に行ったシステム移行作業で使われた「移行データ」だったことです。共同通信によると、大阪市立大学と大阪府立大学の統合（2022年4月開学）に伴うシステム移行のためにクラウドに保存したデータが、そのまま残っていたとされています。移行作業が終わってから数年にわたり、大学の機密情報が委託先のクラウドストレージに残り続けていました。

この記事では、事案の概要を整理したうえで、なぜ移行データは委託先に残ってしまうのか、そして発注側のIT部門やDX担当者が、契約・プロジェクト運営・運用の各段階でどんな仕組みを持っておくべきかを、コンサルタントの視点で考えます。

何が起きたのか

大学の第6報（2026年11月13日）とその別紙を整理すると、概要は次のとおりです。

10月2日：情報基盤システムのサーバーで障害が発生。10月8日まで授業を休講し、10月9日に対面授業を再開
10月20日：NECから、NECがシステム開発・保守業務を委託している事業者（大学の発表では「再委託先」）が9月下旬にサイバー攻撃を受けたことを起点に、大学のシステムへの不正アクセスと、NECが管理するクラウドストレージからの情報漏えいが確認されたと報告を受ける（翌21日に第5報を公表）
11月12日：NECから、漏えいした情報に機密性の高い個人情報も含まれていたと追加報告を受ける
漏えいした情報：約17万名分の学生・教職員のID、氏名、メールアドレス、生年月日など。このうち約1,400名分には、銀行口座番号（約20名分）、健康関連情報（約200名分）、パスポート画像（約200名分）、旅券番号（約1,000名分）など機密性の高い情報が含まれる
侵入の流れ：攻撃者は、委託先の端末やクラウドストレージから盗んだ正規のアカウント（管理者アカウントを含む）とパスワードを使って大学のシステムに侵入し、仮想化基盤や各種サーバー、バックアップデータなどを暗号化したと大学は判断しています

一方で、大学の情報システムそのものから個人情報が漏えいしたという明確な事実は、現時点で確認できていないとしています（可能性は否定できないとして、対象者には説明を行う方針）。大学は、NECが作業完了後も長期間にわたって機密情報を削除せずに保持していたことを「重大な問題」と受け止め、委託先の業務履行状況の管理を徹底するとしています。

NECも10月20日に、委託先への不正アクセスに起因する顧客のシステム障害と情報漏えいについて公表しています。また、NECにシステム運用を委託している大阪大学も10月21日、NECが契約に基づかずに協力会社と個人情報を含むファイルをクラウドストレージで共有し、作業終了後に削除すべきファイルを保持していたことなどが判明したとして、計7万7851人分の情報漏えいを発表しています（報道による）。「作業が終わったファイルが委託先に残っていた」という構図は、両大学に共通しています。

なぜ移行データは委託先に残ってしまうのか

今回の件は特殊な失敗ではありません。システム刷新プロジェクトの現場を見てきた立場から言うと、移行データが残る理由はどこの組織にもあります。

1. 移行データは「プロジェクトの持ち物」で、運用の管理台帳に載らない

本番データベースは資産台帳やアクセス管理の対象になりますが、移行のために抽出したCSVや、データ変換の検証用ファイル、突合結果のExcelは「作業用」の扱いです。誰の管理下にあるのかが曖昧なまま、プロジェクトの共有ストレージに置かれます。

2. 「消す」作業がWBSにない

移行計画には抽出・変換・投入・検証・本番切替のタスクはあっても、「委託先側の移行データを消して報告する」というタスクが入っていないことがよくあります。切替が終われば体制は縮小され、残ったファイルを片付ける担当者がいなくなります。

3. 消すと困るという心理が働く

切替直後は「後で不具合が見つかったら移行元データと突き合わせたい」という理由で、データを残しておきたくなります。保管期限を決めないまま残すと、そのまま忘れられます。

4. 共有ストレージに「何でも」置かれる

発注者と委託先、さらにその先の事業者が使う共有ストレージは便利な反面、設計書、手順書、アカウント情報、移行データが同じ場所にたまりがちです。今回も、クラウドストレージにアクセスする方法や管理者アカウントの情報が漏れ、侵入の足がかりになったと大学は見ています。

発注側が持つべき仕組み

ニュースでは「委託先の管理を徹底」とまとめられがちですが、発注側が「徹底して」と伝えるだけでは何も変わりません。仕組みとして残すべきポイントを、段階ごとに整理します。

契約：データの返却・削除と「削除の証明」を条項にする

業務委託契約や個別契約に、次の3点を明記します。

委託業務のために渡したデータ（移行データ、検証データを含む）は、業務完了時または発注者が求めたときに返却・削除すること
削除した事実を、対象・方法・日付・実施者を記載した書面（削除報告書）で提出すること
再委託先・再々委託先に渡ったデータも同じ扱いとし、元請けが取りまとめて報告すること

特に3点目が重要です。今回のように多層の委託構造では、発注者からは末端の事業者が見えません。再委託をどこまで認めるか、認める場合に何を条件にするかは、再委託承諾条項の記事でも整理していますが、データの削除責任まで元請けに負わせる書き方にしておくことをおすすめします。

プロジェクト：移行計画に「後片付け」のタスクと期限を入れる

移行計画書とWBSに、次のタスクを最初から入れておきます。

移行データの一覧化（どこに、何が、誰の管理で置かれているか）
保管期限の決定（例：本番切替後3か月で削除し、それ以降の突合は本番データで行う）
期限到来時の削除と削除報告書の受領
削除報告書の受領を、最終検収またはプロジェクト完了の条件にする

「検収条件にする」ことで、委託先にとっても後回しにできない作業になります。発注側のPMは、プロジェクト完了報告の項目に「委託先に残ったデータはない」と書ける状態をゴールにしてください。

運用：共有ストレージと特権アカウントを棚卸しする

運用・保守フェーズに入ってからも、次の点を年1回は確認します。

委託先と共有しているストレージの一覧と、中身の分類（設計書・手順書・個人情報・認証情報）
共有ストレージにパスワードや管理者アカウント情報を置かない、というルールの徹底
委託先が使う管理者アカウントの棚卸し（誰が、どの端末から、いつ使えるか）。常時有効にせず、作業の時だけ払い出す方式や、多要素認証、接続元の制限を検討する
バックアップを暗号化の被害から守る構成（ネットワークから切り離した保管など）になっているか

委託先評価シートにこれらの項目を加え、契約更新のタイミングで確認するのが現実的です。

体制と予算：「消す」「調べる」にも工数がかかる

削除報告書の作成、共有ストレージの棚卸し、特権アカウントの管理には、委託先の工数も発注側の工数もかかります。「セキュリティは委託先の責任範囲だから無償で」と考えると、形だけの報告になりがちです。保守契約の作業項目と費用に、こうした管理作業を明示的に含めておくことが、実効性を担保します。

自社の過去プロジェクトを点検する

今すぐできることとして、過去5年ほどのシステム刷新・移行プロジェクトを一覧にし、それぞれについて「委託先に移行データが残っていないか」「削除の報告を受けたか」を確認してみてください。報告を受けていないものは、委託先に削除の実施と報告を依頼します。今回の件は、まさに数年前のデータが問題になりました。

まとめ

大阪公立大学の事案は、委託先の事業者への攻撃から、NECが管理するクラウドストレージに残っていた2021年度の移行データを含む約17万名分の個人情報が漏えいしたものです。発注側が学べることは次のとおりです。

契約に、データの返却・削除と削除報告書の提出を明記し、再委託先分も元請けに取りまとめさせる
移行計画に、移行データの一覧化・保管期限・削除のタスクを入れ、検収条件にする
共有ストレージと委託先の管理者アカウントを定期的に棚卸しする
管理作業の工数を保守契約の費用に含める
過去のプロジェクトで残ったデータがないかを点検する

システムが新しくなっても、古いデータは委託先のどこかに残っているかもしれません。「移行が終わったデータは消えたのか」を、発注側から確認することから始めてみてください。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。