AI駆動開発でエンジニアの評価基準はこう変わった

筆者の面談で見えてきた変化と公開データを、3つの評価軸に整理しました。共通しているのは、評価の重心が移っていることです。つまり「作業のスピードや正確さ」から「判断の質や妥当性」へ、という移り方です。

① 「実装できる」だけでは差がつかなくなった

20代後半で自社プロダクトのリードを務めるエンジニアの方は、面談の冒頭でこう話していました。

筆者も、採用の現場で同じ変化を見ています。その場では、次のようにお答えしました。

※ 面談でうかがった内容は、個人が特定されないよう年代・職種などの要素だけを残し、発言は趣旨を変えない範囲で読みやすく整えています。

実装スピードでは、経験の差が見えにくくなった

実際、CRUD処理程度の実装なら、経験の浅いメンバーでも速く形にできます。AIの力を借りられるからです。さらに、前述のGitHub Copilotの実験にも同じ傾向があります。経験の浅い開発者ほど、生産性の伸び幅が大きかったのです。つまり、実装スピードという単一の指標では、経験差そのものが見えにくくなっているのです。

その結果、面接で聞かれる質問の内容も変わってきています。「実装できますか」という問いから、判断の妥当性やプロセスを問うものに変わってきています。これは、実装力そのものが不要になったという意味ではありません。実装力は依然として土台として必要です。ただし、それだけでは他の候補者との差別化にならなくなってきている、というのが筆者の実感です。

「AIを使っている」だけでも差はつかない

AIツールを日常的に使っているだけでは、差はつきません。30歳のフロントエンドエンジニアの方は、AI開発ツールを日常的に使っていました。

ところが、応募を検討した求人の中には「AIを使って開発を主導した具体例」を求めるものがありました。日常的に使っていることは、もはや前提です。AIで何を変えたかまで語れて、はじめて評価の材料になります。

準備しておきたい質問の例

• 「このコードはAIに書かせましたか。どこを自分で判断しましたか」
• 「AIが提案した実装のうち、採用しなかった部分はありますか。理由は」
• 「この設計を選んだ理由を、トレードオフを含めて説明してください」

② セキュリティとガードレール設計の価値が上がっている

一方で、逆に重みを増しているのがセキュリティの視点です。IPA（情報処理推進機構）は毎年「情報セキュリティ10大脅威」を公表しています。2026年版では「AIの利用をめぐるサイバーリスク」が組織向けランキングに初めてランクインしました。いきなり3位に入っています。前年の2025年版でも、新たな脅威が指摘されました。AIが生成したコードの脆弱性を、多くの企業が十分に評価できていないという指摘です。

先ほどの20代後半のエンジニアの方は、セキュリティ領域のプロダクトを担当しています。勤務先では、セキュリティのチェックシートを一元管理するデータベースを作っていました。

つまり、機密を守る仕組みそのものが、エンジニアの価値の源になっています。筆者が扱っている案件にも、同じ流れがあります。大阪の大手インフラ系企業で、自社独自のセキュリティ環境の中でAIを使って開発するプロジェクトです。AIを安全に使える環境を設計できる人は、業界を問わず求められています。

政府によるガイドライン整備という後押し

こうした動きの背景には、政府側の対応もあります。経済産業省と総務省は2024年4月、「AI事業者ガイドライン（第1.0版）」を公表しました。AIの開発者・提供者・利用者それぞれが取り組むべき責務を、リスクベースのアプローチで整理したものです。

大手企業の中には、外部SaaS型のAIツールを原則禁止する例もあります。その代わりに、自社インフラの中で完結する仕組みを一から設計しています。

「AIが書いたコードを本番にマージする前に、誰が・どこで・何をチェックするか」。このレビューフローの設計自体が、重要なエンジニアリング業務のひとつになりつつあります。実装がAIに置き換わるほど、設計判断の比重は相対的に大きくなっていきます。つまり、AIの出力を安全に使うための仕組みをどう作るか、という判断です。

③ レビューする力・ビジネス理解・そして越境する姿勢

AIの出力を鵜呑みにせず、それが本当に事業の意図に合っているかを確かめる。この視点は、技術の外側にある力と結びついています。フリーランスのコミュニティを運営している方からも、ある話をうかがいました。知人のセキュリティ部門の部長から聞いたという話です。

ただし、伝える力は「見せ方の上手さ」とは違います。30代前半で金融機関の内製開発を担うエンジニアの方は、見せ方ばかりが評価される環境に違和感を持っていました。

評価されるのは、中身のある判断を、相手に伝わる言葉で説明する力です。飾る力ではありません。

仕様書の行間にある「なぜこの機能が必要なのか」を理解していないと、AIの出力の良し悪しを判断できません。実際、IT歴4年のエンジニアの方は、ヘルプデスクから経歴を始めました。その後、上場企業のAI導入プロジェクトで、ベンダー選定から価格交渉までを担っています。技術と事業の両方の言葉を話せることが、役割を広げた理由でした。

言われた範囲を超えて動く姿勢

あわせて重要になっているのが、自分の役割の外側にある課題まで拾いにいけるかどうかです。言われた範囲だけをこなすのではなく、です。「仕様にないけど、これは対応しておいたほうがいい」。そう気づいて動ける人材が評価されやすくなっている、というのが筆者の実感です。

この変化は、複数の現場を渡り歩いてきたエンジニアにとって、必ずしも不利な話ではありません。フリーランスや受託案件の経験が活きるからです。異なる事業ドメイン・異なるチーム文化のなかで「なぜこの仕様が必要なのか」を都度キャッチアップしてきた経験があるからです。つまり、それは事業理解力や越境する姿勢そのものです。この経験を書類でどう見せるかは、フリーランスエンジニアの職務経歴書の書き方で解説しています。