1. はじめに
生成AIの活用が進み、業務でもChatGPTやGitHub CopilotのようなAIツールを使う機会が増え、文章の要約、議事録作成、コードレビュー、調査、設計相談など、日々の業務をかなり効率化してくれています。
一方で、企業で生成AIを使う場合には、個人利用とは違ったリスクがあります。
たとえば、以下のようなケースです。
- 社内文書や会議内容を外部AIに入力してしまう
- ソースコードや認証情報をAIに貼り付けてしまう
- AIが出した設定値を信じて、本番環境に誤設定してしまう
- ディープフェイクや偽情報によって意思決定を誤ってしまう
- プロンプトインジェクションにより、AIの制約を回避されてしまう
改めて生成AIセキュリティ講座を受講し、企業でAIを安全に使うには「AIを禁止する」のではなく、リスクを理解したうえで、安全に使えるルール・技術・運用を設計することが重要だと感じました。
この記事では、
- ✅ 生成AI特有の攻撃とは何か
- ✅ 企業で起きている重大インシデント
- ✅ 情報漏洩はどこで起きるのか
- ✅ AI出力を信じることの危険性
- ✅ 実務で意識すべき対策
上記の観点で生成AIのリスクを整理します。少しでも参考になったら幸いです。
※ なお、詳細なプロンプトインジェクション対策やRAG設計については、別記事で扱う予定です。
2. 生成AI特有の脅威とは
生成AIのリスクは、従来のWebアプリケーションやネットワークセキュリティのリスクとは少し性質が異なります。
特に特徴的なのは、自然言語の入力がそのままAIへの命令になるという点です。
従来のシステムでは、ユーザー入力は主に「データ」として扱われます。
しかし、生成AIではユーザーが入力した文章が、AIの振る舞いを変える「指示」として解釈されることがあります。
そのため、以下のような生成AI特有の脅威が発生します。
| 脅威 | 概要 |
|---|---|
| プロンプトインジェクション | 悪意ある指示により、AIの動作や出力を変更させる攻撃 |
| Jailbreak / 権限超越 | ガードレールを回避し、禁止された回答を引き出す攻撃 |
| Hallucination | AIが存在しない情報や誤った内容をもっともらしく生成する現象 |
| Fake Facts攻撃 | AIを使って偽情報を大量生成・拡散する攻撃 |
| RAG誘導攻撃 | 外部データや社内文書に悪意ある情報を混入し、AI回答を操作する攻撃 |
このうち、Hallucinationは必ずしも攻撃ではありません。
しかし、業務利用では誤判断や設定ミスにつながるため、セキュリティ上も重要なリスクとして扱う必要があります。
3. 企業で起きている代表的なリスク
生成AIの企業利用で起きやすいリスクは、大きく以下の4つに整理できます。
- 機密情報の入力による漏洩
- ソースコード貼り付けによる情報流出
- AI出力を信じた誤設定事故
- 偽情報・ディープフェイクによる意思決定誤り
3-1. 機密情報の入力による漏洩
生成AIに社内資料、議事録、顧客情報、設計書などを入力すると、その内容が外部AIサービスに送信されます。
サービスや契約形態によっては、入力内容がログとして保存されたり、品質改善に利用されたりする可能性があります。また、不具合や設定ミスによって、他ユーザーに情報が表示されるリスクもゼロではありません。
実際に、2023年にはChatGPT Plusで一部ユーザーの氏名・メールアドレス・請求先住所・クレジットカード番号の下4桁などが、短時間ほかのユーザーに表示され得た不具合がOpenAIから公表されています。
https://openai.com/index/march-20-chatgpt-outage/
実務で起きやすい例
- 議事録を要約するために、会議内容をそのまま貼り付ける
- 顧客対応メールを整えるために、顧客名や問い合わせ内容を入力する
- 契約書や設計書をわかりやすくするために、外部AIに貼り付ける
- 障害報告書を要約するために、システム構成や影響範囲を入力する
このような使い方は、どれも業務効率化としては自然だと思います。
しかし、入力内容に個人情報や機密情報が含まれている場合、情報漏洩につながる可能性があります。
対策
- 入力してよい情報・いけない情報を明文化する
- 個人アカウントでの業務利用を禁止する
- 社内専用AIやEnterprise向け環境を利用する
- DLPやPII検出で入力内容をチェックする
- 必要に応じて自動マスキングを行う
- AI利用ログを監査できる状態にする
重要なのは、「入れないでくださいね〜」という社員への注意だけに頼らないことです。
入力前に止める・隠す・承認する仕組みを用意する必要があります。
3-2. ソースコード貼り付けによる情報流出
開発者にとって、生成AIにコードを見てもらうことはよくあると思います。
たとえば、
- エラー原因を調べる
- リファクタリング案を出してもらう
- テストコードを作成する
- 脆弱性がないか確認する
- 実装方針を相談する
一方で、ソースコードには機密情報が含まれている場合があります。
- 独自アルゴリズム
- 社内システムの構成
- APIキー
- パスワード
- 秘密鍵
- 内部URL
- 顧客固有の業務ロジック
Samsungでは、従業員がChatGPTに機密コードを入力したことを受け、社内で生成AIツールの利用を制限したと報じられています。
https://www.forbes.com/sites/siladityaray/2023/05/02/samsung-bans-chatgpt-and-other-chatbots-for-employees-after-sensitive-code-leak/
実務で起きやすい例
- エラー解決のために、社内コードをそのまま貼る
- APIキー入りの設定ファイルを貼る
- 社内リポジトリ名や顧客名が含まれるコードを貼る
- AI生成コードを十分に確認せず取り込む
影響
ソースコードの流出は、単なる情報漏洩にとどまらず、
- 知的財産の流出
- 脆弱性の露呈
- 競争優位の喪失
- OSSライセンス違反
- 認証情報の漏洩
- 攻撃者による悪用
につながる可能性があります。
対策
- 外部AIへの機密コード貼り付けを禁止する
- 社内コードを扱える公式AI環境を整備する
- Secrets検知を導入する
- SASTなどの静的解析を併用する
- AI生成コードは必ずレビューする
- IDE拡張の権限・ログ・同期設定を管理する
コード生成AIは便利ですが、開発者向けには一般社員向けとは別に、より具体的なルールが必要だと感じました。
3-3. AI出力を信じた誤設定事故
生成AIの回答は、文章として自然で、断定的に見えることがあります。
そのため、利用者側が「それっぽいから正しそう」と感じてしまい、十分に検証しないまま手順や設定値を使ってしまうことがあります。
特に、クラウド設定やセキュリティ設定は環境依存の要素が多いため、一般的には正しそうな回答でも、自社環境では不適切な場合があります。
AIが提示した手順や設定値を検証せずに本番環境へ適用すると、以下のような事故につながる可能性があります。
- IAM権限の過大付与
- ネットワークACLの誤設定
- ストレージの公開設定ミス
- IaCテンプレートの誤り
- システム停止
- 情報漏洩
Hallucinationとの関係
よく聞くHallucinationとは、
情報が不足している場合でも、それらしい回答を生成すること です。
Hallucinationは、AIが悪意を持って嘘をつくというより、LLMの構造的な弱点として発生します。
問題は、AIの回答が自然で自信がありそうに見えるため、利用者が正しい情報だと誤認しやすいことです。
対策
- AI回答は「正解」ではなく「確認すべき候補」として扱う
- 本番適用前に検証環境で再現する
- 公式ドキュメントと照合する
- レビュー・承認フローを通す
- 最小権限の原則を守る
- 自動テストや静的解析を組み合わせる
特に開発者目線では、AIが出したコードや設定値をそのまま使うのではなく、自分で理解して説明できる状態にすることが重要だと感じました。
3-4. 偽情報・ディープフェイクによる意思決定誤り
生成AIは、文章だけでなく、画像・音声・動画も生成できるため、偽情報やディープフェイクによって、人の判断を誤らせるリスクがあると思います。
たとえば、経営者や上司の声・顔を再現し、送金や重要承認を迫るようなケースです。
香港では、ディープフェイクを使ったビデオ会議により、企業の従業員が約2,500万ドルを送金してしまった事例が報じられています。
https://www.ft.com/content/b977e8d4-664c-4ae4-8a8e-eb93bdf785ea?syn-25a6b1a6=1
攻撃の流れ
なりすまし
↓
信頼獲得
↓
緊急依頼
↓
通常プロセスの回避
↓
資金流出・誤判断
攻撃者は、「緊急」「秘密」「今すぐ」「通常手順を飛ばして」といった言葉で、正規の確認プロセスを回避させようとします。
対策
- 重要承認は複数経路で確認する
- 送金や契約変更は二重承認にする
- コールバック確認を行う
- 映像や音声だけで本人確認しない
- 緊急依頼ほど正規フローに乗せる
- 従業員教育で事例を共有する
ディープフェイク対策では、技術的な検出だけに頼るのではなく、業務プロセス自体をなりすましに強くすることが重要です。
4. 生成AIセキュリティで大事な考え方
今回の講座を通して、生成AIセキュリティでは以下の考え方が重要だと感じました。
4-1. AIを禁止するのではなく、安全に使える状態を作る
生成AIを完全に禁止しても、現場では業務効率化のために個人アカウントや非公式ツールが使われる可能性があります。
そのため、企業としては「使うな」ではなく、安全に使える公式環境を用意することが現実的です。
4-2. 事故は悪意だけでなく、便利さからも起きる
生成AIの事故は、攻撃者による悪意だけで起きるわけではありません。
「便利だから使う」
「早く終わらせたい」
「要約してほしい」
「コードを直してほしい」
こうした自然な業務行動の中に、情報漏洩や誤判断のリスクがあります。
4-3. AIの回答は正解ではなく、確認すべき候補
AIの回答は自然で説得力がありますが、正しいとは限りません。
特に、設定変更、セキュリティ判断、顧客対応、法務・契約に関わる内容は、人間による確認が必要です。
4-4. 技術・ルール・運用をセットで考える
生成AIセキュリティは、技術対策だけでは不十分です。
- ポリシー
- 入力制御
- 出力検査
- 権限管理
- ログ監査
- 社員教育
- インシデント対応
を組み合わせて考える必要があります。
5. 実務でまず確認したいチェックリスト
- 利用してよいAIツールが明確になっているか
- 個人アカウントでの業務利用を禁止しているか
- 入力禁止情報が具体例で示されているか
- 社内文書・顧客情報・ソースコードの扱いが決まっているか
- AIの回答を本番環境に適用する前のレビュー手順があるか
- 重要承認で複数経路確認を行っているか
- AI利用ログを監査できるか
- インシデント時の報告先が決まっているか
まとめ
生成AIは、業務効率化に大きく役立つ一方で、企業利用ではさまざまなリスクがあります。
特に、以下のようなリスクは実務でも起こりやすいと感じました。
- 機密情報の入力による漏洩
- ソースコード貼り付けによる情報流出
- AI出力を信じた誤設定事故
- 偽情報・ディープフェイクによる意思決定誤り
今回の学習を通して、生成AIセキュリティは「AIを禁止すること」ではなく、AIを安全に使いこなすための設計だと感じました。
次回は、生成AI特有の代表的な攻撃である「プロンプトインジェクション」について整理します。