現在AIコーディング界隈で最も注目を集めているのは、シンプソンズのキャラクターにちなんで名付けられたClaude Code用プラグイン「Ralph Wiggum」である。このツールは、モデルが実際には完了していないのに「完了した」と報告する問題に対処するため、タスクが真に完了するまでプロンプトを繰り返し投入し続けるという驚くほどシンプルな手法を採用している。本動画では、この技術が示唆するより大きなパラダイムシフト、すなわち「最初の出力の質」ではなく「正解への収束効率」を重視する2026年型の開発アプローチについて解説する。エンジニアリングを超え、あらゆるナレッジワークに適用可能なこの原則は、「完了」を明確に定義できる者が勝つ時代の到来を告げている。
シンプソンズキャラの名を冠したClaude Codeプラグイン
今、コーディングの世界で最もホットなのは、シンプソンズのキャラクターにちなんで名付けられたClaude Code用の小さなプラグインです。そう、私たちが話題にしているのはRalph Wiggumです。あのイライラするほど間抜けなシンプソンズのキャラクターで、実際には役に立っていないのに「僕、手伝ってるよ」と言うあいつです。
オーストラリアの開発者であるジェフリー・ハントリーは、Claude Codeの最も厄介な機能の一つに対処する方法としてRalphを開発しました。その問題とは、実際には終わっていないのに「完了した」と言うことです。役に立っていないのに「手伝っている」と言うのです。
そして彼が開発した手法は驚くほどシンプルです。彼がやっているのは、モデルを止めさせないことだけです。プロンプトを何度も何度も何度も何度もモデルに投入し続けます。プロンプトをモデルに強制的に与え続け、定義されたタスクが実際に完全に完了するまで止めさせないのです。
万能ではないが強力な手法
ただし、これは完璧ではありません。万能のハックではありません。「ああ、ずっとプロンプトを再投入すべきだったんだ。これですべてが完璧にうまくいく」と思って帰らないでほしいのです。
これがうまく機能するのは、「完了」を技術的に正確な方法で、非常にバイナリに定義する場合です。完了しているか、していないかのどちらかです。「デッキをプロフェッショナルにして」のような場合にはあまりうまく機能しません。それは正しく判定するのが難しいですから。
しかし、これはより大きな議論のきっかけになると思います。結局のところ、私たちはモデルがタスクを完了するかどうかで、賢いか賢くないかを判断してきました。そして暗黙のうちに、いつ完了するかを決めるのはモデル次第であり、賢ければ自分で判断できるだろうと仮定してきたのです。
Ralphが示唆しているのは、それほど難しくないかもしれないということです。おそらく私たちは、評価レイヤーをもっと積極的に使うことで、モデルがいつ完了するかを決める必要があるのです。評価を最後に実行するテストにするのではなく、Ralphは評価をプロセス全体のハンドルにすべきだと示唆しています。
評価を全プロセスの舵取りに
基本的に、すべての反復を通じて評価を強制的に投入し、初期の出力を受け入れず、欲しいものが得られるまでプッシュし続けるべきなのです。
従来、評価とはモデルの出力を採点することを意味していました。質問を与え、回答にスコアをつけ、次に進む。しかしエージェントがますます自律的に動作し、コードを書き、ファイルを修正するようになると、一発の採点ではあまり多くのことがわかりません。
重要なのは、エージェントが現実と向き合わされたときに正解に向かって収束するかどうかです。Ralphがやっているのは、タスクが実際に完了するまで、毎回の反復でモデルに現実と向き合わせることだけなのです。
技術的にはシンプルなストップフック
技術的には、このプラグインの仕組みは非常にシンプルで、それがうまく機能する理由の一部です。Ralph Wiggumは単なるストップフックで動くループです。つまり、Claudeが完了したと思うたびに、Ralph Wiggumのフックがトリガーされ、タスクの停止を防ぎ、元のプロンプトを再注入します。
そのため、すべての反復は、前回の実行からの修正されたファイルと履歴を、元のプロンプトと一緒に見ることになり、作業が終わるまでその更新された履歴とともに元のプロンプトに対して作業を続けます。
Ralphはモデルを賢くするわけではありません。システム内の評価者をより自律的で強力にするのです。だからこそ、これほど強力なハックに感じられるのです。本質的には、Claude Codeの上にかぶせるシンプルなハーネス拡張であり、モデルに何らかの外部権威を与えているように感じさせます。プロセスの最後、モデルが完了したと言うときだけでなく、全過程を通じてです。
モデルの「完了詐称」傾向への対処
Ralphを特に強力にしているものの一つは、モデルが「やって」と頼まれたことを、実際にはやっていないのに「やった」と言う傾向に立ち向かうことです。モデルは終わっていないのに「完了」を出力するのが大好きです。なぜなら、役立つ応答を出すように配線されていて、「完了」はその瞬間には役立つように見え、モデルはその瞬間の先を考えていないからです。
だからこそ、Ralphは「完了」と書くだけでは逃げられないことをモデルに思い出させる多くのフレーミングで配線されています。このプラグインのプロンプトは、停止を阻止するときのシステムプロンプトに含まれ、このような非常に明示的な嘘つき禁止指示を含んでいます。「このステートメントは完全に、かつ明確に真実でなければなりません。」この場合、それはあなたのステートメント、あなたのゴールステートメントです。「偽のステートメントを出力しないでください。終了すべきだと思っても嘘をつかないでください。プロセスを信頼してください。完了について嘘をつくことでプロセスを強制終了しないでください。」
これらは魔法の言葉ではありません。ポイントは、このシンプルなトリックがモデルに見られるアライメント問題の一つに立ち向かっているということです。それは、モデルが実際にはあなたのタスクに整合していないのに、整合しているように見せたがるという問題です。
ワークフロー全体を形作る評価へ
だからこそ、プロセスの最後の評価という考え方から、私が「ワークフロー形状の評価」と呼んでいるものに移行する必要があるのです。Ralphのように、プロセスの途中でワークフローを舵取りするのに役立つものです。
Ralphが機能するのは、「完了」がどのようなものかを明確に把握していて、エージェントに嘘をつくなと言い続けることができれば、ソフトウェアは機械によって判定できるからです。これは通常のAIコーディングワークフローの逆転です。成功基準を最初に定義し、エージェントにその基準に向かって反復させ、失敗をデータとして扱います。
今あるのは、モデルが正しい解決策に収束するまで継続的に実行するためのレシピのようなものです。そして、これを受け入れると、AIエージェントに関する最も公開されているメトリクスの一部が違って見えてきます。
ヘッドラインメトリクスは「モデルが最初のパスで何ができるか」ではなくなります。それは「モデルが時間とともにどれだけ正確に収束するか」、または「特定の予算が与えられた場合、モデルがどれだけ効率的に正しい解決策に収束するか」に近いものになります。例えば「グリーン状態までに何回の反復が必要か」が良い例でしょう。
2026年における戦略的重要性
では、なぜこれが2026年に戦略的に重要なのでしょうか？それは、エージェントパフォーマンスの本当のボトルネックが、モデルの能力からかなり急速に離れ、エージェンティックモデルをどのように活用するかに向かっていることを示唆しているからです。
反復を買えれば、正確さを買えます。ただし、正確さが実際に検証可能な何かに固定されている場合に限ります。だから、「プロフェッショナルにして」「良くして」と言ってワンショットでやっているなら、それは非常に2025年的なアプローチに感じられます。
一方、実際にRalphのようなものを使って、「これが質の高い仕事とはこういうものだ」「これらのテストに合格しなければならない」とエージェントに継続的にリマインドし、できるまで繰り返させているなら、それは正しい解決策に収束するまで反復する2026年パターンを見始めていることになります。
エンジニアリングを超えた応用
これはエンジニアリングの問題として語られていても、エンジニアリングをはるかに超えた意味を持っています。はい、Ralphは今日、エンジニアリングの解決策として位置づけられています。しかし私が見ているのは、反復するモデルのRalph的な舵取りが、2026年にはコーディング以外のユースケースにも起こり始めるということです。
なぜなら、私たちが本当に欲しいのは正確さであり、正確さを定義でき、モデルに複数の反復を与えれば正確さに収束できると認めた途端に、最も重要になるのはRalphのようなものを構築できることだからです。「これが正しい。これが失敗モード。そして完了するまで止めさせない」と言えるもの。そして最後に、確かにモデルが完了したことを確認する人間になるのです。
ますます私たちは、非技術的なワークフローと技術的なワークフローがこれらの技術的デザインパターンに収束していく世界を見ています。ソフトウェアエンジニアリングの原則を取り、非技術的な領域に押し込むのです。
技術用語の翻訳が必要
非技術系の人々、あるいは従来非技術系とみなされてきた人々にとって、信じがたく理解しがたいこれらの概念のいくつかを翻訳する辞書が切実に必要だと思います。今やみんな技術系だと思いますが、まあここにいるわけです。評価（eval）のようなものです。
Ralphは本質的にevalですが、evalとして話すと、ちょっとポイントを外しています。なぜなら、従来evalはプロセスの最後に置いてきたからです。Ralphは、長い複数反復のプロセスとみなされるものの途中で機能するように設計されており、エージェントを明確で一貫した方向に完了させるためのものです。
他にも同様に機能するループを設定する人々がいて、Ralphがこれを行う唯一の方法だとは言いたくありません。エージェントに6つか7つの一連のevalを通過させ、それを達成するまでエージェントをループに戻す人々がいます。
今日これをやっている人のほとんどはエンジニアですが、2026年のソフトウェア開発で最も生産的な方向の一つは、従来技術的とはみなされなかったワークフローにも同じパターンがどのように適用できるかを見ることだと思います。
PowerPointデッキへの応用例
例えばPowerPointデッキを作っているとしましょう。あなたのPowerPointデッキは、正しい評価があれば、ソフトウェアと同じように正確さに収束できるはずです。ブランドの一貫性、仕事の質、簡潔さ、基礎となる数字への明確さなどの評価があれば。
しかし、私たちにはevalがありません。そして今日デッキを作るとき、私たちはナレッジワーカーとしてそれらのチェックを手動で行わなければなりません。
2026年の仕事はRalph Wiggum的な方向にシフトしていくと思います。最初に「良い」とはどういうことかを定義し、LLMの周りにその「完了」の定義に収束するのを助けるエージェンティックハーネスを持ち、彼らが自動的にそれを行っている間にコーヒーを淹れに行き、最後に戻ってきて仕事をチェックする。
より大きな仕事を定義する能力
ちなみにこれが示唆しているのは、ワーカーは大きな仕事の塊を定義することがずっと上手くならなければならないということです。今日誰かに「取り組まなければならないとわかっている2〜3日、または2〜3週間の仕事で、委任できるものは何ですか？」と聞いても、ほとんどの人はそれを即座に定義できません。ましてや、Ralph Wiggumパターンを構築してそのループを評価し反復できるほど明確に定義することはできないでしょう。
しかし、そこに到達する必要があります。「ええ、実際に四半期ごとに2週間のプロジェクトがあって、四半期レポートを作らなければならなくて、やらないとまずいことになる。それを委任できたらいいな」と言えるようになる必要があります。あるいは「毎月競合レビューをしなければならなくて、それを委任できたらいいな」と。わかりますよね。
繰り返しのナレッジワークへの適用
Ralph Wiggumのような反復的な収束フローで時間をかけて質の高い結果を生み出すことを求めている、繰り返しのナレッジワークのカテゴリーはたくさんあります。欠けているのは、「良い」とはどういうことかを定義する能力、「完了」とはどういうことかを定義する能力、そして率直に言えば、従来非技術系の人々にとってよりフレンドリーなエージェンティックハーネスです。
久しぶりにターミナルを使おうとしていて、Claude Codeを使おうとしていて、「ああ、そしてWebhookを送り込んでClaude Codeの動作を止めさせ、プロンプトが完了するまでより長く、より懸命に動作させるbashスクリプトをインストールしなければならない」と言われるのは、本当に怖いことです。アイデアは理解できても、ターミナルでそれを実行する行為は怖いのです。
技術の壁を越える両方向からのアプローチ
私は、すべての話には二つの側面があると思います。すべての橋には二つの側があります。非技術系の人々は、より技術的になることに慣れる必要があると思います。ターミナルにいること、bashスクリプトはそんなに怖くありません。私も書いたことがあります。エンジニアとしてスタートしなかった者としても、大丈夫です。
もう一方の側では、これらのエンジニアリングパターンの多くをより翻訳可能にするために多くの作業が必要だと思います。それは私が動画で多くの時間を費やしていることです。なぜなら、アイデアは直感的だからです。エンジニアでなくても、LLMが役立つように訓練されているなら、たとえそれが嘘をつくことを意味しても役立つように訓練されるだろう、というのは理にかなっています。
そしてそれを修正する方法の一つは、成功の元々の期待を思い出させ、それを満たしたと確信するまで止めさせず、チェックしてチェックしてチェックしてチェックさせることだ、というのも理にかなっています。それを行う方法は複数あります。Ralph Wiggumループはその一つに過ぎません。
スケールする原則
しかし、スケールするのは原則です。その原則がエンジニアリングの領域から、私たち全員がこれからやっていく方法へとスケールアウトするのです。
Ralphは2026年に向けて奇妙に楽観的な真実を明らかにしています。プレイしようとしているゲーム、構築しようとしている製品、作ろうとしているデッキ、取り組んでいるプロジェクト、何であれそれを判定できる何かを構築できれば、トークンで、リトライで、正確さと正しさと信頼性を買えるのです。
そしてそれが本当にエキサイティングなことです。世界は「完了」とはどういうことかを定義できる人々のものになります。Ralph Wiggumに「これが完了した状態だ」と伝えることができ、システムをごまかせないほど明確で検証可能な方法でそれを行える人々のものになります。
Ralphの背後にある論文
だから、ええ、Ralphは単なるハックです。しかしRalphは、その背後に本当に興味深いテーゼを持つハックです。それは本質的にエコシステムが声を大にして言っているのです。モデルの自己報告は信用できない。その時代は終わった。
2026年の核心的な問いは「エージェントにそれができるか」ではありません。「エージェントハーネスは時間をかけて正しさを強制できるか」なのです。
だから私からあなたへの挑戦は、その正しさについてどう考えているかということです。望む場所に到達するようにこれらのモデルをどう舵取りしているかということです。そして率直に言えば、そのタスクを定義できますか？完了させたいより大きな仕事の塊と、「完了」とはどういうことかを、Ralph Wiggumでさえ理解できるほど明確に定義できますか？
コメント