生成AIを悪用したサイバー攻撃の事例と対策：警察庁・IPA の報告から、開発者が点検すること（2026年）

生成AI（文章・画像・音声・コードなどを作る AI）を悪用したサイバー攻撃は、国内でも、逮捕や報告の形で確かめられています。ただし IPA（情報処理推進機構）は、AI に固有の弱点を狙う間接プロンプトインジェクションは新しい攻撃だとしたうえで、それ以外の事例の大部分は、従来と変わらない攻撃が AI で半自動化・高速化されたものにとどまるので、従来の対策が有効だと書いています。同時に、AI の技術は速く発展していて、数か月のうちにも状況が変わりうるとも書いています。

この記事では、警察庁と IPA の報告を軸に、事例を「文面と翻訳」「声と映像」「道具づくり・脆弱性探し」「マルウェア」の型ごとに並べます。そのうえで、開発者が点検することを「基本を速く回す」「自分が使う AI の道具と鍵」「AI を組み込むアプリ」の3つに分けてまとめます（2026年10月時点）。攻撃の手順や、悪用できるプロンプト（AI への指示文）は書きません。

この記事でわかること

IPA が「新しい攻撃」と「従来の攻撃が速くなったもの」を分けていることと、出典ごとに言っている範囲が違うこと
警察庁・IPA・JPCERT/CC・AI 会社などの報告にある事例を、型ごとに（国内 → 海外の順で）
国が呼びかけているのは、まず基本を速く回すこと
自分が使う AI の道具（エディタ・拡張機能）と、AI の API キーも狙われること
AI を組み込むアプリで、プロンプトインジェクションが SQL インジェクションと違う理由と、設計で縛る考え方
自分と自分のアプリで確かめる点検表（12 行）

生成AIを悪用した攻撃は新しいのか？IPA の結論（2026年10月時点）
1. 出典ごとに、言っている範囲が違う
どんな事例がある？型ごとに見る、国内と海外の例（2026年10月時点）
国は何を呼びかけている？まず基本を速く回すこと（2026年10月時点）
自分が使う AI の道具と鍵も狙われる？API キーとエディタの脆弱性
AI を組み込むアプリを作るなら？プロンプトインジェクションは SQL インジェクションと違う
点検表：自分と自分のアプリで、何を確かめればよい？
この記事で扱わないこと
よくある質問
まとめ
参考資料

生成AIを悪用した攻撃は新しいのか？IPA の結論（2026年10月時点）

IPA の「情報セキュリティ10大脅威 2026」（2026年1月29日公開）では、組織向けの3位に「AI の利用をめぐるサイバーリスク」が入りました。2026年に初めて選ばれた項目です。解説書［組織編］（2026年3月12日に初版が出て、いま開ける PDF は2026年4月11日の四版）は、この項目の中身の1つに「AI の悪用によるサイバー攻撃の容易化、手口の巧妙化」を挙げています（IPA 10大脅威 2026・解説書［組織編］（PDF））。

同じ解説書のコラム「AI とサイバーセキュリティ～脅威の現在地と見通し～」は、書き出しで「現状では既存の脅威を増幅させる傾向が強く見られます」と書き、結びで次のようにまとめています。

間接プロンプトインジェクションは AI に固有の弱点を狙った新時代の攻撃と言えますが、それ以外の事例の大部分は、従来と変わらないサイバー攻撃がAI によって半自動化・高速化されているといったものに留まります。このため、従来のサイバーセキュリティ対策が有効です。

他方で、AI の技術はすさまじい速度で発展しており、数か月の内にも状況が変化する可能性が今のところ常にあります。

この記事は、この2つの文を柱にします。

前半：事例の大部分は、昔からの攻撃が AI で半自動化（半分は自動で）・高速化されたもの。だから従来の対策が効く。→ 次の節で事例を見て、その次の節で「基本を速く回す」ことを確かめます
AI 自体を狙う攻撃は別：AI が自分で読んだデータに悪い指示（不正なプロンプト）が混じっていて、それを取り込んでしまうと成り立つ攻撃を、間接プロンプトインジェクションといいます。IPA は、技術的な対策で完璧なものは知られていないので、AI が参照するデータが外から来た危険かもしれないデータで汚されないよう気を配る必要がある、と書いています。→ 自分が使う AI の道具と、自分が作るアプリは、別に点検します
後半：状況は数か月で変わりうる。IPA は、サイバーセキュリティの基本をより一層しっかり押さえつつ、予断を持たず最新の状況を見続ける姿勢が求められる、と書いています

出典ごとに、言っている範囲が違う

出典ごとに言っている範囲が違うので、この記事では「新しい攻撃ではない」と言い切りません。

出典	書いていること	言っている範囲
IPA のコラム（2026年）	間接プロンプトインジェクションは新時代の攻撃。それ以外の事例の大部分は、従来の攻撃が半自動化・高速化されたものにとどまる	「それ以外の事例の大部分」
政府機関 NCSC（National Cyber Security Centre）の評価（2025年5月7日）	攻撃者はほぼ確実にすでに AI を使って、既存の手口（偵察・脆弱性の調査と攻撃コードづくり・ソーシャルエンジニアリング〔人の心理のすきを突いてだます手口〕・簡単なマルウェアづくり・盗んだデータの処理）を強めている。2027年までは、新しい攻撃の道筋を作るより、既存の手口の進化と強化で、侵入の量と影響が増える見込みが高い	前半は「いま」の状態。後半は2027年までの見通し（予測）なので、柱にはしません
OpenAI の報告（2025年10月）	報告の範囲のサイバー攻撃の活動で、新しい手口や、OpenAI のモデルが攻撃者に新しい攻撃の力を与えた証拠は見つからなかった。悪意がはっきりした頼みは、モデルが断った	OpenAI が報告に載せた活動の範囲
Anthropic の報告（2026年9月10日）	この報告の攻撃そのものは見慣れたもの（盗まれた資格情報・修正を当てていないネットワークの出入口の機器・公開されたままのサービス・SQL インジェクション・フィッシング〔偽のメールやサイトでだます手口〕）で、守る側が見たことのない全く新しい手口に頼ったものは無かった。変わったのは攻撃の「経済」（economics）だと書いている	この報告に載った件の範囲

出典は、NCSC の評価・OpenAI の報告（PDF）・Anthropic の報告です。Anthropic の報告は、同じ段落でこのあと攻撃にかかる時間の数字も書いていますが、AI の能力を言う数字なので、この記事では取り上げません。

どんな事例がある？型ごとに見る、国内と海外の例（2026年10月時点）

警察庁は、令和8年（2026年）3月に「令和7年におけるサイバー空間をめぐる脅威の情勢等について」を出しました。特集Ⅰが「AIをめぐる脅威の情勢と警察の取組」です（警察庁の報告（PDF））。この報告と、IPA・JPCERT/CC・各社の報告にある事例を、型ごとに並べます。国内 → 海外の順です。

型	国内の例	海外の例
文面と翻訳	サポート詐欺で、標的の特定・ポップアップ・日本語への翻訳に生成AIを悪用（令和7年5月に容疑者を逮捕。警察庁の報告）	OpenAI が止めたアカウント。日本語を含む複数の言語でフィッシングの文面を作らせていた（2025年10月の報告）
声と映像	この記事では、国内の例は取り上げません	FBI の注意喚起（AI で作った声のメッセージ）。香港政府の回答（ディープフェイクのビデオ会議）
道具づくり・脆弱性探し	大阪の件（令和7年6月に逮捕）。警視庁の件（令和7年12月に逮捕）。JPCERT/CC のブログ（2026年10月15日）	Anthropic の発表（2025年11月13日）
マルウェア	警察庁が解析した、生成AIを悪用するマルウェア（令和7年7月、海外で確認された攻撃）	Google の脅威インテリジェンスの部門の報告（2025年11月）

型1：文面と翻訳（フィッシングや詐欺の文面）

フィッシングは、本物そっくりの偽のメールやサイトで、パスワードなどをだまし取る手口です。IPA の解説書は、AI の翻訳の力が上がったことで、攻撃者が Web ページの翻訳やフィッシングの文面を、標的の母国語で違和感なく書けるようになり、言語の壁を実質的に乗り越えた多言語での攻撃を格段に容易にする、と書いています。

国内の例：日本人を狙ったサポート詐欺（ウイルスに感染したと偽の警告を出す詐欺）の容疑者グループが、生成AIで標的の特定、ポップアップの生成、日本語への翻訳をしていたと、警察庁の報告にあります。日本の警察と海外の捜査機関の共同捜査で、令和7年5月に容疑者が逮捕されました
海外の例：OpenAI は、日本語を含む複数の言語でフィッシングの文面を作らせ、道具やマルウェアづくりの手伝いをさせていたアカウントを止めた、と2025年10月の報告に書いています。同時に OpenAI は、OpenAI のモデルは新しい攻撃の力を加えておらず、既存の作業の効率を少し上げることに使われたと書いています（OpenAI の報告（PDF））

防ぎ方：IPA の解説書が、AI の悪用による不正アクセスやソーシャルエンジニアリングを抑えるために挙げているのは、多要素認証（パスワードに加えて別の確認を求める仕組み）の徹底と、決裁・承認を複数名でチェックすることです。多要素認証は、パスワードの記事とサプライチェーン攻撃の記事でも点検しています。

型2：声と映像（なりすまし）

ディープフェイクは、AI で本物そっくりに作った偽の映像や音声のことです。

FBI の注意喚起（2025年5月15日）：2025年4月から、政府の高官を名乗る SMS（ショートメッセージ）と、AI で作った声のメッセージが、現職や元職の高官とその連絡先に送られています。別のメッセージアプリに移ろうと言って、悪いリンクを送るのが入口の1つです。FBI は、AI で作った中身は、見分けにくいところまで来ていると書いています（FBI の注意喚起）
香港政府の回答（2024年6月26日）：2024年1月末、本社の最高財務責任者（CFO）を装った、事前に録画したディープフェイクのビデオ会議に呼ばれた社員が、5つの口座への送金を認め、約2億香港ドルを失いました。会議は録画で、やり取りは無かったと書かれています。会社名は政府の文書にありません（香港政府の回答）

防ぎ方：見分けにくいところまで来ているので、この記事では見分け方には踏み込みません。FBI の勧めは、相手の番号を自分で調べてかけ直して確かめる、知っている人から新しい番号やアプリで連絡が来たら前から確かめてある経路で確かめる、お金を頼まれたら連絡先を自分で確かめてから動く、多要素認証を有効にして切らず、そのコードを誰にも渡さない、です。香港政府の回答も、身内や友人がビデオや音声で送金を頼んできたら、電話で確かめることを挙げています。

型3：攻撃の道具づくり・脆弱性探し

脆弱性は、ソフトウェアの弱点のことです。警察庁の報告は、AI を悪用すると、専門知識のない人でも、サイバー攻撃に使える情報に届きやすくなると考えられる、と書いています。

大阪の件：大手 EC サイトを装ったフィッシングサイトを作るときに、生成AIを悪用して改修していた男らを、令和7年6月に不正アクセス禁止法違反で逮捕しました。JC3（日本サイバー犯罪対策センター）が捜査に協力しています（警察庁の報告）
警視庁の件：警視庁が令和7年12月に逮捕した件（警察庁の報告）です
JPCERT/CC のブログ（2026年10月15日）：国内の連続不正アクセスを調べる中で、攻撃者が AI を使って、既知の脆弱性のスキャンや API 経由の攻撃をしていたことを確かめた、と書いています。攻撃元のサーバーは、日本以外の地域向けのサービスにも攻撃していました
Anthropic の発表（2025年11月13日）：Anthropic は、2025年9月中旬に怪しい動きを見つけ、調べると、Anthropic の Claude Code（コードを書く AI の道具）を操って、世界の複数の標的への侵入を試み、少数で成功した諜報活動だったと書いています。国の支援を受けたグループによる活動と見ている、とも書いています。攻撃者は Claude Code の安全の仕組みをだまして外した（脱獄）とあり、Anthropic はアカウントを止め、影響を受けた先に知らせ、当局と連携した、と書いています。同じ発表は、AI はいつも正しく動いたわけではなく、ときどき資格情報をでっち上げたり、公開されている情報を「秘密を取った」と言ったりした、とも書いています（Anthropic の発表）

防ぎ方：JPCERT/CC のブログの勧めは、4つあります（JPCERT/CC のブログ）。

API の認証に使う秘密鍵や、有効期間の長い認証情報を、アプリに埋め込まない
アプリの中の署名処理や難読化（読みにくくすること）だけに頼らず、サーバー側で利用者を認証し、操作の対象と内容に応じて認可する
レート制限（一定時間の回数の制限）と、異常なリクエストの監視をする。正規のアプリ以外からのアクセスも想定する
外の URL の内容を取得する API では、アクセス先を制限し、リダイレクト後の宛先も確かめる

認可は認証と認可の記事で扱っています。

型4：マルウェア

マルウェアは、悪意のあるソフトウェアの総称です。

国内の例（警察庁が解析）：令和7年7月、海外で、政府職員を装った者が、生成AIを悪用するマルウェアをメールに添付して、政府機関宛てに配る攻撃が確認されました。警察庁が検体を解析すると、マルウェア本体には攻撃の命令が入っておらず、感染した端末が使う生成AIのサービスを悪用して、不正な命令を作らせていました
海外の例（Google）：Google の脅威インテリジェンスの部門（GTIG）は、2025年11月の報告で、実行中に LLM（大規模言語モデル。生成AIの中身）を使うマルウェアを初めて確かめたと書いています。そのうち PROMPTFLUX は、Google の Gemini に定期的に問い合わせて、ウイルス対策ソフトを逃れる新しいコードを得る仕組みを持ちます。ただし開発中か試験中で、相手のネットワークや端末に入り込む力はまだ見せていない、と書いています。Google は関係する資産を無効にしました（Google の報告）

IPA のコラムも、実行中に生成AIを活用して挙動やコードを変えるマルウェアが出現している、と Google の報告を出典に書いています。警察庁が解析したマルウェアと Google の報告のマルウェアが同じものかは、どちらの文書にも書かれていません。この記事では結び付けません。

防ぎ方：この型だけの対策は、この記事では取り上げません。IPA の結論の前半のとおり、従来の対策が土台になります。次の節で、国が呼びかけている「基本を速く回す」ことを見ます。

国は何を呼びかけている？まず基本を速く回すこと（2026年10月時点）

日本の政府は2026年5月18日、内閣官房国家サイバー統括室など複数の省庁・部局の連名で、「AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化について～Project YATA-Shield～」を出しました。2026年4月7日に Anthropic が公表した AI をはじめとする、最先端の AI（フロンティア AI）が、脆弱性を見つけて直す性能の急速な向上に備えるものです。一方で、高性能な AI が攻撃者に悪用されると、サイバー攻撃がより速く大規模に行われるおそれがあるため、悪用のリスクを前提に対策を強める必要がある、という書き方です（Project YATA-Shield（PDF））。同日、国家サイバー統括室は各府省庁に、資産管理・リスク評価・脆弱性対策・アカウント管理・バックアップ・ログ・監視・インシデント対応などの基本的な対策を徹底するよう、事務連絡を出しています（各府省庁への事務連絡（PDF））。金融庁と日本銀行は5月22日、金融機関等に求めたこととして、フロンティア AI による脅威の変化を踏まえた短期的な対応に取り組むよう要請しました。1か月程度をめどに進めることが期待される、としています（金融庁の発表）。要請の背景には、脆弱性の発見から攻撃までの期間が大幅に短くなりうると指摘されていること、スキルの低い攻撃者の悪用で高度な攻撃が増えることが懸念されていることが書かれています。どちらも「〜うる」「懸念」という見通しで、断定ではありません。そのうえで、事務連絡と金融庁の要請が引く英国 AISI（AI Security Institute）の評価は、よく守られたシステムを攻撃できるかは「言い切れない」とし、基本（更新・アクセス制御・設定・ログ）が大事だと書いています（AISI の評価・金融庁の要請（PDF））。

国が挙げた基本の中から、開発の現場にも当てはまりそうなものを選ぶと、次のとおりです。選んだのはこの記事です。事務連絡の宛先は政府機関、要請の宛先は金融機関等なので、そのまま自分の仕事に義務として当てはまるわけではありません。

セキュリティパッチ（修正）を速やかに当てる（事務連絡）
ソフトウェアとネットワークの構成を確かめ直し、脆弱性が見つかったとき、パッチを当てる先をすぐ特定できるようにしておく。使っていないネットワークのポートを閉じ、要らない特権 ID（強い権限のアカウント）を消す。インターネットへの露出を最小にする（金融庁の要請・事務連絡の脚注）
サポートが切れた製品は、サポートのある版に更新する。メーカーがパッチを出さないため（金融庁の要請）

Web 開発で点検することの全体は、Web 開発のセキュリティの基本にまとめています。

自分が使う AI の道具と鍵も狙われる？API キーとエディタの脆弱性

ここからは、AI を悪用した攻撃の側ではなく、自分が使う AI の道具そのものが狙われる話です。IPA のコラムが「新時代の攻撃」としたのは、AI に固有の弱点を狙う間接プロンプトインジェクションでした。点検のしかたも、前の節の基本とは別に考えます。

AI の API キーは、本番の資格情報と同じに扱う

API キーは、プログラムが AI のサービスを使うための鍵（合言葉のような文字列）です。Anthropic は、2025年12月から2026年8月に止めた件をまとめた2026年9月10日の報告で、次のように書いています。AI の API キーとセッションのトークンは狙われる。AI のまわりに利用者が作るつなぎ（サンドボックス・中継・再販）も、攻撃される面になる。だから組織は、AI の鍵とエージェント（AI が道具を使って作業を進める仕組み）の連携を、本番の資格情報と同じ真剣さで扱うべきで、攻撃者も同じ真剣さで狙っている、という内容です（Anthropic の報告）。サンドボックスは隔離した実行環境、中継はプロキシ（通信を取り次ぐもの）、再販は AI の利用権を転売することです。

同じ報告から、点検に使えることを3つ取り出します。

鍵はふつうの利用者のうっかりから漏れる：Anthropic は、不正な再販の元になる鍵は、ふつうの利用者が自分の製品・アプリ・公開のコードに、うっかり出してしまった API キーとセッショントークンが、いちばん多いと書いています。出し先の例は、GitHub、スマホアプリのインストールファイル、Docker のコンテナ、Web サイト、チャットボットです。攻撃者は、こうした所から鍵を掘り続けている、とあります
鍵が盗まれると、攻撃者は3つを得る：Anthropic は、売れること、他人の費用で攻撃の計算を回せること、動きが鍵の持ち主のものに見えること、の3つだと書いています
AI は正規の窓口から買う：Anthropic は、安さをうたって、通信と資格情報を知らない中継に通させるものは、利用者のデータとシステムに大きな危険を持ち込む、と書いています

鍵を .env に分ける方法や、コミットしてしまったときの扱いは、.env と環境変数の記事にあります。盗まれたときに取り替えられる資格情報の一覧は、サプライチェーン攻撃の記事の点検表にもあります。

AI のエディタや拡張機能の脆弱性

AI のコードエディタや拡張機能にも、脆弱性が見つかっています。脆弱性には CVE という識別番号が付きます。深刻さを0〜10で表す CVSS という点数が付くこともありますが、同じ脆弱性でも、採点する機関によって点数が違うことがあります（HIGH・CRITICAL は深刻さの区分で、CRITICAL のほうが重い区分です）。次の3件は、版と直し方が出典ごとにはっきり書かれているものです。

件	対象	直った版・対応	利用者がすること
CVE-2025-54135（2025年8月）	AI のコードエディタ Cursor	1.3.9 で直った	使っている版が 1.3.9 以降かを確かめる
CVE-2025-53773（2025年8月12日公開）	Microsoft の告知の対象は Visual Studio 2022 version 17.14（題は「GitHub Copilot and Visual Studio」）	17.14.12 で直った	利用者が更新する必要がある。悪用は確認されていない（Microsoft の告知）
CVE-2025-32711（EchoLeak。2025年6月11日公開）	Microsoft 365 Copilot	Microsoft の側で対応済み	利用者がすることは無い。悪用は確認されていない（Microsoft の告知）

Cursor：作業中のフォルダの中のファイルを、利用者の承認なしに書けました。MCP（AI が外の道具を使うための仕組み）の設定ファイル（.cursor/mcp.json など）がまだ無いと、間接プロンプトインジェクションとつなげて設定ファイルを書かせ、利用者の承認なしにコードを実行させることができました。IPA のコラムは、この件を、プロジェクト内のファイル（README など）に悪い指示を埋め込み、開発者の権限で任意のコードを実行させるもの、と説明しています。点数は GitHub の告知が 8.5（HIGH）、NVD が 9.8（CRITICAL）です（Cursor の告知）
Visual Studio：コマンドインジェクション（コマンドに不正な指示を紛れ込ませる攻撃）で、攻撃者が、利用者の PC の上で（ローカルで）コードを実行させることができました。点数は Microsoft の採点で 7.8 です（Microsoft の告知）
EchoLeak：AI へのコマンドインジェクションで、攻撃者がネットワーク越しに情報を出させることができました。IPA のコラムは、メールなどに含まれる、人の目に見えないプロンプトを AI に読ませて、利用者の操作なしに秘密を外へ送らせるもの、と説明しています。点数は Microsoft の採点が 9.3（CRITICAL）、NVD の採点が 7.5（HIGH）で、食い違います（Microsoft の告知）

直し方は製品ごとに違います。更新が要るもの、提供元が直したので利用者はすることが無いものがあるので、使っている製品の告知で確かめます。VS Code の Copilot を更新すれば直る、とは書けません。CVE-2025-53773 の告知の対象製品は、Visual Studio 2022 version 17.14 の1件で、VS Code の拡張が対象かは、告知の中に見つけられていません。

AI の道具に読ませるものと、使い方の心がけ

IPA の解説書は、AI を使う側の対策として、次のことを挙げています（IPA 解説書［組織編］（PDF））。

社内の秘密情報などを、安易に入力しない
AI は、利用者の指示を正確に反映した結果を出すとは限らないこと、ハルシネーション（もっともらしい誤りや作り話を出すこと）があることを理解する
AI に頼りすぎないよう気をつける
経営者層向けとして、許可・認可していない AI サービスの利用（シャドー IT）を禁止する

AI の道具に読ませるものは、前の節で見たとおり、README のようなファイルの中に悪い指示が混じりうると分かったうえで扱います。Anthropic の発表にも、AI が資格情報をでっち上げた例があります。AI の出力は、そのまま使わず、確かめてから使います。

AI を組み込むアプリを作るなら？プロンプトインジェクションは SQL インジェクションと違う

自分のアプリに AI（LLM）を組み込む場合は、使う側の点検とは別に、作る側の点検が要ります。プロンプトインジェクションは、AI への指示（プロンプト）に、本来の指示とは違う悪い指示を紛れ込ませて、AI の動きを変えてしまう攻撃です。

英国の政府機関の NCSC は、2025年12月8日のブログで、プロンプトインジェクションを SQL インジェクションと同じように考えるのは危険だ、と書いています。SQL インジェクションは、パラメータ化したクエリ（プレースホルダー）で正しく防げます。しかしプロンプトインジェクションは、同じようには防げるようにならない可能性が高く、望めるのは、攻撃の起こりやすさか影響を減らすことまで、という見立てです。理由は、LLM の内部では、「データ」と「指示」の区別がされないことです（NCSC のブログ）。SQL インジェクションとプレースホルダーは、SQL インジェクションの記事で説明しています。

OWASP の「Top 10 for LLM Applications」の最新は2026年版です。1位は Prompt Injection で、Excessive Agency（AI に与えた権限や自律性が過剰なこと）が3位に上がりました。1位の項目も、LLM には命令とデータの区別が仕組みとして無いので、確かな防ぎ方は今は無く、守りは「入口で止める」より「設計で縛る」ものだ、と書いています。破られる前提で、まわりのシステムを設計するという考え方です（OWASP の2026年版・PDF）。

NCSC と OWASP が挙げる、設計で縛る守りは、次のとおりです。

LLM ではない、決まった仕組みで動きを縛る：NCSC は、プロンプトインジェクションは製品や機器では完全に防げず、残るリスクとして、設計・構築・運用で管理するもの、と書いています
権限と判断を、コードに持たせる：資格情報と、状態を変える力は、モデルではなくアプリのコードに持たせ、操作ごとに最小の権限にします。操作が許されるかは、LLM に決めさせず、ロジックで認可します。認可は認証と認可の記事の話と同じです
AI に渡す道具と権限を、最小にする：OWASP の例では、商品をすすめるだけのエージェントは、products テーブルを読むだけで足ります。ほかのテーブルにも、追加・更新・削除にも届かないよう、DB の権限で強制します
人の承認を挟む：権限の要る操作、取り消せない操作、外に見える操作の前に、人がはっきり承認します。要約ではなく、行う操作そのものを見せます。信頼できない入力、機密データ、状態の変更か外への通信、の3つに同時に届くエージェントは、危険が高いとみなします。外の知らない人からのメールを処理する LLM に、強い権限の道具を持たせないことも、NCSC の勧めです。ただし OWASP は、承認が多すぎると判断が鈍ることにも触れています
AI の出力を信用しない：モデルをほかの利用者と同じに扱い、出力を後ろの処理へ渡す前に確かめます。出す場所に合わせたエスケープ（HTML なら HTML のエンコード）、LLM の出力を使う DB の操作はすべてパラメータ化したクエリ、LLM が作った中身による XSS（悪いスクリプトを画面に出させる攻撃）に備えた、厳しい CSP（ブラウザーが読み込むものを制限する仕組み）、が例です。XSS と CSRF の記事も参照してください
記録する：不審な動きを見つけられるだけ、LLM の入出力の全部、道具の使用、API の呼び出しなどを記録します（NCSC）

点検表：自分と自分のアプリで、何を確かめればよい？

次の点検表は、ここまでの内容を、この記事で3つの区分に分けたものです。出典の機関が、この3つに分けているわけではありません。既存の記事の点検表と同じ点検は、そちらの記事にまかせて、リンクを付けています。各行の最後の（→）は、根拠を書いた節の名前です。

自分と自分のアプリで確かめること（チェックリスト）

基本を速く回す：使っているソフトの修正（パッチ）を、ふだんより早く当てているか。サポートの切れた版を使っていないか。インターネットに出している画面・API・管理画面を全部言えて、要らないものを閉じているか。全体の点検はWeb 開発のセキュリティの基本の点検表で（→「国は何を呼びかけている？まず基本を速く回すこと（2026年10月時点）」）
基本を速く回す：配るアプリに、API の秘密鍵や有効期間の長い認証情報を埋め込んでいないか。レート制限と、異常なリクエストの監視があるか（→「型3：攻撃の道具づくり・脆弱性探し」）
基本を速く回す：認可を、アプリの中の署名処理や難読化だけに頼らず、サーバー側で、操作の対象と内容に応じて確かめているか。やり方は認証と認可の記事の点検表で（→「型3：攻撃の道具づくり・脆弱性探し」）
基本を速く回す：送金・権限の変更・連絡先の変更を頼まれたら、前から確かめてある別の経路（自分で調べた番号にかけ直すなど）で確かめているか。決裁を1人で通せない形になっているか。自分と利用者のアカウントに多要素認証を使い、そのコードを誰にも渡していないか。多要素認証はパスワードの記事とサプライチェーン攻撃の記事の点検表で（→「型1：文面と翻訳（フィッシングや詐欺の文面）」）（→「型2：声と映像（なりすまし）」）
自分が使う AI の道具と鍵：AI の API キーとトークンを、本番の資格情報と同じに扱い、GitHub・アプリ・コンテナ・Web サイトに出していないか。AI は正規の窓口から使い、安さをうたう知らない中継に通していないか。手順は.env と環境変数の記事で（→「AI の API キーは、本番の資格情報と同じに扱う」）
自分が使う AI の道具と鍵：AI のエディタ・拡張機能を、使っている製品の告知で確かめて更新しているか。更新が要る件と、提供元が直したので利用者のすることが無い件があると分かっているか（→「AI のエディタや拡張機能の脆弱性」）
自分が使う AI の道具と鍵：秘密情報を安易に AI に入れていないか。許可されていない AI サービスを仕事に使っていないか（→「AI の道具に読ませるものと、使い方の心がけ」）
自分が使う AI の道具と鍵：AI の道具に読ませる外のファイル（知らないリポジトリの README など）に、悪い指示が混じりうると分かっているか。AI の出力（コード・答え）を、そのまま使わず確かめているか（→「AI の道具に読ませるものと、使い方の心がけ」）
AI を組み込むアプリ：プロンプトインジェクションは完全には防げない前提で、設計で縛っているか。資格情報と状態を変える力をアプリのコードに持たせ、「してよいか」をコードで確かめ、AI に渡す道具・機能・DB の権限を最小にしているか。DB の権限はSQL インジェクションの記事で（→「AI を組み込むアプリを作るなら？プロンプトインジェクションは SQL インジェクションと違う」）
AI を組み込むアプリ：取り消せない操作や外に見える操作の前に、人の承認を挟んでいるか。外の人の文（メール・Web）を読む AI に、強い権限の道具を持たせていないか（→「AI を組み込むアプリを作るなら？プロンプトインジェクションは SQL インジェクションと違う」）
AI を組み込むアプリ：AI の出力を、利用者の入力と同じく信頼せず、エスケープ・パラメータ化したクエリ・CSP を通しているか。やり方はXSS と CSRF の記事とSQL インジェクションの記事で（→「AI を組み込むアプリを作るなら？プロンプトインジェクションは SQL インジェクションと違う」）
AI を組み込むアプリ：ログを取り、見ているか。AI の入出力・道具の使用・API の呼び出しも記録しているか（→「AI を組み込むアプリを作るなら？プロンプトインジェクションは SQL インジェクションと違う」）

この記事で扱わないこと

攻撃の手順、悪用できるプロンプト、AI の安全の仕組みを外す（脱獄）文例。事例は、報告書に書かれている範囲の一文までにしています
AI やセキュリティ製品の選び方。どれがよいかは、この記事では決めません
ディープフェイクの見分け方。FBI は、AI で作った中身は見分けにくいところまで来ていると書いているので、別の経路で確かめることに絞りました
個人の名前や、攻撃者の呼び名
AI の能力を測る数字。出典に数字があっても、書いていません
IPA のコラムにある、ほかの例のうち、出典が民間の調査や報道のもの。当事者や公的機関の文書では確かめられていません
2027年以降の予測。NCSC の見通しは、予測であることを断って、本文では1か所だけ書きました

よくある質問

VS Code の GitHub Copilot は、CVE-2025-53773 の対象ですか？

この記事では、対象かどうかを確かめられませんでした。Microsoft の告知の対象製品は Visual Studio 2022 version 17.14 の1件だけで、17.14.12 で直ったとあります。NVD の対象製品の情報も、Visual Studio 2022 だけです。題は「GitHub Copilot and Visual Studio」ですが、VS Code の拡張の版や修正は、告知の中に見つけられていません。そのため、「VS Code の Copilot を更新すれば直る」とは書きません。VS Code で Copilot を使っているなら、Microsoft と GitHub の告知で、使っている製品が対象かを確かめてください。使い方はVS Code の Copilot の記事にあります。

警察庁が解析したマルウェアは、Google が報告した PROMPTFLUX と同じものですか？

同じかどうかは、文書から確かめられません。警察庁の報告は、解析したマルウェアの名前を書いていません。警察庁は「感染先の端末が利用する生成AIサービスを悪用して不正な命令を生成する」と書き、Google の報告は PROMPTFLUX が Gemini に定期的に問い合わせると書いていますが、同じとは言えません。この記事では結び付けていません。

警察庁の報告にある「民間企業の報告」は、Anthropic の発表のことですか？

警察庁の特集は、国家を背景とするサイバー攻撃グループが AI を利用し、人間の介入なしにサイバー攻撃を実施したとの民間企業の報告がある、と書いています。会社名は書かれていないので、Anthropic の発表のことかは、文書から確かめられません。Anthropic の発表の書き方は、人の介入が要ったのは、ときどきだけ、という趣旨です。「人の手をまったく介さず」とは書いていません。

まとめ

IPA のコラムの柱は2つ。AI 自体の弱点を狙う間接プロンプトインジェクションは新時代の攻撃だが、それ以外の事例の大部分は、従来の攻撃が AI で半自動化・高速化されたものにとどまるので、従来の対策が有効。ただし AI の技術は速く発展していて、数か月のうちにも状況が変わりうる
出典ごとに言っている範囲が違う（IPA の「大部分」、NCSC の「いま」と2027年までの見通し、OpenAI と Anthropic はそれぞれの報告の範囲）。この記事では「新しい攻撃ではない」と言い切らない
事例は、文面と翻訳（サポート詐欺・フィッシング）、声と映像（FBI の注意喚起・香港政府の回答）、道具づくり・脆弱性探し（大阪と警視庁の件・JPCERT/CC・Anthropic）、マルウェア（警察庁の解析・Google）の型で整理した
国が呼びかけているのは、まず、パッチを速く当てる、構成を確かめ直す、使っていないポートを閉じるといった基本。AISI は、よく守られたシステムを攻撃できるかは「言い切れない」と書いている
自分が使う AI の道具と鍵も狙われる。API キーは本番の資格情報と同じに扱い、AI は正規の窓口から使う。エディタの脆弱性は、直った版と、利用者がすることを製品の告知で確かめる。VS Code の Copilot を更新すれば直る、とは書けない
AI を組み込むアプリでは、プロンプトインジェクションは SQL インジェクションのようには防げない見込みが高いので、設計で縛る。権限と判断をコードに持たせ、道具と権限を最小にし、取り消せない操作の前に人の承認を挟み、AI の出力を信用しない
点検表は12行。既存の記事と同じ点検は、認証と認可・パスワード・サプライチェーン攻撃・XSS と CSRF・SQL インジェクションの記事にまかせた

Web 開発で点検することの全体は、Web 開発のセキュリティの基本にまとめています。状況は数か月で変わりうるので、警察庁の令和8年の報告や IPA 10大脅威 2027 が出たら、見直します。