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

各モデルごとに、出力品質を高め、省略的・怠慢な挙動を防ぎ、ツール呼び出しを効率化するなどのために、当社のエージェントハーネスに固有の指示や調整が必要になります。

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

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

Cursor のエージェントハーネスに含まれる各モデルには、そのモデルを Cursor 環境内で最適化するための専用の指示セットとツールが用意されています。

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

私たちは、成功率、ツール呼び出し能力、そしてユーザー全体での利用状況に基づいて、モデルの品質と堅牢性を評価しています。ここでは、Codex 向けにエージェントハーネスへ加えた更新内容の一部を紹介します。

#最新の Codex モデルへのアップデート

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

OpenAI チームは、Codex CLI ハーネスに合わせてツールやプロンプトを最適化するため、私たちと緊密に連携してきました。ここでは、私たちが行った変更点の一部を紹介します。

#さらにシェル寄りのアプローチ

OpenAI の Codex CLI は、シェル指向のワークフローに特化しています。その結果、Codex モデルは学習時に限られたツールセットしか与えられず、その代わりにシェルを使って検索したり、ファイルを読んだり、編集したりすることを学習します。

モデルが難しい編集に苦戦している場合、インラインの Python スクリプトでファイルを書き出す方法にフォールバックすることがあります。これらのスクリプトは強力ですが、編集に関しては、Cursor ではツールの呼び出しの方がより安全であり、ユーザー体験も優れています。

ツールの呼び出しを促すために、Cursor 内のツールの名前と定義を、rg（ripgrep）のようなシェルの同等ツールに近いものにしました。この変更は、私たちのハーネス内のすべてのモデルに対して行いました。また、次のような指示も追加しました。

アクションに対してツールが存在する場合は、シェルコマンドの代わりにツールを使用することを推奨します（例：`cat`の代わりに read_file）。

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

#前置き（Preambles）

メインラインの GPT-5 系列モデルとは異なり、Codex モデルファミリーは、処理中の進捗や更新内容をユーザーに伝えるために「reasoning summary（推論サマリー）」を使用します。これは 1 行の見出しの場合もあれば、フルメッセージの場合もあります。

これらの推論サマリーについては、ユーザーがエージェントの進捗を追いかけて誤った方向性を早期に特定できる一方で、通知が多すぎて無視されてしまわないよう、そのバランスを重視しました。モデルには、推論サマリーを 1〜2 文に収めること、新しい情報を発見したときや新しい戦術を取り始めたときにはそれを明示すること、「I’m explaining to the user…（今ユーザーに説明しています…）」のように、自分のコミュニケーションについてコメントしないこと、といったガイドラインを与えています。

Codex モデルはエージェントのターンの終了まで通常の「会話」ができないため、プロンプトからはターンの途中でユーザーに話しかけることに関連する文言をすべて削除しました。この変更により、モデルが最終的に生成するコード出力の品質が向上することがわかりました。

#Lint の読み取り

Cursor では、ハーネス内のすべてのモデルから linter エラー（例: ESLint、Biome）を読み取り、エージェントが自動で修正できるようにするツールを利用できます。

しかし、Codex が read_lints ツールを進んで呼び出すようにするには、ツール定義を与えるだけでは不十分であることがわかりました。代わりに、「いつこのツールを呼び出すべきか」を明確かつ文字どおりに指示してやることで、Codex の挙動が大きく向上します。

実質的な編集を行った後は、read_lintsツールを使用して
最近編集したファイルのリンターエラーを確認してください。
エラーを導入した場合は、修正方法が容易に分かれば修正してください。

#推論トレースの保持

OpenAI の推論モデルは、ツール呼び出しの合間に内部の推論トレースを出力します。これは、モデルがなぜ各アクションを選んだのかを説明する、いわゆる「chain of thought（思考の連鎖）」に相当します。Responses API は、これらの推論アイテム（あるいは機微なコンテキストでは暗号化された推論アイテム）を取得して受け渡せるように設計されており、モデルが毎ターン計画をゼロから再構築するのではなく、ターンをまたいで一貫性を維持できるようにします。

Codex はこの一貫性への依存度が特に高いモデルです。推論トレースが失われると、モデルは直前の思考プロセスを推測し直す必要があり、その結果としてサブゴールの消失、計画品質の劣化、ツール呼び出し順序の乱れ、あるいは以前のステップの繰り返し導出が頻発します。Cursor Bench の実験では、GPT-5-Codex から推論トレースを取り除くと、パフォーマンスが 30% 低下しました。比較として、OpenAI は、推論トレースを省いた場合、SWE-bench における GPT-5 の性能劣化が 3% 程度と報告しています。

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

#モデルが積極的に行動するようバイアスをかける

Cursor のデフォルトのエージェントモードでは、ユーザーのリクエストに応じてエージェントが自律的にファイルを読み取り・編集してくれることが望ましいでしょう。別のタブに切り替えて戻ってみたら、エージェントが先に進んでよいかあなたの許可を求めて待ち続けていただけだったと分かるのは、少しストレスに感じます。

Codex をより適切に誘導できるよう、より具体的な指示の出し方を試しています。

ユーザーが明示的に計画を求めたり、コードを書くべきでないことが明確な意図を示したりしない限り、ユーザーはコード変更やツールの実行によって問題を解決することを望んでいると想定してください。このような場合、提案する解決策をメッセージで出力するのではなく、実際に変更を実装してください。課題や障害に遭遇した場合は、自分で解決を試みてください。

Cloud Agents（Cursor の非同期リモートワークフロー）では、この仕様をさらに厳密なものにしています。

#メッセージの順序

OpenAI のモデルは、メッセージの順序を尊重し、優先度を付けるように学習されています。たとえば、system プロンプトは常に user メッセージや tool の結果より優先されます。

これは便利ですが、その一方で、Cursor が提供するプロンプトに、user メッセージと誤って矛盾してしまう可能性のある指示が含まれないよう、ハーネスを調整する必要があることも意味します。そうしないと、Codex が user のリクエストに従おうとしなくなる状態に陥ることがあります。

たとえば、ある時点で Codex に対して「トークンを節約し、無駄遣いしないよう注意すべきだ」と指示したことがありました。しかし、このメッセージが、よりチャレンジングなタスクや大規模な探索を行おうとするモデルの意欲に悪影響を与えていることに気づきました。ときどき Codex は作業を止めて、頑なにこう言うようになりました。トークンを無駄にしないようにと言われているので、このタスクを続ける価値はないと思います！

#今後に向けて

モデルのリリース速度はさらに加速しています。私たちの目標は、あらゆる最先端モデルをCursorのエージェント基盤で最大限に活用することです。まだ取り組むべきことは多くあり、今後もCursorに対して行っている改善内容を継続的にお伝えしていきます。