最近、coding agent の長時間ワークフローに注目しているなら、snarktank/ralph は一度見ておきたい小さなプロジェクトです。これは新しいモデルのラッパーでも、チャット UI をもう一枚かぶせたものでもありません。Claude Code や Amp を autonomous loop として組み立て、PRD にある story を 1 つずつ進め、すべて終わるまで回し続ける仕組みです。
核になる発想はかなりシンプルです。同じ agent を、どんどん長くて汚れていくコンテキストの中で無理に走らせ続けないこと。代わりに、各イテレーションごとに新しい AI coding session を立ち上げること。 これによって、コンテキストの膨張を抑えつつ、タスク境界もはっきりします。
01 Ralph とは何か
Ralph の公式な位置づけは明快です。PRD の項目が完了するまで、AI coding tool を繰り返し実行する autonomous AI agent loop です。
現在のリポジトリでは、次の 2 つのツールに対応しています。
Amp CLIClaude Code
各イテレーションでは fresh instance が起動されます。つまり、1 本の会話を延々と伸ばし続けるのではなく、次のような外部状態に記憶を持たせます。
- git 履歴
progress.txtprd.json
ここが重要です。大きなタスクを agent に長く走らせるときの問題は、モデルがコードを書けないことではない場合が多いです。むしろ、会話が重くなり、コンテキストを落とし、要件を忘れ、同じ作業を繰り返しやすくなることのほうが大きい。Ralph は、ほぼこの問題に正面から向き合って設計されています。
02 どう動くのか
Ralph のワークフローは 3 段階です。
1. まず PRD を作る
README では、まず付属の prd skill を使って要件書を作り、機能を小さめの story に分割することを勧めています。
2. PRD を prd.json に変換する
次に ralph skill を使って、Markdown の PRD を構造化された prd.json に変換します。このファイルには user stories と、それぞれが通過済みかどうかが記録されます。
3. ループスクリプトを実行する
実際の実行を担うのは ralph.sh です。コマンドはおおむね次の形です。
|
|
デフォルトは 10 イテレーションです。各ラウンドではおおよそ次のことを行います。
branchNameからブランチを作るpasses: falseで最優先の story を選ぶ- その story だけを実装する
- typecheck や tests などの品質チェックを走らせる
- チェックを通過したらコミットする
prd.jsonを更新する- 学びを
progress.txtに追記する - 次のラウンドへ進む
つまり Ralph は、すべてを一気に終わらせようとはしません。1 つのコンテキストウィンドウに収まる小さなループへと仕事を圧縮していくわけです。
03 Ralph の面白いところ
1. 毎回 fresh context を使う
これが Ralph のいちばん中心的な設計です。README でも、各イテレーションは新しい AI instance であり、イテレーション間の記憶は git、progress.txt、prd.json にしか残らないと強調されています。
これは、Claude Code などを 1 本の長い会話の中で使い続ける一般的なやり方とはかなり違います。後者はタスクが大きくなるほど履歴に引きずられて重くなり、少しずつ焦点を失いがちです。Ralph は、1 回の実行ですべてを覚えさせることを諦め、その代わりに記憶をファイルに逃がします。
2. タスクを小さく保つことを前提にしている
ドキュメントでは、各 PRD item は 1 つの context window で終えられる大きさでなければならないと明言されています。たとえば、フィルターを 1 つ追加する、server action を更新する、DB のカラムを 1 本足す、といった粒度は適切です。一方で、API 全体の再設計やダッシュボード全体の構築は大きすぎます。
この制約はとても現実的です。多くの autonomous agent loop が崩れる理由は、loop そのものではなく、タスク分割が粗すぎて 1 ラウンドに抱え込む量が多すぎることにあります。
3. コードだけでなく学びも残す
progress.txt だけでなく、README は AGENTS.md の更新も強く勧めています。理由は単純で、今後のイテレーションや将来の開発者がそのメモを読むからです。各ラウンドで見つかったパターン、注意点、慣習は、プロジェクト文書として残しておいたほうがいい。
言い換えると、Ralph は agent に継続してコードを書かせるだけでなく、コードベースに対する作業記憶も蓄積させようとしています。
04 どんな場面に向いているか
次のような条件なら、Ralph はかなり相性がいいです。
- すでに明確な user stories に分解できている
- テスト、typecheck、CI のような信頼できるフィードバックループがある
- 1 本の長い会話に全部を押し込まず、agent を継続的に前進させたい
- 一発完了より、反復で少しずつ進む形を受け入れられる
逆に、要件がまだ曖昧だったり、議論を何度も往復しながら方向を頻繁に変える必要がある作業では、Ralph は最初の選択肢ではないかもしれません。要件が固まり、実装を安定して前に進めたい段階のほうが向いています。
05 普通の Claude Code 利用と何が違うか
ふつうに Claude Code を使う場合は、1 つのセッションを開いて、そこからコードを読み、編集し、コマンドを実行し続ける形が一般的です。これは小規模から中規模の作業では非常に便利ですが、大きな作業になると次の 2 点が問題になりやすいです。
- コンテキストが伸び続ける
- 途中の判断が構造化された形で残りにくい
Ralph は Claude Code や Amp を、より「バッチ実行器」に近いものへ変えます。
- タスクの起点は都度の会話ではなく
prd.json - 各ラウンドが扱うのは 1 つの story だけ
- 完了状態はファイルへ書き戻される
- 学びは
progress.txtに残る - コード変更は git に残る
その意味で、これは新しい AI assistant というより、coding agent の上にイテレーション制御を追加する仕組みと見たほうが近いです。
06 ひとつ重要な前提
Ralph がうまく機能するかどうかは、loop 自体よりもフィードバックループの質に左右されます。README もかなり率直で、typecheck、tests、CI がないと、エラーは後続イテレーションで積み重なっていくと書いています。
フロントエンド作業については、acceptance criteria にブラウザ検証を含めることまで勧めています。実際の確認がないと、agent は「見た目上は終わった」と「本当に動く」を簡単に混同してしまうからです。
ここは大事です。Ralph は magical automation ではありません。むしろ、すでに持っている開発の規律を増幅する仕組みに近いです。タスク分割が明快で、チェックがしっかりしているプロジェクトほど価値が出ますし、その土台がないなら、混乱を繰り返し増幅するだけになりかねません。
07 ひとことでまとめると
Ralph の価値は、大規模な新基盤を作ったことではありません。シンプルだけれど実用的な発想を、すぐ使えるフローに落とし込んだところにあります。Claude Code や Amp に各ラウンドで十分小さな story を 1 つだけ扱わせ、fresh context で集中させつつ、git、prd.json、progress.txt で継続性を保つ。
もし、すでに coding agent を実プロジェクトで使い始めていて、「長いタスクをどう安定して前に進めるか」で悩んでいるなら、Ralph のやり方はかなり参考になります。
参考リンク
- GitHub リポジトリ: https://github.com/snarktank/ralph
- インタラクティブなフローチャート: https://snarktank.github.io