Code-Review on ROBOCO

オープンソースプロジェクトから学ぶソフトウェアファクトリーのベストプラクティス（2/4）：誰がマージするのか

Sat, 10 Oct 2026 10:00:00 +0900

「（マイグレーション・スキーマ・同期のパスへの変更は）マージ前に実際の人間によるレビューを受ける。例外も、セルフマージも、ボットだけによる承認もない（a real human review before merge — no exceptions, no self-merge, no bot-only approval）」 – Beads PR_MAINTAINER_GUIDELINES.md¹

チョン・ドヒョン - ROBOCO首席コンサルタント

この記事は、4回シリーズ「オープンソースプロジェクトから学ぶソフトウェアファクトリーのベストプラクティス」の第2回です。

シリーズの構成

第1回では、公開リポジトリ12か所をリバースエンジニアリングし、8か所をソフトウェアファクトリーと判定しました。² そのうち、ボットがmainブランチへのマージを大量に行っていることを確認できたのはOpenClawだけでした。ほかのファクトリーでは人による最終マージが主に観察され、そのマージはたいてい一人に集中していました。

今回はこの違いを掘り下げます。OpenClawはどのような条件でボットにマージを任せたのでしょうか。人のアカウントによるマージが観察されたプロジェクトは、なぜボットにマージを任せなかったのでしょうか。そして、その代わりに何によってエージェントの権限を制限しているのでしょうか。数値は第1回と同じく、2026年10月10日にGitHub APIで取得した値です。

TL;DR

OpenClawは、変更のリスク階層ごとに自動化の権限を変えています。ドキュメントの変更はエージェントがmainに直接pushし、通常のコードはゲートを通過すればボットがマージし、セキュリティポリシーとリリースは人が承認します。この階層はポリシーファイルとCODEOWNERSで定義されています。
人のアカウントによるマージが観察されたプロジェクトのリポジトリからは、その背景を3つ読み取れます。GitHub Appは自分のPRを承認できないという構造的な制約、レビューを省いたマージが事故を招いたという経験、そして何を作るか、変更が意図に合っているかは人が決めるという原則です。
人がマージした記録は、人がレビューした記録ではありません。BunではボットPRの82%が、GitHubの承認要件が残った状態でマージされました。OpenHandsでは、AIレビューボットの承認だけで必須承認を満たしたPRが多く見られました。マージ権限よりも重要なのは、その権限を行使する前に何を確認させるかです。

1. マージ権限のスペクトラム

まず、ファクトリーと判定したプロジェクトがマージをどう処理しているかを一つの表にまとめました。「マージ集中度」は、対象のPR群で最も多くマージした一つのアカウントの割合です。ブランチルールは、GitHub APIでmainブランチのルールを取得して確認しました。³

プロジェクト	マージゲート（ブランチルール）	観察されたマージ主体	マージ集中度
OpenClaw	必須チェック1つ、必須承認0件 + CODEOWNERSのパスのみ承認が必要	直近のマージ300件のうち203件をボットがマージ	-
Vercel AI SDK	必須承認1件 + 必須チェック4つ	9月のファクトリーPR 294件すべてを承認済みの状態で人がマージ	294件中63%
OpenHands	必須チェック1つ + 必須承認1件	直近のマージ100件すべてを人がマージ	100件中69%
Beads	必須チェック2つ + マージキュー	直近のマージ300件のうち296件を一つのアカウントがマージ	99%
mastra	公開APIでは確認できず	9月のボットPR 434件すべてを人がマージ	82%
Bun	公開APIでは確認できず	9月のrobobun PR 446件のうち443件を人がマージ	78%
Astro	必須チェックのリストが空	9月のファクトリーPR 31件すべてを人が承認・マージ	31件中28件

表の左の列が示すとおり、ボットによるマージを許す鍵はブランチルールです。OpenClawのmainブランチは必須承認の数が0です。その代わり、CODEOWNERSで指定したパスには該当チームの承認を求め、新しいコミットがpushされると以前の承認を無効にします。⁴ 一方、Vercel AI SDKとOpenHandsは1件以上の必須承認を求めます。この条件では、ファクトリーのAppは自分が作成したPRの承認要件を自分で満たせません。ただし、ほかのボットによる承認までは防げません。OpenHandsでは、実際にそうしたマージが多く見られました（5節）。

オープンソースプロジェクトから学ぶソフトウェアファクトリーのベストプラクティス（3/4）：証拠でふるいにかけるファクトリー

Sat, 10 Oct 2026 10:00:00 +0900

「USE_SYSTEM_BUN=1で通るテストは有効ではない（Your test is NOT VALID if it passes with USE_SYSTEM_BUN=1）」 – Bun CLAUDE.md¹

チョン・ドヒョン - ROBOCO首席コンサルタント

この記事は、4回シリーズ「オープンソースプロジェクトから学ぶソフトウェアファクトリーのベストプラクティス」の第3回です。

シリーズの構成

冒頭の引用は、Bunリポジトリのエージェント向け指示にある一文です。USE_SYSTEM_BUN=1は、修正する前の既存のBunリリースでテストを実行させる設定です。つまりこのルールは、「修正前のコードでも通るテストは何も証明しない」という意味です。

第2回では、マージ権限を誰に与えるかよりも、マージ前に何が確認されるよう強制するかが重要だとまとめました。² 今回はその確認の中身を扱います。エージェントはコードを素早く書きますが、常に通る無意味なテストや、実際より誇張した作業報告も簡単に作ります。そしてBunのエージェントrobobunが2026年9月の1か月間に作成したPRは2,313件です。³ この規模では、人がすべてのdiffを読むことはできません。そこでファクトリーは、人がコードを読む前にまず証拠を見るようにしています。数値はこれまでの回と同じく、2026年10月10日にGitHub APIで取得した値です。

TL;DR

観察した事例をまとめると、ファクトリーが求める証拠は三層です。問題が実際に存在することを示す再現、修正前には失敗し修正後には通るテスト、そして単体テストを超えた実際の動作の証拠です。
そのうち3つのプロジェクトがそれぞれ異なる方法で実装した仕組みが、「修正前の失敗」の証明です。BunはPR本文に修正前の失敗ログを添付し、mastraはCIが新しいテストを修正前のコードに対して実行して失敗するかを確認し、観察したVercel AI SDKの修正PRは再現 → 失敗するテスト → 修正の順にコミットを積み上げていました。
証拠は回避されることがあります。mastraでは修正前失敗ゲートの失敗ラベルが付いたままマージされたPRがあり、Astroでは「動作する」と確認された修正が意図と異なっていたため差し戻されました。証拠の仕組みは、マージ条件と結びついたとき、そして意図まで確認したときに効力を持つと私は考えています。

1. 三層の証拠

観察したプロジェクトがエージェントに求める証拠を私の基準でまとめると、3種類になります。

証拠の種類	問いかける質問	代表的な仕組み
再現	問題は実際に存在するか	Vercel AI SDKの再現PR、Astroの再現ステップ
修正前の失敗	このテストは本当にその問題を捉えるか	Bunの証拠ブロック、mastraの修正前コードテストゲート、Vercel AI SDKのコミット順序
実際の動作	単体テストの外でも動作するか	OpenClawの動作証拠ラベル、OpenHandsのライブE2E、Astroのプレビューリリース

私は、この三層が順番に積み重なるものだと考えています。再現がなければ何を直したのかがわからず、修正前の失敗がなければテストが何を証明しているのかがわかりません。そして、単体テストが通っても実際の環境では壊れることがある、というのが三層目が必要な理由です。

2. まず再現する

Vercel AI SDKのファクトリーは、バグのIssueを受け取るとまず再現を試みます。再現に成功すると、サンプルファイルと再現記録ファイル（reproduction-replay.json）を含むドラフトPRを作成します。観察したIssue #22412の再現PRは、確認後にクローズされました。⁴ 再現結果はラベルとして残ります。task-bug-reproduction-success、-cannot-reproduce、-issue-invalid、-out-of-scopeといったラベルがあり、サポートしているバージョン（v5、v6）ごとに結果を個別に記録します。⁵ この結果によって次のステップが分岐するように見えますが、ファクトリーの内部ルールはリポジトリの外にあるため、確認できませんでした。

Astroのファクトリーは、再現 → 診断 → 意図の検証 → 修正の順に作業します。各ステップには止まるためのルールがあります。再現用サーバーの起動に2回失敗すると、あきらめてレポートを書きます。診断の確信度が低ければ、そこで止まります。意図の検証ステップで「意図された動作」と判定すると、修正しません。⁶ 確信度が低いときには、コードを直す代わりに失敗するテストと// TRIAGE:コメントだけを残す経路もあります。人が引き継げるように、手がかりだけを残すのです。