AIアシスタントに、競合製品を調査し、結果をまとめ、比較ドキュメントを作成し、チームにメールで送るよう依頼する。単一のエージェントはこれらの各ステップを実行できる——しかし、4つのタスクすべてにわたってコンテキストを維持しながら順番にうまくこなすのは、1つのエージェントセッションが優雅に処理できる限界を押し広げる。コンテキストウィンドウが埋まる。エージェントは前のステップを見失う。モデルが同時に多くの懸念を抱えているため、最終出力の品質が低下する。
これがエージェントスウォームが解決する問題だ。1つのエージェントがすべてを行う代わりに、コーディネーターエージェントがタスクをサブタスクに分解し、それぞれを専門エージェントに委任する。リサーチエージェントがWebを検索して構造化された調査結果を返す。ライティングエージェントがその調査結果を受けてドキュメントを作成する。メールエージェントが結果を送信する。各エージェントは独自のコンテナ内で、独自のコンテキストウィンドウを持ち、一つのことに集中して動作する。
このアイデア自体は新しくない——CrewAIやAutoGenは1年以上マルチエージェントパターンを探求してきた。NanoClawのアプローチが異なるのは、スウォーム内の各エージェントが独自の隔離されたコンテナで実行されるため、単一エージェントの会話に適用されるセキュリティと隔離の保証がマルチエージェントワークフローにも自動的に拡張される点だ。
NanoClawでのスウォームの仕組み
NanoClawのスウォームアーキテクチャは、シンプルなプリミティブの上に構築されている：エージェントが他のエージェントを起動できる。Claude Codeがコンテナ内で実行されるとき、利用可能なツールの一つがエージェント委任——サブタスクを記述してNanoClawに新しいコンテナを起動させる能力——だ。親エージェントは子エージェントが完了すると結果を受け取る。
オーケストレーションはClaude自身の推論を通じて自然に行われる。ワークフローグラフを定義したり、YAMLファイルでエージェントの役割を設定したりする必要はない。何が欲しいかを記述すれば、Claudeが直接処理するか、一部をサブエージェントに委任するかを判断する。この判断は、Claudeが複雑な問題を分解するのが得意な理由と同じ推論に基づいている——集中的な注意が有益な独立したコンポーネントがタスクにあることを認識するのだ。
実際には、これはコンテナのツリーのように見える。ルートコンテナがメッセージを受け取り、Web調査とドキュメント作成が必要だと判断し、2つの子コンテナを起動し、結果を待ち、最終レスポンスを統合する。各子コンテナは独自のCLAUDE.mdコンテキスト、独自のマウントされたワークスペース、独自のツールセットを持つ。リサーチエージェントはWeb閲覧が有効で、ライティングエージェントは共有ワークスペースへのファイル書き込みアクセスを持つ。どちらも相手のコンテキストやツールにアクセスできない。
スウォームにおけるコンテナ隔離の重要性
ほとんどのマルチエージェントフレームワークは、すべてのエージェントを同じプロセスで実行する。CrewAIのエージェントはPythonランタイムを共有する。AutoGenのエージェントは会話スレッドを共有する。これはデモでは動くが、スケールすると後から修正しにくい問題を生む。
第一の問題は被害範囲だ。スウォーム内の1つのエージェントがプロンプトインジェクションに遭遇した場合——エージェントの動作を乗っ取ろうとする悪意のあるウェブサイト——インジェクションはその単一のコンテナに封じ込められる。親エージェントに影響を与えられず、他の子エージェントのコンテキストにアクセスできず、元のユーザーの会話履歴を読み取れない。侵害されたコンテナは完了時に破棄され、親エージェントはその出力を受け取る（使用前に品質を評価できる）。
第二の問題はリソース競合だ。共有プロセス内のエージェントは、同じコンテキストウィンドウ、同じメモリ、同じCPUを奪い合う。NanoClawでは、各コンテナが独自のリソースを持つ。重いWebページを閲覧しているリサーチエージェントが、ドキュメントを作成しているライティングエージェントを遅くすることはない。コンテナは別々のスレッドで並行実行され、ホストのリソース管理がスケジューリングを処理する。
第三の問題は認証情報のスコーピングだ。リサーチエージェントにはWebアクセスが必要だがファイル書き込み権限は不要だ。ファイル管理エージェントにはディスクアクセスが必要だがWebアクセスは不要だ。共有プロセスフレームワークでは、これらの境界を強制するにはバイパス可能なアプリケーションレベルの権限チェックが必要だ。NanoClawでは、境界はコンテナマウントだ——リサーチエージェントは書き込み可能なパスがコンテナにマウントされていないため、文字通りディスクに書き込めない。
実用的なスウォームパターン
実際の使用から生まれるパターンは、理論的なアーキテクチャよりも興味深い。最も一般的なのはリサーチ＆統合パターンだ：親エージェントが質問の異なる側面を調査するために3〜5のリサーチエージェントを並列に起動し、調査結果を収集し、単一のエージェントが1回のパスで生成できるよりも徹底的な統合された回答を生成する。
第二の一般的なパターンはドラフト＆レビューだ。エージェントが初稿を書き、それを批評する指示を持つレビューエージェントを起動する。レビューのフィードバックは元のエージェント（または新しいドラフトエージェント）に戻されて修正される。レビューエージェントは新鮮なコンテキストウィンドウを持ち、書いた時の認知負荷なしにドラフトを評価できるため、シングルパス生成よりも明らかに良い出力を生む。
第三のパターンはツール特化だ。一部のタスクには高コストまたはリスクの高いツール——Web閲覧、シェルコマンド実行、ファイルシステム変更——が必要だ。親エージェントはこれらの操作を特定のツールアクセスを持つ子エージェントに委任し、自身のコンテキストをクリーンに、権限を最小限に保てる。親はファイルシステムやネットワークに直接触れない。子エージェントが返す結果のみを処理する。
スウォームの限界
スウォームは無料ではない。すべての子エージェントは別々のClaude API呼び出しであり、別々のトークンコストを意味する。5つのリサーチエージェントを起動するスウォームは、単一のエージェントがすべてのリサーチを行う場合のおよそ5倍のコストがかかる。シンプルな質問——「天気は？」や「この文を翻訳して」——にはスウォームは純粋なオーバーヘッドだ。
レイテンシも積み重なる。並列実行でも、親エージェントは結果を統合する前に最も遅い子の完了を待つ必要がある。5つのエージェントのスウォームで1つが遅いウェブサイトの閲覧に30秒かかる場合、他の4つがどれだけ速くても、ユーザーは30秒プラス統合時間を待つことになる。
NanoClawはこれを実用的に処理する。Claudeがタスクの複雑さに基づいてスウォームを使うかどうかを判断する——シンプルな質問には直接回答し、複雑なマルチパートのリクエストには委任する。ユーザーはスウォームの動作を設定しない。質問するだけで、システムが複雑さに合わせてアプローチをスケールする。目標はスウォームをどこでも使うことではなく、単一のエージェントよりも本当に良い結果を生む場面で使うことだ。
マルチエージェントの未来は、単一エージェントを置き換えることではない。単一エージェントに、必要なときに助けを呼ぶ能力を、安全で、隔離され、透明な方法で与えることだ。NanoClawのコンテナ・パー・エージェントモデルは、共有環境で複数のエージェントを実行することに伴うセキュリティの妥協なしにそれを可能にする。