「AIによる不正アクセスが相次いでいる」
最近、こうした見出しをよく目にします。
顧客から「うちは大丈夫ですか」と聞かれることも増えました。
正直に言います。この質問に、私は少し困っていました。
危機感を煽るのは簡単です。でも、実際に何が起きているのかを正確に把握しないまま「対策が必要です」と言うのは、無責任だと思ったからです。
そこで、公表されている事案を一通り確認してみました。
結論から書きます。
侵入経路は、ほとんどが従来通りでした。
まず、数字を整理する
2026年の被害状況について、公表されている数字です。
国内
- 企業・自治体の不正アクセス等の被害が、9月末時点で600件。昨年を上回る過去最多ペース（共同通信、2026年10月6日）
- 警察庁によると、2026年上半期のランサムウェア被害報告は123件で、半期として過去最多
グローバル
- IBMの調査では、2025年3月〜2026年2月の侵害の4件に1件がAI利用、前年比56%増（CNBC、2026年8月14日報道）
確かに、被害は増えています。 そしてグローバルではAIの利用も確認されています。
ただし、ここからが重要です。
国内でAI関与が確認された事案は、ゼロ
セキュリティ専門企業の調査記事によると、日本国内の各事案について「AIが使われた」と公式に認めた組織は1件もありません（2026年10月8日時点）。
セキュリティ会社や専門家が「可能性が高い」と指摘している段階です。
つまり、現時点では次のように整理できます。
| 事実 | 状況 |
|---|---|
| 被害件数が増えている | 確認されている |
| グローバルでAI利用の攻撃がある | 統計として報告されている |
| 国内事案でAIが使われた | 公式には確認されていない |
「件数が増えている」と「AIが原因である」は、別の話です。
ここを混同すると、対策の方向を誤ります。
公式に確認された事案は、「攻撃」ではないものが多い
では、AI関与が公式に確認された事案はどんなものか。
2026年7〜10月に公表された主なものは5件あります。そのうち4件は、意図的な攻撃ではありませんでした。
①Hugging Face（米国、2026年7月）
OpenAIのモデルが、セキュリティ評価環境から自律的に侵入。OpenAIは「AIエージェントによる初の自律的サイバー攻撃」と説明していますが、両社とも悪意はなかったとしています。
②豪州Medicare統計ポータル（2026年9月）
OpenAIのエージェントが非公開の統計ファイルにアクセス。意図しない動作だったと説明されています。
③Google Gemini（評価演習、2026年9月）
評価演習中、設定ミスでネットにつながった環境からモデルが侵入。
④Bee Cheng Hiang（シンガポール、2026年9月）
従業員がAIに書かせたプログラムの不備で、顧客95,364人のメールアドレスが互いに見える状態に。攻撃ではなく、コードの不備です。
⑤DIVD（オランダ、2026年9月）
ヘルプデスクツールの未知の脆弱性2件をAIエージェントが悪用したと報じられています。
5件のうち4件は、誤動作・設定ミス・コード不備です。
「AIが悪意を持って攻撃してきた」という構図とは、だいぶ違います。
実際の侵入経路は、従来通り
では、国内で実際に何が起きているのか。公表された事案を横断すると、手口は次のパターンに集約されます。
①VPN・公開機器の既知の脆弱性
デジタル庁の事案では、VPN機器の脆弱性が悪用されました。
パッチ未適用の機器が標的になる。 これは何年も前から言われていることです。
②委託先・SaaS経由の侵入
大和証券は委託先の問い合わせ管理サーバー経由、シチズン時計も委託先経由で漏洩しています。
自社が対策しても、委託先が侵入口になる。
③強い権限のアカウントの悪用
デンマークの住民登録では、民間企業に与えられていた正規のアクセス権が悪用されました。
④アプリ・Webシステムの脆弱性
GyazoやGMOリサーチの事案は、脆弱性の悪用によるものです。
⑤クラウドの設定ミス
ベトナムの旅客データベースでは、設定ミスで約2.2億件が露出しました。
どれも、AI以前から存在する手口です。
攻撃者がAIを使って脆弱性の探索を高速化している可能性はあります。でも、入口そのものは変わっていません。
だから、現場でやることは変わらない
ここが本題です。
「AIによる攻撃が増えている」と聞くと、何か新しい対策が必要な気がします。
でも、入口が変わっていないなら、やるべきことも変わりません。
①パッチ適用を、遅らせない
VPN機器や公開サーバーの脆弱性は、最優先です。
攻撃者がAIで探索を高速化しているなら、公開された脆弱性が悪用されるまでの時間が短くなっている可能性はあります。つまり、適用の猶予が減っている。
「次の定期メンテで」と後回しにしていたものを、見直す価値はあります。
パッチ適用の判断基準については別記事に書いたので、優先順位の付け方はそちらを参考にしてください。
②委託先の管理を確認する
自社の対策だけでは防げません。
- 委託先がどこまで自社データを持っているか
- 委託先のセキュリティ基準を確認しているか
- 委託先からのアクセス経路を把握しているか
複数の事案で、委託先が侵入口になっています。 ここは見直す価値があります。
③アクセス権を棚卸しする
強い権限のアカウントが放置されていないか。退職者・異動者のアカウントが残っていないか。
地味ですが、最も効果のある対策の一つです。
④バックアップを隔離する
大阪公立大学の事案では、ランサムウェアで約500台のサーバーが停止し、バックアップの多くも暗号化されました。
バックアップがネットワークに繋がったままでは、一緒にやられます。隔離されているか、今すぐ確認してください。
⑤クラウド構成を定期監査する
設定ミスによる意図しない公開は、ツールで検出できます。
作ったときは正しくても、運用の中で変わることがあります。定期的な確認が必要です。
ただし、1つだけ新しい論点がある
ここまで「やることは変わらない」と書いてきましたが、1つだけ新しいリスクがあります。
AIが書いたコードの検証です。
シンガポールの事案は、従業員がAIに書かせたプログラムの不備が原因でした。これは従来にはなかった経路です。
運用保守の現場でも、AIにスクリプトを書かせることは増えています。私自身もやっています。
だからこそ、ここは線を引く必要があります。
- AIが生成したコードは、必ず内容を理解してから使う
- 検証環境で確認してから本番に適用する
- 外部に公開される処理は、特に慎重に確認する
AIが書いたから正しい、ではありません。 最終的な責任は、使った人にあります。
この点については、AIを使うときの線引きとして別記事にまとめています。
顧客に説明するときの整理
「AIによる攻撃、うちは大丈夫ですか」
こう聞かれたとき、私はこう答えるようにしています。
「AIが使われたかどうかより、入口が塞がれているかが問題です」
そのうえで、確認すべき項目を具体的に示します。
- 公開機器のパッチ適用状況
- 委託先の管理状況
- アクセス権の棚卸し
- バックアップの隔離
- クラウド設定の確認
煽らず、でも具体的に。 これが顧客に対して誠実な態度だと思っています。
「AIが危ないので対策しましょう」では、何をすればいいかわかりません。それでは、不安だけが残ります。
まとめ
「AIによる不正アクセス」について、整理します。
事実関係
- 国内の被害件数は過去最多ペース（9月末時点で600件）
- ただし国内事案でAI関与が公式確認されたものはゼロ（2026年10月時点）
- グローバルではIBM調査で侵害の4件に1件がAI利用と報告
公式確認された事案の性質
- 5件中4件は、誤動作・設定ミス・コード不備
- 意図的な攻撃とは異なるケースが多い
実際の侵入経路（従来通り）
- VPN・公開機器の既知脆弱性
- 委託先・SaaS経由
- 強権限アカウントの悪用
- アプリ・Webの脆弱性
- クラウド設定ミス
現場でやること（変わらない）
- パッチ適用を遅らせない
- 委託先の管理を確認する
- アクセス権を棚卸しする
- バックアップを隔離する
- クラウド構成を定期監査する
唯一の新しい論点
AIが書いたコードの検証。生成されたものを、そのまま使わない
報道の見出しは、どうしても刺激的になります。
でも、運用保守の現場に必要なのは、煽りではなく事実の整理だと思っています。
何が確認されていて、何が推測なのか。それを分けて考える。そのうえで、できることを着実にやる。
地味ですが、それが一番効きます。
結局のところ、基本を守れているかどうか。 AIが出てきても、そこは変わりませんでした。
※本記事の数値・事案は、2026年10月8日時点で公表されている情報に基づいています。状況は変化する可能性があるため、最新情報は各組織の公式発表をご確認ください。
コメント