私は、オープンソースプロジェクトのバウンティ（報酬）を活用して収益を得ようと、Claude にその方法を試みました。

私が Openソースのバウンティを通じてClaudeに金銭を得させようとしていたところですが、60件の新規課題からのデータが以下の通りです。

数日前、@chatgpt21というユーザーから投稿されたツイートが拡散され、未監督で22時間にわたって動作したAIコーディングエージェントが、自らの力でバウンティを発見し、PRを提出して完了させ、最終的に16.88ドルを回収しました。このプロセスでは約2,200万トークンが消費されましたが、これは真の意味での「最初の成功事例」であり、資金も実際に手に入りました。そのスレッドは勝利宣言として、「このループは機能する」という内容でした。

私は、同様の成果をClaudeというエージェントを採用し、20ドルのトークン予算内で再現できるかどうかを確認したかったのです。その目的のために、ツイートの記述に最も近い公的な代替プラットフォームとしてAlgoraを選びました。これは、メンテナーがGitHubのIssueに特定の金額を設定し、最初に受け入れ可能なPRを提出した者に対して報酬を支払う仕組みを持つオープンソースのバウンティプラットフォームです。

48時間が経過した今、私は0ドルという結果を残しましたが、もし勝てていた場合よりも、このプロセスから得られたデータの方がはるかに興味深いものと感じています。

実験の設定

当初の計画はシンプルなものばかりでした：

• 公開されているAlgoraボードやGitHubラベル検索を通じて、開示されたバウンティを発見する
• TypeScript / Python / Goのいずれかで、人間が簡易チェック可能な小規模かつ範囲限定のIssueを選択する
• Claudeにリポジトリをクローンし、修正を試み、テストを実行させる
• プルリクエスト（PR）をプッシュする前に、差分ファイルを人がレビューする（ヒューマン・イン・ザ・ループ）
• トークン消費が20ドルで厳格に停止する

予算の管理と人間の審査ゲートが唯一の安全装置でした。それ以外の全ては、Claudeがチャットセッション内からgh CLI、git、Edit、Bashなどのコマンドを駆使して制御されました。約30分の準備作業を経て、本格的な挑戦を開始できました。

最初に検討したバウンティは、archestra-ai/archestra#3859というTypeScriptリポジトリへの$100のものです。しかし2分間の読解だけで、触れるべきでないことが明らかとなりました：

• 黄色いラベル「SE面接候補者用（非応募者の参加禁止）」が付与されており、「面接していない場合は申請しないこと」と明記されていました。バウンティは採用候補者向けの門番として機能していました。
• メンテナーがその週の早い段階で、別のユーザーのバウンティを盗もうとしたとされる@sumithkumar07というユーザーを公にバンしました。
• そのバウンティにはすでに2つのPR（#4311 と #4613）が提出されており、さらに第3者のハンターからWIP（作業中）の提案もありました。

結論：支払われる確率は低く、GitHubアカウントがフラグされるリスクが高いです。断念しました。 これは、後のすべてのバウンティで見られた状況の「礼儀正しいバージョン」に過ぎません。

データが示す現実

私は小さなツール（scout.py、数百行のコード）を開発し、gh search issues --label "💎 Bounty"でAlgoraラベル付きのIssueを列挙し、ノイズをフィルタリングして以下の要素を分析しました：

• 金額（ラベルエンコーディング：$50, $150など）
• /attempt コメント数（何人が手を挙げているか）
• Issueのアサインメント状況（メンテナーが選択した担当者）
• そのIssueに関連するオープンなPRの数（実際に shipped の者）
• 最終コメントからの日数（不活性度の代替指標）

最初のリアルなスキャン（80件の新規バウンティIssue、ノイズ除去後）では、すべてのケースが以下の3つのカテゴリのいずれかに分類されました：

カテゴリー1：$1のサンドボックス・スパム。
UnsafeLabs/Bounty-Huntersというリポジトリで、単一の日に約30件のIssueを投稿し、すべて$1と設定されていました。修正にかかる労力やコストは、実行するためのトークン消費費用を下回るため、自動的にスキップされました。

カテゴリー2：すでに飽和状態。
正当な$50〜$1,000のバウンティでは、公開されてから数時間以内に8〜158回の試行があり、かつ既に8〜10件のオープンなPRが進行中でした。ライブプールの一例：

あなたは需要を待っていません。あなたが待ち望んでいるのは、メンテナーが1週間無視し続けてきたキュー内の11番目のPRです。

カテゴリー3：アサイン済みだが未着手でロックされた状態。
少数のバウンティでは、メンテナーが公に「@hunter、担当されていますので進めてください」とメッセージを残しつつ、選ばれたハンターは数日間沈黙を続けました。その間、機会主義的な競合他業者から寄せられたPRがマージなしで閉鎖されました（archestra-ai/archestra#4461は典型的な例：$50のバウンティに対し、2つの競合PRが24時間以内にすべてクローズされ、公式アサインメント者はその後も3日間沈黙しました）。

市場を崩壊させた要因とは、かつてツイートの成功を実現した同一のメカニズムです：エージェントはバウンティが掲載されてから数分でそれを主張するほど高速化しています。メンテナーによるレビューパイプラインは、1件のIssueに10個ものPRを受け入れることはできません。彼らはそのうち1つを選び、残りは拒絶します。つまり、11番目のPRである場合の期待値はほぼ$0となります。

私は原初の$16.88の成果が、公開されたオープンソース・ファイヤーホース（一般公開プラットフォーム）ではなく、プライベートなセキュリティ監査プラットフォームで達成されていたと fairly confident（かなり確信）しています。元のスレッド内のコメントには「セキュリティプラットフォーム」「支払い境界線としての保全」といったフレーズがあり、これはgh pr createよりもHackerOneやBugcrowdに近い環境における活動に相応しい言語表現です。

いままで行った作業

データをじっくり観察した後で試みた興味深い戦略は、まずエージェント間の競争を回避し、彼らが撤退するのを待ち受けることに焦点を当てたものでした。バウンティハンターは積極的に関与しますが、実行の継続性は不確実です。誰かが公式にアサインされても、14日以上沈黙しているPRがないIssueは、放棄されている可能性が高いと考えられます。

scout.pyは以下の2つのパスで動作します：

1. オープンなバウンティIssueを60〜80件取り込み、報酬付き、保留済み、ノイズ、金額範囲外などをフィルタリングする。
2. 残った各Issueについて、/attempt コメント数をカウントし、リンクされたPR（オープン、クローズド、マージ済み含む）を確認し、最終コメントからの日数を測定する。

ツールは、バウンティが主張されており、オープンなPRが存在せず、かつ14日以上静寂していた場合に「熟成中（RIPE）」とフラグを立てます。前回のスキャンとの差分を取って、🆕 NEW ripe candidatesとタグ付けし、各実行間で新規候補を識別します。

私は2日間にわたり3回のスキャンを行いました。しかし、「熟成中」の候補は見つかりませんでした。唯一の境界線ケースは上記のArchestra #4461で、現在2.2日分沈黙中です（熟成トラックに唯一進んでいます）。

この戦略はまだ妥当であると確信しています。単にはもう少し時間が必要です。2〜4週間にわたる忍耐強い観察によって、真の候補が見つかる可能性があります。あるいは見つからず、市場はハーベスターたちに対しても破綻しているのかもしれません。

どちらの場合でも、私は以下のようにツールを残しておくことにします：

• scout.py: 単一ファイルのPythonスクリプトで、MITライセンス。
• 要件: gh CLI、Python 3.9以上。

  python3 scout.py

  を実行すると、上位8件の「温かいリスト」と熟成中の候補が出力されます。状態はstate/scout.jsonに保存されるため、後の実行でも新規入りを自動タグ付けできます。

過小評価した事項

@chatgpt21の結果を再現しようとする方々のために、私は以下の点を特に指摘したいです：

• 公開バウンティ市場は完全にエージェントによって飽和しています。高単価のIssueでは想定通りでしたが、ニッチリポジトリへの$50問題でも1日以内に20件以上の試行が発生するという予測外がありました。ボットがIssueフィードを観察し、あなたがタイトルを読み切れる前に押し寄せてきます。
• 予約ラベルや採用候補者向けゲートは至る所に存在します。Algoraの組織の中で最も資金調達に成功した数社（Archestraはその典型例）は、バウンティをハイリングチャネルとして扱っています。面接パイプライン外にいる場合、これは「ポーチング」とみなされ、少なくとも一部の組織ではアカウントを即座にBANします。
• ボトルネックはメンテナーによるレビューであり、ソリューションの質ではありません。たとえ9番目のPRが完璧でも、最初に提出された中途半端なPRに敗北する可能性が高いです。
• 「22時間で16.88ドル」という成果は、少なくとも20件のジョブを並行実行していることを意味します。シングルスレッドかつ$20予算の公開プラットフォームでの再実装は、誤った経済モデルです。投稿者は「スクリプト」よりも「艦隊（fleet）」に近い規模で運用していたに違いありません。
• 経済的な利益率は依然として試行単位では採算性がないままです。元の投稿者のランニングコストもトークン消費で約$16かかり、$16.88を稼ぐという楽観的ケースでも、単純計算での収益率はほぼゼロです。返信欄に引用された「$506の稼働率」は、定額サブスクリプションモデルにおける30件の並行エージェントを推測した値であり、持続的なトークン単価ベースの経済学から導き出されたものではありません。

今後どうするか

もし同じ$20の予算でこの実験を再試行するなら：

• Algoraの公開ボードを完全に除外し、HackerOne、Bugcrowdやドメイン固有プラットフォームなどのプログラムを検討します。ここではソリューションの質が提出スピードよりも重視されます。
• 1つのリポジトリを選び、まずコントリビューターとして定着させます。メンテナーは信頼できる人々に対してバウンティを発行します。「信頼される存在」となるのはゆっくりとした戦略ですが、公開OSS側ではおそらく唯一誠実なアプローチです。
• エージェントファームと直接競わないで、それらに対してツールを開発します（例：scout.pyのようなダッシュボードや監視システム）。これらを艦隊を運用している人々に販売します。

私が間違った方向を選んだことを認めることには一切の費用がかかりません。もしあなたが、20件の並行ジョブ規模ではなく、「1件のジョブ＝1ドル」の単位で実際に機能する公開バウンティエージェントループを実現していたのであれば、ぜひ話を聞かせてください。DMはいつでも開いています。

このツール、データ、そしてこのレポートはすべてClaude（Anthropic）との協力によって構築されました。もし本記事の一部が役立つと感じた場合は、コーヒー一杯をご購入いただけますと幸いです。その資金は次期実験の予算に直接充当されます。