MCP Tasksとは？tasks/get・update・cancelと旧API移行の確認順

結論：Tasksは長い処理を待つ仕組みではなく、状態を後から取りに行く仕組み

MCP Tasks extensionは、serverが時間のかかる処理を開始したとき、最終結果が出るまで接続を占有する代わりに、durableなtask handleをclientへ返すための仕組みです。clientはtaskIdを使って状態をpollし、完了後の結果を取得します。切断や再起動が起きてもtaskIdで再開できるため、CI pipeline、batch処理、外部job、human approvalを含む長いworkflowに向きます。

重要なのは、clientがTasksを知っているだけでは足りないことです。clientはrequest単位のcapabilityでextensionへの対応を示し、serverもserver/discoverで対応を示します。両端が対応している場合でも、毎回taskになるとは限らず、taskを作るかはserverがrequestごとに判断します。

Tasksが向く5つの検索意図・実装シナリオ

• CI/CDやbatch処理：数分から数時間かかるjobを、workerとclientの接続時間から切り離す
• human-in-the-loop：承認や不足情報で停止し、input_requiredとしてclientへ戻す
• 外部job system：cloud deploymentやqueued APIが返すjob IDをMCP taskへ対応させる
• 不安定な通信：mobileやintermittent networkで切断しても、taskIdから再開する
• 大量処理：部分的な進捗、statusMessage、TTL、最終result/errorを追跡する

逆に、短い読み取り、失敗時に再実行すれば済む処理、taskの永続化や認可を管理できない小さな処理では、通常のtool callの方が単純です。Tasksを入れること自体が信頼性を保証するわけではなく、task store、worker、認証、期限、再試行の設計が必要になります。

最初に読む構成：client・server・Task Store・worker

capability negotiation：serverが勝手にtaskを返さない

Tasksの識別子は、client側のio.modelcontextprotocol/clientCapabilities.extensionsに入ります。server側はserver/discoverのcapabilities.extensionsで対応を示します。公式ガイドの要点は、clientがextensionを宣言していないときに、serverがCreateTaskResultを返さないことです。通常結果を返すか、処理に必須ならcapability errorとして扱います。

{
  "io.modelcontextprotocol/clientCapabilities": {
    "extensions": {
      "io.modelcontextprotocol/tasks": {}
    }
  }
}

実装時は、上の識別子を知っていること、capabilityをrequestへ正しく入れること、serverがserver/discoverで宣言すること、対応なしの場合のfallbackを分けてテストします。対応宣言を見ずにtask前提でpollを始めると、通常resultとの判定を誤ります。

結果はpolymorphic：通常resultとtask resultの両方を受ける

Tasks対応clientは、tools/callの結果が常にtaskになると決めつけません。serverが短いと判断したrequestでは通常のresultを返し、長いと判断したrequestではresultTypeがtaskのCreateTaskResultを返します。clientはまず結果の形を確認し、taskならtaskId、初期status、ttlMs、pollIntervalMsを保存してから次の処理へ進めます。

タスクのライフサイクル：workingからterminal statusまで

completed、failed、cancelledはterminal statusです。input_requiredではtasks/getのinputRequestsを読み、tasks/updateで回答します。tasks/cancelは取消の意思を伝える操作であり、serverが受け付けてもworkerが即時に止まるとは限りません。決済、deploy、削除など取り消せないside effectをtaskへ入れる場合は、実行前の承認、idempotency、rollback、期限を別に設計します。

旧experimental Tasks APIからの移行：名前だけ変えない

MCP 2025-11-25系で実験的に使われたTasksの機能と、2026-07-28系のTasks extensionはwire互換ではありません。旧clientが動くから新extensionも動く、またはtasksという名前が同じだから置換できる、と判断しないでください。公式のSEP-2663では、旧tasks/result、task parameter、legacy tasks.requests.*、tasks/listやcancelのcapability表現を新extensionの前提から分けています。

Task IDと入力待ちの安全設計

• taskIdを連番や推測しやすい値にせず、別ユーザーのtaskをgetできない認可を毎回確認する
• 新Tasks extensionではtasks/listによる全task列挙を前提にせず、所有者・tenant・jobの境界をTask Store側で持つ
• inputRequestsはserverから届くelicitationやsamplingの内容なので、表示・承認・自動回答を分離する
• tasks/updateで回答したあとも、同じ回答を再送してside effectが重複しないか確認する
• TTL、削除、監査ログ、失敗時のerrorを決め、taskIdやstatusMessageへ機密情報を入れない
• tasks/cancelのackだけを成功とみなさず、実際のworker停止と外部side effectの状態を確認する

client・server別の導入チェックリスト

よくある誤解

導入前の最小チェックリスト

• 長時間化する理由があり、通常の短いtool callよりTasksの再取得が役に立つ処理を選んだ
• client capabilityとserver/discoverのextension宣言を確認した
• 通常resultとCreateTaskResultを分け、taskId・TTL・pollIntervalを保存できる
• Task StoreがCreateTaskResultの返却前に状態を読めるようになっている
• working・input_required・completed・failed・cancelledを表示と監査へ反映できる
• 切断・再起動・期限切れ・二重poll・二重update・二重side effectをテストした
• 旧experimental APIのtasks/result、task parameter、tasks/listへの依存を洗い出した
• taskId、inputRequests、statusMessage、errorにsecretや個人情報を残さない設計にした

まとめ：Tasksは非同期化より、状態・権限・停止条件の明示が本体

MCP Tasks extensionは、長時間処理をtaskIdへ分け、clientが状態・途中入力・最終結果を再取得するための設計です。導入では、capability negotiation、通常resultとの分岐、Task Store、TTL、input_required、cooperative cancel、Task ID認可を一つの表で確認します。2025-11-25系のexperimental APIとは互換性がないため、read-onlyの小さな処理から旧client・新server・SDKの組み合わせを検証し、外部side effectを伴う自動化は最後に広げてください。