先に要点
- AIツール利用でまず起きやすいのは、情報漏えい、権限の与えすぎ、外部文書経由のプロンプトインジェクションです。
- 危ないのはプロンプト本文だけではなく、添付ファイル、会話履歴、連携ツール、ブラウザ拡張機能、生成コード、ログ保存も含みます。
- OpenAIやOWASPの公開ガイドでも、入力制限、権限分離、信頼できるソースへの限定、出力確認が重要とされています。
- 企業利用では、`使うな` だけでなく、承認済みツール、入力ルール、監査ログ、DLP、SSO、権限設計をセットで考える方が安全です。
- 個人利用でも、仕事用データを私物AIへ入れる、拡張機能へ広いアクセス権を与える、生成コードを未検証で本番へ入れるのは危険です。
生成AIやAIエージェントを使うと、調査、要約、コード生成、画像生成、議事録整理、問い合わせ対応がかなり速くなります。
ただ、その便利さの裏で、従来のSaaS利用とは少し違うセキュリティリスクも増えています。
特にやっかいなのは、AIツールが 入力された情報を読む だけでなく、外部文書を読み 他ツールとつながり その出力を人間が信じて行動しやすい ことです。
そのため、単なる情報漏えい対策だけでは足りません。
この記事では2026年4月19日時点で、NIST、OWASP、OpenAI、Anthropicの公開情報を確認しながら、AIツールを使う際に気を付けるべきセキュリティリスクを実務向けに整理します。
結論：まず警戒すべきリスクは5つ
最初に押さえたいのは、この5つです。
- 情報漏えい
- 過剰な権限付与
- プロンプトインジェクション
- 生成物の無検証利用
- シャドーAI利用
この5つは、個人利用でも企業利用でも起きやすいです。
しかも、1つずつ独立しているのではなく、つながって事故になります。
たとえば、個人の私物AIへ仕事データを入れる、そこにメール要約用の外部連携がつながる、さらに生成されたコードや要約を人が無検証で採用する、といった形です。
どんなリスクがあるのか
| リスク | 何が起きるか | よくある場面 |
|---|---|---|
| 情報漏えい | 機密情報や個人情報が外部サービスへ渡る | 要約、翻訳、エラー調査、議事録整理 |
| 過剰権限 | AIツールや拡張機能が必要以上の情報へ触れる | メール連携、Drive連携、GitHub連携 |
| プロンプトインジェクション | 外部文書内の命令でAIの挙動が乗っ取られる | メール要約、Web要約、RAG、エージェント |
| 生成物の信頼しすぎ | 危険なコードや誤った手順をそのまま採用する | コード生成、設定変更、SQL、運用手順 |
| シャドーAI | 未承認ツールへ仕事データが流れる | 個人アカウント、無料版、私物端末 |
1. 情報漏えい
AIツールでまず一番分かりやすいのはこれです。
プロンプト、添付ファイル、会話履歴、ログ、画像、議事録、ソースコードに、機密情報や個人情報が混ざると、そのまま外部AIへ送られる可能性があります。
NISTのGenerative AI Profileでも、生成AI利用ではプライバシー、セキュリティ、情報管理、ガバナンスを合わせて見る必要があると整理されています。
また、OpenAIの安全ガイドでも、入力を制限し、信頼できる範囲へ絞ることが推奨されています。
ありがちな事故は次のようなものです。
- エラー調査で
.envや接続文字列ごと貼る - 議事録をそのまま要約させる
- 顧客名入りの仕様書を翻訳する
- 本番ログを丸ごと貼る
入力情報そのものの注意点は、AIに渡すプロンプトや入力情報で気を付けること｜機密情報・個人情報・著作権・プロンプトインジェクションでも詳しく整理しています。
2. 過剰な権限付与
AIツールは、単体チャットより、外部連携や拡張機能を付けた瞬間に危険度が上がります。
メール、カレンダー、Drive、Slack、Notion、GitHub、IDE、ブラウザ拡張機能へ広く触れられると、便利になる反面、影響範囲も広がります。
特に危ないのは、便利だから全部許可 の状態です。
本来は読み取りだけで足りるのに書き込み権限まで付いている、特定フォルダだけで足りるのに全社Driveへアクセスできる、という状態は事故の温床になります。
企業では、SSO、最小権限、承認済み連携、監査ログを前提にした方が安全です。
個人でも、使っていない連携や拡張機能を放置しないだけでリスクが下がります。
3. プロンプトインジェクション
OWASPは、プロンプトインジェクションをLLM向けの重要な脅威として整理していて、直接入力だけでなく、Webページやメールに埋め込まれた間接的な命令も問題になると説明しています。
これはAIツールを 使う側 にも普通に関係します。
たとえば、次のような場面です。
- メール要約AIが悪意ある本文を読む
- Webページ要約AIが隠し命令を読む
- RAGで読み込んだ文書に命令が混ざる
- チケット本文やIssueコメントが命令になる
つまり、AIに読ませる文書は、単なる資料ではなく、命令を含むかもしれない入力です。
Anthropicも、文脈と質問を分離することや、重要な指示を分けて管理することを案内しています。
4. 生成コードや提案の無検証利用
AIツールは、それらしいコードや手順をかなり自然に出します。
でも、自然に見えることと、安全で正しいことは別です。
よくあるのは、
- 脆弱なコードをそのまま採用する
- 危険なシェルコマンドをそのまま実行する
- SQLやアクセス制御を無検証で使う
- セキュリティ設定の説明をうのみにする
このリスクは、AIが悪意を持つからではなく、人が それっぽい出力 を信用しやすいから起きます。
特にインフラ、認証、課金、権限まわりはレビュー前提が安全です。
5. シャドーAI
社内で承認されていないAIツールや、個人アカウントの無料版AIへ業務データを入れる状態は、よくあるリスクです。
これは 悪意ある持ち出し というより、便利だから勝手に使ってしまう形で起きます。
禁止だけで止めるのは難しく、社内で安全に使える公式ルートがないと、むしろ広がりやすいです。
既存の生成AIを社内で使うときのセキュリティ対策は？入力ルール・権限・運用設計を解説でも触れた通り、承認済みツールと利用ルールをセットで整える方が現実的です。
6. ブラウザ拡張機能・プラグイン・エージェント連携
AIツールのセキュリティでは、チャット本体より拡張機能や連携部分が危ないことがあります。
とくに、ブラウザ拡張機能は閲覧中ページや入力内容へ触れやすく、権限が広いと意図しない情報取得の入口になります。
また、エージェント型ツールは 読める だけでなく 操作できる ことがあります。
ファイル作成、チケット更新、メッセージ送信、コード変更まで自動化されると、誤動作時の影響が大きくなります。
7. ログと履歴の残り方
AIツール利用では、会話履歴やプロンプト履歴、添付ファイル履歴、監査ログが残ることがあります。
これは監査や再現性のためには大事ですが、全文ログに敏感情報が残ると別のリスクになります。
つまり、ログを残すか残さないか ではなく、何をどこまで残すか の設計が必要です。
この点は、生成AIにクライアント情報を入力してよい？機密情報・契約・ログ管理の実務判断の考え方ともかなり重なります。
実務でやると効果が高い対策
入力ルールを決める
- 入れてよい情報
- 入れてはいけない情報
- 加工してから入れる情報
を分けるだけで、かなり違います。
最小権限にする
- 連携範囲を絞る
- 読み取りだけにする
- 個人トークンより組織管理を優先する
外部文書を信頼しすぎない
- 要約対象のメールやWebページを無条件に読ませない
- 信頼できるソースに寄せる
- 命令混入を疑う
生成物をレビューする
は、特に人間レビュー前提にします。
公式ルートを作る
企業では、禁止だけでなく、承認済みのAI環境、SSO、DLP、監査ログ、申請ルールを整える方が効果が高いです。
まとめ
AIツールを使う際に気を付けるべきセキュリティリスクは、情報漏えいだけではありません。
過剰権限、プロンプトインジェクション、生成物の無検証利用、シャドーAI、拡張機能や連携の広すぎる権限も重要です。
実務では、AIだから危ない とまとめるより、どの入力が危ないか どの権限が広すぎるか どの生成物をレビューすべきか に分けて考える方が対策しやすいです。
この切り分けができるだけで、AIツールの便利さを活かしつつ、事故の確率をかなり下げやすくなります。
参考リンク
- NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- OWASP: Prompt Injection
- OWASP GenAI Security Project: Home
- OpenAI Help Center: Best practices for prompt engineering with the OpenAI API
- OpenAI API Docs: Safety best practices
- Anthropic Docs: Reduce prompt leak