---
title: "GitHub Trending トップページに5日連続で掲載されて考えたこと"
date: 2026-07-29
tags: [振り返り, オープンソース, 方法論, AI Coding]
summary: Open Code Review をオープンソース化してから2ヶ月間の振り返り —— ポジショニング、リリース戦略、コミュニティ運営、そして徹底した AI コーディングのワークフローの背後にある再現可能な方法論。
author: lizhengfeng101
---

> 私たちのチームは2ヶ月前に [AI Code Review ツール](https://github.com/alibaba/open-code-review) をオープンソース化しました。現在 **15.5k スター** です。
> 100% AI 生成コード、100% AI レビューコード、600 近い Issue+PR、100 名近い外部コントリビューター、5 日連続で GitHub Trending トップページに掲載。
> この機会に、それらの数字の裏側を振り返ってみたいと思います —— 何がうまくいき、何を間違えたのか。オープンソースを考えている開発者に再現可能な方法論を残せればと思いますし、あわせて私たちの徹底した AI コーディングの考え方も共有します。

---

## 一、オープンソース化の前に、コアとなる競争力とポジショニングを明確にする
> 本物のビジネスの中から生まれ、本物の課題を解決する —— オープンソースのためのオープンソースにしない。

私たちのチームは AI コードレビューをほぼ2年間やってきました。Alibaba 社内で月間アクティブユーザー 20k、採用率 30%+、誤検知率 5% 未満、ベースラインにマージされた有効な提案のうち 8 割近くが AI 由来です。ユーザーに AI の提案をすべて処理するよう求めているわけではなく、これだけのユーザー規模でこの数字はかなり良いものです。正直なところ、最初はオープンソース化するつもりはありませんでした。転機は '26 年からで、周囲でますます多くの人が同じ問題を口にするようになったのです ——「コードは AI が書くもので、量が多すぎてレビューしきれず、マージする勇気が出ない」。この痛みは本当にリアルで、私自身も感じています。
> Faros AI が発表したレポート『The Acceleration Whiplash』もこれを裏付けています —— 4,000 チーム、22,000 名の開発者による2年間のテレメトリデータが示すのは：
> AI コーディングツールは開発者一人あたりのタスク完了度を 34% 向上させ、コード活動は 210% 急増しましたが、その代償として、コードの手戻り率は 861% 急騰し、PR あたりの本番障害の発生率は 242.7% 上昇、PR の平均レビュー時間は 441.5% 延び、レビューを経ずにそのままマージされる PR の割合も 31.3% 上昇しました。スループットは上がったものの、品質が追いつかなくなったのです。


次に、市場に出回っている大半のソリューションを調べました。すでに商用化されているトップの数社を除けば、残りは demo レベルのオープンソースプロジェクトの山でした。AI 時代に 0→1 のものを作るのはあまりに簡単で、数日あれば一つできてしまいます。しかし、本当に大規模に検証されたオープンソースのソリューションはほとんど存在しませんでした。

そこで私たちはチャンスを見出したのです。

### 私たちのポジショニング

私たちは自分たちを最高だとは主張しません。しかし、私たちが解決する痛みと対象とする層は十分に広いのです。

1. **本番環境での検証**：口で「使える」と言うだけではなく、20k ユーザーの本番環境からの本物のフィードバックがあり、200 件の実際の PR にアノテーションを付けた benchmark 評価セットのスコアもあります。社内外が同一ソースで、各バージョンを社内外で同時にリリースしています。
2. **特徴あるアーキテクチャ**：「決定論的エンジニアリング × Agent 協調」のハイブリッドアーキテクチャです。大規模モデルをラップしただけでも、skill を書いただけでもありません。コードレビューにおける「間違えられない」部分は、言語モデルではなくエンジニアリングのロジックで担保し、AI の強みを本当に得意な領域 —— 動的な意思決定、動的なコンテキスト想起 —— に集中させています。
3. **データはローカルから出ない**：フレームワークのみを提供し、ユーザーのデータには触れません。LLM は自分で選べます。これは企業のシーンでは必須要件です。
4. **安価**：Token 消費量は Claude Code + Skills 構成の 1/9 です。
5. **多様な連携方法**：CLI、IDE プラグイン、各種 Agent プラグイン、CI/CD、MCP、好きなように使えます。
6. **オープン、開放的、包容的**：フレームワークを無償でコミュニティ開発者に渡し、誰もが車輪の再発明をせずに済むようにし、みんなで本当に使いやすいツールを作り上げます。

もう一つ、直感に反する点があります：**不足を自ら開示するほうが、完璧を演出するよりも効果的です。** 私たちは README に、現状まだうまくできていない点を数多く率直に書きました。自分に減点を付けるように聞こえますが、実際の効果は、来た人が正しい期待を持ち、使ってがっかりせず、リテンションがむしろ高くなるというものです。逆に、話を盛りすぎると、ユーザーが来て期待と違うと気づき、最初の反応が「騙された」になります —— こうしたネガティブな口コミは、ポジティブなものよりはるかに速く広がります。

なぜ 100 以上のメディアアカウントが自発的に拡散してくれたのかを後で振り返ると、本質的にはこれらが積み重なった結果でした：裏付けがあり、データがあり、比較があり、コストを節約でき、安全である。メディアが記事を書くには「素材」が必要で、そのまま引用できるものを与えなければならないのです。

---

## 二、まず完成させ、それから完璧にする

1. **ウィンドウは限られている**。3ヶ月磨いている間に、他の誰かがすでにユーザーの心の中の場所を占めてしまうかもしれません。
2. **不完全であることはむしろ良いこと**。すべてが完成していると、外部コントリビューターに参加する余地がなく、コミュニティが立ち上がりません。

### 「完成」をどう定義するか？

私たちがリリースした最初のバージョンが提供したのは、いくつかの内容だけでした：
1. Go 言語でゼロから書き直した CLI ツール。
2. カスタムモデルを設定する一つのコマンド、および OpenAI、Anthropic プロトコルへの互換対応。
2. 一連のレビューコマンドとフレームワークのコア。
3. Claude Code に直接統合できる付属の skill。
4. ユーザーが自分の GitHub リポジトリに直接統合できる付属の GitHub Action。
5. ユーザーが自社内部のシステムに統合できる可観測性の機能。

### 2ヶ月後の現在

v1.0.0 から v1.8.0 まで、89 の正式リリース、81 名のコントリビューター、100 以上の feature commit（うち 67 は外部 PR 由来）。振り返ってみると、「まず完成させ、それから完璧にする」は単なるリリース戦略ではなく、コミュニティの参加の仕方を定義するものでした —— 余地を残せば、人がそれを埋めに来るのです。

社内のコアチームが組み上げたのはフレームワークの骨格でした：Agent ループ、メモリ圧縮、Scan モード、MCP、ルールエンジン、VSCode プラグイン、Skill。コミュニティが育てたのはその肉付けです：

- **連携方法**：当初の CLI + GitHub Action から、GitLab CI、Gerrit（Jenkins）、Agent Skill、委譲モード（ホスト Agent のサブスク枠を再利用）、MCP クライアントへ。
- **モデルエコシステム**：組み込みの provider が 3 個から 14 個へ拡大（Ollama ローカル、LiteLLM ゲートウェイ、Eden AI などを含む）、OpenAI、Anthropic、OpenAI Responses の3つのプロトコルに対応。
- **言語カバレッジ**：Python、Rust、Kotlin、C/C++、FreeMarker、GraphQL、Julia、HCL/Terraform、Bicep など専用のレビュールールを追加。
- **可観測性**：セッションビューア（Web UI）、OpenTelemetry 連携の最適化、W3C traceparent の伝播。
- **エンジニアリングの充実**：再開可能なセッション、token 予算ガード、コメントのバッチ分割、Windows ワンクリックインストールスクリプトなど。

もし v1.0.0 の時点でこれらをすべて作ってからリリースしていたら、少なくとももう1ヶ月余計にかかったでしょうし、これらの機能の半分はコミュニティが自分たちのシーンから「育てた」ニーズでした —— 最初に予見するのは難しいものです。

ここで一つ、必ず共有しなければならない教訓があります。初期の私たちはコア機能の完成度に注力しすぎ、フレームワークのコアに注意が集中してしまい、最も入口となる LLM の設定方法を十分に簡単にできていませんでした。その結果、初期に流入した一波のトラフィックがあったものの、コンバージョン率は非常に低かったのです —— 人は来たが、使いこなせずに去っていきました。

その後、一つのことに気づきました：**使いやすさこそがコンバージョン率である**。「ユーザーができるだけ早く使えるようにする」ことは、それ自体が「まず完成させる」の範疇に属し、後回しにできません。そこで私たちは急いで複数の主流モデルベンダーと GUI インタラクションを組み込み、ユーザーが key を一つ設定するだけで使えるようにしました。

---

## 三、ユーザーの認知的な複雑さを増やすことには慎重に

この意識は徐々に育ったもので、最初からあったわけではありません。

最も典型的な例は README です。コミュニティの発展に伴い、ますます多くの開発者が参加して貢献し、さまざまな機能を開発したため、README はどんどん大きくなっていきました：ダウンロード方法（3種類）、設定方法（3種類）、複数の連携方法、上級者向けの使い方、エコシステム連携、MCP、Web Viewer、可観測性の連携など。初めてアクセスした人は、どこを見ればいいのか全くわかりません。

この問題に気づいた後、私たちは次のものだけを残しました：あなたは誰か、なぜ私たちを選ぶのか、どうやって素早く始めるか。その他はすべてドキュメントサイトに移し、見出しとジャンプリンクだけを残して、README を 1000 行から 200 行に短縮しました。

もう一つ落とし穴になりやすいのが CLI フラグです。フラグを一つ追加するたびに、ユーザーが `--help` を打ったときに見えるリストが一行長くなります。「選択肢が一つ増えた」ように見えますが、実際には認知的負担が一層増えたということです —— ユーザーは「このフラグは付けるべきか？付けないとどうなる？」と考え始めます。フラグが多いほど、ユーザーは手を出すのをためらうようになります。

とはいえ、何も追加できないという意味ではありません。鍵となるのは：**新しく追加するものが、同じユーザーにより多くの選択を迫るかどうか** です。

反例を挙げましょう：GitLab CI と GitHub Actions の連携を同時にサポートすることは、複雑さを増やすことにはなりません。なぜなら、GitLab を使う人は GitHub Actions のドキュメントを見ることすらなく、GitHub を使う人は GitLab CI の設定方法を気にしないからです。この2種類のユーザーは同じ平面上におらず、互いに相手のものが見えません。

最近こんな問題に遭遇しました。私たちはサブタスクのツール呼び出しラウンド数を制限するために `--max-tools` フラグを設計し、極端なケースでのツールループを制御しコストを制約していました。その後、コミュニティの開発者がレビュー全体のツール呼び出し総回数を制御する `--max-tool-calls` フラグ、および token コストを物理的に制約する `--max-tokens-budget` フラグを提案してくれました。私たちは前者を却下し、後者を受け入れました。すべてのユーザーを「どのフラグを使えばいいのか」に陥らせないようにする —— これこそが本当に複雑さを増やしているかどうかの分かれ目です。

判断基準は実はとてもシンプルです：

```
ユーザーが来る -> 5分でコアバリューを理解して動かせる -> 興味があれば詳細を見る
```

この経路を長くしたり、ためらわせたりする変更は、どれも一度立ち止まって考えるべきです。

---

## 四、素早い応答：コミュニティが生きるか死ぬかはこれで決まる

これは、全プロセスを通じて私が得た最も重要な気づきです。

面白い現象があります。外部コントリビューターの中で最も活発な人たちは、ほぼ全員が私たちの勤務時間帯に近いタイムゾーンにいました。最初は偶然だと思いましたが、後で腑に落ちました —— タイムゾーンが近いということは、あなたが PR を出せば私がすぐに返せるということで、ポジティブなフィードバックループが速く、人が残るのです。逆に言えば、**応答速度そのものが、コントリビューターを選別し維持する仕組みなのです**。

私たちの応答のペースはおおむね次のようなものです：

- 小さなバグ、小さな機能：12時間以内にリリースして修正、速いときは2時間。
- コミュニティの Issue & Discussion：投稿されればすぐに返信される。
- コミュニティの PR：投稿されればすぐに見られ、できるだけ早く review & merge。
- 2ヶ月で 89 バージョンをリリース、基本的に毎日1〜2個。

### どうやって実現したのか？人力だけでは無理

正直に言うと、人力だけではこのペースを到底維持できません。その背後にあるのは、一式の AI コーディングワークフローです：

**社内開発者が書いたすべてのコード：100% AI 生成、100% AI レビュー。**
**外部コントリビューターが提出したコード：100% AI レビュー。**
**人は何をするのか？ AI の出力をレビューし、最終的な判断を下す。**

具体的には、私たちはいくつかのコアとなる Skill を作りました：

- `/read-issue`：Issue を素早く理解し、自動でラベルを付ける
- `/mk-issue`：問題の背景をもとに構造化された Issue を作成する
- `/mkpr`：現在の変更内容をもとに自動で PR を作成する。
- `/review`：Claude Code + gh cli でコードをレビューし自動修正する
- `/open-code-review`：OCR 自身でコードをレビューし自動修正する
- `/release-eval`：リリースの変更がコアパスに影響するかを評価し、評価セットを走らせるかどうかを決める（1回走らせるのに8時間かかる）
- `/tag`：新バージョンをリリースする
- `/comment`：人間の意図をもとに返信内容を推敲し、フレンドリーでプロフェッショナルなトーンを保つ。maintainer の返信の質はコミュニティの雰囲気に直接影響しますが、一つひとつ丁寧に言葉を選ぶのは時間がかかりすぎます。この skill は「言いたいこと」を「適切な言い回し」に変えてくれます。

ワークフローの進化も興味深いものです：

- 初期：Claude Code がコードを書く -> Skills がレビュー -> CC が修正
- 現在：Claude Code がコードを書く -> OCR が pre-commit フックとして自動レビュー -> CC が自動修正 -> /mkpr がレビューを作成 -> GitHub Actions が再度のレビューといくつかのガードレールタスクをトリガー -> CC が修正

安定性は何で担保するのか？ 自動コードレビュー + ユニットテスト + Lint + CI/CD パイプライン + E2E 評価セット（200 件の PR）など。反復が速いからこそ、これらのセーフティネットが下で支えていることが一層必要になります。

### All in Code

このワークフローが機能するには、見落とされやすい前提が一つあります：**すべてがコードである** ということです。

CI/CD は YAML、レビュールールは JSON、リリースプロセスは Makefile + shell、ドキュメントサイトは MDX、Issue テンプレートや PR テンプレートまで markdown ファイルです。重要なプロセスが GUI の管理画面や wiki ページ、あるいは誰かの頭の中に隠れていることは一切ありません。

これは、Agent が読める、変更できる、実行できる、ということを意味します。AI にリリースを頼めば、Makefile を `cat` して何を実行すべきかわかりますし、レビュールールを書いてもらえば、既存の `rule.json` を `grep` してフォーマットがわかります。もしあなたのリリースプロセスが「ボタンを3つ押し、フォームを2つ埋め、承認を待つ」というものなら、Agent は入り込む余地がありません。

All in Code は新しい概念ではなく、DevOps の時代から Infrastructure as Code が叫ばれてきました。しかし Agent の時代には、その価値が一桁分増幅されます —— **コードは Agent が最も自律的に操作しやすく、最も間違いを起こしにくい媒体なのです**。あなたのプロセスが「コード化」されているほど、AI が引き受けられる割合は高くなり、あなたの手に残るのは本当に判断力を要する意思決定だけになります。

### 人と AI の関係

この2ヶ月を経て、「人と AI がどう協働すべきか」について、私はかなり明確な考えを持つようになりました。

AI は複数の案を提示するのが得意で、具体的な実装を実行するのも得意です。しかし、**AI に自分で案を選ばせてから実行させてはいけません** —— 意思決定権は人の手になければなりません。

この気づきは、一度の事故と引き換えに得たものです。HN のトップに載る2日前、私たちは AI にツール呼び出しのロジックを最適化させました。コードはもともと AI が書いたものなので、AI のほうが自分の書いたものに詳しいはずだと考え、どう変えるかを指定せず、案は AI 自身に決めさせました。ユニットテストは通り、いくつかの例を走らせても問題なさそうだったので、リリースしました。ところが、グローバル検索のツールにバグを作り込んでいたのです。2日後 HN のトラフィックが押し寄せ、ユーザーは初めて使ったその一発でこの落とし穴を踏みました。それが何を意味するかわかるでしょう —— 多くの人のあなたに対する第一印象が「これは使えない」になり、タブを閉じて二度と戻ってこないのです。痛みを教訓に、私たちは2つのルールを定めました：コアパスに影響する変更は、200 件の PR の評価セットを完走してからでなければリリースしない。そして、AI にコードを書かせるときは、必ず明確な方針の制約を与え、自由に振る舞わせない。

私の日々の時間配分はおおむね：AI の出力のレビュー + コミュニティとのやり取りが 60%、方向性の決定 + Issue の分解が 40% です。

---

## 五、コア開発者がフレームワークを組み、細部はコミュニティに任せる

健全なオープンソースプロジェクトには2種類の人が必要です：安定したコアコントリビューターと、絶えず流入する新参者です。

安定したコントリビューターは何で引き留めるのか？ 共通の誇りです。みんなで一緒にプロジェクトを良くし、プロジェクトが良くなるほど達成感が増す —— これはフライホイールです。

新参者は何で引きつけるのか？ Good First Issue です。

### Good First Issue のコツ

これは人をあしらうために「でっち上げた」タスクではなく、本当にやる必要があるけれど敷居が高くない仕事です。鍵は、背景を明確に書き、明確な受け入れ基準を示し、難易度を適切にラベル付けすることです。コア開発者は日々の仕事の中でこうした issue を継続的に生み出すべきです —— これは余分な仕事ではなく、コミュニティ構築の一部です。

### 一つの教訓

初めて GitHub Trending のトップページに載ったとき、翌日には消えていました。振り返るとその理由は単純でした：新参者が来ても、やることがなかったのです。star を付けて去っていくだけで、その後のやり取りは一切ありませんでした。

2回目に Trending に載ったとき、私たちは2つのことをしました：

1. すぐに一群の good first issue を作成し、新しく来た人に明確な参加の入口を与えた。
2. PR が来たらすぐに対応し、「提出すればすぐに注目される」という体験を生み出した。

結果：5 日連続で Trending のトップページに掲載されました。

そのロジックは実はとても素朴です：

```
新参者が来る -> できることが見える -> PR を出す -> すぐに review & merge される
-> 達成感がある -> star / シェア -> より多くの人が来る -> 循環が回り出す
```

Trending に載るのは製品力によりますが、Trending に留まるのはコミュニティの活発さによります。この2つは別物です。

---

## 六、拡散されやすくすることは、自分で拡散するより重要

私たちが自ら行ったプロモーションは2回だけです —— ただし、Alibaba 自体が巨大な無料のトラフィック源であることは認めなければなりません。私たちが本当に共有できる経験は「プロモーションをしなくてもバズる」ではなく、初期の勢いを得たあとに、どうやって拡散が自ら転がり出すようにするか、です。

1. ある AI 駆動のイノベーションサミットで発表した（Open Code Review はその内容の一部）。
2. WeChat 公式アカウントで多くの自発的な紹介があった後、自分たちでも公式アカウントに記事を一本投稿した（Alibaba Cloud 開発者アカウント）。

そして、それだけです。その後のことは自然に起こりました：

```
サミットでの発表 -> コミュニティでの議論 -> WeChat 公式アカウントの自発的な紹介 -> Trending 入り -> HN コミュニティで誰かが投稿 -> 100+ のメディアアカウントが拡散
```

6月6日に HN のトップに載り、star は 1.5k から一気に 4k へ跳ね上がりました。

なぜ拡散したのか？ 事後に分析してみました：

- AI Code Review はちょうど今の開発者の不安のはけ口である —— コードはますます AI が書くようになり、どうやって品質を担保するのか？
- ブランドの裏付けがあり、信頼性が十分。
- benchmark のデータや比較図があり、メディアがそのまま使える。
- 痛みがリアル：token の節約とデータの安全性、この2つは普遍的な要求である。

本質的に、あなたは大々的なマーケティングを必要としません —— より多くの潜在的な拡散者を引きつけ、その潜在的な拡散者が拡散する敷居を下げるだけでいいのです。

---

## 七、オープンソースが成功するかどうかは、この3つの層で決まる

振り返ってみると、このプロジェクトが今日まで来られたのは、3つの層の支えが同時に整ったからです。

**第1の層：組織の信頼**

オープンソース最大のリスクは技術ではなく、組織です。コードを公開するということは、設計力がすべて透明になるということで、経営層に胆力が求められます。より現実的には、オープンソースには継続的な人的投入が必要で、正式な目標として支援されず、純粋に余暇の時間に頼るだけでは、ペースを維持できません。

2ヶ月で 89 バージョンは、社内でそれを正式なプロジェクトとして投資し、「暇なときにやる」ものにしなかったことが前提です。

**第2の層：安定したコアコントリビューター**

コミュニティが来ては去るのは普通のことですが、コアチームは途切れてはいけません。新参者が PR を出したとき、マージすべきかどうかを誰が判断するのか？ マージして regression が出たら誰が修正するのか？ すべて、プロジェクトを深く理解している人に頼ることになります。

コアコントリビューターは採用するものではなく、コミュニティの中から「育つ」ものです。転換率は、あなたの応答速度と承認の度合いに左右されます。PR を出して1週間誰も見なければ、どんなに熱心な人でも去っていきます。**人を引き留められないのは、プロジェクトが十分でないからではなく、フィードバックが十分に速くないからです。**

**第3の層：本物のユーザーからの継続的なフィードバック**

この層は最も見落とされやすいものです。オープンソース化するのはフレームワークですが、その堀（moat）は、その背後でユーザーが踏んできた落とし穴と、検証されてきた意思決定です。私たちはオープンソース化の前にすでに2年間、20k ユーザーの本番検証を持っていました。これがなければ、v1.0.0 はまた一つの demo にすぎなかったでしょう。

オープンソース化した後、外部ユーザーは全く異なる価値をもたらしてくれました —— 社内環境は統一されていますが、外部のシーンは千差万別です。Gerrit 連携、Ollama ローカルモデル、Windows スクリプト、これらはすべて外部の本物のシーンから「育った」ものです。

社内ユーザーは「その道が通じること」を検証し、外部ユーザーは「まだどんな道が残っているか」を発見します。まずユーザーがいて、それからコミュニティがある —— 順序を逆にすると、とても苦しくなります。

---

## 最後に

今は、オープンソースをやるのに史上最高の時代です。

AI は、かつてメンテナーの膨大な時間を食っていた反復的な作業（Issue の仕分け、コードレビュー、テストの記述、リリース……）を自動化しました。小さなチーム、あるいは一人でさえ、かつての10人チームのペースを支えられるようになりました。敷居は下がりましたが、上限は下がっていません —— 節約できた時間は、本当に判断力を要するところに使います：方向性を決め、意思決定をし、コミュニティを運営することに。

私が最も重要だと考える気づきをいくつか：

**demo をオープンソースにしてはいけない。** AI 時代に 0→1 を作るのはあまりに簡単で、コミュニティに不足しているのは demo ではなく、検証されたソリューションです。あなたの「判決書」が硬いほど（本番データ、benchmark、本物のユーザー規模）、他の人があなたを拡散してくれるときの底力が増します。

**Trending はゴールではなく、スタートである。** トラフィックが来ても受け止められなければ、店の扉を開けたのに棚が空っぽなのと同じです。あらかじめ good first issue を用意しておくのはズルではなく、アクセスしてくれた一人ひとりの時間を尊重することです。

**AI は10倍速の手だが、頭脳は自分自身でなければならない。** 100% AI 生成コードは成り立ちます。ただし、人が「何をするか」と「正しくできているか」をしっかり握っていることが前提です。コミュニティに素早く応答できるのは、眠らないからではなく、AI のワークフローが「issue からリリースまで」を2時間に圧縮したからです。

---

*主要なタイムライン*

| 日付 | 出来事 | Star           |
|------|------|----------------|
| 5月21日 | v1.0.0 正式リリース | 0              |
| 5月28日 | 初めて GitHub Trending 入り、翌日に脱落 | 400            |
| 6月5日 | 2回目の GitHub Trending 入り | 1.5k           |
| 6月6日 | Hacker News のトップに掲載 | 1.5k -> 4k     |
| 7月23〜28日 | 5日連続で GitHub Trending トップページ | 10.5k -> 15.5k |

プロジェクト：[GitHub](https://github.com/alibaba/open-code-review) ｜ 公式サイト：[open-codereview.ai](https://open-codereview.ai)
