Sharkly vs. Conductor：チーム拡大時、並列エージェントはどこで実行するのか

複数のコーディングエージェントを同時に動かすとなれば、多くの人がまず名前を挙げるのがConductorです。そう呼ばれるだけの理由があります。ネイティブのMacアプリで、エージェントは分離されたワークスペースで動き、レビューしやすいクリーンなdiffが得られ、かつて必要だったtmuxの面倒な操作も一切不要です。

したがって有益な比較は「どちらが並列エージェントを動かせるか」ではありません。どちらも動かせます。そうではなく、作業が一人の開発者の午後の仕事ではなくなったときに何が起きるかです。二人目の担当者がその実行を確認する必要が出たとき、Windowsを使う人が加わったとき、エージェントにノートPCではないマシンが必要になったとき、そして計画がワークスペース一覧以外のどこかに存在しなければならなくなったとき。このガイドではそうした境界線を示し、Sharklyが不適切な選択となる場面を率直に述べます。

TL;DR

ConductorはmacOS上の分離されたワークスペースで、Claude Code、Codex、Cursorのエージェントを並列実行します。自分のサブスクリプションとキーを持ち込む無料枠があり、有料プランではConductor Cloud、API、チーム向けのライブコラボレーション、エンタープライズ向けのID管理機能が追加されます。そのドキュメントには、現時点でWindowsとLinuxには対応していないと明記されています。Sharklyは、接続したComputer上でエージェントを実行します。リモートサーバーやコンテナも含まれ、macOS、Linux、Windowsで動作し、それらを業務システムで包み込みます。Tasks、Projects、Sprints、Crews、そして双方向のJira同期です。チーム全員がmacOSを使い、最も洗練されたネイティブ体験を求めているなら、Conductorは有力な答えです。実行がノートPCを離れる必要がある場合、あるいは計画が実行と共にあるべき場合は、そこでSharklyが引き継ぎます。

Conductorの優れている点

Conductorは、今やこのカテゴリ全体が前提としていることを証明しました。並列エージェント作業には分離とレビューの場が必要であり、どちらもシェルの儀式ではなくワンクリック先にあるべきだということを。

そのホームページは製品をこう明快に説明しています。「Mac上の分離されたワークスペースで、Claude Code、Codex、Cursorのエージェントを並列実行する。」各エージェントは専用のワークスペースを取得するため、同じファイルを編集する2つのエージェントがマージの惨事になることはありません。ワークスペースの作成、エージェントの割り当て、生成されたdiffのレビューは、覚えておかねばならないコマンドではなく、インターフェース上の操作です。

価格設定は実行環境との関係について正直です。無料枠は自分のサブスクリプションとキーを持ち込むと謳っており、モデル自体を実行しないレイヤーとしては正しい姿勢です。有料プランではConductor Cloudが追加され、Proではクラウドワークスペース時間とConductor APIが利用でき、Teamsプランではあらゆる規模のチーム向けライブコラボレーション、集中課金、管理ポータルが追加されます。Enterpriseではデータ処理契約、SAML SSO、SCIM、そして専任サポート付きのSLAが追加されます。

この最後の部分は公平な比較のために重要です。「Conductorはソロ向けツール」という以前の捉え方は時代遅れだからです。コラボレーションと管理機能を備えたチーム向けプランがあります。これを省いた比較は、何かを売り込もうとしています。

ローカルランナーのより広い全体像を知りたいなら、Claude Squad、Conductor、tmuxの比較記事で、これらのアプローチが実際にどう異なるかを扱っています。

Macネイティブアプリが限界に達する場面

設計から3つの限界が導かれますが、そのうち機能に関わるのは1つだけです。

プラットフォーム。Conductorのインストールドキュメントにはこうあります。「Conductorは現時点でWindowsとLinuxには対応していません。」全員Macのチームにとっては問題外です。Windowsの開発者、Linuxワークステーション、あるいはCIに近いビルド用マシンがあるチームにとっては、機能比較が始まる前にこれで答えが出ます。

実行ホスト。ワークスペースはアプリが動く場所で実行されます。Conductor Cloudは有料プランでホスト型ワークスペース時間を追加しこれ和らげますが、ローカルモデルは依然として開発者のマシンを中心としています。VPNルート、初期データ投入済みのデータベース、GPUが必要なマシンを要するエージェント作業は、別種のホストであり、通常それはノートPCではありません。

作業の単位。ワークスペースはセッションです。「このエージェント、このブランチ、このdiff」にとっては優れた抽象化です。しかしバックログ項目ではありません。優先度、スプリントへの所属、受け入れ基準、他の誰かが解消すべきブロッカー、三週間前にレビュアーが下した判断の履歴などを運びません。これらを必要とするチームは別の場所に保管するため、計画と実行が2つのシステムに分かれ、乖離していきます。

これらはいずれも欠陥ではありません。集中したローカルツールの形であり、集中しているからこそ使っていて心地よいのです。

判断の分かれ目

Conductorを使うべき場合は、全員がmacOSを使い、欲しいエージェントがClaude Code、Codex、Cursorで、作業が開発者のマシンやホスト型ワークスペース時間で問題なく回り、計画がすでに満足のいくトラッカーにあるときです。ライブコラボレーション付きのネイティブアプリは業務システムより軽量で、軽量さは利点です。

Sharklyを使うべき場合は、実行がノートPCを離れる必要があるか、複数プラットフォームにまたがるか、あるいはチームが計画、実行、レビューを1つの記録で管理したいときです。

違いを担う定義はこうです。SharklyにおけるComputerはAgent作業の実行ホストを提供し、それはローカルコンピュータ、リモートサーバー、コンテナ、または対応するクラウドホストになり得ます。小さなローカルサービスがComputerをSharklyに接続し、利用可能なRuntimeを検出し、作業を受け取り、タスクディレクトリを準備し、選択されたRuntimeを起動し、進捗をストリーミングで返します。

この分離が設計のすべてです。Agentは作業をどう扱うべきかを定義します。Computerはホストとローカルリソースを提供します。Runtimeは実際のエージェントセッションを実行します。Taskはチームの共有記録であり続けます。

業務システムが加えるもの

並列分離にすでに満足しているなら、このセクションが読み続ける唯一の理由です。

作業にセッションより長生きする居場所ができる。Taskは作業の主要単位です。OrganizationとSpaceに属し、ProjectまたはSprintにも属することができます。目標と説明、ステータス、優先度、日付、ラベル、タスクタイプ、担当者、実行を割り当てられたAgentまたはCrew、コメントと添付ファイル、そしてAgentの実行状態、トレース、結果を記録します。実行が停滞したとき、その停滞はTask上にあり、明日それを引き継ぐ人がそこで見つけられます。

エージェントの設定がチームの資産になる。Agentは単発のプロンプトではなく、保存された作業設定です。指示、Runtime、Skills、リポジトリ、環境、実行設定などです。チームはコード変更、レビュー、テスト、ドキュメント、運用トリアージ用に別々のAgentを維持でき、そのたびに同じ指示を書き直す必要がありません。コーディングエージェントのSkillとは何かに関する解説記事で、再利用可能な指示の部分を扱っています。

連携が必要なときに構造が備わる。Crewは、1人のリーダーAgentによって調整されるPeopleとAgentsの再利用可能なグループで、役割ベースのコラボレーション、順序付け、あるいは次にどのAgentが動くかをリーダーが決めることから恩恵を受ける作業に向いています。単一のAgentで十分なときは単一のAgentを使いましょう。Crewsガイドには、いつCrewに手を伸ばすべきでないかが明記されています。

トラッカーはつながったまま。SharklyのJira連携はJira CloudとJira ServerまたはData Centerに対応し、インポート、一方向同期、または双方向同期でJiraプロジェクトをSpaceにリンクできます。Jiraから離れられないチームも離れる必要はありません。

Runtimeは拡張可能。ローカルサービスが求める実行能力を検出しない場合、Computerの詳細からカスタムACP Runtimeを追加できます。アイコン、名前、起動コマンドを設定し、保存してから「接続をテスト」を選択します。

実例

12人編成のチームがWebアプリと社内データサービスを提供しています。開発者8人はMac、2人はWindows、そして2人はデータパイプラインのあるLinuxマシンでSSH経由で作業の大半を行っています。

Macの8人の開発者はローカルで並列エージェントを動かすことに満足していました。残りの4人は参加できず、それこそが実際の問題でした。そのツールは8人がどう働くかを説明しており、チームがどう働くかを説明していなかったのです。

彼らはハードウェアを統一するのではなく、Computerを接続しました。数台のノートPCに加え、すでにパイプライン環境とステージングへのネットワークルートを持つLinuxマシンです。パイプラインが必要な作業はそこで実行されます。開発者のローカル設定が必要な作業はそのノートPCで実行されます。Windowsの開発者も同じ方法で接続します。

各実行は依然として分離されたworktreeを取得し、これが彼らが手放すことを拒んだ部分です。分離されたworktreeで並列エージェントを実行するガイドで、同時実行を安全にする仕組みを扱っています。

変わったのは、レビュアーが見るものです。誰かのマシンからdiffが現れる代わりに、Taskが目標、実行したAgent、実行されたComputer、トレース、ブロッカー、議論を表示します。朝会は8つの別々のワークスペース一覧ではなく、スプリントを読むのです。

Sharkly 対 Conductor：公平な比較

よくある間違い

並列性で比較すること。どちらも並列実行をうまく分離します。その機能で決めても何もわかりません。プラットフォーム対応範囲、実行ホスト、そして計画が実行と共にある必要があるかどうかで決めましょう。

時代遅れの「ソロ向けツール」という捉え方を使うこと。Conductorにはライブコラボレーションと管理ポータルを備えたTeamsプランがあります。チームに使えないと言う人がいれば、最近確認していないのです。

必要のない業務システムを追加すること。全員がmacOSを使い、計画がトラッカーで問題なく、エージェントがノートPCで快適に動くなら、業務レイヤーはオーバーヘッドです。断りましょう。

ツールに合わせてハードウェアを統一すること。ツールが動くようにMacを買うことは、実行する前に検討する価値のある判断であり、特に一部の作業がそもそもサーバーにあるべき場合には。

結論

Conductorは集中したアイデアの最良の形です。並列エージェント、分離ワークスペース、クリーンなレビュー、Macネイティブ、そしてその上にチーム向けプラン。チームがmacOS内に収まり、計画がすでに居場所を持っているなら、その集中は利点であり、より重いものと引き換えるべきではありません。

Sharklyは別の問いに答えます。エージェント作業がサーバーにあるべきとき、どこで実行するのか。複数プラットフォームのチームがどう参加するのか。計画はどうやって実行トレースと人間の判断と同じ記録に留まるのか。SharklyはClaude Code、Codex、その他の実行ツールの置き換えではありません。チームがすでに使っているツールの周りに、共有タスク、Computer、コンテキスト、制御、レビューのレイヤーを追加するものです。

並列エージェントの設定は機能しているがチームの一部にしか機能していないなら、それがギャップです。Sharklyを始めて、ノートPCではないComputerを1台接続し、1つのTaskを割り当ててみてください。

FAQ

ConductorはWindowsやLinuxで動作しますか？インストールドキュメントには、Conductorは現時点でWindowsとLinuxには対応しておらず、通知登録を促すと記載されています。決める前に最新のドキュメントを確認してください。

SharklyはConductorのワークスペースのように分離されたworktreeでエージェントを実行しますか？はい。並列エージェントが衝突しないよう実行は分離され、その分離はローカルのワークスペース一覧ではなく共有Taskに紐づきます。

Conductorを使い続けながらSharklyを追加できますか？はい。ただし通常は作業ごとに1つの居場所を選ぶ方がすっきりします。よくある分担は、個人的な作業にはローカル並列実行、チームが確認・割り当て・レビューする必要のある作業にはSharklyです。

Sharklyはどのエージェントに対応していますか？接続されたComputer上でローカルサービスが検出したRuntime、およびアイコン、名前、起動コマンドを設定して構成したカスタムACP Runtimeです。

それぞれでモデル利用料は誰が支払いますか？どちらもあなたに委ねられます。Conductorの無料枠は自分のサブスクリプションとキーを持ち込むと謳っており、Sharklyはモデル利用がそれらのツールに設定されたサブスクリプションまたはAPIキーを通じて継続すると述べています。

Sharklyには専用サーバーが必要ですか？いいえ。ComputerはノートPCでも構いません。要点は、そうである必要がないということで、特定の環境を必要とする作業はその環境がすでに存在する場所で実行できます。