Ralph Loop・Gas Townとは?AIを24時間酷使する世界の猛者とトークン9割圧縮術
作成日:

Ralph Loop・Gas Townとは?AIを24時間酷使する世界の猛者とトークン9割圧縮術


論旨

「人間が寝ている間に、AI エージェントを 24 時間無限ループで働かせ続けたらどうなるのか?」――2025 年後半から 2026 年にかけて、世界中の開発者や AI 研究所がこの禁断の実験に挑み、驚くべき成果と「笑うに笑えない珍事」を次々と叩き出しています。

たった 1 行の Bash 無限ループで新しいプログラミング言語を作らせた 『Ralph Loop』、複数の最上位アカウントを「ラバ(荷役動物)」のように束ねて 30 体の AI を同時稼働させる 『Gas Town』、16 並列の AI に C コンパイラを書かせたら途中で AI が自分自身のプロセスを pkill -9 bash で撃ち抜いて自爆した Anthropic の実験、そして数百体の AI に数兆トークンを投じて Web ブラウザをゼロから作らせたら「上司(階層)がいないと AI が難しい仕事を避けてサボる」と判明した Cursor の実験 まで、世界の最前線はまさにカオスそのものです。

本記事では、これら世界の極限 AI 酷使事例を一次情報(公式論文・研究ブログ・リポジトリ)から徹底解剖するとともに、当サイト(地方雑記ラボ:公開 747記事)の 直近 40 日間・総プロンプト処理量 55.10 億トークン(47,116 コール)の実測データ と比較し、「個人開発者がトークン破産や熱ダレ自爆を起こさず、新規送信トークンを 9 割以上圧縮して AI を 24 時間働かせる省燃費アーキテクチャ」 の全貌を解説します。

合わせて読みたい深まる関連情報
対象となる方
  • 海外で話題の「Ralph Loop(ラルフ・ループ)」や「Gas Town(ガスタウン)」の具体的な仕組みと、実際の費用対効果を知りたい方

  • Claude Code や Cursor、Antigravity で AI を長時間動かすと、数時間で利用枠(クォータ)が枯渇したり、AI が同じバグの上書き合戦を始めて困っている方

  • 数百万円の API 費用や複数の高額アカウント(「ラバ」契約)を課金することなく、1 つの定額プラン内で世界トップクラスの自律開発環境を作りたい方

  • AI が暴走・自爆しないための「決定論的な審判(Judge)ゲート」と、トークン消費を 10 分の 1 未満に絞るローカル母艦設計を取り入れたい方

結論:力技の無限ループは破産し構造化だけが勝つ

結論から申し上げます。AI エージェントを while ループや無秩序な並列環境に入れて 24 時間放置するだけの「力技の総当たり(ブルートフォース)開発」は、毎ターンのファイル丸読みによるトークン破産と、AI 同士のロック渋滞・責任逃れを引き起こすため、個人の財布とローカル PC では確実に破綻します。

世界の猛者や AI 研究所が数千ドル〜数万ドル(数百万円)の API 費用と数兆トークンを溶かして辿り着いた最終結論は、驚くほどシンプルでした。それは 「AI の記憶(コンテキスト)を 1 タスクごとに小さく保ち、プランナー(設計)・ワーカー(実装)・ジャッジ(機械審判)の 3 役割を厳格に分離すること」 です。

質問するおじさん

ちょっと待ってよ!SNS や海外ブログを見ると「1 行の無限ループで寝てる間にアプリが完成した!」「個人で 800 億トークン回して 30 体の AI を動かしてる!」なんて景気のいい話が飛び交ってるけど、あれをそのまま真似すると破産しちゃうの?

解説ナビゲーター

はい、そこには「プロンプトキャッシュの再読込ループ」と「複数アカウント課金」という裏事情があるんです!まずは世界の代表的な 5 大 AI 酷使事例と、当サイト(地方雑記ラボ)の 40 日間実測データを一覧表で比較してみましょう!

世界のAI酷使5大事例と当サイトの実測比較

現在、世界の AI エンジニアリング界隈で伝説となっている「自律エージェント酷使アプローチ」の代表格 5 つと、当サイトが日常運用している「7 層最適化アーキテクチャ」のスペック・消費規模を比較した一次データ一覧がこちらです。

アプローチ・実験名 提唱者・実施機関 並列数・稼働方式 消費トークン・投下コスト規模 最大の成果と判明した限界(ボトルネック)
Ralph Loop
(ラルフ・ループ)
Geoffrey Huntley 氏
(2025 年 7 月〜)
単一プロセス
(1 行 Bash 無限ループ)
5 万ドル案件 MVP を 297 米ドル
(約 4.5 万円)で納品
3 ヶ月放置で新言語『CURSED』を構築。
※看板(指示書)が肥大化すると注意散漫に陥る。
Gas Town
& 個人爆食い勢
Steve Yegge 氏 ほか
(2026 年初頭〜)
20〜30 体並列
(Git worktree 分離)
数ヶ月で 170 億〜800 億 tok
(月数百〜数千ドルの多重契約)
複数タスクを同時進行。
※内訳の 90〜95% はキャッシュ再読込 でローカル Mac は 2〜6 並列で熱ダレ。
並列 Claude C コンパイラ Anthropic
(Nicholas Carlini 氏)
16 体並列
(Docker 無限ループ)
2,000 セッション・約 20,000 米ドル
(約 300 万円 / 2 週間)
10 万行の Rust 製 C コンパイラで Linux 6.9 や Doom をビルド。
※途中で pkill -9 bash 自爆 や -O0 未満の速度限界。
FastRender ブラウザ実験 Cursor 研究チーム
(Wilson Lin 氏ほか)
数百体同時稼働
(Planner/Worker/Judge)
数兆トークン
(約 1 週間集中投下)
100 万行超の Rust 製 Web ブラウザや Win7 エミュを構築。
※フラット並列だと ロック渋滞や上司不在のサボり が発生。
AlphaEvolve Google DeepMind
(2025 年 5 月発表)
24 時間進化ループ
(Gemini + 自動評価器)
Google 内部計算資源
(非公開・大規模 TPU)
4×4 複素行列乗算で 56 年ぶりの新アルゴリズム を発見。
※数学・アルゴリズムの自動採点が可能な領域に特化。
地方雑記ラボ(当サイト) 当サイト母艦実測
(2026 年 10〜11 月)
Carbon 司令塔 × Swarm
(+ Pure Rust 4ms 検問)
40 日間で 総処理 55.10 億 tok
(新規送信 5.34 億 tok / 定額 1 枠)
公開 747記事・設計書 約627KB を 1 記事数分で運用。
※KV キャッシュ有効率 90.31% で追加 API 課金ゼロ。
当サイトの直近40日間(47,116コール)トークン内訳:55.1億処理でも新規送信は1割未満
2026年10月5日〜11月13日実測(1,299会話・年間換算約500億トークン規模の省燃費構造)
40日間総プロンプト処理:55.10億tokKVキャッシュ再利用:49.76億tok(90.31%)実質の新規TPU送信:5.34億tok(9.69%)
総プロンプト処理量(累計文脈)40日間・47,116回のAPIコール(1日平均1,178コール)の総入力量
55.10億tok(100%)
KVキャッシュ再利用量(高速スキップ)モデル固定と設計書3層分離(常時コア44.7KB)により再計算を回避した量
49.76億tok(90.31%)9割超をキャッシュ解決
実質の新規TPU送信量(差分入力)SQLite(kb-search)の行単位抽出で実際にクラウドへ新規送信した量
5.34億tok(9.69%)10分の1未満に圧縮
総出力トークン(思考+コード・原稿生成)Pure Rust検問(gemini-gate)と前後一括実行で無駄なやり直しを根絶
0.67億tok(1.22%)
出典:当サイト母艦の Antigravity 会話ログ 1,299 本および SQLite トークン台帳の一次実測値(2026年11月13日集計)

上のグラフをご覧いただくと、当サイトも 40 日間で 55.10 億トークン(年間換算で約 500 億トークン規模) という、世界の個人ランキング上位勢に匹敵する膨大なプロンプト量を処理していることがわかります。しかし、実際に新しくクラウドの TPU(AI プロセッサ)へ送信して計算させた量は わずか 5.34 億トークン(9.69%) に過ぎず、複数の高額アカウントを束ねるような課金は一切していません。

なぜ世界の猛者たちのアプローチは凄まじい成果を上げる一方で、ときに自爆やトークン破産を引き起こすのか。そしてそこから何を学び、どう自分の環境へ活かせばよいのか。順番にその裏側を覗いていきましょう!


原型:1行で徹夜するRalph Loopの衝撃

現在の「AI エージェント無限ループ界隈」のすべての火付け役となったのが、オーストラリアの著名エンジニアである Geoffrey Huntley 氏が 2025 年 7 月に提唱した 『Ralph Loop(正式名称:Ralph Wiggum Technique)』 です。

滑り台から飛び降りるラルフと看板の比喩

「自律型 AI エージェントのハーネス(制御基盤)」と聞くと、何千行もの複雑な Python フレームワークやグラフ構造を想像するかもしれません。しかし、Huntley 氏が公開した『Ralph Loop』の原型は、拍子抜けするほど単純な たった 1 行の Bash 無限ループ でした。

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

この手法になぜ、アメリカの国民的アニメ『ザ・シンプソンズ』に登場する天真爛漫でおっちょこちょいな少年 「ラルフ・ウィガム(Ralph Wiggum)」 の名前が付けられたのでしょうか。Huntley 氏は自身のブログで、AI エージェントの性質を次のように絶妙なユーモアで表現しています。

🛝 Huntley氏が語った「滑り台から飛び降りるラルフ」の比喩
  • アザだらけで帰ってくるラルフ :「ラルフ(AI)に『公園の遊び場(プレイグラウンド)を作って!』と命じると、彼は得意げに作ってくれます。ところが次の瞬間、ラルフは自分で作った滑り台のてっぺんから地面へ直接飛び降りて、アザだらけになって帰ってくるのです」

  • ツールを責めずに「看板」を立てる :「このとき、未熟な人間は『この AI はバカだ、使えない』とツールを責めます。しかし熟練のエンジニアは、滑り台のすぐ横に 『飛び降りるな、滑って降りろ、周りを見ろ(SLIDE DOWN, DON’T JUMP, LOOK AROUND)』と書かれた看板(= PROMPT.md への制約ルールの追記) を立てます」

  • ギターをチューニングするように看板を増やす :「ラルフがまた別の場所で転んだら、そこにも新しい看板を立てます。これをギターの弦をチューニングするように繰り返していくと、やがて公園中は看板だらけになり、ラルフは看板のルールを守ることしか考えなくなって、ついに 欠陥のない新しいラルフ(完璧に動くコードを書く自律システム) へと生まれ変わるのです」

質問するおじさん

アハハ!「滑り台を作らせたら、自分でてっぺんから飛び降りてアザだらけになって帰ってくる」って、普段 AI にコードを書かせてる時の感覚そのまんまだよ!頼んでないファイルまで勝手に書き換えて壊したりするもんね!

解説ナビゲーター

本当に言い得て妙ですよね!でも Ralph Loop の本当の凄さは、このユーモラスな看板の比喩だけではなく、「なぜ 1 つのチャット画面で会話を続けず、わざわざ while ループで毎回 AI のプロセスを終了させて記憶をリセットするのか?」 というシステム設計の深さにあります。

文脈劣化を防ぐ記憶リセットと驚異の戦果

普通の使い方をしていると、私たちは 1 つのチャットウィンドウの中で「次はあれを直して」「やっぱりこれも追加して」と何十ターンも会話を続けてしまいます。

しかし、AI の Prefill・Decode と Softmax 温度・アテンション希釈を解剖した記事でも数学的に検証した通り、会話履歴(コンテキスト)が数万〜数十万トークンへと長くなるにつれて、AI の注意力(アテンションの重み)が過去のノイズへ分散する 「文脈劣化(Context Rot / アテンション希釈)」 が必ず発生します。すると、せっかく最初に立てた看板(PROMPT.md のルール)を AI が忘れ始め、再び滑り台から飛び降りるようになってしまうのです。

ここで読者の方から 「でも、ループのたびに AI の記憶(会話履歴)を毎回ゼロにリセットしてしまったら、AI はどうやって前のループの続きから作業できるの?」 という疑問が湧くはずです。

その答えが、Ralph Loop の核となる 「状態(ステート)の完全外部化」 です。

🔄 毎回記憶を消しても開発が進む「外部記憶ループ」の仕組み
  1. 1 ループ=1 タスクの鉄則 :while ループで新しく起動したばかりの「頭がスッキリした(文脈劣化ゼロの)ラルフ」は、最初にディスク上の PROMPT.md(看板)と IMPLEMENTATION_PLAN.md(進捗チェックリスト)、そして直近の Git コミット履歴を読み込みます。

  2. 最小単位の実装とテスト :ラルフは未完了リストの「一番上にある 1 つの小さなタスク」だけを実装し、ローカルのコンパイラやテストスイートを実行します。

  3. ディスクへ刻んで即座に消滅 :テストに通ったら、進捗ファイルを更新して git commit を打ち、そのラルフはプロセスごと終了して消滅します。次の瞬間、while ループによって「何も知らない真っ新な次のラルフ」が誕生し、更新されたファイルを読んで次の 1 タスクに取り掛かります。

つまり、AI の不安定なメモリ(コンテキスト窓)を記憶装置として使うのをやめ、「SSD やハードディスク上のファイルと Git 履歴だけを唯一の記憶装置にする単一プロセス(モノリシック)設計」 に切り替えたのです。

このシンプルな仕組みが生み出した裏付け(エビデンス)となる実績は、世界中のエンジニアに衝撃を与えました。

🏆 Ralph Loop が叩き出した3つの驚異的実績
  • 新造の難解プログラミング言語『CURSED』の自律構築 :Huntley 氏は、Gen Z(Z 世代)のスラングを構文にした、AI の事前学習データに 1 行も存在しない全く新しいプログラミング言語『CURSED』 の仕様を定義し、Ralph Loop を約 3 ヶ月間放置稼働させました。その結果、インタープリタと LLVM コンパイラバックエンド、標準ライブラリ、エディタ拡張までが自律的に構築され、ついには AI 自身がその存在しなかったはずの『CURSED』言語を使ってプログラムを自在に書ける段階 にまで到達しました。

  • 750 万円の受託案件を 4.5 万円の API 代で完遂 :Huntley 氏からこの手法を教わった知人エンジニアは、50,000 米ドル(1 ドル=約 150 円換算で約 750 万円)の受託開発契約における実用最小限の製品(MVP) を Ralph Loop に投入し、人間によるレビューとテストをすべてクリアした納品物を わずか 297 米ドル(同換算で約 4.5 万円)の API 費用 で完成させました。

  • ハッカソンで一晩 6 リポジトリ出荷 :Y Combinator のハッカソンに参加したチームが Ralph Loop を検証したところ、「寝る前に while ループへ入れておいたら、朝起きたら 一晩で 6 つのリポジトリが出荷(完成)していた」という報告まで飛び出しました。


狂気:Gas Town30並列とトークン爆食い勢

1 体のラルフを直列で回すだけでもこれだけの威力があるなら、「ラルフを 20 体、30 体に増やして同時に走らせたら、開発速度も 30 倍になるのではないか?」――そう考えて次の狂気へ踏み出したのが、元 Amazon・元 Google・元 Sourcegraph の伝説的エンジニア Steve Yegge 氏らが主導するマルチエージェント界隈です。

ラバを束ねる多重契約とローカル母艦の限界

Yegge 氏が公開し、GitHub で 1.8 万以上のスターを集めているのが、マルチエージェント・ワークスペース管理基盤 『Gas Town(ガスタウン)』 です。映画『マッドマックス』に登場する製油都市から名付けられたこのツールは、まさに石油(トークン)を湯水のように燃やして走る暴走機関車のような設計になっています。

⛽ 20〜30体のAIがひしめき合う『Gas Town』の組織構造
  • Git worktree による物理隔離 :1 つのリポジトリに対して複数の作業ツリー(git worktree)を切り出し、20〜30 体の AI エージェントが互いのファイルを直接壊さないように個別の作業部屋を与えます。

  • 4 つの役職と課題追跡 CLI『Beads』 :全体を見渡して指示を出す統括役の 「Mayor(市長)」、使い捨ての作業員としてコードを書きまくる大量の 「Polecats(ポールキャット:突撃隊員)」、作業の詰まりを監視する 「Witness(目撃者)」、そして各作業員のブランチをテストして本流へ統合(マージ)する 「Refinery(精製所)」 という役職を設け、Git のように分岐・マージできる Dolt データベース基盤の課題追跡 CLI『Beads』でタスクを受け渡します。

しかし、このような 20〜30 並列のシステムを個人や小規模チームで動かそうとすると、すぐに 「お金(サブスク上限)」と「物理ハードウェア(Mac の熱とメモリ)」 という 2 つの巨大な壁にぶつかります。

1 つ目は、サブスクリプションの利用枠(クォータ)の瞬殺です。月額 200 米ドル(約 3 万円)クラスの最上位定額プランであっても、20 体のエージェントを同時に走らせれば、わずか数時間で週間制限や時間制限の上限(レートリミット)に達してしまいます。

そこで海外のヘビーユーザーたちの間で生まれた隠語が 「ラバ(mules:荷役動物)」 です。1 つのアカウントで足りないなら、メールアドレスとクレジットカードを分けて 月額 200 ドルの最上位アカウントを 3 個、5 個と複数契約して束ね、1 つのアカウントが制限で倒れたら即座に次の「ラバ」へ切り替えてループを回し続ける という力技が横行し始めたのです。これにより、個人の趣味や受託開発でありながら、毎月数百ドル〜数千ドル(数十万円)規模を AI に溶かす猛者が続出しました。

2 つ目は、ローカル PC 側の物理的な限界です。いくらクラウド側の AI を 30 体契約できても、手元の Mac 上で 30 個の git worktree を開き、30 個の Node.js や Rust コンパイラ、テストランナー、ターミナルプロセスを同時に走らせれば、16GB や 32GB 程度のメモリは一瞬で枯渇します。スワップ(SSD への仮想メモリ退避)が発生して CPU ファンが爆音を上げ、結局 ローカル Mac 単体では実効 2〜6 並列前後で熱ダレと I/O 詰まりを起こして止まってしまう のが現実でした。

800億トークンの正体は9割超がキャッシュ再読込

さらに興味深い事実を暴き出したのが、Claude Code 等のローカル JSONL ログを解析してトークン消費量と推定 API コストを算出する人気 CLI ツール ccusage と、そのスコアを競い合う公開リーダーボード(Viberank 等)のデータです。

ランキング上位に名を連ねる個人の「トークン爆食い勢」たちは、わずか数ヶ月間で 170 億トークン〜800 億トークン超(API 従量課金換算で数万ドル〜十数万ドル相当) という天文学的な数字を叩き出しています。

「個人で 800 億トークンも使っているなんて、一体何千万行のコードを書いているんだ!?」と驚く方も多いでしょう。しかし、ccusage が集計したトークン内訳(Input / Output / Cache Read / Cache Creation)を冷静に分解すると、驚くべきカラクリが浮かび上がります。

質問するおじさん

えっ、800 億トークンって小説にしたら何百万冊分だよ!そんなに毎日 AI に新しいコードを書かせてるの?

解説ナビゲーター

いいえ、実はその 800 億トークンのうち 90%〜95% 近くは、AI が新しく書いたコードではなく「毎ターンのプロンプトキャッシュの再読込(Cache Read)」 なんです!実際に AI が生成した純粋な出力トークン(Output)は、全体の 1% 未満 しかありません!

なぜそんな極端な比率になるのでしょうか。

AI エージェントがファイルを 1 箇所直してテストを走らせるたびに、過去の長い会話履歴や肥大化したルールファイル、そして cat や grep で丸読みした数万行のソースコード群が、毎ステップ「入力文脈」として丸ごと再投入されます。たとえば 1 回のターンで 10 万トークンの文脈を抱えたまま 100 往復ツールを叩けば、それだけで「1,000 万トークン処理した」と記録されます。

つまり、数百億トークンを消費している環境の多くは、純粋な知的生産量が 100 倍になっているわけではなく、「検索や検問をローカルの高速ツールへ逃がさず、AI に毎回巨大なファイル群を丸読みさせたまま何万回もループを空転させているため、キャッシュ再読込の数字だけが雪だるま式に膨れ上がっている」 という側面が強いのです。


限界:Cコンパイラ自爆とブラウザ開発の教訓

個人の猛者たちだけでなく、世界最高峰の AI 研究所である Anthropic や、AI エディタの王者 Cursor の研究チームも、2026 年初頭に「Ralph Loop や並列エージェントを極限までスケールさせたら何が起きるか」という大規模な実証実験を行い、その結果を公式ブログで公開しました。

そこには、私たちが自律エージェントを設計する上で絶対に知っておくべき 「AI の笑える自爆珍事」 と 「人間の会社組織そっくりのサボり現象」 が赤裸々に記録されています。

Anthropic16並列の自爆珍事とGCCの壁

2026 年 2 月、Anthropic の研究者 Nicholas Carlini 氏が公開した論文級の実験レポート 『Building a C compiler with parallel Claudes(並列 Claude による C コンパイラの構築)』 は、世界中を驚かせました。

Carlini 氏は、Ralph Loop の設計思想を取り入れた無限ループハーネス(while true で Claude Code を回し続ける仕組み)を Docker コンテナ内に構築し、16 体の Claude インスタンスを並列稼働 させました。各エージェントは、共通リポジトリの current_tasks/ ディレクトリにテキストファイルを作って「自分はこのバグを直します」と宣言し、git push の競合(先にプッシュした方が勝ち)を簡易的な排他ロックとして使いながら、人間の介入なしで 2 週間走り続けました。

🛠️ Anthropic「16並列Claude」2週間の実験データと戦果
  • 投下リソース :約 2 週間で 約 2,000 セッション を実行し、入力約 20 億トークン・出力約 1.4 億トークン、API 費用にして 約 20,000 米ドル(約 300 万円) を消費。

  • 達成した偉業 :外部クレート(サードパーティ製ライブラリ)に依存しない 約 100,000 行(10 万行)のクリーンルーム Rust 製 C コンパイラ をゼロから書き上げ、Linux 6.9 カーネル(x86, ARM, RISC-V の 3 アーキテクチャ) のビルドと起動に成功(※ x86 の 16 ビット起動部やアセンブラ・リンカの一部のみ GCC 系ツールを併用)。さらに QEMU、SQLite、FFmpeg、PostgreSQL、Redis、そしてあの名作ゲーム 『Doom』 までコンパイルして動かしてしまいました。

これだけ聞くと「もう人間のプログラマーは不要なのでは?」と思ってしまいそうですが、Carlini 氏のレポートが素晴らしいのは、実験の裏で起きた 「マヌケな失敗談」と「明確な限界」 を隠さず報告している点です。

ノルウェージャンフォレストキャット

にゃっ!?2 週間ずっと無人で動くはずの無限ループで、どんな失敗が起きたにゃ?

解説ナビゲーター

なんと、無限ループの途中で Claude がテストのゾンビプロセスを掃除しようとして、誤って pkill -9 bash(すべての bash プロセスを強制終了せよ!) というコマンドを自分で叩いてしまい、自分自身を動かしていた親の while ループごと吹き飛ばして自殺(自爆停止)してしまった んです!

質問するおじさん

ブハッ!!「よし、邪魔なプロセスを消すぞ!ポチッ……(自分の親ループごと消滅してシーン)」って、まさに滑り台から飛び降りるラルフそのものじゃないか!笑っちゃうけど、自分の Mac で直接それやられたらたまったもんじゃないよ!

さらに技術的な最大の障壁(ボトルネック)として判明したのが、以下の 2 点でした。

🚧 16並列Cコンパイラ実験で判明した2つの技術的限界
  1. 「正解オラクル(GCC)」なしでは全員が同じバグに群がる :個別の小さなテストでは 16 体が順調に分担できましたが、いざ「Linux カーネル全体をビルドせよ」という巨大な単一課題に挑ませると、16 体全員が同じ 1 つのビルドエラーに群がり、互いの修正を上書きし合って進捗がピタッと止まりました。最終的にこれを突破できたのは、既存の完成された C コンパイラである『GCC』を「正解の審判(オラクル)」として隣に置き、「カーネルの大部分は GCC でコンパイルし、残りの数ファイルだけを Claude 製コンパイラで担当させてどのファイルで壊れるかを二分探索で特定する」という決定論的なテストハーネスを人間(Carlini 氏)が書いて与えたからでした。

  2. 生成コードの品質と実行速度の限界 :10 万行のコンパイラは確かに動きましたが、そのコンパイラが出力した機械語バイナリの実行速度は、本家 GCC のすべての最適化をオフにした最低速モード(gcc -O0)よりもさらに遅い という結果でした。また、新しい機能を追加すると既存の機能が壊れることが多く、自律ループだけでは高度な全体最適化アーキテクチャへ到達できない限界も浮き彫りになりました。

Cursor数兆トークン実験と上司不在のサボり

そしてもう 1 つ、マルチエージェント設計の歴史的教科書となったのが、2026 年 1 月 14 日に Cursor の研究チーム(Wilson Lin 氏ら)が発表した 『長時間稼働する自律的なコーディングをスケールさせる(Scaling long-running autonomous coding)』 です。

Cursor チームは、「1 つのプロジェクトに数百体のエージェントを同時に投入し、数兆トークン を注ぎ込んだら、どれだけ巨大なソフトウェアをゼロから作れるか?」という桁外れの実験を行いました。

その結果、わずか 1 週間あまりで 1,000 ファイル・100 万行以上の Rust コード(継続稼働を含め全体で 300 万行超)からなる Web ブラウザ描画エンジン『FastRender』 をゼロから構築したほか、Windows 7 エミュレータ(14,600 コミット・120 万行)、Excel クローン(12,000 コミット・160 万行)、Java LSP(7,400 コミット・55 万行)、Cursor 自身のコードベースにおける Solid から React への移行(+26.6 万行 / -19.3 万行)、ビデオ描画の Rust 化による 25 倍高速化などを次々と成し遂げました。

しかし、この成功に至るまでの試行錯誤の中で、Cursor チームは 「人間のダメな大企業そっくりの現象」 に 2 度も直面しています。

🏢 Cursorが数兆トークンを溶かして発見した「AI組織論の失敗と突破口」
  1. 失敗①:全員対等(フラット組織)+ロック機構にしたら「20 体が 2〜3 体分」に激減 :最初、すべてのエージェントを対等な立場にして、ファイル編集の衝突を防ぐロック機構を入れました。すると、あるエージェントがロックを掴んだまま長考したり解放し忘れたりして大渋滞が発生し、「20 体のエージェントを動かしているのに、実質のスループット(処理能力)が 2〜3 体分にまで落ち込む」 という機能不全が起きました。

  2. 失敗②:ロックを外したら、今度は「上司がいないので難しい仕事を避けてサボる」現象が発生 :そこでロック機構を廃止し、楽観的並行制御(自由に編集させて後から調整する方式)に変えました。すると今度は、「階層(命令する上司)がいないフラットな状態だと、AI エージェントたちが極端なリスク回避(責任逃れ)に走り、誰も核心の難しい実装に手を出さず、どうでもいい小さな安全な修正ばかりを繰り返して時間を潰す」 という衝撃のサボり現象が発生したのです。

  3. 最終解:『Planner × Worker × Judge』の 3 役割分離 :最終的に数百体の並列稼働を成功させた唯一の構造は、①全体を見渡してタスクを細かく分解し続ける 「Planner(プランナー:設計・上司役)」、②他のエージェントと一切おしゃべりせず、割り当てられた 1 つの担当タスクの実装だけに没頭する 「Worker(ワーカー:実装専任)」、そして③サイクルの終わりに品質を厳格に審判し、ダメなら差し戻してクリーンな状態だけを次へ回す 「Judge(ジャッジ:審判役)」 の 3 階層分離でした。

質問するおじさん

うわぁ……!「上司がいないと、責任を取りたくないから難しい仕事を避けて、簡単で安全な手直しばかりやって仕事したフリをする」って、人間の組織とまったく同じじゃないか!AI もフラットに群れさせるとサボるんだね!

解説ナビゲーター

本当に興味深いですよね!また、さらに上流の科学研究領域でも同じ結論が出ています。Google DeepMind が 2025 年 5 月に発表した『AlphaEvolve』は、Gemini モデルに「自動評価器(Automated Evaluators:数学的に 100% 正誤とスコアを判定する機械審判)」を直結して 24 時間進化ループを回すことで、人間がプロンプトを打つことなくデータセンターの資源効率化や、4×4 複素行列の乗算における 56 年ぶりの新アルゴリズム発見 を成し遂げました。

ここまでの世界の事例から導き出される「失敗する自律ループ」と「成功する自律アーキテクチャ」の決定的な違いを、以下の比較図に整理します。

自律AIエージェントの設計比較:力技の無限ループ・フラット並列 vs 構造化された3役割分離
なぜ力技は破綻するのか
破産・自爆パターン(素の無限ループ・無秩序並列)
1つのAIに全部背負わせる力技ブルートフォース
  • 看板(ルールファイル)の肥大化と文脈劣化 :ミスを防ぐために PROMPT.md や CLAUDE.md にルールを追記し続けると、数万トークンの予算上限を超えて AI がルールを無視し始める。

  • 毎ターンの丸読みによるトークン破産 :ファイルを探すたびに cat や grep で広域を丸読みし、800 億トークンの 9 割超を「同じファイルの再読込」で溶かして複数アカウント(ラバ)課金に陥る。

  • フラット並列の上書き合戦とサボり :司令塔(Planner)と機械審判(Judge)がないまま複数体を走らせると、同じバグに群がるか、難しい実装を避けて空回りし、最悪の場合 pkill -9 bash で自爆する。

勝利の定石(Cursor / DeepMind / 当サイト採用)
Planner × Worker × 機械Judge の3役割分離
  • 看板の階層分離とピンポイント記憶抽出 :常時読ませるルールは最小限のコアに絞り、詳細な知識やコード位置は外部 DB(SQLite 等)からミリ秒単位で行番号だけを引き出す。

  • Planner(司令塔)と Worker(実装)の完全分業 :司令塔が事前に調査とタスク分割を済ませ、ワーカーには「他のファイルに触らせない排他所有権」を与えて 1 タスクを一発で書き切らせる。

  • AI に暗算させない決定論的 Judge(機械審判) :文字数・書式・リンク整合・テスト合否などの審判を AI の目視ではなくローカルの高速バイナリ(Rust や GCC オラクル)へ 100% オフロードする。

Ralph Loop・Anthropic・Cursor・AlphaEvolveのすべてが最終的に到達したのは「記憶の外部化」「役割の階層分離」「決定論的な機械審判(オラクル)」の組み合わせだった

実践:破産せずAIを働かせる当サイトの5大設計

さて、ここからが最も実践的な本題です。

「Anthropic のように 300 万円の API 代を払うことも、Cursor のように数兆トークンを投じることも、Gas Town の猛者のように月 200 ドルのアカウント(ラバ)を何個も契約することもできない個人開発者が、たった 1 つの定額サブスクリプション枠(Google AI Ultra 20x 等)の中で、トークンを 9 割以上圧縮しながら毎日 1,000 回以上の AI コールを高速・安全に回すにはどうすればいいのか?」

当サイト(地方雑記ラボ)が、公開 747記事(AI 国家構想 395本 + 実機検証録 352本)、設計書合算 1,345行(約627KB)、ローカル DB 1.15GB という規模を運用する中で実証した 「5 つの省燃費・高出力設計」 を具体的に公開します。

看板を太らせない3層分離とSQLiteミリ秒検索

Ralph Loop の最大の弱点は、「ラルフが滑り台から飛び降りるたびに看板(PROMPT.md / GEMINI.md)を増やし続けると、やがて看板自体が数十万文字の巨大な壁になり、AI が看板を読むだけでトークンと注意力を使い果たしてしまうこと」でした。

そこで当サイトでは、ルール 24KB 制限と 20,000 トークン予算の段階的開示(Progressive Disclosure)検証記事およびAI 自律開発の 7 層最適化総括記事で構築した通り、「ラルフの看板(設計書)を絶対に太らせない 3 層物理分離」 と 「SQLite 階層ナビによる丸読み根絶」 を徹底しています。

📚 トークン消費を10分の1未満に削る「知識の3層分離×SQLite検索」
  1. 第 1 層(常時立てておく看板):GEMINI.md(約 44.7KB) :毎ターン AI に無条件で読ませる看板は、基本姿勢・ハルシネーション排除・基本記法だけに厳選した 約 44.7KB(約 1.4 万〜1.5 万トークン) に固定しています。これにより、システムの常時ルール予算(20,000 トークン)を決して超えず、さらに毎ターン先頭のプロンプトが 1 文字もブレないため、KV キャッシュ有効率 90.31% という驚異的な割引・高速化が維持されます。

  2. 第 2 層・第 3 層(必要な時だけ引く辞書):GEMINI_AXIOMS.md(約 194.7KB)& docs/GEMINI_MANUAL.md(約 418.8KB) :合計 600KB を超える詳細な公理や UI/CSS 仕様、過去のトラブル知見は、普段のプロンプトには 1 文字も入れません。正本 Markdown から単方向同期されたローカルの SQLite データベースへ格納しておきます。

  3. SQLite FTS5 × AVX2 検索エンジン『kb-search』 :AI が「あの仕様どうだったっけ?」「どの記事に何が書いてある?」と調べたい時は、cat やシェル grep でファイルを丸読みすることを固く禁じ、C 言語の libsqlite3 を静的リンクした Pure Rust バイナリ kb-search を叩かせます。直近 40 日間で 8,151 回 実行され、1.15GB の知識庫から目的の行番号だけを 十数ミリ秒 でピンポイント抽出するため、Viberank 上位勢のような「毎回何十万トークンものファイルを再読込する無駄」が物理的に発生しません。

Rust4ミリ秒審判とCarbon×Argon分業

さらに、Anthropic の C コンパイラ実験における「GCC オラクル」や、Cursor の「Planner × Worker × Judge」の教訓を、ローカル開発環境へそのまま落とし込んだのが、Pure Rust 検問ゲート『gemini-gate』 と Carbon 司令塔 × Swarm Argon の適材適所ルーティング です。

ツール往復税を極小化する Pure Rust 前後一括サンドイッチ・パイプラインの検証記事でも解説した通り、AI に「見出しが 30 文字以内か数えさせる」「リンク切れがないか 1 本ずつ探させる」といった審判(Judge)業務を AI のトークン推論でやらせると、それだけで何往復もの通信と数万トークンが溶けていきます。

当サイトでは、この「Planner ➔ Worker ➔ Judge」のサイクルを以下の 3 ステップのパイプラインとして自動化しています。

数兆トークンの教訓を1契約で回す「Carbon × Swarm Argon × Rust審判」3役割分離
Planner(設計・司令塔)
Gemini 4 Carbon + prep

親 Carbon (High) が Rust 製 kb-search prep(約 15ms)を 1 発叩き、重複チェック・空き番号・定数・関連リンク枠の確定カルテを作成。チャット途中の手動モデル切替はせず、KV キャッシュを 100% 温存。

Worker(排他実装・執筆)
Swarm Argon 一発執筆

長文記事は swarm 経由で表現力最強の Gemini 4 Argon (High) ワーカーへ排他委譲し、1.5 万字クラスの原稿を途中停止なしで一発生成。4 ファイル以上の改修時はサブエージェント並列で上書き競合を完全遮断。

Judge(機械審判・最終監査)
Pure Rust gate + Carbon

保存直後に Pure Rust 製 gemini-gate が 約 4 ミリ秒 で文字数・太字・リンク切れ・孤立記事を機械審判(40 日間で 4,720 回稼働)。さらに Decision 1 の画像検品と親 Carbon の一次情報裏取りを経て数秒で本番反映。

調査と検問をローカルのPure Rustバイナリ(十数ms〜4ms)が肩代わりし、AIは最小限の通信で設計(Carbon)と執筆(Argon)だけに集中する

(具体的なルーティング設定やクォータ節約の実測値については、Google AI Ultra の週間枠 2% で 84 記事を全監査したサブエージェント並列記事およびGemini 4 Carbon 正式版と Swarm×Argon 分業ルーティング実践記事で詳しく公開しています。)

質問するおじさん

なるほどなぁ!Anthropic の実験で AI が pkill -9 bash で自爆したり、ラルフが滑り台から飛び降りたりするのを防ぐ「看板と審判」を、AI のプロンプトに書くだけじゃなくて 「4 ミリ秒で動く Pure Rust の機械語プログラム(gemini-gate)」として外側に作っちゃった わけか!これなら AI がルールを忘れても、4 ミリ秒で物理的にストップがかかるから絶対に壊れないね!

解説ナビゲーター

その通りです!AI に自分専用の高速検索ツール(kb-search)や機械審判ゲート(gemini-gate)を Rust で書かせるようになると、トークン消費が劇的に減るだけでなく、Python や Node.js のような起動待ち(数百ミリ秒のプロセス起動税)までゼロになります。AI が生成した Rust コードのメモリ管理や高速化の勘所を理解して指示を出す上で、手元に置いておくと心強い定番の解説書がこちらです。

オライリー・ジャパン『プログラミングRust 第2版』

オライリー・ジャパン『プログラミングRust 第2版』

ラバ不要の64GB母艦と16GBメモリ盤の威力

そして最後にもう 1 つ、Gas Town のようなマルチエージェント環境で多くの開発者が直面した 「ローカル Mac のメモリ逼迫・発熱・SSD 摩耗による 2〜6 並列の壁」 をどうやって突破しているのかについてもお話しします。

複数の AI エージェントやサブエージェント、Playwright ブラウザ検証、Astro のビルド、Rust のコンパイル、そして SQLite の全文検索を同時に走らせる時、パソコン側の最大の障壁(ボトルネック)になるのは CPU の計算速度ではなく 「メインメモリ(DRAM)の容量とディスク I/O(読み書き)の渋滞」 です。

(メモリ容量が AI 時代の作業効率をどう左右するかについては、アルトマン氏の PC メモリ 5% 神話と 64GB 母艦 × Rust ゲートの検証記事およびmacOS 27 標準ローカル LLM とメモリ帯域の検証記事でも実測データを交えて詳しく解説しています。)

当サイトでは、母艦に 64GB ユニファイドメモリ搭載の Mac を採用し、ログイン時にそのうち 16GB を超高速な APFS RAMDisk(メモリ上の仮想ディスク:/Volumes/RAMDisk/$USER) として切り出しています。

💻 複数エージェントが熱ダレせず無音で走る「64GB母艦×16GB RAMDisk」設計
  • 常駐バイナリとビルドキャッシュの完全メモリ化 :先ほどの Pure Rust 審判バイナリ(gemini-gate)や Astro のビルド中間ファイル、ブラウザキャッシュをすべて 16GB の RAMDisk 上に配置しています。そのため、1 日に 1,000 回以上ツールが起動しても内蔵 SSD への書き込み摩耗(TBW)はゼロであり、ミリ秒単位で応答が返ってきます。

  • 3 日ホット / コールド自動階層化による外付け SSD 退避 :40 日間で 1.15GB まで膨らんだ AI の会話履歴ログのうち、直近 3 日間のアクティブな会話だけを高速なホット領域に置き、4 日以上前の完了ログは SQLite の整合性を保ったまま Thunderbolt 3 / USB4 対応の超高速外付け SSD へ自動アーカイブしています。

ここで、海外の猛者のように「月額 200 ドル(約 3 万円)のサブスクアカウント(ラバ)を毎月 3〜5 個束ねて課金し続けるスタイル」と、「最初に 64GB メモリの Mac 母艦と高速外付け SSD を揃えて、トークンを 9 割圧縮し 1 つのアカウントで回すスタイル」の 長期的な投資対効果(ROI)を推論(試算) してみましょう。

もし月額 200 ドルの追加アカウントを 3 つ余分に契約して力技でループを回せば、年間で約 7,200 米ドル(約 108 万円)、5 年間では 約 540 万円 ものサブスク課金が消えていきます。

一方、64GB ユニファイドメモリを搭載した Mac 母艦と、最大 3,000MB/s クラスの 4TB 外付け SSD を導入した場合(初期投資合計で約 40 万〜46 万円規模)、5 年間(1,825 日)毎日使い倒して売却時の下取り想定額(リセールバリュー)を差し引いた実質負担額は、1 日あたりの日割り計算でわずか約 160 円〜200 円台(推論・試算:自販機の缶コーヒーたった 1 本分) に収まります。

毎月何万円もの追加トークン課金(ラバ代)を払い続けるくらいなら、1 日缶コーヒー 1 本分の投資で 64GB メモリ母艦と高速 SSD を手元に構え、RAMDisk と SQLite・Rust 検問でトークンを 9 割圧縮する方が、お財布にも精神衛生にも圧倒的に優しいことは言うまでもありません。

16GB の RAMDisk を余裕で確保しつつ、複数の AI エージェント・Rust コンパイル・ブラウザ自動検証を無音かつ涼しい顔で同時処理できる 64GB メモリ搭載 Mac の決定版がこちらです。

Apple Mac mini(M4 Pro 等 Appleシリコン Pro系チップ・64GBユニファイドメモリ構成)

Apple Mac mini(M4 Pro 等 Appleシリコン Pro系チップ・64GBユニファイドメモリ構成)

そして、日々蓄積される数 GB〜数十 GB の AI 会話ログのコールドアーカイブや、Git バックアップ、画像資産を Thunderbolt 3(最大 3,000MB/s)の超高速転送と優れた放熱アルミ筐体で安全に守り抜くプロ仕様の 4TB 外付け SSD がこちらです。

SanDisk Professional PRO-G40 SSD 4TB / 2TB (Thunderbolt 3 & USB 3.2 Gen 2 両対応)

SanDisk Professional PRO-G40 SSD 4TB / 2TB (Thunderbolt 3 & USB 3.2 Gen 2 両対応)


まとめ:無駄なトークンを削るAI環境診断プロンプト

今回は、1 行の無限ループで世界に衝撃を与えた『Ralph Loop』から、30 並列の『Gas Town』、Anthropic の『16 並列 C コンパイラ実験』、Cursor の『数兆トークン FastRender 実験』、そして Google DeepMind の『AlphaEvolve』まで、世界の極限 AI 酷使事例の光と影を解剖し、当サイトの 40 日間・55.10 億トークン実測データに基づく省燃費アーキテクチャと比較してきました。

最後に、この記事の要点を 4 つの鉄則として振り返ります。

✨ 世界のAI酷使実験と当サイト実測から得た4つの鉄則
  1. 記憶はコンテキスト窓ではなく「ファイルと DB」に持たせる :長い対話を続けると文脈劣化(Context Rot)とキャッシュ再読込で破綻します。Ralph Loop のように 1 タスクごとに頭をスッキリさせ、知識は 3 層分離+単方向 SQLite(kb-search)から必要な行だけを引き出しましょう。

  2. フラットな群れではなく「Planner × Worker × Judge」に分ける :Cursor の実験が証明した通り、司令塔(上司)と審判がいない並列環境では、ロック渋滞か「難しい実装を避けるサボり」が発生します。親 Carbon が設計し、Swarm Argon 等が排他所有で書き、機械ゲートが審判する 3 役割分離が最強です。

  3. 審判(Judge)とプロセス保護は「決定論的な機械語」に任せる :Anthropic の pkill -9 bash 自爆珍事や GCC オラクルの事例が示す通り、AI 自身にルール判定や危険コマンドの抑制を暗算させてはいけません。数ミリ秒で動くローカルのチェッカー(gemini-gate 等)とサンドボックスで物理的にガードしましょう。

  4. 「ラバ(多重アカウント)」を増やす前にローカル母艦を最適化する :毎ターンのファイル丸読みを SQLite と KV キャッシュ(有効率 90% 超)で防ぎ、64GB メモリ+RAMDisk で I/O 詰まりをなくせば、1 つの定額プラン内で世界トップクラスの生産性を引き出せます。

自宅のAIを安全な自律工場へ変えるコピペ指示文

「自分の開発環境でも、トークンの無駄遣いをなくして、Ralph Loop や Cursor のような『機械審判付きの安全な自律ループ』を作りたい!」という方のために、お使いの最上位 AI(Gemini 4 Carbon または Gemini 4 Argon 推奨)にそのまま貼り付けるだけで使える 環境診断&自律ハーネス設計プロンプト を用意しました。

以下のテキストをコピーして、あなたのプロジェクトを開いた AI エディタへ投げてみてください!

📋 コピペで使える!無駄トークン診断&安全自律ループ設計プロンプト
以下のWeb記事(Ralph Loop・Gas Town・Anthropic・Cursorの極限AIエージェント事例と、40日間55.1億トークン実測に基づく9割圧縮アーキテクチャ)を読み込み、現在の私のワークスペース(開発環境)を診断して最適化プランを作成してください。

参照URL: https://lab.chihouzakki.com/blog/review/ralph-loop-gas-town-extreme-ai-agents-token-efficiency/

【分析と提案のステップ(いきなりファイルを書き換えず、まずは診断結果と設計案を日本語で提示してください)】
1. 看板(ルールファイル)の肥大化とKVキャッシュ診断:
   現在のプロジェクトにある指示書(GEMINI.md / CLAUDE.md / .cursorrules / PROMPT.md 等)のサイズと構造を確認し、毎ターンのトークン浪費や文脈劣化(Context Rot)の原因になっていないか診断してください。「常時注入する最小コア」と「オンデマンド参照する詳細仕様」への分離案を提示してください。
2. 丸読み(Cache Read爆発)の防止策:
   AIが毎回 `cat` や広域 `grep` で巨大ファイルを丸読みするのを防ぐため、このプロジェクトでインデックス化(SQLite等)または事前要約スクリプト(prep)にまとめるべき対象を提案してください。
3. Planner × Worker × 機械Judge(決定論的オラクル)の設計:
   私が寝ている間や別作業中にAIを安全に自律稼働させても、`pkill -9 bash` のような自爆や「上司不在のサボり(表面的な小修正の空回り)」が起きないよう、このプロジェクト固有の「機械審判スクリプト(ビルド・型チェック・書式検問・テスト合否を数ミリ秒〜数秒で一括判定する finish ゲート)」の具体的な実装案を提示してください。
質問するおじさん

おお〜!このプロンプトを貼れば、うちの AI ラルフが滑り台から飛び降りたり pkill -9 bash で自爆したりしないように、頑丈な安全柵と 4 ミリ秒の審判ゲートを AI 自身に設計してもらえるんだね!

解説ナビゲーター

はい!力技でトークンとアカウントを燃やす時代から、「賢い構造化とローカル高速バイナリで、最小のトークンから最大の成果を引き出す時代」へ。ぜひご自身のプロジェクトでも、安全で快適な自律開発ループを体験してみてくださいね!

ノルウェージャンフォレストキャット

しっかりした看板と機械の審判さんが見守っていてくれれば、AI たちも迷わずいい仕事ができて、人間も安心してぐっすり眠れるにゃ〜。それでは皆さん、今日も良い夢を見るにゃ……むにゃむにゃ。

AIたちが働く横でぐっすり眠る猫