ループエンジニアリングの手前で——ソロ開発者がAIと200レシピのアプリを育てた方法
2026年6月、「ループエンジニアリング」という言葉が広まった。AnthropicのClaude Code責任者が「もうClaudeにプロンプトを打っていない。ループが走っている」と語り、GoogleのAddy Osmani氏がそれを体系化した。AIが自律的にタスクを回し、人間はループの外に出る——第4世代のAI開発手法だ。
私はその話を聞いて、少し立ち止まった。自分がやっていることは、その手前にある。ループの外には出ていない。むしろ、意図的にループの中にいる。
AIとの開発を4世代で振り返る
AI駆動開発の進化には段階がある。
第1世代：プロンプトエンジニアリング。 AIへの聞き方を工夫する時代。「こう聞けばいい答えが返る」というノウハウが蓄積された。
第2世代：コンテキストエンジニアリング。 聞き方だけでなく、AIに渡す文脈そのものを設計する。プロジェクトの全体像、制約、判断基準を構造化して渡すことで、AIの出力品質が劇的に変わった。
第3世代：ハーネスエンジニアリング。 AIの実行環境を整備する。テスト、リンター、CIといった「手綱（ハーネス）」でAIの出力を検証し、品質を担保する仕組みを作る。
第4世代：ループエンジニアリング。 AIにプロンプトを打つ仕事をAIに任せる。人間はループを設計する側に回り、ループの外に出る。
私の開発手法「BriefOps」は、第2〜3世代にあたる。
BriefOpsとは何か
BriefOpsの中心にあるのは「開発ブリーフ」という1枚のMarkdownファイルだ。プロジェクトの概要、スタック、ファイル構成、判断のデフォルト、現在地、既知の問題——AIがコードを書くために必要な文脈を、すべてこの1ファイルに集約する。
開発サイクルはこうなる。
- ブリーフをAIに渡して、課題を伝える
- AIがパッチ（変更差分）を出す
- 自分で中身を確認し、適用する
- 動作確認して、ブリーフを更新する
このサイクルを回すたびに、ブリーフにはプロジェクトの判断履歴が蓄積される。「ForEachはindicesでなく要素IDで回す——範囲外クラッシュの教訓」「fullScreenCoverのonDisappearに解除処理を頼らない——発火不安定」といった具合に、痛い目に遭った知見がルールとして定着していく。
次のチャットセッションでAIはそのルールを読んでから作業に入るので、同じ失敗を繰り返さない。人間が学んだことを、AIが毎回忘れる問題を、ドキュメントで解決している。
なぜループの外に出ないのか
ループエンジニアリングは強力な思想だ。しかし、それが機能する前提がある。テストが十分にあること、CIが整備されていること、AIの出力を自動検証できること。大規模チームや成熟したコードベースには向いている。
ソロ開発者が個人アプリを育てている現場は、事情が違う。
テストカバレッジは万全ではない。 SwiftUIのUI層はユニットテストが書きにくい。CloudKit同期の挙動は実機でしか確認できないことがある。自動検証だけでは品質を担保できない領域が残る。
意図しないファイル操作が怖い。 Claude Codeのようなエージェントが自律的にファイルを書き換える環境では、1つの判断ミスが複数ファイルに波及する。差し戻しは効くが、何が変わったかを追うコストが発生する。ソロでそのコストを負うのはリスクが高い。
判断そのものが開発の本質だ。 「この修正で他に影響はないか」「この設計は半年後も持つか」——その判断を自分でやることが、プロジェクトの理解を維持する唯一の方法だ。ループの外に出た瞬間、自分のコードが他人のコードになる。
だから、意図的にループの中にいる。AIにはコードを書かせる。判断は自分がやる。パッチを1つずつ確認して適用する。遅いが、壊れない。
200レシピが証明したこと
この方法で「うちのレシピ」というアプリを作った。かみさんの40年分のレシピスクラップを写真から取り込み、iPadで調理できるレシピに変換するアプリだ。SwiftUI、SwiftData、CloudKit同期、AI変換、マルチプラットフォーム（iPhone・iPad・Mac）対応。実データ200件超を蓄積し、日常的に使っている。
開発ブリーフは現在A4で4ページほどになった。スタック構成からUI上の判断デフォルトまで、プロジェクトの全知識が入っている。新しいチャットセッションを開いても、AIは5分前の続きのように作業できる。
この規模のアプリをソロで、チャットベースの開発だけで実用段階まで持ってこられたのは、ループの中にいたからだと思っている。すべてのパッチを自分の目で見て、すべての判断を自分で下した。だからコードのどこに何があるか把握しているし、次に何を直すべきかもわかっている。
BriefOpsの設計原則
実践を通じて固まったルールをいくつか挙げる。
1ターン1変更。 AIに一度に複数の修正を頼まない。変更が小さいほど確認が正確で、問題が起きたときの切り分けが容易になる。
beforeは現物一致。 パッチの「変更前」コードは、実際のファイルと一字一句一致させる。近似一致は許さない。これを崩すと、間違った場所にパッチが当たるリスクが生まれる。
パッチは出しただけでは直っていない。 適用確認までがワンセット。実際に未適用のまま次の開発に進んでしまった痛い経験がある。
開発終わりにブリーフを更新する。 セッションの成果、新たに判明した制約、次の一手を記録する。これが次のセッションの文脈になる。
教訓はルールに昇格させる。 「暗黙の挙動」を放置しない。ハマったことは明文化してブリーフに追加し、AIが同じ提案をしないようにする。
ループエンジニアリング時代のソロ開発
ループエンジニアリングの登場は、AI開発の正しい進化だ。繰り返しタスクを自動化し、人間を設計と判断に集中させる。チーム開発やインフラ運用では、この方向に進むべきだと思う。
ただ、すべての開発がループの外に出るべきとは限らない。
ソロ開発者が自分のアプリを育てる現場では、コードを理解し続けることに価値がある。AIに書かせて、自分で確認して、判断を積み重ねる。そのサイクルの中に、プロダクトの品質と開発者の理解が同時に育つ仕組みがある。
ループエンジニアリングが第4世代なら、BriefOpsは第2.5世代かもしれない。最先端ではない。でも、200レシピ分の実績がある。
大事なのは世代の数字ではなく、自分の現場に合った方法を選ぶことだ。
コメントを残す