起：AIが「正解に見えるコード」をくれる時代の違和感
Claude Codeを使い始めると、最初は感動します。
「ユーザー認証機能を作りたい」と伝えるだけで、動くコードが数秒で出てくる。テストまで書いてくれる。エラーが出たら、その理由を説明してくれる。昨年までなら、Stack Overflowで何時間も検索して、試行錯誤を繰り返していた作業が、もう不要になった。
でも、ここからが問題です。
コードが「動く」ようになると、多くのジュニアエンジニアは一度、立ち止まります。画面にはAIが出力した実装があって、テストも全部グリーンになっている。でも、なぜこう実装されているのか、本当のところはわかっていない。
「これでいいのかな」という違和感。
多くの人は、そこで「AIだから大丈夫だろう」と思考を停止させます。あるいは「自分の理解が不足しているだけ」と感じて、なんとなく先に進む。その結果、数週間後——プルリクエストのレビューで指摘される。「このライブラリ選択、ここは冗長じゃないですか」「この実装、もっとシンプルにできますよ」と。
そのとき初めて気づく。「あ、AIの出力は『正解』じゃなくて『一つの選択肢』だったんだ」と。
承：落とし穴「動いたら正解」という誤信念
ここで大事な理解があります。
AIが出すコードは、テストが通る、というだけで「ベストプラクティス」ではありません。
例えば、ユーザーの年齢を検証するコードを書いてもらったとしましょう。AIはこう出すかもしれません。
function validateAge(age) {
if (age >= 0 && age <= 150) {
return true;
} else {
return false;
}
}
動きます。テストも通ります。でも、本当はこう書く方が「読みやすい」かもしれません。
function validateAge(age) {
return age >= 0 && age <= 150;
}
あるいは、業務要件が「18歳以上」なら、年齢制限の数字がコードの中に散らばっていない方が、後で変更するときに楽です。
const MINIMUM_REQUIRED_AGE = 18;
const MAXIMUM_REALISTIC_AGE = 150;
function validateAge(age) {
return age >= MINIMUM_REQUIRED_AGE && age <= MAXIMUM_REALISTIC_AGE;
}
AIはどれを出すこともできます。そして、どれを選ぶかは「技術判断」なのです。
ここが重要です。「動く」と「良い」は別です。
テストが通る、エラーが出ない、機能として動作する——これは「正しく動く」というレベル。でも「良い実装」には別の要素があります。
- 保守性：半年後、別の人がこのコードを読んで理解できるか
- 拡張性：要件が変わったときに、修正しやすいか
- 効率性：不要な処理はないか、ライブラリ選択は適切か
- 一貫性：プロジェクト全体の他のコードと同じ雰囲気か
AIは「動く」ことを最優先に出力します。上記の「良い実装」の基準は、人間の経験と判断が必要です。
だから、ジュニアが陥りやすい罠は、こうです。
「AIが出したコードは、とりあえず信頼できる」という信念。
これが学習を止めます。なぜなら「なぜこう実装したのか」という問いが生まれなくなるから。
転：レベルアップの本質は「なぜ？」を言語化する力
では、ジュニアエンジニアがレベルアップするとは、何か。
それは「なぜこの実装なのか」を、自分の言葉で説明できるようになることです。
少し大げさに聞こえるかもしれませんが、これが本当です。
なぜなら、これからの時代、「実装ができること」の価値はどんどん下がっていくからです。AIは日々進化します。やがて、ほぼ全ての実装をAIが担当するようになるでしょう。そのとき、人間のエンジニアに求められるのは何か。
それは「この問題を、どう解決するか判断できる力」です。
ユーザーが「認証機能を作ってほしい」と言ったとき：
- OAuth を使うべきか、セッションベースにするべきか
- データベースは何を選ぶか
- セキュリティ要件は何か
- スケーラビリティは考慮すべきか
- チームの技術スタックとの整合性は
こういう判断ができる人間がいなければ、AIはただ「それっぽいコード」を出力するだけになります。
だから、ジュニアが今やるべきことは、こうです。
Claude Codeが出したコードに対して『なぜ？』と問い続けること。
「なぜこのライブラリを選んだんだろう」
「なぜこの関数の分け方にしたんだろう」
「なぜこの順序で処理してるんだろう」
そして、AIに聞く。何度も。何度も。
「この実装、なぜこうしたんですか」
「他の方法はないですか」
「この場合、メリット・デメリットは何ですか」
「業界のベストプラクティスはどうですか」
短期的には、これは実装を遅くします。質問を重ねていれば、当然時間がかかります。でも、長期的には、あなたの「技術判断力」が磨かれます。
例えば、データベースについて。最初は「AIが PostgreSQL を選んだから、それでいいや」と思うかもしれません。でも「なぜ PostgreSQL なんですか」と聞いて、AIが「スケーラビリティと ACID 準拠が必要だから」と答えたとき、あなたは学びます。「あ、要件によってデータベースの選び方が変わるんだ」と。
次のプロジェクトで、シンプルなキャッシュデータなら、Redis を検討する。ドキュメント指向なら MongoDB も選択肢になる。そういう判断ができるようになります。
これが「レベルアップ」です。実装の速さではなく、判断の深さ。
質問を重ねることは、恥ずかしくない
ここで大事な心理的ポイントがあります。
「何度も同じことを聞くのは、バカに見えるんじゃないか」
多くのジュニアエンジニアが感じる不安です。でも、これは誤解です。
質問を重ねることは、最高の学習方法です。
なぜなら、AIは怒りません。無視しません。昨日と同じ質問をしても、丁寧に答えてくれます。人間の先輩に「同じこと何度も聞くなよ」と言われることはない。
これは圧倒的なアドバンテージです。
書籍を読むとき、わからない部分を何度も読み直すのは当たり前ですよね。同じように、AIとの対話でも「わかるまで何度も聞く」が当たり前でいいのです。
実は、シニアエンジニアたちも、心の中では同じことをしています。わからない技術仕様があれば、ドキュメントを何度も読む。他人のコードを何度も読む。同僚に何度も聞く。その繰り返しで、理解が深まるのです。
あなたは、その「繰り返し」をAIとやるだけです。
結：実践的な3つのアクション
では、具体的に何をするか。3つのシンプルなアクションです。
アクション1：実装後に「なぜ」を聞く
Claude Codeが実装を出したら、すぐに実装に組み込まない。まず聞きましょう。
「このコード、どういう理由でこう実装しましたか」
AIは丁寧に説明します。その説明を読んで、わからなければ、さらに聞く。
「その理由がわからないんですが、もっと簡単に説明してもらえますか」
遠回りに見えますが、このプロセスが理解を深めます。
アクション2：代替案を聞く
「この実装、別のやり方はありますか」
ほぼ全ての実装には、複数の選択肢があります。AIに聞けば、別案を提示してくれます。
「方法A と方法B、どっちが良いんですか」
その違いを理解することで、あなたの判断力が育ちます。
アクション3：自分の言葉で説明してみる
翌日、あるいは翌週に、その実装について「なぜこれを選んだのか」を、自分で言葉にしてみてください。
頭の中で「うーん、確か…」となったら、それはまだ理解が浅いサイン。もう一度 Claude Code に聞く。何度も繰り返す。
この「自分の言葉で説明できる」という状態が、本当の理解です。
最後に
AIツールが当たり前になった時代、ジュニアエンジニアの価値は「どれだけ速く実装できるか」では決まりません。
「正しい判断ができるか」「なぜそう判断したのか説明できるか」——それが価値になります。
短期的には、質問を重ねることは時間がかかります。実装スピードは落ちるかもしれません。
でも、その時間は無駄ではありません。
3ヶ月後、半年後、あなたは「あ、この要件なら、こっちの技術の方が合ってるな」と判断できるようになります。チームのコードレビューでも「これ、なぜこう実装しましたか」と的確な質問ができるようになります。
それは、あなたがレベルアップした証です。
だから、遠回りを恐れないでください。Claude Code に何度も「なぜ」と聞く。その繰り返しが、あなたを「動くコードを書く人」から「判断できるエンジニア」へ変えていきます。
僕たちジュニアエンジニアは、この時代、この環境の中で、誰よりも効率よくレベルアップできます。
AIという最高の先生を相手に、何度でも質問できるのですから。