AI による完全自動化されたソフトウェア開発は存在すべきかという議論が、ついに白熱してきた。その発端となったのは
@yetone がメンテナンスしている magpie だ。同業者からは「ファストフードのようなサービス」「リスクが高すぎて使えない」と批判されている。
AI によるソフトウェア開発の自動化が時代の流れであることには、多くの人が同意するだろう。では、magpie はそれをどう実践しているのか？ 私は magpie のリポジトリをクローンし、過去 10 日間の 2,862 コミットを分析して、OpenClaw と比較してみた。
https://x.com/wquguru/status/2109458639501271530
19 日で 1204 バージョン
magpie は、Claude Code や Codex、Gemini CLI といったコーディングエージェントを、任意のモデルやサブスクリプションに接続するローカル LLM ゲートウェイだ。 9 月 22 日の初回コミットから今日までのわずか 19 日間で、 9,474 スターを獲得している。 2,862 コミットのうち、yetone のアカウントによるものが 85 % を占め、 383 件のコミュニティ PR がマージされた。
タグ数（バージョン数に相当）は 19 日間で 1,204 に達し、1 日あたり平均 60 以上のバージョンがリリースされている。これは人間の手作業では到底維持できないペースだ。対照的に、OpenClaw は最初の 19 日間で 1,423 コミットだったが、その 99 % は Peter Steinberger 本人によるもので、タグ数は約 10 個にとどまっている。
magpie はコミット数が 2 倍程度なのに対し、バージョン数は 100 倍以上なのだ。
私が解き明かしたかったのはただ一つ、このプロジェクトで AI はどのようにループを完結させているのか、ということだ。
ルーティングテーブルと失敗ノート
magpie の CLAUDE.md が参照しているファイルは AGENTS.md と LESSONS.md の 2 つだけだ。
AGENTS.md はルーティングテーブルである。それ自体がルールを定義しているわけではなく、エージェントが作業前にどのドキュメントを参照すべきかを指示するだけだ。サブシステムを変更する前は docs/subsystems/ を確認し、コードの記述やレビューは docs/code-standards.md に従い、コミュニティ PR のレビューは docs/contributors.md を参照する、といった具合である。
LESSONS.md の冒頭一文が、最初の疑問に答えてくれる。
magpie のコードは、エージェントによって書かれ、レビューされ、マージされ、リリースされています。 （magpie's code is written, reviewed, merged, and released by agents）
記述、レビュー、マージ、リリース——すべてエージェントが行っている。人間の監視がないのに、なぜ破綻しないのか？ その答えはこのファイルにある。 479 行からなるこのファイルは、いわば「失敗ノート」であり、毎晩エージェントによって書き込まれている。
毎晩、エージェントはその日の全コミットをレビューし、次の 3 つのケースに注目する。
- どの修正が手戻りしたか？
- そもそもどれがマージされるべきではなかったか？
- どの検証が杜撰だったか？
見つかった問題ごとに、ルールとその理由を記録し、証拠としてコミット番号と Issue 番号を添える。例えばこうだ。
修正完了とする前に、報告者が使用している実際の画面で、報告通りの事象を再現すること。
Issue 834 は 4 回手戻りした（v0.1.920 → .925 → .931 → .938）。各ラウンドで修正されていたのは、スクリーンショットに映っていたエージェントのみだった。 Seen 1× (2026-10-05)。
Issue 834 は 4 回手戻りしており、毎回スクリーンショットに映っていたエージェントだけを修正していた。そこで導かれたルールは、「修正完了とする前に、報告者が使っているインターフェースで正確に問題を再現すること」である。
重要なのは最後の行「Seen 1×」だ。同じ教訓が別々の日のレビューで 3 回出現すると、それは LESSONS.md から code-standards.md へ移動し、経験則から絶対的なハードルールへと昇格する。以降、すべての PR レビューでこれらのルールに一つひとつ照合しなければならない。
すでに 8 つのルールがこの方法で昇格している。例えば「類似のバグはまとめて修正する」（ 10 月 5 日、 6 日、 7 日にそれぞれ 1 回ずつ検出）、「main ブランチでテストが失敗したら即座に修正すべきバグとみなす」、「マージ前に何をどのコミットでテストしたかを明確に記載する」といったものだ。
もちろん、失敗ノートにはうまくいった事例も「Done right」として記録される。これによりエージェントは「やってはいけないこと」だけでなく、「代わりにこうすべきこと」も読み取れるようになる。
失敗ノートは 10 月 6 日の早朝に導入された
この仕組みは最初から設計されていたのだろうか？ LESSONS.md のコミット履歴を確認すると、初版はコミット 303819c5 で、 10 月 6 日の午前 3 時 10 分に作成されていた。
その前日の 10 月 5 日、magpie は 168 バージョンをリリースしている。
LESSONS.md の初版には、その日の状況が記録されていた。 220 コミット、約 170 リリースのうち、およそ 40 は同日または前日にリリースされたバージョンの修正だった。CI はほぼ毎回、次のプッシュによってキャンセルされていた。Linux でのみ失敗するテストが v0.1.877 から v0.1.892 まで赤信号のまま放置され、誰も気づいていなかった。
51 時間で 294 タグが切られたため、最後まで完了した CI ジョブは一つもなかった。 （294 tags in 51 hours meant no CI run could complete）
そこで初版にはこんなルールが追加された。タグ付けの前に、そのコミットの CI が完了しグリーンになっていること。新しいプッシュによってキャンセルされた実行はカウントしない。
初日は 168 リリース、2 日目は 42 、3 日目は 15 、その後 15 〜 26 の間で安定していった。
会議は開かれず、通知も送られなかった。夜間レビューで問題が発見され、失敗ノートにルールが追記されると、稼働中のエージェントがそれを読み取り、リリース頻度が自然と落ちていったのだ。
つまり、最近「問題だ」と指摘されていた 1 日 20 数回のリリースというのは、実はブレーキをかけた後のスピードだったのである。
PR の受け入れ基準
次に、実際の PR を見てみよう。
code-standards.md には 6 つの受け入れ基準が挙げられている。マージやリリースの前には、これらすべてをクリアしなければならない。 3 プラットフォームでのコンパイルやサンドボックスでのテストといった標準的なチェックはさておき、一般的なプロジェクトでは珍しい基準が 3 つある。
- リグレッションテスト：古いコードに戻したとき、新しいテストが明示的に失敗し、どの挙動が誤っているかを指摘できなければならない。コンパイルエラーやスキップされたテストは認められない。
- 実環境での利用：ベンダー統合を変更する場合、実際のアカウント、設定、API レスポンスで検証すること。テストされていない機能の上に構築したり、ユーザーに利用可能だと謳ったりすることはできない。
- 未実行のチェックは必ず列挙すること：
実行しなかったチェックは「未実行」として必ずリストアップし、決して省略しない。 （Checks not performed must be listed as not run, never omitted）
試しに #1339 をピックアップして、マージ前に残されたコメントを見てみた。
Red チェックはリグレッションテスト、Break チェックは意図的にコードを壊してテストが検知できるかを確認するものだ。そして最後の行には Not run、つまり実機ではテストしていないことが明記されている。
マージコマンドには --match-head-commit <reviewed sha> が含まれている。レビュー中に誰かがプッシュした場合、マージは失敗するようになり、レビューされていないコードが混入するのを防いでいる。
Human in the Loop（人間の関与）
もちろん、人間が関与する部分もある。少なくとも以下の領域だ。
- プロダクト判断：「意図的な決定を覆さない」。スクロールの挙動やボタンのカーソルなどは、PR で勝手に変更できない。
- セキュリティゲート：リスクチェックが作動した場合は、メンテナーの承認を待つ。
- コミュニティからの提案： 474 件のコミットタイトルに、X や Discord での報告者への言及がある（例：X の JonahFu、Discord の Jeremy.Zhou など）。
要するに、方向性の管理とゲートの見張りは人間が行い、記述・レビュー・マージ・リリースはエージェントが担っているのだ。
yetone は何か隠しているのか？
ここまで読んで、「yetone は何か隠しているのでは？」と思った人もいるだろう。私も気になったので、さらに深く掘り下げてみた。
確かに、リポジトリに含まれていない情報がいくつかある。
- 夜間レビューがどうトリガーされているかは文書化されていない。 4 つのワークフローはいずれもスケジュール実行ではない。
- LESSONS.md の更新時刻を 7 回分抽出してみたところ、 03:10 、 03:49 、 00:23 、 23:46 、 03:48 、 14:24 、 05:26 だった。バラバラで、cron ジョブというよりは手元での実行やカスタムスクリプトのように見える。
- 夜間レビューに使われているプロンプトもない。どのエージェントを使い、いくつのセッションを並列実行しているのかも文書化されていない。
調査の過程で、さらに 2 つのポイントが見つかった。
第一に、この手法にはコミュニティの貢献が含まれている点だ。 サブシステムのドキュメント化やセマンティックな変更のレビューは、コミュニティメンバーである Junjie Zhou 氏の PR #889 によって導入された。code-standards.md の冒頭にある 2 つの表は、コミット 926bcaa3 で、Junjie Zhou 氏が Discord で提案した 6 つのレビュールールに由来することが明記されている。
第二に、yetone とエージェントのやり取りがコミットに残されている点だ。 52 件のコミットタイトルに、yetone の生の言葉が括弧付きで含まれている。
1(the owner: This is too ugly)2(the owner: Why is this a native selector instead of our abstract ComboBox?)3(the owner: Why did this come back again? Didn't we say it should only appear on hover? Always appearing is too ugly)4(owner: During pr-preview, sometimes there's no data to test. Can you help create some fake data?)
これらは大半が一行の不満で、残りはエージェントが補完しており、コミット本文が数百語に及ぶことも多い。「ダミーデータを作ってほしい」という要望は、後に CI 録画用のモックデータセットとして採用された。
人間が「何が間違っているか」を指摘し、エージェントがそれを検証可能な変更へと落とし込む。この数十件のコミットタイトルは、どんなドキュメントよりも雄弁にその方法論を物語っている。
自分で構築したい場合
ルーティングテーブルなら誰でも書ける。本当に真似すべき価値があるのは、失敗ノートの仕組みだ。LESSONS のエントリは次のような形式になっている。
1**<One-sentence rule>**2- <Which commit/issue caused the problem, what was the consequence>3- <Fix commit>4- Done right: <Example of doing it correctly>5- Seen N× (YYYY-MM-DD, YYYY-MM-DD).
毎晩エージェントにその日のコミットをレビューさせ、手戻り・不適切なマージ・検証不足だけを探させる。同じ問題が別々の日に 3 回出現したら、コーディング規約へ移動させる。受け入れ時には、リグレッションテスト、実環境での利用、未実行項目をコミット本文や PR コメントに列挙する。
リポジトリ全体をレビューして最も感心したのは、「Seen 3×」という閾値だ。失敗が書き留められ、エージェントが起動時にそれを読み込み、同じ過ちを 3 回繰り返すとハードルールへ昇格する。「三度目の正直」という格言を見事に体現している（むしろ「三振アウト」と言うべきかもしれないが）。
最後に…
1 年前、あるいは半年前でさえ、モデルの能力が本番レベルの自動化に達することは稀だった。しかし今、特に Opus 5.5 の登場以降、私たちは確信できる——未来はすでにここにある。
これは @yuanhao 氏の Yoyo を思い起こさせる。 200 日以上自己反復を続けている Agent だ：https://yoyo-gasp.yolog.dev/ こちらもぜひチェックしてみてほしい。
