AIエージェント
複数 AI エージェント運用が挫折する理由と、フォルダベースコンテキスト戦略
複数 AI エージェントのスケーリングが失敗する本当の理由は、エージェント間の自動協調を求めることにあり、正解はプロジェクトフォルダに蓄積したドキュメント・慣例・スキルをコンテキストとして活用し、汎用モデルを特定分野の専門家に変えることである。
原題
“The Folder Is the Agent” （フォルダはエージェントである）
原文からの引用
“I spent three months trying to make agent swarms work. But more agents didn't make me faster. 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個以上のエージェントを並列実行すると人間のマネージャーがボトルネックになることが判明した。
- プロジェクトフォルダ（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 エージェントだけを増やしても、専門性を欠いた汎用モデルが空回りするだけである。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。