Claude Code MCP Tasks：バックグラウンド実行と入力要求

Claude CodeでMCP Tasksを使うには、Tasksに対応したMCPサーバーを用意し、v2.1.304以降のターミナルCLIのメイン会話からツールを呼び出してください。サーバーが処理を引き受けるとClaudeは別の作業を続けられ、処理が終わった時点で結果を受け取れます。サーバーを変更する前に適用条件を確認しましょう。通常のツール呼び出しが2分後にバックグラウンドへ移る動作は、別の仕組みです。

2026-10-24時点で、Claude CodeのドキュメントではMCP Tasksはパブリックベータとされています。ここでは、現行の2026-07-28プロトコルと、呼び出しがMCP Taskとして扱われるための条件を説明します。

TasksとElicitationの役割

Tasksは、ビルド、テスト実行、エクスポート、調査など、サーバーが独立して受け付け、進行状況を管理できる長時間の処理に使います。Elicitationは、処理を進めるためにユーザーの判断や不足している情報を求める機能です。

画面上では似て見えることがあるため、次の3つを区別してください。

仕組み	動作	サーバー側に必要な実装
通常のMCP呼び出し	Claudeはツールの結果を待ちます。	通常のツール実装。
自動バックグラウンド化	メイン会話からの呼び出しが2分経っても実行中の場合、バックグラウンドへ移ります。結果は後から届きますが、セッションを終了すると、このバックグラウンド呼び出しは維持されません。	Tasksへの対応は不要です。
MCP Task	サーバーは処理を引き受けた時点で、タスクを識別・追跡するためのハンドルを返します。Claude Codeはそのハンドルを使って状態を追跡し、結果を取得します。リモートサーバー上の処理はCLIの終了後も続行できます。	Tasks拡張と、タスクの状態を永続的に管理する実装。

ElicitationはTasksとは別の機能です。たとえばレポート作成ツールは、どの環境を照会するかをユーザーに確認してから、エクスポートをTaskとして実行できます。短時間で終わるツールも、Taskを作成せずに同じ確認を行えます。

Elicitationは今回の提供開始より前から存在します。Claude Code v2.1.76のリリースで、入力要求のダイアログとElicitation、ElicitationResultフックが導入されました。今回の新しい機能は、サーバーが管理するTasksです。

呼び出しがMCP Taskになる条件を確認する

公式の適用条件は、すべて満たす必要があります。CLIを新しくするだけでは、次の表の最初の条件しか満たせません。

確認項目	必要な条件
Claude Codeのバージョン	`v2.1.304`以降であること。
サーバーの実装	サーバーがTasks拡張に対応していること。MCP接続ができるだけでは、Tasksへの対応は確認できません。
トランスポートとプロトコル	HTTP、stdio、またはclaude.aiコネクタのサーバーに、プロトコルリビジョン`2026-07-28`で接続していること。
旧プロトコルを強制する設定	`MCP_SDK_GENERATION=v1`や`MCP_PROTOCOL_NEGOTIATION=legacy`によって、古いプロトコルに固定されていないこと。
機能の提供条件	セッションが機能フラグを取得し、Anthropicがそのセッション種別でTasksを有効にしていること。
対応する実行環境	ターミナルCLI、Agent SDK、またはGitHub Actions。VS Code拡張とデスクトップアプリは、現時点ではMCP Tasksに対応していません。
呼び出し元	メイン会話からの呼び出しであること。サブエージェントからの呼び出しはMCP Taskになりません。
入力モード	対話型セッション、または後述の条件を満たすAgent SDKやストリーミング入力のセッションであること。

非対話型で利用する場合、Agent SDKのセッション、または--input-format stream-jsonを使うclaude -pの実行では、さらに次の条件が必要です。

CLAUDE_AUTO_BACKGROUND_TASKS=1
CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUNDが1ではないこと
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSが0ではないこと

入力ストリームは開いたままにしてください。入力を閉じると、実行プロセスはMCP Tasksの完了を待ちません。単発のclaude -p "..."ではTasksを利用できません。GitHub Actionsが対応環境に含まれていても、これらの入力モードの条件は必要です。

環境変数リファレンスには、機能フラグの取得を妨げる設定が記載されています。

DISABLE_GROWTHBOOK=1またはtrue
DO_NOT_TRACK=1
空でない値が設定されたDISABLE_TELEMETRY
空でない値が設定されたCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

最後の2つは、値が0やfalseでも該当する動作を無効にします。Amazon Bedrockなど、通常のサードパーティプロバイダーのセッションも機能フラグを取得しません。ただし、ホスト側が管理する組み込み利用については、リファレンスに例外が記載されています。

起動時の環境変数と、実際に適用されている設定の両方を確認してください。一般的な設定ファイルは~/.claude/settings.json、.claude/settings.json、.claude/settings.local.jsonで、管理設定も確認対象です。それぞれの適用範囲は設定リファレンスに説明があります。

旧プロトコルを強制する設定を削除しても、新しいプロトコルに対応していないサーバーを更新できるわけではありません。同様に、ゲートウェイ経由でAPI互換性があっても、機能フラグの取得条件を満たすとは限りません。運用上、Tasksを妨げる設定を残す必要がある場合は、通常のツール呼び出しを使ってください。

対話型セッションでは、CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=0を設定するとClaudeは完了を待ちます。CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND=1もTasksの完了を待たせますが、その後、通常の自動バックグラウンド化によって長い呼び出しが移動する場合があります。CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1だけでは、MCP Tasksをフォアグラウンドに留めることはできません。

まず1つの処理を実行し、結果を確認する

認証が済み、ドキュメントまたは実装からTasksへの対応を確認できるサーバーを使って、破壊的な変更を伴わない処理を1つ試してください。Bashでインストール済みのバージョンと設定されたサーバーを確認してから、対話型CLIを起動します。

claude --version
claude mcp list
claude

自己更新に対応するインストール方法を使っていて、必要なバージョンに達していない場合は、claude updateを実行して再確認してください。これらのコマンドはCLIリファレンスで確認できます。

Claude Code内で/mcpを使い、サーバーが接続されていることを確認し、必要な認証を完了させます。テスト実行ツールが接続済みなら、たとえば次のように依頼できます。

メイン会話からMCPツールを使って、このリポジトリのテストスイートを実行してください。実行中はREADMEを参照してテストの構成を説明してください。処理が終わったら、結果と失敗したテストを報告してください。

動作は2つの側面から確認します。

Claude Code側： MCPタスク数の表示を確認し、/tasksを開きます。通常のバックグラウンド呼び出しも表示されるため、/tasksに項目があるだけではMCP Taskと判断できません。
サーバーのトレース： tools/callがresultType: "task"を返し、その後のtasks/getリクエストが同じtaskIdを参照していることを確認します。

処理が終わるとClaude Codeが結果を受け取るので、Claudeに報告を依頼してください。Claudeが待機中なら、自動的に結果を取り上げることもあります。通常の呼び出しのままであれば、ツールを書き直す前に、実際のリクエストが宣言している機能と適用条件を確認します。

サーバー実装：ハンドルを返し、最終結果を届ける

古い実験的なサンプルをコピーせず、現行のTasks拡張を実装してください。MCP 2026-07-28の変更では、tasks/resultがtasks/getによるポーリングに置き換わり、tasks/updateが追加され、tasks/listが削除されました。

リクエストが対応を宣言している場合だけTaskを返す

リクエストごとに、次の場所でTasksへの対応が宣言されているかを確認してください。

params._meta["io.modelcontextprotocol/clientCapabilities"].extensions["io.modelcontextprotocol/tasks"]

値は{}です。サーバー側は、server/discoverの応答内のcapabilities.extensionsで同じ拡張への対応を宣言します。両方の場所はTasks拡張の概要に記載されています。

クライアントが対応を宣言している場合、その操作をTaskにするかどうかはサーバーが決めます。宣言がない場合は、可能であれば通常の結果を返してください。Tasksが必須の操作については、拡張で機能不足を示すエラー-32021が定義されています。対応していない呼び出し元にタスクハンドルを返してはいけません。

応答を返す前にタスクを永続化し、そのIDをtasks/getですでに参照できる状態にしてください。接続が変わっても同じIDへの問い合わせに応答できるようにし、後続のリクエストでも認証とタスクへのアクセス権を確認します。

次のJSON-RPC応答は、ビルドを受け付けた場合の例です。ID、タイムスタンプ、後述の結果はいずれも説明用で、実行ログではありません。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "taskId": "6f17bfa2-4c5e-4d21-b563-2f7e83a902bc",
    "status": "working",
    "createdAt": "2026-10-24T08:00:00Z",
    "lastUpdatedAt": "2026-10-24T08:00:00Z",
    "ttlMs": 3600000,
    "pollIntervalMs": 5000
  }
}

タスクのフィールドは、JSON-RPCのresultの直下に配置します。追加のtaskオブジェクトで囲まず、最初に返すハンドルにcontent配列を含める必要もありません。

フィールド	要件
`resultType`	最初のタスク応答では`"task"`を指定します。
`taskId`	必須。サーバーが生成し、推測されにくい値にします。Claude Codeではさらに、空白を含まない印字可能なASCII文字で128文字以内という制限があります。
`status`	必須。`working`、`input_required`、`completed`、`failed`、`cancelled`のいずれかです。
`createdAt`、`lastUpdatedAt`	必須。ISO 8601形式のタイムスタンプ文字列です。
`ttlMs`	必須。作成時からの保持期間を整数のミリ秒で指定するか、無期限の保持には`null`を指定します。処理時間の見積もりではありません。
`pollIntervalMs`	任意。ポーリング間隔を整数のミリ秒で指定します。`null`は送らないでください。
`statusMessage`	任意。進捗や状態を説明するテキストです。

構造は公開済みの拡張スキーマで定義されています。Claude Code固有の検証条件はサーバー実装者向けリファレンスに記載されています。

ClaudeがUnsupported result type 'task' for tools/callを報告した場合は、まず受信したリクエストに拡張の宣言が含まれていたかを確認し、その後、taskId、status、createdAt、lastUpdatedAt、ttlMsの欠落がないかを確認してください。statusに未対応の値を指定した場合も同じエラーになります。タスクIDが不正な場合は、これとは別に、タスクハンドルの形式が不正であることを示すエラーになります。

完了したツールの結果を`tasks/get`に含める

ポーリングのたびに、タスクの現在の状態を返してください。tasks/getの成功応答では、処理のstatusがまだworkingでもresultType: "complete"を使います。完了したのは状態を問い合わせるリクエストであり、処理そのものとは限らないためです。

先ほどのビルド例が完了した場合の応答は、次のようになります。

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "taskId": "6f17bfa2-4c5e-4d21-b563-2f7e83a902bc",
    "status": "completed",
    "createdAt": "2026-10-24T08:00:00Z",
    "lastUpdatedAt": "2026-10-24T08:03:00Z",
    "ttlMs": 3600000,
    "result": {
      "resultType": "complete",
      "content": [
        {
          "type": "text",
          "text": "Build completed successfully."
        }
      ]
    }
  }
}

内側のresultには、通常のツール結果を入れます。isError: trueを使うツールレベルのエラーも、タスクの状態はcompletedです。failedは、errorに格納するJSON-RPCの実行エラーに使います。

tasks/cancelも実装しますが、キャンセルはサーバーの協力によって成立する要求として扱ってください。拡張仕様は、すでに実行中の処理がキャンセルによって確実に停止することを保証していません。Claude Codeは現在、ポーリングで結果を取得するため、結果の配信をnotifications/tasksに依存させないでください。

ツールが決められない判断はElicitationで確認する

対象環境、出力先、承認などが不足している場合は、それに依存する操作を行う前にユーザーへ確認してください。フォームモードのElicitationは構造化された項目を収集し、URLモードは外部サービスへのサインインなど、ブラウザを使う手順を提供します。

Taskの実行中に質問する場合は、tasks/getでstatus: "input_required"とinputRequestsマップを返します。各項目には一意のキーを付け、elicitation/createなどの要求するmethodと、そのparamsを格納します。Claude Codeは、inputResponses内で対応するキーを使い、tasks/updateを通じて回答を送ります。

対話型CLIで質問が/tasksの後ろに隠れている場合は、/tasksを閉じてください。拒否する、またはEscを押すと、入力要求への回答が返ります。その後も処理を続けるかどうかはサーバーが判断します。

非対話型セッションでTaskがユーザー入力を要求した場合、Claude CodeはElicitationフックやAgent SDKのonElicitationコールバックを実行せず、サーバーにそのTaskのキャンセルを要求します。無人実行を始める前に必要な選択を渡しておくか、対話型セッションを使ってください。この制限は、MCP Tasksを通じて要求される入力に対するものです。

Elicitationの回答を人間の承認として扱う前に、フックも確認してください。フックリファレンスには、次の動作が記載されています。

Elicitationは自動で回答し、ダイアログを表示させないことができます。
ElicitationResultはユーザーの回答を変更できます。実装を誤ると、拒否を承認に置き換えることもあります。
Elicitationフックがすでに回答している場合、ElicitationResultは実行されません。

ユーザー、プロジェクト、ローカル、管理設定、プラグインの各設定から実際に適用されているフックを確認してください。リポジトリ内の設定ファイルだけでは、自動回答しているフックを見落とす可能性があります。

停止・終了・会話のクリア・再開で何が起きるか

リモートのTaskをキャンセルしたい場合は、明示的に停止を要求してください。CLIを終了してもキャンセルにはなりません。ドキュメントのライフサイクル説明では、サーバー上での実行とClaude Codeによる追跡を区別しています。

操作	結果と次の対応
`/tasks`でTaskを選び`x`を押す、またはClaudeに停止を依頼する	Claude Codeは追跡を止め、キャンセルを要求します。ただし、サーバーがそのまま処理を完了する場合があります。
通常の対話中に`Esc`を押す	バックグラウンドのTaskは停止しません。
リモートのTaskが実行中にCLIを終了する	サーバー上の処理は続きます。再び追跡するには、開始元のセッションを再開します。
stdioのTaskがある状態でCLIを終了する	ローカルサーバーのプロセスが停止します。サーバーがそのプロセスの終了後も実行を続ける仕組みに明示的に対応していない限り、処理が継続するとは考えないでください。
Claude Codeを開いたまま`/clear`、`/branch`を使う、または`/resume`で別のセッションへ移る	現在の会話に結果が届く場合があります。一度CLIを終了した後は、Taskを最初に開始したセッションを再開してください。
開始元のセッションを対話型で再開する	サーバーがまだTaskを保持していれば、再接続後に追跡が再開します。サーバー名と接続設定は変更しないでください。
新しいセッションを始める、または`--fork-session`を使う	新しいセッションには、そのTaskの追跡は引き継がれません。
単発の`claude -p`で再開する	その実行ではTaskを追跡しません。対話型で再開するか、条件を満たすストリーミング入力を使ってください。

サーバーが切断されている場合は、Taskを停止する前に/mcpで再接続してください。そうしないとキャンセル要求がサーバーに届かず、Claude CodeはそのTaskを追跡対象から外します。

claude --resumeで開始元の会話を選択します。ただし、サーバーの保持ポリシーにも注意が必要です。会話を再開できても、サーバーが破棄した結果は復元できません。

MCP設定を点検するためのプロンプト

サーバーや設定を変更する前に、読み取り専用の点検で、必要な最小限の変更を特定してください。次のプロンプトは、@Voxyz_aiによるMCP監査の提案を基に、現行の応答形式とストリーミングセッションの動作を確認する項目を加えたものです。

Goal: Audit my Claude Code MCP setup for Tasks and Elicitation.

Read the current official documentation:
https://code.claude.com/docs/en/mcp
https://code.claude.com/docs/en/env-vars
https://code.claude.com/docs/en/hooks
https://modelcontextprotocol.io/extensions/tasks/overview

Scope: Inspect connected MCP servers, their configuration, effective settings, and any MCP server implementation in this repository. Say explicitly if no server implementation is present. Keep credential values out of the report.

Check:
1. Long-running tools: identify builds, test runs, exports, or research that could benefit from Tasks. For my server code, recommend the smallest change to return a valid task handle, persist it across connections, and deliver the final result through tasks/get. For third-party servers, cite evidence for the deployed version's support; otherwise mark support unknown.
2. Eligibility: check the CLI version, transport, actual protocol revision, per-request Tasks capability, feature-flag fetching, provider, supported surface, main conversation versus subagents, and input mode. Include MCP_SDK_GENERATION, MCP_PROTOCOL_NEGOTIATION, privacy/flag-fetching variables, CLAUDE_AUTO_BACKGROUND_TASKS, CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND, and CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS. Distinguish one-shot claude -p from stream-json input.
3. Elicitation: find tools that guess missing parameters or perform irreversible actions without obtaining the necessary decision. Inspect Elicitation and ElicitationResult hooks for automatic acceptance or changes to a user's refusal, including hooks outside this repository.
4. Lifecycle: check cancellation, remote versus stdio execution, retention, and resume. Identify unattended Tasks that might request user input.

Output: For each finding, name the tool or setting, cite the evidence, describe current behavior, recommend the smallest change, and give one verification step. Mark conditions you cannot observe as unknown.

Do not edit files, change settings, or invoke operational jobs during this audit. Show recommendations first.