Verifying Agentic Development at Scale (8 minute read)｜大規模なエージェント開発の検証（8 分読了） | AIニュース最前線

## Article ## Conversation Verifying Agentic Development at Scale Devin の仮想マシンにおけるエンドツーエンドのテスト機能構築から得た教訓。 3 ヶ月前、私はソフトウェアエンジニアリングの未来を築くために Cognition に入社しました。AI ソフトウェアエンジニアとして初めて登場して以来、Devin は大きく進化しましたが、その背後にあるチームが実際に毎日 Devin を使用している姿を目の当たりにし、驚嘆しています。 特筆すべきは、Devin がクラウド上でコンピュータを使用して作業を自律的に検証する方法です。テストモードで動作する Devins の軍団が常に存在し、複雑な Windsurf 機能のテストから始まり、チームは常にその能力を活用しています。本稿では、なぜ私たちはエンドツーエンドのクラウドエージェント検証にこれほど注力しているのか、またそれをどのように構築しようとしているのかについて共有します。 Cognition では最近、新たなマイルストーンを達成しました。初めて、より多くの Devin が非同期でトリガーされるようになりました。イベント、自動化、スケジュール、そして他の Devins によってです。最近のリリースに伴い、この加速はさらに進むと予想しています。 この非同期の世界への移行において、開発者がマージ可能な検証済みの結果にいつでもアクセスできることが極めて重要です。今年初めに、複雑なコード差分に対する人間の理解を拡張するコードレビューツールが導入されました。単にバグを指摘するだけでなく、各発見事項を修正して差分がクリーンになるまで繰り返すことで、問題を解決します。しかし、クリーンなレビューだけでは不十分な場合が多く、エンジニアは自分たちが行うのと同じように、変更内容をエンドツーエンドでテストした結果を確認したいと考えています。 Devin が、バグチャンネルのメッセージを確認する前にユーザーからの苦情を修正する PR を提出してくれたときは、とても素晴らしい気分になります。その魔法のような体験がさらに高まるのは、その修正が実際に機能しているという証明付きで PR が提出されたときです。そしてこの魔法は、まもなく必須となるかもしれません。能動的なエージェントによる PR が増加するにつれて、検証されていない変更はすぐに管理不能なものになってしまうからです。 メディアを再生できませんでした。 Devin のセッションにおいて、対話型ではなく非同期トリガーで開始されるものが初めて、対話型のものよりも多くなりました。 Devin が登場して以来、クラウド上の仮想マシン上でその作業を実演できる能力を持ってきました。約 6 ヶ月前に、 機能を開発しました。これは実務的には、Devin のハネス（枠組み）にスクリーンショットの取得、マウスの移動、クリック、ドラッグ、タイピング、キー押下、スクロール、待機、ズーム、録画の開始/停止などのツールを追加したことを意味します。コンピュータ操作はすでに存在する技術ですが、私たちは最先端研究所から登場した最新のモデル群が、これらのツールの活用において本当に上達し始めたと感じています。 コンピューター操作機能により、Devin にはデスクトップゲームの構築やプレイ、ブラウザを使用して Amazon で商品を購入するといった、いくつかの楽しい新機能が解放されました。しかし、私たちが実際に発見した真の突破点は、Devin が自身の作業を検証できる能力です。Devin はアプリを起動し、その中をクリックして確認し、変更が実際に機能していることを検証します。これはエンジニアが行うのと同じ方法です。すべての処理はクラウド上で実行され、並列にスケールアウト可能です。エンジニアたちが 10 から 20 の Devin を並列で実行し、それぞれが独自の開発サーバーを持ちながら変更作業を進めている姿を見たとき、この事実を強く実感しました。これは単一のラップトップでは絶対にできないことです。自動化されたクラウドテストにより、コードをローカルで実行して検証する必要がなくなったため、膨大な時間を節約できるようになりました。 正直に言って、ここに至るまでにはスムーズな道ではありませんでした。その過程で多くの失敗モードに直面し、それぞれがこのシステムをより信頼性の高いものにするために何が必要かを教えてくれました。 初期バージョンでは、テスト中に Devin が本来の軌道から外れることが非常に一般的でした。その原因は様々です：製品の無関係な部分を過剰にテストしたり、機能に到達する前にセットアップで迷ったり、あるいは PR が実際に意図して変更すべき中核的な挙動を見落としたりすることなどが起こりました。 これに対処するため、Devin がテストモードに入ると、まず何をテストするかという明確な目標を詳細に記したテストプランを作成するようにしています。このプランは仮説ではなく、ソースコードに基づいたものである必要があります。コードに基づく根拠がない場合、モデルは存在しないアプリ内のパスを進んでしまう傾向があることがわかりました。さらに、テストプランにより Devin が成功裏にテストできる変更の複雑さが大幅に向上します。私たちの最も野心的なリクエストの中には、動作が到達可能になる前に複数のサービスが実行され、特定の管理設定が構成され、適切なフラグが有効化される必要がある機能も含まれていました。事前にコードを読み込むことで、Devin はテストの途中で何か見落としていることに気づくのではなく、環境を正しくセットアップする可能性が高まります。テストプランは事前のアライメントの一形態として機能し、実際のテスト中に Devin が逸脱する可能性を低減します。 Devin がプランを進める過程で、タイムラインに独自の注釈を追加します。これにはセットアップのメモ、各名前付きテストの開始、および「合格」「不合格」「未テスト」としてマークされたアサーションなどが含まれます。Devin は行動を実行する直前に期待される動作を注釈として記述することで、発見内容について嘘をつく頻度が低減することがわかりました。これはテスト駆動開発と同様の原理で、事前に期待値にコミットすることで、予期しない結果を合格と合理化するのがはるかに難しくなります。 テストフローのいくつかの部分は、ほぼすべての実行で繰り返されます。ログインはその典型例です：コンピュータ操作を通じてログインフォームを処理するには、電子メールの入力、SSO の完了、リダイレクトのクリック、そしてページ読み込みごとのスクリーンショットごとの待機が必要になります。これは時間とトークンの両面でコストがかかる可能性があります。これらのアクションに対する信頼性とコストを改善するために、Devin はこの作業を、当社のリポジトリ内のテストスキルとして存在する決定論的スクリプトに抽出しました。これにより、Devin はスクリプトを実行して数秒で認証済みブラウザセッションを取得し、テストの核心部分に直接進むことができます。これらのスクリプトの決定論的な性質は、フラッキネス（不安定さ）を劇的に減少させるのに役立ちました。私たちはまた、Devin 自身がこのループを閉じるように更新しました。Devin が設定ステップを苦労して見つけた場合、その知識をリポジトリ内のテストスキルとして保存することを提案し、ワンクリックの PR として修正をユーザーに提案します。 メディアは再生できませんでした。 ログインスキルにより、Devin は数秒で認証済みセッションを取得するため、実行時間は変更を検証するクリック/スクリーンショット/アサートループに集中されます。 また、テストフェーズを異なるモデルにルーティングすることを実験しています。テストはコード作成とは異なる強みを必要とするため、例えばスクリーンショットの読み取り、UI 状態の追跡、次のブラウザアクションの決定などです。そのため、コード編集用に通常選択されるモデルよりも、特定のモデルの方がこのタスクに適している場合があります。 Devin は現在、2 つの方法でテストモードに入ります。変更をテストするよう明示的に依頼する場合か、または Devin が PR を作成した後に、該当する場合はその変更をテストする提案を行う場合です。そこから、テストプランを作成し、作業を開始します。 Devin のテスト機能を使い始めたばかりの頃は、しばしばあなたの支援が必要です。例えば、ローカルでアプリを実行する際にシークレットが必要となるケースが典型的な例です。このプロセスをよりスムーズにするため、Devin は不足している情報を取得したり、他の必要な情報を入力したりすることが可能です。より困難なケースでは、あなたが Devin のコンピュータを引き継ぎ、OTP コードなどの入力を行うことができます。好消息は、Devin がリポジトリのセットアップを終えた後、その設定を YAML ブループリントという形式で保存し、今後のすべてのセッションがそこから起動できるスナップショットを生成できるようになることです。 Devin がテストを終了した際、単にアプリが動作したかどうかを伝えるだけではありません。生のスクリーンレコーディングは有用ですが、それだけでは不十分だと私たちは考えました。あなたは自分が何を見ているのかを理解し、なぜ Devin が各アクションを実行したのか、そしてテストのどの部分が成功または失敗したのかを知る必要があります。 迅速なレビューのために、Devin は実行中の重要な瞬間からラベル付きスクリーンショットを含むテストレポートを返します。これにより、Devin が何をテストしたか、その過程でアプリがどのように見えたかを素早く確認できます。 より詳細なレビューをご希望の場合は、Devin は章付きの豊富なプレイヤー UI を備えたテスト動画も生成します。これにより、テストセクション間をジャンプしたり、実行全体をスクラブして再生したり、時系列リストビューで通過または失敗したアサーションを検査したりできます。後処理では、アクション間の無効な時間が圧縮され、アクション周辺の瞬間は通常速度で再生されます。これにより、長時間の実行が実際に視聴可能な録画に凝縮されます。これらのアーティファクトは当社の Web インターフェースで利用可能であり、Devin が Slack から起動された場合は Slack にも配布されます。 メディアを再生できませんでした。 Devin はアプリを実行し、フローを試し、章と合格/不合格アサーションを含む録画を返します。 コンピュータ操作には依然として明確な限界があります。一例としてタイミングが挙げられます。もし Devin がトースト通知のテストを行っている場合、早すぎたり遅すぎたりして撮影されたスクリーンショットではトースト自体を見逃す可能性があり、モデルは期待される動作が実際に発生したかどうかについて混乱する可能性があります。 もう一つの失敗モードは不正行為です。自己判断に任せた場合、モデルは時として UI を通じてクリックする代わりに、ブラウザ内で JavaScript を実行して状態をプログラム的にトリガーすることに過度に依存することがあります。これは機能テストには役立ちますが、ユーザーは多くの場合、Devin が実際のユーザーと同じようにアプリを操作している様子を確認したいと考えています。 私たちは、評価の改善、ハネス内のより厳格なガードレール、およびコンピュータ操作能力が向上する新しい世代のモデルを通じて、これらの課題に取り組んでいます。 過去数ヶ月間、Devin で承認されたテスト実行の1日あたりの回数は2倍以上に増加しました。この成長は単純な事実を反映しています：非同期エージェントが有用なのは、開発者がその結果を信頼できる場合に限られます。多くの場合、コードだけでは信頼を得ることはできません。多くの変更において、アプリが実際に実行され、重要なフローが検証され、結果が容易に検査可能な形で記録されたことを知りたいものです。 それがDevinの自律型テストが提供しようとしているものです。Devinはテストを計画し、アプリを操作し、発生した内容を記録・注釈付けし、最終的にレビュー可能な成果物を返します。まだ改善すべき点は多くありますが、私たちはこれが未来の正しい形だと考えています：単に非同期で作業を完了するだけでなく、証拠を持って戻ってくるエージェントです。 Devinが自身の作業を検証することで節約される時間の多さに常に驚かされており、多くの顧客がDevinの自動テスト機能を十分に活用していないと感じています。実験をサポートするため、現在テストモード中は通常の使用料金の1/5で課金しています。 私たちの取り組みは以下のリンクでお試しください： または もしこのような問題に取り組むことが楽しいと思われる場合は、ido [at] までご連絡ください。

大規模なエージェント開発の検証（8 分読了）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト