ソフトウェア セキュリティ AI 公開日 2026.04.19 更新日 2026.10.26

AIに渡すプロンプトや入力情報で気を付けること|機密情報・個人情報・著作権・プロンプトインジェクション

AIに渡すプロンプトや添付資料で何に気を付けるべきかを、機密情報、個人情報、著作権、ログ、プロンプトインジェクションの観点から整理します。

目次(30項目)

先に要点

  • AIに入力して危ないのは、機密情報だけではありません。個人情報、認証情報、未公開資料、著作権リスクの高い原文、外部から拾った不審な文書にも注意が必要です。
  • 気を付けるべきことは、「何を聞くか」 より 何をそのまま渡すか にあります。
  • そのまま入れず、マスキング、要約、項目抽出、ダミーデータ化で目的を達成できないかを先に考えます。
  • 添付ファイル、メール本文、Webページ、議事録は、情報源であると同時にプロンプトインジェクションの入口にもなります。
  • 実務では、入力前チェック、禁止情報、承認ルール、ログ方針を決めておく方が安全です。

生成AIを使うとき、多くの人は どう聞けばうまく答えてくれるか に意識が向きます。
もちろんそれも大事ですが、実務ではそれ以上に 何を入力してはいけないか 何を加工してから入れるべきか の方が重要です。

特に、仕事でAIを使うときは、プロンプト本文だけでなく、添付資料、会話履歴、貼り付けたログ、メール本文、Webページの引用も入力情報です。
ここを雑に扱うと、情報漏えい、著作権トラブル、誤回答、プロンプトインジェクションの原因になります。

この記事では2026年10月時点で、OpenAI、Google、Anthropic、OWASPの公式情報を確認しながら、AIに渡すプロンプトやインプット情報で気を付けることを実務向けに整理します。

結論:まず見るべきは「入力内容の危なさ」

AIに渡す情報で最初に見るべきなのは、プロンプトの上手さではなく、入力内容の危険度です。
ざっくり言うと、次の順で見ます。

入力前に見る順番

  1. 1
    入れようとしている情報は何か

    まず情報の中身を確かめる。

  2. 2
    そのまま外部AIへ渡してよいか

    そのまま渡せる情報かを判断する。

  3. 3
    加工して目的を達成できないか

    そのまま入れる以外の方法を考える。

  4. 4
    情報源自体が危険な命令を含んでいないか

    資料が命令を含む可能性を疑う。

  5. 5
    後から誰が見ても説明できる入力か

    最後に、説明できる入力かを確かめる。

この順番で見ると、プロンプトのコツ と 情報管理 を混同しにくくなります。

そのまま入れない方がいい情報

まず、次の情報は原則としてそのまま入れない方が安全です。

情報の種類 例 基本姿勢
機密情報 未公開仕様、顧客名、見積、事業計画、ソースコード 原則そのまま入れない
個人情報 氏名、メール、住所、電話番号、問い合わせ履歴 利用目的とルール確認が必要
認証情報 APIキー、パスワード、秘密鍵、トークン 入力しない
著作権リスクの高い原文 有料教材全文、他社記事全文、契約書全文 必要最小限にする
未検証の外部文書 メール、共有ドキュメント、Webページ、PDF 命令混入も疑う

このへんは、便利だから 一瞬だけだから では済まないことが多いです。
とくに受託や法人利用では、生成AIにクライアント情報を入力してよい?機密情報・契約・ログ管理の実務判断の観点ともつながります。

気を付けるべきポイント

1. 機密情報は「少しぼかせばOK」ではない

顧客名を消しても、案件名、金額、時期、地域、機能名、担当者の役割が残っていれば、十分に特定できることがあります。
つまり、表面上の名前だけ消しても安全とは限りません。

消した: 顧客名 残っている: 案件名金額時期 地域機能名担当者の役割 十分に特定できることがある

そのため、単なる伏字ではなく、何の粒度まで落とせば目的を達成できるかを考える必要があります。

そのまま入れる

A社向けの脆弱性報告書

一般化して聞く

Webアプリ診断結果の改善優先度を一般論で整理してほしい

こんな人向けこう変えられないか、という発想

2. 個人情報は目的と範囲で考える

個人情報は、氏名やメールアドレスだけではありません。
問い合わせ本文、会話履歴、注文内容、社員評価メモ、営業メモのように、個人と結びつく情報も注意が必要です。

目的に必要な範囲だけ渡す

AIでやりたいことが「問い合わせ傾向の分類」なら、氏名や会社名まで要らないことが多いです。先にマスキングや項目抽出をしてから渡す方が安全です。

3. 認証情報は絶対に入れない

APIキー・パスワード・秘密鍵・セッショントークン・接続文字列

これはシンプルです。これらは入れません。「このエラーの原因を見てほしい」ときに、設定ファイルや環境変数をそのまま貼る事故はかなり起きやすいです。ログ共有前に、秘密情報が混ざっていないかを必ず見ます。

4. 添付資料や外部文書は「命令」かもしれない

ここは最近かなり重要です。
OWASPはプロンプトインジェクションを、LLMの挙動を悪意ある入力で操作する脆弱性として整理していて、Webページやメールに埋め込まれた間接的な命令も問題になると説明しています。

つまり、AIに読ませる資料は、単なる参考情報ではなく、隠れた命令を含む可能性がある入力です。
特に、次のようなものは注意します。

メール

送られてきたメール本文

共有文書

共有されたGoogle DocsやNotion

Web

要約させるWebページ

PDF

外部ベンダーのPDF

画像

OCRした画像やスクリーンショット

「要約して」のつもりでも命令が混ざって見える

「この文書を要約して」と頼んでいるつもりでも、AIには文書中の命令文が混ざって見えることがあります。

5. 長いコンテキストは便利だが、危険も増える

AIのコンテキストとは?プロンプト・会話履歴・RAGとの違いを整理でも触れた通り、AIはプロンプト本文以外も入力情報として扱います。
会話履歴、添付ファイル、検索結果、ツール出力が全部混ざると、便利になる一方で危険も増えます。

混ざるほど精度も安全性も落ちる

不要な情報や古い情報、機密情報、怪しい外部文書が混ざると、回答精度も安全性も落ちやすいです。

安全に使うための考え方

加工してから入れる

最初に考えるべきは、そのまま入れる 以外の方法です。

一般化

固有名詞を一般化する

伏せる

氏名や会社名を伏せる

要点だけ

文章全文ではなく要点だけ抜く

エラー行だけ

生ログではなくエラー行だけ抜く

ダミー化

本番データではなくダミーデータに置き換える

この一手間で、かなり事故リスクを下げられます。

情報源を信頼しすぎない

OpenAIの安全ガイドでは、入力長を制限したり、信頼できるソース由来の範囲へ絞ったりすることが推奨されています。
Googleも、必要な文脈を明示し、構造化し、複雑な作業は分割する方がよいと案内しています。

言い換えると、何でも自由入力 何でも添付 何でも長文で一気に は危ないです。
入力を制限し、必要な材料だけに絞る方が精度も安全性も上がります。

命令と資料を分ける

OpenAIは、指示を先頭に置き、コンテキストとは区切って書くことを勧めています。
Anthropicも、システムプロンプトを使って重要な情報や文脈をユーザーの質問と分ける戦略を案内しています。

実務では、次の形がかなり有効です。

指示:
- 以下のログを要約し、原因候補を3つ出す
- 秘密情報を出力しない

対象データ:
"""
ここに必要最小限のログだけ入れる
"""

命令と資料が混ざるほど、AIは誤解しやすくなります。

複雑な作業は分ける

Googleのガイドでは、複雑なタスクは分割や連鎖で扱う方がよいと案内されています。
これは安全面でも有効です。

たとえば、次のように分ければ、毎回全部の情報を渡さずに済みます。

複雑な作業を分ける例
  1. 1

    不要情報を除く

    データから不要情報を除く

  2. 2

    要約する

    除いたあとのデータを要約する

  3. 3

    分類する

    要約を分類する

  4. 4

    提案を出す

    分類をもとに提案を出す

よくある失敗

失敗 1

エラー調査で設定ファイルを丸ごと貼る

.env、接続文字列、鍵、トークンが混ざりやすいです。エラー行と周辺だけに絞る方が安全です。

失敗 2

会議録をそのまま要約させる

議事録には個人名、社名、価格、未公開方針、感情的な発言が混ざります。まず要点抽出や匿名化をしてからの方が安全です。

失敗 3

外部記事やメールを無批判に食わせる

プロンプトインジェクションや誤情報の入口になります。出典確認と、命令混入の可能性を意識した方がよいです。

失敗 4

禁止事項だけ書いて安心する

OpenAIのガイドでも、「何をするな」だけでなく「代わりに何をするか」を示す方がよいとされています。たとえば「個人情報を聞くな」だけでなく、「必要ならFAQへ誘導しろ」と書く方が安定します。

実務で使いやすい入力前チェック

AIに送る前に、最低でも次を確認するとかなり事故が減ります。

確認 1:個人情報

個人名、社名、メール、電話番号が入っていないか

確認 2:認証情報

APIキー、パスワード、接続情報が入っていないか

確認 3:機密

未公開資料や契約情報が入っていないか

確認 4:命令混入

外部文書やメールの命令混入を疑うべき内容ではないか

確認 5:量

目的に対して情報量が多すぎないか

確認 6:代替

そのままではなく、要約やマスキングで代替できないか

AIプロンプト入力安全のよくある質問

Q. AI に入力したデータは学習に使われますか?

A. サービスとプランによります。2026年10月時点の各社の案内では、個人向けは設定次第で学習に使われることがあります。ChatGPT の Free / Plus / Pro は「すべての人のためにモデルを改善する」が既定でオンで、設定でオフにできます。Gemini の個人アカウントは「アクティビティを保持」がオンだとモデルの改善に使われることがあります。Claude の Free / Pro / Max はプライバシー設定でモデルの改善への利用を選べます。法人向け(ChatGPT Business / Enterprise / Edu、Google Workspace の Gemini、Claude の Team / Enterprise や API)は、既定で学習に使わないと案内されています。設定は変わることがあるので、使う前に各社のページで確認してください。

Q. プロンプトインジェクションとは何ですか?

A. 入力データに 攻撃者の命令 を混ぜ込み、AI に意図しない動作をさせる攻撃です。Webページ要約や添付ファイル解析で、相手側に潜んだ命令を AI が拾うリスクがあります。

Q. 個人情報のマスキングはどうやりますか?

A. 氏名 → 顧客A、電話 → 090-XXXX-XXXX、金額 → 金額X、のように記号化します。自動マスキングツール(Microsoft の Presidio など)も活用できます。

Q. コードに含まれる秘密情報はどう扱いますか?

A. API キー、DB 接続情報、Secrets を含むコードはそのまま送らず、xxxxxx などに置換します。または、トークン推定パターンを検出する pre-commit hook で AI 送信前にチェックします。

Q. 社内文書を AI に渡しても大丈夫ですか?

A. 法人向けプランで学習に使わない扱いになっていても、それだけで安全とは言い切れません。保存期間や管理者の閲覧範囲も確認したうえで、機密度分類 を社内で決めて、最高機密はオフライン LLM に限定するなどの方針が必要です。

Q. 過去のチャット履歴は誰が見られますか?

A. 個人プランでは基本的に本人のアカウントで管理します。法人向けプランでは、管理者が保存期間を決めたり、監査やデータの書き出しを行えたりする仕組みが用意されていることが多く、どこまで見られるかは契約と設定によります。退職時のアカウント削除、履歴の保持期間、サービスを超えたデータ持ち出し制限、をポリシー化します。

Q. プロンプト入力安全教育はどうやりますか?

A. 事例ベース が効果的です。実際の漏えい事例、社内で発生したヒヤリハット、許可されたツールと禁止ツール一覧、を四半期ごとに更新して全社で共有します。

まとめ

AIに渡すプロンプトや入力情報で気を付けるべきことは、どう聞くか だけではありません。
何を渡すか どこまで渡すか どんな資料を混ぜるか が、精度と安全性を大きく左右します。

特に、機密情報、個人情報、認証情報、著作権リスクの高い原文、不審な外部文書は慎重に扱うべきです。
そのまま貼らず、マスキング、要約、項目抽出、ダミーデータ化で目的を達成できないかを先に考えるのが実務ではかなり大事です。


参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。