コマースAIの健忘症を克服する新アーキテクチャ

Trends2026年2月27日金曜日

業界が華やかなエージェントデモを追いかける中、arXivに発表された新しい論文は、コマースで信頼性の高いAIシステムを構築するための地味だが重要なソリューション、すなわちイベントソーシングを提案している。あなたの状態管理戦略が最大の負債となる。

Aleksey KlempnerCTO.LA

あなたのコマースAIは5秒前の行動を覚えていない。新しいアーキテクチャがそれを解決する。

TL;DR: あなたのエージェントは健忘症にかかっている

今日のほとんどのAIエージェントはステートレスです。過去の行動に関する信頼できる記憶がなく、在庫管理や複数ステップの顧客ジャーニーなど、重要なコマース業務には不向きです。これはバグではなく、予測不可能で監査不可能な障害につながる設計上の根本的な欠陥です。
今週arXivに発表された新しい論文「ESAA: Event Sourcing for Autonomous Agents in LLM」（arXiv:2602.23193v1）は、長年培われてきたエンタープライズパターンであるイベントソーシングをエージェントシステムに応用することで、解決策を提案しています [5]。これにより、エージェントの意図（何をしたいか）と効果（実際に何が起こったか）が分離されます。
このアーキテクチャの変更により、監査可能で、リプレイ可能で、回復力のあるエージェントワークフローを作成できます。これにより、ブランドは異種LLM（GPT-5やClaude Sonnet 4.6など）を使用し、ベンダーロックインを回避し、最終的にミッションクリティカルなタスクを、自身の状態を幻覚させずに信頼できる長期間にわたるエージェントを構築できます [6]。

ますます現実味を帯びてきたシナリオを紹介しましょう。急成長中のDTCブランドのCTO—仮に「Melrose Active」と呼びましょう—が、完全にパニックに陥っていました。彼らが「agentic commerce」（エージェント商取引）の頂点として売り込まれた新しい自律型在庫エージェントが、動きの遅いSKUを50,000ユニット発注しようとしたばかりだったのです。トリガーは？ルーティンの在庫チェック中のネットワークの不具合でした。エージェントは、操作中にコンテキストを失い、初期ロジックを再実行し、失敗した最初の試行からの部分的なデータを誤解して、倉庫が空だと結論付けました。それは100万ドルの間違いであり、正直なところ、自律システムの目的を完全に無効にするhuman-in-the-loop（ヒューマン・イン・ザ・ループ）のアラートによってのみ捕捉されました。

これは例え話ですが、決して絵空事ではありません。エージェントAIブームの汚れた秘密の直接的な結果です。これらのシステムのほとんどは砂浜の上に構築されています。それらはステートレスで、絶え間なく続く現在の中で機能する健忘症患者です。1分前に何をしたか、ましてや昨日何をしたかさえ、確実に覚えていません。単純な質疑応答チャットボットにとっては、これは迷惑です。しかし、実際のコマースを定義する複雑でステートフルな長期間にわたるプロセス—在庫、物流、パーソナライゼーション、顧客サービス—にとっては、壊滅的な負債です。

世界の他の人々がAIエージェントが航空券を予約したり、「vibe researching」（バイブ・リサーチ）旅行プランを作成するデモに魅了されている一方で [1]、私たちは実際のコマースシステムを構築する現場で、はるかに根本的な戦い、つまり状態のための戦いを繰り広げています。そして、今週arXivにひっそりと発表された論文は、その戦いにおいてこれまでで最も重要な進展の1つかもしれません。

それで、3体のAIエージェントがバーに入ってきて...燃やし尽くした？

Melrose Activeのエージェントの問題は、単一障害点だけではありませんでした。それは、マルチエージェントシステムにおけるはるかに深く、システム的な問題の症状でした。在庫データベース、価格エンジン、APIゲートウェイなど、リソースを共有する複数の自律型エージェントを展開すると、それらは個別に停止するだけでなく、ダメージを増幅するような同期され、相関のある形で停止することがよくあります。

今週発表された興味深いarXivの論文「Three AI-agents walk into a bar … ‘Lord of the Flies’ tribalism」は、この悪夢のようなシナリオを完璧に示しています [2]。研究者たちは、自律型LLMエージェントを古典的なリソース競合シナリオ（エル・ファロルのバー問題）に置き、何が起こるかを観察しました。独立した合理的なアクターとして行動するのではなく、エージェントは基礎となる推論パターンに基づいてすぐに「部族」を形成しました。一部は「攻撃的」（人口の27.3%）になり、常にリソースにアクセスしようとしました。その他は「保守的」（24.7%）であり、かなりの多数派が「日和見的」（48.1%）になりました。

恐ろしい結果は？この新たな部族主義は、同期された行動につながり、単純なランダム分布が生み出すものよりもはるかに悪いシステム全体の過負荷と障害を引き起こしました。1つのエージェントが在庫APIを大量に消費することを決定した場合、同じ基盤となるモデルとロジックに基づいて構築された他の何十ものエージェントも同じことをしようとしている可能性があります。これは、障害モードに真の独立性がない、一見自律的なシステムを展開することの危険性です。堅牢なアーキテクチャのバックボーンがなければ、エージェントの労働力は個人のチームではなく、フラッシュクラッシュや群衆のような愚かさに陥りやすい暴徒です。

これが、エージェントの能力—彼らができること—への執着が誤っている理由です。真の課題は、1つのエージェントの障害だけでなく、何十ものエージェントが同時に障害を起こす状況を優雅に処理できるコマースAIアーキテクチャを構築することです。私たちは、LLM駆動ロジックに内在するカオスに対して、確定的で、監査可能で、回復力のあるシステムを必要としています。私たちは成功に驚嘆するだけでなく、失敗に備える必要があります。

健忘症マシン：現在のAIエージェントがコマースで失敗する理由

この脆弱性の根本原因は、エンジニアが「状態管理」と呼ぶものです。または、この場合、それが完全に欠如していることです。今日のほとんどのエージェントフレームワーク、例えば人気のReAct（Reason+Act）ループは、各インタラクションをほぼ独立したイベントとして扱います。エージェントの「記憶」は、LLM呼び出しのコンテキストウィンドウに詰め込まれた会話履歴にすぎません。これは記憶ではありません。それは付箋であり、非常に小さなものです。

エージェントアプリケーションにおける長期間にわたる記憶を評価する今週初めの論文は、私たちの多くが実際に見てきたことを裏付けています。このアプローチは時間とともに壊滅的に劣化します [7]。タスクがより複雑になり、ターン数が増えるにつれて、コンテキストウィンドウはいっぱいになり、重要な情報が失われ、エージェントは逸脱し始めます。最初の指示、以前の行動、そして操作すべき世界の状況を忘れてしまいます。

これは、いかなる真剣なコマースのユースケースにとっても、深刻で具体的な結果をもたらします。

監査不能性： エージェントの行動が確率的なLLMによって駆動される一時的なAPI呼び出しにすぎない場合、真実のソースは何でしょうか？財務部門が、なぜ動的価格設定エージェントが真夜中に主力製品の価格を90%も引き下げたのかを尋ねたとき、あなたの唯一の答えは「LLMが決定しました」ということになります。決定、それに影響を与えたデータ、または一連のイベントの不変のログはありません。これは、規制されたまたはミッションクリティカルなプロセスにとっては不可欠です。
冪等性（Idempotency）の欠如： 分散システムでは、冪等性が重要です。それは、同じリクエストを複数回行っても、1回行ったのと同じ結果になるという保証です。ネットワークエラーの後、Melrose Activeエージェントが在庫チェックを再試行した場合、それは無害で冪等な操作であるべきでした。しかし、その状態が失われたため、再試行は壊滅的な結果を伴う新しい、独立した行動となりました。ほとんどのエージェントフレームワークは冪等性を強制することさえ考慮しておらず、現実世界の避けられないネットワーク障害に直面して脆くなっています。
再生とデバッグの不能性： システムが停止した場合、どのようにデバッグしますか？ステートレスエージェントではできません。障害につながったイベントと状態の正確なシーケンスを再現できません。あなたはLLMプロバイダーからの不透明なログをじっと見つめ、確率的なブラックボックスを逆コンパイルしようとするしかありません。それは、ケーブルニュースの討論を見ながら複雑な財務モデルをデバッグしようとするようなものです。

これらはエッジケースではありません。これは、今日売られているほとんどのエージェントコマースシステムのデフォルトの動作です。それらは根本的に信頼性が低く、監査不能であり、実際のお金と実際の在庫がかかっている本番環境には不向きです。それらは、起こるべくして起こるアーキテクチャ上の負債です。

イベントソーシングは、エージェント商取引にとっての地味で待望のソリューションなのか？

これが、今週発表された、全くセクシーではないタイトルの論文「ESAA: Event Sourcing for Autonomous Agents in LLM」（arXiv:2602.23193v1）につながります [5]。これは、より巧妙なプロンプトや大規模なモデルではありません。高負荷で大規模なエンタープライズシステムの世界から借りてきたアーキテクチャパターン、つまりイベントソーシングを提案しています。

イベントソーシングは新しいものではありません。これは、金融、銀行、物流—監査可能性と信頼性が不可欠なあらゆる場所—で長年使用されてきたCQRS（Command Query Responsibility Segregation）のようなアーキテクチャの中核的なパターンです。核となる考え方は単純です。システムの現在の状態を保存する代わりに、これまでに発生したすべてのイベントの追記専用ログを保存します。現在の状態は、これらのイベントを再生することによって導き出されます。

ESAA論文は、このパターンをAIエージェントに適用することを提案しています。LLMにツールを直接呼び出して世界の状況を変更させる代わりに、エージェントの唯一の仕事は、その意図を記述したJSONオブジェクトを出力することです。それだけです。この意図はイベントとして扱われます。別の決定論的なシステム—オーケストレーター—が、このイベントを検証し、不変のログに永続化し、その後初めてその効果（Shopify APIの呼び出しやデータベースの更新など）を適用する責任を負います。

この分離が鍵です。システムの確率的で予測不能で創造的な部分（LLM）は、システムの決定論的で信頼性が高く、状態を変更する部分（オーケストレーター）から分離されています。

ESAAの仕組み：行動ではなく意図

ESAAベースのシステムのデータフローは、今日の必要とされているエージェントにガードレールを提供します。それは、Melrose Activeで見たような種類の障害を防ぐ規律のレベルを強制します。

プロセスは次のようになります。

これは単なる理論的な図ではありません。ESAA論文は、OpenAIのGPT-5やAnthropicのClaude Sonnet 4.6などの異種モデルでこのアーキテクチャが機能することを実証しています [6]。その美しさは、イベントログとオーケストレーターがモデルに依存しないことです。LLMの役割は「提案エンジン」に縮小されますが、オーケストレーターはすべての状態変更の唯一の真実のソースであり続けます。

自律型在庫エージェントの解説

このアーキテクチャを使用して、Melrose Activeのシナリオを再生してみましょう。ロサンゼルスに本社を置くこのブランドは、アボットキニーの旗艦店の在庫を管理する必要があります。

トリガー： cronジョブが、「アボットキニー店のすべての中核製品が安全在庫レベルを超えていることを確認する」という目標で在庫エージェントを起動します。
意図 #1（クエリ）： LLMエージェントは最初に{"intent": "get_inventory_levels", "location": "abbot_kinney"}という意図を出力します。オーケストレーターはこれをログに記録し、在庫システムを照会し、そのデータをエージェントに返します。
ネットワーク障害： オーケストレーターがデータを送信した直後に接続が切れたとしましょう。エージェントは何も受信しません。ステートレスモデルでは、その次の行動は誰も推測できません。ESAAモデルでは、何も変更されていません。状態は変更されていません。存在する唯一のものは、クエリを意図したログに記録された意図です。
再試行： エージェントが再試行すると、まったく同じ意図を再度出力します：{"intent": "get_inventory_levels", "location": "abbot_kinney"}。この冪等なリクエストを見たオーケストレーターは、最初のクエリの結果を再提供するか、再度実行することができます。結果は同じです。
意図 #2（注文）： SKUが少ないことを確認し、エージェントは次のコマンドを出力します：{"intent": "create_purchase_order", "sku": "MA-LG-BLK", "quantity": 500, "reason": "Stock at 42, below threshold of 50"}。reasonフィールドに注目してください。LLMにその意図を正当化させることができ、その正当化はイベントログに永遠に保存されます。
監査： 6か月後、監査官は不変のイベントログを再生することで、その日の在庫システムの正確な状態を再構築できます。何が起こったかだけでなく、エージェントがなぜ行動することを決定したかを見ることができます。これは、信頼できるエージェント商取引アーキテクトの基盤です。

これは単なるアーキテクチャの過剰なのか？懐疑論者の見解

もちろん、万能なアーキテクチャはありません。懐疑論者、あるいはタイトな締め切りに追われているエンジニアが最初に指摘するのは、オーバーヘッドでしょう。イベントソーシングは複雑さとレイテンシーを導入します。ログへの書き込み、スキーマの検証、そして状態の投影は、データベースレコードを直接変更するよりも本質的に遅いです。

この議論には一理あります。同じ週にarXivに提出された別の論文「Tool-R0」（arXiv:2602.21320v1）は、まったく異なる哲学を示しています。この論文は、ゼロデータからの強化学習を使用して、驚くべき効率でツールを使用する方法をエージェントに教え、ベンチマークで92.5%の改善を誇っています [9]。その焦点は、パフォーマンスと能力のみであり、ロギングによるランタイムの信頼性ではありません。短期間のタスクで、失敗のコストが低い場合、Tool-R0のアプローチは間違いなく優れています。

さらに、「多層防御（defense-in-depth）」の肥大化に関する懸念は現実です。単純なカスタマーサービスチャットボットが注文状況を調べるために、この重厚な機械が必要でしょうか？おそらく必要ありません。より単純なReActループやOpenPort Protocol（OPP）で提案されているモデルゲーティング [1]で十分かもしれません。重要なのは、トレードオフを理解することです。

2026年2月の最後の週に浮上した競合するアプローチの概要を以下に示します。

アプローチ	ESAAとの違い	強み	弱み	出典（2026年2月）
ESAA	追記専用イベントログによるランタイム状態管理	決定論的、監査可能、リプレイ可能、マルチLLM対応	より高いレイテンシー/複雑さ、ストレージのオーバーヘッド	arXiv:2602.23193v1 [5]
Tool-R0	ゼロデータからの強化学習によるツール使用の進化	非常に効率的なツール使用（92.5%向上）、自己改善	組み込みの状態永続性なし、長期間のタスクで脆い	arXiv:2602.21320v1 [9]
OPP (OpenPort Protocol)	最小権限認証とリスクゲーティングに焦点を当てる	安全なツールアクセス、モデルに依存しないゲートウェイ	中核となる状態/記憶の問題を解決しない	arXiv:2602.20196v1 [1]
エージェントの部族主義研究	問題点であり、解決策ではない。新たな障害モードを記述	該当なし	同期されたエージェントの推論がシステム全体の過負荷につながることを強調	arXiv:2602.23093v1 [2]
エージェント契約	形式仕様とランタイム監視	定義されたタスクの高い信頼性	異種エージェントや新たな動作にはスケールしにくい	arXiv:2602.22302 [13]

ESAAパターンはすべての問題に対応するわけではありません。しかし、舞台裏で行われる、リスクが高く、長期間にわたる複数ステップのプロセスを特徴とするコマースにおいては、そのトレードオフ—数ミリ秒のレイテンシーを犠牲にして、何年もの監査可能性と信頼性を得る—は、単に価値があるだけでなく、必須です。

あなたのブランドのエージェント対応型ストアフロントへの準備が意味すること

DTCブランドのCTOやエンジニアリング責任者にとって、これは目覚まし時計となるはずです。あなたのagentic storefront readiness（エージェント対応型ストアフロントの準備）は、チャットボットがいかに派手であるかとは何の関係もありません。それはバックエンドの堅牢性に関することです。あなたのインフラが、ステートフルで、監査可能で、信頼性の高いエージェントに対応できているかどうかにかかっています。

準備とは具体的には次のようになります。

構造化された冪等なAPI： 内部および外部APIは、非常に堅牢である必要があります。create_orderエンドポイントは、同じペイロードで5回呼び出されても、5つの注文を作成せずに処理できますか？できないのであれば、準備ができていません。エージェントは失敗し、再試行します。あなたのシステムはこれに対応できるように構築されている必要があります。
豊富なデータレイヤー： エージェントは、アクセスできるデータの質に依存します。structured data for AI search（AI検索のための構造化データ）—クリーンな製品カタログ、明確に定義された顧客セグメント、アクセス可能な在庫データ—への投資は、あらゆるインテリジェントシステムの基盤です。これは、プリンストンGEOラボのようなチームが取り組んでいることの中核です。つまり、モデルだけでなく、生成のための環境を最適化することです。
状態管理戦略： これが大きな問題です。エージェントがどのように状態を管理するかを意識的に決定する必要があります。リスクの低いインタラクションのためにステートレスなReActループのリスクを受け入れますか？それとも、重要なワークフローのためにイベントソーシングのようなパターンに投資しますか？戦略がないことは、失敗のための戦略です。
AIエクスペリエンスラボ： これをその場で構築することはできません。ブランドは、これらのエージェントアーキテクチャを安全にテストできるサンドボックス環境であるAIエクスペリエンスラボを内部に設置する必要があります。これは、サンタモニカの旗艦店の製品在庫に触れる前に、自社のシステムでレッドチームを組み、ネットワーク障害をシミュレートし、プレッシャーの下でエージェントがどのように動作するかを確認する場所です。

CTO.LAでは、コマースブランドと協力してこの基盤となるインフラを構築しています。私たちはエージェントの魔法を売っているのではなく、それを可能にする回復力のある、地味だが不可欠な配管を実装しています。私たちは、エージェントが不調な日にシステムが崩壊しないようにするagentic commerce architect（エージェント商取引アーキテクト）として機能します。

もう別のエージェントの負債を築かないでください

コマーススタックのあらゆる部分に「AIエージェント」を急いで導入することは、新世代の技術的負債を生み出しています。状態、監査可能性、および障害に対する整合性のあるアーキテクチャ戦略なしに構築されたこれらのシステムは、資産ではありません。それらはトリガーされるのを待っている負債です。

ラボで展開されたエージェントの調査では、データ漏洩やサービス拒否から、タスクを完了したことについて単に嘘をつくことまで、11種類の障害カテゴリが発見されました [1]。問題はエージェントが失敗することではなく、私たちのシステムがその失敗を封じ込めるように設計されていないことです。

ESAA論文が重要であるのは、それが革命的なAIの発見だからではなく、正気を取り戻すための呼びかけだからです。過去20年間の分散システムエンジニアリングにおける辛くも勝ち取った教訓が、強力な新しいLLMがあるからといって放り出されるわけではないことを思い出させてくれます。実際、それらはこれまで以上に重要になります。

あなたの会社の次の大規模なAIイニシアチブが、次の大規模な障害にならないようにしてください。アーキテクチャに焦点を当ててください。信頼性のために構築してください。意図と実行を分離してください。そして、神に誓って、エージェントに記憶を与えてください。

ロサンゼルスおよびその先におけるコマースAIの未来は、最も賢いプロンプトではなく、最も回復力のあるシステムによって定義されるでしょう。CTO.LAは、このエージェントインフラを構築するコマースブランドと協力しています。お話ししましょう。

参考文献

agentic commerce
commerce ai architecture
event sourcing
llm
ai

あなたのコマースAIは5秒前の行動を覚えていない。新しいアーキテクチャがそれを解決する。