不正アクセスや情報漏えいのニュースを見て、「またAIが悪用されたのか」「AIがあるから、こんな事件が起こるのでは」と感じることがあるかもしれません。AIに原因を求めたくなる気持ちは分かります。しかし、私は、そこで話を終わらせてはいけないと考えています。
AIが攻撃を容易にすることと、不正アクセスの原因や責任がAIにあることは別です。 高度なことができる道具だからこそ、誰が、どのように使ったのか。どこから侵入され、何を守れなかったのか。事実を分けて考える必要があります。
交通事故が起きたら、車が悪いのでしょうか
例えば、交通事故が起きたとします。事故が起きたというだけで、車を作ったメーカーが悪いのでしょうか。包丁で人を刺した事件が起きたら、悪いのは包丁ですか。包丁を作ったメーカーですか。
車は人や物を運ぶためのものです。包丁は食材を切るためのものです。本来の目的から離れて悪用する人間はいます。その悪用だけを理由に、道具そのものやメーカーを一律に責めるのは違うと思います。
もちろん、製品の欠陥や安全性の問題まで見なくてよい、という意味ではありません。使う人の行為と、製品の安全性は分けて確認すべき問題です。AIも同じです。AIが悪用されたからといって、AIの存在そのものが悪いとは言えません。一方で、提供側が悪用防止や安全性への取り組みを続けることも必要です。
AIの悪用は現実に起きている
AIをただの便利な道具として、危険性を無視するつもりはありません。Google Threat Intelligence Groupは2026年2月の報告で、攻撃者が情報収集、相手をだます働きかけ、不正プログラムの開発などを効率化するためにAIを利用している状況を説明しています。5月には、AIで開発されたと考えられる、未修正の脆弱性を悪用する攻撃コードの利用を確認したと報告しました。
自然な文章を作る、公開情報を整理する、コードを調べる。正当な仕事を助ける能力は、悪意を持つ人にも利用され得ます。AIは高度なことができるため、一部の攻撃工程に必要な時間や手間を減らす可能性があります。
ただし、これらはAIの悪用事例を示すものであり、不正アクセス全体の何割がAIによるものかを示す資料ではありません。個々の事件についてAIの関与が確認されていない段階で、「AIがやった」と決めつけることはできません。
出典：Google Threat Intelligence Groupの2026年2月報告、Googleの2026年5月報告
「AI関連リスクが3位」の意味を取り違えない
IPAの「情報セキュリティ10大脅威 2026」では、組織向けの脅威として「AIの利用をめぐるサイバーリスク」が初めて選ばれ、3位になりました。
これは、前年に社会的影響が大きかった事故や攻撃の状況などを基に、専門家らが審議・投票して決めた順位です。不正アクセスの発生件数を原因別に並べたランキングではありません。AI関連リスクには、攻撃者による悪用だけでなく、業務情報をAIサービスへ入力することによる漏えいなど、利用する側の問題も含まれます。
AIへの警戒は必要です。しかし、「AIが危険だ」という言葉だけでは、自社が何を改善すべきかは見えてきません。攻撃への備えと、社内でAIを使う際の情報管理を、それぞれ確認する必要があります。
出典：IPA「情報セキュリティ10大脅威 2026」、同・組織編解説書
「AIが悪い」で、安全管理の確認を終わらせない
私が懸念しているのは、AIへの警戒が強まることで、「不正アクセスが起きたのはAIのせいだ」という短絡的な説明が受け入れられやすくなることです。これは筆者の懸念であり、そのような風潮が社会全体でどの程度広がっているかを示す数字があるわけではありません。
不正アクセスを行った人の行為は問われるべきです。そのうえで、情報を預かる企業には、安全管理の実施状況や、事故後の対応を確認する必要があります。AI提供側にも、製品の安全性や悪用防止について確認すべきことがあります。それぞれを一つの「AIが悪い」という言葉で片付けるべきではありません。
「AIを使った高度な攻撃だった」という説明が事実でも、既知の脆弱性への対応、認証、アクセス権限、監視などの確認は必要です。反対に、被害が出たというだけで、その企業に管理上の過失があったと断定することもできません。実際に何が起き、どの対策が行われていたかを確認することが先です。
企業が確認すべきことは、具体的にある
経営者や情報管理の担当者が取り組むべきことは、AIを責めることではなく、自社の守り方を確認し、改善することです。まず、次の項目を担当者と確認してください。
- 利用中のシステムと管理担当を把握し、既知の脆弱性への対応状況を確認する。
- 多要素認証やアクセス制限の適用状況を確認し、不要なアカウントや過剰な権限を見直す。
- 個人情報・機密情報の保管先と利用目的を確認し、必要以上に保有していないかを点検する。
- 不審なアクセスを発見した際の連絡先、封じ込め、復旧の手順を確認する。
- AIサービスへ入力できる情報と、入力してはいけない情報を明確にする。
- AIの出力をそのまま信用せず、重要な判断や設定変更は人が確認する。
確認結果は「対応済み・未対応・要確認」に分け、未対応項目の担当者と期限を決めます。重要な設定変更は、現状の保存や復元方法を確認したうえで、担当者が影響を判断して進めてください。一度点検して終わりにせず、システムや利用者が変わったときにも見直します。
これで攻撃を完全に防げるわけではありません。それでも、未対応項目が減ったか、不要な権限を整理できたか、異常時に連絡できるかは確認できます。曖昧な不安を、実際に改善できる仕事へ変えることが大切です。
AIは、防御を助けるためにも使える
AIの能力は攻撃側だけのものではありません。Googleは、AIを利用した防御の取り組みも公表しています。AIは、異常の調査や対応を支援する方向にも使われています。
自社で使う場合も、安全対策の確認項目を整理する、機密情報を除いた資料の読み解きを助けるなど、用途と扱う情報を限定して活用できます。権限や設定の変更、事故対応の最終判断まで丸投げするのではなく、担当者の確認を支える使い方を考えるべきです。
出典：Google「Introducing Google AI Threat Defense」
高度な道具だからこそ、使い方と管理を問う
AIのせいにしたい気持ちは分かります。しかし、車や包丁の例と同じように、道具の存在、使った人の行為、製品の安全性、情報を管理する側の対応は分けて考える必要があります。
AIは高度なことができます。その能力を悪用する人がいるからこそ、悪用防止と防御の両方に取り組む必要があります。AIへの警戒によって、以前から必要だった安全管理の確認が見えなくなってはいけません。
「AIがやったのか」で話を終わらせず、「誰が、何をし、どこを改善すべきか」を確認する。 私は、その議論が必要だと考えています。
情報確認日：2026年10月9日。この記事はAIの悪用と安全管理の考え方を整理した筆者の意見です。個別の事件の原因や法的責任を断定するものではありません。