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

公開: 2026/09/21

更新: 2026/10/23

開閉

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

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

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

私自身、Web業界に身を置いて20年ほど経ちますが、会社支給のMacBook Proや自宅のWindows環境（WSL2）を行き来しながら、日々の実務でGitHub CopilotやClaude等のAIツールをフル活用し、その恩恵を心から享受しています。しかし同時に、実務の最前線でAIとペアプログラミングを重ねれば重ねるほど、強く確信していることがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

たとえば、リバースプロキシとバックエンド間の通信が詰まった際、私はAIに原因を尋ねる前に、まず手元で以下のような計測コマンドを叩いて遅延レイヤーを切り分けます。

# DNS解決からTTFB（Time to First Byte）までの所要時間をレイヤー別に計測
curl -w "\n--- Timings ---\nDNS Lookup:    %{time_namelookup}s\nTCP Connect:   %{time_connect}s\nTLS Handshake: %{time_appconnect}s\nTTFB:          %{time_starttransfer}s\nTotal Time:    %{time_total}s\n" \
  -o /dev/null -s -v https://api.internal.local/healthz

--- Timings ---
DNS Lookup:    0.0021s
TCP Connect:   0.0054s
TLS Handshake: 0.0123s
TTFB:          5.2140s
Total Time:    5.2148s

この出力を見れば、「ネットワークやSSLハンドシェイクは数ミリ秒で完了しているが、TTFB（アプリケーションの応答開始）で5秒以上待たされている。つまりインフラの疎通ではなく、アプリのロック待ちやDBクエリのスタックが原因だ」と素早く見当がつきます。

また、OS差異もAIが見落としがちな典型的な地雷原です。会社支給のMacBook Pro（macOS / BSD系ツール群）で快適に動いていたAI生成のシェルスクリプトやファイル処理コードが、Linux（Debian/Alpineコンテナ）のCI環境や自宅のWindows（PowerShell / CRLF改行）環境に持っていった途端、改行コードの混入（\r: command not found）やパスセパレータの違い、sed の -i オプションの仕様差によって盛大にクラッシュすることがあります。

編集長

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

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

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

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

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

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

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

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

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

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

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

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

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

たとえば、外部APIからユーザー情報を同期する処理を依頼した際、AIは往々にして次のような「一見スマートで簡潔に見えるコード」を書いてきます。

// ❌ AIが提案しがちな「一見動くが本番で破綻するコード例」
async function syncAllUsers(userIds) {
  // 配列の全件に対して Promise.all で同時にリクエストを発行
  const results = await Promise.all(
    userIds.map(id => fetch(`https://api.example.com/users/${id}`).then(res => res.json()))
  );
  return results;
}

開発環境で10件程度のモックデータを流している間は、高速に動作してテストも緑色で通過します。しかし、現場のコードベースを知るエンジニアであれば、このコードを見た瞬間に複数の危険信号を察知します：

レートリミット超過とソケット枯渇: 対象ユーザーが数千人規模になった時、宛先サーバーへ一斉に同時接続を張り、429 Too Many Requestsやソケット枯渇を招く
全体道連れの例外処理: 1件でもネットワーク瞬断やパース失敗が起きると、Promise.all の言語仕様（MDN Web Docs: Promise.all）により全件の結果が失われて中断する
セキュリティと認可の考慮: OWASP Top 10 で指摘されるような、エンドポイントに対する認可制御や異常系データのサニタイズが考慮されていない

現場の実務であれば、同時実行数を制限するキュー（p-limit 等）を挟むか、指数バックオフを伴うリトライロジック、あるいは部分的な失敗を許容する Promise.allSettled を採用するのが定石です。

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

編集長

TIPS 現場でのマイルール

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

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

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

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

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

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

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

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

4. 不安がる時間があるなら、今日の手元のコードを愛でる

メディアの煽り文句に触れていると、つい「何か全く新しいスキルを身につけなければ生き残れないのではないか」と焦りを覚えるかもしれません。

しかし、私たちが腰を据えてやるべきことは、昔も今も驚くほど変わっていません。

言語の標準仕様や公式ドキュメントを丁寧に読むこと（AI時代のコンテンツ真正性についてはC2PAの仕組みと運用の壁でも触れたとおり、一次情報へのアクセスが最大の武器になります）
フレームワークのブラックボックスの中身（ソースコード）を時々覗いてみること
バグが出た時に、AIに答えを聞く前にまずログとスタックトレースを自分の目で追ってみること
チームのメンバーが読みやすく、半年後の自分が感謝するシンプルなコードを心がけること

AIという最高の相棒が隣にいてくれるおかげで、私たちは退屈なボイラープレートのタイピングから解放され、より本質的な「設計の美しさ」や「課題解決のロジック」に時間を使えるようになりました。

道具に振り回されることなく、エンジニア本来の「仕組みを紐解く面白さ」を、これからも楽しんでいきましょう。