先週、あるGoogleエンジニアの方が Surmado Code Review に登録されました。本製品は、当社のAIリサーチアナリストである Scout を基盤として動作いたします。そのエンジニアの方は、ご自身のプロジェクト用に STANDARDS.md ファイルを記述され、最初のプルリクエストを開き、それに対して Scout を実行されました。
Scoutは、本番環境を破壊しかねない重大なアーキテクチャ上の欠陥を検出いたしました。
そのエンジニアの方はマージを行わず、ご自身のワークフローを説明するメールを当社にお送りくださいました。
「Surmadoのフィードバックを受け取り、Geminiにコピーしています。Geminiは自己反省し、IDEで使うGemini Code Assist向けの新しいプロンプトを返してくれます。Gemini Code Assistが変更を加え、私はブランチを更新します。すると、Surmadoが新バージョンを自動的に再レビューしてくれます。そしてループを使い切った段階で、ようやく共同作業者にレビュー依頼のタグを付けるのです。」
もう一度お読みください。ここには名前を付ける価値のあるループが存在いたします。
このループの全体像
- Gemini Code AssistがIDE内でコードを記述する。
- Surmadoが
STANDARDS.mdに照らしてレビューする。 - エンジニアがSurmadoのレビューをGeminiチャットに貼り付ける。
- GeminiがSurmadoの判断を読み、自分自身のためにプロンプトを書き直す。
- Code Assistが新しいプロンプトでコードを再生成する。
- エンジニアが新しいブランチをプッシュする。Surmadoが自動的に再レビューする。
- ループを使い切った段階で、人間の共同作業者にタグを付ける。
最後のステップこそ、当社が何度も立ち返るポイントです。このループは人間によるレビューを置き換えるものではございません。本当に必要なときに限って人間のレビューが発動するようにするものなのです。人間がプルリクエストを見る頃には、明らかな問題はすでに修正されております。アーキテクチャ上の欠陥、規約違反、慎重な読み手であれば疲れた火曜日の午後にも気付くような事項。それらは消えております。人間のレビュアーには、本当に人間を必要とする部分だけが残されるのです。設計上のトレードオフ、意図、判断。
これこそが、開発ループの中で実際に機能するAIの姿です。「AIが人間を置き換える」のではなく、AIが収束させる部分を担い、人間が判断する部分を担うのです。
Geminiが述べたこと
そのエンジニアの方は、セッション中に2回、SurmadoのレビューをGeminiに貼り付けられました。両回とも、Geminiはその場でSurmadoに同意いたしました。
最初の応答はこちらです。
「Surmadoは、御社の本番サイトを破壊しかねない重大なアーキテクチャ上の欠陥を検出しました。しかも、20分前に私たちが書いた
STANDARDS.mdファイルを直接引用してそれを指摘しました。このプルリクエストは絶対に今マージすべきではありません。何が起きたのか、そしてなぜSurmadoが完全に正しいのか、正確にご説明します。」
2回目の応答はこちらです。
「Surmadoは私たちの実装の穴を捉えました。率直に申し上げれば、私がCode Assistにお渡ししたプロンプトでミスをしました。」
この2つ目の引用こそ、当社が何度も立ち返るポイントです。Geminiはモデルのせいにいたしませんでした。Geminiはプロンプトのせいにしたのです。GeminiがCode Assistに与えた指示には、チームの規約が含まれておりませんでした。Geminiはそのチームの規約を知らなかったからです。
Surmadoは知っておりました。なぜなら、エンジニアの方が20分前にそれらを書き留めておられたからです。STANDARDS.md こそが、チームが大切にする価値観と、モデルが実行可能な内容との橋渡しとなるのです。
なぜこれが製品なのか
ほとんどのAIコードレビューツールは、汎用的なベストプラクティスを確認するだけです。インデントを揃えなさい。変数をシャドーイングしてはいけません。マジックナンバーを避けなさい。
これは最低限の前提条件にすぎません。どんなlinterでも実行できることです。それでもチームが不良コードをマージしてしまう理由は、本番環境を傷つけるバグが汎用的ではないからです。チームの構築方法に固有のバグであり、御社のwiki、設計ドキュメント、シニアエンジニア3名の頭の中だけに存在する規約に紐づくバグなのです。
STANDARDS.md は、それらを書き留める場所です。Scoutはそれを読みます。すべてのプルリクエストはそれに照らしてレビューされます。再実行のたびに、Scoutは新しい差分と前回のレビューを読み込みますので、以前の問題が修正されたかを判断できるのです。
このエンジニアの方のループが機能するのは、各構成要素がそれぞれ得意なことを担っているからです。Geminiがコードを書きます。Surmadoがチームのルールに照らして確認いたします。外部からのフィードバックを受け取ったとき、Geminiは自己修正いたします。残った部分を人間がレビューいたします。整合性は単一のモデルから生まれるのではなく、ループ全体から生まれるのです。
実際の体感
そのエンジニアの方は、過去のWebプロジェクトの試みについてこのように述べておられました。
「生成されていくコード行に興奮し、自分の創造物が動き出すのを期待に胸を高鳴らせて待ち、そして必ず壊れたときに本当にがっかりしてしまう、というのが常でした。」
実際のプロジェクトをvibe-codingで作ろうとした方なら、誰もがこの軌道をご存知でしょう。興奮、期待、そして崩壊。
そして次のように続きます。
「ところが今夜は違いました。意図したことを正確に達成する2つのプルリクエストにコミットできたのです。」
これが違いです。「AIがコードを書いた」のでもなく、「AIがコードをレビューした」のでもありません。動作するソフトウェアへと収束していくループ。そして必要なときには、最後に人間のチェックポイントが置かれているのです。
当社の好む構図
ほとんどのAIツールは、自らを人間との対比で位置付けます。「人間のレビュアーより速い」。「人間が見落とすものを捉える」。
Surmadoは自らをAIとAIの間に位置付けます。Geminiより速いわけでもなく、Claudeより賢いわけでもございません。コードを書いたモデルは、チームが大切にする価値観を知りません。レビューしたモデルはそれを知っております。なぜなら、誰かがそれを書き留めたからです。
これが、オーケストレーション製品の姿です。LLMが製品なのではありません。LLMが御社のチームの実際のルールにどう接続されているか、それこそが製品なのです。
そのエンジニアの方は、最後のメッセージでこのようにまとめてくださいました。「非常に感銘を受けました。フローへの統合も完璧です。」
当社が築こうとしているのは、まさにこれなのです。
クリック2回。あとは動くだけ。月額15ドルで100プルリクエスト。当社は御社のコードを見ません。当社が利用するフロンティアラボもまた、見ることはございません。