AIセキュリティとは、LLM・AIエージェント・機械学習パイプラインに固有の脅威を体系的に防ぐ取り組みを指す。プロンプトインジェクションやai 情報漏洩、モデル汚染といった、従来のサイバーセキュリティの枠組みだけでは捉えきれないリスクが急増し、独立した専門領域として確立しつつある。

このカテゴリの検索需要は2026年に入って前年比+43%で伸びており、CPCも高い。理由は明確で、AIをプロダクトに組み込む企業が増えた一方、「何をどう守ればいいのか」を俯瞰できる地図が不足しているからだ。個別のインシデント解説や単体ツールの記事は無数にあるが、全体像をつかめないまま対策を始めると、外周だけ固めてモデルとデータが素通しになる。

本記事は「AIセキュリティとは何か」を定義するだけでなく、OWASP LLM Top 10・MITRE ATLAS・NIST AI RMFの3大フレームワーク、代表的な6つのリスク、6層の多層防御アーキテクチャ、OSS対策ツールの比較、規制動向までを一本で俯瞰する入門ピラーだ。各論は並走する個別記事へ橋渡しする。

この記事のポイント
  • AIセキュリティ＝LLM・エージェント・MLパイプラインの脅威を体系的に防ぐ取り組み。従来型と地続きだが、モデル自体の脆弱性・確率的振る舞い・データ依存という固有の難しさを持つ
  • 地図になるのはOWASP LLM Top 10（防御設計）・MITRE ATLAS（攻撃想定）・NIST AI RMF（ガバナンス）の3大フレームワーク
  • 代表リスクはプロンプトインジェクション・データ漏洩・モデル汚染・サプライチェーン・computer useの暴走・過度な依存の6系統
  • 防御は単一手段でなく入力分離→権限最小化→出力検証→モニタリング→サプライチェーン対策の多層で初めて成立する

AIセキュリティとは——30秒で全体像をつかむ

AIセキュリティ（AI Security）とは、AIシステムの開発・運用・利用の全段階で発生する脅威を識別し、防御・検知・対応する一連の取り組みだ。守る対象は3つのレイヤーに分かれる。

・LLMアプリ層：チャットボットやRAGなど、LLMをAPIで呼び出すアプリケーション。プロンプトインジェクションや出力の不適切処理が主リスク
・エージェント層：ツール実行・ファイル操作・外部API呼び出しを自律的に行うエージェント。乗っ取られると実害に直結する
・MLパイプライン層：学習データの収集・前処理・学習・デプロイ。データ汚染やモデル窃取、サプライチェーン攻撃が刺さる

この3層を横断して、攻撃者は「入力」「データ」「モデルの権限」のいずれかを突いてくる。だからこそ、ネットワークやサーバーを守る従来のセキュリティとは別の地図が必要になる。その地図が後述の3大フレームワークだ。

セキュリティクラスタには、サプライチェーン攻撃に特化した サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト も用意している。本記事はその上位にあたる「AIセキュリティ全体」の俯瞰ピラーだ。

なぜ「AIセキュリティ」が独立カテゴリになったのか

「セキュリティはセキュリティでは？」という疑問はもっともだ。だがAIには、従来のソフトウェアにない3つの固有性がある。

従来型サイバーセキュリティとの3つの違い

・モデル自体が攻撃対象になる：コードはレビューできるが、数十億パラメータの重みは中身を読めない。学習データに毒を仕込まれても（データポイズニング）、目視では発見できない
・振る舞いが確率的：同じ入力でも出力が揺れる。「この入力なら安全」という決定論的な保証が効かず、シグネチャベースの防御が通用しにくい
・データ依存性が極端に高い：学習データ・RAGの参照文書・コンテキストウィンドウに入る情報すべてが攻撃面になる。信頼できないデータを1行読ませるだけで、間接プロンプトインジェクションが成立する

この3点があるため、「ファイアウォールとWAFで境界を守る」発想だけでは穴が開く。モデルの内側と、モデルに流れ込むデータの両方を守る必要がある。

LLM／エージェント時代の新リスク

2023年以降のLLM普及で、攻撃面は一気に広がった。とくにAIエージェントが「読む」だけでなく「行動する」ようになったことで、プロンプトインジェクションが情報漏洩から実害（DB削除・送金・コード改ざん）へとエスカレートした。実際にAIエージェントが本番データベースを削除した事例も報告されている（CursorのAIエージェントが本番DBを9秒で削除した事例）。

規制が後押しした

技術だけでなく規制も独立カテゴリ化を促した。EUのAI Actは段階適用が進み、日本でもAI推進法が2025年に成立した。「AIを使うなら、AI固有のリスク管理体制を持て」という要請が、法的にも明文化され始めている（詳細は後述）。

AIセキュリティの全体像：3大フレームワーク

AIセキュリティを独学で固めようとすると、無数の論点に溺れる。先人が整理した3つのフレームワークを地図にすれば、抜け漏れを防げる。役割が異なるので、3つを併用するのが定石だ。

フレームワーク 視点 主な用途 提供
OWASP LLM Top 10 防御者（アプリ開発） LLMアプリの脆弱性チェックリスト OWASP Gen AI Security Project
MITRE ATLAS 攻撃者（脅威モデリング） 攻撃戦術・手法のマトリクス MITRE
NIST AI RMF 経営・ガバナンス 組織的なAIリスク管理プロセス NIST（米国国立標準技術研究所）

OWASP LLM Top 10（2025年版）

Webセキュリティで有名なOWASPが、LLMアプリ向けにまとめた脆弱性ランキング。アプリ開発者がまず参照すべき実務的なチェックリストだ。最新は2025年版。

ID 名称 概要
LLM01 Prompt Injection 入力（直接・間接）でLLMの意図した挙動を改変される
LLM02 Sensitive Information Disclosure PII・認証情報・独自データが出力経由で漏えいする
LLM03 Supply Chain モデル・学習データ・依存パッケージ経由の脆弱性
LLM04 Data and Model Poisoning 学習・ファインチューニング・埋め込みデータの汚染
LLM05 Improper Output Handling 出力の検証・サニタイズ不足（下流のXSS・SSRF・コード実行を誘発）
LLM06 Excessive Agency 過剰な権限・機能・自律性による被害拡大
LLM07 System Prompt Leakage システムプロンプト（内部指示）の漏えい
LLM08 Vector and Embedding Weaknesses ベクトル・埋め込み（RAG基盤）の脆弱性
LLM09 Misinformation 誤情報・ハルシネーションへの過信
LLM10 Unbounded Consumption リソース無制限消費（DoS・コスト爆発・モデル抽出）

MITRE ATLAS

ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）は、サイバー攻撃の標準フレームワークATT&CKのAI版だ。AIシステムへの攻撃を、実観測ベースで戦術（tactics）と手法（techniques）に分類する。レッドチームや脅威モデリング、SOCの検知設計で使う。

戦術はおおむねATT&CKと同じ流れ（偵察→初期アクセス→実行→…→影響）で並ぶが、AI固有の戦術が2つ挿入されているのが特徴だ。

・AI Model Access（旧 ML Model Access）：推論API・モデルファイル・学習環境など、モデルそのものへのアクセスを得る段階
・AI Attack Staging（旧 ML Attack Staging）：敵対的サンプル生成・代理モデル構築・データポイズニングなど、本攻撃の準備段階
・このほか Reconnaissance / Resource Development / Initial Access / Execution / Persistence / Privilege Escalation / Defense Evasion / Credential Access / Discovery / Collection / Command and Control / Exfiltration / Impact が並ぶ

※ MITREは接頭辞を「ML」から「AI」へリネーム済みのため、旧称で書かれた解説記事を読むときは読み替えが必要だ。

NIST AI RMF

NIST AI RMF（AI Risk Management Framework, AI 100-1）は、組織がAIリスクを管理するためのプロセス標準だ。経営層・ガバナンス担当が使う。4つのコア機能で構成される。

・GOVERN：AIリスク管理の文化・方針・説明責任を組織全体に根付かせる横断機能。他3機能の土台
・MAP：AIシステムの利用文脈・用途・利害関係者を把握し、リスクを枠付けする
・MEASURE：定量・定性の手法でリスクと影響を分析・評価・ベンチマーク・監視する
・MANAGE：マッピング・測定したリスクに資源を割り当て、優先順位をつけて対応する

生成AIに特化した補完文書として、NIST-AI-600-1「Generative AI Profile」（2024年7月公開）もある。生成AI固有の12のリスク分類と対応アクションを示しており、LLMを扱うならこちらも併読したい。

代表的なAIセキュリティリスク6種

フレームワークを地図とすると、ここからは「具体的に何が起きるか」だ。AIセキュリティで押さえるべき代表リスクを6系統に整理する。攻撃の具体的なペイロードは載せず、仕組みと防御の勘所に絞る。

1. プロンプトインジェクション（LLM01）

ユーザー入力や外部データに紛れ込ませた命令で、LLMの意図した挙動を乗っ取る攻撃。直接入力する「直接型」と、Webページ・PDF・GitHubコメントなど読ませた外部データに仕込む「間接型」がある。間接型はユーザーが気づかないまま発火するのが厄介だ。実例として、GitHubのコメントにAIへの命令を隠す手口が報告されている（GitHubコメントがAIエージェントを乗っ取る「Comment and Control」攻撃）。防御は入力と命令の分離、信頼境界の明示、出力の検証が軸になる。

2. データ漏洩（LLM02）／ ai 情報漏洩

ai 情報漏洩には2経路ある。1つは学習データの記憶からPIIや機密が出力される「学習データ抽出」、もう1つはコンテキストやRAG参照文書に入れた機密が他ユーザーや外部へ漏れる「コンテキスト経由漏洩」だ。SaaSのLLMに社外秘を貼り付けて学習に使われるケースも実務では多い。プラン別の学習利用ポリシーの確認と、入力前のマスキング、出力フィルタが基本対策になる（関連：Claudeに送ったデータは学習に使われる？セキュリティ・プライバシー・ガバナンスガイド）。

3. モデル汚染・バックドア（LLM04）

学習・ファインチューニング・埋め込みデータに毒を混ぜ、特定トリガーで誤動作させる攻撃。学習時に仕込む「データポイズニング」と、配布されたモデル自体にバックドアを埋める手口がある。外部から落としたモデルやデータセットを無検証で使うと刺さるため、出所の検証とサプライチェーン対策が直結する。

4. サプライチェーン（LLM03）

モデル・データセット・依存パッケージ・MCPサーバーなど、AIスタックを構成する外部要素のどこかが汚染されるリスク。2026年はnpm 脆弱性を起点にしたAIライブラリへの攻撃が相次いだ。Microsoft・Red Hatを巻き込んだnpmサプライチェーン汚染（MicrosoftとRed Hatを襲ったnpmサプライチェーン攻撃）、Webを汚染するAI生成コンテンツの問題（AI Miasma：AI生成コンテンツがWebを汚染する）などが典型だ。詳細な防御手順は姉妹ピラーのサプライチェーンセキュリティ2026に譲る。

5. computer use・エージェントの新リスク（LLM06）

画面を見て操作する「computer use」や、ツールを自律実行するエージェントは、乗っ取られた瞬間に「行動」へ移る。トークン窃取と組み合わさると課金破壊やデータ持ち出しに直結する（トークン窃取を多層で止める防御パターン）。エージェント全般の設計思想はAIエージェントフレームワーク徹底比較2026を参照。

6. 過度な依存・過剰な権限（LLM06 / LLM09）

OWASPがExcessive Agencyとして独立項目化したのがこのリスクだ。エージェントに与える権限・ツール・自律性が過剰だと、誤動作1つが致命傷になる。加えて、ハルシネーションを検証せず鵜呑みにする「過度な依存」（Misinformation, LLM09）も、コード生成や意思決定の現場で実害を生む。権限最小化と人間のレビュー工程が防波堤になる。

AIセキュリティの脅威モデリングを始める3ステップ

6つのリスクを並べると圧倒されるが、自社に効く優先順位は脅威モデリングで絞り込める。難しい理論は不要で、次の3ステップを回すだけでも抜け漏れは大きく減る。

ステップ1：攻撃面を棚卸しする

まず「どこからデータが入り、どこへ出ていくか」を図にする。LLMへの入力経路（ユーザー入力・RAG参照文書・Webフェッチ・アップロードファイル）、エージェントが触れるツールと権限、出力の流し先（画面・シェル・DB・外部API）をすべて書き出す。この時点で「信頼できないデータがそのまま行動権限に届く経路」が見えてくる。間接プロンプトインジェクションは、たいていここで発見できる。

ステップ2：OWASP LLM Top 10で自己診断する

棚卸しした各経路に、OWASP LLM Top 10を当てはめる。たとえばRAG経路ならLLM01（インジェクション）・LLM08（ベクトルDB）、出力経路ならLLM05（出力処理）・LLM02（情報漏洩）、エージェントならLLM06（過剰な権限）といった具合だ。10項目を質問リストとして使い、「この経路でこのリスクは起きうるか／対策はあるか」をYes/Noで埋めていく。Noが残った箇所が、そのまま対策の優先順位になる。

ステップ3：被害の大きさで優先順位をつける

すべてのリスクを同時には潰せない。発生可能性×被害規模でスコアリングし、上位から着手する。判断材料として、ATLASの戦術（攻撃者がどこまで到達しうるか）と、その経路が「行動」を伴うか「情報」にとどまるかを見る。行動を伴うエージェント経路は被害規模が大きくなりやすいため、権限最小化を最優先に据えるのが定石だ。このサイクルはモデル切替や新ツール追加のたびに回し直す。

多層防御アーキテクチャ——6層で守る

ここまでのリスクは、単一のツールでは止まらない。AIセキュリティの定石は、複数レイヤーを重ねる多層防御（Defense in Depth）だ。1枚の壁が破られても次の壁で食い止める発想で、入口から出口、運用までを6層で覆う。

flowchart TB U[ユーザー / 外部データ] --> L1 subgraph DEF[AIセキュリティ 6層防御] L1["① Edge層
WAF・レート制限
入力サニタイズ"] L2["② Auth層
認証・認可
最小権限・スコープ制限"] L3["③ App層
入力と命令の分離
プロンプトテンプレ固定"] L4["④ Model層
ガードレール
出力検証・フィルタ"] L5["⑤ Data層
学習データ検証
RAG文書の信頼境界"] L6["⑥ Monitor層
ログ・異常検知
コスト監視・監査証跡"] L1 --> L2 --> L3 --> L4 --> L5 L6 -.観測.-> L1 L6 -.観測.-> L4 end L4 --> OUT[安全な出力 / 制御された行動]

各層の役割を一言で整理すると次のとおりだ。

・① Edge層：外周。WAF・レート制限・ボット対策で、明らかに悪性なトラフィックと無制限消費（LLM10）を弾く
・② Auth層：認証・認可とAPIキーのスコープ制限。エージェントに渡す権限を最小化し、Excessive Agency（LLM06）の被害を抑える
・③ App層：プロンプトテンプレートを固定し、ユーザー入力と命令を構造的に分離。プロンプトインジェクション（LLM01）の発火面を狭める
・④ Model層：入出力ガードレールで、危険な指示や機微情報の出力（LLM02/LLM05）をブロックする
・⑤ Data層：学習データ・RAG参照文書の出所を検証し、信頼できないデータに行動権限を与えない（LLM03/LLM04/LLM08）
・⑥ Monitor層：すべての層を横断して観測する。ログ・異常検知・コスト監視・監査証跡で、すり抜けた攻撃を事後に捕捉する

重要なのは、どの層も単独では不完全だということだ。ガードレール（④）だけ入れて満足するのが最も多い失敗パターンで、後述の「よくある落とし穴」で詳述する。

OSS対策ツール一覧（2026年6月時点）

多層防御を実装するOSSは充実してきた。カテゴリ別に代表的なツールを比較する。GitHubスター数は2026年6月時点の実測値で、公開までに変動する。

ツール カテゴリ 提供 License ★（2026/06時点）
promptfoo レッドチーム / 脆弱性スキャン / eval promptfoo MIT 約21,900
garak LLM脆弱性スキャナ NVIDIA Apache-2.0 約8,000
PyRIT レッドチームフレームワーク Microsoft MIT 約3,900
NeMo Guardrails ランタイムガードレール NVIDIA Apache-2.0 約6,400
Guardrails AI ランタイムガードレール（入出力検証） Guardrails AI Apache-2.0 約7,000
LLM Guard ランタイムガードレール（入出力スキャナ） Protect AI MIT 約3,000

カテゴリごとの使いどころは次のとおりだ。

・脆弱性スキャナ／レッドチーム：garak はLLMの脆弱性を多数のプローブで自動診断する「LLM版nmap」的ツール。promptfoo は評価とレッドチームを統合し、CIに組み込める。PyRIT（正規リポジトリは microsoft/PyRIT）はMicrosoftが自社のAIレッドチーム運用で使うフレームワークだ
・ランタイムガード：NeMo Guardrails（リポジトリは NVIDIA-NeMo/Guardrails へ移管済み）はColangで対話フローに制約をかける。Guardrails AI と LLM Guard は入出力をバリデータ／スキャナで検査し、PII・プロンプトインジェクション・有害出力を遮断する
・サプライチェーンスキャナ：依存パッケージやモデルの汚染検知は、Socket.devやOpenSSF Scorecardなど汎用ツールと組み合わせる。詳細はサプライチェーンセキュリティ2026を参照

なお商用領域では、Lakera Guard（2025年にCheck Pointが買収）、Robust Intelligence（Ciscoが買収しCisco AI Defenseの基盤に）、Galileo Protectなどが、リアルタイムのLLMファイアウォールやランタイム保護を提供している。OSSで内製しきれない部分を商用で補う構成が現実的だ。

最小構成での組み合わせ方

ツールが多くて迷うなら、開発フェーズと本番フェーズで役割を分けて選ぶとよい。

・開発・CI段階：promptfoo か garak でレッドチームテストを自動化し、リリース前にインジェクション耐性とPII漏洩を回帰テストする。両者ともCIに組み込めるため、モデルやプロンプトを変えるたびに自動で再評価できる
・本番ランタイム段階：Guardrails AI か LLM Guard で入出力をフィルタし、PII・有害出力・既知の攻撃パターンを遮断する。対話フローに踏み込んだ制約をかけたい場合は NeMo Guardrails を併用する
・横断：いずれのツールもログを残せる構成にし、⑥Monitor層の異常検知とコスト監視に流し込む

この「CIでテスト＋本番でガード＋全体を監視」の三点セットが、OSSだけで組める最小構成だ。ここから自社のリスクプロファイルに応じて商用ツールやサプライチェーンスキャナを足していくとよい。garak のスキャン結果はそのまま脅威モデリングのステップ2（OWASP自己診断）の裏付けにも使える。

# promptfoo によるレッドチーム設定の最小例（promptfooconfig.yaml）
# 実際の攻撃ペイロードは載せず、検査カテゴリのみ宣言する
redteam:
  plugins:
    - harmful          # 有害出力の誘発耐性
    - pii              # PII漏洩（LLM02）
    - prompt-injection # プロンプトインジェクション（LLM01）
  strategies:
    - jailbreak

# garak で公開モデルの脆弱性をスキャンする例
python -m garak --model_type huggingface \
  --model_name <your-model> \
  --probes promptinject,leakreplay

企業のAIセキュリティ導入チェックリスト

「何から始めればいいか」に答えるため、ガバナンスから運用までを優先度順に整理した。すべてを一度に揃える必要はなく、上から順に固めるのが現実的だ。

・ガバナンス：AI利用方針を定め、責任者を置く（NIST AI RMFのGOVERNに対応）
・リスク評価：利用するLLM・エージェント・データフローを棚卸しし、OWASP LLM Top 10で自己診断する
・データ分類：LLMに入れてよい情報・禁止する情報を定義し、社内に周知する
・契約・ポリシー：利用するAPIの学習利用ポリシー・データ処理契約（DPA）・保存期間を確認する
・権限最小化：APIキーをスコープ制限し、エージェントに渡すツール権限を必要最小にする
・入出力対策：プロンプトテンプレートを固定し、出力をそのままシェル・DB・HTMLに渡さない
・ガードレール：入出力フィルタ（PII・有害・インジェクション検知）を導入する
・サプライチェーン：モデル・データセット・依存パッケージ・MCPサーバーの出所を検証する
・モニタリング：利用ログ・異常検知・コスト監視・監査証跡を本番投入前に用意する
・インシデント対応：AI起因の事故を想定したエスカレーション経路と再評価手順を決める
・再評価サイクル：モデル切替・新ツール追加のたびにリスク評価をやり直す
・教育：開発者と利用者にプロンプトインジェクションとデータ取り扱いを教育する

業界別シナリオ

リスクの重みは業界で変わる。代表的な4業界の勘所を挙げる。

・金融：個人金融情報の漏洩（LLM02）と、エージェントによる不正取引（LLM06）が致命的。出力検証と人間の承認工程、厳格な監査証跡が必須
・医療：診断補助でのハルシネーション（LLM09）が人命に関わる。患者データの学習利用禁止と、出力を最終判断にしない運用設計が要
・EC／カスタマーサポート：間接プロンプトインジェクション（LLM01）でクーポン発行や個人情報開示を誘発される。RAG参照文書の信頼境界とレート制限が効く
・コード開発：AIコーディングエージェントがサプライチェーン汚染や権限暴走を起こす。AIエージェントフレームワーク徹底比較2026の設計指針と、生成コードのレビュー必須化で守る

表にすると、業界ごとに「最優先で守るべき1点」が明確になる。

業界 最優先リスク 効く対策 対応OWASP
金融 不正取引・情報漏洩 人間の承認工程・監査証跡 LLM06 / LLM02
医療 診断ハルシネーション 出力を最終判断にしない運用 LLM09
EC／CS 間接インジェクション RAG信頼境界・レート制限 LLM01 / LLM10
コード開発 サプライチェーン・権限暴走 生成コードレビュー・権限最小化 LLM03 / LLM06

自社が複数業界にまたがる場合は、最も被害規模の大きい経路から着手すればよい。前述の脅威モデリング3ステップと組み合わせれば、限られた工数でも守る順番を間違えにくくなる。

規制と監査：EU AI Act・日本AI推進法

技術対策と並んで、法規制への対応もAIセキュリティの一部になった。主要な動きを押さえる。

EU AI Act（段階適用中）

EUのAI規制は罰金を伴うハードローだ。段階的に適用が進んでいる。

・2024年8月1日：発効
・2025年2月2日：禁止AIプラクティスとAIリテラシー義務が適用開始
・2025年8月2日：汎用AIモデル（GPAI）提供者の義務とガバナンス規定が適用開始
・2026年8月2日：高リスクAIシステム（Annex III型）と透明性義務が原則適用
・2027年8月2日：全面適用。製品安全法制に組み込まれる型の高リスクシステム義務も発効

日本のAI推進法

日本初のAIに関する基本法「AI推進法（人工知能関連技術の研究開発及び活用の推進に関する法律）」は2025年5月28日に成立、6月4日に公布され、9月1日に全面施行された。EUと対照的に直接的な罰則はないソフトロー型で、基本理念・政府のAI基本計画策定・AI戦略本部の設置などを定める。不適切な利用には調査・指導・助言、改善されない場合の事業者名公表といった対応にとどまる。

監査で問われる規格

第三者監査や取引先要請の場では、次の規格が問われる。

規格 対象 AIセキュリティでの位置づけ
SOC2 運用統制 クラウドサービスの統制を顧客に証明
ISO/IEC 27001 情報セキュリティ管理 従来からの基盤。AIにも引き続き適用
ISO/IEC 42001 AIマネジメントシステム AIガバナンス専用規格（2023年制定）。AI版ISMS

社内監査では「学習利用ポリシーの遵守」「権限最小化の実装」「監査証跡の保全」「再評価サイクルの運用」が論点になりやすい。

よくある落とし穴

最後に、現場で繰り返される失敗パターンを挙げる。どれも「対策したつもり」で穴が残るケースだ。

・「LLM自体は安全」と思い込み外周だけ守る：WAFとレート制限は入れたが、間接プロンプトインジェクションとデータ漏洩は素通し。モデルの内側とデータ面を必ず守る
・ガードレールツール導入で完了にする：④Model層だけでは、権限設計（②）やサプライチェーン（⑤）の穴は塞がらない。多層で考える
・新モデル切替時の再評価を忘れる：モデルを変えると安全性の挙動も変わる。切替のたびにレッドチーム評価をやり直す
・サードパーティMCP・プラグインの権限見直しをサボる：便利だからと追加した拡張が過剰な権限を持つ。定期的に棚卸しする
・モニタリングなしで本番運用する：すり抜けた攻撃は観測しなければ気づけない。ログ・異常検知・コスト監視を本番投入の前提にする

AIセキュリティに銀の弾丸はない。3大フレームワークを地図に、6層の防御を一枚ずつ積み上げ、モデル切替のたびに再評価する——この地道な運用こそが、LLM時代に実害を防ぐ唯一の道だ。本記事を入り口に、各リスクの個別記事へ進んでほしい。

FAQ（よくある質問）

各設問の回答は記事冒頭のFAQ構造化データにも収録している。要点を改めて整理する。

・AIセキュリティとサイバーセキュリティの違いは？ モデル・学習データ・確率的出力・エージェント権限という、AI固有の対象を加えて守る点が違う
・OWASPとMITRE ATLASどちらを先に？ アプリ開発者はOWASP LLM Top 10、攻撃想定や検知設計はMITRE ATLAS。補完関係
・中小企業に予算は必要？ 専任は不要だが、APIキー最小権限・出力検証・ログ監視の3点はゼロ予算でも必須
・ChatGPT利用だけでもリスクは？ 入力情報の学習利用と間接インジェクションのリスクがある
・RAGとエージェントどちらが危険？ 行動を伴うエージェントの方が実害に直結しやすい
・自社運用とAPIどちらが安全？ 機密性優先なら自社運用、運用負荷を下げるならAPI＋データ保護契約
・資格・認証は？ 組織向けはISO/IEC 42001が代表。個人向け資格は発展途上

参照ソース