生成AI時代、エンジニア転職の評価基準はどう変わったか

「面接で聞かれたのは、コードの書き方より“なぜその設計にしたか”でした」——Cursorを使いこなす20代のエンジニアが、選考を終えてそう振り返るのを、この半年でよく聞くようになりました。

IT・Web業界を中心に800名以上の転職支援に携わる中で、求人票の文言や面接での質問内容が、ここ1〜2年ではっきり変わってきた実感があります。今回は、生成AIの普及がエンジニア採用の評価基準をどう変えたのか、求人票と面接フィードバックという現場の一次情報をもとに、転職活動でどう備えればよいかまでお伝えします。

目次

1. 生成AI時代のエンジニア転職で評価基準はどう変わったか
2. 求人票の記載内容はここまで変わった
3. コーディング速度から設計判断力・要件定義力へ
4. 面接で実際に聞かれる質問はこう変わった
5. 選考形式そのものも変わり始めている
6. AI生成コードのレビュー力、検証責任が問われる場面
7. プログラミングスキルは本当に不要になるのか、調査データの正しい読み方
8. 企業ごとのスタンス差、AI許容型・AI排除型・ハイブリッド型
9. ジュニア層・未経験エンジニアへの影響
10. 面接・職務経歴書でAI活用力をどう説明すべきか
11. まとめ、評価されるのは「書く力」より「判断する力」

生成AI時代のエンジニア転職で評価基準はどう変わったか

レバテックが企業の採用担当者1,000名とIT人材3,000名を対象に行った「レバテックIT人材白書2025」（2024年11月調査）では、生成AIの普及によって「エンジニアに求めるスキルが変化した」と回答した企業が約4割にのぼりました（出典：レバテック「生成AIとITエンジニアの働き方に関する実態調査」）。同じ調査ではChatGPTの利用率が85.7%と、IT人材の間でAIツールがすでに前提として使われている実態も示されています。

調査から時間が経っている点は割り引く必要がありますが、私が日々受け取る求人票や、選考後に企業からいただくフィードバックの内容とは、この数字の方向性は今も一致しています。以前であれば「〇〇言語の実務経験3年以上」「大規模システムの開発経験」といった条件だけが並んでいた求人票に、この1年ほどで見慣れない一文が増えました。「生成AIツールを活用した開発経験がある方」「AIが出力したコードを検証し、品質を担保できる方」——採用要件に、AIとの向き合い方そのものが明記されるようになったのです。

変化の本質を一言でまとめると、企業が見ている評価軸が「コードを書く速さ」から「コードを設計し、検証する力」へ移ってきたということだと私は捉えています。コードそのものはAIが高速に書いてくれる時代に、人間のエンジニアに求められる役割が変わるのは、ある意味で自然な流れです。

求人票の記載内容はここまで変わった

実際に企業から届く求人票の文言を、私がこの2年ほど担当してきた案件の中から傾向としてまとめると、次のような変化が見えてきます。

以前担当したある自社開発企業の求人は、募集を出してから3か月ほど経ったタイミングで、採用要件の一文が丸ごと差し替わったことがありました。「コーディングテストで高得点を取れる方」という記載が、「AIツールを使った開発プロセスを説明できる方」に変わっていたのです。採用担当者に理由を尋ねると、「コーディングテストの点数と、入社後の活躍度が以前ほど比例しなくなってきた」という率直な答えが返ってきました。点数だけを見て採用した候補者が、実務では設計判断で苦戦する場面が増えたのだそうです。

コーディング速度から設計判断力・要件定義力へ

評価軸の変化を整理すると、次のような対比構造になります。

この表を見て「結局は総合力の話では」と思う方もいるかもしれませんが、私が現場で感じている違いはもう少し具体的です。AIがコードを書けるようになったことで、コーディング速度という指標が持っていた「ふるいにかける力」が弱まったのです。以前は制限時間内にどれだけ書けるかで候補者間の差がはっきり出ましたが、今はAIツールを使えば誰でも一定水準のコードを短時間で出力できてしまいます。差がつく場所が、書く工程の手前（要件をどう咀嚼するか）と後ろ（出てきたコードをどう判断するか）に移動した、というのが私の見立てです。

HR NOTEの採用担当者向け解説（2025年11月公開）でも、評価の軸が単一の技術スキルから、課題解決力、AIオーケストレーション能力（複数のAIを使いこなして成果に結びつける力）、倫理・セキュリティを踏まえた設計力へ広がっていくと解説されています（出典：HR NOTE「AI時代のエンジニア採用」）。こちらは調査データではなく定性的な解説ですが、私が現場で受け取るフィードバックの方向性とは重なっています。

コミュニケーション力やビジネス視点の重要性が上がっているのも、この流れと表裏一体です。AIに指示を出す前提として「何を作るべきか」を人間側が言語化しなければならず、その言語化の精度がそのままアウトプットの質に直結するようになりました。エンジニア職でありながら、面接で「非エンジニアの関係者にどう説明したか」を掘り下げて聞かれる場面が増えているのも、この延長線上にあります。

面接で実際に聞かれる質問はこう変わった

以前担当したEさん（20代後半・自社開発企業でバックエンドエンジニア、実務4年、Cursorを日常的に使用)は、複数のWeb系企業を受ける中で、以前とは違う角度の質問が増えたと話していました。ある企業の技術面接で聞かれたのは、「このAPI設計、AIの提案をそのまま使いましたか、それとも変更しましたか」という質問です。

Eさんは正直に「特に意識せず、提案されたものをほぼそのまま使いました」と答えました。すると次に「なぜ最初の提案ではなく、修正した方を採用したのですか」と重ねて聞かれ、答えに詰まってしまいます。実際には修正を加えていたものの、その判断理由を言語化する準備がなかったため、その場でうまく説明できませんでした。結果は見送りで、企業からのフィードバックには「実装力はあるが、AIの提案を検討したプロセスが見えなかった」とありました。

Eさんはこの経験を踏まえ、次の面接までに使ったプロンプトと、AIの提案をどう修正したかを簡単なメモにまとめる習慣をつけました。次に受けた企業では、「命名規則が社内の既存コードと合わなかったので手動で直した」「例外処理の粒度が細かすぎたので、業務要件に合わせて2パターンに簡略化した」というように、判断の根拠を添えて説明できるようになり、内定につながっています。「AIに何を任せ、何を自分で判断したか」を言葉にできるかどうかが、面接の合否を分ける場面を何度も見てきました。

選考形式そのものも変わり始めている

質問の中身だけでなく、選考の形式も見直しが進んでいます。カミナシの開発者ブログ（2026年9月7日）は、AI時代のエンジニア選考を6つの方式に整理しています。持ち帰り課題とオンラインコーディングテストはAI以降は信頼性が下がり、ペアプロ面接、AI利用を前提にしたライブコーディング、システムデザイン面接は有効という評価です（出典：カミナシ開発者ブログ「AI時代のエンジニア選考・面接のパターン」）。

理由は「提出物から本人の寄与が読めなくなった」ことです。同社は持ち帰り課題とコーディングテストをやめ、設計力を見るライブ形式の面接へ移る方針で、AI利用の可否は候補者に明示するとしています。これは一社の考え方なので業界全体の傾向とまでは言えませんが、先ほどのGさんのように「完成度は高いが本人が書いたか分からない」という評価が出る背景を、選考形式の側から説明してくれる整理だと私は読んでいます。

候補者側の立ち回りとして押さえたいのは、AI利用の可否を事前に確認し、使うなら判断を声に出すことです。ライブ形式の面接で黙ってAIに任せると、面接官には何も伝わりません。「ここは提案をそのまま採用します」「この部分は要件に合わないので直します」と口にしながら進めれば、書類や成果物では見えない判断の跡がそのまま評価材料になります。

AI生成コードのレビュー力、検証責任が問われる場面

もう一つ、印象に残っているのがFさん（30代前半・SES企業でフロントエンドエンジニア、実務6年）のケースです。書類選考は順調に通過しましたが、二次面接で渡された課題は、あらかじめAIが生成したコードの断片を見せられ、「このコードにバグがあれば指摘してください」という検証型の設問でした。Fさん自身も普段からAIツールを使っていましたが、生成されたコードを自分でレビューする習慣までは持っていなかったそうです。

コード自体は一見動きそうに見えるものでしたが、非同期処理のエラーハンドリングが抜けており、特定の条件でしかバグが再現しない、実務では見落としがちな箇所に不具合が仕込まれていました。Fさんは表面的な構文の誤りは指摘できたものの、この非同期処理の抜けまでは見つけられませんでした。

ポイント： AIが書くコードは「文法的に正しく、動きそうに見える」ことが多いからこそ、レビューする側には従来以上の注意力が求められます。企業側が採用面接にこうした検証型の課題を組み込むのは、AI任せにせず不具合を見抜ける人材かどうかを確かめたいという意図の表れです。

このフィードバックを受けたFさんは、その後の選考対策として、普段からAIに書かせたコードを提出する前に必ず自分でレビューし、「なぜこの実装で問題ないと判断したか」をコメントとして残す練習を始めました。次に受けた企業の同様の課題では、非同期処理のタイミング依存の不具合を指摘できただけでなく、「本番環境で再現しにくいタイプのバグなので、テストケースを追加すべき」という一歩踏み込んだ提案までできて、通過しています。

プログラミングスキルは本当に不要になるのか、調査データの正しい読み方

ここまで読むと、「プログラミングスキル自体はもう重要ではないのか」と感じる方もいるかもしれません。ただ、この解釈には注意が必要です。先ほどのレバテック調査（2024年11月時点）では、生成AIの普及によって「プログラミングスキルの重要度が下がった」と回答した企業は26.0%でした。裏を返せば、7割以上の企業は重要度が下がったとは考えていないということです。

私はこの数字を、「不要になった」ではなく「相対的な位置づけが変わった」と読むべきだと考えています。AIが生成したコードが正しいかどうかを判断するには、結局のところ自分でコードを読み、実装の意図を理解できる力が土台として必要です。土台となるプログラミング知識がないまま「AIの提案をどう判断したか説明してください」と聞かれても、判断の根拠そのものを持ち合わせていないことになってしまいます。

AIコーディングツールの普及そのものは、実務レベルでもかなり進んでいます。overflowの調査（Offers会員208名対象）では、2025年3月時点でAIコーディングツールの利用率が63.4%にのぼり、ツール別ではGitHub Copilotが60.1%、Cursorが20.7%、Claude Codeが15.4%という結果でした（出典：overflow「AIコーディングツールの利用実態調査」）。ツールの顔ぶれは動きが速いので、この内訳は当時のものとして読んでください。

より新しい2026年の調査では、レバテックの「IT人材調査2026」（2025年11月調査）で、生成AIの利用率が67.8%でした。ツール別ではChatGPTが75.3%、Microsoft 365 Copilotが47.3%、Gemini 40.7%と続きます（出典：@IT「IT人材の『AIエージェント』利用、20代で約5割」）。調査の母集団もツールの定義も違うので単純比較はできませんが、AIを使うこと自体が当たり前になっている点は共通しています。

これだけの割合のエンジニアが日常的にAIを使っている以上、「AIを使えるか使えないか」自体はもはや選考でのアピールポイントにはなりにくく、使った上でどう判断したかの説明力が差別化要素になってきているというのが、複数の調査データと現場感覚の両方から見えてくる結論です。

企業ごとのスタンス差、AI許容型・AI排除型・ハイブリッド型

生成AIへの向き合い方は、企業によってかなり温度差があります。私がこれまで担当した求人を大まかに分類すると、次の3タイプに整理できます。

金融機関の基幹系システムを扱う案件では、情報漏えいのリスクからAIツールの利用を制限している企業に何度も出会いました。逆に自社開発のスタートアップでは、面接の場で「Cursorをどう使っていますか」と聞かれるのがほぼ前提になっているところもあります。

以前、あるバックエンドエンジニアの方が、AI許容型の企業だと思い込んで「Copilotをフル活用して開発スピードを2倍にしました」と面接でアピールしたところ、実際にはAI排除型の企業で、面接官の反応が芳しくなかったということがありました。求人票だけでは判別がつきにくい部分なので、選考の早い段階で「開発でのAIツールの利用状況を教えてください」と確認しておくと、アピールの方向性を間違えずに済みます。エージェント経由の応募であれば、過去の選考実績からどちらのタイプに近いかを事前に共有できることも多いので、担当者に確認してみる価値があります。

候補者側の意識も動いています。LAPRAS登録エンジニア279名への調査（2026年6月）では、転職先選びでAI活用環境を重視すると答えた人が91.4%、企業がAI駆動開発について発信していると応募意欲が高まる人が82.1%でした（出典：LAPRAS「生成AIに関する意識調査」）。登録者という限られた母集団の回答ですが、企業のスタンスは応募先を選ぶ材料としても見られています。面接でAI利用の可否を確認するのは、失礼どころか自然な質問になってきています。

ジュニア層・未経験エンジニアへの影響

評価軸の変化は、経験の浅い層ほど影響が大きいというのが私の実感です。以前であれば、未経験からIT業界に挑戦する方の書類選考では「基礎的な文法を理解し、簡単なアプリケーションを自作できるか」が一つの合格ラインでした。ところが今は、AIを使えば未経験者でも一見それなりに動くアプリケーションを作れてしまうため、成果物だけを見て評価することが難しくなっています。

未経験からエンジニア転職を目指していたGさん(20代半ば・独学でポートフォリオを作成)は、ポートフォリオ自体はよくできていましたが、面接で「このエラーハンドリングの部分、なぜこの書き方にしたのですか」と聞かれた際、AIに書かせたまま提出していたため理由を説明できませんでした。企業からのフィードバックは、「コードの完成度は高いが、本人が理解して書いたものかどうか判断できなかった」というものです。

一方で、通過したケースにも共通点があります。ポートフォリオ制作でAIを使うこと自体は否定されず、むしろ「一人で開発する未経験者がAIを使わない方が不自然」という反応を示す企業も増えてきました。差がつくのは、AIが提案したコードのうち何を採用し、何を書き直したかを自分の言葉で説明できるかどうかです。ジュニア層にとっては、基礎学習を省略する言い訳としてAIを使うのではなく、基礎を固めるための壁打ち相手としてAIを使うという姿勢が、選考でも実務でも評価されやすくなっていると感じます。

面接・職務経歴書でAI活用力をどう説明すべきか

ここまでの内容を踏まえ、転職活動でどう備えればいいかを整理します。まず職務経歴書についてですが、「Copilotを使用」「Cursorを活用」とツール名だけを並べても、今のところ大きな差別化にはなりません。それよりも、AIをどう使い、どう判断を加えたかというプロセスを書き添える方が、書類選考の通過率に効いてきます。

面接での受け答えも同様です。「AIを使って開発効率が上がりました」という一般論だけで終わらせず、「〇〇の実装でAIの提案を一度採用したが、パフォーマンス要件に合わなかったため、自分で書き直した」というように、判断が分かれた具体的な場面を一つ持っておくと、説得力が格段に上がります。技術面接の準備という意味では、コーディングテストで落ちる人に共通する準備不足の記事でも触れましたが、結局のところ評価されるのは「正解を出せるか」以上に「考えるプロセスを見せられるか」という点で、根っこは共通していると感じています。

まとめ、評価されるのは「書く力」より「判断する力」

生成AIコーディングツールの普及によって、エンジニア採用の評価基準は、コードを速く正確に書く力から、設計判断力・要件定義力・AI出力を検証するレビュー力へと軸足を移しています。レバテックの調査（2024年11月）で約4割の企業が「求めるスキルが変化した」と答えていたのは、決して大げさな数字ではなく、その後も私が日々受け取る求人票やフィードバックの実感と重なります。

プログラミングスキルそのものが不要になったわけではありません。むしろAIの提案が正しいかどうかを判断するための土台として、これまで以上に重要になっている場面もあります。ただ、評価される中心が「書けるかどうか」から「AIに何を任せ、何を自分で判断したか説明できるかどうか」に移ってきているのは間違いありません。

企業ごとにAIへのスタンスは大きく異なるため、応募先がどのタイプかを早い段階で見極めることも、選考対策の一部です。書類選考の評価ポイントについてはこちらの記事でも詳しく触れていますし、IT特化型のエージェントに切り替えるべきタイミングについては別記事でまとめています。評価基準が変わりつつある今だからこそ、自分の経験をどう言語化するかに、これまで以上に時間をかけてみてください。