「AIに仕事を取られるエンジニア」と「AIで仕事を増やすエンジニア」の違い
1. 「AIに仕事を取られるエンジニア」の共通点
① 「実装だけ」に自分の価値を置いている
- 設計は人に任せる
- 要件を深く聞かない
- 言われた仕様を、言われた通りに実装するだけ
このスタイルだと、AIと真正面から殴り合うポジションになってしまいます。
- 単純なCRUD
- テンプレート的なAPI
- 既存実装の焼き直し
こういう仕事は、AI＋ちょっと経験のあるエンジニアで十分回せてしまうからです。
② 「AI＝便利な検索」くらいにしか使っていない
- エラーが出た時だけChatGPTを開く
- たまにコードを貼って「直して」とお願いする程度
- 普段の設計・議論・アイデア出しには使わない
このパターンだと、
**“Googleよりちょっと賢い何か”**としてしか見ていないので、
AIのポテンシャルの1割も引き出せていません。
③ アウトプットの質より「自力で書いたかどうか」を重視している
- 「AIに頼るのは邪道」
- 「全部自分で書けないとダメだ」
という価値観が強すぎると、
**“時間をかけてAIより遅く同じものを作る人”**になってしまいます。
大事なのは
「自力で全部やったか」
ではなく
「ユーザー・クライアントにとって価値があるアウトプットを出せたか」
の方です。
2. 「AIで仕事を増やすエンジニア」の共通点
① 自分の“頭を使う場所”を意識的に決めている
このタイプは、こんな感じで線引きしています。
- AIに任せるもの
- 雑なコード書き
- ボイラープレート
- ライブラリ比較のたたき台
- テストケースの候補出し
- ドキュメントのドラフト
- 自分で考えるもの
- そもそも何を作るべきか
- どこまでを自動化するか
- 仕様の落としどころ
- リスクや運用コスト
- チームやビジネスへの影響
つまり、“作業”をAIに渡して、“判断”に自分の時間を使うイメージです。
② 仕事の「前工程」と「後工程」にAIを使う
AIで仕事を増やしている人は、
コーディングの瞬間だけでなく、
- 仕様の整理
- 技術選定の候補出し
- リスク洗い出し
- 実装後のリファクタ案
- 振り返り資料の作成
など、タスクの最初と最後にもAIを使っています。
例）新しい機能を作るとき
- 要件整理
- 「この要件を満たすための実装パターンを3つ出して、それぞれメリット・デメリットを書いて」とAIに依頼
- 実装方針の比較・決定（ここは人間）
- 実装中
- 迷ったポイントだけピンポイントで相談
- 実装後
- 「このコードの改善できそうな点をレビューして」と投げる
- テストケースの抜け漏れを確認させる
こうすると、1つの機能あたりに回せる“検討の回数”が自然と増えます。
③ 「AIを使えるエンジニア」として見られるポジションを取りに行く
AIで仕事を増やす人は、
社内・クライアントからの見られ方を意識しています。
- 「この人はAIを使って、チーム全体の生産性を上げてくれる」
- 「この人に任せれば、AIをうまく絡めた提案が出てくる」
この印象がつくと、自然と
- 新しいプロジェクトの相談
- 難しめの案件の検討
- 業務改善・自動化の話
がその人のところに集まるようになります。
結果として、
**“AIがあるからこそ頼られる人”**になっていきます。
3. 一日の過ごし方で分かる「2タイプの差」
同じ8時間働いても、
AIに仕事を取られる人と、増やす人ではこう違います。
AIに仕事を取られるエンジニアの1日（イメージ）
- ひたすら言われた機能を実装
- 分からないところだけAIに質問
- 仕様や設計の議論にはあまり参加しない
- 日報には「実装しました」「修正しました」だけが並ぶ
AIで仕事を増やすエンジニアの1日（イメージ）
- 朝：AIに今日のタスク整理と優先度のたたき台を作らせる
- 仕様や設計の段階からAIに案を出させ、自分で選び・組み合わせる
- 実装中は、繰り返し作業やサンプルコード生成をAIに任せる
- 実装後はAIにレビューさせ、自分でもレビューし、改善提案をセットで出す
- 日報には「課題とその改善策」「次に試す仮説」などが残る
やっていることは“ほぼ同じ技術領域”でも、
AIの使い方で「見える価値」がまったく変わります。
4. 明日から変えられる「AIとの付き合い方」3ステップ
記事を読んで終わりだと意味がないので、
明日からできる具体的な3ステップだけ置いておきます。
ステップ① 「毎日AIに相談する“固定テーマ”を決める」
例えば：
- 「毎日、その日のタスクをAIに整理させる」
- 「毎日、書いたコードの一部をAIにレビューさせる」
- 「毎日、学んだことをAIに説明して要約してもらう」
など、**“必ずAIを通す行為”**を1つ決めてしまいます。
習慣化すると、AIとの距離が一気に縮まります。
ステップ② 「AIに任せるタスクの“黒歴史リスト”を作る」
自分の中で、
- もうAIに全部任せていい作業
- AIの提案をベースにすればいい作業
- 自分でやりたい・やるべき作業
この3つにざっくり分けてみてください。
例：
- ✅ AIに任せる
- バリデーションのテストケース案
- エラー文の改善
- 型定義のたたき台
- ✅ ベースだけAIにやらせる
- 設計書のひな形
- ライブラリ比較のまとめ
- SQLの初稿
- ✅ 自分でやる
- 要件の優先順位付け
- どの案で行くかの最終判断
- チームに説明する資料の“最終形”
これを決めておくだけで、
**「全部自分でやるか／全部AIに丸投げするか」**の極端な状態から抜けられます。
ステップ③ 「AIを使った成果物を、あえて見えるところに残す」
- 日報
- 社内チャット
- ドキュメント
- コードレビューコメント
こういった場所に、あえて
- 「AIに出させた3案のうち、これを採用しました」
- 「AIのレビューで指摘されたので修正しました」
といった形で書いておくと、
「この人、AIをうまく使ってるな」
と周りから認識されやすくなります。
結果的に、
“AIを使える人＝相談したい人” というポジションが取れます。
5. まとめ：「AIと競争するか」「AIを味方につけるか」
最後にもう一度、最初の問いに戻ります。
「AIに仕事を取られるエンジニア」と
「AIで仕事を増やすエンジニア」の違いはどこにあるのか？
一言でまとめると、こうなります。
- AIと同じ土俵（作業速度・量）で戦うと、負けるエンジニアが増える
- AIを前提に、「何を考えるか」「どこで価値を出すか」を変えると、仕事が増える
AIは、
エンジニアを消すために出てきた存在ではなく、
“同じ時間で、もっと多くの問いを試せるようにする道具” です。
- AIと競争するポジションに居続けるか
- AIを味方につけて、より上流・より広い領域に出ていくか
その選択が、数年後のキャリアを大きく分けていくはずです。
この記事が、
「AIどうしようかな…」と少し不安になっているエンジニアの方にとって、
ほんの少しでも次の一歩のヒントになれば嬉しいです。
