複数エージェントをうまく回すコツと失敗談

中村 享介（モダンフロントエンド・エンジニア、ピクセルグリッド代表）

大杉 充（シニアディレクター）

松竹 誠（フロントエンド・エンジニア）

松竹：そこは今いろいろ変えているところです。Paseoではエージェントのプロファイルを定義できます。考えることをメインにする「Think」というプロファイルでは、今はClaude Opus 5をハイエフォートで使っています。スペックを考えるような普通の作業は、GPT-5.6のLunaをMAXで動かします。ある程度やらせた後で、レビューは頭のいいThinkのほうでもう一度チェックしてもらう。ちょっとした作業はなるべく速いモデルに任せて、難しい作業は頭がいいけれど遅いモデルに分けるようにしています。

松竹：そうです。スペック用にはこの設定にしたい、というように細かく用意しておいて、スキルに「このプロファイルを呼び出して」と書いておけば、それで呼んでくれます。

中村：僕は同じことを、スキルの中でやっています。こういう作業だったらこのモデルを使う、というのを全部用意しています。結局プロファイルと同じ感じですよね。難易度に応じて上げたり下げたりできるようにして、いくつかピックアップした中から選んでもらう。上のほうのモデルを使うときはユーザーの許可が必要、というふうにしています。

松竹：僕も最初はそうしていたんですけど、モデルを入れ替えたいと思ったときに、スキルを書き直すのかと思って。それは面倒なので分離して、スキルにはプロファイルの名前だけを書くようにしました。

モデルはけっこう真面目に見て、変えていかないといけないんですよね。新しいモデルが出たら、すぐ試して変えるくらいのことをしないと。勝手にやってしまう率が上がっている、といったことを調べて、切り替えるかどうかを決めています。

ベンチマークも少し見ています。いろいろなモデルに同じ開発タスクを解かせて、結果を出してくれている人たちがいるんです。見ると、Lunaは安いわりにいいスコアを出していて、MAXまで上げるとこんなに変わるのか、というのがなんとなくわかる。それで、LunaはもうMAX常用でいいんじゃないか、と判断しました。Sonnetは、このベンチマークだと50％ぐらいしか出ていないので、Lunaを少し頑張らせたほうがコストをすごく安くできる。じゃあSonnetじゃなくてLunaにしよう、と。

ただ、これはあくまで1つの指標で、タスクによって評価も違ってくるので、参考程度です。新しいモデルを全部自分で試すわけにもいかないので、そういうことはAIを研究している人たちに任せていいかなと。

大杉：僕の場合、Slackを探索させるのはSonnet、というところが残っています。AnthropicのSlackのツールはClaudeに組み込みであるんですけど、Codexのほうはサードパーティーのものを挟まないと難しそうで、ぱっと用意できなかったんです。Lunaのほうが全然よさそうなので、全部Lunaで回したいぐらいには思っていますが、そういう理由でSonnetが残っています。

中村：放置してできるんだったら、時間がかかろうが、並行だろうが直列だろうが、あまり関係ないんですよね。でも、エージェントはすぐ「時間がかかるから、この手はやめたほうがいいです」と言い始める。その見積もりも間違っていたりします。コストとして見るべきなのは、人間側が確認しないといけない工程がどれだけあるか、トークンやコンテキストをどのくらい使うかです。人間が作るときの時間で判断してしまうことがけっこうあったので、そうじゃないよ、というのはどこかに入れたと思います。

僕が最初に困ったのは、（Claudeの）Opusが（GPT-5.6の）Lunaに任せてくれなかったことです。使っていいエージェントを何種類か渡すと、何をゴールにしてもすぐ（GPT-5.6の）Solに頼む。どう見ても必要ないような作業も、ライバルだからか信用していないのか、「Lunaでは無理だと思うので」と、全然使ってくれませんでした。

しかも、1回でもSolでうまくいくと、ログが残るので、「過去にSolでうまくいったから」とSolを選びがちになるんです。そのあたりの条件付けをちゃんとしないと、トークンがすぐに溶けて、この構成で動かせなくなってしまうことがありました。

大杉：やっています。作業をさせている間に別のセッションを立ち上げて、全然別のものを並行して進める。これも複数エージェントといえばそうですよね。僕は作業ごとにMacのSpacesでウィンドウを割り当て、切り替えながら使っています。

松竹：同じリポジトリでやる場合は、実装がぶつかるので、必ずワークツリーを分けています。herdrを使っていたときもワークツリーを作っていましたが、Paseoは標準でワークツリーを分けられるので、その時点で新しく作っています。前回見せた流れでも、別のエージェントに渡すごとにワークツリーを作って、その中で作業したものをメインがマージする、という仕組みを組み込むこともできます。

大杉：2、3個が並行するのが通常になるのかなと思います。人間もそうだけど、あまりたくさんのことをやっていたら、ディレクター役がいっぱいいっぱいになっちゃうでしょう。

それこそAIだと、今度はコンテキストというものがあるから、並行して風呂敷を広げすぎると、1つのコンテキストに入るべき情報が薄く広くなって、できなくなったりする。だから上限として5ぐらいを目安にしていました。

中村：すごくわかるかもしれない。僕も今は、できる限り並列で動かさないようにしています。人間のほうがついていけなくなるから、1個のことに集中してやったほうが仕事が速いんですよね。

松竹：僕は、僕から依頼する分は3、4個まではやります。あとは、プランを作るときにどれだけ並行できるかを見ていますが、そちらは実装作業で僕は見ないので、特に上限は設けていません。ただ、そのおかげでトークンのほうがやばいですけど（笑）。

大杉：人間がAIと直接やり取りする部分は、僕はもう2つか3つが限界ですね。リポジトリが違う作業とか、かなり性質の違う作業で分けないと、似たような作業を2つのセッションにやらせていたら、どっちで何をやっていたんだっけ、どこまで進んだんだっけ、と全然わからなくなる。

中村：そうそう。わからなくなるからClaudeに「これ何やってたっけ」と聞くと、それこそトークンの無駄だなと。

大杉：そういうこともあって、全部の状態を一緒にして見えるようにしたくて作ったんです（編集部注：大杉はターミナルで作業していますが、状況を表示するモニターのようなものを作っていると前編で話していました）。

松竹：僕は、最初のスキル、つまり前回見せた質問に答えていくブレストだけはちゃんと集中して見ていて、あとは流れに沿って実行して、たまに見て止まっていないかをチェックするだけです。だから、同時に4つというより、順次4つに投げていく感じですね。朝に1個目を起動して、ブレストが終わったらもう1個起動する。待ち時間の間に、どんどんタスクを追加していっています。一時期、本当に同時並行でやっていたときは、頭がパンクしそうになりました。

大杉：これはプロンプト自体の話になっちゃうけど、何かしら作業をしていたら、エージェントが判断を間違えることは絶対にあるじゃないですか。それを作業しているエージェントに直接「なんでこうなってるの？」と質問すると、指摘と捉えて直しちゃうんですよ。先にこういう仕様があるからこうしてある、といったことも細かく把握していなかったりするので、何があったかわからないまま直される。「ちょっと待て待て、直せって話じゃない」ということになっちゃいます。

だから、別の新しいエージェントを立てて、「こっちでこういうことをしているんだけど、ここってなんでなの？」と質問して、最終的な修正内容が上がってから元のエージェントに渡す。そうすると、他人のものだから自分が責められていると思わないのか、うまく回ります。

中村：誤解されないように「質問なんだけど」とか「教えて」と付けると作業はしないので、ちょっとした言い回しでコントロールできる気はしています。

あと、最初のころは「どういうときにサブエージェントを起動しないか」をあまり書いていなかったんです。そうすると、すぐわかるような質問でも、Lunaを起動して調査させるようになってしまった。今は止めるように調整しています。

松竹：僕は、細かく分けて実装した後にレビューする、ということをしています。そのレビューが、プランに設定してある以外のこともレビューしだして、終わらなくなったことがあります。見に行ったら15ターンもやっていて、タスクの半分も終わらないまま、4時間近くレビューしていたこともありました。

それで、スキルに「書いてないことはレビューするな」「スコープを逸脱してはダメ」と追加しました。指摘することがないと、頑張って指摘することを探したりしちゃうんですよね。

コンパクションがいつの間にか起きたときも、そういうことになりがちです。だから、してはいけないことは、ちゃんと書いておかないとダメですね。

中村：僕も、レビューのところに「差し戻し上限2回まで目安」って書いてあります。無限ループしないようにだけは気を使っています。

松竹：僕も初めはそうしていたんですけど、改良したときに回数制限が漏れていたらしくて、ずっと回っていました（笑）。本当にコードですら、ひたすら重箱の隅みたいなのを見つけ出して直しますよね。

大杉：変数をどう切るかとか、どういう順番で書くかとか、下手したら関数の名前の付け方まで書いておく必要がある場合も（笑）。100％の正解があるとは限らないですから。

松竹：規約があればいいように思うけれど、その規約が「果たしていいのか？」とか言い出しますからね、あいつら（笑）。

中村：そう、規約に問題があるのではないか、というところからレビューしたりします。

大杉：マジか、規約からレビューしてくれるのか。いいなそれ。むしろ俺がずっとそれ言ってるわ（笑）。

何か一言言ったら、無理やり全部やろうとするようになっているんでしょうね。さっきの、質問したら修正しようとするのもそうだし、レビューしてと言われたら、なくても無理やり出すのもそう。曖昧なことを言って頼んだら、先に質問しておけばよかったんじゃないか、というところまで勝手にやっちゃったりする。入力があったら成果を出す、というふうに働いているからなのかなと思います。

中村：ただ、ディレクターだぞ、と役割を与えていると、意外にやらなくなりました。僕のディレクターは委任するのが仕事になっているから、すぐ委任しようとする。そこで、ルールを固めないと委任できない、とすると、足りない部分を聞いてくる。けっこううまく動いてくれている印象です。

大杉：基本的には危ないことを止める形を作っていれば、トークンが無駄になったぐらいしか失敗は起きないはずです。そのあたりはCodexのほうが、サンドボックスか何かで余計なディレクトリまで行かないようになっていて、安全に倒されている気がします。

松竹：ただその制限が強すぎて、困るってことは経験しました。調査なのに「インターネットには接続できません」とか（笑）。

大杉：Claude Codeも、起動するときのオプションで、どのツールを使っていいかを指定できるから、ディレクター役のClaudeから子のエージェントを立ち上げさせるときにも、オプションで指定させることで、調査だったら読み込みしか渡さない、というように制限はできますね。

中村：その制限が厳しすぎて、ディレクターがそれを工夫して使おうとしていたことがあります。テストは自分で実行するとか、そういう状態で実装させようとしていた。それだとCodex側の性能が全然発揮できなくなるので、緩めるように調整しました。

大杉：できるはずなのに、自分でかけている制限のせいでできない、とか言い始めたりする（笑）。

松竹：自分で回避しようとしだしたり（笑）。そういうのは、たまにチェックしないとですね。変なふうに覚えちゃうんですよね。

中村：そう。こうやったら回避できる、と覚えて、それをメモしていっちゃうので。

中村：そうですね、主従を決めておく、というのはあるかもしれません。これがないと、さっき言ったような、ずっとレビューが続いたりするんですよ。GPT系のモデルは粗を探し出すのが得意なので、上限を設けずにレビューさせると、自分のものだって永遠にやっているんですよね。

松竹：たぶん、指示がめちゃくちゃ強く効いちゃうんですよ。

大杉：そのわりに網羅性は疑問で、「ありません」と言った後に「本当に？」と言っただけで、まだありました、といっぱい出てくる。だから、機械で回せるチェックは機械にやらせ、AIによるチェックもやらせるけど何回までとか、そういうのを作ったりしています。

たとえば、textlintでの機械的なチェックはサブエージェントにやらせて、その結果をメインに返す。textlintで見られない文脈によるものは、通読チェックのようなスキルで、また別のサブエージェントなり高いモデルのエージェントなりにやらせてメインに返す。それを突き合わせて修正する、という感じにしています。でも結局、最終的な確認は人間がするしかないですよね。

松竹：僕も、実装ごとにプランのとおりに実装されているかを見て、最終的にもブランチごとにレビューをさせる、というように多重にレビューしています。主従というより、仕組みに沿ってしか動かせないようにしていますね。

大杉：探索系をサブエージェントなりほかのエージェントなりにやらせるのは、簡単だと思います。レビューだと、どこまで見るかといった判断軸が必要になってくる。

中村：別に探索に限る必要はなくて、実行役と指示役を分けるだけでいいと思いますけどね。それはコードを書く場合でも、バグを調べる場合でも一緒だと思うんです。

松竹：きょうすけさん（中村）が言っていたように、プロンプトを作るのをお願いして、指示役と実行役を分ける。指示役に「こういうバグがあるので調査してほしい。サブエージェントを起動して何々してください」と言うだけで、調査方法をどうしたらいいかまでプロンプトを書いて、実行させてくれるじゃないですか。指示役に実行をお願いするだけで、クオリティも上がると思うんですよね。

中村：すごく楽になるけど、自分がバカになるかもしれない（笑）。

中村：それはそうだし、そこにベストプラクティスみたいなものもいっぱい詰め込めますから。プロンプトは、ここが定義されていないとうまく動けない、というポイントがありますよね。

僕のスキルには目的や制約が書いてありますけど、何をすれば合格なのか、どうやって判定するのか、というのを自分でプロンプトで考えるのは難しすぎると思うんです。調査するといっても、何をしたら完了なのか。そのゴールをうまく決めてもらえると、この目的だったらここまでわかればいいよね、というところを定義してくれるので。

あと単純に、Claude CodeとCodexの2種類を同時に使うのは、楽しいからやってみたらいいんじゃないかなと思いますね。

松竹：そうですね。いつも違った感じの答えが返ってくると思います。

中村：最近、僕の試しているOrcaやせるさん（松竹）の使っているPaseoのように、ADE（Agentic Development Environment）と呼ばれる、複数のエージェントを動かしたり、状況を確認したりしやすい環境が増えています。そういった環境は1つのエージェントでももちろん便利ですが、今回話したようなエージェントがエージェントに指示するような環境だとより便利だと思うので、なにかしらのツールを試してみるといいかもしれません。

大杉：座談会で紹介したディレクターとIssue管理のようなことがもっと正確で臨機応変にできるようになれば、「自分がもうひとり」に近づけそうだから、うまく落とし込みたいです。自分の設定ではまだまだ、クリフトがデスピサロにザラキ連発してるレベルとそんな変わらない感（編集部注：ファミコン版『ドラゴンクエストIV』の有名なネタだそうです）。

松竹：複数エージェントの使い分けは、役割で分けるのがわかりやすいですが、できるだけトークンを使いすぎないようにしてあげるのも重要なことです。まずは調査タスクなどを任せるようにして、サブエージェントにどんどん作業を委譲していくところから始めてみるとよいと思います。