エージェントハーネスを継続的に改善する

https://cursor.com/ja/blog/continually-improving-agent-harness

Cursor(Anysphere)のStefan Heule・Jediah Katzによる、エージェントハーネスを意欲的なソフトウェア製品として継続改善する方法論の解説

2026年4月30日公開、カテゴリは研究

全体姿勢

Cursorのエージェントハーネスはビジョン主導のソフトウェア製品として作る

仮説→実験→評価/実利用シグナル→改善のループ

オンライン/オフライン計測基盤が前提、変更で本当に良くなったかを見極める

新しいモデルへの早期アクセス時にこの方法論が一つにまとまり、何週間もかけてハーネスをそのモデルの強み・癖に合わせ込む

多くの場合、改善は飛躍ではなく小さな最適化の執拗な積み重ね

コンテキストウィンドウの進化

LLMとのやり取りの中核はコンテキストウィンドウ

構成はシステムプロンプト+ツール説明→会話状態→ユーザリクエスト

2024年後半の最初のコーディングエージェントでは、モデルが自分でコンテキストを選ぶのが下手で、多くのガードレールを入れていた

編集ごとにlintエラー・型エラーを提示

読み取り行数不足を補う

1ターンのツール呼び出し上限

コードベースのフォルダ構成・セマンティック一致スニペット・添付ファイル圧縮版などを静的コンテキストとして常時投入

現在の方針は逆: ガードレールを減らし、エージェント自身が走行中に取得する動的コンテキストを増やす

残している静的コンテキストはOS・git status・現在表示/最近表示ファイルなど最小限

過去記事Dynamic Context Discoveryで詳しく解説、その後他社コーディングエージェントにも採用された

現在の注力は動的コンテキスト獲得・外部連携の方法をさらに増やすこと

ハーネスの変更を評価する2つの方法

ベンチマーク: 自社CursorBench + 公開ベンチマーク、品質を素早く標準化された形で見る

オンライン実験: 2つ以上のハーネスバリアントを実運用A/Bテスト

表層メトリクス: レイテンシ・トークン効率・ツール呼び出し回数・キャッシュヒット率、傾向把握には有効だが「本当に役に立ったか」までは答えない

真の品質を測る2手法

Keep Rate: 提案コードがしばらく後にコードベースに残っているか、残っていなければユーザが手動修正/再依頼している証拠

LLMによる満足度推定: ユーザの応答をLLMに読ませて満足度判定、次の機能に進めば成功、スタックトレース貼り付けは失敗の信頼シグナル

オンラインテストは「期待外れ」を発見する役にも立つ、コンテキスト要約に高価なモデルを使う実験は品質改善がコスト増に見合わずボツに

劣化の追跡と修復

ハーネスもソフトウェア同様、モデル・機能が増えるほど取りうる状態が増えバグも増える

エージェントのツールは最もバグが出やすい領域、ツール呼び出しエラーはセッションに大ダメージ

エラーはコンテキストに残ってトークンを浪費し、ミスの蓄積で判断品質が落ちる「コンテキストの劣化」を起こす

エラー分類

InvalidArguments: モデルのミスやコンテキストの矛盾

UnexpectedEnvironment: 想定外の環境

ProviderError: GenerateImage・WebSearch等のベンダー側障害

UserAborted・Timeout

分類外の「未知のエラー」は常にハーネスのバグとして扱う

アラート

未知のエラー率がしきい値超過で発火

想定内エラーはベースラインを大きく超えたら発火する異常検知、ベースラインはツールごと・モデルごとに計算

週次自動化でログから新規・急増問題を発見、バックログチケットを起票/更新

多数の修正をクラウドエージェントで並列着手、Linearから直接トリガもできる

「ハーネス向けのソフトウェア工場」を志向、今年前半の集中スプリントで予期せぬツール呼び出しエラーを1桁削減

さまざまなモデル向けにハーネスをカスタマイズする

ハーネスの抽象化はモデル非依存、各モデルに合わせて深くカスタマイズ

例: OpenAI系はパッチベースのファイル編集で訓練済、Anthropic系は文字列置換ベース、慣れない方を使わせると推論トークンが増えミスも増える

プロバイダごと、さらにモデルバージョンごとにプロンプトを調整

モデルの癖の傾向: OpenAIは指示に文字どおり従う、Claudeはもう少し直感的でやや曖昧な指示にも寛容

新モデル早期アクセス時のワークフロー: 一番近い既存ハーネスを土台に、オフライン評価とチーム実利用で問題を洗い、安心してリリースできるまで反復

モデル固有癖の例: 「コンテキスト不安」と命名した現象、コンテキストウィンドウが埋まると「タスクが大きすぎる」と予防線を張って作業拒否し始める、プロンプト調整で抑制した

チャット途中でのモデル切り替えを支える

モデル切り替えでCursorはそのモデル向けのハーネスに自動切替、ただし会話履歴は別モデル生成のもので学習分布外

引き継ぎを伝えるカスタムinstructionsを追加、自分のツールセットにないツールを呼ばないよう誘導する役目

課題2: キャッシュはプロバイダ・モデルごとに別、切替直後はキャッシュミスで初手が遅く高くなる

緩和策として切替時の会話要約を試行、ただし複雑なタスクが進行中だと重要詳細が落ちる

推奨: 明確な理由が無ければ会話を通じて1つのモデルを使い続けるのがベスト

別解: サブエージェントを使う、新しいコンテキストウィンドウから始まるので切り替え問題を回避、最近では特定モデルでサブエージェントを実行する依頼機能を追加

ハーネスとソフトウェア開発の未来

AI支援ソフトウェアエンジニアリングの未来はマルチエージェント化

専門特化したエージェント・サブエージェントに分業: 計画担当・高速編集担当・デバッグ担当など

鍵はハーネス設計にある

どのエージェントに委譲するか、その強みを活かすタスク分割をどうするか、結果をどう一貫したワークフローに繋ぐか、を決める

オーケストレーション能力は単体エージェントではなくハーネスに宿る

ハーネス設計の重要性は今後さらに増す