「プログラマーは要らない」のか
SWE-Bench Verified で95%、SWE-Bench Pro で80%超えのスコアが報告される時代になり、「プログラマーは要らなくなる」という言説が一気に強まりました。米国在住エンジニアの中島聡氏も、「指示通りにコードを書く」工程の単独価値が下がり続けるという趣旨の論考を継続的に発信しており、現場の実感としても、以前は数日かかっていた実装が AI エージェントで数分〜数時間に短縮されるケースが増えています。本記事では、シリーズ①で示した「使う側／使われる側」の分断を踏まえ、エンジニアの仕事がどう変わるかを編集部の視点で具体的に整理します。言及する両氏の論考は要旨を参照する形で扱い、原文の文言ではありません。最新の論考は各氏の発信元で直接ご確認ください。
役割は3つに分かれていく
編集部の現場観察では、エンジニアの役割は今後3層に分かれていきます。(1) 設計を決める層：要件整理、アーキテクチャ判断、技術選定、運用設計。(2) AI を使い倒す実装層：プロンプト設計、エージェント運用、生成物の品質判定、自動修正の調整。(3) 公開情報通りの実装層：仕様書がほぼ完成している状態からの実装、定型的な CRUD、テンプレ的な画面実装。(3) のタスクは AI で代替されやすく単価が下がり、(1)(2) は AI の浸透とともに需要と単価が上がる、というのが現時点の編集部の見立てです。中島氏が論じる「コードを書く工程の単独価値が下がる」という指摘は、(3) の市場価格低下として現実化していると考えられます。
「コードを書く人」から「設計を決める人」へ
注目すべきは、(1) の設計層は「コードを書かない」のではなく、「コードを書ける上で設計を決める」点です。AI に投げる前段階で、何を作るか、なぜ作るか、どう作るかを決められなければ、生成された大量のコードを評価することができません。実装スキルを捨てるのではなく、その上に設計の判断軸を載せる必要があります。堀江貴文氏が一貫して論じてきた「行動量で差がつく」という主張は、エンジニア領域では「設計判断を下した回数で差がつく」と読み替えると分かりやすくなります（堀江氏の各種メルマガ・著書「ゼロ」等）。判断は数をこなさないと洗練されないため、AI で実装を加速し、その分だけ判断の回数を増やすのが現実的な解です。
AI を使い倒す実装層の具体像
(2) の AI を使い倒す層は、新しい職能として急速に立ち上がっています。具体的には次のような業務です。・自社のコードベースを学習させたカスタムエージェントの設計と運用・プロンプトとシステムプロンプトの設計、回帰テストの整備・生成コードの自動評価（eval）パイプラインの構築・複数モデル（Opus / GPT / Gemini など）を切替え可能にする抽象化・エージェントの暴走を検知するガードレール設計これらは「実装スキル」と「品質保証スキル」と「LLM の癖の理解」の3つを横断する職能で、現時点では明確な職種名がまだ定着していません。今のうちに経験を積むと、需給バランスから高単価のポジションを得やすい状況が続くと編集部は分析します。
20代・30代エンジニアの行動指針
編集部から、年代別の現実的な指針を提示します。20代：(3) の実装層に長く留まらないこと。AI コーディングツール（Claude Code, Cursor, Copilot 等）を毎日使い、生成物の評価と修正の判断を高速で繰り返して (2) に移行する。並行して、設計レビューの場に積極的に同席し (1) の判断軸を吸収する。30代：管理側に逃げるのではなく、(1) の設計を決める層に振り切る。「自分で書ける／読める」状態を維持しつつ、要件整理・技術選定・運用設計の判断回数を増やす。両氏の論考から共通して読み取れるのは、年齢ではなく「使う側に回る速度」で勝負がつくという主張です。次回（シリーズ③）では、AI 時代に価値が高まる5つのスキルを掘り下げます。
参考：中島聡氏「Life is Beautiful」および同氏のメルマガ／堀江貴文氏 各種メルマガおよび著書「ゼロ」「多動力」等。発言は要旨を参照し、原文の文言ではありません。
