フロントエンドエンジニアはオワコンなのか｜消えるのは「手を動かすだけの工程」だと思う

最近、改めてコーディングの価値が、少し怖くなりました。

Claude CodeやCursorに実装を任せると、自分が何年もかけて速くしてきた作業が、目の前でどんどん進んでいく。

最近は精度も本当に上がって、「いよいよ、自分いらないんじゃないか」と手が止まる瞬間が何度もあります。

本記事でいう「フロントエンドエンジニア」は、主にHTML/CSS/JSの実装や、画面まわりのコーディングを中心に仕事をしてきた人を想定しています。

設計までガッツリやっている人より、まず「手を動かして形にする」ことで価値を出してきた人、と言ったほうが近いです。

「フロントエンドエンジニアオワコン」と調べているとき、本当に知りたいのは、職種の未来だけではないと思います。

たぶん、自分の1日の作業の中で、どこまでがAIに置き換わるのか。

そして、手を動かすこと以外に、自分の価値をどう広げればいいのか。

そこが、怖いんですよね。

私も同じ場所で一度立ち止まりました。

ただ、AIが速くなればなるほど、人間側に残る価値も、少しずつ見えてきました。

この記事では、その「残る価値」をどう見つけるかを、一緒に整理していきます。

読み終わるころには、自分の作業のどこがAIに置き換わって、どこに価値が残るのかを仕分けて、転職せずに担当範囲のまま「次に伸ばす一点」を、自分で決められるようになるはずです。

この記事でわかること

AIに実装を任せたら、自分より速い。フロントエンドエンジニアって、もうオワコン？
「コーディングしかできない」自分は、本当に危ないの？
実装の経験を活かして、次に何を伸ばせばいい？

フロントエンドエンジニアはオワコンなのか（結論：消えるのは職種でなく工程）
AIが行った方が良い工程 vs まだ人間が見るべき工程（実体験で分解）
「コーディングしかできない」が問題じゃない。その力を「手で打つこと」にしか使っていないのが危ない
実装経験を実装の外側に接続する（設計・UI・要件・AI指示・検証・発信）
最初の半歩は、これくらいでいい
それでも不安な人へ（設計できる／受託だから／誰でもできる）
まとめ：自分の工程を観測して、伸ばす一点を決める

フロントエンドエンジニアはオワコンなのか（結論：消えるのは職種でなく工程）

先に私なりの答えを書きます。

フロントエンドエンジニアは、オワコンではありません。

「フロントエンドエンジニアオワコン」という問いへの私の答えは、こうです。AIで消えていくのは、「コーダー」という職種そのものではなく、その仕事の中にある「手を動かすだけの工程」だと感じています。

実際、不安なのは私やあなただけではないようです。

ある調査では、エンジニアの66.2％がAIに仕事を奪われる不安を感じていると回答しています。

みんな、同じところで止まっている。

そして、この不安をもう少し近くで見ると、こういう感覚に行き着きます。

とりさん

結局、コーディングしかできない自分が危ない、ってことですよね…

そこ、私もずっと違和感があったんです。危ないのは『しかできない』ことより、コーディングを“手作業”のまま抱えていることなんじゃないか、と

「コーディングしかできない人は危ない」とよく言われます。

でも私は、その言い方に長く引っかかっていました。

危ないのは「しかできない」ことより、コーディングを手作業としてしか使っていないこと。

同じ実装でも、手作業のまま抱えている人と、その経験を別の価値に変えている人とでは、これから差が開いていきます。

では、その「手を動かすだけの工程」とは、具体的にどこを指すのか。

自分の作業を一度バラして見ていきます。

AIが行った方が良い工程 vs まだ人間が見るべき工程（実体験で分解）

コードを書く速さは、もうAIのほうが上です。

ここで張り合おうとすると、たぶんしんどいだけ。

私も最初は、無意識にそこで勝負しようとして、怖くなっていました。

でも、速さで張り合うのをやめて、自分の作業を工程ごとに並べてみると、見え方が変わりました。

「AIが行った方が良い工程」と「まだ人間が見るべき工程」に、わりとはっきり分かれていたんです。

仕様が決まった画面を作る
コンポーネントの雛形を作る
似た処理を量産する
エラー文から修正案を出す
既存コードに合わせて実装する

決まったものを手で形にする部分は、AIに任せていい。

ここを抱え込んで「自分のほうが速く書ける」と頑張っても、もうあまり意味はありません。

さっさと渡したほうが、時間が空きます。

一方で、AIが止まりやすい工程もあります。

そもそも何を作るか決める
どこから作るか決める
ユーザーが迷うポイントを見る
仕様の曖昧さに気づく
実装後に、実際の使われ方を観測する
AIの出力が良いか悪いかを判断する

決める。

気づく。

判断する。

ここは「何秒で書けるか」の勝負ではありません。

AIの速さとは、そもそも別の軸の仕事です。

つまり、消えていくのは「実装」という大きな塊まるごとではありません。

その中の「決まったものを手で形にする工程」のほうです。

明暗が分かれているのは、職種という単位より、もっと細かい工程という単位だった。

これは私の体感だけの話でもないようです。

米国ではプログラマーの雇用が減っている一方、設計や判断ができる人は残っている、という報告も出ています。

職種がまるごと消えるというより、職務の中身で差がつき始めている。

では、その「人間が見るべき工程」に自分の時間を移すというのは、具体的にどういうことか。私の経験で書きます。

「コーディングしかできない」が問題じゃない。その力を「手で打つこと」にしか使っていないのが危ない

私はWeb制作を17年ほどやってきました。

手で書く速さには、それなりに自信があった。

だからAIに速さを譲ったとき、正直、すこしぐらつきました。

「17年の自信は、何だったんだ」と。

でも、速さを手放したあとに、見えてきたものがあります。

17年で本当に効いていたのは、手を動かす速さじゃありませんでした。

何をどの順番で作るかを決める力です。

順番を外したときは、いくら実装が速くても、結局は作り直し。

速さだけでは取り戻せない時間を、何度も払ってきました。

とりさん

でも、それって“すごい人”だから言えるんじゃないですか？

いや、すごくはないです。速さはとっくにAIに譲ってます。降りたら、自分に残っている工程が見えただけなんです

「役割が変わるだけですよ」という安心オチの記事も読みました。

でも、自分の手応えとしては、いまいち腑に落ちなかった。

腑に落ちたのは、こう考えたときです。

問題は「コーディングしかできない」ことじゃない。

危ないのは、その「コードを書ける力」を、コードを手で打つことにしか使っていないことなんだ、と。

同じ力には、もうひとつの使い道があります。

書くためでなく、「このコードでいいか」を見抜いたり、何をどう作るかを決めたりする”目”として使う。

AIが「手で打つ」を肩代わりした今、打つことにしか使っていない人は丸ごと食われて、見抜く・決める側に使い直せる人は、逆に価値が上がります。

実装経験を実装の外側に接続する（設計・UI・要件・AI指示・検証・発信）

ここで多くの記事は「上流に行け」「フルスタックになれ」と言います。たしかに正しいのですが、いきなり転職や職種転換を求められても、現実的に動けないことが多いですよね。

私が言いたいのは、もっと手前の話です。実装経験を、実装の「外側」に半歩だけ染み出させる。それだけで、置き換えられる側からAIを使う側へ、ゆっくり回り始めます。

実装経験は、こんなところに接続できます。

このコードはあとで破綻しないか、AIの出力は良いか悪いか。

それを判断できるのは、実装で痛い目を見てきた人です。

ユーザーが迷う場所も、画面を作ってきた人ほど見える。

仕様の曖昧さに最初に気づくのも、AIに「何を、どの順番で作らせるか」を組み立てるのも、コードを書いてきた経験がそのまま効きます。

作ったものが実際どう使われたかを確かめたり、その判断を言葉にして外に出したり。

そういう「書く以外の使い道」が、ぜんぶ実装経験の延長線上にあります。

どれも、ゼロから新しいスキルを覚える話ではありません。

今ある実装経験を、別の角度から使い直すだけ。

私自身、実装の速さを半分AIに渡しても、AIでアプリを実際に作って世に出せています（Diff Pro Maxなど、小さいながらも課金が回っているものもあります）。

実装専任のままだったら、たぶんここまで来ていません。

実装の手を外側へ広げたから、「作って出す側」に半歩回れた。

これが、今の私の実感です。

ただ、「外側へ」と言われても、まだ少し抽象的かもしれません。

私が実際に踏んだ”最初の半歩”を書いていこうと思います。たいしたことのない、小さな一手です。

最初の半歩は、これくらいでいい

ここまで読んで、「言いたいことは分かった。

でも、今さら何から変えれば…」と止まっている人へ。

先に、一番伝えたいことを書きます。

実装経験は、捨てなくていいです。

むしろ、これからの土台になります。

そして、いきなり大きく変えなくていい。

最初の半歩は、拍子抜けするくらい小さくて大丈夫です。

私自身の最初の一手も、たいしたことではありませんでした。

以前は、頭の中である程度考えたら、そのまま手でコードを書き始めていました。

でもAIを使うようになってから、いきなり実装させる前に、こんなことを短く言葉にして、先にAIへ渡すようになりました。

この機能は、何のために作るのか
最初に作る画面はどれか
今回は、どこまでをMVPにするのか
後回しにしていい機能はどれか
このUIで、ユーザーが迷いそうな場所はどこか

たったこれだけです。

コードを書く前に、手を動かす作業から少しだけ離れて、「何を、どの順番で作るか」を先に見る。

それだけで、手は半分AIに任せても、「決める」工程が自分の中に残る感覚がありました。

転職も、新しいフレームワークの勉強も、していません。

いつもの案件の中で、ちょっとだけ”決める側”に立ってみる。

私にとっての「実装の外側に出た最初の半歩」は、それでした。

この半歩を踏むと、AIに実装を丸投げして終わり、にはなりません。

AIを使って作る側に、少しだけ回りやすくなります。

だから、もし今「全部やり直さなきゃ」と思っているなら、その必要はありません。

全部、捨てなくていい。実装経験は、まだまだ使える。まずは、この半歩でいい。

ちなみに、自分の作業のどこを半歩外に出せそうか、一度ちゃんと棚卸ししたくなったら、紙1枚に「AIに任せる工程／自分にしか出せない価値」を2列で書き出す、というやり方もあります。

ただ、それは”やりたくなってから”で十分です。

最初は、上の半歩のほうがずっと先。（この2列の棚卸しワークは、メルマガ登録の特典でも配っています）

とはいえ、ここまで読んでも「いや、自分の場合は別だ」と感じている人もいると思います。

次に、その引っかかりに答えます。

それでも不安な人へ（設計できる／受託だから／誰でもできる）

3つ、よく出てくる引っかかりに答えます。

「自分は設計もできるから、コーダーオワコン論は関係ない」

ここは少し厳しめに書きます。

設計が「できる」ことと、設計の判断を言語化・再現できることは、別物です。

判断が暗黙知のまま頭の中にあると、AIへの指示にも、改善提案にも変換できません。

結局、「手を動かすだけの設計者」になってしまう。

設計できるかどうかより、その判断を外に出せているかを観測したほうがいい。

「受託だから上流に行けない。半歩外へなんて無理」

これはよく分かります。

上流に転職しろ、という話ではありません。

いきなり要件定義を担当しなくていい。

転職しなくてもいい。

まずは、実装前に「ここ、仕様が曖昧かも」と1つ確認する。

AIで作業時間が短くなった分、UIの違和感を1つ見る。

実装後に「この画面、本当に使いやすいか」を1つ観測する。

それだけでも、手を動かすだけの工程から、半歩外に出られます。

職種を変えなくても、工程の使い方は変えられる。

「AIで誰でも作れるなら、結局自分はいらないのでは」

むしろ逆です。

誰でも生成できる時代こそ、生成されたコードの良し悪しを判断できる人、どの順番で何を作るか決められる人の価値が上がります。

AIで高度なコードを引き出せるのは、もともと良し悪しを判断できる人です。

「誰でも作れる」は、「判断できる人がいらない」を意味しません。

ついでに、もう1つ。

「役割が変わるだけ」という安心オチも、半分は正しい。

ただしそれは、自分の工程を観測して使い方を変えられる人の話です。

コーディングを手作業のまま抱えている人は、役割が変わるどころか、工程ごと食われていく。

安心オチの一歩手前で立ち止まって、自分がどちら側にいるかを観測したほうがいい。

その「どちら側か」を決めるのは、最後は自分の観測です。

締めに、その話を書きます。

まとめ：自分の工程を観測して、伸ばす一点を決める

ここまでの話を、もう一度だけ整理します。

フロントエンドエンジニアはオワコンなのか？
答えは、職種としてはオワコンではありません。
AIで価値が落ちるのは「コーダー」という職種そのものより、その中の「手を動かすだけの工程」です。
実装は「AIが行った方が良い工程」と「人間が見るべき工程（決める・気づく・判断する）」に分かれ、消えるのは前者だけ。
実装経験そのものは、設計・UI・要件・AI指示・検証・発信へ接続できる資産のまま残ります。

つまり、要点はこの4つです。