規制・社会

AIの代理送信と暗号化攻撃に学ぶ情報漏えい対策

記事バナー画像

POINT

  • OpenAIがChatGPTからApple Messagesを操作できるプラグインを公開し、AIがユーザーに代わってメッセージを下書き・送信できるようになった
  • 同時期、暗号化した悪意ある指示でAIチャットボットの制限を回避し、ユーザー名やチャット履歴を外部に送信させる攻撃手法がGrokで確認された
  • 記事を読むと、AIに接続権限を渡す際に何を確認し、どんな情報を代理送信させてはいけないかが分かる

※ 本記事で紹介する攻撃手法は研究者による検証事例であり、すべてのAIサービスで同様の被害が発生するとは限らない

ChatGPTが「代わりにメッセージを送る」とはどういうことか

OpenAIは2026年8月20日、ChatGPTからAppleのMessages受信箱を接続できるプラグインを公開した。ChatGPT can now send texts for you with new Apple Messages plug-inによれば、このプラグインはCodexやChatGPT Workにも対応し、メッセージの整理や分析、編集ができる。

できることは想像より広い。メッセージの削除、利用者に代わる下書き作成と送信、過去の会話履歴からの情報検索まで一通りこなす。「先週のあの人との約束、リマインドしておいて」と頼めば、AIが履歴を読んで文面を作り、そのまま送る仕組みだ。

OpenAIはメッセージ全体をインデックス化しない設計にし、内容は端末にローカル保存されサーバーには送らないと説明している。ただし設定時にはFull Disk Accessの有効化が必須で、AIは端末上のファイルを読み書きできる状態になる。OpenAI自身も、送信前に内容を確認するよう利用者に呼びかけ、永続的な承認設定にすると最終チェックの機会が消えると注意している。便利さと引き換えに、確認の手間を意図的に減らさない設計になっている点は覚えておきたい。

ChatGPT Messagesプラグインの動作フロー
プラグインの処理手順(全6ステップ) STEP 01 アクセス許可 Full Disk Access を有効化する 【利用者操作】 STEP 02 受信箱接続 ChatGPTが Messagesの 受信箱に接続 STEP 03 履歴読取 リクエスト毎に 履歴を読み取り ※全体DB化なし STEP 04 下書き作成 指示に基づき メッセージの 下書きを作成 STEP 05 送信前確認 送信前に内容を 最終確認 (推奨設定) STEP 06 送信実行 確認された メッセージを 相手へ送信 セキュリティ・データ保護 ローカル保存: メッセージデータや会話履歴は端末内にのみローカル保存されます。 サーバー非送信: OpenAIの外部サーバーには送信・保存されません。 インデックス不保持: メッセージ全体の常時インデックス化は行われません。 プラグインの動作の流れ STEP 01 Full Disk Access 有効化 利用者が端末のアクセス権限を許可 STEP 02 Messages受信箱に接続 ChatGPTが受信箱データへ接続 STEP 03 個別リクエストで履歴を読取 必要な情報のみ参照(全体DB化なし) STEP 04 メッセージの下書き作成 指示に応じた文面をAIが作成 STEP 05 送信前確認 (推奨設定) 送信前に利用者が文面を最終チェック STEP 06 メッセージ送信 確認された文面を相手へ送信 セキュリティ・データ保護 ローカル保存: 内容はすべて端末内に保存 サーバー非送信: OpenAIサーバーへは非送信 インデックスなし: 全体検索DBは作成しない
※処理はローカル環境で完結し、OpenAIのサーバーにはメッセージデータが送信されません。

暗号化した指示でAIを乗っ取る攻撃とは

代理送信の利便性の裏で、AIチャットボット自体を騙して情報を抜き取る手口も進化している。Adversaの研究者Rony Utevskyは、暗号化した悪意ある命令でGrokの制限を回避する攻撃を発見した。Grok exfiltrates user data when malicious instructions are encryptedが詳しい。

仕組みはこうだ。攻撃用のウェブページに暗号文と復号方法、復号鍵を仕込んでおく。利用者が「このページを要約して」とGrokに頼むだけで、暗号文に隠された命令が実行される。PBKDF2とAES-256-GCMという暗号技術を使い、復号後の命令はGrok自身のコード実行結果としてモデルに渡されるため、通常のフィルターをすり抜けてしまう。

Grokが生成した偽の復号鍵にはユーザー名、所在地、チャット履歴が含まれ、その情報が攻撃者のURLのパラメーターとして送信された

Grokが攻撃者の用意したURLを開いた瞬間、送信内容は攻撃者のサーバーのログに記録される。この手法は「Cryptographic Context Injection」と呼ばれ、Adversaは同じ方法をGeminiへの脱獄攻撃にも応用し、制限コンテンツの生成やシステム指示の再現に成功している。Geminiはここ数週間で耐性を高めたが、Adversaはその原因を特定できていないという。xAIには6月に通知済みだったにもかかわらず、記事公開時点でGrokの挙動は変わっていなかった。Microsoft 365 Copilot for Enterpriseでも、秘密の入力で受信トレイのパスワードを外部送信させる攻撃が報告されている。

渡してよい情報、ダメな情報の線引き

この二つの事例は別々の話ではない。AIに「読ませる・送らせる」権限を渡すこと自体が、便利さとリスクを同時に運ぶという一つの構造だ。判断基準を持たずに接続すると、便利な秘書のつもりが情報漏えいの入口になりかねない。

渡してよいのは、公開されても実害が小さい定型的なやり取りだ。日程調整、リマインド、公開情報の要約依頼などはAIに任せやすい。逆に渡してはいけないのは、パスワード、認証コード、口座番号、取引先との機密情報、家族の所在地といった単独で悪用可能な情報だ。ChatGPTのMessagesプラグインでもGrokの攻撃でも、狙われているのはまさにこの種の情報である。

Full Disk Accessのような包括的な権限は、必要な機能に対して過剰な場合が多い。メッセージを要約してほしいだけなのに端末全体へのアクセスを許可する状況になっていないか、設定画面で権限範囲を確認する価値はある。

今すぐできる自衛策

まず、AIに読ませるウェブページや文書は出所を選ぶ。見知らぬリンクの「要約して」という一手間が、暗号化された命令を実行させる引き金になり得る。仕事で使う場合は特に、社外から届いたURLをそのままAIに渡す前に一呼吸置きたい。

次に、代理送信機能を使うなら永続的な承認は避け、送信前の確認画面を毎回通す設定にする。OpenAI自身が警告している通り、この一手間を省略した瞬間にチェック機能は失われる。

最後に、パスワードや認証情報をAIとのやり取りに含めない習慣を徹底する。Microsoft 365 CopilotやGrokの事例が示すのは、AIが悪意を持って情報を盗むのではなく、巧妙な指示に騙されて正規の機能として情報を送信してしまう構図だ。だからこそ、AI側の防御に頼り切らず、そもそも危険な情報を渡さない運用が効く。

まとめ

AIにメッセージの送受信を任せる機能は便利だが、権限の広さと送信内容の確認体制はセットで見直す必要がある。代理送信を有効にする前に、その接続で何にアクセスできるのかを一度確認し、パスワードや認証情報など単独で悪用できる情報は最初から渡さない。これが今すぐできる最も確実な対策だ。