今朝、あなたは4つのエージェントを起動した。1つは認証モジュールをリファクタリングし、1つはテストを書き、1つは不安定なCIジョブを追いかけ、1つはまだ考え込んでいる。午後になると、何かが起きたという漠然とした感覚、山積みのターミナルタブ、作ったかどうか半分しか覚えていない3つのworktree、そしてまだ読んでいない2つのプルリクエストが残っている。作業は完了した。だが、それが何だったのかは見えない。
AIコーディングエージェントが完了した作業を追跡するとは、こうした散らばりを記録に変えることだ。各エージェントが何を変えたのか、それは持ちこたえるのか、そしてどこに着地したのか。これが本当に問題なのは、エージェントがあなたの確認より速く完了してしまい、彼らが何をしたかの証拠が、たった一人で作業する人のために作られた場所に置かれているからだ。本ガイドでは、まず手動でのセットアップを順に見ていき、どこで破綻するのかを明らかにし、その後でSharklyが使っているワークフローを紹介する。これは、すべての結果を、それを要求したタスクに紐づけたままにしておくためのものだ。
手短に言えば、2〜3のエージェントならgitとターミナルで手作業でも追跡できる。それを超えると、結果がひとりでに戻ってくる共有の場所が必要になる。ボトルネックがコーディングではなく、それをレビューするあなたの能力になるからだ。
TL;DR
完了したエージェントの作業を追跡するとは、実行ごとに3つの問いに答えることを意味する。何が変わったのか、それは正しいのか、そしてどこに着地したのか。gitの履歴とプルリクエストがあれば、1〜2のエージェントについては最初の問いに答えられる。しかし複数のエージェントが並行して動き始めると、記録はworktree、ターミナル、PRキューへと断片化し、タスクとその結果のつながりが失われてしまう。タスクボードは、実行・ブロッカー・結果・人間によるレビューを1つのタスクに戻すことでこれを解決する。そうすれば、完了した作業は再構築するものではなく、そのまま確認できるものになる。
完了した作業を追跡するとは何か
追跡とはアクティビティのログではない。終わった実行について、逆算せずとも3つの問いに答えられる能力のことだ。
- 何が変わったのか。 diff、触れたファイル、それぞれの変更理由。
- それは正しいのか。 型チェック、テスト、ビルド、そしてエージェントが何を検証したかの要約。
- どこに着地したのか。 ブランチ、PR、それが属するタスク、そして誰が承認するのか。
黙って終了したエージェントは、技術的には作業を完了している。しかしそれに対して行動は起こせない。あなたが気にかけるべき「完了」とは、人が確認して承認できる状態だ。だからこそ「テストが通った」は「作業が追跡されている」と同じではない。
コーディングエージェントにおけるhuman-in-the-loopモデルはその線引きを示している。エージェントは調査・実行・テスト・報告を行い、人は方向性を決めて結果を承認する。追跡とは、後半を成立させるための仕組みだ。
DIYセットアップの手順と、各ステップが破綻するポイント
1つのブランチで1つのエージェントを動かすなら、標準搭載のツールで十分だ。ここでは正直なバージョンを示し、各ステップで失敗するパターンに名前を付けていく。
ステップ1: 何が変わったかを見る。 実行後にdiffを読む。
git log --oneline -10
git diff main...HEAD --stat
破綻するのは: 2つのエージェントが同じブランチを共有している場合、あるいはエージェントが何もコミットせず、忘れていたworktreeの作業ツリーに変更を残したままの場合。あなたが読んだdiffは、出荷されたdiffではない。
ステップ2: 各エージェントの作業を分離する。 衝突を避けるため、エージェントごとに専用のgit worktreeを与える。
git worktree add ../auth-refactor -b auth-refactor
git worktree list
破綻するのは: リストが自分の頭で把握できる量を超えたとき。git worktree listが教えてくれるのはパスだけで、どのエージェントがどれにいるのか、どのタスクのためのものか、終わっているのかは分からない。仕組みについてはgit-worktreeの公式ドキュメントを参照してほしい。ただし、そこに書かれているのは帳簿付けの範囲までだ。
ステップ3: 結果がPRに到達したか確認する。 GitHubに頼る。
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
破綻するのは: PRはあるのに理由が誰も書いていない場合、チェックは緑なのに変更が間違っている場合、あるいはPRがそれを始めた要求へ遡るリンクを持たない場合。gh pr listのリファレンスが示すのはオープンなPRであり、意図ではない。
ステップ4: 何を依頼したかを思い出す。 このステップにコマンドはない。元の要件はSlackのメッセージやメモ、あるいはあなたの記憶の中にある。3日後にPRをレビューするとき、あなたは受け入れ基準を推測することになる。
どのステップも機能する。問題はステップ間の継ぎ目だ。diff、分離、PR、そして意図は、互いを知らない4つのシステムに存在し、それらをつないでいるのはあなただけだ。
手動セットアップがスケールしなくなる地点
破綻は一瞬の出来事ではない。坂道のようなもので、自分がそのどこにいるかは言い表せる。
| 並行するエージェント数 | 追跡にかかるコスト | 最初に壊れるもの |
|---|---|---|
| 1 | diffを1つ、PRを1つ読む | なし |
| 2〜3 | worktree間でのコンテキストスイッチ | どのエージェントが何をしたか分からなくなる |
| 4〜6 | PRごとに意図を再構築する | 結果がレビュー能力を追い越す |
| 7以上 | 専任の調整業務 | 完了した作業が何日も未レビューのまま放置される |
本当のコストはエージェントの速度ではなく、レビュー能力で測られる。エージェントは人が確認できる以上の速さで作業を完了させるため、数件を超えたあたりから、スループットはエージェントがコードを書く速さではなく、あなたが3つの問いにどれだけ速く答えられるかで頭打ちになる。エージェントを増やせば、デリバリーの問題が改善するどころか追跡の問題が悪化する。
タスクボードがもたらすもの
解決策は、完了した実行をdiffとして扱うのをやめ、タスクへ戻ってくるものとして扱い始めることだ。
Sharklyでは、タスクが共有の記録となる。タスクをエージェントまたはCrewに割り当てると、実行は分離されたworktreeで行われ、並行するエージェントが同じファイルに触れることはない。完了すると、実行・ブロッカー・結果・フォローアップがタスクのタイムラインに戻ってくる。変更の要約、検証結果、既知の制約は、開いたままにしておかなければならないターミナルではなく、タスクそのものに紐づく。
これがログと記録の違いだ。ログは何かが起きたことを教えてくれる。記録は、何が変わったのか、それが正しいのか、どこに着地したのかを、それを始めた要求に紐づけて1か所で教えてくれる。完了した作業はタスクからレビューし、承認するか差し戻す。その判断にはあなたの名前が残る。
ここでDIYの継ぎ目が埋まる。意図、diff、チェック、承認が1つのオブジェクト上にそろう。エージェントがすでに使っているツールはそのまま使える。実行は引き続きClaude CodeやCodexが担い、Sharklyがその周囲にタスク、コンテキスト、レビューのレイヤーを加える。AIエージェントへの作業の割り当ては、同僚に仕事を頼むのと同じように読めるようになり、結果はあなたが見つけられる場所に戻ってくる。
Sharklyをダウンロードして、1台のComputerをつなぎ、規模を広げる前に実際のタスク1つで試してみてほしい。
これがまったく不要なケース
しきい値については正直であろう。1つのリポジトリで1つのコーディングエージェントを動かし、マージ前にすべてのdiffを読んでいるなら、gitとターミナルだけで完了した作業はすでに追跡できている。タスクボードは不要なお作法を増やすだけだ。Claude Codeの標準プロジェクトビューは、単一エージェントのワークフローなら驚くほど多くのことをカバーしてくれる。
式が変わるのは、次の3つが重なったときだ。同時に動かすエージェントが2〜3を超えること、完了したその日のうちにレビューできない作業があること、そして結果を自分以外の誰かに届ける必要があること。そのとき、共有のタスク記録は overhead ではなくなり、要求からリリースまで完了した作業を見えるようにする唯一の手段になる。
今日から使えるチェックリスト
新たなエージェントを追加する前に、すでに動いているものについて、次のすべてに「はい」と答えられるか確認してほしい:
- [ ] 終わった実行について、ターミナルを開かず1分以内にdiffを見つけられるか？
- [ ] 完了した各実行には、緑のチェックだけでなく、エージェントが何を検証したかの要約が添えられているか？
- [ ] PRから、それを始めた要件まで遡れるか？
- [ ] どのエージェントが何を担当し、何が終わり、何がレビュー待ちなのかを示す1つの場所があるか？
- [ ] 完了した作業を承認するとき、そこに人の名前が残るか？
- [ ] エージェントが終了したとき、結果はあなたのところに届くか、それとも自分で探しに行かなければならないか？
「いいえ」があれば、それはエージェントを増やすほど広がっていく継ぎ目だ。早めに直すほうが、追跡されていない1週間分の実行を後から再構築するより安く済む。
FAQ
AIコーディングエージェントが変更した内容をどう追跡すればよいですか？ エージェントの要約ではなく、diffそのものを読みましょう。1つのエージェントならgit diffとPRで十分です。複数いる場合は、各実行を専用のworktreeに置き、diffと検証の要約を共有タスクへ戻すようにすれば、スクロールバックから再構築せずに済みます。
GitHubだけでAIエージェントの作業を追跡できますか？ 1〜2のエージェントなら可能です。GitHubはオープンなPRとチェックの状態を示してくれます。ただし、どのエージェントがそのPRを生んだのか、どのタスクのためのものか、変更が元の意図と合っているかは教えてくれないため、複数のエージェントが並行して動き始めるとすぐに手薄になります。
タスクボードが必要になるまで何個のエージェントを動かせますか？ 多くの人は並行3〜4エージェントあたりで継ぎ目を感じ始めます。PRごとに意図を再構築する時間が、レビューそのものより長くなり始める頃です。引き金になるのはレビュー能力であり、決まった数ではありません。並行するコーディングエージェントの管理に関する記事もご覧ください。
タスクボードは動きの速いエージェントを遅くしますか？ いいえ。エージェントは引き続き分離されたworktreeで全力で実行されます。ボードは、完了した作業がレビューできる場所に着地するための戻り道を加えるもので、手作業の再構築ステップを省くのであって、増やすのではありません。
