AIエージェント

MCPのロードマップは、ポーリング頼みでない完了通知を探る

2026/10/3

🤖 AIが執筆しています

現行の仕様は、ポーリングを既定にし、通知を任意で足す

MCPの2026年7月28日版の仕様（以下、07-28版）で長い仕事を扱うのは、Tasksという拡張である。Tasksでは、時間のかかる道具の呼び出しに対して、サーバーが最終結果の代わりにタスクの控えを返し、クライアントが後から、控えに書かれたIDで結果を受け取る³。

ポーリングに当たる操作はtasks/getである。クライアントはtasks/getで、タスクの状態をサーバーに問い合わせる。07-28版の変更点の一覧（changelog）は「作り直した拡張は、ブロックするtasks/resultメソッドを、tasks/getによる問い合わせへ置き換える」と書く⁵。tasks/resultは、結果が出るまで応答を返さない操作だった。問い合わせの間隔は、サーバーが応答のpollIntervalMsで示し、クライアントはそれに従うべきだと拡張の仕様は書く³。この間隔は仕事の途中で変わってよく、示された間隔より速く問い合わせるクライアントを、サーバーは制限してよい³。

開いた接続の上で完了を受け取る方法に当たる通知はnotifications/tasksである。拡張の仕様は、サーバーが問い合わせに応じるのに加えて、notifications/tasksで状態の更新を送ってもよいと書く³。送るかどうかはサーバーの任意である。通知はタスクの状態と最終結果を丸ごと載せるので、クライアントはtasks/getで尋ね直さずに済む³。

通知を受け取るための要求が、subscriptions/listenである。クライアントはこの要求で関心のあるタスクのIDを伝え、サーバーは応答を閉じずに、通知を順に送る³。応答を閉じずにメッセージを順に送るこの経路を、応答ストリームと呼ぶ。応答ストリームで通知を受け取ることを、仕様は購読と呼ぶ。

この通知が届くのは、完了の時点で接続が開いている場合に限る。この条件は、07-28版の仕様に書かれている。仕様は、購読が終わる場合の一つに、HTTPのタイムアウトやTCPの切断で、通知を運ぶ接続が閉じることを挙げる⁶。

接続が閉じていた間の通知を、後から受け取る仕組みも無い。changelogは、切れた応答ストリームを続きから受け直す仕組みと、メッセージの再配送を外すと書く⁵。応答ストリームが切れたときの扱いは、「壊れた応答ストリームは進行中の要求を失う。クライアントは新しい要求として出し直さなければならない」である⁵。

07-28版には、完了の通知のほかに、仕事の途中経過を伝える進捗の通知もある。進捗の通知は、処理中の要求そのものの応答ストリームに流れる⁵。Tasksのタスクには使えない³。

ロードマップは、ポーリングの費用を理由にpush配送を挙げた

ロードマップは、対象とする期間に進める作業の一つに「push配送のためのchannelとsubscription。webhookを含む」を挙げる¹。担当はTriggers & Eventsという作業部会である。ロードマップの頁は、channelとsubscriptionの中身をこの1行より詳しく書いていない。作業部会の公開リポジトリには、上流のシステムで起きた出来事をクライアントへ届ける仕組みの設計の下書きがあり、届け方をポーリング、接続の上のpush、webhookの三つに分けている⁷。リポジトリは、中身が探索段階のもので、MCPの公式の仕様でも推奨でもないと断っている⁷。下書きは、Taskの状態の変化をこの仕組みで届けるかを、まだ決まっていない問いに置いている⁷。

理由としてロードマップが書くのは、ポーリングの費用である。ポーリングの問い合わせの回数は仕事の長さを間隔で割った数になり、完了に気づくまでの遅れを減らそうと間隔を短くするほど、回数が増える。「Tasksや他のイベントを通じて非同期の仕事を扱うにつれ、高くつくクライアント側のポーリングだけに頼らずに、仕事が終わったことをサーバーがクライアントに伝える拡張が要る」と書く¹。公開記事も「この作業はサーバー起点のイベント（webhookとchannelで、クライアントを結果のポーリングに留め置かない）に及ぶ」と書く²。

webhookを含めた点については、担当の作業部会の文書がもう少し詳しく書いている。作業部会の憲章は、いまクライアントがサーバー側の更新を知る方法を「ポーリングするか、SSEの接続を開いたままにするか」とし、webhookのような呼び戻しの仕組みを定めると書く⁸。Tasksの提案が先の検討事項に挙げたwebhook型のタスク完了通知も、この作業部会が受け持つ⁸。設計の下書きは、webhookでの配送を、長い接続を保つことも頻繁なポーリングも実際的でない場合に向けたものと書く⁷。

この作業は、前の版のロードマップより優先度が上がっている。サーバー起点のイベントは3月のロードマップでは先の課題に置かれており、今回、優先領域の作業に上がったと作り手は書く²。3月の版も今回の版も同じ作り手の文書なので、この変化は作り手の計画の中での変化である。

作り手は、push配送と並ぶ同じ期間の作業として、既存の仕組みの見直しも挙げている。07-28版には、サーバーの仕事がまだ終わっていないことを伝える仕組みが、Tasks、subscriptions/listen、進捗の通知の三つある。ロードマップは、この三つが、仕事の始まりから終わりまでの状態の扱い、取消の方法、エラーの返し方を共有していないことをリスクに挙げ、組み合わせて使えるようにしたいと書く¹。三つを組み合わせて使えるかを確かめる見直しは、三つの作業部会をまたぐ作業として挙がっている²。

push配送は、まだ仕様ではない。ロードマップの頁は、この計画は確約ではなく、項目が延期されたり別の形で届いたりしうると断っている¹。

webhookを受ける側と送る側の作業は、A2Aの仕様に書かれている

webhookでの通知をすでに仕様に書いているのがA2Aである。A2Aの仕様は、公開リポジトリa2aproject/A2Aで2025年から作られている⁴。仕様書はこの通知をpush notificationと呼び、「長時間の、あるいは切断された状況のために、クライアントが提供したwebhook URLへのサーバー起点のHTTP POST要求で届ける非同期のタスク更新」と定義する⁴。webhookでは、サーバーは渡されたURLへ新しく要求を送るので、クライアントとの接続が閉じていても完了が届く。定義が切断された状況を挙げている点は、この性質と合う。

その代わりに、クライアントはそのURLで外部からの要求を受け付けるプログラムを動かし続け、届いた要求を検証する。こうした安全にかかわる作業を、A2Aの仕様の13.2節は送る側と受ける側の双方に課す。「push通知を実装するとき、webhookを呼び出す側のエージェントと、webhookを受け取る側のクライアントの双方が、安全の責任を負う」と書く⁹。

受ける側には、「提供された認証情報を使ってwebhookの真正性を検証する」ことと、受け取ったことをHTTPの2xxで応答することを必須とする⁹。届いた要求が、仕事を任せたサーバーから来たものかをクライアントが確かめる作業が、前者に当たる。

受ける側への推奨には、冪等な処理と流量制限が含まれる。同じ通知を2回受け取っても、結果が1回のときと変わらない処理を、冪等な処理という。13.2節は「重複配送が起こりうるので、通知は冪等に処理する」ことを推奨する⁹。たとえば完了の知らせが2回届いても、クライアントは結果を使う次の処理を1回だけ始める。流量制限は、一定の時間に受け付ける要求の数に上限を置くことを指し、大量のwebhookが届く場合に備える⁹。

送る側には、認証情報をwebhook要求に含めることを必須とする⁹。推奨には、「妥当なタイムアウト値（10〜30秒を推奨）」の実装と、通知先のURLの検証が含まれる⁹。URLの検証は、サーバーが意図しない宛先へ要求を送らされる攻撃（SSRF）を防ぐために行う。送る側は、失敗した配送を間隔を延ばしながら送り直すことも推奨され、失敗が続けば送るのをやめてよい⁹。仕様が約束するのは、設定した送り先ごとに少なくとも1回配送を試みるところまでである⁴。

13.2節は、どちらの側とも分けずに、設定の扱いも推奨する。通知の設定に入れる認証トークンは、秘密として扱い、定期的に更新する⁹。

これらの作業は、通知先をURLで渡す設計を選ぶ限り、送る側にも受ける側にも残る。仕様が固まっても無くならない費用である。MCPのwebhookが課す要件を、ロードマップは書いていない。作業部会の下書きは、署名の方式にStandard Webhooksを使い、署名の秘密をクライアントが必ず渡す形を描いている⁷。push配送が仕様になるまでは、07-28版のtasks/getによる問い合わせを既定にし、サーバーが対応していればnotifications/tasksで完了を受け、購読は接続が閉じれば終わるのでtasks/getで尋ねる経路を残す形になる³。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。