LLMの台頭をサイバーセキュリティの防御面から考える
Replay.fmというPodcastをやっていて、約1年半セキュリティ系の記事を読み続けている。奇しくもLLMの台頭と時期が被っているのでLLMとセキュリティの関連についてのトピックはかなり多い。
その中で「サイバーセキュリティの領域で防御をする立場」から見たとき、LLMをどう捉えるといいか現時点での自分の考えをまとめてみる。
excuseになってしまうが、自分はセキュリティのリサーチャーではないのでカバレッジが低かったり詰めが甘い部分があるかもしれない。そういうのがあったら忌憚のない意見がほしいです(当ブログにはコメント機能がないのでSNSとかでぜひ)。追ってるfeedはそれなりに多いのでそこまで偏った意見にはならない、はず。
LLMの台頭によって何が変わったか
大きく分けて3つあると思っている。
1. LLM自体を狙う攻撃という概念が生まれた
新しく生まれたLLMというソフトウェア領域に対する攻撃手法が多く編み出されている。みんながよく見るものだとPrompt Injectionとかだろうか。
LLM01:2025 Prompt Injection
A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways. These inputs can affect the model even if they are imperceptible to humans, therefore prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model. Prompt Injection vulnerabilities exist in how […]
OWASPが公開しているOWASP Top 10 for LLM Applicationsなんかを覗いてみるとメジャーな攻撃手法を眺めることができる。
OWASP Top 10 for LLM Applications 2025
Discover the OWASP Top 10 for LLM Applications (2025) – essential guidance for securing large language model applications against emerging vulnerabilities.
OWASP Top 10 for Agentic Applications for 2026
The OWASP Top 10 for Agentic Applications 2026 is a globally peer-reviewed framework that identifies the most critical security risks facing autonomous and agentic AI systems. Developed through extensive collaboration with more than 100 industry experts, researchers, and practitioners, the list provides practical, actionable guidance to help organizations secure AI agents that plan, act, and make decisions across complex workflows. By distilling a broad ecosystem of OWASP GenAI Security guidance into an accessible, operational format, the Top 10 equips builders, defenders, and decision-makers with a clear starting point for reducing agentic AI risks and supporting safe, trustworthy deployments.
日本語のソースだとFlatt Security社の以下の記事もとてもよくまとまっている。
LLM / 生成AIを活用するアプリケーション開発におけるセキュリティリスクと対策 - GMO Flatt Security Blog
はじめに こんにちは、GMO Flatt Security株式会社セキュリティエンジニアの佐藤(@Nick_nick310)です。 近年、大規模言語モデル(LLM、 Large Language Models)の進化と普及は目覚ましく、多くのサービスや業務プロセスで生成AIとして活用されています。LLMは多大なメリットをもたらす一方で、その特性に起因する新たなセキュリティリスクも指摘されており、安全な活用のためには十分な理解と対策が不可欠です。LLMを自社のサービスや業務に組み込む際、どのようなセキュリティ上の課題に直面する可能性があるでしょうか。 本稿では、LLMを活用したアプリケーションを…
LLMをアプリケーションに組み込む際、要件によってはLLMのoutputからコントロールできる権限が強い場合がある。
昨今のAI Agentブームではその傾向が特に強いように感じられる。OpenClawなんかはその極地とも言える。
この前提で攻撃が成立した際のリスクは大きくなる可能性があるため、LLMを組み込んだアプリケーション開発をする際には意識しておきたい領域と言える。
Prompt Injection対策の限界
自分の認識だと今時点ではPrompt Injectionを完全に防ぐことは困難だと思っています。
門外漢でありながらLLMのプロンプトエンジニアリングを読んだ上での私の理解だとLLMは「ある文字列を渡した時に次の文字列を予測する」モデルであり、それ以上でもそれ以下でもないということです。
私たちが普段触れるCoding用のAI AgentやChatベースのLLMではこれに色々な皮を被せて目的を達成するためのソフトウェアとして実装されています。
当然、そのソフトウェアでPrompt Injectionの対策はいくつも行われていますが、一方で原理上防ぐ可能性が100%に近しい対策は存在しないのが現在地点です。
例えばSQLインジェクションでプリペアドステートメントを使ったり、XSSでHTMLエスケープを使ったりすることで(あえてこう表現しますが)100%に近い可能性で封じ込めることができます。
一方でLLMはどこまで行っても次の文字列を予測する君なので、最終的にモデルを騙し切ることができれば攻撃は成立します。これはLLMが渡された文字列のうちどの部分がエンドユーザから入力された任意の値であるかを常に正しく認識する方法が存在しないから、と理解しています。
いやいや、システムプロンプトでどうにかなるでしょ、と思ってもそれを回避するテクニックが色々あることは今さら語るまでもないと思います(気になる方は調べてください)。
下記の記事ではOpenAIのCISOであるDane Stuckey氏のXのポストを取り上げ、事実上Prompt Injectionに対する銀の弾丸であることを示唆していると語っています。
Dane Stuckey (OpenAI CISO) on prompt injection risks for ChatGPT Atlas
My biggest complaint about the launch of the ChatGPT Atlas browser the other day was the lack of details on how OpenAI are addressing prompt injection attacks. The launch post …
ただ、前述したように大手各社はこれを大いに認識しながら多層防御で対策を行っているので基本的には手法が見つかっては塞がれ、を繰り返していくものと思われます。
個人的に面白かった記事を2つ貼り付けておく。
Mitigating prompt injection attacks with a layered defense strategy
Posted by Adam Gavish, Google GenAI Security Team With the rapid adoption of generative AI, a new wave of threats is emerging across the ind...
OpenAI: Understanding prompt injections: a frontier security challenge
2. 従来から存在した脅威の変化
LLMが台頭する以前から存在していた攻撃手法や脅威も変化している。
変化しているのは主に効率と精度と言える。
ただし最終的にやってること自体は従来と変わらない、言い換えると新しいCWEが増えたりしたわけではないと理解している。
a. 攻撃の効率が上がる
コーディングの速度を上げるのと基本的に理屈は同じで、攻撃のための作業もAIで効率化される。
例えばGitHub Actionsのpull_request_targetを狙った攻撃では、AI Agentによる自動化の兆候が確認されている。2026年初頭に確認されたhackerbot-clawというキャンペーンでは、AIを活用して脆弱なワークフローを自動的にスキャンし、リポジトリの言語やフレームワークに合わせたペイロードを生成してPRを大量に送りつけていた。
攻撃者がAIを積極的に活用しているという事実は、AIプロバイダ自身が報告している。
Anthropicは2025年8月のThreat Intelligence Reportで、Claudeを悪用したランサムウェア開発や大規模な情報窃取・恐喝のケースを報告し、該当アカウントをBANしている。
Detecting and countering misuse of AI: August 2025
Anthropic's threat intelligence report on AI cybercrime and other abuses
さらに2025年9月にはClaude Codeを悪用した国家レベルのサイバースパイ活動まで検出・阻止している。
Disrupting the first reported AI-orchestrated cyber espionage campaign
A report describing an a highly sophisticated AI-led cyberattack
私たち開発者にとってLLMが有用であるように攻撃者にとってもLLMは有用であり、すでに積極的に活用されてると思わないといけない。
そのためにLLM系サービスのAPI keyをターゲティングした攻撃キャンペーンまであったりして、攻撃者側のモチベーションが見て取れると言えるかもしれない。
b. 攻撃の敷居が下がる
Coding用のAI Agentの発展に伴い、コードを自分で書く能力がない人でもそれなりの強度でコーディングができるようになった。
これと同じことが攻撃者側でも起きている兆候があると言える。つまりBlack Hackerとしての知識や技術力が高くなくても高度な攻撃をLLMの活用によって行うということ。
2026年2月、AWS Security Blogでこんな記事が出た。
AI-augmented threat actor accesses FortiGate devices at scale | Amazon Web Services
Commercial AI services are enabling even unsophisticated threat actors to conduct cyberattacks at scale—a trend Amazon Threat Intelligence has been tracking closely. A recent investigation illustrates this shift: Amazon Threat Intelligence observed a Russian-speaking financially motivated threat actor leveraging multiple commercial generative AI services to compromise over 600 FortiGate devices across more than 55 countries […]
ざっくりいうと「hackerとしての能力がジュニアからミドルレベルと思われるアクターがLLMを活用することによりエッジデバイスを狙った大規模な侵害を成功させた」という話。
具体的には600以上のエッジデバイスに対して攻撃を成立させ、そこから先の攻撃もいくつか成功させたというもの。
このようなことが起きるのは時間の問題かなと個人的には思っていたがとうとうこういう事例が出てきたかぁと悪い意味でしみじみしている…。
また、マルウェアの生成においてもLLMが悪用されていることが確認されてる。
日本国内でも実際に攻撃が発生し、逮捕に至ってる事例もある。
生成AIでランサムウェアを作成した容疑者の摘発事例を考察
2024年5月27日、生成AIを悪用してランサムウェアを作成したとして警視庁が男性を逮捕しました。同年10月1日には東京地裁において論告求刑公判が行われました。本稿では、生成AIを悪用してマルウェアを作成し逮捕された日本初の事例を解説し、今後予想される脅威も考察します。
ただ、さまざまな事例で今のところ共通して言えそうなのは、LLMによって従来より高度なマルウェアが作られているわけではないということ。
去年のいつかのニュースではマルウェアがLLMのAPIにアクセスし、その場で攻撃コードを生成するみたいな挙動のものもあったりしたが現時点で流行っている兆候はなさそうに見えるし、マルウェア実装を手動からLLMに置き換えた。もしくはそもそも自分で作れない攻撃者がLLMを活用した、という範囲に留まっている印象。
開発者としてLLMを触っている人であれば、直感的にもこの状態は理解しやすいんじゃないかなと思う。Claude Codeを何も考えずに頑張って使えばめっちゃ質のいいソフトウェアを量産できるわけじゃないよね、という。
appendix ソーシャルエンジニアリング攻撃の変化
色々思い出しながらこの記事を書いてる中でソーシャルエンジニアリング攻撃もLLMで変わったよね、と書くつもりだったがちゃんと調べてみるとこの領域において因果関係が証明されたデータ等はなさそうだった(勉強するいい機会だった)。
よく挙げられる話として海外の攻撃者によるフィッシングメールの日本語がLLMによって自然に作成できることにより、より日本が狙われる、攻撃の成功率が上がるという話だ。
直感的にはそうだよね、と認識してたがLLMが台頭したからフィッシング件数が増えたと言い切るのはちょっと時期尚早かな？というのがおそらく現状かなと思う。
一方で下記のような記事があったりもして、まあ相関してても違和感はないかなと思う。ただ、これをもってやるべきことが変わるかというと変わらないかなというのが自分の所感。
日本を標的にしたメール攻撃の割合が世界の84％に急増、日本プルーフポイントが発表
日本プルーフポイントは2025年6月10日、サイバーセキュリティーの現状についてメディア向けの説明会を開催した。米Proofpoint（プルーフポイント）の統計によると、全世界の新種メール攻撃のうち日本を標的とした攻撃の割合は2025年1月～5月で84.0％であり、2024年の21.0％から4倍に急増した。
また、LLMというよりは生成AIの文脈で挙がるようになった話題としてディープフェイクを悪用した攻撃が挙げられる。
個人的にこの領域が印象的だったのは実は割と前からで、2年前に英国の会社が2500万ドルを騙し取られた事件を知った時だった。
Finance worker pays out $25 million after video call with deepfake ‘chief financial officer’ | CNN
A finance worker at a multinational firm was tricked into paying out $25 million to fraudsters using deepfake technology to pose as the company’s chief financial officer in a video conference call, according to Hong Kong police.
入り口はCFOを名乗る怪しいメールから始まった詐欺だったが、その後に招待されたテレビ電話でディープフェイクによる偽造映像が利用され攻撃が成功してしまった。
当時はディープフェイクの知名度が今ほど広くなかった、というのもあるが大金が動くようなシチュエーションにおいて生成AIが役立つことが証明されてしまった苦い例だと思う。
日本だとtakepepeさんという優秀なエンジニアの方がディープフェイクによるなりすましの被害に遭い、注意喚起の記事を投稿しているのが個人的には印象深い。
ディープフェイクによる攻撃は隣の国、どこかの会社の話ではなく1〜2ホップ先でもう起きていると思って過ごすのが個人的にはいいと思う。
3. 脆弱性管理のあり方が変わる(かもしれない)
ここでいう脆弱性とはOSSでCVEが採番されるようなもので、自社アプリ固有の脆弱性とかではない。
AIの台頭以前から脆弱性報告の加速は課題になっていたが、AIによってなおのこと加速している。結果として質が担保された脆弱性DBを頼るのが難しくなってきている。
NISTがギブアップしたのが記憶に新しい。2024年からNVDのバックログが膨れ上がり、2025年を通じて解消を試みたものの、2026年4月にはついに全CVEのエンリッチメントを断念し、高リスクのものだけに絞る方針に転換した。
NIST admits defeat on NVD backlog, will enrich only highest-risk CVEs going forward - Help Net Security
NIST is overhauling how it manages the National Vulnerability Database (NVD), switching to a risk-based model for vulnerability enrichment.
また、Claude Mythosのように脆弱性の発見に特化したLLMが出てきている。
各社、このようなモデルへのアクセスは絞っているものの広く活用されるようになっていくと脆弱性の報告件数は今後さらに増えていく可能性が高く、そうなってくると脆弱性管理の仕組みそのものを見直す必要が出てくるのかもしれない。
現時点で脆弱性のトリアージに手が回っていない、もしくは手一杯のチームがあれば何かchangeが必要ではないかと思う。
防御する立場としてどうすればいいのか
ここからは自分の考え。
LLMを組み込むアプリケーション開発について
LLMを組み込むアプリケーション開発においては特有の注意点が多くある。またLLMが組み込まれるアプリケーションの性質上、脆弱性があった時のダメージがでかい可能性が高いように思える。
そのため当たり前ではあるがOWASP等のリファレンスをきちんとインプットしてアプリケーションを作っていく必要があると思う。
個人的に悩ましいのはLLMが持つ不確実性で、例えばプロンプトインジェクションだと同じプロンプトが刺さったり刺さらなかったりする。ここにどう向き合うべきかは悩ましい。やっていけばできるようになるかもしれないが。
従来のアプリケーション開発について
従来のアプリケーション開発においては 「LLMが台頭してきたからこそ変えなければいけないこと」はそこまで多くないと思っている。
攻撃の効率が上がったとはいえ、攻撃手法そのものは変わっていない。守るべきポイントも基本的には同じ。やるべきことをやりましょう、という話になる。
私の意見をおさらいすると、LLMの台頭で変わったのは攻撃の効率が上がったこと、攻撃の敷居が下がったことの2点。ソーシャルエンジニアリングの話も含めると3点。
じゃあそれらの対策が今までと変わるかといったら変わらない。資産把握をして脆弱性パッチを当て続ける。最小権限の原則に伴い権限の管理やNHIの管理を行う。多層防御を実現するためのアーキテクチャを目指す等が引き続きやっていくべきことかなと思う。
「攻撃の総量が増えていく可能性があると見て、対策を加速させた方がいいのでは？」という問いもあると思うが、まあ理想論で言えばYesだけど元来から存在していた脅威なのでLLMがなかったとしてもやるべきことなのは変わらなかったと思う。
でも結局、私たち防御側は人やお金といったリソースは有限なのでどこにどれだけ投資しましょうかという話でしかなくてやっぱり今までと変わらない、変えられないのかなぁとは思う。
ただし、どこかで特定の攻撃のトレンドが加速したりすることはありうる(直近だとサプライチェーン攻撃が激アツですよね…)のでそれには食らいついていきましょうというはありますね。またこのトレンドの移り変わりがLLMの台頭で早くなってしまう、とかはあるかもしれない。
書いてて本当に思うけど言うは易し案件でしかないので、各位頑張りましょうという気持ちです。
脆弱性管理について
さっきも書いた通り、脆弱性管理についてはおそらく何かchangeが必要なのではと思っている。
NVDに頼り切る運用をしている場合はエンリッチメントの遅延や欠落の影響を受けるし、脆弱性の報告件数が増え続ける中でどうトリアージしていくかは考え直す必要がありそう。
某メディアでは「重要なCVEだけレビューすることは悪くない。誰が使ってるかわからない小さいソフトウェアのCVEのレビューばかりしても仕方がない」ということが書いてあって、報告してくれてる人に同じことは言えないかなと思いつつトリアージする立場としては近しい気持ちになることはあるのでそういうのに真剣に向き合う時が来たのかなとも思ったり。
また、今何かをchangeするならLLMの活用はほぼ必須科目になると思っているのでチャレンジしていきたいですねの気持ち。
最後に
色々書いたけど言いたかったこと、というより自分の中で整理して再認識したかったことは2つ。
- LLMアプリケーション作るときはちゃんと新しい概念の知識を武装してやっていかないとだめ
- 従来の攻撃はLLMの台頭で劇的に進化してるわけでは今はない、防御側に関してはやるべきことは大きくは変わってないはずだし頑張りましょう
今時点の認識なので1年後には変わってるかもしれないし、これを言い切るのに必要な情報をinputしきれてるかはわからない。
それは違うと思うゾって方がいたらぜひ議論したいです。みんなんで頑張っていきましょう。