Ralphメソッド

アップデート（2025年1月）: AnthropicはCLAUDE_CODE_TASK_LIST_IDを通じた依存関係・ブロッカー・マルチセッション連携を備えたネイティブタスク管理をリリースした。Ralphの回避策の多くが製品に組み込まれた。以下のコア原則は引き続き有効だ。新システムが配管作業をネイティブに処理してくれる。

エージェントにタスクリストを渡す。エージェントは1つを取り上げ、コードを書き、テストを実行し、コミットする。次のタスクへ。また次へ。あなたが眠っている間に、すべてが動き続ける。

これがRalphだ。シンプソンズのキャラクターとは無関係。エンジニアのソフトウェア開発を静かに塗り替えつつある、自律型コーディングループのことだ。

Ralphが違う理由

ほとんどの人はClaude Codeをチャットアプリのように使う。プロンプトを入力して待って、読んで、また入力する。簡単な作業には十分だ。しかし実際の機能を実装するとなると、あなた自身が遅い部分になる。

Ralphはそれを逆転させる。毎回ステアリングする代わりに、作業が完了するまでClaude Codeを動かし続けるループを構築する。コツはClaude Codeのストップフックにある。エージェントが終了しようとした瞬間に発火するため、その試みを捕捉してエージェントを作業に戻せる。

核心的なパターンはこうだ:

1. Claude がタスクに取り組む
2. Claude が停止しようとする（完了を出力する）
3. ストップフックが介入し確認する: 作業は本当に完了したか？
4. 未完了なら、プロンプトを返してループを継続する
5. 完了なら、終了を許可する

ステップ4がすべてだ。エージェントは最初に「完了した」と思ったときには止まらない。作業が検証されて初めて止まる。

完了プロミス

Ralphは「完了プロミス」を活用する。「本当に完了した」を意味する特定の単語やフレーズだ。Claudeがタスクを終えたと確信したとき、そのプロミスを出力する（通常は単に「complete」という単語）。

// Ralphループの設定
completion_promise: "complete"
max_iterations: 25

Claudeが停止しようとするたびに、フックがそのプロミスをスキャンする。見つからない？ループは続く。見つかった？ループ終了。早期終了はブロックされ、正規の終了だけが通過する。

重要なルール: プロミスなし、停止なし。これによりエージェントは、作業が本当に完了したと確信するまで動き続けるよう強制される。

検証: 絶対に外せないコア

Claude Codeを作ったBoris Chernyには、絶対に破らないルールが1つある: 常にClaude自身が作業を検証できる方法を与えること。

このルールがRalphを機能させる理由だ。検証を省くと、永遠に動き続けるか、早く止まりすぎるかのどちらかになる。追加すれば、ループが「いつ終わるか」を正確に判断できる。

Ralphと相性の良い3つの検証アプローチを紹介する。

1. テスト駆動検証

最初にテストを書く。Claude はそれを実行し、失敗を見て、コードを書き、再度実行する。ループはすべてがグリーンになるまで繰り返す。

ワークフロー:
1. /tests/feature-x/ のすべてのテストを実行する
2. テストが失敗したら、パスするコードを実装する
3. テストを再実行する
4. 全テストがパスするまで繰り返す
5. テストスイートがグリーンのときのみ "complete" を出力する

これが最も信頼できる方法だ。テストは嘘をつかない。パスかフェイルか。曖昧さはない。

2. バックグラウンドエージェントによる検証

メインエージェントの作業を確認するだけのセカンドエージェントを起動する。Borisは長時間の実行にこれを使う:

作業完了後、バックグラウンドエージェントで:
1. 変更されたすべてのファイルをレビューする
2. フルテストスイートを実行する
3. リグレッションを確認する
4. 見つかった問題を報告する

独立したチェックが得られる。バックグラウンドエージェントが問題を発見したら、メインループがすぐに作業に戻る。

3. ストップフック検証

ストップフック自体が検証を実行できる。進捗ファイルの確認、リンターの実行、ビルドの検証など。検証が失敗したら？停止をブロックしてエージェントを戻す。

// ストップフックの疑似コード
if (agent_trying_to_stop) {
  validation_result = run_tests();
  if (validation_result.failed) {
    return { decision: "block", reason: "Tests failing, continue work" };
  }
  return { decision: "allow" };
}

2フェーズワークフロー

ほとんどの人が犯す最初のミス: 計画と実装を同じコンテキストウィンドウで行うことだ。

2つに分けよう。

フェーズ1: 計画セッション

• 会話を通じて仕様を生成する
• 手動でレビューし編集する
• ファイル参照を明示した実装計画を作成する
• 仕様を「ピン」として保持し、ハルシネーションを防ぐ

フェーズ2: 実装セッション

• 新しいコンテキスト（前の会話をクリア）
• 計画ドキュメントのみを渡す
• Ralphループを実行する
• 完了まで反復させる

なぜ分けるのか？コンテキストウィンドウの劣化は現実の問題だからだ。やり取りを重ねるうちに、Claude は以前のメッセージに頼り始める。計画のみで新鮮なスタートを切ることで、フォーカスが保たれる。

計画がアンカーになる。ループの各反復がそれを参照する。エージェントが求めていないものへ脱線しないよう保つのがこれだ。

実践的な実装: PRDアプローチ

Ryan Carsonのバージョンはこのようになる:

1. PRD（製品要件定義書）から始める

• 何を作るのか？
• スコープ内は何か？
• 明示的にスコープ外は何か？

2. 受け入れ基準を持つユーザーストーリーに変換する

• 各ストーリーは小さくテスト可能な単位
• 受け入れ基準が「完了」を定義する

3. エージェントが処理できる形式に整える

• JSONまたはMarkdown形式
• 進捗追跡用の明確なチェックボックス
• 関連コードの場所へのリンク

4. ループを実行する

• エージェントが次の未完了ストーリーを選ぶ
• 実装する
• 検証（テスト）を実行する
• 完了マークを付ける
• 次へ移る

ここが報われる瞬間: その場を離れるだけでいい。朝目覚めたら機能が完成し、テストがグリーンで、コミットがログに記録されている。

UI検証: 隠れた落とし穴

誰もが一度は引っかかる落とし穴: テストはグリーンだが、UIがおかしい。

理由はこうだ。Ralph はコードが動いていることを確認しつつ、視覚的なバグに完全に気づかないままでいられる。コンポーネントはレンダーされ、テストはパスし、ボタンはまだ画面外にある、あるいはテキストが途中で切れている。

スクリーンショットベースの検証プロトコルで修正する。

UIの変更を実装した後:
1. 影響を受けるコンポーネントのスクリーンショットを撮る
2. レビュー後に各ファイルに "verified_" プレフィックスを付けてリネームする
3. まだ完了プロミスを出力しない
4. 次の反復ですべてのファイルが検証済みであることを確認する
5. その後で初めて "complete" を出力する

これによりUIの変更には最低2回のループパスが強制される。パス1で実装とスクリーンショット取得。パス2ですべてのスクリーンショットがレビューされたことを確認。視覚的チェックはスキップできない。

重要な洞察: スクリーンショットのリネームは完了プロミスを獲得しないとClaude に指示する。次の反復こそが完了のシグナルとなる。これにより早期終了がブロックされる。

経済性: なぜこれがすべてを変えるのか

ソネットで止まらず動き続けるコーディングエージェントのコストは、おおよそ1時間あたり10.42米ドル（24時間バーンレートで測定）。

ほとんどの地域の最低賃金より安い。そして支払うのは:

• バックログを一晩でクリアできるマシン
• 複数の機能を並行して実行できるマシン
• 疲れたり気が散ったりしないマシン
• コンピュートを増やすことでスケールするマシン

ボトルネックが変わる。「いくら使う気があるか？」から「どれだけ信頼性の高い作業を定義できるか？」へ。

信頼性の高いループを運用するチームは、そうでないチームに大きく差をつける。格差はすでに広がっている。

よくある失敗と修正

ループが終わらない

原因: 不可能なタスクまたは完了基準の欠如 修正: 最大反復回数を設定する（例: 25）。プロンプトに明示的な完了基準を追加する。

ループが早く終わる

原因: Claudeが作業完了前にプロミスを出力した 修正: 検証を強化する。テストを追加する。UIにはスクリーンショットプロトコルを使う。「完了」を客観的に測定できるものにする。

反復を重ねるごとに品質が低下する

原因: コンテキストウィンドウが失敗した試みで埋まっている 修正: チェックポイント状態を実装する。完了した作業を外部ファイルにマークする。コンテキストが埋まったときにループをクリーンに再開できるようにする。

エージェントが機能を発明する

原因: 仕様が曖昧またはない 修正: 仕様が発明を防ぐ「ピン」だ。具体的にする。既存コードへの明示的な参照を含める。何をしてはいけないかをClaude に伝える。

最初のRalphループのセットアップ

最初の実行は小さく始める。テストが既に存在する、よく知っている機能を選ぶ。

1. Ralphプラグインをインストールする（またはストップフックパターンを自分で実装する）

2. プロンプトファイルを作成する:

/docs/plan.md の実装計画を調べる
最も重要な未完了タスクを1つ選ぶ
既存のパターンに従って実装する
次のコマンドでテストを実行する: npm test
パスしたら: plan.md でタスクを完了マークし、変更をコミットする
失敗したら: 問題を修正して再度テストを実行する
すべてのタスクが完了してテストがパスしたときのみ "complete" を出力する

1. 制約を設定する:

• 最大反復回数: 25
• 完了プロミス: "complete"
• 品質ゲート: テストのパス、リンティングのパス

2. 最初の実行を観察する。まだその場を離れないこと。挙動がおかしければキャンセルする。プロンプトを調整して再実行する。

3. 信頼が積み重なるにつれて徐々に自律性を高める。

Ralphの哲学

Ralphはコーディングから人間を排除するものではない。試みと試みの間の退屈なループから人間を解放するものだ。

設計はあなたのものだ。仕様はあなたのものだ。「完了」の意味を定義するのはあなただ。最終結果をレビューするのもあなただ。

Ralphが引き受けるのは、深夜2時のデバッグの苦労だ。延々と続くテスト・修正・テストのグラインドだ。機能間の切り替えだ。これらの処理を担う。

Borisは常に同じ言葉に戻ってくる: 検証がすべてを動かす。Claudeに自分の作業を確認する方法を与えれば、何時間も信頼性高く動く。取り除けば、博打になる。

検証から始めよう。ループをその周りに構築しよう。自律型コーディングの未来は、より賢いプロンプトではない。より優れたフィードバックシステムだ。

次のステップ

• 組み込みの永続化とマルチセッション連携のためにネイティブタスク管理を試す
• カスタムストップ動作を実装するためにフックについて学ぶ
• 複数のループを実行するための非同期ワークフローを探る
• 自律的なワークフローをスケールするためのスレッドベースエンジニアリングについて読む
• 検証パターンのためのフィードバックループを確認する

Ralphを使いこなすようになった人々は、単なるClaude Codeユーザーではない。眠っている間にコードを出荷するシステムを構築しているのだ。