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

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

ラルフループ（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倍安かった

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

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

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

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

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

**原理1: キャッシュはプロンプトの前半部（prefix）をまるごと保存する。**Claude APIのプロンプトキャッシング⁴は、プロンプトの先頭からの連続した区間をキャッシュします。内容のハッシュがキーなので、バイト単位で同一のprefixが再び来ると、モデルは再処理せずにサーバーに保存された状態をそのまま呼び出します。usageフィールドの cache_creation_input_tokens は今回のリクエストで新たにキャッシュに書き込んだトークン、cache_read_input_tokens はキャッシュヒットで読み込んだトークンです。

**原理2: エージェントの対話は構造的にキャッシュ親和的である。**エージェントの対話はappend-onlyで蓄積されます。以前のターンを修正せず後ろに追加するだけなので、直前までの履歴全体が常に安定したprefixになります。結果として毎ターン「以前のすべて = キャッシュ読み込み、今回のターンの新しい入力と出力だけが正価」で課金されます。Claude Codeはシステムプロンプト、ツール定義、対話履歴を自動的にキャッシュするので、ユーザーが別途設定するものはありません。

原理3: キャッシュ読み込みは正価の0.1倍である。キャッシュ書き込みは基本inputの1.25倍（5分TTL基準）とわずかな割増がつきますが、読み込みは0.1倍程度にすぎません⁵。しかも5分のTTLはヒットするたびに無料でリセットされるため、エージェントが5分以内にターンを続けている限り、キャッシュはセッション中ずっと生きています。一度でもヒットすれば損益分岐点を超える構造です。

**原理4: キャッシュはセッションではなくprefixの内容にキーイングされる。**新しいセッションが高くつく正確な理由はここにあります。システムプロンプトやツール定義のようにセッション間で共通の部分（上で測定した約20.6Kの起動税の領域）はTTL内であれば再利用され得ますが、対話履歴と読み込んだファイルはセッションごとに異なるため、その部分は毎回キャッシュ書き込み（1.25倍）で再構築されます。またキャッシュは tools → system → messages の階層構造なので、ツール定義やモデルを変えるとその下のすべてが無効化されます。

この四つの原理を実測に当てはめると、数字が説明できます。ラルフの単一セッション（112メッセージ）はcache readが840万トークンに達しました。同じコンテキストを112回再処理していたら発生していたコストが、0.1倍で吸収された痕跡です。一方PTEはセッションごとにprefixが新たに始まるため、cache_creationが204万トークン（ラルフの8.7倍）に膨れ上がりました。

billable指標はcache readを除いた近似値なので、実際の請求額に近づけるためOpusの単価（input $5/M、output $25/M、キャッシュ書き込み $6.25/M、キャッシュ読み込み $0.5/M）で換算すると、次のようになります。

（表の「PTE + スキル」条件は4章で扱います。）

ドル基準でもラルフループはPTEの1/6.8のコストです。一つ注目すべき点は、単一セッションでもcache readが最大のコスト項目（ラルフの53%）だということです。0.1倍とはいえ毎ターン履歴全体を読むので、セッションが長くなるほどコストは二次曲線で累積します。ラルフループにもタダ飯はありません。適切なタイミングでの /compact が推奨される定量的な根拠です。

4. 分割が避けられないとき: スキル式の段階的開示

課題が単一セッションのコンテキストに収まらないなら、分割は避けられません。その場合の処方も実験しました。同じPTEワークフローにスキル（Skill）式の段階的開示を適用し、計画セッションがドメイン別の契約（エラー文字列、検証順序、共有インフラの規約）を200行以下のスキル文書として書いておき、各タスクセッションは必要なスキルだけをその都度ロードするようにしました。

ワークフローは同一で、コンテキスト構造だけを変えたのに**39.3%減りました。**タスクセッションが読むコンテキストが「自分の仕様 + 必要なスキル」に限定されたことで繰り返し読み込みが消え（Read 49回 → 25回、スキル呼び出し41回）、契約が明示されていたおかげで検証ゲートを初回で通過し、手戻りコスト336K（約34万）トークンがまるごと消えました。

興味深いのは反対側の実験です。同じスキルを単一セッションのラルフに提供した場合は、効果を確認できませんでした（n=2、平均差 +3.5% が条件内の変動幅200Kに完全に埋もれた）。理由は明確でした。課題全体を一人でこなすセッションはどのみちすべての契約が必要なので、スキルのツール呼び出しは0回 — セッションの序盤にスキル文書をすべて読んでしまったのです。段階的開示の節約メカニズムは、セッションが全体コンテキストの部分集合だけを必要とするときにのみ機能します。裏を返せば、単一セッションのラルフループはコンテキスト構造にこれ以上手を加える余地もなく、すでにキャッシュの観点では最適に近いということです。

5. ノイズの大きさを知るべき理由

別の実験では、「全工程を英語で進めれば韓国語よりトークンが少なく済む」という仮説も検証しました。静的な測定では効果は実在します。同じ内容の文書をトークン化すると、韓国語は散文基準で2.76倍、表とコードの混在基準で1.39倍大きくなります。しかし実際の作業では、言語効果（平均差 約29K）がrun間の軌跡の変動（最大138K）に埋もれ、判定不能でした。

同一条件で2回実行したrunがトークン基準で1.7倍（191K vs 329K）、四つ目の実験では2倍（199K vs 400K）まで開きました。エージェントが仕様のエッジケースをどれだけ深く掘り下げると「決心」するかが、言語よりはるかに大きなコスト変数だったのです。成果物の大半が言語中立的なコードであることも、言語効果の上限を下げました。

この観察はそれ自体に実務的な含意があります。エージェントの作業軌跡の変動は±数十万トークンの定常ノイズなので、10%程度の節約テクニックは一、二回の実行比較では検証できません。誰かが「この設定でトークンが15%減った」と言うなら、まず何回実行した平均なのかを尋ねるべきです。逆にラルフループの8.7倍やスキルの-39.3%のような効果はこのノイズ帯域を数倍上回るので、一度の実行でも方向が覆ることはありません。

結論

四つの実験を貫く結論は一つです。仕様が固定された実装段階において、**トークンコストの支配変数はワークフローの精緻さではなく、コンテキスト（キャッシュ）の再利用です。**ラルフループの9倍の効率はループ自体の魔法ではなく、「append-only履歴 = 安定したprefix = 0.1倍での再利用」というキャッシング構造の直接的な帰結です。実務指針としてまとめると次のようになります。

1. **実装するものが決まっている課題が単一セッションに収まるなら、単一セッションで回すこと。**セッションを分けた瞬間に起動の固定費とコンテキスト再構築のコストが累積し、同じ課題が6〜9倍高くなります。
2. **分割が避けられないなら、コンテキストをスキルとして構造化すること。**各セッションが必要な部分集合だけをロードするようにすれば、分割の税金を40%近く減らせます。ただし、全体のコンテキストが必要な単一セッションには効果がありません。そちらはすでに最適です。
3. **非常に長い単一セッションは再び高くつく。**cache readはタダではなく0.1倍の課金であり、二次曲線で累積します。適切なタイミングでの /compact は定量的に正当化されます。
4. **文書の言語（韓国語/英語）のような10%水準の変数は、この二つの決定よりはるかに小さい。**run間の変動のほうが大きいので、ワークフローとコンテキスト構造から固めるのが順序です。

計画が無意味だという話ではありません。この結果は仕様が固定された実装段階に限られ、要件定義や設計のように探索と合意そのものが目的となる段階にそのまま一般化することはできません。またPTEが残した計画書、インターフェース契約、タスクごとの完了記録は、保守と引き継ぎの観点でラルフが作れない資産です。ただし実装段階に関する限り、最も単純に見える方式がキャッシング構造と正確に噛み合い、最も安く済みました。トークンが組織のボトルネックとなった時代に、コスト構造を実測なしに直感で判断することこそが、最も高くつく選択です。