問題
私たちは小さなチームです。5人でAIプラットフォームを開発しています。同時に14のリポジトリを抱えていて、PRの数も多く、人手で十分にレビューする余裕がありません。
レビューには時間がかかりすぎていました。重要な部分が流し読みされることもありました。コードを出すスピードに対して、検証が追いついていなかったのです。
そこで、自分たちでコードレビューボットを作りました。最初は内部の課題を解決するためのサイドプロジェクトでしたが、今ではプロダクトになっています。Surmado Code Review。月額15ドルで100PRまで。
ここでは、実際にどうやって作ったのかを説明します。どこをvibe codingで作り、どこをそうしなかったのか。そして、AIパイプラインを試作する方におすすめしたいフレームワークです。
フェーズ1：vibe codingによる立ち上げ
最初のバージョンはサマリーエージェントでした。PRを開くと、変更内容の自然言語サマリーが出る。それだけです。すべてvibe codingで作りました。スピード重視で、Claudeに大部分を任せました。
その後、「バグも検出できるのか？」と考え始めました。
ここから面白くなってきます。
フェーズ2：フォワード・バックワードパス
ここが一番共有する価値のある部分だと思っています。コードレビューに限らず、どんなAIパイプラインにも使えるフレームワークです。
私たちは機械学習の「フォワード・バックワードパス」という概念を借りました。ただし、モデルの重みではなく、パイプライン全体をLLMのように扱って「訓練」しました。
仕組みはこうです。
フォワードパス。 管理された入力を用意します。私たちの場合は、意図的にバグを仕込んだPRです。それをパイプラインに通し、何を検出できて、何を見逃したかを記録します。
バックワードパス。 見逃しを分析します。プロンプトや構造、レビューのロジックを調整します。そして再度実行。今度は検出できたか。誤検出は増えていないか。
これを繰り返します。各サイクルは安くて速い。モデルを再訓練する必要はありません。コード、プロンプト、アーキテクチャを調整しながら、即座に結果を確認できます。
重要なポイントは、Claude Codeを「合成ユーザー」として使うことです。期待する入力と出力を与え、追加のテストケースを生成させ、結果をパイプラインに照らして評価する。それがテストハーネスになります。
このテストハーネスはvibe codingで簡単に作れます。呼び出せるAPIがあれば、半日で構築できます。デプロイ済みでも、コンテナでも、ローカル実行でもかまいません。検出したいバグの種類を定義し、テストケースを生成し、実行して改善する。
これがv1とv2でした。レビューの構造について10個の仮説があれば、議論する代わりに全部テストハーネスに通し、結果で判断しました。
フェーズ3：vibe codingの限界
実験を重ねる中で、本当の突破口が見えてきました。「標準（standards）によるグラウンディング」です。
レビューエージェントは、しっかり書かれた標準ドキュメントを参照できるようになった途端、劇的に改善しました。チームの実際のコーディング規約、慣習、設計判断を明文化したものです。
vibe codingをしている方は、すでにCLAUDE.mdや.cursorrulesをお持ちだと思います。それは「書く」ための契約です。エージェントに何を生成させるかを伝えます。ですが、多くのチームは「レビューする」ための契約を持っていません。人間にもエージェントにも、マージして良い基準を伝えるファイルがない。この非対称がドリフトを生みます。
私たちはリポジトリごとにSTANDARDS.mdを書きました。このファイルが存在すると、レビューエージェントは具体的な基準で判断できるようになりました。一般論ではなく、私たちのやり方です。
ただし、標準ドキュメント自体はvibe codingで作れませんでした。書式、パイプラインへの組み込み方、具体的な言い回しや構造。どれも慎重な人間の判断が必要でした。書いて、試して、エージェントの解釈を確認して、書き直す。このループは人間主導です。
プロダクト化の部分は、すべて手作業でした。
認証と決済。 意図的に組み立てました。顧客のお金を守ることを重視しています。
失敗時の処理と返金。 一つひとつ設計しました。何かが壊れたとき、何がどう起きるかを私たちが正確に把握している必要があります。
プライバシー。 譲れません。顧客のコードが私たちのパイプラインを通ります。生成任せではなく、意図的なアーキテクチャが必要です。
Scoutとの統合。 Scoutは私たちのAIリサーチアナリストです。Surmado Code ReviewとScoutの接続は、慎重に、テスト可能な形で、意図を持って作りました。
さらに、パイプライン内のモデルの使い分けにも時間をかけました。どのモデルに何を任せるか、コストと品質のバランスをどう取るか。こういう判断はvibe codingには向きません。マージン、顧客の期待値、各モデル階層の失敗パターンを理解している必要があります。
ここは機械に委ねませんでした。
フェーズ4：人間によるレビューと仕上げ
vibe codingでのプロトタイプと、エージェント型のテストループで堅い土台ができた後は、多くの部分が人間によるレビューでした。出力を読み、シニアエンジニアなら実際に指摘するだろう内容と比較し、標準ドキュメントを調整し、誤検出を潰す。
14の社内リポジトリでドッグフードしました。v7をリリースする頃には、私たちが気にかけている本物のコードに対する何千ものPRを通過していました。
結果として、マージまでの時間は3倍改善しました。PRが滞留しなくなりました。シニアエンジニアは、どのレビューでも同じ5つの指摘を繰り返さなくなりました。ジュニアは規約を推測しなくなりました。エージェントが書いたPRも、チームなら書かない形に漂流しなくなりました。
最終的には、開発チームに「外に出せ」と迫られてプロダクト化しました。「社内限定です」と友人の創業者に伝え続けるのに、みんな疲れていたのです。
フレームワーク（持っていってください）
AIパイプラインを作るなら、コードレビューでもそれ以外でも、このパターンです。
1. プロトタイプはvibe codingで作る。 まずは基本のフローを動かしましょう。アーキテクチャを考えすぎない。足場はAIに任せる。
2. エージェント型のテストハーネスを作る。 期待する入力と出力を定義し、Claude Codeを合成ユーザーとして使う。これがフォワード・バックワードパスです。呼び出せるAPIがあれば立ち上げは速く、10個のアイデアを、手動で1つ評価する時間でテストできます。
3. データに勝者を決めさせる。 どのアプローチが良いかを議論しない。ハーネスに全部通す。シグナルはすぐに出ます。
4. グラウンディングの仕組みを見つける。 私たちの場合は標準ドキュメントでした。あなたの場合はスタイルガイド、ルーブリック、ルールの集合、参照データセットかもしれません。パイプラインを一貫した意見を持つものにする、その核心です。ほぼ確実に人間の手仕事が必要です。
5. 顧客を守る部分は手作業で作る。 認証、決済、プライバシー、失敗時の処理。これらはvibe codingの領域ではありません。信頼を獲得するのはここです。意図を持って作りましょう。
正直な結論
vibe codingは、試作と実験のための素晴らしい手法です。エージェント型のテストループ、つまりフォワード・バックワードパスのパターンのおかげで、初期開発は以前なら考えられなかった速さで進みました。「コードレビューボットを作ったらどうなるか」から、実際のバグを検出する動くプロトタイプまで、数日でした。
ですが、プロダクトを信頼できるものにする部分は、十分な文脈を持った人間が、意図を持って判断する必要がありました。標準によるグラウンディング。モデル選定。決済フロー。プライバシー・アーキテクチャ。
プロトタイプと実験のレイヤーはvibe codingで。顧客を守る部分は手作業で。それが線引きです。正しい線だと思っています。
自分のリポジトリで試してみてください
Surmado Code Review。月額15ドルで100PRまで。5人チームで作りました。14リポジトリで実運用しています。
Surmado Code Reviewの仕組みを見る、または次のPRでレビューを開始する。
関連記事