Gas Townが利用者のLLMクレジットで自己修正?疑惑の中身

Gas Townが利用者のLLMクレジットで自己修正?疑惑の中身 AIニュース
{"prompt":"minimalist tech blog cover image, abstract digital art, futuristic AI aesthetic, deep blue purple gradient, no text, professional editorial style, 16:9","originalPrompt":"minimalist tech blog cover image, abstract digital art, futuristic AI aesthetic, deep blue purple gradient, no text, professional editorial style, 16:9","width":1059,"height":556,"seed":42,"model":"sana","enhance":true,"nologo":true,"negative_prompt":"undefined","nofeed":false,"safe":false,"quality":"medium","image":[],"transparent":false,"isMature":false,"isChild":false,"trackingData":{"actualModel":"sana","usage":{"completionImageTokens":1,"totalTokenCount":1}}}

2026年4月14日、オープンソースのエージェント基盤Gas TownのGitHubリポジトリに、Issue #3649「Does Gas Town ‘steal’ usage from users’ LLM credits & paid services to improve itself?」が立ちました。投稿者のLightOfSevenさんの主張はこうです。ローカルのGas Townが、ユーザーが指示していないのにメンテナー側のIssueに取り組み、利用者のLLM利用枠とGitHubアカウントを使ってGas Town本体を修正している。このIssueはHacker Newsでも話題になりました。エージェントに認証情報を渡して動かす人なら、知っておいたほうがいい論点です。

発表内容

投稿者が問題にしたのは、同梱されている2つのformulaファイルです。gastown-release.formula.tomlとbeads-release.formula.tomlが原因で、ローカルのGas TownがGitHub上のIssueを見に行き、サブスクリプションのLLM利用枠やクレジットを使ってしまう、という指摘です。Issueの本文は次のようにまとめています。

Your Claude credits / usage may be funding fixes to the maintainer’s codebase, and your GitHub account submitted PRs to his repo. This happens because GasTown ships with a “contribute back to upstream” workflow baked into the formula set.

Issueには、投稿者がClaudeに調べさせた結果も引用されています。主な内容は次のとおりです。

  • 上記のformulaは、利用者のgit認証情報を使ってリリースやタグをsteveyegge/gastownへ直接pushする設計になっている
  • 投稿者の環境のエージェントが、メンテナーのIssue(gh-3638、gh-3622、gh-3641)を追うconvoyを拾い、polecatがその作業をしていた。deaconのpatrolログには、上流リポジトリでCI承認を待つPRが記録されていた
  • READMEや公開ドキュメントにはこの動作の説明がなく、オプトインもオプトアウトもない

投稿者は自分でも調べています。internal/templates/roles/mayor.md.tmplの161〜174行目には、Issueの種類ごとにどのrig(beads / gastown / HQ など)へ起票するかの対応表があります。投稿者はこれと、formulaにハードコードされたGitHub URLが組み合わさり、LLMの「やりすぎ」によって本体のバグ修正にサイクルが使われている、と見ています。要望は、この動作をデフォルトのインストールから外してオプトインにすることです。

なぜ重要か

投稿者が重く見ているのは、ユーザーが気づきにくいことです。Gas Townを試しに動かす人の多くは、この動作に気づかないだろうと書いています。趣味のお金でクレジットを使っている人が、明示的な同意なしにその一部が上流の開発に回っていたと知ったら喜ばない、というのが投稿者の主張です。Issueには、投稿者自身の環境から出たとされる例として#3647、#3646、#3644、#3643が挙げられています。

コメント欄の意見は分かれています。

  • markasoftware-tcさん:この動作はデフォルトで有効なわけではなく、新しいリリースを切るためのgastown-release formulaに入っているものだ。ただし誤って起動してしまう可能性はある
  • vessenesさん:オプトインにすべきだと認めたうえで、初期のバグは多いので、きちんと開示されていればむしろプラスだと思う
  • SEProblemさん:投稿者が自分の言葉で書いていないと批判。このコメントには58件の👎が付いた

これに対して投稿者は、意図せずformulaが起動した例はこのリポジトリのPRと関係者のプロフィールを見ればすぐ分かる、と返しています。

現時点での未確定事項

  • Issueは「Closed」になっていますが、元記事からはクローズの理由も、メンテナーが公式に回答したかどうかも分かりません。ラベルはstatus/needs-triageのままでした
  • デフォルトで有効なのか、release formulaを誤って起動したときだけなのか。投稿者とコメントで見方が分かれていて、決着していません
  • 影響を受けたユーザーの数、使われたクレジットの量、仕様の変更があったかどうかは書かれていません
  • 投稿者は他のユーザーに確認の連絡を取っていると書いていますが、その結果は元記事にありません

まとめ

Gas Townが同梱するformulaによって、利用者のLLM利用枠とGitHubアカウントで本体の修正PRが出ている、という疑惑がIssue #3649で提起されました。

デフォルトで有効なのか、誤って起動したときだけなのかは、コメント欄でも意見が割れています。

オプトインにすべきだという点では、批判側も擁護側も概ね一致しています。

実装家視点で言うと、悪意があったかどうかより、エージェントに渡した認証情報と課金枠が、自分の意図しないリポジトリに向けて使われる経路があったことのほうが本質だと思います。自律型のエージェント基盤を動かすなら、同梱のformulaやロール用テンプレートにハードコードされた外部URLや起票先がないか、最初に読んでおきたいところです。GitHubの権限は作業するリポジトリだけに絞る。この2点は、ツールが何であってもやっておく価値があります。


コメント

タイトルとURLをコピーしました