はじめに
こんにちは！現役でITエンジニアやってるやむぅ。です。
ここ最近に限ったことじゃないですが、AIの変化・進化スピードえげつないですね。
特にエンジニア界隈ではClude Code、Codex、Copilot、Antigravity、Cursorでほぼブッチぎりです。
僕も日々Xなどで動向を追っていたところ、よく「エンジニアもういらなくね？」「非エンジニアでもアプリ作れたw」みたいなエンジニア不要論をよく見かけるんですが、僕目線「仕事で実用するレベルじゃなくね」「エンジニアの仕事ってそんな無責任じゃない」というように実務のエンジニアレベルを誤解してる雰囲気があったので、
今回は実際のエンジニアの仕事ってどんなことをしているのか、8年目エンジニアが解説していきます。
また、AIによって仕事が奪われるかどうかについてもお話ししていきます。
そもそも、エンジニアってコードを書く仕事？
まず、エンジニアの仕事についてざっくり解説します。
※本記事のエンジニアはシステムエンジニア（SE）およびWebエンジニアが該当します。
エンジニアの仕事を一言でいうと、「オールラウンダー」です。
実は、コードを書いてシステムやサイトを実装することだけが仕事ではないんです。
では、実際どんな仕事内容があるかというと大きく分けて
- 要件定義
- 設計
- 開発・実装
- テスト
があります。もっと深ぼると「ヒアリング / 企画・ビジネス要件 / リリース / 運用・保守...etc」といったようにたくさんあります。
また、よく言われているのが要件定義や設計といった決めるメインの工程を上流工程、開発・実装やテストといった作るメインの工程を下流工程と言ったりします。
このようにエンジニアの仕事には「コードを書く」以外にもたくさんの工程・タスクがあるのです。
AI代替度の評価軸を定義
さて、エンジニアの仕事内容を詳しく解説する前に今回僕が使ってく「AI代替度」を定義しておきます。
本記事では、各業務がどの程度AIに移行可能かを客観的に測るため、独自の「AI代替度スコア」を使っていきます。この評価軸は、あくまで僕が感じた・経験した「業務プロセスにおける人間の介在価値」を基準としています。
AI代替度の5段階評価（★1〜★5）
以下の5段階評価をベースに、各タスクの代替性を分類します。
| 評価 | ステータス | 定義と役割分担 |
|---|---|---|
| ⭐1 | 人間主体 | AIは補助にもなりにくい。現時点でほぼほぼ人間じゃないと物理的・倫理的に無理なもの。 |
| ⭐2 | 人間＋AI補助 | AIは情報整理や下書きなど断片的に利用。ただし、文脈の理解や意思決定は100%人間が行うべき。 |
| ⭐3 | 共創（ハーフ） | プロセスの半分程度をAIで進められる。人間は「プラン立て」と「最終調整・判断」を担う。 |
| ⭐4 | AI主導 | プロセスの大部分をAIが完遂できる。人間はチェックと微調整のみで運用可能。 |
| ⭐5 | フル自動 | ほぼ全てのプロセスをAIに任せて問題ないレベル。なんならスタートさせた後もAIが自律的に行動・改善させてもいいかも。 |
評価にあたっての前提条件
今回の評価ですが、以下の3点を重要な前提としています。
-
2026年5月時点での判定
Claude、Cursor、GPT-5など、現時点でTopの推論能力を持つAIツールをフル活用することを前提としています。 -
個人的見解と環境依存性
このスコアは僕個人の普段使用および実務現場での経験に基づく「感覚値」です。さらには「渡したデータはAI学習や漏洩などしない」ことを前提としてます。なので導入する組織のセキュリティポリシーや、使用者の習熟度、ナレッジ量によって変動するので「誰しも同じでしょ」とは限りません。 -
「代替できる」≠「責任不要」
これ僕一番大事だと思ってて、AIが★5の評価であっても、そのアウトプットによって生じる社会的・法的・道徳的な最終責任は常に人間が負うものだと考えます。AIはあくまでツール・手段であり、オーナーではありません。
本題入ります
それではエンジニアの仕事内容について細かく解説していきます。
今回は、
- ヒアリング
- 要件定義
- 設計
- 開発・実装
- テスト
- リリース・デプロイ
- 運用・保守
についてそれぞれ経験したことを踏まえて解説していきます。
ヒアリング
エンジニアの仕事において、最初の一歩となるのがこの「最上流」の工程です。ここではまだプログラムのコードは1行も書きません。クライアント(システム作りたい人)や社内の事業部門とかが抱えている「解決したい課題」を掘り起こして、それをITでどう解決するか、そもそも作る価値があるのかを議論・聞き出すといった初手フェーズです。
1. ステークホルダーヒアリング
AI代替度：★☆☆☆☆
【タスク内容】
クライアントから、現状の不満や「実現したいこと」を聞き出します。単に相手が言ってたからメモして話合わせる、と大抵この後失敗します。重要なのは、相手が言葉にできていない「ほんとにしたいこと」や「イメージできてなかった本来の目的」を特定する作業です。
【AIとどう付き合うか】
ヒアリングの録音・文字起こし・要約に関しては、AIがほぼ完璧にこなせちゃうのでありがたい。でも、「相手がなぜその機能が欲しいと言ったのか？」という背景にある感情とか、言葉の裏にある「本当は予算を抑えたい」とかのニュアンスを読み取るのは、依然として人間じゃないとできないと思います。ここはコミュニケーションや感情、その場で変動する思想が大きいので、相手の表情を見ながら深掘り質問を投げ、さらに信頼関係を築いていくのはAIには任せられないなと思いました。逆にいえばここの力は、AI時代でも最も生き残っていけるスキルの一つだと思います。
2. 課題の言語化・要件の優先順位付け
AI代替度：★★★☆☆
【タスク内容】
ヒアリングで出た要望を整理して、解決すべき課題を言語化します。また、予算や納期は有限なので、「何をやって、何をやらないか」という優先順位（スコープ）を決定します。
【AIとどう付き合うか】
情報整理や情報の落とし込み、感情排除した客観的判断は人間よりAIが圧倒的に勝っています。なので僕的にはAI代替進みそうと感じるが一点懸念点があって、この部分実はかなり泥臭いというか感情論というかなんというか...。最終的な「優先順位の決定」には、組織内のパワーバランスとか別口の長期的な事業戦略とかが絡みます。「論理的にはBだが、大口顧客の要望だからAを優先する」みたいな判断が必要になることもあったり。なので星３つとします。
3. 概算スケジュール・工数見積もり
AI代替度：★★★★☆
【タスク内容】
このプロジェクトを実現するために「どれくらいの期間」と「何人のエンジニア」が必要かを概算します。この時点では詳細な設計がないので、よくあるのは過去の経験や既存プロジェクトをもとにした「アバウトだが外さないだろう」予測が求められます。
【AIとどう付き合うか】
過去の類似データをAIに読み込ませれば、統計的な予測値はすぐに出ます。なので後の懸念である、ソフトウェア開発には常にある「不確実性」をどうするか。「〜〜だから、バッファを2割多めに積んでおこう」とか「あの部署との調整には時間がかかるはずだ」とかは現状、勘頼りみたいなことがあるけどそれもAIが織り込んで判断・予測できることを期待して星４つです。
要件定義
ヒアリングで「なぜ作るのか（Whyの部分）」が固まったら、次に行うのが「要件定義」です。ここでは「具体的に何を、どこまで作るのか（Whatの部分）」を明確にします。
多くの人が「設計」と混同しがちですが、要件定義はあくまで「ビジネス上の要求をシステムの仕様に翻訳する」作業です。設計（どう作るか）に踏み込む一歩手前のフェーズと言えます。
※多くの炎上(うまくいかなかった)プロジェクトの原因の多くはここが粗いことがほとんどです。
1. 機能要件の定義
AI代替度：★★☆☆☆
【タスク内容】
「ユーザーがログインできる」「商品検索ができる」など、システムが備えるべき機能を一つひとつ書き出していきます。単なる箇条書きではなく、例外的な操作（エラー時の挙動など）も含めて網羅的に定義する必要があります。
【AIとどう付き合うか】
企画書をAIに読み込ませて「必要な機能をリストアップして」と指示すれば、8割方の機能一覧は一瞬で生成されます。残りの2割——例えば「特定条件下で発動するロジック」とか「ウチの業務フロー特有の例外処理」など、AIが想像しにくい仕様を見落とさないようにしたり、AI特有の「それっぽい回答」を見逃さずに微調整するのが人間の役割です。AIに下書きをさせ、人間が「抜け漏れ」を徹底的に叩くのが結局ベストです。
何度も言いますが、ここで抜け・漏れ・ミスがあれば全てがポシャるので絶対に人間が確認するようにしましょう。
2. 非機能要件の定義（性能・セキュリティなど）
AI代替度：★★☆☆☆
【タスク内容】
「何秒以内に画面が開くべきか」「何万人までの同時接続に耐えるか」「セキュリティ基準をどう満たすか」といった、機能以外の品質を定義します。
【AIとどう付き合うか】
AIは一般的なチェックリストを提示するのは得意なので、それと合わせて「この予算規模なら、ここまでの可用性は過剰ではないか？」「将来の拡張性をどこまで考慮しておくべきか？」といった、客観的判断をレポートしてもらうのがいいかなと感じました。最終的な、ビジネス上のトレードオフ判断は人間が行い、コストと安心感のバランスをどこで取るか、双方納得のいく着地点を専門家として「決める」のは結局人間なんじゃないかと。
3. 要件定義書の作成・構造化
AI代替度：★★★★☆
【タスク内容】
決まった内容を、開発メンバーやクライアントが後から見ても誰がみても齟齬がないよう、ドキュメントとしてまとめます。
【AIとどう付き合うか】
「綺麗に、構造的に書く」という作業は、AIが最も得意とする領域です。箇条書きのメモとかヒアリングの録音を放り込めば、ある程度プロフェッショナルな要件定義書の体裁に整えてくれます。そのためこういった資料作成系にて人間が時間をかけるべきタスクは「文章や体裁整えること」から、その「中身の整合性を確認すること」に完全シフトできるのでかなりの時短が可能になります。
ここからは、要件定義で決まった「何を作るか」を、具体的なコンピュータへの命令に落とし込んでいく「設計・実装・テスト」のフェーズを解説します。
設計
要件を具体的にどう実現するかを定義する工程です。基本的にこれをみて実装をしていきます。なので誰がみても同じような実装ができるレベルまで落とし込んだ設計が(基本的には)必要です。ちなみに設計工程をかなりざっくりコンフルに書いといたり、なんなら設計なしで実装進むところもあります。
1. システム構成・アーキテクチャ設計
AI代替度：★★★☆☆
【タスク内容】
プロジェクト初期にてどのクラウドサービスを使うか、サーバーの構成はどうするか、フロントエンドとバックエンドをどう繋ぐかといった「システムの骨組み」を決めます。
【AIとどう付き合うか】
「一般的なBtoCサービスの標準構成を提案して」とAIに頼めば、ベストプラクティス(っぽいの)を瞬時に出してくれます。ですが実際の現場では「既存のレガシーシステムとの兼ね合い」とかで「これが最適解！」が通用しない場面もあったりします。現状の条件をもとに複数の選択肢を出させて判断するのが良いかと思います。
2. DB設計（テーブル・リレーション）
AI代替度：★★★★☆
【タスク内容】
データを保存する「箱（テーブル）」と、それらの「繋がり（リレーション）」を設計します。データの整合性を保ちつつ、高速に検索や処理できる構造を目指します。
【AIとどう付き合うか】
ER図（設計図）のコード生成や、正規化といった定型的な作業において、AIは非常に強力な助っ人になります。要件で必要になったデータ群をAIに渡せば、それをもとに最適なDB構成を提案してくれます。ただし注意としては、3年後、5年後を見据えた柔軟性や正規化ができるような設計になっているかも織り込んで作ってもらいましょう。
3. API設計（インターフェース定義）
AI代替度：★★★★☆
【タスク内容】
画面（フロントエンド）とサーバー（バックエンド）の間で、どんなデータをやり取りするかを定義します。
【AIとどう付き合うか】
こちらも基本的にAI主体で可能です。したいこと、必要なデータ群、型定義や基本的なバリデーション（入力チェック）ルールの生成・網羅はAIが非常に得意です。
4. 画面設計・UI/UX設計
AI代替度：★★☆☆☆
【タスク内容】
ユーザーが直接触れる画面の構成や、遷移の流れを設計します。
【AIとどう付き合うか】
ワイヤーフレーム（画面のラフ案）をAIに複数パターン出させることで、アイデア出しの時間は大幅に短縮されました。しかし、AIが出すデザインは基本的に「それっぽいAIチック」なことが多いです。あくまで参考として捉え、プロのUIデザイナーと協力して設計していくのが現実的です。
実装
設計書をもとに、実際にプログラムを書いていく工程です。エンジニアの仕事として最もイメージされやすい部分ですが、実はAIによって最も劇的な変化が起きている領域でもあります。
1. 環境構築・初期セットアップ
AI代替度：★★★★★
【タスク内容】
開発を始めるための設定や、ライブラリのインストール、初期設定などを行います。
【AIとどう付き合うか】
初心者だとかつては数日かかることもあったセットアップですが、今は「こういう構成でDockerファイルを作って」とAIに指示すれば、一瞬で土台が出来上がります。定型的な作業であるため、AI代替度は極めて高いです。
2. フロントエンド・バックエンド実装
AI代替度：★★★★☆（フロント） / ★★★☆☆（バック）
【タスク内容】
画面の見た目や動き、サーバー側の処理ロジックをプログラミングします。
【AIとどう付き合うか】
CursorやClaude Codeなどのツールを使えば、自然言語(日本語でチャット)で指示するだけで、かなりの精度のコードが生成されます。特にフロントエンドはAIが非常に強いです。決められた要素とデザインを忠実に守ってコード生成してくれるので、爆速でUIを完成することができます。
一方で、バックエンドの複雑な業務ロジックは、人間が論理的な指示を細かく出す必要があります。「0から1をフルで書かせる」のではなく「AIが書いたものを読んで修正する」や「自分が書いたものをAIで最適化する」というスキルが重要になってきます。
3. 既存コードの読解・修正（リファクタリング）
AI代替度：★★★☆☆
【タスク内容】
既に実装されたコードを書き換えて、機能追加や改善を行います。
【AIとどう付き合うか】
「このコードは何をやっているの？」とAIに聞けばそこのニュアンスや流れは簡単に解説してくれます。ですが実は、コードは「最適に書ければOK」というわけではなく「読みやすいか」が重要になってきます。
なので、一部分だけラムダ式で省略マックスで短縮させたり、今回の改修対応箇所だけ既存と全く異なるやり方で書いたりすると全体の可読性が落ちてしまい、開発チームとしてはかえって悪影響を与えてしまいます。
かといって「じゃあ全部リファクタリングすればいいじゃん！」となるかもですが、
- 何十万行もあるコード全てを書き換えて
- かつ、現状うまくいってるシステムの機能全てを担保(ちゃんと問題ないよね)して
- かつ、書き換えて終わりではなく、チェックもする
というように、リファクタリングするにはコストがかかるんです。
なのでその結果、「なんか動くけどよくわからん」や「改善したいけど下手にさわれない」ような化石コード・実装がよくあります。
なので、ここに関しては人間の必要性は否めないのかなと思います。
テスト・品質保証
作ったシステムが正しく動くか、バグがないかを確認する工程です。
1. 単体テスト作成
AI代替度：★★★★★
【タスク内容】
プログラムの最小単位（関数など）が、意図通りに動くかをチェックするテストコードを書きます。
【AIとどう付き合うか】
単体テストで大事なのは網羅性です。そしてこのテストパターンの網羅は、AIの独壇場といってもいいぐらい大得意です。「このロジックに対するテストケースを全部出して」と指示すれば、人間が思いつかないようなエッジケース（特殊な条件下でのエラーなど）まで指摘してくれます。ギリ「テストパターン大丈夫だよね？」の確認で人間が入る余地あるかなってぐらい、ここはAI任せになりそうです。
2. 結合テスト・E2Eテスト
AI代替度：★★★★☆
【タスク内容】
複数の機能が連携して動くか、実際のユーザー操作を通して問題ないかを確認します。
【AIとどう付き合うか】
テストを自動化するスクリプト作成はAIで時短できます。さらに「どんなシナリオでテストすべきか」という設計もAIが洗い出すことができます。ここは単体テストとは異なり、複数の機能や処理が絡まり合っている分、想定されるシナリオが複雑かつ膨大なので人間的チェックも必要なのではないかと思います。
3. コードレビュー
AI代替度：★★★☆☆
【タスク内容】
他のエンジニアが書いたコードをチェックし、ミスがないか、もっと良い書き方がないかをアドバイスします。
【AIとどう付き合うか】
タイポ(誤字)や文法のミス、規則やセキュリティの脆弱性といった「機械的なチェック」は、AIの方が正確で速いです。しかし、「チームの設計方針に合っているか」「後から読む人が理解しやすいか」「そもそも本当に正しい(と思える)か」といった「意図」のレビューとなるとAIだけでは怪しいです。
もっといえばAIは「それっぽいこと」をいうので100%正しいことを言うわけではないです。
特にレビューは、自分のコードが正しいかを確認する場所だと僕は想定してます。指摘者(相手が人間でもAIでも)のレビューを鵜呑みにして即修正することが良いのではなく、
指摘受けても自分が書いたやつが正しいと思うのであれば、それを貫いて理由を説明する、逆に指摘を受けて、調べて納得したなら修正する。
というように自分のコードに責任を持てることが重要で、何でこう書いたかを説明できることが大事です。
なのでAIレビューを一次受けとし、人間が本質的な議論に集中するスタイルが主流になってくると僕は考えます。
さらにはこの先、AIが生成したコードを自分でレビューするという力は必須になってくるとも思います。
リリース・デプロイ
開発したシステムを、実際にユーザーが触れる「本番環境」に反映するフェーズです。一見すると「本番へ移行」ボタンを押すだけの作業っちゃそうなんですが、事故が許されないめちゃくちゃ緊張感のある工程とも言えます。
1. CI/CDパイプライン構築
AI代替度：★★★★☆
【タスク内容】
プログラムを自動でテストしてサーバーへ反映させる仕組みを作ります。
【AIとどう付き合うか】
GitHub Actionsなどの設定ファイルを書くのは、AIが非常に得意な領域です。やりたいことを伝えれば、公式Docsに則って標準的なテンプレートをすぐに生成してくれます。ただし、その組織固有のセキュリティルールとか複雑な承認フローを組み込んだりしたり、そもそもそのフローで問題ないかなどのチェックは人間が担当する必要があります。
2. 本番リリース作業
AI代替度：★★☆☆☆
【タスク内容】
新機能を本番環境に反映させ、正しく動いているかを確認します。万が一不具合があった場合は、即座に元の状態に戻す作業・判断も含まれます。
【AIとどう付き合うか】
手順の自動化はAIで作れますが、「今、この瞬間にリリースして本当に大丈夫か？」という最終的なゴーサインを出すのは人間の仕事です。リリース直後の違和感に気づいたり、最悪の事態を防ぐための「責任」を伴う判断は、AIには代替できません。
3. リリースノート作成
AI代替度：★★★★☆
【タスク内容】
今回の更新で何が変わったのかを、ユーザーや社内向けに分かりやすくまとめます。
【AIとどう付き合うか】
プログラムの差分（コードの変化）をAIに読み込ませれば、人間が書くよりも正確で分かりやすい要約が一瞬で出来上がります。
運用・保守
システムは「作って終わり」ではなく、リリース後に安定して動かし続けるため改善していくことをします。
1. 監視・アラート対応
AI代替度：★★★★☆
【タスク内容】
システムに異常がないか24時間監視し、エラーが発生した際に対応します。
【AIとどう付き合うか】
定型的なエラーへの一次対応はAIで自動化可能です。あとは、「このエラーは無視していいのか、それとも深夜でも人を叩き起こすべき緊急事態か」という優先順位の判断やサービスの重要度を学習させることでさらに精度をあげることができます。
2. 障害対応・原因調査
AI代替度：★★★☆☆
【タスク内容】
予期せぬトラブルが発生した際、どこに原因があるかを突き止め、修正します。
【AIとどう付き合うか】
エラーログをAIに解析させれば、原因の仮説を5秒で3つほど出してくれます。これめちゃくちゃ強いです。ですが自動で修正させるとなった場合は必ず人間が確認する必要があります。
3. ユーザー問い合わせの調査・ドキュメント更新
AI代替度：★★★★☆
【タスク内容】
ユーザーからの「動かない」という問い合わせに対し、ログを調べて回答したり、古くなったマニュアルを更新したりします。
【AIとどう付き合うか】
膨大なログからの特定ユーザーの挙動抽出や、最新の仕様に基づいたドキュメントの書き換えはAIが圧倒的に得意なので代替可能性はかなり高いです。
まとめ
ここまで見てきた通り、エンジニアの仕事は多岐にわたります。
- 「ものを作る作業（実装・テスト・ドキュメント化）」は、AI代替度が★3〜5と高く、AIに任せることで劇的に効率化できます。
- 「判断・調整・人と握る作業（要件定義・合意形成・意思決定）」は、AI代替度が★1〜2と低く、これからも人間に残り続けます。
8年やってきて感じるのは、エンジニアの仕事が消えるのではなく、「仕事の重心が移る」そんな感じがします。これからのエンジニアは「コードが書ける」ことを前提として、その一歩手前にある「課題を整理し、人と合意し、AIを使いこなして形にする」という総合力が求められるようになります。
あわせて読みたい記事
プログラミング・キャリア相談やってます
AI時代のキャリアについて、「結局何から勉強すればいいの？」と迷う方も多いはずです。
- エンジニア未経験の方：どうすればエンジニアになれるのか、AI時代でエンジニア目指す意味あるのか、今の学習方向が正しいか不安な方
- 現役エンジニアの方：これからのキャリアをどう伸ばすべきか、AIとどう向き合うべきか悩んでいる方
僕個人でも、こうした「AI時代に価値を残すエンジニア」になるための支援をしています。僕自身の8年の経験をベースに、フラットにお話を聞きます。
お問い合わせはX（@yamuu_desu_yo）のDM、またはこちらのフォームからお気軽にどうぞ！
個人的な観点でのエンジニアの仕事解説でしたが、なにか参考になるところがあれば嬉しいです！みなさんのエンジニア経験談とかイメージも教えてください！
まだ小さいですがXアカウント @yamuu_desu_yo で発信していますので、こちらもよければぜひ！