「Cursorを使えます」は採用基準の入口に過ぎない。ハーネスエンジニアリングと生産性の言語化

複数の開発現場でAIコーディングツールの導入を経験し、採用面接に関わってきた立場から書く。

あなたが今、転職活動を考えているか、次の面接でCursor活用をどう語るか迷っているなら、この記事はその判断材料になる。「Cursorを使えます」という一言が採用側にどう響くか、そして本当に差がつく2つの軸は何か。採る側と採られる側、両方の視点から整理する。

「Cursorを使えます」はもう差別化にならない
採用側が実際に見ている2つの軸
行数・PR数は虚構の指標だ
ハーネスエンジニアリングが整っていない環境でAIは機能しない
AIに任せていい領域と自分が握る領域の境界線
技術力の定義を更新しないと市場価値が下がる
面接で語れる「Cursor活用の解像度」を上げる準備
採られる側の戦略まとめ：今日から動ける3つのアクション

「Cursorを使えます」はもう差別化にならない

カカクコムは2025年4月、全エンジニア約500名にCursorを一斉導入した。コロプラも同時期にエンジニア組織全体への展開を進めている。こうした大企業での全社導入が相次いだ結果、Cursorは一部の先進的なエンジニアだけが使うツールではなくなった。標準インフラに近い存在になりつつある。

「使える」と言えるエンジニアが増えると、採用側の質問は自然に変わる。「Cursorを使えますか？」という問いへの答えが「はい」だけで終わるエンジニアと、そこから先を語れるエンジニアの間に、今は明確な差がある。

採用側が聞きたいのは「ツールを知っているか」ではない。「そのツールを使って、チームの開発サイクルにどんな変化をもたらせるか」だ。

採用側が実際に見ている2つの軸

エンジニア採用の意思決定は、事業の数字で動く。1ポジションの採用には、スカウト費用・面接工数・入社後のオンボーディングコストを合算すると相当な投資になる。採る側はその投資に対して「このエンジニアがチームの開発サイクルをどれだけ短縮するか」を見ている。月額数千円のツールコストは、その判断のなかで誤差にすぎない。

現場で採用に関わってきた経験から言うと、Cursor活用について深掘りする面接官が本当に見ているのは、次の2つの軸だ。

軸1：ハーネスエンジニアリングの設計力

ハーネスエンジニアリングとは、AIエージェントが自律的に動ける環境を設計する概念だ。HashiCorpの共同創業者Mitchell Hashimotoが2026年2月に提唱し、OpenAIが同月に公式記事を公開したことで業界に広まった。

簡単に言うと「馬具」の比喩だ。どれだけ高性能なモデルでも、リンター・フォーマッター・テストランナーが整備されていなければ、AIは暴走するか止まるかのどちらかになる。Cursorが前提として動ける環境を設計できるエンジニアと、ただCursorを起動しているエンジニアの生産性は、同じモデルを使っていても大きく変わる。

採用側が問いたいのは、「.cursorrulesやAGENTS.mdを書いたことがあるか」「リンターとテストランナーをCursorのエージェントが呼び出せる状態に整えているか」という具体的な環境設計の経験だ。

軸2：生産性のビジネス指標への翻訳力

「PR数が増えました」「コードを速く書けるようになりました」という説明は、採用側に刺さらない。事業の数字で動いている採用担当者が知りたいのは、チームの開発サイクルへの直接的なインパクトだ。

「バグ報告を当日中に潰せるようになった」「チケット消化にかかる時間が3日から半日に変わった」「リリース頻度が月1回から週1回になった」。こうした語り方ができるエンジニアは、採る側の言語で話せている。

行数・PR数は虚構の指標だ

「AIを使ったら1日に2万行書けた」という表現を導入事例でよく見かける。しかし行数は生産性の指標にならない。

テストコードを丁寧に書けばコード量は増える。拡張性を残す設計をすれば、あえて冗長に書くことがある。逆に、密結合なコードは行数が少なくてもリファクタリングコストが高い。「1日に何行書いたか」という問いには、意味がない。

Cursor CEOのMichael Truellのデータによれば、2025年時点ではタブ補完ユーザーがエージェント利用者の2.5倍いたが、2026年2月時点ではエージェント利用者がタブ補完ユーザーの2倍になったという。つまり、エージェントとして本格的にAIに仕事をさせる使い方が主流になった。エージェントが動くほど、行数はただ膨らむ。その数字を生産性として語っても、採用側には伝わらない。

語るべきは「このバグ報告を昨日中に潰せた」「このチケットを3日から半日に短縮した」という、ビジネスへの直接インパクトだ。

ハーネスエンジニアリングが整っていない環境でAIは機能しない

「AIが生成したコードがダメだ」と言うエンジニアに、私はひとつだけ聞き返したいことがある。「リンターは通っているか。テストは自動で走っているか。AIがコードを修正してフィードバックを受け取れる環境になっているか」と。

多くの場合、問題はモデルの性能ではなく周辺環境にある。Findyが整理したデータでも、同じモデルを使っていても環境設計の差が成果を大きく左右することが示されている。

リンター・フォーマッター・テストランナーをCursorのエージェントが前提として呼び出せる状態に整えることが、まず先決だ。そのうえで、プロジェクトルール（.cursorrulesやAGENTS.md）を育てていく。エージェントが失敗したら、同じ失敗が起きないようにルールを一行追加する。この積み重ねがハーネスの実体だ。

Martin Fowlerはハーネスエンジニアリングを「feedforward制御（事前にガイドを書く）とfeedback制御（逸脱を検知して修正させる）の両輪でエージェントを信頼に足るものにする設計」と定義している。この発想でCursorを使っているエンジニアと、ただ質問を投げているエンジニアでは、面接での語れる量がまったく違う。

AIに任せていい領域と自分が握る領域の境界線

AIに任せていい領域と、自分で判断しなければならない領域は、はっきり分かれる。

AIに任せていい領域

テストコードの生成
リファクタリング
ドキュメント生成
繰り返しの実装パターン（CRUD・バリデーションロジックなど）

自分が握る領域

設計意図の定義（なぜこのアーキテクチャなのか）
例外処理のロジック（ユーザーがどの状況でどう使うかの仕様判断）
AIが誤動作したときのデバッグと原因の特定

この切り分けを実践に落とすと、モデルの使い分けにつながる。設計フェーズでは上位モデルで実装計画を固め、実装フェーズはコストの低いモデルに切り替える。Claude CodeとCursorを併用しているエンジニアは、この使い分けを自然にやっている。設計の意思決定だけ人間が行い、実装作業はエージェントに渡す。そのインターフェースを設計できるエンジニアが、採用側から見て価値のある人材だ。

技術力の定義を更新しないと市場価値が下がる

「AIを使いすぎると技術力が下がる」という懸念を耳にする。この懸念は否定しない。ただ、問題は「技術力」の定義が古いことにある。

包丁が普及したとき、人間の手の力が弱くなったと嘆くのは見当違いだ。道具の変化は、求められるスキルの中心を変える。コードを書く速さや量が技術力の指標だった時代は、AIエージェントが当たり前になった今、変わりつつある。

採用側が2026年に求めている技術力は、次の3つに集約される。

何を作るかを決める判断力 ── 仕様の優先順位付け・ユーザーの使い方の想定
例外処理の設計力 ── エッジケースを潰す思考、障害時の回復設計
AIが誤動作したときのデバッグ力 ── エージェントの出力を評価し、ハーネスを修正する能力

「自分でコードを書ける」より「チームとAIを組み合わせてプロダクトを速く前進させられる」人材が採用される。この定義の更新を先送りにしたままでいると、市場価値の評価が変わっていく。

面接で語れる「Cursor活用の解像度」を上げる準備

面接で使える自己PRのフォーマットは、次の3点セットだ。

「どんな課題に対して・どう環境を設計して・ビジネスにどう貢献したか」

これだけでいい。具体例を出すとすれば、次のようなものが語りやすい。

顧客バグ報告のトリアージからフィックスまでのフローをCursorのエージェントで自動化し、当日対応率が上がった
テストカバレッジを整備した結果、リリース後の障害件数が減り、ポストモーテムの開催頻度が落ちた
.cursorrulesにチームの設計ルールを書き起こし、新メンバーのコードレビュー指摘が減った

これらはすべて「ビジネスインパクト」で語れる形に変換できる。行数でもPR数でもない。

もし現在の環境でCursorを使っていないなら、それ自体は大きな問題ではない。採用側がより重視するのは、ツール環境の有無より「AIツールへの適応意欲と学習速度」だ。「使ったことはないが、リンターとテスト環境を整えるところから始める準備がある」と言えるエンジニアのほうが、「使っているが何も語れない」エンジニアより印象がいい。