まず、まわりの言葉を一度そろえておきます。ここが混ざったまま対策の話をすると、話が噛み合わなくなります。

代表的なデータベースエンジンとして、IPA『安全なウェブサイトの作り方』改訂第7版は MySQL、PostgreSQL、Oracle、Microsoft SQL Server、DB2 を挙げています。この一覧のどれも使っていなくても、データベースを持っていないことにはなりません。

その理由が、法律の定義です。著作権法にはこう書かれています。

個人情報保護法にも、対象を個人情報に絞った同じ形の定義があります。3つ並べると、共通しているものがはっきりします。

e-Gov法令検索で2026年8月22日に確認。3つに共通するのは「検索できるように体系的に構成されていること」だけです。ソフトの種類も、電子か紙かも、件数も、要件に入っていません。

第1章 おわり — 次は第2章

個人情報保護委員会は毎年、個人データの漏えい等について受けた報告の件数を公表しています。令和7年度（2025年4月1日から2026年3月31日まで）の数字はこうでした。

出典：個人情報保護委員会『令和7年度 個人情報保護委員会 年次報告』（令和8年7月）。1つの事案が複数の類型に当たる場合はすべてに計上されるため、内訳の合計は100%を超えます。17,139件のうち委員会への直接報告は13,345件、委任先省庁を経由したものは3,794件でした。

次が、この記事でいちばん見てほしい表です。同じ報告を「どんな漏れ方だったか」で切り直すと、想像とはかなり違う姿が出てきます。

出典：同上。発生原因として同報告が挙げているのは、病院や薬局における要配慮個人情報を含む書類等の誤交付、クレジットカード等の誤送付、そして不正アクセス等によるものです。報告の多数派は、サーバーが破られた話ではなく、紙の取り違えです。第1章で見た「紙でもデータベースに当たる」という定義は、この数字と地続きです。

では、不正アクセスによる分はどうだったのか。同じ年次報告が、指導した事案でよく見られた原因を3つ挙げています。

出典：同上。3つのうち「データベース」という語が国の年次報告に原因として名指しで出てくるのは、3つ目です。

第2章 おわり — 次は第3章

データベースの中身が外に出るまでには、いくつかの段階があります。段階ごとに「気づける材料」と「自力で止められるか」が変わるので、そこを列にして並べます。

段階の並びは、個人情報保護委員会が原因として挙げた3類型と、IPA『安全なウェブサイトの作り方』改訂第7版が示すSQLインジェクションの脅威（非公開情報の閲覧、改ざんや消去、認証回避による不正ログイン、OSコマンドの実行）を突き合わせて筆者が整理したものです。4段階目に入った時点で、勝負は「防げるか」から「どれだけ早く気づけるか」に変わります。

入口になる2段階目は、大きく4つに分かれます。自社がどれを心配すべきかで、やることが変わります。

1つ目のSQLインジェクションについて、IPAは根本的解決を「SQL文の組み立ては全てプレースホルダで実装する」と示しています。文字列をつなげて命令文を作らず、値の入る場所を先に決めておく書き方です。

第3章 おわり — 次は第4章

個人情報保護委員会のガイドライン（通則編）は、何が「個人情報データベース等」に当たり、何が当たらないかを事例で示しています。抽象的な議論をする前に、この一覧を見るのがいちばん早いです。

出典：個人情報保護委員会『個人情報の保護に関する法律についてのガイドライン（通則編）』（令和8年6月一部改正）。分かれ目は「他人によっても容易に検索できる状態に置いているか」です。同じ名刺でも、山積みなら当たらず、五十音順に仕切ると当たります。

誤解として多いものを4つ、実際と並べます。

3つ目について補足します。暗号化は目的別に選ぶもので、ディスクごと暗号化する方式は盗難・紛失に、通信の暗号化は経路上の盗み見に効きます。アクセス制御の穴を暗号化で埋めることはできません。

第4章 おわり — 次は第5章

個人にとってのデータベース対策は、少し変わった形になります。自分の名前や連絡先が入っているデータベースは、ほとんどが他人の会社の中にあり、直接は守れないからです。できるのは、載っている数を減らすことと、1つ漏れたときの被害を他へ広げないことの2つです。

2番目の効果は地味ですが確実です。個人情報保護委員会が受けた報告のうち83.9%は顧客情報でした。つまり、漏れているのは主にどこかのサービスの会員である自分です。

第5章 おわり — 次は第6章

個人情報データベース等を扱う事業者には、技術的安全管理措置として4つの項目が求められています。ガイドラインは大企業向けの例と、中小規模事業者向けの現実的な例を分けて示しています。

出典：個人情報保護委員会『個人情報の保護に関する法律についてのガイドライン（通則編）』（令和8年6月一部改正）10-6。4項目の筆頭がアクセス制御です。第2章で見た「設定ミスによりデータベースへのアクセス制御が不適切」という指摘は、この義務に正面から当たります。

そのうえで、データベースそのものについて確かめておきたいことを7つに整理しました。上から順に、放置したときの被害が大きいものです。

3番と4番は、IPA『安全なウェブサイトの作り方』改訂第7版がSQLインジェクションの保険的対策として挙げている項目です（データベースアカウントに適切な権限を与える／エラーメッセージをそのままブラウザに表示しない）。6番は、上のガイドラインが求める「ログ等の定期的な分析」に対応します。

第6章 おわり — 次は第7章

データベースからの漏えいが疑われる場面では、技術的な調査と法律上の手続きが同時に走ります。順番を間違えると、どちらも遅れます。

切り離しても電源を切らない理由は、稼働中のメモリにしか残っていない情報があるためです。詳しくはデジタルフォレンジックの記事で扱っています。

報告の期限は、条文と通則編に具体的な日数が書かれています。ここは覚えるより、事故が起きたときに開く表として使ってください。

出典：個人情報保護法第26条、同法施行規則第7条・第8条、通則編3-5-3-3および3-5-3-4。日数の計算には土日・祝日も含めます（30日目や60日目が休日の場合はその翌日が期限）。不正の目的をもって行われたおそれ（第3号）に当たる事案は、第1号・第2号・第4号にも同時に当たる場合も60日以内です。速報の時点ですべて報告できるときは、1回の報告で速報と確報を兼ねられます。

なお、ランサムウェアによる被害については報告先が一本化されました。個人情報保護委員会は、政府全体としてのサイバー攻撃の被害報告一元化の方針に従い、令和7年10月1日以降、ランサムウェア事案による個人データの漏えい等（またはそのおそれ）は共通様式で報告できるとしています。

第7章 おわり — 次は第8章

この用語とセットで覚えると理解が早くなる語です。

第8章 おわり — 最後にFAQ