AIコーディングで仕事は速くなった。なぜ疲れる？ エンジニアの燃え尽き症候群と役割の変化

Stack Overflowが2026年10月6日に公表した開発者調査には、169カ国から30,903人が
回答しました。AI利用に関する集計では、AIコーディング支援ツール・エージェントの
利用が66％。[1]

仕事への現状維持感の主な理由を尋ねた別の設問では、回答者8,312人のうち1,753人
（21.1％）が「燃え尽き・技術疲れ」を選びました。[2]

「仕事のやりがいのある部分をAIが自動化している」を選んだ人は822人（9.9％）です。

いずれもこの設問に答えた人の割合で、21.1％は燃え尽き症候群の診断率ではありません。
この集計から分かるのは、それぞれの回答を選んだ人数までです。

AIの利用が疲弊を引き起こしたかは、この数字からは判断できません。

WHOはバーンアウト（燃え尽き症候群）を、うまく対処できなかった慢性的な職場ストレスに
関連する職業上の現象と位置づけています。[3]

特徴は、消耗、仕事との心理的な距離や否定的な感情、職務上の効力感の低下です。
「新しい技術を追うのに疲れた」という実感から考え始める場合も、こうした疲れが
どのような仕事の条件で続いているかを見ると、困りごとを具体的にできます。

コードを書く時間が短くなると、開発全体も楽になりそうです。
ただ、実際の負担は、コードができたあとに何を確かめるか、誰が判断を担うか、
空いた時間を何に使うかでも変わります。

AIが数分でコードを出せば、実装に使う時間は短くなるかもしれません。
ところが、開発チームには、その差分が既存機能を壊さないか、例外時にどう動くか、
利用者の困りごとに応えているかを確かめる仕事が残ります。

たとえば、AIが返金処理の修正案を出したとします。

通常のテストは通っていても、通信が切れて同じ要求が再送されたとき、二重返金を防げる
でしょうか。

どんな例外を想定し、どこまで確かめれば利用者に届けられるか。その判断まで含めて、
変更にかかる時間を見ていきます。

開発者のNiklas Gruhnは、AIの出力を理解・検証せず、そのまま相手に取り次ぐ行為を
「ミート・プロキシ」という言葉で批判しました。[4]

「meat（肉＝人間）」＋「proxy（代理・中継）」の造語で、人間がAIの単なる
中継サーバーになっているという皮肉な意味が含まれています。

たとえば、レビューで設計の理由を聞かれ、その質問をAIに渡して、返ってきた説明を
そのまま送る場面です。

やり取りは進んでも、担当者が設計の根拠を理解し、採用するかを判断する機会は薄くなります。


既存の仕様や利用者の事情を踏まえて修正案を見極めるレビューには、開発者の経験が活きます。
理由を考えて判断できるか、次の人に回すところまでを任されているかで、仕事の手応えは
変わります。

午前中に一件の実装が終われば、午後には別の変更に着手できます。
チームの何人もが同じように進めると、レビューを待つ変更が一度に増えることがあります。

確認する側は案件ごとに仕様や経緯を読み直し、別の案件に移ったあと、指摘を反映した
修正箇所をもう一度見ます。一件あたりの実装時間と、チームで同時に進める案件数の
両方を見ておくと、誰に負担が集まったかが分かります。

ここから、働く本人の側にも問いが生まれます。たとえば、障害の原因を突き止め、
どう直すかを考え、利用者が再び使えるようになるところまで見届けることに、仕事の
手応えを感じてきた人がいるとします。

担当業務が「AIに指示を出して差分を回す」ことに偏ると、何を判断したか、
誰にどう役立ったか、その結果から何を学んだかが見えにくくなります。

「この仕事をする自分は、これから何を担うのだろう」。こうした職業人としての
自己像の揺らぎを、この記事では職業上のアイデンティティ・クライシスと呼びます。

仕事で自分の役割を捉え直すときも、人としての価値は仕事の処理量や職場での評価から
切り離して考えられます。

負担が減っても、判断する機会や、相手にどう届いたかを知る機会が戻るとは限りません。

逆に、手応えを感じる仕事でも、レビューが積み上がれば疲れます。二つの悩みを分けると、
負担を軽くすることと、役割を見直すことのどちらが必要かを考えやすくなります。

新しいAIツールが出ると「何ができるか」に目が向きます。
それだけでなく、働き方の変化を知るには、職場に入ったあと、時間の使い道や判断を担う人が
どう変わったかも見ておきたいところです。

例えば、AIで実装時間が短くなった二つの架空のチームを考えてみます。
一方は、空いた時間に次の案件を入れ、レビュー待ちの変更が増えました。
もう一方は、その時間を使ってサポート担当者に話を聞き、利用者が迷う箇所を
実装前に見直しました。
同じように実装が速くなっても、時間の使い道によって仕事の中身は変わります。

【見るところ】　　　　　【確かめる問い】
時間の使い方　　　　　　短縮できた時間は、次の案件、レビュー、
　　　　　　　　　　　　利用者との対話のどこに使われたか。
判断と責任　　　　　　　誰がAIの案の採用を決めるか。その人には確認する時間と
　　　　　　　　　　　　判断する権限があるか。
結果から学ぶ機会　　　　リリース後の問い合わせや利用者の反応は、
　　　　　　　　　　　　次の変更を考える人に届いているか。

ニュースや調査で気になる動きを見つけたら、最近の案件を一つ思い出し、
以前の進め方と比べてみます。

肩書が同じでも、毎日の仕事の中身は変わります。その変化を早めに知っておくと、
仕事の進め方が固まる前に、案件数や分担について相談したり、次に学ぶことを選んだりできます。

疲れが増えたら、直近の一件で実装・レビュー・手戻りにかかった時間を振り返ります。
確認が追いついていないなら、次の案件では並行する変更を一つ減らすか、レビューの時間
をあらかじめ確保できるか、チームで相談します。

仕事の手応えが薄れているなら、自分が決めることと、確かめたい反応を一つずつ選びます。

例えば、返金処理。
AIを使う次の開発案件で、着手前に三つだけ書いてみます。

・AIに何を任せるか
　　→修正案とテストケースの下書き
・自分は何を決めるか　
　　→同じ返金要求が再送されたときに、システムが返す結果
・誰のどんな反応を確かめるか
　　→サポート担当者に、処理済みか再試行が必要かを画面から判断できるか聞く

終わったら、返ってきた反応を一行だけ残します。
たとえば「処理済みかどうかは分かるが、顧客に何と説明すればよいか迷う」。
その一行が、次に何を直すかを考える材料になります。自分の裁量で変えられない場合は、
レビュー時間や利用者の声が届く経路について、チームで一つ相談するところから始められます。

AIで仕事が速くなったら、空いた時間が何に使われ、確認や判断を誰が担うようになったか
を見てみます。疲れが増えたなら、レビューや手戻りがどこに集まっているかを確かめ、
仕事の量や分担、休息を取れる条件をチームで見直します。

一方、AIの出力を理解・検証せずに取り次ぐだけの「ミート・プロキシ」のような役回りが
続くと、自分で判断し、その結果を知る機会が減ることがあります。

仕事は続いていても、「自分はこの仕事で何を担っているのだろう」と感じる。
そこに、職業上のアイデンティティ・クライシス、つまり職業人としての自分の
捉え方の揺らぎがあります。

そんなときは、これまで仕事のどんな場面に手応えを感じてきたかを振り返ってみてください。
不具合の原因を突き止める。
利用者の話を聞いて設計を見直す。
後輩が自分で判断できるよう、
考え方を伝える。

たとえばコードを書く時間が減っても、原因の仮説を立て、検証の順番を決めるところには、
関わり続けられるかもしれません。

働き方の変化を早めに見ておくと、何を学ぶか、どんな仕事に関わりたいか、
どんなペースなら続けられるかを考える余地が生まれます。
休む時間や、仕事の外で大切にしている人との時間も、その判断に含めていいのです。

次の仕事で、AIに何を任せますか。自分で考え、相手の反応まで確かめたいことは何ですか。

参考文献・出典
[1] Business Insider Japan（2026年11月4日）「エンジニアはAIのせいで燃え尽き、働く意欲を失い、アイデンティティ喪失の危機に直面している【3万人調査】」
AIコーディングによる働き方の変化と、エンジニアの疲弊や職業上のアイデンティティの揺らぎを取り上げた報道。
[2] Stack Overflow（2026年10月6日）『2026 Developer Survey』
調査の規模、AIコーディング支援ツールの利用状況、「燃え尽き・技術疲れ」および「仕事のやりがいのある部分をAIが自動化している」を選んだ割合の一次資料。 調査概要 ／ AI利用の集計 ／ 仕事に関する設問別集計
[3] 世界保健機関（WHO、2019年5月28日）“Burn-out an ‘occupational phenomenon’: International Classification of Diseases”
ICD-11におけるバーンアウトの位置づけと特徴を示した公式資料。
[4] Niklas Gruhn（2026年8月3日）“Don’t be a meat proxy”
AIの出力を理解・検証せずに取り次ぐ行為を「ミート・プロキシ」と表現した、ソフトウェア開発者本人の投稿。