Gas Town開発記：カオスな「おふざけ」から正式リリースv1.0への軌跡

Gas Townがついにv1.0を迎えました。当初はプロジェクトとして「道化師のショー」のように混乱した状態でしたが、多くの苦労を経て安定したプロダクトへと進化しました。これまでの道のりを振り返ります。

Beadsは気に入ってたんだけど、Gitに依存しすぎていて問題が絶えなかった。まず一つ目に、私が使うすべてのシステムやプロジェクトがGitを使っているわけじゃないこと。二つ目に、ブランチを切り替えるとBeadsの状態が完全に壊れることがあった。三つ目は、少なくとも私が使っていた当時は安全装置がなくて、Claudeが何も検証せずにBeadsをクローズしてしまうことだった。

結局Claudeで自作することにしたよ。最初はSQLiteにして、GitHubと同期したりGitHubからプルできるようにした。さらに「ゲート」という概念を追加して、コンパイル、ユニットテストの実行、あるいは人間による単純な確認といったプロセスが完了していない場合に、Claudeなどのエージェントがタスクを完了とマークできないようにしたんだ。このゲートの考え方のおかげでClaudeの使い勝手が向上したよ。というのも、以前は完了したと言いながら実際には終わっていないことがあまりに多かったからね。すべてのタスクにゲートが必要で、タスクをクローズする前にゲートを通過しなければならない。ゲートはタスク間で再利用できるから、「ユニットテストを実行」というゲートを作れば、すべてのタスクで使い回せる。一度通過すれば、その「タスクとゲートの組み合わせ」に関しては合格ってことさ。

とにかく、Beadsには期待しているけど、Gas Townの方は今のところ私の守備範囲じゃないかな。

真面目な質問なんだけど、Gas Townに関するふわっとした話はたくさんあるよね。でも、Gas Townは誇大広告やブログ記事抜きで、公開された状態で実際に評価できるようなものを提供しているの？

現時点では、Gas Townが評価に値する何かを実現したのかどうか、はっきりさせるべきだと思う。

待つ必要はありません。大まかに言えば、Gas Cityがすべての問題の解決策です。ハハ！少なくとも「AIを社内に導入し、監査証跡を残すにはどうすればいいか」といった特定の問題に対してはね。

私の会社で重要な監査を行うのはFDAなんだ。

ソフトの変更によってユーザーに害が及ぶのを防ぐために、どのようなプロセスを踏んだのかと彼らに聞かれたとき、「漫画のキツネの格好をしたAI市長にやり方を指示したら、AIで動く架空のキャラクターたちがヴァイブコード（雰囲気で書いたコード）を大量に出力したんだ」なんて答えを聞きたがるとは思えないんだけどね。

Gas Townの運用コストをGoogleで検索してみた。Geminiの回答によれば、Gas Townは1時間あたり100ドルかかり、1時間で4000行のコードを吐き出せるから、1行あたり2.5セントという計算になるらしい。

その数字の根拠を追ってみたけど、ソースは少し怪しかった。Gas Townを使ったことがある人で、この数字を確認できる人や、個人の運用実績を教えてくれる人はいないかな？

いいタイミングだね。ちょうど古いリポジトリのbeadsを見ていて、そのまま……動いたことに感心していたところだよ。アップデートも問題なく動いたし、追跡しなきゃいけないような変なエラーも出なかった……「最高！」って感じ。Beadsが1.0になったのは素晴らしいね。Gas Townはここ1ヶ月くらい使っていないけど、安定版が出るならかなり価値がありそうだ。

Yeggeが考えている、プログラム可能で編集可能な調整レイヤーを作る（彼がGas Cityと呼んでいるもの）という直感は素晴らしいと思う。Gas Townの初期は、システムを破壊されないように細心の注意を払わなきゃいけなくて、まさにワイルドな体験だったよ。その後、私はそのエネルギーをOpenClawに注ぎ込んだんだけど、そろそろGas Cityを立ち上げて何ができるか試してみるつもり。すごく面白そうだ。

Gas Townはヴァイブコードというだけでなく、ヴァイブデザイン（雰囲気で設計）されているように感じるよ。
マルチエージェント設定が本当に違いを生むのか確認するために調べてみたけど、設計思想全体が「エージェントの層をもう一段増やせば、きっと今度こそ上手くいくはずだ」というのを10回連続で繰り返しているように見える。

市長、ヤマネコ、証人、助祭、犬といったタイプのエージェントに加え、理解不能な名前の不要なコンストラクトが山ほどある状態だ。

Gas Townのブログ記事の一つで、作者が「すごく非効率だけど、トークンを大量に消費するから、結局は欲しいものが手に入る！」というようなことを書いていたのを覚えている。明らかにこれがこのプロジェクトの設計思想だよね。とにかく（AIを使って）ランダムな抽象化やエージェントのタイプを投げ込んで、なんとなく上手くいったような気分になるまで繰り返す。それらが実際に何か貢献しているのかどうか、自分自身に問いかけることはしないんだ。

これを見て、Gas Townの複雑さのほとんどは全く不要で、むしろ有害だとはっきり感じたよ。

結局、自分で10倍シンプルなものを作った。話しかけるだけの単純なメインエージェントがサブエージェントに指示を出し、全員で通信して起こし合い、シンプルなCLIで作業状況を把握するだけ。リファイナリーとか、ウェイストランドとか、モレキュールとか、コンボイとか、助祭なんてものはない……。

Beadsは面白いけど、使ってみたらバックエンドがどうも腑に落ちなかった。バックグラウンドでSQLデータベースを走らせなきゃいけないの？Gitとどうやって同期しているんだ？（リポジトリにコミットされたファイルやオブジェクトは見当たらなかったし）それに、Doltが何もしていないときでもバックグラウンドで常に3〜30kB/sのI/Oを消費していた。その上、Beadsには私が使わないような機能が多すぎる。私の小さな脳には複雑すぎたよ。

というわけで、1〜2日で自分のBeads実装を急ごしらえで作った（https://codeberg.org/mutablecc/dingles ）。おそらくバグはあるし、Gas Townと無理やり使えばレースコンディションも起きるだろうし、スケーリングもしないと思う。でも、課題を作成・追跡して同期する（ローカルでもリモートでも、通常のマージか専用のチケットブランチ経由で）のに必要な最小限の機能はある。SQLも余計な機能もなし、JSONLとGitだけだ。大規模なソフトウェアプロジェクトに放り込んでみたけど、AIは水を得た魚のように使ってくれたよ。プロジェクト全体のエピックを作って、依存関係を優先して、複数のコンテキストセッションをまたいで体系的に進めてくれた。AIが使いたくなるようなツールを作るというパラダイムは、間違いなく勝者だ。

Yeggeは本当に、プロダクション向けのソフトウェア開発をこんな方法でするのが良いアイデアだと思っているのか？

コンテキストをうまく管理するのが課題であり、こうしたオーケストレーションがそれを解決すると仮定しよう。だが、エージェントにはもう一つ問題がある。

システムやコンポーネントを設計するとき、私たちは不変条件（イナバリアント）を形成するアイデアを持っている。ある種の壮大なアーキテクチャのような大きなものもあれば、データ構造の選択のような小さなものもある。だが最終的には、その不変条件と衝突する機能を追加したくなるものだ。そのとき、通常は3つの選択肢がある。

• その機能を追加しない。不変条件は有用な簡略化の原則であり、機能よりも重要だ。他の面で利益をもたらすだろう。
• 不変条件の上に、美しくない、または非効率な方法で機能を追加する。まあ、すべての機能がエレガントで効率的である必要はない。
• 戻って不変条件を変更する。考慮していなかった新しいことを学び、新たな光が当たることで、より良いアプローチが見つかる。

多くの場合、このうち一つだけが正しい。そして、たいていの場合、どれか一つが非常に大きな間違いで、悪い結果を招く。

しかし、どれを選ぶかはコンテキストの問題じゃない。判断の問題だ。そしてモデルは――ハーネスではなく――あまりにも頻繁にこの判断を誤る（彼らは自分が知っていること、つまり学習データの「平均」に従うか、単に理解できていないだけだ）。実際、間違いが急速に蓄積・複合し、2〜3回悪い決定を下すとコードベースは修復不可能になる。今日のモデルは、それ単体で完全で持続可能なプロダクトを作るにはまだ十分ではない。賢明な判断をすると信頼することはできないんだ。数々の研究や実験がそれを証明している。

まあ、エージェントが持っていないコンテキストを私たちが持っているから、より良い判断ができるのかもしれない。だが、事実から教訓に至るまで、ソフトウェアのあらゆる抽象化レイヤーに関する知識をすべて文書に叩き込むことはできない。できたとしても、現在のモデルでは扱いきれない。だからコンテキストの問題だとしても、それはコンテキスト「管理」を改善すれば解決できるようなことではない。監査証跡があるのは良いことだが、それが一つまた一つと悪い決定を積み重ねた記録なら意味がないんだ。

私の経験では、エージェントコーディングを使えば、それなりに動くソフトウェアを作れるのは確かだ。ただ、結局のところ数日間は、コードを理解し、検証し、そして自分が意図した形とエージェントが推論した形を合わせるために、小突いたり微調整したりする必要がある。

夜にアイデアをブレインストーミングして、ChatGPT Proに実装のための長いBeadsのリストを吐き出させ、完全に空のリポジトリに放り込んで一晩放置し、朝起きたらプロジェクトの大部分が実装されているのを見るのは、かなり魔法のようだよ。

Beadsは不必要にオーバーエンジニアリングされている。Gas Townを試そうという気力を削ぐよ。