AIエージェント
複数 AIエージェント運用が挫折する理由と、フォルダベースコンテキスト戦略
筆者は3か月のエージェントスワーム実験で、エージェントを増やしても速くならなかったと振り返り、プロジェクトフォルダに蓄積したドキュメント・慣例・スキルをコンテキストとして使い、汎用モデルを特定分野の専門家に変えることが答えだったと述べる。
原題
“The Folder Is the Agent” （フォルダはエージェントである）
原文からの引用
“I spent three months trying to make agent swarms work. The context that this folder gives an AI model makes the generalized model a specialist in whatever task or field you want it to excel in.”
日本語訳 エージェントスワームを機能させようと、3ヶ月を費やした。 フォルダが AI モデルに供給するコンテキストこそが、汎用モデルを任意の分野の専門家に変える。
要点
- 筆者は3ヶ月かけてエージェント「スワーム」（複数エージェントが互いに協調し、何をするかも自分たちで決める体制）を試したが、エージェントを増やしても速くならなかった。10個が同時に終わると、信頼できる結果を見分ける文脈がないまま10件の成果を評価することになり、エージェントに速度の上限はなくても、それを管理する人間にはある、と書いている。
- プロジェクトフォルダ（CLAUDE.md、ドキュメント、スキルから構成）にコンテキストが蓄積していれば、汎用言語モデルは特定分野の専門家に変身でき、筆者はこれをそのままエージェントと呼んでいる。
- Cora（Email Assistant）のプロジェクトでは、`~/cora/`（機能開発用）と`~/cora-agent/`（運用管理用）の2個のフォルダを運用し、同じモデルでも役割が異なるエージェントになる。
- Ruby daemon + ファイルベースのメッセージングによるディスパッチレイヤーで44個のフォルダエージェントを管理し、`/hey`（朝のブリーフ）と`/orchestrate`（タスク実行）の2コマンドが主な役割を担っている。
- スケール運用の前提条件は「フォルダを自分で検証する」フェーズであり、予め使いこなして信頼できてから初めてディスパッチレイヤーに預けることが重要である。
編集部の考察
同じ Opus 4.6 というモデルでも、`~/cora/` に向ければ Rails の規約を守るエンジニアになり、`~/cora-agent/` に向ければインシデント履歴とサービストポロジーを把握した運用エンジニアになる（要点3）――この事実が示すのは、専門性を生んでいるのはモデルの性能ではなく、フォルダに積み上がった CLAUDE.md・runbook・ポストモーテムだということだ。裏を返せば、専門性は個人やモデル単体に宿るものではなく、記録として持ち運び可能な資産だということになる。この見立てをそのまま組織に当てはめると、人材評価・育成の軸が変わってくる。「このエンジニアは運用に強い」という評価は、実は本人の暗黙知そのものではなく、彼が日々使っているデプロイ規約・runbook・過去のインシデント記録の質を測っているだけかもしれない。だとすれば育成投資の振り向け先は、個人向けのスキルアップ研修だけでなく、各役割が依拠する文脈資産をドキュメント化し、誰が担当しても再現できる状態に変換することにも回すべきだ。人が異動・退職してもフォルダという形で文脈資産が残っていれば、後任者も AIエージェントも同じ専門性を即座に引き継げる。決めるべきは、各役割の暗黙知をどこまで明文化された runbook・conventions・postmortem に変換するかという投資判断であり、これを怠ったまま AIエージェントだけを増やしても、専門性を欠いた汎用モデルが空回りするだけである。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。
この記事の調査と下書きにはAIを使っています。数値や事実は出典と照合し、公開するかどうかは運営者が判断しています。（制作方針）