コーディングエージェントの可用性は、それが動作するマシンの可用性と同じです。Claude Code や Codex で大規模なリファクタリングを開始し、電車に乗るためにノートPCの蓋を閉じれば、実行は SSH セッションとともに途絶えてしまいます。同じノートPCで2つのエージェントを同時に走らせれば、ファンが唸りを上げ、エディタはカクつきます。いつしか問いは「どのエージェントを使うか」から、「エージェントは実際どこで動かすのか」へと変わります。
答えはたいてい3つのうちのどれかです。ノートPC上に置く、リモートサーバーへ移す、あるいは両方に作業を分散させる。どの選択も、利便性と信頼性を天秤にかけることになります。ノートPCはすぐ手元にある代わりに、スリープし、スロットリングし、切断されます。サーバーは眠らずコアも多い代わりに、セットアップが増え、「今いったい何をしているのか」という層が加わります。折衷案を選べば、両方の良いところと、両方の管理の手間を同時に手に入れることになります。
この記事では、リモートエージェントのセットアップを端から端まで見ていきます。実際のコマンドを使った自作の道のり、各ステップに待ち受ける失敗モード、そして Sharkly の接続された Computer が、壊れ続ける部分をどこで取り除くのか。あなたはすでにコーディングエージェントを持っています。問題は、それを持続可能な場所で動かし、目を離していた間に何が起きたかを把握することにあります。
エージェントをノートPCから移す理由
ノートPCが既定の選択になるのは、そこがタイピングする場所だからです。同時に、集中力が続く時間より長く動くものにとっては、最悪のホストでもあります。macOS は蓋を閉じるとスリープします。バッテリーモードは CPU をスロットリングします。社内 VPN は切れます。こうした出来事はどれも、エージェントをタスクの途中で殺してしまい、エージェント自身は中断されたことに気づきません。気づくのは、ターミナルを開き直して、死んだプロンプトと要約のなさを目にしたときです。
リモートホストはこの物理的な制約を解決します。クラウド VM や余っている Linux マシンなら、電源が入ったまま、ネットワークも維持し、並列作業のためのコアにも余裕があります。その代償は、エージェントが今や見えない場所で動いていることです。様子を見るために SSH で入り、どこまで進んだかを推測するためにログをスクロールし、結果はコピーして持ち出すまでそのマシン上に留まります。
両方を動かすのが、ほとんどの人にとって正直なところの最終形です。フィードバックが即座に返る素早い対話的な編集はノートPCに残し、長時間または並列のジョブは、1時間放っておいても走り続けられるサーバーへ送ります。コツは、1台でも5台でも、IP アドレスの表計算ではなく「1つの場所」のように感じられるようにすることです。
自作のリモートセットアップと、各ステップが壊れるポイント
手動の道のりはよく知られています。ここでは要点を、各ステップで現れる失敗モードとともに紹介します。
ホストを用意し、エージェントをそこへ導入します。
ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude
失敗モード: エージェントは、他の人が触るかもしれないマシン上であなたのアカウントに対して認証し、認証情報はそのシェルの履歴と設定に残ります。どのホストがどの鍵を保持しているかの記録はありません。
SSH セッションを越えて実行を生かし続けます。
tmux new -s agent
claude # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent
失敗モード: tmux は SSH 接続の切断には耐えますが、サーバーの再起動、OOM による kill、あるいは3台のサーバーにある6つのセッションのうちどれが目的の実行を保持しているかを忘れることには耐えられません。デタッチは、持続性とは別物です。
結果を取り戻し、何が起きたかを確認します。
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
失敗モード: diff はマシン上にあり、推論はすでに切り詰められたスクロールバッファの中にあり、「なぜ」は消えています。これを2つのホスト上の2つのエージェントに掛け算すれば、確認のたびに手作業で状態を再構築することになります。
これらのステップはどれも難しくありません。問題は、それらが組み合わさらないことです。新しいホスト、新しいエージェントのたびに、SSH の接続先が1つ増え、tmux セッションが1つ増え、秘密情報の置き場所が1つ増え、「終わったのか」に答えるために読まなければならないログが1つ増えます。
接続された Computer が変えるもの
Sharkly は、あなたがこれまで即興でやってきたものに名前を与えます。Computer とは、Agent が作業を実行できる、接続されたデバイス、サーバー、またはコンテナのことです。Agent が必要とするオペレーティングシステム、ファイル、認証情報、ネットワークアクセス、ツールを提供します。この定義は3つの選択肢すべてをカバーします。「ローカルコンピュータ、リモートサーバー、コンテナ、あるいはサポート対象のクラウドホストのいずれかになります。」
毎回 SSH で入る代わりに、ホストは一度だけ登録します。対象マシンで、Settings の Computers からワンタイムのインストールトークンを生成し、次を実行します。
sharkly computer register --install-token <install-token>
トークンは有効期限が短く、一度きりなので、イメージやスクリプトに含めるべきものではありません。その後、バックグラウンドのローカルサービスが Computer 上で動作します。このサービスはホストを登録し、インストールされているエージェントツールを検出してそれぞれを Runtime として報告し、ハートビートを送信し、キューに入った実行を受け取り、ディレクトリを準備し、進捗と結果を報告します。
2つの境界線ははっきり述べておく価値があります。ここで人は誤解しがちだからです。第一に、ローカルサービスがサーバーへの接続を開始するため、一般的なセットアップではインバウンドポートは不要です。ビルドマシンをインターネットに開放するわけではありません。第二に、Computer が Online と表示されるのは、そのローカルサービスがハートビートを送信しているという意味にすぎません。Runtime が Task を実行できるという意味ではありません。オンラインのホストで実行が始まらない場合は、ネットワークに手を付ける前に Runtime の機能ステータスを確認してください。
ここから先は、先ほどの失敗モードにそれぞれ対処先があります。認証情報はホストのものであり、そのホストにスコープされます。実行は、tmux セッションではなくローカルサービスが所有するため、あなたのターミナルより長く生き続けます。そして diff、要約、推論は、SSH で入らなければならないマシン上のスクロールバッファに留まるのではなく、Task に返ってきます。
ノートPC、サーバー、それとも両方：実際の選び方
ホストが多いほど自動的に良いわけではないので、作業内容で選びましょう。
ノートPCを使うのは、タスクが短く、対話的で、眺めていたい場合です。パーソナルな Computer として登録し、Sharkly Desktop で Prevent sleep をオンにすれば、手早いジョブがシステムスリープで打ち切られません。Prevent sleep はデスクトップアプリのローカルマシンにのみ表示され、共有またはリモートの Computer では利用できない点に注意してください。実行するものがすべてコーヒーブレイクの間に終わり、蓋を閉じても生き延びる必要がないなら、まだサーバーは必要ありません。追加しても、疎ましく思うだけのメンテナンスが増えるだけです。
リモートサーバーを使うのは、タスクが長時間にわたる、より多くのコアを必要とする、あるいはエディタとリソースを奪い合うべきでない場合です。登録済みの Linux ホストやクラウド VM は既定で起きたままで、並列エージェントに働く余地を与えます。ここで Computer のホストごとのタスク同時実行数の上限と、Organization または Space の可視性が役に立ちます。マシンとその認証情報は共有されることを前提としており、Sharkly もそのように扱います。
両方を使うのは、対話的な編集はローカル、重い実行はリモートに、2つのメンタルモデルを維持せずに実現したい場合です。ノートPCとサーバーを登録し、それぞれの Task を合った Computer と Runtime に割り当てます。エージェントが1つのホストを共有していても複数にまたがっていても、並列エージェントの衝突を防ぐworktree 分離は同じように機能するので、「両方」でかかるコストは選択の手間だけで、2つ目のワークフローではありません。
自作がスケールしなくなる場所と、タスクボードが加えるもの
SSH と tmux のセットアップは、1つのホスト上の1つのエージェントなら通用します。複数のマシン上で複数のエージェントを動かした瞬間に破綻します。「どのエージェントが何をしていて、何が終わり、何が失敗し、何が自分のレビューを必要としているのか」に対する共通の答えがないからです。この問いこそが複数のエージェントを同時に動かす理由そのものであり、まさにターミナルの山では答えられないことです。
タスクボードは、単位を「ホスト上のセッション」から「記録を持つ Task」へと変えます。エージェントは調査し、実行し、テストし、報告します。人は方向性を示し、権限を与え、結果を受け入れます。実行、ブロッカー、結果、そしてフォローアップの議論は Task のタイムラインに戻ってくるので、リモートの実行を確認することは、当て推量で SSH することではなく、Task を開くことになります。自動化はチームの判断が必要とされるところで止まります。エージェントは要約と根拠とともに変更を手渡し、マージとリリースの判断はあなたのものです。
これが2つのアプローチの分かれ目です。自作はエージェントをリモートで動かします。タスクボードは、どのホストが作業を行ったかに関係なく、コンテキスト、進捗、ブロッカー、結果、人によるレビューを、依頼からリリースまで見える状態に保ちます。
今日から実行できるチェックリスト
使う予定のホストで、このリストを上から順にこなしていきましょう。
- [ ] ホストを正直に選ぶ：対話的ならノートPC、長時間または並列ならサーバー、本当に必要なら両方。
- [ ] 各ホストにサポート対象のエージェント Runtime をインストールし、自分のサブスクリプションまたは API キーで認証する。
- [ ] 実行のたびに SSH する代わりに、
sharkly computer register --install-token <token>で各ホストを一度だけ登録する。 - [ ] 各 Computer が Online と表示され、かつ少なくとも1つの Runtime が Available を報告していることを確認する。オンラインだけでは Task は実行されない。
- [ ] Computer の可視性を、ノートPCは Personal、共有サーバーは Organization または Space に設定する。
- [ ] ノートPCでは、蓋を閉じても生き延びる必要がある実行のために Prevent sleep をオンにする。
- [ ] 小さくて退屈な Task を1つリモートホストに割り当て、結果がスクロールバッファではなく Task に返ってくることを確認する。
- [ ]
sharkly computer listとsharkly daemon disk-usageを使って、ホストを把握し、スペースを再利用する。
リモートセットアップは SSH、tmux、worktree で手作業で構築することもできますし、既存のホストを Computer として登録し、実行をローカルサービスに任せることもできます。すでに複数のマシンで複数のコーディングエージェントを動かしているなら、Sharkly がそれらのタスクと結果を管理する1つの場所を提供します。まずは Computer を1つ接続し、Agent を1つ作成して、退屈なタスクを割り当ててみてください。
