複数エージェントの使いこなし 前編 複数エージェントを使い分ける開発の現場
複数のエージェントを使い分けると聞くと、どんな作業を思い浮かべるでしょうか。サブエージェントや別セッションに作業を分ける理由や、レビュー・指示役を別のエージェントに任せるやり方を、ピクセルグリッドの3人で話してみました。
はじめに
エージェントを1つ起動して会話しながら作業するところから一歩進み、複数のAIエージェントに作業を任せる開発が広がっています。しかし、どう分けて使うのか、分けたエージェントがそれぞれ何をしているのかは、普段あまり複数エージェントを使っていないと想像しにくいところです。
そこで今回は、複数のエージェントを日常的に使い分けているメンバーに、どのように使っているのかを聞きました。前編では、作業を分ける理由や、3人それぞれの作業環境を紹介します。
参加者は次のとおりです。
なお、この座談会は2026年9月中旬に行われました。発言の内容には、2026年9月時点の状況を反映したものが含まれています。
複数エージェントとは、役割やセッションを分けて使うこと
――まず、複数エージェントとは何を指すのか、整理しておきたいと思います。コーディングエージェントに別のエージェントを操作させたり、複数のコーディングエージェントに役割を分けて作業させたりすることを指すのでしょうか？
大杉：何を複数にするか、というところはあると思います。CodexなのかClaude Codeなのか、エージェントというよりCLIツールだったりもしますけど。
わかりやすい例でいうと、Claude Codeにはサブエージェントがあります。メインのエージェントがサブエージェントをうまく使うんです。
たとえば、Slackから関連する情報だけを引っ張ってきて反映したいとき、Slackの情報を全部網羅的に漁っていたら、それだけでコンテキストを食いつぶしてしまいますよね。単純に探してくるだけなら性能の低いモデルでもいいので、そちらに探索だけさせます。
そのサブエージェントには、情報の取捨選択まではさせずに、「このあたりにあるっぽいよ」という場所だけを見つけさせる。メインのエージェントはその結果を使って探しに行く。そうすると、メインのほうに余計なものが入ってくるのを最低限に防げます。
――サブエージェントに下調べを任せるような使い方ですね。
大杉：そうです。下調べだけじゃなくて、部分的な実装を任せてもいいんですけどね。
それとは別に、Claude Codeでは、ほかのセッションとやり取りすることも少し前からできるようになりました。たとえば、CodeGridのサイトを作っているセッションAと、CodeGridの部分的な修正について調べているセッションBの2つを立ち上げていたとします。
そのとき、自分はAとだけやり取りして、「これはBにも関係しそうだから伝えておいて」「そのうえでBにやらせておいて」と頼む。Claude Code同士でメンションして、そういうやり取りができるんです。
その一歩先として、Claude CodeからCodex、CodexからClaude Codeというようにやり取りさせてもいい。どう使い分けるかは人それぞれで、こちらのほうが得意だからやらせるとか、スキルの都合とかもあると思います。
僕の場合はだいたい、トークンとコンテキストの問題です。片方ばかり集中して使っていると、そちらのトークンを食いつぶしてしまうから、ほかのものにもやらせる。コンテキストの中に余計なものが入るとメインの話ができなくなるから、分ける。そうやって、サブエージェント、別セッションのClaude Code、そもそもCodexにする、といったものを使い分けています。
コンテキストを守り、得意なことで使い分ける
――松竹さんは、どんな使い方をしていますか？
松竹：大杉さんとだいたい同じです。Claude CodeにもCodexにもサブエージェントの機能があるので、その中で閉じた形でやるだけでも十分効果があります。Claude CodeからCodexを呼び出すようなことは、必ずしもしなくていい。
ただ、最近はエージェントそれぞれに特徴があるんですよね。Codexは堅めで、依頼されたことから外れるようなことはあまりしない。Claude Codeは少し外れ気味なことをしますが、ちょっと突飛なことをしてブレイクスルーになったりする。ものによって頼んだほうがいい相手が変わるので、そこで分けることもあります。それは大元の依頼をするときに決めることで、サブエージェントではあまり意識していません。
僕も大杉さんと同じように、コンテキストをたくさん使わないために分けています。コーディングするときは、まずプランをしっかり考えてもらって、そのプランを小分けにしてサブエージェントに頼みます。
ただ、サブエージェントから返ってきた結果が、頼んだ指示どおりにできているかをチェックしないと、けっこうずれることがあるんです。今までは大元のエージェントで全部やっていたので早めに終わっていたけれど、作業を分けて、チェックを入れると作業時間が伸びることがある。だから、できるだけ並列にするようにしないと、今までと同じ感覚では使えません。でも、クオリティは上がっていると感じています。
――「並列に使う」というのは、実装が決まって、タスクA、B、Cがあったら、それぞれを別のエージェントに同時に頼むようなイメージですか？
松竹：そうです。そのときはサブエージェントを3つ同時に起動させます。
「Execute an Implementation Plan」というスキルを作ってあって、プランを作るときに、並列にできそうなものは一緒に頼めるようなプランにしてもらいます。そのプランを読ませると、エージェントが「じゃあサブエージェントを3つ立てるね」という感じで勝手に動きます。
大杉：スキルにしなくても、毎回プロンプトで「これとこれとこれを調査したいから、3つに分けてサブエージェントに調査させて」と言えば、そのようにやってくれます。
松竹：そうですね。はじめはプロンプトで試してみて、うまくいったら、毎回打つのが面倒だと思った時点で、今やったことをスキル化する。それが一番わかりやすいと思います。
あとは、コンテキストを抑えるためではなく、CodexとClaude Codeの2つに同じことをリサーチさせて、結果を突き合わせてリサーチの品質を上げる使い方もします。同じことを頼んでも探索の仕方が違うので、違う事実を持ってきたりするんです。
コンパクションに任せず、早めに引き継ぐ
コンテキストの使い方の話から、会話を要約して空きを作る「compaction（コンパクション）」の話題にもなりました。
OpenAIも、GPT-5.6の開発者向けガイドで、長い会話をコンパクションで圧縮することで、以前の文脈を再構築せずに、長期の作業でも一貫性を保てると説明しています。「Codexのコンパクションはいい感じにやってくれて、あまり忘れない気がします」（松竹）という感触には、中村も同意していました。
一方、Claude Codeについては、コンパクションに任せずに自分から区切るという声が出ました。「Codexでも多少は忘れるけれど、自分のトランスクリプトを見せて『思い出せ』と言えばなんとかなる。Claude Codeは忘れるだけでなく、話をまったく変えてくるくらいの勢いで変わる」（大杉）ため、大杉はClaude Codeではコンパクションを使わないそうです。中村も、コンテキストを10％使った時点でもうクリアの準備を始め、20％ほど使ったところで区切るといいます。
引き継ぐときは、大杉は前のトランスクリプトから自分の発言だけを抜き出して新しいセッションに読ませています。そのほうが、話の流れを正確に把握してくれるそうです。
レビューは別のエージェントに任せる
――2つのエージェントの結果を突き合わせるのは、レビューでも使えそうですね。
中村：僕もデュアルレビューのようなスキルを作ってあって、2つのエージェントにレビューを頼んで、返ってきたものを合わせて考える、ということをしています。
松竹：そうですね。今までは、実装した後に同じエージェントにレビューさせていたんですけど、それだとすごく忖度しちゃう。今は、レビューするときは完全にサブエージェントに、情報をなるべく与えずにさせています。そうしたら、今まで上がってこなかった指摘が上がるようになりました。
なるべくコンテキストを渡さないほうがいい場合もあるので、そこは意識して使い分けないと、もったいないと思います。
中村：レビューは、コンテキストを持っていないエージェントにやらせたほうが優秀ですよね。安く済むし、視点も新しい。
指示役と実行役を分ける
――レビューだけでなく、指示する側と作業する側でエージェントを分けるということはどうでしょうか。
中村：僕は最初はClaude Codeばかりに頼んでいて、Codexのトークンがずっと余っていたんです。Codexを直接使うのは切り替えが面倒なので、Claude CodeからCodexを使ってもらうようにしました。Claude Codeは安いプランで使っているので、トークンを節約したいというのもあります。
「指示する側」という意味では、普段エージェントを使って作業していて、人間が大変だと思うことの1つが、プロンプトを考えることだと思っているんですね。この「指示」をAIにやらせたい。
なので、僕はいつも「ディレクター」と呼んでいるエージェントを1つ置いて、そこから実作業をするエージェントに投げる形を必ず取っています。ユーザーがすごく雑に投げても、ディレクターが人間とやり取りしてヒアリングしてくれて、より効果的なプロンプトを書いてCodexに依頼し、実装してくれる、という形です。
――そのディレクターというのは、CLAUDE.mdに書いておくということですか？
中村：CLAUDE.mdには入っていなくて、スキルの中に入っています。「/codex-director」というスキルを作ってあって、それを呼んだときは、Claude Codeがディレクターの役割を取るようにしています。スキルを呼んで話しかけると、プロンプトを書くのに必要な情報を持っていなければ、人間に質問してくる形です。
3人それぞれの環境
――複数のエージェントを使うとき、このメンバーは全員、使っているツールが違いますよね。松竹さんは最近はPaseoで、中村さんはGhosttyでherdr、大杉さんはiTerm2とtmuxを使っていると、事前に聞きました。ちょっと各自、どんな感じで使っているか説明してもらえますか。
補足：関連記事
環境変化は現在進行形
このあとに続く各人の環境は座談会当時のものです。みなさんいろいろと試されているようで、記事の配信時には、すでに違うものを試している人もいました。
松竹：Paseoで工程ごとに分ける
松竹：Paseoにもう全部統合しています。デーモンが動いていて、そのデーモンにローカルからもリモートからもすぐにつなげられるので、外からでも同じように指示できます。herdrやtmuxのようなCLIではなく、完全にチャット風のUIです。
Paseoはちょっと特殊で、CodexとClaude Codeはネイティブでサブエージェントに対応していますが、Paseoも別にサブエージェントのような仕組みを持っています。たとえばClaude CodeからCodexに投げて、ここにためておけたりもするので、マルチエージェントが気軽にできるようになっています。今まで僕が頑張って作ろうとしていたことが、これでできるから、これでいいやという感じです。
――実際の作業は、どのように進めているのでしょうか？
松竹：こんな感じです。
調査：Explorerが調査して、その結果をもとに質問を1個ずつ投げてくるので答えていく。質問の内容がわからないときは、深掘りするようにしているが、端折りがちなので、「質問するときはなるべく詳細に書く」という指示も最近追加した。最終的に「こういう設計でいいよね」と確認させるようにしている。
スペック作成：別のエージェントに投げて、スペック、つまり要求仕様をMarkdownで書いてもらう。実装の詳細は書かず、何をするべきかだけを書いたもの。この流れはスキルに書いてあって、ベースにしているのはSuperpowers。
実装プラン作成：スペックを読みながら実装のプランを書いてもらう。書いた後にレビューを回して、指摘があれば直す。エージェント側が「もうレビューの指摘はない」となった時点でプランの完成となる。
実装：実装プランをマルチエージェント・デベロップメントというスキルに渡す。このスキルがタスクの依存関係を見て、サブエージェントに分けて並列で実装するか、このセッションのまま直列で実装するかを判断する。依存し合うタスクが多いのにサブエージェントに分けると、立ち上がっているのに待っているだけのエージェントが出てきてかえって時間がかかる。判断させることが必要。
- 検証：実装が終わったら、必ず検証を始めることもスキルに組み込んである。さっきの指示書どおりに実装されているかを検証して、いったん終わり。
検証まで終わったらそのあとに僕がチェックして、「ここ直ってないやん」とやり取りします。なので、こうした会話はどうしても長くなるんですけど。
こうして、作業ごとにコンテキストを切って渡しています。並列ではなく、縦にも分割して複数のエージェントを使っている形ですね。
中村：herdrにディレクターを置く
中村：僕はPaseoに似たツールのOrcaに移りたいかなという気持ちもあるので、今はどちらでも使えるようにスキルを調整しながら、併用していろいろ試しています。
herdrでは画面を上下のパネルに分けていて、上のパネルがメインです。ここで開いているのは記事にも書いたナレッジのリポジトリで、常にナレッジへの追加候補が登録されています。
補足：関連記事
ちょっとした作業なら、ディレクターが自分でやってもいいことにしています。あまりに小さい作業だと、依頼するよりそのほうが早い。本当に現実の仕事みたいです（笑）。
たとえば、候補の中から1つ追加してもらうように頼むと、ディレクターは、どういう理由でこれを選んだか、ということも書いたうえで依頼文を書きます。プロンプトのコツみたいなものは世の中でいろいろ流れてきますが、そんなのは覚えていられないので、このディレクタースキルの中に仕込んであるんです。僕より圧倒的にうまいプロンプトが書かれます。
herdrは隣のパネルを操作できるので、ディレクターが書いたプロンプトを、下のパネルの作業役に入力してくれます。その間、上のディレクターはちゃんと待機しています。ワークスペースは分けていないので、同じリポジトリを見ながら2人で作業している状態ですね。同時に作業はしていません。下のパネルで動いているのはClaude CodeではなくCodexです。
作業が終わると自動的に上のディレクターが動き始めて、何か違ったら、そのまま差し戻します。依頼どおりにできているかをチェックして、差し戻すときは、また新しいプロンプトが下に飛んでいきます。
この作業って、本来は人がやっていたじゃないですか。プロンプトを考えて、上がってきたら見て、全然できてないじゃん、と返して。それを、ディレクターと作業役のやり取りで自動にしているだけです。指示役と実行役を分けることで、その2人が「できたぞ」というところまではやってくれる。
――完全に役割が分かれているんですね。
中村：そうですね。コンテキストが大きいのがOpusなので、そちらに全体を把握する役割をやらせています。きちっと指示すると、そのとおりにカチッとやろうとするのがCodex系かなと思うので、作業はそちらにやらせている。安いからというのもあります。
合格すると、パネルも閉じてくれます。何を変えたか、その結果はどうだったかを報告してくれるので、僕が打つプロンプトの量はものすごく減っていると思います。
あと、herdrのサイドバーには今起動しているエージェントが並ぶので、大杉さんの状況表示（編集部注：このあと紹介します）を参考に、それぞれが今何をしているかを出すようにしました。CLIだと、こういう変更がしやすいのがいいですね。公式にサマリを出すドキュメントがあったので、それに従っただけですけど。
大杉：tmuxとIssueで状態を管理する
大杉：僕は全部ターミナルでやっています。せるさんやきょうすけさん（中村）が言っていたような細かく作り込むところまでやりたいけれど、自分で全部やろうとしているがゆえに、手が回っていない感じです（笑）。
やっていることは同じようなものですが、tmuxの機能で、状況を表示するモニターのようなものを作っています。ディレクター役のエージェントがIssueを作って、作業役のエージェントを立ち上げてアサインする。ユーザー確認が必要なものもIssueにしてユーザーにアサイン。確認したらディレクターにアサインを付け返すと、通知がディレクター役に飛んで、その通知を受けてまた割り振りを始める、という仕組みです。
下はClaude CodeのUIで、上のペインにはNode.jsなどのスクリプトを走らせて、集計して表示しています。上のペインの右側にはIssueリストが並んでいて、選んでVimで開いて確認や編集ができるようにしています。
僕はずっとGitHub Projectsのボードなり、Issueなりで管理してきたので、やっていることが全部Issueの状態になっているのが一番見やすいんです。
これからは、どうやって判断して渡すのか、そもそもどういう判断でIssueを分けるのか、といった判断用のスキルをいっぱい作っていかないといけない。今は、とりあえずこの形を作ってみたかった、という状態です。作り切れたら、今まで自分がディレクターとしてやってきたことを全部任せられるので、そうなればいいなとは思っていますが、先は長いというのが現状です。
――それぞれの環境とその作業イメージがつかめました。次回は、作業に合わせたモデルの割り当て方や、同じリポジトリで並行して作業するときの工夫、実際にうまくいかなかった話など、複数エージェントをうまく回すためのコツについてお聞きします。
（後編に続く）