生成AIのセキュリティ対策とは？企業のリスク類型と実装手順を解説

生成AIのセキュリティリスクにはどんな種類がある？

生成AIのリスクは、入力・処理・出力・自動実行の四層に分けると対策の担当と手順を決めやすくなります。AX全体の中での位置づけは、AXとは？DXとの違いと5層の構成要素で整理しています。

従来の情報セキュリティと何が違うのか

違いは、入力した内容そのものが攻撃面になり、出力が確率的に誤りうる前提に立つ点です。

従来の情報セキュリティ管理は、機密性・完全性・可用性を守る発想で組み立てられてきました。生成AIでは、これに三つの性質が加わります。第一に、利用者が入力する自然文がそのまま処理系への指示になるため、データと命令の境界が曖昧になること。第二に、出力が常に正しいとは限らず、誤情報が業務判断や外部公開物に混入しうること。第三に、AIエージェントのように出力が自動で次の操作を起動する構成では、誤りが「間違った文章」ではなく「間違った実行」として現れることです。ISO/IEC 42001:2023（AIマネジメントシステム、2023年12月発行）がISO/IEC 27001とは別規格として整備されたのも、この管理対象の差を反映したものと理解できます。

リスクはどう分類すると整理しやすいか

OWASPが公開するLLMアプリケーション向けTop10を土台に、自社の利用形態へ翻訳するのが実務的です。

OWASPは「OWASP Top 10 for LLM Applications」を公開しており、2025年版ではプロンプトインジェクション、機密情報の開示、サプライチェーン、データおよびモデルのポイズニング、不適切な出力処理、過剰な代理権限（Excessive Agency）、システムプロンプトの漏えい、ベクトルおよび埋め込みの脆弱性、誤情報、無制限の消費が挙げられています。攻撃手法の体系としてはMITRE ATLASが、リスク管理の枠組みとしては米国NISTの「AI Risk Management Framework 1.0」（2023年1月公表）と生成AI向けプロファイル「NIST AI 600-1」（2024年7月公表）が参照先になります。ゼロから独自の分類を作るより、これらを社内用語に置き換えて使うほうが、外部への説明も通りやすくなります。

自社に該当するリスクをどう見極めるか

SaaS利用・API組み込み・RAG構築・AIエージェント運用のどれに当たるかで、対策の範囲が変わります。

同じ「生成AIを使う」でも、OpenAIのChatGPTやMicrosoft 365 Copilot、GoogleのGemini、AnthropicのClaudeを業務端末から利用するだけの段階と、自社システムにAPIを組み込む段階、社内文書をRAG（検索拡張生成）で参照させる段階、AIエージェントに実行権限を与える段階では、守るべき対象が大きく異なります。前者は主に利用規程とアカウント管理の問題ですが、後段に進むほどアプリケーション設計と権限設計の比重が増します。現場で相談を受けていると、SaaS利用の段階のルールをそのままRAG構築に流用してしまい、参照権限の設計が抜け落ちるケースが少なくないように見えます。

生成AIのセキュリティ対策は何から始めるべき？

着手順は、利用実態の棚卸し、扱ってよいデータの線引き、承認済みサービスの提供、の三段が現実的です。

最初に手をつけるべきことは何か

規程の起草より先に、どの部門がどのサービスを何に使っているかの棚卸しから始めます。

規程を先に書くと、実態を知らないまま禁止事項だけが積み上がりがちです。棚卸しでは、利用中の外部サービス名、契約形態（個人アカウントか法人契約か）、入力しているデータの種類、業務での用途、出力の利用先の五項目を集めます。あわせて、SaaS利用状況の可視化ツールやプロキシログから、申告されていない利用がないかを突き合わせます。禁止を先行させると利用が私物端末や個人アカウントへ流れ、最も見えない場所で機密情報が扱われる状態になりかねません。承認済みの選択肢を先に用意することが、結果的に統制の実効性を高めます。

入力してよいデータの線引きはどう決めるか

情報資産を三区分し、区分ごとに利用可能なサービスと承認要否を対応づける方法が扱いやすいです。

区分の粒度は細かくしすぎないほうが運用に乗ります。既存の情報資産管理区分がある場合は、それを流用して生成AI利用の可否列を追加するだけでも成立します。判断に迷う典型が、顧客名を含む議事録、採用候補者の情報、未公開の財務データ、ソースコードです。これらは「一律禁止」ではなく、法人契約で学習利用が遮断されたサービスに限定して許可する、といった条件付きの設計にすると現場が回りやすくなります。

技術対策と運用ルールはどちらを先に置くか

権限とアカウント管理を先に固め、検知や監査ログの整備を後続に回す順序が投資効率で優れます。

法人テナントへの集約、シングルサインオンと多要素認証の適用、退職者アカウントの失効といった基本動作は、生成AI特有の対策を導入する前提条件になります。ここが緩いまま出力フィルタやプロンプト検査を入れても、迂回経路が残ります。順序としては、(1) 法人契約への集約とアカウント統制、(2) データ区分と利用規程の公開、(3) 監査ログの取得開始、(4) DLPや出力検証などの検知系、(5) レッドチーミングと定期評価、と積み上げるのが無理のない進め方です。

機密情報や個人情報の漏えいはどう防ぐ？

漏えい防止は、入力の制御、契約による学習利用の遮断、保存先の管理という三点の組み合わせで設計します。

入力側で漏えいを止める手段は

個人アカウント利用の遮断と、法人契約サービスへの集約が、入力経路の制御では最も効きます。

技術的には、業務端末からの未承認サービスへのアクセス制限、DLPによる特定パターン（マイナンバー、クレジットカード番号、顧客IDの書式など）の検知、ブラウザ拡張の管理といった手段があります。ただし、自然文に埋め込まれた機密の判定は完全には自動化できません。だからこそ、入力前の判断を担う利用者側の教育が実効性を左右します。研修は網羅的にするより、「入力してよい情報の区分」「出力を業務に使う前の確認義務」「事故時の報告先」の三点に絞った短時間の内容のほうが定着しやすい印象があります。

学習利用と保持期間は契約でどう確認するか

確認点は、入力データの学習利用、保持期間、保存リージョン、再委託先の四つに集約されます。

主要ベンダーは、APIや法人向けプランについて入力データを既定でモデル学習に利用しない旨を規約やドキュメントで示していますが、個人向けプランでは設定によって扱いが異なる場合があります。規約は改定されるため、導入時点の内容を根拠として保存し、更新時に再確認する運用が必要です。契約審査では、不正利用監視のためのデータ保持期間、保存先リージョン、サブプロセッサ（再委託先）の一覧と変更通知、監査対応の可否を確認項目に入れておきます。ISMSやSOC 2の報告書提出可否も、審査の効率を左右する要素です。

個人情報保護法の観点で注意すべき点は

個人データを外部サービスに入力する行為が、第三者提供や委託のどれに当たるかを整理します。

個人情報保護委員会は2023年6月に、生成AIサービスの利用について注意喚起を公表しています。実務上の論点は、個人データを含むプロンプトを外部サービスへ送信する場合の位置づけ、利用目的の特定と通知、外国にある第三者への提供に該当する場合の対応です。加えて、経済産業省・総務省の「AI事業者ガイドライン第1.0版」（2024年4月公表）はプライバシー保護とセキュリティ確保を共通の指針に挙げています。法務判断は個別性が高いため、社内で一般化した結論を出すより、ユースケース単位で法務部門と確認する枠組みを作っておくほうが安全です。

プロンプトインジェクションとRAGのアクセス制御にはどう対処する？

プロンプトインジェクションは根絶できない前提で、権限の最小化と出力の取り扱いで被害を抑えます。

直接型と間接型はどう違うのか

利用者が入力する直接型より、外部文書に指示を仕込む間接型のほうが検知は難しくなります。

直接型は、利用者自身が「これまでの指示を無視して」といった文言を入力し、システムプロンプトの制約を外そうとする手口です。間接型（インダイレクト・プロンプトインジェクション）は、AIが読み込むWebページ、PDF、メール、社内文書などにあらかじめ指示文を埋め込んでおき、AIがそれを取り込んだ時点で発火させます。RAGやAIエージェントのように外部データを自動で読ませる構成では、この間接型が主要な脅威になります。入力を人が目視する機会がないため、検知の難易度が上がる点が実務上の厄介さです。

多層防御はどう組み立てるか

入力検査、システムプロンプト分離、出力検証、権限制御の四層を重ねる構成が基本になります。

単一の対策で防ぎ切ろうとしないことが重要です。指示文の検知フィルタは有効ですが、言い換えや多言語、エンコードによる回避が知られており、精度には限界があります。したがって、「攻撃が成功しても実害が出にくい」設計を並行して作ります。GoogleのSecure AI Framework（SAIF、2023年6月公表）のように、既存のセキュリティ原則をAIシステムに適用する枠組みも参照先になります。

RAGのアクセス制御で押さえる点は

検索前に利用者の権限でフィルタし、権限のない文書は候補にも載せない設計が原則です。

RAGでの事故は、攻撃というより権限設計の不備で起きるほうが多いのが実感です。典型は、社内文書を一括でベクトルデータベースに取り込み、検索時に利用者の権限を考慮しない構成です。この場合、人事評価や役員会議の資料が一般社員の質問への回答として要約されて返る事態が起こりえます。実装上は、インデックス作成時に元文書のアクセス制御情報をメタデータとして付与し、検索時に利用者の権限でフィルタしたうえで生成に渡す流れにします。Microsoft 365 Copilotのように既存のアクセス権を継承する仕組みでも、SharePointの過剰共有がそのまま露出するため、導入前に共有設定の棚卸しが必要です。あわせて、埋め込みベクトル自体から元文書の内容が推測されうる点、削除した文書がインデックスに残り続ける点も設計時の確認事項になります。

AIエージェントの権限暴走をどう抑えるか

実行可能な操作を許可リストで限定し、外部送信や削除は人の承認を挟む設計にしておきます。

OWASPが「Excessive Agency（過剰な代理権限）」を独立した項目として挙げているとおり、AIエージェントでは権限そのものがリスク源になります。設計時に決めるべきは、呼び出せるツールとAPIの範囲、書き込み・削除の可否、外部への送信可否、実行回数と費用の上限、そして人による承認を挟む操作の定義です。読み取り専用から始め、実績を見ながら書き込み権限を段階的に開放する進め方が、結果的には早道になる場面が多いように思います。

生成AIのセキュリティ体制はどう運用・監査すればよい？

運用は、利用ログの取得、定期的なレッドチーミング、インシデント経路の三点を回すことで成立します。

何をログに残すべきか

利用者、日時、対象サービス、参照した社内文書、外部送信の有無を最低限の記録項目とします。

ログは事故時の説明可能性を担保するために取ります。特にRAGやAIエージェントを使う構成では、「誰の質問に対して、どの文書が参照され、どの操作が実行されたか」を追跡できないと、影響範囲の特定ができません。プロンプトと出力の全文保存は、それ自体が機密情報の集積になるため、保存範囲・保持期間・閲覧権限を先に決めておく必要があります。ログを取ること自体が新たなリスク資産を生む、という点は見落とされやすい論点です。

評価とレッドチーミングはどの頻度で回すか

モデルやサービスの更新時と、四半期に一度の定期実施を組み合わせる運用が現実的です。

日本のAIセーフティ・インスティテュート（AISI）は2024年9月に「AIセーフティに関する評価観点ガイド」と「AIセーフティに関するレッドチーミング手法ガイド」を公表しており、社内で評価の型を作る際の出発点として使えます。実務では、自社の高リスクユースケースに絞って攻撃シナリオを10〜20件用意し、更新のたびに同じシナリオを流して結果を比較する形が続けやすいでしょう。導入時の検証だけで終わらせると、モデル更新後の挙動変化を検知できません。

インシデント発生時の対応はどう設計するか

生成AI起因の事象を既存のインシデント報告経路に接続し、判断基準を先に決めておきます。

新しい報告窓口を作るより、既存の情報セキュリティインシデント対応フローに生成AI固有の類型を追加するほうが定着します。事前に決めておくべきは、機密情報を入力してしまった場合の初動、誤情報を対外的に発信した場合の訂正手順、AIエージェントが誤操作を実行した場合の停止権限の所在です。あわせて、報告した利用者を責めない運用を明示しないと、報告そのものが上がってこなくなります。

生成AIのセキュリティ対策は、規程の分量ではなく、実態把握と権限設計の精度で決まります。まず利用実態を棚卸しし、扱ってよいデータの線引きを示し、承認済みの選択肢を用意する。RAGやAIエージェントに進む段階では、参照権限と実行権限の設計に工数を割く。この順序であれば、利活用の速度を落とさずに統制を効かせられます。技術は変わり続けますが、最小権限と説明可能性という原則は、当面変わらない土台になるはずです。

姉妹メディアの関連記事