ChatGPTのプラグインが「自分で動き出す」と聞いて、社内からはこんな声が出ているのではないでしょうか。
「新しい問い合わせが来たら、AIが勝手に下書きまで作ってくれるなら助かります。でも、勝手に送られたら困るんですよね」
「便利そうなのは分かります。ただ、誰の権限で動いているのか、あとから追えるのかが心配です」
「担当者が辞めたあとも、その人が仕掛けた自動処理が動き続けたりしませんか」
結論を先に言います
ChatGPTのMCP Eventsとは、MCPサーバー側で起きた新着メッセージや内容の更新をChatGPTが購読し、届いたときにユーザーが決めておいた指示どおりに動き出す仕組みです。業務では「読む・まとめる・下書きを作る」までを任せ、「送る・確定する」は人が押す形が扱いやすいかなと思います。
そして、ここが一番大事なところなのですが、購読は「作った人の権限で動き続ける合鍵」に近いものです。退職や異動のときに止める手順を決めずに広げると、あとから困ります。
この記事で持ち帰れること
- MCP Eventsで、ChatGPTのプラグインの何が変わったのか
- 公式ドキュメントに書かれている、使える場所と技術的な条件
- 業務で任せやすいことと、人が押すべきこと
- 購読が「資格情報」として扱われるべき理由と、退職者の論点
- 仕様がまだ固まっていない部分と、いま全面依存しない理由
MCP Eventsで何が変わったのか
TechCrunchの記事によれば、ChatGPTのプラグインはこれまでも、Slack・SharePoint・Airtable・Google Driveといった普段使いのツールにChatGPTをつなぐものでした。MCP Eventsで、つながったアプリでの変化をきっかけに動き出せるようになります。
OpenAIの開発者向けドキュメント「MCP Events」（https://developers.openai.com/plugins/build/mcp-events）には、MCP Events lets ChatGPT subscribe to updates from your MCP server, such as new messages, content updates, or status changes. と書かれています。続けて Users choose what to monitor and what ChatGPT should do when an update arrives. とあり、何を見張るか、届いたら何をするかはユーザーが決めます。
同じページには、使い方の例として2つが載っています。1つは #product-feedback チャンネルを見張ってバグ報告からドラフトのプルリクエストを作る例、もう1つは文書へのレビューコメントを見張って修正を反映する例です。
発表の場は9月29日のDevDayでした。TechCrunchの記事（https://techcrunch.com/2026/09/29/openai-expands-chatgpts-plugins-with-app-like-interfaces-and-automations/）は、OpenAIが「proposed MCP Events specification」への対応を加え、つながったアプリでの出来事をきっかけにプラグインが自動処理を始められるようになる、と伝えています。
同じ発表では、プラグインの見た目側も広がっています。OpenAIの「Plugin Extensions」（https://developers.openai.com/plugins/build/extensions）によると、サイドバーから全画面で開くアプリ、会話の横に開くパネル、ファイルの表示と編集、構造化された入力フォームなどを、プラグインに組み込めるようになりました。ただし Plugin extensions on the web are coming soon to ChatGPT Free and Go users. とあり、FreeとGoのWeb版は「近日対応」の段階です。また Composer mentions are available only in the ChatGPT desktop app. と、入力欄からのメンションはデスクトップアプリだけです。
公式ドキュメントに書かれている条件
MCP Eventsは、どこでも使えるわけではありません。公式ドキュメントに書かれている条件を表にまとめます。
| 確認する項目 | 公式ドキュメント「MCP Events」の記載 |
|---|---|
| 使える場所 | ChatGPT Web版のWorkチャット、デスクトップアプリでCloudを選んだWorkチャット、dots |
| 管理者側の制御 | プラグインとイベント起点のタスクには、ワークスペースの制御が適用される |
| 必要なプロトコル | MCP 2.0（プロトコルバージョン 2026-07-28） |
| サーバー側に必要なもの | 購読を保存し続ける仕組みと、コールバックURLへの外向きHTTPS通信 |
| 配送の方式 | ドラフト仕様のうち、Webhookでの配送とコールバックの検証に対応。ポーリング・ストリーミング・gap/terminatedの制御通知には非対応 |
| 1件あたりの上限 | 1リクエストに1イベント、本文は256 KiB（262,144バイト）まで |
| コールバック先 | HTTPS必須。非公開・ローカルのアドレスはブロックし、リダイレクトは追わない |
| 署名 | Standard WebhooksのHMAC署名で検証する |
流れは5段階です。サーバーが対応しているイベントを示し、ユーザーが見張る対象と動き方を伝え、ChatGPTがコールバックURLと署名用のシークレットを渡して購読し、サーバーが該当するイベントをそのURLへ送り、ChatGPTが購読したチャットで指示どおりに動く、という順番です。
実装の注意として、届いたイベントの順番が前後することがあるので、書き込み系のツールは同じ呼び出しが重なっても変更が二重にならないように作る、と書かれています。大きなデータは要約だけを送り、全文は読み取り用のツールで取りに行く形も勧められています。コメントのような利用者が書いた文章はデータとして扱い、モデルへの指示をイベントの中に入れない、という注意もあります。
部署別の使いどころ（ここからは弊社の考え）
ここは公式ドキュメントの記載ではなく、弊社が業務に当てはめたときの考えです。共通しているのは、AIに任せるのは「読む・まとめる・下書きを作る」までにして、外に出る操作は人が押す、という線の引き方です。
| 部署・業種 | 見張る変化の例 | AIに任せること | 人が押すこと |
|---|---|---|---|
| 営業 | 問い合わせフォームの新着、商談メモの更新 | 相手の会社情報を調べ、返信の下書きを作る | 送信、見積金額の確定 |
| カスタマーサポート | チャットやチケットの新着 | 過去の対応履歴から回答案を作り、分類する | 返信、返金や例外の判断 |
| 開発・情報システム | 不具合報告、監視アラート | 関連ログを読み、原因の候補と修正案をまとめる | 本番への反映、利用者への告知 |
| 経理・総務 | 申請や請求書の受け取り | 不足項目を洗い出し、差し戻し文の下書きを作る | 承認、支払い |
| 店舗・サービス業 | 予約の変更、口コミの投稿 | 変更点の要約と、返信文の候補を作る | 公開、顧客への連絡 |
表の右端の列を人が押すのは、AIの精度の問題だけではありません。次の節で書くとおり、イベントで動き出す仕組みには「誰の権限で動いているのか」という別の論点があるからです。
任せる前に決めること：購読は資格情報と同じ
公式ドキュメントは、購読を受け付ける前に、ユーザーがそのイベントと条件に対して権限を持っているかを確認するよう求めています。そのうえで、購読の持ち主、絞り込み条件、コールバックURL、署名シークレット、有効期限を保存するよう書いています。さらに Recheck the user's access during the subscription's lifetime and stop delivery if access is revoked. とあり、購読の有効期間中もユーザーの権限を確認し直し、権限が外れたら配送を止めるのはサーバー側の責任です。
この点を掘り下げているのが、認証基盤を提供するWorkOSの記事「MCP Events in ChatGPT: Why an event subscription is a credential」（https://workos.com/blog/mcp-events-chatgpt-subscription-revocation）です。記事は、購読を「あるユーザーのアクセストークンで作られ、そのトークンが切れたあとも、そのユーザーのデータをエージェントへ送ることを許す持続的な記録」と説明し、購読は資格情報（credential）だと述べています。
記事によれば、ドラフトの設計資料は配送時の権限の再確認を「定期的に行うべき（SHOULD）」としていますが、間隔は決めていません。また、ChatGPTはドラフトにある terminated の通知に対応していないため、サーバー側で購読を止めても、ChatGPTが気づくのは次の更新（refresh）が失敗したときになります。記事はここから、サーバーが与える有効期限（TTL）がそのまま取り消しまでの猶予になる、と指摘しています。
記事の具体例はこうです。月曜の朝に退職者の権限を外しても、購読の有効期限が24時間なら、ChatGPT側が知るのは火曜の朝です。サーバーが購読時にしか権限を確認していなければ、その間の更新がコールバック先へ送られ続けます。
記事が勧めている対策は3つです。
- 有効期限は短く有限にし、期限なし（
ttlMs: null）の購読は断る - 権限の再確認を「定期的に」ではなく、言い切れる間隔で回す（記事のコード例は15分ごと）
- ユーザー単位で購読を引ける索引を持ち、退職・異動の処理から全部止められるようにする
仕様がまだ固まっていない部分
もう1つ知っておきたいのは、MCP側のイベント仕様がまだ正式に決まっていないことです。
MCPの公式サイトにある「Triggers and Events Working Group」の設立趣意書（https://modelcontextprotocol.io/community/working-groups/triggers-events）は、このグループの目的を、MCPサーバーが状態の変化をクライアントへ自分から通知する方法を定めることだとしています。今はクライアントがポーリングするか、SSEの接続を開いたままにして更新を知る、と書かれています。
同じページの作業項目では、「SEP: Events in MCP v1 RFC」の状態が Ideating、目標時期が End April、担当が TBD のままです。変更履歴は2026年3月24日の設立の1件だけです。OpenAIの公式ドキュメント自体も、対応しているのは「draft MCP Events specification」からのWebhook配送とコールバック検証だと書いています。
WorkOSの記事も、ChatGPTはこの未完成の設計資料の一部を実装している、と書いています。
CodeClimbの見解
ここまでは出典に書かれていることを並べました。ここからは弊社の解釈と経験で、出典のある事実とは分けて書きます。
正直、この話を読んで最初に思い浮かんだのは、Google Apps Scriptのインストール型トリガーでした。GASのトリガーも、作った人のアカウントで動き続けます。担当者が異動したあとに「誰も中身を知らない自動処理が毎朝動いている」という状態は、中小企業の現場でよく見かけます。この構造はGASの限界と業務システムへの線引きでも書きましたが、MCP Eventsの購読も同じ形をしているかなと思います。違うのは、届いた先にいるのが「決めた指示どおりに動くAI」だという点です。
なので、弊社が導入を手伝うなら、次の順番で進めます。
- 最初は「読む・まとめる・下書きを作る」だけに絞る。送信や確定のツールはつながない
- 購読を作るアカウントを個人ではなく、業務用のアカウントに寄せられるかを先に確認する
- 退職・異動の手順書に「AIの購読を止める」行を1行足す
- 自社でMCPサーバーを作る場合は、有効期限を短くし、権限の再確認を決まった間隔で回す
弊社自身も、営業のアプローチ文づくりは「調査から文面までAIが用意し、人が確認して送る」形にしています。以前は朝2時間で15件だったのが、確認して送るだけで30分弱になりました。送る操作を人に残しても、時間はちゃんと減ります。全部を自動にしなくても、効果は出るということです。
もう1つ、仕様がワーキンググループの段階である以上、いまの時点で基幹業務を全面的に乗せるのは早いと考えています。仕様が変われば、サーバー側の作り直しが要る可能性もあるからです。社内で「便利そうだから」と広がる前に、管理者側のワークスペース制御でどこまで絞れるかを確認しておくほうが、あとで止めるより楽です。社内AIエージェントの選び方は社内AIエージェントは契約済みツールで作れる・3社比較、Gemini側でMCPにつなぐ話はGemini外部ツール連携の使い方と制限にまとめています。
よくある質問
Q. MCP EventsはChatGPTのどの画面で使えますか
OpenAIの公式ドキュメント「MCP Events」が使える場所として挙げているのは、ChatGPT Web版のWorkチャット、デスクトップアプリでCloudを選んだWorkチャット、そしてdotsです。同じページのテスト手順も、Web版でWorkチャットを始めるか、デスクトップアプリでWorkとCloudを選んでから、ChatGPTにイベントの購読を頼む流れで書かれています。dotsでも試せるとあります。
Q. イベントの中身に「この指示に従え」と書かれていたら、ChatGPTは従ってしまいますか
公式ドキュメントは、コメントのような利用者が書いた文章をデータとして扱い、イベントの中にモデルの振る舞いを指示する文を入れないよう、サーバーの作り手に求めています。WorkOSの記事も、イベントの中身はツールの結果と同じく指示の混入（インジェクション）のリスクを持つと書いています。外部の人が書ける場所を見張る場合は、とくに送信系のツールをつながない設計が安全です。
Q. 購読を止めたいときは、どうすればいいですか
公式ドキュメントでは、ChatGPTで見張るのをやめると、サーバー側で events/unsubscribe が処理されて配送が止まる流れになっています。ただしWorkOSの記事が指摘するとおり、サーバー側から止めた場合にChatGPTが気づくのは次の更新が失敗したときです。両側で止まったことを確認する手順を用意しておくと安心です。
まとめ
MCP Eventsで、ChatGPTのプラグインは、つながったアプリでの変化をきっかけに動き出せるようになりました。使える場所はWorkチャットとdotsで、MCP 2.0とWebhookでの配送が前提です。
一方で、購読は作った人の権限で動き続ける資格情報に近く、権限の再確認の間隔は仕様で決まっていません。まずは「読む・まとめる・下書き」までを任せ、送る・確定するは人が押す。そして止める手順を先に決める。この順番で始めるのがいいかなと思います。
「来たら動くAI」の線引きを、一緒に決めませんか
CodeClimbは、AIツールを売る側ではなく、業務に組み込む仕組みを作る側の会社です。どの業務をAIに任せ、どこを人が押すのか、退職や異動のときにどう止めるのかまで含めて設計します。
「何から任せればいいか分からない」という段階からでも構いません。AI導入支援のサービス内容をご覧いただいたうえで、お問い合わせから今の状況をお聞かせください。
出典
https://developers.openai.com/plugins/build/mcp-events ｜ OpenAI Developers ｜ 参照 2026-10-03
https://developers.openai.com/plugins/build/extensions ｜ OpenAI Developers ｜ 参照 2026-10-03
https://modelcontextprotocol.io/community/working-groups/triggers-events ｜ Model Context Protocol ｜ 2026年3月
https://workos.com/blog/mcp-events-chatgpt-subscription-revocation ｜ WorkOS ｜ 2026年10月
https://techcrunch.com/2026/09/29/openai-expands-chatgpts-plugins-with-app-like-interfaces-and-automations/ ｜ TechCrunch ｜ 2026年9月
