AI時代だからこそ際立つ「泥臭い現場感覚」とエンジニアの普遍的な基礎力

2026/09/21

開閉

ここ1〜2年で、エンジニアの開発現場は目を見張るほどのスピードで様変わりしました。

エディタを開けば次の一行や関数全体が滑らかにサジェストされ、ターミナルで対話型AIツールを呼び出せば、面倒な正規表現やシェルスクリプトのワンライナー、果ては単体テストの雛形までほんの数秒で組み上がります。「コードを書く」という行為そのものにかかる時間は、体感として半分以下になったと感じている方も多いのではないでしょうか。

その一方で、SNSやメディアを見渡せば「もう人間がプログラミングを学ぶ意味はない」「数年以内にエンジニアは淘汰される」といった、極端で刺激的な言説が毎日のように流れてきます。

私自身、Web業界に身を置いて20年ほど経ちますが、現在のAI支援ツールを現場業務にフル活用し、その恩恵を心から享受しています。しかし同時に、実務の最前線でAIとペアプログラミングを重ねれば重ねるほど、強く確信していることがあります。

それは、「AIが進化すればするほど、現場の泥臭いエンジニアリング基礎力を持つ人の価値が何倍にも跳ね上がる」 という逆説的な現実です。

今回は、派手なバズワードから少し距離を置き、日々の泥臭い実装や障害対応と向き合ってきた現場の目線から、これからの時代に求められる「変わらない普遍的な力」について書いてみたいと思います。

1. AIがどうしても埋めてくれない「3つの領域」

AIは膨大な学習データを元に、統計的にもっともらしいコードを高速に紡ぎ出します。しかし、実務のプロダクト開発において「コードを書く」というのは、全体のパズルのほんの1ピースに過ぎません。

現場で実際に直面する課題のうち、AIにどれだけプロンプトを重ねても代替できない領域が明確に3つ存在します。

① 「何を作るべきか」の文脈とトレードオフの判断

ビジネスの要求は、いつだって曖昧で不完全です。「画面の表示をもっとサクサクにしてほしい」「外部連携のエラーをいい感じにハンドリングしてほしい」といった現場の要求に対して、AIは「言われた仕様通りのコード」を10パターン出すことはできます。

しかし、以下の判断を下せるのは現場の文脈を知る人間だけです：

「いまこのテーブル構造を変えると、深夜のバッチ処理と競合してロック多発の原因にならないか？」
「この機能を愚直に作り込むより、既存のSaaSのWebhookで迂回したほうが運用コストが1/5で済むのではないか？」
「チームの今の習熟度で、この新しい非同期ライブラリを採用して半年後に誰が保守できるのか？」

工学の本質は「トレードオフの選択」です。速度、メモリ、保守性、開発期間、チームスキル。どの天秤をどう傾けるかの意思決定は、コードの自動生成では決して肩代わりできません。

② 「動かない時」の境界線の切り分け力

AIが生成したコードは、一見すると非常に洗練されていて完璧に見えます。しかし、ローカルで動いていたものがCI環境でコケたり、ステージング環境で突如504 Gateway Timeoutを吐き出したりした時、AIに「動かないんだけど」と尋ねても、一般的なトラブルシューティング手順が返ってくるだけです。

このとき現場で本当に求められるのは、以下のような泥臭い切り分けの手順です：

ログのタイムスタンプを追い、どのレイヤー（ブラウザ、リバースプロキシ、アプリケーション、DB）で遅延が起きているかを特定する
curl やパケットキャプチャで、HTTPヘッダーやTLSハンドシェイクの挙動を確認する
Linuxカーネルのファイルディスクリプタ上限や、Dockerコンテナ内のリソース競合を疑う

編集長

CAUTION 生成コードの盲信に対する警戒感

「AIが書いたコードは『文法的に正しいが環境依存の地雷を踏んでいる』ケースが往々にしてあります。動かない時にOSやプロトコルの基本に立ち返って自力で原因を絞り込めるかどうかが、そのままエンジニアの地力になります」

基盤となるネットワークプロトコル（HTTP/TCP）、OSのプロセスモデル、データベースのトランザクション分離レベルといった基礎知識が頭に入っていなければ、AIが提示した誤った推論に振り回され、時間を浪費することになります。

③ 「引き算の美学」と長寿なコードの見極め

AIに機能追加を頼むと、放っておけばいくらでも冗長でリッチなコードを書いてくれます。新しいクラスを作り、デザインパターンを適用し、過剰な抽象化レイヤーを挟み込もうとします。

しかし、実務で数年生き続けるコードベースにおいて最も尊いのは、「あえて書かないこと（引き算）」 です。

「この要件なら、わざわざ新規テーブルを切らなくても、既存のカラムにステータスを1つ足すだけで十分ではないか」「標準ライブラリの関数1行で済む処理に、外部依存ライブラリを追加する必要はない」。そうしたシンプルな設計への愛着と規律は、数々のレガシーコードの負債に苦しんできた人間の現場感覚からしか生まれません。

2. 道具の主導権を握る：AIを「優秀な新人」として迎える

では、私たちは日々の開発でAIとどう向き合うべきでしょうか。

私が意識しているのは、「AIを全能の魔法使いではなく、極めてタイピングが速いが仕様を全く知らない新人エンジニア」 として扱うことです。

「レビューする側」の基礎知識が問われる

新人エンジニアが書いたPRをレビューする場面を想像してみてください。もしレビューする側のリードエンジニアが言語仕様やセキュリティ（SQLインジェクション、XSS、認可制御）を理解していなければ、そのPRが安全かどうか判断できるはずがありません。

AIツールを使う場合も全く同じです。プロンプトに凝る技術（プロンプトエンジニアリング）ももちろん役立ちますが、それ以上に重要なのは、「生成されたコードの違和感に一瞬で気づける審美眼」 です。

「このループ処理、データ量が1万件を超えたらN+1問題でDBが悲鳴を上げるな」
「例外を握りつぶしているから、本番で障害が起きた時に原因追究ができなくなるな」
「非同期処理のエラーハンドリングが抜けていて、プロミスが未解決のまま残りそうだな」

こうした違和感を察知できるかどうかは、プロンプトの巧拙ではなく、過去にどれだけ自分でコードを書き、バグに悩み、手を動かして失敗してきたかという経験の蓄積にかかっています。

編集長

TIPS 現場でのマイルール

「AIにコードを書かせたら、必ず手元で最小のユニットテストを書くか、ローカル環境で意図的に異常値を流して挙動を確認する癖をつけています。自分で納得していないコードは1行たりともコミットしない、という姿勢が一番の安全弁です」

3. 20年の技術変遷を振り返って思うこと

思えば、Webの業界に足を踏み入れてからの20年間、「エンジニアの仕事はなくなる」という言説は形を変えて何度も繰り返されてきました。

高級フレームワーク（Ruby on Rails等）が登場した時：「誰でも数コマンドでブログが作れるから、フルスタックエンジニア以外は不要になる」
AWSなどのクラウドが登場した時：「サーバーを自前で立てるインフラエンジニアは全員職を失う」
ノーコード・ローコードが台頭した時：「簡単な業務システム開発はすべて非エンジニアの内製で完結する」

しかし、実際に起きた現実はどうだったでしょうか。

抽象度が一段上がり、面倒な定型作業が自動化されるたびに、世の中からエンジニアの需要が消えることはありませんでした。むしろ**「手軽に作れるようになったからこそ、ソフトウェアが解決すべき領域が社会の隅々まで爆発的に広がった」** のです。

そして、システムの規模が大きくなり、外部システムと複雑に連携するようになれば、必ずどこかで「ブラックボックスの隙間」から予期せぬ不具合が噴き出します。その時に問題を解決できたのは、ツールの使い方を知っている人ではなく、「裏側で何が起きているか（プロトコル、メモリ、OS、アーキテクチャ）を理解している人」 でした。

AIも、これまでの技術進化の延長線上にある、極めて強力な「抽象化レイヤー」のひとつです。恐れる対象でも、盲信する対象でもなく、自分の思考と実装を何倍にもレバレッジしてくれる最高のテコに過ぎません。