getpaseo

Paseo：エージェント開発の操作・判断負担を減らす個人実践 エージェント開発における操作と判断の負担 開発エージェントに作業を任せても、その間ずっと画面の前にいるのは大変でした。 結局、まとまった時間があるときにしか作業を進められないことが、私にとっての課題でした。 そこで、Paseo画面から複数のエージェントへ作業を依頼する環境を使っています。 スマホから依頼や確認を行い、実装やレビューを役割に応じて分ける構成です。 個人開発で使っている構成と採用理由、運用で確認していること、感じた効果、外出先からの復旧経路を紹介します。 Paseoの位置付けと全体構成 Paseoは、複数の開発エージェントを動かし、そのセッションや作業場所を管理する基盤です。 デスクトップ・モバイル・Web・CLIから利用でき、エージェントは手元やサーバーなどの実行ホスト上で動きます。 製品の概要はGetting started - Paseo Docsに説明されています。 私の環境では、Windows上のWSL2を実行ホストにしています。 Paseo画面からの依頼を受け、実行ホスト上でエージェントを起動・管理するのがPaseo daemon（以下、デーモン）です。 依頼の分解、担当の割当、成果物の照合・統合を担うエージェントをOrchestrator（調整役）と呼び、実装エージェントとレビューエージェントへ作業を分けています。 実線は通信・制御、破線はファイル成果物への操作・参照を示しています。 Orchestratorから実装・レビューエージェントへの依頼と結果の取得は、デーモンを介して行います。 成果物は各エージェントが利用するワークスペースで管理します。 エージェントの役割と実行の仕組み 要素 この環境での役割 Paseo画面 人間がエージェントへ依頼し、判断や結果確認を行う入口 デーモン エージェントの起動、セッションと作業場所の管理 Orchestrator 依頼の分解、担当の割当、成果物の照合・統合 実装エージェント 指定した範囲のファイル編集やコマンド実行 レビューエージェント 実装結果を読み取り、問題点や確認事項を報告 この環境では、OrchestratorとレビューエージェントにCodex、実装エージェントにCodexまたはClaudeを割り当てています。 役割とモデルの割当は、私の運用規則で決めています。 CodexなどのエージェントCLIを起動し、出力や入力を扱うPaseo側の接続の仕組みを、provider（プロバイダー）と呼びます。 実際のエージェントCLIは実行ホスト上のプロセスとして動くと、Providers - Paseo Docsに説明されています。 Orchestratorが担当への依頼や状態確認に使うのがPaseoツールです。 プロバイダーに応じてネイティブのツールインターフェースまたはMCP（Model Context Protocol）を通じて提供され、操作の一覧はMCP reference - Paseo Docsで確認できます。 完了通知による待機と時間をおいた実行 create_agentとsend_agent_promptは、担当の作業完了を待たずに戻る操作です。 Paseo内の依頼元エージェントには、完了・エラー・権限要求の通知が既定で届きます。 Orchestratorはいったん応答を終え、通知が届いてから結果の確認や次の判断を進められます。 通知はnotifyOnFinishで制御でき、falseにすると届きません。 時間をおいて再評価したい場合には、Heartbeat（ハートビート）とSchedule（スケジュール）も利用できます。 仕組み 動き出すきっかけ 対象と動作 完了通知 担当エージェントの作業終了 依頼元のエージェントに通知を届ける ハートビート（create_heartbeat） cronで指定した周期 同じエージェントへプロンプトを送る スケジュール（create_schedule） cronで指定した周期 実行ごとに新しいエージェントを起動する ハートビートは会話を続けながら定期的に状況を見直す用途、スケジュールは毎回新しいセッションで行う定例作業に対応します。 この違いはSchedules - Paseo Docsに説明されています。 完了通知を使った待機はPaseo内のエージェント向けです。 外部MCPクライアントから利用する場合は、get_agent_statusやget_agent_activityで結果を確認する方式として、MCP reference - Paseo Docsに説明されています。 プロジェクトと作業場所の分離 Paseoのproject（プロジェクト）にはリポジトリなどのディレクトリを登録し、workspace（ワークスペース）には作業場所を結び付けます。 既存のチェックアウトを使う方法と、Git worktreeで作業ディレクトリを分ける方法があります。 Git worktrees - Paseo Docsでは、Git worktreeに対応したワークスペースの作成と、その中でのエージェント起動が説明されています。 Git worktreeで分離するのは作業ディレクトリです。 プロセスや認証情報の権限管理は別途必要です。 Paseoを選んだ理由 役割に応じたエージェントとモデルの使い分け 一つ目の理由は、オーケストレーションを利用できることです。 実装、調査、レビューでは必要な能力が異なるため、Orchestratorを通して作業を分担し、役割に合ったエージェントとモデルを選びたいと考えました。 この使い分けによって、できるだけ無駄を減らすことが狙いです。 スマホからの依頼と確認 二つ目の理由は、スマホから操作できることです。 パソコンの前に戻る時間を確保しなくても、生活の合間に依頼や確認を行えるようにしたいと考えました。 仕事の休憩中など、短い時間でも個人開発に関われることが、私には重要でした。 スマホで行うのは主に依頼、判断、結果の確認です。 実際のファイル編集やコマンド実行は、実行ホスト上のエージェントが担当します。 複数のAIによる検討と判断負担の軽減 三つ目の理由は、複数のAIによる検討を利用し、人間が毎回判断する負担を減らしたいことです。 実装とレビューを別のセッションへ分けることで、実装結果に加え、別の視点からの指摘も受け取れます。 期待しているのは、人間が判断するための材料を整え、確認の負担を軽くすることです。 複数のAIが同じ前提を誤る可能性もあるため、最終判断と承認は人間に残します。 運用で確認していること 作業対象と実行結果の照合 続きを依頼するときは、対象セッション、ワークスペース、作業ディレクトリを照合し、編集範囲と確認条件を明確にします。 依頼が届いたことと、意図したリポジトリで作業が完了したことは別に確認します。 応答が途切れた変更操作は、二重実行を防ぐため、エージェントの状態・履歴・実ファイルを照合してから再実行を判断します。 作業範囲、重要な変更、マージや公開などの最終判断と承認は人間が行います。 完了待ちと定期的な確認の使い分け 担当の完了を待つだけなら完了通知を使い、時間をおいて状況を見直す必要がある場合にハートビートを使い分けます。 たとえば、外部のビルド結果を定期的に確かめる用途はハートビート、毎日の調査を新しいセッションで始める用途はスケジュールが候補になります。 LLMを使って状態照会を繰り返す運用と比べ、完了通知を待つ構成では、確認用の入力や応答を会話に積み重ねる回数を減らせます。 これは確認用のトークンを抑えるための設計上の利点で、節約幅は確認頻度や通知後の処理内容によって変わります。 ハートビートやスケジュールも、実行のたびにエージェントの処理を伴います。 利用する場合はmaxRunsやexpiresInで回数・期限を絞り、用が済んだ定期実行を残さないようにします。 デーモンと実行ホストが利用できることを前提に、必要なタイミングだけ確認する構成を選びます。 実行環境と接続経路の保守 Paseo、エージェントCLI、認証、実行ホストを維持する作業は残ります。 外出先から利用する接続経路も、実行環境と合わせて管理します。 実例：機能説明の追加を依頼してからマージするまで この記事に完了通知と定期実行の説明を加えた作業を、具体例として紹介します。 依頼したのは、機能の違いと、ポーリングを減らすことで確認用のトークンを抑える考え方を説明することでした。 この文書作業では、Orchestratorが編集と検証も担当し、構成の相談とレビューを別セッションへ分けました。 構成だけを相談する助言役をArchitectと呼んでいます。 工程 担当 実際に行ったこと 目的と範囲の指定 人間 追加したい機能と、記事で伝えたい観点を指定 根拠の確認 Orchestrator 公式資料で通知・ハートビート・スケジュールの動作を確認 構成の相談 Architect 機能の説明と運用上の使い分けを、別の節に置く案を提示 編集と検証 Orchestrator 本文と図を修正し、形式・HTML生成・未公開設定を確認 読み取りレビュー 新しく起動したレビューエージェント 公式仕様と本文の整合、機能と体感の区別などを確認して報告 PR作成と統合 Orchestrator・人間 人間の承認後にOrchestratorがPRを作成し、マージは人間が実施 レビューを依頼した後は、Paseoの完了通知を待ち、通知後に報告内容と原稿を照合しました。 レビュー対象と手元の原稿が一致していることも確認し、結果と差分を人間へ返しました。 何を記事に加えるか、PRを作成するか、マージするかは、人間が判断しました。 作業の段取りをエージェントへ任せつつ、人間が内容と反映範囲を確認する流れです。 個人利用で感じた効果 採用理由に対する手応え 作業に応じた役割分担、スマホからの操作、複数のAIによる検討を組み合わせることで、採用時に挙げた課題を軽くできたと感じています。 エージェントに任せながらも画面に張り付き続ける、という前提を減らせたことが、私にとって大きな変化でした。 これまでの運用で感じた確認頻度の変化 以前は、約5分に1回は確認しないと作業が進んでいないと感じていました。 エージェントへ役割を分けて任せる運用を続ける中で、確認は約30分に1回で済むようになったと感じました。 私の評価では、その間の作業量と品質は以前と同程度です。 これらは、構成を見直しながら運用してきた中での体感の目安です。 現在の構成への変更だけを比較した結果や、同じ条件で測定したベンチマークを表す数値ではありません。 外出先からの手動復旧経路 Paseo画面からの依頼経路が使えなくなったときに備え、SSHクライアントのTermiusから、Tailscale経由でWindows側のSSHサーバーへ接続する経路を用意しています。 通常の依頼経路とは別に、人間が状態を確認して復旧操作を行うための経路です。 通常の依頼: 人間 ↔ Paseo画面 ↔ デーモン ↔ エージェント 手動復旧: Termius → Tailscale経由のWindows側SSHサーバー → WSL2再起動 実際に外出先でWSL2が停止した際、TermiusからTailscale経由でWindows側のSSHサーバーへ接続し、WSL2を再起動しました。 そのときはWSL2の起動時にPaseoなど必要なサービスが自動で起動するように設定しており、作業を継続できる状態に戻りました。 この復旧経路を使うには、Windowsホスト、ネットワーク、Tailscale、SSHが利用できることが前提です。 WSL2の手動再起動とサービスの自動起動を組み合わせているため、ホストの電源や接続経路自体に障害がある場合には、別の対処が必要です。 製品と接続方式の説明は、Termius - Modern SSH ClientとProtect your SSH servers using Tailscale · Tailscale Docsを参照してください。 導入時の判断材料と限界 必要な構成は、どこに負担を感じているかによって変わります。 一つのエージェントで十分なら、まずその作業範囲と確認方法を整えるだけでもよいと考えます。 複数の担当を使い分けたい、スマホから関わりたいという課題がある場合に、Paseoを使った役割分担が検討材料になります。 導入前の確認項目 判断する内容 実行環境 エージェントCLIと認証、対象リポジトリ、実行ホストとWSL2の起動条件 役割分担 実装・レビューの担当範囲、人間が承認する操作、成果物の確認方法 外出先からの接続 Paseo画面と復旧用SSHに誰が接続でき、どの操作を許可するか 維持管理 認証・依存更新・障害切り分け・外出先からの復旧を誰が担うか チームで利用する場合は、エージェントが利用する外部サービスへ渡す情報の範囲と、端末・認証情報の管理方法を、所属する組織の規則に沿って決める必要があります。 参考資料 GitHub - getpaseo/paseo: Orchestrate multiple coding agents from desktop and mobile · GitHub Getting started - Paseo Docs Providers - Paseo Docs Git worktrees - Paseo Docs MCP reference - Paseo Docs Schedules - Paseo Docs Protect your SSH servers using Tailscale · Tailscale Docs Termius - Modern SSH Client

Paseo と DeepSeek Harness (DSH) で構築する自律管理型マルチエージェント開発スタジオ Paseo と DeepSeek Harness (DSH) で構築する：100% 自律管理型マルチエージェント開発スタジオの深層 AgDex システム＆アーキテクチャチーム 2026年11月2日 読了目安 15分 マルチエージェント設計＆データ主権 技術エグゼクティブ・サマリー 単一のターミナル内でコーディングエージェントを孤立して動かす時代は終わりました。本稿では、Paseo のローカルデーモンおよび管理型 Git Worktree と、DeepSeek Harness (DSH) の Cordis プラグイン実行基盤を統合し、完全セルフホストのオープンソース・マルチエージェント開発工坊を構築する方法を徹底解剖します。Direct Provider 通信による思考プロセスのリアルタイム可視化、対話型質問カード、そして計算コスト 83.2%〜92.8% 削減（商用フラッグシップ比では 95% 以上の削減）の実証データを公開します。 1. ターミナルの限界：なぜ単一エージェントの CLI 運用はスケールで破綻するのか 2025年から2026年にかけて、最先端基盤モデルに支えられた自律型コーディングエージェント群——Claude Code（Claude Opus 5.5 / Sonnet 5.5 搭載）から OpenAI Operator / Codex（GPT 6.1 SOL 搭載）、Google Antigravity（Gemini 4 Argon 搭載）、Cursor、Aider に至るまで——は開発者の生産性を飛躍的に高めました。しかし、単機能の生成にとどまらず複数タスクにわたる大規模スプリントを並行処理させようとした途端、深刻なボトルネックに直面します。それは「単一ターミナルかつ単一作業ディレクトリの制約」です。 エンジニアが1つの Git リポジトリ内で複数のエージェントプロセスを立ち上げると、ファイルシステムは大混乱に陥ります。バックグラウンドのビルドウォッチャーがクラッシュし、未コミットのコードが別エージェントに上書きされ、並行実行された Git コマンドが致命的な .git/index.lock 競合を頻発させます。手動で大量の tmux ペインを立ち上げて回避しようとしても、コンテキスト切り替えの認知的負荷は限界に達します。 さらに、商用のプロプライエタリなクラウド環境は、高額なシート課金や不透明なトークン手数料、強制的なテレメトリ送信で開発組織を囲い込みます。Claude opus 5.5、GPT 6.1 SOL、Gemini 4 Argon といった最先端商用モデルは単一タスクで卓越した推論力を発揮するものの、多重エージェントによる連続的なスプリントループを商用クラウド API だけで回し続けることは、組織の API 予算を急速に逼迫させます。現場が真に求めているのは、物理的な作業領域の隔離、複数デバイスからの遠隔操作、そして外部クラウドに依存しない安全な自律型マルチエージェント管理ハブです。 2. Paseo アーキテクチャ：ローカルファースト・デーモンと管理型 Git Worktree Paseo（github.com/getpaseo/paseo）は、分散型ローカルコントロールプレーンによってこの並行制御の課題を根本から解決します。核となる軽量 TypeScript デーモンが各エージェントのライフサイクルを監視し、プロセスI/Oを統括し、デスクトップ（Electron）、Web、モバイル（Expo iOS/Android）へエンドツーエンド暗号化（E2EE）WebSocket を介してリアルタイム中継します。 +─────────────────────────────────────────────────────────────────────────────────────────────────+ | PASEO + DEEPSEEK HARNESS (DSH) MULTI-AGENT ARCHITECTURE | +─────────────────────────────────────────────────────────────────────────────────────────────────+ | | | [ CLIENT ACCESS MATRIX ] | | • Desktop (Electron) • Web Dashboard • Mobile App (Expo / iOS / Android) | | │ (E2EE WebSocket Relay) | | ▼ | | [ PASEO LOCAL CONTROL DAEMON ] (Node / TypeScript) | | • Workspace Manager • Process Supervisor • Diff / Stream Review Engine | | │ | | ┌───────────────────────┼────────────────────────┐ | | ▼ ▼ ▼ | | [ WORKSPACE: feat/auth ] [ WORKSPACE: feat/db ] [ WORKSPACE: test/e2e ] | | • Worktree: slug-auth • Worktree: slug-db • Worktree: slug-tests | | • Branch: feature/auth • Branch: feature/db • Branch: test/e2e | | • Hook: paseo.json • Hook: paseo.json • Hook: paseo.json | | │ │ │ | | ▼ (Direct Provider IPC) ▼ (Direct Provider IPC) ▼ (Direct Provider IPC) | | [ DEEPSEEK HARNESS (DSH) ] [ DEEPSEEK HARNESS (DSH) ] [ DEEPSEEK HARNESS (DSH) ] | | • Preset: PTC (Reasoning) • Preset: Standard (CRUD) • Preset: Minimal (Test Suite) | | • Cordis Plugin Kernel • Cordis Plugin Kernel • Cordis Plugin Kernel | | • Reversible Registers • Reversible Registers • Reversible Registers | | | +─────────────────────────────────────────────────────────────────────────────────────────────────+ Paseo は重量級の仮想マシンを起動する代わりに、管理型 Git Worktree（決定論的に $PASEO_HOME/worktrees/<hash>/<slug>/ 配下に配置）を作業空間の隔離基盤として採用しています。 - 自動ブランチプロビジョニング: origin/main からの自動分岐や個別プルリクエストのチェックアウトを、共通の .git オブジェクトデータベースを共有しながら即座に実行します。 - 自動化されたライフサイクルフック: paseo.json を定義することで、各 Worktree 作成時の依存関係インストールや .env 生成、アーカイブ時の自動クリーンアップを自動化します。 - 仮想マシンのメモリオーバーヘッド皆無: 1インスタンスあたり 1.5GB〜3GB を消費する Docker コンテナとは異なり、Git Worktree のディスク差分はわずか 50MB 未満、起動時間は 180 ミリ秒以下です。 このアーキテクチャにより、Git インデックスのロックやコードの衝突、メモリ不足に悩まされることなく、同一リポジトリ上で 3台、5台、10台のエージェントを同時に安定稼働させることが可能になります。 3. DeepSeek Harness (DSH)：Cordis プラグインカーネルの全貌 Paseo がオーケストレーターと作業領域の隔離を担う一方、自律的な推論とツール実行エンジンを提供するのが DeepSeek Harness (DSH)（@deepseek-ai/dsh）です。DeepSeek はエージェント設計において「Agent = Model + Harness」という明快な哲学を掲げています。 従来のフレームワークはツール定義やステートループを単一の巨大なクラスに固定しがちでした。これに対し、DeepSeek Harness は時空間の構成可能性を追求した先進的メタフレームワーク Cordis を採用しており、あらゆる構成要素がプラグインとして設計されています： - モデルアダプタ: DeepSeek V4 Pro、Flash、あるいは vLLM や Ollama でローカル配信されるオープンモデルを柔軟に切り替え可能。 - エージェントループ: 計画立案、内省、反復的なツールディスパッチを司る交換可能な制御ループ。 - ツール＆スキル: AST構文解析、ファイル変更、Bash実行、MCP連携を含む動的な拡張機能群。 - セッション＆ストレージ: ターン間の状態破壊を防止し、厳格な監査証跡を保証する追記専用イベントログ。 Cordis カーネル最大の工学的強みは「可逆的登録（Reversible Registrations）」です。プラグインやツールがアンマウントされると、関連するイベントリスナー、プロンプト定義、ミドルウェアが自動的に完全ロールバックされ、メモリリークやゴーストツールの残留を根本から遮断します。 DSH はこれらの機能を4つの特化型プリセットにパッケージングしています：Standard（汎用コーディング）、PTC (Program-Time Compute)（深い推論と大規模リファクタリング）、Minimal（トークン消費を抑えた自動テスト）、Creator（高速プロトタイピング）。 4. Direct Provider 対 ACP：高速通信ブリッジの優位性 外部エージェントランタイムをオーケストレーターに接続する際、標準の Agent Client Protocol (ACP) が使われるケースが一般的です。しかし実測検証の結果、ACP は帯域幅の狭い隘路となってしまい、ストリーミング思考の表現力喪失や対話型UIカードの欠落といった制限をもたらすことが判明しました。 この制約を打開するため、オープンソースコミュニティの Jecvay 氏によって開発されたのが paseo-dsh-direct です。DSH を Paseo の内部 IPC 通信路に直接ネイティブ Provider として結合します： 1. リアルタイム推論深度（Reasoning Effort）スライダー: DeepSeek V4 の内部思考プロセスを平坦なテキストに潰すことなく、ストリーミング形式で忠実に描画。 2. 対話型 ask_user_question カード: 曖昧な要件が発生した際、Paseo の UI 上に選択式カードや確認モーダルを直接提示し、1クリックで意思決定を完了。 3. Build vs. Plan 実行前ゲートウェイ: 破壊的なシェルコマンドの実行前に、エージェントへ明確な手順計画の提示を義務付け、人間が事前承認。 4. インフライト・ステアリング（In-flight Steer）: エージェントの思考途中であっても、セッションを破棄することなく介入して指示を軌道修正可能。 さらに paseo-dsh-direct はセッションの完全永続化に対応しており、~/.dsh/sessions から過去の実行ログを取り込んで Paseo の Diff ビューア上でデバッグの経緯を即座に再生できます。 5. 実証ベンチマーク：フットプリント測定と開発コスト 90% 削減の実態 Paseo と DSH の実用性を検証するため、実戦的な開発スプリントを想定したストレステストを実施しました：FastAPI マイクロサービスのリファクタリング、Pydantic スキーマの更新、および 4台の並行エージェントによる E2E 統合テストの自動作成です。 +─────────────────────────────────────────────────────────────────────────────────────────────────+ | Table 1: Multi-Agent Concurrency & Isolation Benchmark (4 Concurrent Agents) | +──────────────────────────┬──────────────┬──────────────────┬──────────────┬─────────────────────+ | Concurrency Strategy | Cold Latency | Resident RAM (4x)| Disk Delta | Merge & Git Safety | +──────────────────────────┼──────────────┼──────────────────┼──────────────┼─────────────────────+ | Single Directory (Raw) | Instant (0s) | ~220 MB | 0 MB | ❌ 100% Lock Fail | | Docker / MicroVM (e2b) | 4.2s ~ 7.8s | 7.4 GB ~ 12.0 GB | 4.8 GB | ⚠️ Complex Remote | | Paseo Managed Worktree | < 180 ms | < 340 MB (Shared)| ~120 MB | ✅ Native Clean PR | +──────────────────────────┴──────────────┴──────────────────┴──────────────┴─────────────────────+ 表1 の測定値が示す通り、Paseo の Git Worktree はコンテナ型 MicroVM と比較して起動速度が23倍高速であり、RAM消費量を95%削減しながら、Git インデックスロックを完全に解消しています。 +─────────────────────────────────────────────────────────────────────────────────────────────────+ | Table 2: 3-Agent Parallel Sprint Financial ROI (4.5M Total Tokens) | +──────────────────────────┬───────────────┬────────────────┬───────────────┬─────────────────────+ | Model / Harness Setup | Input Tokens | Output Tokens | Total Cost | Effective Savings | +──────────────────────────┼───────────────┼────────────────┼───────────────┼─────────────────────+ | Claude Opus 5.5 (CLI) | $14.00 (3.5M) | $20.00 (1.0M) | $34.00 | Baseline (0%) | | DeepSeek V4 Pro via DSH | $0.75 (3.5M) | $4.95 (1.0M) | $5.70 | 83.2% Reduction | | DeepSeek V4 Flash Hybrid | $0.35 (3.5M) | $2.10 (1.0M) | $2.45 | 92.8% Reduction | +──────────────────────────┴───────────────┴────────────────┴───────────────┴─────────────────────+ コスト面（表2）においては、Claude Opus 5.5 で 450万トークンのマルチターンコーディングを回すと 34.00 ドルを要します（Claude Sonnet 5.5 では 17.00 ドル、GPT 6.1 SOL などの最先端推論フラッグシップでは 120 ドル以上に急騰します）。一方、プロンプトキャッシュを併用した DeepSeek V4 Pro（DSH経由）では、スプリント全体の総費用はわずか 5.70 ドル（Opus 5.5 比 83.2% のコスト削減） に圧縮されます。さらに、テストコード生成や定型処理に DeepSeek Flash をハイブリッド投入した場合、費用は 2.45 ドル にまで低下し、最大 92.8%（商用フラッグシップ比では 97% 以上）のコスト圧縮を達成します。 6. 実践プロダクションガイド：3エージェント並行スプリントの立ち上げ 自律管理型マルチエージェントスタジオの導入は極めてシンプルです。まず、リポジトリのルートに paseo.json を作成し、隔離環境のフックを設定します： { "worktrees": { "root": "~/.paseo/worktrees" }, "hooks": { "setup": "pnpm install && cp .env.example .env", "teardown": "pnpm test:clean" }, "services": { "dev": { "command": "pnpm dev", "port": 3000, "proxy": true } } } 設定完了後、Paseo CLI から3つの Worktree を瞬時に立ち上げます：paseo workspace create --isolation worktree --mode branch-off --new-branch feat/auth --worktree-slug auth-service --base origin/main。データベース移行とテスト作成用にも同様に実行します。 Paseo デスクトップ UI から、認証エージェントには深い推論を行う PTC プリセットを、DB移行とテスト作成には Standard プリセットを割り当てます。各エージェントが隔離された作業ディレクトリで同時にコードを生成する間、開発者はデスクトップ上で差分を統括レビューするか、外出先から Expo モバイルアプリ経由で PR を承認できます。 7. 自律管理型スタジオの未来と AgDex 連携 Paseo、DeepSeek Harness、そして paseo-dsh-direct の融合は、AI支援開発の主導権が閉鎖的な商用クラウドエディタから開発者自身の手元へ戻りつつあることを証明しています。オープンで自律管理型の編排は、比類なき処理速度、データ主権、そして圧倒的な経済合理性をもたらします： - 完全なデータ主権: ソースコード、Git の履歴、APIシークレットがローカルPCや社内VPCの外部へ漏洩するリスクを完全に遮断。 - 柔軟なモデル選択: エディタ環境を変えることなく、最先端のクラウドAPI（Claude opus 5.5, GPT 6.1 SOL, Gemini 4 Argon）とオフラインのローカルLLMをシームレスに併用。 - SaaS課金の排除: 毎月の高額な座席サブスクリプションに縛られることなく、エージェントの並行数を自由に拡張。 AgDex.ai ディレクトリ では、インタラクティブな 3-Step Stack Finder と連動して本ソフトウェアスタックを網羅しており、Claude Code や DeepSeek などのエンジニアリングツールの検証済みスターターテンプレート、実測テレメトリ、比較ベンチマークを提供して、自律型マルチエージェント群を配備する開発チームを支援しています。 参考情報および検証済みオープンソースリポジトリ 本稿で解説したすべてのツールおよびプラグインはオープンソースとして公開されており、誰でも検証可能です： • Paseo オーケストレーション基盤: getpaseo/paseo（公式サイト: paseo.sh） • DeepSeek Harness (DSH): deepseek-ai/deepseek-harness（npm: @deepseek-ai/dsh） • Direct Provider プラグイン (Jecvay 氏): Jecvay/paseo-dsh-direct • Cordis プラグインカーネル: cordis.moe よくある質問（FAQ） Q1: Paseo の Git Worktree は Docker コンテナと比較して何が優れていますか？ Git Worktree は仮想化を行わず、基底の .git データベースを共有する軽量な物理ディレクトリを作成します。起動時間は180ミリ秒未満、追加のRAM消費はゼロであり、Docker のように数ギガバイトのイメージ容量や複雑なボリュームマウントを必要としません。 Q2: 標準の ACP プロトコルではなく paseo-dsh-direct を使う理由は？ 汎用の ACP プロトコルはモデル固有の高度な制御機能を切り捨ててしまいます。paseo-dsh-direct を利用することで、DeepSeek V4 のリアルタイム推論深度スライダー、選択肢付き質問カード、および実行前計画承認ゲートウェイにネイティブ IPC 経由でアクセスできます。 Q3: 外部クラウド API を使わず、完全オフラインで動作させることは可能ですか？ はい、可能です。Paseo と DeepSeek Harness はどちらも 100% セルフホスト対応です。vLLM や Ollama でローカル配信される量子化版 DeepSeek や Qwen Coder モデルを DSH に接続することで、完全にエアギャップされた無償の開発環境を構築できます。 Q4: 開発デスクから離れている間、どのようにモバイルからレビューや指示を行いますか？ Paseo はローカルデーモンと Expo モバイルアプリ（iOS/Android）を結ぶエンドツーエンド暗号化 WebSocket 中継を備えています。開発者は外出先のモバイル回線から安全にリアルタイムのコード差分を確認し、質問に回答してタスクを承認できます。 --- 元記事：AgDex.ai - Orchestrating DeepSeek Harness (DSH) with Paseo: Inside the 100% Sovereign Multi-Agent Software Studio 最新の AI エージェントアーキテクチャ・ベンチマークデータは agdex.ai でご確認いただけます。

I also opened a feature request for Paseo to add a microphone setting, since this seems like something the app should handle: paseo#8684

Herdr vs T3 Code vs Amp: Software Factory Test Herdr, T3 Code and Amp all promise to help you run lots of coding agents at once, but they aren't the same kind of tool. Herdr and T3 Code are control surfaces for agents you already have: Herdr in your terminal, T3 Code as a desktop, web and mobile app. Amp is a coding agent with its own cloud machines and its own manager agent, Puck. To see how they compare in practice, I built the same minimal software factory with each one: open GitHub issues, let agents turn them into pull requests, and have the merges deploy a website to GitHub Pages. All three got there, on free plans, with my Claude subscription doing the work. Each factory shipped five issues to the live site in under eight minutes with no help from me. None of them noticed new issues on its own. About an hour in, GitHub suspended my account, and I explain why below. Herdr vs T3 Code vs Amp: the quick verdict | | Herdr | T3 Code | Amp | |---|---|---|---| | What it is | Terminal multiplexer for coding agents | Desktop, web and mobile app for coding agents | Coding agent plus cloud machines and a manager agent | | Price | Free, open source (Apache-2.0) | Free, open source (MIT) | Hobby plan is free; Puck and Amp-hosted machines need credits | | Runs agents | In terminal panes on your machine | On your machine | On Amp's cloud machines ("orbs") or your own ("runners") | | Agents it manages | Claude Code, Codex, Amp and 20+ others | Claude Code, Codex, Cursor, OpenCode, Grok, Antigravity, plus the ACP registry | Amp only | | Wave 1: five issues to the live site | 5.3 min | 3.8 min | 7.7 min | | Picked up new issues by itself | No | No | No (only with paid hosted machines) | | Best for | Terminal users who want to see every agent at once | People who want a GUI over the agents they already pay for | People who want agents to keep working after they close the laptop | The speed differences are small and mostly reflect how long each Claude run took. What separates the tools is how you watch and steer the agents, and what each one locks behind a paid plan. What each tool actually is It's easy to assume you'd use T3 Code to manage your Amp agents, until you notice Amp has its own manager, Puck. The tools sit in two layers: agents like Claude Code, Codex and Amp hold the model and do the work, and Herdr and T3 Code sit on top of agents you already have so you can run, watch and steer many at once. Amp is the odd one out, because it brings its own control layer too. - Herdr is a terminal workspace manager for coding agents, written in Rust. It works like tmux, with panes, prefix keys and sessions that survive disconnects, but it also knows which agent is in each pane and whether it's working, blocked or done. That's the difference from plain tmux, which only shows you terminals. Its command-line tool lets one agent create worktrees, start other agents, prompt them and wait for them. - T3 Code, from Theo Browne and Ping.gg, is a desktop, web and mobile app for the agents already installed on your machine, using your existing subscriptions. It isn't a harness itself: it gives each Claude Code or Codex thread its own git worktree and shows its status and pull request. It also installs a t3 command for starting and messaging threads from a script. It calls itself "very very early", and I used version 0.1.5. - Amp is a coding agent. Its threads can run on "orbs", which are Amp's cloud machines billed by the minute, or on your own computer as a "runner". Puck, its manager agent, starts and monitors Amp threads from the web, the apps, Slack or any MCP client. Together they do the job of Herdr and T3 Code, but only for Amp. How I tested The goal was the smallest software factory that's still a factory: issues go in, a live website comes out, and I don't touch the code. - The site. A static site called Cape Trails, about day hikes around Cape Town, in plain HTML, CSS and JavaScript. The starting code had three trail cards, a planted bug (the Kasteelspoort card opened the Pipe Track page) and a typo in the footer. - The repo. Each tool's agent created its own public repository from the same starting folder, turned on GitHub Pages, and confirmed the site was live. A check workflow ran a link checker on every pull request, and every push to main deployed the site. - The rules. The same AGENTS.md in each repo: one branch per issue, open a pull request that says Closes #N, wait for the check, squash-merge, rebase if the merge conflicts. It also said to touch no other repository. - Wave 1. I opened five issues at once: add a Lion's Head trail page, add difficulty filter buttons, add dark mode with a toggle, fix the Kasteelspoort link, and "Homepage feels a bit plain. Can we make the homepage look nicer?" Filters, dark mode and the homepage polish all touch the same CSS, so conflicts were likely. - The dispatcher. In each tool, one agent got the same prompt: list the open issues, start a separate agent per issue in its own git worktree using this tool, run them in parallel, keep them going until every issue is closed by a merged pull request, then check the live site. The only difference between the three prompts was one line naming the tool's command. - Wave 2. After wave 1, I opened two more issues (an About page and the footer typo) and waited ten minutes without saying anything, to see if anything picked them up. Then I told the dispatcher: "Two new issues have been opened. Handle them the same way." - Free plans only. Herdr and T3 Code are free. Amp was on the free Hobby plan with my Claude subscription linked, running in Amp's "Claude Code mode" on my Mac as a runner. Every agent in every tool was Claude Opus 5.5 through the same subscription, so the tools are the only thing that changes. - No approval prompts. Amp and T3 Code ran agents with full access by default. In Herdr I started Claude Code with --dangerously-skip-permissions to match. - Timings come from GitHub: when each issue was opened, when its pull request was opened and merged, and when the Pages deploy containing it finished. I ran the tools one after another, on 30 October 2026, so they weren't competing for the same subscription limits. Amp Code: works free, but Puck doesn't Amp's free Hobby plan lets you link a Claude or ChatGPT subscription and run Amp in "Claude Code mode", with no Amp credits used. I ran amp --no-tui --runner-id ritza-mac in the project folder, and threads started from the Amp CLI or website ran on my Mac. My first plan was to have Puck dispatch the work, since that's what Puck is for, but on the free plan it refused. So Amp's dispatcher was an ordinary Amp thread instead. It created a git worktree per issue, added each one to the runner with amp runner dirs add, and started five threads with amp -m claude-code --executor runner:ritza-mac -x "<prompt>". Each thread appeared in the Amp web app as it started, which made it easy to follow along. | Issue | To PR | To merge | Live | |---|---|---|---| | Kasteelspoort opens the wrong page | 1.6 min | 2.0 min | 2.4 min | | Add a Lion's Head trail | 2.2 min | 2.6 min | 2.9 min | | Filter trails by difficulty | 2.6 min | 3.1 min | 3.5 min | | Homepage feels a bit plain | 2.6 min | 4.4 min | 4.8 min | | Add dark mode | 3.3 min | 7.3 min | 7.7 min | Dark mode was last because by the time it was ready, the filter and Lion's Head changes were already on main, and its pull request conflicted. The agent rebased, resolved the conflict by switching the new filter buttons to the dark mode colours, and added the theme toggle to the new Lion's Head page as well. The dispatcher then checked that the live files matched main, removed the worktrees and runner folders it had created, and noted that it hadn't looked at the site in a browser. <a><img src="techstackups.com" alt="The Amp factory's live site after wave 1, with dark mode, filters, the new Lion's Head card and a gradient header" /></a> Wave 2: nothing happened in the ten minutes after I opened the two new issues. Once I messaged the dispatcher, both were merged within two minutes and live within four and a half. Amp is the only one of the three that can react to new work on its own. Orbs can wake on a schedule, on outside events, and through webhooks a plugin registers, and Amp works Linear issues natively. But the webhook docs describe them for Amp-managed orbs, which on Hobby are pay-as-you-go (from $0.08 an hour). On a free plan with your own machine, Amp waits for you like the others. Herdr: multiple Claude Code agents in one terminal Herdr runs in your terminal, so I opened it in a Terminal window in the project folder. On first launch, it offered to install "agent integrations". For Claude Code, that adds four hooks to your global ~/.claude/settings.json, so Claude Code reports its status to Herdr directly instead of Herdr reading it off the screen. I installed it, and removed it afterwards with herdr integration uninstall claude. <a><img src="techstackups.com" alt="Herdr's first-run integrations screen, listing claude, codex and hermes as available" /></a> The setup agent created the repo and confirmed the live site in 51 seconds. The dispatcher then ran herdr --skill, read the instructions, and used Herdr's own commands rather than plain git: herdr worktree create --cwd "$PWD" --branch issue-1-lions-head-trail --base origin/main --label issue-1 --no-focus herdr agent start issue1 --kind claude --pane w2:p1 -- --model claude-opus-5-5 --dangerously-skip-permissions herdr agent prompt issue1 "Resolve GitHub issue #1 in hashkader47/factory-herdr. Follow AGENTS.md." herdr agent wait issue1 herdr worktree create makes the git worktree and a Herdr workspace for it in one step, so every agent got its own named workspace in the sidebar, with a live working, blocked or done status. Of the three tools, this was the clearest view of what every agent was doing at any moment. <a><img src="techstackups.com" alt="Herdr with five issue agents working, each in its own workspace" /></a> | Issue | To PR | To merge | Live | |---|---|---|---| | Kasteelspoort opens the wrong page | 0.9 min | 1.3 min | 1.8 min | | Homepage feels a bit plain | 1.0 min | 1.4 min | 2.2 min | | Add a Lion's Head trail | 1.4 min | 1.7 min | 2.3 min | | Filter trails by difficulty | 0.9 min | 2.8 min | 4.2 min | | Add dark mode | 1.6 min | 4.5 min | 5.3 min | The dispatcher started all five agents within 30 seconds of being prompted, then waited on herdr agent wait in the background until they were done. No agent got stuck. One Pages deploy was cancelled because a newer merge replaced it, and the dispatcher spotted that and confirmed the later deploy had shipped the change. Wave 2: again, nothing in ten minutes. After the prompt, both issues were closed in under two minutes, but only one by a pull request. The agent working on "Homepage feels a bit plain" in wave 1 had fixed the footer typo in passing, so the wave 2 agent checked main, found the fix, and closed the issue with a comment pointing at the commit. That's tidy, but it's also an agent going beyond "the smallest change that resolves the issue", which is worth knowing if your factory has stricter rules. Herdr left the seven workspaces and worktrees open afterwards and offered to close them. T3 Code: a GUI with a CLI behind it T3 Code picked up my existing Claude Code login straight away. Its web interface on 127.0.0.1:3773 asks for a pairing token, so I used its command-line tool instead, which talks to the running desktop app. Setup took 59 seconds. The dispatcher started each worker with one command, which created the worktree and branch for it: ~/.t3/bin/t3 thread start . "Resolve GitHub issue #1 in hashkader47/factory-t3. Follow AGENTS.md." \ --provider claudeAgent --model claude-opus-5-5 --worktree main --branch issue-1-agent Each thread appeared in the T3 Code app with its worktree, status and pull request number. <a><img src="techstackups.com" alt="T3 Code's sidebar with the Dispatcher working and four issue threads waiting, each with a worktree and PR number" /></a> | Issue | To PR | To merge | Live | |---|---|---|---| | Homepage feels a bit plain | 0.9 min | 1.4 min | 1.8 min | | Add a Lion's Head trail | 0.7 min | 2.4 min | 2.8 min | | Kasteelspoort opens the wrong page | 0.6 min | 2.4 min | 3.1 min | | Filter trails by difficulty | 0.8 min | 3.1 min | 3.6 min | | Add dark mode | 1.1 min | 3.4 min | 3.8 min | T3 Code was the fastest to a pull request every time, and the fastest to finish wave 1, but it also had the most confusing moment. The workers opened their pull requests and then ended their turns. One explained that it couldn't sit and wait for CI in this environment, so it had asked T3 to wake it when the checks finished. The dispatcher saw four threads marked "completed" with open pull requests, decided they had stalled, and sent each one a message with t3 thread send telling it to merge. Most of those messages weren't needed: two workers had already merged by the time the message arrived, and replied to say so. The other two had conflicts by then and rebased. The dark mode agent, finding the filter buttons had arrived first, opened a second, follow-up pull request to give them dark colours, where Amp's agent had fixed the same thing inside one pull request. Wave 2: T3 Code started no threads in the ten minutes after the new issues were opened. Then GitHub suspended my account, so I couldn't finish it. Herdr vs T3 Code vs Amp: results side by side The vague issue, "Homepage feels a bit plain", got three different answers. Amp and T3 Code both added a gradient header banner. Herdr's agent coloured the title and added a rule under the header instead. All three gave the cards a coloured edge by difficulty, which none of the issues asked for. These screenshots are each repo's final main branch, served locally after the suspension took the live sites down. Amp <a><img src="techstackups.com" alt="Amp factory's final site" /></a> Herdr <a><img src="techstackups.com" alt="Herdr factory's final site" /></a> T3 Code <a><img src="techstackups.com" alt="T3 Code factory's final site, with the typo still in the footer" /></a> | | Amp | Herdr | T3 Code | |---|---|---|---| | Setup (repo, Pages, live site) | Not comparable (my GitHub token lacked the workflow scope) | 51 s | 59 s | | Wave 1: all five issues live | 7.7 min | 5.3 min | 3.8 min | | Wave 1: times I had to step in | 0 | 0 | 0 | | Dispatcher interventions | 0 | 0 | 4 messages, mostly unneeded | | Picked up wave 2 issues without a prompt | No | No | No | | Wave 2 after the prompt | Both live in 4.2 min | Both closed in 1.8 min | Interrupted | | Cost | $0 | $0 | $0 | Every agent in every tool used the same model and subscription, and one run per tool isn't enough to rank them on speed. A dark mode rebase in one run and not another is the kind of thing that decides these times. What is consistent is that all three tools could be driven entirely by an agent, from the command line, on a free plan. How my GitHub account got suspended At 13:31 UTC, about an hour after the first repository was created, GitHub suspended my account and the three Pages sites went offline. GitHub hasn't given a reason yet and I've asked support to reinstate it, but the hour's activity looks like a bot: three new public repos, 21 issues, 19 agent-merged pull requests and about 40 Actions runs, all from one personal account. Every agent stayed inside its own test repository and stopped cleanly when requests failed. If you build a factory like this, use a dedicated GitHub account or organisation, not your main one, and ramp up slowly. A suspension also cuts you off from every organisation you belong to. Can you manage Amp with T3 Code or Herdr? Herdr: yes. Amp is one of Herdr's built-in agent kinds (herdr agent start --kind amp), and Herdr ships rules for reading Amp's working, blocked and idle states. T3 Code: sort of. T3 Code doesn't support Amp directly, but it can add agents from the Agent Client Protocol registry, and Amp is listed there as an "ACP wrapper for Amp". It's a community adapter built on Amp's SDK, not something Amp or T3 publishes, and users in T3 Code's issue tracker report that it streams whole blocks of output rather than token by token. I didn't install it, because I couldn't confirm it would use my Claude subscription rather than Amp credits. <a><img src="techstackups.com" alt="T3 Code's provider picker with Amp highlighted in the ACP registry list" /></a> Amp's Puck: only Amp, and only paid. Puck manages Amp threads, not other agents, and on the free plan it doesn't run at all. Which one should you use? - You live in the terminal and want to see every agent's state at a glance: Herdr. It was the clearest view of five agents at once, its command-line interface is the most complete of the three, and it supports Amp out of the box. - You want a polished app over the agents you already pay for: T3 Code. Worktrees and pull requests are built into every thread, it works on your phone, and its t3 command means you can script it too. It's early software, and it showed: agents ending turns while waiting for CI confused its own dispatcher. - You want agents to keep working after you close the laptop, and you'll pay for it: Amp. It's the only one with cloud machines, schedules, webhooks and a manager agent. On the free plan you get none of those, but a good agent that runs on your own Mac with your own subscription, and a web and phone view of every thread. - You want issues to become deployed code with nobody watching: none of them, for free. You'd need Amp's paid orbs and webhooks, or your own trigger, such as a GitHub Action or a scheduled script that starts the dispatcher. For more on the agents themselves, see our coding agent harness comparison, Claude Code vs Amp Code and Replit vs Amp. Frequently asked questions What about Paseo? Paseo is closest to T3 Code and Herdr: a local service that runs Claude Code, Codex, OpenCode and others in git worktrees, with desktop, mobile, web and command-line clients, and built-in skills for agents to hand work to each other. I left it out to keep the test small. Its README doesn't list Amp. Is T3 Code free? Yes. T3 Code is free and open source under the MIT licence, and it uses the subscriptions you already have for Claude Code, Codex and the other agents it supports. You can download it from t3.codes or the GitHub releases page, or install it on a Mac with brew install --cask t3-code. Is Amp Code free? Amp's Hobby plan is free, and you can link a Claude or ChatGPT subscription so that Amp uses it instead of Amp credits. Running threads on your own machine as a runner is free. Puck, Amp's own agent modes and Amp-hosted orbs need credits or a paid plan. Is T3 Code any good? For running several agents you already pay for, yes. In this test it was the quickest to get every issue to a pull request, and each thread showed its worktree, status and pull request in one place. It's also early (version 0.1.5): its workers ended their turns while waiting for CI, which confused the dispatcher watching them, and its web interface needs a pairing token before you can use it in a browser. How do you run multiple Claude Code agents with git worktrees? Give each agent its own git worktree and branch, so they never edit the same checkout. Herdr does this with herdr worktree create, which also opens a workspace for the agent. T3 Code does it with --worktree and --branch on t3 thread start. With Amp, the dispatcher ran git worktree add itself and served each worktree to the runner with amp runner dirs add. In all three, agents that touched the same files still had to rebase when the first one merged. Is Herdr better than tmux for Claude Code? If you run several Claude Code sessions at once, yes. Herdr keeps tmux's panes, prefix keys and persistent sessions, and adds agent status (working, blocked, done), notifications when an agent needs you, and an API that lets one agent start and prompt others. For a single session, tmux is enough. Can Claude Code run multiple agents in parallel by itself? Claude Code has its own subagents, but they run inside one session. To run several independent Claude Code sessions, each in its own worktree and each opening its own pull request, you need something like Herdr, T3 Code or a script around git worktrees. In this test, a single Claude Code dispatcher used each tool's command line to start and watch the others.

Paseo is Apache 2.0 (vs T3 MIT). Haven't tried T3 and can't find docs for it to get more insight without installing. Re: changes: Paseo's plugin system is very, very good. Some limitations since not all of the internals are accessible via plugin system, but allows building very custom UIs. So this may be a point of delta with T3. But I have some coworkers that have gone absolutely HAM with the plugins and built entirely custom workspaces (wild). For me, what I have found most useful about Paseo is the multi-platform, multi-agent setup because this has given my agent teams much, much more autonomy that I feel like I can trust (after weeks of watching them work). The agent profile system looks too simple at first blush, but actually, that simplicity and semi-structured dynamic nature of the sub-agents is what makes it powerful. Might try T3 for a week and see; thanks for sharing! EDIT: T3 has no docs site yet, but sifting through docs, this was interesting: github.com/pingdotgg/t3code/blob/main/docs/user/r… > Each T3 Connect account can link up to 3 machines. Phones and browsers do not count. A paid T3 Chat plan raises the limit to 10 machines with Pro, or 100 with Premier. Paseo has no paid features; only if you want to use the hosted hub gateway (entry point for Slack, Discord, GH). T3 Connect looks to be the equivalent of the Paseo Relay: paseo.sh which has no limits (Herdr's ipml is better, though; Paseo currently cannot manage individual connections which would make it SICK for team collab. See: paseo#6896)

@yetone getpaseo/paseo 怎么样？

The agentic development environment, in 30 seconds. Parallel worktrees, diff review, agent handoffs, and a mobile app that actually does everything the desktop does. Self-hosted. Open source. No telemetry. Star it: getpaseo/paseo Get it: paseo.sh

I built an ADHD-friendly ⌘Tab-style switcher for my coding agent sessions in Paseo reddit.com I usually have a dozen agent sessions going across different projects. I reply to one, jump to another, and a minute later I've lost track of the one I was just in. Your brain can hold about 4 things at once, and ADHD makes that even tighter. So I built a ⌘Tab-style session switcher on my fork. I shared it in the existing GitHub discussion and asked about opening up the plugin API to support it, or bringing something like this into core: paseo#4996 If you'd like this in Paseo, a 👍 on the GitHub discussion helps! 😎 And I'm curious: how do you keep track of parallel agent sessions?

Paseo is open source (getpaseo/paseo, Apache 2.0) and not my project; not affiliated. I have other products and I work for private equity (no affiliation with Paseo at all). You've entirely missed the lede.

You can just move the worktree to a fresh branch yourself (or have the agent do it), but Paseo in its current version unfortunately is also a little wonky with picking this up, like it's just not expecting someone to do this.