Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新

Jan 12, 2026 - 日記

Twitch Plays PokemonからOpen Chaosへ:群衆開発10年史と次の10年

Twitch Plays PokemonからOpen Chaosへ:群衆開発10年史と次の10年 cover image

先日、Hacker News で387ポイントを獲得したOpen Chaos というプロジェクトを見つけて、正直ワクワクしました。

「コミュニティ投票で進化するOSS」——このコンセプト、実は10年以上前から形を変えながら進化してきた「群衆開発」の最新形です。2014年のTwitch Plays Pokemon から始まった実験が、2026年にどう姿を変えたのか。そしてAI時代に何が起きるのか。まとめておきます。

Open Chaosとは何か

Open Chaosは、毎週日曜日09:00 UTCにコミュニティの投票で最も支持されたプルリクエスト(PR)を自動マージするプロジェクトです。

仕組みはシンプル

  1. 誰でもPRを提出できる
  2. GitHub リアクション(👍/👎)で投票
  3. スコア = 👍 - 👎
  4. 最高得票のPRが自動マージ
  5. 無限に繰り返す

変更可能な範囲は**「全て」**です。UIの完全変更、新機能追加、バックエンド追加、ゲーム化——ルール自体も含めて、すべてがコミュニティの投票で決まります。

現在のリポジトリはskridlevsky/openchaos で公開されており、技術スタックはNext.js 16、Tailwind CSS v4、Vercel という現代的な構成です。

逆説的な現実:「カオス」が秩序を生む

興味深いのは、「カオス」を掲げながら、実際に投票されているPRの内容です。

PR番号内容👍得票数
#6+1/-1リアクション計算の実装862
#13Rustで書き直し459
#51毎日マージ化342
#47IE6モード(GeoCities風)163

トップ得票は「投票システムの改善」です。カオスを目指しているはずなのに、人々は秩序を求めている——この逆説的な行動パターンは、Hacker Newsでも議論のテーマになっていました。

“Am I the only one who’s noticing that this ‘open chaos’ project’s most voted PRs are to add structure to the project?”

「このプロジェクトで最も投票されているPRが『構造の追加』だと気づいているのは私だけ?」

人間は本能的に、一定の秩序を求めるのかもしれません。

群衆開発の系譜:10年の進化

Open Chaosは突然現れたわけではありません。少なくとも10年前から、「群衆による創作」の実験は繰り返されてきました。

2014年:Twitch Plays Pokemon

群衆がゲームをコントロールする実験のイメージ

2014年2月、Twitch のチャット欄でポケモンをプレイするという実験が始まりました。視聴者がコマンド(「A」「B」「上」「下」等)を投稿すると、それがゲームに反映される仕組みです。

問題はすぐに顕在化しました。数万人が同時にコマンドを送ると、キャラクターはまともに動けません。壁に延々とぶつかり続ける光景が16日間続きました。

Anarchy vs Democracy

この問題を解決するため、開発者は「Democracy(民主主義)モード」を導入します。30秒間で最も多く投票されたコマンドを実行する仕組みです。

しかし、これが新たな対立を生みました。

  • Anarchy派: 「混沌こそ面白い。Democracy は本来の趣旨に反する」
  • Democracy派: 「進行不可能なら意味がない。合理的に進めるべき」

最終的に、コミュニティは「状況に応じてモードを切り替える」という妥協点を見つけ、16日17時間でクリアを達成しました。参加者は累計116万人を超えたと言われています。

教訓: 群衆の意思決定には「方向性」が必要です。完全な無秩序は機能しません。

1982年:Nomic(ルール変更ゲーム)

実は、Open Chaosのアイデアはもっと古くから存在していました。

1982年、哲学者Peter Suber が考案したNomic というゲームがあります。これは**「ルール変更がゲームのムーブ」**という、メタ的なボードゲームです。

  • プレイヤーはルール変更案を提案
  • 投票で可決されればルールが変わる
  • ルール自体を変更するルールも変更可能

GitHubを使った実装例として、mburns/nomic があります。PRで提案→リアクション投票→マージという流れはOpen Chaosと酷似していますが、Nomicには「勝利条件(200ポイント獲得)」があり、ゲームとしての構造を持ちます。

Open ChaosとNomicの違い: Open Chaosには「勝利条件」がありません。永続的に進化し続けることが前提です。

2019年:GitConsensus(ガバナンス自動化ツール)

GitConsensus は、GitHubリアクションを使った投票システムを汎用化したツールです。

.gitconsensus.yamlという設定ファイルでルールを定義し、リアクション数に応じて自動マージします。Open Chaosが「単一プロジェクトの実験」なのに対し、GitConsensusは「どのリポジトリでも使えるツール」として設計されています。

これにより、OSSプロジェクトのメンテナが不在でも、コミュニティの合意に基づいてプロジェクトを進められる可能性が生まれました。

ただし、GitConsensusは2019年から更新が止まっており、現在は活発に使われていません。**「ガバナンスをコードで記述する」**というアイデアは先進的でしたが、実際の採用には至りませんでした。

2026年:Open Chaos(エンターテインメント性の追加)

Open ChaosがGitConsensusと違うのは、エンターテインメント性です。

  • 公開Webサイト: openchaos.devでリアルタイム投票状況を確認できる
  • カウントダウン: 次のマージまでの時間が表示される
  • ユーモアあるPR: IE6モード、Rustで書き直し、毎日マージ化など

これは「ガバナンスツール」ではなく、「社会実験としてのショーケース」です。Twitch Plays Pokemonの「観客参加型エンターテインメント」要素を、GitHub上で再現した形と言えます。

技術的深掘り:GitHub APIによる投票→自動マージの実装

Open Chaosのような仕組みを自分のリポジトリで実装したい場合、GitHub Actions + GitHub APIで実現できます。

基本的な実装パターン

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# .github/workflows/auto-merge.yml
name: Auto Merge by Votes

on:
  schedule:
    - cron: '0 9 * * 0'  # 毎週日曜日 09:00 UTC

jobs:
  auto-merge:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      
      - name: Get PR reactions
        id: get_prs
        uses: actions/github-script@v7
        with:
          script: |
            const { data: pulls } = await github.rest.pulls.list({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'open'
            });
            
            // 各PRのリアクションを取得
            const prScores = await Promise.all(pulls.map(async (pr) => {
              const { data: reactions } = await github.rest.reactions.listForIssue({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: pr.number
              });
              
              const score = reactions.reduce((acc, r) => {
                if (r.content === '+1') return acc + 1;
                if (r.content === '-1') return acc - 1;
                return acc;
              }, 0);
              
              return { number: pr.number, score, createdAt: pr.created_at };
            }));
            
            // スコア順にソート(同点なら新しいPRを優先)
            prScores.sort((a, b) => {
              if (b.score !== a.score) return b.score - a.score;
              return new Date(b.createdAt) - new Date(a.createdAt);
            });
            
            return prScores[0]?.number || null;
      
      - name: Merge winning PR
        if: steps.get_prs.outputs.result
        uses: actions/github-script@v7
        with:
          script: |
            const prNumber = ${{ steps.get_prs.outputs.result }};
            await github.rest.pulls.merge({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: prNumber,
              merge_method: 'squash'
            });

GitConsensusとの設計思想の違い

GitConsensusは.gitconsensus.yamlで以下のような設定を記述します:

1
2
3
4
version: 1
quorum: 5          # 最低投票数
threshold: 0.65    # 可決に必要な賛成率
merge_method: squash

一方、Open Chaosは**「最も得票数が多いPRを無条件にマージ」**というシンプルなルールです。quorum(定足数)もthreshold(閾値)もありません。

この違いは、両者の目的の違いを反映しています:

  • GitConsensus: 「健全なOSSガバナンス」を目指す
  • Open Chaos: 「予測不可能な進化」を楽しむ

AIエージェント時代の群衆開発

Hacker Newsのコメントで興味深い指摘がありました:

“Is most code not written by LLMs these days anyway?”

「最近のコードって、ほとんどLLMが書いてるんじゃないの?」

実際、ClaudeChatGPT がコードを生成し、人間がそれをレビューしてマージするというワークフローは既に一般化しつつあります。

AIエージェントがPRを自動生成する未来

Open ChaosにAI エージェントが参加するとどうなるでしょうか?

シナリオ1: 民主的な進化

  • 複数のAIエージェントが異なる提案を自動生成
  • 人間が投票して方向性を決める
  • AIは人間の意思を実現する「手段」となる

シナリオ2: AIによる支配

  • AIエージェントが大量のPRを生成
  • 人間が追いつけず、実質的にAIが進化の方向を決める
  • Open Chaosは「AIが遊ぶ場」になる

どちらのシナリオも技術的には既に可能です。AIエージェントがGitHub APIを使ってPRを作成し、リアクションを投票するだけなら、数時間で実装できます。

GitConsensus的ルールの重要性

AIエージェントが参加する場合、GitConsensusのような「定足数」や「閾値」が重要になります。

  • 人間の投票を優先: 人間のリアクションだけをカウント
  • AIからのPRにラベル付与: ai-generatedラベルで識別
  • AIのPRは別枠で評価: 人間のPRと競合しないようにする

技術的には、GitHub APIのユーザータイプ(user.type === 'Bot')で判定可能です。

まとめ:次の10年に何が起きるか

2014年のTwitch Plays Pokemonから10年。群衆開発は以下のように進化してきました:

プロジェクト特徴
1982Nomicルール変更がゲームのムーブ
2014Twitch Plays Pokemonリアルタイム群衆操作
2019GitConsensusガバナンスの自動化
2026Open Chaosエンターテインメント性 + 完全自治

次の10年で何が起きるか?個人的には、以下のような進化が予想されます:

  1. AIエージェント参加型プロジェクト: 人間とAIが協調して開発
  2. DAO的ガバナンス: トークン投票とGitHubリアクションの融合(DAO = Decentralized Autonomous Organization、分散型自律組織)
  3. 自律進化OSS: メンテナ不在でもコミュニティが維持

Open Chaosは「実験」です。でも、この実験から学べることは多い。群衆の意思をどう集約し、どう方向性を与えるか——これはOSSだけでなく、組織運営や民主主義の問題でもあります。

自分みたいに「面白いプロジェクトを探している」人には、ぜひOpen Chaosに投票してみることをおすすめします。あなたの一票が、プロジェクトの未来を決めるかもしれません。

参考リンク