AIエージェントが設計上忘れる理由：ステートレスAPIアーキテクチャの代償

あなたはこのループを見たことがあるだろう。顧客がフロンティアモデルで構築されたサポートエージェントに4回目のメッセージを送っている。彼らはアカウント番号を2回伝え、問題を2回説明した。エージェントは親切丁寧に、もう一度尋ねる：「確認のため、アカウント番号を教えていただけますか？」モデルは壊れていない。その周りのハーネスが前のターンを転送しなかったのだ。そしてAPIは、設計上、2メッセージ前の発言を記憶していない。

これはエッジケースではない。これは主要なLLMプロバイダーのAPIすべてのデフォルト動作であり、現在出荷されているエージェントシステムにおける最大の生産摩擦源である。理由はアーキテクチャ上のものであり、偶然ではない。そしてそのアーキテクチャのコストは、あらゆる請求書とあらゆるチームのカレンダーにのしかかる。

なぜAIエージェントは設計上忘れるのか？

OpenAIのChat Completions API、AnthropicのMessages API、GoogleのGemini APIは、エージェントの文献で驚くほど注目されていない特性を共有している：それらはステートレスである。各呼び出しは独立しており、サーバーはセッション、ユーザーID、以前のターンの記録を保持しない。モデルが「記憶」するのは、アプリケーションがこの特定のリクエストのためにメッセージ配列に入れることを選択したものだけである。

これがすべての主要プロバイダーが選んだアーキテクチャである。ドキュメントで謝罪される制限ではない。Anthropic Messages APIのドキュメントは明白に述べている：APIはステートレスであり、クライアントはすべての呼び出しで完全な会話履歴を送信する責任がある。OpenAIの新しいResponses APIはサーバーサイドの会話オブジェクトを便利レイヤーとして提供するが、基盤の推論呼び出しは依然としてステートレスである。状態はアプリケーションがモデルの周りで維持するものであり、モデル自身が維持するものではない。

この決定には十分な工学的理由がある。ステートレス推論はスティッキーセッションなしで水平スケーリングを可能にし、負荷分散を簡単にし、ステートフルシステムを悩ませるメモリとセキュリティのバグのクラスを回避し、モデル（入力から出力への関数）とアプリケーションロジック（どの入力を組み立てるかを決定する）をきれいに分離する。プロバイダーにとって、ステートレスは正しい選択である。

しかし、エージェントを構築するあなたにとっては、有効にできる「記憶」機能は存在しないことを意味する。あるのは、各リクエストで埋めるコンテキストウィンドウと、その周りに構築する足場だけである。

以下のコードは問題を示している：最初の呼び出しでユーザーがアカウント番号を入力するが、2回目の呼び出しでは履歴が渡されず、モデルはまったく覚えていない。

（コード例省略）

2回目の呼び出しは最初の呼び出しが発生したことをまったく知らない。APIにとって、これらは同じキーからの無関係なリクエストである。モデルにアカウント番号を「覚えて」もらいたい場合、エージェントハーネスは次回それをメッセージ配列に戻さなければならない。これが2026年の推論層における記憶の仕組みのすべてである。

コンテキストウィンドウは記憶ではない

明らかな反応は：「では毎回すべての履歴を送ればいい」というものだ。これはほとんどのプロダクションエージェントが行っていることであり、うまくいかなくなるまでは機能する。スケーリングが完了する前に、3つの理由で壊れる。

まずコスト。長時間セッションで毎ターン50Kトークンの会話履歴を再送信すると、あっという間に積み上がる。Claude Sonnet 4.6の入力価格は100万トークンあたり3ドル（2026年7月時点）で、100ターン・平均再送50Kトークンのセッションでは、キャッシュ前の入力コストだけで15ドル（出力やツール呼び出しは別）。プロンプトキャッシュはコストを削減する——会話履歴は追記型プレフィックスであり、キャッシュ読み取りは基本入力価格の10分の1で動作する。しかしデフォルトキャッシュは5分間しか保持されず、人間の思考時間はこれを超えることが多い。1時間キャッシュは書き込みコストが2倍になり、どのキャッシュもセッション、ユーザー、モデル交換をまたいで存続しない。キャッシュは再送信を割引するが、再送信を必要とするアーキテクチャを取り除くわけではない。

次にレイテンシ。より大きなコンテキストは、最初のトークンまでの時間が長くなることを意味する。ユーザーはミリ秒単位でコストを感じる。数百の内部ターンを実行するエージェントは、タスクあたりのドル単位でコストを感じる。

3点目はほとんどのチームが過小評価しているものだ：長いコンテキストはモデルのパフォーマンスを低下させる。Liuらの「Lost-in-the-Middle」論文は、言語モデル（長コンテキストフラッグシップを含む）が長いコンテキストの最初と最後から情報を検索する方が、中間からよりもはるかに信頼性が高いことを示した。40ターンの会話の12ターン目に埋もれた事実は、統計的に、同じ事実がシステムプロンプトや最新のユーザーメッセージに貼り付けられた場合よりもモデルの回答に影響を与える可能性が低い。モデルは「覚えていない」と言うとき嘘をついているわけではない——それはしばしば目の前のものを見つけることが本当にできないのだ。

より大きなコンテキストウィンドウは記憶アーキテクチャではなく、記憶の回避策である。違いは重要である。回避策には上限があり、私たちはそれに近づいている。100万トークンのコンテキストウィンドウは、Sonnet 4.6で埋めるのにリクエストあたり3ドル（セッションあたりではない）、Claude Fable 5では10ドルかかり、処理に数秒を要し、それでも中間から特定の事実を確実に抽出させることはできない。さらに詰め込むのは前進の道ではない。

記憶不足が引き起こす4つの生産障害

アーキテクチャ上の問題は、実際のユーザーの前で数週間以上実行されているエージェントなら誰でも見る4つの異なる障害モードとして現れる。

再説明。すべてのセッションはゼロから始まる。最も知識のあるユーザー、6ヶ月製品を使ってきたユーザーは、チャットウィンドウがリセットされるたびに、エージェントに自分が誰か、何に取り組んでいるか、どのような慣習を好むかを教えなければならない。コストはユーザーの時間、信頼、好意で支払われる。ユーザーのフラストレーションは繰り返すたびに増大し、ユーザーだけがそれに気づく。

引き継ぎ断絶。セッションが終了する。ユーザーは離れる。エージェントがそのセッションで学習、推論、確立したものはすべて消え去る。次のセッション、同じユーザーまたは同じ問題に取り組むチームメイトは、同じ白紙の状態から始める。CursorやClaude Codeを使用しているエンジニアリングチームは毎朝これを見る：前日のアーキテクチャ決定、命名規則、落とし穴を人間が新しいチャットに再読み込みしなければならない。エージェントの見かけ上の知能はセッションとともにリセットされる。

矛盾未解決。今日、ユーザーはエージェントにプロジェクトがPostgresを使用していると言う。明日、移行後、ユーザーはDuckDBを使用していると言う。永続記憶システムが両方の事実を単純に追加すると、矛盾する2つのエントリができ、どちらが現在有効かを判断するメカニズムがない。現在のベクトルストアベースの記憶実装には、「この新しい事実が古いものに取って代わる」というネイティブの概念がない。両方が取得される。モデルは時間的有効性ではなく、意味的類似性に基づいて選択する。ユーザーはエージェントのコードが間違ったデータベースをターゲットにしていることを知る。

不明時の推測。モデルが何かを知らないとき、それは「わかりません」と言うよりももっともらしく推測する傾向がある。これは部分的にはモデル訓練の問題であり、部分的には記憶設計の問題である：ほとんどのエージェント記憶層は「これは自信のある検索だ」と「この記憶はない」を区別する方法がない。その区別がなければ、モデルがでっち上げない理由はない。「以前のデプロイ設定の記憶がありません。教えていただけますか？」と正直に言えるエージェントは、もっともらしい答えをでっち上げるものよりも有用である。

これらの障害はすべて同じ根本原因を持ち、4つの異なる表面症状を持つ。それらを解決するには、より大きなコンテキストウィンドウやより良い埋め込みモデル以上のものが必要である。アーキテクチャが必要である。

チームが現在実際に行っていることと、各アプローチが不足している理由

いくつかの緩和パターンが登場している。どれも根本的な問題を解決するものではないが、ほとんどは狭い状況で役立つ。

プロンプト詰め込み。より関連性の高いコンテキストをシステムプロンプトまたは最新のユーザーメッセージに詰め込む。安価で高速だが、数千トークンを超えると崩壊し、中間喪失に悩まされる。

ファインチューニング。知識を重みに焼き付ける。安定したドメイン知識には強力だが、毎週変化する事実やユーザー固有の事実には役立たず、反復が困難。

検索拡張生成。推論時に知識ベースから関連チャンクを取得する。ドキュメントや参考資料には有効だが、ターンごとに進化する会話状態には適さない。

ベクトルデータベース。以前の会話の埋め込みチャンクを保存し、意味的類似性で検索する。2026年で最も一般的なパターンであり、記憶と混同されることが最も多い。テキストを取得するが、記憶層が必要とする時間的、構造的、信頼性の特性を提供しない。ベクトルデータベースだけでは不十分であり、それらを記憶プリミティブとして扱うことは、実際のアーキテクチャギャップをごまかすことになる。

会話要約。古いターンを実行中の要約に圧縮し、コンテキストに残す。本質的に損失がある。要約器自体がステートレスなモデルであり、何を保持し何を捨てるかを決定するが、3セッション後に何が重要になるかについての認識はない。

カスタム記憶ラッパー。すべてのチームが独自のものを構築する。形状はほとんど同じに見え、すべてにチームが本番で発見するエッジケースがあり、どれもアプリケーション間で移植可能ではない。

エージェント記憶ライブラリ。成長しつつあるオープンソースおよび商用ライブラリのカテゴリで、上記のパターンを採用しやすい形にバンドルする。エンジニアリングの労力を減らすが、個別には時間的、構造的、放棄の問題を解決しない。

プラットフォームベンダーも動いている：AnthropicのClaude Tag（2026年6月リリース）は、Slack内でClaudeにチャンネルスコープの永続記憶を提供する。

ほとんどのプロダクションエージェントはこれらのうち2つまたは3つを組み合わせて使用する。組み合わせはデモを出荷するのに十分機能する。6ヶ月後には、同じいくつかの問題が顧客フィードバックで繰り返し現れ、うまく機能しなくなる。

ステートレスなLLM APIへの呼び出しは毎回、アプリケーションが保持することを選択したものからコンテキストを再構築する。モデル自体はリクエスト間で何も覚えていない。

誰も話さない時間的問題

ストレージの問題を完全に解決したとしても、その下にはさらに難しい問題が残る：時間的有効性である。

記憶システムが「ユーザーはAivenで働いている」という事実を、ユーザーが18ヶ月前に言ったからという理由で保存したとする。その後、ユーザーは2回転職している。その事実はまだストアにある。ベクトル埋め込みはほぼ同じで、ユーザーが仕事関連の質問をすると依然として取得される。そしてそれは今や自信過剰に間違っている。

現在のエージェント記憶システムは、意味的類似性に基づいて検索し、時折再帰重み付けを組み合わせる。どちらも記憶が実際に表現する必要があるものを捉えていない：何が学習されたかだけでなく、いつ学習されたか、いつ真実だったか、そしてその後何かがそれを取って代わったかどうか。真の記憶表現は2つの時間次元を持つ：事実がシステムに入力された時間と、それが有効だった時間範囲。現在のほとんどの実装はどちらもきれいに追跡しない。

結果は、幻覚のように見えるが実際には古くても自信過剰な記憶であるというバグのクラスである。モデルが…

（原文はコスト抑制のため途中で切れています）