誰もが「継続的学習」と言うとき、それはモデルの重みを更新することだけを意味するかのように話します。しかし、エージェントエコシステムには都合の悪い真実があります。現在本番環境で稼働しているエージェントの大部分は、クローズドなフロンティアモデルを活用しているのです。重みを所有していなければ、当然ファインチューニングもできません。ほとんどのエージェント開発者にとって、特に能力の最先端（Fable 5 や GPT 5.6 を考えてみてください）で作業する場合、重みレベルの継続的学習は選択肢に入りません。
だからといって、エージェントが学習できないわけではありません。エージェントシステムは、モデル、ハーネス、コンテキスト [0] の3つの層で改善することができ、最後の2つは完全にあなたのコントロール下にあります。ここに、巨大でありながらしばしば見落とされている機会が眠っています。ハーネスレベルの学習では、本番環境のトレースを活用して、エージェントのすべてのインスタンスを動かすコード、ツール、指示を体系的に改善できます。一方、コンテキストレベルの学習では、エージェント、ユーザー、組織レベルでパーソナライズできるため、製品はインタラクションのたびに向上していきます。これらすべてを実行すれば、毎日リリースできる複合的な改善を積み重ねることができるでしょう。
この記事の残りの部分では、過去1年間にわたって Replit Agent に継続的学習を適用してきた方法と、その過程で学んだすべての教訓を共有します。
Replit Agent の大規模な評価と改善
ほとんどの Replit Agent ユーザーは、アイデアから始めます。彼らはリポジトリやテストスイート、選択されたフレームワークなしで、自然言語で目標を説明し、エージェントがそれを機能するアプリに変えてくれることを期待します。結果は、ウェブサイト、スライドデッキ、モバイルアプリ、いくつかの接続されたアーティファクト、あるいはまったく別のものになる可能性があります。
Vibe coder は通常、差分やテスト出力をチェックしません。Replit Agent の成功は、見かけほど単純ではありません。ユーザーがクリックして回ったときにアプリが動作することです。
これにより、評価の役割が変わります。単一のスコアは特定のリリース判断に役立ちますが、週を追うごとに Replit Agent がユーザーにとって改善されているかどうかを教えてくれるわけではありません。その問いに答えるためには、評価を改善ループの一部にする必要があります。
NASA ルイス研究センター、エンジン研究棟の中央制御室、1968年 — 測定は、それがリリースするものを変えるときに重要です。
評価は今、より多くのことをしなければならない
エージェント評価は、かつては一方通行のプロセスのように見えていました。評価を実行し、スコアを出し、リリースの判断を下す。これはリリースが遅く、測定対象がめったに変わらない場合に機能します。しかし、モデル、プロンプト、ツール、プロダクトサーフェスがすべて急速に変化している場合、この方法は機能しなくなります。
古いループは、評価を限定的なものに感じさせました。しかし、Replit Agent は変化が速すぎるため、単一のスコアで全体の判断を担うことはできません。スコアは、あるタスクの一部分において2つの候補を比較できます。しかし、ユーザーが何を気にしているのか、本番環境のどこで問題が発生しているのか、次に何を改善すべきなのかを説明することはできません。
評価は、リリースチェックから改善ループへと移行しなければなりませんでした。
古い評価の役割は、人間によるリリース判断で終わります。新しい評価は、本番環境から学習し、改善されたエージェントをリリースする継続的なシステムに情報を提供します。
このシステムには、2つの測定の柱と1つの最適化ループがあります。オフラインベンチマークは、候補となる変更が、リリース前にシミュレートされたアプリ構築タスクを完了できるかどうかを教えてくれます。オンライン A/B テストと本番環境のトレースは、変更がリリースされた後に実際のユーザーがどのような影響を受けるかを示します。これらのシグナルは、その後、評価とリリース判断にフィードバックされます。
どの層も単独では十分ではありません。ベンチマークはリリース前にリグレッションをキャッチします。A/B テストは、本番環境の動作が変化したかどうかを示します。トレースクラスターは、集計メトリクスの背後にある障害を説明します。人間の判断は、改善ループを正しい製品およびエンジニアリングの成果に向け続けます。その形状は、安全工学におけるスイスチーズモデルに類似しています。各層には穴がありますが、それらが一緒になることで、どの単一の層よりも多くのものをキャッチできます。
既存のベンチマークはユーザーの手前で止まっている
SWE-bench [1] や Terminal-Bench [2] などのエージェントコーディングベンチマークは、制約された反復可能な環境でコードを評価します。これらのベンチマークは価値があり広く採用されていますが、vibe coder が気にするシグナルを見逃しています。
Replit Agent は、しばしばコードベースをゼロから作成します。ユーザーは固定されたルート、関数シグネチャ、セレクタ、テストを持ち込まず、製品リクエストを持ち込みます。エージェントは、スタック、スキーマ、ルート、コンポーネント、インタラクションフローを選択します。
これにより、機能的正当性のギャップが生まれます。エージェントはコーディングベンチマークの局所的な制約を満たしても、ユーザーが見るもの、つまり完成したアプリが要求されたことを実行しているかどうか、という点で失敗する可能性があります。Vibe coding において、評価のターゲットはアーティファクトそのものです。ロードされるか、コアワークフローが機能するか、結果がリクエストと一致するか。
ViBench の紹介
このスタイルのエンドツーエンド評価の必要性こそが、私たちが ViBench [3] を構築した理由です。これは、vibe coding のための公開ベンチマークであり、シンプルながら重要なシグナルを測定します。エージェントによって構築されたアプリケーションが仕様を満たしているかどうかです。
ViBench は、匿名化された Replit の本番トレースから抽出された平易な英語の製品要件ドキュメント（PRD）から始まります。そこから、エージェントは PRD を受け取り、従来のコーディングベンチマークで必要とされるような足場、ルート、参照に制約されることなく、スクラッチから実行可能なアプリを構築します。
しかし、ViBench を現実的にしているのと同じ柔軟性には、同様に柔軟な評価エージェント、つまり PRD に根ざしたエージェントが必要です。SWE-bench スタイルのベンチマークでは、プロジェクトはすでに存在するため、評価対象は固定されています。Vibe coding では、エージェントがスタック、ルート、コンポーネント、フローを選択します。評価は、それが発明したものは何でも探索しなければなりません。
そのために、各 ViBench タスクは PRD と、完成したアプリが満たさなければならない機能レベルのインタラクションとアサーションを記述する一連の自然言語テスト計画をペアにします。評価エージェントは Playwright を柔軟なバックボーンとして使用し、オフラインシミュレーション、ファイル操作、マルチテナンシーなどの複雑な機能を実行できるようにします。アプリのロケーターや構造を事前に知らないため、ノートブック環境で動作し、アプリがどのように構築されているかを段階的に発見しながら対話します。これは、Replit の自動セルフテストに関する初期の研究 [4] から引き出されたアプローチです。
Replit の規模で ViBench と、一般的に私たちの評価を実行するには、強力なインフラストラクチャサポートも必要です [5]。社内では、アプリの構築やエージェントの実行のために、分離された十分なリソースを持つサンドボックスを迅速に立ち上げることができる、同じ本番インフラストラクチャを活用しています。これらのサンドボックスを迅速にフォークできるため [6]、評価の多くを並行して実行し、評価間の汚染のリスクを回避できます。
アプリをゼロから構築するだけでなく、同じ ViBench の基盤、つまり自然言語のテスト計画によって評価される自然言語の PRD は、さまざまな vibe coding シナリオに適応します。既存のアプリ内でエージェントがどのように機能するかを評価するために、Replit の中間軌道ワークロードに近い形で、既存のコードベースでエージェントを起動し、機能 PRD から機能拡張をどれだけうまくリリースできるかを測定します。そのコードベースは、私たち自身のリファレンス実装から取得することも、エージェント自身が vibe coding したアプリから取得することもでき、私たちの出版物では Vibe-to-ref および Vibe-on-Vibe と呼んでいます。新しいプロダクトサーフェスをリリースするとき、同じバックボーンを使用して、Agent 4 の並列・マージ分解やサブエージェント分解で行ったように、新しいインタラクションパターンを評価するための新しい問題を迅速に導き出すことができます。
ViBench は行動評価器を固定したまま、入力と構築戦略を変化させます。
初期の ViBench の結果から、2つの有用な教訓が得られました。第一に、フロンティアのコーディングベンチマークスコアは、特にオープンウェイトモデルにおいて、完全なアプリ構築に常に転移するとは限らないこと。第二に、ほとんどのモデルは自身のコードを拡張する際に悪化することです。これは、エラーがしばしば複合的に発生するためです。これらの教訓を合わせることで、私たちはより良い登るべき丘を得ることができました。それは、テストに合格するコードを書くだけでなく、次のユーザーリクエストに耐えられるアプリを構築することです。
A/B テストは私たち自身を正直に保つ方法
私たちはオフライン評価を深く信頼していますが、それが唯一の判断基準ではありません。制御された環境では良好に見えても、実際のユーザーの行動を後退させてしまうエージェントのアップデートを何度も見てきたため、本番環境には独自の測定層が必要であることを私たちは知っています。
ユーザーはスクリプト化されておらず、常にオンラインで、オフラインベンチマークが完全に再現できる規模を超えて操作しています。彼らはプロジェクトを放棄し、考えを変え、驚くべき方法で機能を組み合わせ、私たちがテストすることを知らなかった障害モードを発見します。
そのため、私たちはエージェントに影響を与えるほとんどのアップデート（プロンプト、ツール、ハーネスの改訂、モデルの交換、より大規模な動作変更）を A/B テストします。複数の実験が同時に実行されることが多く、相互作用効果を隠さないように属性は明確に保たれます。A/B テストは、ユーザーの行動、感情、成功を明らかにします。ユーザーは使い続けたか、コストは予期せぬ動作をしたか、感情は動いたか、ユーザーは何かをリリースしたか。
A/B テストは、本番環境の動作に関する制御された読み取り値を提供しますが、集計メトリクスはそれ自体を説明しません。これは勝利か？根本的な動作の変化は何か？
A/B テストの課題は、結果の解釈が難しいことです。実行時間が増加した場合、エージェントはより多くの有用な作業を行ったのか、それともスタックしたのか？コストが下がった場合、効率が向上したのか、それともエージェントが価値のある何かを静かに実行しなくなったのか？感情が低下した場合、どのユースケースが後退したのか、どの障害モードが新しいのか、どのユーザーが諦めたのか？
Telescope: 何が壊れているのか
A/B テストは、本番環境の動作がいつ変化したかを教えてくれます。Telescope（トレース分析とクラスタリングのための私たちのシステム）は、その理由を説明するのに役立ちます。
本番規模では、どのエンジニアもすべてのトレースを読むことはできません。Telescope は、繰り返されるパターンを、エンジニアやエージェントが対処できる問題クラスターに整理します。障害の軌跡を要約し、それらを埋め込み、類似したケースをクラスタリングし、分布が変化するにつれて新しいセッションを分類します。目標は単に障害を数えることではなく、明白でありながら見えにくい障害を発見することです。
GIF
私たちが探すことを知らなかったものをクラスタリングする。
Telescope は、Clio [7] と同じボトムアップアプローチに触発された、短く証拠に基づいたファセットを使用します。トレースの場合、ユーザーメッセージ、表示可能なエージェントの応答、ツールコール、エラー、メタデータ、その他のコンテキストからセッションを再構築します。そこから、Telescope は何が問題だったかを要約し、それらの要約を埋め込み、密度ベースのクラスタリング [8] を使用して、創発的な問題グループを形成します。
ファセットは、特にクラスタリングだけでは不十分な場合に、調査を迅速化します。サポートレポートがポート障害などの広範な問題を指摘している場合、エンジニアとエージェントはまずコンパクトレイヤーを検索し、関連するファセットを調査し、その後、それを説明するために必要なログと可観測性コンテキストを使用して代表的なセッションをドリルダウンできます。
集約すると、同じ構造が散在する障害を製品の質問に変換します。どのワークフローが支配的か、どれが放棄されるか、何が繰り返し壊れるか、そして緩和策が意図したクラスターを縮小しているかどうか。
この基盤となるアーキテクチャの詳細については、Braintrust [9] の協力者による Topics に関する詳細な投稿を参照してください。
ループ: 証拠からエージェントの改善へ
測定が確立されれば、ボトルネックは移動します。ViBench、A/B テスト、Telescope は、何が失敗したか、どこで失敗したか、それがどのくらいの頻度で発生しているかを教えてくれます。私たちはその証拠を、もっともらしい修正に変えなければなりません。
この問題に対処するために、私たちは自己改善ループを採用しています。その動作原理はシンプルです。エージェントがソフトウェア構築に役立つのであれば、エージェント自体の改善にも役立つはずです。各パスは、本番ログ、トレースクラスター、最近の障害を読み取り、追求する価値のある仮説を見つけることから始まります。次に、候補を構築し、推論を添付したドラフト PR を開き、ViBench、A/B 結果、軌跡データ、最近のベースラインに対して結果を測定し、リリース、反復、または破棄のいずれかを推奨します。
最適化ループは問題を発見し、エージェントの変更を提案し、それらを評価し、リリース、反復、または破棄を決定します。
リリースが自動化されるわけではありません。ループは証拠と最初の実装を準備できます。エンジニアは依然として結果をレビューし、リリースの決定を担当します。
各実行は、試したことと何が起こったか（失敗を含む）を記録します。この記録は、時間の経過とともにループを改善します。将来の実行は、機能したものを再利用し、既知の行き止まりを回避し、一般化する変更を提案できます。
エンジニアリングの制御を放棄することなく、エージェントの反復が高速化されます。新しいモデル、プロダクトサーフェス、または信頼性目標が与えられると、ループはプロアクティブにプロンプトの編集、スキルの提案、ツールの修正、ハーネスの変更を見つけることができ、エンジニアはシステムをより大きな製品最適点に向け続けます。
具体的な例
最近のある実行は、小さくても成長している Telescope クラスターから始まりました。環境セットアップが、コールドスタートシナリオのロングテールにわたって静かに劣化していました。これらのセッションは集計メトリクスからは明らかではありませんでしたが、クラスターは調査する価値のあるパターンを示していました。
パターンが表面化した後、ループは影響を受けた軌跡を読み取り、パッチを提案し、リグレッションテストを追加し、ViBench に対して候補を実行して、ハッピーパスが後退していないことを確認しました。エンジニアは証拠をレビューし、変更を承認し、同日中に本番環境にプッシュしました。
パッチがリリースされた後、感情は回復し、影響を受けたユーザーはブロック解除されました。これが私たちが望む形です。実際の障害パターンを見つけ、影響を受けたユーザーに接続し、適切なレベルの修正を提案し、人間がリリースするかどうかを決定するのに十分な証拠を持ち帰るループです。
人間の判断が最も重要である領域
これらの多くは自律的に実行できます。障害のクラスタリング、仮説の提案、候補の構築、評価の実行、証拠の収集などです。人間は依然として方向性を設定し、ほとんどの出口をゲートします。これには以下が含まれます。
- 仮説の選択。 システムは何千もの障害を表面化できますが、どの質問がループの夜間予算に値するかを決定するのは人間です。すべてのクラスターが等しく重要であるとは限らず、すべてのリグレッションが正しい製品問題を指し示すとは限りません。
- 実装アーキテクチャ。 トレースはユーザーがワークフローを放棄していることを示すかもしれませんが、そのパスをスムーズにするか、エージェントの動作を変更するか、サーフェスを再設計するかの決定は、エンジニアリングと製品の判断です。
- 評価のキュレーション。 これは管理業務ではありません。エージェントが登る丘を形成します。評価が間違った行動に報いる場合、最適化ループは忠実に間違った方向に最適化します。
- リリース承認。 エージェントの変更をリリースすることは、単に数値を読むことではありません。リリース承認とは、証拠を読み、影響範囲を理解し、リスクが許容可能かどうかを判断し、ロールアウトを担当することを意味します。
このバランスが重要です。ループは、探索、測定、統合の多くを実行できます。エンジニアは依然として方向性を選択し、製品判断を下し、何をリリースするかを決定します。
ループを閉じる
評価はもはや、リリース前の単なるゲートではありません。何を修正し、何をテストし、何をリリースするかを決定するのに役立ちます。
仕事は、より良い数値を生み出すことではありません。ユーザーの失敗をより良いリリースに変え、より多くのアイデアが人々が公開して誇りに思えるアプリになるようにすることです。
私たちは、最も複雑なコーディングタスクに対する信頼性に焦点を当て、自律エージェントのフロンティアを押し広げ続けることに興奮しています。自律コーディングエージェントの開発に興味があれば、私は Replit AI チームで常に採用しています。 [email protected] までご連絡ください。
著者: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
参考文献
[1] SWE-bench: 言語モデルは現実世界の GitHub の問題を解決できるか？
[2] Terminal-Bench: コマンドラインインターフェースにおける困難で現実的なタスクでのエージェントのベンチマーク
[3] ViBench: Vibe Coding のベンチマーク
[4] REPL ベースの検証による Agent 3 の大規模セルフテストの実現
[5] エージェントコーディング評価におけるインフラストラクチャノイズの定量化
[6] Replit のスナップショットエンジン内部: AI エージェントを安全にする技術
[7] Clio: 現実世界の AI 使用に関するプライバシーを保護した洞察
