黒い画面でカーソルだけが点滅しています。ジュニア開発者は要件を書いては消し、例外を足し、壊してはいけない既存コードの場所をエージェントに伝えます。数分後、複数のファイルに変更が入りました。動作を確認した後は、別のモデルに差分のレビューを頼みます。
もう珍しい光景ではありません。自分でコードを書く時間より、何を頼むかを決め、生成された変更を読み、惜しいところで外れた答えを直す時間のほうが長い。そんなジュニアが増えています。作業は速くなりました。同時に、「今学んでいることは数年後も役に立つのか」という不安も強くなりました。
「基礎をやれば大丈夫」だけでは足りません。かといって、流行のツールを追うだけでは足元が弱くなります。必要なのは二者択一ではなく、基礎を学ぶ順番と、理解を証明する方法を変えることです。
コードを書く時間が減っても、判断は減らない
以前のジュニアは、小さな機能を自分で実装しながら言語とフレームワークを覚えました。今は同じ機能のたたき台をAIが数分で用意します。ただし、動いたコードと理解したコードは別物です。
正常系を通っただけの実装が、決済を二重に実行したり、ログにトークンを残したり、同じリクエストが続けて来た瞬間に壊れたりします。
Stack Overflowの2025年開発者調査では、AI出力の正確さを信頼する人より、信頼しない人のほうが多いという結果が出ました。もっとも多かった不満は「ほぼ合っているが、完全には合っていない」こと。45%は、AIが作ったコードのデバッグにかえって時間がかかると答えています。
AIが役に立たないのではありません。生成の速さと、結果に責任を持つ仕事は別だということです。
基礎知識には、いままで以上に具体的な出番がある
データ構造、ネットワーク、データベース、OSはまだ必要です。ただ、試験のために覚える基礎と、AIの回答を疑うために使う基礎では、手触りが違います。
エージェントがキャッシュを追加したとします。レビューする側は、少なくとも次の三つを聞けなければなりません。
- キャッシュが空でも整合性を保てるか
- 何をきっかけにデータを無効化するのか
- 障害時に正しいデータへ戻れるか
これはプロンプトの小技ではなく、状態と失敗を理解する力です。HTTPヘッダーを全部暗記する必要はありませんが、認証情報がどこまで流れるかは追えるべきです。SQLを毎回手書きしなくても、実データで実行計画が崩れる兆候は読めなければなりません。
基礎は入社試験のチェック項目ではなく、もっともらしい間違いを見つけるための道具になっています。
責任はシニアになってから始まるわけではない
同じ調査では、多くの開発者がデプロイや監視、プロジェクト計画をAIに任せる予定はないと答えました。この段階では「動いたか」より、「壊れたときに誰が止め、説明し、戻すか」が問題になるからです。
ジュニアが全社アーキテクチャを決める必要はありません。しかし、自分が担当した小さな機能の境界は説明できるべきです。入力はどこから来るのか、何が変わるのか、失敗後に何が残るのか、誰が安全に再実行できるのか。この四点です。
ポートフォリオの見せ方も変わります。画面を何枚並べたかより、次の記録があるほうが実力を伝えます。
| 残す記録 | 伝わる力 |
|---|---|
| 最初の要件と変更理由 | 問題を絞る力 |
| 採用しなかったAI案 | 判断基準 |
| 再現できる失敗 | デバッグの習慣 |
| テストと運用ログ | 検証する姿勢 |
| 戻し方のメモ | 障害時の責任感 |
AIを使ったことを隠す必要はありません。大事なのは、使った後も人が判断していた証拠です。
速く感じることと、早く終わることは違う
AIは最初の出力が早いので、仕事全体も速くなったように感じます。実際にはそうならない場面もあります。
METRは、使い慣れたオープンソースのリポジトリで作業する熟練開発者を対象に、2025年初頭のAIツールの影響を調べました。参加者は短縮を予想していましたが、実測では平均19%長くかかりました。
この数字をそのままジュニアや現在のモデルへ当てはめるべきではありません。対象もツールも限定されています。それでも、生成時間だけを見ればレビュー、修正、巻き戻しに使った時間が消えてしまうという指摘は残ります。
測るならコード行数ではなく、自分で説明できる変更を安全に終えた数です。
12週間で残せる実践記録
大きなサービスは要りません。認証、データ保存、外部APIをひとつ、簡単な管理画面を持つ小さなサービスで十分です。
1〜3週目：AIと作る。ただし変更は全部読む。 変更されたファイルごとに、目的を一文で書きます。説明できない変更はマージしません。
4〜6週目：わざと壊す。 遅い通信、不正な入力、重複リクエスト、期限切れの認証を入れます。AIに直させる前に、ログから原因を絞ります。
7〜9週目：運用の痕跡を残す。 重要な処理にログを加え、失敗ごとに回帰テストを作り、前の正常版へ戻す手順を書きます。
10〜12週目：他人に渡す。 READMEだけで動かせるか、なぜその構造にしたか、どんな制約が残っているかを説明します。相手がいなければ、一日置いて自分で試します。
毎週、次の四行だけ残します。
- 解決しようとした問題
- AIの提案で採用したもの、捨てたもの
- 実際に起きた失敗
- 次回、最初に確認すること
モデルが変わっても、この記録は残ります。
AIを切る時間もつくる
全部を手書きし直す必要はありません。自分がどこまで理解しているかを見るために、短い時間だけAIを切ります。チャットを開く前にデータの流れを描く。コードを頼む前にテストケースを書く。原因調査を頼む前に、現象を自分の言葉で説明する。それだけでも違います。
AIを使うときは遠慮なく使えばいい。定型コード、知らないライブラリの入口、テスト候補の洗い出しには強い味方です。問題は使ったかどうかではなく、どこまで任せ、何を自分で確認したかです。
ジュニア開発者に残る仕事
AIがコードを書く時代でも、問題を定義する人は必要です。利用者の困りごとに気づき、危ないリリースを止め、判断の理由を説明する人も要ります。これはシニアだけの仕事ではありません。
ジュニアがAIと入力速度を競う必要はありません。違和感を拾い、根拠を確かめ、小さな機能を他人が運用できるところまで持っていく経験を積むべきです。バックエンドを学んできたなら、その土台にAIを載せればいい。フロントエンドなら、AIの不確実さを隠さず扱える画面を設計できます。
ツール名も職種名も変わり続けます。それでも、問題を絞り、文脈を理解し、結果に責任を持つ姿勢は簡単には消えません。ジュニアがいま投資すべきなのは、そこです。
