LLM時代の個人開発、ボトルネックは“タスク生成”だった
はじめに
最近ずっと、LLM を使った並列開発に憧れていました。
サブエージェントを複数走らせて、worktree で隔離して、PR で整理してレビューを通してマージする。うまく回れば、かなり効率がよさそうに見えます。
実際、そういう構成を何度も考えては捨てました。サブエージェントの分担方法、PR の切り方、レビューの経路、統合のタイミング。一通り試したのですが、サブスク枠内で動かす個人開発という自分の文脈では、ほぼ採用に至りませんでした。
その過程で気づいたのは、「並列開発できないのが問題」ではなく、そもそも並列に積めるタスクが手元にない ことが問題だった、という話です。
この記事は、そのプロセスで得た気づきの記録です。同じ憧れと挫折を繰り返している個人開発者向けに書いています。
試したこと
具体的には、この辺りを行ったり来たりしていました。
- サブエージェントで実装を分担し、最後に親セッションでマージ
- worktree を複数切って、それぞれ別テーマを並列で実装
- まとまった変更を PR 経由にして、ローカルレビュー → マージ
- 自律エージェント運用（Issue を取りに行く、ラベルで進行を管理する、など）
どれも 1〜2 回は回りますが、続けるとだいたい同じところで詰まります。
前提: サブスクの枠内で完結させたい
並列開発を諦めた直接的な理由のひとつとして、API キー課金を使いたくない という前提があります。
Claude や ChatGPT のサブスクは月額固定で使える一方、GitHub Actions に組み込んで自動レビュー・自動マージ・自動修正を回そうとすると、従量課金の API キーを使うことになります。技術的にはできますが、月末の請求額が読みにくい状態を生活に持ち込みたくなかったので、この経路は取りませんでした。
API 課金を許容できるなら、話は別です。GitHub Actions で自動レビューを回し、複数 worktree で並列実装させ、合格したものだけマージするような構成は普通に成立すると思います。
この記事はあくまで、「サブスク枠の中で個人開発する」という前提での話です。
個人開発で PR 経由の並列はそこまで旨味がない
前提を脇に置いても、もうひとつ壁がありました。
PR を使う利点はあります。「いつ・何が・なぜ加わったか」がコミットだけより整理しやすい、というのは事実です。
ただ個人開発では、コードとプロダクトの責任を基本的に自分ひとりで引き受けます。PR を介在させる本来の理由である、他人にレビューしてもらう、合意を取る、CI を通す、といった要素の多くが、自分の中で完結しています。
そこに並列化を重ねると、worktree の進捗、PR のマージ順、コンフリクト解決、各実装の検証状況といった状態管理が増えます。実装そのものより、並列化のための認知コスト の方が重くなる感覚がありました。
レビュー対象としての PR ではなく、単に「区切りを作るための PR」になると、わざわざ PR にしている意味は薄い。コミットを丁寧に切る運用で、大半は足ります。
そもそも並列に積めるタスクが手元にない
さらに大きかったのは、並列で流せるだけのタスクが手元になかったことです。
粒度を切ったタスクであれば、LLMエージェント に渡せばかなり速く処理してくれます。自分が普段の個人開発で扱う範囲では、1 件ずつ直列で流しても十分追いつくことが多いです。
一方で、頭の中にあるアイデアの多くは、まだ実装に着手できる粒度まで噛み砕けていません。
- タスクとして言語化されていない
- 実装可能な大きさに分解されていない
- そもそも課題として発見されていない
- やるべきか捨てるべきか判断されていない
こういう状態のものが大量にあります。
つまり、並列に流せない以前に、直列に流すためのタスクもまだ十分に整っていない。実装の前段にある「何をやるか決める」「やらないことを捨てる」「実装可能な粒度に落とす」工程が詰まっていました。
ボトルネックは“タスク処理”ではなく“タスク生成”
LLM 時代の個人開発で本当に効くのは、「実装処理速度」を上げる工夫より、「タスク生成速度」を上げる工夫だと思います。
- 何をやるべきかを早く決める
- 何をやらないかを早く捨てる
- 思いつきを実装可能な粒度まで落とす
- LLM に渡せる状態まで整理する
実装処理は LLM がかなり肩代わりしてくれます。しかしその手前、どの方向に進めるか、どこまで作るか、どの単位で切るかは、まだ人間の判断負荷が支配的です。
ここを速くしないと、いくら LLM を並列に並べても食わせるものがありません。
「タスク生成がボトルネック」という話自体は昔からあります。ただ、LLM の実装速度が伸びたことで、相対的にここがかなり目立つようになった、というのが今の実感です。
実際にやっている対応
抽象論で終わると役に立たないので、現状の運用も書いておきます。目新しい内容はないかもしれませんが、参考になれば。
1. タスク処理側を単純化する
サブエージェント分担、worktree 並列、自律エージェント運用。どれも一度は組みましたが、今はかなり削りました。
理由はシンプルで、ボトルネックがタスク生成側にある以上、タスク処理側の効率をいくら上げても全体の進みはそれほど速くならないからです。
むしろ複雑な処理パイプラインは、
- モデルが進化するたびに陳腐化する
- 構築・保守に時間を取られる
- 動かなくなったときの原因切り分けが重い
という形で、保守コストが効率改善を食ってしまう場面が多くありました。
処理側を諦めた瞬間、構成はかなり単純になりました。
2. Ralph Loop ── 単純なローカルチケット駆動
代わりに採用したのが、Ralph Loop と呼ばれるシンプルな実行ループです。私が考案したものではなく、ググればいろいろな説明がヒットします。
私の運用の場合、実体は「プロンプト 1 枚 + チケット用ディレクトリ + シェルスクリプト」で、ディレクトリ構成は以下のようにしています。
docs/
tickets/ # 処理対象のチケット格納先
2026-05-13-xxx.md
2026-05-13-yyy.md
done/ # 完了したチケット移動先
2026-05-12-zzz.md
prompts/
ralph-loop.md
ralph-loop.sh
CHANGELOG.md
docs/product-map.md
docs/decisions.md
ループ 1 周でやることも単純です。
-
docs/tickets/
直下からチケットを 1 件選ぶ - チケットの受け入れ条件を満たす最小実装をする
- lint / test / build を通す
- 完了したチケットを
docs/tickets/done/
に移動する -
CHANGELOG.md
に「何を・なぜ・検証・残課題」を短く追記する -
Ralph: <概要>
のメッセージで 1 commit する
実行時は、普段使っている開発ブランチから Ralph Loop 用の worktree をひとつ切り、その中でシェルスクリプトを起動しています。スクリプト内部では
claude -pや
codex execに
prompts/ralph-loop.mdの内容を渡し、1 周ごとに「チケットを選ぶ → 実装する → 検証する → 完了処理する」までを LLM に実行させます。
メインの作業ツリーとは分けているので、ループ中に途中コミットや一時的な変更が発生しても、普段の作業場所には影響しません。最終的には人間が差分を確認し、必要なら開発ブランチへ取り込む、という運用にしています。
GitHub Issue、ラベル運用、WBS、自律エージェント、サブエージェント分担、worktree 並列。このループでは、基本的に使いません。LLM に任せるのは「1 チケット選んで実装して完了処理する」という小さな処理だけです。
チケット 1 枚は、LLM がそのファイルだけを読めば独立して着手できる程度にしています。背景・ゴール・スコープ・非ゴール・受け入れ条件・検証方法を最低限書き、人間側で「これは任せてよい」と判断したものだけを並べます。
ビルドやテストを通せず、エージェントが自力で解消できないものは
docs/tickets/blocked/に退避させます。人間判断が必要なものを通常のキューから外しておくことで、ループ全体がそこで止まらないようにしています。
3. タスク生成側に時間と頭を使う
処理側を単純化した分、人間が時間を使うのは以下です。
- product-map.md に未整理の思いつきや将来方向を置く
- そこから「次に実装すると決めたもの」をチケット化する
- 完了後の CHANGELOG.md を読んで現在地を確認する
- 別 LLM に CHANGELOG.md と product-map.md を渡して、次に潰すべき課題候補を出させる
- 出てきた候補を、自分の判断でチケットに落とすか捨てるか決める
主戦場は「何を作るか決める」「何を捨てるか決める」側です。ここを LLM に補助させつつ、最終判断は人間が行う流れにしています。
4. 判断と実装は時間帯を分ける
平日夜の頭で重い判断をすると精度が落ちます。そのため、チケット化や設計判断は週末にまとめて行い、平日夜は決まったチケットを Ralph Loop に流して実装に寄せています。
「夜に判断もしなければいけない」状態をなくすだけで、平日の着手率はかなり上がりました。
おわりに
「並列開発できたらかっこいい」という憧れから始めて、回り道した末に出た結論は、「タスクを作る方が遅いのだから、まずそちらを速くしよう」というシンプルな話でした。
並列開発が悪いという話ではありません。並列に積めるタスクが揃っていない状態で並列化を考えても効かない、という順序の話です。API 課金を許容できる人や、チームでタスク総量が常に多い文脈では、結論はまた違ってくると思います。
ただ少なくとも、サブスク枠で個人開発を回している今の自分の文脈では、LLM の実装速度が伸び続けるほど、ボトルネックは人間側の「何をやるか決める」工程に寄っていきます。
並列実装の構成を凝るより、自分の頭の中にある未整理のアイデアを言語化・分解する仕組みを整える方が、今は効いています。
同じところで詰まっている人の参考になれば幸いです。