今朝、あなたは3つのコーディングエージェントを立ち上げました。1つは認証モジュールのリファクタリング、1つはテストの作成、もう1つは不安定なCIジョブの調査です。1時間後、手元には5つのターミナルウィンドウとデタッチされた2つのtmuxペインが開き、目を離している間にどれか1つはとっくに停止して放置されているのではないかという嫌な予感がよぎります。Alt+Tabで画面を切り替え、ログをスクロールし、状況を推測する羽目になります。
この「推測」こそが、エージェントを並列実行する際の真のコストです。複数のコーディングエージェントを同時に起動すること自体は、今や容易になりました。しかし、どのエージェントが人の介入を必要としているのか、どれが行き詰まっているのか、どれが音もなく完了したのかを見極める作業が、午後の貴重な時間を奪っていきます。並列コーディングエージェントを監視するとは、5つものウィンドウを開くことなく、4つのリアルタイムな問いに答えられることを意味します。すなわち、「各エージェントは何をしているのか」「どこまで進んだのか」「何がブロックしているのか」、そして「レビュー待ちとして何が戻ってきたのか」です。
本ガイドでは、まず自作（DIY）の監視環境を順を追って解説し、各ステップにおける潜在的な破綻モードを明らかにします。その上で、なぜその構成ではスケールしなくなるのか、そして共有タスクレイヤーを導入することで何が解決されるのかを示します。その共有レイヤーを担うのがSharklyです。すでに導入済みのコーディングエージェントを、Sharklyはチームへとまとめ上げます。各エージェントの進捗、ブロッカー、成果物をターミナルごとに散乱させることなく、1か所に可視化するのです。監視の仕組みの多くは自作できます。両方のアプローチを解説する目的は、手作りの仕組みが節約分以上のコストを生み始める境界線を的確に把握することにあります。
注視すべき4つのシグナル
監視とは単一の作業ではありません。エージェントの実行が「順調に見える」と言うとき、通常は4つの異なるシグナルのいずれかを指しており、それぞれ破綻の仕方が異なります。
- 状態（State）： プロセスは実行中か、入力待ちか、完了したのか、それとも停止したのか。完了したエージェントもハングしたエージェントも新たな出力を生成しないため、「無音」という事実だけでは何も判断できません。
- 進捗（Progress）： タスクはどこまで完了しているか。計画のチェックリスト消化、変更されたファイル、パスしたテストなどです。進捗を見ることで、実行中のエージェントがループに陥ることなく、実際に作業を進めているかどうかが分かります。
- ブロッカー（Blockers）： エージェントは何を待っている状態か。権限の確認プロンプト、不足している環境変数、マージコンフリクト、あるいはエージェントからの質問が未回答のまま放置されているケースなどです。
- レビュー待ちの成果物（Output needing review）： 人間が承認または却下すべきものとして、エージェントは何を生成したか。差分（diff）、PR、変更の要約などが該当します。
状態だけを見ていては、実行中でありながらリトライループに陥っているエージェントを見落とします。進捗だけを見ていては、20分前に完了していたエージェントに気づけません。監視環境は、すべてのエージェントについてこれら4つのシグナルを一目で把握できるようにする必要があります。
ステップ1：DIY方式の監視と各ステップの限界
手作りの構成では、手元にある既存のツールを使います。以下にその現実的な手法と、各ステップに残る落とし穴を示します。
実行状況の確認。 各エージェントが専用のgit worktreeで動作している場合は、ワークツリーとブランチの一覧を確認します。
git worktree list
tmux ls # if each agent runs in a tmux session
破綻のシナリオ： これで分かるのはセッションが存在することだけであり、内部のエージェントが作業中なのか待機中なのかは分かりません。Continue? (y/n)のプロンプトで止まっているtmuxペインも、タスク実行中のペインと見た目はまったく同じです。セッションにアタッチして初めて状況が分かります。
進捗の監視。 各エージェントの出力をtailし、ワークツリーの変更をポーリングします。
tail -f /path/to/agent-1.log
watch -n 5 'git -C ../wt-auth status --short'
破綻のシナリオ： これはエージェントの数に比例して負荷が増加します。3つのログなら読めますが、6つのログtailが入り乱れると追いきれません。また、watchループで見えるのはファイルの変動だけであり、その意味までは分かりません。ファイルが変更されていることは分かっても、その変更が正しいのか、エージェントが同じ処理を繰り返しているだけなのかは判別できないのです。
完了の検知。 プロセス終了時に通知が飛ぶよう、各エージェントをラッパーで囲みます。
your-agent-command "$TASK"; \
curl -s -X POST "$WEBHOOK_URL" -d "agent-1 exited $?"
破綻のシナリオ： 終了コード0はプロセスが終了したことを示すだけで、成果物が適切であることや作業が完了したことすら保証しません。多くのエージェントは、見落とされた質問を投げかけた後に正常終了します。「完了」通知は、実際には完了を意味しないシグナルを盲信させる原因になります。
コンフリクトの検知。 複数のエージェントが同一リポジトリを共有している場合、worktreeによって作業ディレクトリは分離されますが、2つのエージェントが異なるブランチで同じファイルを編集していれば、マージ時にやはり衝突します。
git worktree list --porcelain | grep branch
破綻のシナリオ： ファイルの重複に気づくのはマージを試みた瞬間であり、これは問題を発見するタイミングとして最も手戻りコストが高くなります。
これら自体が間違っているわけではありません。関連性のないタスクで2〜3個程度のエージェントを動かすだけであれば、いくつかのtmuxペインとwatchループによる監視で十分であり、過剰に大がかりな仕組みを導入する必要はありません。限界を感じるまでは、構成要素を最小限に留めておくのが賢明です。
DIY監視がスケールしなくなる境界線
その限界は、1つの画面に収まらないほど多くのエージェントを実行するようになったあたりで現れます。以下の3つの破綻が重なり合って顕在化します。
ポーリングでは「状態」しか分からず「原因」が分からない。 git statusやログのtailで分かるのは、何かが変更されたか、あるいは出力が止まったかということだけです。エージェントがプロンプトで止まっているのか、依存関係の欠落でブロックされているのか、あるいは単に終了したのかまでは分かりません。結局、原因究明のためにセッションへ1つずつアタッチすることになり、並列化によって排除するはずだった「ターミナルの切り替え作業」に逆戻りしてしまいます。
共有された状態が存在しない。 監視情報は個人のノートPC、tmuxサーバー、シェルの履歴の中に閉じ込められています。チームメンバーはどのエージェントがどのタスクを担当しているか確認できず、作業者自身もノートPCを閉じた瞬間に把握できなくなります。さらに、エージェントをリモートマシン上で動かしている場合、ローカルでのログtailによる監視アプローチは完全に破綻します。
レビューがボトルネックになる。 これは多くの人が軽視しがちな点です。成果物のレビューが1つの直列キューに逆戻りしてしまうなら、エージェントを並列実行する意味がありません。「レビュー済み / 修正要求 / マージ済み」を追跡する共通の場所がないまま5つの完了差分が上がってくると、5つのブラウザタブと頭の中の記憶だけで管理することになります。エージェントが速くなっても、人間側が遅くなってしまうのです。
この段階で不足しているのは、ターミナルの数ではありません。「共有された記録」なのです。
タスクボードがもたらす価値：成果物が1か所に集約される
タスクレイヤーを導入することで、監視の単位は「ペイン内のプロセス」から「状態を持つタスク」へと変わります。これこそがSharklyの設計思想であり、前述の4つのシグナルと直結しています。
各エージェントの実行は1つの「タスク」に紐づけられます。状態、進捗、ブロッカー、成果物はすべて、自分しか見られないログではなく、そのタスクのタイムラインに集約されます。ポーリングを繰り返す代わりに、ボードを一目見るだけで済みます。どのタスクが進行中か、どれがブロックされているか、どれが完了して自分の確認待ちかが一目瞭然です。SharklyのInboxには人間の介入が必要な実行が集まるため、「何か終わっただろうか？」と探し回る必要はなくなり、「自分が判断を下すべき案件はこれだ」と明確になります。エージェントは調査、実行、テスト、報告を行い、人間は方針の決定、権限の付与、成果物の承認を担当します。判断が求められる境界で自動化が適切に引き継がれるのです。
ここで境界線を明確にしておくことが重要です。誤解されやすいのですが、Sharkly自体がエージェントを実行したりコードを書いたりするわけではありません。実際のコード作成やコマンド実行は、普段使っているClaude CodeやCodexなどの既存ランタイムが担当します。Sharklyはそれらを取り巻く共有タスク、コンピューティング、コンテキスト、レビューのレイヤーを提供し、実行の進捗や差分を依頼からリリースまでチーム全体が把握できるようにします。また、各実行を専用の独立したworktreeに保持するため、通常ならマージ時に初めて発覚する同一ファイルの競合も、タスク単位で封じ込めることができます。
率直な判断基準を述べるなら、独立したタスクで1〜2個のエージェントを実行し、誰にも引き継ぐ必要がないのであれば、DIY方式の監視で十分であり、Sharklyはオーバースペックです。しかし、エージェントの数が画面数を上回ったとき、手元の端末以外で作業を実行するとき、あるいは他のメンバーと同一ボードを共有する必要が生じたとき、状況は一変します。単一のエコシステムに縛られることなく複数のコーディングエージェントを使い続けたい場合、そうした共通の可視化基盤こそがまさにSharklyの解決する課題です。ボードに表示すべき全体像の詳細については、AIコーディングエージェントのダッシュボードに本当に必要な表示項目をご覧ください。
今すぐ実践できる監視チェックリスト
手作りの構成を維持するにせよ、共有レイヤーへ移行するにせよ、並列エージェントの監視環境は、個々のセッションに1回もアタッチすることなく以下の問いに答えられる必要があります。
- すべてのエージェントが名前付きのタスクに紐づいているか。 名前のない「agent-3」ではなく、それぞれが何のタスクを担当しているか即答できる状態になっているか。
- 状態が一目で把握できるか。 実行中、入力待ち、完了、失敗が区別されており、「無音だから終わったのだろう」といった推測に頼っていないか。
- ブロックされたエージェントがアラートを上げているか。
y/nの確認プロンプト、シークレット情報の不足、未回答の質問などが、静かに停滞することなく通知されているか。 - 完了とは「レビュー可能」を意味しているか。 単にプロセスが終了しただけでなく、差分やPRが提示されているか。
- レビュー自体のステータスが管理されているか。 レビュー済み、修正要求、マージ完了などが追跡され、並列処理の成果が1つずつのレビュー待ちキューに逆戻りしていないか。
- ノートPCを閉じても状況が維持され、チームと共有できるか。 状態がシェルの履歴以外に記録されているか。
- 同一リポジトリ内の作業が分離されているか。 各エージェントに固有のworktreeが割り当てられ、ファイルの重複がマージ作業中ではなく事前に検知できるか。
現在の環境をこのリストと照らし合わせてみてください。今日チェックを付けられなかった項目が、後になって午後の貴重な時間を奪う原因になります。すでに複数のエージェントを運用しているなら、Sharklyを導入することでタスクと成果物を一元管理できるようになります。また、現在お使いのランタイムをそのまま活かしながら、既存のコーディングエージェントをSharkly経由で実行することも可能です。
