生成AIを会社で使いたいが、何を守れば安全なのか判断がつかない。そう感じる担当者は少なくありません。禁止事項を並べるだけの運用では現場が指示を守りきれず、実際に事故が起きた時の対応も決まらないままになります。
この記事では、生成AIに特有のセキュリティリスクを整理します。そのうえで、企業、利用者、開発担当者がそれぞれ何を対策すべきかを解説します。目的は、安全に利用できる範囲を定めることです。許可する業務と条件を先に決め、入力、契約、権限、監査の運用を組み立てる考え方です。
公開情報の要約だけに使う場合、顧客情報を入力する場合、社内データへ接続してファイル更新やメール送信まで任せる場合。この三つでは、情報が漏れた時の影響も、必要な対策の重さも大きく異なります。まず自社の利用形態がどれに近いかを確認してください。そのうえで、入力、保存、学習利用、アクセス権、外部送信、出力確認、ログ、停止手順を一つずつ点検します。
生成AIにセキュリティ対策が必要な理由
生成AIのセキュリティ対策は、一般的な情報セキュリティ対策の延長線上にはありません。生成AI特有の性質に合わせて、別立てで考える必要があります。生成AIは入力した文章や資料を外部のサービスへ送信します。出力される内容も常に正しいとは限りません。事実と異なる説明を、そのまま信じてしまう危険があります。
さらに注意したいのが、業務システムとの接続です。API、RAG(検索拡張生成)、AIエージェントとして接続すると、生成AIは情報を閲覧するだけでなく、送信や更新といった操作まで担うようになります。従来のパソコンやスマートフォンの端末管理では、通信先やアプリの制御はできても、入力した文章の中身やAIが下した判断内容までは把握できません。この把握しきれない領域こそ、生成AI固有のセキュリティ対策が必要な理由です。
IPA(情報処理推進機構)は、生成AIの導入、運用、リスク管理を分けて考えるガイドラインを公開しています。企業に求められるのは、利用者、扱うデータ、契約プラン、連携先のシステム、権限、監査方法を一つの利用単位としてまとめて評価する姿勢です。
生成AIの主なセキュリティリスク
生成AIの利用で起こり得るリスクは複数あります。想定する使い方によって現れ方も変わります。代表的なものは、機密情報や個人情報の漏えい、誤った情報をそのまま公開してしまう誤情報の拡散、著作権や知的財産権に関わる問題、悪意のある入力で想定外の指示を実行させるプロンプトインジェクション、生成されたコードに含まれる脆弱性、外部サービスとの連携部分を狙った悪用、そして部署や個人が管理外で生成AIを使い始めるシャドーAIです。
これらのリスクは、生成AIのサービス自体が安全でも発生します。たとえば共有設定を誤ったまま資料を生成AIへ渡すと、本来見せてはいけない相手にも内容が届きます。権限設定の誤りは、サービスの脆弱性がなくても情報漏えいにつながる典型的な失敗条件です。
リスクの大きさは利用形態でも変わります。個人が社内向けの下書きを作る場面と、AIエージェントが顧客へ直接メールを送信する場面。この二つを同じルールで扱うと、後者で発見が遅れやすくなります。影響度、発生しやすさ、検知方法、止め方を業務ごとに整理する。これが失敗を早期に見つける前提です。
企業が行うべき生成AIセキュリティ対策
企業が生成AIのセキュリティ対策を進める時は、まず何を許可し、何を管理下に置くかを一つずつ決める作業から始めます。許可する生成AIサービスと契約プラン、入力してよい情報の範囲、用途ごとの出力確認者、アカウントの発行と管理、利用ログの取得、外部システムとの連携可否、データの保存と削除、事故発生時の連絡先。これらを決める根拠になるのが、各サービスの公式な利用規約やプランの説明です。法人向け契約であっても、学習利用の有無、データの保持期間、管理者機能の範囲はサービスや契約内容によって異なります。
決めた内容は文書化するだけでは伝わりません。「顧客名を伏せれば入力してよいか」「契約書の要約を社外の取引先へ共有してよいか」。現場で迷いやすいこうした具体例を挙げ、許可、禁止、要確認の三つに仕分けて教育する。これが実務に定着しやすい進め方です。
導入して終わり、という話でもありません。利用状況、事故やヒヤリハットの有無、新しいサービスや契約変更の有無を定期的に見直します。そのうえで許可範囲や教育内容を更新し続ける。これが企業側の継続的な役割です。
利用者が守るべき生成AIの安全な使い方
現場の利用者に求められるのは、会社が許可したアカウントとサービスだけを使うこと。そして、入力する前に情報の機密区分を確認することです。生成AIが返してきた内容には、そのまま使ってよい場面と、必ず人の目で確認すべき場面があります。顧客向けの文章、契約書、採用や人事評価、医療や法務に関わる判断。こうした影響の大きい用途では、出力をそのまま使わず、元になる資料や情報へ戻って裏付けを取ります。
| 場面 | 対応 |
|---|---|
| 公開済みの一般情報を要約する | 会社が許可したサービスであれば入力してよい |
| 顧客名や契約条件など個人情報・機密情報を含む | 匿名化や上長への確認なしに入力しない |
| 契約書、人事評価、医療・法務に関わる判断に使う | 出力をそのまま使わず、元資料で裏付けを取ってから使う |
| 社内で許可されていない外部GPTや拡張機能を使う | 事前に管理者へ確認し、許可されるまで使わない |
この表は、入力前と出力後のどちらで立ち止まるべきかを見極めるための目安です。実際の可否は会社が決めたルールを優先します。不審な共有リンク、社内未許可の外部GPT、ブラウザ拡張機能、連携アプリを追加しないことも欠かせません。誤って機密情報を入力してしまった場合、自分だけで削除して終わらせてはいけません。入力した内容、発生した時刻、使用したサービス、共有範囲を記録したうえで、管理者へ速やかに連絡してください。
生成AIをシステム連携する場合の追加対策
API、RAG、AIエージェントとして生成AIを業務システムへつなぐと、閲覧だけの利用より確認すべき項目が増えます。APIやRAGを使う構成での主な確認ポイントは、認証情報の保管方法、参照するデータへのアクセス権限、利用ログの取得、リクエストの回数制限、生成結果の送信先です。AIエージェントとして動かす場合は、エージェントが呼び出せる機能や道具を必要な範囲だけに絞ります。送信、削除、購入、権限変更のような操作には人による承認を挟んでください。外部の文書やウェブページに埋め込まれた指示を、そのままエージェントに実行させない対策も欠かせません。
生成AIが書いたコードは、人が書いたコードと同じ扱いにします。レビュー、テスト、依存関係の確認、脆弱性検査を通してから使う点は変わりません。RAGを使う構成では、元になる文書に設定された閲覧権限を、生成AIの回答にもそのまま引き継ぐ設計が必要です。この引き継ぎが漏れると、権限のないユーザーに、本来閲覧できない文書の内容が回答として渡ってしまう事故が起こります。AIエージェントを導入する際の設計条件はAIエージェント導入、RAGの仕組みと注意点はRAGで詳しく説明しています。
生成AIセキュリティ対策の導入手順
生成AIのセキュリティ対策は、順序が重要です。次の順番で整えると、利用範囲を広げながらも管理が追いつかなくなる事態を避けられます。
- 社内の利用実態と、これから使いたい用途を洗い出し、扱うデータの機密度と、生成AIに任せる操作の範囲でリスクを分類する。
- 候補となる生成AIサービスの契約内容、データの取り扱い、管理者機能を確認し、まず限られた利用者と業務範囲で試験導入する。
- 利用ルール、教育内容、問い合わせ先、監視の仕組み、緊急時の停止手順を用意してから、対象部署や用途を広げる。
どこまで利用範囲を広げてよいか。判断材料になるのは、試験導入で見つかった事故やヒヤリハットの件数、利用者からの問い合わせ内容、確認にかかった手間です。問題が続く用途は、範囲を広げずに条件を見直します。
導入した後も、新機能の追加、契約内容の変更、連携システムの追加、事故の発生、利用者からの質問を定期的にレビューしてください。生成AIの安全性評価は一度きりで終わりません。利用範囲が変わるたびに見直す前提で運用します。IPAやNISTなど公的機関が出しているガイドラインの更新日も定期的にチェックしておくと、社内ルールとの差分に早く気づけます。
まとめ
生成AIのセキュリティ対策は、入力禁止事項を並べるだけでは完成しません。許可するサービスと契約内容、アカウントの管理、入力してよい情報の範囲、出力の確認方法、外部システムとの連携、利用ログ、事故対応の連絡先。これらを、企業、利用者、開発担当者それぞれの役割に分けて決める必要があります。利用者に求められる確認と、API・RAG・AIエージェントを扱う開発担当者に求められる確認は異なります。
まず自社の業務を一つ選んでください。そこで扱う情報と生成AIに任せる操作を、具体的に洗い出します。そのうえで権限を必要な範囲まで絞り、出力を確認する担当者と、問題が起きた時に利用を止める手順を決めてください。安全性を理由に生成AIの利用を一律で禁止するより、守れる条件を業務ごとに具体化していく方が、結果としてシャドーAIの発生も把握しやすくなります。
