「1エージェント1タスク」の前提が崩れつつある

数百ファイルに散らばった型エラーを直す。コーディング規約を全ファイルに適用する。セキュリティパッチをコードベース横断で展開する。

こういった作業を1つのClaudeセッションで順番にこなすのは、そもそも無理がある。コンテキストは溢れるし、時間もかかる。

claude_code_agent_farm（以下Agent Farm）は、この問題に対する直接的な回答だ。複数のClaude Codeエージェントをtmuxセッション上で並列起動し、コードベース全体のバグ修正やベストプラクティス適用を自動化するオーケストレーションフレームワーク。デフォルトで20エージェント、設定次第で最大50まで拡張できる。GitHub Starsは781（2026年4月13日時点）。作者はJeffrey Emanuel氏。

設計の骨格を押さえておく

アーキテクチャはシンプルに2スクリプト構成だ。

メインのclaude_code_agent_farm.pyがオーケストレーターで、tmuxセッションの作成・エージェントの起動停止・ハートビート監視・リアルタイムダッシュボード・HTMLレポート生成を担う。これが2,991行の単一ファイルに全機能を詰め込んだ設計になっている。pyproject.tomlでもpackages = ["claude_code_agent_farm.py"]として1ファイルをそのままパッケージ扱いにしている。

もう一方のview_agents.sh（130行）は表示専用のシェルラッパーで、グリッド表示・フォーカスモード・分割表示・直接アタッチの4モードを提供する。オーケストレーターとビューアーを分離したことで、ヘッドレス実行や既存セッションへの後付け監視が可能になっている。

ロック機構も2層に分かれている。Pythonコードで実装された起動時のファイルロック（~/.claude/.agent_farm_launch.lockへの排他的ファイル作成）と、プロンプトの指示文だけで動くLLMレベルの協調ロック。前者は確実性が要求される設定ファイル保護、後者は柔軟な協調制御——という使い分けが意図的に設計されている。

一番面白いのはここだ：コードを書かずに分散ロックを動かす

Agent Farmで最も注目すべきポイントは、マルチエージェント協調開発ワークフローの実装方法だ。

複数エージェントが同一リポジトリ上で協調開発するとき、ファイルの競合をどう防ぐかが課題になる。Agent Farmの答えは、/coordination/ディレクトリ以下にJSONファイル群（active_work_registry.json、completed_work_log.json、planned_work_queue.json、agent_locks/）を置き、エージェントが互いの作業状況を確認しながら動く分散ロック機構だ。

ここまでは普通の設計に聞こえる。面白いのはその実装方法で——Pythonコードとして一切実装されていない。プロンプトファイルに書かれた自然言語の指示文だけで、LLMが自律的にこのプロトコルを解釈・実行する。

READMEにはこう書かれている。

"No actual code is needed to effectuate the system; rather, the LLM (particularly Opus 4) is simply smart enough to understand and reliably implement the system autonomously"

「particularly Opus 4」と特定モデルを名指ししているのが正直で良い。これはトレードオフの裏返しだ。コードより柔軟な協調が実現できる一方、モデルの変更で挙動が変わりうる。モデルに依存したアーキテクチャ、という構造的なリスクを抱えている。

「LLMの自然言語理解を協調制御の実装手段として使う」という発想は、従来の並列処理フレームワークとは異質だ。実用上どこまで信頼できるかはケースバイケースだが、アプローチとして面白い。

3つのワークフローと重複排除の仕組み

提供されるワークフローは3種類。バグ修正・ベストプラクティス実装・マルチエージェント協調開発。

バグ修正ワークフローでは、mypyなど型チェッカーの出力をインプットとして各エージェントが並列にエラーを修正する。修正済みの問題には[COMPLETED]タグが付与され、他のエージェントが同じ問題に着手しない仕組みになっている。チャンクサイズはmax(10, total_lines / agents / 2)で動的に決まる。エージェント数を増やしても無駄な重複作業が起きない設計だ。

ベストプラクティス実装ワークフローでは、各エージェントが進捗追跡ドキュメント（@<STACK>_BEST_PRACTICES_IMPLEMENTATION_PROGRESS.md）に処理状況を記録しながら、未処理ファイルを順に消化していく。

設定テンプレートはconfigs/以下に30種類以上用意されており、Python・Next.js・Go・Rustといった言語だけでなく、Solana・Unreal Engine・Terraform・Kubernetesまでカバーしている。

実務で使うなら押さえておくべき点

いくつか留意が必要な点がある。

コスト。並列エージェントはそれぞれ独立したコンテキストウィンドウを持つ。20エージェント動かせばトークン消費も20倍方向に増える。まず3〜5エージェントで感触を掴んでからスケールさせるのが現実的だ。

起動間隔の制御。エージェントの起動間隔はデフォルト10秒で、成功時は半減・失敗時は最大60秒まで倍増する適応制御が入っている。これはAPIレートリミット対策ではなく、複数エージェントが同時起動したときにsettings.jsonが破壊される問題を防ぐための仕組みだ。

コンテキスト管理。長時間実行時のコンテキスト肥大化に対して閾値ベースの自動クリアが動く。手動でもCtrl+Rで全エージェントに/clearをブロードキャストできる。

自動復旧。--auto-restartを有効にすると、ハートビートが120秒以上更新されないエージェントを自動再起動する。再起動には指数バックオフが適用され、初回10秒から最大5分（min(300, 10 * (2 ** restart_count))）まで延長される。

ライセンスの罠。MITベースだが、OpenAI・Anthropicおよびその関連企業による利用を全面禁止する追加条項が含まれている。ベンチマークや機械学習パイプラインへの組み込みも対象になる。商用・研究目的で使う前にLICENSEファイルを必ず確認してほしい。

まとめ

Agent Farmが示しているのは、「AIエージェントをどう束ねるか」という問いへの一つの答えだ。

並列数・重複排除・自動復旧といった実務的な要素はきちんと作り込まれている。その上で「分散ロックをプロンプトだけで動かす」という設計判断が混在している。エンジニアリングとしての割り切りなのか、実験的な試みなのかは読む人によって評価が分かれると思うが、少なくとも「LLMに何をやらせるか」の境界線を意識的に引いた設計だとは言える。

大規模コードベースの一括改善を試みる前に、一度アーキテクチャだけでも読んでおく価値はある。