【AI・セキュリティ】IPA「情報セキュリティ白書2026」公開。Web運営者が確認したい4つの対策

こんにちは、Ryohei（@ityryohei）です！

AIを使った不正アクセスが気になるものの、「自分のサイトでは何を見直せばよいのか」が分かりにくいと感じる方もいるのではないでしょうか。

IPAは2026年9月30日、「情報セキュリティ白書2026」のPDF版を公開しました。本記事ではこの発表と海外の一次情報をもとに、AIをめぐるリスクを整理し、Web開発者・サイト運営者が確認したい点を紹介します。

IPAが整理する、AIとセキュリティの3つの観点

IPAの白書公開の発表では、政府のサイバーセキュリティ戦略におけるAIへの対応を、次の3つの観点で紹介しています。

AIそのものを安全に利用・運用すること
AIを悪用したサイバー攻撃に対処すること
防御側でもAIを活用すること

この整理をWeb運用に当てはめると、外からの攻撃への備えに加えて、AIに渡すデータや、連携ツールに与える権限も確認対象になります。これは本記事の運用上の整理であり、白書が個別サイトに指示する設定ではありません。

海外ではAIが関与した可能性のある攻撃も報告

Google Threat Intelligence Groupは2026年5月11日の発表で、AIで開発されたと同社が考えるゼロデイ攻撃コードを、攻撃者が利用した事例を報告しました。ゼロデイ攻撃は、提供元が把握していない脆弱性や、修正プログラムがまだ提供されていない脆弱性などを悪用する攻撃です。

ただし、「AIで開発された」はGoogle側の評価です。この報告だけで、すべての攻撃がAIで自律的に実行されているとは言えません。同社は、AIによる脆弱性の発見や修正にも取り組んでいると説明しています。

ニュースを読む際は、AI利用が確認された事実なのか、調査組織の推定なのかを区別することが大切です。

攻撃の高度化と、AI連携の権限リスクを分けて考える

対策を考える前に、守る対象を2つに分けましょう。1つ目は、攻撃者がAIを使うかどうかにかかわらず、公開サイトやアカウントが狙われるリスクです。もう1つは、自分が導入したAIに情報や操作権限を渡すことで生じるリスクです。両者は重なる場合もありますが、確認すべき場所が異なります。

前者では、公開したサービスの脆弱性や認証情報の漏えいが侵入の入口になり得ます。AIの利用有無だけで危険度を決めず、対象の製品・バージョン・公開条件、自分の環境に該当するかを調べる必要があります。後者では、AIが誤った出力をしたときに、接続先で何を実行できるかが問題になります。

OWASPの「Excessive Agency」は、LLMを使うシステムに機能・権限・自律性を与えすぎることで、望ましくない操作につながるリスクを説明しています。対策として、使える機能と権限の最小化、重大な操作の承認、接続先側での権限検証などを挙げています。

ここからは、ニュースを読むAIにWordPress投稿機能を接続する場面を、仮想例として考えます。取得した外部ページの中に、記事の材料とは無関係な操作指示が混ざっていたとします。それを信頼できる命令として処理し、さらにAIが管理者相当の操作まで行える設計なら、記事生成を超える影響が生じる可能性があります。これは特定サイトで起きた事件の報告ではありません。

入力文を注意深く扱うだけでなく、接続先の権限で実行範囲を制限することが重要です。例えば、記事の作成が目的なら、ユーザー追加やプラグイン変更まで可能なアカウントを使う必要があるかを見直します。投稿できることと、サイト全体を変更できることを分けて設計します。

Web開発者・サイト運営者が確認したい4項目

以下は、上記の情報を踏まえた本記事の実務上の提案です。特定の攻撃を必ず防ぐ方法ではありませんが、日々の運用で確認する項目として使えます。

1. 公開しているソフトウェアを把握する

WordPress本体、プラグイン、テーマ、サーバー側のソフトウェアを一覧にし、提供元の更新情報を確認しましょう。不要な機能の整理や、更新前のバックアップ・動作確認も運用手順に含めます。

2. AI連携用の権限を必要な範囲に絞る

AIから投稿するためのアカウントは、作業に必要な権限で運用します。記事投稿だけならサイト全体の設定変更権限まで与える必要があるかを見直し、使用を終えた認証情報は失効させます。

3. AIへ渡す情報と外部コンテンツを区別する

APIキー、パスワード、個人情報、顧客データなどを、用途や取り扱い条件を確認せずAIへ入力しないようにします。また、AIが読むWebページや添付文書に書かれた指示を、そのまま公開・削除などの操作命令として扱わない設計が必要です。

4. 異常を検知し、復旧できるようにする

不審なログイン、予期しない記事やユーザーの追加などを確認できるようにし、バックアップからの復元手順も用意します。対策の導入だけでなく、通知を誰が確認し、異常時に何を止めるかまで決めておきましょう。

WordPressの自動投稿で、具体的に何を確認するか

WordPress公式の説明では、アプリケーションパスワードは特定のユーザーに紐づくAPI用の認証情報で、連携ごとに個別に失効できます。通常の管理画面ログイン用パスワードを外部ツールと共有するための仕組みではありません。通信にはHTTPSを使用します。

実務上は、連携専用ユーザー、連携ごとの認証情報、実際に必要な操作の一覧をセットで管理すると、問題が起きたときに停止する対象を判断しやすくなります。アプリケーションパスワードを発行しただけで、権限が投稿用途に限定されるとは考えないでください。利用するユーザーの権限と、連携サービスの実行可能な操作を確認します。

また、APIが公開されていることと、未認証で投稿を書き換えられることは別です。外部連携のためにアクセス制限を調整する際は、読み取り・投稿・管理操作を区別して確認しましょう。接続できないからといって、原因が分からないまま複数の保護設定をまとめて解除するのは、変更の影響も分かりにくくします。

対策の優先順位と、確認したい証拠

まず、公開中の製品に関する悪用情報があり、自分の環境が影響条件に該当する場合は、提供元の案内に沿った対応を優先します。単に深刻度の数値が高いことだけでなく、外部から到達できるか、悪用が報告されているか、修正や回避策があるかを確認します。ニュースの見出しだけでは、この判断に必要な条件が抜けることがあります。

次に、認証情報と権限を点検します。連携ごとに用途・利用ユーザー・停止方法を記録し、使っていない認証情報を残さないようにします。AIに与える権限を見直した場合は、実際に許可したい操作ができることと、範囲外の操作が拒否されることの両方を確認するのが実務上の提案です。

継続運用では、ログが保存されているだけでなく、誰が確認するかを決めます。確認対象の例は、予期しない公開記事、知らないユーザーの追加、認証情報の不審な利用などです。異常を見つけたときに自動投稿を止める方法、該当する連携を失効させる方法、復旧を担当する人を事前に決めておくと対応の判断がしやすくなります。

バックアップも取得の成否だけで終わらせず、別の環境で復元できるかを確認します。復旧時点と保存期間を把握し、直近のバックアップにも不正な変更が含まれていないか調べる必要があります。ここまでの運用例は本記事の提案で、すべてのサイトに同じ設定値を適用するものではありません。