毎日モデル比較してる人、仕事はあんまり終わってないと思う。
仕事が終わるかどうかは、モデル単体の知能じゃなくて、その周りにあるハーネスで決まる。Cursorが強いのはそこ。
この記事で言うハーネスは、モデルに渡すプロンプトの魔法じゃない。エージェントが「読んで、直して、コマンドを打って、失敗したら戻る」ための土台全部のこと。
公式ドキュメントも、Agent をこう分解している。
- Instructions（システムプロンプトと Rules）
- Tools（検索、編集、ターミナル、ブラウザなど）
- Model（そのタスクで使うモデル）
Cursor は対応モデルごとに、この1と2をチューニングする側に回っている。新しいモデルが出ても、こっちはソフトを書くことに集中できる、というのが建前で、現場でもだいたいそう感じる。
モデルは差し替えられる。ループは差し替えにくい
Claude Code も Codex も、中身のモデルは強い。同じ週に同じ系統のモデルを食ってることも多い。
差が出るのはこのあたり。
- コードベースをどう切って読ませるか
- 編集を diff として見せられるか
- 失敗したときに checkpoint で戻せるか
- ターミナルや MCP をどこで止めるか
- ルールを「お願い」で済ますか、「実行前に拒否」できるか
ここがハーネス。最強比較スレが噛み合わない理由でもある。モデルの勝敗を議論してる間に、リポジトリ側のループを固めた人のほうが成果物は残る。
Cursor のハーネスは「お願い」と「拒否」が分かれている
ここがいちばん大事。
Rules はソフト制約
.cursor/rules/*.mdc や AGENTS.md は、コンテキストに載る指示。コーディング規約、ディレクトリの約束、やってほしくないことを書く場所。
効く。ただし保証ではない。モデルは確率的なので、Rules を無視してファイルを触ることがある。公式も「Rules は steering であって、有害な操作の防止にはならない」と分けて書いてある。
例:
---
alwaysApply: false
globs: src/components/**/*.tsx
---
- named export を使う
- コンポーネントは 200 行超えたら分割する
- 生成物の `dist/` は触らない
alwaysApply、globs、description で「いつも / このファイルのとき / Agent が関連と判断したとき / @メンションしたとき」を切り替えられる。チームルールは Team / Enterprise ならダッシュボードからも配れる。
「書いておけば守られる」ではない。守らせたいなら次の層が要る。
Hooks と permissions はハード制約
実行前にプロセスが割り込んで、許可・拒否できる。モデルが「push します」と言っても、フックが deny なら走らない。
公式の Hooks は preToolUse / beforeShellExecution / beforeMCPExecution / beforeReadFile など、エージェントループの段に引っ掛けられる。
git を勝手に叩かれたくないときのイメージ:
{
"version": 1,
"hooks": {
"beforeShellExecution": [
{
"command": "./hooks/block-git.sh",
"matcher": "git push"
}
]
}
}
block-git.sh 側で permission: "deny" を返す。Rules に「push するな」と書くより、こっちのほうが話が早い。
同じ思想で、.cursorignore は Tab / Agent / メンションからのファイルアクセスを制限する。ただしターミナル経由の cat までは完全に止めない、という既知の穴はある。機密を置くなら allowlist からそういうコマンドを外す。
お願い（Rules）と拒否（Hooks / permissions）を分けて持っているのが、Cursor のハーネスの芯だと思う。片方しかないツールは、現場で必ずどちらかに寄せて壊れる。
現場で効いている残りの部品
比較記事で抜けがちなので、短く置く。
Checkpoints
Agent が大きめの変更に入る前にスナップショットを取る。Git とは別。変な方向に行ったらチャット上の checkpoint からファイルだけ戻せる。探索とリファクタの保険。
並列と Cloud Agent
ローカルで複数エージェント、クラウド側の background agent が PR を開く、という形が公式に載っている。モデル比較より「待ち時間を並列に逃す」ほうが、仕事のスループットは上がる。ただし並列で投げすぎるとレビュー地獄になる。最初は1本。リポジトリのルールが空だと平気で暴れる。
モデルを仕事ごとに替える
Composer、Claude、GPT、Gemini を同じループの上で差し替えられる。Claude Code は Claude のループに最適化されている。どっちが偉いではなく、ハーネスの形が違う。
CLI もある
「Cursor は IDE だから terminal 勢には負け」は、IDE 対 Claude Code CLI の話としては正しい。Cursor CLI 対 Claude Code CLI なら、Rules / MCP / agent は揃ってきている。まだ Skills や Stop フックの深さは Claude Code 側が厚い、という比較は 2026 年時点でもよく見る。
じゃあ Claude Code と Codex は弱いか
弱くない。ハーネスの置き場所が違う。
Claude Code はターミナル常駐。CLAUDE.md、Skills、Stop / SubagentStop の blocking hook、明示的な権限確認。シェルと複数リポジトリをまたぐ仕事は今でも強い。Codex も CLI 側のループが本体。
Cursor が強いのは、編集・検索・ターミナル・レビュー・差し替え可能なモデルを、同じ Agent ループに載せている点。ファイルを見てる最中に仕事が進む。逆に、tmux と neovim から出たくない人には回帰に見える。
「どっちが最強」の正解は、自分の仕事が IDE の中で完結するか、シェルの外に出て完結するか。
明日からやること（モデル比較の代わり）
- リポジトリに
AGENTS.mdか.cursor/rulesを1枚置く。空のまま Cloud Agent を投げない。 - 「してほしくないこと」（本番設定、生成物、
git push）は Rules ではなく Hook か permissions に落とす。 - 並列は1本から。レビューできない仕事を増やさない。
- モデル比較は、同じハーネスの上で同じタスクを1回ずつ流したときだけ意味がある。
最強を毎日決めても、リポジトリに残るハーネスは増えない。残るほうを先に固めた方が、仕事は終わる。