結論を先に書きます。攻撃者がAIエージェントを使い始めても、中小企業が最初にやることは変わりません。OSやCMSを更新して、管理画面の脆弱性を解消することです。変わるのは、「うちは小さいから大丈夫」という言い訳が使えなくなることです。

なお、AIの鬼を運営する株式会社TOEは、AI検索対策・AI導入支援を売りうる利害関係者です。WAFやセキュリティ製品の性能は、当社では測っていません。

何が観測されたのか──3つのIPアドレス、3通りの攻撃

クラウド型WAFを提供するビットフォレストは2026年10月14日、同社の技術ブログ「WAF Tech Blog」で、日本企業のWebサイトに対するAIエージェントによる攻撃を観測したと報告しました。この報告はITmedia AI+が10月15日に伝えています。

同社は、攻撃元がAIエージェントかどうかを判定する仕組みをWAFに導入しました。その結果、10月10日夜から14日までに、少なくとも3つのIPアドレスからの攻撃を確認したとのことです。

攻撃元 続いた時間 段階 確認された中身
IPアドレス① 8時間弱 10段階 毎秒約35件・約1万件の高速スキャン、既知の脆弱性への攻撃、約250件のログイン総当たりなど。ツールを切り替えながら実行
IPアドレス② 記載なし 5段階 問い合わせフォームへの連投を含む
IPアドレス③ 記載なし 記載なし 約1000件のスキャンのみ

同社によると、3つの攻撃は特徴が異なり、攻撃主体は別々の可能性があります。①で使われた具体的なツール名は、素材には書かれていません。

目を引くのは①の「10段階」です。スキャンで止まらず、既知の脆弱性を突き、ログインを総当たりするというように、手口が順に切り替わっています。同社は、サーバの応答を読み取って次の行動を修正することをAIエージェントの特徴に挙げています。応答を見て次の手を選ぶ相手にとっては、自社サイトが返す応答の一つひとつが次の段階の材料になります。これは当編集部の読みで、素材にこう書かれているわけではありません。

「AIエージェントの攻撃」と言い切れるのはどこまでか

判定方法の詳細は公開されていません。理由について同社は「見分ける方法を公開すると攻撃者側に対策されてしまうため」と説明しています。公開されたのは大枠だけです。応答を読んで行動を直すというAIエージェントの特徴を逆手に取り、次のような従来型の攻撃と区別できるようにWAFの挙動を調整した、という内容です。

  • 「単純なリクエストを連続して送るだけ」の攻撃
  • 「単純に『curl』や『sqlmap』を実行するだけ」の攻撃

導入前の検証では、高性能モデル8種による攻撃を検出できたとしています。8種には、中国Alibabaの「Qwen 3.8 Flash Next」と中国Z.aiの「GLM-5.3 Flash」が含まれます。ただし、この8種は導入前の検証で使ったモデルです。今回の3件の攻撃にどのモデルが使われたのかは、素材に書かれていません。残る6種の名前も分かりません。

報告のうち、言い切っている部分と推測の部分を分けると次のとおりです。

内容 報告での扱い
3つのIPアドレスからのAIエージェントによる攻撃 観測した（「少なくとも」3つ）
検知したものがAIエージェントであること 「間違いなくAIエージェントである」と断定
AIエージェントを漏れなく見つけること 「漏れなく列挙することはできない」と明言
判定の方法 非公開
3つの攻撃が別々の主体によるものか 可能性にとどまる
今後ほぼすべての攻撃者がAIエージェントを使うこと 同社の推測

つまり「見逃しはありうるが、誤認はしない」という設計です。裏返せば、検知されなかった攻撃にAIエージェントが含まれていないとは言えません。「3つ」は観測できた最低限の数であり、全体の数ではありません。

同じ出来事を扱った他社の報道は、当編集部が集めた範囲では0件でした。ITmedia AI+の記事も、ビットフォレストの技術ブログを伝えたものです。別の立場から報告を裏付ける情報は、素材の中にありません。また、報告したのはWAFを提供する当事者で、有効策にもWAFの導入を挙げています。報告を疑う根拠があるという意味ではありません。第三者による検証が素材に無い、という点を押さえておく必要があります。

中小企業にとって何が変わるのか

一番大事なのは、ビットフォレスト自身が「攻撃者がAIエージェントを使っていても対策は大きく変わらない」としている点です。同社が挙げた有効策は次の2つです。

  • 脆弱性の解消
  • シグネチャ（既知の攻撃パターン）のみに依存しないWAFの導入

「AIエージェント対策」と名の付く何かを先に買う理由は、この報告からは出てきません。

変わるのは、狙われる側の前提です。同社は「AIエージェントはあまりにも便利で優秀なので、攻撃者が使わないわけがない」と述べ、今後はほぼすべての攻撃者が使うようになると推測しています。攻撃のコストが下がれば、「規模が小さい会社のサイトは後回しにされる」という期待は持てなくなります。

①と②で狙われたのは、ログイン、問い合わせフォーム、既知の脆弱性でした。ログイン画面と問い合わせフォームは、中小企業のコーポレートサイトにもごく普通にある部品です。

当社の実測とも突き合わせます。当社は2026年8月1日、福岡県の金属加工業45社について、生成AI（Gemini Flash-Lite＋Google検索グラウンディング、1社3回）が公式サイトを根拠に会社を説明できるかを測りました。説明できたのは42社（93%）です。AI検索から見ると、中小企業の公式サイトは「AIに読まれる入口」として働いています。そして今回の報告は、同じ日本企業のWebサイトが、別の目的のAIエージェントからは攻撃される対象にもなることを示しています。当社は「AIに読まれるサイト」づくりを勧める立場です。だからこそ、AIに読まれることと、古いまま放置してよいことは別の話だとはっきり書いておきます。

もう1つの実測もあります。当社は2026年7月22日、主要25サイトのrobots.txtを取得しました（成功23）。結果は次のとおりです。

  • AIクローラを1つ以上拒否していたサイト：6
  • そのうち6種すべてを拒否していた新聞社：3
  • 明示的な拒否がなかったサイト：17

robots.txtはクローラに向けた宣言のファイルです。今回のような攻撃を止められるかどうかは、素材には書かれていません。攻撃者がそれに従うと見込んで、安心材料にしないほうが安全です。

明日からの点検──観測された攻撃から逆算する

素材にある攻撃の中身を、自社サイトで確かめる問いに置き換えました。

観測された攻撃 自社サイトで確かめる問い
高速スキャン（①毎秒約35件・約1万件、③約1000件） 旧サイトや使っていないページを公開したままにしていないか
既知の脆弱性への攻撃（①） OS・CMS・プラグインは更新されているか。更新の担当者は決まっているか
ログイン総当たり（①約250件） 管理画面のURLとアカウントを誰が把握しているか。使っていないアカウントが残っていないか
問い合わせフォームへの連投（②） 連投されたとき、誰の受信箱に何が届き、誰が気づくか
有効策として挙げられたWAF WAFは入っているか。入っているなら、シグネチャだけに頼る方式か

取りかかる順番は、上の3行にある「古いまま放置された箇所」の解消が先です。当編集部が明日の一言にするなら、「攻撃者がAIを使うかどうかより、古いまま放置された箇所が入口になる前提で点検する」です。サイトの保守を制作会社やホスティング会社に任せている場合は、この表をそのまま質問として渡せます。

ただし、どの点検でどれだけ攻撃が減るのかは、当社では測っていません。どのWAF製品が「シグネチャのみに依存しない」方式に当たるのかも、素材からは分かりません。

AIエージェントを使う側として

当社も社内業務の自動化を27本運用していて、AIエージェントを使う側でもあります。サーバの応答を読んで次の行動を修正するという特徴は、攻撃で使われても業務で使われても同じです。業務で使うときに権限をどこまで渡すかは、次の2本の記事で扱いました。

攻撃される側としての点検と、自社で使う側としての権限設計は、あわせて見直すと抜けが少なくなります。

この記事で言えないこと

  • 攻撃を受けた日本企業の社名・業種・規模・社数は、素材に書かれていません。中小企業が含まれていたかどうかも分かりません。
  • 攻撃が成功したのか、情報流出や改ざんなどの被害があったのかは、素材からは分かりません。
  • 実際の3件の攻撃に使われたAIモデルは分かりません。検証で検出できた8種のうち、名前が出ているのは2種だけです。
  • 判定方法は非公開で、見逃しや誤検知がどれくらいあるのかは分かりません。
  • IPアドレスの所在地や攻撃主体は、素材に書かれていません。②と③の攻撃が続いた時間も分かりません。
  • 同じ出来事を扱った他社の報道は0件で、別の情報源による裏付けはありません。
  • 「今後はほぼすべての攻撃者がAIエージェントを使う」は同社の推測です。時期や根拠となるデータは示されていません。
  • 当社は、WAFの性能、上の点検項目の効果、自社サイトへの攻撃状況のいずれも測っていません。
  • robots.txtの設定が今回のような攻撃に効くかどうかは、素材にも当社の実測にもありません。

まとめ

  • ビットフォレストは2026年10月10日夜〜14日に、日本企業のWebサイトへのAIエージェントによる攻撃を、少なくとも3つのIPアドレスから観測しました。うち1つは8時間弱にわたり、10段階で手口を変えていました。
  • 判定は「検知すれば間違いなくAIエージェント、ただし漏れなくは見つけられない」という設計で、「3つ」は最低限の数です。判定方法は非公開で、他社の報道による裏付けもありません。
  • 同社は「攻撃者がAIエージェントを使っても対策は大きく変わらない」とし、脆弱性の解消と、シグネチャのみに依存しないWAFを有効策に挙げています。
  • 中小企業にとって変わるのは「うちは小さいから大丈夫」が通らなくなることで、点検の中身は変わりません。まずOS・CMSの更新と、管理画面の脆弱性解消を終わらせてください。
  • 公式サイトはAIに読まれる入口（当社の実測では、福岡県の金属加工業45社中42社）であると同時に、攻撃の入口にもなります。どの点検がどれだけ効くかは、当社は測っていません。

この記事は、ITmedia AI+の報道（ビットフォレストがWAF Tech Blogで公開した報告を伝えたもの）を素材に、当社（株式会社TOE / AIの鬼）の実測とあわせて書きました。使った実測は、2026年8月1日の福岡県金属加工業45社の調査、2026年7月22日の主要25サイトのrobots.txt調査、社内業務の自動化27本の運用状況です。