Loop Engineering はソロプレナー的な新規プロダクトで最も効く — ゼロから立ち上げて全設計を自分が把握しているとき
前回、Hermes Agent 向けに omh-issue-loop という自律ループスキルを書きました（issue を投げると PR が返ってくる）。GitHub issue の URL を 1 本渡すと、実装を Codex CLI に、レビューと挙動検証を Claude Code CLI に委譲して、review-ready な PR を残して止まる仕組みです。
この「issue を投げて PR を受け取り、人間はマージ判断だけをする」開発スタイルは、世の中では Loop Engineering と呼ばれています。エージェントが実装と検証のループを回し、人間は plan と基盤と最終判断だけを担う、という分担の形です。
日々このループを回してみて、はっきり見えてきたことがあります。Loop Engineering は万能ではなく、効くリポジトリと効かないリポジトリが、想像以上にきれいに分かれるということです。そして、いちばんきれいに効くのが、ソロプレナー的な新規プロダクト、つまりゼロから立ち上げて自分が全設計を把握しているリポジトリです。
この記事は、なぜそこで効くのか、どこで効かなくなるのか、そしてソロプレナー的な新規プロダクトで Loop Engineering を回すために何を最初に用意すべきかを書きます。
Loop Engineering が求める 3 つの前提
前回の記事の後半で、人間の時間が「ループが回る開発基盤」と「issue の plan」に完全に移動した、と書きました。そこを裏返すと、この 2 つが弱いとループは回らない、という話でもあります。
もう少し分解すると、Loop Engineering が機能するためには、少なくとも次の 3 つの前提が要ります。
- 仕様を持っているのが誰かがはっきりしていて、その人が issue を書けること
- 検証基盤（テスト・型・lint・CI）が実際に壊れたときに落ちること
- マージ判断まで含めて意思決定が閉じていて、レビュアーと実装依頼者の温度感が揃っていること
3 つとも、ソロプレナー的な新規プロダクトなら自動的に満たされます。仕様を持っているのは自分、検証基盤を作るのも自分、マージするのも自分。判定の系統がすべて一人に閉じているので、系統のズレそのものが発生しません。
一方、これらの前提のどれかが崩れているリポジトリでは、ループを回しても、回っているように見えるだけで何も判定していない、という状態が起きます。
効かないリポジトリの典型
先に「効かない側」を整理しておきます。ここが見えていた方が、なぜソロプレナー的な新規プロダクトで効くのかが対比で分かりやすくなります。
既存の大きなコードベース
10 年動いているコードベースで Loop Engineering を回そうとすると、まず検証基盤の粗さで詰まります。テストは形だけ残っていて実際には壊れても落ちない、lint は一部のディレクトリでしか有効になっていない、型はあるが any で穴が空いている、といった状態です。
このとき、5 つのレビューゲートを通ったあとの PR は、ゲートを通ったという事実だけを保証します。「実際にリグレッションを起こしていない」ことは保証しません。検証基盤が判定していないものは、ゲートを何段重ねても判定できないからです。
このリポジトリで Loop Engineering を有効化する道はあります。ただし、まずやるべきは新しい issue を回すことではなく、検証基盤の底上げです。そちらの方が先に来る、という順序を間違えるとひどい目に遭います。
組織で意思決定が分散している場合
もうひとつ効きにくいのが、issue のスコープを最終確定できる人と、実装を依頼する人と、レビュアーと、マージする人がそれぞれ違う、というケースです。
Loop Engineering は issue を唯一の権威あるスコープとして扱います。issue に書いていないことは実装されないし、そこから外れる変更を検出したら止まります。この設計は、issue を書いた人と、成果物を受け取る人が同じであることを暗黙に仮定しています。
意思決定が分散していると、issue に書いた内容と、レビュアーの期待と、マージ判断者の判断基準が微妙にずれます。ゲートは通っているのに、レビュアーが「これは自分の想定と違う」と言い出す。この温度差を吸収する回路が、今の Loop Engineering にはありません。
もちろん、issue に至る前に十分に議論をして、書いた時点で全員の合意が取れているならこの限りではありません。ただ、そのぶん issue の作成コストは重くなるので、ループ全体の投資対効果は変わってきます。
検証基盤が壊れているのに見た目は動いているコードベース
いちばんたちが悪いのがこれです。テストは通る、lint は通る、CI は緑、でも本番でしか出ないバグを大量に抱えている、という状態のリポジトリでは、Loop Engineering は「動いていない検証を、動いていると信じ続ける」機械になります。
前回の記事でも「失敗したレビューをクリーンとみなさない」と書きましたが、そもそも失敗しない壊れ方をしている検証は、この規定でも救えません。ここは検証を直すところから始めないと、ループを回すほど誤った自信だけが積み上がります。
ソロプレナー的な新規プロダクトが特別なわけ
ここまでの裏返しとして、ソロプレナー的な新規プロダクトが Loop Engineering にとって特別なのは、次の 4 つが同時に成り立つからです。
1. 仕様の権威が一人に閉じている
ゼロから立ち上げているので、なぜこの機能が要るのか、どこまでがスコープでどこからが後回しか、代替案をなぜ採らなかったのかを、全部自分が知っています。issue を書くというのは、頭の中にある設計を外に出す作業になります。他人と合意を取る工程がないぶん、書くのは早い一方で、書かなかったことは絶対に伝わりません。
これは Loop Engineering ととても相性がいい構造です。エージェントに「自分の意図どおりに動いてほしい」と思うなら、自分の意図を issue にすべて書き出せる状態にあることが最短です。ソロプレナー的な新規プロダクトでは、この状態にコストなくたどり着けます。
2. 検証基盤を自分の意思だけで整えられる
新規プロダクトの初期は、テスト、型、lint、CI をどう組むかが完全に自分の裁量です。過去のしがらみもないし、他チームとの調整もいらない。テストの粒度、型の厳密さ、lint のルール、CI で落とす条件を、自分が判定してほしい水準で決められます。
Loop Engineering は、検証基盤が判定できる範囲までしかエージェントに任せられません。だからこそ、判定水準を自分で決められる時期に、その水準を高く設定できる余地があるのは大きな武器です。あとで水準を上げるのは、あとで型を厚くするのと同じで、何倍も面倒になります。
3. マージ判断まで含めて意思決定が閉じている
前述のとおり、Loop Engineering の設計はマージ判断だけを人間に残しています。そのマージ判断者と、issue を書いた人と、実装の温度感を知っている人が同一だと、レビューで見るべき観点が完全に噛み合います。
「issue にはこう書いてあるが、この機能の本来の狙いを考えるとここは違う実装であるべきだ」というような、issue に書ききれていない温度感の判定は、ソロプレナーの場合すべて自分の中で処理できます。他人にこの温度感を伝えるコストが発生しない、というのは意外なほど大きな効果を生みます。
4. 一機能ごとの粒度をコントロールできる
もうひとつ、副次的だが実務では効くのが、issue の粒度を自分で決められることです。
Loop Engineering の修正上限は累計 10 回に設定しています（前回の記事）。この上限は、issue が扱いやすい大きさに刻まれていることを暗黙に前提にしています。1 つの issue に 5 つの機能が入っていると、10 回ではまず収束しません。
新規プロダクトでは、issue の粒度を自分の判断だけで決められます。「この issue は 1 PR で片付く粒度に切っておこう」と最初から意識できる。既存の大きな課題を分割しなくてよいので、粒度の設計コストがそもそも小さくなります。
「意図どおりに進む」の内訳
冒頭で「自分の意図どおりにかなり開発が進む」と書きましたが、これが具体的に何を意味しているかを分解しておきます。
意図どおりに進む、という感覚には少なくとも 3 つの層があります。
意図がそのまま実装される
いちばん表層の意味は、issue に書いたとおりの差分が返ってくる、というものです。ソロプレナー的な新規プロダクトでは、これは高い頻度で成り立ちます。理由は単純で、issue に書いてあることの背後にあるコンテキストを自分がすべて持っているので、書き漏らしが少ないからです。
書き漏らしがあっても、レビューのターンで自分がすぐに気づけます。他人の書いた issue だと、「そもそも書き漏らしがあったのか、そういう仕様だったのか」を区別するのに時間がかかりますが、自分の issue ならその判断に迷いません。
意図と違うとき、なぜ違うかがすぐ分かる
次の層が、意図と違うものが返ってきたときの対応です。ソロプレナーの場合、意図と違う実装が上がってきた瞬間に、その原因が「issue の書き方が悪かった」なのか「エージェントの解釈が変だった」なのか「そもそも自分の意図が固まっていなかった」なのかを、その場で判別できます。
判別できるので、次のアクションが即決まります。issue の書き方が悪ければ issue を直して回し直す、エージェントの解釈が変ならプロンプトの禁則を強化する、意図が固まっていなかったなら一度止まって設計し直す。この分岐がスムーズに回ることが、体感として「意図どおりに進む」ことに寄与しています。
意図の質そのものが上がっていく
もう一段深い層がここです。Loop Engineering を回すために issue を書き続けていると、書く前に決めなければならないことが増えます。前回の記事で書いたとおり、「まあ書きながら決めればいい」で済ませていた判断が、全部前倒しになります。
ソロプレナー的な新規プロダクトでは、この前倒しがそのまま設計の質になります。他人と合意を取るための文章ではなく、自分で自分に説明するための文章として issue を書くと、書きながら「そういえばこれ、どうするんだっけ」に自分で気づく回数が増えます。
意図どおりに進む、というのは、単に実装が意図に一致しているという話ではなく、意図そのものが以前よりくっきりしている、という話でもあります。
立ち上げ時に何を用意しておくか
ソロプレナー的な新規プロダクトで Loop Engineering を回すつもりなら、リポジトリを切った最初の 1 日で入れておきたいものがいくつかあります。あとから足せますが、あとから足すと、そのあいだ回すループの検証水準が下がります。
AGENTS.md と CLAUDE.md
AGENTS.md と CLAUDE.md は、リポジトリごとにエージェントへの指示を書くファイルです。Loop Engineering の preflight はここから検証コマンドと禁則を読み出すので、以下は最初に書きます。
- ビルド・テスト・lint・フォーマットの正確なコマンド
- どのファイルに触ってよく、どこは触ってはいけないか
- 生成ファイルの扱い（コミットするのか、コミットしないのか）
- 依存関係の追加ルール
- コミットメッセージや PR タイトルの規約
新規プロダクトなら、まだ規約が固まっていないものも多いはずです。それでも「今はまだ決めていない」ではなく、暫定でよいので言語化して書きます。エージェントは「書いていない」を「自由に判断してよい」と解釈するので、暫定を書くのと空白のままにするのでは意味が違います。
落ちるテストと動く CI
初日から書けるテストは多くありませんが、「壊れたら実際に落ちるテストが 1 本ある」状態と、「テストは 0 本」の状態は、ループの安全性がまったく違います。1 本しかないテストは検証の内容としては弱いですが、CI が実際に動き、失敗が実際にエージェントに伝わる回路ができている、という証拠になります。
同時に、CI ワークフローファイルを最初から置いておきます。テストが増えたらそこに追加していくだけで済むので、あとで「CI を整える日」を作らずに済みます。
issue テンプレート
Loop Engineering の preflight は issue のスナップショットを唯一の権威として使います。issue が曖昧だと出力が曖昧になるので、GitHub の issue テンプレートを最初に置きます。
自分が今使っている項目は次のものです。
- 何を解決するのか、なぜ今それをやるのか
- スコープの内と外を、明示的に列挙
- 受け入れ条件を、検証可能な形で
- 触るコードと触らないコードの範囲
- 選択肢がある場合、採る案と採らない案の理由
ソロプレナーの場合、この項目に沿って自分で自分に問い直すこと自体が設計行為になります。テンプレートは他人のためではなく、自分の思考を強制的に手続き化するためのものと割り切ります。
signoff の要否を先に決める
前回の記事で書いた signoff_required フラグですが、これは新規プロダクトの初日に決めておくと後が楽です。個人プロジェクトで signoff が要らないなら、そのことを AGENTS.md か CLAUDE.md に明示します。逆に将来 OSS 化する予定があって DCO を求めるなら、最初から gh signoff 相当のラッパーを用意しておきます。
途中で切り替えると、それ以前のコミットのポリシー整合を後から取り直すことになります。Loop Engineering は「設定されているアカウントがあることと有効なセッションがあることは違う」という規律で動くので、ポリシー自体が変わることも同じくらい壊れやすい要因になります。
効かなくなるサインを見逃さない
ソロプレナー的な新規プロダクトで Loop Engineering を回していても、プロダクトが育ってくると、少しずつ効きが悪くなる時期が来ます。次のようなサインが出たら、いったん立ち止まって設計を見直す合図です。
- 同じ指摘がループの中で復活し、10 回では収束しなくなる issue が増えてくる
- レビューは通っているのにマージ後にバグが出始める
- issue のスコープが「1 PR に収まる粒度」に切りづらくなってくる
- 検証コマンドが増えすぎて、AGENTS.md の記述が実態と合わなくなる
- 自分ひとりで全設計を把握しきれなくなり、issue に書き漏らしが目立つようになる
これらは、Loop Engineering の 3 つの前提のどれかが崩れ始めているサインです。仕様の権威が分散し始めた、検証基盤が判定できる範囲を超え始めた、意思決定が閉じなくなり始めた、というシフトが起きています。
このタイミングで無理にループを回し続けると、「回っているように見えるが判定していない」状態にじわじわ移行します。むしろこの段階で、Loop Engineering を回しつつ、判定できる範囲を意識的に守る運用に切り替えるか、部分的に人間のレビューを差し込むかを判断すべきです。
つまり、Loop Engineering は「新規プロダクトが新規である間に最大効率で回る」ツールであり、プロダクトの成熟とともにコストが変わっていくものだ、と理解しておくのが正確です。
まとめ
Loop Engineering は、AI エージェントに issue を渡して review-ready な PR を返させる開発スタイルです。エージェントが実装と検証のループを回し、人間は plan、基盤、マージ判断に集中します。
このスタイルが機能するには、仕様の権威が誰にあるかがはっきりしていること、検証基盤が実際に壊れたときに落ちること、マージ判断まで含めて意思決定が閉じていることが要ります。既存の大きなコードベースや、意思決定が分散している組織、判定が形骸化した検証基盤では、この 3 つが揃わないので、ループは回っているように見えても中身が空洞になりがちです。
一方、ソロプレナー的な新規プロダクトはこの 3 つが自動的に揃います。ゼロから立ち上げているので仕様の権威は自分、検証基盤は自分の裁量で最初から高く設定でき、マージ判断者も issue の書き手も同一です。だから Loop Engineering の設計思想がそのまま活き、意図どおりに進む感覚が強く得られます。
ただしこれは万能ではなく、プロダクトが育つにつれて 3 つの前提のどれかが崩れます。回りにくくなるサインを見逃さず、判定できる範囲を守る運用に切り替えるか、人間のレビューを差し込むかの判断を、そのつどしていく必要があります。
言い換えると、Loop Engineering は「今この時期のソロプレナー的な新規プロダクト」で最大の効果を出す道具です。この時期にいる自覚があるなら、迷わず全振りしていい投資です。
以上、Loop Engineering が効くリポジトリと効かないリポジトリを分ける前提を整理し、ソロプレナー的な新規プロダクトでこそ最も効くことを、日々ループを回しながら確認した、現場からお送りしました。