コーディングエージェントに実際のタスクを任せ、ノートPCを閉じてランチに出かける。そこまでは簡単だ。難しいのは戻ってきたときに目にするものだ。上へ流れて消えてしまったターミナル、書き上がるのを見ていなかったdiff、そして唯一重要な問い――この作業は残す価値があるのか――に対する明確な答えがないことだ。
エージェントの無人運用には2つの半分があり、ほとんどのセットアップは最初の半分しか解決していない。前半は、誰も見ていない間にプロセスを生かし、生産的に動かし続けること。後半はレビューキューだ。つまり、戻ってきたときに人間の判断を待っている、完了済み・中途半端・失敗の実行の山である。後半を飛ばすと、無人エージェントはボトルネックをコードを書くことから「何が起きたかを再構築すること」へ移すだけになる。
本記事ではその両方を扱う。自分で無人実行をセットアップする方法、各ステップに潜む失敗パターン、そしてその自作セットアップがスケールしなくなる地点だ。ターミナルが1つから5つになると、Sharklyのようなタスクボードがコーディングエージェントの上位に位置する。Claude Code、Codex、Gemini CLIに作業を任せたまま、Sharklyがタスク・実行・レビューを、すでに閉じてしまったターミナルに散らばった状態ではなく1か所にまとめてくれる。
エージェントの無人実行で実際に必要なこと
無人実行とは、自分が能動的に見ていないホスト上でコーディングエージェントがタスクを実行し、その出力が後からレビューできるように記録されている状態を指す。この定義には欠かせない要素が3つある。自分がいなくてもエージェントが完了できるタスク、自分が切断しても動き続けるホスト、そして後から読める記録だ。
記録こそ、多くの人が軽視する部分だ。エージェントをリアルタイムで見ているとき、ログの役割を担っているのは自分自身である。間違ったファイルを選ぶのを見て、割り込み、軌道を修正する。無人になると、そのどれも起こらない。エージェントがやったことのすべては、何時間も後、自分が何を依頼したかも覚えていない状態で、まっさらな目で確認できる形で残っていなければならない。エージェントは調査し、実行し、テストし、報告する。人間は方向性を示し、権限を与え、結果を受け入れる。この分担が成り立つのは、戻ってきたときに報告が本物で完全である場合だけだ。
つまり目標は「エージェントを自分の代わりに動かすこと」ではない。「自分の代わりに動かし、レビューできるものを返してもらうこと」だ。これは別の問題であり、無人ワークフローがたいてい破綻するのは後者のほうだ。
自分で無人実行をセットアップする
以下が最小限の手動セットアップだ。各ステップで刺さる失敗パターンも併記する。
ステップ1: 作業を隔離する。実行ごとに専用のチェックアウトを用意し、エディタや他のエージェントと衝突しないようにする。
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
失敗パターン: これを省くと、同じディレクトリで走る2つの実行が互いの未コミットの変更を上書きしてしまう。ブランチだけではなくワークツリーがなぜ隔離の境界になるのかは、タスクごとに1つのチェックアウトを参照してほしい。
ステップ2: プロセスをデタッチする。SSHセッションやターミナルはやがて閉じられ、フォアグラウンドのプロセスはそれと一緒に終了する（SIGHUP）。nohupやtmuxセッションで動かし続けよう。
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
失敗パターン: 普通のフォアグラウンドシェルで走らせると、ノートPCを閉じた瞬間に複数ファイルにまたがる編集の途中でエージェントが落ち、壊れたツリーが残る。nohupはプロセスの寿命を確保できるが、後から中に入る手段はない。tmuxなら再アタッチして何が起きているかを確認できる。
ステップ3: すべてを記録する。上の> run.log 2>&1は省略できない。これが最も原始的な形のレビューキューだ。
失敗パターン: ログを残していなければ、「なぜ止まったのか」に答えられない。最もよくある静かな停止は、誰も答えない対話型プロンプトの前でエージェントが永遠に待ち続けるケースだ。無人とは、誰も「yes」と入力しないということだからである。非対話モードで実行し、そのタスクに必要な最小限の操作だけを事前承認しておこう。
ステップ4: 影響範囲を限定する。離席する前に、エージェントが単独でやってよいこと、人間の手が必要なことを決めておく。ファイルの範囲を制限し、force-pushを禁止し、無人実行が保護ブランチにマージすることは絶対にさせない。
失敗パターン: 権限を与えすぎた実行がmainに直接プッシュするのは、生産性の向上ではなくインシデントだ。承認ゲートは、エージェントが最後の安全な地点で止まって待つために存在する。
ステップ5: いつ、どう終わったかを知る。終了コードを確認し、自分の手でログをポーリングしなくて済むよう通知を受け取ろう。
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
失敗パターン: 完了通知がなければ、「無人」は「20分ごとにターミナルを確認する」に変わる。それはレイテンシが増えただけの有人運用にすぎない。
自作セットアップが通用しなくなる瞬間
1エージェント、1ワークツリー、1ログファイル。これでうまくいくし、1回の実行ならこれ以上重いものは要らない。このセットアップが破綻するのは、実行が2つ以上になった瞬間だ。
3つのタスクで3つのエージェントを走らせれば、ワークツリーが3つ、ログファイルが3つ、終了コードが3つ、そして一瞥しただけでは読み間違える完了メールが3通になる。隔離は依然として機能している。崩れるのはレビューキューだ。どの実行がきれいに完了し、どれがテストで失敗し、どれがひっそりプロンプトで待っているのか、教えてくれるものは何もない。それを手作業で、ログを1つずつ読んで再構築することになる。まさに外に出そうとしていた仕事そのものだ。
これが本当のコストであり、一つひとつは単体では問題なく見えるので見落としやすい。複数の並列実行のモニタリングは、数が1画面に収まる量を超えた時点で、本当に厄介な問題になる。ログファイルが答えてくれるのは「この実行が何を出力したか」であって、「6つの実行のうち、いま自分を必要としているのはどれか」ではない。記録する価値のあるステータスと失敗シグナルは、勝手にキューへと整理されてくれるわけでもない。そして、離席中に働いてもらう目的はまさにこのキューにある。欲しいのは生の出力が並んだディレクトリではなく、優先順位づけされた判断のリストだ。
タスクボードが変えるもの
タスクボードは、問題の後半部分が解決される場所だ。無人実行自体は、自分が接続したComputer上で、既存のRuntimeがコードを書く形で行われることに変わりはない。変わるのは、結果がどこに着地するかだ。
Sharklyでは、作業・実行・レビューが1つのTask上に存在する。TaskはAgentに割り当てる。Agentは指示・Runtime・リポジトリを保存した設定であり、毎回打ち直す単発のプロンプトではない。AgentがTaskを引き受け、隔離されたワークツリーで実行し、その実行状況・ブロッカー・結果がTaskのタイムラインに返ってくる。戻ってきたら、6つのログファイルをgrepする必要はない。ボードを開いてキューを読むだけだ。何が完了し、何が失敗し、何が自分の判断を待っているのか。
ここははっきり言っておくべき境界線だ。SharklyはClaude Code、Codex、その他の実行ツールの代替ではない。チームがすでに使っているツールの周囲に、共有のタスク、Computer、コンテキスト、レビューのレイヤーを追加するものだ。コードを書くのは、これまでどおりエージェントである。Sharklyが保証するのは、自分が離席している間に書かれたコードが、変更サマリーとテスト結果を添えて確認できる場所に戻ってくること、そして最終的な受け入れ判断は人間が行うことだ。自動化は、判断が必要な地点で止まる。
これらはすべて、ワークツリーとnohup、そしてmailコマンドで手作業でも構築できる。正直な判断基準を挙げよう。たまに1つのエージェントを動かすだけなら、手動セットアップで十分だし、Sharklyは不要なオーバーヘッドだ。状況が変わるのは、複数のエージェントが複数のタスクとリポジトリにまたがって動き、朝の時間をレビューキューに費やすようになったときだ。1つのエコシステムにコミットするのではなく、複数のコーディングエージェントを使い続けたいなら、そのキューこそSharklyが解決の中心に据えている問題だ。
本当のボトルネックはレビューキューだ
疑ってかかるべき前提が一つある。人は無人実行の最適化に注力し、レビューは後回しの作業として扱う。これは逆だ。寝ている間にエージェントを並列で走らせることが成果になるのは、翌朝その出力をレビューするほうが、自分で作業するよりも速い場合だけだ。5つのエージェントが一晩で完了し、その5つの差分すべてをレビューするのに、2つを自分で書くより時間がかかるなら、並列化は何も生み出していない。
だから、まずレビューキューを設計しよう。実行が自分のところに届く前に、「完了」に何が含まれていなければならないかを決める。テストの通過、型チェック、変更サマリー、既知の制限の記載だ。キューは完了時刻ではなくリスク順に並べよう。そうすれば、タイポを直した実行より、認証まわりに触れた実行のほうが先に目に入る。「変更を依頼する」は「承認する」と同じくらい手軽にしよう。無人実行の半分は、惜しいが正解ではないからだ。並列エージェントのワークフローではレビューがボトルネックになるし、エージェントが物理的にどこで動くか――自前のサーバーか、ノートPCか、その両方か――は、その出力が片付けられるキューとして届くかどうかに比べれば、はるかに重要ではない。
今日から使えるチェックリスト
エージェントから離れる前に、次を確認しよう。
- 隔離: 実行には専用のワークツリーがあり、自分の作業用チェックアウトを使っていない。
- 寿命: 切断してもプロセスが生き残る（
nohup、tmux、またはマネージドなComputer）。ノートPCを閉じても編集中に落ちない。 - 記録: stdoutとstderrが永続的なログ、または後からまっさらに読めるTaskタイムラインに残る。
- 非対話: 誰も答えないプロンプトでエージェントが止まらない。
- 影響範囲: ファイルの範囲が限定され、force-pushが無効で、無人実行が保護ブランチにマージしない。
- 完了通知: ポーリングしなくても、いつ終わったか、合格したかが通知される。
- レビューの約束: 完了した実行は必ずテスト、変更サマリー、既知の制限を伴って届き、受け入れ判断は自分のものだ。
最初の6つが実行を無人にする。最後の1つが、それをやる価値のあるものにする。すでに複数のエージェントを動かしていて、朝のレビューに時間を取られているなら、既存のコーディングエージェントをSharkly経由で実行しよう。散らばった状態ではなく、整理されたキューとして自分のもとに届くようになる。
