「AI がここまで実装できるなら、エンジニアの仕事はいつまで残るのか」。そんな不安が、頭をよぎったことはありませんか？
僕は現役のエンジニアですが、いまは実装の大部分を AI に任せています。自分でコードを書くことは少なくなり、代わりに何を作るか、どこを調べるか、どこを直すかを AI に指示する時間が増えました。
この働き方を続けていると、「エンジニアの仕事がなくなる」というより、その前に別の変化が起きているように感じます。
これまで職種を分けていた境界が、少しずつ薄くなっています。
この記事では、海外企業で起きている変化と、自分の現場で実際に起きていることを材料に、AI 時代にエンジニアの何が変わり、何が残るのか、そして今後どんな技能を伸ばすべきかを考えてみました。
世界のプロダクト開発チームで起きている変化
まず、海外のプロダクト開発チームで起きている変化を見てみます。
従来はエンジニア、プロダクトマネージャー、デザイナーのように職種ごとに役割を分けるのが一般的でしたが、AI の普及によって、その境界を見直す議論が出てきています。
| 会社 | 従来の役割 | AI 前提で示されている方向 |
|---|---|---|
| Anthropic | エンジニア / PM / デザイナーなど | Prototyper / Builder / Sweeper / Grower / Maintainer |
| Atlassian | PM / デザイナー / エンジニア | Product Engineer / Builder へ役割が拡張 |
| Microsoft | 人が主体となる仕事 | Author → Editor → Director → Orchestrator |
Anthropic の例は、Claude Code の責任者である Boris Cherny 氏の発言 によるものです
Cherny 氏は Claude Code チームを見ていると、エンジニアリング、プロダクト、デザインといった従来の役割が混ざり合い、Prototyper（試作する人）、Builder（作り込む人）、Sweeper（整理して磨く人）、Grower（伸ばす人）、Maintainer（保守する人）という5つの原型に分かれつつある、と述べています。
Anthropic が正式に職種をこの5つへ変更したわけではありません。ただ、エンジニアやデザイナーといった職種ではなく、「試作する」「育てる」「保守する」といった役割で人を捉えている点は興味深いです。
もともと Anthropic は、採用ページで「エンジニアはたくさん研究をするし、研究者はたくさんエンジニアリングをする」と説明している会社です。
もともと職種の境界が薄い組織で、AI によってその傾向がさらに強まっていると考えられます。
Atlassian でも近い議論があります。
Atlassianは自社ブログで、AI によってソフトウェアエンジニアが、与えられた仕様を実装するだけではなく、顧客の課題やプロダクトの成果まで見る Product Engineer に近づいていくと説明しています。
プロダクトマネージャー側も、仕様をまとめてエンジニアに渡すだけではなく、自分で試作して検証するところまで担当しやすくなっています。
Microsoft は、人と AI の協働の仕方を Author / Editor / Director / Orchestrator という4段階で説明しています。 (Microsoft Blog)
自分で作る Author、AI の出力を修正する Editor、方向を示して AI に任せる Director、複数の AI エージェントに仕事を割り振る Orchestrator、という考え方です。
会社ごとに表現は違いますが、共通しているのは、担当する技術ではなく、どこまでの成果に責任を持つかで役割を捉える方向に動いていることです。
こういう話は、数年遅れて日本にも来るものだと思っています。
ですが、僕の現場では、以前はエンジニアに実装を依頼していたプロダクトマネージャーが、AI を使って自分で機能を実装するようになりました。その結果、「決める人」と「作る人」を完全に分ける必要がなくなり、実装だけを担っていた人員が削減されました。
少なくとも僕の周りでは、AI は単に開発を速くするだけではなく、誰がどこまで仕事を担当するのかまで変わり始めています。
職種を区切っていたのは、何だったのか
従来の Web 開発では、作業内容と職種が強く結びついていました。
デザイナーは画面を設計し、フロントエンドエンジニアは画面を実装し、バックエンドエンジニアは API や DB を担当し、プロダクトマネージャーは要件を整理する。もちろん実際の現場はもっと複雑ですが、大きく分ければこうした分業です。
AI によって実装コストが下がると、この分け方が崩れ始めます。
たとえばフロントエンドエンジニアであっても、渡された画面をそのまま実装するだけではなく、画面の使いにくさを見つけ、ユーザーの行動を確認し、改善案を考える。AI を使って試作し、そのまま実装して、結果を計測するところまで担当できます。
ここまで一人で回せるなら、その人の役割を「フロントエンドを実装する人」だけで表すのは難しくなります。
「このユーザー体験を改善する人」の方が、実態に近くなります。
フロントエンドとバックエンドの境界も同じです。
AI の補助があれば、バックエンドを専門としていない人でも、必要な API やデータ処理まで実装しやすくなりました。
もちろん、バックエンドの知識まで不要になったわけではありません。認証や認可、トランザクション、DB 設計などを知らなければ、AI が出した実装が妥当なのか判断できません。
変わっているのは専門知識の価値ではなく、専門領域をまたいで手を動かすためのコストです。
以前より領域を越えやすくなったことで、「何を実装できるか」だけでは職種を分けにくくなっています。
役割を決めるものが、「どの技術を扱えるか」から「どの成果に責任を持つか」へ移りつつある、ということです。
直列のリレーと、一人で持つ課題
これまでのプロダクト開発では、プロダクトマネージャーが要件を整理し、デザイナーが画面を作り、フロントエンドエンジニアが実装し、バックエンドエンジニアが API を作り、QA がテストする、といった形で一つの仕事を順番に渡していくことが多くありました。
いわばバケツリレーです。
AI が各工程を補助できるようになると、このリレーの一部を一人で持てるようになります。
たとえば「オンボーディングを改善する」という課題なら、問題を見つけ、仮説を立て、画面を設計し、実装し、結果を計測してまた改善する。その途中にある作業の多くを AI に任せられます。
これまで別の担当者にお願いしていた作業を自分と AI で進められるなら、人から人への受け渡しは減ります。当然、仕事の進め方も変わります。
すべての専門職が一人に統合されるわけではありません。高度なデザインやセキュリティなど、深い専門知識が必要な領域は残ります。
ただ、自分の専門外についてもある程度理解し、必要なら AI の助けを借りながら成果まで進められる人ほど、担当できる範囲は広がっていきます。
評価されるポイントも変わります。
実装が速いかだけではなく、正しい問題を見つけられるか、適切な判断ができるか、AI の出力を評価できるか、実際にユーザーの問題を解決できたか。
こうした部分の比重が上がっていくと思います。
これから伸ばす技能
では、これからどんな技能を伸ばすべきなのか。
僕が特に重要だと思っているものを挙げます。
まず、全体像を図にするとこんなイメージです。
プロダクト設計力
「検索機能を追加して」と言われたとき、そのまま検索機能を作るのではなく、なぜ検索したいのかを考えられるかどうかです。
本当の問題は「欲しい情報が見つからないこと」かもしれません。それなら絞り込みを改善した方がいいかもしれないし、おすすめ表示を改善すれば検索そのものが不要になるかもしれません。
AI は、指定したものをものすごい速さで作れます。
だからこそ、「何を作るか」を間違えたときの無駄も大きくなります。
実装速度より前に、そもそも解くべき問題を正しく決められるかが重要になります。
UI/UX の設計と改善
ここでいう UI/UX は、単にきれいな画面を作ることではありません。
ユーザーがどこを見るのか、どこで迷うのか、何を押せばいいのか分かるか、必要な情報が必要なタイミングで出ているか。そうしたことを考えて、迷わず使える画面にしていく力です。
「もっとモダンなデザインにして」と頼めば、それらしい画面は AI でも作れます。
難しいのは、ユーザーが今何をしたいのか、なぜ迷ったのか、どの情報を先に見せるべきなのかを考えることです。
ビジュアルデザインだけでなく、インタラクションデザインや UX 設計の方が、より重要になると思っています。
違和感を見つける力
AI に画面を見せて「改善点を出して」と頼めば、いろいろな指摘を返してくれます。
それでも、普段プロダクトを触っている中で「なんか使いにくい」「この見せ方は分かりづらい」と気づくことには価値があります。
情報量が多すぎる、ボタンの印象が強すぎる、この説明は読まれなさそう、この導線は分かりづらい。あるいは、そもそもこの画面自体が必要なのか。
大切なのは、AI が問題候補を挙げられるかではなく、その中で何を本当の問題として扱うかです。
違和感の原因を考え、仮説を立て、改善して、結果を見る。この一連の流れまで持てる人は強いと思います。
問題を構造化する力
「ログインできないことがある」という報告を受けたときに、何から調べればいいのか。
トークン、Cookie、API 認証、トークンの更新処理、状態管理など、関係しそうな要素に分けて原因を絞っていきます。
優秀なエンジニアが AI を使うと強い理由は、プロンプトを書くのが上手いからというより、問題を適切な大きさに分けられるからだと思っています。
Microsoft の Author / Editor / Director / Orchestrator も、AI への任せ方が深くなっていく段階を表しています。
自分で書く Author、AI の出力を修正する Editor、方向を示して AI に任せる Director、複数の AI エージェントへ仕事を割り振る Orchestrator。
AI に任せる範囲が広くなるほど、「何を任せるか」「どこで分けるか」を考える力が必要になります。
技術設計を評価する力
技術設計も、AI に任せられる範囲がかなり広がっています。
クライアントとサーバーのどちらに処理を置くか、DB をどう設計するか、トランザクションが必要か、どこをキャッシュするか。こうした判断は、要件や現在の構成を伝えれば、AI でもかなり妥当な案を出せるようになりました。
特に、よくある Web アプリの設計には既存のパターンが多くあります。複数の選択肢を出し、それぞれのメリットやデメリットを比較するところまで含めて、AI に任せやすい領域だと思います。
一方で、設計の前提をどう置くかは別の話です。
この機能が今後どれくらい使われるのか、事業がどの方向へ伸びるのか、半年後にどんな要件が増えそうか、チームがどこまで複雑な構成を運用できるのか。こうした不確実な要素を踏まえて、「今はどこまで作り込むか」「どこは割り切るか」を決める必要があります。
AI は、要件や制約がある程度決まっていれば、それに合う設計方法を考えたり、複数の選択肢を比較したりすることにはかなり強くなっています。
これから人間側により残りやすいのは、そもそもどの前提で設計するのか、将来の変化をどこまで見込むのか、どこまで作り込んでどこを割り切るのか、といった判断だと思います。
今は AI の提案を評価するためにも設計の知識が役立ちます。
ただ、単に技術設計ができることを強みとする以上に、AIに委ねる部分と人間が判断すべき部分を明確に切り分ける姿勢が求められます。
ユーザーを理解する力
ユーザーを理解するには、定量的な分析と定性的な分析の両方が必要です。
アクセス数や離脱率、コンバージョン率などの数値から傾向を見るのが定量的な分析です。一方で、ユーザーインタビューや問い合わせの内容から、「なぜその操作をしたのか」「なぜ途中でやめたのか」を探るのが定性的な分析です。
数字として「何が起きているか」が分かっても、「なぜ起きたのか」までは分からないことがあります。
逆に、数人のユーザーから強い意見を聞いても、それがユーザー全体に当てはまるとは限りません。
そのため、数字から傾向を見つけつつ、実際のユーザーの声から理由を探る必要があります。
集計や分類、数値から傾向を見つける作業は AI にかなり任せられるようになると思います。
それでも、どの数字を見るべきか、どの声を重要だと考えるか、その結果を受けて何を変えるかを決めるには、ユーザーへの理解が必要です。
ユーザーを見て問題を見つけ、仮説を立て、UX を考え、実装し、計測して改善する。この一周を理解している人は、今後かなり強いと思っています。
AI を「使う」ではなく「働かせる」力
「Claude Code が使えます」というだけでは、この先ほとんど差がつかなくなると思います。
重要なのは、AI にどこまで仕事を渡し、自分はどこに時間を使うのかです。
僕自身、最近は「このコードを書いて」と細かく指示するより、「この問題を調べて、原因を特定して、修正して、テストまで確認して」と、まとまった仕事として渡すことが増えました。
その分、自分が見るのはコードそのものより、「この修正で本当に問題が解決しているか」「既存の仕様を壊していないか」「もっと単純な方法はないか」といった部分です。
Microsoft の 2026 年の Work Trend Index でも、AI を高度に使う人ほど、AI の答えをそのまま完成品として扱わず、自分の判断を加える傾向が示されています。 (Microsoft WorkLab)
AI に任せる範囲が広くなるほど、自分で手を動かす力より、仕事を渡して結果を判断する力の比重が上がっていきます。
センス
生成するコストが下がるほど、何を選ぶかが重要になります。
AI がデザイン案を6つ出したときに、どれが一番いいのか。それとも、2つの案を組み合わせた方がいいのか。
僕は 0→1 のデザインが得意ではないので、Claude に一つの案を作ってもらうより、複数の案を出してもらい、その中から良いものを選ぶやり方をよく使っています。
最初は「なんとなくこっちがいい」としか言えなくても、何度も比較していると、「こっちの方が何をすればいいか分かりやすい」「情報が詰まりすぎていない」「ユーザーが慣れ親しんだ見た目や動きになっている」と、少しずつ理由を説明できるようになります。
デザインだけではありません。
コードでも、「動いてはいるけど、この実装はなんとなく嫌だ」と感じることがあります。
そうした感覚も、過去に見てきた実装や失敗の積み重ねからできた判断基準の一つだと思います。
AI が作る側を担えるようになったからこそ、良し悪しを判断する基準を持っていることが重要になります。
どの技能から伸ばすか、S〜C で格付けする
ここまでの内容に、従来のエンジニアリング技能も加えて一枚の表にしてみます。
この表は「仕事として重要か」ではなく、これから Product Engineer として働くときに、どれだけ差別化につながるかを基準にしています。また、現在だけではなく、AI がさらに進化した場合にどの程度残りやすいかも少し加味しています。
| ランク | 技能 |
|---|---|
| S | プロダクト思考、UX 設計、問題発見と問題設定、判断力、AI オーケストレーション |
| A | UI デザイン、ユーザー理解、データ分析、言語化能力 |
| B | ソフトウェア設計、セキュリティ基礎、テスト設計、アクセシビリティ、DB や API の設計、デバッグ |
| C | 実装レベルのコードレビュー、特定フレームワーク固有 API の暗記 |
ソフトウェア設計を B にしているのは、重要度が低いからではありません。
今の開発ではかなり重要です。ただ、要件や制約がある程度決まっていれば、それに合う設計方法を考えたり、複数の選択肢を比較したりする部分は、今後さらに AI に任せやすくなると思っています。
一方で、どの前提で設計するのか、将来の変化をどこまで見込むのか、どこを割り切るのかといった判断には、人間側の比重がまだ大きく残ります。
セキュリティ基礎も同じです。認証・認可や代表的な脆弱性についての知識は、プロダクトを作る以上欠かせません。
一方で、脅威モデリングや認証基盤の設計など、セキュリティを専門領域として扱う場合は別です。そこまで行けば、一般的な Product Engineer が持つ基礎知識とは別の専門性になります。
コードレビューを C に置いているのは、命名や重複、典型的なバグ、単純な実装改善など、実装レベルのレビューを想定しているからです。この辺りはすでに AI がかなり得意です。
もちろん、「この設計でいいのか」「この仕様は本当に必要か」といった判断まで含めれば、それはコードレビューというより設計やプロダクトのレビューに近くなります。
この分類は、2026 年時点で僕が考えているものです。
AI にできることが増えれば、当然この順位も変わります。数年後に見返したら、B や C に落ちている技能もあると思います。
手を動かす技術から、判断する技術へ
コードを書く量が減っても、僕はエンジニアをやめたつもりはありません。
これまで身につけてきた技術の知識も、AI の出力を確認するときには今でも役立っています。
ただ、役割の中心は少しずつ変わっています。
自分で実装することより、何を作るのかを決めること。AI に任せられるところを見極めること。出てきたものが本当に良いのか判断すること。
冒頭の「AI がコードを書く時代に、エンジニアの何が残るのか」という問いに今の自分なりの答えを出すなら、こうなります。
消えていくのは、「コードを書く人」という職種の切り方です。
残るのは、問題を見つけて、どう解決するかを決め、成果につなげる仕事です。
コードを書くことは、そのための手段の一つです。そして、その手段の多くを AI に任せられるようになりました。
これから必要なのは、AI と同じ速さでコードを書くことではありません。
AI に何を任せて、自分は何を考えるのか。
その境界を見極めることだと思っています。