ワーキングメモリエージェント（ワーキングメモリエージェント）
タスク実行中に中間結果や計画を一時保持するエージェントの短期記憶機構。人間の作業記憶（ワーキングメモリ）を模倣し、マルチステップ推論や複雑なタスク分解に必要な情報を一時的に管理する。
ワーキングメモリエージェントとは、AIエージェントがタスクを実行する際に中間結果・計画・仮説を一時的に保持する短期記憶の仕組みである。認知科学におけるBaddeleyのワーキングメモリモデル（1974年）に着想を得ており、「中央実行系（Central Executive）」がタスクの制御を行い、「音韻ループ」「視空間スケッチパッド」に相当するバッファが情報を一時保持する構造をLLMエージェントに適用する。
概要
LLMエージェントが複雑なタスク（コード生成、データ分析、調査レポート作成など）を実行する際、1回のLLM呼び出しでは完結しない。複数のステップにわたる推論が必要であり、各ステップの結果を次のステップに引き渡す仕組みが不可欠である。
2024年のReAct（Reasoning + Acting）パターン以降、エージェントのワーキングメモリは以下の要素で構成されるのが標準となった：
- スクラッチパッド: 中間計算結果や推論の過程を記録するテキストバッファ
- タスクスタック: 現在実行中のタスクとサブタスクの階層構造
- ツール呼び出し履歴: 過去に使用したツールとその結果のログ
- 仮説キュー: 検証待ちの仮説や候補リスト
2025年のClaude Code、2026年のOpenAI Codex CLIが商用実装の代表例であり、いずれもタスクの実行状態を構造化して管理している。
主な特徴・仕組み
- スクラッチパッド（Chain-of-Thought）: エージェントが推論過程をテキストとして書き出し、次のステップで参照する。GPT-4やClaudeの
<thinking>タグが典型 - タスク分解と管理: 大きなタスクを小さなサブタスクに分解し、進捗状況をTodoリストとして管理。Claude CodeのTaskCreate/TaskUpdateが該当
- 注意のフォーカス制御: ワーキングメモリの容量制限（通常5〜9チャンク）を模倣し、最も関連性の高い情報のみを保持。不要な中間結果は長期記憶に退避
- 自己モニタリング: エージェントが自身の進捗を定期的に評価し、行き詰まった場合は戦略を変更する。LangGraphのconditional edgesが実装手段
- 並列処理の同期: 複数の独立したサブタスクを並列実行し、結果をワーキングメモリで統合。Claude Codeのfork機能やCrewAIのtask delegation
- コンテキストの圧縮と退避: ワーキングメモリが肥大化した場合、完了済みのサブタスク結果を要約して圧縮し、コンテキストウィンドウの空きを確保
- 失敗からの回復: エラー発生時にワーキングメモリの状態をロールバックし、別のアプローチを試行する
ワーキングメモリ実装パターン比較
| パターン | 状態管理 | 容量 | 復元性 | 代表実装 |
|---|---|---|---|---|
| スクラッチパッド | テキストバッファ | コンテキスト長依存 | なし | ReAct/CoT |
| 構造化タスクリスト | JSON/Todoリスト | 数十タスク | 部分的 | Claude Code Tasks |
| ステートマシン | グラフノード | ノード数依存 | あり | LangGraph |
| メッセージキュー | イベントストリーム | 無制限 | あり | AutoGen/CrewAI |
| 永続化スクラッチパッド | ファイル/DB | 無制限 | あり | Devin/SWE-Agent |
具体例・対応製品
Claude Code: タスクの実行中にTaskCreate/TaskUpdate/TaskListツールでサブタスクを管理。各タスクにはstatus（pending/in_progress/completed）とblocked_byの依存関係が設定可能。forkによる並列実行とSendMessageによるエージェント間通信をサポート。
LangGraph: LangChainのステートマシン拡張。各ノードがエージェントの1ステップに対応し、エッジの条件分岐でワークフローを制御。StateGraph でワーキングメモリの状態を定義し、チェックポイント機能で任意時点の状態を保存・復元。
AutoGen（Microsoft）: マルチエージェントフレームワーク。各エージェントが独自のワーキングメモリ（チャット履歴）を持ち、GroupChatを通じて情報を共有。UserProxyAgentが人間のフィードバックを仲介する。
設計上の課題と対策
ワーキングメモリの最大の課題は「コンテキスト汚染」である。長いタスク実行中にワーキングメモリが肥大化し、重要な情報が古い中間結果に埋もれてしまう。対策として：
- 定期的な要約圧縮: 10ステップごとにワーキングメモリの内容を要約し、コンテキストを圧縮
- 重要度ベースのフィルタリング: 完了済みタスクの詳細は破棄し、結果のみを保持
- 階層的な情報管理: 高レベルの計画は常に保持し、低レベルの実装詳細は必要時のみ展開
関連用語との違い
| 用語 | 持続期間 | 目的 |
|---|---|---|
| ワーキングメモリ | タスク実行中のみ | 中間結果・計画の一時保持 |
| 永続メモリ | セッション間で永続 | ユーザー属性・好みの蓄積 |
| コンテキストウィンドウ | 1回の推論のみ | 入出力の管理 |
| エピソード記憶 | 長期 | 過去の体験の保存 |
よくある質問（FAQ）
Q1: ワーキングメモリの容量はどの程度が適切ですか？ A: 認知科学のMiller's Lawに基づき、同時に管理するサブタスクは7±2件が目安。LLMエージェントでも、ワーキングメモリに保持する情報チャンクを5〜10件に制限し、超過分は長期記憶に退避させるのが実用的である。
Q2: ワーキングメモリの状態を永続化すべきですか？ A: 長時間（30分以上）かかるタスクでは永続化が推奨される。LangGraphのCheckpointerやDevinのファイルベーススクラッチパッドのように、任意時点の状態を保存しておくと、エラー時の復元やタスクの中断・再開が可能になる。
Q3: マルチエージェント環境でのワーキングメモリ共有はどう設計しますか？ A: 各エージェントが独自のワーキングメモリを持ちつつ、共有メッセージキュー（AutoGenのGroupChat、CrewAIのShared Memory）で必要な情報のみを交換するパターンが標準。全エージェントが同一のワーキングメモリを共有すると、情報の衝突やコンテキスト汚染が発生しやすい。
まとめ
- ワーキングメモリはエージェントの複雑なタスク実行に不可欠な短期記憶機構
- スクラッチパッド、タスクリスト、ステートマシンなど複数の実装パターンが存在
- コンテキスト汚染の防止には定期的な要約圧縮と重要度フィルタリングが有効
- 長時間タスクでは状態の永続化（チェックポイント）が推奨
- マルチエージェントでは個別メモリ+共有キューのパターンが標準