人が常にエージェントをチェックしていると、他のタスクを並行して進めるのは難しい

Lauren氏がCursorに加わったばかりの頃、エージェントウィンドウのパフォーマンス最適化を支援する必要がありました。アプリはReactで開発されており、リリース期限が迫っていました。コードベースは彼女にとってもエージェントにとっても馴染みがありません。当初のやり方は、彼女が開発者ツールを開いてパフォーマンストレースを記録し、スクリーンショットやファイルをエージェントに渡して分析させるというものでした。エージェントは頻繁に原因を自信を持って指摘するものの、修正しても問題が解決しないことがよくありました。

このプロセスでは、コードを書くことは任せられても、アプリの動作を確認する作業は依然として人にのしかかっていました。エージェントが完了と言えば、人が開発バージョンを開いて問題を発見し、スクリーンショットやエラーメッセージをコピーして返す。この往復の速度は、人がどれだけチェックできるかに依存していました。他のエージェントを追加しても、皆この人の検収を待つことになります。

そこでLauren氏がまず補ったのは検証能力です。エージェントがアプリを起動し、インターフェースを操作し、CPUパフォーマンス記録やメモリスナップショットを収集し、必要に応じてシミュレータを実行できるようにしました。エージェントは、ユーザーが実際に使用するレイヤーに触れ、変更前後で何が起こったのかを確認する必要があり、自分が書いたコードだけを見て成功を判断するべきではありません。

これにより「問題が解決したかどうか」には答えられますが、優れたアーキテクチャ、保守性、ビジネス上の判断には他の制約が必要です。一度の実行が成功したとしても、それはその時に実際に検証された動作のみをカバーしています。

Lauren氏はこのプロセスを手描きの曲線で説明しました。講演の中で、目が覚めると約20件のPRが自動マージされていた経験があると述べています。PRはコードベースへのレビューとマージのために提出される一連の変更です。また、先月は約1,000件のPRをマージし、当月は12日までに既に800件近くに達したとも言及しました。これらの数字は彼女が当時処理した変更の頻度を示すものであり、各PRの内容と規模は異なるため、これに基づいて生産性の倍率を計算することはできません。

エージェントに機能マップを渡し、問題を見つけて検証できるようにする

エージェントがアプリを操作できるようにすると、すぐに別の問題が明らかになりました。ウィンドウは開けるものの、製品機能がどこにあるのか分からないのです。

ユーザーが「左のサイドバーがカクカクする」とか「右側のPRタブが機能しない」と言った場合、人間は通常、具体的な場所を連想できます。しかし、新しいエージェントにはこの認識がなく、コードを調べながらクリックを試すしかありません。フィードバックがスクリーンショットと疑問符だけであれば、問題がどの機能を指しているのかさえ特定できません。

Lauren氏は検証スキルに機能マップ（Feature Map）を追加しました。これは、ユーザーが認識する機能と実際の到達経路を結び付けます。どこから入るか、どのようなサブ機能があるか、どのように操作するか、どのようなショートカットがあるか、そしてプログラムでインターフェースを操作する際に使用できる要素属性などです。これにより、エージェントは曖昧なフィードバックを実行可能なナビゲーションプロセスに変換できます。マップは製品の使い方を説明する役割を担い、内部実装を理解する必要がある場合は、依然としてコードに戻る必要があります。

以下の質問群を使って、自分のマップが役立つかどうかを確認できます。

この表は機能マップを整理する際の出発点として使用でき、具体的なパスや要素は自身の製品に合わせて記入する必要があります。別の製品のナビゲーションドキュメントをコピーしても、エージェントが現在のアプリを理解できるようにはなりません。

Lauren氏は、検証スキルの作成とメンテナンスの方法をpstackにまとめました。メンテナンスは作成と同様に重要です。エントリーポイント、ショートカット、インタラクションが変更されると、古いマップはエージェントを間違った場所に導きます。検証ツールは「操作できること」を担当し、機能マップは「検証すべき場所に到達する方法を知っていること」を担当します。

繰り返し遭遇する問題を、再利用可能な作業方法にまとめる

pstackはもともと、Lauren氏が日々の業務で蓄積した一連のスキルです。スキルとは、エージェント向けのタスク説明や操作方法と理解でき、多くの場合Markdownで保存され、実行ツールと組み合わせて使用されます。その価値は具体的な経験に由来します。ある種の失敗が繰り返し発生したら、その正しい対処方法を書き留めるのです。

例えば、エージェントがある障害の原因を断言した時、彼女が実際のツール呼び出しを確認すると、関連するはずのコードをまったく読んでいないことが分かりました。このような問題に対して、「もっと真剣にやれ」と一言追加するだけでは、仕事のやり方を変えるのは困難です。彼女は、まず関連する実装を検索して読み、必要に応じて調査を分担し、その後に証拠に基づいて原因を説明することを明確に要求する必要がありました。

これは、初期の観察では最終的な回答だけを見てはいけないことも示しています。回答はもっともらしく聞こえても、実際の行動がそれを裏付けていない可能性があります。何を読み、何を実行し、何を検証したのかを見ることで、どのような能力を追加すべきかが分かります。

実際のタスクで評価し、スキルが役立つかどうかを確認する

スキルに書き込んだからといって、エージェントが安定して従うとは限りません。Lauren氏はeval（エージェントの行動に対する評価）を使用して、スキルの変更が期待した結果をもたらすかどうかを確認しました。彼女の方法は次の通りです。まずタスクと評価基準を明確にし、次に複数のエージェントを独立したディレクトリで実行させ、それらが正しく実行できるかを観察します。普段使っている複数のモデルでも評価を繰り返し、必要に応じて別のモデルを判定役として使用し、判断を相互に確認します。

また、ディレクトリ名などの手がかりで「評価に参加している」と直接分からないようにも努めています。エージェントが評価シナリオを認識すると、行動を変える可能性があると彼女は観察したからです。ここで注目するのは日常的な実行の信頼性であり、単に今回のデモが見栄えよく成功することではありません。

彼女はまた、コーディネーターエージェントにスキルを繰り返し修正させ、評価を実行させ、スコアを向上させる方法についても説明しました。検証スキル自体がこのような反復を経ています。評価で満点を取ることは、そのタスクセットと評価基準を満たしたことを意味し、すべての新しいタスクが正しく実行されることを保証するものではありません。評価が実務で起きる失敗を見つけられるかどうかは、依然として人間の継続的な観察と判断が必要です。

これらの基盤ツールもエージェントの助けを借りて構築できます。Lauren氏は、アプリを制御するコマンドラインツールの作成や検証スキルの改善にエージェントを参加させ、評価を通じて効果を確認しました。人が解決すべき問題と判断基準を選択し、エージェントが実装と反復に参加します。これにより、人手不足でこれまで構築できなかったエンジニアリングツールも、徐々に整備する機会が生まれます。

この改善は、小さな範囲から始められます。まず頻繁に失敗するタスクを選び、エージェントがどの手順を抜かしたかを記録し、具体的な方法を一つ追加し、その問題を引き起こす可能性のあるタスクで行動が変わったかどうかを確認します。この種の問題が安定したら、スキルの適用範囲を広げます。

繰り返し発生するエラーを自動チェックに変える

検証能力は「実行して目標に達したか」を解決しますが、コードベースは「機能が増えるにつれて、全体が悪化しないか」という問題も解決する必要があります。

Lauren氏は、これは大規模なエンジニアリングチームが直面する問題と非常に似ていると考えています。多くの人が同時にコードを提出する場合、全員が常にすべての原則を覚えていることに依存することはできません。フレームワーク、規約、権限、自動チェックが必要です。エージェントが変更を提出する速度が向上すると、小規模なチームでもこのような調整のプレッシャーに直面します。

したがって、成熟した制約がすでにある既存プロジェクトの方がエージェントに適している可能性があります。むしろリスクが高いのは、迅速に作り上げた新しいプロトタイプです。各タスクがその時々で最も都合の良い方法で解決されると、機能間の依存関係が混乱し、一箇所を修正すると別の箇所が壊れるという事態になります。

各機能がバラバラな方法で実装されることを避けるため、彼女はエージェントアプリ「Grokbot」をDuneと呼ばれる共通のエンジニアリング規約にリファクタリングしました。これは、コードの編成方法、許可されない依存関係を定義し、自動チェックを通じてこれらの制限を実行します。Lauren氏はこれを一連の原則と設計として説明しており、汎用フレームワークとしてオープンソース化するとは約束していません。

Duneの最も具体的な例は、UIレンダリング側に入るコードを制限することです。Electronはデスクトップアプリを構築する技術の一つで、UIの描画と他の作業は適切に分担される必要があります。Lauren氏によれば、エージェントウィンドウでは過去に分離が不十分だったため、重い計算や大量のI/Oが誤ってレンダリングパスに入り込み、UIの更新と時間を争っていました。

60 FPSは毎秒60フレームを表示することを意味し、各フレームの予算は約16.7ミリ秒で、講演では約16ミリ秒と近似されています。他の作業がこの時間を占有すると、UIはフレーム落ちやカクつきが発生しやすくなります。レビューの時に「カクつきを入れるな」と注意するだけでは、頻繁にマージされる変更に対応するのは困難です。

彼女はDuneで関連コードを明確に分離されたディレクトリに配置し、CIで依存関係グラフをチェックして境界違反のインポートを防ぎました。CIはコードがコミットされた後に自動的に実行される一連のチェックです。検出可能な制約に違反すると、チェックは失敗します。これにより、エラーは人がPRを読むまで待たなくても発見されます。

ここで、Bugbotはコードレビューを支援するツールです。いくつかの種類の制約がそれぞれ異なる役割を担っています：

Lauren氏はまた、コード内コメントを禁止するプロジェクト制約についても例を挙げました。彼女は、エージェントが一度限りの局所的な修正コメントを、まるで恒久的に有効なルールであるかのように書き残し、後で実行するエージェントがそれを全体ルールと誤解することを観察しました。彼女はまた、DuneでReactのuseEffect（コンポーネントと外部システムを同期させるためによく使われるインターフェース）を無効にしました。これは誤用されやすいと彼女が考えたためです。これらは彼女がそのコードベースに対して行った選択であり、すべてのReactプロジェクトや全チームのルールとして一般化することはできません。

Rustについて言及した際も、彼女が強調したのはコンパイラが人の代わりに一部の制約を強制できることでした。コンパイルチェックの価値は、それが認識できるエラーを事前に防ぐことにあります。ビジネスロジックが正しいか、UIがスムーズかは、それぞれ独自の検証問題があります。

チームにとってより有益なアクションは、同じ種類のレビューコメントが繰り返し発生する場合、それがlint（コードパターンを自動チェックするルール）、CIチェックにできるか、またはアーキテクチャ調整によってそのエラーパスを排除できるかを確認することです。これにより、人の判断が以降のすべてのコミットに蓄積されていきます。

正しい書き方を、最も簡単な書き方にする

ハードな制約が増えると、開発がどんどん面倒になるのではないでしょうか。Lauren氏のもう半分の設計は、通常の作業を進めるために、分かりやすく、手元ですぐ参照してまねできる実装方法を用意することです。

例えば、ある機能の関連コードを一つのディレクトリに集中させ、新機能も同じ編成方法に従います。エージェントがユーザーの初回利用ガイドを処理する際には、対応する機能ディレクトリを中心に作業でき、コードベースのあちこちで断片を探す必要がありません。フレームワーク内の機能、エントリーポイント、チャットカードなどの概念にも、定められた作成方法があります。

Duneはまた、長期間保存する必要がある各状態値について、書き込み元が一つに決まっていることを要求します。新しい製品機能は可能な限り独立したファイルを追加し、共有エントリーポイントに分岐を追加し続けることを避けます。どうしても例外が必要な場合は、範囲を狭くし、意図を明確にし、アーキテクチャ変更としてレビューを受けます。これらの規約により、状態を誰が変更するか、機能をどこで拡張するか、境界をどのように調整するかが明確になります。

これは、エージェントが既存のパターンを踏襲することを好む特性を利用しています。良いパターンは簡単に見つかり、それに従えば制約を満たせます。悪いパスは自動チェックで阻止されます。アーキテクチャはこれにより、正しい実装例と禁止される範囲を同時に提供し、エージェントは不必要な選択を減らし、既存の方法を正しく使用しやすくなります。

不必要な判断を減らすことは、タスクに対するモデル能力の要求を下げる可能性もあります。Lauren氏は、この環境を整えた後、最大規模のモデルほどの能力がないエージェントでもコード作業をうまくこなせると述べています。彼女は統一されたコスト削減率を示していませんが、これは検証可能な方向性を提供します。まずタスクパスとエンジニアリング境界を明確に説明し、次に自身のタスクでより強力なモデルが必要かどうかを評価します。

作業の分割も、同じ目的に役立ちます。Lauren氏は、変更を意味が通る複数のPRに分けるよう推奨しています。それぞれのPRが、小さな作業のかたまりが何をしているのかを説明できるようにするためです。こうすることで、Gitの履歴から文脈を理解しやすくなり、問題が起きたときの特定とロールバックも容易になります。

彼女はPRの行数に一律の上限を設けていません。彼女が説明する規模は、およそ50行のものから千行を超えるものまで様々で、主にコードの削除である場合もあります。つまり「小さいPR」の重点は、変更が独立して説明でき、確認でき、撤回できることにあるのであって、すべてのコミットを同じ行数に収めることではありません。

先にローカルで確実に動作させてから、クラウドとチームへ

Lauren氏は、ローカルで検証プロセスを構築することから始めるよう勧めています。その場に人がいれば、エージェントが正しい画面に入っているか、どのツールを呼び出したか、実際にチェックを完了したかを確認できるためです。この能力が信頼できるようになってからクラウドに移せば、複数の人々が再利用しやすくなります。

彼女が紹介したBennyは、フィードバックを処理するエージェントです。バグレポートを受け取ると、自身のクラウド上のコンピューターでCursorを起動し、同じ制御スキルを使って再現を試みます。具体的な報告の一つとして、古いコミットでは問題を再現できたものの、main、つまりメインブランチのコードではすでに修正されていることが判明した、というものがあります。

この報告の価値は非常に直接的です。チームは修正がすでに存在することを知り、次のステップは修正を含む新しいビルドをリリースすることになります。わざわざ担当者がエージェントと一時間やり取りして確認したり、修正済みのコードを再度修正したりする必要はありません。

クラウドでの再利用が拡大するのは、まさにこのような確立された能力です。検証ツール、機能マップ、環境設定は、もはやLauren氏だけの助けではなく、フィードバックを受け取る同僚も活用できます。逆に、個々のエージェントの操作がまだ信頼できない段階で、多数のクラウドインスタンスに直接拡張しても、空回りやエラーを拡大するだけです。

より多くの同僚に使ってもらうには、適切な入り口も必要です。Lauren氏によると、IDEやコマンドラインは開発者向きであり、プロダクトマネージャーやデザイナーには必ずしも使いやすいとは限りません。Grokbotは、より日常的なチャットに近いインターフェースを採用しており、彼らがタスクを依頼したり、進捗を確認したり、変更に参加したりしやすくなっています。使いやすい入り口は人々を呼び込み、その後の検証とエンジニアリング上の制約が変更の品質を支えます。

自動マージも、このプロセスの後半に位置づけられます。Lauren氏の実践は、自動マージに何が必要かを理解するのに役立ちますが、すべてのプロジェクトに当てはまる自動マージの条件が存在するわけではありません。チームは引き続き、自らのエンジニアリング標準に基づいて、どのような結果が次の操作を支えるのに十分かを確認する必要があります。

この改革の価値は、チーム全体が持続的に利益を得られるかどうか

Lauren氏はGrokbotをこのアーキテクチャにリファクタリングするために、600件を超えるPRを投入し、大量のトークンも消費しました。彼女自身、自分はAIラボで働いており、非常に潤沢なトークンリソースを持っていることを認めており、他のチームが同じ投入条件を前提にできないと述べています。

したがって、この方法のコストは、その後の利益と合わせて見る必要があります。初期段階では、制御ツールの構築、機能マップの整理、評価の反復、アーキテクチャの移行、チェックの補充が必要です。利益は、その後の反復的な検証を減らし、より多くの貢献者が同じ制約の下で作業を完了できるようにすることです。彼女が説明する利益には、プロダクトマネージャーやデザイナーがエージェントを利用して問題を修正したり、機能を提出したりでき、それをエンジニアリング担当者がレビューできるようになることも含まれます。

前述のフレームワーク、チェック、検証環境は、専門的な経験の一部を、他の同僚も利用できる条件に変えました。彼女は普遍的な投資回収期間を示してはいません。投資する価値があるかどうかの判断は、これらの設備が継続的に再利用できるかどうか、そして反復的な手作業による介入が実際に減少したかどうかを基準に行うべきでしょう。

もし実践を始めるなら、範囲は非常に小さく絞れます。繰り返し発生し、ローカルで観察できる障害を選び、エージェントに再現と検証を自律的に完了させます。そして、この経路の機能マップを整備し、よくある違反パターンを実行可能なチェックに変換します。同種のタスクで、もはや人手によるステップの補完が繰り返されなくなったら、その能力を他の機能やクラウドへと拡張できます。

エンジニアの仕事もそれに伴って変化します。目の前の問題を解決するだけでなく、その解決を支えた知識、手順、守るべき境界を、次の作業にも使える形で残すことが求められます。次に実行する者がこれらの条件を直接利用できれば、信頼できる自律的な作業を持続的に増やしていくことが可能になります。

原文情報

Lauren Tan, How Cursor Turned AI Agents Into Better Engineers, Maven, 2026年8月12日。動画の章構成は、検証と機能マップ（08:35）、スキル評価（20:04）、クラウド上のエージェント（26:34）、リファクタリングと制約（32:34）、Duneアーキテクチャ（41:00）、コスト（50:38）です。

元のプレゼンテーションを見る

会社情報：Cursorは2026年8月14日、SpaceXによる買収が正式に完了したことを発表し、チームは公式発表でSpaceXAIに参加することを明言しました。元のプレゼンテーションと製品内のCursorという名称は、当時の呼称に基づいてそのまま使用しています。買収発表 · チーム帰属の説明