結論：2026年10月16日時点で、AIエージェントによる攻撃は国内の企業サイトで実際に確認されています。クラウド型WAF「Scutum（スキュータム）」を開発する株式会社ビットフォレストが10月14日、10月10日夜からの監視で少なくとも3つのIPアドレスからの攻撃を確認したと公表しました。ただ、狙われた場所は、公開されたままのファイル、既知の脆弱性、問い合わせフォーム、ログイン画面でした。
- 要点1：1つ目のIPは1,000件程度のスキャンだけ。2つ目は5段階で問い合わせフォームへの連投（約210件）まで、3つ目は8時間弱・10段階で、パスワード再設定と新規登録のフォーム、ログインの総当たり（約250件）も試していました（同社の技術ブログ・10月14日）。
- 要点2：見分け方は、公表すると対策されてしまうとして非公開です。同社は、手元で試した8種類のモデルはすべて検出できたと説明しています。
- 要点3：同社は、対策は攻撃者がAIエージェントを使うかどうかで大きくは変わらないと書いています。今日やるのは、自社サイトの5か所とログ、AIエージェントに渡した鍵の確認です。
対象読者：問い合わせフォームや会員ログインのある自社サイトを持つ会社のサイト担当・情報システム担当と、AIエージェントを業務で動かしている会社の管理部門の方。
読了後にできること：自社サイトで今日確かめる5か所と、AIエージェントに渡した鍵の棚卸しを、担当者と期限つきで割り振れます。
国内のWAF（ウェブサイトへの不正なアクセスを見張って止める仕組み）の開発者が、2026年10月14日の技術ブログに、AIエージェントが日本のウェブサイトへの攻撃に使われているかどうかを「議論する段階は終わりました」と書きました。10月15日には ITmedia AI＋ もこの記録を報じています（ITmedia AI＋）。
この記事では、公開された表から数字を1つずつ写して手口を整理し、自社で今日確かめることと入られた後の動きを、JPCERT/CC・国家サイバー統括室・IPA・個人情報保護委員会の文書に沿ってまとめます。検知の方法は公開されていないため、推測では書きません。
何が起きたか｜10月10日夜からの監視で3つのIPを確認
報告したのは、クラウド型WAF「Scutum（スキュータム）」を開発する株式会社ビットフォレストの技術ブログ「WAF Tech Blog」で、書き手は Scutum の開発者で同社の取締役です。2026年9月ごろからウェブサイトで情報漏洩の報告が相次いでいることを受け、「これらの攻撃がAIエージェントによるものなのかを調べる仕組み」を入れて監視した結果を、10月14日に公開しました（WAF Tech Blog）。
| 項目 | 原文の要点（WAF Tech Blog・2026年10月14日） |
|---|---|
| 監視の開始 | 10月10日の夜から、AIエージェントによる攻撃かを調べる仕組みを導入 |
| 確認した範囲 | 10月14日までに、少なくとも3つのIPアドレスから日本の企業のウェブサイトへの攻撃 |
| 3つの攻撃の中身 | 1つ目はスキャンだけ。2つ目は5段階、3つ目は8時間弱・10段階で、道具を切り替えながら進んだ |
| 見分け方 | 公表すると対策されるため、詳細は説明できない（非公開） |
| 本番に入れる前の確認 | 手元の開発環境で8種類のモデルを試し、すべて検出できた（事業者の説明） |
どの会社のサイトが狙われたのかは書かれていません。検出されたIPアドレスは 38.54.56[.]121、185.196.220[.]130、192.236.229[.]229 の3つです（誤ってリンクにならないよう「[.]」で区切った原文の表記のまま）。原文は「これらのIPアドレスは、WAFによる検知時点で攻撃元として利用されていたものですが、正規の通信で利用されている可能性もあることにご注意ください」と書いています。自社のログと照らす材料にはなりますが、一致しただけで攻撃と決めつけることはできません。
見分け方は非公開｜8種類のモデルで確かめたという説明
見分け方について、原文は「公表してしまうと対策されてしまうため詳細についてはここではご説明できません」としています。公開されているのは、仕組みの前提にしたAIエージェントの特徴だけです。
- curl や sqlmap、あるいは自分で生成した Python などのコードを使って攻撃してくる
- 実行した結果や出力（ウェブサーバ側の反応）を読み取り、必要に応じて次の行動を軌道修正する
- 賢く柔軟性があり、目的を達成しようとする強いモチベーションがあり、判断が速い
事業者は、これらの点を逆手に取り、AI以前の「シンプルに決められたリクエストを単に連続して送ってくるタイプ」の攻撃ツールとは違う流れが起きるよう、WAFの挙動を変えたと書いています。本番に入れる前には、手元の開発環境で最近リリースされた高性能のモデル8種類を試し、すべて検出できたと説明しています。名前が挙がっているのは Qwen 3.8 Flash Next と GLM-5.3 Flash Next の2つだけで、攻撃者が実際に使っているモデルは分からないとしています。
原文は、この仕組みを「漏れなくAIエージェントを列挙することはできないが、もし検知した場合は間違いなくAIエージェントである」性質のものだと書いています。見分け方が非公開で外から確かめる手段はないので、事業者自身の説明として読んでください。モデル名に出てくる GLM-5.3 の攻撃に使える能力は、GLM-5.3の攻撃能力をAnthropicが検証した件の解説で整理しています。
3つのIPの手口｜スキャンだけの例と、8時間弱・10段階の例
3つのIPアドレスの動きは、それぞれ違いました。中でも3つ目は、8時間弱のあいだに道具と名乗りを切り替えながら、ファイルのスキャン、既知の脆弱性への攻撃、パスワード再設定と新規登録のフォーム、ログインの総当たりへと進んでいます。以下は原文の表から写したもので、件数は原文でも「約」の値です。
1つ目のIP｜1,000件程度のスキャンだけ
1つ目のIPからは、/.well-known/security.txt、/admin/index.html、/.git などがあるかを探す、多くが404（ページが見つからない応答）になるアクセスが1,000件程度続きました。道具の切り替えや段階の変化はなく、原文は「AIエージェントを使ってはいるが、実際に発生していたのは非常に古くからあるタイプの、大量のスキャンのみでした」とまとめています。
2つ目のIP｜5段階で問い合わせフォームの連投まで
2つ目のIPの攻撃を、原文は「複数のツールを切り替えて段階的に攻撃が変化していく、AIエージェントで典型と見られる攻撃」と書いています。
| 段階 | 経過時間（原文の表記） | 件数（約） | 中身（原文の要約） |
|---|---|---|---|
| 1 スキャン第1波 | T+0:00〜T+14:18 | 330 | 疎通の確認のあと、XSS や SQL インジェクションを試す文字列、.git・.env・.hg・phpmyadmin などのスキャン。約30秒で約90種の管理画面やバックアップファイルのスキャン |
| 2 スキャン第2波 | T+35:47〜T+39:25 | 70 | 特徴的な Range ヘッダ（ファイルの一部だけを求める指定）付きのスキャン。ステータスコード206が見られ、/.git/HEAD などにアクセス |
| 3 スキャン第3波 | T+44:46〜T+1:02:52 | 800 | 毎分約44件。数百の存在するディレクトリに .git/HEAD、.env、.env.bak、backup.zip、db_backup.sql、.htaccess、web.config などを組み合わせた約800パスの網羅スキャン |
| 4 スキャン、SQLインジェクション | T+1:30:46〜T+1:34:26 | 30 | .git/HEAD、.env、backup.zip、BackupFiles、wp-admin、phpinfo.php などのスキャン。末尾にシングルクォートを付けたものもあった |
| 5 問い合わせフォームの連投 | T+1:39:30〜T+2:23:31 | 210 | 存在する問い合わせフォームに、正規の流れに沿って自動化された POST（送信）を連続で試行。XSS や SQL インジェクションも混在 |
出典は WAF Tech Blog（2026年10月14日）の表です。経過時間は最初のアクセスからの相対時刻で、この表は「分:秒」（1時間を超えると「時:分:秒」）の書き方です。第3波の毎分約44件・約800パスと時間の幅が合います。名乗り（User-Agent）は、第1波が Googlebot や iPhone の Safari などを含む10種を混ぜたランダムなものでした。
3つ目のIP｜8時間弱・10段階、ログインの総当たりも
3つ目のIPについては、原文の言葉で「長時間(8時間弱)にわたって多くのツールを切り替えて攻撃が実施されていました」。
| 段階 | 経過時間（原文の表記） | 件数（約） | 中身（原文の要約） |
|---|---|---|---|
| 1 低速スキャン | T+0:00〜T+0:23 | 50 | トップやログイン画面へのアクセス。XSS・SQL インジェクション・パストラバーサルの混入。Bitrix、WordPress、SharePoint、Axis2、Struts などの既知の脆弱性 |
| 2 高速スキャン 第1波 | T+0:50〜T+0:55 | 10000 | 毎分約2,100件（毎秒約35件）で大量のファイルをスキャン。404を連発 |
| 3 高速スキャン 第2波 | T+0:58〜T+1:00 | 1200 | 大量の404が出る、第1波に似たスキャン |
| 4 既知の脆弱性への攻撃 | T+1:15〜T+1:24 | 850 | Elasticsearch、Consul、Facelets/JSF など、非常に多数 |
| 5 Nmap | T+3:18〜T+3:21 | 15 | HEAD、PROPFIND、OPTIONS などのリクエスト（Nmap はネットワーク調査の道具） |
| 6 フォームへのアクセス | T+4:43〜T+4:58 | 20 | ヘッドレスブラウザ（画面を表示せずに動くブラウザ）による、パスワード再設定フォームや新規登録フォームなど正規の機能へのアクセス |
| 7 WebLogicのスキャン | T+5:01〜T+5:03 | 15 | WebLogic に特有の少数の URL へのスキャン |
| 8 ログイン総当り | T+5:08〜T+5:41 | 250 | ログイン画面への GET とログイン試行の POST の繰り返し |
| 9 既知の脆弱性への攻撃 | T+6:03〜T+6:41 | 40 | Struts、/WEB-INF/web.xml、F5 BIG-IP、GraphQL など、既知の脆弱性の少数のスキャン |
| 10 トップページやフォームへのアクセス | T+7:01〜T+7:46 | 10 | トップページやログインのフォームなどへの、少数の HEAD・GET・POST でのアクセス |
出典はWAF Tech Blog（2026年10月14日）の表です。この表の経過時間は「時:分」の書き方で、最後の T+7:46 は7時間46分です（原文の「8時間弱」と合います）。名乗りは、第1段階が存在しないOS名を組み合わせたものを含む35種類程度のランダム、第2段階は Chrome/87 だけ、第3段階は Safari や Firefox などの数十種のランダムと、段階ごとに変わっていました。
原文は、3つのIPはそれぞれ特徴が違う攻撃をしており、別のアクター（攻撃の主体）である可能性があるように思える、と書いています。また、大きな被害を出している「A2B攻撃」で見られる「User-Agentにスマホアプリの文字列が入っている」ケースは、この3つのIPには見られなかったとしています。A2B攻撃は、同じ週の10月13日に NICT（情報通信研究機構）の分析チームが名前を付けて注意を呼びかけた、公開されている Android アプリを解析して接続先のサーバを狙う手口です（NICT）。
何が違って、何が変わらないか｜対策は大きく変わらない
原文の対策の節は、「ウェブアプリケーションやウェブサイトにおけるセキュリティ対策は、攻撃者がAIエージェントを使っているかどうかによって大きく変わることはありません」という一文で始まります。表を読み直すと、目立つのは多くの道具を切り替えながら段階を進める攻め方で、狙われたのはファイル・既知の脆弱性・フォーム・ログインという、これまでの攻撃と同じ弱点でした。
| 違うところ（記録と事業者の説明） | 変わらないところ（狙われた場所） |
|---|---|
| 道具を切り替えながら段階を進める（2つ目は5段階、3つ目は10段階） | .git、.env、バックアップのファイルなど、公開されたままのファイルを探す |
| ウェブサーバの反応を読み取り、次の行動を軌道修正する（事業者が挙げた前提） | WordPress、Struts、Elasticsearch などの既知の脆弱性を試す |
| 長く続く（3つ目は8時間弱） | 問い合わせフォーム、パスワード再設定と新規登録のフォームを使う |
| 名乗り（User-Agent）を段階ごとに替え、数十種を混ぜる | ログイン画面で総当たりを繰り返す |
1つ目のIPのように、AIエージェントを使っていても中身は「非常に古くからあるタイプ」のスキャンだけ、という例もありました。JPCERT/CC が10月8日に出した注意喚起も、国内で相次ぐ不正アクセスの型の1つ（ケースA）を挙げています。標的ごとにさまざまな既知の脆弱性をスキャンして悪用を試みたり、環境設定ファイルやバックアップファイルの窃取など機器の管理不備を突いたりしている可能性がある、という内容です（JPCERT/CC）。狙う場所は、今回の記録と重なります。
守る側から見て変わるのは粘り方です。事業者は前提の1つに「目的を達成しようとする強いモチベーション」を挙げ、3つ目のIPは8時間弱、入口を替えながら試し続けました。守りの薄い入口が1か所でもあれば、いずれそこが試される、と考えておくのが現実的です。事業者は「今後はほぼすべての攻撃者がAIエージェントを使うようになると推測できます」と書く一方、そのときの対策も「大きくは変わりません」としています。AIエージェント型の攻撃を「既知の弱点を、速く・安く・休まず探す」攻撃と見る整理は、AIエージェントによるサイバー攻撃の事例と7つの確認（韓国の金融機関の件）でも書きました。
自社サイトで今日確かめる5か所｜フォーム・ログイン・再設定・更新・公開ファイル
自社で「AIエージェントかどうか」を見分けようとするより、今回の記録で試された入口を先に確かめるほうが確実です。見分け方は公開されておらず、見分けられたとしても守る場所は同じだからです。サイトの保守を制作会社に任せている場合は、この表を渡して答えをもらうのが早いと思います。
| 場所 | 今回の記録で見られた動き | 今日確かめること | よりどころ |
|---|---|---|---|
| 1. 問い合わせフォーム | 2つ目のIPが約210件の自動の送信を連続で試し、XSS や SQL インジェクションも混ぜた | 短い時間に大量の送信が来た時に止める回数の制限があるか。フォームの仕組み（CMS のプラグインなど）に未適用の更新がないか | JPCERT/CC（悪用のリスクが高い機能に個別の回数制限）、国家サイバー統括室（CMS などの更新） |
| 2. ログイン画面 | 3つ目のIPが約250件、ログイン画面への GET とログイン試行の POST を繰り返した | 回数の制限があるか。多要素認証を使えるか。推測されやすいパスワードを禁止しているか。外からの異常な認証の試みに気付けるか | JPCERT/CC、国家サイバー統括室 |
| 3. パスワード再設定・新規登録 | 3つ目のIPが、ヘッドレスブラウザで約20件、正規の機能にアクセスした | 再設定と登録に回数の制限があるか。作った覚えのないアカウントや、無効にしたはずなのに有効なアカウントがないか | JPCERT/CC（パスワードリセットに個別の制限）、IPA（アカウントの異常の確認） |
| 4. 既知の脆弱性（更新） | WordPress、Struts、Elasticsearch、F5 BIG-IP、GraphQL などの既知の脆弱性を試した | OS・ミドルウェア・CMS・プラグインに未適用の更新がないか。サポートが終わった製品や、使っていない機能が動いたままになっていないか | 国家サイバー統括室、JPCERT/CC、IPA |
| 5. 公開されたままのファイル | .git、.env、backup.zip、db_backup.sql などを数百のディレクトリで探し、phpinfo.php や wp-admin も探した | 設定ファイル・バックアップ・開発用のフォルダが公開の場所に置かれていないか。要らない管理画面が外から開けないか | JPCERT/CC（不要な機能の公開停止）、国家サイバー統括室（使っていない機能の停止・削除） |
「今回の記録で見られた動き」は WAF Tech Blog の表から取りました。フォームの行は JPCERT/CC の考え方の当てはめで、JPCERT/CC はログイン・パスワードリセット・SMS送信・検索処理など悪用のリスクが高い機能に個別の回数の制限をかけるよう求めています（JPCERT/CC）。更新の行は、国家サイバー統括室の「OS、ミドルウェア、CMS（コンテンツ・マネジメント・システム）、アプリケーション等のセキュリティパッチやアップデートを速やかに適用する」です。
ログで確かめる｜「エラーの出力量」と「平時との差異」
IPA は10月9日の文書で、アプリケーションやサービスごとに直近のログに異常がないかを確かめるよう求め、見分け方の例に「エラーの出力量、平時との差異等」を挙げました。期間は「直近１ヵ月、その後３ヵ月といったように」段階的に広げるとしています（IPA）。今回の記録にも、404を連発するスキャンや、短い時間に集中した送信がありました。公表された3つのIPアドレスも照らす材料になりますが、一致だけで判断せず、その時間にどの画面へ何が送られたかを合わせて見てください。
AIエージェントを業務で使う会社が足す確認｜渡した鍵と外部連携
原文は、AIエージェントを開発や脆弱性診断に使っている人からすれば当たり前の感覚だとしたうえで、「AIエージェントはあまりにも便利で優秀なので、攻撃者が使わないわけがない」と書いています。業務でAIエージェントを動かしている会社は、攻める側と同じ種類の道具を使っている、ということです。違うのは、自社のエージェントには社内の鍵（APIトークン）と外部のサービスへの連携を渡している点です。JPCERT/CC は、国内で相次ぐ不正アクセスの手口の1つに「他のシステムの侵害で窃取したAPIキーを使用する」を挙げています（JPCERT/CC）。1か所で鍵が漏れれば、その鍵で入れる先がすべて入口になります。サイトの5か所と同じ週に、次の5つを確かめてください。
| 確かめること | 中身 | よりどころ |
|---|---|---|
| 1. 鍵と連携先の一覧 | AIエージェントや社内の仕組みに渡した鍵と、つないでいる外部のサービスを、部署ごとの分も含めて書き出す | IPA「自組織が利用している外部サービスをすべて洗い出してください」 |
| 2. 権限と期限 | 鍵の権限を業務に要る最小限にし、長く有効なままの鍵を減らす | JPCERT/CC（必要最小限の権限・適切な有効期限） |
| 3. 止め方 | 漏えいが疑われた時に、誰が・どこで鍵を無効にするかを先に決めておく | JPCERT/CC「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」 |
| 4. 置き場所 | 鍵を設定ファイルやメモに平文で置かない | 国家サイバー統括室「パスワードや認証情報を平文で保存しない」 |
| 5. AIに入れたデータ | どのデータをどのAIのサービスに入れているか、要らない情報を持ち続けていないかを把握する | 国家サイバー統括室（情報の所在と管理者の把握）、IPA（不要な情報は持たない） |
今回の記録でも、2つ目のIPが .env（鍵などの設定を書いておくファイル）を何度も探していました。サイトにAIのチャット窓口や問い合わせへの自動応答を付けている場合は、その入口も5か所と同じ点検に入れてください。自社のエージェント自身が、外部のサイトで想定外の動きをすることもあります。例はOpenAIエージェントが豪政府の統計ポータルの制限を回避した件の解説に、外部のページに仕込まれた指示に従ってしまう危険はプロンプトインジェクションの解説にまとめています。
この記事の内容を社内で使うなら
要点と手順をまとめた資料を無料で受け取れます。研修6,000名以上・支援100社以上の実績をもとに、自社の業務に当てはめる相談も30分から受け付けています。
入られた後の初動と、戻せるかの確認
国家サイバー統括室は10月9日の文書で「侵入を完全に防ぐことは困難です。不審な挙動の早期発見と迅速な対応が被害発生及び拡大の防止につながります」と書きました（国家サイバー統括室）。5か所を確かめても、入られた後の動きは決めておく必要があります。
気付く・鍵を止める・ログを残す
同じ文書は、不審な通信や大量のアクセスの監視と、外部からの異常な認証試行の把握を挙げています。IPA は、異常なログやアカウントが見つかったら速やかにセキュリティインシデントと判定して対応を進めるよう求め、専門のセキュリティベンダーに詳しい調査を頼むことを「強く推奨」しています（IPA）。漏えいが疑われる鍵（APIトークン）は無効にします（JPCERT/CC）。当社が先に止めるべきだと考えるのは、外から届く仕組み（サイト・フォーム・API）で使っている鍵と、AIエージェントに渡した鍵のうち権限の広いものです。漏れた時に入れる範囲が広いほど、被害が広がるからです。並行して、調査に要るアクセスログや認証のログが消えないよう保管します。国家サイバー統括室も、ログを一定期間保管することと、異常を検知した場合の対応態勢を整えることを求めています。
報告する｜個人情報保護委員会の期限
個人情報保護委員会のページは、報告の期限について「発覚したら、まずは速やかに報告してください」と書き、不正な目的で行われたおそれがある場合は「発覚日から、60日以内」としています。報告が要る例には「不正アクセスにより個人データが漏えいした場合」「ウェブサイトが改ざんされ、ユーザーが入力した個人情報が第三者に送信された場合」が挙がり、本人の数が1,000人を超える漏えい等（そのおそれを含む）も対象です。業種によっては、権限を委任された省庁が報告先になります（個人情報保護委員会）。国家サイバー統括室は、被害にあった組織に攻撃の技術的な情報を所管省庁や専門機関等へ速やかに共有するよう求め、JPCERT/CC もインシデント対応の相談を受け付けています。
戻せるか｜鍵・ログ・バックアップを平時に確かめる
- 鍵：止めた鍵の代わりを発行し直して、業務を戻せるか。その鍵を使う仕組み（フォームの通知、AIエージェントの連携など）を一覧にしておかないと、止めた時に業務も止まります。
- ログ：ログが何か月分残っているか。IPA は、サービスごとにログの保有期間が違うことを挙げ、誰がいつどう確認できるかを整理するよう求めています。残っていなければ、さかのぼって調べられません。
- バックアップ：サイトをきれいな状態に戻す控えがあり、その控えも守られているか。国家サイバー統括室は「バックアップデータについても適切に保護する」と書き、JPCERT/CC は「Webサーバー等が侵害された後の横展開対策を見直す」ことを挙げています。
教育で防げる範囲と防げない範囲
正直に書くと、今回の記録のような攻撃を社員教育で止められる範囲は限られます。攻撃は社員ではなく、公開しているサイトそのものに向かっているからです。一方で、教育が効く場所もはっきりあります。
| 教育で防げる・減らせること | 教育だけでは防げないこと |
|---|---|
| 推測されやすいパスワードを使わない | 公開しているサイトの既知の脆弱性（更新と診断が要る） |
| 多要素認証を設定して使う | 公開されたままのファイルや要らない管理画面（設定の見直しが要る） |
| AIエージェントに必要以上の権限や鍵を渡さない | フォーム・ログイン・パスワード再設定の回数の制限（仕組みが要る） |
| 鍵を平文でメモや設定ファイルに置かない | 大量のアクセスや異常なログインの把握（ログと監視の仕組みが要る） |
| おかしいと思ったらすぐ報告する | 制作会社・委託先の側の設定（契約と継続的な確認が要る） |
左の上の2つは、国家サイバー統括室が「アカウント管理・認証」に挙げる対策です。当社（Uravation）は、脆弱性の診断、侵入テスト、監視、事故対応の代行はしていません。右の列は、サイトの制作・保守を担う会社や専門の事業者と、社内の担当で埋める部分です。
【要注意】読み違えやすい4つ
読み違い1：AIエージェントが相手なら、これまでの対策は効かない
❌ AIが攻めてくるのだから、これまでの守りは役に立たない。
⭕ 事業者自身が、対策は攻撃者がAIエージェントを使っているかどうかによって大きく変わることはないと書いています。今回狙われたのも、公開されたままのファイル、既知の脆弱性、フォーム、ログインでした。
読み違い2：User-Agentを見ればAIエージェントかどうか分かる
❌ ログの名乗り（User-Agent）で、AIエージェントのアクセスを見分けられる。
⭕ 手口の節の表のとおり、名乗りは段階ごとに変わり、10種や35種類程度を混ぜたランダムなものもありました。事業者の見分け方は非公開です。名乗りより、どの画面に何件、何が送られたかを見ます。
読み違い3：公表された3つのIPを止めれば安心
❌ 3つのIPアドレスを遮断すれば、この攻撃は防げる。
⭕ 原文は、検知時点で攻撃元として使われていたIPアドレスで、正規の通信で利用されている可能性もあると注意しています。IPアドレスは自社のログを調べる材料に使い、遮断するかどうかはサイトの保守を担う会社と相談して決めます。守りの中心は5か所の点検です。
読み違い4：「AIエージェント対策」の製品を入れれば済む
❌ AIエージェント対策をうたう製品を入れれば、ほかは後回しでよい。
⭕ 事業者が対策の最初に挙げているのは、バックエンドのAPIなども含めて、事前に漏れなく脆弱性がない状態にすることです。原文は必要に応じてシグネチャ（既知の攻撃の型）だけに頼らないWAFの導入も有効としていますが、何を足すかは、5か所の点検とログで自社の弱いところを把握してから決めるのが筋です。
Uravationならこう判断する｜製品の前にフォーム・ログイン・ログ
当社は、AIエージェントを業務に組み込む側の会社です。その立場から、今回の記録を受けた判断を書きます。
- 「AIエージェント対策」の製品探しから始めない。今回試された入口は、フォーム、ログイン、パスワード再設定、既知の脆弱性、公開されたままのファイルでした。まずこの5か所を、担当と期限を決めて確かめます。
- 見分けることにこだわらない。見分け方が非公開なので、AIエージェントかどうかは自社では確かめられません。確かめられなくても、やることは変わりません。
- ログの保存期間を先に確かめる。調べたい時に残っていなければ、入られたかどうかも分かりません。IPA の「直近１ヵ月、その後３ヵ月」をさかのぼれるかが目安です。
- AIエージェントに渡した鍵の棚卸しを同じ週にやる。止める順番は、外から届く仕組みで使う鍵と、権限の広い鍵からです。
- 制作会社には3つ聞く。「フォームとログインに回数の制限はあるか」「CMSとプラグインの更新は最後にいつ当てたか」「アクセスログは何か月分残っていて、すぐ出せるか」。
よくある質問
AIエージェントによる攻撃とは何ですか？
攻撃者が、自分で道具を使い、結果を見て次の行動を決めるAI（AIエージェント）に攻撃の作業をさせるものです。今回の事業者は、ウェブサーバの反応を読み取って次の行動を軌道修正する、という特徴を挙げています。AIそのものをだます攻撃（プロンプトインジェクションなど）とは別の話です。
日本のサイトでも実際に起きていますか？
はい。WAF「Scutum」を開発する株式会社ビットフォレストが2026年10月14日、10月10日夜からの監視で、少なくとも3つのIPアドレスから日本の企業のウェブサイトへの攻撃を確認したと公表しています。どの会社のサイトかは書かれていません。
どうやってAIエージェントの攻撃だと分かったのですか？
詳細は、公表すると対策されるため説明できない、と事業者は書いています。手元で試した8種類のモデルはすべて検出でき、検知した場合は間違いなくAIエージェントだと言える仕組みだ、というのが事業者の説明です。外から確かめる手段はありません。
個人情報が漏れたら、いつまでに報告しますか？
個人情報保護委員会は「発覚したら、まずは速やかに報告してください」とし、不正な目的で行われたおそれがある場合は「発覚日から、60日以内」としています。業種によっては、権限を委任された省庁が報告先になります。
AIを業務で使っている会社が、まずやることは何ですか？
AIエージェントや社内の仕組みに渡した鍵（APIトークン）と連携先を一覧にし、要らない鍵を止め、漏えいが疑われた時にすぐ無効にできるようにしておくことです。JPCERT/CC も「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」と求めています。
まとめ
2026年10月14日、WAF「Scutum」を開発する株式会社ビットフォレストが、少なくとも3つのIPアドレスから日本の企業のウェブサイトへのAIエージェントによる攻撃を確認したと公表しました。3つ目のIPは8時間弱・10段階のあいだにログインの総当たりも試していましたが、事業者は、対策は大きく変わらないと書いています。自社でやることは、5か所とログの確認、AIエージェントに渡した鍵をすぐ止められるようにしておくこと、報告の期限を担当者と共有しておくことの3つです。
あわせて読みたい
- AIエージェントによるサイバー攻撃｜事例と7つの確認（韓国の金融機関の件と、今週確かめる7項目）
- AIエージェント時代のサイバー攻撃 事例集と自社点検シート（無料の資料。点検用の Excel と、事故時の初動の1枚つき）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書に『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・書籍シリーズ累計66,000部・2026年10月時点）、『AI推進担当になったら読む本』（大和書房）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。
今日から始める3つのアクション
- 今日：自社サイトの5か所（問い合わせフォーム、ログイン、パスワード再設定と新規登録、更新、公開されたままのファイル）を、保守の担当か制作会社に確かめる
- 今週中：アクセスログと認証のログが何か月分残っているかを確かめ、公表された3つのIPアドレスからのアクセスがないかを見る（一致だけで判断しない）
- 今月中：AIエージェントや社内の仕組みに渡した鍵と連携先を一覧にし、止める順番と手順、報告の期限を担当者と決める
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
参考・出典
- AIエージェントによるウェブサイトへの攻撃の注意喚起（WAF Tech Blog・株式会社ビットフォレスト・2026年10月14日）（参照日: 2026-10-16）
- 直近で相次いでいる国内組織における不正アクセスに関する注意喚起 JPCERT-AT-2026-0030（JPCERT/CC・2026年10月8日公開、10月9日更新）（参照日: 2026-10-16）
- 不正アクセスによる漏えい等の事案を踏まえた対応について（内閣官房国家サイバー統括室・2026年10月9日・PDF）（参照日: 2026-10-16）
- 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について（IPA・2026年10月9日）（参照日: 2026-10-16）
- 漏えい等の対応とお役立ち資料（個人情報保護委員会）（参照日: 2026-10-16）
- 【注意喚起】相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」（NICT・2026年10月13日）（参照日: 2026-10-16）
- 国内WebサイトへのAIエージェント攻撃を観測 「8時間弱」続いた攻撃の推移を公開 国内セキュリティベンダー（ITmedia AI＋・2026年10月15日）（参照日: 2026-10-16）
この記事の内容を社内展開する方へ: 部門別 AIエージェント活用マップ 50選（無料・PDF 32ページ＋Excel） をダウンロードできます。
