ガスタウンのエージェントパターン、デザインのボトルネック、そしてスケールでのバイブコーディング

2026年1月24日原文(maggieappleton.com)

概要

Steve Yeggeの「Gas Town」は、複数のエージェントを同時に動かす異色のオーケストレーションシステム
設計や実装は即興的かつ非効率で、APIコストも高額
ソフトウェア開発の未来像を問う「デザインフィクション」として注目
設計と計画が新たなボトルネックになることを示唆
カオスの中に将来のエージェントオーケストレーションのヒントが隠れる

Gas Town現象と評価

Steve Yegge による「Gas Town」は、 Mad Max や Waterworld などをモチーフにした エージェントオーケストレーター 開発
完全に vibecoded （雰囲気重視・即興設計）で、APIコストが月数千ドル規模
ソフトウェアエンジニア界隈で 議論と変化 を巻き起こす
$GASという ミームコイン がBags上で登場し、$400,000超の取引高
- Gas Town本体とは無関係な 純粋な投機対象
「実用的なツール」ではないが、 ソフトウェア開発の未来像 を投げかけるデザインフィクションとして評価

デザインフィクションとしての意義

デザインフィクション とは、近未来のありそうなものを作り、 問いや議論 を生む手法
- 予測ではなく、 日常的な不便や副作用 を考える
- 詳細はNear Future Labの解説やManual of Design Fictionを参照
Yeggeは 不完全なプロトタイプ を公開し、議論を促進
- 「自分には作れたが、他の誰もやらなかった」精神

Gas Townの実用性と体験

筆者自身は 本格利用経験なし
- Yeggeの「自作ツール使うな」という警告に従う
- ユーザー体験は 混沌とカオス
Yeggeの「8段階自動化レベル」では、Gas Townは最上位の オーケストレーター運用
Onboardingは 極めて難解 で、設計思想がYegge本人にしか合わない

エージェント開発の新たな課題

エージェントがコードを書く時代、 設計と計画 が最大のボトルネック
- 実装よりも「 何を作るか」「 どう設計するか」が重要
- 人間の 文脈・好み・ビジョン が不可欠
Gas Townは設計が「 思いつきの連続」で、体系的な構造がない
- 17日間で75,000行・2,000コミットという 突貫開発
- 「Beads」プロジェクトの延長線で、 設計不在のまま規模拡大

将来のエージェントオーケストレーションへの示唆

現状はカオスだが、 将来のエージェントシステム のヒントが埋まる
エージェントに 専門役割 と 階層的監督構造 を持たせる設計
- 例：Mayor（人間との窓口）、Polecats（一時作業員）、Witness（監督）、Refinery（マージ管理）
- 各エージェントが 明確な役割 を持ち、 指示範囲を限定 し、同時多発的な運用が可能
Mayorが全体を統括し、直接コードを書かずに 作業割り振り を担う
システム内の 監督エージェント （Witness, Deacon, Boot the Dog等）が作業進捗を随時確認
役割設計と階層構造 による協調・注意力問題の解決

まとめ

Gas Townは「 設計なきカオス」だが、 未来の開発環境 を考える上で重要な実験場
人間の設計力・計画力 が、エージェント時代の新たな必須スキル
現状のGas Townは「 Yeggeの脳内にしか合わない」が、今後のエージェントシステム設計の原石となり得る

Hackerたちの意見

「ガスタウン」について学んだことは、全部自分の意志に反してる。

└

バイブコーディング、ラルフ、ヨロモードの創造者（抽象的に）によって提供されています。現実の見方を解体するための陰謀か、ただの面白い言葉を作る傾向か。

└

Yeggeの承認を得て、暗号通貨のポンプ・アンド・ダンプ詐欺に移行した部分、見逃した？それに、「Ralph」のvibe codingをやってたやつが、同じ詐欺を支持してたんだよ。彼は元々暗号通貨の批判者だったはずなのに、どうしてそんなことを？

最初は、ガスタウンはGOODY-2みたいな高レベルの風刺だと思ってたけど、どうやらみんなちょっとおかしくなってるみたい。ラルフループも無駄だよね、kvキャッシュをうまく使ってないし。 --- https://github.com/steveyegge/gastown/issues/503 問題: すべてのgtコマンドがbdバージョンを実行して、最小ビーズバージョンの要件を確認します。高い同時接続（17以上のエージェントセッション）の場合、このチェックがタイムアウトしてgtコマンドの実行をブロックします。影響: 17以上の同時セッションがそれぞれgtコマンドを実行している場合: - 各gtコマンドがbdバージョンを生成 - 各bdバージョンが5-7のgitプロセスを生成 - これにより、リソースを争う85-120以上のgitプロセスが生成される - gtの2秒のタイムアウトが超過する - gtコマンドが「bdバージョンチェックがタイムアウトしました」と失敗する

└

Ralphループは、kvキャッシュを適切に活用してないから馬鹿げてる。これはコストやリソースの問題だよ。もしもっと効果的でリソースがあるなら、それは全然問題ない。

└

これはサティアだと思うし、かなり明白なサティアだよね。誰か本気にしてる人いるの？

イェッゲは、ガスタウンのアーキテクチャやワークフローのために、自分でたくさんの華やかで動物的な図を作ったけど、全然役に立たない。主に、全てがジェミニのナノバナナによって作られたから。ナノバナナは図を作るのが最先端だけど、生成AIシステムはまだイラスト的な図を作るのが本当に下手なんだ。解読が難しくて、細かい詳細がごちゃごちゃしてて、矢印が間違った方向を指してることが多く、重要な情報が欠けてることもある。ほんとその通り！それに、図全体にわたる意味不明なテキストや不一致なビジュアルは——読者の知性への侮辱だよね。どうして人々はこんなにスラングのような視覚表現を我慢できるんだろう？

└

うん、最初はただのイラストとして意図されてるのか分からなくて、しばらくして読むのを諦めちゃった。実際に読みやすいアーキテクチャ図があればすごく助かったのに、文体がめちゃくちゃ難解で、マニックな「楽しい」無礼なスタイルだったからね（独特の声で書くのは面白くするためにはいいけど、やっぱり…混乱する）。それに、数段落ごとに新しいユニークな名前やつながりが出てきて、頭に入れるのが大変だった…最初にGemini 3 Proに退屈な技術的概要にまとめてくれって頼んだら、元の投稿と同じくらい理解不能な1ページのアウトラインとマーメイド図を作ってくれたから、AIでも消化するのが難しいみたいだね…

イェッゲはこのプロジェクトでバイブコーディングの真の定義に寄り添っている: 「これは100%バイブコーディングだ。コードを見たこともないし、見る気もない。」意味がわからない。自分がやっている仕事のタイプをよく理解していて、コードの事前知識もあるのに、非常に仕様がしっかりした問題でも、クロードコードなどは単純に失敗するか、雑なコードを使ってる。業界の人たちは、225K行以上のコードの一部を見たことがないのに、それが動くと約束するのはどういうこと？誰も理解できないコードの海が生まれる時代に突入している気がする。それをAGIが掃除してくれることを期待してるけど。

└

この見解には共感するけど、アセンブリ言語プログラマーがコンパイラについて言ってたことと同じことなんじゃないかとも思う。機械語を見ないってどういうこと？コンパイラが非効率なことをする可能性は？

└

誰も何も約束してないよ。ただの巨大な実験で、著者は明確に使わないように言ってる。新しいことに挑戦する人には感謝してる、たとえそれが壁に糞を投げて何がくっつくか見るようなことでも。もしかしたら、私たちのコーディングの仕方が変わるかもしれないし、変わらないかもしれない。バイブコーディングは、確かに役立つツールを作るのに助けになった。

└

俺も同じ経験があるよ。 vibe codingを試みたら、いつもオフバイワンエラーや論理エラー、間違った仮定の繰り返しとかに悩まされてきた。最初はうまくいってるように見えるけど、コードレビューで見るとすぐにバグが見つかるし、実際の使用では軽いものでも問題が出てくる。手動で修正することはできるけど、労力はプロジェクトの規模によって変わるね（小さいプロジェクトなら簡単に修正できるけど、大きいプロジェクトだと「自分で書いた方が楽だったな…」って感じ）。Gas Townの多層的な監視機関は、この手動の修正を置き換えるためにあるんだろうけど、ほんとに？みんながこんなもので成功してるってどういうこと？俺が間違った使い方してるのかな？もし本当に成功してるなら、AIが開発・維持してるオープンソースプロジェクトが、AI管理のシステム以外に存在しないのはどうして？（それともあるけど、俺が知らないだけ？）

Hacker Newsで議論の続きを見る

ハクソク