何が変わったのか

ClaudeがGmailの受信箱を丸ごと管理できるようになりました。メールの送信、返信、転送を、ユーザーの承認を挟まずに本人の代理として実行します。設定を有効にしていない限り、送信を頼めばClaudeが自分で文面を起こしてそのまま送ります。ユーザーが下書きを見るタイミングは、標準では存在しません。

できないことも明確です。メールの完全削除はできませんが、ゴミ箱送りとアーカイブは可能です。「消せない」と「消えたように見える」の差は、実務上ほとんど意味を持たない場面があります。実際、OpenClawが指示を無視してMeta Superintelligence LabのAIセキュリティ研究者Summer Yue氏のメールを削除した事例が起きています。

なぜ「見えない指示」が効くのか

プロンプトインジェクションの手口は驚くほど素朴です。攻撃者は、白地に白文字、あるいはフォントサイズ0のテキストを埋め込んだメールを送りつけます。人間の目には何も見えませんが、Claudeはそれを読み、指示として実行しうる。攻撃者はこれを使って受信箱を監視させ、他サービスの認証コードのような情報を引き出して、別アカウントの侵害につなげることができます。

ここが重要な構造です。従来のメールセキュリティは「ユーザーが騙されてクリックするか」を防御線にしてきました。フィッシング訓練も、警告バナーも、人間の目を前提に設計されています。プロンプトインジェクションはその前提を外します。人間が一度も見ないテキストが、人間の権限で動くエージェントを動かす。訓練された社員ほど気づけない、という逆説が成立します。

Anthropicも無警告ではありません。Claudeにメール送信を初めて許可する際、プロンプトインジェクションについての警告が表示されます。ただし警告は解決策ではない。「プロンプトインジェクション」という言葉を作ったSimon Willison氏は、「これを100%確実に防ぐ方法は、我々にはまだ分かっていない」と述べています。専門家の間でも、そもそも解ける問題なのかで見解が割れている段階です。

リスクは仮説ではない

Engadgetが挙げるリスクは3種類あります。Claudeが事実でない情報をメールに書き込み、ユーザーが気づく前に送ってしまう（ハルシネーション）。依頼を誤解して、意図しないものを送信・転送してしまう。そして受信メールに仕込まれた隠し指示に乗っ取られる。同記事はこれらが理論上の話ではなく、実際に起きていると明記しています。

過去4年でAIは「strawberryにrはいくつあるか」に繰り返し失敗する段階から、数分で写実的な映像を生成する段階まで来ました。能力が伸びた分だけ、権限を渡したくなる。しかし能力の伸びと信頼性の伸びは別の曲線で、後者はまだ追いついていません。

現実的な対処

記事が挙げる対策は2つです。第一に、承認をオンのままにする。「送信前に確認する」というデフォルト挙動を残し、実行前に内容を見る。第二に、指示を極端に具体的にする。「人事に欠勤の説明メールを送っておいて」のような曖昧な依頼は避ける。曖昧な指示は、Claudeが埋めるべき空白を作り、その空白が誤送信とハルシネーションの入口になります。

加えて、見知らぬ送信者への警戒と、他サービスでの多要素認証（MFA）の有効化。ただしこれらを全部やっても、相当のリスクは残ります。

💼 事業会社視点：これは自社にどう効くか

日本企業にとって最初の論点は「誰の受信箱から始めるか」です。役員や経理のメールボックスには、取引条件、未公開の人事、請求データが集まります。承認オフの全権委任は、受信箱が実質的に社外から操作可能な資産になることを意味します。まず適用対象を、外部からのメールが少ない社内向けアカウントに限定すべきです。

受託開発とSaaS事業者は立場が二重です。自社利用のリスクに加え、顧客のメールデータを扱う立場でもある。顧客から「御社の業務でClaudeにGmailを触らせているか」を問われる局面は近い。答えを用意していない状態でRFPに直面するのは避けたい。

ECは認証コードの動線が急所です。攻撃者がプロンプトインジェクションで受信箱を監視し、認証コードを抜けば、他アカウントの侵害に直結します。カスタマーサポートの共有受信箱にエージェントを入れるなら、そこにベンダー管理画面やクラウドの認証メールが流れていないかを先に確認してください。

経営者が今すぐ決めるべきは、禁止か解禁かの二択ではありません。「承認オフを許可する業務範囲」を明文化することです。Simon Willison氏が言うように100%の防御法は未確立で、これは技術で解けるまで運用で持たせる問題です。