AIコーディングのためのターミナル選び

2026年9月時点の情報です。この分野では、わずか数か月で前提が変わることがあります。情報の基準日を意識してお読みください。

はじめに：なぜ今「ターミナル」を選び直すのか

私はここ数年、macOS 上で iTerm2 + VS Code という構成を使って開発してきました。しかし、Claude Code と Codex を毎日使うようになると、ターミナルに求める役割が明らかに変わりました。

従来のターミナルは、「自分がコマンドを入力する場所」でした。一方、現在は「エージェントが長時間作業し、必要に応じて人間に許可や判断を求める場所」になりつつあります。その結果、次のような新しい悩みが生まれます。

• Claude Code を3つ並べたら、どのタブが自分の入力を待っているのか分からなくなった
• 夜にエージェントへ大きなタスクを任せてノート PC を閉じたら、作業が止まっていた
• Shift+Enter で改行したつもりが送信されてしまった
• 通知が来ない（あるいは来すぎる）

そこで、近年注目されている tmux、cmux、Orca、OpenCode、Warp、herdr、Zed、Conductor、Traycer を調べ、「Claude Code と Codex を主に使う iTerm2 + VS Code ユーザー」の視点から整理しました。

---

TLDR

1. 「どのターミナルに乗り換えるか」という問いだけでは、もはや十分ではありません。 上に挙げた9つのツールは、それぞれ異なる「層」に属しています。たとえば、tmux と Orca は同じ基準で比較できません。考えるべきなのは、「自分の運用にどの層まで必要か」です。
2. iTerm2 ユーザーは、すぐに別のターミナルへ乗り換える必要はありません。 2026年9月8日にリリースされた iTerm2 3.7 には、Claude Code の公式統合機能が加わりました。また、Claude Code の Agent Teams（分割ペイン表示）に公式対応するのは、tmux と iTerm2 のみです。
3. VS Code の統合ターミナルは、公式ドキュメントに照らすと制約の多い実行環境です。 VS Code はエージェントの主な「実行場所」ではなく、「レビューする場所」として使うのが合理的です。
4. 並列で動かすエージェントが常時4つを超えるなら、新たな層を1つ追加しましょう。 永続化と SSH を重視するなら herdr、macOS ネイティブの見やすさを求めるなら cmux、worktree の作成から PR まで一貫して管理したいなら Conductor または Orca が候補になります。

---

1. 「ターミナル選び」は5層スタックの選択です

まず、調査対象の各ツールがどの層に位置づけられるのかを整理します。

層	役割	主なツール
L5	計画・仕様	Traycer
L4	オーケストレーション（ADE）	Orca / Conductor / Codex app / Claude Code Desktop / Zed（ACP 経由）
L3	エージェント本体	Claude Code / Codex CLI / OpenCode
L2	多重化・永続化	tmux / herdr / Zellij
L1	ターミナルエミュレータ	iTerm2 / Ghostty / cmux / Warp / VS Code 統合ターミナル / Zed 内蔵端末

• tmux（L2）：古くから使われているマルチプレクサ。Claude Code Agent Teams の分割ペインを公式に支えるバックエンドです。
• herdr（L2）：エージェントの状態（working / blocked / idle / done）を把握できる常駐ランタイムです。
• cmux（L1+L2）：libghostty で描画する macOS ネイティブ端末。サイドバーと通知リングが特徴です。
• Warp（L1+L4）：「Agentic Development Environment」を掲げる端末で、2026年4月にオープンソース化されました。
• Zed（L1/L4）：Rust 製エディタ。ACP を介し、Claude Code や Codex をエディタ内の並列スレッドとして動かせます。
• Orca（L4）：OSS の ADE。タスクごとに worktree、端末、ブラウザを用意します。
• Conductor（L4）：macOS 向けアプリ。worktree、端末、diff、PR を一つのワークスペースにまとめます。
• Traycer（L5）：仕様（spec / ticket）を先に固め、任意のエージェントへ実装を渡します。
• OpenCode（L3）：プロバイダに依存しない OSS エージェント。Claude Code や Codex と同じ層に位置します。

たとえば、「cmux と herdr はどちらがよいか」と聞かれたら、「cmux は人間が状況を把握する場所を、herdr はエージェントが稼働する環境を最適化するツール」と整理するのが正確です。cmux はターミナルエミュレータ自体なので、iTerm2 から乗り換えるか、別のアプリとして併用します。一方、herdr は iTerm2 の中で動かせます。この違いを理解すると、選択肢を絞りやすくなります。

---

2. Claude Code と Codex は、ターミナルに何を求めているのか

ツールを比較する前に、エージェント側がターミナルに求める要件を、公式ドキュメントに基づいて確認します。これらを押さえておけば、「なぜこの端末では通知が届かないのか」といった疑問を理解しやすくなります。

2.1 Shift+Enter で改行できるか

Claude Code では、Enter キーでメッセージを送信します。改行を入れる方法は、使用する端末によって異なります。公式ドキュメント（Configure your terminal）によると、対応状況は次のとおりです。

• 設定なしで使える端末：Ghostty、Kitty、iTerm2、WezTerm、Warp、Apple Terminal、Windows Terminal
• 初回設定が必要な端末：VS Code、Cursor、Alacritty、Zed。/terminal-setup を一度実行します。
• Shift+Enter に対応していない端末：gnome-terminal、JetBrains 系 IDE。Ctrl+J、または「\ の後に Enter」を使います。

端末に依存しない代替手段として、Ctrl+J、または「\ の後に Enter」という操作も覚えておくと安心です。

2.2 デスクトップ通知が標準で届くか

意外に知られていませんが、Claude Code が標準でデスクトップ通知を出すのは、Ghostty、Kitty、iTerm2 の3種類のみです。それ以外の端末では、preferredNotifChannel を "terminal_bell" に設定するか、Notification hook を用意する必要があります。公式ドキュメントでは、Warp と VS Code の統合ターミナルが、通知を受け取るために hook または bell の設定を要する端末として明記されています。

iTerm2 でも、Settings → Profiles → Terminal の「Notification Center Alerts」を有効にし、さらに「Filter Alerts」から「Send escape sequence-generated alerts」を有効にする必要があります。これらの設定を見落とすと、iTerm2 を使っていても通知は表示されません。

任意の端末で通知音を鳴らしたい場合は、hook を使う方法が確実です。

// ~/.claude/settings.json
{
  "hooks": {
    "Notification": [
      {
        "matcher": "permission_prompt|idle_prompt",
        "hooks": [
          { "type": "command", "command": "afplay /System/Library/Sounds/Glass.aiff" }
        ]
      }
    ]
  }
}

permission_prompt は許可を待っているとき、idle_prompt は一定時間、入力待ちの状態が続いたときに発火します。

2.3 tmux の中で動かすには、3行の設定が必要です

tmux の中で Claude Code を動かすと、標準設定では Shift+Enter が送信として扱われ、デスクトップ通知や進捗バーも外側の端末まで届きません。公式ドキュメントが示す ~/.tmux.conf の設定は、次の3行です。

set -g allow-passthrough on          # 通知と進捗を外側の端末へ通す
set -s extended-keys on              # Shift+Enter を Enter と区別する
set -as terminal-features 'xterm*:extkeys'

tmux source-file ~/.tmux.conf を実行すれば、稼働中のサーバーにも設定を反映できます。

2.4 Agent Teams（分割ペイン）は tmux か iTerm2 だけ

Claude Code の Agent Teams は、1つのセッションがリーダーとなり、複数の Claude Code インスタンスにタスクを分担させる実験的な機能です（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化します）。表示モードは2種類あります。in-process モードはどの端末でも利用できますが、各チームメイトを独立したペインに表示する split-pane モードには tmux または iTerm2 が必要です。公式ドキュメントの制限事項には、split-pane モードを VS Code の統合ターミナル、Windows Terminal、Ghostty では利用できないことが明記されています（Agent teams）。

サブエージェントは結果をリーダーに返すのに対し、Agent Teams ではタスクリストを共有し、チームメイト同士が直接やり取りします（出典: Claude Code Docs）

teammateMode の設定は ~/.claude/settings.json に書きます。

{ "teammateMode": "auto" }

auto を指定すると、tmux 内で実行している場合、または iTerm2 に it2 CLI が導入されている場合にだけ分割ペインになります。それ以外の環境では、in-process モードに切り替わります。iTerm2 で分割ペインを使うには、it2 CLI を導入し、Settings → General → Magic で Python API を有効にします。公式ドキュメントが tmux -CC（iTerm2 のネイティブ tmux 統合）を推奨していることも、iTerm2 ユーザーにとっては大きな利点です。

2.5 VS Code 統合ターミナルの弱点

VS Code の統合ターミナルで Claude Code を使うと、/terminal-setup によって terminal.integrated.gpuAcceleration が "off" に書き換えられます。これは文字化けを防ぐためです。また、公式ドキュメントでは、大容量のテキストを貼り付けると一部の文字が失われることがあるため、ファイルを経由するワークフローが推奨されています。通知は標準では表示されず、Agent Teams の分割ペインにも対応していません。

つまり、VS Code の統合ターミナルで Claude Code は動くものの、GPU 描画、通知、分割ペインには制約があります。VS Code を使い続けたい場合は、統合ターミナルで CLI を常用するよりも、Claude Code の VS Code 拡張（ネイティブパネル。公式ドキュメント）と外部ターミナルを使い分ける構成が適しています。

2.6 Codex 側の要件

Codex CLI では、通知やサンドボックスに関する設定を ~/.codex/config.toml に記述します（Advanced Configuration）。TUI の通知は、[tui] セクションで指定します。

# ~/.codex/config.toml
[tui]
notifications = ["agent-turn-complete", "approval-requested"]
notification_method = "osc9"   # auto / osc9 / bel

OSC 9 は、デスクトップ通知に使われる制御シーケンスです。この場合も、端末が OSC 9 を OS の通知に変換できるかどうかが重要です。従来の notify = [...] は非推奨となり、Stop などの hooks へ移行するよう案内されています。サンドボックスには、macOS では Seatbelt、Linux では bubblewrap + seccomp が使われます。sandbox_mode は read-only / workspace-write / danger-full-access から選択します（Agent approvals & security）。

---

3. 各ツールを見ていきます

3.1 iTerm2 3.7 —— 現在の環境を維持したまま強化できる

iTerm2 3.7 は2026年9月8日にリリースされました。主な新機能は、iOS 連携アプリの iTerm2 Buddy、Claude Code 統合、タブグループです（iTerm2 News）。

「iTerm2 > Install Claude Code Integration」で、変更内容を確認しながらセットアップできます（出典: iTerm2 公式ドキュメント）

公式ドキュメントによると、この統合機能を導入することで、各 Claude セッションの状態（working / waiting / idle）が iTerm2 の Session Status ツールに表示されます。さらに、Claude との会話、diff ビューア、コードレビュー用セッションをワンクリックで切り替えられる Workgroup も用意されます。

Session Status。注意が必要なセッションほど上に並びます（出典: iTerm2 公式ドキュメント）

仕組みはシンプルです。~/.claude/settings.json に状態報告用の hook を追加し、iTerm2 の Python API を通じてツールベルトに反映します。アンインストールすれば元の状態に戻せる点も安心です。

Chat / Diff / Code Review の3ペインを1クリックで切り替える Workgroup（出典: iTerm2 公式ドキュメント）

具体例: Claude に「認証モジュールをリファクタリングして」と依頼した後、Workgroup の「Diff」を押すと、作業ツリーの差分が横に表示されます。「Code Review」を押せば、別セッションの Claude がレビューを開始します。レビューで得られた指摘は、Clippings を通じて元の Claude に返せます。これまで VS Code に切り替えて行っていた作業を、iTerm2 内で完結できます。

注意点は2つあります。1つ目は、macOS でしか利用できないことです。2つ目は、Agent Teams 用の iTerm2 バックエンド（it2 CLI）について、2026年2月の時点で「iTerm2 を検出できず、何も通知しないまま in-process モードに切り替わる」という不具合が報告されていたことです（#24292、#24301）。安定性を優先するなら、iTerm2 + tmux -CC の組み合わせが手堅い選択です。

3.2 tmux —— 実績のある公式バックエンド

tmux はサーバー・クライアント型の構成を採用しているため、端末を閉じてもセッションが維持されます。SSH 接続先の Linux サーバーでも安定して動作します。Agent Teams の分割ペインも、tmux の split-window や send-keys を使って実装されています。

弱点は、エージェントの状態を意味のある情報として扱えないことです。たとえば、許可待ちで停止しているペインと、単に何も実行していないペインを区別できません。また、初期の Agent Teams では、4つ以上のエージェントを同時に起動するとレイアウトが崩れる、send-keys で送る文字が化けてチームメイトの起動に失敗する、といった問題も報告されています（#23615）。

それでも tmux が重要であり続けるのは、Agent Teams の公式バックエンドであり、さまざまな OSS が下層として利用しているからです。herdr のように tmux そのものを置き換えるツールもありますが、tmux で得たセッション管理の知識は、他のツールに移行しても活かせます。

3.3 cmux —— Mac で「どれが待っているか」を一目で把握

出典: cmux 公式サイト

cmux は、Swift/AppKit で開発された macOS ネイティブのターミナルです。描画エンジンに libghostty を使用し、テーマやフォントなど、既存の Ghostty 設定をそのまま読み込めます。開発の動機は非常に具体的です。Claude Code の通知は毎回「Claude is waiting for your input」と表示され、どの作業に関する通知なのかが分かりません。さらに、タブが増えるとタイトルも読めなくなります。cmux は、こうした問題を解決するために開発されました（GitHub README）。

主な機能を挙げます。

• 縦置きのサイドバー: ワークスペースごとに、git ブランチ、関連する PR の番号と状態、作業ディレクトリ、LISTEN 中のポート、最新の通知内容を表示
• 通知リング: OSC 9/99/777 を検出し、エージェントが待機状態になるとペインを青い枠で強調。サイドバーのタブも点灯し、Cmd+Shift+U で最新の未読通知へ移動
• 内蔵ブラウザ: agent-browser 由来のスクリプト API を持ち、アクセシビリティツリーの取得、要素のクリック、フォーム入力、JS 評価ができる
• CLI と Unix socket: ワークスペースの作成、ペインの分割、キー入力の送信、URL のオープンまでスクリプトで操作

さらに、Claude Code の teammate モードをワンコマンドで起動できます。チームメイトは cmux のネイティブな分割ペインとして作成されるため、tmux は必要ありません。ベータ版の iOS コンパニオンアプリも提供されています。ライセンスは GPL で、無料のオープンソースソフトウェアです。

具体例: 「API 実装」「テスト追加」「ドキュメント更新」の3つのワークスペースで Claude Code を動かし、その間に自分は別の作業を進めます。どれかが許可待ちになると、対象のペインだけが青く強調され、サイドバーには「Bash: npm test を実行しますか？」といった最新の内容が表示されます。そのワークスペースだけを確認すれば済みます。

cmux 自身は「primitive であって solution ではない」と位置づけられており、worktree の管理や PR のワークフローはユーザー自身が構築する前提です。macOS でしか利用できず、プロジェクト自体もまだ若く、更新のペースが速いことは理解しておく必要があります。

3.4 herdr —— 端末を閉じても稼働し続けるランタイム

出典: herdr 公式サイト

herdr は Rust 製の単一バイナリで、iTerm2 や Ghostty など、既存の端末内で動作します。最大の特徴は、常駐サーバーがセッションを保持する点です。ウィンドウを閉じたり、ノート PC の蓋を閉じたり、ネットワークが切断されたりしても、エージェントは稼働し続けます。さらに、マシンを再起動した後はレイアウトを復元し、セッションを再開できます。

もう1つの特徴は、エージェントの状態検知です。herdr は各ペインの内容を読み取り、エージェントを working / blocked / idle / done に分類します。いずれかのエージェントが停止し、応答を待っている場合は、その状態を通知します。Claude Code、Codex、OpenCode、Cursor、Grok など、22種類のエージェント CLI を自動検出できます。

エージェント自身が herdr を操作できる点も重要です。CLI と socket API は同じ機能を提供しており、エージェントはペインの分割、別のエージェントの起動、プロンプトの送信を行えます。さらに、相手が実際に blocked 状態になるまで待機できます。単にキー入力を送って結果を期待するのではなく、相手の状態を確認しながら待つ設計です。

さらに、手元のノート PC、自宅のデスクトップ、リモートサーバーを SSH で追加すると、それぞれのワークスペースとエージェントを、ローカル環境のものと並べて表示できます。

具体例: 金曜日の夕方に、Claude Code へ「すべてのテストが通るまで再試行して」と依頼し、herdr のペインで動かしたままノート PC を閉じます。月曜日に開くとペインは「done」と表示され、途中の出力もそのまま残っています。

注意点として、herdr は v0.9 系で、まだ 1.0 に達していません（Apache-2.0、GitHub スター約4万）。ターミナルエミュレータではないため、描画品質は外側の端末に依存します。また、herdr のペイン内で tmux を入れ子にすると、状態検知が機能しなくなります。tmux と併用するのではなく、tmux の代替として使うのが適切です。

3.5 Warp —— 端末ごと「開発環境」にする

出典: Warp 公式サイト

Warp は Rust 製のクロスプラットフォーム対応ターミナルで、2026年4月にクライアントがオープンソース化されました。UI フレームワークは MIT、それ以外は AGPLv3 でライセンスされており、OpenAI がリポジトリの founding sponsor になっています（GitHub）。

Warp は「Agentic Development Environment」を名乗っています。ブロック単位の出力表示、複数のモデルに対応する内蔵エージェント、Claude Code や Codex などの外部 CLI エージェントの取り込みに対応しています。さらに Factory MCP を通じて、triage → spec → implement → review → verify の工程を複数のエージェントで進めるクラウドサービス「Warp Factories」に作業を依頼できます。

興味深いのは、Warp 自身が2026年9月の記事（Best Terminal for AI Coding Agents in 2026）で、「ブランドではなく層で選ぶ」と整理していることです。Ghostty や iTerm2 はエミュレータ、herdr はランタイム、Warp は ADE と、それぞれ異なる層に位置づけています。そのうえで、多くの開発者は2つの層を組み合わせて使うことになると述べています。本記事の5層モデルは、この整理を拡張したものです。

弱点は、ここで取り上げるツールの中でも動作が比較的重く、利用にアカウントが必要なことです。また、前述のとおり、Claude Code のデスクトップ通知は標準設定では届かないため、hook の設定が必要です。個人が Claude Code と Codex をローカルで使うだけなら、機能が過剰と感じられるかもしれません。組織で作業をクラウドに移し、その実行状況を計測・管理したい場合に、特に力を発揮します。

3.6 Zed —— エディタ側からエージェントを並列に

出典: Zed 公式ブログ

Zed は Rust 製の高速なエディタです。連携の中心となるのは、ACP（Agent Client Protocol） です。ACP は JSON-RPC ベースのオープン標準で、エディタがエージェントを別プロセスとして起動し、ファイル操作や権限要求をエディタ側の UI で扱えるようにします（zed.dev/acp）。Zed のドキュメントでは、Gemini CLI、Claude Code、Codex CLI、OpenCode との連携が紹介されています。

2026年4月29日にリリースされた Zed 1.0 の主要機能は、エージェントの並列実行です。1つのウィンドウ内で複数のエージェントを同時に動かし、コードベースの異なる部分を分担させられます。各エージェントによる編集はエディタ上に diff として反映され、その場でレビューできます。これは、ターミナル単体では得にくい強みです。

ただし、制約もあります。Zed の外部エージェント連携は ACP アダプタを経由するため、Claude Code の一部のスラッシュコマンドは、Zed のエージェントウィンドウ内で動作しないと指摘されています。Zed の公式ドキュメント（External Agents）によると、Claude Agent の hooks と Agent Teams は現時点で対応していません。Claude Code の hooks や Agent Teams を積極的に活用している場合は、導入を見送るのが妥当です。

3.7 Orca —— OSS で「worktree＋端末＋ブラウザ」を一体化

出典: Orca 公式ドキュメント

Orca は、複数の AI コーディングエージェントを並列で動かすためのデスクトップアプリです。タスクごとに git worktree、エージェント用ターミナル、ブラウザタブを用意します。自らを IDE ではなく、ADE（Agent Development Environment） と位置づけています。

対応エージェントは幅広く、Claude Code、Codex、Gemini、Cursor CLI、GitHub Copilot、OpenCode、Amp、Goose、Cline、Kiro、Qwen Code などが事前設定済みで、任意の CLI エージェントも追加できます。レビュー面も充実していて、diff の特定行に Markdown コメントを付けてまとめてエージェントに返せるほか、CI の確認、コンフリクト解消、PR 作成もアプリ内で完結します。Design Mode では、worktree ごとの Chromium ウィンドウで UI 要素をクリックすると、その HTML・CSS・切り抜きスクリーンショットがエージェントに送られます。

具体例: 「このボタンの余白がおかしい」とチャットで詳細に説明する代わりに、Design Mode でそのボタンをクリックします。すると、対象要素の情報がそのまま Claude Code に渡されます。フロントエンドにおける、言葉だけでは伝えにくい修正に効果的です。

MIT ライセンスのもとで無料で利用でき、macOS、Windows、Linux に対応しています。SSH 接続先のマシン上でエージェントを動かすことも可能です。一方、Chromium と Monaco エディタを内包する比較的重いアプリです。機能追加のペースも非常に速く、UI や API が変更されやすいことは、導入前に理解しておきましょう。

3.8 Conductor —— Issue から PR までを最短で

出典: Conductor 公式ドキュメント

Conductor は macOS 向けアプリで、Claude Code、Codex、Cursor、OpenCode を並列で動かせます。タスクごとに、独立したワークスペース、ブランチ、ファイル、ターミナル、diff、レビューの経路が用意されます。作業完了後は、diff の確認、PR の作成、マージ、ワークスペースのアーカイブまで、一連の操作をアプリ内で進められます。

実務で効くのは細かい配慮です。.env.local のような gitignore 済みファイルは「Files to copy」で新しいワークスペースに複製でき、依存のインストールは setup スクリプトに書け、複数の dev サーバーを同時に動かすときは CONDUCTOR_PORT でワークスペースごとにポート帯を分けられます。

料金は Free が $0 でローカルのワークスペース、Pro が月 $50 で Conductor Cloud（クラウドワークスペース）や Multiplayer、API が付きます（Pricing）。クラウドワークスペースは Vercel のサンドボックス上で動き、アプリを閉じても作業が続きます。

具体例: GitHub の Issue を3つ選び、それぞれのワークスペースを作成します。3つの Claude Code が異なる worktree で並列に作業し、完了したものから diff を確認して PR を作成します。git worktree add の実行や .env のコピーなど、従来は手作業で行っていた準備を省けます。

注意点として、公式ドキュメント自身が「ワークスペースの分離は開発上の分離であって、セキュリティ境界ではない」と明記しています。並列セッションは同じアカウントの利用枠を消費しますし、クラウドではチャット内容が Conductor 側に保存されます。

3.9 Traycer —— 「仕様を先に固める」ためのワークスペース

出典: Traycer 公式サイト

Traycer は、他のツールとは異なる層に位置します。「どのように実行するか」ではなく、「何を作るか」を事前に定めるためのワークスペースです。作業を Task 単位でまとめ、その中にエージェント（Chat または Terminal インターフェース）、ファイル、git diff、spec、ticket、review などの artifact を配置します（Traycer Docs）。

自分が契約しているサブスクリプションを持ち込む BYOA 方式で、Claude Code、Codex、OpenCode、Cursor を1つのワークスペース上で並べて使用できます。エージェント同士で質問を送り合い、レビューを依頼したり、作業を引き継いだりできます。

具体例: 「決済プロバイダを Stripe から Adyen に切り替える」という大きな変更を、まず Traycer で PRD、技術計画、チケット群に分解します。チケットごとに Claude Code へ handoff し、エージェントは仕様を読みますが書き換えません。実装後は仕様と照らして検証します。「途中で何を作っていたか分からなくなる」問題への対策です。

料金は、BYOA が $0、クラウド同期を利用できる Sync が月額 $10、クレジット付きの Lite が $20、Pro が $40、Ultra が $100 です（2026年9月時点、Pricing）。小さなタスクに対しては準備の負担が大きいため、比較的規模の大きな機能をチームで分担する場合に適しています。

3.10 OpenCode —— 「第3のエージェント」として

出典: OpenCode 公式サイト

OpenCode はターミナルではなく、Claude Code や Codex と同じ層に属する エージェントです。MIT ライセンスのオープンソースソフトウェアで、ターミナル、IDE、デスクトップアプリから利用できます。Claude、GPT、Gemini など、さまざまなプロバイダーのモデルに接続できます。GitHub スターは 208K を超えており、この分野で最大級のコミュニティを持ちます。

ターミナル選びの文脈で重要なのは client/server 構成です。opencode serve でヘッドレスの HTTP サーバーを立て、TUI はそのクライアントとして動くため、複数のクライアントから同じサーバーに接続したり、プログラムから操作したりできます（Server）。サーバーをリモートに置いて、手元の端末から opencode attach で繋ぐ、という使い方が自然にできます。

Claude Code と Codex を主に使う人にとっての位置づけは、「ローカルモデルや別プロバイダを使う保険」です。cmux、herdr、Orca、Conductor はいずれも OpenCode に対応しているので、どの層を選んでも一緒に動かせます。

3.11 あわせて知っておきたいもの

• Ghostty: Shift+Enter もデスクトップ通知も設定不要で動く、最速級の端末です。ただし AI 機能は意図的に持たず、Agent Teams の分割ペインは非対応です（中で tmux を使えば回避できます）。cmux と Orca の描画エンジンでもあります。
• Claude Code Desktop: 2026年4月の刷新で、1つのウィンドウで複数の Claude セッションを並べ、サイドバーで管理し、ペインをドラッグで並べ替えられるようになりました。ターミナルを使わずに並列運用したい人の選択肢です。
• Codex アプリ: スレッドごとに worktree を持ち、ローカル環境とのハンドオフやスケジュール実行に対応しています。2026年7月に ChatGPT デスクトップアプリへ統合されたと報じられており、CLI と IDE 拡張も引き続き提供されています。Codex を中心に使う人にとっては、有力な選択肢です。

---

4. ツール別の比較

各ツールの対応環境、実行基盤、連携・レビュー機能を順に整理します。

• iTerm2 3.7
  • 環境・価格：macOS。無料（GPL）。
  • 状態・実行基盤：Session Status による状態表示に優れています。永続化には tmux -CC の併用が必要で、worktree の分離にも別途対応が必要です。
  • 連携・レビュー：Agent Teams の分割ペインには it2 または tmux -CC で対応します。Python API と it2 から操作でき、Workgroup でレビューできます。
• tmux
  • 環境・価格：macOS、Linux。無料（ISC）。
  • 状態・実行基盤：エージェントの状態表示はありません。SSH 先でもセッションを永続化でき、claude --worktree を併用すれば worktree を分離できます。
  • 連携・レビュー：Agent Teams の分割ペインに公式対応しています。send-keys と capture-pane で操作できますが、レビュー機能はありません。
• cmux
  • 環境・価格：macOS。無料（GPL）。
  • 状態・実行基盤：通知リングとサイドバーで状態を把握できます。永続化や worktree の分離には別途対応が必要です。
  • 連携・レビュー：Agent Teams をネイティブな分割ペインで表示できます。CLI、socket、ブラウザから操作でき、レビュー機能は条件付きで利用できます。
• herdr
  • 環境・価格：macOS、Linux、Windows（ベータ版）。無料（Apache-2.0）。
  • 状態・実行基盤：4段階の状態表示に対応しています。常駐サーバーで実行を維持でき、複数マシンを横断できます。worktree の分離には別途対応が必要です。
  • 連携・レビュー：Agent Teams はプラグインで対応します。wait-until-blocked から操作できますが、レビュー機能はありません。
• Warp
  • 環境・価格：macOS、Linux、Windows。無料プランあり（MIT + AGPL）。
  • 状態・実行基盤：状態表示に対応しています。クラウド機能の Factory で実行を維持でき、worktree の分離には別途対応が必要です。
  • 連携・レビュー：Agent Teams の分割ペインには対応していません。MCP から操作でき、レビュー機能も利用できます。
• Zed
  • 環境・価格：macOS、Linux、Windows。無料（OSS）。
  • 状態・実行基盤：スレッド単位で状態を確認できます。実行の永続化やリモート実行には対応しておらず、worktree の分離には別途対応が必要です。
  • 連携・レビュー：Agent Teams の分割ペインには対応していません。ACP から条件付きで操作でき、エディタ上の diff でレビューできます。
• Orca
  • 環境・価格：macOS、Windows、Linux。無料（MIT）。
  • 状態・実行基盤：Inbox で状態を把握できます。SSH と自己ホストに対応し、worktree を分離できます。
  • 連携・レビュー：Agent Teams の分割ペインには対応していません。Orca CLI から操作でき、行コメントを付けて PR へつなげられます。
• Conductor
  • 環境・価格：macOS。Free プランと Pro プラン（50ドル）があります。
  • 状態・実行基盤：状態表示に対応しています。Pro では Cloud を利用でき、worktree も分離できます。
  • 連携・レビュー：Agent Teams は環境変数を設定すれば利用できます。Pro の API から操作でき、diff の確認から PR 作成まで進められます。
• Traycer
  • 環境・価格：デスクトップ。BYOA 方式で、無料プランがあります。
  • 状態・実行基盤：状態表示、Sync、worktree の分離に対応しています。
  • 連携・レビュー：Agent Teams と操作用 API には対応していません。artifact を使ったレビューに優れています。
• OpenCode
  • 環境・価格：macOS、Linux、WSL。無料（MIT）。
  • 状態・実行基盤：serve と attach によって実行を分離できます。状態表示と worktree 分離は、この比較では評価対象外です。
  • 連携・レビュー：HTTP API と ACP から操作できます。Agent Teams とレビュー機能は、この比較では評価対象外です。
• VS Code 統合端末
  • 環境・価格：macOS、Linux、Windows。無料。
  • 状態・実行基盤：状態表示、実行の永続化、リモート実行、worktree の分離には対応していません。
  • 連携・レビュー：Agent Teams の分割ペインには対応していません。外部からの操作は限定的ですが、拡張機能の diff でレビューできます。

---

5. ユースケース別のおすすめ

• 1〜2つのエージェントを使う個人開発
  • 第一候補：iTerm2 3.7 ＋ Claude Code Integration
  • 代替：Ghostty
  • 理由：別の端末へ乗り換えずに、状態表示、Diff/Review、iOS 通知を利用できます。
• Agent Teams を分割ペインで見たい
  • 第一候補：iTerm2 ＋ tmux -CC（＋ tmux.conf 3行）
  • 代替：cmux
  • 理由：公式に対応しているのは tmux と iTerm2 です。
• 3〜6つのエージェントを並列で動かし、待機中のものをすぐ見つけたい（Mac）
  • 第一候補：cmux
  • 代替：herdr
  • 理由：通知リングとサイドバーにより、確認が必要なエージェントをすぐ見つけられます。
• 長時間ジョブ、SSH 先、複数マシンで使いたい
  • 第一候補：herdr
  • 代替：tmux ＋ 自前の hook
  • 理由：PC の蓋を閉じても処理が止まらず、複数マシンを横断して管理できます。
• Issue から worktree、PR までを GUI で効率化したい（Mac）
  • 第一候補：Conductor（Free プランから利用可能）
  • 代替：Orca
  • 理由：setup / run スクリプト、ポート分離、PR フローがそろっています。
• OSS・クロスプラットフォームの ADE で、ブラウザを使って UI を検証したい
  • 第一候補：Orca
  • 代替：Conductor
  • 理由：worktree、端末、ブラウザの三つがそろい、Design Mode も利用できます。
• 仕様駆動で大きな機能をチーム開発したい
  • 第一候補：Traycer
  • 代替：Claude Code の plan mode ＋ 手書きの spec
  • 理由：spec、ticket、review を artifact として残せます。
• VS Code を使い続けたい
  • 第一候補：VS Code 拡張（Claude Code / Codex）＋ 外部端末
  • 理由：統合ターミナルには、GPU 描画、通知、分割ペインの制約があります。
• エディタを刷新し、並列エージェントを編集画面で扱いたい
  • 第一候補：Zed（ACP）
  • 理由：一つのウィンドウで並列スレッドを管理でき、diff もエディタ上で確認できます。
• モデル非依存の構成やローカルモデルを使いたい
  • 第一候補：OpenCode ＋ herdr / cmux
  • 理由：75以上のプロバイダに対応し、serve と attach で実行環境を分離できます。
• Codex を中心に使いたい
  • 第一候補：Codex アプリ（ChatGPT デスクトップ内）
  • 代替：Conductor
  • 理由：スレッドごとに worktree を持ち、自動実行にも対応しています。
• Windows または Linux で使いたい
  • 第一候補：Orca / herdr / Warp / Zed
  • 理由：cmux、Conductor、iTerm2 は macOS 専用です。

---

6. もう一歩踏み込んだ話

6.1 「気づくまでの時間」を自分で測る

ターミナル間の入力遅延の差は数ミリ秒程度です。しかし、AI コーディングでより大きな損失になるのは、エージェントが許可待ちのまま停止している時間です。この時間は製品カタログからは分からず、実際の運用の中で計測する必要があります。Claude Code の hooks を使えば、簡単に記録できます。

// ~/.claude/settings.json（概念例）
{
  "hooks": {
    "Notification": [
      { "matcher": "permission_prompt|idle_prompt",
        "hooks": [ { "type": "command", "command": "~/bin/tta-log notify" } ] }
    ],
    "UserPromptSubmit": [
      { "hooks": [ { "type": "command", "command": "~/bin/tta-log submit" } ] }
    ]
  }
}

#!/bin/sh
# ~/bin/tta-log : 通知と復帰の時刻を端末名つきで記録する
mkdir -p ~/.tta
printf '{"ts":%s,"event":"%s","term":"%s","tmux":%s}\n' \
  "$(date +%s)" "$1" "${TERM_PROGRAM:-unknown}" "${TMUX:+true}" >> ~/.tta/events.jsonl

notify から次の submit までの時間が、「気づくまでの時間（Time-to-Attend）」です。ターミナルを1〜2週間ずつ切り替えて中央値を比較すれば、単に「cmux は良さそう」と評価するのではなく、「自分の環境では、iTerm2 の中央値が4分、cmux は50秒だった」と数値で判断できるようになります。

6.2 ステータス信号を1本にまとめる

エージェントの状態をターミナルへ伝える経路は、現在のところ統一されていません。具体的には、通知用の OSC 9/99/777、iTerm2 の Session Status 用シーケンス、cmux notify、herdr の hook などがあります。ツールを切り替えるたびに hook を書き直すのは非効率です。そこで、状態通知の処理を1本の agent-status スクリプトに集約し、実行環境を検出して、対応するすべての経路に状態を送る構成がおすすめです。

Claude Code hook / Codex 通知 ──▶ agent-status <state> <detail>
        ├─ 常に: OSC 9 でデスクトップ通知（tmux 内なら allow-passthrough 前提）
        ├─ iTerm2 なら: Session Status に状態を書く
        ├─ cmux があれば: cmux notify
        └─ herdr があれば: herdr に状態を報告

こうしておくと、端末は「交換可能な部品」になります。iTerm2 の公式統合は Claude Code だけが対象なので、Codex の状態も同じ Session Status に出したい人には、この自作スクリプトに価値があります。

6.3 worktree はセキュリティ境界ではありません

Conductor の公式ドキュメントに明記されているとおり、worktree の分離は作業間の衝突を避けるためのものであり、エージェントを安全に閉じ込める仕組みではありません。必要な隔離レベルは、エージェントの並列数ではなく、どの程度まで権限の制限を緩和するかに応じて決めるのが安全です。

段5  クラウドサンドボックス / VM   Conductor Cloud, Orca の VM, Warp Factories
段4  OS サンドボックス            Codex の Seatbelt / bubblewrap, Claude Code のサンドボックス
段3  git worktree                  claude --worktree, Conductor, Orca, Codex アプリ, Traycer
段2  tmux / herdr セッション       プロセスの寿命だけ分離
段1  ペイン / タブ                  何も分離しない

--dangerously-skip-permissions や danger-full-access のような権限緩和モードで実行するなら、少なくとも段4以上の隔離を用意するのが望ましいでしょう。

6.4 「エージェントが端末を操作できる」ことの裏面

cmux、herdr、iTerm2（Python API / it2）、Orca CLI、tmux の send-keys には、いずれも エージェント自身が別のペインへキー入力を送り、画面の内容を読み取れる仕組みがあります。これは生産性を高める一方で、プロンプトインジェクションの影響を受けたエージェントが、隣のペインに表示された許可プロンプトへ「y」を送るための経路にもなり得ます。

Claude Code は、チームメイト間のメッセージを「ユーザーによる承認ではない」ものとして扱う設計です。しかし、ターミナル API を経由したキー入力は、その制御の対象外です。信頼できないリポジトリを扱うエージェントは、別のワークスペースやマシンに分けましょう。また、権限緩和モードとこれらの API を同時に使わないなど、事前に運用ルールを定めておく必要があります。

---

おわりに

「AI コーディングのためのターミナル選び」を調べ始めたとき、私は、どれか1つの製品へ乗り換える問題だと考えていました。しかし、実際には、それぞれのツールが担う層を理解し、自分の運用に必要なものだけを組み合わせることが答えでした。

iTerm2 + VS Code を使っているなら、まずは iTerm2 3.7 の Claude Code 統合と、tmux 用の3行の設定から始めてください。それで不足を感じるようになったら herdr または cmux を追加し、PR 単位の並列作業が日常になったら Conductor または Orca を導入します。この順番なら、現在の環境を保ちながら、必要に応じて段階的に強化できます。

最後に、この記事で取り上げたツールの多くは、まだバージョン 1.0 に達していないか、リリースから数か月しか経っていません。Agent Teams も実験的な機能です。導入前に、バージョン、料金、対応状況を必ず公式サイトで再確認してください。

---

参考リンク（一次情報）

• Claude Code Docs: ターミナル設定 / Agent Teams / VS Code
• iTerm2: Claude Code Integration / Session Status / News
• cmux / herdr / Warp / Zed ACP
• Orca Docs / Conductor Docs / Conductor Pricing
• Traycer / OpenCode / OpenCode Server
• Codex Docs（設定） / Codex サンドボックス