Conductor使い方ガイド: MacでClaude Codeを並列実行する方法

Conductorとは結局何をしてくれるアプリなのか

Conductorは、Claude Code、Codex、Cursor、OpenCodeといったコーディングエージェントをMac上で「複数同時に」動かすために作られたmacOS専用アプリだ。Y Combinator 2024夏バッチ出身のスタートアップMelty Labsが開発し、現在は10万人を超える開発者が使っていると公表している。

ターミナルでclaudeを直接起動して使うのと何が違うのかというと、ポイントは「分離」にある。Claude Codeをターミナルの複数タブで同時に立ち上げたことがある人ならわかると思うが、同じプロジェクトフォルダでエージェントが2つ同時にファイルを触ると、互いの変更を上書きしたりdiffが混ざったりする問題が起きる。Conductorはタスクごとに専用のgitブランチと専用の作業ディレクトリ(ワークツリー)を自動で作ってくれるので、エージェントを5個同時に動かしてもファイルが競合しない。これが「conductor(指揮者)」という名前の意味だ――複数のエージェントを同時に指揮するということ。

インストールと初期設定

Conductorは現時点でmacOS専用だ。WindowsとLinuxはまだ対応しておらず、公式サイトでメールアドレスを登録すればウェイトリストに入り、対応時期に案内が来る。

インストール自体はシンプルだ。

  1. Conductor公式サイトのDownloadボタンからアプリを入手する。
  2. ダウンロードしたConductor.appをApplicationsフォルダにドラッグする。
  3. Conductorを起動する。

アプリを初めて開くと、必要なツールと認証情報が揃っているか自動でチェックするセットアップ画面が表示される。確認される項目は次の通り。

  • GitHub認証: ターミナル環境のGitHub認証状態を確認する。自分で確認したい場合はターミナルでgh auth statusを実行すればよい。
  • Claude Codeログイン: Claudeを使う予定なら必要。手動でログインするにはclaude /login。
  • Codexログイン: Codexを使う場合はcodex login。
  • Cursor APIキー: Cursorを使う場合はSettings → Harnesses → Cursorでキーを登録する。

Conductorを使うにはGitHub認証と、少なくとも1つのエージェントプロバイダー(Claude、Codex、Cursor、OpenCodeのいずれか)が必要だ。新たにAPIキーを発行する必要はない――すでに持っているClaude Codeのサブスクリプションや Codexアカウントをそのまま接続して使う構造(BYOサブスクリプション)になっている。

git worktreeによる分離の仕組み

Conductorを理解するうえで一番重要な概念はgit worktreeだ。git worktreeは、1つのリポジトリに対して複数の作業ディレクトリを同時に作れるgit自体の機能である。リポジトリを丸ごとコピーしたりcloneを何度も取ったりする代わりに、同じ.gitオブジェクトデータベース(履歴、refs、remote)を共有しつつ、ディスク上のチェックアウトだけをワークスペースごとに別々に持つ仕組みだ。

Conductorで新しいワークスペースを作ると、内部では次のことが起きる。

  • そのワークスペース専用のgit worktreeが作られ、その中に新しいブランチがチェックアウトされる。
  • ワークスペースは通常~/conductor/workspaces/<リポジトリ名>/<ワークスペース名>というパスの下に生成される。
  • エージェントによるファイル変更、ターミナルコマンド、セットアップ/実行スクリプトはすべてこのワークスペースディレクトリの中だけで行われる。
  • チャット履歴、diff、PRの状態、アーカイブの有無はそのワークスペースにそのまま紐づく。

gitは1つのブランチを2つのワークツリーで同時にチェックアウトすることを許さない。つまりワークスペースAがfeature-xブランチを使っている場合、別のワークスペースで同じブランチをチェックアウトすることはできない。同じブランチで作業を続けたいなら、そのブランチを起点に新しいブランチを切るか、元のワークスペースを別ブランチに切り替えたうえでチェックアウトする必要がある。

1つ注意したいのは、新しいワークツリーはgitが追跡(track)しているファイルからしか始まらないという点だ。.env.localやローカル証明書、ローカルDBファイルのように.gitignoreに含まれるファイルは自動では引き継がれない。こうしたファイルが毎回のワークスペースで必要なら、「Files to copy」設定(.worktreeinclude方式のパターンマッチング)で指定しておくか、依存関係のインストール・コード生成・シンボリックリンクなどのコマンドが必要ならセットアップスクリプトを登録しておけば、新しいワークスペースが作られるたびに自動で実行される。

ここで正しておきたい誤解が1つある。ワークスペースの分離はあくまで開発状態の分離であって、セキュリティ境界ではない。エージェントとコマンドは結局のところ皆さんのMac上で、皆さんのユーザー権限で実行される。サンドボックスではなく「競合防止」の仕組みだと理解するのが正しい。

実際にワークスペースを作って並列で動かす流れ

Conductorをインストールしたら、次の順番で最初のワークスペースを作ればよい。

  1. リポジトリの追加: Open project(ローカルフォルダを選択)、Open GitHub project(GitHubから選択)、Quick start(新規リポジトリ作成)のいずれかを選ぶ。
  2. ワークスペースの作成: リポジトリを追加すると、Conductorが自動で最初のワークスペースを作る。以降は⌘⇧N(Command+Shift+N)、またはNew workspaceボタン横の...アイコンでワークスペースを追加できる。ブランチ、PR、GitHub issue、Linear issueのどれを起点にするか選択可能。
  3. 実行できる状態にする: 依存関係のインストールや.envファイルのようにgitが追跡しないものはセットアップスクリプトで処理し、アプリ/サーバー/テストを起動する実行スクリプトを登録しておく。実行スクリプトをCONDUCTOR_PORT環境変数を使うように作っておけば、ワークスペースを複数同時に立ち上げてもポートが衝突しない。
  4. 作業開始: ワークスペース内でClaude Code、Codex、Cursor、OpenCodeのうち使いたいエージェントとチャットを始める。ファイル、フォルダ、コメントをメンションしてコンテキストを渡し、コミットしない引き継ぎメモは.contextフォルダに残しておける。

ここからが「並列」の核心部分だ。issueを3つ同時に処理したいなら、ワークスペースを3つ作り、それぞれで異なるエージェント(あるいは同じエージェントの別セッション)を立ち上げればよい。あるワークスペースでは機能Aを実装しながら、別のワークスペースではバグを調査し、さらに別のワークスペースでは実験的なリファクタリングを試すこともできる。それぞれが独立したブランチ・作業ディレクトリ・ターミナル状態を持つので、互いに干渉しない。

1つのワークスペースにまとめるか、複数に分けるか

これが実務で一番迷うポイントだが、Conductorの公式ドキュメントが示している判断基準は明確だ。

複数のワークスペースを使う場合(独立して進む作業):

  • 互いに独立した機能開発
  • 個別にデプロイできるバグ修正
  • GitHub issue、Linear issue、PR単位の作業
  • 捨てる可能性がある実験
  • 別のアプリプロセスやテスト実行が必要な作業

1つのワークスペースを使う場合(同じブランチ・同じコンテキストを共有すべき作業):

  • 一方のエージェントが実装している間に、別のエージェントが同じdiffをレビューする
  • 一方のエージェントがコードを変更した後、別のエージェントが壊れたテストを直す
  • 必ず一緒にデプロイしなければならないフロントエンド/バックエンドの変更
  • 同じブランチに対するマルチエージェントレビュー

基準はシンプルだ。成果物が独立してマージできるならワークスペースを分け、同じブランチ・同じ最新ファイル状態を共有する必要があるなら1つのワークスペース内でエージェントを複数走らせる。

issueからPRまで: 実践ワークフロー

Conductorが描く全体の流れは、「ワークスペースは委任の単位、ブランチとPRは統合の単位」という一文に要約できる。実際の進め方は次の通り。

  1. 処理するタスクをレビューしやすい単位に分割する。1つのワークスペースが1つのshippable unitを持つのが理想的。
  2. shippable unitごとにワークスペースを作る。
  3. 各ワークスペースでエージェントを独立して動かす。プロジェクト全体に適用するルールはRepository Settingsか、リポジトリにコミットされたガイドラインファイルで管理し、タスクごとのコンテキストはチャットと.contextで管理する。
  4. ⌘⇧D(Command+Shift+D)でDiff Viewerを開き、変更されたファイルを確認する。特定の行にコメントを残すと、それがそのままエージェントに渡されるコンポーザーの添付に変わる。Checksタブではgitの状態、CI、デプロイ、コメント、TODOリストを一度に確認できる。
  5. 問題がなければ⌘⇧P(Command+Shift+P)でPRを開く。Conductorが PR説明文の下書きを手伝い、レビューコメントへの返信や失敗したチェックの修正も助けてくれる。
  6. PRが承認されチェックが通ったらマージし、使い終わったワークスペースはアーカイブする。後で必要になればサイドバーのHistoryからチャット履歴ごと復元できる。

料金プラン: ローカルだけ使うなら事実上無料

Conductorの料金プランは4段階だ。

  • Free($0): 複数のコーディングエージェントを並列実行、Mac上で動くローカルワークスペース、既存のサブスクリプションやAPIキーをそのまま接続して利用可能。ここまでで、これまで説明したワークツリーベースの並列作業がすべて含まれる。
  • Pro($50/月): Freeの全機能に加えて、Conductor Cloud(クラウドワークスペース)、Conductor API、モバイルアプリ(公開予定)が追加される。クラウドワークスペースは8コアCPU/16GB RAM仕様の隔離されたmicroVMで動き、Macの電源を切っても作業が続くのがローカルワークスペースとの決定的な違いだ。
  • Teams($60/月/ユーザー): Pro機能にマルチプレイヤー(ワークスペースをチームメンバーとリアルタイム共有)、管理者ポータル、一括請求が追加される。
  • Enterprise(カスタム): DPA、PO(発注書)ベースの請求、SCIMプロビジョニング、SLAなど組織向け機能。

つまり「Conductor MacでMacで無料で使えるか」という問いへの答えは、明確にイエスだ。ローカルのワークツリーベースの並列作業だけを使うならFreeプランで十分で、この記事で扱った機能はすべてFreeの範囲に収まる。クラウドサンドボックスでMacの電源を切った状態でもエージェントを動かし続けたい場合にだけProが必要になる。

Conductor vs ただのClaude Code、使う価値があるのはどんなとき

ターミナルでClaude Codeを1つだけ立ち上げて順番に作業する方式と比べたとき、Conductorが確実に有利な状況は次の通り。

  • 同時に処理すべき独立したタスクが実際に複数あるとき。 issueトラッカーに溜まったチケットを3〜4個並列で回したいなら、ワークツリーによる分離なしにはファイル競合を手作業で管理することになる。
  • レビュー→修正のループを視覚的に管理したいとき。 Diff Viewerで行単位のコメントを残し、それがそのままエージェントに伝わる流れは、ターミナルだけでは再現しづらい。
  • PRまでの流れを自動化したいとき。 PR作成、チェックの追跡、マージまでを1つのアプリの中で管理できる。

逆にConductorがオーバーヘッドに感じられる状況もある。タスクが1つだけで、順番に進めても問題ないなら、素直にターミナルでclaudeを立ち上げるほうが軽い。git worktree自体を手動で管理することにすでに慣れているチームなら、Conductorなしでも似たワークフローをシェルスクリプトで組める。Conductorの価値は「そのワークツリー管理作業を自動化し、複数のエージェントの状態を1画面で見せる」ことにあり、ワークツリーという概念自体を発明したわけではない。

よく使うショートカットと細かい設定

毎回マウスでメニューを探さずに済むように、以下のショートカットくらいは覚えておくといい。

  • ⌘⇧N(Command+Shift+N): 新規ワークスペース作成。...ボタンを押すと、ブランチ、PR、GitHub issue、Linear issueのどれを起点にするか選べる。
  • ⌘⇧D(Command+Shift+D): Diff Viewerを開く。変更されたファイルを左側のリストから切り替えられ、統合(unified)diff表示やコミット単位のフィルタリングにも対応している。
  • ⌘⇧P(Command+Shift+P): 現在のワークスペースの変更でPRを作成。
  • ⌘⇧C(Command+Shift+C): ワークスペースの共有リンクを作成。最近追加されたマルチプレイヤー機能で、チームメンバーを招待して同じワークスペースで一緒にプロンプトを送ったり進捗を見たりできる(Teamsプランから提供)。

ワークスペースごとに毎回設定し直す必要がないように、チーム全体が同じ値を使うようにするには、セットアップスクリプトと実行スクリプトをRepository Settingsで管理するか、.conductor/settings.tomlファイルにコミットしてチーム全員で共有できるようにする。もしプロジェクトがワークスペースディレクトリでそのまま実行しにくい構造なら(例: 絶対パスに依存するレガシーなビルドスクリプトなど)、Spotlight testingという代替の実行方式も用意されている。

レビュー段階で気をつけるべきこと

Diff Viewerは単に変更ファイルを表示するだけの画面ではない。コードレビューに必要なチェックリストをそのまま反映できるよう設計されている。実際にマージ前に確認すべき項目は次の通り。

  • エージェントが触ったファイルの一覧に意図しないファイルが混ざっていないか
  • テストやドキュメントが漏れていないか
  • ローカルコメントとGitHubレビューコメントがすべて解決されているか
  • コンフリクトが起きていたり、手動確認が必要なファイルがないか

特定の行にコメントを残すと、通常のチャットメッセージよりずっと具体的なコンテキストとしてエージェントに伝わる。GitHubで付いたレビューコメントもConductor内にそのまま表示され、対応が終わったらスレッドをresolve表示しておけばChecksタブに反映される。Checksタブはgitの状態、CI結果、デプロイ状態、残っているコメント、TODOリストを1画面で確認できる役割を持ち、マージボタンを押す前の最終チェックポイントとして使うとよい。

セキュリティの観点で知っておくべきこと

ワークスペースの分離を「サンドボックス」だと誤解して機密性の高い作業を任せてしまうケースがあるが、Conductorのドキュメントはこの点を明確にしている。ワークスペースの分離は開発状態(ファイル、ブランチ、プロセス)を分けるための仕組みであって、システム権限を制限するセキュリティ境界ではない。エージェントとセットアップ/実行スクリプトは結局のところユーザーアカウントの権限でMac上で直接実行される。特別なセキュリティ設定をしていない限り、エージェントがローカルのファイルシステム全体にアクセスできるという前提でプロジェクトをセットアップするのが安全だ。一方でConductor Cloudのクラウドワークスペースは隔離されたmicroVMで動く別の実行環境なので、ローカルワークスペースよりシステムアクセスが制限されている。

結論として、ConductorはClaude Codeを置き換えるツールではなく、Claude Code(そしてCodex、Cursor、OpenCode)を「複数同時に、安全に」動かすためのオーケストレーション層だ。無料プランだけでローカル並列作業の中核機能をすべて使えるので、同時に処理すべきタスクが2〜3個以上溜まっている人なら、インストールしてワークスペースを2つ作ってみるだけでも違いがすぐに体感できるはずだ。

関連記事