意外にも9倍安いラルフループ - コンテキストキャッシングの経済学

Sun, 26 Jul 2026 10:00:00 +0900

ゴールだけを与えて完了するまで回す単一セッションのループが、計画ベースのワークフローの1/9のコストで同じ課題を完走しました。秘訣はループではなく、キャッシュにあります。

チョン・ドヒョン - ROBOCO首席コンサルタント

ラルフループ（Ralph loop）は単純な方式です。ゴールと完了条件だけを明示し、単一セッションでエージェントが完了判定を通過するまで自律的に反復させます。計画書も、タスク分割も、セッション間の引き継ぎ文書もありません。一見すると無計画で非効率に見えます。

バイブコーディングが標準になるにつれ、多くの組織がトークン不足に直面しています。以前の記事でトークン管理戦略を扱いましたが¹、そのときの処方はほとんどが経験則でした。そこで私たちは経験則を検証するための実験リポジトリ vibecoding-token-experiments² を作りました。トークン使用に関する仮説をカタログとして管理し、RealWorld App³ のバックエンド実装という固定のベンチマーク課題の上で、ワークフロー戦略・トークン習慣・言語という三つの軸の仮説を、統制された条件で一つずつ実測するプロジェクトです。

その第一の軸がワークフロー戦略でした。実測してみると、ラルフループというこの単純な方式が、計画ベースのワークフローより約9倍安く同じ課題を完走しました。この記事では、これまでに実施した四つの実験の結果とともに、ラルフループを安くする本当のメカニズムであるプロンプトキャッシングの動作原理を説明します。

1. 実験: ラルフループ vs 計画ベースのワークフロー

共通の課題はRealWorld Appのバックエンド実装です。MediumクローンのREST APIを仕様どおりに実装し、公式APIテストを100%通過して初めて完走と認めます。モデルはClaude Opus一つに固定してモデル差による撹乱を排除し、ツールはClaude Codeを使いました。測定はセッションログのusageフィールドを集計し、billableトークン（input + output + cache_creation）を基準としました。

比較した二つのワークフローは次のとおりです。

Ralph loop: ゴールと完了条件だけを明示し、単一セッションでエージェントが完了判定を通過するまで自律的に反復させる方式
Plan-then-execute (PTE): 計画セッションでタスクを分割しインターフェース契約を文書化したうえで、タスクごとに独立したセッションを立ち上げて実装する方式

始める前に、この実験の範囲を明確にしておきます。RealWorld Appは**仕様が完全に固定された課題です。**APIスペックとテストがすでに与えられているため、エージェントがするのは純粋な実装だけです。一方、実際の開発では要件定義や設計の段階からエージェントが投入されるのが一般的で、その段階では探索と計画の成果物そのものが目的になります。したがってこの実験が測定するのは「計画が必要か」ではなく、**実装段階におけるコンテキストキャッシングの効果とラルフループのコスト効率です。**何を作るかがすでに決まっている状態で、ワークフローとコンテキスト構造がトークンコストをどれだけ左右するのかを見ます。

2. 結果: ラルフループが約9倍安かった

指標	Ralph loop	Plan-then-execute
完了判定	通過	通過
実時間	14分	49分
セッション数	1	16
outputトークン	90,877	797,845
cache_creationトークン	233,687	2,040,513
billable合計	324,775	2,839,815

両条件ともAPIテストを100%通過しました。品質は同じなのにコストが分かれたのです。ラルフループは14分、単一セッション、約32万トークンで完走しました。billable基準でPTEの1/8.7、時間では1/3.5です。PTEの計画セッション一つ（約36万トークン）だけで、ラルフループの実行全体より高くついていました。

ラルフループが回避したコストをログから分解すると、四つあります。

セッション起動の固定費: セッションを新しく開くたびに、システムプロンプトとツール定義がコンテキストに新たに組み込まれます。実測した起動税はセッションあたり約20.6Kトークン。PTEは16セッションなので33万トークンを支払い、ラルフの1回分（約2.1万）を引いた差額の約31万トークンだけで、ラルフの実行費全体（32.5万）に匹敵します。
同じファイルの繰り返し読み込み: PTEの各セッションはリポジトリを初めて見る状態から始まります。src/app.ts を7回、同じ仕様書を5回読み直しました。ラルフは一つのコンテキストの中で、一度見たものを見直しません。Read呼び出しはラルフ 2回に対しPTE 49回、検証用のBash呼び出しは35回に対し186回でした。
文書の連続性を保つ生産コスト: PTEの成果物の44%はコードではなく、セッション間の知識伝達用の文書（仕様、完了記録）でした。ラルフではこのコストがゼロです。コンテキストそのものが生きた引き継ぎ文書だからです。
アトミック分割のパラドックス: PTEでは、GETエンドポイント一つだけの最小タスクが15.6万トークンを使いました。ラルフ全体の半分に近い量です。タスクが小さくなるほど、固定費（起動税 + リポジトリ把握 + 独立した検証）の比重が支配的になります。

3. 秘訣はプロンプトキャッシングにある: その動作原理

ラルフループが勝ったのは、ループ構造が優れているからではありません。**一度作ったコンテキストをプロンプトキャッシュで最後まで再利用したからです。**このメカニズムを理解すれば、結果は当然のものになります。

Token-Optimization on ROBOCO

意外にも9倍安いラルフループ - コンテキストキャッシングの経済学

チョン・ドヒョン - ROBOCO首席コンサルタント

1. 実験: ラルフループ vs 計画ベースのワークフロー

2. 結果: ラルフループが約9倍安かった

3. 秘訣はプロンプトキャッシングにある: その動作原理