00:00:00「Ralph Wiggum」が今、猛烈にバズっています。これについては昨年動画を作りましたが、
00:00:04それ以来、Twitter（X）はその話題で持ちきりです。Matt Pocock氏は大量の動画を公開し、
00:00:09Ryan Carson氏は非常に人気の高い記事を執筆。さらにRazmike氏は「Ralphie Bash script」を構築して拡張しています。
00:00:13しかし、皆やり方を間違えているのでしょうか？ 開発者本人は、一部の実装は正しくないと述べています。
00:00:19では、正しい方法とは何でしょう？ そしてなぜ今、AIを使ったソフト開発においてRalphが最良の手法なのでしょうか？
00:00:21チャンネル登録をして、さっそく本題に入りましょう。
00:00:26「Ralphループ」はJeff Huntley氏によって考案され、昨年6月に記事が公開されました。
00:00:30その本質は、AIエージェントに全く同じプロンプトを何度も繰り返し与えるBashのループ処理です。
00:00:35しかし、これが実に天才的なのは、AIエージェントを最も「賢い」状態で動作させられる点にあります。
00:00:40つまり、コンテキスト（文脈）が可能な限り少ない状態を維持できるのです。こちらをご覧ください。
00:00:46これがエージェントの全コンテキストウィンドウだとします。0から約30%までを、
00:00:51エージェントが最高のパフォーマンスを発揮する「スマートゾーン」と呼びましょう。30から60%の間は、
00:00:57まだ非常にうまく機能します。しかし、60%を超えると、
00:01:01性能が低下し始めます。ここを「ダムゾーン（無能ゾーン）」と呼びます。もちろん、この数値は絶対ではなく、
00:01:08モデルによって異なります。あるモデルのスマートゾーンは40%や50%かもしれませんが、
00:01:12通常、コンテキストウィンドウの80%を超えると、性能の低下が顕著になります。
00:01:16例えば Claude Sonnet や Opus の場合、一般的なコンテキストウィンドウは20万トークンです。
00:01:21最初の6万がスマートゾーン、次の6万はまあまあですが最初ほどではなく、
00:01:28最後の8万トークンでは、パフォーマンスが落ちるように感じられます。これは私の個人的な、
00:01:33このモデルでの経験談であり、皆さんは違う感想を持つかもしれません。この現象が起きる理由は、
00:01:38モデル自体が「自己回帰型」だからです。つまり、次のトークンを予測するために、前のトークンをすべて参照する必要があります。
00:01:43トークンが膨大になると、目の前のタスクに関連する重要な部分を見つけ出すために、
00:01:47大量の情報を読み解かなければなりません。さて、最初の30%に注目してみましょう。
00:01:52最初のプロンプトを書く前でも、自動的にコンテキストに追加されるものがあります。
00:01:56まずはシステムプロンプト、次にシステムツールです。典型的なClaudeモデルでは、
00:02:01それぞれコンテキストの8.3%と1.4%を占めます。つまり、この30%のうちの約10%がすでに埋まっています。
00:02:06さらに「スキル」があれば追加され、カスタムのMCPツールがあればそれも加わります。
00:02:12最後に「agent.md」ファイルがあれば、それも追加されます。
00:02:16当然、これらのファイルが大きければ大きいほど、より多くのトークンを消費します。
00:02:21これらはすべて、自分のプロンプトを入力する「前」の段階の話です。そのため、基本的には、
00:02:25このセクションはできるだけ小さく保つのが最善です。ツールやスキルを減らし、
00:02:30agent.md ファイルの内容を絞ることで、モデルを最適なコンテキスト状態で動作させられます。
00:02:356万トークンがどれくらいの量かというと、『スター・ウォーズ エピソード4/新たなる希望』の脚本
00:02:40丸ごと一冊が、GPT-4でおよそ5万4千トークンです。だいたいそれくらいの量ですね。
00:02:44「コンパクション（圧縮）」で解決できるのでは？ と思うかもしれませんが、
00:02:51それについては後で触れます。今は、Ralphが具体的にどう役立つかを見ていきましょう。
00:02:56Ralphの利点は、1つのコンテキストウィンドウにつき1つの目標に集中できることです。
00:03:0020万トークンのコンテキスト全体を、たった1つのゴールやタスクに捧げることができます。その方法は、
00:03:05まず「plan.md」ファイルを読み込むプロンプトを書くことです。ここには、フロントエンドの作成、
00:03:10バックエンドの作成、データベース構築といった、やるべきタスクが記されています。
00:03:15これはあくまでハイレベルな例です。実際にはもっと詳細で粒度の細かいタスクを書き込みますが、
00:03:19ここではこの例で進めます。このプロンプトはエージェントに対し、
00:03:23最優先のタスクを選んで変更を加えるよう指示します。変更を行ったら、
00:03:28プログラムを実行し、テストをした上で、コミットとプッシュまで行わせます。
00:03:33それらが完了し、テストが通ったら、plan.md ファイルの該当タスクにチェックを入れ、
00:03:38再び同じことを繰り返します。こうしてエージェントは、すべてのタスクが完了するまで、
00:03:42常に「次にやるべき最も重要なタスク」を探し続けます。あ、今の発言は取り消させてください。
00:03:46というのも、すべてのタスクが終わった後でも、Ralphループを回し続けることができるからです。
00:03:52そうすることで、自分では気づかなかった修正箇所や、plan.md にはない新機能のアイデアを、
00:03:57エージェントが見つけ出してくれるかもしれません。もし挙動がおかしくなっても、Ralphなら、
00:04:02いつでもプロセスを停止し、プロンプト用のMDファイルを調整して再開できるという利点があります。
00:04:08Ralphがこれほどシンプルなのは、プロセス全体が1つのBashの「whileループ」で実行されているからです。
00:04:12ここでは単に prompt.md を読み込んでエージェントに渡し、
00:04:16Claudeを「YOLOモード」で走らせているだけです。実際のフラグは YOLO ではなく、
00:04:22「dangerously-skip-permissions（権限確認をスキップ）」ですが、スペースの関係で短くしました。
00:04:26Ralphが特別なのは、ループがモデルの制御外にあることです。つまり、
00:04:31モデル側からRalphを止めることはできません。ループは回り続けます。これにより、
00:04:36新しいタスクが始まるたびに、あるいは新しいプロンプトが実行されるたびに、
00:04:41コンテキストはエージェントを最初に立ち上げたときと同じ「真っさら」な状態になります。
00:04:46圧縮も何もされていない新鮮な状態です。各タスクに最大限のコンテキストが割り当てられ、
00:04:50モデルが最も賢く最適な状態で動作するのです。一方「コンパクション（圧縮）」とは、
00:04:55エージェントがこれまでのやり取りから、次のプロンプトに重要そうな部分だけを抜き出す機能です。
00:05:01しかし、エージェントが「重要だ」と判断したものが、本当に重要とは限りません。
00:05:05そのため、圧縮によって不可欠な情報が失われ、プロジェクトが正常に動かなくなるリスクがあります。
00:05:11さて、開発者による「正統な」Ralphループの実装を見たところで、他の実装との違いを考えてみましょう。
00:05:16例えばAnthropicの実装では、スラッシュコマンドを使ってClaudeの内部コードでRalphを動かし、
00:05:21最大反復回数や完了の約束（promise）を設定しています。この特定の実装の問題点は、
00:05:27次のタスクに移る際に情報を「圧縮」してしまうことです。一つのタスクが終わって再実行する際、
00:05:33コンテキストを完全にリセットせず、前の内容を圧縮して引き継ぐため、重要な情報を失う可能性があります。
00:05:38また、反復回数の制限や完了の定義があることも、少し気になります。Ralphはただ回し続けることで、
00:05:43思いもよらない興味深い修正点を見つけてくれることがあるからです。人間がそのループを監視していれば、
00:05:48モデル特有の良いパターンや悪いパターンに気づき、元のプロンプトをさらに磨き上げることができます。
00:05:54Ryan Carson氏のアプローチを見てみると、これも「正統」とは少し異なります。
00:05:59ループのたびに agent.md ファイルを調整したり追記したりする可能性があるからです。
00:06:04システムプロンプトや設定にもよりますが、私の経験上、モデルは放っておくと非常に饒舌になりがちです。
00:06:08ループごとに agent.md に内容が追加され、それが各プロンプトの冒頭で読み込まれると、
00:06:14コンテキスト内のトークンがどんどん増えていき、結果としてモデルが「無能」な状態に陥りかねません。
00:06:19とはいえ、多くの人が基本のRalphループを元に独自のスクリプトを作っている事実は、
00:06:24この手法がいかにシンプルで理解しやすいかの証です。「正統なやり方」はあるにせよ、
00:06:29開発者やチーム、企業がそれぞれの用途に合わせてカスタマイズするのは良いことだと思います。
00:06:33例えば、Raz Mike氏の「Ralphie script」にある、複数のRalphを並列で走らせる機能や、
00:06:39ブラウザツールを使ってテストを行う仕組みは素晴らしいですね。また、Matt Pocock氏のバージョンでは、
00:06:44GitHubのIssueをタスクとして追加し、Ralphループが重要なものから順に処理して完了マークを付けるようになっており、
00:06:48これも非常に賢いやり方だと感じます。Ralphの持つパワーとシンプルさは、
00:06:53この先も長く定着していくでしょう。今後も多くの改良や派生版が登場するはずです。
00:06:57Jeffrey氏が「Loom and Weaver」プロジェクトで進めている、ソフトウェアを自律的かつ正確に作成する方向性も楽しみです。
00:07:03しかし、Ralphが自律的にソフトを作り続けるなら、エラーを探して確実に修正する手段も必要です。
00:07:08そこで「Better Stack」の出番です。ログを取り込んでエラーを抽出するだけでなく、
00:07:13フロントエンドのエラー追跡も可能です。このMCPサーバーを使えば、エージェントに対し、
00:07:18膨大なログを読み込ませる代わりに、フロントやバックのエラーだけを特定して抽出させることができます。
00:07:23結果として、コンテキストウィンドウの節約にも繋がります。
00:07:28ぜひ「Better Flux」をチェックして、感想をコメント欄で教えてください。
00:07:32I think is really clever. I think the power and simplicity of Ralph means that it's going
00:07:37to stick around for a very long time. And you also may see a lot of iterations and improvements
00:07:42from it. I really like the way Jeffrey is taking this with his Loom and Weaver project where
00:07:47he wants to create a way to make software autonomously and correctly. But with all these
00:07:52Ralphs autonomously creating new software, you need a way to search for errors and make
00:07:56sure they get fixed. This is where better stack comes in because not only can it ingest logs
00:08:01and filter out errors from them, but it can also handle error tracking on the front end.
00:08:06So with this MCP server, you can ask an agent to specifically pick out errors from the front
00:08:11end or back end instead of reading through the whole log, which in turn reduces the context
00:08:16window.
00:08:17So go and check out Better Flux, and let me know what you think in the comments.