AI開発コネクト
開発会社の登録（無料）無料で相見積もり・相談
AI最新ニュース日本のAI・国内報道

AIエージェントによる攻撃を国内サイトで観測。8時間で10段階、要件に足す5行

ビットフォレストが2026年10月14日に公表。10月10日夜以降に3件のIPを確認し、1件は8時間弱で手口を10段階に変えました。LLMを呼ぶフォームは連投が課金になります。見積依頼に書く5行を整理します。

公開: 2026.10.19 ／ 更新: 2026.10.19

AI 開発を外注すると、納品物のほとんどがインターネットに面する。問い合わせフォーム、ログイン画面、チャットの受け口、そして裏側の API である。これらは今まで「誰かが手でツールを回して探している」前提で守られてきた。

2026 年 10 月 14 日、WAF サービス Scutum を提供するビットフォレストが、日本企業のサイトに対する AI エージェントによる攻撃を観測したと公表した。10 月 10 日の夜から 14 日までに少なくとも 3 つの IP アドレスを確認し、そのうち 1 つは 8 時間弱にわたって手口を 10 段階に変えながら攻撃を続けていた。

発注側にとっての論点は、攻撃手法の新しさではない。自分が発注した AI 機能の見積書に、この種の試行に耐える行が入っているかである。

蓋を開いたサーバーラックの前に同じ形の侵入記録の紙が10枚階段状に並び、1枚だけ縁がアンバー

公表されている内容

公表は同社の技術ブログ「WAF Tech Blog」で、筆者は Scutum の開発者である。以下は公表資料に書かれている範囲である。

項目 内容
公表日 2026 年 10 月 14 日
観測期間 10 月 10 日夜から公表日まで
確認した IP アドレス 3 件（同社は「少なくとも」としている）
検知方法 非公表（対策されることを避けるため）
検知の精度 8 つのモデルで試験し、すべて検知できたとしている。誤検知はほぼ無いが、見逃しはあり得る
攻撃者が使ったモデル 不明
同社の見立て 3 件は特徴が異なり、別の攻撃主体の可能性がある

検知の考え方として、AI エージェントは curl や sqlmap、自分で書いた Python などを実行し、サーバーの応答を読んで次の手を変えるという性質が挙げられている。従来の一括スキャンと異なるのはこの点である。

3 件の内訳

観測対象 段階数 概算リクエスト数 中身
1 件目 1 段階 約 1,000 ファイルとディレクトリの総当たり。/.git や管理画面の既定パスなど。ほぼ 404
2 件目 5 段階 約 1,440 スキャン 3 波 → SQL インジェクションの探索 → 問い合わせフォームへの連投
3 件目 10 段階 約 12,450 低速スキャン → 高速スキャン → 既知脆弱性 → Nmap → フォーム操作 → ログイン試行 → 再度の脆弱性探索

3 件目が「8 時間弱」のもので、最後の記録は開始から 7 時間 46 分後である。第 2 段階では 5 分間で約 10,000 リクエスト（毎分約 2,100）を送り、第 8 段階ではログイン画面に対して約 250 回の試行を 33 分間続けている。第 6 段階ではヘッドレスブラウザでパスワード再設定と会員登録のフォームに触っている。

2 件目の第 5 段階が、受託開発の納品物に最も近い。既存の問い合わせフォームに対し、通常の送信手順をたどったうえで約 44 分間に約 210 件の POST を送り、XSS と SQL インジェクションの文字列を混ぜていた。

同社が挙げた対策

公表資料では、攻撃者が AI エージェントを使っていても対策は大きく変わらないとしている。挙げられているのは 2 点である。

  1. 脆弱性を事前に解消しておくこと（裏側の API も含む）
  2. 既知パターンの一致だけに頼らない WAF を使うこと

そのうえで、今後はほぼすべての攻撃者が AI エージェントを使うようになると推測している。

発注者・企業への影響

ここからは見立てである。特定の製品の是非ではなく、AI 機能を外注した企業に共通する構造として整理する。

1. 「手口が 10 段階変わる」は、見積書の前提を変えると考えられる

従来のスキャンは、1 つのツールの 1 回の実行で終わることが多かった。だからこそ「既知パターンの一致で弾く」設計が成り立っていた。応答を読んで次を変える相手に対しては、1 つの入口を塞いだだけでは試行が続くと考えられる。

発注の実務で効くのは次の 3 点である。

  • 守る範囲を画面だけでなく API まで書く
  • 1 回の攻撃が長時間続く前提で、ログの保持期間と通知の条件を決める
  • 「正常な手順をたどる連投」は脆弱性ではないので、別に対策費が要る

レート制限・スループットとは。AIシステムが遅くなる・止まる3つの上限で書いたとおり、上限の設計は性能のためだけのものではない。今回のような連投に対しては、費用の防波堤としても働く。

2. 生成 AI 機能のフォームは、連投されると請求が増える

ここが AI 開発に固有の点である。問い合わせフォームが単にメールを送るだけなら、連投の被害は迷惑メールで終わる。しかしフォームの裏で LLM を呼んでいる場合、1 件ごとにトークン課金が発生する。

フォームの裏側 210 件の連投で起きること
メール送信のみ 迷惑メールが 210 通
分類・要約を LLM で行う 210 回分の API 課金
社内文書を検索して下書きを作る（RAG） 210 回分の検索 + 生成の課金
エージェントが外部システムを操作する 210 回分の課金 + 外部システムへの書き込み

4 行目まで作っている場合、連投は課金で済まない。トークン課金とは。入力・出力・キャッシュの単価と、請求が膨らむ6か所で挙げた「膨らむ 6 か所」に、外部からの連投という 7 か所目が加わると考えてよい。

3. 見積依頼に書く 5 行

今回の公表内容から、発注側が事前に書いておける項目を挙げる。どれも作業としては小さい。

  1. 保護範囲の明記: 「公開画面に加えて、裏側の API エンドポイントも保護対象に含めてください」
  2. 連投の上限: フォーム・チャット・API ごとに、IP 単位と利用者単位の呼び出し上限を設計に含める
  3. LLM を呼ぶ前の関門: 認証前のフォームから LLM を呼ぶ場合、課金が発生する前に弾く仕組み（CAPTCHA・トークン・キュー）をどこに置くか
  4. ログの保持と通知: アクセスログの保持期間、異常な試行を検知したときの連絡先と時間
  5. WAF の費用の所在: WAF は初期費用か月額か、誰の契約か。「別途」になっていないか

5 番目は見落としやすい。AI開発の見積書で「別途」になりやすい費用10個。依頼時に含めさせる書き方で挙げた費目と同じ扱いで、WAF とログ基盤は発注者側の契約に回りやすい。

4. 検収で 1 項目足せる

AI開発の検収。何を確認し、どう合格を判定するかで書いた検収項目に、次の 1 行を足せる。

認証前に呼び出せる経路から、短時間に同一内容を連続送信したとき、課金が発生する前に遮断されることを確認する。

精度の検証と違い、これは数分で確認できる。にもかかわらず、検収項目に入っていないことが多い。

5. 開発会社の責任にする話ではない

最後に 1 点。公表資料自身が「対策は大きく変わらない」と述べている。つまり今回の件は、新しい技術的対策が必要になったという話ではない。必要なのは、やるべきだった基本の工程が見積書に残っているかの確認である。

AIシステムのセキュリティ設計。何を守り、どう守るかで整理した守る対象の一覧に、**「課金が発生する経路」**を 1 行加える。それが今回の観測から引ける実務上の線だと考えられる。

まとめ

  • 2026 年 10 月 14 日、ビットフォレストが日本企業サイトへの AI エージェントによる攻撃の観測を公表した。10 月 10 日夜以降に少なくとも 3 件の IP を確認
  • 1 件は 8 時間弱で手口を 10 段階に変え、約 12,450 リクエスト。別の 1 件は問い合わせフォームに約 210 件を 44 分間連投した
  • 同社の対策は**脆弱性の事前解消（裏側の API を含む）**と、既知パターンだけに頼らない WAF の 2 点である
  • AI 開発に固有の論点は、フォームの裏で LLM を呼んでいる場合、連投が課金になること
  • 見積依頼に入れるのは保護範囲・連投の上限・課金前の関門・ログと通知・WAF の費用の所在の 5 行である

無料で相見積もり・相談の案件票では、公開範囲と認証の有無を選択式で揃えている。同じ保護範囲で書かれていない見積書は、金額だけ比べても意味がない。

参考・出典

AI開発の見積もりを、同じ条件で比べる。

条件を整理した 1 枚の案件票で複数のAI開発会社に依頼。初期費用だけでなく、データ整備・API 費・精度検証・保守・権利まで同じ列で比較できます。

無料で相見積もり・相談する →
無料で相見積もり・相談30秒で費用診断