AIセキュリティ対策とは？生成AI・AIエージェントのリスクと6層の実装手順

AIセキュリティ対策とは？従来のセキュリティと何が違う？

AIセキュリティ対策とは、生成AI・AIエージェント特有の攻撃と誤動作を、入力・出力・権限・データの層で抑える取り組みです。

従来のセキュリティは「誰がシステムに入れるか」を主に守ってきました。AIセキュリティでは、これに加えて「正規の利用者から入った自然言語の指示が、AIに想定外の動作をさせないか」も守る必要があります。境界防御とID管理の考え方はそのまま使えます。ただし、それだけでは足りない点がAIセキュリティの難しさです。AX全体の中での位置づけは、AXとは？DXとの違いと5層の構成要素で整理しています。

守る対象は「システム」から「判断と行動」へ広がる

従来の対策は脆弱性やアクセス権限を守るものでしたが、AIではモデルの判断と、その判断で実行される行動も守る対象に入ります。

大規模言語モデル（LLM）は、指示とデータを同じ「テキスト」として受け取ります。そのため、社内文書やWebページに紛れ込んだ一文が、システムへの命令として解釈されることがあります。従来のSQLインジェクションのように「入力を無害化すれば終わり」とはいかず、完全な防御策がまだ確立されていない点が大きな違いです。

生成AIとAIエージェントでは求められる統制の強度が違う

チャット型の生成AIは情報漏えいが中心ですが、AIエージェントは誤った行動を実行するリスクまで負うため、より強い統制が要ります。

社内向けの生成AIチャットなら、主な論点は入力データの扱いと出力の正確性です。メール送信、チケット起票、コード実行、決済API呼び出しなどを自律的に行うAIエージェントになると、プロンプトインジェクション1件が「実害のある操作」に直結します。

導入支援の現場では、PoC段階でチャットと同じ感覚のままAIエージェントに広い権限を渡してしまい、本番移行の直前に権限設計をやり直すケースが少なくないと感じています。最初から「どのツールを、誰の権限で、どこまで実行できるか」を設計書に書いておくと、手戻りを抑えやすくなります。

生成AI・AIエージェントの主なリスクは？

主なリスクは、プロンプトインジェクション、機密情報の漏えい、過剰な権限、出力の誤り、サプライチェーンの5系統に整理できます。

整理の土台として広く使われているのが、OWASPの「Top 10 for LLM Applications」です。2025年版では、以下の10項目がリスクとして挙げられています。

情報系リスク：漏えいと汚染はRAG導入で一気に表面化する

RAG（検索拡張生成）を導入すると社内文書がAIの回答に直接流れ込むため、アクセス権限の不整合がそのまま漏えい経路になります。

多くの企業で見落とされがちなのは、ファイルサーバーやSharePoint上の「実は全社公開になっていた文書」です。人間が探しても見つからなかった文書を、RAGは簡単に見つけて回答に引用します。RAG導入の前に、参照元の権限棚卸しを別タスクとして予算化しておくのが現実的です。

出力の誤り（LLM09）は攻撃がなくても起きるリスクです。ハルシネーションの原因と評価指標は「ハルシネーション対策とは？」で詳しく整理しています。

行動系リスク：AIエージェントは「権限×自律性」で危険度が決まる

AIエージェントのリスクは、付与した権限の広さと人の確認を挟まない自律性の掛け算で決まり、片方を絞るだけでも大きく下がります。

たとえば「読み取りのみ・人が最終承認」の構成なら、プロンプトインジェクションを受けても被害は限定的です。反対に「書き込み可能・完全自動」の構成では、外部から届いたメール1通が攻撃の起点になりえます。OWASPはAIエージェント向けの脅威整理も別途公開しています。ツール連携が多い構成では、LLM向けのTop 10とあわせて参照するとよいでしょう。

AIセキュリティ対策はどの層で何を実装する？

対策は利用ガバナンス・入力・モデル・出力・権限・監視の6層で実装し、単一の防御に頼らず多層で被害を止めるのが原則です。

プロンプトインジェクションのように完全には防げない脅威がある以上、「どこか1層で破られても、次の層で止める」設計が前提になります。

モデル・データ層の「調達元の確認」では、OpenAIやAnthropicなどのAPIを使う場合も、入力データの保持期間や学習への利用有無を各社の公式ドキュメントと契約条件で確認し、確認日を記録しておくと、監査や社内説明のときに根拠を示しやすくなります。

入力・出力層：ガードレールは「補助の防御」と位置づける

入出力のガードレールは有効ですが、すり抜けを前提に、後段の権限制御と組み合わせる補助の防御と位置づけるのが安全です。

Microsoft、Google、Amazon Web Servicesなどの主要クラウドは、プロンプト攻撃の検知やコンテンツフィルタをマネージド機能として提供しており、導入は比較的容易です。ただし、提供状況（プレビューか一般提供か）、対象リージョン、日本語への対応は機能ごとに異なるため、採用前に各社の公式ドキュメントで確認し、確認日を残しておきます。

検知モデル自体も確率的に動くため、精度は100%になりません。実務では「ガードレールを入れたから安全」という説明が社内で独り歩きしないよう、残るリスクを明文化しておくことが重要です。ガードレールの種類とツールの選び方は「AIガードレールとは？」で比較しています。

権限・監視層：AIエージェントの安全性はここで決まる

AIエージェントで最も効く対策は、最小権限と人による承認ポイントの設計であり、あわせて全操作を後から追えるログを残します。

具体的には、次の4点を押さえます。

1. AIエージェント専用のサービスアカウントを発行し、利用者本人の権限を丸ごと委譲しない
2. 呼び出せるツールとAPIを許可リスト方式で限定する
3. 送金・削除・外部送信など取り消しにくい操作には、必ず人の承認を挟む
4. プロンプト、参照文書、ツール呼び出し、結果を1件ずつ紐づけて記録する

ログ設計は後回しにされがちです。しかしインシデントが起きたとき「AIがなぜその操作をしたか」を説明できないと、原因究明も再発防止もできません。承認フローの具体的な設計は「ヒューマンインザループ（HITL）とは？」で解説しています。

多層防御の限界とトレードオフ：安全性と利便性は引き換えになる

層を重ねるほど安全性は上がりますが、承認待ちや誤検知で業務が遅くなるため、ユースケースのリスクに応じて強度を変えます。

「書き込み可能・完全自動」のAIエージェントは、取り消しにくい操作を伴う業務（送金、データ削除、社外への送信）には向きません。こうした業務では、自動化の範囲を下書き作成や候補提示までに留め、実行は人が行う構成を選ぶのが現実的です。

AIセキュリティ対策はどの順番で進める？

棚卸し→ポリシー→リスク評価→技術対策→検証→運用の6段階で進め、最初に利用実態を把握することを最優先にします。

最初の3か月は「見える化」と「ルール化」に集中する

立ち上げ期は高度な技術対策より、どのAIが誰にどう使われているかの把握と、最低限の利用ルールの整備を優先します。

1. 利用実態の棚卸し：社内で使われている生成AIサービス、API、AIエージェント、RAGの参照元を一覧化する。プロキシログやSaaS管理ツールで、シャドーAIも洗い出す
2. 利用ポリシーの策定：入力してよい情報の区分、承認済みツール、例外申請の手順を定める
3. ユースケース別のリスク評価：「扱うデータの機密度」と「AIの自律度」の2軸で各ユースケースを分類し、対策の強度を決める

この段階で全社一律の禁止に振り切ると、かえってシャドーAIが増えやすいという声をよく聞きます。「使ってよい環境」を先に用意し、そこへ誘導するほうが統制は効きやすいと考えます。社内展開の進め方は「生成AIの社内活用はどう進める？」も参考になります。

本番運用に入る前にレッドチーミングで検証する

技術対策を実装したら本番前に攻撃者視点の検証（AIレッドチーミング）を行い、発見事項を直してから公開するのが原則です。

4. 技術対策の実装：前章の6層のうち、リスク評価で「高」になったユースケースから優先して実装する
5. AIレッドチーミング：プロンプトインジェクション、情報の抜き出し、権限外操作などを実際に試し、防御が効くかを確かめる
6. 継続運用：モデルの更新、プロンプトの変更、ツールの追加のたびに再評価する。ログの定期レビューも運用に組み込む

AIセキュリティは一度の診断では完結しません。モデルのバージョンアップだけで挙動が変わることもあるため、変更管理のプロセスに評価を組み込むことが、継続運用のいちばんの要点です。プロンプトインジェクションに絞った多層防御の実装手順は「プロンプトインジェクション対策とは？」で詳しく扱っています。

つまずきやすいポイント：PoCの権限設計とログの後回し

失敗が起きやすいのは、PoCで広い権限を渡したまま本番直前に設計をやり直す場面と、ログ設計を後回しにして事後追跡できない場面です。

参照すべきガイドラインとフレームワークは？

国内は「AI事業者ガイドライン」、技術面はOWASPとNIST、体系的な管理はISO/IEC 42001を軸に参照するのが実務的です。

国内企業がまず押さえるべきガイドライン

国内では経済産業省・総務省の「AI事業者ガイドライン」が基本の参照先で、検証手法はJ-AISIの公開資料が具体的で使いやすい資料です。

グローバル標準と技術フレームワーク

技術的な脅威の整理にはOWASPとMITRE ATLASが、リスク管理の枠組みにはNIST AI RMFとISO/IEC 42001が使えます。

ガイドラインはどの段階で何を使い分ける？

すべてを一度に満たそうとすると取り組みが止まりがちなため、全体方針・抜け漏れ確認・対外説明の順に段階的に使い分けます。

※実務コメントは一般的な導入現場の傾向に基づく見解です。各ガイドラインの最新版と詳細は、発行元の公式サイトで確認してください。

姉妹メディアの関連記事