MCP Events:サブスクリプションが取り消せない認証情報になるとき
重要なポイント
- MCP Events はエージェントに 3 つ目の起床トリガーを追加した —— cron スケジュールと人間のメッセージに加えて、MCP サーバーは接続先アプリで変化が起きたとき、署名付き webhook を ChatGPT にプッシュできるようになった。
- サブスクリプションは、それを作成したアクセストークンより長く生きる ——
ttlMs: nullは期限のないサブスクリプションを要求し、それを識別するタプルにはトークン・スコープ・有効期限が含まれない。 - ChatGPT は webhook 配信モードをサポートするが、ドラフトの
terminated取り消しエンベロープはサポートしない —— 残された唯一の取り消しシグナルは、-32012 Forbiddenを返す失敗したリフレッシュである。 - ワーキンググループ自身の成功基準 —— SEP の提出 —— はまだ出荷されていない — チャーターの表は「Ideating」のまま、チャンピオンは「TBD」で、変更履歴は 2026 年 3 月 24 日の 1 件のみ。
- WorkOS はサブスクリプションを認証情報として位置づけている —— あるユーザーのアクセストークンの下で作成された永続的なレコードであり、トークンの期限が切れたずっと後でも、そのユーザーのデータをエージェントにプッシュすることをサーバーに許可する。
これまで、AI エージェントが起床する理由は 2 つでした:cron スケジュールの発火、または人間がメッセージを入力すること。2026 年 9 月 29 日、DevDay で OpenAI は提案中の MCP Events 仕様のサポートを追加すると発表し、接続先アプリで何かが起きたときにプラグインがオートメーションを開始できるようになりました。ドキュメントは、MCP サーバーが ChatGPT に更新をプッシュする方法を説明しています —— チャネルでフィルタされた message.created イベント、ドキュメントでフィルタされた comment.created イベント —— バグ報告が届いたときやレビューコメントが投稿されたときに、問い合わせを思い出したときではなく、エージェントが動き出します。Notion でプロダクトデザインに携わる Nathan Baschez は 10 月 3 日に投稿し、これほど興奮がないのは見たことがないと述べました:「イベント駆動トリガーは huge deal だ。」
本記事は、MCP Events が実際に実装するもの、その中心にある認証情報ライフタイムの隙間、そして本番 MCP サーバーが webhook を出荷する前に保存し検証すべきものをマッピングします。ステートレスコアを扱った MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments を土台に、ここではイベント駆動拡張と、ワーキンググループがまだ仕様化を終えていないサブスクリプションライフサイクルの問題に焦点を当てます。
ChatGPT が実際に実装しているもの
MCP Triggers and Events ワーキンググループのチャーターは、アクティブな作業項目を 1 つだけ列挙しています:「SEP: Events in MCP v1 RFC」、ステータス「Ideating」、目標日「End April」、チャンピオン「TBD」。チャーターの変更履歴は 1 件のみ、日付は 2026-03-24:「Initial charter」。ワーキンググループは AWS の Clare Liguori と Anthropic の Peter Alexander が率いています。
インキュベーションリポジトリは別の物語を語ります。そこには「Status: Draft proposal」と印付けされたデザインスケッチがあり、著者は Peter Alexander、日付は 2026-02-19 です。README は率直です:内容は探索的であり、「MCP の公式仕様や推奨を表すものではない」。実装者はすでにそれに対するフィールドレポートを提出しています。しかし、提出された SEP —— チャーター自身が定めた成功基準「トリガー/コールバックメカニズムとそのサブスクリプションライフサイクルを定義する、受諾された SEP」—— は存在しません。
ChatGPT は、この未完成の文書の一部を実装しています。OpenAI の MCP Events ガイドは MCP 2.0 とプロトコルバージョン 2026-07-28 を要求し、ドラフトの webhook 配信とコールバック検証をサポートします。ポーリング、ストリーミング、そしてドラフトの gap と terminated 制御通知はサポートされていません。最後の項目が重要です。
メカニズムは単純です。サーバーは server/discover レスポンスで events ケイパビリティを告知します。ユーザーは ChatGPT に何を監視し、どう応答するかを伝えます。ChatGPT はイベント名、フィルタ引数、コールバック URL、署名シークレットを添えて events/subscribe を呼び出します。サーバーは使い捨てのチャレンジでコールバックを検証し、サブスクリプションを保存し、一致するイベントを署名付き webhook としてプッシュします。3 つのメソッド —— events/list、events/subscribe、events/unsubscribe —— は、ツールと同じ認証済みエンドポイントで実行されます。
サブスクリプションは認証情報である
注意を要するのは、ドラフトがサーバーに保存を求めるものです。WorkOS の分析が位置づけるように、イベントサブスクリプションは認証情報です:あるユーザーのアクセストークンの下で作成された永続的なレコードであり、作成したトークンの有効期限が切れたずっと後でも、そのユーザーのデータをエージェントにプッシュすることをあなたの MCP サーバーに許可します。
サブスクリプションを、その呼び出しを許可したトークンと比較してください。2026-07-28 認証仕様の下では、サーバーはアクセストークンが自分専用に発行されたことを検証しなければならず、認可はすべての HTTP リクエストに含まれ、無効または期限切れのトークンには 401 を返さなければなりません。短命で、スコープは狭く、毎回のリクエストで再検証されます。サブスクリプションはそのどれも受け継ぎません。デザインスケッチは webhook サブスクリプションをタプル (principal, delivery.url, name, arguments) でキー付けします —— principal は認証された主体に対するサーバーの正規識別子です。タプルにはトークンそのもの、そのスコープ、有効期限は含まれません。そしてライフタイムは永遠まで交渉可能です:ttlMs: null は期限のないサブスクリプションを要求し、それを認めたサーバーは refreshBefore: null を返します。
| アクセストークン | イベントサブスクリプション | |
|---|---|---|
| ライフタイム | 短く、固定の有効期限 | あなたが認める TTL 次第、無期限(ttlMs: null)まで |
| バインド先 | あなたのサーバーをオーディエンスとし、スコープを追加 | (principal, url, name, arguments) —— トークン・スコープ・有効期限なし |
| チェック | すべての HTTP リクエストで、期限切れは 401 | 登録時に必須(MUST);以降は「定期的に」(SHOULD)、間隔の指定なし |
| 終わるのは | 期限切れ、または認可サーバーが取り消したとき | TTL の経過、クライアントによる退会、またはあなたのサーバーが終了させたとき |
アクセストークンは期限切れになります。それが作成したサブスクリプションは配信を続けます。
ChatGPT では取り消しが非対称である
ドラフトは義務については明確ですが、頻度については曖昧です。登録時には、principal の認証と認可が必要です。配信時には:「サーバーは SHOULD として定期的に権限を再検証すべきです。ユーザーのアクセスが取り消された場合(たとえば Slack チャネルから削除された場合)、」サーバーはサブスクリプションを終了します。OpenAI のガイドも同じ義務を繰り返します:「サブスクリプションのライフタイム中にユーザーのアクセスを再チェックし、アクセスが取り消されたら配信を停止すること。」
「定期的に」はこの文で多くの仕事を担っています。間隔はなく、MUST もなく、その背後に適合性試験はありません。
次にシグナルそのものです。ドラフトでは、配信モードごとに「停止」を伝える方法があります。webhook の場合は、署名付き {"type":"terminated"} エンベロープをコールバック URL に POST する方式です。その後サブスクリプションは存在しなくなるため、終了原因が残っている場合、後続のリフレッシュは -32012 Forbidden を返します。このエンベロープこそ、プロトコルがエージェントに「これは停止した、理由はこれだ」と伝える方法です。これは ChatGPT の統合がサポートしない 2 つの制御通知の 1 つでもあります。
| 配信モード | ドラフトが「停止」を伝える方法 | ChatGPT では |
|---|---|---|
| ポーリング | 次のポーリングでエラー | モード未サポート |
| プッシュストリーム | notifications/events/terminated |
モード未サポート |
| Webhook | 署名付き terminated エンベロープをコールバックへ POST |
モードはサポート、エンベロープは未サポート |
| すべてのモード | 次のリフレッシュが -32012 Forbidden で失敗 |
残された唯一のシグナル |
ChatGPT の統合では、残された唯一の取り消しシグナルは失敗したリフレッシュです。ユーザーのアクセスが取り消され、あなたのサーバーが配信を停止しても、エージェントがそれを知るのは、サブスクリプションの TTL が切れてリフレッシュが失敗したときだけです。ttlMs: null を認めていたなら、エージェントは永遠に知りません。
あなたのサーバーが検証すべきもの
ドラフトと OpenAI のガイドは、合わせて本物のセキュリティサーフェスを規定しています。交渉の余地がない部分:
- 認証済み principal を要求する。
events/subscribeとevents/unsubscribeは認証済み principal と共に呼ばれなければならず、認可に失敗した呼び出しは-32012 Forbiddenを受け取ります。 - 最初の本配信の前にエンドポイントを検証する。 HMAC は偽造を止めますが、フラッディングは止めません。エンドポイントが配信を受ける意思を持つことを確認するまでは —— チャレンジハンドシェイク、許可リスト、事前のアウトオブバンド検証のいずれかで —— サーバーはコールバック URL への配信を開始してはなりません。
- 配信時に SSRF チェックを実行する。 コールバック URL は HTTPS を使わなければなりません。接続ごとに宛先アドレスを解決して検証し、プライベートとローカルの範囲をブロックし、リダイレクトを決して追わず、そのすべてを検証リクエストにも配信と同じく適用します。
- ペイロードを最小に保つ。 イベントペイロードはツール結果と同じインジェクションリスクを持ちます。OpenAI のガイドは、要約を送り完全なレコードのための読み取りツールを公開すること、ユーザー作成テキストをデータとして扱うこと、ペイロード内にモデルの振る舞いを指示する内容を追加しないことを求めています。
- 書き込みを冪等にする。 イベントは順序不同で到着しうるため、繰り返し呼び出しが変更を複製してはなりません。配信は 256 KiB で上限、410 と 413 の応答は再試行されません。
- 受領時ではなく行動時に認可する。 イベントの受領は行動の認可を構成しません。エージェントが応答として行うツール呼び出しは、あなたの通常のチェック —— OAuth スコープを超えて MCP ツール呼び出しを見張るのと同じチェック —— を通ります。
ここまでの内容はすべて文書にあります。文書にない 2 つのこと:アクセスをどの頻度で再検証するか、そしてユーザーや管理者が自分のアカウントが何をプッシュしているかをどう確認するか。
あなた自身が決めなければならない 3 つの決定
サブスクリプションライフサイクルは、まさにワーキンググループがチャーターで仕様化を自らに課し、まだ SEP を出荷していない事項です。それまでの間、3 つの決定はあなたのものとなり、デフォルトはそこを悪く決めつけます。
第一に、短い有限 TTL を認め、ttlMs: null を拒否すること。TTL は、取り消されたサブスクリプションがクライアントに可視になる間隔です。期限のないサブスクリプションは、誰にも見えない OAuth 許可です。
第二に、一言で表せるスケジュールでアクセスを再検証すること —— 「定期的に」ではなく。「15 分ごとに再チェックしている」と言えて、それを実行するジョブを示せないなら、あなたが頼っているのは間隔も適合性試験もない SHOULD です。
第三に、ユーザーごとのサブスクリプションインデックスを維持すること。なければ、ユーザーの退職処理は、その subscriptions が死んだと仮定することを意味し、確認するのではありません。従業員が退職するとき、取り消しの問いは「トークンは期限切れか」ではなく「本人が許可したすべての webhook は停止したか」です。
MCP Events はエージェントのトリガーモデルを変えます。それが本当のアーキテクチャ変化です。しかし、最初に本番デプロイを咬むのは、認証情報ライフタイムの隙間です。プロトコルはサーバーをステートレスにしました。イベント拡張はサーバーを再びステートフルにしました —— そしてその状態が持っているのは、取り消しの頻度が未仕様の認証情報です。
次のダイアグラムは、サブスクリプションライフサイクル、認証情報ライフタイムの隙間、非対称な取り消しサーフェスをマッピングします:```svg
Related reading
- MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments — 親記事:ステートレスコアが MCP Events によりイベント駆動能力で拡張される経緯。ステートレスプロトコルがサーバーをステートレスにし、イベント拡張が再びステートフルにした理由
- MCP Security Hardening Checklist for Production Deployments — ガバナンスされたモジュールのテーゼと、イベントサブスクリプションに適用されるセキュリティ管理:SSRF、ペイロード注入、シークレットローテーション、コールバック検証
- A2A vs MCP: Choosing the Right Protocol — MCP Events が MCP にイベント駆動能力を追加することで、プロトコル比較がどう変わるか
中堅の SaaS 企業が、カスタマーサポート用の MCP サーバー —— ChatGPT をチケットシステムとナレッジベースに接続するタイプ —— を運用しており、新しい高優先度チケットが届いたときにエージェントが回答案を起草できるよう、イベント駆動トリガーを追加したいと考えています。エンジニアリングチームは events/subscribe を実装し、サブスクリプションを保存し、webhook 配信を出荷しました。3 週間後、サポート担当者が退職します。アクセストークンは 1 時間で失効しました。しかし、そのトークンの下で作成されたイベントサブスクリプションは、誰も有限の TTL を認めず、ユーザーごとのサブスクリプションインデックスが存在しないため、ChatGPT への webhook を送り続けます。統合で「これは停止した」と ChatGPT に伝えるはずだった terminated エンベロープはサポートされていません。エージェントは、退職した担当者にもはやソースシステムで見る権限のないチケットに対して動き続けます。
スコープを明確にした設計を依頼する。1 週間のディスカバリー。システムインベントリ、ワークフローマップ、固定スコープが手に入ります —— 私たちと共作するかどうかにかかわらず。
あなたのシステムのためにこれを構築したいですか？
ここの各ドキュメントは実際の本番作業から来ています。ターゲットシステムとワークフローがあれば、1週間でスコープを定義できます。
スコープ付き構築を依頼1週間のディスカバリ。システムインベントリ、ワークフローマップ、固定スコープを提供します — 私たちと構築するかどうかにかかわらず。