Skip to content

Claude Code を長時間働かせる方法

はじめに

従来の AI コーディングアシスタントは「会話型」です:あなたが一言言うと、一度返答して停止します。しかし実際の開発タスクでは、このモードは全く不十分です。

次のようなシナリオを想像してください:Claude にプロジェクト全体をリファクタリングさせたいのに、いくつかのファイルを編集して「完了」と言います;Claude に全テストが通るまでバグを修正し続けてほしいのに、一度実行して停止します;Claude に「一晩中作業して」ほしいのに、翌朝にはずっと前に停止していたことに気づきます。

2025年の夏、Geoffrey Huntley というオーストラリアの開発者(羊飼いでもあります)が、5行の bash スクリプトを書きました。スクリプトはシンプルでした:Claude Code を継続的に再起動し、同じタスクを与え続けます。彼はこのスクリプトを「Ralph Wiggum」と名付けました—決して諦めずに挑戦し続けるシンプソンズのキャラクターにちなんで。

このシンプルなスクリプトはシリコンバレーに衝撃を与えました。わずか2週間で関連プロジェクトが7,000以上の GitHub スターを獲得しました。人々はこれを使って一晩で6つの完全なプロジェクトを生成し、わずか$297の API コストで$50,000の契約作業を納品し、さらに3ヶ月で完全なプログラミング言語を構築しました。

この章が解決する中心的な質問は:Claude Code を本当の開発者のように、タスクが真に完了するまで継続的に働かせる方法です。


核心原理:なぜ AI は「早すぎる停止」をするのか?

具体的な方法を議論する前に、まず根本原因を理解しましょう。

AI の完了判断は信頼できない

LLM には根本的な弱点があります:作業が真に完了したかどうかを確実に判断できません。

人間の完了基準は客観的です:全テストが通り、機能が完全で、コード品質が基準を満たしています。しかし AI は「感覚」でしか判断できません。「これくらいでいいだろう」とか「出力が十分に見える」とか、次に何をすべきかわからないために停止するかもしれません。

だから AI の内部的な感覚に頼るのではなく、外部システムが真の完了を判断する必要があります。

解決策の核心的なアイデア

核心的な解決策は、AI を「ループ」の中で働き続けさせることです。

AI が抜けようとするたびに、外部システムが3つの質問を確認します:本当に完了したか?客観的基準を満たしているか?何か見落としはないか?そうでなければ、タスクを再注入して別のラウンドを続けます。

このアイデアは単純な bash スクリプトから複雑なオーケストレーションシステムまで多くの形で実装できますが、本質は同じです。


方法 1:While True Bash ループ(最も原始的な方法)

これは最もシンプルで直接的な実装です。本質的には、無限ループを書いて Claude Code を毎ラウンド再起動し、同じタスク説明を与えます。

最もシンプルな実装はわずか5行です:

bash
#!/bin/bash
while true; do
    cat PROMPT.md | claude
done

仕組み

スクリプトの流れは単純です。ステップ1で PROMPT.md からタスク説明を読み取ります。ステップ2で Claude Code を起動し、タスク説明を渡します。ステップ3で Claude が作業し、結果を出力します。ステップ4で Claude が完了後終了します。ステップ5でループが自動的に再起動しステップ1に戻り、手動で Ctrl+C で中断しない限り無限に循環します。

メリットとデメリット

メリットは極端なシンプルさです:誰でも理解でき、設定不要、すぐに使えて素早い実験に適しています。

しかしデメリットも明確です:真の完了を判断できず、永遠に回り続ける可能性があり、安全ガードレールがなく、API 呼び出しを無駄にする可能性があります。

実際の使用例

まず、タスクを説明する PROMPT.md ファイルを作成します。例えば、ユーザー認証モジュールのリファクタリング:

markdown
# タスク:ユーザー認証モジュールのリファクタリング

要件:
1. すべての認証ロジックを独立した AuthService クラスに抽出
2. ユニットテストを追加、カバレッジ > 80%
3. 関連ドキュメントを更新

すべてのテストが通り、ドキュメントが更新されたら出力:task complete

次にループスクリプトを作成して実行します:

bash
chmod +x loop.sh
./loop.sh

より安全な改良版

無限ループを避けるため、反復制限を追加します:

bash
#!/bin/bash
MAX_ITERATIONS=50
iteration=0

while true; do
    iteration=$((iteration + 1))
    echo "=== 反復 $iteration/$MAX_ITERATIONS ==="

    cat PROMPT.md | claude

    if [ $iteration -ge $MAX_ITERATIONS ]; then
        echo "最大反復回数に達しました。停止します"
        break
    fi

    sleep 5  # API レート制限を避けるための短い遅延
done

この改良版は最大反復制限を追加し、ラウンドごとの進捗を表示し、制限で自動停止します。また各ループに5秒の遅延を追加してレート制限を回避します。


方法 2:Ralph Wiggum プラグイン(公式推奨)

Ralph Wiggum は長時間実行タスクのために特別に構築された Anthropic の公式プラグインです。シンプソンズのキャラクターにちなんで名付けられ、「失敗しても挑戦し続ける」精神を表しています。

コアメカニズム:Stop Hook

Ralph の核心は Stop Hook です。Claude が終了しようとすると、Stop Hook が終了信号を傍受します。次にシステムが確認します:出力に特定の完了マーカーが含まれていたか?マーカーが見つからない場合、元のプロンプトを再注入して別の反復を開始します。完了マーカーが検出された場合のみ、Claude の終了が許可されます。

これにより、Claude が「十分に近い」と感じたことだけで停止しないことが保証されます。明確にマークされた要件を完了する必要があります。

インストール

Ralph Wiggum は公式 Claude Code プラグインで、2つの方法でインストールできます。

オプション1:公式プラグインマーケットプレイスからインストール(推奨)

bash
# Claude Code で実行
claude

# 公式プラグインマーケットプレイスを追加
/plugin marketplace add anthropics/claude-code

# Ralph Wiggum をインストール
/plugin install ralph-wiggum@claude-code-plugins

# インストール確認
/plugin

オプション2:GitHub から直接インストール

bash
# プラグインディレクトリに入る
cd ~/.claude/plugins/

# プラグインリポジトリをクローン
git clone https://github.com/anthropics/ralph-wiggum-plugin.git

インストール後、使用可能:

  • /ralph-wiggum:ralph-loop - ループ開始
  • /ralph-wiggum:cancel-ralph - ループキャンセル
  • /ralph-wiggum:help - ヘルプ表示

基本的な使い方

/ralph-wiggum:ralph-loop を使用:

bash
/ralph-wiggum:ralph-loop "CRUD 操作、入力検証、テストを備えた todo API を構築してください。
             すべて完了したら <promise>COMPLETE</promise> を出力してください。" \
  --max-iterations 50 \
  --completion-promise "COMPLETE"

パラメータの説明

最も重要な2つのパラメータは --max-iterations--completion-promise です。

--max-iterations はハード安全上限を設定します。推奨値は通常 20-100 です。未完了でも Ralph はこの制限で停止し、無限の API 支出を防ぎます。

--completion-promise は完了マーカーテキストを指定します。これは明示的で一意である必要があります。Ralph は Claude の出力にそのマーカーが含まれる場合のみタスクを完了と見なします。COMPLETETASK_DONE のような明確なマーカーを使用し、曖昧な言葉は避けてください。

プロンプトのベストプラクティス

良いプロンプトを書くことが Ralph の成功の鍵です。

悪いプロンプトは通常、完了基準を定義していません。例えば、「todo API を書いて」では、AI が大雑把なスケルトンを出力して停止する可能性があり、テストも検証もドキュメントもありません。

良いプロンプトは段階的な要件と明確な受け入れ基準を含めるべきです。例えば:

まず段階的なタスクを説明します。フェーズ1はすべての CRUD エンドポイントを備えたコア機能:POST /todos 作成、GET /todos 一覧、GET /todos/:id 個別取得、PUT /todos/:id 更新、DELETE /todos/:id 削除。フェーズ2は入力検証:タイトルは空にできない、完了状態はブール値でなければならない。フェーズ3はテスト:各エンドポイントのテストを作成、カバレッジ > 80%。

次に受け入れ基準を定義します:すべてのテストが通り、コードがリンターを通過し、README に API ドキュメントが含まれる。

最後に一意の完了マーカーを定義します:<promise>TODO_API_COMPLETE</promise>

これで Claude は何をすべきか、そして完了が本当に達成されたのはいつかを正確に知ることができます。

さらに多くのプロンプトテンプレート

以下は直接使用または調整できる一般的なタスクテンプレートです。

テンプレート1:テスト移行(Jest -> Vitest)

text
/ralph-wiggum:ralph-loop "
このプロジェクトのすべてのテストを Jest から Vitest に移行してください:
- すべてのテストロジックを変更せずに維持
- 設定ファイルを更新(vite.config.js, vitest.config.js)
- Jest 固有の API を置換(例:jest.mock -> vi.mock)
- すべてのテストが通ることを確認
- Jest 関連の依存関係を削除

受け入れ基準:
- npm test が完全に通る
- package.json に Jest の依存関係がない
- プロジェクトが正常にビルドされる

完了後に出力:<promise>VITEST_MIGRATION_COMPLETE</promise>
" --max-iterations 40 --completion-promise "VITEST_MIGRATION_COMPLETE"

テンプレート2:UI/UX 最適化(モバイルファースト)

text
/ralph-wiggum:ralph-loop "
このプロジェクトの UI/UX を洗練されたモバイルファーストの言語学習アプリに仕上げてください:
- スペーシングと余白を統一(4px ベースユニットを使用)
- 明確なタイポグラフィ階層を確立(タイトル/本文/補助テキスト)
- カード、リスト、共有コンポーネントのスタイルを統一
- ボトムナビゲーションを追加(ホーム/学習/クイズ/進捗/設定)
- モバイルレンダリング品質を確保

受け入れ基準:
- npm run build が成功
- TypeScript エラーがない
- 主要ページがモバイルで正しくプレビューされる

完了後に出力:<promise>UI_UX_COMPLETE</promise>
" --max-iterations 25 --completion-promise "UI_UX_COMPLETE"

テンプレート3:一括 TypeScript アノテーション

text
/ralph-wiggum:ralph-loop "
プロジェクト内のすべての関数に TypeScript 型アノテーションを追加してください:
- src/ ディレクトリを優先
- 関数パラメータと戻り値に型を追加
- any を避け、具体的な型または unknown を使用
- 必要な型定義を追加

受け入れ基準:
- npm run typecheck が通る
- @ts-ignore や @ts-any コメントがない
- コードが正しく実行される

完了後に出力:<promise>TYPES_ADDED</promise>
" --max-iterations 30 --completion-promise "TYPES_ADDED"

テンプレート4:TDD 駆動機能開発

text
/ralph-wiggum:ralph-loop "
TDD を使用してチェックアウト機能を実装してください:
1. まずテストを書く(checkout.test.ts)
2. テストを実行(失敗するはず)
3. テストを通すための最小限のコードを書く
4. リファクタリングと最適化
5. すべてのテストが通るまで繰り返す

機能要件:
- ショッピングカートのアイテムリスト
- 配送料計算
- クーポン適用
- 支払いフォームバリデーション

受け入れ基準:
- すべてのテストが通る(npm test checkout.test.ts)
- コードカバレッジ > 80%
- ESLint エラーがない

完了後に出力:<promise>CHECKOUT_COMPLETE</promise>
" --max-iterations 25 --completion-promise "CHECKOUT_COMPLETE"

テンプレート5:コードスタイル統一

text
/ralph-wiggum:ralph-loop "
プロジェクト全体のコードスタイルを統一してください:
- すべてのファイルを Prettier でフォーマット
- 命名規則を統一(変数 camelCase、コンポーネント PascalCase)
- 未使用の import と変数を削除
- 文字列引用符スタイルを統一(シングルクォート)
- セミコロンスタイルを統一(セミコロンなし)

受け入れ基準:
- npm run lint が通る
- 一貫したコードスタイル
- ビルドが成功

完了後に出力:<promise>STYLE_UNIFIED</promise>
" --max-iterations 20 --completion-promise "STYLE_UNIFIED"

実際のケース

有名なケースが Y Combinator ハッカソンで発生しました。あるチームが Ralph Loop を使用しました。午後11時にタスクを設定しました:6つの製品仕様に対して順次 MVP を実装し、それぞれに特定の完了マーカーを出力する。最大反復を200に設定して就寝しました。

翌朝、6つのデモ可能なプロジェクトがあり、API コストはわずか$297でした。それが Ralph の力です:あなたが寝ている間、AI が働き続けます。

別のケースは Boris Cherny(Claude Code リード)からです。Ralph と Opus 4.5 を使用して、30日間で259の PR を納品しました。497のコミット、40,000行の追加、38,000行の削除が含まれていました。最も驚くべきことに、すべて Claude Code が手動でのコード記述なしに生産しました。

さらに驚くべきケースは CURSED プログラミング言語です。Ralph の作成者である Geoffrey Huntley が3ヶ月間 Ralph Loop を使用して、自律的に完全なプログラミング言語を構築しました。キーワードは Gen Z のスラング(slaysusbased など)を使用し、さらに重要なのは完全な LLVM コンパイラ実装、標準ライブラリ、部分的なエディタサポートが含まれていることです。これは Ralph Loop の真の可能性を示しています:明確な目標を提供すれば、複雑なプロジェクトが真に完成するまで数ヶ月間働き続けることができます。

さらに多くの実際のケース

自動プロジェクトリファクタリング

ある開発者が Ralph を使用して、コードが乱雑でテストがなく、ドキュメントが欠落しているレガシープロジェクトをリファクタリングしました。割り当てられたタスクは:

  1. 既存コードにテストを追加
  2. 段階的にリファクタリング、各変更後にテストが通ることを確認
  3. ドキュメントを更新

Ralph は丸一週末実行されました。月曜日には47のコミット、よりきれいなコード構造、75%のテストカバレッジ、完全な API ドキュメントがありました。コストは約$12でした。

Ralph の哲学

Ralph は3つのコア哲学を反映しています。

第一は完璧より反復です。一度の完璧を期待せず、ループを使って改善してください。最初のパスはスケルトンだけを構築するかもしれませんが、2回目はバグを修正し、3回目は最適化し、4回目はテストを追加します;毎ラウンド良くなります。

第二は失敗をデータとして見ることです。すべてのテスト失敗は改善の機会です;失敗を恐れず、そこから学んでください。

第三は粘り強い試みです:機能するまで挑戦し続ける。それが Ralph の精神です。

Ralph が適している・適していないシナリオ

Ralph がどこに適合するかを知ることは、時間とコストの両方を節約するのに役立ちます。

Ralph に適したシナリオ

これらのタスクは明確な完了基準があり、自動反復に適しています:

シナリオ理由
テスト移行明確なターゲットフレームワーク、テスト通過で検証可能
大規模リファクタリング特定のリファクタリングルールを定義できる
フレームワーク移行成功した移行は動作するコードで検証可能
一括型アノテーションtypecheck が通れば完了
テストカバレッジ改善カバレッジパーセンテージが客観的
ドキュメント生成API ドキュメントを自動検証できる
UI/UX 統一具体的なデザインルールを定義できる
再現可能なバグ修正通過条件がテスト可能

Ralph に適さないシナリオ

これらのタスクは人間の判断や探索が必要です:

シナリオ理由
アーキテクチャ決定例:マイクロサービス vs モノリスにはトレードオフ判断が必要
セキュリティ機密コード脆弱性は微妙で自動検出が困難な場合がある
曖昧な要件明確な完了基準がない
探索的作業方向が継続的に変わる
クリエイティブデザイン人間の審美的判断が必要
単純な一度きりのタスクRalph の使用は過剰

決定チェックリスト

自分に3つの質問をしてください:

  1. 明示的な完了基準を定義できるか? できない場合、不適切
  2. 客観的な検証方法があるか?(テスト/ビルド/タイプチェック)ない場合、不適切
  3. このタスクは継続的な人間のフィードバックを必要とするか? はいの場合、不適切

3つの回答がすべて「いいえ」なら、Ralph を実行してください。


方法 3:強化版 Ralph

これは公式 Ralph のコミュニティによる強化実装です。frankbria/ralph-claude-code プロジェクトはより強力な安全メカニズムを追加しています。

追加機能

強化版 Ralph はいくつかの追加安全機能を追加しています。

第一は二重終了条件です。公式 Ralph は完了マーカーのみを確認しますが、強化版は完了マーカーと明示的な EXIT_SIGNAL の両方を要求してから停止します。これは Claude が完了マーカーを出力しても、明示的な終了が現れない限りループが追加検証のために続行できることを意味します。

第二はレート制限です。デフォルトは1時間あたり100回の実行で、バグが無限ループを引き起こした場合の API 請求額の急増を防ぎます。この制限は調整可能です。

第三はスマートサーキットブレーカーです。システムが完了マーカーを5回連続で検出した場合、強制停止します。これはループが正しく終了しない稀なエッジケースを防ぎます。

第四はリアルタイムダッシュボードです。強化版 Ralph は現在の反復、タスク進捗、推定コストを表示するコマンドラインダッシュボードを提供します。

インストール

GitHub からクローンして強化版 Ralph をインストールします:

bash
git clone https://github.com/frankbria/ralph-claude-code.git
cd ralph-claude-code
./install.sh

インストールスクリプトが必要なファイルと設定を自動的にセットアップします。

使用方法

強化版 Ralph の使用は2つのステップです。まず ralph-setup でプロジェクトを初期化します:

bash
ralph-setup my-project

これによりプロジェクトに必要な設定ファイルが作成されます。次に ralph loop でループを開始します:

bash
ralph loop

設定ファイル

強化版 Ralph は .claude/ralph-config.json を使用します:

json
{
  "maxIterations": 50,
  "rateLimitPerHour": 100,
  "completionPromise": "TASK_COMPLETE",
  "exitSignal": "EXIT_NOW",
  "costAlertThresholds": [10, 50, 100]
}

maxIterations は最大ループ回数です。rateLimitPerHour は時間あたりのレート制限です。completionPromise は完了マーカーテキストです。exitSignal は明示的な終了信号です。costAlertThresholds は予算警告レベルを定義します。


方法 4:エージェントチーム(並列マルチエージェント)

タスクが十分に大きい場合、単一の Claude では不十分です。「チーム協力」が必要です。

エージェントチームは、複数の Claude インスタンスが並列に実行し、共有タスクリストと依存関係を通じて調整する高度な機能です。これは非常に大規模なプロジェクトに適しています。Nicholas Carlini の実験では、16の並列エージェントが2週間で100,000行以上のコードを生産し、Linux カーネルをコンパイルできる C コンパイラを構築しました。

エージェントチームはより複雑で、次のセクションで詳しく説明します:「3.3 エージェントチーム マルチエージェント協力」。


方法 5:バックグラウンドタスク(Ctrl+B)

これはシンプルで実用的な非ブロッキング実行方法です。

基本操作

使用方法は簡単です。Claude がタスクを開始したら、Ctrl+B を押してバックグラウンドにプッシュします。

例えば、「全テストスイートを実行して」と言います。Claude が実行を開始します。Ctrl+B を押すと、Claude が「タスクをバックグラウンドにプッシュしました(ID: task_abc123)」と応答します。その後、続けて「その間、このログファイルを分析して」と言えます。テストがバックグラウンドで続く間、Claude はログを分析できます。

バックグラウンドタスクの表示

バックグラウンドタスクを確認するにはいくつかの方法があります。/tasks を使用してタスク ID、状態、開始時刻を含むすべてのタスクを一覧表示します。Ctrl+T を押して素早いステータスサマリーを確認します。また、タスクをフォアグラウンドに戻してライブ出力を検査することもできます。

適したシナリオ

バックグラウンドタスクは典型的な状況に適しています:

第一に、長時間実行されるテスト。完全なスイートは数十分かかる場合があり、バックグラウンドモードはブロックを回避します。

第二に、大規模プロジェクトのビルド。ビルドパイプラインは他の作業を続ける間に実行できます。

第三に、一括ファイル操作。一括リネームやフォーマットなど。

第四に、同期的に待ちたくないものすべて。


安全メカニズム:無限ループの防止

自動化されたループシステムには保護を含める必要があります。そうしないと制御を失う可能性があります。

ハードリミット

最も基本的な保護は --max-iterations(最大ループ回数)の設定です。これは必須です。完了状態に関係なく、タスクはこの制限で停止し、無限の API 支出を防ぎます。

時間制限を適用することもできます。例:4時間後に自動停止。また、支出閾値(例:10 USD、50 USD、100 USD)で一時停止して通知する予算アラートを設定することもできます。

インテリジェント検出

スマートなデッドループ検出を追加できます。例えば、最近のコミットに意味のある変更が含まれているかを確認:

bash
if [ $(git diff HEAD~5 | wc -l) -eq 0 ]; then
    echo "最近5つのコミットに実質的な変更がありません。ループの可能性"
    exit 1
fi

最近の差分が最小限の場合、システムがスタックしている可能性があり、アラートと共に停止すべきです。

コストアラート

設定にコストアラート閾値を設定します:

json
{
  "costAlertThresholds": [10, 50, 100],
  "alertAction": "pause_and_notify"
}

支出が10、50、または100 USD に達すると、システムが一時停止して通知し、続行するかどうかを決定できます。

手動チェックポイント

重要なタスクには手動チェックポイントを追加します:

bash
if [ $((iteration % 10)) -eq 0 ]; then
    read -p "$iteration 反復を完了しました。続けますか?(y/n)" answer
    if [ "$answer" != "y" ]; then
        break
    fi
fi

これは10回の反復ごとに確認のために一時停止し、適時の人間の介入を可能にします。


実践ビルド:Ralph Loop で完全な BBS フォーラムを構築

完全な例を使用して Ralph Loop の力を示しましょう。ユーザー認証、投稿、プロフィールセンター、管理バックエンドを含む BBS スタイルのフォーラムシステムをゼロから構築します。

プロジェクト目標

完全に機能する BBS フォーラムシステムを構築します:

ユーザー側の機能:

  • ユーザー登録、ログイン、ログアウト
  • 投稿リストの閲覧(ページネーション)
  • 投稿詳細の表示
  • 新規投稿の発行
  • コメント機能
  • プロフィールセンター(自分の投稿表示、プロフィール更新)

管理バックエンドの機能:

  • 管理者ログイン
  • ユーザー管理(BAN/BAN解除)
  • 投稿管理(削除/ピン留め)
  • コメント管理
  • システム統計

技術スタック:

  • バックエンド:Node.js + Express + SQLite
  • フロントエンド:React + React Router + Axios
  • 認証:JWT トークン
  • スタイリング:Tailwind CSS

準備

まず Ralph Wiggum プラグインをインストールします:

bash
claude /plugins:add ralph-wiggum

Ralph Loop 開始

それでは Ralph Loop を起動してプロジェクト全体を構築します:

bash
/ralph-wiggum:ralph-loop "
TDD を使用してゼロから完全な BBS フォーラムシステムを構築してください。

プロジェクト構造要件:
- backend/ ディレクトリ:Express API サーバー
- frontend/ ディレクトリ:React フロントエンドアプリ
- 両ディレクトリに独自のテストを含む

バックエンド要件:
- Express フレームワークを使用
- SQLite ストレージ(better-sqlite3)
- JWT 認証(jsonwebtoken + bcrypt)
- user テーブル:id, username, password, email, role, createdAt
- post テーブル:id, title, content, authorId, category, pinned, createdAt
- comment テーブル:id, content, postId, authorId, createdAt

バックエンド API エンドポイント:
- POST /api/auth/register - ユーザー登録
- POST /api/auth/login - ユーザーログイン
- GET /api/posts - 投稿リスト取得(ページネーション + カテゴリフィルター)
- GET /api/posts/:id - 投稿詳細取得
- POST /api/posts - 投稿作成(認証必要)
- PUT /api/posts/:id - 投稿編集(作成者または管理者)
- DELETE /api/posts/:id - 投稿削除(作成者または管理者)
- POST /api/posts/:id/comments - コメント追加(認証必要)
- GET /api/user/profile - プロフィール取得(認証必要)
- PUT /api/user/profile - プロフィール更新(認証必要)
- GET /api/admin/stats - 管理者統計(管理者のみ)
- GET /api/admin/users - ユーザーリスト(管理者のみ)
- PUT /api/admin/users/:id/ban - ユーザーBAN(管理者のみ)

フロントエンドページ要件:
- /login - ログインページ
- /register - 登録ページ
- / - ホームページ(投稿リスト)
- /post/:id - 投稿詳細
- /new - 投稿発行
- /profile - プロフィールセンター
- /admin - 管理パネル(管理者権限必要)

管理パネル機能:
- ユーザー管理(表示、BAN、BAN解除)
- 投稿管理(表示、削除、ピン留め)
- コメント管理(表示、削除)
- システム統計(ユーザー数、投稿数、コメント数)

TDD 要件:
- 先にテストを書いてから実装
- 各機能に対応するテストが必要
- バックエンドは Jest、API テストは全エンドポイントをカバー
- フロントエンドは Vitest、コンポーネントテストは主要機能をカバー
- 認証ミドルウェアにテストが必要

受け入れ基準:
- npm test(バックエンド)が通る
- npm test(フロントエンド)が通る
- フロントエンドが正常に起動して動作する
- バックエンド API が正しく応答する
- 一般ユーザーと管理者間の適切な権限分離
- コードが ESLint チェックを通過

完了後に出力:<promise>BBS_SYSTEM_COMPLETE</promise>
" --max-iterations 150 --completion-promise "BBS_SYSTEM_COMPLETE"

予想時間

複雑さに基づいて:

手動コーディングの場合:約40-60時間(スキーマ設計、認証システム、フロントエンド/バックエンド統合、テストを含む)

Ralph Loop 使用の場合

  • ベースバージョン(コア機能):約3-5時間
  • フルバージョン(管理バックエンド + テスト):約6-10時間

進捗モニタリング

Ralph Loop 実行中、いくつかの方法で進捗をモニタリングできます:

反復回数:Ralph は現在と最大の反復回数を表示し、残り時間の見積もりに役立ちます。

ログ:Claude が現在何をしているかを見ることができます。スキーマ設計、API 作成、コンポーネント構築、バグ修正など。

テスト状態:すべてのテスト実行結果が表示されます。合格するテストが増え、失敗するテストが減ります。失敗が減り始めると、プロジェクトが完成に近づいています。

完了後の検証

Ralph が完了マーカーを出力した後、手動検証を行います:

bash
# バックエンドテスト
cd backend
npm test

# フロントエンドテスト
cd frontend
npm test

# バックエンド起動
cd backend
npm start

# フロントエンド起動(別ターミナルで)
cd frontend
npm run dev

ブラウザを開いてテストします:

  1. 新規ユーザー登録
  2. ログイン
  3. 投稿閲覧
  4. 新規投稿発行
  5. コメント追加
  6. プロフィールセンターを開く
  7. ログアウトして管理者としてログイン(デフォルトアカウント:admin/admin123)
  8. 管理バックエンド機能をテスト

注意事項

Ralph Loop は強力ですが、以下の点に留意してください:

第一に、より詳細なプロンプトがより良い結果を生みます。 曖昧なプロンプトは修正により多くの反復を必要とします。

第二に、合理的な反復制限を設定してください。 BBS システムは複雑です;少なくとも100回の反復を推奨します。

第三に、TDD が推奨されます。 先にテストを書くことでデバッグ時間を大幅に削減できます。

第四に、最終的な手動検証が必要です。 AI はエッジケースや特殊なシナリオを見落とす可能性があります。特にセキュリティに敏感なパスで。

第五に、スキーマ設計に細心の注意を払ってください。 Ralph は堅牢なスキーマに到達する前にいくつかの反復が必要な場合があります。


方法の比較と選択

各方法には独自の特徴があり、異なるシナリオに適しています。

While True ループが最もシンプルです:わずか5行で実行でき、素早い実験とプロトタイプに適しています。しかし制限があり、真の完了を検出できず、反復制限のみに依存します。

Ralph Wiggum はほとんどのシナリオに対する一般的な推奨です。完全な Stop Hook メカニズム、完了マーカーチェックのサポート、公式サポート、充実したドキュメントがあります。

強化版 Ralph は本番環境に適しており、二重終了条件、レート制限、スマートサーキットブレーカーがあります。

バックグラウンドタスクはシンプルな非ブロッキング実行に便利です:Ctrl+B を押すだけ。しかし単なるバックグラウンド実行であり、反復ループのオーケストレーションではありません。


まとめ

Claude Code を長期間働かせるための核心的なアイデアはシンプルです:「一度で完了して」と頼むのではなく、「真の完了まで挑戦し続けて」と頼んでください。

すべての方法は根本的に同じことをしています:Claude にタスクを与え、実行させ、完了が本当かどうかを確認し、そうでなければ次のラウンドを続けます。

どの方法を選ぶかはあなたのニーズによります。

シンプルで迅速にしたい場合、While True ループを使用してください。5行で実行できますが、機能は限定的です。

一般的な推奨が欲しい場合、Ralph Wiggum を使用してください。公式サポート、完全な機能、ほとんどの場合に適しています。

本番使用の場合、強化版 Ralph を使用してください。追加の安全メカニズムがあり、より信頼性が高いです。

(エージェントチームのマルチエージェント協力については、次のセクションを参照してください:「3.3 エージェントチーム マルチエージェント協力」。)

この章が Claude Code をより効果的に使用するのに役立ち、AI が単なるチャットボットではなく真の生産性ツールになることを願っています。


参考文献

公式リソース

コミュニティプロジェクト

記事とチュートリアル

英語リソース

中国語チュートリアル

実践ケーススタディ