はじめに
昨今の生成AIやエージェントの進化は、本当に目を見張るものがあります。コードを書いてもらい、設計の相談をして、ドキュメントまで作ってもらえる。エンジニアとしての仕事の進め方が、ここ1〜2年で大きく変わったと感じている人も多いのではないでしょうか。
ただ、そんな中でふと考えることがあります。「AIがやってくれる」ことへの依存が深まるほど、自分自身の技術的な地力はどうなっていくのだろう、と。エンジニア歴〜5年ぐらいの時期は、基礎体力が決まる大事な時期だと考えています。ここでAI活用の便利さに乗っかるだけで終わるか、AIを使いながら基礎技術への理解も着実に深めていくかで、2〜3年後のエンジニアとしての実力に大きな差が出ると感じています。
AIに使われるのではなく、AIを使いこなす側であり続けるための地力の養い方について、考えをまとめてみます。
便利さの落とし穴——AI依存が生むリスク
【「動く」と「わかる」は別物】
生成AIは優秀です。プロンプト(AIへの指示文)を渡せば、それなりに動くコードをすぐに出してくれます。初めて触る技術でも、ある程度の実装ができてしまいます。これは本当にすごいことで、生産性の観点では疑いようのないメリットです。
しかし、「動くコードが手に入る」ことと「そのコードがなぜ動くかを理解している」ことは、まったく別の話です。AIが出したコードをそのまま貼り付けて動作確認し、OKだったらコミット(変更を保存すること)する、というサイクルが続くと、「動いているが、なぜ動いているかわからない」コードが積み重なっていきます。
最初のうちはそれでも回ります。しかし、予期せぬバグ(プログラムの誤り)が出たとき、パフォーマンス(処理性能)が劣化したとき、要件が変わって設計を見直す必要が出たとき、「なぜそうなっているか」を理解していないコードは、修正するのが非常に難しいです。
【エラーへの対処力が育たない】
AI活用への依存が深まると、エラーが出たときの対処パターンが「AIに貼り付けて聞く」一択になりがちです。これ自体は悪いことではありません。AIはエラーメッセージの解読が得意ですし、ありきたりなエラーなら素早く解決策を出してくれます。
問題は、AIが答えを出せないタイプのエラーに直面したときです。本番環境特有の再現しないバグ、複数のサービスが絡み合った複雑な障害、ドキュメントが少ない社内の独自ライブラリに起因する問題——こういったケースでは、「ログ(記録)を読む」「スタックトレース(エラーの発生経路)を追う」「仮説を立てて切り分ける」という地道なデバッグ(問題の調査・修正)能力が必要になります。
この能力は、自分でエラーと向き合い、「どこで何が起きているか」を自力で追いかけた経験の積み重ねによって育ちます。AIに頼り続けると、この経験が積まれません。
【思考力の成長が止まる】
さらに深刻なのが、設計判断における思考力への影響です。アーキテクチャ(システムの構造設計)を決める、パフォーマンスのボトルネック(処理の詰まりどころ)を特定する、トレードオフ(何かを得るために何かを犠牲にする判断)を考える——こういった判断をすべて「AIが出した案をそのまま採用する」という形で進めていると、判断する力そのものが育ちません。
AIは「それっぽい答え」を出すのが得意ですが、その答えが本当にプロジェクトの文脈に合っているかどうかを評価するのは、エンジニア自身の理解力に依存します。基礎がなければ、良い案と悪い案の区別がつきません。
【変化への脆弱性】
AIツールへの依存が深まると、そのツールが使えなくなったときに途端に生産性が落ちます。AIサービスが仕様変更される、コストの問題で使えなくなる、新しい技術領域でAIの学習データが少なくて頼りにならない——こういった場面で、「自分の力で考える」引き出しがないと身動きが取れなくなります。
また、「なぜそうなるのか」を理解していないと、新しい技術パラダイム(技術の考え方の枠組み)が登場したときに自力でキャッチアップ(追いつくこと)できず、常に「誰かが解説してくれるのを待つ側」になってしまいます。
基礎を積み上げると何が変わるか
【「裏で何が起きているか」がわかる】
OS(コンピュータの基本ソフトウェア)、ネットワーク、データ構造、アルゴリズム(問題を解く手順)の理解が深まると、どんなツールやフレームワーク(開発の土台となる仕組み)を使っても「裏で何が起きているか」がわかるようになります。
例えば、Webアプリケーションのレスポンス(応答)が遅い問題に直面したとき。ネットワークの知識があれば「DNSの名前解決(ドメイン名をIPアドレスに変換すること)に時間がかかっているのでは」「TCPのコネクション確立(通信の開始処理)が多すぎるのでは」という仮説が立てられます。データ構造やアルゴリズムの知識があれば「このクエリ(データ検索の命令)の計算量(処理に必要な操作の数)が問題では」という視点が持てます。
原因を構造的に理解できるから、対処も的確になります。これは、AIへの「なんで遅いの？」という曖昧な問いとは、問題解決の質がまったく違います。
【新技術を「本質」で理解できる】
技術の移り変わりは速いです。新しいフレームワーク、新しいクラウドサービス、新しいプログラミング言語が次々と登場します。これらをすべて表面的に追いかけていると、永遠に「使い方を覚える」だけで終わります。
基礎技術への理解が深いと、新技術に触れたとき「この仕組みは、あの概念と同じだ」という対応付けができます。Docker(アプリをまとめて動かす仕組み)はOSのプロセス分離とファイルシステムの仕組みを使ったもの、Redis(データをメモリ上に置いて高速に読み書きできるツール)はデータをメモリ上に持つハッシュテーブル(キーと値の対応表)として理解できる、といった具合です。使い方のドキュメントを読む前に、大まかな動作原理が推測できます。これが、新技術の学習速度に大きな差をもたらします。
【技術的負債を回避できる】
技術的負債(短期的に楽な実装を選んだ結果、後で修正コストがかかる状態)を積み上げないのも、基礎力があるエンジニアの強みです。
パフォーマンスのボトルネックになりそうな箇所を事前に察知できる、セキュリティリスクを「なぜ危ないのか」という構造レベルで理解できる、スケーラビリティ(システムの規模拡大への耐性)を見据えた設計ができる——これらはすべて、基礎知識があってはじめて判断できることです。AIが「安全なコードを書いてくれる」場合も多いですが、それが本当に安全かどうかを判断するのは結局のところエンジニア自身です。
【長期的に「難しい問題を任される人」になれる】
AI時代においても、「AIでは解けない問題」は確実に存在します。未知の本番障害の対応、複数の技術的制約が絡み合った設計判断、ビジネス要件と技術的なトレードオフのすり合わせ——こういった問題を解けるエンジニアの価値は、AIが普及するほど相対的に高まっていきます。
基礎技術を積み上げたエンジニアは、時間とともに「あの人に頼めば解決できる」という信頼を積み重ね、シニアエンジニア、アーキテクト、CTO（Chief Technology Officer：企業の技術部門を統括する最高技術責任者）へのキャリアパスが開けていきます。
地力が活きる瞬間
【本番障害が起きたとき】
深夜にアラートが鳴り、本番環境でエラーが多発している。そんな場面でまず頼りになるのは、ログ(システムの記録)を読む力、スタックトレース(エラーの発生経路)を追う力、そして「どこで何が起きているか」を仮説立てて切り分ける力です。
AIにエラーログを貼り付けて聞くこともできますが、ログのどの部分が本質的な情報かを判断できなければ、AIも的外れな回答を返してきます。OSやネットワーク、アプリケーションの各層(役割ごとに分かれた構造)を理解しているエンジニアは、「これはDBの接続数が上限に達している」「これはメモリ不足でプロセスが落ちている」という仮説を素早く立てられます。障害対応のスピードと精度に、地力の差がはっきり出る瞬間です。
【パフォーマンス劣化に気づいたとき】
「最近レスポンスが遅い気がする」という報告が来たとき。データ構造やアルゴリズムの計算量への感覚があると、「あの処理、データが増えるにつれて重くなる構造になっていたな」とすぐに候補が浮かびます。ネットワークの知識があれば、アプリケーション側ではなく通信の往復回数が原因だと気づけることもあります。
AIはコードを書くのが得意ですが、「どこを調べるべきか」の当たりをつけるのはエンジニア自身の仕事です。問題の目星を自力でつけられるかどうかで、解決までの時間がまったく変わってきます。
【設計の判断を求められたとき】
新機能の実装方針を決める場面、技術選定の議論、コードレビュー(コードの確認・評価)でのフィードバック——こういった場面では、「なぜそうするのか」を言語化できる力が必要です。
AIは選択肢を並べてくれますが、「自分たちのシステムの文脈ではこちらが適切だ」という判断は、コードベース(プロジェクト全体のコード)の構造やトレードオフへの理解があってはじめてできます。この判断を自分の言葉で説明できるエンジニアが、チームの中で少しずつ信頼を積み重ねていきます。
【新しい技術を評価するとき】
新しいフレームワークやサービスが登場したとき、「これは自分たちのプロジェクトに採用すべきか」を判断する機会があります。基礎技術の理解があると、ドキュメントを読みながら「内部でどんな仕組みが使われているか」を推測でき、採用した場合のリスクやコストを見積もる精度が上がります。
こういった評価・判断の場面に関われるエンジニアになれるかどうかも、地力の積み上げにかかっています。
【地力の差は、静かに開いていく】
AI任せになったエンジニアは、「ジュニアレベルの仕事を速くやる人」として認識されるようになります。実装はできるが、設計の判断を任せるには心許ない、難しい問題の解決は別の人に頼む必要がある、という状況です。一方、基礎を積み上げてきたエンジニアは、難しい問題が来るほど輝く存在になっていきます。
この格差が静かに怖いのは、差がついていることに自分では気づきにくい点です。AIのおかげで「なんとなく動くもの」は作れてしまうため、成長が止まっていることに気づかないまま時間が過ぎていく可能性があります。
AIと共に、基礎を積み上げる実践法
【「なぜ」を一回多く問いかける】
地力を育てる上で、一番手軽に始められる習慣があります。それは、AIが答えを出してくれたあとに「なぜその答えが正しいのか」を自分でも考えてみることです。
AIにエラーを解決してもらったなら、「なぜそのコードでエラーが起きたのか」を追いかける。AIが書いたコードをコミット(変更を保存すること)する前に、「この処理、データが増えたらどうなるか」を一度考えてみる。この「一回多く問いかける」習慣が、日々の開発の中で少しずつ地力を積み上げていきます。
【基礎技術の学習にもAIを活用する】
基礎技術を学ぶ場面でも、AIは強力な味方になります。「OSのプロセスとスレッドの違いを、身近な例えで説明して」「このアルゴリズムの計算量がO(log n)になる理由を教えて」といった使い方は、難解な概念の理解を大きく助けてくれます。
大切なのは、AIの説明を読んで「わかった気になる」で終わらないことです。「自分の言葉で説明できるか」「別の場面に応用できるか」を確認することで、表面的な理解が本物の地力に変わっていきます。
【何を積み上げるか】
「基礎技術を学ぶ」といっても、何から手をつければいいか迷う人も多いと思います。AI時代に特に効いてくると感じる領域は以下の通りです。
データ構造とアルゴリズム は、AIが生成するコードの計算量が適切かどうかを判断する基準になります。配列・ハッシュテーブル(キーと値の対応表)・木構造といったデータ構造の特性と、O記法(処理コストをデータ量との関係で表す記法)によるコスト感覚は、コードレビュー(コードの確認・評価)でも設計でも活きます。
OS・プロセス・メモリ の知識は、パフォーマンス問題のデバッグやDockerなどのコンテナ技術の理解に直結します。「なぜメモリが足りなくなるのか」「なぜ並行処理(複数の処理を同時に行うこと)で競合が起きるのか」がわかる土台になります。
ネットワーク は、Web開発をするうえで避けられない基礎です。HTTPSの仕組み、DNSの動作、TCPとUDPの違いを知っていると、通信まわりの問題を自力でデバッグできるようになります。
セキュリティの基礎 は、AIがコードを書くようになったからこそより重要です。AIは「動くコード」を出してくれますが、脆弱性を常に排除してくれるとは限りません。攻撃のパターンを構造的に理解しているエンジニアだけが、AIの出力を安全に使えます。
【焦らず、着実に】
基礎技術は、1週間で身につくものではありません。日々の開発の中で「なぜこうなるんだろう」と立ち止まり、少しずつ理解を深めていくものです。すぐに成果が見えなくても、この積み重ねが2〜3年後に「難しい問題を任される人」になれるかどうかを静かに決めていきます。
まとめ
AI活用と基礎技術の学習は対立するものではなく、両方を実践することで「生成AIに負けない地力」が養われます。AIを便利な道具として賢く使いながら、基礎を積み上げ続けるエンジニアが、これからの時代に本当の意味で強くなれると感じています。