生成AIは労働者やエンジニアの「燃え尽き」を起こす引き金になりうるのか？

本記事では、生成AIの導入が現場の開発者における「燃え尽き」に影響を与えているかを取り上げます。

生成AIツールは、私たちの働き方を大きく変えつつあります。多くの企業が「AIによって生産性が飛躍的に向上する」という期待のもと、積極的な投資を進めています。

しかし、実際の現場には複雑な状況もあります。確かにコード生成は速くなったかもしれないけれど、その検証やデバッグに時間がかかる。また、組織からは「AIを使ってもっと速く」というプレッシャーがかかる。こうした状況に、多くの開発者が疲弊しているかもしれません。

燃え尽きの影響とメカニズムについて調査をもとに実態を見ていきます。

背景

生成AIが、ソフトウェア開発の現場に急速に浸透しています。この変化は2022年後半から本格化しました。コードを書く、レビューする、保守するといった開発作業全般を変革し始めたのです。実際、2025年のStack Overflow（開発者向けの大規模Q&Aサイト）による調査では、開発者の84%が生成AIツールを使用しているか、使用する予定だと回答しています。

企業側もこの流れに乗り遅れまいと、大規模な投資を進めています。その背景にあるのは、「生産性が大幅に向上する」という魅力的な期待です。実際、いくつかの研究はこの期待を裏付けるような結果を報告しています。企業が積極的に投資したくなるのも無理はありません。

しかし、話はそう単純ではないようです。2025年のHarness社によるレポートでは、開発者の67%がAI生成コードのデバッグ（不具合の修正）により多くの時間を費やすようになり、68%がAIが作成したセキュリティ問題の修正により時間がかかるようになったと報告しています。

これらの相反するデータが示唆しているのは、生成AIによる効率化の効果が一様ではないということです。最初のコード生成は速くなるかもしれませんが、その後の検証や監視、修正作業に時間が取られ、結局は開発作業の負担が創造から検証へとシフトしているのかもしれません。

それでも組織は急速に生成AIを採用し続け、開発者への要求を高め、業務の自動化を加速させています。この流れは労働市場にも影響を及ぼしています。スタンフォード大学の報告によると、主に経験の浅い開発者が就く職種が、13～20%減少していると報告しています。こうした現象を背景に「人間のスキルは失われるのではないか」という不安も広がっています。

このような状況下で、懸念されるのが開発者の「燃え尽き」です。

開発者たちにはこれまでも時勢の流れによってたびたび燃え尽きが起きがちでした。生成AIもそうしたリスクを抱えているのでしょうか？

以下では生成AIの台頭による開発者たちへの心労的な影響について詳しく見ていきます。

生成AIがもたらす開発現場の光と影

生産性向上への期待

生成AIツールが開発現場に広がっているのは、実際に成果が出ているからです。

たとえばGitHub Copilotというツールを使うと、開発にかかる時間が半分以下になったという報告があります。他の研究でも、タスクの処理速度が20～50%ほど速くなったというデータが出ています。特に毎日のルーチン作業では、AIが大きく生産性を高めることが分かってきました。

こうした成果を受けて、人々は「AIをどう開発作業に組み込むべきか」を探っています。ソフトウェアの設計でAIがどう役立つか、要件定義からコード生成、品質チェック、保守まで、開発プロセス全体でAIをどう活用できるかといった検証が進んでいます。

また、人間側の要因も重要です。公平性や親しみやすさ、感情といった要素が、AIへの信頼を左右します。そしてその信頼が、実際にAIを使うかどうかを決めるのです。システムの性能だけでなく、チーム内の考え方の多様性なども、AI採用に影響することが分かってきました。

隠れたコスト

ただし、良い話ばかりではありません。

39,000人の開発者にヒアリングした調査では、AI採用が増えても生産性の伸びはわずかで、むしろソフトウェアの提供パフォーマンスが下がっていました。別の研究では、AIツールのせいで作業完了時間が19%も増えたという結果も出ています。

なぜでしょうか？

確かにAIはコードを素早く生成してくれますが、その後の検証、デバッグ、セキュリティチェックに時間がかかるのです。節約した時間が、別の作業で消えてしまうわけです。

さらに問題なのは、こうした状況にもかかわらず、多くの開発者が十分なトレーニングやサポートを受けていないことです。組織からは「AIを使え」「速く働け」というプレッシャーを受ける一方で、使いこなすための支援は足りない。このギャップが、開発者たちにストレスを生んでいます。

つまり、パフォーマンスの低下、組織からの圧力、作業負荷の増加、不十分なサポートが重なって、開発者は追い詰められているのです。こうした開発者の心の健康については、これまでほとんど研究されてきませんでした。

バーンアウトとは何か

そこで今回は「バーンアウト」に注目します。

バーンアウトとは、仕事のストレスが積み重なって起きる燃え尽き状態のことです。疲れ果てて何もやる気が起きない、仕事に冷めた態度を取るようになる、自分は役に立っていないと感じる、雇用の安定に不安を覚えるといった形で現れます。

バーンアウトを分析するために、「Job Demands-Resources（仕事の要求度・資源）」モデルという考え方を応用できます。

簡単に言うと、このモデルは次のように考えます。

仕事には「要求度」と「資源」の2つの側面があります。

要求度とは、作業負荷や圧力、不確実性など、エネルギーを消耗させるもののことです。一方、資源とは、自分で仕事をコントロールできる自由度や、学習の機会など、エネルギーを補充してくれるもののことです。

要求度が高すぎて資源が足りないと、人はバーンアウトしてしまいます。逆に資源が豊富にあれば、要求度が高くても乗り越えられます。このバランスが重要なのです。

このモデルは柔軟性が高く、ソフトウェア開発を含むさまざまな職場で使われてきました。生成AI導入という新しい状況でも、開発者が直面する要求と使える資源のバランスが、どうバーンアウトにつながるのかを理解するのに役立ちそうです。

（今回のテーマによらず、広く役立ちそうな考え方です）

燃え尽きが起こるメカニズムを考察する

「仕事の要求度」の影響

仕事の要求度とは、持続的な努力、疲労のような心理的・身体的コストのことです。これまでの研究から、仕事の要求度には大きく2つの要素があることが分かっています。

それは組織的圧力と作業負荷です。

組織的圧力とは、会社や上司からの期待やプレッシャーのことです。

生成AIの文脈で考えてみましょう。経営層がAI導入を指示したとします。でも組織の準備が整っていなければ、現場は効果的にAIを使えません。経営層の期待と現場の実態がズレていると、チームに構造的な負担がかかります。

また、AI導入によって「もっと速く仕事ができるはず」と見なされ、より多くのタスクを割り当てられたり、より速いペースで完了することを求められたりすることもあります。さらに、AI生成コードのデバッグや修正に追加の時間を費やさなければならず、結果として作業負荷が増えることもあります。

こうした組織的圧力と作業負荷の増加が、仕事のストレスを大きく高めることが知られています。そこで今回、次のような予測が立てられました。

「生成AIに関連する仕事の要求度は、開発者のバーンアウトと関連している」

これを仮説1とします。

「仕事の資源」の影響

次に「仕事の資源」について見てみましょう。

仕事の資源とは、仕事の目標達成を助けたり、要求度を減らしたり、個人の成長を促したりする要素のことでした。

これには大きく2つの要素があります。それが自律性と組織的サポートです。

自律性とは、どれだけ自分で判断して仕事を進められるかという自由度のことです。生成AIの文脈では、開発者がAIツールをいつ、どのように使うかを自分で決められる度合いを指します。自律性が高いと、変化する環境でも幸福度やモチベーション、パフォーマンスが向上することが、これまでの研究で繰り返し示されています。

組織的サポートとは、会社が提供する学習機会や支援のことです。たとえばAIツールの使い方を学ぶためのトレーニングやリソースを提供することで、開発者はAIの価値を最大化できます。

こうした自律性と組織的サポートは、仕事の要求度がもたらす悪影響を和らげ、バーンアウトを減らし、エンゲージメント（仕事への熱意）を高めることが、技術主導の職場環境における多くの研究で示されています。

なお、リーダーの立場においては特に「自律性」が負担を軽減しパフォーマンスを高める中心的な資源であることが強調されています。

そこで次のような予測が立てられます。

「生成AIに関連する仕事の資源は、開発者のバーンアウトと関連している」

これを仮説2とします。

「AIに対するポジティブさ」の影響

バーンアウトは、仕事のプレッシャーだけでなく、精神的ストレスや雇用の不安定さといった内的要因も含まれます。

生成AI導入の文脈では、こんな状況が考えられます。

日常的な開発タスクが自動化されるとか、経営陣が人員削減の可能性を示唆するといったことがあると、雇用の不安が高まってしまいます。さらに、AI採用に関するニュースが絶え間なく流れたり、AIの進化が目まぐるしく速かったりすることで、スキルが陳腐化するのではないかという恐れが生まれます。

ただし、バーンアウトは複雑な概念で、個人が新しい技術の進歩に意欲を持ち、ワクワクしているときは、状況が変わります。技術に対する好意（有用性や信頼など）は、ストレスを軽減し、ネガティブな結果を和らげることができます。

つまり、同じAI導入でも、それをポジティブに捉えているかネガティブに捉えているかで、影響が変わるということです。

そこで次のような予測が立てられます。

「AIに対する好意は、開発者のバーンアウトと関連している」

これを仮説3とします。

「開発者の特性」の影響

最後に重要なポイントがあります。仕事の要求度や資源へのアクセスは、組織内で均等に分配されているわけではありません。経験年数、役職、組織の規模といった要因によって、状況は大きく異なります。

たとえば、ベテラン開発者と新人開発者では、同じAI導入でも受ける影響が違うかもしれません。大企業と小規模企業でも、提供される資源が異なるでしょう。

そこで次のような予測が立てられました。

「開発者の特性は、バーンアウト、組織的圧力、作業負荷、自律性、学習資源と関係している」

これを仮説4とします。

調査の実施

以上の仮説を検証するため、実際のソフトウェア開発者を対象とした調査が実施されました。

調査は、参加者の基本情報（性別、役割、経験年数、組織規模など）に始まり、組織的圧力や作業負荷といった「仕事の要求度」、自律性や学習資源といった「仕事の資源」、そしてバーンアウトの程度について尋ねる内容でした。各質問は5段階評価で、調査の完了には5～8分かかる設計でした。

参加者は、マイクロソフト、グーグル、ネットフリックスといった大手企業から、KubernetesやHugging Faceのようなオープンソースプロジェクトまで、56のコミュニティから募集されました。ソフトウェア開発には、従来のエンジニアだけでなく、データサイエンティストやAI開発者も含まれるため、意図的に幅広い募集が行われました。

2週間の公開期間で688件の回答が集まり、無効な回答を除いた442人が最終的なデータセットとなりました。

参加者の内訳を見ると、最も多かったのはフルスタック開発（画面からサーバーまで幅広く担当する開発者）で160人（36.2%）でした。性別は男性が398人（90.05%）、ジェンダーマイノリティが44人（9.95%）、組織規模は半数以上（56.79%）が大規模または超大規模企業、業界経験は大多数（360人）が6年以上でした。以下に統計を示します。

生成AI導入とバーンアウト（燃え尽き）の関係を探る

442人の開発者から集めた調査データをもとに、仮説を検証する分析が行われました。

分析の方法

PLS-SEMという統計手法が分析に使われました。複数の要因がどのように関連し合っているかを同時に分析できる手法です。
たとえば「組織的圧力と作業負荷がバーンアウトにどう影響するか」「自律性と学習資源がその影響をどう和らげるか」を一度に分析できます。

統計分析に加えて、221人の参加者が自由記述で寄せた意見も分析されました。それぞれの意見は、「組織的圧力」「作業負荷」「自律性」「学習資源」「AI認識」といった要素に分類されました。

分析結果

まず仮説1「生成AIに関連する仕事の要求度は、開発者のバーンアウトと関連している」について。

分析の結果、たしかに仕事の要求度（組織的圧力と作業負荷）がバーンアウトと正の関連を示しました。つまり、AI導入に伴う圧力や作業負荷が高いほど、バーンアウトも高いということです。「作業負荷」の影響がとくに強いことが分かりました。

仮説2「生成AIに関連する仕事の資源は、開発者のバーンアウトと関連している」について。

仕事の資源（自律性と学習資源）がバーンアウトと負の関連を示しました。これはつまり、どういうことか。
AIツールを使う自由度が高かったり、学習機会が豊富だったりすると、バーンアウトが低いということです。「自律性」の効果がとくに大きいことが分かりました。

仮説3「AIに対する好意は、開発者のバーンアウトと関連している」について。

AIに対する好意的な認識がバーンアウトと負の関連を示しました。つまり、AIをポジティブに捉えている人ほど、バーンアウトが低いということです。

これら3つの要因（仕事の要求度、仕事の資源、AI認識）でバーンアウトの約40%を説明できることが分かりました。

開発者の生の声から見える現実

また、統計では見えない具体的な状況が、自由記述のコメントから浮かび上がってきました。

組織的圧力に関連する声

多くの開発者が経営層主導の無理な導入を指摘しています。

「AIは過度に宣伝されている」という声や、「経営幹部が旗を振っている」という指摘がありました。

印象的だったのは「必要なくても、経営陣に報告する指標のためだけにAI使用を強制されている」という声です。

（もちろん、現場主導で生成AIの導入が進んでいる会社も多いため、これはあくまで一例です）

ある参加者は核心を突いてこう述べています。「ツール自体は問題ない。問題は、それがリーダーに与えた影響だ。リーダーが持っている過度な期待は本当にひどい」。つまり、AI自体よりも、AIをめぐる組織の圧力が問題だというのです。

作業負荷に関する声

AIがむしろ過度な負担を生んでいる側面も見えてきます。

ある参加者は車に例えてこう説明しました。「私の車の推奨最適速度は時速65マイル（約105キロ）です。エンジンの寿命を考えた最適速度です。でも今、みんなが新しい燃料添加剤を使って、楽々と時速100マイル（約160キロ）で走っているようです。私の脳も、本来の最適速度である時速60マイルではなく、時速100マイルで動いている気がします」。この比喩は、AIによって仕事のペースが持続不可能なレベルまで加速していることを鮮やかに表現しています。

さらに、AIが生成したコードの品質問題も指摘されています。「AIツールの後始末に、ゼロからコードを書くよりも多くの時間がかかる」「微妙なバグを追跡するのに時間を無駄にした」という声です。コード生成は速いかもしれませんが、その検証と修正に結局時間を取られてしまうのです。

自律性に関する声

状況が大きく二分されていることが分かりました。

開発者に選択の自由がある環境では「使用は必須ではない。仕事の要件や必要な成果物は変わっていない」「AI登場以前の行動を続けることができ、有益だと思う場面でAIを使うことができる」という声です。

しかし、対照的な環境も存在します。「経営陣に報告する指標のために、AIの使用を強制されている」という声がそれです。こうした強制的な導入は、非効率なワークフローを生み出します。「コード注入のたびにミニレビューが必要で、思考の流れが途切れる」といった不満が寄せられました。

学習資源に関する声

サポートの不足が繰り返し指摘されています。

ある参加者はこう警告しています。「AIの出力を盲目的に信頼すると、より多くの問題が生じる。スタッフが検証なしにAI出力を使う習慣がつかないよう、トレーニングが必要だ」。

そして実際、トレーニングが不足しています。「生産性向上のためにAIを使えという広範な声明はあるが、使い方のトレーニングは一度も提供されていない」という声が象徴的です。

別の参加者はこう指摘します。「AIは魔法の解決策ではない。LLMを使用する際には幻覚にLLMをコントロールする必要があるし、例を与えてやらなければいけない」

AIへの認識に関する声

ネガティブな意見として目立ったのは「私は、LLMベースのツールはこれまでのところマイナスだと思う。微妙なバグを追跡するのに時間を無駄にした」という声や、「これらのツールが本当に役立つ時期までの谷間にいるような気がする」という声です。期待と現実のギャップが、フラストレーションを生んでいます。

一方、AIをポジティブに捉えている人は、ストレスを感じていません。「私は概ねポジティブだ。エージェントシステム（主にCursorを使用）により、退屈なタスクを任せて研究を加速できる」という声がありました。

つまり、AI導入の影響が一様ではないということです。同じツールを使っていても、組織のサポート、自律性の有無、個人の認識によって、経験が大きく異なっています。

開発者の特性による違い

AI導入の影響は、すべての開発者に同じように現れるわけではありません。経験年数、役割、組織の規模によって状況が異なる可能性があります。以下は仮説4「開発者の特性は、バーンアウト、組織的圧力、作業負荷、自律性、学習資源と関係している」の検証結果です。

分析の方法

回帰分析という統計手法が使われました。ある要因が別の要因にどう影響するかを調べる手法です。開発者の役割、組織規模、経験年数が、5つの要素（組織的圧力、作業負荷、自律性、学習資源、バーンアウト）にどう影響するかが分析されました。

各要素への影響

バーンアウト

開発者の特性とバーンアウトの間には関係が見られませんでした。つまり、バーンアウトは特定の役割や組織、経験レベルに限らず、広く経験される現象だということです。

組織的圧力

コーディング中心の役割の開発者は、より組織的圧力を感じていました。コード生成AIへの期待が高く、活用の圧力を受けやすいためと考えられます。

また、組織規模が大きいほど圧力も高いことが分かりました。大規模組織では経営層主導でAI導入が進められ、標準化された方針が採用を義務付ける傾向があるためです。

経験年数は組織的圧力と関係がありませんでした。

作業負荷

作業負荷については、どの特性とも関係が見られませんでした。AI導入に伴う作業負荷の増加は、役割や組織規模、経験年数に関わらず、広く経験されているということです。

自律性

組織規模が大きいほど、自律性が低いことが分かりました。大規模組織では官僚的な構造になりがちで、個人の影響力は抑制する傾向にあります。

一方、大規模組織では経験年数が長いほど自律性が高いことも分かりました。ベテランは専門知識と組織内での信頼により、より大きな発言権を持つためです。

学習資源

大規模組織の開発者は、より多くの学習資源にアクセスできると報告しました。大企業にはトレーニングプログラムや教育予算の余裕があるためです。

また、経験豊富な開発者も、より多くの学習資源を得ている傾向があります。ベテランは学習機会を積極的に求める傾向が強いか、組織内での立場によりトレーニングへの参加が優先されるためと考えられます。

なお、361件の回答から、学習資源には6つのカテゴリーがあることが特定されました。

最も多かったのは「社内トレーニング」や「ワークショップ」で、全体の30.2%でした。

次に多かったのが「ビデオ」や「ドキュメント」といったトレーニング教材へのアクセスで、19.04%です。

注目すべきは、自主学習が15.23%を占めていた点です。

勤務時間外に自分の時間とお金を使って学習している開発者が一定数いるのです。

「会社が提供するのは基本的なことだけだ。そのため、私自身が大学のコースに登録した」という声がありました。

また、22.4%の回答者が「組織は有意義なサポートを提供していない」と回答していました。

組織規模が小さいほど自主学習が一般的であり、また、ベテランほど自主学習に頼る傾向がありました。

まとめ

この調査から生成AI導入が開発現場に3つの大きな懸念をもたらしているという事実が浮かび上がってきます。世間では期待が取り上げられがちですが、懸念にも注目したいところです。

懸念の一つ目は、期待から圧力への変化です。「AIで誰もが速くなる」という期待が、「もっと多くの仕事をこなせ」という要求に変わり、開発者は常に緊急対応に追われる状態に陥っています。

二つ目は、学習方法の変化です。かつては先輩とのペアプログラミングやコードレビューを通じて学んでいましたが、今はAIとの対話が中心になりつつあります。社会的なつながりを減らし、新人のスキル習得を遅らせる懸念があります。

三つ目は、見えないコストの発生です。AIがコードを生成するのは速いかもしれませんが、それをレビューする負担が増えています。品質チェックや冗長なコードの編集に時間を取られ、チーム内の摩擦も生まれています。

教訓は明確です。生産性指標を見直し、AI導入に関する検証コストも考慮するようにした方が良さそうです。新人には十分な学習時間を確保し、ベテランだけでなく全員が平等にトレーニングにアクセスできる環境を整える必要があります。チームレベルでは、AIをいつどう使ったかを明示し、レビュー負担を公平に分配するルール作りが求められます。

生成AIの可能性はもちろん大きいですが、その活用には人間と組織の適応力が試されています。