https://www.knightli.com/ja/tags/ralph/ Recent content in Ralph on KnightLiブログ Hugo -- gohugo.io ja Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/ja/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/ja/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ <p>最近 coding agent を使っていると、すぐにひとつの現実的な問題にぶつかります。<strong>AI は確かに仕事をしてくれる。でも、どうすれば何時間も動かし続けても途中で脱線せず、要件を忘れず、同じ作業をやり直さずに済むのか。</strong></p> <p><code>Ralph</code> やマルチエージェント協調をめぐる議論で本当に重要なのも、まさにこの点です。単にどのモデルが強いかを比べる話ではありません。より実用的な問いは、<strong>長いタスクでも AI が安定して動けるように、どうワークフローを設計するか</strong> です。</p> <p>この問題を分解すると、よく出てくるルートは大きく 2 つあります。</p> <ul> <li><code>Ralph</code> 方式：新しいセッションを繰り返し起動し、ファイルシステムで文脈をつなぐ</li> <li>マルチエージェント方式：リード Agent が調整し、子 Agent が分担して実行する</li> </ul> <p>もっと平たく言えば、問われているのは「どのモデルが強いか」ではなく、「どう AI を組織して、継続的に成果を出す小さなチームのように動かすか」です。</p> <h2 id="01-なぜ長時間タスクは崩れやすいのか">01 なぜ長時間タスクは崩れやすいのか </h2><p>短いタスクでは、多くの問題は表に出ません。指示を 1 つ出し、モデルが数ファイルを読み、少しコードを書き換えれば終わります。</p> <p>ところがタスクが長くなると、問題が一気に表面化します。</p> <ul> <li>会話が伸び続けてコンテキストが膨らむ</li> <li>初期の要件が新しい情報に押し流される</li> <li>ひとつの Agent が設計、実装、テストまで全部抱える</li> <li>明確な受け入れ確認がないと、「終わった」と「終わったと言っているだけ」が混ざる</li> </ul> <p>そのため、長時間 AI を動かすときに本当に問われるのは単発の出力性能ではなく、<strong>タスク分割、状態の受け渡し、役割分担、フィードバックループ</strong> です。</p> <h2 id="02-ralph-方式長いタスクを短いラウンドに分ける">02 Ralph 方式：長いタスクを短いラウンドに分ける </h2><p><code>Ralph</code> の考え方は、まず「コンテキストがどんどん汚れていく」問題を解くのに向いています。</p> <p>やっていることはシンプルです。</p> <ul> <li>ループで新しい agent セッションを何度も起動する</li> <li>各ラウンドでは十分小さなタスクを 1 つだけ扱う</li> <li>ラウンドをまたぐ状態は会話ではなくファイルに置く</li> </ul> <p>利点は明快です。毎回 fresh context から始まるので、1 ラウンドごとの集中が保ちやすく、過去の履歴に引きずられにくくなります。</p> <p><code>Ralph</code> 系のプロジェクトを見たことがあるなら、構造はかなり一貫しています。</p> <ul> <li>現在のタスクは構造化ファイルに書く</li> <li>途中の学びは進捗ファイルに残す</li> <li>コードの変化は git 履歴に残す</li> </ul> <p>つまり <code>Ralph</code> は、1 つの Agent に「全部を永遠に覚えさせる」ことを目指していません。記憶を意図的に外へ逃がし、セッションそのものを軽く保とうとします。</p> <p>この種の方式は、特に次のような条件で相性がいいです。</p> <ul> <li>作業がすでに小さな story に分けられている</li> <li>各 story が 1 つの context window に収まる</li> <li>プロジェクトに tests、typecheck、その他のチェックがある</li> </ul> <p>これは <strong>AI を一歩ずつ安定して前に進めるにはどうするか</strong> という問題への答えです。</p> <h2 id="03-マルチエージェント方式1-人では抱えきれない仕事を分担する">03 マルチエージェント方式：1 人では抱えきれない仕事を分担する </h2><p>もうひとつのルートがマルチエージェント協調です。</p> <p>この種のワークフロー設計でより有望なのは、リード Agent が自分で全部やるのではなく、調整役に回り、ほかの Agent が実装、テスト、確認、受け入れを分担する形です。</p> <p>ここが <code>Ralph</code> との大きな違いです。</p> <ul> <li><code>Ralph</code> は直列の反復に近い</li> <li>マルチエージェントは並列の分業に近い</li> </ul> <p>タスクの中に自然な役割分担があるなら、マルチエージェントのほうが扱いやすくなります。たとえば次のように分けられます。</p> <ul> <li>ひとりがタスク分解と実行計画を担当する</li> <li>ひとりが実装する</li> <li>ひとりがテストして検証する</li> <li>ひとりが結果が最初の要件に合っているか見直す</li> </ul> <p>大事なのは、ただウィンドウを増やすことではありません。価値があるのは役割を分離することです。もともと 1 つの Agent に押し込んでいた仕事を、より明確な段階に分けられます。</p> <p>役割の境界がはっきりすると、いくつかの問題が軽くなります。</p> <ul> <li>書く人とレビューする人を分けられる</li> <li>テストする側が毎回ゼロから要件を再構築しなくていい</li> <li>リード Agent が実装詳細に埋もれにくい</li> </ul> <p>これは <strong>AI を小さなチームのように協調させるにはどうするか</strong> という問題への答えです。</p> <h2 id="04-本当に重要なのは並列化ではなくどう分けるか">04 本当に重要なのは並列化ではなく、どう分けるか </h2><p><code>Ralph</code> を使うにしてもマルチエージェントを使うにしても、見落とされやすいのはこの点です。<strong>大事なのは Agent の数より、ワークフロー設計の質です。</strong></p> <p>タスク分解が悪ければ、Agent を増やしても混乱を並列化するだけです。</p> <p>より安定しやすい分け方には、だいたい次の特徴があります。</p> <ul> <li>1 タスクに 1 つの明確な目標がある</li> <li>1 役割に 1 種類の出力責任がある</li> <li>各ラウンドに明確な完了条件がある</li> <li>前のラウンドの成果が次のラウンドでそのまま使える</li> </ul> <p>たとえば「機能を全部作って」と一気に投げるより、次のように段階を切るほうが安定しやすいです。</p> <ul> <li>まず要件と境界を分ける</li> <li>次に実装を分ける</li> <li>次にテストを分ける</li> <li>最後に受け入れ確認を独立させる</li> </ul> <p>この分け方の利点は、問題が起きたときに、理解、実装、テスト、受け入れ基準のどこに原因があるのか見つけやすいことです。</p> <h2 id="05-なぜ受け入れ確認が重要なのか">05 なぜ受け入れ確認が重要なのか </h2><p>多くの AI ワークフローが崩れるのは、前半で何もしていないからではありません。最後に、本当に独立した確認ステップがないからです。</p> <p>長いタスクでは、「結果が生成された」と「その結果が本当に使える」のあいだに、かなり大きな差があることがよくあります。</p> <p>だからこそ、開発と受け入れを分けて考える方向が重要です。複雑な仕組みにしなくても、少なくとも次の問いは独立して投げる価値があります。</p> <ul> <li>最初のタスクを本当に完了しているか</li> <li>表面だけ直して根本原因を残していないか</li> <li>テストが都合のいい経路だけを見ていないか</li> <li>上流の要件を途中で勝手に変えていないか</li> </ul> <p>この層が欠けると、AI は長いフローの中で何度でも「成功した」と自己申告しがちです。</p> <h2 id="06-どう選ぶべきか">06 どう選ぶべきか </h2><p>手早い目安としては、次のように考えられます。</p> <ul> <li>いちばん痛いのがコンテキスト肥大化や長セッションの失焦なら <code>Ralph</code></li> <li>いちばん痛いのが 1 つの Agent に役割を詰め込みすぎていることならマルチエージェント</li> </ul> <p>もう少し具体的に言うと、</p> <ul> <li><code>Ralph</code> は、流れが明快で、粒度が細かく、ラウンド単位で進めやすい仕事に向く</li> <li>マルチエージェントは、役割分担が明確で、並行処理や相互検証が必要な仕事に向く</li> </ul> <p>実際には、この 2 つは対立するものではありません。むしろ成熟したやり方は組み合わせです。</p> <ul> <li>外側は <code>Ralph</code> のような反復ループで大きなタスクを進める</li> <li>内側は各ラウンドでマルチエージェントを使い、調査、実装、テスト、受け入れを分担する</li> </ul> <p>こうすれば、長いコンテキストの制御と、1 ラウンド内の協調効率を両方取りにいけます。</p> <h2 id="07-ひとことでまとめると">07 ひとことでまとめると </h2><p>これらの方法が重要なのは、<code>Ralph</code> やマルチエージェントそのものを単独で推しているからではありません。むしろ、ひとつの現実的な事実をはっきりさせているからです。<strong>AI を長時間安定して働かせる鍵は、モデル単体の強さよりも、コンテキスト、タスク、役割、受け入れ確認をどう設計したかにある。</strong></p> <p>すでに <code>Claude Code</code>、<code>Codex</code>、そのほかの coding agent に長めの実タスクを任せ始めているなら、こうしたワークフロー発想は「もっと強いモデルに替える」より優先して学ぶ価値があります。</p> https://www.knightli.com/ja/2026/04/27/ralph-autonomous-agent-loop-claude-code-amp/ Mon, 27 Apr 2026 08:08:55 +0800 https://www.knightli.com/ja/2026/04/27/ralph-autonomous-agent-loop-claude-code-amp/ <p>最近、coding agent の長時間ワークフローに注目しているなら、<code>snarktank/ralph</code> は一度見ておきたい小さなプロジェクトです。これは新しいモデルのラッパーでも、チャット UI をもう一枚かぶせたものでもありません。<code>Claude Code</code> や <code>Amp</code> を autonomous loop として組み立て、<code>PRD</code> にある story を 1 つずつ進め、すべて終わるまで回し続ける仕組みです。</p> <p>核になる発想はかなりシンプルです。<strong>同じ agent を、どんどん長くて汚れていくコンテキストの中で無理に走らせ続けないこと。代わりに、各イテレーションごとに新しい AI coding session を立ち上げること。</strong> これによって、コンテキストの膨張を抑えつつ、タスク境界もはっきりします。</p> <h2 id="01-ralph-とは何か">01 Ralph とは何か </h2><p>Ralph の公式な位置づけは明快です。<code>PRD</code> の項目が完了するまで、AI coding tool を繰り返し実行する autonomous AI agent loop です。</p> <p>現在のリポジトリでは、次の 2 つのツールに対応しています。</p> <ul> <li><code>Amp CLI</code></li> <li><code>Claude Code</code></li> </ul> <p>各イテレーションでは fresh instance が起動されます。つまり、1 本の会話を延々と伸ばし続けるのではなく、次のような外部状態に記憶を持たせます。</p> <ul> <li>git 履歴</li> <li><code>progress.txt</code></li> <li><code>prd.json</code></li> </ul> <p>ここが重要です。大きなタスクを agent に長く走らせるときの問題は、モデルがコードを書けないことではない場合が多いです。むしろ、会話が重くなり、コンテキストを落とし、要件を忘れ、同じ作業を繰り返しやすくなることのほうが大きい。Ralph は、ほぼこの問題に正面から向き合って設計されています。</p> <h2 id="02-どう動くのか">02 どう動くのか </h2><p>Ralph のワークフローは 3 段階です。</p> <h3 id="1-まず-prd-を作る">1. まず PRD を作る </h3><p>README では、まず付属の <code>prd</code> skill を使って要件書を作り、機能を小さめの story に分割することを勧めています。</p> <h3 id="2-prd-を-prdjson-に変換する">2. PRD を <code>prd.json</code> に変換する </h3><p>次に <code>ralph</code> skill を使って、Markdown の PRD を構造化された <code>prd.json</code> に変換します。このファイルには user stories と、それぞれが通過済みかどうかが記録されます。</p> <h3 id="3-ループスクリプトを実行する">3. ループスクリプトを実行する </h3><p>実際の実行を担うのは <code>ralph.sh</code> です。コマンドはおおむね次の形です。</p> <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code><span class="lnt">1 </span><span class="lnt">2 </span></code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">./scripts/ralph/ralph.sh <span class="o">[</span>max_iterations<span class="o">]</span> </span></span><span class="line"><span class="cl">./scripts/ralph/ralph.sh --tool claude <span class="o">[</span>max_iterations<span class="o">]</span> </span></span></code></pre></td></tr></table> </div> </div><p>デフォルトは 10 イテレーションです。各ラウンドではおおよそ次のことを行います。</p> <ol> <li><code>branchName</code> からブランチを作る</li> <li><code>passes: false</code> で最優先の story を選ぶ</li> <li>その story だけを実装する</li> <li>typecheck や tests などの品質チェックを走らせる</li> <li>チェックを通過したらコミットする</li> <li><code>prd.json</code> を更新する</li> <li>学びを <code>progress.txt</code> に追記する</li> <li>次のラウンドへ進む</li> </ol> <p>つまり Ralph は、すべてを一気に終わらせようとはしません。1 つのコンテキストウィンドウに収まる小さなループへと仕事を圧縮していくわけです。</p> <h2 id="03-ralph-の面白いところ">03 Ralph の面白いところ </h2><h3 id="1-毎回-fresh-context-を使う">1. 毎回 fresh context を使う </h3><p>これが Ralph のいちばん中心的な設計です。README でも、各イテレーションは新しい AI instance であり、イテレーション間の記憶は git、<code>progress.txt</code>、<code>prd.json</code> にしか残らないと強調されています。</p> <p>これは、<code>Claude Code</code> などを 1 本の長い会話の中で使い続ける一般的なやり方とはかなり違います。後者はタスクが大きくなるほど履歴に引きずられて重くなり、少しずつ焦点を失いがちです。Ralph は、1 回の実行ですべてを覚えさせることを諦め、その代わりに記憶をファイルに逃がします。</p> <h3 id="2-タスクを小さく保つことを前提にしている">2. タスクを小さく保つことを前提にしている </h3><p>ドキュメントでは、各 PRD item は 1 つの context window で終えられる大きさでなければならないと明言されています。たとえば、フィルターを 1 つ追加する、server action を更新する、DB のカラムを 1 本足す、といった粒度は適切です。一方で、API 全体の再設計やダッシュボード全体の構築は大きすぎます。</p> <p>この制約はとても現実的です。多くの autonomous agent loop が崩れる理由は、loop そのものではなく、タスク分割が粗すぎて 1 ラウンドに抱え込む量が多すぎることにあります。</p> <h3 id="3-コードだけでなく学びも残す">3. コードだけでなく学びも残す </h3><p><code>progress.txt</code> だけでなく、README は <code>AGENTS.md</code> の更新も強く勧めています。理由は単純で、今後のイテレーションや将来の開発者がそのメモを読むからです。各ラウンドで見つかったパターン、注意点、慣習は、プロジェクト文書として残しておいたほうがいい。</p> <p>言い換えると、Ralph は agent に継続してコードを書かせるだけでなく、コードベースに対する作業記憶も蓄積させようとしています。</p> <h2 id="04-どんな場面に向いているか">04 どんな場面に向いているか </h2><p>次のような条件なら、Ralph はかなり相性がいいです。</p> <ul> <li>すでに明確な user stories に分解できている</li> <li>テスト、typecheck、CI のような信頼できるフィードバックループがある</li> <li>1 本の長い会話に全部を押し込まず、agent を継続的に前進させたい</li> <li>一発完了より、反復で少しずつ進む形を受け入れられる</li> </ul> <p>逆に、要件がまだ曖昧だったり、議論を何度も往復しながら方向を頻繁に変える必要がある作業では、Ralph は最初の選択肢ではないかもしれません。要件が固まり、実装を安定して前に進めたい段階のほうが向いています。</p> <h2 id="05-普通の-claude-code-利用と何が違うか">05 普通の Claude Code 利用と何が違うか </h2><p>ふつうに <code>Claude Code</code> を使う場合は、1 つのセッションを開いて、そこからコードを読み、編集し、コマンドを実行し続ける形が一般的です。これは小規模から中規模の作業では非常に便利ですが、大きな作業になると次の 2 点が問題になりやすいです。</p> <ul> <li>コンテキストが伸び続ける</li> <li>途中の判断が構造化された形で残りにくい</li> </ul> <p>Ralph は <code>Claude Code</code> や <code>Amp</code> を、より「バッチ実行器」に近いものへ変えます。</p> <ul> <li>タスクの起点は都度の会話ではなく <code>prd.json</code></li> <li>各ラウンドが扱うのは 1 つの story だけ</li> <li>完了状態はファイルへ書き戻される</li> <li>学びは <code>progress.txt</code> に残る</li> <li>コード変更は git に残る</li> </ul> <p>その意味で、これは新しい AI assistant というより、coding agent の上にイテレーション制御を追加する仕組みと見たほうが近いです。</p> <h2 id="06-ひとつ重要な前提">06 ひとつ重要な前提 </h2><p>Ralph がうまく機能するかどうかは、loop 自体よりもフィードバックループの質に左右されます。README もかなり率直で、typecheck、tests、CI がないと、エラーは後続イテレーションで積み重なっていくと書いています。</p> <p>フロントエンド作業については、acceptance criteria にブラウザ検証を含めることまで勧めています。実際の確認がないと、agent は「見た目上は終わった」と「本当に動く」を簡単に混同してしまうからです。</p> <p>ここは大事です。Ralph は magical automation ではありません。むしろ、すでに持っている開発の規律を増幅する仕組みに近いです。タスク分割が明快で、チェックがしっかりしているプロジェクトほど価値が出ますし、その土台がないなら、混乱を繰り返し増幅するだけになりかねません。</p> <h2 id="07-ひとことでまとめると">07 ひとことでまとめると </h2><p><code>Ralph</code> の価値は、大規模な新基盤を作ったことではありません。シンプルだけれど実用的な発想を、すぐ使えるフローに落とし込んだところにあります。<strong><code>Claude Code</code> や <code>Amp</code> に各ラウンドで十分小さな story を 1 つだけ扱わせ、fresh context で集中させつつ、<code>git</code>、<code>prd.json</code>、<code>progress.txt</code> で継続性を保つ。</strong></p> <p>もし、すでに coding agent を実プロジェクトで使い始めていて、「長いタスクをどう安定して前に進めるか」で悩んでいるなら、Ralph のやり方はかなり参考になります。</p> <h2 id="参考リンク">参考リンク </h2><ul> <li>GitHub リポジトリ: <a class="link" href="https://github.com/snarktank/ralph" target="_blank" rel="noopener" >https://github.com/snarktank/ralph</a></li> <li>インタラクティブなフローチャート: <a class="link" href="https://snarktank.github.io" target="_blank" rel="noopener" >https://snarktank.github.io</a></li> </ul>