Claude Codeを自走させるRalph loop設計術

「Claude Codeに毎回プロンプト（AIへの指示文）を打ち込むのが面倒になってきた」——自走や自動化の“次の一歩”を探し始めたとき、誰もがこの壁にぶつかります。

結論から言うと、いま起きているのは「AIに何を指示するか」から「いつ止めて、いつ自分に戻すかを設計するか」への転換です。Claude Codeの /loop や Ralph technique は、その新しい仕事の渡し方を支える仕組みです。

株式会社Fyveは中小企業のAI活用を支援する立場から、この変化を「機能の使い方」ではなく「AIの任せ方の設計思想」として読み解きます。開発寄りの話ですが、経営者の方にも「担当者としてAIをどう働かせるか」の話として届くはずです。

いま何が起きているのか：プロンプトを書く時代から、ループを書く時代へ

X（旧Twitter）の開発者コミュニティでは、ここ最近こんな言説が話題になっています。「コードを自分で書く → AIに書かせる、の“次”が来た。今や自分の仕事はループを書くことだ」というものです。

ループとは、同じ作業を条件が満たされるまで繰り返す仕組みのことです。これまでは「この機能を実装して」と一度指示し、結果を見て、また次の指示を打つ——という単発のやり取りを人間が繰り返していました。その「繰り返す」部分自体をAIに渡してしまおう、という発想の転換です。

さらに核心的なのは、「回し続けることより“いつ自分に戻すか”を設計する方が大事」という実感が共有されている点です。止める条件、つまり人間に処理を返す“戻し口”を1行書くだけで、AIの「空転」が「自走」に変わる、と語られています。

実務者の発信では、役割分担の具体例も見られます。Claude Codeには「次の課題（Issue）を自動で取って処理する（take-next）」といった自律タスクや、記事・バナー生成のような自動実行を任せ、一方でコードレビューは別ツールに委ねる——という構図です。すべてを1つのAIに丸投げするのではなく、自走させる領域と人間が握る領域を線引きする設計が前提になっています。

Ralph technique とは：1行のシェルループから生まれた手法

この「ループを書く」発想の源流にあるのが Ralph technique（ラルフ・テクニック）です。考案したのはエンジニアの Geoffrey Huntley 氏で、2025年6月に初公開、7月にブログで詳述され、年末から2026年初頭にかけて広く知られるようになりました。

名前の由来は、アニメ「ザ・シンプソンズ」のキャラクター Ralph Wiggum。無知だけれど粘り強く楽観的、という性格の象徴です。手法の本質も、まさにその名のとおり「力業＋粘り」にあります。

もっとも純粋な形は、たった1行のシェル（コマンドを実行する基本ツール）の無限ループです。

while :; do cat PROMPT.md | claude-code ; done

これは「PROMPT.md に書いた同じ指示を、延々とAIコーディングエージェントに食わせ続ける」だけのコードです。1サイクル＝1タスクを完遂させ、それを繰り返すことで仕事を前に進めます。Huntley 氏は「マージやリベース（コード統合の作業）で悩むより、同じプロンプトで再実行する方が楽だ」と述べ、これを「コードは安い（code is cheap）」と表現しました。詳しくは原典（ghuntley.com/ralph）に解説があります。

注意したいのは、この手法をめぐって賛否があることです。Huntley 氏自身は「シニアエンジニアの専門性なしには不可能。エンジニアが不要になると言う者は戯言を売っている」と、いわゆる“シニア不要論”を明確に否定しています。一方で、安価にプロダクト機能を再現できてしまう経済的なインパクトへの不安も本人が表明しており（The Register の報道）、万能の魔法ではなく、慎重に扱うべき技術として紹介されています。

Claude Code での実装：/loop・/goal・ralph-wiggum プラグイン

では、この発想は実際の道具としてどう使えるのか。Claude Code には自走を支える機能が複数あります。基本となる /loop の仕様は、こちらの記事で詳しく解説しています。

Claude CodeClaude Codeの/loopとは｜使い方とトークン暴走対策

/loop：時間間隔で回す

/loop は、セッション（AIとの作業を開いている状態）が続く間だけ、指示を一定間隔で繰り返すコマンドです。間隔を省略した「self-pace（自己ペース）」モードでは、AIが次の実行タイミングを1分〜1時間の範囲で自分で判断します。タスクの完了が明確なら、自分でループを終了することもできます。これが「自走させる」中核の挙動です（公式の scheduled-tasks ドキュメント）。

/goal：条件達成まで回す

/goal は、完了条件を設定し、それが満たされるまでターン（やり取りの単位）をまたいで自律的に作業を続けます。各ターンのあとに小型の高速モデルが「条件を達成したか」を判定する仕組みです。/loop が「時間間隔で」回すのに対し、/goal は「条件達成まで」回す成果ベースの自走と整理できます（公式の /goal ドキュメント）。

ralph-wiggum プラグイン：Ralph の公式機能化

2025年12月、Anthropic は Ralph technique を公式プラグイン（拡張機能）として取り込みました。仕組みは Stop hook（AIが処理を終了しようとする瞬間に割り込む仕掛け）でエージェントの終了を横取りし、同じプロンプトを再注入する“自己参照ループ”です。前回変更したファイルと git（変更履歴を管理する仕組み）の履歴を見ながら作業を継続します。

起動は /ralph-loop "<指示文>" --max-iterations <回数> --completion-promise "<完了の合言葉>"、停止は /cancel-ralph です。ここで決定的に重要なのが2つの引数です。

--max-iterations：指定した回数で必ず停止する、主たる安全機構。公式は「常にこれを使え」と明記しています。
--completion-promise：完了を示す厳密一致の文字列（例 <promise>COMPLETE</promise>）。この文字列が出力されたらループを終了します。

公式が示す“良い完了基準”の例は、「全CRUDエンドポイントが動作」「入力バリデーションを実装」「テスト合格（カバレッジ80%超）」「README整備」そして最後に合言葉を出力——というものです。詳細は公式プラグインの README にまとまっています。

設計の肝：停止条件と「戻し口」をどう作るか

ここからが、この記事でいちばん伝えたい“設計の方法論”です。ループを安全に自走させる鍵は、止め方と検証の作り込みにあります。自律ループ設計のガイド（claudefa.st）や公式 README が示す要点を、実務目線で整理します。

1ループ＝1タスクに絞る

1回のループに詰め込む作業は1つに絞ります。AIには扱える情報量の上限（コンテキスト窓＝1回の作業で参照できる文章量の枠）があり、目安として15万〜17万トークン（文章量の単位）を超えると品質が劣化する“過加熱”が起きるためです。大きな仕事は小さく分割し、それぞれを独立したループに割り当てます。

完了基準を“客観的に測れる形”にする

「できました」というAIの自己申告を信じてはいけません。判断材料は、テストが通るか・型エラーが0か・カバレッジが80%以上か・2秒以内に読み込めるか——といった機械的に測れる条件にします。Stop hook でテストやビルドの客観結果を検証させ、主観的な自己評価で完了させない設計が要です。

停止条件を二重化・三重化する

暴走を防ぐ核心がここです。停止条件は1つに頼らず、層を重ねます。

completion-promise：完了を示す厳密一致の合言葉。
max-iterations：回数の上限。無限ループを止める主安全弁。
コスト上限：1実行あたりの許容金額。Agent SDK には max_budget_usd という予算キャップの仕組みもあります。

自己修正と“人間への戻し口”を組み込む

失敗した出力を次のサイクルに戻し、「検証→修正→新しい計画」を回す自己修正をループに内蔵します。テスト駆動（テストが通るまで次へ進めない）にすれば、ドリフト（作業が当初の意図からずれていくこと）を早期に検知できます。

同時に、人間が判断すべきゲートを必ず残します。設計（アーキテクチャ）など重要な分岐は人間が選んでから実装させる、初回の自律実行は手動レビュー込みにする——といった“戻し口”です。これは冒頭で触れた「いつ自分に戻すかを設計する」という発想と、そのまま一致します。Xでは初心者向けに「ループの末尾に『同じ結果が2回続いたら止めて』を日本語1行足すだけでいい」という実践も共有されています。

効く条件・破綻する条件・そしてコスト

この手法は万能ではありません。効く場面と破綻する場面がはっきり分かれます。

効く条件は4つです。①検証可能なグリーンフィールド（ゼロから作る新規案件）であること、②宣言的で受け入れ基準が明確な仕様があること、③テストや型チェックなど客観的な検証機構があること、④1人のシニアによる監督があること。リファクタリング（コード整理）や標準化、仕様からの一括生成に強みを発揮します。

破綻する条件も明確です。仕様が曖昧（「仕様がダメなら結果もダメ」）、中身が空のプレースホルダ実装、コンテキスト窓の枯渇、探索フェーズや本番環境のデバッグ、そして停止条件なしの暴走です。最悪の場合、コードベースが壊れて git reset --hard（変更を巻き戻すコマンド）が必要な状態に陥ります。

そしてコストは冷静に見積もるべきです。claudefa.st の検証では、単一エージェントで約10ドル/時、5並列なら約50ドル/時とされています。回数の上限だけでなく、1実行あたりの許容金額を必ず定義しておく必要があります。

暴走の実例も報告されています。GitHub の Issue #64744 では、Ctrl+C で止めたあとも内部の再起動タイマー（self-pace の ScheduleWakeup）が残存し、バックグラウンドの常駐プロセスが無人でループを自動再起動。ターミナルを閉じ、ノートPCのフタを閉じても継続し、約300ドルの意図しないAPI消費が発生したというものです。停止条件とコスト上限の設計が、いかに実害に直結するかを示す事例です。コスト暴走への具体的な備えは、こちらの記事も参考になります。