先に要点
- AIに入力して危ないのは、機密情報だけではありません。個人情報、認証情報、未公開資料、著作権リスクの高い原文、外部から拾った不審な文書にも注意が必要です。
- 気を付けるべきことは、`何を聞くか` より 何をそのまま渡すか にあります。
- そのまま入れず、マスキング、要約、項目抽出、ダミーデータ化で目的を達成できないかを先に考えます。
- 添付ファイル、メール本文、Webページ、議事録は、情報源であると同時にプロンプトインジェクションの入口にもなります。
- 実務では、入力前チェック、禁止情報、承認ルール、ログ方針を決めておく方が安全です。
生成AIを使うとき、多くの人は どう聞けばうまく答えてくれるか に意識が向きます。
もちろんそれも大事ですが、実務ではそれ以上に 何を入力してはいけないか 何を加工してから入れるべきか の方が重要です。
特に、仕事でAIを使うときは、プロンプト本文だけでなく、添付資料、会話履歴、貼り付けたログ、メール本文、Webページの引用も入力情報です。
ここを雑に扱うと、情報漏えい、著作権トラブル、誤回答、プロンプトインジェクションの原因になります。
この記事では2026年4月19日時点で、OpenAI、Google、Anthropic、OWASPの公式情報を確認しながら、AIに渡すプロンプトやインプット情報で気を付けることを実務向けに整理します。
結論：まず見るべきは「入力内容の危なさ」
AIに渡す情報で最初に見るべきなのは、プロンプトの上手さではなく、入力内容の危険度です。
ざっくり言うと、次の順で見ます。
- 入れようとしている情報は何か
- そのまま外部AIへ渡してよいか
- 加工して目的を達成できないか
- 情報源自体が危険な命令を含んでいないか
- 後から誰が見ても説明できる入力か
この順番で見ると、プロンプトのコツ と 情報管理 を混同しにくくなります。
そのまま入れない方がいい情報
まず、次の情報は原則としてそのまま入れない方が安全です。
| 情報の種類 | 例 | 基本姿勢 |
|---|---|---|
| 機密情報 | 未公開仕様、顧客名、見積、事業計画、ソースコード | 原則そのまま入れない |
| 個人情報 | 氏名、メール、住所、電話番号、問い合わせ履歴 | 利用目的とルール確認が必要 |
| 認証情報 | APIキー、パスワード、秘密鍵、トークン | 入力しない |
| 著作権リスクの高い原文 | 有料教材全文、他社記事全文、契約書全文 | 必要最小限にする |
| 未検証の外部文書 | メール、共有ドキュメント、Webページ、PDF | 命令混入も疑う |
このへんは、便利だから 一瞬だけだから では済まないことが多いです。
とくに受託や法人利用では、生成AIにクライアント情報を入力してよい？機密情報・契約・ログ管理の実務判断の観点ともつながります。
気を付けるべきポイント
1. 機密情報は「少しぼかせばOK」ではない
顧客名を消しても、案件名、金額、時期、地域、機能名、担当者の役割が残っていれば、十分に特定できることがあります。
つまり、表面上の名前だけ消しても安全とは限りません。
そのため、単なる伏字ではなく、何の粒度まで落とせば目的を達成できるかを考える必要があります。
たとえば A社向けの脆弱性報告書 をそのまま入れる代わりに、Webアプリ診断結果の改善優先度を一般論で整理してほしい に変えられないか、という発想です。
2. 個人情報は目的と範囲で考える
個人情報は、氏名やメールアドレスだけではありません。
問い合わせ本文、会話履歴、注文内容、社員評価メモ、営業メモのように、個人と結びつく情報も注意が必要です。
AIでやりたいことが 問い合わせ傾向の分類 なら、氏名や会社名まで要らないことが多いです。
先にマスキングや項目抽出をしてから渡す方が安全です。
3. 認証情報は絶対に入れない
これはシンプルです。
APIキー、パスワード、秘密鍵、セッショントークン、接続文字列は入れません。
このエラーの原因を見てほしい ときに、設定ファイルや環境変数をそのまま貼る事故はかなり起きやすいです。
ログ共有前に、秘密情報が混ざっていないかを必ず見ます。
4. 添付資料や外部文書は「命令」かもしれない
ここは最近かなり重要です。
OWASPはプロンプトインジェクションを、LLMの挙動を悪意ある入力で操作する脆弱性として整理していて、Webページやメールに埋め込まれた間接的な命令も問題になると説明しています。
つまり、AIに読ませる資料は、単なる参考情報ではなく、隠れた命令を含む可能性がある入力です。
特に、次のようなものは注意します。
- 送られてきたメール本文
- 共有されたGoogle DocsやNotion
- 要約させるWebページ
- 外部ベンダーのPDF
- OCRした画像やスクリーンショット
この文書を要約して と頼んでいるつもりでも、AIには文書中の命令文が混ざって見えることがあります。
5. 長いコンテキストは便利だが、危険も増える
AIのコンテキストとは？プロンプト・会話履歴・RAGとの違いを整理でも触れた通り、AIはプロンプト本文以外も入力情報として扱います。
会話履歴、添付ファイル、検索結果、ツール出力が全部混ざると、便利になる一方で危険も増えます。
不要な情報や古い情報、機密情報、怪しい外部文書が混ざると、回答精度も安全性も落ちやすいです。
安全に使うための考え方
加工してから入れる
最初に考えるべきは、そのまま入れる 以外の方法です。
- 固有名詞を一般化する
- 氏名や会社名を伏せる
- 文章全文ではなく要点だけ抜く
- 生ログではなくエラー行だけ抜く
- 本番データではなくダミーデータに置き換える
この一手間で、かなり事故リスクを下げられます。
情報源を信頼しすぎない
OpenAIの安全ガイドでは、入力長を制限したり、信頼できるソース由来の範囲へ絞ったりすることが推奨されています。
Googleも、必要な文脈を明示し、構造化し、複雑な作業は分割する方がよいと案内しています。
言い換えると、何でも自由入力 何でも添付 何でも長文で一気に は危ないです。
入力を制限し、必要な材料だけに絞る方が精度も安全性も上がります。
命令と資料を分ける
OpenAIは、指示を先頭に置き、コンテキストとは区切って書くことを勧めています。
Anthropicも、重要な情報や文脈はユーザー質問と分けて扱う戦略を案内しています。
実務では、次の形がかなり有効です。
指示:
- 以下のログを要約し、原因候補を3つ出す
- 秘密情報を出力しない
対象データ:
"""
ここに必要最小限のログだけ入れる
"""
命令と資料が混ざるほど、AIは誤解しやすくなります。
複雑な作業は分ける
Googleのガイドでは、複雑なタスクは分割や連鎖で扱う方がよいと案内されています。
これは安全面でも有効です。
たとえば、
- データから不要情報を除く
- 要約する
- 分類する
- 提案を出す
と分ければ、毎回全部の情報を渡さずに済みます。
よくある失敗
1. エラー調査で設定ファイルを丸ごと貼る
.env、接続文字列、鍵、トークンが混ざりやすいです。
エラー行と周辺だけに絞る方が安全です。
2. 会議録をそのまま要約させる
議事録には個人名、社名、価格、未公開方針、感情的な発言が混ざります。
まず要点抽出や匿名化をしてからの方が安全です。
3. 外部記事やメールを無批判に食わせる
プロンプトインジェクションや誤情報の入口になります。
出典確認と、命令混入の可能性を意識した方がよいです。
4. 禁止事項だけ書いて安心する
OpenAIのガイドでも、何をするな だけでなく 代わりに何をするか を示す方がよいとされています。
たとえば 個人情報を聞くな だけでなく、必要ならFAQへ誘導しろ と書く方が安定します。
実務で使いやすい入力前チェック
AIに送る前に、最低でも次を確認するとかなり事故が減ります。
- 個人名、社名、メール、電話番号が入っていないか
- APIキー、パスワード、接続情報が入っていないか
- 未公開資料や契約情報が入っていないか
- 外部文書やメールの命令混入を疑うべき内容ではないか
- 目的に対して情報量が多すぎないか
- そのままではなく、要約やマスキングで代替できないか
まとめ
AIに渡すプロンプトや入力情報で気を付けるべきことは、どう聞くか だけではありません。
何を渡すか どこまで渡すか どんな資料を混ぜるか が、精度と安全性を大きく左右します。
特に、機密情報、個人情報、認証情報、著作権リスクの高い原文、不審な外部文書は慎重に扱うべきです。
そのまま貼らず、マスキング、要約、項目抽出、ダミーデータ化で目的を達成できないかを先に考えるのが実務ではかなり大事です。
参考リンク
- OpenAI Help Center: Best practices for prompt engineering with the OpenAI API
- OpenAI API Docs: Safety best practices
- Google AI for Developers: Prompt design strategies
- Anthropic Docs: Reduce prompt leak
- OWASP: Prompt Injection