記憶の錯覚：
LLMのステート管理とエージェント設計の全貌

はじめに：LLMは「覚えている」のか？

ChatGPTやClaudeと会話していると、まるでAIが前回の話を覚えているように感じます。しかしその「記憶」は錯覚です。LLMの核心的性質は完全にステートレス（状態を持たない）であり、前回の会話を内部的に保持することはありません。ユーザーが体験する「ステートフル」な挙動は、すべてアプリケーション層が過去の会話履歴を毎回プロンプトに含めて再送信することで実現されています。

LLMは完全にステートレスである

ChatGPTやClaudeなどのLLM本体は、基本的には純粋な関数（入力に対して出力を返すのみ）であり、モデルそのものが「前回の会話状態」を保持することはありません。Anthropic APIやOpenAI APIのモデル本体は、サーバー側にセッションや会話状態を一切持たない純粋な関数として機能します。

ステートフルに見えるのは、アプリケーション側が毎回すべての文脈を再投入しているからです。モデルは毎ターン完全にリセットされ、「Context Package」として過去の会話履歴・システムプロンプト・ユーザー入力がまとめて送信されます。

記憶を持っているのは「誰」か？

「文脈を覚えている」と感じる背後には、4つの異なる層がそれぞれの役割でステート管理を担っています。

トークン累積のメカニズム（毎回フル送信）

会話履歴をすべて再送信する方式では、新しいメッセージを送るたびに過去の会話履歴をすべて再送信する必要があります。会話が何ターン続けられるかは、固定のターン数ではなく「合計トークン量」に依存します。

履歴の累積が引き起こす「O(N²)のトークン爆発」

送信トークン総量は会話の長さの2乗に比例して増加します。1ターンあたり1,000トークン増加するケースでは、50ターン目には累計1,275,000トークンに達します。

コスト影響：サブスクリプションモデルで「上限に当たりやすくなる」現象や、API利用におけるコスト急増の主因となります。

コンテキストウィンドウの4つの限界

コンテキストウィンドウには、単に「枠を広げる」だけでは解決しない4つの根本的な制約があります。物理的（VRAM）および数学的（計算量）な制約が重なり合っています。

巨大なコンテキストの死角「Lost in the Middle」

長いコンテキストウィンドウを詰め込むと、入力の先頭や末尾の情報は処理されやすいが、中間に配置された重要な情報が見落とされる現象が発生します。これが「Lost in the Middle」問題です。

具体例：冒頭で環境を「Mac」と指定し、中盤に大量の履歴を挟んだ後で質問をすると、モデルがWindows前提の回答をするリスクがあります。

トークン爆発の救世主：プロンプトキャッシュ

プロンプトキャッシュは、APIサーバー側でリクエストの先頭部分（Prefix）を一時保存し、再計算をスキップする技術です。同じプロンプトの「接頭辞（Prefix）」が一致すると、サーバー側で計算済みのKV状態を再利用します。

キャッシュの経済学（100Kコンテキスト × 20ターンの場合）

プロンプトキャッシュのコスト効果は劇的です。損益分岐点はわずか「2ターン目」。システムプロンプトやRAGの固定資料を先頭に固めることで、APIコストを劇的に圧縮できます。

キャッシュを最大化する設計ルール

キャッシュは「前方一致」で効くため、プロンプトの構造化が極めて重要です。「Bedrock to Sand」アーキテクチャに従い、固い（変わらない）情報を土台に、変動する情報を上に積みます。

限界を突破する3層のコンテキスト管理

トークン爆発とコンテキスト制限に対応するため、単一のコンテキストウィンドウにすべてを詰め込むのではなく、情報の鮮度と重要度に応じて3つの層を使い分けます。

永続的な心を作る：自律型エージェントの正体

「Hermes Agent」などの先進的な設計では、LLMのステートレス性を前提に、外側のシステムで「永続的な知能体」を構成しています。AIエージェントは、LLMの進化を待つのではなく、「外側の記憶システム」を構築することでステートフルな知能体を実現しています。

エージェントを形作る「3つの記憶」

認知科学における記憶の分類を、AIエージェントの設計に応用します。記憶は単一の構造ではなく、役割ごとに別々のデータベースと検索ロジックを持たせることが、高度なエージェントの条件です。

SYNTHESIS：認知アーキテクチャの全貌

すべてを統合すると、ステートレスな推論エンジンの周囲に、履歴管理・プロンプトキャッシュ・3層の外部記憶を緻密にオーケストレーションする「認知アーキテクチャ」が浮かび上がります。

我々はもはや「AIにプロンプトを投げている」のではありません。ステートレスな推論エンジンの周囲に、履歴管理・プロンプトキャッシュ・3層の外部記憶を緻密にオーケストレーションする「認知アーキテクチャ」を設計しているのです。

開発者のための3つのゴールデンルール

実践編：プロンプトキャッシュのテクニックとアンチパターン

プロンプトキャッシュの理論を理解しても、実装で台無しにしてしまうケースは非常に多いです。ここでは、キャッシュ効率を最大化するための具体的なテクニックと、無意識にキャッシュを破壊してしまう6つのアンチパターンを解説します。

プロバイダー別：キャッシュの基本仕様

プロンプトキャッシュの仕様はプロバイダーごとに異なります。設計時に把握すべき主要な違いを整理します。

キャッシュ効率を最大化する5つのテクニック

キャッシュを台無しにする6つのアンチパターン

以下は、キャッシュを「無意識に」破壊してしまう典型的なミスです。1つでも該当すると、キャッシュの恩恵が大幅に失われます。

Anthropic API でのキャッシュ実装例

# Anthropic API - プロンプトキャッシュの実装例
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "あなたはAIアシスタントです。...(長いシステムプロンプト)...",
            "cache_control": {"type": "ephemeral"}  # ← ブレイクポイント1
        }
    ],
    tools=[
        # ... ツール定義（順序を固定！）...
        # 最後のツールに cache_control を付与
        {
            "name": "search",
            "description": "...",
            "input_schema": {...},
            "cache_control": {"type": "ephemeral"}  # ← ブレイクポイント2
        }
    ],
    messages=[
        # 過去の会話履歴（シリアライズ方法を固定）
        {"role": "user", "content": "前回の質問..."},
        {"role": "assistant", "content": "前回の回答..."},
        # 最新のユーザー入力（末尾 = 動的部分）
        {"role": "user", "content": "今回の質問 + RAG結果 + タイムスタンプ"}
    ]
)

# キャッシュヒット率の確認
print(f"Cache Write: {response.usage.cache_creation_input_tokens}")
print(f"Cache Read:  {response.usage.cache_read_input_tokens}")  # ← これが大きいほど効率的
print(f"通常Input:   {response.usage.input_tokens}")

参考文献

• rural writer「Prompt Cache：10倍コストを下げる仕組みと、それを無意識に台無しにする6つのミス」Zenn, 2025.
  https://zenn.dev/ruralwritter/articles/4656b52b64a0ed
• Nous Research「Hermes Agent」 ― 永続的記憶システムを備えた自律型AIエージェントフレームワーク.
  https://github.com/NousResearch/hermes-agent
• agentskills.io ― AIエージェントのスキル設計・オーケストレーションに関するリファレンス.
  https://agentskills.io
• Anthropic「Prompt Caching」公式ドキュメント.
  https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

全スライド一覧