この投稿は、実践ではなく異論から始まる。著者は、複数のコーディングエージェントを同時に動かしているエンジニア — 複数の Claude Code や Codex CLI のインスタンスを、ときに 1 つのリポジトリで、ときに別々のチェックアウトや Git ワークツリー にまたがって動かしている — の話をしばらく前から耳にしていたが、それに懐疑的だったと報告する。その根拠は、AI が生成したコードはレビューしなければならず、したがって自然なボトルネックは自分自身がどれだけ速くレビューできるかにある、というものだった（レビューのボトルネック を参照）。1 つのモデルについていくだけでもすでに大変なのに、さらに後れを取るだけなら、複数を動かして何が得られるのか、と彼は問う。
変わったのは異論そのものではなく、その適用範囲である。彼は、重要な変更をレビューしてマージすることには依然として一度に 1 つしか集中できないと報告し、その代わりに見出したのは、その主要な作業に大きな認知的負荷を加えることなく並列に投げられるタスクが増えていることだったと述べる。投稿の本体はそうしたタスクの 4 つのカテゴリであり、方法論としてではなく、彼が効果的だと感じたパターンとして提示されている。
カテゴリは、決して残さない作業から残す作業へと並んでいる。リサーチタスクは、残すつもりのある変更を一切加えずに、問いに答えたり推奨を出したりする — 彼の例は、2 つのライブラリをつなぎ合わせたときに実際に動作するかどうかを確かめることであり、訓練データに含まれていないほど新しいライブラリであっても障害にはならないと記している。エージェントにそのリポジトリをチェックアウトしてコードを読むよう指示できるからである。次は既存のシステムについての質問である。彼は、ここではコードベースの大きさは問題にならないと論じる。エージェントは grep のようなツールを極めて効果的に使い、数十のファイルにまたがるコードパスをたどることができるからであり、その説明は後のプロンプトのための良いコンテキストになるので残しておく価値がある。その次は、小さく極めてリスクの低い保守作業である — テストスイートで出る非推奨警告を丸ごと任せる、といったもので、彼はこれを、いろいろ試してみることで最もよく身につくコツを要するものだと述べる。最後は彼自身が仕様を書いた作業である。どこからともなく届いたコードをレビューするのは、まずその目的を再構築しなければならないため高くつき、自分自身の詳細な仕様から作られたコードを確認するのははるかに安く済む、と彼は論じる。
要点
- エージェント支援の作業におけるボトルネックは著者自身のレビュー能力であり、これはエージェントの並列実行がうまくいかない理由としてではなく、当初それに懐疑的だった理由として述べられている。
- 彼が報告する解決策は、レビューを増やすことではなく分業である。アクティブにレビューする重要な変更は一度に 1 つとし、追加のタスクは、それに加える認知的負荷が小さいことを理由として選ぶ。
- リサーチや概念実証の作業は、生み出されたものを残すつもりがなく、レビューのキューに入ることがないため、うまく並列化できる。
- モデルの訓練データに現れないほど新しいライブラリであることは、この種のスパイクの障害にはならない。エージェントに依存先のリポジトリをチェックアウトしてソースを読むよう指示できるからである。
- 既存のシステムがどう動くかについての質問には、現在の推論モデルが 1、2 分で答えてくれる。著者は、エージェントが grep のようなツールを効果的に使い、数十のファイルにまたがるコードパスをたどれるため、コードベースの大きさはこれを制約しないと述べている。
- 自分のシステムについて LLM が生成した説明は保存しておく価値がある。後のプロンプトに貼り付けるのに良いコンテキストになるからである（コンテキストエンジニアリング を参照）。
- 低リスクの保守の雑用 — 彼の例はテストスイートに出てくる非推奨警告 — は、技術的な難しさが小さいからではなく、認知的負荷が小さいからこそ委任する価値がある。
- こうした機会を見つけることは、小さなタスクを試し、成功と失敗の両方から学ぶことで身につくコツとして説明されている。これはルールとしてではなく、著者自身の直感として示されている。
- 頼まれていない変更をレビューするには、コードを読む前に、まずその目的、プロジェクトにそれが必要かどうか、そのアプローチが予定している今後の作業に合っているかを導き出す必要がある。
- レビュアー自身が書いた仕様から生成されたコードは、目的、アプローチ、詳細な仕様がすでに決まっているため、レビューのコストが大幅に低い。
- 執筆時点で著者が日常的に使っていると報告しているのは、Sonnet 4.5 上の Claude Code、GPT-5-Codex 上の OpenAI Codex の CLI、そして非同期タスク用のそのクラウド版であり、後者はスマートフォンから起動することが多いと述べている。
- 彼は GitHub Copilot コーディングエージェント と Google Jules も試したと報告しており、後者を上記のクラウドエージェントに対する Google の当時無料の代替と説明している。
- 彼のローカル環境は、異なるディレクトリで開いた複数のターミナルウィンドウで、さまざまなエージェントを YOLO モード で動かすというものであり、悪意ある指示がコンテキストに到達しえないと確信できるタスクに限定している。
- 影響範囲を限定するためにローカルのエージェントを Docker コンテナ内で動かすべきだと述べつつ、それを習慣にはしていない — これは彼の実践ではなく意図として記録されている。
- 執筆時点では git worktree を採用しておらず、1 つのリポジトリに対して 2 つのエージェントを分離したいときは、代わりに新しいチェックアウトを使っている。
- よりリスクの高いタスクは非同期のクラウドエージェントに回し、そこでの最悪のケースを自分のソースコードが持ち出されることだと見積もっている — 彼はエージェントにネットワークアクセスを許可している — そして、自分が取り組んでいるものの大半はオープンソースであるため、これは自分にとってあまり問題にならないと記している。
- エディタのエージェントモードを動かす GitHub Codespaces は驚くほど効果的であり、GitHub アカウントを持っていれば誰でも使え、追加の API キーを必要としないため、ワークショップやデモに特に適していると報告されている。
- 著者は、モデルがこれらのツールを効果的に駆動できるほど良くなったのは執筆前のわずか数か月のことだとし、特に Claude 4 と GPT-5 の世代を挙げている。
- 彼は、大規模なコードベースに対して本当に難しいタスクを、その出力をマージするつもりなく、純粋にどのファイルに手を入れるか、問題をどう捉えるかを知るためだけにエージェントに渡すという実践を試したと報告している — これは Josh Bleecher Snyder に由来する習慣であり、彼はそれを斥候を送り出すことと呼んでいる。
背景
この投稿は、著者自身の LLM の使い方についての継続的なシリーズの一部であり、明示的に未完成の思考として提示されている。彼はまだパターンに馴染みつつある段階であり、今後も反復を続けるつもりだと述べ、他の実務者にも自らの記述を公開するよう促して締めくくっている。全体を通じた根拠は、測定ではなく彼自身の最近の実践 — どのツールを動かしているか、何を委任しているか、何にまだ手をつけていないか — であり、セキュリティ上の姿勢は個人的なリスク判断として示されている。その中には、承認なしで動かしており、コンテナ化すべきだと感じているという告白も含まれる。投稿はまた、並列エージェントのワークフローについて公開された他の 3 人の実務者の記述に対して自らを位置づけており、それらを要約するのではなく推薦している。それらの記述の詳細は各著者のものであり、ここでは確立されたものとして扱わない。モデルに非常に明示的に指示することについての著者の以前の投稿が 4 つ目のパターンの起源として挙げられており、エージェント的ループの設計 は同じシリーズの直前のエントリである。