―― 攻撃者もAIで「超効率化」する時代のセキュリティ対策 ―― 攻撃者もAIで超効率化する
時代のセキュリティ対策

「AIが書き、AIが狙う」時代のWebセキュリティ。
AI生成コードの脆弱性と最新ハッキングへの防衛術

対象：Webサイト運用担当者・情報システム担当者・経営層テーマ：Webセキュリティ / AIハッキング / 脆弱性（XSS・SQLi） / システム保守目的：AIによるサイバー攻撃の現状とAI生成コード特有のリスクを理解。防衛体制を構築。最終更新日：2026年10月7日

生成AIの普及により、非エンジニアでも「問い合わせフォームの機能追加」や「データベースの抽出スクリプト」を数秒で書けるようになりました。
しかし、この恩恵を最も喜んでいるのは、実は「悪意を持ったサイバー攻撃者（ハッカー）」かもしれません。

現在、サイバーセキュリティの最前線では、恐ろしいエコシステムが生まれつつあります。
それは、「AIに書かせた『脆弱なコード（セキュリティの穴）』が本番環境に残り、攻撃者がAIも使ってそれを自動で探し、突いてくる」という構図です。

本記事では、Web・システム運用のプロフェッショナルとして、現場で懸念が高まっている「AI生成コード特有の脆弱性（特にXSS）」の実態と、高度化する「AIを使った攻撃」から自社のWebサイトを守るための具体的な防衛術を解説します。

1. 攻撃者もAIで「超効率化」している現実

私たちがAIを使って企画書を書いたりコードを生成したりしているのと同じように、攻撃者もAI（悪用目的に調整されたLLMや、制限を回避されたAI）を使って、攻撃プロセスを「自動化・高度化」しはじめています。

● 脆弱性スキャンと悪用の自動化

かつては手動で行っていた「標的サイトの弱点探し」や、見つかった弱点の悪用手順の組み立てを、AIエージェントに任せる研究・事例が報告されています。機械は24時間止まらないため、公開サーバーは常に自動スキャンにさらされている前提で考える必要があります。

● ポリモーフィック・マルウェア（自己変異型マルウェア）の生成

実行のたびにコードを変化させ、アンチウイルスの検知をすり抜けるマルウェアです。生成AIを悪用して亜種を大量に生成する手法は研究段階で報告されており、従来の「定義ファイルによる検知」が効きにくくなる懸念があります。

● 標的型フィッシングの巧妙化

「不自然な日本語」で見破れていた詐欺メールは、もはや判断材料になりません。AIが企業の公開情報やSNSを読み込み、取引先を装った自然な文面で仕掛けてくることが想定されます。IPAも、AIによる加工・生成を悪用したサイバー攻撃の巧妙化をリスクとして挙げています。

サイバー攻撃のハードルは下がり、「数撃ちゃ当たる」式の無差別攻撃に、AIによる自動化が加わりつつあります。

具体的な研究として、イリノイ大学の研究チームは、公開済みの既知の脆弱性（one-day脆弱性）15件を対象にした実験で、脆弱性の説明（CVE情報）を与えたGPT-4ベースのAIエージェントが87%を悪用できたと報告しています。ただし条件には注意が必要です。他のモデルや既存のスキャナーは0%で、説明を与えない場合のGPT-4の成功率は7%に下がりました。つまりこの研究が示したのは「弱点を見つける力」より「見つかった弱点を突破する力」であり、2024年時点・15件という限られた条件での結果です。それでも、脆弱性情報が公開されてから対応するまでの猶予が短くなるという点は、運用上きわめて重要な示唆です。

参照：Fang et al.「LLM Agents can Autonomously Exploit One-day Vulnerabilities」（arXiv, 2024）

こうした状況は国内でも認識されています。IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」では、組織向けの脅威として「AIの利用をめぐるサイバーリスク」が初めて3位に選ばれました（なお、順位は危険度そのものではなく、選考会が社会的影響の大きさを判断した順です）。

参照：IPA「情報セキュリティ10大脅威 2026［組織］解説書」

2. AIが書いたコピペコードは、なぜ攻撃者の標的になるのか

攻撃が高度化する一方で、防御側（企業のWebサイト）には「確認されないまま本番に入ったAI生成コード」が増えています。

プログラミング知識のないWeb担当者が、「ChatGPTが出力したコード」をそのままWordPressのfunctions.phpやテーマファイルにコピペして実装するケースが増えています。AIは「とりあえず動くコード」を提示するのは得意ですが、プロンプトで明示的に求めない限り、セキュリティを考慮した堅牢なコードを選ぶとは限りません。

これは感覚論ではありません。セキュリティ企業Veracodeが2025年7月に公表した調査では、100以上のLLMに、脆弱性になりうる実装方法が選べる80のコーディング課題を与えたところ、約45%のケースで脆弱なコードが生成されたと報告されています。

この数字を読む際の注意点が3つあります。

これは「脆弱になりうる選択肢がある課題」を意図的に集めたテストの結果で、実務のコード全体の45%が脆弱という意味ではありません。
セキュリティに関する指示を与えない条件での結果です。指示すれば改善する余地はあります。
調査対象はAIモデルの出力そのものであり、「非エンジニアが使った場合」を測ったものではありません。ただ、レビューできる知識がなければ、脆弱な出力に気づけず、そのまま本番に入るリスクが高いのは確かです。

AIが生成したコードのセキュリティ実態

さらに重要なのは、この傾向が1年経っても大きく変わっていない点です。2026年7月公表の最新版でも、安全なコードを選べた割合は平均で約56%と、ほぼ横ばいでした。構文的に正しいコードを書く力は向上しても、セキュリティの面ではモデルの新しさや大きさがほとんど効いていません。

参照：Veracode「2025 GenAI Code Security Report」プレスリリース／Veracode「Spring 2026 GenAI Code Security Update」

こうした「確認されないままの隙だらけのコード」は、自動で弱点を探す攻撃者にとって、狙いやすい標的になります。

3. AI生成コードに潜む2つの代表的な脆弱性（XSS・SQLi）

では、AIが生成したコードには、具体的にどのような「隙」が生まれやすいのでしょうか。Veracodeの調査から、特に差が大きい2つの脆弱性を見てみます。

XSS：2025年7月版で、86%のケースで安全なコードを書けませんでした。最新の2026年版でも安全に書けた割合は約15%にとどまり、ほとんど改善していません。
SQLインジェクション：2025年7月版の失敗率は約20%でしたが、最新版では安全な実装（パラメータ化クエリ）を選べた割合が8割強まで上がり、改善が進んでいる領域です。

つまり現時点では、AIが特に苦手なのはXSS（および、ログに入力値を書き出す際に改行などを処理しない「ログインジェクション」）です。SQLインジェクションは比較的改善していますが、それでも約2割弱のケースで危険な書き方が出るうえ、被害が出たときの影響が大きいため、引き続き確認が必要です。

① クロスサイトスクリプティング（XSS） 出力エスケープの欠落

ユーザーが入力した内容（例：検索窓やコメント欄）を、画面にそのまま表示してしまう脆弱性です。AIに「検索キーワードを表示するコードを書いて」と頼むと、「文脈に応じた出力エスケープ」処理が抜けたコードが出力されることがあります。

【被害】 攻撃者が悪意のあるJavaScriptコードを入力すると、他のユーザーのブラウザ上でそれが実行され、ログイン状態を悪用された操作や、偽サイトへの誘導などにつながります。
【対策】 出力する箇所ごとの適切なエスケープが基本です。WordPressならesc_html()、esc_attr()、esc_url()などの関数を、出力先に応じて使い分けます。さらに多層防御として、CookieへのHttpOnly属性の付与（JavaScriptからのCookie窃取を防ぐ）や、CSP（Content Security Policy）の設定で被害を軽減できます。ただし、XSSが成立してしまえばCookieを盗まれなくても操作は悪用されうるため、これらはあくまで補助的な対策です。

クロスサイトスクリプティング

参照：OWASP Top 10:2025「A05:2025 - Injection」（XSSはInjectionに含まれる）

② SQLインジェクション（SQLi） プレースホルダ（prepared statement）の欠落

データベースとやり取りする際、入力された文字列を「データベースを操作する命令（SQL）」として誤認識してしまう脆弱性です。AIは、プレースホルダ（prepared statement）を使わず、入力値を直接SQL文に文字列連結する危険なコードを出力することがあります。エスケープ処理だけでは限界があるため、根本的な対策はパラメータ化クエリ（プレースホルダ＋値のバインド）です。WordPressでは$wpdb->prepare()が該当します。
なお、プレースホルダが使えるのは「値」の部分のみです。テーブル名・列名・ORDER BYなどを外部入力で切り替える場合は、あらかじめ許可した値のリストと照合する方式が必要です。

【被害】 問い合わせフォームの入力欄などに特殊な文字列を入れるだけで、データベースが不正操作され、顧客の個人情報が抜き取られたり、データが消去されたりする、重大な情報漏洩につながります。

SQLインジェクション

4. 「プレビューで動いたからOK」が招く最悪のシナリオ

XSSやSQLインジェクションの恐ろしいところは、「脆弱性があっても、普段の操作では全くエラーが出ず、正常に動いているように見える」ことです。

現場で起きうる崩壊のプロセス

担当者がAIで「予約フォームの項目追加コード」を生成する。
テスト環境（プレビュー）で確認すると、見栄えも良く、データも送信できたため「成功した！」と思い込み、本番環境へコピペ（実装）する。
しかし、コードには「入力値の検証」と「プレースホルダによるSQL実行」が欠落していた。
数日後、攻撃者の自動ツールがそのフォームの脆弱性を検知する。
不正なSQLが送信され、顧客名簿が流出。企業は謝罪対応や損害賠償、再発防止対応に追われる。

「動く＝正しい」ではありません。コードの裏側に潜む「見えない穴」を塞ぐことこそが、エンジニアリングの本当の価値なのです。

さらに注意したいのが、AIを使うと、かえって「安全に書けた」と思い込みやすいという研究結果です。スタンフォード大学の研究チームによるユーザー実験では、AIアシスタントを使った参加者のほうが、使わなかった参加者より安全でないコードを書く傾向があり、にもかかわらず「安全なコードを書けた」と信じる傾向が強いことが示されました。（対象は開発者で、実験も2022年頃のものですが、「確認する習慣がなければ気づけない」という本質は今も変わりません。）

参照：Perry et al.「Do Users Write More Insecure Code with AI Assistants?」（Stanford University）

なお、「権限チェック（認可）の欠落」はSQLiとは別系統のリスクです。OWASP Top 10:2025でも、アクセス制御の不備（Broken Access Control）は第1位に位置づけられています。こちらが抜けると、SQLを介さずとも「他ユーザーのデータが本来見えてはいけないのに見える」といった事故に直結するため、あわせて確認が必要です。

参照：OWASP Top 10:2025（日本語）

5. プロが実践するAI時代のWebシステム防衛術

AIによる攻撃が現実の脅威になった今、私たちはどのようにWebサイトやシステムを守るべきでしょうか。プロの保守現場で実践されている防衛策を紹介します。

実践1：コードレビューの多重化（人間＋SASTツール）

AIが生成したコードを本番環境に入れる前に、必ずセキュリティの専門知識を持つエンジニア（人間）がレビューを行います。さらに、SAST（静的アプリケーション・セキュリティ・テスト）ツールを開発工程に組み込み、コード内の脆弱性を自動解析する「二重のチェック体制」を構築します。SASTはあくまで補助であり、最終判断は人間が行うことが前提です。また、AIにコードを依頼する段階で「出力時のエスケープ」「プレースホルダの使用」「権限チェック」を明示的に求めることも、リスクを下げる第一歩になります。

実践2：WAF（Web Application Firewall）の導入と最適化

万が一、アプリケーション（CMS）側に脆弱性が残っていたとしても、攻撃の通信そのものを検知して遮断する「WAF」をサーバーの前段に設置します。
ただしWAFは万能の解決策ではなく、あくまで補完的な防御層です。アプリ側のコード修正やレビューの代替にはならないため、クラウド型WAFで常にシグネチャ（防御ルール）を最新に保つ運用とセットで考えます。

実践3：CMSのガバナンス強化（権限分離）

WordPressなどのCMSにおいて、管理画面からテーマやプラグインのコードを直接編集できる機能（テーマエディタ・プラグインエディタ）を無効化します。WordPressであれば、設定ファイル（wp-config.php）のwp-settings.phpを読み込む行より前に、次の定数を追記します。
define('DISALLOW_FILE_EDIT', true);
これにより、管理画面上でAIのコードをその場でコピペできる経路を塞ぎ、Git等を通じた正規のリリースフローに一本化しやすくなります。
ただし、この設定で消えるのは管理画面のエディタだけです。サーバーへのSFTP接続やホスティングの管理画面から直接ファイルを編集することは可能なため、サーバー側のアクセス権限管理もあわせて行います。より厳格にしたい場合は、プラグイン・テーマの導入や更新までダッシュボードから止めるDISALLOW_FILE_MODSもあります。ただし更新作業を別の手段で行う運用が必要になるため、体制に合わせて選択します。
※作業前に必ずwp-config.phpのバックアップを取得してください。記述の位置や書式を誤ると、サイトが表示されなくなる場合があります。

参照：Jetpack「How to Disable File Editing in WordPress (DISALLOW_FILE_EDIT)」

6. まとめ：AIの盾には「プロの知見」という鎧が必要

AIは業務を劇的に効率化する素晴らしいツールですが、サイバー空間においては「攻撃者」の能力も同時に引き上げうるという事実を忘れてはいけません。

攻撃者はAIで脆弱性の悪用を自動化しはじめている。公開済みの脆弱性は、対応が遅れるほど危険になる。
指示なしで生成させた場合、脆弱になりうる課題の約45%でAIは危険な書き方を選んだ。この傾向は1年経っても大きく改善していない。
特にXSSはAIが苦手で、最新の調査でも安全に書けた割合は約15%。SQLインジェクションは改善傾向だが、確認は不要にならない。
XSSやSQLインジェクションは、プレビュー画面では正常に動いて見えるためタチが悪い。
AI生成コードを本番実装するには、「プロによるコードレビュー」と「WAF等の多層防御」が欠かせない。

「AIにコードを書かせればエンジニアは不要になる」という考えは、自社をセキュリティ事故の危険に晒すだけです。AIがコーディングを代行する時代だからこそ、その安全性を担保する「プロのエンジニアによる保守・監査」の価値が高まっています。

参考情報・出典

ご利用にあたって（免責事項）
本記事は2026年10月7日時点の情報にもとづく一般的な解説であり、特定のサイト・システムの安全性を保証するものではありません。サーバーやCMSの構成、利用中のプラグイン・テーマ、ホスティング環境により、適切な対策や手順は異なります。設定ファイルの変更やコードの修正を行う際は、必ず事前にバックアップを取得し、可能であればテスト環境で動作を確認してください。
ご自身のサイトに合った進め方で迷われたときや、被害の可能性が心配なときは、お気軽にご相談ください。