ワーキングメモリアーキテクチャ（ワーキングメモリアーキテクチャ）
LLMエージェントがタスク実行中に一時的なコンテキスト情報を保持・操作するための短期記憶メカニズム。LLMのコンテキストウィンドウやスクラッチパッドとして実装され、タスク完了後に破棄または長期記憶へ昇格される。
ワーキングメモリアーキテクチャとは
ワーキングメモリアーキテクチャ（Working Memory Architecture）は、LLMエージェントがタスク実行中に必要な情報を一時的に保持・操作・更新するための短期記憶システムである。認知心理学者Alan Baddeley（1974年）が提唱したワーキングメモリモデルを基盤に、LLMのコンテキストウィンドウ管理やスクラッチパッド機構として実装される。
2026年現在のLLMコンテキストウィンドウは、Claude 3.5 Sonnetで200Kトークン、GPT-4oで128Kトークン、Gemini 2.0で2Mトークンと拡大しているが、全情報をコンテキストに詰め込むアプローチはコスト面（$0.003〜$0.015/1Kトークン入力）で非効率である。ワーキングメモリは「今のタスクに必要な情報だけ」を選択的にコンテキストに配置する設計思想だ。
Baddeleyモデルとの対応関係
| Baddeley（人間） | LLMエージェント | 実装例 |
|---|---|---|
| 中央実行系 | エージェントオーケストレータ | LangGraph / AutoGen Orchestrator |
| 音韻ループ | テキストバッファ | ConversationBufferMemory |
| 視空間スケッチパッド | マルチモーダル入力バッファ | GPT-4V画像コンテキスト |
| エピソードバッファ | タスクスクラッチパッド | Scratchpad / Chain-of-Thought |
スクラッチパッド実装
スクラッチパッドは、エージェントが推論過程や中間結果を書き留めるための一時記憶領域である。
基本パターン
[System] あなたはタスクを実行するエージェントです。
[Scratchpad]
- 現在のタスク: データベースの用語数を確認
- 取得済み情報: glossaryテーブルに13,902件
- 次のステップ: Meilisearch同期を実行
- 制約: Redis flushが必要
[/Scratchpad]
ReAct（Reasoning + Acting）パターン
Yao et al.（2022）が提案。思考（Thought）→行動（Action）→観察（Observation）のサイクルをスクラッチパッドに記録。
| ステップ | 内容 | トークン消費 |
|---|---|---|
| Thought 1 | 「まずDBの現在の件数を確認する必要がある」 | 〜50 |
| Action 1 | SELECT COUNT(*) FROM glossary | 〜20 |
| Observation 1 | 「13,902件」 | 〜10 |
| Thought 2 | 「新規5件追加後は13,907件になるはず」 | 〜40 |
| Action 2 | INSERT INTO glossary ... | 〜500 |
| Observation 2 | 「INSERT 0 5」 | 〜10 |
コンテキストウィンドウ管理戦略
1. Sliding Window（スライディングウィンドウ）
直近N件の対話のみを保持。古い対話は切り捨て。
- 利点: 実装が単純、コスト予測が容易
- 欠点: 重要な初期コンテキストが失われる
- 適用: カジュアルなチャットボット（N=10〜20ターン）
2. Summary Buffer（要約バッファ）
古い対話を要約して圧縮保持。LangChainのConversationSummaryBufferMemoryが代表実装。
- 利点: 長期コンテキストを少ないトークンで保持
- 欠点: 要約時の情報損失、要約コスト
- 適用: カスタマーサポート、長時間セッション
3. Selective Attention（選択的注意）
タスクに関連する情報のみをコンテキストに配置。MemGPT/Lettaの仮想ページングが代表例。
- 利点: 最も効率的なトークン利用
- 欠点: 実装複雑、関連性判断の精度に依存
- 適用: 複雑なマルチステップタスク
4. Hierarchical Context（階層コンテキスト）
システムプロンプト（固定）→タスク定義（半固定）→直近対話（動的）の3層構成。
- 利点: 重要度に応じた配置が可能
- 欠点: 層間の境界設計が必要
- 適用: 企業向けAIアシスタント
ワーキングメモリの容量最適化
| モデル | コンテキスト長 | 入力コスト/1Kトークン | 推奨WM割当 | 有効容量 |
|---|---|---|---|---|
| Claude 3.5 Sonnet | 200K | $0.003 | 30-50% | 60K-100K |
| GPT-4o | 128K | $0.005 | 30-50% | 38K-64K |
| Gemini 2.0 Flash | 1M | $0.00015 | 10-20% | 100K-200K |
| Llama 3.1 70B | 128K | ローカル | 40-60% | 51K-77K |
MemGPTの仮想ページング
MemGPT（Packer et al., 2023、現Letta）は、OSの仮想メモリ管理をLLMに適用した画期的な手法。
- メインコンテキスト: LLMのコンテキストウィンドウ（「RAM」に相当）
- アーカイブストレージ: 外部DB（「ディスク」に相当）
- ページイン/アウト: LLM自身が関数呼び出しで記憶の読み書きを制御
- 性能: 無制限の対話履歴を128Kコンテキストで管理可能
よくある質問（FAQ）
Q1: ワーキングメモリとプロンプトエンジニアリングの関係は？ A: ワーキングメモリはプロンプトエンジニアリングの上位概念である。プロンプトが「何を伝えるか」の設計なら、ワーキングメモリは「いつ・どの情報をコンテキストに配置するか」の動的管理を担う。Few-shot例の選択的配置もワーキングメモリ管理の一種。
Q2: コンテキストウィンドウが無限に大きくなればワーキングメモリは不要ですか？ A: 不要にはならない。Gemini 2.0の1Mトークンコンテキストでも、全情報を入れると入力コストが増大（$0.15/リクエスト）し、Lost-in-the-Middle問題（中間部の情報が無視される現象）も発生する。選択的配置は常に有効。
Q3: ワーキングメモリの最適サイズはどのくらいですか？ A: タスク依存だが、認知科学のMiller's Law（7±2チャンク）を参考に、「同時に保持すべき概念数」を5〜9に制限し、各概念に割り当てるトークン数（500〜2,000）を掛けた値（2,500〜18,000トークン）が実用的な目安。残りはシステムプロンプトと出力バッファに充てる。
まとめ
- ワーキングメモリはタスク実行中の一時的コンテキスト管理メカニズム
- スクラッチパッドやReActパターンで中間推論を記録
- Sliding Window・Summary Buffer・Selective Attention・Hierarchical Contextの4戦略
- MemGPTの仮想ページングが最も先進的な実装
- コンテキストウィンドウ拡大後も、コスト最適化とLost-in-the-Middle対策で必要性は維持