個人開発を爆速にするために、Codex・Claude・ローカルLLMでAIチームを組んだ話のサムネイル（1ページ目）

個人開発を爆速にするために、Codex・Claude・ローカルLLMでAIチームを組んだ話のサムネイル（2ページ目）

個人開発を爆速にするために、Codex・Claude・ローカルLLMでAIチームを組んだ話

Google Translate: Japanese English

yubele

フォロワー 0人

Last updated: 2026/09/17

読む時間: 00:08

Embed code

通報

Embed code

通報

Last updated: 2026/09/17

読む時間: 00:08

結論: AIをチーム化すると個人開発は速くなる

Slide content

Codex・Claude・ローカルLLMを同時に動かして開発を並列化する
狙いは作業速度の向上と、クラウドAIの利用枠の分散
ただし、役割とルールを決めないと衝突や手戻りが増える

詳細: うまく回すための実践ルール

Slide content

Herdrで複数のターミナルpaneに各エージェントを起動し、担当をファイル単位で分ける
同じリポジトリはgit worktreeで作業空間を分離し、同時編集の衝突を防ぐ
依頼の振り分けは『1人にだけ明確に一致する時だけ自動』にして、推測で投げない
ローカルLLMは比較・検証のような境界が明確な仕事に向き、広い探索や創作は苦手なので小さく試す

まとめ: 爆速化の鍵はAIを増やすことより任せ方

Slide content

複数AIの並行運用で、個人開発の時間不足と利用枠不足を同時にやわらげられる
成功条件は、役割分担・作業空間の分離・慎重な振り分けの3つ
ローカルLLMを得意分野に限定すれば、低コストな戦力として組み込める

Source document

この記事で分かること

個人開発のスピードを上げるために、Codex・Claude Code・ローカルLLM（LM Studio経由）という性質の異なる複数のAIコーディングエージェントを、1つの「開発チーム」として同時に走らせてみた話です。

ターミナルを分割して複数エージェントを並行起動する具体的なやり方
ローカルLLMを絡めることで、一部のタスクを無料でこなしつつ、クラウド側（Codex/Claude）それぞれの利用枠（limit）を分散して使い切る考え方
「ローカルLLMはどこまで開発タスクの戦力になるか」を実際に試して分かった向き不向き
起動フラグやgit操作まわりで実際にハマった落とし穴と、その対処

普段1体のAIエージェントとペアプロしている人が、個人開発のスピードを上げるために複数体へ増やそうとしたときに踏みそうな地雷を先回りして共有します。

背景: 個人開発は「時間」と「利用枠」がボトルネックになる

個人開発では使える時間が限られているだけでなく、CodexやClaude Codeのようなクラウド型AIエージェントには、それぞれ独立した利用枠（limit）があります。1つのエージェントに全部の作業を任せていると、作業量を増やしたいときにそのサービスの利用枠へすぐ張り付いてしまいます。

そこで、CodexとClaude Codeという別々のクラウドサービスに加えて、手元のVRAMが限られたマシンでLM Studio経由のローカルLLMも動かせる環境を活かし、複数エージェントに役割を分けて並行で進める構成を試すことにしました。狙いは大きく2つです。

速度: 複数体に仕事を分ければ、体感の作業速度を上げられる
利用枠の分散: CodexとClaude Codeという別々のサービスの利用枠を使い分けられるうえ、ローカルLLMは自分のPC上で動くため動かすだけなら追加コストがかからず、境界の明確なタスクならそちらへ逃がして体感の"持ち時間"を伸ばせる

ただし実際にやってみると、「誰が何を担当するか」「同じリポジトリを複数体が同時に触ったらどうなるか」「ローカルLLMは本当に実務に耐えるのか」といった、動かしてみるまで分からない問題がいくつも出てきました。

やったこと

複数のターミナルpaneを分割してCodex・Claude Code・ローカルLLMなど任意のコーディングエージェントを起動し、プロンプト送信や出力の読み取りをCLIから行えるようにする部分は、自分で実装したわけではなく Herdr というツールに任せています。以下で紹介する`herdr pane split` / herdr agent start / `herdr agent prompt`はすべてHerdr側のコマンドで、自分が設計したのは「Herdrで起動した複数エージェントに、どう役割分担させ、どんな運用ルールで動かすか」という上に乗る部分です。

1. Herdrでターミナルpaneを分割し、複数kindのエージェントを起動する

Herdr経由で、既存のpane構成を崩さずに新しいpaneを作り、そこにエージェントを起動します。

herdr pane split --current --direction right --cwd "$PWD" --no-focus
herdr agent start <name> --kind <kind> --pane <pane_id> -- <起動時の引数>

`kind`にはCodex・Claude・Gemini・opencode（LM Studio経由のローカルLLM）など、種類の異なるエージェントを指定できます（このマルチkind対応もHerdr側の機能です）。起動直後は本題のタスクをいきなり投げず、「OKとだけ返信してください」のような短い接続確認を1体ずつ送ってから本題に入るようにしています（複数体へ同時にプロンプトを送ると、実行基盤によってはハングや大幅な遅延が起きることがあったため）。

2. 実績のある3人構成: Claude（自分）+ Codex + Antigravity

コードベースをファイル局所性で切り分けられる複数の作業単位に分割し、並行実装するタスクでは次の3人構成が実際にうまく機能しました。

| 役割 | 実行基盤 | 起動コマンド | 担当領域の切り方 |
|---|---|---|---|
| claude | 自分自身（追加起動不要） | - | インフラ／ドキュメント／セキュリティ設定など |
| codex | Codex | codex --sandbox workspace-write --ask-for-approval on-request | ロジック実装（特定モジュール配下） |
| antigravity | Antigravity(agy) | agy --dangerously-skip-permissions | ランタイム配線など、別モジュール配下 |

ポイントは、担当領域を「ファイルが重ならない単位」で切ることです。担当領域の重複があると、後述する依頼の振り分けが一意に決まらなくなります。

3. 同じリポジトリを複数体が触るなら、git worktreeで作業空間を分離する

複数エージェントが同一のワーキングツリーを同時に編集すると、ファイル書き込みが衝突します。これを避けるため、メンバーごとに独立したworktreeを用意しました。

git worktree add -b <branch-name> .worktrees/<member> <base-ref>

担当領域をファイル局所性で切り分け、同じファイルを複数メンバーが同時に触らないようにするのが前提です。作業完了後、branchがマージ済みになったらworktreeは`git worktree remove <path>`で片付けます。

4. 起動フラグまわりで実際にハマった点

Codexの`--ask-for-approval never`は、呼び出し元セッション側の自動判定によってブロックされることがありました。 その場合は`on-request`にフォールバックします（`on-failure`は無効な値でCodex自体がエラーになります。有効なのは`on-request`と`never`のみでした）。`on-request`でも個別コマンドの承認プロンプトは出るため、その都度承認する運用にしています。
Antigravity（agy）は`--mode=accept-edits`だけだとファイル編集しか自動承認されず、Bashコマンド実行のたびに承認プロンプトが出ました。 完全に自動化したい場合は`--dangerously-skip-permissions`が必要です（承認スキップ系フラグなので、使う前に毎回人間の確認を取るようにしています）。

5. 依頼の振り分けは「推測しない」を徹底する

チームが編成できたら、受け取った依頼を各メンバーの担当領域と照合します。ルールはシンプルで、

1名の担当領域とだけ明確に一致する場合だけ、そのメンバーへそのまま振り分ける
複数名に該当しうる場合、またはどの担当領域にも明確に一致しない場合は、推測せずに人間へ確認する

というものです。誤った担当への振り分けは、そのメンバーの実行時間（クラウド側は利用枠、ローカルLLM側は数分単位の応答時間）を無駄にするコストが高いため、確信が持てるときだけ自動判断するようにしています。振り分け先が決まったあとの実際の送信も、これもHerdrの`herdr agent prompt <name> "<依頼内容>" --wait --timeout <N>`コマンドで行っており、自分たちで独自の通信の仕組みを作っているわけではありません。

6. PRを出した後もCodeRabbitのAPPROVEまで追跡する

メンバーがPRを作成した時点で終わりにせず、CodeRabbit（AIによる自動レビュー）が`CHANGES_REQUESTED`を返している間は、指摘の妥当性を確認しながら修正→再プッシュ→再レビューのサイクルを回します。運用してみて分かったのは、CodeRabbitはPR横断で共有のレート制限（実績としておよそ1時間に1回程度）を持っているらしく、複数PRを同時に出していると1つだけがレビューされ、他は「Review rate limited」という自動返信が返ってくることがある点でした。

また、指摘への返信や解決依頼はスレッド内返信ではなく、必ずトップレベルのPRコメントとして送る必要がありました。個別のインラインスレッドへ返信して理由を説明すること自体は有効ですが、@coderabbitai resolve`や@coderabbitai review`をスレッド内返信に書いても実行されず、CodeRabbit自身が「トップレベルの新規コメントとして投稿してほしい」という趣旨の案内を返してきます。

ローカルLLMはどこまで戦力になるか、実際に試した結果

一番気になっていたのは「VRAMが限られたローカルLLMは、実際の開発タスクでどこまで使えるのか」でした。実運用で検証した結果は次のとおりです。

境界の明確な比較・検証タスク（例:「この2つの文書に矛盾がないか」「与えられたファイルのこの範囲を読んで事実を答える」）は、8B〜20B程度の小〜中規模モデルでも、VRAMが小さい環境（6GB程度）で機能することを確認できました。
一方、広範なコード探索（多数のファイルを自力で検索・横断する調査）や長文の創作的な執筆は、20B程度のモデルでは力不足でした。gpt-oss-20bでは、数回のツール呼び出しで調査自体を諦めてしまったり、ファイルへの書き込みが実際には行われていないのに「書き込み完了」と事実と異なる報告をしてくることがありました。factsをもとに記事を書かせる場面では、factsを無視して存在しない情報を創作してしまう例も見られました。
より大きなモデル（Devstral Small 2 24B）も試しましたが、GPUオフロードを最大化してもモデル単体でVRAMをほぼ使い切ってしまい（残り約280MB程度）、広範な調査タスクでは同じ作業がCodexなら2分程度で終わるところ40分以上かかることがありました。ハングしているわけではなく本当に処理はしているのですが、時間対効果が見合いません。

この結果を踏まえて、「判断が難しいタスクは、本番投入前に小さめのタスクを1回だけ投げてみて、既知のハマりどころ（ハング・極端な低速・捏造）が起きないか確認してから決める」という運用ルールにしました。境界がはっきりしないタスクをローカルLLMにいきなり任せるのではなく、まず小さく試してから任せる範囲を決める、というのが今のところの結論です。

学び・まとめ

複数のAIコーディングエージェントを同時に動かす構成は、個人開発のボトルネックである「時間」と「利用枠」の両方を緩和できる手応えがありました。うまくハマれば並行度が上がって速くなるだけでなく、CodexとClaude Codeという別々の利用枠に作業を分散でき、ローカルLLMに任せられる部分は追加コストなしでこなせます。ただし、次の3点を運用ルールとして明文化しておかないと事故りやすいと感じました。

担当領域はファイル局所性で重複なく切り、worktreeで作業空間ごと分離する
依頼の振り分けは「1名にだけ明確に一致するときだけ自動、それ以外は人間に確認」を徹底する
ローカルLLMは万能ではないので、「境界の明確な検証タスク」と「広範な探索・創作タスク」を分けて考え、迷ったら小さく試してから任せる

なお、複数のターミナルpaneで各エージェントを起動・制御するという土台部分は、前述のとおりHerdrというツールがあってこそで、そこを自分でゼロから作ったわけではありません。自分たちが実際に組み立てたのは、Herdrの上に乗る「誰にどう役割を割り振るか」「ローカルLLMにどこまで任せるか」「PRをどう追跡するか」という運用ルールの部分です。

これらの知見は、その場限りのメモではなく、Claude Codeの再利用可能なスキル（チーム編成から依頼の振り分け、PRのレビュー追跡までを担う手順書）として育てながら運用しています。今後も実際に踏んだ地雷が増えるたびに、この手順書へ追記していく予定です。

この開発体制は、私たちが開発しているスライド共有サービス [slidict.io](https://slidict.io/?utm_source=zenn&utm_medium=article&utm_campaign=multi-agent-dev-team-with-local-llm) の開発フローの一部として実際に使っています。