AIが新人の仕事を吸収した時代、エンジニアはどう育つのか

AIが下積みの仕事を担うようになった今、新人エンジニアはどう経験を積むのか。vibe codingの危険性と、AIを「家庭教師」として使う学び方を現役エンジニアの視点で論じる。

「入口」が見えにくくなっている

最近、新人エンジニアを見ていて感じることがある。コードは動く。アウトプットのスピードも悪くない。でも「なぜこれで動くのか」を聞くと、言葉に詰まる。

これは責める話ではない。構造的な問題だと思っている。

従来、新人エンジニアが育つ道筋はわりと明確だった。退屈で、地味で、でも確実に効いていた。ボイラープレートを写経する、CRUDのAPIを何本も書く、先輩のコードを読んで意図を推測する、構文エラーを自力で直す、レビューで赤を入れられる。その繰り返しの中で「コードを読む目」と「なぜ動くかの直感」が育っていった。

今、その入口の多くをAIが担っている。

それ自体は悪いことではない。ただ、その変化が何を奪い、何を残し、新人はこれからどう育てばいいのか——育てる側はどう設計すればいいのか——を正直に考える必要があると感じている。この記事はそのための論考だ。

何が変わったか：下積みの吸収

AIコーディングアシスタントが日常的に使われるようになって、エンジニアの仕事の流れが変わった。具体的に言えば、以下のような作業の多くをAIが代替するようになった。

• 定型的なCRUD実装の雛形生成
• バリデーションロジックの記述
• 構文の調べ方・使い方の確認
• よくあるバグパターンの発見と修正案の提示
• テストケースのスケルトン生成
• ドキュメントの初稿作成

これらはかつて「新人が手を動かして覚えるもの」だった。退屈だが、この反復がなければ土台が積み上がらなかった。

シニアエンジニアにとっては、AIの登場は生産性の向上だ。経験と判断力があるから、AIの出力を素早く評価し、適切に修正し、先に進める。しかし経験がない新人にとっては、状況が少し違う。AIが答えを出してくれるのは便利だが、その答えが正しいかを判断する軸がまだ育っていない。

入口の仕事が減ったというより、入口の見え方が変わった——と言ったほうが正確かもしれない。問題は、その入口がどこにあるか、本人も周囲も気づきにくくなっていることだ。

危険：理解を伴わない「vibe coding」

「vibe coding」という言葉がある。雰囲気でAIにコードを生成させ、動いたからOK、という開発スタイルを指す。

たとえば、次のようなLaravelのコードをAIが生成したとする。

// AIが生成したコード例（問題あり）
public function search(Request $request)
{
    $keyword = $request->input('keyword');
    $results = DB::select("SELECT * FROM users WHERE name = '$keyword'");
    return response()->json($results);
}

このコードはSQLインジェクションの脆弱性を持っている。動くことは動く。テストも通るかもしれない。しかし「なぜ危ないのか」を理解していなければ、問題に気づけない。

// 正しい実装
public function search(Request $request)
{
    $keyword = $request->validated()['keyword'];
    $results = User::where('name', 'like', '%' . $keyword . '%')->get();
    return response()->json($results);
}

二つのコードの差を説明できるか。Eloquentがなぜ安全なのか、プリペアドステートメントとは何かを理解しているか。AIが出した答えを評価する土台がなければ、正しいコードも危ないコードも「動いた」という結果に見えてしまう。

浅い習熟は、表面的には優秀に見える。アウトプットは速い。でも本番環境のインシデント、セキュリティ事故、スケールしたときのパフォーマンス問題——そういう場面で突然、土台の薄さが露わになる。

それでもどう育つか：AIを「家庭教師」として使う

「なぜ？」を聞き続ける習慣

AIはコードを生成するだけでなく、説明するのが得意だ。これを積極的に使う。

# 悪い使い方
「LaravelでAPIを作るコードを書いて」→ そのまま使う

# 良い使い方
「このコードのRouteServiceProviderでのルートグループ定義の意図を説明して」
「なぜEloquentのwithを使うとN+1が解消されるのか、SQLレベルで説明して」
「このミドルウェアの処理順序はどう決まっていて、なぜこの順番でなければいけないのか」

生成されたコードを「写す」のではなく、「説明させてから自分で再現する」。この手順を踏むだけで、学習の深度が変わる。

基礎はむしろ重要になった

AIが普及したことで、コンピュータサイエンスの基礎は不要になった——という意見を聞くことがある。私はむしろ逆だと思っている。

AIの出力を評価するには、判断の軸が必要だ。その軸の根っこは基礎知識だ。

flowchart TD
    A[AIが出力を生成] --> B{評価できるか？}
    B -->|基礎あり| C[問題を発見・修正できる]
    B -->|基礎なし| D[動いたからOKになる]
    C --> E[信頼できるエンジニア]
    D --> F[vibe coding の罠]
    style C fill:#10B981,color:#fff
    style F fill:#EF4444,color:#fff

• HTTP・リクエスト/レスポンスの仕組み：なぜAPIが動くかの基本
• データ構造（配列・連想配列・ツリー）：アルゴリズムの選択に直結
• SQLの実行計画：ORMが生成するクエリを評価できる
• メモリとスコープ：なぜメモリリークが起きるか
• 非同期処理の概念：JavaScriptのPromise・async/awaitの本質

これらはAIに聞けば教えてくれる。しかし「一度聞いた」と「自分の言葉で説明できる」の間には大きな溝がある。その溝を埋める努力を、AIはしてくれない。それは本人がやるしかない。

「疑う目」を早めに育てる

コードレビューは、シニアが新人のコードを見るものだという固定観念がある。しかし今の新人には、「AIの出力をレビューする目」が早期から求められる。

AIの出力に対して、以下を習慣にする。

• エラーハンドリングは網羅されているか
• エッジケース（空文字・null・大量データ）に対応しているか
• セキュリティ上の考慮（インジェクション・認可漏れ）はあるか
• テストは書けるか（書けないならコードの設計に問題がある可能性）

// AIが出したコードを疑う視点の例
// 「このメソッド、$userがnullのときどうなる？」
public function getUserProfile(int $userId): array
{
    $user = User::find($userId); // nullの可能性がある
    return [
        'name'  => $user->name,  // nullでエラー
        'email' => $user->email,
    ];
}

// 疑った結果、こう直す
public function getUserProfile(int $userId): array
{
    $user = User::findOrFail($userId); // 404を明示的に返す
    return [
        'name'  => $user->name,
        'email' => $user->email,
    ];
}

「このコードが壊れるのはどんな状況か」を考える癖は、AIが普及する前から重要だった。今はそれを「自分のコード」と「AIのコード」の両方に向ける必要がある。

小さくても、最後まで自分で責任を持つ

規模は問わない。「自分が作って、自分でデプロイして、自分で運用して、壊れたら自分で直す」という経験を持つことが重要だ。

これはAI時代でも変わらない、むしろより意識的に確保すべき経験だ。小さなCLIツールでも、個人のサイドプロジェクトでも構わない。誰かの指示でなく、自分が意思決定者として最後まで付き合う経験が、判断力を育てる。

AIはコードを書いてくれる。でも「本番でこのコードを動かしていいか」の判断と責任は、人間が取る。その判断の重さを早めに経験することが、エンジニアとして育つための核心だと思っている。

コードの外側の価値が上がっている

AIがコーディングを部分的に担うようになると、相対的に価値が上がるのが「コードの外側」だ。

「何を作るべきか」「なぜこの機能が必要か」「ユーザーが本当に困っているのは何か」——これらはAIが代替しにくい領域だ。新人のうちから、要件の背景を聞く習慣、問題の定義を疑う習慣を身につけることが、長期的な差になる。

育てる側の責任：学びの機会は意図的に設計しなければ消える

新人が育たないとしたら、それは新人だけの問題ではない。

入口の仕事がAIに吸収された分、「学びの機会を意図的に設計する」のが先輩・会社の役割になった。これはコストだが、避けられないコストだと思っている。

具体的には、こういうレビューの問いかけが有効だと感じている。

# 表面的なレビュー
「動いてる？OK、マージしよう」

# 学びを設計するレビュー
「このN+1、気づいた？どうやって見つけた？」
「AIが出したコードをそのまま使ったなら、このメソッドの挙動を僕に説明してみて」
「このエラーハンドリング、どんなケースを想定して書いた？」

「AIが書いたコードを理解して説明できるか」を問うレビューは、ある意味で以前より難しくなっている。なぜなら、先輩も「動いたからOK」に流されやすいからだ。意識的にそこに抵抗する文化が、チームの底力を決める。

逆説的な希望：AIは史上最高の個人教師でもある

問題を正直に書いてきたが、最後に逆説的なことを言いたい。

やる気のある新人にとって、今は学習環境として過去最高水準にある。

かつての新人は、疑問があっても聞ける先輩が近くにいないと詰まった。書籍を買い、Stack Overflowを読み、試行錯誤した。それも悪くはなかったが、効率は良くなかった。

今は、深夜でも、何度でも、恥ずかしがらずに「なぜ？」を聞ける相手がいる。それがAIだ。

「実務経験」だけはAIが代替できない。でもそれ以外の学習環境は、過去と比べて格段に良くなっている。

差がつくのは、シンプルにここだと思う。

AIに考えさせるか、AIと一緒に考えるか。

前者は答えを消費する。後者は思考を鍛える。同じツールを使っていても、3年後の実力は全く違うものになる。

まとめ：AI時代のエンジニア育成チェックリスト

AIが台頭したこの時期に新人であることは、チャンスでもあり、罠でもある。その両面を正直に見ながら、意図的に学ぶ——それが今の時代にエンジニアとして育つということだと思っている。

新人の育成設計や、AI時代のチーム開発の進め方について悩んでいる方は、気軽にご相談ください。Fivenine Designでは、開発の現場から感じる実感をもとに、一緒に考えることができます。