AI時代のエンジニアキャリアラダー再設計——L1〜L7に求められるスキルはどう変わったか

「AIを使えば生産性が上がる」という話は、もう耳タコだろう。問題は、その「生産性が上がる」の恩恵が、エンジニアのキャリアラダーを根本から塗り替えつつあることを、多くの組織がまだキャリア制度に反映していないことだ。

上司から「AIを使って速くやってよ」と言われる一方で、昇進判断の基準は相変わらず「どれだけコードを書いたか」「どれだけ実装に貢献したか」という軸で動いている。ジュニアエンジニアはAIのおかげでPRを量産できるが、その経験がシニアへのキャリアパスにどう繋がるのか、誰も答えを持っていない。EMとして採用・育成に関わる立場でも、「何で評価するか」の再定義を迫られている感覚は、いまや多くの現場で共有されている。

この記事では、Google・Meta・Amazon・メルカリ・DeNAといった企業の実際のキャリアラダー定義を参照しながら、AI時代にL1からL7(プリンシパル相当)までの評価軸がどう変わっているかを整理する。


「AIで生産性3倍」の内側で起きていること

数字から入る。DORA 2025レポート(Google・GitHub・GitLab協力)によると、開発者のAIツール利用率はすでに95%に達しており、個人の生産性指標は確かに改善している。Faros AIの分析(2025年データ)では、AIツール高採用チームでタスク完了数が21%増、PRマージ数が98%増——見た目は圧倒的な改善だ。

ところが、組織全体のデリバリー指標は横ばいだった。個人が速くなっているのに、チームとしてのアウトプットは変わっていない。

さらに気になるのが副作用だ。Faros AIの2025年分析では、AIの活用が進んだ組織でコードレビュー時間が91%増え、バグ率が9%増加したという。さらに2026年の同社追跡データ(AI Acceleration Whiplash レポート)では、PRレビュー時間の中央値が441%増、インシデントとPRの比率が242.7%増という数値も出ている。

DORAレポートはこの現象をこう表現している。「AIは組織の既存の強みと弱みを増幅するアンプとして機能する。ツールの精巧さよりも、組織システムの健全性が成果を決定する」。

つまり、AIはコーディング速度を上げるが、そのコードを適切に判断・レビュー・統合できる人間の能力が追いついていなければ、速さはそのままリスクに変わる。ここにキャリアラダー再設計の核心がある。


従来のL1〜L7は何を測っていたか

主要企業のキャリアラダー定義を見ると、現在地が見えてくる。

Googleはレベル3(L3)からスタートし、L5がキャリアの定着点として知られている。designgurus.ioによると、L5→L6の昇進が最大の関門で、判断基準は「自チーム外の技術方向性に影響を与えられるか」だ。実装の速さや量ではなく、影響範囲の広さが問われる。

MetaはE3からE5の間に約85%のエンジニアが定着し、E6(Staff)に到達できるのは全体の約15%にとどまる。Amazonでは、L6(SDE III)からL7(Principal SDE)への昇進に「組織やディビジョン全体の技術戦略を担えるか」が問われる。

国内ではメルカリが参考になる。メルカリのエンジニアリングラダーでMG6(Principal Engineer)以上に求められるのは、「他者が達成できない技術的ブレークスルー」「エンジニア組織ビジョンへの貢献」「社内外への知識共有」という3軸だ。

従来のキャリアラダーは、要約すると「実装 → 設計 → 影響範囲の拡大」という単純な成長モデルで設計されていた。ジュニアはコードを書いて学び、シニアはシステムを設計し、スタッフ以上は組織に影響を与える。このモデル自体は今も有効だが、AI時代に入って「ジュニアがコードを書いて学ぶ」という最初のステップが崩れ始めている。


ジュニア(L1〜L3)のキャリアパスに何が起きているか

数字が象徴的だ。エントリーレベルのテック職求人は前年比73.4%減という報告がある(quasa.io)。Chrome Engineering LeadのAddy Osmaniの分析でも、ジュニア開発者の雇用が生成AI採用後6四半期以内に9〜10%減少し、ビッグテック各社が過去3年間で新卒採用を50%削減したという傾向が報告されている(参照)。

なぜこうなるのか。理由の一端は、「AIスキルインバージョン」と呼ばれる現象にある。

AIツールはCRUDエンドポイントやReactコンポーネントのような定型タスクが得意だ。これは従来のジュニアが時間をかけて「学んでいた」作業と重なる。結果、ダッシュボード上ではAI補助のジュニアがシニアより高い生産性を示すことがある。しかし、アーキテクチャ的な判断力は育っていない。表面上の数字と実際のスキル習熟が乖離する構造だ。

さらにLeadDevのAI Impact Report 2025(880人以上のエンジニア調査)では、38%のエンジニアが「AIツールによりシニア・ジュニア間の直接メンタリングが減少した」と報告している。シニアがジュニアのコードを一緒に見て教える機会が、AIを介することで薄れていく。

GitHubの研究によると、6ヶ月間GitHub Copilotを使い続けた経験の浅い開発者は、AIなしの状態でのアルゴリズム問題解決能力が28%低下するという結果も出ている(GitHub Blog)。一方でPR完了時間は55%短縮されるので、速さと基礎力が逆方向に動く現象が起きる。

この状況への一つの回答として提唱されているのが「AI Reliability Engineer(ARE)」という新ロールの概念だ。

従来のジュニア(L1〜L3)AI時代の再定義
機能実装・バグ修正仕様書の設計(AIエージェントへの命令書)
コーディング速度ハルシネーションチェック・検証テスト
コードを書くAI生成コードのアーキテクチャリスクレビュー
commit数Defect Capture Rate(欠陥検出率)

ジュニアに求められるのが「書く力」から「仕様を書き、AIの出力を検証し、欠陥を発見する力」に変わっている。評価の入り口も変わりつつあり、「レビューシミュレーション」(意図的に欠陥を仕込んだAI生成コードを提示し、アーキテクチャリスクを特定できるか評価する)が採用・昇進評価の新手法として登場している。

5〜10年後にシニアが不足する「パイプライン崩壊」リスクは、EMが今から意識しておくべき問題だ。ジュニアがAIに依存して基礎技術を習得できないまま量産されると、次の世代のシニアが育たない。


シニア以上(L5〜L7)に求められる「次の判断軸」

シニア以上はどうか。Pragmatic Engineerは、「エージェントがコードをより多く書くにつれて、Staff Engineerの需要はむしろ増す」という逆説的な結論を示している。ソフトウェアライフサイクルの自動化が進めば進むほど、人間が監督者として判断に介在する必要性が増すからだ。

LeadDevの現役Staff Engineerの記録には、従来1ヶ月かかった複数リポジトリの解析をAIエージェントで2〜3日に短縮した体験とともに、変化した価値の所在が記されている。「どれだけ速く実装できるか」から「実装されたものを信頼できるか判断できるか」へ。

L5〜L7それぞれの評価軸の変化を整理すると以下のようになる。

L5(シニア):AI下でのメンタリング再設計

GoogleのL5→L6昇進の従来要件は「自プロジェクト外の技術方向性に影響を与えた実績」だ。これにAI時代の追加軸として浮上しているのが、AIエージェントのアーキテクチャ設計(どのエージェントをいつ使うか)、AI生成コードの品質管理フレームワーク策定、そして「AIの限界を認識し、人間の介入が必要な場面を定義するガードレール設計」だ。

また、メンタリングの形も変わる。AIが実装を担うなら、シニアがジュニアに伝えるべきは「コードの書き方」ではなく「判断の仕方と仕様の質」になる。

L6(スタッフ):オーケストレーションの設計者へ

L6に求められていたのは「複数チームへのアーキテクチャ判断」だった。AI時代にこれに加わるのが、AIエージェントのオーケストレーション設計だ。どのエージェントをどう組み合わせるか、チームがAI生成コードをどのように品質保証するか、その組織的フレームワークを設計できるかが問われる。

L7(プリンシパル+):AI戦略の策定者

プリンシパル以上に求められていた「組織全体の技術戦略」という役割に、AI時代ならではの軸が加わる。

従来のL7AI時代の追加要件
複数チームへのアーキテクチャ影響AIエージェントオーケストレーションのフリート全体設計
技術戦略の策定どこにエージェントを使いどこに人間を残すかの組織方針
シニアエンジニアのメンタリングAIリテラシー格差の橋渡し(懐疑者・過信者双方への対応)
システム設計ドキュメントをインフラとして整備(AIが参照できる知識ベース構築)

CIO誌の分析によると、2026年以降のL7の仕事の中核は「エンジニアリングは『オーケストレーションと品質保証』を中心に再設計される」という方向に動いている。


日本企業の実践例——メルカリとDeNA

抽象論ではなく、実際に動いている企業の事例も見ておきたい。

メルカリは2025年5月にAI-Native化を宣言し、その数週間後に100人超のAI Task Forceを設立した。全希望エンジニアにCursorライセンスを配布し、開発スピードが前年比64%向上したとmercanは伝えている。2026年6月にはCTOがCHROとCAIOを兼任するという組織モデルを採用し、「AI戦略と人事戦略を同一リーダーが統括する」形に移行した(プレスリリース)。コードのAI生成割合は70%に達しているという。

DeNAは2025年8月にDARS(DeNA AI Readiness Score)を全社導入した(DeNA PR)。5段階評価で、Level 1「基本的な知識と使用習慣」からLevel 5「AIを活用して事業変革を起こせる戦略設計力」まで、エンジニア・非エンジニアを問わず全従業員を対象としている。人事評価との直接連動はしないが、グレード制度内の「推奨要素」として半期ごとのゴール設定に組み込まれている。2027年度新卒採用からは「AIジェネラリスト」コースを新設し、2026年度の内定者へのAIツール月額100ドル補助も先行提供している(DeNA PR)。


自分のキャリアを再設計するための視点

自分のレベルに合わせて、何が変わるかを整理しておく。

ジュニア〜ミッドレベル(L1〜L4相当)の人へ

AIなしで問題を解ける力を意識的に鍛える期間を設けることを勧める。週に1度、Copilotなしのコーディングセッションを作るだけでも意味がある。それと同時に、仕様書を書く機会を増やしてほしい。AIへの命令書としての仕様書の質が、将来の自分の価値になる。

「AIが書いたコードをどれだけ速くレビューできるか」ではなく、「AIが書いたコードの何が危ないかを指摘できるか」が、これからの評価軸になる。

シニア(L5相当)の人へ

メンタリングのやり方を変えることが急務だ。ジュニアのコードを一緒に書く機会が減っているなら、意図的に「仕様の書き方」「AI出力の検証方法」「欠陥の発見パターン」を教える時間を作る必要がある。DORA 4指標(デプロイ頻度・リードタイム・変更失敗率・復旧時間)を使いこなし、AI導入前後の変化を数字で語れるかどうかが、L6昇進の判断材料になる。

スタッフ以上(L6〜L7相当)の人へ

AIエージェントのオーケストレーション設計が実務課題になっている。Claude CodeやLangGraphを使った実験をチームに持ち込み、どのタスクをどのエージェントが担うべきかの方針を文書化する。DeNAのDARSのような「チーム内AI習熟度マップ」を独自に設計するのも、L7の仕事として価値が高い。


おわりに

キャリアラダーは、「評価する側が何を価値とするか」を示す設計図だ。コードを書く速さや量を軸に設計されたラダーは、AIが普及した環境では機能しなくなる。

ジュニアが量産できるようになった分、シニアに求められる判断力の価値は上がっている。ただし、その判断力がパイプラインとして次の世代に受け継がれなければ、5〜10年後に困るのは組織だ。

「自分が今のレベルで何を評価されているか」ではなく、「次のレベルで何を見せなければならないか」を、AI時代の文脈でもう一度確認しておいてほしい。

あなたの組織のキャリアラダーの定義が、最後に改訂されたのはいつか。一度確認してみると、議論の出発点が見つかる。

コメント

タイトルとURLをコピーしました