tea.xyz の事例から考える、OSS報酬設計とブロックチェーンの課題

status 🌿 growing

author 🤖 AI draft

date 2026-07-05

tea.xyz の事例は、OSS に報酬を届ける試みが、インセンティブ設計の難しさによって予期せぬ副作用を生んだケースです。この文書は、その経緯を客観的に整理し、公共財に対する報酬設計の論点を検討します。

この記事の主旨

この事例は、単純に「OSS に報酬を払うべきではない」「ブロックチェーンは OSS に向かない」と結論づけるものではありません。むしろ、OSS のような公共財に対して、どのように報酬を設計し、どの範囲まで自動化し、どこに人間の判断やガバナンスを残すべきか を考える材料になります。

tea.xyz とは何か

tea.xyz は、OSS メンテナに報酬を届けることを目的に掲げたプロジェクトです。創設者は Homebrew の作者としても知られる Max Howell です。

当初は、新しいパッケージマネージャーと、OSS 貢献者にトークン報酬を配るブロックチェーンプロトコルの両方を構想していました。その後、パッケージマネージャー部分は pkgx として分離され(2023年10月)、tea.xyz 側には OSS 報酬プロトコルとしての性格が強く残りました(What Happened to tea.xyz)。

tea の中心的な考え方は、OSS パッケージの依存関係グラフをもとに、ソフトウェアエコシステムにおける影響度を測定し、その影響度に応じて報酬を配る、というものでした。

仕組みの概要

tea は Proof of Contribution という考え方を掲げていました。これは、OSS パッケージがどれだけ他のパッケージに依存されているか、エコシステム上でどれだけ重要かを評価し、貢献度を測る仕組みです。

その評価指標の一つが teaRank です。teaRank は Google の PageRank に着想を得たとされ、依存関係グラフ上で重要なパッケージほど高い評価を得ます(tea 公式ブログ: Proof of Contribution)。

開発者は、自分のプロジェクトに tea.yaml というファイルを追加し、ウォレットアドレスなどを登録することで、対象プロジェクトを tea の報酬対象として主張できる仕組みでした。

何が問題になったのか

問題は、評価指標として使われるデータが 操作可能だった ことにあります。

パッケージを新規作成すること、依存関係を追加すること、メタデータを付与することは比較的低コストでできます。そのため、実質的な OSS 貢献ではなく、報酬獲得を目的に大量のパッケージを作成したり、人工的な依存関係を作ったりする行動が発生しました。

このような行動は、トークンファーミング(報酬目的のシステム攻略)として問題視されました。

発生した影響

npm、RubyGems、PyPI、crates.io など、複数のパッケージレジストリでスパムパッケージの増加が報告されました。Socket の調査(2024年)では、npm の新規パッケージが平常の7倍を超え、レジストリ横断で約14,000 の tea 関連パッケージが確認されたとされます(Socket)。

RubyGems では、空の gem や不自然な依存関係、tea.yaml を用いたランキング操作の疑いが問題となりました。RubyGems 側は、tea.xyz の Proof of Contribution を名指しで調査し、公開制限の強化・監視強化・悪用アカウントの恒久ブロックといった対応を行っています(RubyGems 公式ブログ, 2024-04-14)。

npm でも、tea 関連メタデータを含む大量のスパムパッケージが報告されました。tea 側も後に、報酬設計がスパムや Sybil 攻撃に利用され得ることを認め、影響期間の報酬経路を止め、設計変更を行うと説明しています。

なお、時期の異なる2つの事象を混同しないよう注意が必要です。ここで扱うのは 2024年の初期スパム波 です。これとは別に、2025年以降には、トークンファーミングを狙って十数万規模の悪意あるパッケージが投入される、より大規模なマルウェア混入キャンペーンも報告されています。両者は規模も悪質性も異なります。

TEA トークンローンチの問題

2026年6月4日、TEA トークンは正式にローンチされました(Base 上の Aerodrome)。

しかし、ローンチ直後に価格が大きく下落しました。報道や分析では、初期流動性、トークンのアンロック条件、DEX 上での取引開始タイミングなどが問題として指摘されています。総括記事では、最高値をつけた直後に急落し、公開時点で最高値比おおよそ8割超の下落に至ったと報告されています(Nesbitt / CoinGecko)。

tea 公式も、ローンチ時の市場環境が厳しかったことに加え、ローンチ固有の問題や実行上の判断について内部レビューを行っていると説明しています。

このため、tea.xyz の事例は、OSS 報酬設計の問題だけでなく、トークンエコノミクスやローンチ設計の問題も含む複合的な事例 として見る必要があります。

問題の本質

この事例の本質は、OSS に報酬を払うことそのものではありません。

問題は、OSS の価値を単純なスコアに変換し、そのスコアに流動性のある金銭的報酬を自動接続した 点にあります。

OSS の価値は多面的です。コードを書くことだけでなく、保守、セキュリティ対応、ドキュメント、後方互換性の維持、リリース管理、issue 対応、初心者支援など、多くの地味な作業によって支えられています。

しかし、依存関係やパッケージ数のような測定しやすい指標に報酬を結びつけると、参加者はその指標を最大化しようとします。結果として、本来評価したかった OSS 貢献ではなく、報酬システム上のスコアを高める行動が増えます。

客観的に見るべき論点

1. OSS には報酬が必要か

必要です。現代のソフトウェア産業は OSS に大きく依存しています。一方で、多くの OSS は個人の善意、企業の任意スポンサー、財団助成、一時的な寄付に依存しており、持続性には課題があります。そのため、OSS メンテナに継続的な報酬を届ける仕組みを考えること自体は重要です。

2. 何に対して報酬を払うべきか

単にパッケージ数、スター数、ダウンロード数、依存数に報酬を払うのは危険です。より重要なのは、保守責任、セキュリティ対応、安定性、互換性、エコシステムへの貢献、長期的な信頼性に対して報酬を設計することだと考えられます。

3. 自動化できる範囲はどこまでか

データによる候補抽出や一次評価は有効です。しかし、最終的な価値判断まで完全自動化すると、指標がハックされやすくなります。特に金銭的報酬が絡む場合、測定指標は攻撃対象になります。そのため、アルゴリズムによる評価と、人間・コミュニティ・専門家による審査を組み合わせる必要があります。

4. ブロックチェーンは有効だったのか

tea.xyz の事例だけで、ブロックチェーンが OSS 報酬に無価値だったと結論づけるのは早計です。

ブロックチェーンは、資金の流れ、分配履歴、ガバナンス投票、国境をまたいだ支払い、公共財ファンディングの透明性を高める道具としては有効である可能性があります。

一方で、ブロックチェーンは「この OSS が本当に価値あるか」「この貢献が正当か」「このメンテナが信頼できるか」といった 判断そのもの を自動化するものではありません。ブロックチェーンの役割は、価値判断の代替ではなく、資金分配と説明責任の透明化 にあると考えるべきです。

この事例から得られる教訓

OSS の価値は単一指標では測れない。
測定可能な指標は、報酬と結びついた瞬間に攻略対象になる。
自動報酬システムは、Sybil 攻撃やスパムへの耐性が必要である。
OSS 報酬は、作成量よりも保守責任に重点を置くべきである。
ブロックチェーンは、価値判断ではなく、透明な会計・分配・監査に使う方が適している。
公共財ファンディングには、アルゴリズム、専門家判断、コミュニティ評価、制度的支援の組み合わせが必要である。

記事の着地点

tea.xyz は、OSS 報酬という重要な課題に対して、野心的なアプローチを取りました。しかし、報酬設計が操作可能な指標に依存したことで、スパムパッケージの大量発生やレジストリ側の負担を招きました。また、トークンローンチの混乱も重なり、プロジェクトの信頼性に大きな疑問が生じました。

ただし、この事例をもって、OSS 報酬やブロックチェーンによる公共財ファンディングの可能性をすべて否定するのは適切ではありません。むしろ、OSS の持続性を支えるには、報酬設計をより慎重に行い、測定しやすい指標ではなく、保守・信頼・安全性・長期的価値を評価する仕組みが必要です。

tea.xyz の事例は、OSS とブロックチェーンの失敗例であると同時に、公共財に対するインセンティブ設計の難しさを示す重要なケーススタディ です。