MCP Tasksとは？時間のかかるツール処理を非同期で扱う仕組み

MCP Tasksとは？時間のかかるツール処理を非同期で扱う仕組み

基本は「受け付けた」という応答と「完成した結果」を分けることです。資料分析を依頼したAIアプリは、タスクの情報を手元に残し、必要なタイミングで状態や結果を確認できます。

MCP Tasksが解決する長時間処理の待ち合わせ

通常のツール呼び出しでは、依頼した処理に対する結果が応答として返ります。短い検索や計算なら、この形で十分です。一方、大量の資料を読み込み、集計し、レポートへまとめる処理では、最終結果を待つ間にも「今どうなっているか」を確認したくなります。

Tasksを使うと、実行側はまず処理を追跡するための情報を返せます。依頼側はそこに含まれるtaskIdという識別子を使い、同じ処理の状態を照会します。最初の要求の応答を完成まで待ち続ける形から、受付、追跡、結果取得を分けた形へ変わるわけです。

ここでいう非同期とは、依頼への受付応答と実際の処理完了が別のタイミングになることです。実行側では分析が続き、依頼側のアプリは別の質問への対応などを進められます。ただし、そのように画面やエージェントを動かすには、アプリ側もタスクを記録して扱える必要があります。

通常のMCPでも、実装によって複数の要求を並行して扱えます。Tasksが加える価値は、単に並列に動かすことではなく、処理の開始から終了までを共通の方法で追跡できる点です。分析の計算量や外部サービスの待ち時間が、自動的に減るわけではありません。

また、2026-07-28版では、TasksはMCPのcoreにあったexperimental機能から拡張仕様へ移行しています。MCP対応というだけで利用可能とは限りません。依頼側と実行側が、同じ版のTasks拡張に対応していることが前提になります。

タスクの開始から結果取得までの流れ

例として、AIアプリがMCPサーバーへ「大量の資料から月次の分析レポートを作成する」と依頼する場面を考えます。この例では、AIアプリ側のMCPクライアントが依頼側、レポート作成ツールを提供するサーバーが実行側です。

1. 処理を開始する：対応しているツールへ、対象資料や集計条件を渡し、タスクとして実行する要求を送ります。
2. タスク情報を受け取る：実行側から返されたtaskIdや状態などを、元の依頼と結び付けて保存します。この時点でレポートが完成しているとは限りません。
3. 状態を確認する：taskIdを指定してtasks/getを呼び、実行中か、入力待ちか、終了したかを調べます。
4. 最終結果を取得する：完了を確認したら、tasks/resultで元の要求に対応する最終結果を受け取ります。

tasks/getは状態の照会、tasks/resultは最終結果の取得という区別が重要です。状態の応答に「完了」と書かれていても、それ自体がレポート本文とは限りません。結果の形式は元のツールに依存し、本文や成果物への参照などを受け取る形が考えられます。

一定間隔で状態を問い合わせる方法をポーリングと呼びます。タスク情報に照会間隔の目安が示されている場合は、それを踏まえて問い合わせます。数分かかる処理に対して極端に短い間隔で照会しても、完成が早まるわけではなく、通信やサーバーの負担が増えます。

状態の変化を知らせる通知を利用できる場合もあります。通知は画面更新のきっかけになりますが、通知を受け取ることと、必要な時点の状態を照会することは別です。対応状況や接続条件を確認し、通知が届かないだけで処理の失敗を判断しない設計が必要です。

なお、「実行中」という状態と「全体の何％が終わったか」という進捗は異なります。資料ごとに分析時間が違う処理では、正確な完了割合を計算できないこともあります。Tasksを使えば必ず進捗率や完了予定時刻が得られる、という意味ではありません。

状態遷移で見る実行中・完了・失敗・キャンセル

タスクの状態は、依頼側が次の行動を決めるための手掛かりです。処理がまだ続く可能性のある状態と、そのタスクの実行が終了した状態を分けて理解すると、待機、入力、結果取得の判断がしやすくなります。

分析が順調に進めば、実行中から完了へ移ります。途中で対象資料の指定が足りないと分かった場合は、入力待ちになり、必要な情報を受け取った後に処理が続く流れが考えられます。一方、継続できない問題が起きれば失敗、取消が成立すればキャンセルとなります。

input_requiredは、入力を待っているという状態を示します。質問をどう表示するか、入力をどの仕組みで集めるかまでを、この状態名が決めるわけではありません。入力を求める仕組みと、タスクの状態管理を連携させて扱います。

キャンセルにはtasks/cancelを使いますが、キャンセル要求を送ったことと、キャンセルされたと確認できたことは別です。送信後に通信が途切れた場合などは、返された情報や状態照会で結果を確認します。処理が先に完了する可能性も考慮します。

また、タスクの状態と、ツールの結果に含まれるエラー情報も区別します。終了したかどうかだけでは、レポートの内容が目的を満たしたかまでは分かりません。終端状態に応じて結果やエラーを確認し、「完了と表示されたから、集計内容もすべて正しい」とは判断しないことが大切です。

通常の呼び出し・進捗通知・MCP Appsとの違い

Tasksの役割は、他の機能と比べると明確になります。選ぶ基準は、単に応答を待ちたいのか、途中経過を知りたいのか、それとも処理を識別子で継続的に管理したいのかです。

例えば「資料を読み込み中」という進捗通知が届けば、作業の途中経過が分かります。しかし、その通知だけで、後から識別子を指定して完成したレポートを取り出せるわけではありません。文章が少しずつ届くストリーミングも同様で、配信とタスクの保存・管理は別の役割です。

MCP Appsは画面、Elicitationは入力要求、Tasksは実行状態の管理を担います。分析画面でタスクの状態を表示し、対象期間が不足していれば入力を求める、といった併用は可能です。Tasksを導入しただけで、その操作画面や入力フォームまで用意されるわけではありません。

ジョブキューとの違いも押さえましょう。ジョブキューは実行待ちの仕事を並べ、担当する処理へ渡すための実行基盤です。Tasksは、その仕事をMCP越しにどう追跡するかを扱います。内部でキューを使う設計はできますが、Tasksの採用だけで、永続保存、時刻を指定した実行、自動再試行まで一括で実現するわけではありません。

分析レポートの作成例と向いている用途

利用場面を、利用者の操作に沿って整理します。担当者が複数部署の資料と対象月を指定し、レポート作成を開始します。アプリは返されたtaskIdを依頼内容と一緒に保存し、「作成中」と表示します。担当者は完成を待つ間に、別の資料を整理できます。

アプリは保存した識別子で状態を確認します。入力待ちになった場合は、例えば集計対象に含める部門など、求められている条件を補います。完了したら最終結果を取得し、対象期間や集計条件が依頼に合っていることを確かめたうえで、レポートを利用者へ渡します。

失敗した場合は、理由を確認して次の対応を決めます。資料へのアクセス権が不足しているなら権限や対象を見直し、一時的な障害なら再実行を検討します。どの状態でも、元の依頼とtaskIdの対応が残っていれば、どのレポートについて確認しているかを判断できます。

注意したいのは、応答が見えないだけで同じ作成依頼を送り直すことです。実行側では最初の処理が始まっている可能性があります。状態確認と新しい処理の開始を区別することで、重複したレポート作成や余計な費用の発生を抑えられます。

向いているのは、大量データの分析、多数の資料を使ったレポート生成、時間のかかる変換や生成など、完了時刻を読みづらく、途中からも追跡したい用途です。一方、短時間で答えが返る単純な照会では、通常のツール呼び出しを基本に考えられます。待ち時間の長さだけでなく、識別子の保存や状態管理を追加する手間に見合うかで選びます。

導入前に確認する対応状況と運用上の注意

導入時は、まず仕様と実装の組み合わせを確認します。本記事の対象は2026-07-28版のTasks拡張です。Tasksの拡張仕様と同版のリリース候補に関する説明を起点に、拡張の識別方法、能力宣言、対象となる要求を確認します。使用するSDKについても、拡張への対応範囲を調べる必要があります。

旧core仕様の説明やコードを、新しい拡張の実装へそのまま当てはめないようにします。クライアントとサーバーの双方が対応していても、すべてのツールがタスク実行を受け付けるとは限りません。対象のツールで利用できることまで確認して、開始方法を決めます。

次に、タスク情報と結果の保存期間を確認します。後から取り出せる仕組みでも、無期限に残るとは限りません。完了後いつまで取得できるのか、保存期間が切れた場合にどう扱われるのかを確認し、必要な成果物は期限内に保存する設計にします。

通信のタイムアウト、タスク情報の保存期限、処理自体の失敗は、それぞれ別の出来事です。照会への応答が時間内に届かなかっただけで、分析処理も失敗したとは断定できません。また、情報を取得できなくなった原因が保存期限なら、それだけで元の処理結果を判断することはできません。

再接続後に同じtaskIdを使える条件も重要です。認証やセッションが変わった場合の扱い、サーバー再起動後も情報が残るか、実行中の処理を引き継げるかを確認します。非同期であることだけでは、切断や再起動を越えた処理の継続は保証されません。保存方式と実行基盤を含めて設計します。

認可では、taskIdを知っているだけで他の利用者の状態や結果へアクセスできないようにします。タスクを利用者や組織と結び付け、状態照会、結果取得、キャンセルのそれぞれで権限を確認します。レポートに機密情報が含まれる場合は、結果の保存先やログに残す内容も管理対象になります。

運用負荷を抑えるためには、同時実行数と照会頻度に上限を設けます。少数の利用者では問題がなくても、多数のアプリが短い間隔で照会すれば負荷が増えます。処理の所要時間に応じた照会間隔や、利用者ごとの実行数を考えておきます。

最後に、再試行と取消の扱いを決めます。再送しても同じ業務処理を重ねて実行しないための仕組みや、元の依頼を特定する記録が必要です。キャンセルが成立しても、すでに行ったファイル保存や外部サービスへの書き込みまで戻るとは限りません。Tasksを処理の受付・追跡・結果取得に使い、重複防止や副作用の管理は実行側と合わせて整えることが、安定した運用につながります。

更新履歴