席を外したあとでも、ローカルで動いている Claude Code / Codex / OpenCode のセッションを見たい——その需要は、クラウド sandbox にコードを預ける案だけでは解けないことがあります。
📑目次
次のような現場では、「どこで agent が走るか」が採用境界になります。
- NDA
- 実機依存の再現
- すでに組んだ MCP やサブスクをそのまま使いたい
Paseo（GitHub: getpaseo/paseo、paseo.sh）は、既存の CLI 型コーディングエージェント（Claude Code / Codex / OpenCode など）を自前ホスト上のプロセスとして起動し、Desktop / Mobile / Web / CLI の同じ UI から監督する自ホスト・オーケストレータです。
調査時点のスナップショット
人気指標は調査窓の as-of 値として扱い、約 12.1k★（2026-08-05 時点の GitHub 表示） を基準にします。
調査時点のスナップショットは次のとおりです。
- ライセンス: AGPL-3.0
- Latest: v0.2.5（2026-07-30 前後）
- GitHub 表示: 約 12.1k★ / 1.2k forks（2026-08-05）
この記事で扱う範囲
本記事では、アーキテクチャと導入ルート、E2E リレーとセキュリティ境界、並列 worktree とスキル、クラウド型・他メタハーネスとの役割分担、導入前チェックリストを整理します。
読後の次アクションは、常時起動ホストの可否を決め、Desktop か headless CLI で daemon を立て、必要なら relay pair でモバイル監督を1セッション試すかどうかの判断です。
Paseoとは何か — 自ホスト daemon と多端末監督
結論と設計方針
Paseo の中核は、ホスト上の daemon が agent プロセスを管理し、client（desktop / mobile / web / CLI）がそこに接続する構成です。公式サイトのタグラインも、desk と phone から coding agent をオーケストレーションする self-hosted / multi-provider / open source という位置づけです。
設計上の要点
設計上の要点は次のとおりです。
- エージェントは各プロバイダの自前クレデンシャルで動く
- コードをクラウド sandbox に預けない（ローカル実行が前提）
- サブスク・skills・config・MCP などネイティブ harnessを CLI 側のまま再利用する
- テレメトリなし・強制ログインなしを README が明記
- monorepo は server（daemon）、Expo アプリ、CLI、Electron desktop、relay、website などで構成
「新しいエージェント runtime を配る」のではなく、すでに使っている Claude Code / Codex などを監督面に載せる層だと捉えると分かりやすいです。
規模感と一次情報
| 項目 | 内容（調査時点） |
|---|---|
| リポジトリ | getpaseo/paseo |
| 公式サイト | paseo.sh |
| ライセンス | AGPL-3.0 |
| Latest | v0.2.5（2026-07-30 前後） |
| 人気指標 | 約 12.1k★ / 1.2k forks（2026-08-05 調査） |
| 既定 listen | 127.0.0.1:6767 |
| 接続 | E2E Encrypted Relay または Direct（LAN / Tailscale / VPN 等） |
出典: GitHub README、paseo.sh、Security docs（2026年8月時点）
対応エージェントと v0.2.5 の導入ルート
前提と対応範囲
導入の前提は、ホストに Claude Code / Codex / GitHub Copilot / OpenCode / Pi のいずれかが入り、各プロバイダ認証が済んでいることです（README）。
表記の揺れには注意が必要です。公式 FAQ は Cursor を列挙し、README は Copilot を含みます。第三者の Qiita 検証では Cursor を ACP（cursor-agent acp）経由と説明する例もあります。安全な読み方は、「少なくとも Claude Code / Codex / OpenCode / Pi を含む複数 CLI」とし、第5枠は実機確認です。
導入ルート（最短から headless まで）
- Desktop（最速）: paseo.sh/download または GitHub Releases。macOS dmg / Homebrew
brew install --cask paseo、Windows exe、Linux AppImage / DEB / RPM。起動で daemon が自動開始しやすい。 - Mobile: Google Play（
sh.paseo）、APK、iOS App Store「Paseo – Pocket Engineer」（id6758887924）。 - Web: app.paseo.sh
- Headless CLI:
npm install -g @getpaseo/cliのあとpaseo。nix run github:getpaseo/paseoも案内あり。 - Docker 例:
ghcr.io/getpaseo/paseo:latestを 6767 で公開し、PASEO_PASSWORDと volume を指定。
リリース資産と導入後確認
v0.2.5 では Linux Debian パッケージ修正（#2654）などが入り、dmg / exe / deb / rpm / AppImage / APK など資産が Releases に揃います。GIGAZINE は Windows Desktop のインストーラ手順と、プロジェクト追加→ワークスペース→エージェント選択→チャット指示の流れを画面付きで紹介しています。
導入後の確認コマンド例:
paseo status
paseo daemon pair
paseo run --provider claude-code
paseo ls
paseo attach <session>
（プロバイダ名やサブコマンドはバージョンで差が出るため、公式 CLI ドキュメントと paseo --help を優先してください。）
外出先接続 — E2E リレーとセキュリティ境界
接続方式の選び方
外出先から監督する経路は大きく2つです。
- E2E Encrypted Relay（推奨されやすい）: daemon が outbound でリレーへ接続。公式リレーは getpaseo/paseo-relay（Elixir）。新規 install では relay offで、ペアリング時に有効化を確認する流れ。
- Direct: 同一 LAN、Tailscale / VPN、ポート公開など。手元ネットワークが整っている場合に有効。
暗号は ECDH（Curve25519）+ XSalsa20-Poly1305（NaCl box）。リレーが見るのは IP / タイミング / サイズ / session ID 程度で、平文のコード本文を中継しない設計です（Security docs）。
認証・bind・実務の落とし穴
既定 listen は 127.0.0.1:6767 です。0.0.0.0 への bind は警告対象で、DNS rebinding 対策として host allowlist（daemon.hostnames）があります。パスワードは bcrypt。Bearer / WebSocket subprotocol で保護し、/api/health のみ認証免除という整理です。
実務で押さえる境界
重要な境界は次です。
- Paseo は API キーを保存・送信しない（provider 認証は各 CLI 側）
- コードはローカル実行前提でも、agent は通常どおり各プロバイダ API と通信する
- モバイルは relay、QR はパスワード相当、ネットワーク bind 時は password、Docker は mount 範囲を最小化——が推奨運用
pairing の失敗パターン
Qiita の実務検証では、Android ネイティブで offer URL が途中切れし Connection timed out になりやすいこと、Web 版フォールバックや URL 全文貼り付けが有効、といった pairing 失敗パターンが共有されています。初回は paseo status で Daemon / Relay を確認し、1 セッションだけ phone から attach / send できるかを見るのが安全です。
並列セッション・worktree・同梱スキル
CLI と並列ブランチ
単一セッションの監督だけでなく、並列作業が必要なら worktree が中心機能になります。公式 CLI ドキュメントでは、paseo run / ls / attach / send / logs / stop / wait に加え、--new-workspace worktree や --worktree-mode branch-off、--new-branch / --base といった分岐実行が案内されています。
実務フローのイメージは次です。
- ブランチ（または worktree）を切る
- プレビュー URL で確認（ブランチ名ベース URL でポート競合を避ける、という第三者整理あり）
- 差分を inline review
- commit / PR / merge
GIGAZINE や Zenn の検討記事でも、分割・タブ UI、ブランチ名ベースの並列開発サーバ、paseo run / ls / attach / send のスクリプト可能性が取り上げられています。
スキルと任意 Hub
同梱スキルは npx skills add getpaseo/paseo のあと、/paseo-handoff、/paseo-loop、/paseo-advisor、/paseo-committee などが使えます。エージェント間の引き継ぎやループ、合議的なレビューを、監督 UI の上に載せる用途です。
任意の Hub では GitHub / Slack / Discord トリガとチームアクセスが案内されます。ボイスはローカル STT/TTS が既定で、OpenAI speech は任意です。最初から全部を有効にせず、単一セッション監督 → 必要なら worktree → さらに skills の順が負荷が低いです。
クラウド sandbox 型・他メタハーネスとの役割分担
比較の軸
比較で見るべきは機能一覧の長さより、次の4点です。
- agent がどこで走るか
- UI の主目的
- 既存 CLI 資産の再利用
- 外出先到達手段
比較表
| 観点 | Paseo | クラウド sandbox 型（例: Cosyra 対比） | チーム harness / スウォーム系 |
|---|---|---|---|
| 実行場所 | 自マシン / 自前 VM・dev server の daemon | 事業者クラウド上の隔離環境 | 製品により分散・制御プレーン中心 |
| コードの置き場 | ローカル実行が前提（agent は各 API と通信） | クラウド側に作業領域 | 設計次第 |
| UI 主目的 | 多端末からの監督・オーケストレーション | ブラウザ完結の実行環境 | チーム協調・多数 agent 制御 |
| 既存 CLI 資産 | サブスク・skills・MCP・設定をネイティブ再利用 | 多くは環境を新規に組む | 独自 runtime のことが多い |
| 遠隔到達 | E2EE relay / LAN / 自前トンネル | サービス到達が前提 | 製品依存 |
| 向きやすい用途 | NDA・実機依存・常時自ホスト可能な個人/小チーム | セットアップ最小化・共有隔離環境 | 大規模並列・組織ワークフロー |
出典と第三者比較画面
出典:
（2026年7–8月時点）
読者向けの差分
Cosyra の独立比較は、Paseo を free/OSS・コードがマシン外に出にくい・既存 CLI 認証再利用が強みとしつつ、daemon ホスト常時 awake と CLI 事前インストール必須を制約として明示しています。note の KeiTy 記事は 2026 年のメタハーネス俯瞰で、多ハーネスをスマホから監督する用途の候補として Paseo を位置づけています。
QM のようなチーム harness や Puppetmaster のようなスウォーム制御と並べるなら、Paseo の主軸は リモート監督 UI + 自ホスト daemon です。大規模協調の制御プレーンを求めるなら別レイヤを検討し、既存 CLI を捨てずに外出先から見たいなら Paseo 側が近い、という切り分けが実務的です。
導入前チェックリストと向き不向きの判断
判断手順（チェックリスト）
読者がそのまま使える判断手順です。
- ホスト常時起動: ノート PC スリープで daemon が落ちないか。落ちるなら自宅サーバ / VM / 常時起動マシンへ移すか決める。
- CLI 前提の充足: 使いたい provider（Claude Code / Codex 等）がホストに入り、ログイン済みか。
- 導入ルート選択: Desktop（最速） /
brew install --cask paseo/@getpaseo/cliheadless / Docker。 - 到達経路: 同一 LAN 直結で足りるか。外出先なら relay を pair 時に有効化するか、Tailscale 等の自前トンネルか。
- セキュリティ設定: 既定 127.0.0.1 のままか。bind を広げるなら password + host allowlist。Docker volume のマウント範囲を最小化。
- モバイル監督の検証:
paseo statusで Daemon/Relay を確認 → pair → 1 セッションを phone から attach/send。Android は offer URL 全文貼り付けを優先。 - 並列が必要か: 単一セッション監督だけなら skills/worktree は後回し。並列が必要なら worktree と branch URL を試す。
- 不向きサイン: ホストを常時用意できない / クラウド隔離が必須 / AGPL の配布義務が組織ポリシーと衝突 / provider 利用規約上のリモート操作が不明確。
向き・不向き
向き
- 既存 Claude Code / Codex / OpenCode を捨てずに外出先から見たい
- コードを自ホストに残したい
- 複数 CLI を一つの監督面にまとめたい
不向き
- ホスト運用コストをゼロにしたい
- 完全マネージド隔離が必須
- AGPL が配布・社内ポリシーと合わない
関連ガイド
Paseo に載せる前に、ローカル harness 側を先に固めたい場合の関連記事です。
- ループ設計・停止条件: Claude Codeの4種ループ設計 — 停止条件・/goal・トークン管理の実務ガイド
- hooks / skills / MCP: Claude Code Setup 公式プラグイン — リポジトリ解析で hooks / skills / MCP / subagents を提案
関連記事:
- wmux — Claude Code / Codex / Gemini を1ウィンドウで並列運用するワークスペース多重化（MIT）
- Better Harness（QoderAI）— Claude Code / Codex / Cursor の Loop を採点・改善する OSS（MIT）
- Claude CodeとCodexの設定同期｜CLAUDE.mdとAGENTS.mdのズレを防ぐ
よくある質問（FAQ）
Q1. Paseo は無料か？
公式 FAQ は無料の OSS（AGPL-3.0）と説明しています。各エージェントの API / サブスク費用は別です。
Q2. コードは外部に送られるか？
設計上、コードはローカル実行が前提です。ただし agent は通常どおり各プロバイダ API と通信します。リレーは暗号ペイロードを中継し、平文のリポジトリ全文を預けるモデルではありません（Security docs）。
Q3. Claude Code 以外も使えるか？
少なくとも Codex / OpenCode / Pi 等が対象です。Copilot や Cursor（ACP）はドキュメントと第三者検証で言及されます。公式の第5枠表記は README と FAQ で揺れるため、導入時に実機確認が必要です。
Q4. スマホだけで完結するか？
いいえ。ホスト上に daemon と agent CLI が必要です。スマホは監督クライアントです。
Q5. リレーは必須か？
同一ネットワーク直結や Tailscale 等でも可能です。新規 install は relay off が基本で、外出先の手軽さでは公式 E2E relay が有力です。
Q6. API キーは Paseo に渡すのか？
公式 security の整理では、provider 認証は各 CLI 側です。Paseo は API キーを保存・送信しません。
Q7. Windows でも使えるか？
download に Windows インストーラがあります。GIGAZINE が Windows Desktop 手順を画面付きで紹介しています。
まとめ — 次に確認すること
価値の中心
Paseo は「クラウドに預ける代替」ではなく、手元（または自前サーバ）で動く CLI agent を多端末から監督する層です。価値の中心は、既存 harness の再利用、モバイル / Web 監督、任意の E2E relay、worktree / skills です。
採用判断の4点
採用判断は機能一覧より、次の4点で行うと迷いにくいです。
- 常時ホストを用意できるか
- セキュリティ境界（bind / password / relay / mount）を運用できるか
- AGPL が組織ポリシーと合うか
- 実ペアリングで 1 セッション監督できるか
次の一手
- 対象 provider をホストに入れる
- Desktop または CLI で daemon を起動する
- 必要なら relay pair する
- 1 本の実タスクで attach / send を確認する
- 問題なければ worktree と skills を拡張する
一次情報と補助ソース
一次情報（優先）:
比較の補助として、Cosyra・GIGAZINE・Qiita・Zenn・note などの第三者検証を参照するとよいです。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す