AIをセキュリティ対策に活用する企業が増えています。
不審なログインを検知する。大量のアラートを整理する。マルウェアの兆候を見つける。クラウド環境を監視する。人の手だけでは追いきれない領域をAIで補う流れは、かなり自然なものです。
ただ、現場で見落としたくないのは、攻撃者も同じようにAIを使っているという点です。
AIは、防御側だけの道具ではありません。攻撃者にとっても、コード作成、偵察、フィッシング文面の生成、脆弱性調査、盗んだデータの整理、攻撃の自動化を助ける道具になっています。
つまり、これからのセキュリティは「AIを導入したから安心」という単純な話ではなくなります。AIを使う防御側と、AIを使う攻撃側の両方を見たうえで、守り方を設計する必要があります。
TABLE OF CONTENTS
AIは企業のセキュリティ対策を確実に助けている
企業がAIをセキュリティに取り入れる理由は明確です。今のIT環境は、人の目だけで管理するには複雑になりすぎています。
社内システム、クラウドサービス、SaaS、API、従業員端末、外部委託先、開発環境、ソフトウェアパッケージ。これらが日々変化し、それぞれが攻撃の入口になり得ます。
セキュリティチームは、アラートを見て、ログを確認し、脆弱性を管理し、インシデントを調査し、開発部門や経営層にも説明しなければなりません。限られた人数でこの全てを回すのは、正直かなり大変です。
AIは、こうした業務を補助できます。
- 通常とは異なるログインやアクセスを検知する
- 大量のセキュリティアラートを要約する
- マルウェアや不審なファイルの特徴を整理する
- ソースコード内の脆弱性候補を見つける
- クラウド設定の不備を検出する
- フィッシングの可能性があるメールを判定する
- インシデント対応時の初動判断を支援する
正しく使えば、AIはセキュリティ担当者の判断を速くし、調査の抜け漏れを減らす力になります。
ただし、ここで終わらせると半分しか見えていません。
攻撃者もAIで速く、広く、巧妙になっている
AIは攻撃者にも、速さと自動化を与えます。
以前であれば、マルウェアを作る、脆弱性を悪用する、フィッシングページを作る、攻撃用スクリプトを書くといった行為には、一定の技術力が必要でした。コードを書き、エラーを直し、対象の仕組みを理解し、攻撃手順を組み立てる必要があったためです。
今は、AIにコードを書かせ、エラーを修正させ、文章を自然に整え、攻撃対象に合わせた文面を作らせることができます。
もちろん、AIを使えば誰でも高度な攻撃者になるわけではありません。実際の攻撃には、環境理解、判断力、運用力が必要です。
それでも、攻撃の入口に立つためのハードルが下がっていることは間違いありません。
- 基本的な攻撃スクリプトを作成する
- フィッシングメールを自然な文章にする
- 詐欺文面を複数言語に翻訳する
- 偽のWebサイトやログイン画面の文言を作る
- 盗んだデータから重要そうな情報を抽出する
- 流出した認証情報を整理する
- 検知されにくいようにコードを少しずつ変える
- 多数の対象に対する作業を自動化する
怖いのは、AIが熟練攻撃者をさらに強くするだけではないことです。これまで技術的に届かなかった人まで、攻撃に近づけてしまう点です。
2026年の問題は、攻撃が高度化するだけではない
2026年のサイバーセキュリティで特に厄介なのは、攻撃の高度化だけではありません。
攻撃を実行できる人の数が増えることです。
企業はこれまで、国家背景の攻撃グループ、ランサムウェアグループ、組織的な犯罪集団、技術力のある攻撃者を主な脅威として見てきました。もちろん、これらの脅威は今も深刻です。
しかし、AIによって、低スキルの犯罪者、詐欺グループ、内部不正者、若年層の模倣犯なども、以前より現実的な脅威になり得ます。
| 従来の攻撃者像 | AI時代に増える可能性がある攻撃者像 |
|---|---|
| 高度な技術を持つ攻撃者 | AIでコードや手順を補う低スキル攻撃者 |
| 専門的な犯罪グループ | 詐欺グループや副業的な犯罪者 |
| 英語圏中心の攻撃文面 | 自然な日本語や多言語に変換された攻撃文面 |
| 手作業中心の探索 | 自動化された広範囲の探索 |
守る側から見ると、「誰が攻撃してくるか」だけでなく、「どれだけ多くの人が攻撃を試せるようになるか」を考えなければなりません。
AIでフィッシングはかなり見破りにくくなる
フィッシングは、今も企業侵害の入口としてよく使われます。
攻撃者は、必ずしも高度な脆弱性を突く必要はありません。従業員がリンクをクリックし、認証情報を入力し、添付ファイルを開いてしまえば、そこから侵入の糸口が生まれます。
AIは、このフィッシングをより自然にします。
昔のフィッシングメールには、明らかな不自然さがありました。日本語がおかしい、敬語が変、社内では使わない言い回しがある、差出人名と内容が合っていない。こうした違和感で気づけることもありました。
しかし、AIを使えば、かなり自然な日本語で、相手や業務に合わせた文面を作れます。
- 上司からの依頼に見えるメール
- 取引先からの請求書送付に見えるメール
- クラウドサービスの認証確認に見えるメール
- 金融機関や決済サービスの通知に見えるメール
- 採用候補者や顧客からの問い合わせに見えるメール
- 社内ツールのパスワード再設定に見えるメール
さらに、公開情報を組み合わせれば、部署名、役職、サービス名、過去のニュース、採用情報などを文面に混ぜることもできます。
従業員教育で「日本語が不自然なメールに注意しましょう」と伝えるだけでは、かなり不十分になってきています。
AIは脆弱性悪用までの時間も短くする
脆弱性情報が公開されると、防御側は急いで影響範囲を確認し、パッチ適用や設定変更を行います。
しかし、攻撃者も同じ情報を見ています。
AIは、公開された脆弱性情報の読み解き、影響を受ける製品の整理、検証コードの作成、探索スクリプトの作成、自動スキャンの準備を助ける可能性があります。
このとき問題になるのが、対応速度の差です。
- 攻撃者は数時間から数日で悪用を試す
- 企業は影響調査、検証、承認、適用、本番反映に時間がかかる
- 外部公開資産が多いほど、確認漏れが起きやすい
- 古いシステムほど、パッチ適用に調整が必要になる
「早くパッチを当てる」は、今でも正しい対策です。ただ、それだけでは追いつかない場面が増えています。
自社のどこが外部に出ているのか。どの資産が攻撃されやすいのか。どの脆弱性から優先すべきなのか。こうした露出管理と優先順位付けが、これまで以上に重要になります。
ソフトウェアサプライチェーンは特に狙われやすい
多くの企業は、オープンソースソフトウェアに依存しています。
開発者は、npm、PyPI、Maven、NuGetなどの公開リポジトリからパッケージを取得し、アプリケーションを開発します。これ自体は現代の開発では当たり前の流れです。
ただし、攻撃者もそこを見ています。
企業を直接攻撃するのではなく、開発者が使うパッケージ、保守者アカウント、CI/CDパイプライン、ビルド時の認証情報を狙う攻撃が増えています。
- 正規に見える悪性パッケージを公開する
- 既存パッケージの保守者アカウントを乗っ取る
- 似た名前のパッケージで誤インストールを狙う
- インストール時に実行されるスクリプトで情報を盗む
- CI/CD環境からトークンやシークレットを取得する
- 取得した権限でさらに別のパッケージやリポジトリへ広げる
この攻撃が厄介なのは、侵入経路が「信頼している開発フロー」の中に入ってくることです。
ファイアウォールやEDRを整備していても、開発環境やビルド環境が汚染されたパッケージを取り込めば、攻撃は正規の開発プロセスに紛れ込みます。
検知ツールだけでは足りない場面が増えている
検知ツールは重要です。ログ監視、EDR、SIEM、メールセキュリティ、クラウド監視は、今後も必要です。
ただ、AI支援型の攻撃では、検知が難しくなる場面があります。
AIで作られた悪性コードやフィッシング文面は、従来より自然で、整っていて、正規のものに見えやすくなります。
- 悪性パッケージの説明文が自然に書かれている
- コード構造が通常のライブラリに似ている
- フィッシングメールの日本語が自然になっている
- 社内用語や業務文脈に合わせた文面になっている
- 攻撃パターンが少しずつ変化し、シグネチャに乗りにくい
つまり、「怪しいものを見つけたら止める」だけでは間に合わない可能性があります。
これからは、怪しいものが入ってきた後に検知するだけでなく、そもそも危険なものが入りにくい仕組みを作る必要があります。
セキュリティの考え方を少し変える必要がある
従来のセキュリティ運用は、どうしても反応型になりがちです。
- 何かが起きる
- アラートが出る
- 担当者が調査する
- 必要に応じて遮断や修正を行う
- 再発防止策を検討する
この流れは今後も必要です。ただ、AI支援型攻撃では、攻撃側の準備と展開が速くなるため、反応型だけでは遅れる場面が出てきます。
重要なのは、攻撃が成立しにくい状態をあらかじめ作ることです。
| 従来の発想 | これから必要な発想 |
|---|---|
| 攻撃を検知して対応する | 攻撃の入口を減らす |
| アラートを見て調査する | 危険な権限や設定を事前に減らす |
| パッチを急ぐ | 外部公開資産と影響度を常に把握する |
| 不審メールを見分ける | 認証情報を盗まれても被害が広がりにくくする |
| 開発者の注意に頼る | 依存関係とCI/CDを仕組みで守る |
企業が今すぐ見直したい対策
1. IDとアクセス権限を強くする
AI時代でも、攻撃の入口として認証情報は非常に重要です。
フィッシングや情報窃取によってIDが盗まれる前提で、MFA、多要素認証、条件付きアクセス、最小権限、不要アカウントの削除を徹底する必要があります。
- 管理者アカウントにMFAを必須化する
- 退職者や異動者のアカウントを速やかに無効化する
- 共有アカウントを減らす
- 特権アカウントの利用履歴を監査する
- 必要な時だけ権限を付与する運用に近づける
2. フィッシング訓練をAI時代に合わせる
不自然な日本語や怪しい見た目だけを見分ける訓練では、限界があります。
今後は、自然な日本語で届く業務メール、取引先を装うメール、クラウドサービスの通知、社内ツールの認証依頼なども想定した訓練が必要です。
従業員に「見抜く力」だけを求めるのではなく、報告しやすい仕組み、誤って入力しても被害が広がりにくい認証設計も合わせて考えるべきです。
3. 外部公開資産を継続的に把握する
攻撃者は、公開されているIP、ドメイン、サブドメイン、VPN機器、管理画面、クラウド設定を探します。
AIや自動化ツールを使えば、この探索はさらに効率化されます。
企業側も、自社がインターネット上に何を公開しているのかを継続的に把握する必要があります。
- 使われていないサブドメイン
- 古いVPN機器やネットワーク機器
- 外部公開された管理画面
- 不要なクラウドストレージ公開設定
- 期限切れや管理者不明の資産
4. ソフトウェアサプライチェーンを守る
開発環境やCI/CDは、今や重要な攻撃対象です。
オープンソースを使わないという話ではありません。現実的には使い続ける必要があります。だからこそ、何を、どこから、どの権限で、どのように取り込んでいるかを管理することが大切です。
- 依存パッケージを定期的に棚卸しする
- 不要なパッケージを削除する
- パッケージの自動更新を無条件に通さない
- CI/CDのトークン権限を最小化する
- 長期間有効なシークレットを減らす
- パッケージ公開権限を持つアカウントにMFAを徹底する
- SBOMを活用して利用部品を把握する
5. AIを使った攻撃シナリオを想定する
AIを防御に使うだけでなく、攻撃者がAIをどう使うかも考える必要があります。
たとえば、次のような問いを社内で持ってみると、見直すべき箇所が見えやすくなります。
- AIが自社従業員向けの自然なフィッシングメールを作れるか
- 公開情報から役員や管理者を特定できるか
- 自社の公開ドキュメントから攻撃に使える情報が読み取れるか
- 未修正の脆弱性をAIで調査しやすい状態になっていないか
- 開発者やCI/CD環境に過剰な権限が残っていないか
- 漏えいした認証情報が悪用された場合、どこまで被害が広がるか
これは恐怖を煽るためではありません。攻撃者目線で一度見ておくことで、現実的な対策の優先順位がつけやすくなるからです。
AIセキュリティは、防御だけでなく脅威側も見る
AIをセキュリティに取り入れること自体は、前向きな取り組みです。
ただし、AIを「守るための便利な道具」とだけ捉えると、攻撃側の変化を見落とします。
AIは中立的な技術です。防御側にとっては、分析、検知、要約、対応支援の力になります。一方で攻撃者にとっては、自動化、文面作成、コード生成、情報整理、拡散の力になります。
企業が考えるべきなのは、「AIを入れるかどうか」だけではありません。
AIによって攻撃者の行動がどう変わるのか。その変化に対して、自社のID管理、外部公開資産、開発環境、従業員教育、監視体制が追いついているのか。そこまで見ておく必要があります。
AIを導入するだけではなく、AI時代の攻撃を前提にする
AIは、守る側にとっても強い味方です。セキュリティ人材が不足する中で、AIによる分析支援や自動化は今後ますます重要になります。
一方で、攻撃者もAIを使っています。
フィッシングメールは自然になり、攻撃スクリプトは作りやすくなり、脆弱性情報の悪用は速くなり、ソフトウェアサプライチェーンへの攻撃も巧妙になります。
だからこそ、これからの企業に必要なのは、単にAIツールを追加することではありません。AIによって攻撃の速度と量が変わる前提で、セキュリティ戦略そのものを見直すことです。
AI時代の守りは、攻撃を見つけて追いかけるだけでは足りません。攻撃されやすい入口を減らす。権限を絞る。認証を強くする。開発環境を守る。外部公開資産を把握する。従業員が迷ったときに報告できる流れを作る。
一つひとつは地味ですが、攻撃者にとっては確実にやりにくい環境になります。
AIを使って守ることは大切です。ただ、それと同じくらい、AIを使って攻撃される前提で自社を見直すことも大切です。
投稿者プロフィール
-
Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）
