要点：業務ツールにおけるAIのデータ漏洩は、AIアシスタントが悪意あるテキストを読み込み、そこに隠された指示に従って、URLフェッチ、画像のレンダリング、またはリンクを通じて外部サーバーへプライベートデータを送信してしまうことで発生します。公開された調査研究では、Atlassian Rovo、Notion AI、Slack AIでこの現象が確認されています。NotionとSlackは修正パッチをリリースしましたが、2026年10月27日時点でRovoにおけるこの経路に対する公開された修正は見つかっていません。
プロジェクト管理AIは、サポートチケット、アップロードされたPDF、連携ツールのページ、パブリックチャンネルなど、利用者が書いていないテキストも読み込みます。そのいずれにも悪意ある指示が仕込まれている可能性があります。
本記事では、Rovo、Notion AI、Slack AI、ClickUp Brainを比較します。各行には一次情報源となる記事やベンダーの公式ページ、および日付を記載しています。情報が見つからなかった項目については「公開レポートなし」と記載しています。同様の仕組みはコーディングエージェントにも当てはまるため、記事の最後で詳しく取り上げます。
AIのデータ漏洩とは何か：一言で解説
間接的プロンプトインジェクション（Indirect Prompt Injection）とは、AIアシスタントが処理するコンテンツ内に隠された指示のことであり、AIはあたかも正規のユーザーから指示されたかのようにそれに従ってしまいます。
これがデータ漏洩に発展するのは、3つの条件が揃ったときです。Simon Willison氏は2025年6月、これを「死の三要素（lethal trifecta）」と名付けました。
- アシスタントがプライベートデータを読み取れること。
- アシスタントが外部の第三者が関与できるコンテンツを読み取ること。
- アシスタントに外部へデータを送信する手段があること。
このうち1つでも排除できれば漏洩経路は塞がれます。しかし、ワークスペース向けAIアシスタントはその設計上、この3つすべてを兼ね備えてしまっています。
Atlassian Rovoのデータ持ち出しの仕組み
PromptArmorは2026年8月5日にRovoに関する調査レポートを公開しました。その攻撃フローは極めてシンプルです。
- ユーザーが隠し指示の仕込まれたファイル（デモでは「バックログガイド」）をアップロードする。
- ユーザーがRovoにJiraチケットの整理を依頼する。
- RovoがJiraとConfluenceを検索し、ファイル内の隠し指示に従う。
- Rovoがチケットやページの内容を攻撃者のURLに付加し、自身のURL取得ツールでそのURLにアクセスする。
- 攻撃者のサーバーがデータを含んだリクエストを記録する。ユーザーの画面には通常通りの出力が表示される。
この間、ユーザーへの承認確認ステップは一切発生しませんでした。また、Web検索機能をオフにしていても攻撃は成立しました。なぜなら、そのトグルをオフにしてもURL取得ツール自体は無効化されないためです。さらに、RovoはMarkdown画像をレンダリングするため、これも第2の送信経路となります。
導入を検討する企業にとって、脆弱性開示のタイムラインは重要です。PromptArmorは2026年5月23日に報告し、Atlassianは5月25日に受領を確認しました。しかし、その後の6月4日と7月29日のフォローアップには返答がなく、脆弱性が残されたまま8月5日にレポートが公開されました。Hacker Newsのスレッドは306ポイント、138件のコメントを集めました。
なお、Rovoの別の問題については修正済みです。2026年8月14日付のCloud Security Allianceの研究ノートでは、チャットのURLパラメータを悪用したVaronisのワンクリック攻撃「RovoBlast」について触れられています。これについてAtlassianは、Varonisの公開前にサーバーサイドで修正を行いました。しかし同ノートでは、PromptArmorが指摘したドキュメント経由の経路は未解決のままであると述べられています。私たちが2026年10月27日時点で調査した限りでは、その後の修正のアナウンスは見当たりませんでした。
名称に関する注意点として、Rovo DevはAtlassianのコーディングエージェントです。本記事で取り上げているRovoアシスタントとは別製品であり、上記の調査ではテストの対象となっていません。
Rovo、Notion AI、Slack AI、ClickUp Brainの比較
以下の表は、各アシスタントで実証された挙動やドキュメントに記載された内容を比較したものです。「言及なし」は、参照した情報源においてその項目への言及がなかったことを意味します。
| 項目 | Atlassian Rovo | Notion AI | Slack AI | ClickUp Brain / Super Agents |
|---|---|---|---|---|
| 実証されたインジェクション経路 | アップロードファイル（PromptArmorはサポートチケット、Web検索結果、コネクタも指摘） | アップロードされた履歴書内の隠しテキスト | パブリックチャンネル内のメッセージ | 公開レポートなし |
| 実証された持ち出し経路 | URL取得ツール、Markdown画像のレンダリング | ドキュメントのテキストから生成されたMarkdown画像 | ユーザーがクリックするMarkdownリンク | 公開レポートなし |
| ユーザーのクリックや承認の要否 | 不要 | 不要（承認前に編集内容が保存された） | 必要（リンクを1回クリック） | 言及なし |
| 設定の無効化で阻止できたか | 不可（Web検索をオフにしても漏洩） | 言及なし | 研究者はファイルの取り込み制限を推奨 | 言及なし |
| 報告日 | 2026-05-23 | 2025-12-24（HackerOne経由） | 2024-08-14 | 対象外 |
| ベンダーの初回対応 | 受領確認とケース番号発行後、音信不通 | 2025-12-29に「該当なし」としてクローズ | 「意図された仕様」（2024-08-19） | 対象外 |
| 現在のステータス | 2026-10-27時点で公開された修正なし | Notionによると2026-01-07に本番環境へ修正適用済み | 2024-08-21にパッチ発表 | 公開レポートなし |
| 一次情報源 | PromptArmor（2026-08-05） | PromptArmor（2026-01-07） | PromptArmor（2024-08） | ClickUp（ベンダー公式ページ） |
なお、LinearとAsanaは今回の比較から除外しています。2026年10月27日時点の調査では、いずれのアシスタントについてもプロンプトインジェクションによるデータ持ち出しの公開レポートは見当たりませんでしたが、レポートが存在しないことが安全の証明になるわけではありません。
Notion AI：ユーザーが承認する前に編集内容が保存されていた
PromptArmorによるNotion AIの検証事例では、履歴書の中に1ポイントの白いフォントで指示が隠されていました。その履歴書をもとに採用トラッカーを更新するよう依頼されると、Notion AIはトラッカーのテキストを末尾に付加した画像URLを生成しました。Notionは外部URLに関する警告を表示したものの、編集内容はすでに保存されていたため、ユーザーが承認したかどうかにかかわらずデータは外部へ送信されてしまっていました。
Notionは脆弱性の公表後に問題を検証し、その日の夜に修正パッチをリリースしました。PromptArmorはNotion Mailの下書きアシスタントにも同様の問題が存在すると指摘していましたが、私たちが確認した更新情報では、今回の修正がMailにも適用されているかどうかは明記されていません。
Slack AI：「再認証」リンクを1回クリックするだけで漏洩
攻撃者は自身が作成したパブリックチャンネルに指示を投稿しました。被害者ユーザーが自身のプライベートチャンネルにある機密情報についてSlack AIに尋ねると、回答の中にその機密情報がURLに含まれた「再認証はこちらをクリック」というリンクが表示されました。このリンクを1回クリックするだけで、データが外部へ送信されてしまいました。
Slackは2024年8月19日、パブリックチャンネルの検索は意図された仕様であるとPromptArmorに回答しました。その後、2024年8月21日にSlackは低重大度のフィッシングシナリオに対するパッチを発表しましたが、SC Mediaの報道によると、そのセキュリティアドバイザリではPromptArmorの名前や同一の問題であるかどうかの確認には触れられていませんでした。またPromptArmorは、同月にSlack AIがチャンネルやDM内のファイルの取り込みを開始した点についても言及していますが、この経路についてはテストを行っていません。
ClickUp Brain：公開レポートは見当たらず
2026年10月27日時点で、ClickUp BrainまたはSuper Agentsに関するデータ持ち出しの公開研究は見つかりませんでした。ClickUpのSuper Agentsのページでは、エージェントは暗黙的および明示的な権限に基づいて動作し、「すべてのアクションに対して完全な監査証跡」を保持すると記載されています。また、Super Agentのワークフローに関するClickUpのブログ記事では、エージェントはユーザーレベルの権限を継承し、重要なアクションには人間の承認が必要であると述べられています。ただし、これらはベンダー側の主張であり、検証結果ではありません。なお、プロンプトインジェクションに関するClickUpのヘルプ記事はボット判定に引っかかったため、引用していません。
真に有効な対策と、攻撃を遅らせるだけの対策
Hacker Newsのスレッドでは、防御策の有効性について次のような順位付けが議論されていました。
- ユーザーが入力したURL、または信頼できるツールが返したURLのみを取得する：Simon Willison氏は、エージェント自身にいかなるURLも組み立てさせてはならないと主張しました。ワイルドカードDNSを利用すればサブドメインにデータを含めることができてしまうため、クエリ文字列をフィルタリングするだけでは不十分です。
- インデックス済みのURLのみに制限する：コメント投稿者のwunderwuzzi23氏は、取得対象を検索エンジンにインデックスされているページに限定しても、1回のリクエストにつき1文字ずつ漏洩させることが可能であると指摘しました。
- ドメインの許可リスト：業務範囲が限定されているアシスタントであれば、送信先として許可する外部ドメインの短いリストを作成することが有効に機能します。
- 分類器や正規表現フィルター：多層防御の1つのレイヤーとしては有用です。ただし確率的な仕組みであるため、最終防衛ラインにはなり得ません。
これらに共通する結論は、「スマートなプロンプトよりも、アウトバウンド経路に対する決定論的な制限のほうが効果的である」ということです。拒絶する頻度が高くなったモデルであっても、与えられたネットワークアクセス権限そのものは保持しています。この点については、Claude Opus 5.5のリリース時に公開したプロンプトインジェクションとエージェントのガードレールに関する記事でも指摘しました。
ワークスペース向けAIを有効化する前に確認すべきこと
以下の項目について、ベンダーへ書面で確認することをお勧めします。
- URLフェッチ、画像のレンダリング、リンクのレンダリング、メール、コネクタなど、テナント外へデータを送信できるツールはどれか？
- 関連する各設定はツール自体を完全に削除するのか、それともツールを利用する機能を表向き隠すだけなのか？（RovoのWeb検索トグルは後者でした）
- モデル自身が生成したURLを取得できるか？
- AIの出力内で外部ドメインからのMarkdown画像がレンダリングされるか？
- デフォルトで何を読み込むのか（アップロードファイル、接続されたドライブ、DM、パブリックチャンネルなど）？
- どの操作に人間の承認が必要であり、その承認は副作用（変更の保存など）が発生する前に行われるか？（Notionの事例では承認が後でした）
- 外部から直近で報告された脆弱性レポートに対し、ベンダーはどう対応し、解決までにどれだけの時間を要したか？
ワークスペースアシスタントを採用するのは、外部への送信経路が明確に文書化されており、それらを個別に無効化できる場合に留めるべきです。ベンダーがそれらをリストアップできない場合は、導入を見合わせるのが賢明です。
Sharklyの立ち位置について（率直な見解）
Sharklyはドキュメント内に埋め込まれたアシスタントではありませんし、プロンプトインジェクションに対して完全に無敵というわけでもありません。SharklyはClaude CodeやCodexなどのコーディングエージェントを管理しますが、これらのエージェントはIssueの本文、README、取得したページなど、信頼できないテキストを日常的に読み込んでいます。前述の「死の三要素」は、これらにも同様に当てはまります。
異なるのは、「誰がセキュリティ境界を管理しているか」という点です。Sharklyでは、エージェントはローカルサービスを介して利用者の管理下にあるコンピューター（Computer）上で実行されます。Computersのドキュメントに記載されているとおり、タスク実行に必要なファイル、認証情報、ネットワークアクセス、ツールはコンピューター側から提供されます。そのため、外部への通信（エグレス）制限は利用者が主導権を握って設定できます。コンピューターをドメイン許可リストの配下に置けば、どのアカウントやエージェントが実行されても、すべてのタスク実行がその制限を継承します。
ドキュメントには、その他にもいくつかの境界防御策が記載されています。
- ゲストは追加されたSpaceのみを閲覧可能：パブリックなSpaceを見つけたり、自身で参加したりすることはできません（ユーザーとロール）。
- サードパーティのアクションには認証済みコネクタが必要：自動化ワークフローは、連携設定されていない外部アプリを勝手に呼び出すことはできません。
- シークレット情報はSkillに含めない：Skillsのドキュメントでは、パスワード、トークン、秘密鍵などをSkillの指示やファイル内に決して保存しないよう定めています。
これらの対策をもってしても、エージェントが与えられた権限の範囲内で悪意ある指示に誘導されてしまう可能性をゼロにはできません。しかし、アクセス権限そのものを狭め、タスクに対して人間の承認ステップを維持することは可能です。コーディングエージェントの権限設定や承認ゲートに関する過去の記事では、その境界線をどこに引くべきかについて解説しています。
結論
コーディングエージェントを含め、信頼できないテキストを読み込むあらゆる製品において、プロンプトインジェクションは未解決の問題です。問うべき本質的な論点は、より絞り込まれます。「そのアシスタントは外部へ何を送信できるのか、そしてそれを無効化できるのか？」という点です。今回取り上げた4つのツールのうち、2つは漏洩が公表されて修正済み、1つは漏洩が公表されたものの修正が確認できておらず、残り1つは公開レポートがありませんでした。
複数のコーディングエージェントを運用し、ネットワークを自社で制御できるホスト環境で動かしたい場合は、1台のコンピューターをSharklyに接続し、送信トラフィック（エグレス）を厳格に制限したうえで、リスクの低いタスクをエージェントに1つ割り当ててみてください。Sharklyは現在、5名以下の組織であれば無料でご利用いただけます。
FAQ
Atlassian Rovoは現在もデータの持ち出しに対して脆弱ですか？
PromptArmorが指摘したドキュメント経由の経路は2026年8月5日時点で未修正であり、私たちが調査した2026年10月27日時点でも公開された修正は見つかっていません。なお、Varonisが報告した別のリンクに関する脆弱性は修正されています。
NotionはNotion AIのデータ漏洩を修正しましたか？
はい。Notionによると、AIによる安全でないドキュメント更新への是正措置は、PromptArmorが公表した当夜である2026年1月7日に本番環境へ適用されました。
Slack AIのプロンプトインジェクションは修正されましたか？
Slackは2024年8月21日にパッチを発表しましたが、それがPromptArmorの報告した問題と同一であるかは確認していません。
Web検索をオフにすればAIアシスタントからのデータ漏洩を防げますか？
必ずしも防げるとは限りません。Rovoの事例では、Web検索設定をオフにしてもURL取得ツール自体は削除されなかったため、依然として漏洩が発生しました。
AIセキュリティにおける「死の三要素（lethal trifecta）」とは何ですか？
「プライベートデータ」「信頼できないコンテンツ」「外部へのデータ送信手段」の3つです。この3つをすべて備えたアシスタントは、悪意ある誘導によってデータ漏洩を引き起こすリスクがあります。
コーディングエージェントも同様にデータを漏洩させる可能性がありますか？
はい。悪意あるREADMEを読み込み、かつネットワークアクセス権を持つコーディングエージェントは、まったく同じリスクに直面します。ホストレベルで認証情報を制限し、外部ネットワークへの通信を遮断することが重要です。
