8月26日、Eivind Kjosbakkenが「How to Effectively Solve 100+ Tasks with Claude Code」と題した記事を公開した。コーディングエージェントの普及が生んだ逆説——タスクが増えすぎてエージェント自体の管理が破綻する——を解決する実践的なパイプラインの記事で、特に「タスクごとにサブエージェントを独立したworktreeで起動させる」という設計が核心をなす。
コーディングエージェントが普及した結果、皮肉な問題が生まれた。コードを書くコストが下がったことで、プロダクトへのフィードバックの敷居も下がり、小規模な修正依頼が爆発的に増えたというのだ。
Kjosbakkenはスタートアップや複数のアプリケーション開発に関わる中で、この問題を日常的に体験してきた。タスクが1日に大量に積み重なると、1タスクにつき1セッションを立ち上げる方式は現実的ではない。かといって全タスクを1セッションに詰め込めば、コンテキスト長の上限に当たり、モデルが適切にオーケストレーションできなくなる。
この記事では、その両方の問題を回避する具体的なパイプラインが紹介されている。なお、Claude CodeはAnthropicが提供するターミナルベースのコーディングエージェントで、ファイル操作・コード編集・コマンド実行をエージェントに委譲できるCLIツールだ。コーディングエージェント全般の概要についてはAnthropicの公式ドキュメントも参照されたい。
パイプライン全体像
Kjosbakkenが日常的に使うパイプラインは以下の7ステップで構成される。
- Slackでフィードバックを受け取る
- 自動botがLinearのチケットを作成する
- その日のタスク専用のClaude Codeセッションを1つ立ち上げる
- タスクをトリアージする（小さければそのセッションで処理、大きければ別スレッドに分離）
- Claude CodeにHTMLレポートを生成させ、不明点を人間が補足する
- Claude Codeがタスクごとにサブエージェントを起動し、開発環境へデプロイする
- HTMLレポートで動作確認し、完了またはフィードバックを返す
最も重要なポイント：サブエージェントの使い方
このパイプラインの核心は「タスクごとにサブエージェントを別worktreeで起動させる」という指示方法にある。
ここでいうworktreeとは、Gitのworktree機能のことだ。通常、Gitリポジトリは1つの作業ディレクトリ（ワーキングツリー）しか持たないが、git worktree addコマンドを使うと、同一リポジトリから複数の作業ディレクトリを同時に展開できる。各worktreeは独立したブランチを持ち、ファイルシステム上でも別々のディレクトリとして存在するため、複数のエージェントが同時に異なるタスクを処理しても互いのコードに干渉しない。
Claude Codeに対して明示的に「各タスクをサブエージェントに独立したworktreeで処理させる」と指示することで、サブエージェント同士が互いのコードへ干渉しなくなる。CLIのメニューからサブエージェントの一覧を確認でき、必要であれば個別に中に入って状況を確認することもできる。
また、タスクの種類によって扱い方を変えている点も実用的だ。
- 通常の修正タスク → サブエージェントに実装・コードレビュー・デプロイまで一気に実行させる
- デザイン変更など視覚確認が必要なタスク → localhostサーバーを立ち上げさせて人間が目視確認してからデプロイする
トリアージ：大きいタスクは必ず分離する
タスクトリアージのステップで強調されているのが、大きなタスクは必ずメインセッションから分離するという原則だ。
Linearチケットを読み込んだClaude Codeにタスクの詳細をHTMLレポートとしてまとめさせ、人間が各タスクについて設計方針や実装方針を補足する。このとき、規模の大きいタスクが混じっていれば、Claude Codeに「ハンドオフ」を作らせて別セッションに切り出す。
大きいタスクをメインセッションに混在させると、エージェントへの質問・確認が分散して管理が破綻するためだ。別セッションに分離することで、そのタスクに関するやり取りを一箇所に集約できる。
検証の効率化：HTMLレポートを活用
実装が完了した後の確認フローも工夫されている。Claude Codeに以下の内容を含むHTMLレポートを生成させる。
- 元のSlackメッセージまたはLinearチケットの文言そのままの引用
- 動作確認ができる具体的なページへの直リンク
- テスト手順
これにより、確認担当者がプロダクト内をナビゲートする手間が省け、1タスクあたり30秒〜1分で確認が完了するという。確認の結果、実装が正しければ完了マーク、問題があればフィードバックを返して再度HTMLレポートを待つ。
この確認サイクルを高速に回せることが、大量タスクを現実的に処理できる理由のひとつとなっている。1件ずつ手作業でプロダクトを開いて確認する従来の方法と比べ、直リンクと標準化されたレポート形式の組み合わせが確認コストを大幅に下げている。
まとめ
この方法論の要点を整理すると次のようになる。
| ステップ | ポイント |
|---|---|
| タスク収集 | Slack + Linearで一元管理 |
| セッション設計 | 1日1セッション、大タスクは別セッションに分離 |
| 並列処理 | タスクごとにサブエージェント＋別worktreeで独立実行 |
| 確認 | HTMLレポート＋直リンクで高速化 |
コーディングエージェントを使う機会が増えるほど、セッション設計の巧拙が生産性を左右するようになる。1タスク1セッションでも全部1セッションでもなく、その中間の設計を意識的に組むという視点は、実務で即応用できる。とりわけworktreeを活用したサブエージェントの独立実行という発想は、並列処理の干渉問題に悩む場面で汎用的に参照できる設計パターンだ。
詳細はHow to Effectively Solve 100+ Tasks with Claude Codeを参照していただきたい。
