Agentastic、AgentsRoom、CodeAgentSwarm、Paseo：オーケストレーターは違っても、土台は一つ

この一年で、新しい形のツールが現れました。まだ定まった名前がありません。Agentastic、AgentsRoom、CodeAgentSwarm、Paseo——表面の違いの下にあるのは、どれも同じ発想です。一つの環境で複数のコーディングエージェント CLI を同時に走らせる——ここでは Claude Code、あちらでは Codex、三つ目のワークツリーでは別のエージェント——そして人が編隊を監督する。マルチエージェント・オーケストレーターと呼んでおきます。

彼らは、自分が解く問題には長けています。しかし、どれも「仕事の記録」ではありません。その隙間が本記事の主題です——並行して走らせるエージェントが増えるほど、その隙間は早くあなたを見つけます。

四つのツール、簡単なプロフィール

違いは本物です——ネイティブかクロスプラットフォームか、商用かオープンソースか、エージェントごとにワークツリーか、プロジェクトごとに窓か。しかし類似点のほうが重要です。どれもが答えているのは「誰が、どこで、並行に走るか」です。

彼らが共有する盲点

四人のエージェントを並行に走らせれば、四つの仕事の流れ——そして四つのスクロールバックが得られます。コードは安全です。ワークツリーが隔離し、git が記録します。しかし、コードの周りにある調整の事実には、耐久性のある住所がありません。

• どのエージェントが何をしていて、各タスクの「完了」とは何を意味するか
• エージェントBのセッションでなされた判断が、エージェントAのすべきことを変えること
• 人が9時03分にチャットのプロンプトで承認した一件と、まだ承認を待つ三件
• あるタスクがなぜ放棄されたか——次のセッションが使える言葉で

オーケストレーターが管理するのはプロセスです。起動、停止、切り替え、監督。彼らは「仕事の事実が蓄積される場所」として作られてはおらず、そのセッションはどのエージェントのセッションとも同じく儚いものです。一日が終われば、編隊の共有理解も一緒に終わります——単独エージェントの引き出し問題と同種の問題が、並行性によって増幅されただけです。

その下に共有の記録層があると、何が得られるか

解法は、オーケストレーターのもう一つの機能ではありません。そのすべての下に敷く一層です。タスク、判断、仕事の状態をレコードとして保持する一つの基盤。どのオーケストレーターが起動したエージェントであっても、行動の前に読み、終われば書き込む。具体的には：

• タスクの状態は編隊より長生きします。 Agentastic で走るエージェントと Paseo で走るエージェントが同じプロジェクトに取り組むとき、見るのは同じタスク一覧、同じ判断、同じ未解決の問い。オーケストレーターを替えることが、最初からやり直す意味ではなくなります。
• 判断は入力になります。 あるセッションで下された決定は、次のセッションが読むレコードであり、見つけられない記録の写しの中に埋もれた段落ではありません。
• 承認に正当な家ができます。 重みのある成果——あの移行、あの顧客向けの変更——は diff を伴う変更リクエストとして待機でき、通常の更新は直接着地します。監督は、見張らなければならないスクロールバックではなくなります。
• CLI は交換可能な部品になります。 上の表で CodeAgentSwarm の一覧に注目してください。Antigravity CLI は Claude Code や Codex と並んで、同じ屋根の下のもう一つのエンジンとして座っています。これがカテゴリ全体の方向です——エンジンは替わる。替わってはならないのは記録です。

表のツールはすべて、その形で Busabase に接続できます——Agent Skill または MCP 経由で、変更リクエストのワークフロー込み。それこそが要点です。基盤は、今四半期にどのオーケストレーターが流行っているかを気にしません。

引き継ぎ：盲点が牙をむく瞬間

「paseo handoff」のような検索が本当に問うているのは、仕事が移動するとき——あるエージェントから別のエージェントへ、デスクトップからモバイルへ、今日のセッションから明日へ——何が起こるかです。チャットの書き出しで運ぶ引き継ぎは、言葉を運んでも状態を運びません。機能する引き継ぎは、次の四つをレコードとして運びます。

1. タスクの状態——何が終わり、何が進行中で、何がどこで詰まっているか。
2. なされた判断——そして、その理由。受け手が実際に読む形で。
3. 未解決の問い——明示的にまだ決まっていないこと。受け手が勢いで静かに決めてしまわないように。
4. 成果物——成果そのもの。チャットのスレッドではなく、それが属するタスクにリンクして。

この四つが共有の基盤に住んでいれば、引き継ぎとは次のエージェントが基盤を読むことであり、「引き継ぎ」は失敗しうるイベントではなくなります。それらがオーケストレーターのセッションに住んでいれば、引き継ぎのたびに小さな移行が起き、小さな移行こそが文脈の死ぬ場所です。

隣接する形、同じ結論

同じ検索群から、もう二つの名前にも一行を割く価値があります。オーケストレーターではありませんが、同じ必要に着地するからです。Grok Bot——xAI の常時稼働する AI チームメイトで、各 Bot が独自の永続的なクラウド VM を持つ——は賭け金を逆方向に押し上げます。眠らないエージェントは四六時中、事実を生みます。「これは誰がレビューしたのか」は、修辞的な問いではなくなります。Hermes Agent——Nous Research の自律型ターミナルエージェント——は、自身の永続的な記憶とスキルを備えています。それは一人のエージェントについては問いに答えますが、二つ目のツールが Hermes の知っているものを必要とする日に、問いを再び開きます。どちらの場合も、検索（「grok bot mcp」「hermes agent mcp」）は同じ場所に終わります。エージェントを共有の記録に接続し、その知ることと行うことが、自身のランタイムの中に閉じ込められないようにすることです。

オーケストレーターは増え続けます——それは健全なカテゴリがその仕事をしている姿です。あなたの編隊を最もよく走らせるものを選んでください。ただし、それに仕事の記憶まで担わせないでください。それは別の層であり、あなたのものであり、その上のすべてが替わるときに、替わってはならない唯一のものであるべきです。

よくある質問

組み込みの共有メモリがあるかどうかで、オーケストレーターを選ぶべきですか。 一つのオーケストレーターの内蔵メモリは、仕事がそのツールの外に出るまで役に立ちます——二つ目のオーケストレーター、常時稼働のボット、同僚の別の構成。オーケストレーターはエージェントの実行の良し悪しで判断し、記録層は別に判断して、どのツールからも届くものを優先してください。

エージェントが今日、全部ひとつのツールの中で走っています。それでも必要ですか。 必要になるのは、二人目のエージェントが、一人目が依存するものを書き始める日です——そしてマルチエージェント IDE の中では、それはたいてい初日です。並行ワークツリーとはまさに、一つのセッションの判断がもう一つのセッションを静かに無効化する構成であり、両者が同じ記録を読んでいない限り、それは続きます。