生成AIのセキュリティリスク｜情報漏えい・誤情報・権限を分ける実務例

IPAはAIの利用をめぐるセキュリティリスクを取り上げています。文章作成が上手になったことは、機密情報を入力してよい理由にはなりません。利用者の情報入力、モデルの誤り、外部文書による誘導、操作権限の過剰などを分けて考えます。

個人用サービスへ業務情報を入れるシャドーAIは、組織が利用状況や契約条件を把握できない問題です。サービス名の承認だけでなく、アカウント、利用プラン、接続先、扱う情報の条件を定めて確認します。

リスクを組織の判断手順へ変える方法は生成AIの社内ルールで、承認対象と例外の記録から考えます。

架空の営業担当者が、会議録をAIで要約しようとしています。会議録には顧客名、連絡先、未公表価格、担当者の意見が含まれます。文章を短くする目的でも、全文を送れば、それらの情報も入力になります。氏名だけ削っても、組合せから相手が分かる場合があります。

まず必要な要約項目と、社内で利用が承認された環境を確認します。不要な情報を除き、顧客との約束や社内分類に反する情報は送らない判断が必要です。個人情報の法的な取扱いは、この架空例だけで可否を断定せず、管理者や法務の判断へつなげます。

「モデルの学習に利用しない」という設定は、提供者の保存期間、監査ログ、管理者の閲覧、外部連携などをすべて無くすという意味ではありません。実際の条件はサービスと契約で異なります。表示された一つの設定だけで、機密情報を入力できると判断しないようにします。

共同ワークスペースでは、共有範囲やリンクの公開先も点検します。社内文書を検索させる場合、もとの文書の閲覧権限を保ち、利用者が本来見られない資料を回答に混ぜない設計が必要です。

社内検索やRAGを使うAIは、検索先に書かれた文章を読みます。文章内の指示を利用者の命令として扱うと、意図しない情報の出力や操作につながることがあります。仕組みはプロンプトインジェクションの記事で別途扱います。

AIへメール送信やファイル操作も許可する場合は、読むだけの場合より影響範囲が広がります。必要最小限の権限、宛先や操作の制限、重要操作前の承認、記録を組み合わせます。承認ボタンがあっても、人が中身を読まず押す運用では十分な確認になりません。

架空のチームが最初は文章の下書きだけにAIを使い、後からメールや共有フォルダとの連携を有効にしたとします。サービス名が同じでも、読み取る情報と実行できる操作が増えれば、導入時と同じ条件ではありません。追加機能ごとに、用途、対象データ、利用者、承認者を確認します。

事故対応に備え、利用環境の所有者、停止方法、記録の保存場所、提供元への問い合わせ窓口を整理します。AIの応答だけを残しても、どの文書を参照し、どの操作を許可したかが分からなければ、原因の確認が難しくなります。ただし記録そのものに機密情報が含まれるため、保存範囲と閲覧権限も決めます。

担当者が退職・異動した後に共有や外部連携が残らないかも点検します。導入時の承認を一度得れば終わりではなく、機能・契約・利用目的が変わった時点で見直す仕組みが必要です。

独自ケースで、議事録には「価格は次回相談」とあり、AIの要約には「値下げを合意」と出ていました。自然な文章だから採用するのではなく、根拠となる発言へ戻り、未合意として修正します。出力の誤りは、情報漏えいとは別の品質・判断リスクです。

研修では「このサービスは安全か」という一問だけでなく、何を入力し、何を読ませ、何を出し、何を実行させるかを具体化すると判断を練習できます。AIの利用を禁止すればすべて解決すると決めつけず、必要な業務と管理できる条件を照合します。

本記事のケース・図解は当サイト独自の学習用です。公表事例と架空の練習例を区別し、実際の試験問題や過去問を再現していません。時事情報がそのまま出題されるという意味ではありません。

学習範囲を確認するなら情報・サイバーセキュリティ管理士の概要、理解を確かめるなら登録不要の無料お試し20問へ。収録内容と料金は管理士のコースページで確認できます。

外部の制度・事例は2026年10月14日時点で確認しました。事件の評価や製品の対応状況は更新されるため、実務判断では末尾の一次資料も再確認してください。