サブエージェントは作業をするためには使わないですね。分析するのが一番得意です。「テストカバレッジを評価して」とか「プロジェクトがスタイルガイドに従っているか確認して」とか。こうすることで、「メイン」のコンテキストにはレポートだけが届いて、大量のテスト出力や複数のファイルを読むスペースを無駄にしないです。

コードベースのリファクタリング能力はすぐにダメになります。まさにその通りです。Claudeにコードを一つのファイルから別のファイルに移動させようとしたんですが、いくつかのコードが消えちゃったり、途中で変更されちゃったりしました。人間はリファクタリングのための戦略を持っていて、「ファイルの先頭から始めて、移動させる必要のあるコードを切り取って、新しい場所に貼り付ける」とかやりますよね。でもLLMはクリップボードを持ってないから（まだ！）、これができないんです。Claudeは、開始ファイルと終了ファイルをコンテキストに保てる時だけ、信頼性のあるリファクタリングができます。これが大きなファイルだったので、情報が失われちゃったんです。それでも、直接の監視が必要です。

完全に同意します。いろんなことにエージェントを試してみました（エージェントのチームを作り始めたんです、アーキテクト、フロントエンドコーダー、バックエンドコーダー、QAなど）。失敗したプロジェクトに約50ドル使いましたが、コンテキストが汚染されて、結局プロジェクトを再作成しなければなりませんでした。それから、いくつかの部分をルールに移したり、スラッシュコマンドにしたりしたら、ずっと良い結果が出ました。サブエージェントはフリーランスの契約者みたいなもので（私も最近そうでした）、少ない引き継ぎ（リアルタイムでは不可能）や監視でうまくやれる時もあります。彼らの結果はアドバイスとしては良いけど、アクションにはならないです。彼らはあなたが何をしているか知らないし、彼らが出す情報で何をするかも気にしません。あなたが他のことをしている間に、彼らはあなたのために作業をしてくれるか、独立した結果を出すのを待っているだけです。彼らは既存の機能についての知識がほとんどなく、独立しては良い仕事をします。今、私がまだ持っているエージェントは3つと、現在作業中のものが1つあります。1: スキャフォールディング：今、私はたくさんの新しいプロジェクトを作ったり、時には壊したりしています。新しいことを試すときはスキャフォールディングエージェントを使います。彼らは「何をスキャフォールドするか」という一行の新しい指示から始まります（例：HonoとPostgres接続の新しいDockerコンテナ、R2、D1、AI Gatewayに接続する新しいCloudflareワーカー、またはSQSを使ったAWSサーバーレスAPIゲートウェイなど）。プロジェクトの構造を整え、GitHubリポジトリを作成してコミットしてくれます。私はそこから進めます。2: トリアージ：コードを読むだけでは明らかでない問題に直面したとき、場所といくつかのログを渡すと、エージェントは利用可能なもの（DBデータを含む）を使って、なぜその問題が発生するのかを最善の推測をしてくれます。最近の作業にバイアスされていないときに最も効果的に働くことが多いです。3: プレリリースチェックQA：このQAはシステム全体をテストします（基本的にすべての統合テストとエンドツーエンドテストスイートを呼び出して、この製品が既存のものを壊さないことを確認します）。今、私は彼らに元のビジネス要件を見せて、コードがそれを満たしているかどうかを確認する機能を追加しています。このエージェントには、何かをリリースパイプラインに進めるかどうかを決める手助けをしてもらいたいです。4: ウェブ検索（実験的）：時々、既存のトークンでは検索が高コストすぎて、私たちが必要なのは最終結果だけで、彼らが検索した内容や見つけた10ページは必要ないことがあります…。

サブエージェントは同じシステムプロンプトを持っていると理解してたんだけど、どうやって彼らがCLAUDE.mdの指示に従わないってわかるの？サブエージェントが導入されて以来使ってるけど、コンテキストのサイズや汚染を管理するのにすごく役立ってるよ。

これまでの経験として、CCを異なる戦略で軌道に乗せようとした結果、結局同じような失敗に陥ることが多いと感じてる。エージェントやワークフローを定義しても、今はただGitHubのイシューとやり取りさせてるけど、品質はほとんど変わらないね。

まずは計画モードに入れる筋肉記憶を身につけるように訓練してるんだ。そっから何をするか教える感じで。

俺はほぼいつも、（ライブラリ名）LLM.txtをコンテキストとして添付するか、（フレームワーク機能）のドキュメントページへの直接リンクを貼ってる。あんまりエージェント的じゃないけど、ずっと効果的だよ。

すごいことをやってるのを見たことがあるよ。一発で、独自のバックオフィスシステムの修正、DBスキーマの更新、新しいAPIモデルの定義、バックエンドとフロントエンドの変更を含む機能を追加したこともある。逆に、検索結果のカウントを追加するだけでつまずいてるのも見たことがある。短く言うと、試させるのは安上がりだよ。

Claudeは知識のカットオフのせいで、最新バージョンにはいつも少し遅れを取ってるんだ。それに、君が言ってるi18nライブラリも知ってるけど、それは多分正しい判断だったね。

私も今までの経験はそんな感じです。基本的なプロンプトだけで、これらの複雑な追加機能よりもずっと進むことができる気がします。どこかで立ち止まって、Claudeを管理するのにやりすぎているのではないかと考えなきゃいけない時が来ると思います。

そのコツは、エージェントの発見をまとめる合成ステップだと思います。少なくとも、私はそこで一番成功しています。

そうだね、役割ごとにサブエージェントを作るんじゃなくて、トークンが多いタスクのためにコンテキストを管理するためのものを作るべきだよ。バックエンド開発者のサブエージェントはまあまあ仕事をするけど、スーパーバイザーエージェントは何が行われたかの有用なコンテキストが欠けてしまって、うまくいかなくなる。理想的なサブエージェントは、シンプルな質問を受けて、大量のトークンを使って答えを出し、最終的にシンプルな答えだけ返すことができるものだね。その間のトークンは不要だからね。ドキュメント検索はいい例だよ。「XライブラリにはY関数があるの？」って質問に対して、サブエージェントがウェブを検索して、ドキュメントを読んで、スーパーバイザーがすべてのコンテキストに悩まされることなくシンプルな答えを返せるんだ。

いや、これが俺の経験でもあるよ。やるべきだって言ってる人はたくさんいるけど、実際には自分でやってないことが多い。あるいは、失敗したりスケールしたりしたときにどう対処するかの具体例を全然見せてくれない。だって、何もないときは、エージェントが適当なことをやっても問題ないからね。イライラするよ。

いや、みんなそのアイデアが好きで「エージェント」に関する盛り上がりのせいで遊んでるだけだと思うけど、個人的には必要ないと思うよ。

もう一つエージェントが欲しいな…

だんだんと、そして突然？不正確な推論や解決策への「修正」は、現在のインスタンスを解決するだけじゃなくて、将来使われるルールベースのシステムに繋がるんだよね。ループにいることが必要で、「ただ承認する」だけになったら、リラックスして振り返ることができるけど、最初は細かいタスクが必要だと思う。信頼性が高まると、タスクはもっと複雑になっていく。「並列化」することで、単一の（サブ）エージェントがアドホックな責任を持ちながら、別の「制度化された」コンテキストやルールに頼ることができる。例えば、アーキテクチャエージェントとコーダーエージェントが互いに話し合って、どちらが具体的なルールに基づいて決定を下しているのか、あるいは幻覚的な決定をしているのかに基づいて、決定の対立を解決できる。友達がルールベースのシステムを構築しているのを見て、LLMがそのコンテキスト内でどれだけうまく機能するかに感心したよ。

サブエージェントはいらないよ。これ、ClaudeCodeのサブにもシェアしたんだ。https://www.reddit.com/r/ClaudeCode/s/barbpBxG78 サブエージェントはコーディングには全然向いてない。

同意だね、役割は何か儀式的な感じがする。

ペルソナには懐疑的だけど、異なるタイプの作業のためにコンテキストや指示を整理するのには使ってる。トップレベルの.agentsディレクトリを使って、コマンドや役割、ルールをサブディレクトリに分けてる。CLAUDE.mdはちょっとスリムに保ってて、./docs/の個別ファイルへのポインタを持ってるし、.claude/commandsは.agents/commandsへのシンボリックリンクになってる。Claudeを起動した後、/commandsを使って役割とコンテキストを読み込むんだけど、必要なドキュメントだけを引っ張ってくるから、バックエンド機能を追加する時にUIデザインやテストアーキテクチャのドキュメントを読み込むことは避けられる。こんなことはやりたくないんだけど、エージェントを軌道に乗せて、コンテキストの劣化を最小限に抑えるのに役立ってる。

俺も部分的に懐疑的なのは、どのLLMでも生成される長いエッセイが好きじゃないから。CLAUDE.md/AGENTS.md/README.mdが5ページ以上あるのは、どれも同じくらいダメだと思う。何かが自分にとって有用な情報を得るには長すぎるなら、そのLLMも同じように振る舞うべきだと思ってる。たとえそれが真実じゃなくても、短い文で説明できることを2段落も使って説明するのは無駄だよね。俺のCLAUDE.mdやAGENTS.mdは、だいたい高レベルの情報を持った箇条書きのリストになってる。エージェントがもっと指示を必要とするなら、もっとリマインダーを追加するようにしてる。事前に計画なしにあまりにも広いタスクを与えないようにしてるけど、そうしないと脱線しちゃうから。実は、claudeにADRを生成させることはあまり試したことがないんだけど、あなたのRFC/アイデアみたいにやってみようと思ってる。 [1]: https://adr.github.io/

フロントエンド/バックエンドを意識したClaude Codeを自分の好きな形で動かすのに苦労してるんだ。つまり、親のエージェントと計画を立てて、何らかの形式でファイルを出力して、それをフロントエンドとバックエンドのClaudeにそれぞれ渡すってこと？でもその「サブクラウド」たちは他のリポジトリのコンテキストを持ってないってこと？

この概念は小説『Accelerando』に出てくるから、またAIファンがLARPしてるだけだと思うよ、今のLLMの盛り上がりと同じようにね。