ソフトウェアエンジニア求人が前月比20%減ったのに、年間では11%増えた。その差分にいるのが「新しい開発者」だ

「AIに仕事を奪われる」。この言葉を聞くたび、私はちょっと笑ってしまう。

5年前、私はコードから完全に離れていた。カスタマーサクセスの仕事は充実していたし、キーボードを叩く日々に戻るつもりもなかった。心のどこかで「もう一度書きたい」と思いつつ、それは封印した感情だった。

2026年4月8日。CNN Businessがある記事を出した。

タイトルは “The demise of software engineering jobs has been greatly exaggerated”。日本語に訳すなら「ソフトウェアエンジニアの終焉は大げさに語られすぎている」だ。

（参照: CNN Business）

データの中に、自分が見えた気がした。

私は「エンジニアが消える」派でも「大丈夫」派でもない。実際にコードから離れ、AIで戻ってきた人間として言える。消える仕事と生まれる仕事がある。問題はどちら側に自分がいるかだ。

「20%減」と「11%増」はどちらも本当だ

まず「減っている」側のデータから確認しよう。

Zero To Mastery（ゼロ・トゥ・マスタリー）が毎月出している求人レポートがある。2026年3月版によると、ソフトウェアデベロッパーの求人は前月比で20%減少した。ソフトウェアエンジニアも15.6%の下落。2ヶ月連続の減少で、合計16,000件以上の求人プールが縮んでいる状況だ。

（参照: Zero To Mastery 3月レポート）

この数字だけ見れば「やっぱり終わりか」と感じる。SNSで流れる「エンジニア不要論」と重なって不安になる気持ちはよくわかる。

ところが、年間データを見ると景色が変わる。

Citadel Securities（シタデル・セキュリティーズ）がIndeed（インディード）のデータを分析した。結果はソフトウェアエンジニアの求人が年間で11%増加。全職種平均を上回るペースだ。

（参照: Yahoo Finance）

月次では減った。年次では増えている。矛盾しているように見えるこの2つのデータは、実はどちらも正しい。

ポイントは「何が減って、何が増えているか」の中身にある。ここを分解すると、AI時代の開発者キャリアの地図が見えてくる。

消えているのは「コードを書くだけ」の仕事

CNNの記事で、IBMの事例が紹介されていた。

開発者の仕事が大きく変わったという内容だ。かつてはルーチンのコーディング作業が中心だった。今は顧客と直接話して、AIで機能を設計する仕事に移行しているという。

これを読んで、私は膝を打った。「それ、CSの仕事そのものじゃないか」と。

CS（カスタマーサクセス）の現場では、顧客の声を聞いて何を作るべきかを判断する。仕様を整理して実装の優先順位を決める。技術チームへの橋渡しも担う。CS出身だからこそ断言できるのだが、この「何を作るか」の判断はコードを書く技術より難しい。正解が1つではないからだ。

実際、お客さんが「この機能がほしい」と言ったとき、本当に必要なのは別の機能だったというケースは山ほど経験してきた。表面的な要望の裏にある本質を見抜く力。それは何百行のコードより価値がある場面が多い。

Zero To Masteryのデータをもう少し細かく見てみよう。減っているのは「Software Developer」「Software Engineer」という汎用的なポジション。16,000件以上の求人プールは残っているものの、縮小傾向が続いている。

対照的に「AI/ML Engineer」や「Data Engineer」は横ばいか微増だった。「Cloud Engineer」も同様の傾向を示す。

つまりコードを書くこと自体の価値は下がっている。代わりに何のためにコードを書くかを設計する力が求められるようになった。

ここに私自身のストーリーが重なる。新卒のころ挫折した理由はまさにこれだった。周りのエンジニアはコードの品質が圧倒的に高く、同じ土俵では勝てなかった。

いまAIがコードの品質を底上げしてくれる時代が来た。差がつくのはコードの外側。「設計」と「判断」の領域になっている。かつての弱点が時代の変化で中和された感覚がある。

具体的に言うと、こんな場面だ。先月、社内の問い合わせデータを可視化するダッシュボードを作った。技術的にはReact（リアクト）とChart.js（チャートJS）の組み合わせで、コード自体はCursorが8割書いてくれた。私がやったのは「何を可視化するか」の設計と「CSチームが本当に見たい数字はどれか」の選定。この判断はAIにはできない。ユーザーの隣で何百回も会話してきた経験から出てくるものだからだ。

BLS予測「15%成長」の内訳に落とし穴がある

アメリカ労働統計局（BLS）のデータを確認しよう。

ソフトウェア開発者の雇用は2024年から2034年にかけて15%成長すると予測されている。全職種平均を大きく上回る数字だ。年間約12万9,200件の求人が見込まれる。

（参照: BLS Occupational Outlook）

ただし、この予測を「安心材料」として読むのは危ない。

15%成長の需要内訳を見ると、中心はAI、IoT（モノのインターネット）、ロボティクス、自動化アプリケーションの開発。「AIを使う側」の開発者が増える予測であって、「AIが代替できるコードを手で書く人」が増えるわけではない。

ここにゲンとしての実感がある。

先週、Cursor 3の全機能を試した記事を書いた。8つのエージェントを並列で走らせて、Design Modeでプロトタイプを生成する体験をした。

（参照: 前回記事「まだCursor 2で1人ずつ相談してるの？ Cursor 3の並列エージェント×Design Modeを全部試したら、開発が別ゲーになった」）

1人の開発者が、かつてのチーム5人分のアウトプットを出せる体感があった。

生産性が5倍になったとき何が起きるか。単純計算なら必要人数は5分の1になる。ところが実際には作れるものの幅が広がるから、新しいプロジェクトが生まれ、新しいポジションが作られる。

私自身、Cursor 3を使い始めてから「これ自動化できるかも」と思う業務が3つ増えた。社内の問い合わせ集計ダッシュボード、Slack通知の自動振り分け、週次レポートの自動生成。どれもCursor 3以前の自分なら手をつけなかった案件だ。

ツールの進化が新しい需要を生む。BLSの15%成長は、この「作れるものの拡張」を織り込んだ数字だ。問われているのは、あなたが「5倍の生産性を出す側」に回れるかどうか。

ハマりポイントを1つ共有しておく。Cursor 3の並列エージェント機能は便利だが、指示が曖昧だとエージェント同士が競合する。「ヘッダーを修正して」と「ナビのレイアウトを変えて」を同時に投げた。すると同じファイルを2つのエージェントが書き換えてコンフリクトした。指示の粒度を適切に分けるスキルが必要になる。これも「設計力」の一種だ。

Cursor ARR 20億ドルが証明する「ツール投資の本気度」

CursorのARR（年間経常収益）は2026年3月に20億ドルを突破した。

（参照: TechCrunch）

2025年1月時点で1億ドルだった数字が14ヶ月で20倍に膨れ上がった。SaaSの歴史を振り返ると、Slackが1億ドルARRに到達するまで約3年。Zoomは約4年かかった。Cursorは約2年で到達し、さらに12ヶ月で20倍に伸びている。

評価額はSeries D時点で293億ドル。さらに600億ドル規模の資金調達が交渉中との報道もある。

（参照: BusinessWire / Bloomberg）

この数字が意味するのは何か。「開発者がAIコーディングツールにお金を払っている」という明確な事実だ。企業も個人も、AIコーディングを標準装備として投資し始めた。

私がCursorを使い始めたとき、月額$20で凄腕エンジニアが自分に宿った感覚があった。あの数億規模のプロジェクトで出会った、到達できないレベルのエンジニアたちの技術。それがAIを通じて手の中にある。

ARR 20億ドルの背景には、世界中で同じ体験をしている開発者が何百万人もいる。「AIコーディングは一時的なブーム」という見方はもう通用しない。開発のインフラになったのだ。

この成長速度が物語る事実は1つ。AIコーディングが「あると便利」から「ないと仕事にならない」段階に入った。月額$20のツールが年間20億ドルの市場を作った。その重みを正面から受け止める必要がある。

「増える側」に入るためのセルフ診断5問

あなたが「増える側」にいるかどうか。5つの問いを用意した。

CNNでIntuit（イントゥイット）の採用担当が語った内容がある。Zero To Masteryの増減データと私自身の経験も組み合わせた。

1. AIコーディングツールを毎日使っているか？

CNNによると、Intuitは「AIと共に育った若手開発者」を積極採用している。ミドルキャリアの開発者より、AIネイティブの新人のほうが評価されるケースが出始めた。ツールに触っていない時点でこの流れから外れてしまう。Cursor、Claude Code、GitHub Copilot（ギットハブ・コパイロット）。どれでもいいから毎日触ることが第一歩になる。

2. 「何を作るか」を自分で決められるか？

コードの品質より、プロダクトの方向性を判断する力が問われる時代。CS出身の私にとっては唯一自信を持てるスキルだった。「ユーザーが何に困っているか」を聞き取り「だからこの機能を作る」と判断できるかどうか。AIが書いたコードをレビューするには、この判断基準が欠かせない。

ここで正直に言っておく。「何を作るか」を決める力は、ビジネス経験がなくても鍛えられる。自分が使っているアプリの「不便な点」を3つ書き出して、「どう改善するか」を言語化する練習から始めればいい。思考の筋肉は何度も動かすことで育つ。

3. 1つの言語に縛られていないか？

Zero To Masteryのデータで増えている職種の特徴がある。特定の言語ではなくシステム設計やデータパイプラインの知識が求められるポジションが多い点だ。Pythonが書けるだけでは足りない。アーキテクチャを理解してAIに適切な指示を出せるかが問われる。

4. AIが生成したコードを読めるか？

「動くけど、なぜ動くかわからない」。正直に言うとこれは私の弱点でもある。とはいえ完全に理解する必要はない。ポイントは「このコードが何をしているか」を把握し「セキュリティ的に大丈夫か」を判断できること。100%の理解より80%の判断力のほうが実践では役に立つ。

私の場合、Cursorで生成されたコードを必ずコメントで説明させるようにしている。「このコードの各行が何をしているか、日本語でコメントを付けて」と指示するだけで、学習と確認を同時にできる。

5. 「コードを書かない時間」に価値を生めるか？

IBMの事例が示すとおり、開発者が顧客と直接話す時間は増えている。コードを書く時間が減った分、設計・レビュー・顧客対話に時間を使える。この「コードを書かない時間」で成果を出せるかが分かれ目になる。

5問中3問以上に自信が持てるなら、あなたはすでに「増える側」にいると思う。2問以下でも悲観する必要はない。今日からAIコーディングツールを触り始めれば、1番と4番は1ヶ月で確実に伸ばせる。

私自身がそうだった。Cursorを初めて起動した日、何をすればいいかわからずに30分固まっていた。最初に作ったのは「今日のタスクをランダムに表示するWebページ」。たった20行のHTMLとJavaScript。それが動いた瞬間の感動は忘れられない。凄腕エンジニアが自分に宿った瞬間だった。

私が「増える側」に入れた理由は、挫折していたから

正直に書こう。5つの質問のうち、私が最初から強かったのは2番と5番だけだった。

「何を作るか」の判断力と「コードを書かない時間の価値」。これはCSの現場で何年も鍛えられたスキルだ。顧客の声を聞いて優先順位をつけ、技術チームに伝える。コードを書く代わりに、コードが解決すべき課題を定義する。そんな毎日を何年も過ごしてきた。

1番（AIツールの日常使い）はCursorを触り始めるまで完全にゼロだった。3番（言語の幅）もフロントとバックを広く浅く触った程度。4番（AIコードの読解力）に至っては、今でも正直あやしい場面がある。

それでも「増える側」に入れたのは、挫折していたからだ。

プロのエンジニアには敵わないと認めた日がある。あの日から「自分は何が得意で何が苦手か」を嫌というほど考えてきた。たどり着いたのが「ユーザーの気持ちがわかるエンジニア」というポジション。AI時代になって、このポジションの価値が跳ね上がった。

かつてコードの品質で負けた経験が、今はアドバンテージになっている。AIがコードを書いてくれるなら、コードの品質で競争する必要がない。代わりに「なぜこのコードが必要か」を判断する力で勝負できる。

挫折経験がある人にこそ伝えたい。あなたの「コードが書けなかった時間」は、AI時代のアドバンテージに変わる可能性がある。CSやマーケティングや営業の現場で積んだ経験は「何を作るべきか」の判断力そのものだ。

その判断力を持つ人間がAIコーディングツールを手にしたとき、「新しい開発者」になれる。求人データの「増える側」に入れるのはそういう人だと確信している。

日本の開発者に、この流れはいつ届くか

CNNの記事はアメリカ市場のデータがベースだ。日本の状況はどうか。

正直、日本の求人データで同じ精度の分析はまだ出ていない。ただ兆候はいくつもある。

Cursorの成長速度が示すとおり、日本でもAIコーディングツールの普及は着実に進んでいる。私の周りでは、CS出身の非エンジニアがCursorで社内ツールを作り始めた事例が3件ほどある。「プログラミング経験不問」の求人に「AI活用経験歓迎」が追加される動きも目にするようになった。

あるSaaS企業のCS部門では、問い合わせ分析ダッシュボードをCS担当者自身がCursorで構築したという話を聞いた。以前なら開発チームに依頼して3ヶ月待ちだった案件が2週間で完成。「開発者」の定義が変わる瞬間を、日本でも目撃し始めている。

BLSの15%成長予測はアメリカの数字だ。ソフトウェア開発のグローバル化を考えれば、日本も同じ方向に進むのは間違いない。遅れるとしても1〜2年の差だろう。

むしろ日本語でこの構造変化を解説している記事がほとんどないこと自体がチャンスだと感じる。「開発者キャリアの二極化」という概念を日本の文脈で語る発信者はまだ少ない。この記事を読んでいるあなたは、すでに情報感度が高い側にいるはずだ。

アメリカで起きていることは日本でも起きる。問題は「いつ」ではなく「そのとき自分はどちら側にいるか」だ。

準備は今日から始められる。必要なのは高価な教材でも長い学習期間でもない。CursorかClaude Codeをインストールしよう。自分の仕事で「面倒だな」と感じている作業を1つ自動化してみること。それが最初の一歩になる。

まとめ: 求人データの矛盾が教えてくれたこと

月次で20%減、年次で11%増。この矛盾の正体は「開発者の定義が変わっている」ことだった。

コードを書く人という旧来の定義では求人が減る。AIを使ってプロダクトを設計する人という新しい定義では求人が増える。BLSは向こう10年で15%の成長を見込んでいる。Cursorは14ヶ月でARR 20億ドルに到達した。

今回の記事で紹介したデータを整理しておこう。

• Zero To Mastery: 月次で-20%/-15.6%の下落。汎用ポジションの縮小
• Indeed/Citadel: 年次で+11%の成長。全職種平均を上回る
• BLS: 2034年まで15%成長予測。年間12万9,200件の需要
• Cursor ARR: 14ヶ月で1億→20億ドル。SaaS史上最速級
• 評価額: 293億ドル（Series D）→600億ドル交渉中

これらの数字が共通して指し示す方向は1つ。AIコーディングツールは「エンジニアを置き換える道具」ではない。「エンジニアの定義を書き換える道具」なのだ。

減る側にいるのは、手動のルーチンコーディングに依存する人。増える側にいるのは、AIを道具として使いこなし、設計と判断で価値を出せる人。その境界線は「コードの品質」ではなく「何を作るべきかの判断力」に引かれている。

私はかつてプロのエンジニアに敵わないと感じ、コードから離れた。AIが来て戻ってこれた。コードの品質で勝負する時代が終わり、「何を作るか」「誰のために作るか」で勝負する時代が始まっている。

5年前の私に伝えたい。「諦めなくてよかった。AIが来た。もう一回作れる」と。

この記事を読んでいるあなたにも同じ言葉を贈りたい。まだコードを書き始めていないなら、今日がスタートの日だ。Cursorをインストールして「とりあえず動くもん」を1つ作ってみてほしい。減る側にいるか増える側にいるかは、その1つ目で変わり始める。