Two desk lamps facing each other over a sheet of paper marked in red pencil
Back to blog
EngineeringAI Automation

2,481回の相互レビュー:Claude CodeとCodexがお互いの仕事を確認する

2か月間、公開前にClaude CodeとCodexが互いの仕事をレビューするようにしました。2,481回のレビューで数字は何を示したのか。そして、追加せざるを得なかったルールとは。

S
Sno AI Team
September 22, 2026
|
6 min read
|
139 views
Share:

Claude Codeが仕事を終えると、公開前にCodexがそれを読む。Codexが書いたものはClaudeが読む。

銀行も同じように動く。自分の融資を自分で承認する人はいない。ある人が書類を作り、別の人が署名する。それを侮辱とは受け取らない。私たちは、二つのAIエージェントがペアで同じ仕事に取り組み、一方が実行し、もう一方がレビューするこの方式をDual Brainと呼ぶ。Sno Stationに組み込まれていて、私たちは七月半ばからずっとこの中で仕事をしている。

レビューのたびに、ビルド用マシンのログファイルに一行が残る。少し前に気になって、数えてみた。

件数

七月19日から九月21日までに、二つのAIエージェントは互いの仕事を2,481回レビューした。そのうち実際に稼働したのは63日間で、一日あたり約39回。9,452ファイル、3.2百万行を読んだ。

レビューには約二分かかる。中央値は141秒で、十回中九回は六分未満で終わる。この数字は見た目以上に重要だ。人によるレビューには一日かかり、その大半は人を待つ時間だ。二分なら、レビューする価値があるかどうかを考えなくなる。すべてをレビューする。

大半は通ると思っていた。

判定が出たレビューのうち、431回は承認だった。1,953回は要対応。つまり五回に四回、二番目のAIエージェントが仕事を差し戻した。

五回に四回。疲れたインターンが書いた雑な初稿ではない。モデルはすでにテストを実行し、作業は終わったと言っていた。

コードと計画

次に、コードのレビューと計画のレビューを別々に数えた。

コードが通ったのは27%だった。1,475回中398回が承認された。よくはないが、何とか受け入れられる。

計画が通ったのは3.6%だった。907回中33回。

思わず見直した。計画は文書だ。何を、なぜ作るのかを書く。コンパイルする必要がないのだから、コードより文書のほうが正しく書きやすいと思うかもしれない。実際は逆だ。コードは実行するたびに現実に訂正される。計画には、存在しないデータベースの列があると書けてしまう。誰かがそれを前提に作り始めるまで、その一文はまったくもっともらしく見える。

そこで今は、計画と一緒に事実もレビュアーに渡す。計画のレビュー前に、書き手のAIエージェントがコマンドを実行し、行数を数え、スキーマを出力して、その生の出力を添付する。これでレビュアーは主張と照らし合わせる材料を得る。それがなければ、資料なしの試験だ。文書内の矛盾は見つけられても、文書と現実の食い違いは見えない。

重大な指摘の多くは、まさにその隙間から生じた。同じ期間に、レビュアーは1,395回のレビューで4,277件の重大な問題を指摘した。私はすべてを確認したわけではないし、すべてが実在するわけでもない。ただ、本当にあった問題には共通点があった。誰も実際には確認していないことが、自信たっぷりに書かれていたのだ。

うまくいかなかったこと

ここで終われば、いい話だ。これだけのレビューで仕事がよくなったと思いたい。

そう単純ではない。レビュアーは必ず何かを見つける。

後のラウンドを見てほしい。書き手が指摘を修正して再レビューを頼んだ後、仕事が通った割合は21%だった。最初のラウンドでは17%。すべての指摘を直しても、通る確率はほとんど変わらない。ある仕事は十五ラウンドも続いた。

書き手が十五回失敗したわけではない。レビュアーがレビュアーらしく振る舞っただけだ。有能なモデルに問題を探すよう頼めば、問題を見つける。普通の使い方で問題がなければ、隅を探す。同じミリ秒に届く二件のリクエスト。書き込みの途中でのキャンセル。起こり得なくはない。隕石に当たるのも起こり得なくはないのと同じだ。

そして書き手は素直に、一つ見つかるたびに何かを足して直す。

今月初め、小さなバグがあった。修正は六ラウンドのレビューを経た。毎回レビュアーが新しい懸念を出し、毎回書き手が防御策を足した。トークン数の上限。セッションごとのロック。提供済みのものを追跡する別のテーブル。別名の対応関係。最後には、パッチは小さな要塞になっていた。

これらの仕組みが本番環境で動くことは一度もなかった。その下には、修正そのものに一行の同一性に関するバグがまだ残っていたが、防御策に埋もれて誰も気づかなかった。小さな楽器の音を聞こうと音量を上げたら、聞こえてくるのはほとんど雑音だった、という具合だ。

追加したルール

そこでルールを一つ書いた。この実験全体で最も役に立った成果だ。

指摘は、コードを追加せよという命令ではない。

今ではレビューの結果を二つに分けている。最初のグループは、実際のユーザーが普通の日に遭遇し、最小限の修正で新しいものを追加せずに済む問題だ。これは直す。もう一方はそれ以外すべて。まれなケースや、新しいロック、再試行、テーブルが必要になるものだ。記録して報告する。人が必要だと判断しない限り、コードにはしない。

また、レビュアーには足りないものを探す前に、余計なものを探してもらう。誰も必要としなかったロック。呼び出し元が一つだけのフラグ。コードを言い換えただけのテスト。削除も今ではレビューの指摘に数える。

回数にも上限がある。コードは三ラウンド。テストは一ラウンド。その後の議論は人に渡す。おそらく最初からそこがふさわしい場所だった。

どれほどの価値があるか

価値をきれいな数字では示せない。示したいのだが。同じ仕事をレビューなしで公開した別の会社という対照群がない。

私にあるのはこの事実だ。五回に四回、あるモデルが完成したとした仕事に、別のモデルは変えるべき点を見つけた。その一部は雑音だ。ただ、一つのAIエージェントが自分の仕事をレビューしても、差し戻すことはほとんどない。自分の書いたことをすでに信じているからだ。別の意見は外から得るしかない。別の人たちが訓練し、最初のモデルが「すべて大丈夫」と判断した場にいなかった別のモデルから。

二つの頭は一つよりいい。どちらも人間でなくても、どうやらそうらしい。

Sno Stationはオープンソースで、相互レビューもその一部だ。sno.aiで公開している。

S

Written by Sno AI Team

Contributing writer at Sno.ai, sharing insights about AI, productivity, and knowledge management.

Related Articles

Comments

Comments coming soon. Configure Giscus at giscus.app

2,481回の相互レビュー:Claude CodeとCodexはお互いの間違いをどこまで見つけられたのか