Geoffrey Huntley が 2025 年 7 月 14 日付で自身のサイトに掲載した記事で、彼がソーシャルメディアで
話題にしていた Ralph Loop の手法を解説している。記事の言葉によれば Ralph は手法であり、
最も純粋な形では、同じプロンプトファイルをコーディングエージェントに繰り返しパイプで渡す Bash
ループである：while :; do cat PROMPT.md | claude-code ; done。記事はこの手法を『ザ・シンプソンズ』の
登場人物 Ralph Wiggum として擬人化しており、説明の多くはその比喩に沿って進む——Ralph は間違いを犯し、
そのたびにオペレーターはプロンプトに標識を追加することで彼を「チューニング」する。
記事を通して用いられる例は CURSED である。これは Ralph が構築していると著者が報告する新しい難解 プログラミング言語で、コンパイラを備え、プロンプトに記された目標としては、その言語自体で書かれた 標準ライブラリを持つ。著者は、この言語がモデルの学習データに含まれていないにもかかわらず、Ralph が それを構築し、その言語でプログラミングできたことを指摘している。記事は、この作業を通じて著者が たどり着いた原則を示し、最後に言語の構築と計画に使っていたプロンプトの全文を掲載している。
要点
- Ralph は単一のリポジトリで、ループごとに 1 つのタスクをこなす単一のプロセスとして自律的に動作する。 著者はこれをモノリシックと呼び、現段階ではマルチエージェントやエージェント間連携の設計は不要だと 論じ、非決定的なエージェントをマイクロサービスとして扱うことを「ひどい大混乱」になぞらえている。
- 各ループは 1 つのことだけを行うべきであり、次に実装すべき最も重要なことの選択はエージェントに 任される。著者はこれを、責任あるエンジニアリングの限界を試す、完全に手放しのバイブコーディングだと 呼んでいる。
- 各ループは毎回決定論的に同じもの——計画（
fix_plan.md）と仕様——をコンテキストに読み込む。 各ループを小さく保つ理由として著者は、利用できるコンテキストウィンドウは約 170k トークンしかなく、 その多くを使うほど結果が悪化することを挙げている。 - 主となるコンテキストウィンドウは、高コストな作業のためにサブエージェントを起動するスケジューラとして 振る舞うべきである。多数のサブエージェントが検索やファイル書き込みを行ってもよいが、ビルドとテストを 実行するのは 1 つだけにすべきで、検証を数百のサブエージェントに分散させると、著者の言う悪い バックプレッシャーが生じる。
- よくある失敗は、エージェントが
ripgrepで検索し、コードが未実装だと誤って結論づけ、重複した実装を 作ってしまうことである。対処法は、何かが未実装だと決めつけないよう指示することであり、著者はこの 非決定性を Ralph のアキレス腱と呼んでいる。 - Ralph が誤ったパターンを生成するとき、著者は自身の技術的な標準ライブラリを更新する。まったく違う ものを作ってしまうときは仕様を疑う——著者は、1 か月経ってようやく、レキサーの仕様が 1 つの キーワードを相反する 2 つのケースで二重に定義していたことに気づき、多くの時間を無駄にしたと 報告している。
- テスト、型システム、静的解析ツール、セキュリティスキャナーは、生成された不正なコードを差し戻す バックプレッシャー として機能する。著者は動的型付け言語では静的解析ツールや型チェッカーを 組み込むことを強調し、Rust の正確性とコンパイルの遅さを比較検討している。
- 各ループは新しいコンテキストで始まるため、エージェントには、各テストと実装がなぜ重要なのかを ドキュメントに記録するよう求める。その理由を知らない後続のループのためのメモである。
- プレースホルダーや最小限の実装に傾くモデルのバイアスに対抗するため、プロンプトは完全な実装を 要求する。さらに Ralph Loop を追加で走らせて、プレースホルダーを見つけて To-Do リストに変える こともできる。
- To-Do リストは、尽きたり方向がずれたりするたびに、別の計画用プロンプトによって再生成される。 著者は、何度もそれを捨て、「鷹のように」監視していると報告している。
- Ralph には、プロジェクトのビルドと実行について学んだことで
AGENT.mdファイルを更新することが 許されており、記事はこれをループの核心と呼んでいる。 - 夜のうちにコードベースが壊れたとき、オペレーターは
git reset --hardして再スタートするか、 それを救うために新しいプロンプトを書くかを判断する。ループが生み出したどんな問題も、別の一連の プロンプトによって解決できるというのが著者の立場である。 - 著者は、この手法はグリーンフィールドのプロジェクトを立ち上げるのに適しており、およそ 90% までは 到達できると見込んでいること、既存のコードベースでは使わないこと、そしてそれを導くにはシニア エンジニアの専門知識が依然として必要であることを述べている。これらは 1 つのプロジェクトに基づく 著者自身の判断である。
背景
この記事は手法の実践者による一人称の報告であり、執筆時点でまだ公開されていなかった単一のプロジェクト に基づいて論じられている。著者は、プロジェクトに大きな欠落があったため記事の公開を控えていたと述べて いる。最も強い主張——この手法がグリーンフィールドの作業における外注の大半を置き換えられること、 そして現在のモデルとツールがすでに彼の言う「ポスト AGI」の領域に達していること——は、測定された 結果ではなく著者自身の立場として示されている。記事は、他者がこの手法を試した一例として、ハッカソンで コーディングエージェントをループで実行した第三者によるフィールドレポートへのリンクを示している。