Fuga 5001機能比較

同時：multi-agent の同時スレッド数（親を除く）。既定は V1=6・V2=3、agents.max_concurrent_threads_per_session で変更。 累計・延べ：1実行・1日の累計上限は未公表。消費はプランの利用枠に含まれる。

• 種別：協調スウォーム＋独立並列
• 1タスク内では親Agentが専門Subagentへ委任し、結果を回収・統合する真の協調（spawn・待機・メッセージ・resume）を持つ。一方で1タスクの同時数は既定で親を除き6（V1）または3（V2）と小さく、100体規模のスウォームを前提にした設計ではない。Desktopの複数チャット／worktree、Cloudの複数タスクは相互連携のない独立並列セッションで、同時数の公式上限は確認できなかった。
• 協調タスク内の同時数｜6 体（同時・親を除く）｜既定値｜Codex CLI/Desktop/IDE の multi-agent V1（features.multi_agent=Collab、既定有効）。リポジトリ HEAD 970111f6cb（2026-10-23）
• 協調タスク内の同時数｜3（総スレッド4・root含む） 体（同時・親を除く）｜既定値｜multi-agent V2（features.multi_agent_v2、または V2 を指定するモデル。GPT-5.6 系の Desktop で確認報告あり）
• 協調タスク内の同時数｜8（公式例）／6（公式例） 体（同時・親を除く）｜設定可能値｜公式 Subagents ドキュメントの設定例（PR review 例 8、frontend debugging 例 6）
• 1実行の累計｜上限未確認 体（累計）｜公式上限｜Codex multi-agent 全般
• 1日の延べ｜上限未確認 体（日延べ）｜公式上限｜-
• 独立した並列セッション｜上限の記載なし セッション・タスク｜公式上限｜Desktop の複数チャット／worktree 並列、Codex Cloud の並列タスク
• 登録・定義できる数｜上限の記載なし 個（カスタムエージェント定義）｜設定可能値｜~/.codex/agents/ と .codex/agents/ の TOML 定義

同時：swarm_init の maxAgents は既定15・1〜50。swarm記録上の登録上限で、実際の同時稼働はホスト側（Claude Code等）が決める。 累計・延べ：1実行の累計上限は見つからず。daemonが自動で起こすclaude子プロセスだけは既定12起動/日。

• 種別：協調スウォーム＋独立並列
• Ruflo 自体は LLM を起動する実行器ではなく、Claude Code・Codex の周囲で swarm/hive-mind の調整記録（topology・maxAgents・合意）と agent_spawn の登録を行う調整層。階層・メッシュ型の委任・合意の仕組みは実装されているが、同時に何体が実際に動くかは Claude Code の Task（run_in_background）等ホスト側で決まり、Ruflo は上限を強制しない。#2028 では hive-mind 協調が一部ホストで無言で失敗した報告あり。協調の仕組みはあるが規模の実測値は公開されていない。
• 協調タスク内の同時数｜15（範囲 1〜50） 体（swarm 登録上限）｜既定値｜Ruflo v3.61.1 MCP swarm_init（hierarchical-mesh 既定）
• 協調タスク内の同時数｜15（範囲 1〜1000） 体（hive-mind 登録上限）｜既定値｜Ruflo hive-mind_init
• 協調タスク内の同時数｜100（ライブラリ既定）／例 15・50・100 体（登録上限）｜設定可能値｜@claude-flow/swarm UnifiedSwarmCoordinator（npm 3.0.2）
• 協調タスク内の同時数｜6〜8（推奨）／8（設定例）／15（init 既定・config 例） 体｜既定値｜ruflo-swarm プラグイン・CLAUDE.md・swarm init 既定値
• 1実行の累計｜未確認（公称なし） —｜公式上限｜Ruflo 全体
• 1日の延べ｜12（上限・daemon 自動起動の claude 子プロセス） 起動/日｜既定値｜Ruflo daemon の自律ワーカー（global-ai-budget）
• 独立した並列セッション｜15（daemon workers 既定の同時実行 10） 本｜既定値｜Ruflo background workers / worker-dispatch
• 登録・定義できる数｜100+（定義済み種別） 種｜提供元の公称｜Ruflo README

同時：Cue の max_concurrent は Agent ごとに1〜10（既定1）。独立セッションの並列は「無制限」と公称するのみ。 累計・延べ：1実行・1日の累計の公表・報告なし。Auto Run は1文書内を直列実行。

• 種別：協調スウォーム＋独立並列
• 2種類の機構がある。(1) 無制限と公称する独立セッション並列（相互連携なし。Cross-Agent Mentionsの@は単発の相談）。(2) 連携を伴う協調：Group ChatのModeratorが異種Agentへ委任・追質問・結果統合（参加数上限の記載なし）、Cueのfan-out/fan-in・agent chaining（Agentごと同時1〜10）。数値で確認できる同時数はCueの1〜10のみで、Group Chatの規模は未公表。両者は単位が異なるため合算しない。
• 独立した並列セッション｜上限記載なし（「unlimited」と公称） 体（独立セッション）｜提供元の公称｜Maestro デスクトップ（README / docs features.md）
• 登録・定義できる数｜上限記載なし（同上） 体（登録Agent）｜提供元の公称｜Maestro デスクトップ
• 協調タスク内の同時数｜1〜10（既定1） 件（Agentごとの同時Cue実行）｜設定可能値｜Maestro Cue（イベント駆動の自動実行）settings.max_concurrent
• 協調タスク内の同時数｜上限記載なし（並列で委任） 体（Group Chatの参加Agent）｜既定値｜Group Chat（Moderatorが委任）
• 1実行の累計｜未確認 —｜既定値｜Auto Run / Playbooks
• 1日の延べ｜未確認 —｜既定値｜—

同時：1タスクを複数エージェントで協調させる機能はなし。独立Workspaceの並列数に上限設定はない。 累計・延べ：実行単位・日次の上限設定はコード・docsになし。上限は各CLIの契約・API制限に依存。

• 種別：独立並列のみ（内蔵の協調なし）
• 多数のWorkspace/Sessionを独立に並列で開ける製品で、相互連携・委任・結果統合を担う内蔵の統括役は無い。MCPサーバー(start_workspace/create_session/run_session_prompt/get_execution)で外部MCPクライアントが複数CLIへ指示し結果を取得することはでき、これは外部統括による方式。内蔵の協調スウォームとは区別する。
• 独立した並列セッション｜上限の設定なし（数値は公表されていない） Workspace（独立並列）｜公式上限｜Vibe Kanban v0.1.45 / ローカルWorkspace
• 独立した並列セッション｜1 Workspace内に複数Session（数の上限なし） Session｜既定値｜Workspace内のSession
• 協調タスク内の同時数｜未提供（1タスクで複数エージェントを協調させる機能なし） 体（同時）｜公式上限｜Vibe Kanban v0.1.45
• 1実行の累計｜未確認（累計起動数の上限・設定は無い） 体｜公式上限｜Vibe Kanban v0.1.45
• 1日の延べ｜未確認（日次上限なし） 体/日｜公式上限｜Vibe Kanban v0.1.45
• 登録・定義できる数｜10種類のCLIから選択 種（Executor）｜公式上限｜Claude Code・Codex・Gemini CLI・Copilot・Amp・Cursor・OpenCode・Droid・CCR・Qwen Code

同時：非同期Taskは1件1スレッド、akickoff_for_each は件数上限なく同時実行（v1.15.30の実装）。AMPの同時数は未公表。 累計・延べ：AMP Basic は月50実行まで（公式料金表）。Enterpriseは個別。1実行の定義エージェント数に上限の記載なし。

• 種別：協調スウォーム＋独立並列
• 1つの Crew 内では Manager による委任（allow_delegation の Delegate Work / Ask Question ツール、階層プロセス）と、タスク context による結果統合があり、相互連携を伴う協調。ただし同時並列は『非同期Task（1件1スレッド）』をコードで明示する方式で、階層プロセスの docs は『Sequential Task Progression』と記載。多数同時実行は akickoff_for_each（互いに連携しない独立実行）が主で、数十体規模のスウォームを標準で組む機構・実測・公式事例は確認できない。
• 登録・定義できる数｜上限の記載なし（Crew の agents はリスト） 体（定義）｜公式上限｜CrewAI OSS 1.15.30 の Crew／AMP に配備した Crew
• 協調タスク内の同時数｜タスク数の制約まで（非同期タスク1件＝1スレッド、上限値なし） 件（同時の非同期Task）｜既定値｜CrewAI OSS 1.15.30 Crew.kickoff の Task(async_execution=True)
• 1実行の累計｜上限値なし（Agent は max_iter 既定20回／タスク） 体・タスク（1回の kickoff）｜設定可能値｜CrewAI OSS 1.15.30 の Crew 1実行
• 独立した並列セッション｜上限値なし（asyncio.gather による同時 kickoff） Crew 実行（独立）｜既定値｜CrewAI OSS 1.15.30 akickoff_for_each / kickoff_async + asyncio.gather
• 1日の延べ｜未公表 実行/日｜公式上限｜AMP
• 1実行の累計｜Basic: 含む50・最大50／月。Enterprise: 契約で個別設定 実行/月（Automation 2 件まで）｜公式上限｜CrewAI AMP の Basic（無料）プラン／Enterprise（要見積）

同時：親は複数サブエージェントを同時起動できる（公式は最大数を記載せず）。teamwork・boostも人数を示さない。 累計・延べ：1実行の累計・日延べ・公称の数値は確認できず。

• 種別：協調スウォーム＋独立並列
• 独立並列の複数会話と、親が複数サブエージェント／teamworkで協調する形の両方があるが、協調規模の上限・実例が公開資料にない。
• ネスト深さ｜10 階層｜公式上限｜主エージェント配下のサブエージェント
• 協調タスク内の同時数｜上限の記載なし 体｜未記載｜親のサブエージェント同時起動

同時：Grok Build同時サブエージェント数は公式ドキュメントに数値なし。第三者記事の『8』は未確認。 累計・延べ：1実行の累計や1日延べの公称は確認できず。

• 種別：協調スウォーム＋独立並列
• Grok Buildは親が子セッションを並列に走らせるサブエージェント方式（上限は公式未記載）。別にAPIのMulti-Agentが4/16体のリーダー＋推論エージェント協調。
• 協調タスク内の同時｜4 / 16 体｜設定可能値（公式）｜xAI API grok-4.20-multi-agent（推論協調）
• 協調タスク内の同時｜8 体｜利用者報告・第三者記事｜Grok Build サブエージェント
• 登録定義数｜50 件｜公式上限｜1セッションの /loop 予約タスク

自社CLI・契約の再利用。複数社の契約済みCLIを束ねる標準UIではありません。

自社のCLI・契約枠で実行。複数社の契約済みCLIをまとめる標準操作面とは区別します。

Cursor基盤で実行。複数社の既存CLIを束ねる仕様は未確認。

Antigravity CLI（agy）・デスクトップアプリ・IDE拡張を自社提供。選べるのはモデル（Gemini/Claude/GPT-OSS）で、他社のコーディングCLIを選んで起動する機能は確認できず。FAQは第三者ツール経由のアクセスを規約違反と明記。

公式文書は、全方式で働き手は Claude セッションであり、別の道具を使う場合は MCP サーバーとして Claude に公開すると明記（agents ページ）。第三者製の公式 Codex プラグイン（OpenAI 公開、Apache-2.0）で /codex:rescue から Codex にタスクを委任でき、結果を受け取れる。ただしベンダーの自動選定・タスク配分・再配分の標準機構はなく、委任先と範囲は利用者や Claude の判断。定義の『外部MCP統括は△』に該当。

Claude Code・Codexに共通の協調ツールを接続し、Swarm・LLM provider routingを提供。混在する異社CLIを統括が自動選択して起動・委任・回収する一連の標準経路は、確認資料から特定できません。

同一Workflow内でClaude・Codex等を混在させ、ノード単位のprovider/model指定で引継ぎ可能。事前定義した担当・工程の自動実行であり、統括役が都度タスクを分割してベンダーを自律選定する機能とは区別します。

ローカルMCPからexecutorを指定して複数社CLIを起動し、プロンプト送信・結果取得が可能。自動分解・配分を担う統括役は接続先MCPクライアント等に持たせる構成で、標準の内蔵自動統括とは区別。

複数社のLLM APIをSwarm topologyで協調実行。既存CLIをそれぞれの契約・認証で動かす異種CLI統括とは区別します。

Manager による委任と複数 LLM provider に加え、A2A プロトコルで遠隔の他社・他製品 agent へ自律的に委任し結果を返せる（AMP で A2A サーバー公開も可）。ただし相手は A2A 対応 agent で、各社の既存コーディングCLIを起動・配分する機構ではないため△のまま。

Devin Local／CLIのcustom subagentは model: で他社モデルを固定でき、親が子へ委任して結果を受ける。ただしAPIモデル協調であり、異社CLIへの自動委任・結果統合ではない。ACPは外部Agentの起動・状態管理に留まり、親Devinがこれを自動分解・配分する記載は見つからない。

サブエージェント定義の model に別モデルIDを指定でき、/best-of-n は複数モデルで並列実行。ただしいずれも Cursor 自身のエージェント基盤上で動き、Claude Code・Codex 等の他社CLIへ自動委任する機構は確認できない。Cursor CLI の ACP は Cursor が他クライアントから呼ばれる側（サーバー）で、他社エージェントを起動する側ではない。定義上、APIモデル協調は△。

[secondary_model.models]でサブエージェントに別プロバイダのモデルを割当可能。ただしAPIモデルの協調であり他社CLIへの自動委任ではない。

複数Agentを管理。内蔵の階層型自律指揮は未確認。

人が工程を定義し、Agentが工程内で判断する。

目標の分解・レビューは人中心の設計。

ruflo-goalsはhorizon（目標）と進捗・ドリフトを/goalsで確認でき、セッションをまたいで保持される。ruflo-autopilotはエージェントを自律ループで回すが、達成条件による停止は文書になく、上限（iterationCap既定1000）で止まる。達成の自動判定と明示的な再開コマンドは確認できなかった。

Swarmsのエージェントはmax_loops="auto"で自律モードとなり、計画・実行しエージェント自身が終了を判断、stopping_token等の停止条件も指定できる。ただし達成条件の自動判定・状態確認・再開の仕様は公式で確認できず、停止機構の記述も不統一。Swarms API(ホスト版)公式ページには記載なし。SDKでの構成が前提。

タスクごとにガードレール（Python関数または自然言語の文字列条件）を設定でき、不合格ならエラーをエージェントへ返して再試行する（guardrail_max_retries 既定3回）。達成条件の自動判定と自動継続はあるが、上限回数つきのタスク単位の再試行で、セッション全体の目標を満たすまで続ける機能ではない。状態確認・中断後の再開は未確認。AMP固有の追加機能も未確認。

Projects（Pro/Max の beta）は1つの統括会話がスレッドを起こし、Overview で状態を追う。プロジェクトを分ければ統括も分かれるが、成果の受入（PRのレビュー・マージ）は人が行い、常駐の専任PMが受入まで担う形ではない。1会話のゴールは /goal（ゴール機能の行）。

独立した Goal を複数のチャットで並列に走らせられるが、各 Goal を管理する専任PMはない。1会話のゴールは Goal mode（ゴール機能の行）。

目標管理はある。専任PMの常設対応は未確認。

複数作業群を管理。ゴール別専任PMとは同一でない。

複数実行は可能。各ゴールの専任PMは未確認。

独立した目標実行。専任PM階層の標準化は未確認。

階層構成は可能。複数ゴールの常設PM管理は未確認。

Managerは設定できる。Fugaと同じPM管理画面は未確認。

子は作業単位。ゴール別専任PMの常設仕様は未確認。

Projects（2026-09-10 beta）は Project ごとの coordinator が計画・委任・成果回収を行うが、受入判断は人。常駐の専任PMが受入まで担う形ではない。

/goal nextで次のゴールを順に待機させる方式で並列の専任PMはない。Towerは1ワークスペースに統括1体でmission分解・進捗・merge承認を行うが、ゴール別の常駐PMではない。

Tasks・依存・調整を利用。目的関数・制約式・求解法を持つ数理最適化機構は確認資料に明記されていません。

LLMによる計画と進捗評価。明示目的関数・制約・複数求解法で割当を解く標準機構は確認資料に明記されていません。

適応的な割当・学習を記載。今回定義したタスク群の資源制約付き数理計画と同じ実装は、確認資料から特定できません。

役割・作業依存・並列実行を制御しますが、同等の明示目的関数による組合せ最適化は確認できません。

依存する工程を定義・実行できますが、資源配分を数理目的関数で最適化する機能とは区別します。

実行フロー・イベント・反復目標を管理。同等の制約付き数理配分モデルの記載は確認できません。

複数の経路・協調方式を選択できますが、同等のタスク群の資源制約付き最適化モデルは確認できません。

Managerによる委任やFlow制御を提供しますが、同等の数理配分モデルは確認できません。

親が子の作業を計画・監督。公開された同等の数理目的関数・制約モデルは確認できません。

依存を保つ並列計画を提供しますが、同等の数理配分モデルは確認できません。

Plan modeとplan型サブエージェントはLLMの計画。目的関数・資源制約による数理最適化の記載なし。

明示的な目的関数・制約の最適化は確認できず。

ルーティングはあるが、公開ベンチの継続取込は未確認。

Adaptiveは依頼ごとに最適モデルを自動選択するルーターで、難易度に応じて割り当てる。外部公開ベンチマークを取り込み割当へ反映するとの記載は無い。Arena Modeは利用者の投票で比較する方式。

/usageに自社プラン枠等を表示。複数ベンダーのサブスク残量の横断集計ではありません。

自社プラン枠と追加利用を管理。他社のサブスク残量まで横断して表示する機能は未確認。

`gt quota status` が登録アカウントごとに available／rate-limited／cooldown と limited_at・resets_at を表示し、`gt quota rotate` が制限済みセッションを空きアカウントへ（macOS Keychain 差替え・LRU）切替える。対象は Claude Code のみで、残量（利用枠の数値）ではなく制限検知後の状態表示。

Codex実行中のチャットで/statusを実行すると、プランと利用率(%)・クレジットをCodexのアカウント情報から表示。単一ベンダー・都度表示で、複数社・複数アカウント・時間窓別の一覧画面ではない。Claude複数アカウント切替(PR#1983)は未マージ。

Devin Desktopの使用量メーター／プランページで日次・週次の残量とリセット時刻を確認できる。Devin自身の枠のみで、他社サブスク（OpenAI・Anthropic等）の残量表示は確認できない。ChatGPTプラン連携は課金の付け替えで、残量表示ではない。

/usage（別名/quota）とSettingsで5時間・週のモデル別クォータ使用量を表示。ただしGoogleアカウント1社の枠で、複数社・複数アカウント管理ではない。

/usage（/cost）でクレジット使用量・請求管理、/context でコンテキスト使用量。xAI単社のみ、複数社・複数アカウント横断の枠表示なし。

Kimiプランの利用枠のみ。複数社横断なし。

複数APIの切替。定額CLI間の振替と同一ではない。

Schedulerは枠消耗を抑制。別ベンダーへの自動振替は未確認。

別アカウントへの手動変更にも追随。別CLIへの自動振替は未確認。

ミッション→ワークフロー台本がタスクをレベル別に並べ、最大並列数を見積もる。作業の終了見込み・遅延予測は記載なし。稼働ガントは「ガントチャートUI」で判定。

依存・作業状態を追跡。同等のガントとETAは未確認。

依存順は指定可能。同等の時間ガントは未確認。

並列化時に依存を保持。同等のガントとETAは未確認。

依存順のmergeはあるが所要時間からの終了見込みは未確認。

人のレビューとAgentへの差し戻しを支援。

汎用の評価・実行部品。開発工程は要構成。

汎用部品を構成。開発用の一貫工程は要構築。

plan/exploreサブエージェント、Hooks（PreToolUse等・SubagentStop）、Workflowで工程化できる。実装者から独立したレビュー役・不合格時の自動差戻しは標準機能として未確認。

スケジュールやAgentの設定は可能。ノードと接続を画面で編集する再利用Workflowビルダーは未確認。

スケジュールやSDK・Hooksで処理を組み立て可能。ノードと接続を編集し配備するビジュアルWorkflow構築は未確認。

Console に /console/builder の実験的キャンバス（ノード・接続・検証・YAMLプレビュー）があるが、既存Workflowの読込→編集→保存の往復は未対応で include/loop_group/workflow ノードも表せない。

トリガーと指示・ツールをUIで設定できます。任意の多段ノードを持つGraph構築まで確認した判定ではありません。

Workflowを説明から作成・保存・再実行・一時停止できるが、ノード・接続を画面で編集するビルダーは未確認。

SDKのSubagents/MCPで制作処理を構成可能。falキー設定・複数メディア・費用制御まで統合した標準機能は未確認。

標準の画像生成を提供。falキーで画像・動画・音声を分担生成し費用制御まで統合する標準仕様は未確認。

複数Agentへ独自ツールを接続可能。公式Marketplace実装にはプロンプト担当→画像モデルの生成例がありますが、商用API標準のfalキー管理・動画／音声まで同梱する仕様とは区別します。

AgentがDALL-Eで画像を生成する標準ツールを提供。falキーを製品設定から統一管理し、画像・動画・音声をまとめて扱うFugaの経路と同等とは確認できません。

画像生成ツール（Nano Banana 2、利用者はモデル変更不可）があるが、利用者のfalキーでの画像・動画・音声の汎用生成経路は確認できず。

画像・動画生成コマンドあり。ただしxAI自社生成でfalキー対応・複数メディア分担は未確認。

外部ツールを統合。任意アプリ・成果物の専用ランチャーと同等の範囲は未確認。Cowork固有機能は加算していません。

ツールと成果物を作業面から利用。任意アプリを一覧・検索して窓として起動するランチャーの全条件は未確認。

ハーネス拡張・コマンドのカタログです。一般アプリを同一デスクトップの窓で使うランチャーとは別方式。

Usage、Graph、Media Playerなど組み込み画面とプラグインを提供。外部アプリも含むFuga型ランチャーとは範囲が異なります。

統合ランチャー・ミニアプリ一覧は無い。エージェント用MCPサーバーの設定画面、VSCode/Cursor/Windsurf拡張、内蔵プレビューブラウザはある。定義上、MCP一覧・IDE拡張は部分対応。

Google Docs / Slides等をエージェントのツールとして連携。アプリ自体を同じデスクトップの窓に並べる機能とは区別します。

エディタ・ターミナル・拡張を統合。一般アプリのランチャーと同等という判定にはしません。

エージェントの作業面に開発ツールを統合。汎用アプリを窓で使うランチャーとは区別します。

Marketplaceタブでプラグイン（skills・サブエージェント・MCP・hooks）を一覧・導入できる。v2.22でUI Extensionsも追加。生成成果物を窓として起動する統合ランチャーは確認できず。

/plugins /marketplace /skills /mcps のモーダルで追加・管理。ミニアプリ統合ランチャーではない。

/pluginsでskills・MCP・データソースのインストール。統合ランチャー画面ではない。

Local/Cloudの定期タスクを設定・一覧管理。予定と実績を重ねるカレンダーUIは未確認。LocalはPC起動・アプリ起動が必要。

Localの繰返し実行を管理。予定・実績を統合するカレンダーは未確認。Cloudの実行条件・対象機能はプランとsurfaceに依存します。

時刻に基づくバックグラウンド実行を記載。予定・実績のカレンダーUIは確認できません。

Deacon プラグインのゲートに cooldown／cron／condition／event／manual があり `schedule = "0 9 * * *"` のように定期実行を定義できる。予定・実績のカレンダー表示は無い。

schedule/webhook の trigger binding で定期起動できる（macOS 標準スケジュール、Linux/Windows は cron 等）。予定・実績のカレンダー表示は無い。

単発・特定時刻・反復実行と次回時刻・履歴を一覧管理。予定と実績をカレンダー上で重ねる要件は確認できません。

SDK の CronJob で秒・分・時間間隔の繰返し実行と実行統計はあるが、カレンダー表示・永続履歴はなし。定義上『時刻トリガーだけなら△』。

料金ページの機能表に Cron scheduling（Basic・Enterprise とも対応）、kickoff の execution_origin に schedule がある。予定・実績を重ねるカレンダー表示、次回時刻・失敗履歴の統合表示は確認できない。

定期・単発実行と履歴を管理。カレンダー上の予定・実績表示までは確認できません。

時刻やcronでクラウドエージェントを起動。予定・実績のカレンダー表示は確認できません。

/scheduleは5フィールドcronとタイマー、MaxIterations、sidecarで永続化。v2.22でAutomations追加。予定・実績のカレンダー画面や失敗履歴の表示は確認できず。

/loop で60秒以上の間隔の定期プロンプト、/tasksで一覧。カレンダー表示・失敗履歴は未確認。

1回または繰返しのcronをエージェントが作成。チャットに通知カード表示。カレンダー画面は未確認。

CLIのファイル生成、共通DesktopのプレゼンPreview・修正を確認。Fuga型の専用AI Slide一覧まで同等とは判定せず、Web Work専用機能も合算していません。

エージェントでプレゼン作成・内容編集・画像背景・サムネ取得が可能。外部Google Slides連携であり、製品内の専用スライド制作・閲覧画面とは区別します。

Session Insights のタイムラインは完了後の分析表示で、依存・予定を持つガントではない。

`gt orphans procs list/kill`、`gt cleanup`、`gt deacon zombie-scan` で tmux に紐づかない孤立 Claude プロセスを検出・終了。CPU・メモリの監視画面や worktree 容量の統合は確認できない。

Maestroが起動したプロセスをグループ・セッション・Group Chat単位のツリーで表示し、PID・実行時間・作業ディレクトリを確認、K/Deleteで終了できる。CPU・メモリ・孤立プロセス検知・worktree容量は未確認（画面ソースにも表示なし）。

継続記憶・指示ファイルを提供。関係を探索する記憶グラフ画面は確認資料に明記されていません。

継続記憶の設定と保持機構を確認。関係ノードを探索する記憶グラフ画面の標準提供は確認資料に明記されていません。

永続記憶・グラフ関係・検索を記載。今回確認した資料ではFuga型の記憶グラフ閲覧UIの範囲は特定できません。

`gt remember` が beads の KV に記憶を保存し gt prime で注入、`gt memories` で一覧・検索（feedback/project/user/reference 分類）。ノード関係のグラフ可視化は無い。

エージェント間の永続共有記憶を提供。記憶ノードをグラフで閲覧するUIは確認できません。

エージェントの記憶・再利用を提供。ノード間の関係をグラフで閲覧するUIは確認できません。

Devin Memoryは設定・修正・プロジェクトの教訓をノートとして保存しセッション間で引き継ぎ、Dreamingが整理する。ノード関係のグラフ閲覧は確認できない。保存・検索のみのmemoryは△の定義。

メモリの保存・閲覧・統合はあるがグラフ可視化は記載なし。

GT_OTEL_METRICS_URL／GT_OTEL_LOGS_URL を設定すると、標準 OTLP HTTP でメトリクス（18種）とログを任意のバックエンドへ送る（VictoriaMetrics は開発既定）。internal/telemetry に trace の実装は無く、認証ヘッダ設定の記述も未確認。

SDK は OpenTelemetry の OTLP/HTTP トレースを既定で出力するが、送信先は Swarms の収集先に固定で、標準の OTEL_EXPORTER_OTLP_* では変更できない。自前のバックエンドへは非公式にスパンプロセッサを足す手段のみ。logs の OTLP 出力は未確認。

Devin CLI v3000.11.1（2026-09-21）でuser configのotelブロックまたは標準OTEL_EXPORTER_OTLP_*でOpenTelemetry collectorへagent eventsとmetricsを出力。air-gapped版の警告表ではENDPOINT・HEADERS・TIMEOUT・PROTOCOLが有効でTRACES_系は無視と読める。Desktop・Cloud側の同等機能は未確認。

公開リポジトリ文書に、マスタースイッチとexporter選択で有効化するオプトインのOTelストリームあり（既定は内容なし）。trace/log別の設定・認証の詳細は未確認。

Plan modeで読み取り専用のまま実装計画を作り、承認後に実行。計画ファイルは ~/.claude/plans/（またはplansDirectory設定先）に置かれ、Ctrl+Gでエディタ編集も可能。ただし機能要件・非機能要件・受入条件を備えた要件定義書を自動で作る標準機能は公式資料で確認できず、計画文書までのため△。スキル・CLAUDE.md・プロンプトで自作すれば要件書生成も可能。

Long-running workの「Start a goal」で、目的が曖昧なら/planでChatGPTが聞き取りを行い、測定可能な成功基準を持つ目標にまとめる。ただし要件定義書・仕様書をファイルとして保存する旨の記載は公式ページになく、計画・目標文までのため△。AGENTS.mdやプロンプトで自作すれば仕様書生成は可能。

同梱のsdlcパックのarchon-plan(およびarchon-shipの計画段階)が、決定済みの意図を実装可能な計画にして成果物として残し、実装・検証・PR作成へつなぐ。ただし中身は設計判断と実装計画で、要件定義書・仕様書(機能/非機能要件・受入条件)の自動作成を目的とする同梱ワークフローは見つからず、計画文書までのため△。リポジトリにPRD生成プロンプトはあるが開発者用(.github/prompts)で製品機能ではない。利用者がワークフローを自作すれば可能。

README は AI と協働して詳細な仕様書を作ると説明。Onboarding Wizard と /wizard は対話で確信度80以上になると Auto Run 用の計画文書（フェーズ別チェックリスト）を .maestro/playbooks/ 配下にファイルとして生成する。ただし内容は実行用の作業計画で、機能要件・非機能要件・受入条件を備えた要件定義書として生成すると明記した資料は確認できず、タスク分解・受入判定への自動連携や変更時の更新も記載なし。spec-kit/OpenSpec 連携の記載もなし。

SDK に AutoSwarmBuilder（タスク分解とエージェント自動構成）と PlannerWorkerSwarm（目標を優先度付きタスクへ分解）があるが、要件定義書・仕様書を文書として生成・保存する機能は確認できない。要件書作成はエージェントやプロンプトを利用者が構成すれば可能という条件付き。SwarmRouter 経由の AutoSwarmBuilder は未対応との記載あり。

Crew Studio の出力はエージェント・タスク・入力・ツールの構成とコードで、要件定義書・仕様書ではない。Crew Assistant の確認質問は Crew 構築のための聞き取り。CrewAI で PRD・仕様書を作る Crew を利用者が組む（第三者テンプレートの例あり）ことは可能だが、公式の標準機能としては確認できず、タスク分解・受入判定・変更時更新への自動連携も未確認。

Ask Devin で既存コードを調べ、実装計画を作らせ、文脈入りのセッションを作れる。Devin Wiki は既存リポジトリのドキュメントを自動生成するが要件定義書ではない。Playbook・プロンプトテンプレートで仕様書作成を自作することは可能。要件定義書・受入条件を自動作成して保存し、変更時に更新する公式機能は公式 docs の索引から確認できず。

Plan Modeが要件を確認する質問をしたうえで実装計画を作成。計画はmarkdownとして既定ではホーム配下に保存され、「Save to workspace」でリポジトリへ移せ、チャットやmarkdownで編集可能。ただし要件・受入条件の構成を持つ要件定義書の自動作成やタスク分解・受入判定への自動連携は公式に記載なく、計画文書までのため△。

Implementation planは「必要な変更の技術詳細」で要件・受入条件は記載なし。teamworkは範囲確認から承認用ブリーフと計画・進捗の成果物を作る。完了時のwalkthroughは変更内容の簡潔な要約（ブラウザ作業は画面録画付き）で、検証結果の記載は明記なし。要件定義書と成果報告書の両方を自動作成する根拠は確認できず。

Plan mode が session の plan.md を作る（/view-plan）。要件定義書（機能・非機能要件・受入条件）や作業完了時の成果報告書を自動生成する機能は公式資料で確認できず。Skills等で自作は可能。

/initはコードベース解析によるAGENTS.md生成、Plan modeはチャット内の計画。要件定義書・作業完了時の成果報告書を自動作成する機能は確認できず。Towerは.tower/commsに監査記録を残すが成果報告書ではない。

Desktopの編集・ターミナル・差分と外部IDE連携。独立したフルIDEや入力中のAI補完まで同等とは判定していません。

差分・ファイル操作とIDE連携を提供。独立したフルIDEや入力中のAIコード補完と同等の標準機能とは判定していません。

Console に統合エディタ・補完は無く、サーバー上のパスを vscode:// リンクで開く機能のみ。

ファイル・差分閲覧とエージェント管理を提供。LSP・入力中のAI補完までを備えた統合IDEとは区別します。

差分、ターミナル、ブラウザプレビューを提供。汎用IDEの言語支援・AI補完と同等とは扱いません。

公式はTUI。ACP（grok agent stdio）で対応エディタに組込み可。入力中のAI補完は確認できず。

VS Code拡張・ACP（Zed/JetBrains）。独自IDE・補完は確認できず。

Localとの安全な引継ぎとPR操作を確認。別ブランチのベースへのマージ・競合処理まで統合した専用UIの全条件は確認資料から特定できません。

同等の既定Merge完了経路までは未確認。

PR作成を支援。Merge完了の標準自律経路は未確認。

公表例ではPR群を作成。自律Merge完了までは根拠不足。

コーディング・レビュー・GitHub操作のツールを提供。同等の提供元常駐PRボットとしての標準サービスは確認していません。

gh CLIでPRをポーリング（既定5分）、またはwebhookのpull_requestイベントで、PR作成を契機にAgentがレビューを実行。PRの更新契機・インライン指摘・CIチェック返却の標準機能は確認できず、プロンプト次第。ローカルPCのMaestroが動いている間のみ。

ローカルWorkspaceの差分・レビューを支援。常駐PRレビューボットとは区別します。

@claude-flow/swarm（UnifiedSwarmCoordinator・Queen・consensus）と @claude-flow/plugins（PluginBuilder・workers・hooks・MCP ツール）が npm ライブラリとして提供され、自アプリから組み込める。LLM 実行ループ付きの Agent SDK として一式を定義・実行できるかは確認できない。

エンジン（@archon/workflows 等）は monorepo 内パッケージで、npm 公開は確認できず（レジストリ 404）。外部アプリからは CLI／REST／webhook で依頼する形。

外部システムとAPI連携可能。ライブラリ内の独自Agentランタイムとは区別します。

外部プログラムからCLI・APIで呼び出せます。この資料だけでは同等の埋め込み用Workflowライブラリとは判定しません。

Grok Build向けSDKパッケージはなくACPの生JSON-RPC。xAI SDKはAPIモデル呼出し用（multi-agentのagent_count等）。

VS Code拡張が使用する公開SDK。カスタムAgent・複数Agent Workflow定義の記載は確認できず。

Desktop（macOS 14以降・Windows）とCLI（macOSのみ）で、利用者自身の画面をスクリーンショットで見てクリック・入力・スクロールできる。初回に「このセッションだけ許可」で操作するアプリ単位の承認、ターミナルやFinder等への警告、アプリ種別ごとの操作制限（ブラウザは閲覧のみ・ターミナル/IDEはクリックのみ）、Escでの即時中止、同時に1セッションのみのロックなど安全の仕組みは揃う。一方で公式にresearch previewと明記され、ProまたはMaxプラン限定（Team/Enterprise不可）、非対話モード不可、Linux不可のため条件付きとして△。

公式ドキュメントにあるのは Browser Use 連携（実ブラウザの操作）と bash 実行・Web スクレイピングの例。ローカルのデスクトップ画面を見てマウス・キーボードで操作する機能は確認できない。ブラウザ操作だけのため △。

公式ドキュメントのツール一覧にデスクトップ操作（画面・マウス・キーボード）は無い。あるのはブラウザ自動化（Stagehand・Browserbase・Selenium・MultiOn）と、E2B／Daytona のサンドボックスでのシェル・ファイル操作、Code Interpreter。ローカルのデスクトップ操作は確認できず、ブラウザ操作だけのため △。

公式ドキュメント上、自前のマシン（セルフホストワーカー）を --computer-use で起動すると、macOSとLinuxで画面を見てクリック・入力できる。macOSでは専用ヘルパーアプリにAccessibilityとScreen Recordingの許可が必要。ただしCursorのデスクトップアプリ自体の機能ではなく、Windowsの記載はなく、アプリ単位の承認は記載が確認できない。フォーラムには2026.08.25版でmacOSのヘルパーが同梱されないという報告もあり、条件付きとして△。

ブラウザサブエージェントが利用者のローカルChromeを別プロファイルで操作（URL許可・拒否リスト、録画）。利用者PCのデスクトップ画面を見てネイティブアプリをマウス・キーボードで操作する機能は公式資料で確認できず（追加検索でも該当なし）。

React Nativeモバイル開発の専門エージェント定義（iOS/Android向けのコード作成）が同梱されている。ただしシミュレーター／エミュレーターの起動・画面確認・操作を行う機能やプラグインは確認できず、組み立て（コード生成）までの対応。

公式ドキュメントで、AIがシミュレーター／エミュレーターを起動・操作する内蔵機能は確認できない。クラウドエージェントはUbuntu VMでiOS Simulator不可、Androidも高速化(KVM)なしで、公式フォーラムでも機能要望が出ている状況。ローカルMac上でRocketSimや外部のシミュレーターMCP、Expo EASのリモートSimulatorを組み合わせれば可能なため、外部ツール前提の条件付きとして評価。

Build with GoogleのAndroid CLIバンドルでアプリ作成・Android仮想デバイスへの配備・自然言語での試験が可能。画面を見て操作する仕組みの詳細は記載なし。FlutterはDart MCPで実行中アプリと対話するがエミュレーター起動は記載なし。iOSはXcode拡張（Xcode 27 beta 6以降）があるがシミュレーター操作の記載なし。

ツール実行の許可とセッション継続を制御。実行済みOSプロセスを危険検知で凍結してその場から再開する仕様とは区別します。

権限境界とGoalの一時停止・再開を提供。実行中OSプロセスを危険検知で凍結する仕様とは区別します。

操作の制御はある。同等のプロセス凍結・再開は未確認。

`gt estop` で全 agent セッションに SIGTSTP を送りその場で凍結（文脈は保持）、`gt thaw` で再開。town 全体または rig 単位。Mayor は除外。ESTOP ファイルに manual/auto の起動元と理由を記録し、auto は dolt-unreachable 等のテストあり。危険な操作の検知は PreToolUse の guard フックが担うが、docs/HOOKS.md は dangerous-command guard が未実装と明記。

Workflowのwait。同等の危険操作検知・プロセス凍結ではない。

工程内の承認待ち。同等の危険操作検知・プロセス凍結は未確認。

危険操作の自動検知は無い。PRE_TOOL_CALL フックで利用者が条件を書けば HookAborted でツール実行を遮断でき、承認ゲートの例も docs にある。AMP は HITL で『Pending Human Input』に止め /resume で再開、Checkpoint は完了タスクを飛ばして再開・分岐できる。検知理由・判断履歴を標準で提示する機構は未確認。

親が子を止められる。危険検知からの同等凍結は未確認。

権限チェックと、実行後のプロセス凍結は別。

Planモード、Auto（安全でない操作のみ確認）、Always-approve、Sandboxプロファイル（Landlock/Seatbelt）、PreToolUse Hookで拒否、PermissionDenied。実行中プロセスを保ったままの凍結・再開や判断履歴の提示は未確認。

permission.dangerous_command_guard、PreToolUseのexit 2でブロック。実行中プロセスを保持したままの凍結・判断履歴提示は未確認。

Severity別に統括・人へ問題を送る。

実行時の承認はCLI設定にも依存。

人が途中で指示・確認可能。強制承認ゲートの範囲は未確認。

ユーザーに admin/member を割当て、run の承認・取消等は起動者か admin のみ。独自ロールやリソース単位権限は無く、Security 文書は単一開発者向けでマルチテナント隔離なしと記載。

クラウド組織にAdmin・Memberの2ロールのみ。独自ロール作成やリソース単位の権限は無く、組織機能自体が終了告知。ローカル版に人間のチーム権限は無い。

エンタープライズはIAMロール（agentspaceAdmin／agentspaceUser）で管理。機能・リソース単位の独自ロール設計は記載なし。

Web ログインは Better Auth のメール＋パスワード（Postgres時のみ）。SAML/OIDC/SCIM は無いが、信頼プロキシの X-Archon-User ヘッダで外部IdPプロキシのID連携ができる。

Agent SDKは自分のプロセスで動かすライブラリ。APIトリガー可能なCloudタスクと、独自Workflowコードの管理基盤配備・再配備は区別します。

アプリやCIからタスクを開始・継続可能。独自Workflowコードを提供元基盤へ配備・RESTサービス化・再配備する専用基盤とは区別します。

webhook.receivedで認証付き（HMAC対応）のHTTPエンドポイントからCueパイプラインを起動でき、maestro-cliでもPlaybookをCI等から実行できる。ただしローカルPC上のリスナー（既定127.0.0.1:17997）で、管理基盤への配備・安定RESTサービス化・API再配備はない。

RESTへカスタム構成を送って実行可能。ここで定義する独自コードの個別サービス配備・再配備までは確認していません。

外部からセッションを起動する用途に対応。CrewAI型の独自Workflow個別配備とは別です。

外部からエージェントを起動するAPIを提供。独自Workflowの配備サービスとは別です。

自作Agentを管理基盤へ配備して安定RESTエンドポイント化する機能はAntigravity本体では確認できず。SDKドキュメントは別製品のGemini API Managed Agentsへ誘導（詳細未確認）。

grok -p、streaming-json、grok agent serve で外部から起動可。Workflowを安定REST化・再配備する仕組みは未確認。

安定エンドポイントとしての配備は確認できず。

ruflo-agent の managed_agent_* が Anthropic のクラウドコンテナで長時間・非同期のエージェントを動かし、ファイルとトランスクリプトがターン間で残る。ANTHROPIC_API_KEY と Claude Managed Agents ベータ権限が必要で、Ruflo 自身のマネージド基盤ではない。

提供元のマネージド実行基盤は無く、README は Self-hosted と明記。自前のVPS/Docker/ローカルで archon serve と detached run により PC外でも継続できますが、再試行・状態復元は自己運用です。

Remote Controlは接続先が自分のマシンで、PCが寝る・切れると到達不能。概要はCLIがクラウド環境・SSHで使えると記す。Gemini APIのManaged Agentsは別製品でLinux実行環境を提供（詳細は未確認）。

Grok Build CLIは利用者の環境で実行。別製品のGrok Botは常駐クラウドコンピューターで『ノートPCを閉じても継続』と公式記載。コーディングCLIのクラウド実行とは別。

ruflo-browser が Playwright の 23 ツールでブラウザ操作し、スクリーンショットと軌跡をセッションごとに保存する。WASM 隔離ランタイムと Anthropic マネージドコンテナもある。ただしデスクトップ GUI を持つ隔離 VM とテスト録画ではない。

コード実行ツールを提供。提供元のフルGUIデスクトップを操作・録画する機能と同等とは確認できません。

コード実行を提供。フルGUIデスクトップ操作・録画までの標準提供とは区別します。

Grok Botが永続クラウドマシン上でブラウザ・ファイル・端末を操作。Grok Build自体の隔離VMでのGUI操作・テスト録画は確認できず。

v3/goal_ui は目標入力→GOAP 計画→エージェント実行を Web で確認でき、/agents に稼働中エージェントを表示。公開デモ goal.ruv.io あり。スマホ最適化・認証付き介入は記載なし。ChatGPT 向け RuFlo Federation アプリ（OAuth）は連携メッセージ用。

ホストPCのVibe KanbanにペアリングコードでスマホのWebから接続し、Workspaceの閲覧・指示ができる方式がdocsとコードに存在（モバイル向けレイアウトは2026-02にマージ）。ただし中継・認証はcloud.vibekanban.com側に依存し、運営終了後の稼働継続は確認できない。

Grok BotにiOS/Androidアプリがあり依頼可能。Grok Build CLIの公式スマホ/Web操作はなく、第三者のgrok-remoteがある程度。