10月15日、InfoWorldがArjun Mullick氏による「Your AI agent needs more than memory. It needs reliable state」と題した記事を公開した。Mullick氏はInfoWorldへの寄稿者であり、大規模ECインフラやリアルタイムパーソナライズ基盤の構築経験を持つエンジニアだ。記事が問うのは、「AIエージェントが記憶を持てば安全に動くのか」という点であり、その答えは明確に「否」である。返金の二重実行のような現実世界の実害は、記憶系の強化では防げない。必要なのは「信頼できる状態管理（Reliable State）」だ、と氏は主張する。

記憶は「何が起きたか」しか教えてくれない

AIエージェント開発で多くのチームが注力するのは、より長いコンテキストウィンドウ、会話サマリー、RAG（検索拡張生成）といった「記憶系」の強化だ。だがこれらは、ある本質的な問いには答えられない。「そのアクションは本当に完了したのか？」

記事が挙げる具体例がわかりやすい。カスタマーサービスエージェントが返金を承認したとする。返金処理は実際に完了したが、確認レスポンスがタイムアウトしてエージェントに届かなかった。エージェントの記憶には「返金リクエストを送った」という記録しかない。タスクが未完と判断したエージェントは、再度返金を実行する。推論は正しい。だが二重返金という実害が発生する。

会話履歴をいくら増やしても、この問題は解決しない。エージェントに必要なのは、リクエストID・現在のステータス・確認済みの結果という「信頼できる記録」だ。記憶は「顧客が何を求めたか」は教えてくれるが、「別のシステムが実際に何をしたか」は教えてくれない。

レコメンドシステムが先に直面していた同じ問題

Mullick氏は、レコメンデーション・パーソナライズシステムの構築経験から、この問題の本質を説明する。

レコメンダーは購買履歴・閲覧履歴からパターンを読み取り、「次に欲しいもの」を予測する。だがこれはあくまで推論であり、現在の意図を示す事実ではない。選挙シーズンに政治関連の本を数冊買ったユーザーのケースを挙げる。選挙が終わり、ユーザーの関心は移っても、購買履歴は変わらない。履歴は正確だが、現在の意図を反映していない。

氏が実際に携わったリアルタイムパーソナライズ基盤では、「鮮度（Freshness）」が最大の技術課題だったという。ユーザーの推定インタレストが実際の行動に追いつかず、システムが自信を持って「ズレたレコメンド」を出し続けた。パイプラインを再構築し、シグナル更新がほぼリアルタイムで反映されるようにして解決した。

本を薦めるだけなら、このズレは許容範囲内だ。しかしエージェントが「ユーザーの代わりに実際に行動する」立場になると、ステールなデータは推奨ミスではなく、現実世界のミスになる。

Reliable Stateとは何か

Reliable State（信頼できる状態）とは、特定の運用上の事実について、権威ある情報源から取得した検証済みの記録だ。返金の例で言えば：

• 会話履歴 → 顧客が何をリクエストしたか
• 決済システム → 返金が実行されたか
• 注文システム → 注文の現在ステータス
• ポリシー/権限システム → そのアクションが現時点で許可されているか

それぞれの事実には、それぞれの権威ある情報源がある。そしてエージェントは、自身の記憶に頼るのではなく、都度その情報源を参照しなければならない。権限は処理の途中で変わり得る。注文はキャンセル可能ウィンドウを過ぎているかもしれない。すべてのチェックを通過しても、アクション自体が途中で失敗することもある。

記事では、こうした「今何が真実か」問題を解くために設計されたツール群を列挙している：

• 業務状態/ワークフローDB: PostgreSQL、DynamoDB、Spanner、Cosmos DB
• ワークフローオーケストレーション: Temporal、AWS Step Functions、Azure Durable Functions
• エージェント状態: LangGraphのチェックポイント機能
• セッション/キャッシュ: Redis、Memcached
• イベント履歴: Kafkaなどのストリーミング基盤
• 権限状態: Open Policy Agent、Amazon Verified Permissions

これらは互いを置き換えるものではない。本番環境のエージェントは、これらの複数を組み合わせて動かす必要がある。

安全なリトライには「レシート」と「リカバリ計画」が必要

エージェントが重要なアクションを実行するたびに、一意の識別子（レシート番号に相当するもの）を付与すべきだ。レスポンスが失われた場合、エージェントは同じIDで同じ操作を再試行する。受信側のシステムはそのIDを認識し、デデュプリケーション（重複排除）ウィンドウ内であれば二重実行を防ぐ。これがいわゆる冪等性（Idempotency）のある設計だ。AWSのBuilders' Libraryにある「Making retries safe with idempotent APIs」が、この設計の詳細を解説している。

さらに必要なのがReconciliation（照合）だ。エージェントが「完了した」と信じている内容と、システムオブレコードが実際に記録している内容を定期的に突き合わせる。銀行明細とレシートを照合するのと同じ発想だ。不一致が生じたとき、次のアクションが明確でなければならない：再確認、アクションの取り消し、または人間へのエスカレーション。

大規模なECインフラの経験から、氏は次の教訓を示す。高トランザクション量では、「このトランザクションは本当に完了したか」という問いに記憶や推定で答えることは許されない。わずかな未確認・重複アクションの発生率でも、大量トランザクションでは顧客への実害に直結する。

監視すべきは「モデルの精度」より「決定のトレース」

最後に記事は、監視設計についての指針を示す。レイテンシ・コスト・モデル精度は重要だが、それだけでは「エージェントが古くなった権限情報に基づいて動いていた」「発表した返金が実際には処理されていなかった」という問題は検出できない。

重要な決定のそれぞれについて、以下をトレースすべきだとする：

• エージェントが使用した情報
• その情報の最終更新日時
• アクション前にチェックされたルール
• 実際に試行されたアクション
• その後に記録された結果

記事の結論は明快だ。エージェント自体を「真実の記録」にしてはいけない。その役割は、そのために設計されたシステムが担うべきだ。 記憶はエージェントに「何が起きたか」を教える。Reliable Stateは「今何が真実か、そしてアクションが安全かどうか」を教える。

詳細はYour AI agent needs more than memory. It needs reliable stateを参照していただきたい。