MCP Eventsとは？通知をきっかけにChatGPTが動く仕組みと設定条件

通知から始まる、プラグインの処理

MCP（Model Context Protocol）は、AIが外のサービスとつながるための共通の決まりです。GmailやSlack、GitHubなどとつなぐプラグインは、この仕組みを使っています。

ただ、これまでのMCPは、AIの側から聞きにいくのが基本でした。サーバーの更新を知るには、定期的に問い合わせる（ポーリング）か、つなぎっぱなしにする必要があります。

MCPの作業部会のページも、この点を課題としていて、サーバーが自分から通知する標準の仕組みを作ることを目的に掲げています。

MCP Eventsは、その「自分から通知する」仕組みです。公式ドキュメントでは、ChatGPTが、MCPサーバーからの更新（新しいメッセージ、内容の変更、状態の変化など）を購読できると説明されています。ユーザーが、何を見張り、来たらどうするかを決めます。

• 出典：OpenAI「DevDay 2026 の振り返り」（新しいタブ）

動く流れ

流れは、5つです。サーバーが、購読できる出来事を公開し、ユーザーが対応を伝えます。ChatGPTは、受け取り先のURL（コールバック）と署名用の秘密の値をサーバーに渡して購読し、出来事が起きると、サーバーが署名つきで通知します。

ChatGPTは、購読した会話のなかで、ユーザーの指示どおりに動きます。

公式ドキュメントが挙げる使い方は、2つです。

フィードバックをPRに：チャンネル #product-feedback を見張り、バグ報告が来たら、修正とテストを付けた下書きのPRを作る

書類のレビューコメントを反映：書類を見張り、レビューコメントが付いたら、頼まれた修正を実施する

作る側の条件と、注意

プラグインを作る人にとっては、いくつかの条件があります。

MCP 2.0（プロトコルのバージョン2026-07-28）が必要です

配信はWebhook（サーバーから、受け取り先のURLへ送る方式）。ポーリングとストリームには、この連携では対応していません

サーバー側には、購読の情報を保存しておく場所と、HTTPSで外へ出せる通信が必要です

出来事の一覧を返す events/list、購読を作る events/subscribe、止める events/unsubscribe の3つのメソッドを実装します

通知は署名つき（Standard Webhooks）で、1件ずつ、256KiB以内で送ります

注意点もはっきり書かれています。イベントが届く順番は入れ替わることがあるので、書き込みを行うツールは、何度呼ばれても結果が重複しないように作ります。

そして、コメントなどのユーザーが書いた文章は、あくまでデータとして扱い、通知の本文に、モデルへの指示を書かないことです。また、自動で起こした処理が、元のアプリのデータを変え、それがまた新しいイベントを生む、という堂々巡りが起きないかも確認するよう書かれています。

なお、この仕様は提案中です。MCPの作業部会は、今年3月に趣意書をまとめ、共通の仕組みの作成に取り組んでいます。

使う人の見どころ

使う人にとっての変化は、「頼んでおく」から「見張ってもらう」への移行だと思います。「毎朝、確認する」という仕事を、「新しいものが来たら、そのときに動いて」という頼み方に変えられます。

ただし、勝手に動くぶん、「来たらどうするか」の決め方が大切です。たとえば、「下書きまで作って、送らずに私に見せて」と、最初に線を引く。この考え方は、常時稼働のAI「dots」でも同じです。

dotsも、つないだサービスが対応していれば、特定の出来事（たとえばSlackへのバグ報告）をきっかけに動けます。詳しくは、dotsの記事をどうぞ。

問い合わせ通知から下書きを作る例

MCP Eventsは、アプリから届いた出来事をAIの作業のきっかけにできます。たとえば新しい問い合わせの通知に、問い合わせIDと本文を付けて送ると、AIが分類して返答の下書きを作る流れを組めます。通知するアプリと、受け取った後に行う作業の両方に対応が必要です。

再試行や接続の復旧で、同じ通知が届く可能性を考えます。同じ問い合わせIDを受けたら同じ下書きを二重に作らない、処理が失敗したら原因を記録する、といった条件を決めます。実行済みの問い合わせを判定する記録は、通知の本文とは別に用意します。

現在の仕様は通知・購読を扱うMCPの拡張案です。使える環境として、WebのWork、Cloudを選んだデスクトップのWork、dotsが説明されています。既存のMCPサーバーが、そのまま通知にも対応するとは限りません。