ステートレスMCPとステートフルAgentワークフロー：AndroidスマホAgentのタスク状態設計

MCP 2026-07-28で変わったこと

MCP 2026-07-28で重要なのは、ステートレスMCPとステートフルAgentワークフローが矛盾しない点です。Model Context Protocolの2026年7月28日仕様リリースは、ステートレスなプロトコル中核、自己記述的なリクエスト、MRTR、ヘッダールーティング、キャッシュ可能なリスト、認可強化、拡張フレームワーク、Tasks拡張を含む更新として説明されています。プロトコルの運搬部分が軽くなるほど、どの状態をどこで持つかを設計者が明確に決める必要があります。

SEP-2575のステートレス化提案では、必須の初期化ハンドシェイクを外し、セッションに暗黙に置いていた前提をリクエストごとのメタデータへ移す方向が示されています。これにより、互換サーバーインスタンスのどれが受けても処理しやすくなり、ロードバランサー、サーバーレス、再起動、スケールアウトの設計が楽になります。

FoneClawを作る立場から見ると、この変化はスマホAgentに向いています。Androidタスクは、画面、権限、承認、端末状態、途中復旧に強く依存します。外部コネクタのプロトコルセッションに作業状態を閉じ込めるより、Agentホスト側がタスク状態を持ち、必要な参照だけをMCPリクエストへ渡すほうが、ユーザーに見える復旧を作りやすくなります。ツール発見と認可の分け方は、Agentic Resource Discoveryとは：ai-catalog.json、検証、スマホ操作の認可を分けて考えるでも詳しく扱っています。

ステートレスMCPリクエストの流れ

ステートレスMCPのリクエストでは、サーバーが過去の暗黙セッションを覚えている前提を薄くします。クライアントは、呼び出しごとに必要なメタデータ、能力、要求内容、認可情報、状態参照を明示し、サーバーはその一回のリクエストを処理できる形で受け取ります。リストや能力情報はキャッシュしやすくなり、ヘッダーでルーティングしやすくなり、任意の互換インスタンスが処理できる範囲が広がります。

ただし、実際の機能がすべて一回のリクエストで終わるわけではありません。長い処理、ユーザーへの追加確認、外部サービスの待ち時間、Android端末上の権限復旧などは、明示的な参照が必要になります。SEP-2567の明示的なstate handleの提案は、暗黙のプロトコルセッションに置いていた状態を、サーバーが発行する明示的なハンドルとして後続呼び出しへ渡す考え方を示しています。

ここで大切なのは、state handleをアプリケーション全体の記憶や承認として扱わないことです。ハンドルは、後続の呼び出しが参照する識別子です。ユーザーが何を承認したか、Android端末の現在状態がどう変わったか、同じ操作を再試行してよいか、結果をどう監査するかは、Agentホスト側のステートフル設計で扱います。MCPサーバーはステートレスに拡張しやすく、Agentは状態を明示的に所有する。この分担が、スマホAgentの信頼性を高めます。

スマホAgentが持つべき六つの状態

スマホAgentのタスク状態は一種類ではありません。FoneClawの実装で私たちが重視しているのは、会話、タスク、端末、承認、認証、監査を分けて持つことです。ステートレスMCPサーバーへリクエストを送る場合でも、これらの状態はAgentホスト側で整合させる必要があります。Androidの画面は変わり、権限はユーザー操作で変わり、アプリはログアウトし、通知や通信状態も動くからです。

承認と認証は特に分けます。サービスへアクセスする資格があっても、ユーザーが特定のSMS送信やDo Not Disturb変更を承認したことにはなりません。逆に、ユーザーが画面で承認しても、必要なAndroid権限やサービス認証が足りなければ実行は進みません。アイデンティティ、権限、監査を深く見る場合は、AIエージェントのアイデンティティ、権限、監査ログ：ツール単位で安全に実行する設計が、状態の分解を補います。

MCP Tasks、MRTR、聞き返し、承認のつなぎ方

MCP 2026-07-28では、Tasksが正式な拡張として扱われます。長くかかる処理や後続確認が必要な処理では、Task handleを返し、後で状態を確認したり、キャンセルしたりする設計ができます。MRTRは、モデルやツールの処理中に必要な追加情報をやり取りする考え方として、スマホAgentの聞き返しにも近い意味を持ちます。たとえば「どのSIMで送りますか」「この宛先でよいですか」「この設定変更を1時間だけ適用しますか」といった確認です。

ここでも、Task handleとユーザー承認は別に扱います。Task handleは作業を参照するための識別子です。承認は、ユーザーが特定の操作、対象、内容、影響を見て許可した記録です。スマホAgentでは、この二つを結び付ける必要があります。タスクが進行中でも、ユーザーが承認を取り消す、端末権限が変わる、画面が別アプリへ移る、期限が切れる、といったことが起きます。

FoneClawの現在製品は、MCP Tasksの実装例としてではなく、同じスマホ内でタスク状態を持つホスト設計の例として参考になります。現在のFoneClawでは、Homeとフローティングアシスタントの間で作業を追い、権限が足りないときは復旧へ進めます。最新のリリース情報はFoneClawのダウンロードページで案内しています。将来MCPコネクタを設計する場合も、Task handle、承認記録、Android権限、監査ログを分ける設計が必要です。

ステートレスMCP上で動くAndroidタスクの例

具体例として、会議前にDo Not Disturbを1時間だけ有効にするタスクを考えます。ユーザーはFoneClawのようなスマホAgentに「会議中だけ通知を抑えて」と頼みます。Agentホストは会話状態に意図を記録し、タスク状態を作り、現在のAndroid設定、予定、権限を読み直します。ここで外部コネクタが必要なら、ステートレスMCPリクエストには、必要なメタデータ、タスク参照、idempotency key、要求内容だけを渡します。

次に、Agentは変更内容をユーザーに見せます。「Do Not Disturbを1時間有効にする」「通話やアラームの扱いは現在設定に従う」「終了時刻を表示する」といった形です。承認を受けたら、Android上の対応操作を実行します。実行直前には端末状態を再確認します。ユーザーが設定画面を開いていた、権限が切れていた、別のモードが有効になっていた、ということがあり得るからです。

実行後は、結果を検証します。設定が変わったか、予定した終了時刻が見えるか、失敗した場合は何が足りないかを記録します。ネットワークや外部コネクタの再試行が必要な場合、idempotency keyで重複実行を避けます。SMSのような外部に影響する操作では、宛先、本文、送信条件を確認し、同じ送信を二重に走らせないことがさらに重要になります。

この考え方は、通話やナビにも使えます。MCP電話ツールとAndroidダイヤラー操作の違いは、AIエージェントの電話発信：MCP電話ツールとAndroidダイヤラー操作の違いで扱っています。現在画面をユーザーが添付して作業を始める流れは、Android フローティングAIアシスタント 画面認識：現在画面から安全に操作へ進む方法が実用的な補助になります。現在のFoneClawで対応しているAndroid操作はFoneClawの機能紹介で確認できます。

ステートレスMCPサーバーを拡張しながら信頼性を保つ

ステートレスMCPサーバーは、運用面で大きな利点があります。リクエストが自己記述的になれば、ロードバランサーの背後に複数インスタンスを置きやすく、サーバーレスや短命なコンテナにも載せやすくなります。再起動後の復旧も単純になります。MCP Go SDK v1.7.0のリリースは、2026-07-28プロトコルに合わせたリクエストごとのメタデータやサーバー発見、既存バージョンとの互換パスを示す実装例として参考になります。

ただし、スマホ操作の外部効果は慎重に扱います。リトライには分類が必要です。読み取り系の再試行、候補生成の再試行、設定変更の再試行、SMS送信の再試行は同じではありません。外部に影響する操作では、idempotency key、相関ID、実行前の端末再確認、実行後の検証、監査ログが必要です。ステートレスなサーバーを増やしても、ユーザーに同じSMSが二回送られたり、設定変更が重複したりすると、体験は壊れます。

FoneClawを作っていると、信頼性はインフラの可用性だけでは決まらないと分かります。ユーザーがどのタスクを見ているか、どの承認をしたか、どの権限が足りないか、どの結果が確認済みかをホスト側で追えることが重要です。会議メモから確認付きスマホ操作へ進むようなワークフローは、AIレコーダーMCP：会議メモを確認付きスマホ操作につなげる方法でも応用できます。MCPがステートレスになるほど、Agentホストの状態設計がユーザー体験を支えます。

セキュリティ境界と移行チェックリスト

最後に、移行時の基準を整理します。MCP 2026-07-28は認可強化も含みますが、認証、認可、ユーザー承認、端末権限、監査はそれぞれ別の状態です。サービスにアクセスできること、MCP Task handleを持っていること、ユーザーが特定のAndroid操作を承認したことは、同じ意味ではありません。スマホAgentでは、この違いをUIとログに落とし込む必要があります。

移行では、既存クライアントや既存サーバーとの互換も見ます。すべてのSDKやデプロイが同時に新ライフサイクルへ揃うわけではないため、プロトコルバージョン、能力発見、レガシー初期化、明示的state handle、Tasks対応、認可ヘッダー、キャッシュ対象を段階的に扱います。FoneClawのようなAndroidホストから見ると、外部コネクタが新仕様へ進んでも、端末側の権限、承認、復旧、監査はホスト側で維持します。

• リクエストに必要なメタデータを毎回明示する。
• 会話、タスク、端末、承認、認証、監査の状態を分ける。
• Task handleを承認や権限として扱わない。
• idempotency keyと相関IDで再試行を追えるようにする。
• Android端末状態を実行直前に再確認する。
• 外部効果のある操作は結果検証と監査を残す。
• 旧プロトコルと新ライフサイクルの互換パスを段階的に試す。

私たちがFoneClawで重視しているのは、ユーザーのタスクがどこにあり、どこで止まり、どこから戻れるかです。MCPがステートレスな中核へ進むほど、その考え方は強くなります。プロトコルは軽く、Agentは状態を明確に持つ。これが、信頼できるAndroidスマホAgentワークフローの土台です。