先に要点
- 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ツールは、それらしいコードや手順をかなり自然に出します。
でも、自然に見えることと、安全で正しいことは別です。
よくあるのは、
このリスクは、AIが悪意を持つからではなく、人が それっぽい出力 を信用しやすいから起きます。
特にインフラ、認証、課金、権限まわりはレビュー前提が安全です。
5. シャドーAI
社内で承認されていないAIツールや、個人アカウントの無料版AIへ業務データを入れる状態は、よくあるリスクです。
これは 悪意ある持ち出し というより、便利だから勝手に使ってしまう形で起きます。
禁止だけで止めるのは難しく、社内で安全に使える公式ルートがないと、むしろ広がりやすいです。
既存の生成AIを社内で使うときのセキュリティ対策は？入力ルール・権限・運用設計を解説でも触れた通り、承認済みツールと利用ルールをセットで整える方が現実的です。
6. ブラウザ拡張機能・プラグイン・エージェント連携
AIツールのセキュリティでは、チャット本体より拡張機能や連携部分が危ないことがあります。
とくに、ブラウザ拡張機能は閲覧中ページや入力内容へ触れやすく、権限が広いと意図しない情報取得の入口になります。
また、エージェント型ツールは 読める だけでなく 操作できる ことがあります。
ファイル作成、チケット更新、メッセージ送信、コード変更まで自動化されると、誤動作時の影響が大きくなります。
7. ログと履歴の残り方
AIツール利用では、会話履歴やプロンプト履歴、添付ファイル履歴、監査ログが残ることがあります。
これは監査や再現性のためには大事ですが、全文ログに敏感情報が残ると別のリスクになります。
つまり、ログを残すか残さないか ではなく、何をどこまで残すか の設計が必要です。
この点は、生成AIにクライアント情報を入力してよい？機密情報・契約・ログ管理の実務判断の考え方ともかなり重なります。
実務でやると効果が高い対策
入力ルールを決める
- 入れてよい情報
- 入れてはいけない情報
- 加工してから入れる情報
を分けるだけで、かなり違います。
最小権限にする
- 連携範囲を絞る
- 読み取りだけにする
- 個人トークンより組織管理を優先する
外部文書を信頼しすぎない
- 要約対象のメールやWebページを無条件に読ませない
- 信頼できるソースに寄せる
- 命令混入を疑う
生成物をレビューする
は、特に人間レビュー前提にします。
公式ルートを作る
企業では、禁止だけでなく、承認済みのAI環境、SSO、DLP、監査ログ、申請ルールを整える方が効果が高いです。
筆者が実際に使って固めた「リスク × 対策 × 確認の仕方」チェックリスト
ここまでは一般的な整理ですが、最後に筆者自身が業務で運用しているチェックリストを共有します。 筆者はSE歴9年以上の現役エンジニアで、直近はAIを本格的に実戦投入し、3か月で社内アプリ80本規模を開発しました。その過程で痛感したのは、「リスクを知っている」ことと「対策が回っている」ことは別だという点です。対策を書いて終わりにせず、確認の仕方まで決めておかないと、忙しい現場では結局すり抜けます。
そこで、各リスクに対して「具体的な対策」と「どう確認するか」をセットにして手元で運用しています。新しいツールを試す前に、この表を上から1分で見直すだけで、致命的な事故はかなり防げています。
| リスク | 具体的な対策 | 確認の仕方 |
|---|---|---|
| 機密・個人情報の入力 | 機密情報や個人情報はそのまま入れず、ダミー化や匿名化をしてから渡す | 送信前に固有名詞、接続文字列、顧客名が残っていないか目視で1回確認する |
| 学習への利用 | オプトアウト設定やゼロデータ保持(学習に使わせない)を有効にする | 設定画面で学習利用がオフか、入力が保存されない契約かを確認する |
| 出力の検証不足 | ハルシネーションや著作権侵害を前提に、出典と内容を人間が確かめる | コードは実行とレビュー、事実は一次情報、文章は引用元の有無を確認する |
| プロンプトインジェクション | 外部のメールやWebページを無条件で読ませず、信頼できる入力に絞る | 要約対象に隠し命令や不自然な指示文が混ざっていないか確認する |
| APIキー・権限管理 | 連携は最小権限と読み取り中心にし、個人トークンより組織管理を優先する | キーの権限範囲と有効期限、使っていない連携が残っていないかを確認する |
| ログと監査 | 全文ログに敏感情報を残さず、何をどこまで保存するかを設計する | 保存対象のログにマスキングが効いているか、保持期間が妥当かを確認する |
| シャドーAI | 私物アカウントへ業務データを入れず、承認済みの公式ルートを使う | 使っているツールが利用一覧にあるか、個人課金になっていないか確認する |
実際にアプリを量産していて効いたのは、表の真ん中の「対策」より、右端の「確認の仕方」を具体的にしておくことでした。 対策だけだと「気を付ける」で終わりがちですが、確認の手順まで決めておくと、自分でもチームでも同じ基準で止められます。プロンプトインジェクションのように完全には防ぎきれないリスクほど、入力を絞り、出力を疑い、確認をルーチン化する地道なやり方が現実的だと感じています。
AIツールのセキュリティリスクのよくある質問
Q. ChatGPT などを禁止する企業はまだ多いですか？
A. 減っています。代わりに Enterprise 契約で安全に使う 流れが主流です。完全禁止 → シャドー利用が増える → 把握できないリスクが拡大 というパターンが多いため、公式ルートを整備する 戦略に変わっています。
Q. AI ツールの社内ポリシーで最低限決めるべきことは？
A. 使ってよいツール一覧、入力してよいデータ分類、禁止行為(無断契約、個人課金、機密の AI 送信など)、違反時の対応、相談窓口 の5点です。
Q. AI ベンダーの SOC2、ISO 27001 認証は重要ですか？
A. 重要です。データ保護の最低水準を示します。Enterprise 契約や代表的なベンダー(OpenAI、Anthropic、Google)は取得済みですが、新興 AI スタートアップは未取得のことも多いので注意します。
Q. プロンプトインジェクションをアプリで防ぐには？
A. ユーザー入力の検証、システムプロンプトと入力の分離、出力の検証、AI に渡す前の正規化、危険な命令の検出、などを組み合わせます。完全に防ぐのは難しいので、AI 出力を信頼しない設計 が基本です。
Q. AI 生成コードに脆弱性が混ざるリスクはどう管理しますか？
A. CI/CD に SAST(静的解析)、SCA(依存スキャン)、シークレット検出、を組み込みます。AI が書いた = 安全 ではなく、人間が書いた以上にチェックする のが安全です。
Q. RAG(社内文書検索AI)のセキュリティ注意点は？
A. アクセス権限の継承、機密文書のインデックス除外、PII の自動マスキング、ユーザーごとの結果絞り込み、ログ取得と監査、です。全社員が役員資料を AI 経由で読める 状態を作らないようにします。
Q. AI による業務自動化(エージェント)のリスクは？
A. 暴走、誤操作、コスト爆発、外部 API の不正呼び出し、操作の取り消し不能、などです。許可リスト方式、重要操作は人間承認、予算上限、実行ログ でガードレールを重ねます。
まとめ
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