アリババエンジニア、GitHub Trending 5 連覇と AI コーディング手法

タイトル（参考のみ・出力に含めない）: 连续五天登上 GitHub Trending 首页的思考

著者：李峥峰

2026年8月11日 18:18 浙江

この記事では、オープンソース開発に取り組むエンジニア向けに、応用可能なメソドロジーを共有するとともに、AI コーディングの極致に関する考え方を紹介します。

これは 2026 年の第 49 回記事です。

（本文の読了時間：約 15 分）

私たちのチームは、2 ヶ月前に AI コードレビューツールをオープンソース化しました。現在、このプロジェクトは GitHub で 2 万スターを獲得しています（プロジェクトURL: https://github.com/alibaba/open-code-review）。

生成されたコードの 100％が AI によるものであり、レビューも 100％AI が行いました。その結果、800 件以上の Issue や PR を受け付け、100 名を超える外部コントリビューターが参加し、GitHub Trending のトップページに連続 5 日間ランクインしました。

この好成績の背景にある要因を振り返り、何が正しく、何が間違っていたのかを検証します。オープンソース開発を目指すエンジニアにとって応用可能なメソドロジーを共有するとともに、私たちが目指す AI コーディングの極致についても触れていきます。

01

オープンソース化する前に、自社の強みと立ち位置を明確にすること

実際の業務から生まれ、真の問題を解決するツールであるべきです。単なる「オープンソース化」のために作るものではありません。

私たちのチームは、AI によるコードレビューの取り組みを約 2 年間行っています。アリババ社内では月間アクティブユーザーが 2 万人を超え、採用率は 30％以上、誤報率は 5％未満です。また、マージされた基線への有効な提案のうち、約 8 割は AI が生成したものです。ユーザーに対してすべての AI の提案を処理させることを強制していませんが、この規模のユーザーベースにおいてこれらの数値は非常に良好だと言えます。

正直なところ、当初はオープンソース化することを考えてはいませんでした。転機となったのは 2026 年からです。周囲の人々が口にする共通の課題、「AI が書いたコードが多すぎて確認しきれない」「マージすることに不安がある」という声が増えたのです。この痛みは非常にリアルで、私自身も同様の経験があります。

Faros AI が発表した『The Acceleration Whiplash』というレポートも、この状況を裏付けています。4,000 のチームと 22,000 人の開発者に関する 2 年間のテレメトリデータによると：

AI コーディングツールの導入により、開発者のタスク完了率は 34% 向上し、コード活動量は 210% も急増しました。しかし、その代償は甚大です。コードの書き換え率が 861% も跳ね上がり、各 PR（プルリクエスト）が引き起こす本番環境での事故発生率は 242.7% 増加。PR の平均レビュー時間も 441.5% 延長され、レビューを経ずに直接マージされる PR の割合も 31.3% 上昇しました。

スループットは上がりましたが、品質の維持が追いついていません。

そこで市場にある主要なソリューションを調査しましたが、すでに商業化されている大手を除けば、残りはデモレベルのオープンソースプロジェクトばかりでした。AI の時代において 0 から 1 を作ることは極めて容易で、数日あれば何とかなります。しかし、大規模環境で実際に検証されたオープンソースの解決策はほとんど存在しませんでした。

そこで私たちは一つの機会を見出しました。

私たちの立ち位置

「世界最高」と主張するつもりはありませんが、私たちが解決する課題や対象とするユーザー層は非常に広範です。

1. 本番環境での検証: 「使いやすい」という言葉だけの話ではありません。2 万人のユーザーによる本番環境での実証データと、200 の実際の PR をラベル付けしたベンチマーク評価セットのスコアを提示しています。内部開発と外部公開は同期しており、すべてのバージョンで同じ品質を保証します。

1. 特徴あるアーキテクチャ: 「決定論的エンジニアリング × エージェント協働」のハイブリッドアーキテクチャを採用しています。単に大規模言語モデル（LLM）を被せるわけでも、スキル（skill）を追加するだけではありません。コードレビューという「絶対にエラーが許されない」場面においては、言語モデルではなくエンジニアリングロジックで安全性を保証します。AI の真価が発揮されるべき領域——動的な意思決定や文脈の動的検索にリソースを集中させるのです。

1. データのローカル保持: フレームワークのみを提供し、ユーザーデータを一切扱いません。LLM はユーザー自身が選択できます。これは企業利用において必須の要件です。

1. 低コスト: トークン消費量は、Claude Code + Skills 構成の約 1/9 です。

1. 多様な接続方法: CLI、IDE プラグイン、各種エージェントプラグイン、CI-CD、MCP など、あらゆるユースケースに対応可能です。

1. オープンで包容的: フレームワークをコミュニティ開発者に無料で提供し、誰もが同じ車輪を再発明する必要のない環境を作ります。共に使いやすいツールを構築しましょう。

さらに、直感に反する重要な戦略があります。「欠点をあえて公開すること」が「完璧さを演出すること」よりも効果的だということです。私たちは README に、現在まだ不十分な点や課題を率直に記載しています。一見すると自らの評価を下げるように思えますが、実際には来訪者の期待値が明確になり、利用後に失望することが減り、結果としてリテンション（継続利用率）が高まります。逆に、過度に完璧な印象を与えてユーザーが入ってみたら期待と異なっていた場合、最初の反応は「騙された」というものであり、こうしたネガティブな評判の拡散速度はポジティブなものよりも遥かに速いのです。

後日、なぜ 100 以上のメディアが自発的に取り上げてくれたのかを振り返ると、その本質はこれらの要素が重なり合った結果だとわかります。信頼できるバックグラウンド、具体的なデータ、他社との比較、コスト削減、そして安全性です。

02

まずは完成させ、その後で完璧を目指す

この戦略には 2 つの鍵があります。

1. タイムリミット: 3 ヶ月かけて磨き上げる余裕はありません。その間に競合がユーザーの心をとらえてしまうからです。
2. 不完美さの価値: すべてを完璧に仕上げてしまうと、外部からの貢献者が参画する余地がなくなり、コミュニティは育ちません。

では、「完成」とはどう定義されるのでしょうか？

私たちがリリースした最初のバージョンには、以下の要素のみが含まれていました。

1. Go 言語でゼロから書き直された CLI ツール。
2. カスタムモデルを設定するためのコマンドと、OpenAI および Anthropic プロトコルへの対応。
3. レビュー機能を提供する一連のコマンドと、フレームワークの核となる部分。
4. Claude Code に直接統合可能な専用スキル（skill）。
5. ユーザーが自身の GitHub リポジトリに容易に組み込める GitHub Action。
6. 自社内部システムへの統合を支援するための可観測性（observability）機能。

2 ヶ月後の現在

v1.0.0 から v1.9.0 へ。100 個の正式リリース、100 名以上の貢献者、そして 100 件を超える機能追加コミット（そのうち 60% 以上が外部からの PR）。

振り返ってみれば、「まずは完成させ、その後で完璧を目指す」というのは単なるリリース戦略ではありません。それはコミュニティの参加形態を定義するものです——余地を残せば、誰かがそれを埋めに来るのです。

内部コアチームが構築したのはフレームワークの骨格です：Agent のループ、メモリ圧縮、Scan モード、MCP、ルールエンジン、VSCode プラグイン、そしてスキル。コミュニティによって育まれたのはその血肉です。

接入方式

当初は CLI と GitHub Action の組み合わせから始まり、現在は GitLab CI、Gerrit（Jenkins）、Agent Skill、ホスト側の Agent サブスクリプションを流用する委託モード、そして MCP クライアントまで多様な接続方法に対応しています。

モデルエコシステム

内蔵プロバイダーは当初の 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 の伝播機能を強化しています。

エンジニアリングの充実

セッションの復元機能、トークン予算ガード、コメントのバッチ分割処理、Windows 向けワンクリックインストールスクリプトなど、実用性を高める機能が追加されました。

もし v1.0.0 のリリース時点でこれらすべてを完備してから公開していたとしたら、少なくとも一ヶ月は遅れていたでしょう。また、これらの機能の半分はコミュニティが自らのユースケースから「育んできた」需要によるものです。初期段階でそれらを全て予測するのは不可能です。

ここでもう一つ、教訓として共有させてください。当初私たちはコア機能の完全性やフレームワークの核にばかり注目が向き、最も重要な入口となる LLM 設定の簡素さを軽視していました。その結果、初期にアクセスしたユーザーの転換率が極めて低かったのです。「人が来て、使いこなせず、去っていく」という状況でした。

その後、「使いやすさこそが転換率である」と悟りました。「ユーザーがいち早く使い始められること」は「まずは形にする（MVP）」の範疇であり、後回しにしてはいけない課題です。そこで迅速に主要なモデルベンダーを内蔵し、GUI によるインタラクションを実装。ユーザーはキーを一つ設定するだけで利用できるようにしました。

ユーザーの認知負荷を慎重に増やす

この意識は最初からあったわけではなく、徐々に育まれたものです。

最も典型的な例が README です。コミュニティでの発展に伴い多くの開発者が貢献し、多様な機能が追加された結果、README は肥大化しました。「ダウンロード方法（3 種類）」「設定手順（3 種類）」「多様な接続方式」「上級者向けテクニック」「エコシステム連携」「MCP」「Web Viewer」「可観測性への接続」など、初めてページを訪れた人がどこから手をつけていいか迷う状態になっていました。

この問題に気づいた私たちは、README に残すべきは「あなたは何者か」「なぜこれを選ぶべきか」「どうやってすぐに始められるか」の 3 点のみとし、他はすべてドキュメントサイトへ移管しました。その結果、README は 1000 行から 200 行に短縮されました。

もう一つの落とし穴が CLI パラメータです。パラメータを一つ増やすごとに、ユーザーが --help を実行した際のリストは一行長くなります。「オプションが増えただけ」に見えるかもしれませんが、実際には認知負荷が一層重くなるのです。ユーザーは「このパラメータを使うべきか？使わなければどうなる？」と迷い、パラメータが多ければ多いほど、手を出せなくなります。

ただし、何も追加してはいけないという意味ではありません。重要なのは、新しい機能が同じユーザーに対して選択肢を増やすかどうかです。

反例を挙げましょう。GitLab CI と GitHub Actions の両方を同時にサポートすることは、複雑さを増すことにはなりません。なぜなら、GitLab を使う人は GitHub Actions のドキュメントを見ず、GitHub を使う人が GitLab CI の設定方法に関心を持たないからです。これら二つのユーザー層は異なる平面にあり、互いの存在を意識しないからです。

最近、私たちは --max-tools パラメータを設計しました。これはサブタスクでのツール呼び出し回数を制限し、極端なケースにおけるツールの無限ループやコストを抑制するためです。その後、コミュニティの開発者から、レビュー全体の総ツール呼び出し回数を制御する --max-tool-calls と、トークンコストを物理的に制約する --max-tokens-budget というパラメータが提案されました。私たちは前者を却下し、後者を採用しました。ユーザーに「どちらのパラメータを使うべきか」で迷わせるような設計は避け、複雑さを増やさないように努めています。

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

ユーザーが訪れたら、5 分以内にコアバリューを理解し、すぐに実行できる状態にする。このフローを長くしたり、迷わせたりする変更はすべて慎重に検討すべきだ。

04

迅速な対応：コミュニティの活気はこの一点で決まる

私がこのプロセス全体を通じて最も重要だと考える認識がこれだ。

面白い現象がある。外部からの貢献者の中で最も活発な人々のほとんどは、私たちが働く時間帯（タイムゾーン）と近いのだ。最初は偶然かと思ったが、後になって理由がわかった——タイムゾーンが近ければ、PR を提出した瞬間に即座に返信ができる。この速いフィードバックループこそが貢献者を留める鍵だ。逆に言えば、対応速度そのものが貢献者を選別し、定着させるメカニズムなのである。

私たちの対応ペースは以下の通りだ。

• 小さなバグや機能追加：12 時間以内のリリースで修正。最速なら 2 時間で完了する。
• コミュニティからの Issue や Discussion：投稿されれば即座に返信が来る。
• コミュニティからの PR：提出されれば即座に確認され、迅速なレビューとマージが行われる。

2 ヶ月で 89 バージョンをリリース。ほぼ毎日 1〜2 回だ。

これをどう実現したのか？人手だけで支えることは不可能だ。

正直に言えば、このペースを人力だけで維持するのは到底無理だ。その背後には、AI を活用したコーディングワークフロー全体がある。

• 内部開発者が書くコード：100% AI 生成、100% AI によるレビュー
• 外部貢献者が提出するコード：100% AI によるレビュー

では人間は何をするのか？AI の出力を検証し、最終的な判断を下すことだ。

具体的には、以下のコアスキルを実装した。

/read-issue：Issue を素早く理解し、自動的にタグ付け

/mk-issue：問題の背景に基づき構造化された Issue を作成

/mkpr：現在の改変内容に基づき PR を自動生成

/review：Claude Code と gh cli を組み合わせてコードをレビューし、自動修復

/open-code-review：OCR を活用して自身でコードをレビュー・自動修復

/release-eval：リリース変更がコアプロセスに影響するか評価。影響がある場合はテストスイートを実行（1 回に約 8 時間かかる）

/tag：新バージョンのタグ付け

/comment：人間の意図に基づき返信内容を推敲し、友好的かつプロフェッショナルなトーンを維持。メンテナーの返信品質はコミュニティの雰囲気に直結するが、毎回丁寧に文章を作るのは時間がかかる。このスキルで「伝えたいこと」を「適切な表現」に変換している。

ワークフロー自体も進化してきた。

初期：Claude Code でコード作成 → Skills によるレビュー → CC（Claude Code）で修正

現在：Claude Code でコード作成 → OCR を pre-commit-hook として自動レビュー → CC が自動修復 → /mkpr で PR 作成 → GitHub Actions が再度レビューとガードレールタスクをトリガー → CC が最終修正

安定性はどのように担保しているのか？自動化されたコードレビュー、ユニットテスト、Lint、CI/CD パイプライン、そして E2E テストスイート（200 の PR を含む）などだ。イテレーションが速いからこそ、これらの安全網が不可欠となる。

All in Code

このワークフローが機能する背景には、見落としがちだが極めて重要な前提がある——「すべてはコードである」ことだ。

CI/CD は YAML で定義され、レビュールールは JSON、リリースプロセスは Makefile と shell スクリプト。ドキュメントサイトは MDX 形式。Issue テンプレートや PR テンプレートに至るまですべて Markdown ファイルだ。重要なフローのどこにも、GUI ベースの管理画面や Wiki ページ、あるいは特定の人間の頭脳の中に隠された部分は存在しない。

つまり、エージェントが読み込み、変更し、実行できる状態にある。AI にリリースを任せても、cat コマンドで Makefile を確認するだけで何を実行すべきか理解する。レビュールール作成を依頼すれば、既存の rule.json を grep して形式を理解する。もしリリースプロセスが「3 つのボタンをクリックし、2 つのフォームに入力し、承認待ち」という手順なら、エージェントは介入する余地さえ持たない。

「All in Code」は新しい概念ではありません。DevOps の時代にはすでに「Infrastructure as Code」という言葉が叫ばれていました。しかし、Agent（自律型エージェント）の時代において、その価値は桁違いに高まっています。コードこそが、Agent が最も自由に操作でき、かつエラーを起こしにくい媒体だからです。

あなたのプロセスをいかに「コード化」できるかによって、AI に任せる割合は決まります。そうすれば、人間が残るのは真に判断力を要する意思決定のみとなります。

人と AI の関係性

ここ二ヶ月間、「人と AI はどう協働すべきか」という点について、私は明確な認識を持つようになりました。

AI は複数の解決策を提示したり、具体的な実装を実行したりするのは得意です。しかし、AI に「どの方案を選ぶか」から任せてはいけません。最終的な意思決定権は人間が握るべきです。

この教訓は、ある事故を通じて得たものです。HN（Hacker News）のトップに載る前日、私たちは AI にツール呼び出しロジックの最適化を依頼しました。コード自体も AI が書いたものであり、AI は自分が書いたコードについて人間よりも熟知しているはずだと考え、変更方法や方針を指定せず、すべて任せてしまいました。

単体テストは通過し、いくつかのサンプルを実行しても問題なさそうだったのでリリースしました。しかし、結果としてグローバル検索機能にバグが発生してしまいました。二日後、HN の話題で大量のトラフィックが流入した際、初めて利用するユーザーがこの罠にはまってしまったのです。

これが何を意味するかは明白です。多くのユーザーにとって、あなたのサービスに対する第一印象とは「使い物にならない」というものです。そう思われた瞬間、彼らは離脱し、二度と戻ってきません。

痛烈な反省から、私たちは二つのルールを設けました。

1. コアとなるフローに影響を与える変更は、200 件の PR（Pull Request）のテストセットを実行して合格してからでなければリリースしないこと。
2. AI にコードを書かせる際は、明確な方針制約を与え、自由奔放に振る舞わせないこと。

私の日常の時間配分は概ね以下の通りです。AI の出力レビューとコミュニティとの対話に 60%、方向性の策定と Issue（課題）の分解に 40% を割いています。

05

コア開発者が骨格を構築し、細部はコミュニティへ委ねる

健全なオープンソースプロジェクトには、二種類の貢献者が不可欠です。安定したコアコントリビューターと、絶え間なく流入する新規参加者です。

なぜコアメンバーが定着するのか？それは「共同の達成感」です。皆でプロジェクトを成功に導き、その成果が大きくなるほど満足度が高まるという好循環（フライングホイール）が生まれます。

では、どうやって新人を引きつけるのか？答えは「Good First Issue（初心者向け課題）」です。

「Good First Issue」の本質

これは単に「見栄えを良くするための作り物」ではありません。実際に必要とされる作業でありながら、参入障壁が低いタスクであるべきです。重要なのは、背景を明確に記述し、具体的な验收基準（受け入れ条件）を示し、適切な難易度を設定することです。

コア開発者の日常業務の中に、こうした Issue を継続的に生み出す仕組みを組み込む必要があります。これは追加作業ではなく、コミュニティ構築そのものです。

一つの教訓

GitHub Trending のトップページに初めて載った際、翌日には姿を消しました。その原因は単純でした。新人が入っても、やるべきことがないからです。スター（Star）を押して去り、何の交流も生まれませんでした。

2 回目の Trending 登頂時には、私たちは二つの施策を行いました。

1. 直ちに多数の Good First Issue を作成し、新規参加者が明確に参加できる入口を用意した。
2. PR が提出され次第即座に対応し、「投稿すれば必ず注目される」という体験を提供した。

その結果、5 日連続で Trending トップにランクインしました。

論理は非常にシンプルです。

新人が参入 -> 実行可能なタスクを発見 -> PR を提出 -> 迅速なレビューとマージ -> 達成感を得る -> Star やシェアを行う -> さらに多くの人が参入 -> ループが完成し、Trending に定着する

Trending の上位に上がるのは製品力によるものですが、そこに留まり続けるのはコミュニティの活発さによります。この二つは別物です。

06

自ら積極的に広めることよりも、「拡散されやすい状態」を作ることが重要

私たちが意図的に行ったプロモーションはたった2回だけです。ただし、Alibaba 自体が巨大な無料トラフィックの入口であることは否定できません。私たちが伝えたいのは「プロモーションなしでも爆発する」という話ではなく、初期の勢いが生まれた後、いかにして拡散を自走させるかという点です。

AI を駆使したイノベーションカンファレンスで発表を行いました（OpenCodeReview もその一部です）。また、公式 WeChat 公众号（公式アカウント）での自発的な紹介が増えたため、グループ傘下の公式アカウントにも投稿しました。

その後は自然な流れが生まれました。

カンファレンスでの発表 -> コミュニティ内での議論 -> 公式アカウントによる自発的な紹介 -> Trending への掲載 -> HNコミュニティからの投稿 -> 100 以上のメディアによる拡散

6月6日にはHNのトップに登場し、スター数は 1,500 から一気に 4,000 に跳ね上がりました。

なぜこのプロジェクトがこれほどまでに広がったのか。振り返って分析すると、いくつかの要因が見えてきます。

まず、「AI によるコードレビュー」は、現在の開発者が抱える不安に対する絶好の出口となっています。「AI が書いたコードが増えているが、その品質はどう担保すればいいのか」という問いは、多くの人が直面している課題です。

また、信頼できるブランドからの後押しがあるため、情報の信憑性も高いと言えます。ベンチマークデータや比較グラフといった具体的な数値や視覚資料があれば、メディアやインフルエンサーがそのまま記事に活用することも容易になります。

さらに、解決すべき課題は明確で本質的です。「トークン数の削減」と「データのセキュリティ」。これらは業界全体が共通して抱える切実な要望です。

つまり、派手なマーケティング活動に頼る必要はありません。重要なのは、潜在的な拡散者（共感してくれる人々）をいかに増やし、彼らが情報を広めやすい環境を整えるかにかかっています。

07

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

振り返れば、このプロジェクトが今日に至るまで成長できたのは、以下の 3 つの要素が同時に整っていたからです。

第一層：組織からの信頼

オープンソース化における最大のリスクは技術ではなく「組織」にあります。コードを公開することは、設計思想や実装レベルをすべて透明化する行為であり、経営陣に決断力と覚悟が必要です。より現実的な問題として、オープンソースには継続的な人件費の投入が不可欠です。これが正式な目標としてサポートされず、あくまで「空き時間」で行われるものだと認識されていれば、開発ペースは維持できません。

2 ヶ月間で 89 バージョンをリリースできたのは、内部でこのプロジェクトを「本格的に投資すべき対象」として位置づけ、「暇な時にやる程度」の扱いではなかったからです。

第二層：安定したコアコントリビューター（貢献者）

コミュニティには常に入退去があり、それは自然なことです。しかし、中核となる貢献者の輪が切れてはいけません。「PR（プルリクエスト）を提出したが、これはマージすべきか？」という判断や、「マージ後に回帰バグが発生した場合の修正」は、プロジェクトに深い理解を持つ人々によって行われなければなりません。

コアコントリビューターは外部から採用するのではなく、コミュニティの中から「育つ」ものです。その定着率は、プロジェクト側がどれだけ迅速に応答し、貢献を認めるかにかかっています。「PR を提出しても 1 週間反応がない」となれば、どんなに熱意を持っていても離れてしまいます。人が定着しないのはプロジェクト自体が良くないからではなく、フィードバックのスピードが遅いからです。

第三層：実ユーザーからの継続的なフィードバック

この要素は最も見落とされがちです。オープンソース化するのはフレームワークですが、真の参入障壁となるのは、その背後にある「ユーザーが経験した課題」や「検証済みの判断」です。私たちがオープンソース化する前にはすでに 2 年間、2 万人規模のユーザーによる本番環境での検証が行われていました。これらがなければ、v1.0.0 は単なるデモの一つに過ぎません。

オープンソース化之后、外部から寄せられたフィードバックは全く異なる価値をもたらしました。内部では環境が統一されている一方、外部には千差万別の利用シーンが存在します。「Gerrit への接続」「Ollama を使ったローカルモデルの活用」「Windows スクリプトの対応」など、これらはすべて外部の実世界という土壌から「育まれた」機能です。

内部ユーザーは「この道なら通れる」と検証し、外部ユーザーは「まだ開拓すべき道がある」ことを発見します。コミュニティを作る前にまずユーザーが必要であり、順序を間違えると非常に苦しい思いをすることになります。

08

結びに

今こそ、オープンソースに取り組むのに最適な時代です。

AI が、これまでメンテナンス担当者の時間を大幅に奪っていた反復作業（Issue の分類、コードレビュー、テストケースの作成、リリース作業など）を自動化しました。小規模なチーム、あるいは個人でも、かつて 10 人規模のチームが担っていたペースを維持できるようになりました。参入障壁は下がりましたが、その分、上限も下げてはいけません。節約された時間を、真に判断力が必要な領域——方向性の決定、意思決定、コミュニティ運営——に注ぎ込むべきです。

私が特に重要だと考える認識をいくつか挙げます。

デモのためにオープンソース化してはなりません。

AI の時代において 0 から 1 を作ることは容易になりました。コミュニティにはデモが溢れていますが、必要なのは検証済みのソリューションです。「判決」の材料となるものが硬ければ硬いほど（本番環境でのデータ、ベンチマーク結果、実ユーザー規模など）、他者があなたのプロジェクトを拡散する際の根拠も強固になります。

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 日：二度目の Github Trending 掲載 / 1.5k
• 6 月 6 日：Hacker News のトップニュースに / 1.5k → 4k
• 7 月 23 - 28 日：連続 5 日間 Github Trending ホームページに掲載 / 10.5k → 15.5k

*プロジェクト公式サイト：https://open-codereview.ai*

GitHub Trending ホームページに 5 日連続で登場した理由について考える

コメント欄で一緒に議論しましょう。

WeChat で開くにはこちらへ