PJR-Q3W9 Gas Town との設計思想の対比と理解の負債
1. メモ
競合比較（prj-0001:pjr-36qg-competitive-landscape-and-release）は機能の対応を扱う。本 note は設計思想の対比と、そこから生じる「理解の負債」という論点を記録する。位置づけの判断（prj-0001:pjr-e8tt-initial-release-positioning）を見直すときの材料とする。
調査は 2026-09-24 時点である。
1.1. Gas Town の思想
公式の説明で使われる語がそのまま特徴を表す。
| 概念 | 内容 |
|---|---|
| Dark Factory | 自律 agent が背後で動き、人は監督する |
| Wanted Board（Wasteland） | 共有の仕事掲示板。投稿された仕事を agent が claim する |
| 規模 | Gas Town は数十、Gas City は数百の並行 agent |
| 人の役割 | 「agents read and write the ledger; humans audit it」 |
| 品質 | stamps（多次元の証明）。信頼性や創造性を評価し、移譲可能な評判を蓄積する |
task を起票して依存関係で並列に流す思想である。beads の依存グラフと bd ready が土台になる。
1.2. 理解の負債という論点
task を細かく割って多数の agent で並列に進めると、人が全体像を把握できなくなるのではないか、という懸念がある。
Gas Town はこれに無自覚ではない。明示的に答えを用意している。
Naming the parts the way a mechanic would makes the system legible — both to the humans running it and to the agents working inside it.
命名と記録の透明性で legibility を担保し、人は個々の作業を追わず台帳を監査する。人が全部理解することを最初から諦めている設計であり、放置の結果ではなく意図的な選択である。
それでも構造的な弱さが 2 つある。
- beads が解くのは agent の記憶であって人の理解ではない。 公式の説明は "A memory upgrade for your coding agent" で、agent がセッションをまたいで忘れる問題を埋める。人が全体像を把握する問題は対象外である。
- 依存グラフは順序を決めるが整合性を保証しない。 「A の後に B」は表現できても「A と B が同じ設計思想に沿っているか」は表現できない。細かく割るほど、個々は正しいが全体として筋が通らない状態になりやすい。review を agent が行えば、agent が agent をレビューする閉じた輪になり人の理解は増えない。
一方、反論も成り立つ。すべてを理解する必要はなく、人間の大規模開発でも全員が全体を理解してはいない。型とテストが契約を守れば中身を読まずに使える。理解の所在がコードから issue グラフと台帳へ移る、という見方もできる。したがって「必ず破綻する」とは言えず、どこまで持つかが未知という段階である。
1.3. SpecDojo の二面性
当初「Gas Town は並列、SpecDojo は 1 件ずつ承認を挟む」と整理したが、これは誤りである。SpecDojo には 2 つの経路がある。
| register 経路 | schedule 経路 | |
|---|---|---|
| 起点 | 気づいたことを起票 | 成果物カタログ → timeline → schedule |
| 順序判定 | 無し（人が決める） | CPM で ready 判定 |
| 実行 | 1 件ずつ、承認を挟む | --auto --parallel --loop で無人 |
| 人の役割 | 承認 | 計画と review |
rtn-exec-cycle.yaml は parallel: 2 / loop: true / max_rounds: 100 を cron で回す定義を持つ。人は介在しない。schedule 経路は Gas Town と同じ方向である。
1.4. 差は並列性ではなく仕事の発生源と人の関与点
| Gas Town | SpecDojo（schedule 経路） | |
|---|---|---|
| 仕事の発生 | Wanted Board へ投稿された仕事を agent が claim する | 成果物カタログから計画される |
| 単位 | task（任意の粒度） | 成果物 × フェーズ（done_criteria と rulebook を持つ） |
| 順序の根拠 | 依存グラフ（agent が張る） | CPM（人が設計した timeline と catalog から導出） |
| 完了の判定 | gates / tests / stamps | done_criteria + review 観点 |
当初 Gas Town を創発的（agent が仕事を見つけて投稿し、別の agent が拾う）と特徴づけたが、これは誤りである。詳細は 実践者の報告 に記す。実態は、人が設計と計画を供給し続けないと回らない。SpecDojo は計画的である。何を作るかを人がカタログで宣言し、そこから機械的にタスクが導出される。SpecDojo で並列に流れるのは、人が「これを作る」と決めた成果物だけであり、agent がタスクを増やすことはない。
人の関与点も異なる。SpecDojo は事前（計画）に重心があり、Gas Town は事後（監査）にある。
| 観点 | Gas Town | SpecDojo |
|---|---|---|
| 並列実行 | 中核。数十〜数百 | 持つが中核ではない。既定は 1 |
| 仕事の発生源 | Wanted Board（投稿の主体は人を含む） | 人（成果物カタログ） |
| 人の関与点 | 台帳の監査（事後） | 計画（事前）と review（事後）、register なら承認（実行時） |
| 理解の拠り所 | 台帳の legibility | 成果物文書と grade |
1.4.1. 実践者の報告（2026-09-24 調査）
「創発的に多数の agent を回して本当に成立するのか」を確認するため、作者と実践者の記述を調べた。
作者は throughput を最適化し、正確性は最適化していないと明言している。
most work gets done; some work gets lost
一部が失われる前提で設計されている。欠陥ではなく仕様である。
報告されている詰まりは 4 つある。
| 問題 | 内容 |
|---|---|
| 人のレビューが律速 | agent は人がレビュー・承認・軌道修正できる速度より速く動く |
| 設計と計画が新たな律速 | 「Gas Town は実装計画を高速に消費するので、エンジンを養うために大量の設計と計画が要る」 |
| 検証の輪が閉じていない | 多数の agent が相互検証する触れ込みだが、本番運用者は verification chain is not closed と報告 |
| 統合の破綻 | 1 人分の merge conflict を捌くためだけに専用の Refinery agent が必要。複数人が同じ main へ流すと問題が増える |
Maggie Appleton の評は、17 日で 75k 行・2000 commit という速度を認めつつ、深刻な利用者からの運用上の成功報告は無いとし、design fiction（構想の実演）に近いと位置づける。
「創発的」という特徴づけは誤りである。 Wanted Board は「work that needs doing を投稿し、他の人が投稿した仕事を claim する」場であり、投稿の主体が agent とは限らない。むしろ報告は逆を示す。人が設計と計画を供給し続けなければ空回りする。人の計画力が供給側の制約になっている。
1.4.2. 検証の非対称性
文書は、コードよりも多数 agent による並列実行に向かない。理由は自動検証の有無である。
| コード | 文書 | |
|---|---|---|
| 自動検証 | 型検査・テスト・ビルド | ほぼ無い |
| 誤りの検出 | 実行すれば分かる | 読まないと分からない |
| 「動く」の定義 | 明確 | 曖昧 |
Gas Town の gates / tests はコードだから成立する仕組みで、文書へは適用できない。SpecDojo が grade と review 観点を持つのは、この欠落を埋めるためである。
本プロジェクトの実測も裏づける。
- kata の要修正は 58%（prj-0001:pjr-2w38-sample-quality-observation）。agent が書いた文書の品質である。
- prj-0001:pjr-ypns-kata-resolution では、executor が指示どおり 22 箇所を置き換えたが「解決」と「列挙」を区別するという判断を誤った。親検証が捕らえたのは型エラーだけで、設計上の誤りはテストでは捕まらず、人が差分を読んで発見した。
原因は agent の能力不足ではなく、個票の完了条件が曖昧だったことである。指示が正確なら従うが、範囲の判断はできない。 創発的な作業はまさにその判断を要求する。
1.4.3. 両者の弱点は相補的である
「したがって SpecDojo が正しい」と結論づけるのは早計である。
Gas Town が到達した結論は「設計と計画が律速になる」であった。これは SpecDojo が成果物カタログ・timeline・schedule・kata で埋めようとしている領域そのものである。Gas Town は走ってみて設計の不足に突き当たり、SpecDojo は設計から始めて実行速度が出ない。
SpecDojo 側の未証明な点も残る。
- 成果物カタログを書く負担が、実際に割に合うか
- kata 106 種から必要なものを選ぶ判断ができるか
- 文書の維持負担（要修正 58%）に耐えられるか
Gas Town に運用上の成功報告が無いのと同様、SpecDojo にも実利用者による検証が無い。どちらも未検証である。
1.4.4. リスクの性質の違い
両者の未検証な点は、性質が異なる。
| Gas Town | SpecDojo | |
|---|---|---|
| 問題の性質 | 思想に内在する | コストと習熟 |
| 例 | verification chain が閉じない、most work gets done; some work gets lost | カタログを書く負担、106 種からの選定、文書の維持 |
| 努力で縮むか | 縮まない。throughput 優先を捨てない限り残る | 縮む余地がある |
Gas Town の「一部は失われる」は仕様である。努力で減らすには throughput 優先という前提自体を変えるしかなく、それは別のツールになる。
SpecDojo 側は少なくとも 2 点が設計で軽くできる。106 種からの選定は規模別プリセット・推奨セット・orchestrator による選択で、カタログを書く負担は会話からの生成で軽減できる。2026-09-23〜24 の作業（npm 導線の register 先行、kata の参照既定、orchestrator の配布）はこの方向である。
ただし努力の外にある要素が 2 つある。
技術の軌道への賭け。SpecDojo は「agent は範囲の判断ができないから、人が型と完了条件で指定する」という前提に立つ（prj-0001:pjr-ypns-kata-resolution が実例）。モデルの能力が上がって粗い指示でも意図を推測できるようになれば、型を用意する価値は下がる。Gas Town はモデル能力の向上に賭け、SpecDojo は構造の価値に賭けている。どちらが当たるかは努力では決まらない。
ただし型は「agent への指示」だけでなく「人が後から読むための記録」でもある。能力が上がっても、3 年後に判断の理由を追う必要は消えない。この部分は能力向上で無価値にならない。
採用は努力の変数ではない。正しいが重い体系が軽い方式に負けた例は多い。RUP や重厚な PMBOK 準拠プロセスは、方法論として誤っていたから廃れたのではなく、学習コストと維持負担が割に合わないと判断されたためである。prj-0001:pjr-36qg-competitive-landscape-and-release が「劣位」に学習コストと体系の維持負担を挙げるのは、この歴史認識と一致する。軽くする努力は有効だが、どこまで軽くしても重いと見なされる閾値があるかは分からない。
1.4.5. 段階的に価値が出る構造が最大の防御
「全体を採用しなければ価値が出ない」構造であれば、重さで脱落する。SpecDojo は段階的に使える。
register だけ 設定 2 行。catalog も schedule も要らない
+ orchestrator 会話で起票・実行
+ kata（参照のみ） eject せず package から参照
+ catalog / schedule 必要になったら重さが必須ではなく選択になっている限り、賭けが外れたときの損失は限定される。
したがって「SpecDojo の方が見込みがある」と判断する根拠は、「努力で到達できるから」ではなく「段階的に価値が出る構造だから、外れたときの損失が小さい」に置く。前者は検証不能だが、後者は空リポジトリから register まで 4 コマンドで到達することを実測している（prj-0001:pjr-09kk-npm-onboarding-path）。
1.5. SpecDojo にも同じ負債がある
負債の置き場所を変えているだけで、消してはいない。
schedule 経路で夜間に無人実行すれば、翌朝には知らない変更が入る。構造は Gas Town と同じである。--loop --max_rounds 100 を無人で回せば、レビューされない成果物が積み上がる。実際 rtn-exec-cycle は enabled: false のままで、本プロジェクトでも常用していない。
違いは 2 点ある。
- 生成物が文書である。 コードは読まなければ分からないが、成果物は人が読むために書かれた文書であり、差分を読むこと自体が理解の回復になる。
- grade で劣化が測られる。 無人実行で品質が落ちれば score と findings に出る。Gas Town の理解の負債は破綻するまで指標に現れにくい。
ただし文書の維持負担そのものが SpecDojo の負債である。prj-0001:pjr-36qg-competitive-landscape-and-release は「劣位」に体系の維持負担を挙げており、kata の要修正は 58%（prj-0001:pjr-2w38-sample-quality-observation）である。文書が腐れば、文書を正本とする設計の根拠が崩れる。
1.6. 観測として残す判断
どちらが正しいかは決められない。速度が要る場面、仕様が明確な場面では Gas Town が勝つ。判断が要る場面、長く保守する場面では承認と計画を挟む方式が効く。優劣ではなく何を最適化するかの違いである。
本 note は判断を下さず、対比を記録するに留める。位置づけを見直すときに、誤った対比（逐次 vs 並列）へ戻らないための記録とする。
2. 背景・文脈
利用者から「Gas Town は task をどんどん起票して依存関係で多数の agent が一気に進める思想か。理解の負債が積み上がって最終的に管理できない仕組みになるのではないか」という問いがあり、調査して整理した。
その過程で「SpecDojo も schedule に落とせば並列実行できるので二面性がある」という指摘を受け、当初の対比が誤りであることが判明した。
さらに「創発的にうまくいくのか。文書生成のレベルを見ると難しいのでは」という問いを受けて作者と実践者の記述を調べ、実践者の報告 のとおり「創発的」という特徴づけ自体が誤りであることが分かった。訂正を含めて記録する。
3. フォローアップ
rtn-exec-cycleを有効化する場合、無人実行した成果物をいつ誰が読むかを決める必要がある。決めずに回すと Gas Town と同じ負債を抱える。- prj-0001:pjr-2zvs-grade-review-integration の決定（review フェーズで grade を実行し verdict を合成する）は、この負債への対処として働く。無人実行の成果物が review を経る経路が確立される。
- 位置づけ（prj-0001:pjr-e8tt-initial-release-positioning）では、並列実行を差別化として主張しない。中核ではなく、Gas City に規模で先行されている。
4. 関連ドキュメント
- prj-0001:pjr-36qg-competitive-landscape-and-release
- prj-0001:pjr-e8tt-initial-release-positioning
- prj-0001:pjr-2zvs-grade-review-integration
- prj-0001:pjr-2w38-sample-quality-observation
docs/ja/projects/prj-0001/routines/rtn-exec-cycle.yaml- https://yegge.ai/gastown
- https://maggieappleton.com/gastown
- https://reviewcommit.substack.com/p/gas-town-a-review
- https://tenzinwangdhen.com/posts/gastown-good-bad-ugly/