【ITニュース解説】MCP Went Stateless. Your AI Agent Still Needs State.

AI技術が急速に進展する中、高性能なモデルだけでなく、それらを本番環境で安定稼働させるためのシステム設計が極めて重要になっている。特に、自律的に一連の作業を実行するAIエージェントの分野では、その重要性が増している。最近、AIシステムの基盤技術である「Model Context Protocol（MCP）」の仕様が変更され、そのコアが「ステートレス」になった。この変更は、一見するとエージェント自体もステートレスであるべきだと示唆するが、実際にはエージェントのワークフローにおける「状態」管理の重要性が高まっているのである。

MCPがステートレスになったとは、以前のようなクライアントとサーバー間の「セッション」に依存せず、各リクエスト自体が処理に必要なすべての情報を持つようになったことを意味する。これにより、ロードバランサーを経由してどのMCPサーバーに振り分けられても、リクエストは独立して処理できるようになる。特定のサーバーに縛られず、システムの拡張性（スケーラビリティ）が格段に向上する。これは通信層における優れた改善点だが、重要な落とし穴がある。それは「通信層がステートレスになったからといって、アプリケーションのワークフローまでステートレスになるわけではない」という点だ。

AIエージェントは、多くの場合「状態機械」として動作する。これは、一連の手順やプロセスを、その途中の状況を記憶しながら実行するプログラムだ。例えば、顧客からの返金リクエストを処理するエージェントのワークフローを考えてみよう。「ユーザーが返金要求する」→「エージェントが注文を調査する」→「返金ポリシーを確認する」→「返金金額を計算する」→「人間の承認が必要」といった段階を経て進行する。ここで「人間の承認が必要」となった場合、エージェントの作業は一時的に中断され、承認を待つ状態に入る。この一時停止は数十分から数時間続くこともある。

この一時停止期間中に、もしエージェントが現在の作業状況をプログラムの実行中のメモリの中にだけ保持していたらどうなるだろうか。エージェントを動かしているサーバーの再起動、システムのデプロイ、ロードバランサーによるリクエストの別サーバーへの振り分けなどで、メモリ上の情報は簡単に失われてしまう。結果として、人間による承認が到着しても、エージェントは過去の作業内容を思い出せず、処理を再開できなくなるか、最初からやり直す羽目になる。これでは実用的なシステムとは言えない。

このような問題を避けるためには、エージェントのワークフローの状態を「永続的に保存する」必要がある。プログラムのメモリではなく、データベースのような外部の記憶装置に現在の進捗、次にやるべきこと、これまでに得られた情報などを記録するのだ。これにより、たとえエージェントを動かしていたサーバーが停止しても、別のサーバーがデータベースから状態を読み込み、中断された箇所から処理を正確に再開できるようになる。

本番環境でAIエージェントを構築する際には、エージェントが扱う「状態」をいくつかの異なる種類に分けて考えることが有効だ。一つ目は「会話状態」である。これは、AIモデルがユーザーとの対話を理解し続けるために必要な情報で、メッセージのやり取り、会話の要約などが含まれる。二つ目は「ワークフロー状態」である。これは、アプリケーション全体がエージェントの実行が現在どの段階にあるかを把握するために使う情報だ。例えば「返金ID：39281のワークフローは、現在人間の承認待ちで、次のステップは返金確定である」といった具体的な情報がこれにあたる。これは分散システム全体で管理すべき重要な状態だ。三つ目は「副作用状態」である。これは、エージェントがすでにどのような「外部システムへの影響（副作用）」を与えたかを記録する情報だ。例えば「顧客へのメールは送信済みか」「返金処理はすでに作成済みか」といった事実を記録する。この情報が欠けていると、システムのリトライ（再試行）が非常に危険になる。

例えば、エージェントが返金APIを呼び出した後、ネットワークのタイムアウトが発生したケースを想像してみよう。エージェントは返金が成功したか失敗したかを知らないため、安全のために再試行を試みる。もし、最初のAPI呼び出しが実際には成功していたのに、エージェントがその事実を知らないまま再試行してしまうと、顧客に二重に返金されてしまう可能性がある。このような問題を防ぐために「べき等性」という概念が極めて重要になる。べき等性とは、同じ操作を複数回実行しても、一度実行した結果と変わらないことを保証する性質である。例えば、返金APIを呼び出す際に「ワークフローID_ステップID」のようなユニークな「べき等性キー」を付与するように設計する。一度そのキーで返金処理が実行されていれば、同じキーでの二度目以降の呼び出しは、すでに処理済みであることを検知し、既存の結果を返すだけで、新たな返金処理は行わないようにできる。これは決済処理だけでなく、メール送信、チケット作成、リソース削除など、エージェントが行うあらゆる外部へのアクションに応用すべきであり、AIシステムの安全性にも直結する重要な要素だ。

人間による承認が必要なワークフローも、分散システムの問題として捉えるべきだ。エージェントが何らかのアクションをドラフトし、人間がそれを承認するまで一時停止し、承認されたらその続きから処理を再開する、というパターンは一般的になる。ここで重要なのは「再開（resume）」であり、最初からやり直す「再起動（restart）」ではない。永続的な状態管理があればこそ、エージェントは一時停止した時点の状況を正確に記憶し、そこから処理をスムーズに継続できる。

このように、長時間実行されるAIエージェントのシステムは、プロセスがクラッシュしたり、ネットワークが故障したり、メッセージが重複したり、タイムアウトが発生したり、リトライが必要になったり、あるいは実行中にデプロイが行われたりするといった、従来の分散システムが直面してきた様々な問題に再び直面することになる。これらの問題は大規模なソフトウェアシステムでは以前から存在していたもので、AIエージェントの登場によって改めてその重要性が認識されているのだ。したがって、本番環境のAIエージェントシステムでは、エージェントの実行を管理する「Agent Orchestrator」や、状態を永続化する「State DB」、非同期処理を担う「Queue」、そしてイベントログなどが連携する「永続的なワークフロー（Durable Workflow）」の仕組みが不可欠となる。

ここで、MCPのステートレス化と、エージェントの永続的な実行は、解決する問題が異なることを明確に理解しておく必要がある。MCPは「エージェントがどのようにツールや外部システムと通信するか」という、通信プロトコル層の効率化とスケーラビリティを向上させるものだ。一方、永続的な実行は「エージェントが時間をかけて確実に作業を継続する方法」という、アプリケーション層の信頼性と回復力を保証するものだ。これらは互いに補完し合い、協力して動作することで、より堅牢なシステムを構築できる。

さらに、AIエージェントのシステムでは「可観測性（Observability）」の確保も変化する。従来のAPI監視では「APIが200 OKで4.2秒かかった」という情報だけでは不十分だ。エージェントの実行は、複数のステップ、モデル呼び出し、ツール呼び出し、人間による承認、状態遷移など、複雑な一連の処理で構成されるため、各ステップでのモデル呼び出しの引数や応答、レイテンシ、トークン使用量、リトライ回数、エラー、さらにはかかったコストまで、エージェントの「完全な実行軌跡（トレース）」を詳細に追跡できる仕組みが必要となる。

本番環境で高品質なエージェントシステムを設計するならば、役割を明確に分離することが重要である。API層がユーザーからのリクエストを受け付け、Agent Orchestratorがエージェントの計画立案や推論、ツールの選択といった知的な処理を担当する。その下で、MCPがツールとのステートレスなインターフェースを提供し、Workflow Runtimeが永続的な状態管理を通じてエージェントの実行を確実に継続させる。そして、その永続的な状態はデータベースに、非同期処理はキューに、発生したイベントはログにそれぞれ保存される。このように各コンポーネントがそれぞれの役割に専念することで、堅牢性とスケーラビリティを持ったシステムが実現する。大規模言語モデル（LLM）にこれらすべての懸念（永続性、回復力、可観測性など）を解決させようとすると、エージェントアーキテクチャは破綻してしまうだろう。

最終的に、AI業界はこれまで「どのモデルを使うか」「どのプロンプトを使うか」「どのエージェントフレームワークを使うか」といった問いに注力してきた。しかし、本番環境でAIエージェントを運用する上で本当に重要な問いは、徐々に「ワークフローはどのように回復するか」「実行をどう再開するか」「重複した副作用をどう防ぐか」「状態はどこに保存されるべきか」「ツール呼び出しをどう認可するか」「50ステップにわたる実行をどうトレースするか」といった、従来の「分散システム」の知識が問われるものへとシフトしている。MCPがステートレスになったことは、エージェントシステムから状態をなくすことではなく、状態を「アプリケーションおよびワークフロー層」という、本来管理されるべき場所にきちんと配置することの重要性を示しているのである。

これからのAIアプリケーションは、単に「ユーザーがプロンプトを与え、LLMが応答を返す」という単純なものではなくなるだろう。それは「ユーザーがエージェントと対話し、エージェントがプランナーを通じて思考し、MCPを介してツールを呼び出し、永続的なワークフローエンジンによって実行が管理され、必要に応じて人間の承認やリトライが行われ、その全てが可観測性によって監視されながら、最終的な結果を出す」という、はるかに複雑で信頼性の高いシステムへと進化していく。AIモデルはシステムの「脳」ではあるが、本番環境における信頼性や安定性は、古くからある優れたシステムエンジニアリングの原則に基づいて構築される。そして、どれほど優れたプロンプトエンジニアリングをもってしても、このシステムエンジニアリングの重要性に取って代わることはできないのだ。