MCP タスク（非同期）：なぜエージェントは未対応か

エージェントが MCP Tasks に未対応な理由：非同期処理の壁と V2 仕様の未来

「なぜ AI エージェントは、すでに存在するはずの MCP Tasks（タスク）機能に対応していないのか？」この疑問に対する答えは、実は「エージェント側が賢いから」です。AI エンジニアリングの世界で注目されている長期実行型の非同期タスク（MCP Tasks）は、単なるチャットボットの枠を超え、複雑な業務フローを自律的に処理するインフラへと進化させる鍵となりますが、その実装にはネットワーク障害や人間との対話待ちなど、予想以上に高いハードルが存在します。

本稿では、Temporal の Cornelia Davis 氏による講演を基に、エージェントが MCP Tasks に慎重である理由、タスクの耐久性とライフサイクル管理の重要性、そして解決策となる V2 仕様の展望について解説します。

なぜエージェントは「賢く」MCP Tasks を避けるのか

MCP（Model Context Protocol）のタスク仕様は昨年 11 月に実験的（experimental）として発表されました。多くの開発者が「実験的な機能なら実装してもいいのでは？」と考えるかもしれませんが、クライアント側の開発者たちはあえて対応を見送っています。

その理由は、非同期タスクが抱える複雑性にあります。短期間のリクエスト・レスポンス型とは異なり、長期にわたって実行されるタスクでは、以下のようなインフラ上の不確実性が常に付きまといます。

「ネットワークの瞬断（blip）やサーバーダウン、そして何より人間との対話待ちなど、長期実行におけるインフラ課題がエージェントの実装を阻んでいる」

例えば、購入注文処理中にサーバーが再起動したり、承認待ちで人間の担当者が休暇に入ったりした場合、タスクは途切れてはいけません。この「どんな状況下でもタスクが生き残り、状態を維持する必要がある」という要件（耐久性）を満たす実装は、単純な API 呼び出しよりも遥かに複雑です。

タスクのライフサイクル管理と耐久性の実証

MCP Tasks の核心は、「一度起動されたタスクは消えてはならない」という仕様にあります。クライアントやサーバーが再起動しても、接続が切断されても、タスク ID は保持され、その状態（ステータス）を維持し続ける必要があります。

Cornelia 氏は、購入注文処理のデモを通じてこの仕組みを実証しました。シナリオは以下の通りです。

1. 購入注文の提出: ユーザーが注文を送信すると、即座にレスポンスが返るのではなく、「タスクハンドル」が返されます。
2. 並列処理の実行:

• 商品の受取記録
• 在庫更新や通知送信などのバックオフィス業務
• 請求書処理（MCP ツール経由）

1. 人間との対話（Human-in-the-loop）: 請求書処理プロセスでは、ERP システムとの照合後、承認が必要となるケースがあります。この時、システムは「入力待ち（input required）」状態になり、人間の判断を待機します。

デモ映像では、サーバーが停止している状態で注文を送信しても、タスクが正しくキャプチャされ、サーバー再起動後に処理が継続される様子が確認できました。また、承認ボタンを押すことで、バックエンドにシグナルが伝わり、請求書の支払いプロセスが再開・完了する流れも示されました。

この実装において重要なのは、「reject（拒否）や approve（承認）」といった信号を、長期実行中のプロセスにどう組み込むかという点です。これが非同期処理の真髄であり、MCP Tasks が持つべき機能です。

V1 仕様の限界：スケーラビリティの壁

現在の V1 仕様（2023 年 11 月版）には、実用化に向けた重大な課題が残されています。特に「task list」エンドポイントの問題が顕著です。

V1 の仕様では、サーバー上のタスク一覧を取得する際にフィルタリング機能が欠けています。つまり、クライアントはサーバーに「すべてのタスクリストをください」と要求し、その中から必要なものを探す必要があります。タスク数が数百、数千と増える大規模環境では、この非効率なデータ取得がパフォーマンスのボトルネックとなり、システム全体を重くしてしまいます。

「V1 の『task list』エンドポイントにはフィルタ機能がなく、多数のタスクを持つ環境ではパフォーマンスが低下する問題がある」

また、V1 プロトコルはステートフル（状態依存）な通信に依存しており、接続を維持し続ける必要があるため、大規模展開における管理コストも高くなる傾向があります。

近々発表される V2 仕様：通知ベースと実装の簡素化

これらの課題を解決するため、V2 仕様が今年 7 月に発表される予定です。V2 では、プロトコルが根本から見直され、以下の改善が期待されています。

• 通知ベースのスケーラビリティ: サーバー側からクライアントへ状態変化をプッシュする通知メカニズムの導入により、不要なポーリング（問い合わせ）を減らし、大量のタスクを扱う際の効率を劇的に向上させます。
• 実装の簡素化（Fast MCP）: 複雑なプロトコル処理を削減し、「Fast MCP」のような軽量ライブラリでの実装が容易になります。これにより、開発者が耐久性やライフサイクル管理の実装に費やす時間を短縮できます。

V2 の登場は、MCP Tasks が単なる実験的な機能から、エンタープライズ環境で信頼して使える標準インフラへと進化するための転換点となるでしょう。

まとめ：エージェントの自律化への道

MCP Tasks の標準化と非同期処理の確立は、AI エージェントが「チャットボット」から「複雑な業務フローを自律的に実行するインフラ」へ進化するための基盤です。V2 仕様によるスケーラビリティの改善と実装の簡素化は、大規模なエンタープライズ環境での実用化を加速させる可能性が高いと言えます。

開発者にとって今後は、V1 の課題を理解しつつ、近々登場する V2 仕様に備えたアーキテクチャ設計が求められるでしょう。非同期タスクの実装ハードルは高いですが、それを乗り越えた先にこそ、真の自律型 AI エージェントの世界が広がっています。