データ漏えい事例に学ぶ中小企業のAI時代セキュリティ点検実務

タイムズカーは9月25日にWebシステムへの不正アクセスを検知しました。
第2報では約660万アカウントの漏えいを公表し、退会済みの人なども対象に含めています。
9月29日の第3報では、本人確認書類が漏えいしたアカウントは約160万件と説明しました。
両者は異なる集計範囲であり、足し合わせる数字ではありません。

物語コーポレーションは10月5日、焼肉きんぐのアプリ会員情報10,788,963件の漏えいを公表しました。
不正アクセスを確認したのは10月2日、漏えいの判明は翌3日です。
公表時点では侵入経緯を調査中としていました。

ローソンの事例と自社で見る範囲

ローソンは10月8日、ローソンIDの2,155,345件とアプリ予約の26件を対象とする漏えいを公表しました。
同社は、利用者本人へ情報を表示するための機構が不正アクセスを受けたと説明しています。

3社の原因を同じ攻撃手法と決めつけることはできません。
自社では、保管データの種類、退会後の保管範囲、本人以外への表示を防ぐ仕組みを確認しましょう。
ここで扱う公表内容から、AIの関与を示す事実は確認していません。

お問い合わせ

中小企業の被害状況と統計の読み方

大規模な漏えい事例を、自社と無関係な事件として扱うのは適切ではありません。
警察庁の2026年上半期の情勢資料では、ランサムウェア被害組織の規模別で、中小企業が約6割を占めると説明しています。
ランサムウェアは、データを暗号化して使えなくし、復旧の対価などを要求する不正プログラムです。

被害報告の構成比と自社の危険度

約6割という値は、被害を報告された組織に占める構成比です。
中小企業の約6割が被害に遭ったという意味ではなく、企業規模別の被害確率も比較できません。
ただし、中小企業にも被害が発生していることは確認できます。

IPAの2024年度調査速報でも、2023年度に被害を受けたと答えた975社の35.1%が、個人情報の漏えいを挙げました。
これは被害企業への複数回答で、全国の中小企業全体に対する割合ではありません。

点検を優先するデータと業務

自社の優先順位は、保有情報と業務停止の影響から決めます。
応募者の履歴書、顧客の連絡先、請求データでは、閲覧できる担当者も復旧の順番も異なるためです。
経営者はIT担当者と、漏れると困る情報と、止まると事業を続けられない業務を先に特定してください。

AI・RAGで増えるデータの参照経路

生成AIへの入力と社内AI検索では、情報を渡す経路が異なります。
2026年10月時点の点検では、利用するサービスの契約条件と、自社が作る検索の仕組みを分けて確認します。

外部AIサービスへ入力する情報

個人情報保護委員会は、個人情報の入力が利用目的の達成に必要な範囲か、確認するよう注意喚起しています。
個人データの機械学習への利用など、応答の出力以外の取扱いにも確認が必要です。

会社で認めたAIでも、履歴書や顧客一覧を自由に入力できるとは限りません。
管理担当者は、保存期間、削除方法、管理者の閲覧範囲を確認し、許可するデータを業務ごとに決めます。
氏名だけを消しても、経歴や所属先から本人が分かる情報には注意が必要です。

社内AI検索に複製する文書

RAGは、社内文書などを検索し、見つけた内容をAIの回答に使う仕組みです。
接続用アカウントが読める情報を、そのまま全社員の検索対象にすると、閲覧範囲を広げるおそれがあります。

Microsoftの文書単位アクセス制御の説明でも、検索時の利用者照合と権限情報の同期を扱っています。
自社でも、元文書の権限変更や削除を、検索用に分割・複製したデータへ反映できるか確認してください。
人事部限定の面接評価を例に、権限のない利用者の検索結果や回答へ含まれないことを試験します。
権限変更後は、過去の回答や一時保存データに残る範囲も確認対象です。

RAG導入前のデータ・文書・権限設計｜社内AI検索の準備ガイド

RAGを使った社内AI検索は、文書をベクトルDBへ入れるだけでは業務で使える状態になりません。本記事では、RAG導入前に企業が整えるべきデータ、文書、権限、更新責任、検索品質の確認項目を実務視点で整理します。

Web・アプリと管理者アカウントの点検

認証は利用者が誰かを確かめる処理、認可はその人に許す閲覧や操作を決める処理です。
点検では、この2つを区別して記録を残します。

管理者と遠隔接続の認証

メール、クラウド、会員管理画面、VPNなどの遠隔接続を一覧化し、管理者を確認します。
VPNは、社外から社内環境へ接続する際などに使う仮想専用網です。
MFAは、パスワードに加えて別の要素で本人を確認する多要素認証です。
管理者や外部から入れるアカウントを優先して適用し、不要なアカウントを停止しましょう。

担当者は、有効化した設定と対象一覧、例外の理由を記録します。
MFAだけでは機器やソフトウェアの脆弱性を解消できないため、更新状況とサポート期限も保守担当者へ確認してください。
適用できない機器は、接続制限や更改の担当と期限を決めます。
アクセスログの保存先と点検担当者も定め、不審なログインを定期的に確認します。

利用者ごとの表示と操作範囲

開発会社には、自社の検証環境で、異なる権限のテスト利用者を使った確認を依頼します。
画面の表示だけでなく、画面の裏側でデータを返す処理でも、他人の情報を取得できないことが確認対象です。

ボタンを隠すだけでは、操作そのものを制限した証拠にはなりません。
担当者は試験した機能、利用者の権限、期待結果と実際の結果を残します。
権限外の情報が見える場合は、該当機能を制限し、修正の確認が終わるまで公開やAI連携を進めない判断が必要です。

外部チームとの共有範囲と終了処理

開発会社や採用支援会社へ情報を渡す場合、発注側は共有目的と責任者を決めます。
国内外を問わず、業務に必要な範囲と、作業終了後の処理を具体化することが出発点です。

作業ごとに発行するアクセス権限

点検例として、日本とインドの開発チームが問い合わせ機能を改修する場合を考えます。
画面の検証には、本番の顧客一覧を丸ごと渡さず、架空のテストデータで対応できるか確認します。
実データが必要なら、承認者が対象項目と期間を絞り、作業者個人のアカウントで利用させます。

共有IDでは、誰が操作したかを追いにくくなります。
契約書の守秘義務に加え、再委託先の閲覧、個人端末への保存、生成AIへの入力可否を、双方で読める作業ルールにしてください。
海外チームと連携する際は、日本側の判断者と現地側の連絡担当、障害時の連絡方法も決めます。
海外から個人データへアクセスする構成では、保存先と契約形態を法務担当者にも確認します。

契約終了と担当交代の確認記録

作業終了時には、システム管理者がアカウントや接続用の認証情報を停止します。
発注担当者は、共有フォルダだけでなく、端末へ取得したファイル、検索用の複製、チャットへの添付も確認対象として委託先へ伝えます。

バックアップなど即時削除できない保存先は、保管期限と利用制限を記録します。
本人確認書類や候補者情報は、残す目的と期間も確認し、削除対象と法令等に基づく保存対象を分けてください。
担当者の交代でも同じ終了処理を行い、発注側が完了記録を保管します。

AIエージェント開発を外注する前に確認すべき権限設計と検収項目

問い合わせ対応、営業資料作成、社内ナレッジ検索、請求確認、プロジェクト進捗整理などをAIエージェントに任せたい企業は増えています。本記事では、AIエージェント開発を外注する前に、発注者が確認すべき権限設計、認証認可、承認フロー、監査ログ、検収項目を整理します。

バックアップと事故発生時の対応準備

バックアップの取得と、業務を再開できることは別に確認します。
IPAの中小企業向けガイドライン第4.0版も踏まえ、自社では復旧手順と事故時の役割を点検しましょう。

復元して確認する範囲

システム担当者は、必要なデータを隔離した検証環境へ戻し、利用できるか試します。
ファイルを開けるだけでなく、権限設定や業務アプリとの接続も確認する必要があります。
本番環境と同じ管理権限でバックアップまで変更・削除できる状態は、保管方式の見直し対象です。

復旧記録には、対象業務、使用したバックアップの時点、復旧に要した時間、戻せなかった範囲を残します。
経営者が許容する停止時間やデータの欠落と照合し、不足があれば取得頻度や保管先を修正してください。
バックアップがあっても、外へ漏れた情報を回収できるわけではありません。

発覚時に連絡する相手と残す証拠

経営者、システム管理者、保守会社の連絡先と、接続停止を判断する担当者を事前に決めます。
異常を検知した場合は、被害の拡大を防ぎながら専門家とログなどの証拠を保全し、操作時刻と対応内容を記録します。
証拠を消す可能性がある初期化や上書きを、現場だけの判断で進めないことも必要です。

個人データの漏えい等が疑われる場合は、個人情報保護委員会の案内に沿い、報告・本人通知の要否と期限を確認します。
原因の確定を待って初動を遅らせず、警察や専門家への相談も進めてください。

中小企業の初回点検とAI利用の開始判断

初回点検では、経営者が取りまとめ担当を指名し、各担当者が確認記録を持ち寄ります。
次の項目はPhinxが提案する実務点検であり、公的な認証基準ではありません。

担当者が残す点検結果

製品の導入有無だけでは、対策が機能しているか判断できません。
担当と証拠を組にして、未確認項目を明確にします。

データ所在：業務担当者が、保管先、用途、閲覧者、保管期限を記録する。
認証：管理者が、MFA対象、例外、機器の更新状況を確認する。
認可：開発・保守担当者が、他人の情報を取得できない試験結果を残す。
外部共有：発注担当者が、共有先、AI入力可否、権限停止と削除の記録を揃える。
復旧：システム担当者が、復元結果と経営者の許容範囲との差を記録する。
AI接続：導入担当者が、利用目的、許可データ、サービス条件、権限変更の確認結果を残す。

未確認の範囲を除いた限定試行

AIへ接続する範囲は、データの責任者が決まり、利用を許可され、必要な復旧確認が済んでいることを開始条件にします。
1つでも未確認なら、該当データやシステムの接続を保留してください。
これらが揃っても安全の保証にはならず、法令・契約上の条件や公開前の検証は別途確認が必要です。

図では、責任者、接続許可、復旧確認の順に判断します。
承認済みのデータだけで利用者を限定して試し、問題がない範囲を確認してから広げましょう。
本番の顧客情報を外した検証なら、既存環境の是正と並行して進められます。

まとめ

中小企業のデータ漏えい対策は、保管している情報と業務のつながりを整理する運用上の課題です。
会員情報、本人確認書類、応募者情報では、外部へ渡った場合の影響も、社内で必要な閲覧範囲も異なります。
AIや外部人材を活用する際も、その違いを残したまま共有先を決める必要があります。

初回点検では、経営者が責任者を置き、担当者が確認結果を記録してください。
認証と認可の試験、委託先の終了処理、復元できることの確認を、業務ごとに進めます。
AIへ接続するデータは、利用目的と権限、外部サービスの条件を確認し、承認済みの範囲から試すのが現実的です。

兼務担当者だけで、アプリの認可、クラウドの権限、検索用データの削除まで検証するのは負担が大きくなります。
外部へ依頼する場合も、発注側が許可範囲を決め、実装側が試験結果を残す役割分担は必要です。
人の記憶に頼らない記録があれば、担当交代後も同じ条件で点検を続けられます。
点検結果は、新しいシステムへの接続や委託先の変更時にも見直します。
確認済みの範囲を明示することで、現場は毎回承認を取り直す負担を抑えながら、許可された業務でAIを使えます。

Phinxは、データ基盤の構築と国内外の開発チームとの連携を通じ、業務要件から導入後の運用まで整理する知見を持っています。
企業の規模と体制に応じて、データの使い方と管理する人の役割を一体で設計できる点が強みです。

出典