エンジニアの仕事はAIでなくなる？――職種ではなく「消える作業」から備える

丸一日かけていた収集、整形、グラフ化、テストが、数分で終わった。

画面を見ながら僕が怖くなったのは、AIがコードを書いたことではない。エンジニアの仕事がなくなる前に、仕事の中の「作業」が一つずつ安く、速くなっていく。その構造を、僕は翻訳業ですでに見ていたからだ。

この記事は、AIで仕事がなくなるかを予測する記事ではない。自分の作業を「AIへ渡す／AIと組む／自分が持つ」に分けるための記事だ。

読み終わったときに持ち帰るもの：

• 職種の存亡ではなく、作業単位で危険度を見る5つの軸

• 自分の仕事を分ける3つの箱

• 今週やる、たった1つの作業移行

エンジニアの仕事はAIでなくなるのか

先に答える。

安心も恐怖も売らない。この記事がやるのは、問いの単位を下げることだ。

❌ 「エンジニアという職業は残るか」
→ 答えが出るのは数年後。今週の行動が何も決まらない。

⭕ 「僕のこの作業は、単価と人数が変わるか」
→ 今日確認できる。今週から動ける。

「エンジニアはなくならないから大丈夫」も、「AIに全部奪われる」も、どちらも今週の行動に変換できないという点で同じだ。だから僕は、職種の話を作業の話に置き換える。

その置き換えを、僕は一度やらされた経験がある。翻訳業だ。

翻訳業では、職業より先に「発注の中身」が変わった

僕はかつて、業務の傍ら身につけた中国語で、副業として特許翻訳や訴訟文書の翻訳をしていた。当時の常識は「機械翻訳はプロの実務には使えない」だった。

2016年、ニューラルネットワーク版のGoogle翻訳（GNMT）が出てから、僕が受ける仕事の内容が変わっていった。ここから先は、業界統計ではなく、僕個人が受けた発注の話として読んでほしい。

僕の側で実際に起きたことは4つだ。

1. ゼロから訳す仕事が減り、機械翻訳の出力を検品する仕事が増えた

2. 求められる速度が上がった（1日1万字が限界だった作業量の感覚が、数万字規模の話になった）

3. 単価が下がった

4. 担当範囲が変わった（訳す人ではなく、品質を保証する人として扱われるようになった）

重要なのは、この間ずっと「翻訳者」という職業名は消えていないことだ。求人も検索結果も残っている。消えたのは職業ではなく、発注書の中身だった。

僕の周囲で残った人は、二方向に分かれたように見えた。片方はAI出力の検品を大量にこなす方向。もう片方は、原文の意図を汲んで構成ごと組み替える、編集やライティングに近い方向だ。

職業名が残っても、中身が同じとは限らない。これが僕が持ち帰った唯一の教訓だ。

危ないのは「コードを書く人」ではなく、切り分けられた作業

2025年の夏、僕はClaude Codeを初めて触った。

「Pythonで防災情報を収集・可視化するプログラムを作って」――このプロンプトから、APIでのデータ取得、整形、グラフ化、単体テストの生成までがほぼ自動で進んだ。僕の体感では、丸一日かけていた作業が数分で終わった。

このとき僕が思ったのは「エンジニアが消える」ではなく、「翻訳のときと同じ順番で来た」だった。まず作業が切り出され、次に発注の中身が変わる。

だから見るべきは、職種でも肩書きでもなく、自分の作業一つひとつだ。僕は次の5つの軸で見ている。

作業の危険度を見る5つの軸

① 入力

• 確認すること：仕様が明確な仕事か、それとも口頭の曖昧な依頼で回っている仕事か

• 指示が明確な仕事ほど、リスクが高い

② 文脈

• 確認すること：社内事情や利用者理解が必要な仕事か

• 文脈が不要な仕事ほど、AIの影響を受けやすい

③ 検証

• 確認すること：正解を自動的に確認できるタイプの仕事か

• 正解を機械的に確認できる仕事ほど、AIによる変化が起こりやすい

④ 失敗コスト

• 確認すること：間違えたとき、誰にどこまで影響するか

• 小さいほど、変わりやすい

⑤ 調整

• 確認すること：他部署や顧客との合意が必要か

• 不要なほど、変わりやすい

この軸で見ると、「AIにできる／できない」の二択が成立しないことが分かる。

例えば、僕の本業であるプログラマーには「テストを書く」という作業がある。これについて考えてみても、仕様が固まった内部処理のテストと、顧客の運用ルールが絡む例外処理のテストでは、5軸のスコアが全く違う。作業名では判定できないから、案件ごとに判定するしかない。

AI時代のエンジニアが生き残るための条件を一言でまとめるなら、スキル名を増やすことではなく、この5軸の判定を自分の手元でできるようにすることだと僕は考えている。

AIコーディングの現状は「速度」の話であって、「雇用」の証拠ではない

AIコーディングツールの生産性については、提供元による調査が公開されているたとえばGitHubの2026年3月の公式発表では、Copilotにコードの変更を依頼し、テストやコードの検査を実行させる機能が紹介されている。（GitHubの公式発表）

ただし、これはツールを売っている側自身の調査だ。そして仮に速度向上が事実でも、それはそのまま雇用が減る証拠にはならない。速く終わるようになった仕事は、減る場合も、量が増える場合も、別の人へ移る場合もある。

だから僕は、雇用の総量を予測するのをやめた。代わりに自分の作業の内訳を見ることにした。

僕の仕事を3つの箱へ分ける

やることは1つだ。この1週間にやった作業を、3つの箱へ入れる。

箱1：AIへ渡す

仕様が明確・自動検証できる・失敗コストが小さい作業。

• 定型テストの叩き台

• CRUDや管理画面の初期実装

• ドキュメントやコメントの下書き

• ログ整形などの使い捨てスクリプト

僕はここを迷わず渡す。渡した後にレビューする時間を確保することが条件だ。

箱2：AIと組む

下書きは任せられるが、判断に文脈が必要な作業。

• 既存コードのリファクタリング方針の比較

• 設計案を3つ出させて、制約に合うものを選ぶ

• エラー原因の仮説出し

出力を選ぶのは自分であって、AIではない。ここを混同すると、責任だけが自分に残る。

箱3：自分が持つ

曖昧な問題設定、責任、交渉、優先順位が中心の作業。

• 「使いやすくしてほしい」を実装可能な仕様へ落とす

• どの機能を捨てるかを関係者と決める

• 障害時に誰へ何を伝えるかを判断する

僕がユーザーの抽象的な要求（「売上を上げたい」）と、具体的なプログラム（変数・関数・テーブル定義）の間をつなぐ仕事に価値を感じているのは、この箱が一番厚いからだ。

箱は職種で決まらない。案件で変わる

注意点を1つだけ書く。

同じ作業でも、扱うデータと失敗コストで箱は移動する。個人情報を含むデータの整形は、処理内容が定型でも箱1には入らない。金額計算のロジックも同じだ。

「この職種は安全／危険」という固定的な診断にしないこと。これが、この分類を使うときの唯一のルールだ。

分類を「予定」に変える部分から、980円です。

ここまで読めば、自分の作業を3つの箱のどこに入れるかは、もう判断できる。

ただ、僕が翻訳業でつまずいたのは、この先だった。

変化の構造は分かっていた。分類もできていた。それなのに、「で、いつ、どれを移すのか」を決めなかった。決めないまま単価が下がり、気づいたときには、選ぶ側ではなくなっていた。

分かることと、決めることは別だ。

この先は、分類を「予定」に変える部分になる。

この先の有料パートで渡すもの

• 1週間の作業ログの記録フォーマット（7項目・コピーしてそのまま埋められる）

• 3つの箱の判定チェックリスト（どちらの箱か迷った作業を決める基準）

• 90日移行プラン（1〜30日／31〜60日／61〜90日に何をやるか）

• 学習の撤退基準（「今期は学ばない技術」を1つ決める3つの質問）

• 上司・顧客へ確認する一文（AI利用の責任を、自分だけで背負わないため）

この先で渡さないもの

• エンジニアの雇用がこの先どうなるかの予測

• どの言語・技術が生き残るかのランキング

• 「これをやれば安全」という保証

僕は未来を当てられない。渡せるのは、自分の1週間の作業を分類し終えて、90日後の判断日がカレンダーに入っている状態だけだ。

読むのに10分。埋め終わるまでも、たぶん30分もあれば十分だろう。