AnimaWorks 脳科学5層記憶 × マルチエージェント「文脈崩壊」問題への解答

まさお@AI駆動開発さんが、マルチエージェントの最大の課題である「長期タスクで文脈が壊れる」問題に対して、脳科学ベースの記憶システムで挑むOSS「AnimaWorks」を紹介しています。

マルチエージェントの最大の課題「長期タスクで文脈が壊れる」に、脳科学ベースの記憶システムで挑んでいるOSSがある。それが『AnimaWorks』。エージェントを「ステートレスな関数」ではなく「組織の中の人」として設計するフレームワーク。

https://x.com/AI_masaou/status/2029134762447667373

21 いいね・2 RT を集めたこのポストが注目するのは、従来のマルチエージェントが抱えるコンテキストウィンドウの限界を、「記憶の蓄積・整理・忘却」というサイクルで乗り越えようとする設計思想です。

マルチエージェントの「文脈崩壊」問題

LLM の「記憶」の仕組み

まず前提として、LLM（ChatGPT や Claude など）には人間のような記憶がありません。LLM が「覚えている」ように見えるのは、会話の全履歴を毎回テキストとして入力に含めているからです。この入力テキスト全体をコンテキストウィンドウと呼びます。

┌─────────────────────────────────────┐
│  コンテキストウィンドウ（例: 200K トークン）  │
│                                     │
│  システム指示                          │
│  ユーザー: こんにちは                   │
│  AI: こんにちは！                      │
│  ユーザー: Pythonで関数を書いて          │
│  AI: def hello(): ...                │
│  ...（数百ターンの会話履歴）             │  ← 会話が長くなるほど膨らむ
└─────────────────────────────────────┘

ウィンドウの物理的限界

コンテキストウィンドウには上限があります（Claude で約 200K トークン、日本語で約 10〜15 万文字）。長期タスクでは会話履歴がこの上限に達し、古い情報から順に切り捨てられます。

タスク開始時:
  「このプロジェクトでは認証にJWTを使う方針です」  ← 重要な初期方針

... 200ターン後 ...

  「ログイン機能を実装して」
  → エージェントは JWT の方針を忘れており、
    セッション認証で実装してしまう

注意力の希釈（Lost in the Middle）

ウィンドウ内に収まっていても、情報量が多すぎると LLM の「注意力」が分散します。研究では、コンテキストの先頭と末尾の情報は活用されやすいが、中間部分は見落とされやすいことが分かっています。

[よく見る]  最初の指示 ─────── 重要な方針
[見落とす]  中間の会話 ─────── 途中で決めた例外ルール ← 消える
[よく見る]  最新のやり取り ──── 直近の質問

マルチエージェント特有の増幅

1つの AI との会話なら上記だけですが、複数エージェントが協調すると問題が増幅します。

┌──────────┐    ┌──────────┐    ┌──────────┐
│ Planner  │───→│ Coder    │───→│ Reviewer │
│ 独自の    │    │ 独自の    │    │ 独自の    │
│ コンテキスト│    │ コンテキスト│    │ コンテキスト│
└──────────┘    └──────────┘    └──────────┘

• 伝言ゲーム問題: Planner の方針を Coder に全文渡すとコンテキストを圧迫し、要約すると情報が欠落します。Reviewer に届く頃には「なぜその設計にしたか」が失われています
• コンテキスト爆発: 3つのエージェントが互いの出力を共有すると情報量が3倍に膨張し、エージェント数が増えるほど指数的に悪化します
• 状態の不整合: Planner が方針を変更しても、Coder が古い方針で作業を続けるケースが発生します

セッション間の断絶

会話が終わるとエージェントの状態は完全にリセットされます。

月曜日: 「認証はJWT、DBはPostgreSQL」と決定 → セッション終了 → 全て消える
火曜日: 「続きをやって」→ 何も覚えていない → 最初から説明し直し

週次レポートで見る具体例

第1週: 「売上データを集計してレポート作成して」
  → 手探りで CSV を読み、集計方法を試行錯誤 → 2時間で完成 → セッション終了

第2週: 同じ依頼
  → また手探りから開始 → また2時間、フォーマットも先週と微妙に違う

第3週: 同じ依頼
  → また最初から...（永遠に学習しない）

人間なら「先週こうやったから同じ方法で」と手続き記憶が働きますが、LLM にはこの仕組みがありません。

従来の対策と残る課題

Planner と Executor を分離してコンテキストを独立させる手法や、RAG（Retrieval Augmented Generation）で外部ストレージに情報を逃がす手法がありますが、「何を覚え、何を忘れるか」の判断は未解決の課題でした。

AnimaWorks の設計思想: Organization-as-Code

AnimaWorks はエージェントを「ステートレスな関数」ではなく「組織の中の人」として設計します。

各エージェント（Anima）は名前・性格・記憶・スケジュールを持ち、メッセージで連携しながら自律的に判断します。他の Anima の内部思考や記憶は見えず、テキストメッセージだけで通信します。実際の組織と同じ情報の非対称性が設計に組み込まれています。

AnimaWorks のアーキテクチャ詳解

全体構成

AnimaWorks は以下のレイヤーで構成されています。

┌─────────────────────────────────────────────────┐
│  Web UI / CLI                                   │
│  (FastAPI + Dashboard / Voice Chat / 3D)        │
├─────────────────────────────────────────────────┤
│  DigitalAnima                                   │
│  ┌──────────┬──────────┬────────────┐           │
│  │ Identity │ Memory   │ Agent      │           │
│  │ (名前,   │ Manager  │ Core       │           │
│  │  性格,   │          │            │           │
│  │  ロール) │          │            │           │
│  └──────────┴──────────┴────────────┘           │
├─────────────────────────────────────────────────┤
│  Execution Engines                              │
│  ┌────────┬────────┬────────┬────────┐          │
│  │ S:SDK  │ C:Codex│ A:Auto │ B:Basic│          │
│  │(Claude)│(OpenAI)│(LiteLLM│(1-shot)│          │
│  └────────┴────────┴────────┴────────┘          │
├─────────────────────────────────────────────────┤
│  Infrastructure                                 │
│  ┌──────────┬──────────┬──────────┬──────────┐  │
│  │ MCP      │ Tooling  │ Security │ Messenger│  │
│  │ Server   │ Dispatch │ (10層)   │ (組織間) │  │
│  └──────────┴──────────┴──────────┴──────────┘  │
├─────────────────────────────────────────────────┤
│  Storage                                        │
│  ┌──────────┬──────────┬──────────┐             │
│  │ ChromaDB │ File     │ RAG      │             │
│  │ (Vector) │ System   │ Engine   │             │
│  └──────────┴──────────┴──────────┘             │
└─────────────────────────────────────────────────┘

DigitalAnima クラス: エージェントの中核

DigitalAnima は AnimaWorks の中心的なクラスで、1つの Anima（エージェント）= 1つのディレクトリという原則で設計されています。

1
2
3

class DigitalAnima(MessagingMixin, InboxMixin, HeartbeatMixin, LifecycleMixin):
    """A Digital Anima: encapsulates identity, memory, agent, and communication.
    1 anima = 1 directory."""

4つの Mixin を継承し、関心ごとに機能を分離しています。

主要な内部コンポーネントは以下の通りです。

DigitalAnima
├── memory: MemoryManager      # 5層記憶の統括
├── agent: AgentCore           # LLM実行サイクル管理
├── model_config: ModelConfig  # モデル設定（ホットリロード対応）
├── messenger: Messenger       # 組織内通信（共有ディレクトリ経由）
├── _conversation_locks        # スレッド別排他制御
├── _task_semaphore            # 並列タスク実行制御
└── _status_slots              # ステータス管理（inbox/background）

4つの実行エンジン

AnimaWorks は LLM プロバイダごとに最適化された4つの実行エンジンを持ちます。

core/execution/
├── agent_sdk.py          # モード S: Claude Agent SDK
├── codex_sdk.py          # モード C: OpenAI Codex SDK
├── litellm_loop.py       # モード A: LiteLLM 自律ループ
├── base.py               # モード B: 基本1ショット
├── anthropic_fallback.py # フォールバック
├── _sdk_hooks.py         # セキュリティフック
├── _sdk_security.py      # コマンドフィルタリング
└── _sdk_session.py       # セッション永続化

モード S（Claude Agent SDK）の内部動作

モード S は AnimaWorks の最も高機能な実行エンジンです。Claude Agent SDK を介して Claude モデルを呼び出し、サブプロセスとしてツールを実行します。

┌──────────────┐
│ DigitalAnima │
└──────┬───────┘
       │ execute() / execute_streaming()
       ▼
┌──────────────────┐
│ AgentSDKExecutor │
│                  │
│  ┌────────────┐  │     ┌─────────────────┐
│  │ Claude API │──┼────→│ Anthropic API   │
│  │ (SDK)      │  │     │ / Bedrock       │
│  └────────────┘  │     │ / Vertex AI     │
│                  │     └─────────────────┘
│  ┌────────────┐  │
│  │ PreToolUse │  │  ← ツール実行前にセキュリティ検証
│  │ Hook       │  │
│  └────────────┘  │
│                  │     ┌─────────────────┐
│  ┌────────────┐  │     │ MCP Server      │
│  │ Tool       │──┼────→│ (subprocess)    │
│  │ Dispatch   │  │     │ aw_* ツール群    │
│  └────────────┘  │     └─────────────────┘
└──────────────────┘

利用可能なツール:

認証は4パターンに対応しています。

Claude Code との関係

AnimaWorks のモード S は Claude Agent SDK（Python ライブラリ）を使用しており、Claude Code（CLI ツール）とは別のレイヤーで動作します。

┌─────────────────────────────────────────────────┐
│ 人間が使うツール                                   │
│                                                 │
│  Claude Code (CLI)                              │
│    └→ ターミナルで対話的にコーディング               │
│    └→ Cowork でチーム生成                         │
│    └→ CLAUDE.md / Auto Memory で記憶              │
│                                                 │
├─────────────────────────────────────────────────┤
│ エージェントが使うライブラリ                         │
│                                                 │
│  Claude Agent SDK (Python)                      │
│    └→ AnimaWorks モード S が内部で使用             │
│    └→ プログラムからClaude APIを呼び出す            │
│    └→ ツール実行・セキュリティフックをコード制御       │
│                                                 │
├─────────────────────────────────────────────────┤
│ 共通基盤                                         │
│                                                 │
│  Anthropic API / Bedrock / Vertex AI             │
│    └→ Claude モデル本体                           │
└─────────────────────────────────────────────────┘

両者は競合ではなく、レイヤーが異なります。Claude Code は「人間が AI と一緒にコードを書く」ツールであり、AnimaWorks は「AI エージェント同士が組織として自律動作する」フレームワークです。Claude Code の CLI プロセスを AnimaWorks が内部で起動する機能は実装されていません。

メモリサブシステムの実装構成

記憶に関する実装は core/memory/ 以下に 28 ファイル + RAG サブディレクトリで構成されています。

core/memory/
├── manager.py             # MemoryManager: 5層記憶の統括
├── priming.py             # PrimingEngine: 5チャンネル並列検索
├── consolidation.py       # 記憶固定化の前処理・後処理
├── distillation.py        # エピソード→ナレッジ蒸留
├── forgetting.py          # 3段階忘却処理
├── reconsolidation.py     # 再固定化（記憶の更新）
├── conversation.py        # 会話履歴管理
├── shortterm.py           # 短期メモリ（セッション状態）
├── contradiction.py       # 矛盾検出
├── dedup.py               # 重複排除
├── validation.py          # 記憶の整合性検証
├── rag_search.py          # ベクトル検索
├── streaming_journal.py   # リアルタイム行動記録
├── task_queue.py          # タスクキュー管理
├── skill_metadata.py      # スキル記憶のメタデータ
├── activity.py            # 活動ログ統括
├── _activity_priming.py   # 活動ログからのPriming
├── _activity_conversation.py
├── _activity_timeline.py
├── _activity_rotation.py
├── _activity_models.py
├── config_reader.py       # 設定読み込み
├── frontmatter.py         # Markdownメタデータ解析
├── resolution_tracker.py  # Issue解決追跡
├── cron_logger.py         # 定期実行ログ
├── _io.py                 # ファイルI/Oユーティリティ
└── rag/                   # RAGエンジン（ChromaDB + sentence-transformers）

Priming の5チャンネル並列検索

PrimingEngine は asyncio.gather() で5チャンネルを同時実行し、メッセージの種類に応じてトークン予算を動的に調整します。

メッセージ種別ごとの基本トークン予算:

Consolidation の処理フロー

記憶の固定化は、Anima 自身が LLM を使って実行します。consolidation.py はその前処理（素材収集）と後処理（RAG インデックス更新）を担当します。

毎晩のサイクル:
  _collect_recent_episodes()     過去N時間のエピソードを収集
  _collect_activity_entries()    活動ログを~4000トークンに切り詰め
       ↓
  Anima が LLM で蒸留           「今日の経験から学んだこと」を生成
       ↓
  knowledge/ に保存              意味記憶として定着
  _update_rag_index()           ベクトルインデックス更新

問題解決時:
  _collect_resolved_events()    解決イベントを収集
       ↓
  Anima が LLM で手順化         「同じ問題の解決手順」を生成
       ↓
  procedures/ に保存            手続き記憶として定着

月次:
  monthly_forget()              古い記憶をアーカイブ・削除
                                RAG インデックス再構築

外部起源のファイル（他の Anima や人間が書いたもの）が検出された場合、信頼レベルが consolidation_external にダウングレードされます。これは「自分の経験」と「他人の情報」を区別する仕組みです。

脳科学にマッピングした5層記憶構造

AnimaWorks の記憶システムは、Tulving（1972）の記憶分類理論に基づく5層構造を採用しています。

脳科学の記憶分類

Tulving は人間の記憶を以下のように分類しました。

• エピソード記憶: 個人が経験した出来事の記憶。時間・空間的文脈と共に記録される
• 意味記憶: 世の中に関する一般的知識。概念間の関係を組織化して保持する
• 手続き記憶: スキルの自動化に関する潜在的記憶。意識せずに実行できる

下位のシステムほど発達が早く、長期間保持され、加齢や損傷に強いという特徴があります。

AnimaWorks の5層マッピング

コンテキストウィンドウに全てを詰め込むのではなく、「書庫型」で必要なときに自分で検索して想起する設計です。

記憶の進化サイクル: Priming → Consolidation → Forgetting

AnimaWorks の記憶システムの核心は、記憶が静的なデータベースではなく、成長・整理・忘却するライフサイクルを持つ点です。

Priming（想起）

メッセージを受信すると、5系統の並列検索が自動的に起動します。

1. 送信者プロファイル — 誰からのメッセージか、過去のやり取り
2. 直近の活動 — 最近何をしていたか
3. 関連知識 — テーマに関する学習済みの教訓
4. スキルマッチング — タスクに適したスキル記憶
5. 保留タスク — 未完了の作業キュー

検索結果はシステムプロンプトに注入され、エージェントは「思い出しながら考える」状態で応答します。これは人間が会話中に関連する記憶を無意識に想起するプロセスに相当します。

Consolidation（固定化）

睡眠中に記憶が整理されるように、AnimaWorks も定期的に記憶を蒸留します。

• 毎晩: エピソード記憶を意味記憶（Knowledge）に変換。「今日やったこと」が「学んだこと」になる
• 問題解決時: 解決した Issue が自動的に手続き記憶（Procedures）に変換される
• 毎週: Knowledge エントリをマージ・圧縮し、重複を排除する

たとえば週次レポート生成を任せると、初回は手探りでも、翌週以降は前回の手順が手続き記憶に定着し、過去の分析結果が意味記憶として蓄積されます。使うほど精度が上がる構造です。

Forgetting（忘却）

人間の脳が不要な情報を忘れるように、AnimaWorks も3段階で記憶を整理します。

1. Marking — 一定期間参照されなかった記憶にマークを付ける
2. Merging — マークされた記憶を類似の記憶とマージして圧縮する
3. Archival — さらに参照されなければアーカイブに移動する

ただし、重要な手続き記憶（Procedures）とスキル記憶（Skills）は忘却の対象外として保護されます。

他の記憶システムとの比較

AnimaWorks と同時期に、複数のエージェント記憶システムが登場しています。

AnimaWorks の特徴は、記憶システム単体ではなく「組織としてのエージェント設計」と記憶を統合している点です。他のシステムが記憶レイヤーとして汎用的に使えるのに対し、AnimaWorks は組織・階層・コミュニケーションと記憶を一体設計しています。

技術スタック

AnimaWorks は4つの実行モードを持ち、幅広いモデルに対応しています。

記憶・検索基盤には ChromaDB + sentence-transformers + NetworkX を使用し、RAG エンジンとして機能します。

セットアップ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# クイックスタート
curl -sSL https://raw.githubusercontent.com/xuiltul/animaworks/main/scripts/setup.sh | bash
cd animaworks
uv run animaworks start
# → http://localhost:18500/ でセットアップウィザード

# 手動インストール（Python 3.12+）
git clone https://github.com/xuiltul/animaworks.git && cd animaworks
python3 -m venv .venv && source .venv/bin/activate
pip install -e .
animaworks start

自律動作の設計

AnimaWorks のエージェントは「指示待ち」ではなく「自分の時計で動く」設計です。

• ハートビート: 定期的にタスクを自己確認し、必要な行動を自律的に判断する
• タスク委譲: マネージャー Anima が部下に委譲し、進捗を追跡し、報告を受領する
• 会話での生成: 「こういう人材がほしい」と伝えるだけで、ロール・性格・階層を自動設定した新しい Anima が作成される

6つのロールテンプレート（engineer, manager, writer, researcher, ops, general）が用意されており、組織構造を素早く構築できます。

セキュリティ: 10層防御

マルチエージェントが自律動作する以上、セキュリティは重要です。AnimaWorks は10層の防御機構を実装しています。

1. 外部データに対する信頼境界ラベリング
2. 5層コマンドセキュリティ（インジェクション検出 → ブロックリスト → 許可リスト → パストラバーサル検査）
3. エージェントごとのファイルサンドボックス
4. Unix Domain Socket によるプロセス分離
5. 3層レートリミット（セッション重複排除 + 30回/時 + 100回/日）
6. カスケード防止（10分間でエージェント間最大6ターン）
7. Argon2id パスワードハッシュ
8. HMAC-SHA256 Webhook 検証（Slack/Chatwork）
9. SSRF 軽減（IP ブロック + コンテンツ検証）
10. Fail-closed アウトバウンドルーティング

特にカスケード防止（10分間6ターン制限）は、マルチエージェントが暴走して無限ループに陥るリスクを構造的に防止する設計です。

まとめ

• **マルチエージェントの「文脈崩壊」**は、コンテキストウィンドウの肥大化とセッション間の記憶断絶が主因で、長期タスクの最大障壁となっている
• AnimaWorks の5層記憶は、Tulving の記憶分類理論（エピソード・意味・手続き記憶）を AI エージェントにマッピングし、コンテキスト詰め込みから「書庫型検索」に転換する
• Priming → Consolidation → Forgetting の循環が設計の核心で、記憶が成長・整理・忘却するライフサイクルを持つ
• **Consolidation（固定化）**により、日々のエピソードが毎晩ナレッジに蒸留され、解決した問題が自動的に手順書化される「使うほど賢くなる」構造
• Organization-as-Code はエージェントを「関数」でなく「組織の一員」として設計し、プライベート記憶・メッセージパッシング・階層構造を実現する
• 10層セキュリティ（カスケード防止、ファイルサンドボックス、レートリミット等）で自律動作のリスクを構造的に管理している
• Apache License 2.0 で公開され、Claude / GPT / Gemini / Ollama と幅広いモデルに対応している

参考

• まさお@AI駆動開発さんのポスト
• AnimaWorks GitHub リポジトリ
• 記憶の分類 — 脳科学辞典
• MIRIX: Multi-Agent Memory System for LLM-Based Agents
• Memory in the Age of AI Agents: A Survey
• コンテキストエンジニアリング + マルチエージェントでの解決法 — Insight Edge Tech Blog
• Memory for AI Agents: A New Paradigm of Context Engineering — The New Stack