ChatGPT WorkがGmail・Slack・GitHubのWebhookに対応、自動化で注意すべきリスクは？

OpenAIは2026年8月25日、ChatGPT Workのスケジュール型タスクに、Gmail、Slack、GitHubの更新をきっかけとして処理を始めるWebhookベースの機能を追加した。PlusとProのユーザーは、メールの受信やSlackへの投稿、GitHubのプルリクエストの変更に応じてタスクを実行できる。

クラウドブラウザには、一部のWebサイトへ安全にサインインし、その後の作業を継続する機能も加わった。さらに無料ユーザーも、最大3件のスケジュール型タスクを利用できるようになった。自動化の範囲が広がる一方、外部から届くコンテンツをAIが自動処理するため、接続先や権限、実行内容を慎重に設定する必要がある。

■Gmail、Slack、GitHubの更新をきっかけにタスクを実行

Webhookベースのタスクは、対応するアプリでイベントが生じたときに実行される。Gmailでは新着メッセージを受信した場合のほか、送信者や件名を条件にできる。Slackでは指定チャンネルへの新しい投稿、GitHubでは許可したリポジトリにおける対応済みのプルリクエストイベントを利用できる。

たとえば、登録開始を知らせるメールを受信した時点で内容を要約したり、顧客がSlackにフィードバックを投稿した際に次の対応案を作成したりできる。GitHubでは、プルリクエストの変更を受けてレビュー用の要約を準備させる使い方が考えられる。

従来の時間指定タスクでは、設定された時刻や時間帯が実行の起点となる。これに対してWebhookベースのタスクは、アプリ側のイベントを起点とするため、次の実行時刻を待たずに処理を開始できる。一般にWebhookは、イベントの発生を外部システムへ通知し、その通知を受けた側が後続処理を始めるイベント駆動型の仕組みである。

OpenAIは、Webhook通知やOAuth認可を内部でどのように実装し、維持しているかという詳細までは公開していない。このため、従来のスケジュール型タスクでは認可が実行のたびに終了し、Webhookでは受信トレイへの常時読み取り接続へ変わるとまでは断定できない。いずれの方式でも、接続したアプリに対する認可は、ユーザーが解除するまで残る場合がある。

重要な変化は、アクセス権の有無そのものより、外部から新しいコンテンツが届いたことをきっかけにAIの処理が始まる点にある。送信者を限定しないGmailタスクなどでは、信頼できない第三者が作成した内容が自動的に処理対象へ入る可能性がある。

■生成AIを組み込んだイベント駆動型自動化

従来型のワークフロー自動化では、イベント発生後に実行する処理をあらかじめ細かく定義する方式が中心だった。ChatGPT Workでは、イベントを受け取った生成AIが文章やコードの内容を読み取り、設定された指示に沿って要約、分類、下書き作成などを行う。

この仕組みにより、単にデータを別のアプリへ転送するだけでなく、メールの要点を抽出したり、プルリクエストの文脈を踏まえた説明を作成したりできる。入力内容を解釈して出力を変えられることが、生成AIを組み込む利点となる。

一方、処理結果が入力内容に左右されるため、悪意のある指示がメールやWebページなどに埋め込まれていた場合、エージェントの動作や回答が誘導される可能性がある。事前に固定された処理だけを行う自動化とは異なり、生成AIを使うタスクでは、入力データ自体を信頼できるかという観点も必要になる。

■クラウドブラウザがサインインを必要とするサイトに対応

ChatGPT Workのクラウドブラウザは、OpenAI側のリモート環境でWebサイトを操作する機能である。今回の更新により、一部の対応サイトでは、ユーザーがサインインした後もクラウドブラウザが作業を続けられるようになった。

サインインが必要になると、ChatGPT Workは処理を一時停止して認証画面を表示する。ユーザー名やパスワード、必要に応じて2要素認証のコードをユーザーが安全なフォームへ直接入力する。OpenAIによると、入力されたユーザー名とパスワードはモデルには表示されず、ChatGPTもこれらの認証情報を保存しない。

サインインの要求を表示する前には、別の確認用モデルが、入力先や画面にフィッシングなどの兆候がないかを検査する。ユーザー自身も、Webサイトのアドレス、ログインフォームのプレビュー、実際のページを確認してから入力できる。

サインイン後の認証状態は、将来のタスクでも利用できるよう残る場合がある。これはパスワードそのものを保存することとは異なるが、クラウド側のブラウザでログイン状態が継続する可能性があることを意味する。保存されたブラウザデータは、ChatGPTの設定からサイト別または一括で削除できる。

クラウドブラウザは、公共サービスの予約候補を探す、公共料金のプランを比較する、物件情報を保存する、会計ソフトの記録を更新するといった作業に利用できる。対応状況はWebサイトやアカウント、必要な操作によって異なり、一部の処理ではユーザーによる確認や最終操作が必要となる。

■メールを自動処理する場合のプロンプトインジェクション

Webhookベースのタスクでは、メールやチャンネル投稿など、第三者が作成したコンテンツが自動的にAIへ渡される可能性がある。そこで問題になるのが、コンテンツ内に悪意のある命令を埋め込み、AIに本来の依頼とは異なる処理を行わせようとする間接プロンプトインジェクションである。

セキュリティ企業のRadwareは2025年、ChatGPTのDeep ResearchとGmailを組み合わせた環境を対象に、「ShadowLeak」と名付けた脆弱性を報告した。実証実験では、攻撃者が白い背景に白い文字を置く方法や極端に小さい文字、HTMLのレイアウトを利用し、利用者から見えにくい命令をメールへ埋め込んだ。

ユーザーがDeep Researchに受信メールの調査を依頼すると、エージェントが隠された命令を読み取り、受信トレイ内の情報を外部へ送信する可能性があった。通信がOpenAIのクラウド環境から実行されるため、利用者側の端末や社内ネットワークだけでは検知しにくいことも特徴だった。Radwareによると、この脆弱性はOpenAIへの開示後、2025年8月に修正された。

今回のWebhook機能で同じ脆弱性が再現すると確認されたわけではない。しかし、第三者から届いたメールを生成AIが読み取るという共通構造があるため、間接プロンプトインジェクションは考慮すべきリスクとなる。OpenAIも、プロンプトインジェクションを継続的な対策が必要な難しい研究課題と位置付けている。

Webhookによって変わるのは、ユーザーが受信トレイの分析をその都度指示しなくても、指定した条件に合う新着メッセージをきっかけにタスクが起動し得る点である。特に外部の不特定多数からメールを受信するアカウントでは、信頼できない入力が自動処理へ入る可能性を前提に設定する必要がある。

■承認フローだけでは防げない処理もある

OpenAIのリリースノートによると、承認が必要と判断されたアクションについては、ChatGPT Workが処理を一時停止し、ユーザーの確認を求める。クラウドブラウザも、取り消しが難しい操作や、金銭、法律、アカウントなどに関する現実の義務を伴う可能性がある操作の前に確認を求めるよう設計されている。

もっとも、確認画面が表示されるかどうかは、機能や操作内容、OpenAI側の判定によって異なる。メールの読み取り、要約、分類、下書き作成など、外部への確定操作を伴わない処理でも、プロンプトインジェクションによって回答の内容が歪められる可能性はある。

承認フローは、最終的な送信や購入などを利用者が確認するうえで重要だが、AIが悪意のある指示を読み取ること自体を防ぐ仕組みではない。自動処理する入力の範囲を狭め、接続先の権限を必要最小限にする対策と組み合わせる必要がある。

■個人利用と組織利用で異なる管理方法

PlusとProの個人ユーザーは、ChatGPTの設定画面からGmail、Slack、GitHubを接続し、イベントと実行内容を設定できる。Googleアカウントなど接続先のサービス側でも、付与済みのアクセス権を確認し、不要になった連携を解除することが重要だ。

Slackでは、監視対象とする各チャンネルに「@ChatGPT」を追加する必要がある。この方式により、ワークスペース内のすべての会話ではなく、追加したチャンネルごとに対象を区切ることができる。参加者が限定されたチャンネルを選ぶことで、外部や不特定多数からの入力が処理される可能性を抑えられる。

Business、Enterprise、Eduなどの管理対象ワークスペースでは、プランや設定に応じて、管理者がWebhookベースのタスクや接続アプリの利用可否を制御できる。特にEnterprise、Edu、ChatGPT for Healthcareでは、管理者がイベント駆動型タスクを明示的に有効にする必要があり、初期状態では無効とされている。

企業で利用する場合は、個々のユーザーによる判断だけに任せず、接続を許可するアプリ、対象チャンネルやリポジトリ、読み取り・書き込み権限、承認が必要な操作を組織として定めることが望ましい。

■無料ユーザーは最大3件のスケジュール型タスクを利用可能

無料ユーザーは、最大3件のアクティブなスケジュール型タスクを作成できるようになった。タスクは1回だけ実行することも、繰り返し実行することもできるが、繰り返しの頻度は1日1回までとなる。実行時刻は正確な時刻ではなく、柔軟な時間帯で指定する。

無料プランとGoプランでは、Webhookベースのイベント駆動型タスクは作成できない。Plus、Pro、Business、Enterprise、Eduなど、対象となるプランとワークスペースで利用できる。

スケジュール型タスクの共有機能はFree、Go、Plus、Proで提供される。受け取ったユーザーは指示やスケジュールを確認、調整し、自分の接続アプリを使って独立したコピーを作成できる。Webhookベースのタスクをコピーして実行するには、受け取る側にもChatGPT Workや対応プラン、接続アプリへのアクセスが必要となる。

■Webhook対応はGmail、Slack、GitHubから開始

提供開始時点でWebhookベースのタスクに対応するのは、Gmail、Slack、GitHubである。Microsoft Outlook、Microsoft Teams、Jira、Notion、Linear、Asanaなどについては、OpenAIからWebhook対応の予定は示されていない。

対応サービスが少ないため、既存の業務システムを多数連携し、複数段階の処理を細かく制御する用途では、従来のワークフロー自動化サービスが引き続き適する場合がある。一方、受け取った文章やコードをその場で解釈し、要約や下書きを作る用途では、生成AIを直接組み込んだChatGPT Workの強みを生かせる。

■安全に使うための設定

Gmailを接続する場合は、処理対象を送信者や件名で絞り、不特定多数から届くメールを無条件に処理させないことが基本となる。接続アプリの権限は、タスクに必要な範囲に限定し、書き込みや送信が必要ない場合は読み取り中心の構成を選ぶべきだ。

Slackでは、参加者が管理されたチャンネルだけに「@ChatGPT」を追加する。GitHubでは、対象リポジトリとプルリクエストイベントを限定し、外部から投稿された内容も信頼できない入力として扱う必要がある。

OpenAIのロックダウンモードは、外部へのネットワーク要求や一部の接続機能を制限し、プロンプトインジェクションによるデータ流出の経路を減らすための高度なセキュリティ設定である。個人アカウントでは、リアルタイムのコネクターアクセスや書き込み操作などが制限されるため、Webhookタスクと同時に利用できる機能にも影響する可能性がある。

ロックダウンモードは、コンテンツ内の悪意ある指示を取り除くものではない。入力によって回答内容が影響を受ける可能性は残るが、外部へのデータ送信経路を制限することで、情報流出のリスクを抑える補助策となる。

●ChatGPT WorkをGmailと接続しても安全ですか？

安全性は、処理するメールの範囲、付与する権限、タスクの内容によって変わります。送信者や件名で対象を絞り、権限を必要最小限にしてください。不特定多数から届くメールを自動処理する場合は、間接プロンプトインジェクションを想定する必要があります。

●Webhookタスクと従来のスケジュール型タスクの違いは何ですか？

スケジュール型タスクは指定した時刻や時間帯を起点に動きます。Webhookベースのタスクは、Gmailの新着メッセージ、Slackの投稿、GitHubのプルリクエストイベントなどを起点として実行されます。OpenAIは、両方式におけるOAuth接続の内部的な維持方法までは公開していません。

●クラウドブラウザで入力したパスワードはモデルに見えますか？

OpenAIによると、安全なサインインフォームに入力したユーザー名やパスワードはモデルには表示されず、ChatGPTも保存しません。ただし、サインイン後の認証状態が将来のタスクのために残る場合があります。保存されたブラウザデータは設定画面から削除できます。

●悪意のあるメールだけで重要な操作が完了する可能性はありますか？

OpenAIは、承認が必要な操作ではタスクを一時停止し、ユーザーに確認を求めると説明しています。ただし、すべての操作について必ず確認が入ると一律に保証されているわけではありません。要約や下書きなどの出力が悪意ある指示の影響を受ける可能性もあるため、承認フローだけに依存しない設定が必要です。

●ロックダウンモードを有効にすればプロンプトインジェクションを防げますか？

完全に防ぐものではありません。ロックダウンモードは、外部へのネットワーク要求や一部の機能を制限し、データ流出経路を減らすための設定です。処理対象のコンテンツに含まれる悪意ある指示が、回答の内容や正確性に影響する可能性は残ります。

元記事: ChatGPT Work Adds Gmail Webhooks and Inbox Login: New Automation, New Attack Route