「うちは小さな会社だから、攻撃する理由がない」。そう考えて、古いWebサイトや業務アプリを公開したままにしていないでしょうか。
攻撃者が、会社名や事業内容を知っているとは限りません。インターネット上のシステムを探し、弱点を調べる工程にAIが使われれば、これまで以上に多くの対象が短時間で調査される可能性があります。
企業がまず進めたいのは、何を公開しているか、誰が更新するか、異常時に誰が止めるかを明確にすることです。修正情報が出てから担当者を探し始める状態では、対応に時間がかかります。
レイズでは、手作業・検査ツール併用・AI併用の3条件で、架空のWebアプリを各5分間点検しました。この記事では、その結果と公式の注意喚起をもとに、経営者・Web担当者が保守会社と進められる対策を整理します。
まず行う3つのこと
- 会社サイト、EC、予約、管理画面、古い業務アプリを一覧にする。
- 更新を依頼する相手と、緊急時の連絡先を確認する。
- 利用中のシステムに、未適用の修正やサポート終了がないか確認する。
この記事の目次を見る
AIを悪用した攻撃は、すでに確認されている
JPCERT/CCは2026年10月15日、攻撃元サーバーの調査から、攻撃者がAIを利用して既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを公表しました。APIは、アプリとサーバーなどがデータや操作をやり取りする窓口です。JPCERT/CCの調査報告
10月23日更新の注意喚起では、AIを用いたペネトレーションテスト基盤を悪用する攻撃試行も報告されています。ペネトレーションテストとは、許可された範囲で侵入の可能性を確かめ、対策に役立てる試験です。そのための道具が、無断の攻撃にも使われています。JPCERT/CCの注意喚起・ケースE
ただし、AIを使う攻撃がすべて成功するわけではありません。同じ注意喚起でも、修正済みソフトウェアへの更新、APIのアクセス制御、不要な公開の停止、検知と初動対応の見直しが勧められています。
AIの登場によって、更新や権限管理が不要になることはありません。放置している弱点を減らし、異常を把握して対応するまでの時間を短くする必要があります。
新人社員：「AIが攻撃に使われるなら、もう防ぎようがないのですか？」
R.A.I：「まず、使っていない公開機能や未修正のソフトウェアを確認しましょう。攻撃への備えには、入口を減らすことと、異常時にすぐ動ける準備の両方があります。」
レイズで検証：手作業・検査ツール・AIを各5分使ってみた
2026年10月26日、レイズ代表の大塚が、自分のパソコン上に用意した架空のWebアプリを点検しました。備品購入・研修申込・資料印刷を題材に、同じ4種類の問題を意図的に含め、名称や処理の配置を変えた教材です。外部のWebサイトや顧客データは使っていません。
各条件の制限時間は5分。中心に見るコードは約50行で、仕様・全体コード・動くアプリも参照できる環境です。読む時間だけでなく、ツールやAIの待ち時間、動作確認、所見の入力・保存までを含めました。
表は横にスクロールして確認できます。
| 比較項目 | A：手作業 | B：検査ツール併用 | C：AI併用 |
|---|---|---|---|
| 進め方 | 仕様とコードを読み、必要に応じて動作確認 | 手作業にBanditを追加 | Bと同じ環境に、新しいAI会話での調査を追加 |
| 制限時間 | 5分 | 5分 | 5分 |
| 時間内に保存した具体的な問題候補 | 1件 | 1件 | 4件 |
| SQLの問題候補を手動で確定保存した時刻 | 開始から約4分33秒 | 開始から約1分50秒 | 開始から約1分18秒 |
| 保存証拠で確認できた内容 | 問題箇所の指摘。成立の裏付けは不足 | 問題箇所の指摘。成立の裏付けは不足 | 問題動作3件と、HTML未エスケープ応答1件 |
この表の時刻は、最初に気づいた瞬間や侵入に成功した時刻ではなく、候補を手動で確定保存した時刻です。 Cで4候補すべての確定保存が終わったのは、開始から約2分51秒でした。
A・Bが指摘したSQLの問題は、実際の問題箇所に対応しています。ただし、時間内の記録だけでは、問題の成立まで説明・実証できていません。Aには別に途中メモが1件ありましたが、具体的な問題候補には含めていません。
検証条件と比較の限界
BanditはPythonのコード検査ツールです。B・Cとも1.8.6版・同じ設定で、約50行の抜粋を開始時に自動検査し、それぞれSQLに関する警告を1件出しました。CのAI側の記録には「Bandit出力は受け取っていない」とあり、AIがその警告を活用したとは確認できません。
CではCodexを使用しました。画面表示をもとに本人が記録した設定は「GPT-6.1-Sol medium」です。これは実験時の申告であり、内部モデル版を独立に検証したものではありません。
同じ1人がA→B→Cの固定順で、異なる課題を1回ずつ実施しています。以前の試行経験もあり、課題差や慣れ、順序の影響をAIの効果から切り離せません。準備・採点の時間、AIの利用料金、実作業と待ち時間の内訳は今回の比較に含めていません。
採点は準備を担当したCodexによる保存記録の事後照合で、独立した第三者の評価ではありません。実在サイトへの侵入速度、攻撃の成功率、一般的な性能倍率を示す実験ではありません。
この条件で確認できたのは、AIを併用した試行では、5分以内に複数種類の問題候補と、その検討に使える証拠を残せたことです。「AIは人間の何倍速い」と結論づけるより、守る側も調査の補助にAIを使い、候補を実際の動作と照合する進め方に意味があります。
見つかった4種類の問題は、自社の何を点検する手掛かりになるか
Cの候補を保存された応答記録と照合すると、次のことが分かりました。いずれも架空データを使った検証環境での結果です。
表は横にスクロールして確認できます。
| 問題候補 | 保存証拠で確認できたこと | 自社の開発・保守で確認したい点 |
|---|---|---|
| SQLインジェクション | 一般利用者の検索結果に、別担当者の架空申請が表示された | 入力値をSQL文の命令部分へ直接つなげていないか。検索結果の閲覧範囲も制限しているか |
| 数量の下限チェック不足 | 負数の注文が受け付けられ、架空の利用可能額が20,000円から20,600円へ増えた | 数量や金額の範囲をサーバー側で検査し、業務ルールに反する処理を拒否しているか |
| 承認時の権限チェック不足 | 一般利用者の操作で、申請が未承認から承認済みへ変わった | 承認処理のたびに、操作する人の権限と対象をサーバー側で確認しているか |
| メモのHTML出力 | 入力したタグが、HTML応答へそのまま入った | 表示先に応じたエスケープ処理があるか。HTMLを許す場合は安全化しているか |
最後の項目は、HTMLとして解釈され得る出力を確認したものです。ブラウザ上でJavaScriptが実行されるところまでは、この検証では確かめていません。
SQLインジェクションへの基本対策は、SQLの命令と入力値を分離するパラメーター化クエリです。数量のような値は、形式だけでなく業務上許される範囲も検査します。OWASPのSQL対策・入力値の検証
権限は画面のボタンを隠すだけでは足りません。サーバーへ届く各リクエストで確認します。また、利用者の入力を表示する際は、表示先に適したエンコードやHTMLの安全化が必要です。OWASPの権限管理・XSS対策
担当者がコードを読めなくても、保守会社に「一般利用者が他人の情報を見られないか」「管理者だけの操作を実行できないか」を、検証環境で確認した記録とともに説明してもらうことはできます。
新人社員：「AIに見てもらって、問題なしと言われたら完了ですか？」
R.A.I：「確認したファイル・機能・利用者権限を記録しましょう。AIの回答だけでは、調べていない範囲や実際の動作までは分かりません。修正後も、問題が解消したことと通常業務が動くことを確かめます。」
サイトの停止は、受発注・請求・取引先にも影響する
セキュリティ対策で守りたいのは、サイトの画面だけではありません。ECが止まれば注文を受けられず、業務アプリが止まれば出荷や請求が滞ることがあります。
2024年のChange Healthcareへのサイバー攻撃では、医療機関などが請求を提出できず、支払いを受け取れない問題が生じました。米国CMSは、影響を受けた事業者の資金繰りを支えるため、支払いの前倒し措置を公表しています。この資料は、AIを使った攻撃だったと示すものではありません。共通サービスの停止が、利用企業の業務や入金に波及した例です。CMSの公表資料
元のnoteでは、このような被害の連鎖を考える言葉として「AI恐慌」を使いました。経済危機が必ず起こるという予測ではなく、AIで攻撃の調査が速まる一方、企業の対応が追いつかなければ何が起こり得るか、という問題提起です。
自社に置き換えるなら、明日、受注システムが使えなくなったとき、注文・出荷・請求をどう続けるかを確認してください。代替の受付方法、連絡先、再開時にデータを照合する手順があれば、停止による混乱を小さくできます。
企業が進める7つの対策
オーストラリアのサイバーセキュリティ当局も、中小企業に対し、不要なWebサイト・機能の停止、更新、開発ソフトウェアの検査、保守責任者の明確化を勧めています。中小企業向け公式ガイド
以下は、その考え方と今回の検証を、自社の作業に落とし込んだ7項目です。担当者が分からない項目は「未確認」として残し、確認を依頼する相手を決めましょう。
01公開しているものを一覧にする
会社サイトに加え、EC、採用、予約、管理画面、サブドメイン、以前作った業務アプリを確認します。社内の契約書・請求書・管理台帳と、保守会社が把握する一覧を突き合わせてください。
一覧には、URL、用途、保存する情報、管理会社、社内担当者を記入します。「現在も必要か」「担当者が不明ではないか」が判断できる状態にするのが最初の目標です。
02更新の担当者と範囲を決める
サーバー、PHPなどの実行環境、WordPress本体、プラグイン、独自コードを、誰が更新するか確認します。「保守契約がある」だけで、すべて含まれるとは限りません。
保守会社には、更新対象、対象外、緊急の修正情報を受け取る窓口、作業前後の確認方法を聞いてください。契約外のものは、担当・費用・作業範囲を整理します。
03不要な公開を減らす
古いキャンペーンサイト、使っていない管理機能、テスト用アプリなどは、業務への影響と必要なデータの保管を確認してから停止します。
トップページからリンクを消すだけでは、URLを知る人が開ける場合があります。停止やアクセス制限の後は、管理者に、権限のない状態でアクセスできないことを確認してもらいます。
04アカウントと権限を整理する
退職者、以前の委託先、使途不明のアカウントを洗い出し、必要性を確認して停止します。管理権限は必要な人に絞り、重要なアカウントでは多要素認証を有効にします。
業務アプリでは、ログインできるかだけでなく、「誰が、誰のデータを、どこまで操作できるか」も確認します。今回の承認処理のように、一般利用者が管理者の操作を実行できる問題は、ログイン機能があっても残り得ます。
05更新とログ確認を継続する
ソフトウェアの版・サポート状況・未適用の修正を記録し、修正が必要なものには担当と期限を付けます。変更前には戻す方法を用意し、適用後はログイン、検索、注文、送信など、そのシステムの主要な業務を確認してください。
ログはアクセスや操作の記録です。保存先、保存期間、確認する担当者、不審な動きがあった場合の連絡先を決めます。「収集している」だけでなく、異常を知らせる仕組みが担当者まで届くかを確認することも必要です。
06異常時の連絡先と判断者を決める
不審なログイン、身に覚えのない管理者追加、サイト改ざんなどが起きた際、誰が調べ、誰が公開停止を判断するかを決めます。休日や担当者不在時の連絡先も用意してください。
連絡先は、そのシステムが止まっても参照できる場所に保管します。最初の連絡では、発見日時・対象・症状・実施した操作を共有し、推測と確認済みの事実を分けます。具体的な流れは初動対応マニュアルでも確認できます。
07バックアップから業務を戻せるか試す
バックアップの存在だけで完了にせず、本番と分けた環境で復元し、必要なファイル・データ・設定がそろうかを確かめます。保存先には、本番のアカウントが侵害されても一緒に消されにくい保護が必要です。
復元後は画面表示に加え、検索・受注情報・権限などを確認します。復旧にかかった時間、どの時点のデータまで戻るか、停止中の注文をどう反映するかを記録し、再開できるかを業務担当者と判断します。ランサムウェア対策50項目も併せて利用できます。
CSVには、確認内容・完了の目安・状態・根拠・担当者・期限・確認日を記入できます。状態は「確認済み／要対応／未確認／対象外」で分け、対象外には理由を残してください。チェック数を安全度の点数にするものではありません。
よくある質問
AIの攻撃には専用のAI製品が必要ですか
最初に進めたいのは、自社が何を使っていて、どこまで管理できているかの把握です。更新、権限の整理、公開範囲の見直し、異常時の対応、復元の確認は、AIを使った攻撃への備えでも基本になります。追加の製品やサービスは、そこから残る課題に合わせて検討できます。オーストラリア政府の中小企業向けガイド（CGA）
制作会社に任せていれば社内での確認は不要ですか
依頼している範囲を社内でも把握しておきましょう。技術的な作業を委託していても、業務への影響や停止の判断、顧客への連絡は、自社の対応が必要になることがあります。担当者と契約範囲を共有しておくと、問題が起きた際の連絡が早くなります。
無料のWebサイトチェックで今回の4種類の問題を調べられますか
今回の実験は、仕様、ソースコード、動作するアプリを参照した点検です。レイズの無料チェックは、Webサイトの公開情報を確認するサービスで、確認範囲が異なります。
ログイン後の権限や内部の処理を詳しく確認するには、対象と権限を整理したうえで、別途調査の範囲を決める必要があります。無料チェックの結果だけで、こうした問題がないと判断することはできません。
今日の確認を、実際の対応につなげる
まず7項目を使い、公開中のシステムと更新担当者を確認してください。担当者が決まったら、未修正の問題、不要な公開、過剰な権限のうち、どれから対応すべきかを整理します。
実際の侵害が疑われる場合は、通常の棚卸しの完了を待たず、担当者へ連絡し、被害拡大の防止と記録の保全を進めます。更新や再起動が調査用の記録へ影響する場合もあるため、対応は調査担当者と調整してください。
AIは、守る側でもコードの確認や問題候補の整理に活用できます。ただし、顧客データや秘密情報をそのまま渡さず、利用条件と調査範囲を決め、出力を検証することが前提です。今回の実験も、候補の数だけでなく、保存された証拠まで確認しました。
入口を減らす。異常を早く知る。被害を広げず、仕事を戻す。 この準備を担当者・確認記録・次の対応まで具体化することが、企業の備えになります。
レイズのWeb AI Securityでは、Webサイトの公開情報から基本的な設定や状態を確認できます。無料チェックは、今回のように内部コードやログイン後の権限を検証するものではなく、侵害の有無やサイト全体の安全性を保証するものでもありません。
公開情報からの確認を入口に、内部の調査や修正が必要な場合は、対象と作業範囲を確認してお見積もりします。
参考資料と検証の出典
情報確認日：2026年10月27日。検証実施日：2026年10月26日。制作・編集：株式会社レイズ。検証の補助、保存記録の照合、記事制作にAIを使用しています。新人社員とR.A.Iは説明用の架空の案内役です。
- 元のnote記事：AI恐慌に備えよ。人間 vs AIでサイバー攻撃能力を比べてみた：問題意識と検証の経緯。サイト版の数値は、各5分の実験の保存記録に照合しています。
- JPCERT/CC：連続不正アクセス事案の攻撃手法に関する調査：攻撃へのAI利用の確認。
- JPCERT/CC：直近で相次いでいる国内組織における不正アクセスに関する注意喚起：2026年10月23日更新。AIを用いた基盤の悪用と対策。
- オーストラリア政府：Defending against AI-enabled cyber attacks：中小企業の保守・更新・復旧に関する確認事項。
- CMS：Change Healthcare/Optum Payment Disruption：サイバー攻撃による請求・支払いへの影響。
- OWASP：SQL Injection Prevention、Input Validation、Authorization、Cross Site Scripting Prevention：問題候補を対策へつなげる際の技術的な参照資料。
