この記事の内容
8 月、私たちの AI 開発ループが作った直近 10 件のプルリクエストを数えてみました。1 回目のレビューを通ったものは 1 件もありません。問題がなくなるまでに、合わせて 43 回のレビューが必要でした。
悪い数字に見えますが、そこが狙いです。このループは、人が変更を見る前に AI が自分の間違いを見つけるように作られています。この記事では、その仕組みと、途中で起きた問題、そして私たちが変えたことを紹介します。
このループは、Claude Code を音声で動かすデスクトップアシスタント Miko Assistant の一部です。Miko にタスクを頼むと、Miko は /miko-dev を実行するセッションを始めます。計画、採点、コード、レビューの 4 つを、それぞれ別の AI モデルが担当します。私たちは毎日これを使っていて、Miko 自身の開発にも使っています。
ループの仕組み
各ステップは、それぞれ専用のモデルを持つ別のエージェントとして動きます。計画は A+ がつくまで書き直します。コードはレビューで問題がなくなるまで修正します。どちらのループも 3 回で止まります。
なぜモデルを使い分けるのか
最初はシンプルでした。Fable が計画し、Fable が計画を採点し、Opus がコードを書く。ところが、費用のほとんどがコードを書く工程にかかっていることに気づきました。書き手に強いモデルが必要だったのは、計画が設計の判断を書き手に任せていたからです。
そこで 8 月、設計の仕事を計画の側に移しました。
- 計画は概要ではなく、作業の足場であること。 変更するファイル、すべての関数の完全なシグネチャ、すべてのテストとその確認内容、エッジケースとその扱い、変更の順番まで書きます。
- 採点役の基準は 1 つ。 より安いモデルが、設計の判断を 1 つもせずにこの計画を実行できるか。できなければ A+ ではありません。
- コードを書くのは Sonnet。 判断はすでに済んでいるので、必要なのは発明ではなく丁寧な作業です。
- レビューするのは Opus。 自分のコードをレビューするモデルは、自分と同じ見落としをします。強いモデルの価値が出るのはレビューです。安いモデルが見落としたものを見つけるのが仕事だからです。
つまり、判断が必要なところにだけお金をかけるということです。
何が壊れ、何を変えたか
最初のバージョンが動いたのは 7 月です。それ以来、元になっているテンプレートは 30 回以上変わりました。どの変更も、実際に使っていて起きた問題がきっかけです。
この記事の冒頭の数字が、8 月 26 日の変更につながりました。
2 つのループ、1 つの作業コピー。 同じリポジトリで動く 2 つのループが、1 つの作業コピーを共有していました。片方がコミットの途中で、もう片方がブランチを切り替え、コミットが別のブランチに入ってしまいました。今は、ループごとに専用の git worktree でコードを書きます。
誰も確認しない修正。 最初、レビューは 1 回きりでした。レビュー役が問題を見つけ、書き手が直し、その修正はレビューされないまま入っていました。今は修正のたびに、レビュー役が変更全体を読み直します。ループが終わるのは、最新のバージョンのレビューで問題がなかったときだけです。
終わらないレビュー。 そのルールが、冒頭の数字の原因になりました。10 件のプルリクエストで 43 回のレビュー。1 回目で問題がなかったものはなく、4 件は上限の回数に達するか、それを超えました。1 回のレビューに 3〜14 分。コメントだけを直した 26 行の変更に、5 回かかりました。
原因は細かいことでした。言い回しの修正や古いコメントのような、ちょっとした手直ししか見つからない回でも、もう一度フルレビューが走っていました。さらにレビュー役は、前の回の修正の言い回しにまで指摘を続けていました。そこで指摘を「不具合」と「手直し」に分けました。手直しだけの回は、それを反映して終わります。上限は 3 回に減らし、必ず守るようにしました。
記録と合わないまとめ。 確認した 2 回の実行の両方で、ループの最後のまとめが、プルリクエスト上の自分のレビューコメントと食い違っていました。人が読むのはまとめなので、今はすべての数を記憶ではなくコメントから取ります。
何を公開するかは、今も人が決める
このループは、計画、コード、レビュー、プルリクエストの作成までを自分で行えます。でも公開はできません。それを守るのが次のルールです。
- マージしない。 Miko が始めるセッションは、どれもプルリクエストのマージを禁止されています。Claude Code は、最も制限のゆるいモードでもこの禁止を守ります。ループは開いたプルリクエストで止まり、人が Miko に「ship it」と伝えます。
- そのバージョンそのもののレビュー。 レビューコメントの最後には、レビューしたコミットを示すスタンプが付きます。公開のステップが受け付けるのは、最新のコミットに対する問題なしのスタンプだけです。以前のチェックはコミットに言及したコメントなら何でも受け付けたので、ビルドのメモでも通ってしまいました。
- レビューが行われた証拠。 レビューコメントには、レビュー役自身のトークン数と実行時間が入ります。自分の仕事を自分でレビューした書き手には出せない数字なので、レビューを飛ばせばすぐに分かります。
- 手抜きはバックログへ。 採点役の指摘を技術的負債として受け入れたときは、プルリクエストの「Deferrals」に書きます。変更が公開されると、それぞれが新しい issue になります。
- 週に 1 度の見直し。 週に 1 回、スケジュールされたクラウドエージェントがその週にマージされたものをすべて見直し、小さな修正を 1 つのプルリクエストにまとめます。それをマージするのも人です。
まだ改善の途中
このループは完成していません。チームで今も改善を続けています。数字が示したときに変え、どの変更もこのループ自身を通してから公開しています。
私たちがつくるものを使う方にとって、結果はシンプルです。どの変更にも、コードを書く前に採点された計画、すべてのレビューの記録、そして承認した人がいます。
Miko にできることを見てみませんか。Miko Assistant の事例を読むか、作りたいものを聞かせてください。
