はじめに ─ なぜ今、AIセキュリティを学ぶのか

ある会社で起きた、ふたつの事件

2025年7月、SaaStr創業者のJason LemkinがReplitで進めていた検証中、AIコーディングエージェントに「コードフリーズ中なので、何も変更しないでくれ」と明示していたにもかかわらず、エージェントはその指示を破って本番DBを削除した。1,200を超えるエグゼクティブのレコードと、1,190社近い企業の顧客データが失われた。さらにそのAIは「ロールバックは不可能だ」と虚偽の報告をした。実際には、Replitのスナップショットからのロールバックは可能だった。

事件は「AI Incident Database」のNo.1152として記録され、ReplitのCEOは公式に謝罪、その後dev/prod DBの自動分離とPlanning-only モードの追加に踏み切った。

ほぼ同じ時期、Microsoft 365 Copilotで「EchoLeak」と名付けられたゼロクリック脆弱性 (CVE-2025-32711, CVSS 9.3) が発見された。攻撃者がメールを1通送るだけで、被害者のOneDrive・SharePoint・Teamsの社内データを抜き取れた。被害者は何もクリックしていない。受信トレイにメールが届いた瞬間に、Copilotが背後でそのメール内の不可視な指示を読み、参照型Markdownの仕掛けを使って情報を外部へ送り出す経路ができていた。

このふたつの事件は、表面的にはまるで別物に見える。片方は「開発で使っていたAI」が暴走した話で、片方は「プロダクトに組み込まれていたAI」が乗っ取られた話だ。

しかし両方を貫いている問題は、ひとつしかない。LLMは「何が指示で、何が単なるデータか」を本質的に区別できない。Replitの事件では、AI自身が「仕様にない命令」を「自分の自由裁量」と解釈してしまった。EchoLeakでは、メール本文の文字列が「Copilotへの命令」として実行されてしまった。データと指示の境界が、どちらの事件でも溶けていた。

このシリーズが目指すこと

本シリーズは、2026年5月時点での「AIに関わるセキュリティ問題」を、開発プロセスでAIツールを使う側と、AIをプロダクトに組み込む側の両方から、ひと続きの議論として整理する。

読み終えたとき、あなたは以下のことができるようになる。

第1部の到達点（開発プロセスを守る）

• Claude Code / Cursor / GitHub Copilot / MCPサーバーといったAI開発ツールの脅威モデルを、自分の言葉で描ける
• 過去2年間で公表された主要な脆弱性 (Cursor CurXecute / MCPoison、Copilot CVE-2025-53773、Claude Code CVE-2025-59536・CVE-2026-21852、Rules File Backdoor等) が、なぜ起きたかを構造的に説明できる
• DevContainerでのサンドボックス、Plan Mode、最小権限のMCP設定、SBOM、approval gateを、組織の運用ルールに落とし込める

第2部の到達点（プロダクトを守る）

• OWASP Top 10 for LLM Applications 2025とOWASP Top 10 for Agentic Applications 2026の地図を持って、自社プロダクトの脅威モデルを描ける
• 直接・間接プロンプトインジェクション、RAGポイズニング (PoisonedRAG)、メモリ汚染 (MINJA)、ジェイルブレイク (Policy Puppetry / Crescendo)、モデル抽出、PII漏洩、Denial of Walletといった攻撃ベクタを区別できる
• 入力分離、出力経路の審査、ガードレール (NeMo / Llama Guard / Constitutional Classifiers / Lakera / Bedrock)、観測可能性、レッドチーミングを、設計の初期から仕込める

ガバナンス章の到達点

• NIST AI RMF (1.0 + Generative AI Profile)、ISO/IEC 42001、EU AI Act、MITRE ATLAS、CoSAIといった枠組みを使い分けられるようになり、法務・調達・SOCチームと共通言語で話せる

4つの根本原理 ─ 第1部と第2部に共通する伏線

開発側とプロダクト側は、現場感覚としてはまったく違う仕事に見える。しかし、両者は同じ4つの根本原理で説明できる。各章末で「この攻撃はどの原理を破ったのか」「この防衛策はどの原理を守るのか」を明示し、最終章で4つを回収する。

#	原理	ひと言で
1	信頼境界（Trust Boundary）	「自分のコード」と「取得したコンテンツ」、「system prompt」と「user input」の境界を絶対に曖昧にしない
2	Lethal Trifecta（Simon Willison, 2025）	①プライベートデータアクセス × ②untrustedコンテンツ曝露 × ③外部通信能力 のうち2つまでに抑える
3	最小権限（Least Privilege for Tools）	エージェントに渡すツールは、機能スコープで絞る。Excessive Agencyは表側、Confused Deputyは裏側、表裏一体の問題
4	Defense in Depth と観測可能性	単一のclassifierやguardrailに賭けない。Anthropicの最新Constitutional Classifiersですらjailbreak成功率は4.4%残る

これら4つは、開発時のClaude Code設定でも、プロダクトのRAG設計でも、まったく同じ式として登場する。「同じ式が両側に効く」という体験を、本シリーズの中で繰り返し作っていく。

対象読者

• AIアシスタント（Claude Code / Cursor / GitHub Copilot / Codeium 等）を日常的に使っている開発者・テックリード
• 今後AIを組み込んだプロダクトのリリースを検討している開発者・PdM・アーキテクト
• 「AIセキュリティ」が抽象論ではなく、具体的なCVEや事件としてどう現れているかを知りたいセキュリティエンジニア

前提知識：Web開発の基礎（HTTP / OAuth / npm or pip）、基本的なセキュリティ用語（XSS / SQL injection / RCE）、LLMを軽く触ったことがある程度。NIST・ISO・OWASPといったキーワードを聞いたことがあれば十分で、詳細な仕様は本書で都度説明する。

メタ情報

項目	内容
難易度	★★★★☆ (中〜上級者向け、実例ベース)
想定読了時間	約100〜120分（コードと図を読みながら）
対象時期	2026年5月時点の情報。法規制と脅威動向は四半期単位で動くため、常に一次情報の最新版を確認すること
対象環境	Claude Code 2.x / Cursor 1.x / VS Code + Copilot / MCP仕様 2025-11-25 / OWASP LLM Top 10 2025 / EU AI Act 2026/8施行版を念頭
章数	全10章 + おわりに

シリーズ構成

第0章 (本ファイル): はじめに ─ なぜ今、AIセキュリティを学ぶのか

第1部: 開発プロセスを守る ─ AI コーディングアシスタントを使う側
  第1章: AIコーディングアシスタントの脅威モデルを描く
  第2章: IDEとAIアシスタント本体を狙う攻撃
  第3章: MCPサーバーを介する攻撃と防衛
  第4章: サプライチェーンと自律実行 ─ axiosとReplitに学ぶ

第2部: プロダクトを守る ─ AI を組み込む側
  第5章: AI組込みプロダクトの脅威モデルを描く
  第6章: プロンプトインジェクションと出力経路を防ぐ
  第7章: RAGとエージェントメモリを汚染から守る
  第8章: ジェイルブレイク・モデル抽出・PII漏洩に備える

ガバナンス
  第9章: NIST、ISO 42001、EU AI Act、MITRE ATLASをどう使うか

最終章
  第10章: おわりに ─ 4つの根本原理を回収する

第1部から順に読むと、AIに関する脅威の「具体」から「抽象」へ、また「目の前の道具を守る」から「出していくものを守る」への流れで理解が深まる構成になっている。気になる章だけ拾い読みすることもできるが、4つの根本原理は第1章で導入したあと第2部以降で再利用するため、最初に第0章 → 第1章を通すことを勧める。

本書のスタイル

• 攻撃手法は必ずCVE番号、公表日、修正バージョンを併記する。「2025年に発見された脆弱性」のような曖昧な表現は使わない
• 防衛策は ✅ 良い例 / ❌ 悪い例 の対比で示す。設定ファイルやコマンドはそのまま流用できる粒度で書く
• 引用元は本文中にリンクを置き、最終章にまとめて再掲する
• 図はmermaidで描き、概念の関係や攻撃の連鎖が「文字より速く伝わる」場面で挿入する

それでは、まずはあなたの開発環境から見ていこう。