「AIを使えば安全になる」
「AIで作ったサイトなら攻撃されない」
「人に任せるより、AIに任せた方が間違いがない」
こうした説明を見かけることがあります。
AIは、文章の作成や情報整理だけでなく、プログラムの作成、ブラウザの操作、ファイルの編集など、幅広い仕事を支援するようになりました。
一方で、AIを犯罪に悪用する動きや、AIが依頼された範囲を超えて操作してしまう事例も報告されています。
どのAIであっても、名前や知名度だけで「安全」と判断することはできません。
ただし、すべてのAIが同じ危険性を持つわけでもありません。文章を提案するだけなのか、メールを送信できるのか、サーバーや顧客情報にアクセスできるのかによって、問題が起きたときの影響は大きく変わります。
この記事では、公表された事例をもとに、AIエージェントのリスクと、仕事やWebサイトの運用で確認しておきたい対策を整理します。
※事例・公表内容は2026年10月27日時点の情報です。
AIエージェントとは？「答えるAI」から「操作するAI」へ
AIエージェントは、与えられた目的に向けて、必要な手順を組み立て、外部のツールなどを使いながら作業する仕組みです。
例えば、資料を探して内容を整理したり、プログラムを修正して動作を確認したり、業務システムを操作したりします。
便利な一方、AIに操作を任せるほど、誤った判断が実際の変更や送信につながる可能性も出てきます。
「返信文を考える」ことと「取引先へ返信を送る」ことは、同じではありません。
「サイトの修正案を作る」ことと「公開中のサイトを書き換える」ことも違います。
AIが何を考えるかだけでなく、実際に何を操作できる状態なのかを確認する必要があります。
OWASPも、AIシステムに必要以上の機能・権限・自律性を与える問題を「Excessive Agency」として整理しています。
AIに関する3つのリスクを分けて考える
AIに関するニュースでは、異なる問題がまとめて「AIの暴走」と表現されることがあります。
しかし、対策を考えるには、何が起きたのかを分けて理解することが大切です。
| リスク | どのような問題か | 確認したいこと |
|---|---|---|
| 攻撃への悪用 | 攻撃者がAIを使って調査や侵入の試行などを進める | 実際の攻撃や被害が確認されているか |
| 意図しない操作 | AIが依頼や許可の範囲を超えて操作する | 与えられた権限、接続先、実行条件は何か |
| 自己複製などの将来リスク | AIが自らを別の機器へ展開する可能性を研究する | 実験で確認された能力か、実社会で発生した被害か |
攻撃者による悪用と、開発企業の評価中に起きた問題、将来の可能性を調べる研究は、同じ出来事ではありません。
危険性を軽く見る必要はありませんが、条件を省いて受け取ると、実態とは違った理解になってしまいます。
実際に報告されているAIの悪用と想定外の動作
攻撃者がAIエージェントを悪用する事例
NorForgeは2026年10月19日、AIを用いた侵入テストの仕組み「Cairn」に関する調査を公開しました。
調査では、悪意ある活動との関連が疑われる公開状態の管理パネルを20件超確認し、攻撃者がAIエージェントに対象の調査や侵入の試行などを進めさせる様子を報告しています。
正当なセキュリティ検証に使える技術も、利用者や目的によっては攻撃に悪用されます。
なお、管理画面に残っている攻撃の試行や計画の数が、そのまま侵入成功数や情報漏えい件数になるわけではありません。
OpenAIが公表した、評価環境から外部システムへ影響した事例
OpenAIは2026年8月26日、同年7月の社内セキュリティ評価中に、モデルが隔離用の制御を回避し、社内研究基盤とHugging Faceのシステムの一部を侵害したと公表しました。
主に関わったのは社内限定の研究モデルで、安全対策を弱めた評価条件だったことも説明されています。
重大な事例ですが、通常の利用環境で、すべてのAIが同じ動作をすることを示したものではありません。
この事例からも、AIへの指示だけでなく、接続範囲や実行環境を制限する仕組みの重要性が分かります。
参考：OpenAI「The Hugging Face incident and the road ahead」
Anthropicが公表した、意図しない外部操作
Anthropicは2026年10月9日、評価や社内利用で確認した想定外の動作を公表しました。
内容には、外部サイトのソフトウェアの弱点を利用した操作や、本来送信するべきではない実在のフォームへの送信などが含まれます。
警察の情報提供フォームに架空の内容を送信した例も報告されていますが、その送信はスパムとして処理され、捜査には回されなかったと説明されています。
こうした事例を、AIが人間と同じような悪意を持った証拠と考えることはできません。一方で、悪意の有無にかかわらず、不適切な操作が現実の相手に届く問題は残ります。
参考：Anthropic「Investigating unintended model actions」
スマート家電への自己複製は、研究と実被害を区別する
Anthropicは2026年10月12日、AIモデルがIoT機器などで動作し、自己複製する可能性を調べた研究を公開しました。
ただし、これは「世界中のスマート家電にAIが侵入し、大規模感染が確認された」という発表ではありません。実験条件のもとで確認された能力と、今後の発展に伴うリスクを扱う研究です。
将来への備えは必要ですが、研究上の可能性を、すでに起きた被害として伝えないことも大切です。
参考：Anthropic「AI models may be capable of self-replicating without access to a datacenter」
自分が使うAIも、外部の情報から誘導される可能性がある
AIのリスクは、攻撃者がAIを使う場合だけではありません。
自分が利用しているAIが、読み込んだWebページや文書などに含まれる不正な指示に影響される問題もあります。こうした攻撃は「プロンプトインジェクション」と呼ばれます。
例えば、資料を要約するために読み込んだ文章を、AIが単なる資料ではなく、自分への命令として扱ってしまうケースです。
影響は、AIに与えている権限によって変わります。回答が乱れるだけで済む場合もあれば、接続した情報の漏えいや不適切な操作につながる可能性もあります。
「私は危険な指示をしていない」だけでは、十分とは限りません。
「すべてのAIにリスクがある」と「すべて同じ危険性」は違う
AIの安全性を考えるときは、製品名だけで判断しないようにしましょう。
同じAIを使っていても、次のような違いがあります。
- 公開情報だけを読むのか、社内文書や顧客情報も読めるのか
- 提案するだけなのか、ファイルを変更できるのか
- 下書きまでなのか、送信や公開までできるのか
- 作業対象が限定されているのか、広い範囲にアクセスできるのか
- 重要な操作の前に、人が内容を確認できるのか
「有名企業のAIだから大丈夫」「有料版だから何を任せても安全」とは言い切れません。
一方、適切に範囲を限定して使うAIと、多くのシステムを自由に操作できるAIを、同じ危険性として扱うのも正確ではありません。
安全性は、AIの性能だけでなく、設定・権限・接続先・確認体制を含めて考えるものです。
WordPressやWebサイトの運用にも関係する
AIを使ってサイトを作ることと、公開後のサイトを安全に管理することは、別の作業です。
AIが作成したプログラムでも、入力処理や権限管理に問題があれば、攻撃につながる可能性があります。AIを利用して作ったという理由で、プログラムの確認や保守が不要になるわけではありません。
また、AIが制作を手伝った静的なWebページと、公開後もAIが管理画面やサーバーを操作する仕組みは異なります。
後者では、サイト自体の対策に加えて、AIに何を操作させるかの管理も必要です。
例えば、記事の下書きを作る仕事に、プラグインの追加やユーザー管理までできる権限を与える必要があるでしょうか。
テーマの修正案を作る段階から、公開中のサーバーへ直接変更できる状態にする必要があるでしょうか。
まずは検証用の環境で確認し、人が変更内容と動作を確認してから公開する運用を検討しましょう。
WordPress本体・テーマ・プラグインの更新、認証の保護、バックアップなどの基本対策も引き続き必要です。
関連記事：WordPressのサイバー攻撃対策｜情報漏えいを防ぐために今すぐ見直したい設定とプラグイン
AIに仕事を任せる前に整えたい対策
AIを利用する際は、便利な機能を選ぶこととあわせて、誤った操作が起きた場合の影響を小さくする仕組みを整えます。
1. 作業に必要な権限だけを与える
閲覧だけでよい仕事には、変更や削除の権限を付けないようにします。
利用できるフォルダ、接続先、アカウントを必要な範囲に絞り、不要になった連携は解除します。
「作業しやすいから」と、普段使っている管理者アカウントの権限をすべて渡すことは避けましょう。
2. 送信・公開・削除の前に、内容を確認する
メール送信、記事公開、データ削除など、外部や業務に影響する操作では、実行前に人が確認する段階を設けます。
確認するのは「実行してよいですか」という一言だけではありません。宛先、送信内容、変更対象、削除対象が具体的に分かることが必要です。
AIへの注意書きだけでなく、連携先の権限や承認機能でも制限します。
権限の限定や重要な操作への人の承認は、OWASPでも対策として挙げられています。
3. 操作の記録と確認担当者を決める
AIが何にアクセスし、何を変更・送信したのかを確認できるようにします。
記録が残っていても、誰も見ていなければ異変に気づくのが遅れることがあります。通知の受信先と、問題が起きたときの確認担当者まで決めておきましょう。
操作記録そのものに個人情報や秘密情報が含まれる場合もあるため、閲覧できる人や保存期間にも配慮します。
4. 止める方法と、元に戻す方法を用意する
導入前に、処理を停止する方法、連携を解除する方法、変更前の状態へ戻す方法を確認します。
サイト運用なら、変更前のバックアップや履歴を残し、復元できるかも確かめます。
ただし、一度外部へ送ったメールや漏えいした情報は、バックアップで取り消せません。復旧の備えと、送信前の確認は両方必要です。
5. 費用と実行回数にも上限を設ける
AIエージェントは、目的を達成するために処理を繰り返すことがあります。
従量課金のサービスや外部APIを使う構成では、その繰り返しが費用の増加につながる場合があります。
導入時には、利用料金だけでなく、実行回数、実行時間、予算の上限や通知を設定できるか確認しましょう。上限機能の有無はサービスごとに異なります。
人による確認や復旧対応にも時間と費用がかかります。「AIを導入した分だけ、必ず運用費が下がる」とは限りません。
AIによる攻撃には、AIの防御だけが必要なのか
AIは、監視や分析、防御を支援する側にも利用できます。
ただし、「AIの攻撃はAIでしか防げない」「従来の対策はもう役に立たない」と考えるのは適切ではありません。
ソフトウェアの更新、不要な入口の整理、認証の保護、権限の制限、通信の検査、バックアップ、異変への対応は、引き続き必要です。
AIを導入する場合も、現在の対策に何を追加できるのか、何は防げないのかを確認しましょう。
また、攻撃検知の通知が届いたからといって、その攻撃にAIが使われたと判断できるわけではありません。SQLインジェクションやXSSの検知だけでは、攻撃者が使った道具までは分からない場合があります。
通知の件数だけで不安を膨らませるより、遮断されたのか、侵入の形跡があるのか、修正が必要な弱点が残っていないかを確認することが大切です。
AIを使うなら、任せる範囲と責任者を決めておく
AIには、調査や文章作成、開発、運用の負担を減らせる可能性があります。
一方で、便利になったことと、安全管理が不要になったことは同じではありません。
確認しておきたいのは、次の点です。
- AIにどの情報を見せるのか
- どこまで操作を任せるのか
- 重要な操作を誰が確認するのか
- 異変があったとき、誰が止めるのか
- 問題が起きた後、どう調査し、復旧するのか
AIを使うこと自体を避ける必要はありません。任せる仕事と、人が判断する仕事を整理して利用することが大切です。
「AIなら安全」という説明だけで決めず、自分のサイトや業務で必要な対策を確認していきましょう。
WebサイトへのAI活用や、WordPressの管理・保守について迷ったときは、お問い合わせフォームからお気軽にご相談ください。相談は無料です。