複数の開発現場で採用側と求職者側の両方に関わってきた立場から、この記事を書いている。
あなたが今、転職を考えているなら、あるいはCursorやGitHub Copilotを使ってはいるがそれがキャリアにどう効くかを言語化できていないなら、この記事は読む価値がある。
採用側が書類審査で何を見ているか。AIコーディングツールの使用が「加点要素」から「ボーダーライン」に変わったのはいつか。そして生き残るエンジニアが持つべき力とは何か。採る側と採られる側の両視点から、具体的な判断材料を渡す。
AIコーディングツールを使っていないエンジニアは、書類審査で落ちる
断言する。AIコーディングツールを業務で使っていないエンジニアを、書類審査の段階で落とす採用現場が既に存在する。
電卓が普及した時代に手書き計算を続ける経理担当者を採用する会社はない。それと同じ判断が、エンジニア採用の現場で起き始めている。
「使えると加点」という認識は、もう古い。
Findy社が2025年9月に220社を対象に行った調査では、「採用面接時にAI技術やツールの活用経験の有無が候補者の評価に影響する」と回答した企業が57.0%に達した。同年2月時点では18.1%だった数字が、半年で約3倍に跳ね上がっている。
さらに同調査では、「ChatGPTで情報収集する」や「GitHub Copilotを利用してコーディングする」といったアクションが、選考時のアピールではなく「できていて当たり前」として扱われている企業が一定数存在することも明らかになった。
レバテックが2025年初頭に公表した「IT人材白書2025」でも、生成AIの出現により採用担当者の約4割が「エンジニアに求めるスキルが変化した」と回答している。変化の内容として最も多く挙げられたのはコミュニケーションスキル（48.3%）だが、プロンプトスキル（38.5%）も上位に入る。対照的に、以前ほど重要でなくなったスキルの1位はプログラミングスキル（26.0%）だった。
採用基準の変化を「肌感」として持っている人は多い。ただ、それが数字として可視化されると、動くべき理由の重みが変わる。
採用側が書類審査で何を見ているか
採用側の視点から具体的に言うと、書類審査で見ているのは職務経歴書の中のAIツール活用記述の有無だ。
重要なのは「どのツールを使ったか」ではない。「何の課題に、どう使ったか」という文脈だ。「CursorとGitHub Copilotを使用」と書くだけでは加点にならない。「コーディング規約の適用をCursorで自動化し、レビュー工数を削減した」という文脈があって初めて評価の対象になる。
HR NOTEの記事でも指摘されている通り、採用の選考設問はプログラミング言語の経験を問うものから、AIエージェントツールの使用経験を問うものへとシフトしている。面接の設問が変わっているということは、評価軸が変わっているということだ。
採用コストの観点からも整理できる。AIを使いこなせないエンジニアを採用することは、チームの生産性に直接マイナスを与える事業判断になる。採用側にとって、これは慈善事業ではなく投資の話だ。生産性を下げる採用をする理由はない。
「コーディングを深める vs 上流設計にシフト」という二択は偽の問いだ
この二択がよく語られる。コーディングスキルをさらに深めるか、PMや上流設計にシフトするか。
答えはどちらでもない。正確に言えば、その二択の設定が間違っている。
AI時代において、答えはドメイン理解と上流設計力への移行しかあり得ない。「コーディングを深める」という選択肢は、AIが実装速度と品質の両面で人間を追い越しつつある領域で消耗戦を続けることを意味する。その戦い方は市場価値を積み上げない。
「何をつくるべきか」「誰にどんな価値を届けるか」に答えられないエンジニアは、AIに任せられる作業しかできないポジションに押し込まれる。
コーディング量そのものは、市場価値の根拠にならなくなりつつある。
採用基準の重心が「実装量」から「問いの設計力」に移った理由
エンジニアファクトリーの案件データによると、AI関連案件の全体構成比はQ1 2025（2025年1〜3月）の6.5%から、Q1 2026（2026年1〜3月）には13.5%へとわずか1年で約2倍に拡大した。さらに同データでは、コーディング中心の開発案件が11ポイント以上減少する一方、インフラ案件が13ポイント以上増加していることも示されている。
この数字が示すのは、「コードを書く量」で差がつく時代が終わりつつあるということだ。
同時に、AI案件の単価データも変化を裏付ける。AI案件の平均単価は非AI案件より月6〜8万円高い水準にあり、AIスキルと上流スキルを持つ人材が高単価側に吸い上げられる構造変化が起きている。
レバテックの調査では、採用担当者が重要視するスキルとしてコミュニケーションスキルが最上位に入り、プログラミングスキルは重要度が下がったスキルの上位に入った。企業がエンジニアに期待する重心が、実装量から問題定義力とコミュニケーションへとシフトしている。
会社のフェーズや規模に関わらず、「何を解くべきか」を定義できないエンジニアは、AIに任せられる作業しかできないポジションに留まり続ける。
「AIが書いたコードを読まないのはサボり」論への反論
この通説に正面から反対する。
コーディング規約とテストハーネスを適切に整備した上でAIコーディングツールを使うなら、生成コードを逐一読んで動作確認することは不要だ。むしろ非効率だ。
具体的な例を示す。Cursorには.cursorrulesファイルやルールセットによって、プロジェクト固有のコーディング規約を強制する機能がある。ここに命名規則、エラーハンドリングのパターン、テスト必須条件を定義しておくと、Cursorが生成するコードはその規約に従って出力される。
結果として何が起きるか。人間がレビューしていた時代よりも厳しいコーディング規約を、一貫して適用できるようになる。人間のレビューには疲労・見落とし・担当者ごとのばらつきがある。Cursorのルールセットにはない。
「人間は責任を持つのが仕事」という通説も、同様に綺麗事だ。レビューもテストもAIの方が性能が高い場面は既に存在する。責任という言葉を盾にして、AIの方が得意な作業を人間がやり続けることを正当化するのは、単なる非効率の温存だ。
Cursorとコーディング規約：AIが品質基準を上げる逆説
Cursorの.cursorrulesファイルに書くべき内容は、「どんなコードを書いてはいけないか」の定義だ。
例えば、「エラーは必ず専用の例外クラスでラップすること」「ビジネスロジックをコントローラーに書かないこと」「テストカバレッジ80%以下のプルリクエストは受け付けないこと」といった規約を記述する。これをCursorが読み込んだ状態でコードを生成すると、規約に反するコードが出力される確率が大幅に下がる。
人間がやるべきことは「規約とハーネスの設計」であり、「生成コードの逐一確認」ではない。
AIに任せる領域と人間が固める領域を整理すると、以下のようになる。
AIに任せる領域
- 実装（規約が定義された範囲内での）
- 定型テストの生成
- 定型レビュー（命名・フォーマット・既知のアンチパターン検出）
人間が固める領域
- 規約とハーネスの設計
- ドメインの定義（何をシステムで表現するかの判断）
- 要件の判断（何をつくるべきか・何はつくらないかの意思決定）
この切り分けを意識していないエンジニアは、AIツールを使っていても採用側に「使いこなせていない」と判断される。
生き残るエンジニアが持つ「問いの力」：採用される側の具体的な動き方
「何をつくるべきか・誰にどんな価値を届けるか」を問い続けられる力が、唯一の差別化になる。
これは抽象論ではない。採用の文脈で言うと、面接でこの問いに答えられるエンジニアと、答えられないエンジニアとでは、評価が明確に分かれる。
職務経歴書への反映で言えば、「AIツールを活用して効率化した」という書き方は弱い。「コーディング規約の適用をCursorで自動化することで、レビューフローを再設計し、チームの開発サイクルを短縮した」という書き方にする。何の課題に、どんな判断で使ったかを書く。
コーディングテストの設問も変化している。コードを書く速さではなく、設計の意図を説明する力を問う設問が増えている。「なぜこのアーキテクチャを選んだか」「どこをAIに任せてどこを自分で判断したか」を言語化できるかどうかが評価軸になる。
ドメイン知識をAIへの指示精度と結びつけて語れるエンジニアが、面接で突き抜ける。「この業界の商習慣を理解しているから、AIへのプロンプトの精度が上がる」という語り方ができると、採用側には刺さる。
転職活動でAIツール経験を正しく武器にする方法
職務経歴書にAIツール経験を書く際の型を示す。
書くべき構造
- どのツールを使ったか（Claude Code・Cursor・GitHub Copilot など）
- どのフローをAIに任せたか
- どこを人間が判断したか
- チームの生産性や品質にどう影響したか（できれば数字で）
面接でAI活用経験を問われたときに答えるべきなのは、ツール名よりも文脈と判断だ。「Cursorを使っています」で止まるエンジニアと、「コーディング規約をCursorに読み込ませて実装の自動化範囲を広げ、その分の時間をドメイン設計に使えるようにした」と語れるエンジニアとでは、採用側に届く情報量が全く違う。
AIコーディングによってチームの生産性がどう変わったかを数字で語れると、採用側の事業判断に直接刺さる。「レビュー工数が週○時間削減できた」「バグの検出率が上がった」といった数字は、採用をコスト投資として考える採用側が最も欲しい情報だ。
まとめ：AI時代のエンジニアキャリアを設計するための3つの判断軸
この記事で伝えたかったことを、判断軸として整理する。
判断軸1：AIコーディングツールはボーダーライン
使えることは前提であり、使い方の深さが差別化になる。書類審査でAIツール活用の記述がない職務経歴書は、採用側に「現状を把握できていない候補者」というシグナルを送る。
判断軸2：コーディングスキルの深化よりドメイン理解と上流設計力への投資
AI案件の構成比が1年で倍増し、コーディング中心案件が縮小している市場構造の中で、実装量に市場価値の根拠を置くことはリスクだ。「何を解くべきか」を定義できる力への投資が、市場価値に直結する。
判断軸3：AIに任せる領域と人間が固める領域の切り分けを言語化できること
この切り分けを語れるかどうかが、採用側への最大のアピールになる。Cursorのルールセットで規約を強制し、Claude Codeでテストを生成し、GitHub Copilotで実装を加速させる。その上で、何をつくるべきかとどんな規約にすべきかを人間が決める。この構造を語れるエンジニアが、次の採用市場で突き抜ける。
