実際の開発でCursorとCodexを使い分けている理由

はじめに

「Cursor vs Codex、どちらが上か」という議論は、スレッドを読む限り終わりません。自分の現場では、どちらか一方に寄せ切れない状態が続いています。比較表より先に、作業の種類で開くアプリを固定した方が迷いが減ったので、その使い分けを記録します。

前提：同じ「AI付きエディタ」に見えて役割が違う

両方ともコードを書く支援はします。違いは、コンテキストの取り方と変更の粒度に出やすいです。

• Cursor — リポジトリ全体・複数ファイル・差分前提の編集に強い
• Codex（CLI / エージェント系） — ターミナルに近い操作、コマンド実行、単発の調査・修正に向く

「どちらが賢いか」より、どちらが今の作業フローに乗るかで見ると整理しやすいです。

自分の使い分けルール

Cursor を開くとき

• 機能追加で3ファイル以上触る見込みがある
• UIコンポーネントと型・テストを同時に直す
• 設計の相談をしながら、その場でパッチまで欲しい

このときは、プロジェクトルール（lint、ディレクトリ構成）をエディタ側に読ませた方が、手戻りが少ないです。

Codex を開くとき

• ログやエラーメッセージから原因特定→1ファイル修正
• マイグレーションやスクリプトの一回きりの生成
• CIの失敗をターミナル出力ごと渡して直したい

エージェントに「実行まで任せる」領域は、CursorよりCLI側の方が自然なことが多いです。

どちらも開かないとき

仕様が曖昧なまま実装に入る段階。AIに書かせる前に、自分で箇条書きの受け入れ条件を書く。ここを飛ばすと、どちらのツールでも綺麗な的外れが返ってきます。

失敗から学んだこと

両方使える環境だと、同じバグを二重に直すことがありました。Cursorで直したつもりが、Codex側の別ブランチに古い提案が残る——履歴の分散は、ツール過多と同型の問題です。今は「そのタスクのオーナーは一方」と決め、完了したらもう一方は閉じる運用にしています。

おわりに：読者への提案

スペック勝負より、次の1タスクを紙に書き、ファイル数と実行の有無で選ぶ——それで十分です。自分は「複数ファイル改修はCursor、ターミナル1本勝負はCodex」と割り切り、月に一度だけルールを見直しています。固定は保守ではなく、速度のための選択です。