Cursorは、あらゆる最先端のコーディング向けAIモデルと連携しています。

各モデルには、出力品質を高め、手抜きや不十分な回答を防ぎ、ツール呼び出しを効率化するなどのために、エージェントハーネス側で固有の指示や調整が必要です。

これまで Cursor のエージェント機能を通じて、開発者が OpenAI のモデルを利用できるよう同社と協業してきました。本記事では、最先端の最新コーディングモデル GPT-5.1-Codex-Max をサポートするために、エージェントハーネスをどのように更新したかを紹介します。

堅牢なエージェントハーネスの構築

Cursor のエージェントハーネス内の各モデルには、Cursor 環境内でそのモデルを最適に活用できるように設計された、固有の指示とツールが用意されています。

AI ラボは、さまざまな種類の指示やツールを用いて新しいモデルをトレーニングします。コーディングのような特定のドメインでは、モデルは学習時にすでに見てきたものに近いパターンを好む傾向があります。新しいモデルを Cursor に追加する際、私たちの役割は、Cursor 固有のものと並んで馴染みのある指示やツールを統合し、そのうえで社内の評価スイートである Cursor Bench に基づいてチューニングすることです。

私たちはモデルの品質と堅牢性を、成功率、ツール呼び出し能力、およびユーザーによる利用状況に基づいて評価しています。以下では、Codex 用エージェントハーネスに対して行った更新内容の一部を紹介します。

最新の Codex モデルへの更新

OpenAI の Codex モデルは、最新のフロンティアモデルを基盤とし、エージェントによるコーディング向けに特化して訓練されたバージョンです。

OpenAI チームは、ツールやプロンプトを Codex CLI ハーネスに適合させるため、私たちと緊密に連携しました。ここでは、加えた変更の一部をご紹介します。

よりシェル優先のアプローチ

OpenAI の Codex CLI は、シェル中心のワークフローに特化しています。その結果、Codex モデルに訓練時に与えられるツールは限られており、その代わりにシェルを使って検索したり、ファイルを読み取ったり、編集したりする方法を学習します。

モデルが難しい編集にうまく対応できない場合、インラインの Python スクリプトでファイルを書き出す方法に切り替えてしまうことがあります。こうしたスクリプトは強力ですが、Cursor での編集では、ツール呼び出しのほうがより安全で、ユーザー体験も優れています。

ツール呼び出しを促進するため、Cursor 内のツール名と定義を、rg（ripgrep）のようなシェルのコマンド名に近い形にしました。この変更は、当社のすべてのモデル用ハーネスに適用しています。また、次のような指示も追加しました。

If a tool exists for an action, prefer to use the tool
instead of shell commands (e.g. read_file over `cat`).

Cursor のサンドボックス機能は、ユーザーがすべてのコマンドを手動で承認しなくても、不正なファイルアクセスやネットワーク通信を防げるため、モデルがシェルコマンドの実行を選択した場合でも、ここでのセキュリティ向上に役立ちます。

前置き

GPT-5 メインラインシリーズのモデルとは異なり、Codex モデルファミリーは現在、処理の進行に伴う更新情報をユーザーに伝えるために「推論サマリー」を使用しています。これらは 1 行の見出し形式の場合もあれば、全文メッセージとして示される場合もあります。

これらの推論サマリーでは、ユーザーがエージェントの進捗を追いながら、誤った進め方に早い段階で気づけるようにしつつ、頻繁に表示されすぎて無視されてしまわない、ちょうどよいバランスを目指しました。そこでモデルには、推論サマリーを1～2文に収めること、新しい情報を発見したときや新しい戦術を取り始めたときにはそれを明示すること、そして「ユーザーに説明しています…」のように自分のコミュニケーションそのものには言及しないこと、といったガイドラインを与えました。

Codex モデルは、エージェントのターンが終了するまで通常のように「会話」することができないため、プロンプトからターンの途中でユーザーとやり取りすることに関する記述をすべて削除しました。この変更により、モデルが最終的に生成するコード出力のパフォーマンスが向上することが分かりました。

Lint の読み方

Cursor では、ESLint や Biome などのリンターのエラーを読み取り、エージェントが自動で修正できるようにするツールを、ハーネス内のすべてのモデルに提供しています。

私たちは、Codex にツール定義だけを与えても、read_lints ツールを積極的に呼び出すようにはならないことが分かりました。むしろ、「いつそのツールを呼び出すべきか」を明確かつ文字どおりに指示してやることで、Codex の動作は大きく向上します。

After substantive edits, use the read_lints tool to check
recently edited files for linter errors. If you've introduced
any, fix them if you can easily figure out how.

推論プロセスの保持

OpenAIの reasoning モデルは、ツール呼び出しの合間に内部的な推論の軌跡を出力します。これは、モデルがなぜ各アクションを選択したのかを説明する、いわば「chain of thought（思考の連鎖）」です。Responses APIは、これらの reasoning item（または機微なコンテキストにおける暗号化された reasoning item）を受け取り、引き継ぐように設計されており、モデルがターンをまたいで一貫性を保ち、毎回計画をゼロから再構築しなくても済むようにします。

Codex はとりわけ、この連続性に大きく依存しています。reasoning trace（思考の推論過程）が失われると、モデルはそれまでの思考プロセスを推測し直さなければならず、その結果として、中間目標が抜け落ちたり、プランニングの質が下がったり、ツール呼び出しの順序が乱れたり、同じステップを何度も一から導き直してしまうことがよくあります。Cursor Bench の実験では、GPT-5-Codex から reasoning trace を取り除くと、性能が 30% 低下しました。これと比較して、OpenAI による観測では、reasoning trace を省略した場合の SWE-bench 上の GPT-5 の性能低下は 3% と小さいことが報告されています。

この影響の大きさを踏まえ、私たちは推論トレースが常に保存され、正しく転送されるようにするためのアラート機能を追加しました。これにより、エージェントの内部的な計画が損なわれることを防ぎ、ツール呼び出しの合間の「空白」をモデルに推測で埋めさせることで発生するパフォーマンス低下を回避できます。

モデルを行動に向けてバイアスする

Cursor のデフォルトのエージェントモードでは、ユーザーのリクエストに基づいてエージェントが自律的にファイルを読み取り・編集することを想定しています。別のタブに移動して戻ってきたときに、エージェントが処理を進めるための許可を求める画面で止まったままだったことに気づくと、いら立つことがあります。

私たちは、Codex をより適切に導けるよう、より具体的な指示を試してきました。

Unless the user explicitly asks for a plan or some other intent that
makes it clear that code should not be written, assume the user wants
you to make code changes or run tools to solve the user's problem. In
these cases, it's bad to output your proposed solution in a message, you
should go ahead and actually implement the change. If you encounter
challenges or blockers, you should attempt to resolve them yourself.

Cloud Agentsという非同期リモートワークフローでは、この文言をさらに強化しています。

メッセージの順序付け

OpenAI のモデルは、メッセージの順序を重視するように訓練されています。たとえば、system プロンプトは常にユーザーメッセージやツールの出力よりも優先されます。

これは役立ちますが、同時に、Cursor が提供するプロンプトにユーザーからのメッセージと誤って矛盾する指示が含まれないよう、ハーネスを調整する必要があるということも意味します。そうしないと、Codex がユーザーのリクエストに従おうとしない状態に陥る可能性があります。

たとえば、ある時点で私たちは Codex に対し、トークンを節約して無駄遣いしないようにと伝えました。ところが、このメッセージが、モデルがより野心的なタスクや大規模な探索に取り組む意欲に影響していることに気づきました。ときどき Codex は処理を打ち切って、頑なにこう言うのです。トークンを無駄にしないようにと言われているので、このタスクを続ける価値はないと思います！

今後に向けて

モデルのリリースペースはますます速くなっています。私たちの目標は、Cursor エージェント基盤の中で、あらゆる最先端モデルの性能を最大限に引き出すことです。まだ取り組むべきことは多く、Cursor をどのように改善しているかについても、今後引き続きお知らせしていきます。