CLI で自力実装した Hub-Worker 構成と Managed Agents API を比較してみた

Anthropic が Managed Agents API を公開したので、自前の Hub-Worker 構成と並べてみたら構造がほぼ同じだった。Claude Code CLI を tmux で 8 インスタンス並走させて自力で組んだものが、Anthropic の公式基盤と同じ設計になっていたというのは、なんとも不思議な感覚だ。

この記事では以下 3 機能を自前構成と比較しながら整理する:

1. Managed Agents API — エージェント定義・環境・セッション・イベントを一式管理するクラウド基盤
2. Multiagent sessions — Coordinator が複数 Worker を並列・直列に束ねるマルチエージェント実行基盤（Research Preview）
3. Dreams — 過去セッションのログを読んで memory store を自動整理・再構築する非同期ジョブ（Research Preview）

自前構成の概要

参考までに今の自前構成を簡単に説明する（詳しくはこの記事）。

• Claude Code CLI インスタンス × 8 を tmux セッションで管理
• Hub インスタンスがタスクを分解し、Worker インスタンスに GitHub Issues 経由で委譲
• Worker へのトリガーは tmux send-keys ベースのスクリプト
• ガバナンスルールは POLICY.md に明文化し、各インスタンスが自律参照

自前 Hub-Worker 構成

User（たけやす）

▼ tmux send-keys

Hub（Claude Code CLI）
tmux: cl_orchestrator · POLICY.md でガバナンス

▼ GitHub Issues 起票 + tmux send-keys トリガー

BlogGen

ImgGen

ClaudeChat

… × 5

▼ 読み書き

WSL2 ファイルシステム / Git リポジトリ群

Managed Agents API の構造——並べてみると激似だった

Managed Agents API のドキュメントを読んで最初に思ったのは「あ、これ自分で作ったやつだ」だった。コアコンセプトを自前構成と対比すると：

Managed Agents API の概念	自前構成の対応物
Agent（モデル・system prompt・ツール定義）	CLAUDE.md + settings.local.json でロールを定義した各 CLI インスタンス
Environment（コンテナ・パッケージ・ネットワーク設定）	WSL2 + 各リポジトリの .venv・パス設定
Session（タスクを実行するエージェントの実行インスタンス）	tmux セッション内の Claude Code プロセス
Events（アプリ↔エージェント間のやり取り）	GitHub Issues への書き込み + tmux send-keys によるトリガー

Managed Agents API 構成

Your App

▼ Events API（SSE）

Session（primary thread）

Coordinator Agent
モデル / system prompt / tools / MCP を定義

▼ session threads（最大 25）委譲 1 レベルのみ

Worker
Agent 1

Worker
Agent 2

Worker
Agent 3

… 最大
20種

▼ 読み書き

共有コンテナ
ファイルシステム

Memory Store
（永続メモリ）

対応表と図を見比べると、設計はほぼ一致している。ただし実装上の差は大きい。Pros & Cons をまとめると：

観点	Managed Agents API	自前構成（Claude Code CLI）
初期ツール	自前定義が必要	Bash/Read/Write/MCP が最初から全部乗っている ✅
Linux 資産の活用	要別途設計	apt install や設定変更まで自律実行できる ✅
観測性	イベントストリームで全スレッドをリアルタイム把握 ✅	tmux 出力を目視か Monitor で追う
インフラ運用	Anthropic 管理。環境維持不要 ✅	WSL 維持が必要。ただし git から復元できる
料金	API トークン従量課金。大量実行でコスト跳ね上がりリスク	Max プランの月額固定。ヘビーユースでも定額 ✅
移行コスト	CLI 資産は移植不可。全面書き直し	なし（現状維持）✅

Multiagent sessions——公式版が解決している問題

Multiagent sessions のドキュメントを読んで、自前構成との差が明確になった箇所がいくつかある。

ボールロスの検知。各エージェントは session thread（コンテキスト分離されたイベントストリーム）で動き、状態変化は session.thread_status_idle / session.thread_status_running などのイベントとして primary thread に集約される。自前構成では「誰も次のボールを投げない」状態は何も発火しない——これが最大の盲点だった。公式版はここが構造的に解決されている。

ツール確認の集約。子エージェントが確認待ちになると requires_action が primary thread に cross-post される。自前構成では各インスタンスの確認要求が分散していて、見落としが起きやすい。

なお {"type": "self"} を使うと Coordinator が自分のコピーを並列展開することもできる。スレッド上限・委譲深さ・アクセス要件は以下の表を参照。

観点	Multiagent sessions	自前構成（tmux + GitHub Issues）
ボールロス検知	thread_status_idle で構造的に検知 ✅	誰も投げない状態は無音。目視かポーリングが必要
ツール確認の集約	requires_action が primary thread に一元集約 ✅	インスタンスごとに分散。見落としが起きやすい
コンテキスト引き継ぎ	スレッド永続。追加指示で前の文脈が引き継がれる ✅	同左（tmux セッションが生きている限り引き継ぐ）✅
委譲の柔軟性	1 レベル固定（深さ制限は基盤保証）	POLICY.md の設計次第で柔軟に変更できる ✅
スケール上限	スレッド 25・エージェント 20 の固定上限	ハードウェアと Max プランの許す限り無制限 ✅
アクセス要件	Research Preview・別途アクセスリクエスト必要	今すぐ使える ✅

Dreams——メモリ整理の自動化

Dreams は memory store を非同期バッチで整理・再構築する機能（Research Preview・要アクセスリクエスト）。入力の store は一切変更しないので、気に入らなければ出力を捨てられる。

仕様の要点：

• 入力：既存 memory store（必須）＋ 過去セッション最大 100 件（任意）
• instructions パラメータでキュレーションの方向付けが可能（最大 4,096 字。例：「コーディングの好みに絞れ、一時的なデバッグメモは無視しろ」）
• 対応モデル：claude-opus-4-7 / claude-sonnet-4-6
• 料金：通常 API トークン課金。入力セッション数・長さに比例
• ベータヘッダーは managed-agents-2026-04-01,dreaming-2026-04-21 の 2 つが必要

自前構成では memory の更新は手動で、インスタンスが増えると追いつかなくなる。「既存 store がなくても空ストアを作ってセッションログだけを入力にできる」とドキュメントに書かれており、段階的な導入が現実的にできる点は大きい。

観点	Dreams	自前構成（手動 memory 管理）
実行トリガー	cron や任意タイミングで自動実行。ユーザー不在でも動く ✅	「学習して」と依頼したときのみ
スケール	インスタンス数に依存せず同じフローで回せる ✅	インスタンスが増えると人間が追いつかなくなる
安全性	入力 store を変更しない。出力を確認してから差し替えられる ✅	直接書き換えのため意図しない改変の検知が難しい
コスト	セッション量に比例して課金増。大量処理でコスト跳ね上がりリスク	Max プラン内に収まる（追加コストなし）✅
完了までの時間	数分〜数十分（非同期ジョブ）	会話の中で即時実行 ✅
アクセス要件	Research Preview・追加ヘッダー・アクセスリクエスト必要	今すぐ使える ✅

CLI で自力実装した経験が教えてくれたこと

自分でスクラッチから組んだことで、Managed Agents API のドキュメントを読んだとき「なぜこの設計なのか」がすぐ腑に落ちた。ロスターの 1 レベル制限・スレッドの永続性・primary thread への集約——どれも自前実装でぶつかった問題に対する答えだった。

「生成 AI を使える」は当たり前になりつつある。次に差がつくのは——エージェント間の責任境界の引き方、コンテキスト設計、障害検知と回復の設計など、実際に組んで壊してみないと身につかない経験値だと思う。早期クラウドアーキテクトが「AWS を知っていた」より「オンプレの失敗パターンをクラウドでどう回避するか」を語れた理由と同じだ。

自前構成を持っている今は、API への移行コストより現状の自由度と定額コストのほうが優先度が高い。ただ Worker を大幅に増やしたい・24 時間無人稼働を常態化させたい段階が来たら、その時点で移行を考えると思う。

まとめ

CLI で自力実装した Hub-Worker 構成と Managed Agents API を並べたら、設計がほぼ同じだった。Multiagent sessions が明確に勝っているのは「ボールロスの構造的な検知」と「ツール確認の一元集約」。Dreams は手動では追いつかないメモリ管理のスケール問題に応える機能で、空ストアからの段階的導入が可能。

この記事が参考になったら X（Twitter）でシェアしてもらえると喜びます。

よくある質問

Q. Managed Agents API は今すぐ使えますか？

A. API アカウントがあればデフォルトで有効です（ベータヘッダー managed-agents-2026-04-01 が必要）。Multiagent sessions と Dreams は Research Preview で別途アクセスリクエストが必要です。

Q. 自前構成から Managed Agents API への移行は大変ですか？

A. CLI の資産（Bash スクリプト・MCP サーバー・ポリシーファイル）は移植できないため、実質全面書き直しです。移行するなら新規プロジェクトとして設計し直すのが現実的です。

Q. Max プランのまま Managed Agents API は使えますか？

A. Managed Agents API は API 従量課金です。Max プランとは別に API の利用料が発生します。Dreams はセッション量に比例するため、スモールバッチでコストを確認してから本番規模に上げることをお勧めします。

※本記事の情報は執筆時点（2026 年 5 月）のものです。Managed Agents API はベータ機能のため仕様が変更される場合があります。最新情報は Anthropic 公式ドキュメント を参照してください。

このブログを書いた人のアプリ

本ブログの著者が作った iOS 読書管理アプリ わたしのほんやさん を App Store で公開しています。本棚をシンプルに管理したい方はぜひ。

App Store で見る →

関連記事

• Claude Code 同士が相談しながら開発したら10人チームが3日で自然発生した話【Hub-Worker 構成公開】
• tmux + Tailscale + Termius でスマホから Claude Code を動かす最短手順【母艦ハブ型】

参考

• Anthropic — Claude Managed Agents overview
• Anthropic — Multiagent sessions
• Anthropic — Dreams

※この記事は Claude Code を使った自動更新を試しています。