本記事は、Claude Code の Deep Research ワークフロー（計218エージェント、52ソース、50クレーム検証）を使って調査した「マルチエージェントLLMシステムの現在地」のレポートです。

「複数のAIに役割分担させて、大きなタスクをこなさせる」——この仕組みをどう設計するか、忘れや境界崩壊をどう防ぐか、世界の研究者やAnthropicがどう考えているかをまとめています。

調査の背景

日常的にClaude Codeを使っていると、自然と「役割を分けた複数エージェント」の構成を試したくなります。秘書役・調査役・実装役——それぞれに CLAUDE.md で役割を明文化し、ファイルで情報を共有する、という仕組みです（このサイトの運営も、そういった仮想組織システムで動いています）。

そこで疑問が生まれました。

  • この設計は研究の最前線と合っているのか？
  • 「AIが役割を忘れる」問題には、どんな解決策があるのか？
  • Anthropicはこの問題をどう捉えているのか？

第1部：学術SOTAの現状

階層型マネージャー/オーケストレーターパターン

2025〜2026年の複数論文で確認されている標準的な構成：

[Manager / Orchestrator]
        │
        ├── DAGによるタスク分解（依存関係を持つ流れ図）
        │
        ├── [Subagent A] ─┐
        ├── [Subagent B] ─┼──→ フィードバック → Manager が再計画
        └── [Subagent C] ─┘

グローバル計画エージェント（Manager）が高レベルの意思決定を担い、ローカル実行エージェントが実作業を行い結果をフィードバック。Managerはそれに応じて**適応的再計画（Adaptive Replanning）**を行います。

出典: arxiv 2503.13415（2025年3月サーベイ）/ arxiv 2410.22457（NeurIPS 2024）

コンテキスト境界の問題：「長すぎると読めなくなる」

「情報量が増えると精度が落ちる」——これは複数の研究で実証されています。

  • Lost in the Middle（TACL 2024）: 情報が文脈の中間にあると精度が30%以上低下
  • Chroma Research 2025: 調べた18種類のLLM全てで、コンテキスト長が増えるとF1スコアが単調減少

これは「忘れる」のではなく、長すぎると読めなくなる問題です。エージェント間で情報を渡す際には、要約・圧縮が不可欠です。

ドリフト問題：数学的には「暴走しない」

長い会話でエージェントが本来の役割からずれていく「ドリフト」について、Adobe Research（2025年10月）が数理モデルを提案しました。

重要な結論：ドリフトは「避けられない劣化」ではなく、均衡点に向かう制御可能な現象。暴走し続けるのではなく、ある落ち着きポイントに収束する傾向があるとのこと。

ただしこれはプレプリント（未査読）であり、独立した再現実験は未確認です。

AdaptOrch：トポロジーを自動選択（2026年2月）

最新の研究では、タスクの依存グラフを分析し、以下の4パターンから実行構造を動的に選ぶフレームワークも登場しています。

パターン用途
並列独立した複数タスク
逐次依存チェーン
階層Manager + Subagent
ハイブリッド混在タスク

第2部：Anthropicの設計哲学

「シンプルを優先」が一貫したトーン

“Start with simple prompts… and add multi-step agentic systems only when simpler solutions fall short.”

Anthropicは、エージェントシステムの複雑さを増やすことに対して明確に保守的な立場をとっています。これは建前ではなく、全設計ドキュメントに貫かれています。

Anthropicの4つのタスク分解パターン（検証スコア: 12-0）

パターン内容
Orchestrator-Workers中央LLMが実行時に動的分解・委譲（並列化との違いは「実行時の柔軟性」）
Parallelization独立サブタスクを並列処理
Specialization専門エージェントへのルーティング
Escalation複雑なサブタスクを高性能モデルへ委譲

コンテキストエンジニアリングの答え（検証スコア: 6-0）

Anthropicが公式ブログ（Effective Context Engineering）で示した実践的解法：

サブエージェントは何万トークンも自由に探索してよい
         ↓
オーケストレーターには 1,000〜2,000 トークンの要約だけ返す

「全情報を共有するのではなく、圧縮した要約を渡す」——これがコンテキスト汚染と忘れへの答えです。

Managed Agents APIの設計（2026年4月）

最新のManaged Agents APIより：

  • 共有するもの: ファイルシステム・サンドボックス・Vault認証
  • エージェントごとに分離するもの: 会話履歴・システムプロンプト・ツール・MCP

「ファイルは共有、コンテキストは分離」という設計思想です。

安全性の多層防御（検証スコア: 9-0）

Layer 1: RL（強化学習）による行動訓練
   → プロンプトインジェクションを「見抜いて拒否」する行動を直接訓練

Layer 2: ランタイムClassifier
   → テキスト・画像・UI要素に埋め込まれた悪意あるコマンドをリアルタイム検知

Layer 3: 人間による割り込み制御
   → いつでも止めて修正できる構造

Anthropicが認めているリスク

正直に書かれていることが印象的でした：

① プロンプトインジェクションは現時点で完全防止不可能

“No browser agent is immune to prompt injection.”

1%の攻撃成功率でも「意味のあるリスク」と明言。

② パーシステントメモリへの汚染（2026年5月 新警告）

CLAUDE.mdファイルや長期エージェントの状態ディレクトリに悪意ある指示が入ると、エージェント起動のたびに再ロードされ続ける。

ウェブスクレイピング結果などをそのまま永続ファイルに書き込まないことが推奨されています。

出典: How We Contain Claude（2026年5月）

第3部：ファイルベース仮想組織システムの評価

このサイトを運営している仮想組織システム（秘書役エージェント + 各部署 + 共有ファイル）を、今回の調査結果で評価してみました。

一致している点

手法システムの対応評価
階層型 Manager/Orchestrator秘書 = Manager、各部署 = Subagent✅
タスクを依存関係で管理queue.md の依存列（T-019→T-017 等）✅
コンテキスト注入各部署の CLAUDE.md で役割を明文化✅
要約して渡すnotes/ への要約記録✅
ドリフト緩和週次振り返り（Dreaming）・月次記憶整理（GC）✅
ファイル共有 + コンテキスト分離ファイルベース共有、CLAUDE.md でスコープ分離✅
シンプルを優先・段階的に複雑化秘書のみで開始、必要に応じて部署を追加✅

未達の点

手法現状
動的トポロジー選択（AdaptOrch）固定階層のみ 🔶
ドリフトの数値的計測・自動補正定性的な振り返りのみ 🔶
Escalation（高性能モデルへの委譲）全タスク同一モデル 🔶
CLAUDE.md汚染対策外部コンテンツの直接ペースト禁止ルールを追加 ⚠️

総合評価

「設計哲学・構造はSOTA・Anthropic推奨と一致。現時点のプロダクションとしては十分SOTAレベル。」

未達の機能（自動トポロジー選択・ドリフト数値制御・権限付き共有メモリ）は、商用フレームワーク・最新研究でもまだ提案段階です。完全な意味でのSOTAは、まだ誰も作れていません。

まとめ

調査を通じて見えてきたのは、「マルチエージェントシステムの設計は、研究者もAnthropicも同じ課題を抱えており、まだ解決の途上にある」ということです。

一方で、シンプルなファイルベースの実装でも、設計の方向性さえ合っていれば研究最前線と同じ問題に取り組めます。

今日から実践できること：

  • サブエージェントには探索させて、要約だけ返させる
  • 役割をファイルに明文化して、毎回コンテキストとして渡す
  • 外部コンテンツをそのまま永続ファイルに書き込まない
  • 週次でエージェントの振る舞いを振り返る

本調査は Deep Research ワークフロー 2回（218エージェント、52ソース、50クレーム検証）による。検証で否定されたクレーム（21件）は除外済み。