Codexエージェントを1つ動かすのは簡単です。ターミナルを開き、タスクを伝え、作業の様子を眺めるだけ。面倒になるのは3つになったときからです。1つは認証モジュールをリファクタリングし、もう1つは不安定なテストを修正し、3つ目はマイグレーションの下書きを作成中——それぞれが独立したターミナルタブと、それぞれのスクロールバックの中にあります。10分も経てば、どのタブがどのタスクなのか、マイグレーションが終わったのか、テスト修正はどのブランチに入ったのか、思い出せなくなっています。エージェントは何も問題ありません。追跡できなくなったのはあなたの側です。
これが「複数のCodexエージェントの管理」という言葉の裏にある本当の問題です。問題は並行処理ではありません。作業ディレクトリを分ければ、Codexは喜んで並列で動きます。問題は、その作業の状態——各エージェントが何をしているか、何が終わったか、何が失敗したか、何がレビュー待ちか——がターミナルタブやworktreeフォルダ、そしてあなたの記憶に散らばってしまうことです。そのうち1つでも失えば、流れを見失います。
Sharklyはまさにこのギャップのために存在します。コーディングエージェントはすでに手元にあるはずです。Sharklyは、エージェントの実行ごとに1つの共有レコードを与えることで、彼らをチームに変えます。この記事ではまず手動セットアップを順に説明します。何を自動化しようとしているのかを理解しておくべきだからです。そのうえで、タスクボードが真価を発揮する場面を示します。最後には、今日から実行できるチェックリストを用意しています。
「追跡を失う」とは実際何を意味するのか
「追跡を失う」は漠然とした話ではありません。具体的な故障です。つまり、作業状態を置くべき唯一の場所が存在しないのです。複数のCodexセッションを手作業で動かすと、各タスクの真実は同時に4か所へ分散します。指示は打ち込んだターミナルに、変更はGitの作業ディレクトリに、ステータスはあなたの頭の中に、結果はまだ開いていないプルリクエストに。この4つを同期させてくれるものは何もありません。ターミナルを閉じれば指示は消えます。タブを切り替えればステータスは推測になります。エージェントが増えるほど、「今何が起きているか」のコピーが増え、それらをつなぎ止めている唯一の統合点があなた自身になります。
つまり、複数のCodexエージェントを管理する目的はとても狭く、はっきり言い切る価値があります。各エージェントのタスク、進捗、変更、レビューステータスを、非公開のターミナルセッションに分散させるのではなく、1か所にまとめておくことです。以下の話はすべて、この1つの基準で判断されます。
ステップ1: worktreeで各エージェントを隔離する
最初の失敗パターンは衝突です。2つのCodexエージェントを同じフォルダに向けると、互いの編集を上書きし、互いのファイルをステージし、誰にも読めないdiffを生み出します。Git worktreeは、同じリポジトリのチェックアウトをエージェントごとの専用ブランチで与えることで、これをきれいに解決します。
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
あとは各ディレクトリの中でCodexセッションを1つずつ起動するだけです。各エージェントは自分のファイルしか見えず、自分のブランチにコミットし、他のエージェントを踏みつけることはありません。
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
ここで名前を付けておくべき失敗パターン: worktreeが解決するのはファイルの衝突であって、追跡ではありません。名前がほぼ同じ3つのフォルダができたのに、どれがどのタスクなのかの記録はありません。タスクをエンコードした命名規則（agent/<task>）を採用しましょう。1週間もすればrepo-2やrepo-3は何の意味も持たなくなります。より深い仕組みを知りたい場合はAIコーディングエージェントのためのGit worktreeを、より広いパターンについては複数のCodexタスクを同時に実行する方法をご覧ください。
ステップ2: セッションを見失わないようにする
3つのエージェントを3つのタブで動かすということは、誤ってCmd+Wを押すだけで実行中のタスクを殺し、そのスクロールバックを失う距離にいるということです。tmuxのようなターミナルマルチプレクサなら、すべてのセッションを名前付きウィンドウで生かしたまま、デタッチして後から再アタッチできます。
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
名前付きウィンドウ（auth、flaky、migration）は、素のタブが捨ててしまうラベルを取り戻します。Ctrl-b dでデタッチし、ノートPCを閉じ、翌朝再アタッチすれば、セッションはそのまま残っています。
ここで名前を付けておくべき失敗パターン: tmuxがセッションを実行し続けることはあっても、どれがあなたを必要としているかは教えてくれません。20分前に終わったエージェントも、エラーで止まったエージェントも、外から見れば同じです——静かなペイン。結局どのウィンドウも訪れて最後の100行を読まないと、ステータスは分かりません。このポーリングコストはエージェントが増えるほど大きくなり、手動セットアップが時間とともに重く感じられる税金になります。
ステップ3: ステータスとレビューを永続的な場所に記録する
最後の手動パーツは、多くの人が飛ばしてしまうもの。各エージェントが何を生み出し、自分がそれを受け入れたかどうかを書き留めることです。スクロールバックは記録ではありません。消えてしまい、タスクをまたいで検索できず、チームメイトも読めません。軽量版は、手で更新するただのチェックリストです。
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
これは仕事の全体を縮図にしたものです。進捗、ブロッカー、結果、そして人間のレビューが、依頼からリリースまで見える形で残る永続的な場所。これを忠実に維持できれば、ターミナルから複数のエージェントを長く管理できます。落とし穴は、何か変わるたびに手で更新する「同期エンジン」があなた自身だということです。エージェントの出力を監査可能にする方法については、AIコーディングエージェントが完了した作業を追跡する方法をご覧ください。
手作りセットアップがスケールしなくなる地点
手動アプローチで十分なのはどんなときか、正直に判断しましょう。範囲が明確なタスクに対する1～2個のCodexエージェントなら、worktree＋命名規則＋手書きのステータスファイルで本当に十分です。必要のないツールを足してはいけません。可動部はほぼゼロで、全体が頭に収まります。
等式が変わるのは予測できる地点です。次のように感じたらそのときです:
- 3つ以上のエージェントを動かしていて、ポーリングコスト（すべてのペインを訪れ、末尾を読み、ステータスを覚える）が、エージェントが節約してくれる時間より多くの時間を食っている。
- 作業が複数のリポジトリにまたがり、worktreeだけでは1つのきれいな全体像にならない。
- 他の誰かが「今エージェントたちは何をしているの？」と聞いてきて、正直な答えがあなたのターミナルと記憶の中にしかない。
これらはすべて、記事冒頭と同じ根本原因です。共有の置き場所を持たない作業状態。手動セットアップはそれを、唯一スケールしない場所——あなた自身——に置き続けます。チームが最も早くこの壁にぶつかるのは、並列AIコーディングエージェントを管理するための最良ツールがどれも同じ一手に収束するからです。作業にターミナルの外の家を与える、という一手です。
タスクボードが加えるもの
タスクボードは、管理の単位を「ターミナルセッション」から「タスク」へ変えます。Sharklyでは、すでにCodexを動かしているコンピュータを接続し、ペインに打ち込む代わりにCodexエージェントへタスクを割り当てます。エージェントは専用の隔離されたworktreeで実行され、実行状況・進捗・ブロッカー・結果はタスクへ戻ってきます。もうポーリングは不要です。何が終わり、何が失敗したかをボードがすでに把握しています。
この分業は意図的なもので、境界として明言する価値があります。SharklyはCodexの代替ではありません。実行するのはCodexです。Sharklyはその周りに、共有タスク、コンピュータ、コンテキスト、レビュー層を追加します。エージェントは調査・実行・テスト・報告を行い、人間は方向性を示し、権限を与え、結果を受け入れます。自動化が止まるのはあなたの判断が必要なところ、つまりコードではなくレビューゲートです。
これこそ手動のステータスファイルが目指していたもので、永続的かつ共有された形になったものです。ターミナルには与えられない3つのことが、ここから生まれます:
- ポーリングなしのステータス。各タスクは、ペインを訪れなくても実行中・完了・ブロック・レビュー待ちを示します。
- リポジトリをまたぐ1つの全体像。多くのリポジトリや多くのエージェントのタスクが1つのスペースに収まるので、エージェントが増えても見守るターミナルが増えるわけではありません。これはチームが1か所からClaude CodeとCodexを一緒に動かすのと同じ理由です。
- 機能するレビューステップ。結果は、変更サマリーと根拠が添えられたhuman-in-the-loopゲートで待ちます。保留中だったことを忘れたせいでマージされてしまうことはありません。
これらはすべて、worktreeと規律で手作りすることもできますし、エージェント数が増えたらSharklyでワークフローを管理することもできます。Codexはそのままのままで、管理はあなたの肩から離れます。すでに複数のCodexエージェントを動かしているなら、それがまさにSharklyが想定して設計された問題です。
今日から実行できるチェックリスト
手動のままでもボードに移っても、追跡を失わないための最低ラインはこれです:
- [ ] エージェントごとに1つの隔離されたworktree、タスク名を付けたブランチで。1つのフォルダに2つのエージェントを決して置かない。
- [ ] タスクをエンコードする命名規則。
repo-3よりagent/auth-refactor。 - [ ] 長時間生きるセッション（tmuxまたはボード）。作業を殺さずにデタッチ・再アタッチできる。
- [ ] ターミナルのスクロールバックの外にある永続的なステータス記録: タスク、ブランチ、ステータス、レビュー状態。
- [ ] 明示的なレビューゲート。人間が受け入れるまでブランチはマージしない。
- [ ] 数の確認: エージェント3つ以上、またはリポジトリ2つ以上なら、ステータスを頭の外に出す。
ポーリング税が痛むまで手動版を続けましょう。痛くなったら、既存のコーディングエージェントをSharkly経由で実行してください。追跡はあなたではなくボードの仕事になります。
よくある質問
現実的にCodexエージェントは同時にいくつ動かせる？マシンとレート制限が許す限りです。最初にぶつかる上限は通常、技術的ではなく人間側です。3つ以上を手で追跡するあたりで、多くの人が流れを見失います。実行側の上限についてはCodexの同時スレッドとサブエージェントをご覧ください。
タスクボードはCodexを置き換える？いいえ。実行するのはCodexで、ボードはその周りの割り当て、隔離、コンテキスト、レビューを管理します。両者は補完関係にあります。
