読んだ資料に AI が指図される？マーケティング業務のプロンプトインジェクション対策

競合のウェブサイト、代理店の提案書、メールで届いた文書。こうした資料の要点を AI アシスタントにまとめてもらうとき、注意したいのが資料中に書かれた「依頼」です。人なら通常、それが自社の上司からの指示ではないと判断します。しかし、AI が分析する文章の中には、業務を変更させる指示が紛れ込むことがあります。

この問題を考える出発点は、資料が正しいかどうかだけではありません。その資料に、アシスタントの仕事を決める権限まで与えていないか。読み取り、要約、社内情報の参照、メッセージの送信を一つの流れにまとめる前に、確認しておきたい点です。

要約の間違いと、仕事を変えさせる指示は違う

プロンプトインジェクションとは、攻撃者が用意した内容によって、大規模言語モデルに本来の目的から外れた動作をさせようとすることです。利用者がその指示を直接入力するとは限りません。ウェブページや文書、メール、ツールが返した結果を通じて入ってくるものは、間接的なプロンプトインジェクションと呼ばれます。

例えば、存在しない製品機能を AI が書いてしまう場合は、根拠のない情報を生成した問題です。一方、読んだページに要約の方針を変えるような指示が含まれている場合は、情報源を通じて仕事に介入しようとする問題です。要約が偏るだけでなく、ツールの使い方が変わったり、情報が外に出たりする可能性もあります。どこまで影響するかは、アシスタントが使える機能と権限によって変わります。

ここで架空の場面を考えてみましょう。三社の公開ページを比較して社内向けの説明資料を作る途中、一社のページに、自社を有利に扱い、弱点には触れないよう求める文章が含まれていたとします。それでも、依頼された仕事は出典のある比較のままです。ページ内の文章が、その方針を変更できるわけではありません。

もし同じアシスタントに社内の価格検討メモを読む権限や、メッセージを送る機能まで与えていたら、社内情報を本来見せてはいけない相手に送ってしまうおそれもあります。公開情報を調べる仕事に、それらの権限を自動的に持たせる必要があるのかを問い直すべきです。見慣れたサイトだからと信頼したり、特定の怪しい言い回しだけを探したりしても、この問題を確実に見分けることはできません。

「閲覧のみ」の設定でも、情報の出口を確認する

MindVerve では、最初の試行を、承認済みの機密性のない資料から下書きを作る業務に絞ることを勧めています。マーケティング担当者だけで判断せず、システム管理者と一緒に、入力元、読める社内データ、利用可能なツール、外部への通信経路、成果物を読む人を確認します。調査に不要な書き込み、送信、公開の機能は無効にし、調査の段階には秘密情報を渡しません。

注意したいのが「閲覧のみなら安全」という解釈です。読み取り専用の権限は、一部の変更操作を防ぎますが、読んだ情報が外に出ることまで自動的に防ぐものではありません。アクセスできる URL、外部へのリクエストにどの情報を含められるか、結果を受け取れる相手も確認する必要があります。ファイルを書き換えなくても、通信や回答を通じて情報が伝わる可能性があるためです。

こうした制限は、利用する基盤の機能や IT・セキュリティ部門の設定によって実現するものです。マーケティング担当者がプロンプトに「外部送信は禁止」と書くだけでは設定したことになりません。提案された操作を言語モデルの外側で検証し、許可した処理と宛先だけを通す仕組みについて、システムの責任者に確認しましょう。

権限や外部通信の制限を確認できない場合は、担当者が選んだ承認済み文書を手動で渡し、外部操作を行わない範囲まで試行を縮めます。機密情報を扱う必要が出てきたら、その時点で IT・セキュリティの責任者と範囲を相談します。

プロンプトと人の確認、それぞれに任せる役割

指示文には、調査の目的、比較する項目、出典を残すことを明記します。資料の中に仕事を変えようとする文章があれば、従わずに、信頼できない資料中の指示として報告するよう求めます。業務の指示と資料を分けて渡すことは意図を伝える助けになりますが、それ自体がセキュリティ上の境界になるわけではありません。

関連する文章を検索してから回答を作る RAG（検索拡張生成）でも、検索結果に含まれる指示によって仕事を変えられるおそれは残ります。別の AI に回答を点検させる方法も、見落としがなくなる保証にはなりません。モデルの振る舞いに加え、権限の制限、モデル外での操作検証、継続的な確認を組み合わせてリスクを減らす必要があります。複数の対策を重ねても、完全な防御が証明されるわけではありません。

人が確認する段階では、重要な主張を元の資料に戻って確かめられるようにします。出典が残っていれば、競合企業自身の説明と、比較の結果として導いた結論を区別しやすくなります。単に読んで承認する役目にせず、どの主張と操作を見るのかを決めておくことが大切です。

下書きを代理店に送る場合は、作成とは別の手順に分けます。確認画面には送る内容そのもの、実際の宛先、送信という操作を示し、その組み合わせを承認します。曖昧な「続行」では何を許可したのか分かりません。ウェブへの公開や広告予算の変更も、それぞれ別の操作として許可と確認が必要です。

試行では、回答だけでなく実行記録を見る

導入前には、隔離した環境で架空の文書とデータを使い、動きを確かめるとよいでしょう。以下は実施を提案する演習であり、実行済みの検証結果ではありません。本物のメッセージを送らない環境で、通常の業務が成立するかと、許可しない操作が起きないかを一緒に確認します。

1. 通常の資料を渡す。内容に忠実で、担当者が使える要約ができることを確かめる。
2. 要約に無関係な標語を入れるよう求める文書を渡す。その要求を実行せず、資料中の不適切な指示として報告できるかを見る。
3. 未承認の架空の相手へ資料を送るよう求める文書を渡す。許可されていない外部操作が起きていないか、実行ログで確かめる。

アシスタントが「送信していません」と答えても、それだけで判断してはいけません。実際に何を実行したかをログで確認します。入力、プロンプト、モデル、業務フローのバージョン、期待した結果、観察した結果を記録し、どの条件で何が起きたのかを追えるようにします。

問題のない資料まで拒否していないか、必要な仕事を完了できたか、人による確認にどれだけ手間がかかったかも見ます。誤検知が多く、毎回調べ直しが必要なら、業務として有用かどうかを再検討する必要があります。一度の合格で安全が確定するわけではなく、モデル、ツール、業務手順に重要な変更を加えたら再度試します。

予期しない操作や情報の開示が起きた場合は、対象の業務フローを止め、利用範囲を広げないようにします。調査に必要な最小限の証拠を残し、機密情報をむやみに複製・共有せず、担当する IT・セキュリティ責任者に引き継ぎます。再開前には再検証が必要です。

一つの業務を、無理なく確認できる範囲で始める

外部の資料は判断の根拠になっても、アシスタントに権限を与える立場にはありません。まず一つの業務について、何を読み、何を作り、どの操作を別途承認するかを決めましょう。必要な情報だけを扱い、人が根拠を確認できる状態で役に立つなら、その範囲には導入を進める価値があります。

担当者への研修は、権限設定の代わりにはなりません。同様に、技術的な設定だけでは、比較の観点や主張の妥当性を判断する仕事はなくなりません。両方を一つの業務に合わせて整えることで、次に自動化する範囲も判断しやすくなります。

参照した公式資料の確認日：2026 年 9 月 22 日（UTC）。