エンジニアのAI疲れとの付き合い方

この記事は、「AIを使えば楽になるはずなのに、なぜか前より疲れている」 と感じたことがあるエンジニアの人に向けて書いています。

AIに何度もプロンプトを投げ直し、出てきたコードを修正し続け、気づけば一日が終わっている。
「AIは便利なはずの道具なのに、なんで自分はこんなに消耗しているんだろう。。（泣）」

「AIを使っているのに、なぜか前より疲れている」という感覚はありませんか。
私は、あります。
むしろ、AIを本格的に使い始めてからのほうが、消耗感は強くなりました。
「AIで効率化できる時代なのに、なぜこんなにしんどいのか」と、疑問がわいてきました。

エンジニアの仕事は、本来、仕組みを作って楽になるためのものです。
それなのに、最新の技術を使えば使うほど疲れていくのは、どこかおかしいのではないか。。

私自身、設計相談、コード生成、レビュー補助、ドキュメント作成など、ほぼすべての業務でAIを使っています。
最初の頃は、「24時間働いてくれる自分専用のもう一人の優秀な新人が増えた！これで勝つる！」と感じるほど便利で、歓喜した時期もありました。
しかし、喜んだのもつかの間、ある時期から、以前より強く疲労を感じるようになりました。
作業時間は短くなっているのに、なぜか頭が重い状態。。。あれっ、コードを書くのが、なんだか楽しくないぞ。。。？？
AIによって作業が楽になっているはずなのに、今現在疲れて果てている自分の状態の矛盾に、混乱しました。

本記事では、私自身の失敗や遠回り、試行錯誤を交えながら、エンジニアが感じやすい「AI疲れ」と、その付き合い方について、言語化してみたいと思います。

AI疲れとは

AI疲れとは、AIを活用することで 業務効率が上がっているにもかかわらず、精神的・認知的に消耗してしまう状態 のことです。
止め処無いAIのアウトプットによる情報過多が脳に過度な負担をかけ、深い疲労感をもたらします。

生成AIを使い始めたばかりの頃は、「こんなに簡単にコードや文章が書けるのか！すごい！」と感動する人が多いと思います。
私も最初の数か月は、毎日のように新しい使い方を試し、「これは革新的だ」と興奮していました。
しかし、そのうち「作業は早く終わるのに、なんだかやたら疲れた。。。」「うっ、、、仕事中、頭が回らない」といった状態になりました。
なぜだかわからないけど、コードを見るのも書くのも嫌になった時期もあります。AIが出してくるコードに恐怖さえ感じました。
最初は年齢や忙しさのせいだと思っていましたが、振り返ると、原因はAIとの付き合い方にありました。
AIは作業を肩代わりしてくれますが、その分、人間側に新しい種類の負担を生み出しているのではないでしょうか。

「読む」「考える」「判断する」という作業の増大

私がAI疲れを強く意識するようになったのは、生成AIを本格的に業務に使い始めてからでした。
以前は、設計を考えるときはホワイトボードやメモ帳に向かって一人で悩んでいました。
しかしAIを使うようになってからは、まずAIに聞き、案を出してもらい、それを評価するという流れに変わりました。
一見すると合理的ですが、実際には「読む」「考える」「判断する」という作業が何倍にも増えていました。
例えば、新機能の設計でAIに三案出してもらい、それぞれのメリット・デメリットを比較し、修正案を考える、という作業を繰り返していました。
これは、自分で一案をじっくり考えるよりも、はるかに脳を消耗します。
気づけば、一日中レビューと判断ばかりしている状態になっていました。

AI疲れを生む主な要因

AI疲れにはいくつかの典型的な原因があります。

認知不可の増加

まず一つ目は、認知負荷の増大です。
AIが出してきた文章やコードを評価し、「正しいか」「安全か」「実用的か」を判断する作業は、想像以上に脳を使います。
私自身、1時間ほどAIの出力をレビューしただけで、頭がぼんやりしてくることがありました。

マルチタスクの増加

二つ目は、マルチタスクの増加です。
AIの応答を待つ間に別のタスクを開き、戻ってきて確認し、また次の指示を書く、という作業を無意識に繰り返していました。
結果として、一つひとつの作業に集中できず、常に頭がとっ散らかった状態になります。
「一日中忙しかったのに、あまり達成感がない」という感覚の正体は、ここにありました。

確率的な動作の増加

三つ目は、AIが確率的に動作していることです。
これまで多くのエンジニアは、決定論的なコードを前提に仕事をしてきました。
同じ入力なら、何度実行しても同じ結果が返るのが当たり前でした。
しかし生成AIは、確率にもとづいて出力を生成します。
私も、「昨日は完璧だったプロンプトが、今日はなぜか微妙な結果になる」 という経験をしました。
従来ならログを追って原因を特定できますが、AIの場合はそれが難しいです。
「なぜ失敗したのか分からないまま試行錯誤する」状態は、大きなストレスになります。

周りとの比較、見えないプレッシャーの増加

四つ目は、無意識のプレッシャーです。
「もっと使いこなせるはずだ」「自分はまだ甘いのではないか」と考えてしまい、自分で自分を追い込みます。
私はSNSで他人のAI活用事例を見るたびに、焦りを感じていました。
SNSのキラキラした投稿を見るたびに 「自分はAIを使いこなす能力がない駄目なやつだ」 と自己肯定感が下がっていきました。

アーリーアダプターにならねばという強迫観念

AIの新ツールや新機能が出るたびに、「今すぐ試さないと遅れるのではないか」と不安になることがあります。私も以前は、そのタイプでした。

私は、Claude Codeをメインに使っているのですが、毎日起動するたびにバージョンが上がっていきます。リリースノートには把握できないくらいの新機能が追加されています。
私はAnthropicsの動向を追うことに必死になっていました。

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Claude関連で言えば、MCP, Skills, Subagent, Claude Agent SDK, Claude Cowork, Claude × Excel 統合などなど、追うべきことが際限なく登場しています。

他にもSNSで話題になったサービスを片っ端から触り、ブログやスライドを読み漁り、週末を丸ごと検証に使う。気づけば、本業とは関係ないところでエネルギーを消耗していました。

さらに厄介なのは、AIまわりのツールやベストプラクティスの流行り廃りが異常に早いことです。半年前に「これが正解」と言われていた使い方が、今ではほとんど話題にされていない、ということも珍しくありません。

「このやり方を覚えればしばらく戦える」 と思って必死に身につけた独自のプロンプト設計やエージェント運用フローやツールのベストプラクティスが、数か月後には時代遅れになっていた経験が誰しもあるのではないでしょうか。
そのたびに、「あの時間は何だったんだろう」と虚しくなりました。
情報が陳腐化するのが早すぎて唖然とします。

以前 「Clineに全部賭けろ」 が話題になりましたが、何か特定のAIツールにすべてを賭けるのは結構リスクが高いと感じています。かといって 何にベットすべきかは未だによくわからない状態 です。正解はわかりません。今現在私はClaude Codeに賭けている状態ですが、これも数カ月後にどうなるかはわかりません。

一時期は、毎週のように新しいツール紹介やノウハウ記事やスライドを追いかけ、「最新の正解」を探し続けていました。しかし、それは終わりのないマラソンのようなもので、走れば走るほど疲れていきました。

しかし、現場で本当に役に立つのは、多くの人に使われ、改善され、安定してきたツールや機能です。最初に飛びついた人たちが地雷を踏み、問題点を洗い出してくれた後の方が、安心して使えます。

私はある時、「自分はアグレッシブに新規ツールを使い始める積極タイプではなく、枯れたツールや知識で実務で確実に成果を出すタイプのエンジニアだ」と考えるようになりました。それ以来、あえて一歩遅れて導入するようにしています。

結果として、新規ツールや新機能のトラブル対応に追われる時間は減り、本来の開発に集中できるようになりました。
レイトマジョリティくらいの立ち位置が、私にはちょうどよかったです。

AIと仕事することは優秀すぎる新人との仕事に似ている

AIとの共同作業は、「とても仕事が早い新人と一緒に働く感覚」に近いと感じています。
その新人は、頼んだことをすぐに大量に仕上げて持ってきます。
しかし、そのすべてを細かくチェックしなければなりません。
しかも次々と成果物が届くため、こちらは常に判断を迫られます。
最初は助かりますが、しばらくすると「休む暇がない状態」になります。
作業を新人に任せる代わりに、新人の出してくる成果物のチェックと新人の行動のコントロールや監視という新たなタスクがのしかかるからです。
他人をコントロールするのは、自分をコントロールするのと比べてはるかに難しいです。
なぜなら自分で操縦桿を握れないのに、指示だけで飛行機を操縦するのと同じだからです。
AIとの仕事もまさにこれと同じです。

AIを使いこなすとは、確率と戦うということ

エンジニアの仕事は、長い間 「決定論」 と一緒にありました。

同じコードを同じ条件で動かせば、同じ結果が返ってくる。それが当たり前でした。だからこそ、バグは追えるし、原因も突き止められます。

それがAIで崩れ去りました。

同じプロンプトを投げても、同じ結果が返ってくるとは限りません。

昨日うまくいった指示が、今日は通用しないこともあります。
設定も変えていないのに、なぜか挙動が変わる。その不安定さに、戸惑いました。

APIのコードをAIに任せていたとき、前日はほぼ完璧なコードが出てきたのに、翌日は明らかに品質が落ちたコードが返ってきました。「なぜ？」と考えても、理由は分かりません。AIの出力にはログもスタックトレースもありません。ただ、そう出た、というだけです。
このとき私は、「AIはデバッグできない存在なんだ」 と気づきました。コードなら追えますが、AIの思考過程はブラックボックスです。問題が起きたときに、論理的に切り分けられない。
AIの出力がうまくいかなかったときに、自分のプロンプトに問題があるのか？、はたまたLLMのモデルの能力に問題あるのか？、それとも"たまたま"運が悪かっただけなのか？、それを判断する情報はありません。
この不確実さが、地味に精神を削ります。

私は一時期、プロンプトを細かくバージョン管理し、成功パターンを必死に再現しようとしていました。しかし、それでも完全な再現性は得られませんでした。
(プロンプトのバージョン管理ってみんなどうやってやってるのだろう。。。)

そこで考え方を変えました。AIは「正確な計算機」ではなく、「確率的にそれっぽい答えを返す相談相手」なのだと割り切るようにしました。

この前提に立つと、かなり楽になります。AIの出力を前提に設計しない。必ず人間が最終判断をする。外れても想定内と考える。そうやって付き合うことで、無駄なストレスが減りました。

AIを使いこなすとは、便利さを享受しつつ、この不確実さと折り合いをつけること だと、今では思っています。

AIは大いなる力をもたらすが、代償も大きい

AIを本格的に使い始めてから、私の生産性は間違いなく上がりました。資料作成、調査、設計のたたき、コードの雛形づくり。以前なら数時間かかっていた作業が、30分で終わることも珍しくありません。

正直に言って、「もうAIなしでは戻れない」と感じる瞬間もあります。それくらい、強力な道具です。

しかし、その一方で、確実に失ったものもあります。
それは、「ゆっくり考える時間」と「試行錯誤する余裕」 です。

以前の私は、仕様を読み込み、ホワイトボードや紙に図を書き、頭の中で何度も設計を組み立てていました。その過程で理解が深まり、経験として蓄積されていました。

ところが、AIを使うようになってからは、「とりあえず投げてみる」が増えました。考える前に聞く。悩む前に生成する。その結果、自分の中に残るものが減っていきました。

あるとき、久しぶりにAIを使わずに対面の設計レビューに参加したことがあります。その場で議論についていけず、「あれ、自分、こんなにアタマが働かなくなってたっけ」とショックを受けました。

また、AIに頼りすぎることで、判断を先送りにする癖もつきました。「AIに聞いてから決めよう」が癖になっていたのです。

便利さと引き換えに、思考力や自信を少しずつ削っていた。その事実に気づいたとき、背筋が冷たくなりました。

だから私は今、あえてAIを使わない時間を作るようにしています。設計初期は紙に書く。まず自分で考える。ある程度固めてからAIに相談する。
こうすることで自分で自分の仕事をコントロールする感覚が戻ってきます。
自身の手で直にハンドルを握ることが大事なのです。

AIは間違いなく強力な武器です。しかし、武器は使い方を誤れば、自分を傷つけ、弱くします。そのことを忘れないようにしています。

エンジニアの完璧主義とAIの相性が悪い

エンジニアの多くは、無意識のうちに 「完璧に動く状態」を理想 として仕事をしています。私自身もそうでした。テストがすべて通り、Lintも警告ゼロで、仕様どおりに動く。その状態になって初めて「よし、終わった」と安心できるタイプです。

以前、業務で使うツールをAIに補助させながら開発していたことがあります。APIのラッパーコードやテストコードをAIに生成させていたのですが、最初はかなり便利でした。ただ、しばらくすると「9割正しいけど、1割おかしいコード」が大量に溜まり始めました。

最初は調子が良くても、扱うコードベースの規模やファイルの量が大きくなるとコンテキストウィンドウを圧迫して、細かいミスや急にAIが記憶喪失なったりといったことが目立ち始めます。

一見すると動きそうなのに、エッジケースで落ちる。型が微妙に違う。例外処理が抜けている。前提条件のコンテキストにズレがある。こうした“惜しいミス”が積み重なっていきました。

完璧主義のエンジニアにとって、これがかなりストレスになります。なぜなら、「あと少し直せば完璧なのに」という状態がずっと続くからです。しかも、その修正作業は創造的でも楽しくもありません。
ただの後始末の尻拭いです。

ある時期、AIが出したコードを一行ずつチェックして修正する作業に毎日2〜3時間使っていました。その結果、「これ、最初から自分で書いた方が早くないか？」と思うようになり、AIを使っているのに疲れるという矛盾した状態に陥りました。AIの尻を拭く作業に疲れたのです。

さらに厄介なのは、AIは「70点の成果物」を平然と出してくる点です。人間なら恥ずかしくて出さないレベルの中途半端さでも、AIは気にしません。この価値観のズレが、完璧主義の人ほど精神的に響きます。

私も最初は「100点に近づけないと気が済まない」と思っていました。しかし、スケジュールが厳しくなったとき、思い切って「70点で出す」ことを許容しました。「だいたい自動テスト通ってるし、ま、大丈夫でしょう」とリリースするようにしました。(これは個人開発の話なので許される。。。はず)。
すると、不思議と精神的にかなり楽になりました。

AIと付き合う上では、「完璧を目指さない勇気」が必要になります。AIはあくまで叩き台を作る存在であり、最終品質は人間が決めるものです。最初から100点を期待すると、かなり疲れます。

私は今では、AIの成果物に対して「これは下書き」「これはメモ」と心の中でラベルを貼るようにしています。そうすることで、無駄にイライラせずに済むようになりました。

Spec-Driven-Development（仕様駆動開発）を業務でやるのはかなり難しい

AIとの付き合い方を悩んだ時期に、「SDD（仕様駆動開発）」のやり方も試していました。先に仕様を細かく文章化し、それをそのままAIに渡して実装させる方法です。理屈としてはかなり合理的で、「これならブレずに作れるはずだ」と期待していました。

「ついにAIと仕事するための銀の弾丸を手に入れた」と歓喜しました。

私は早速実際に、画面仕様、入力条件、エラーケース、境界値まで細かく書いたドキュメントを用意しました。正直、仕様を書くのに丸一日かかりました。そのうえでAIに投げてみたのですが、返ってきたコードは、なぜか一部の前提を無視していたり、都合よく解釈されていたりしました。

「ここまで書いたのに、そこ外すのぉ。。。。」と、画面の前で呆然としました。結局、その後も何度も仕様を修正し、補足を書き足し、説明を変えましたが、期待したほど安定はしませんでした。

結果として、「仕様を書く → AIに投げる → ズレる → 仕様を修正する → 別のズレが発生する」というループにハマり、むしろ負担は増えていました。仕様を書く力も、AIを制御する力も、両方求められる状態になっていたのです。

この経験から、「正しいやり方をすれば楽になる」という幻想を、私はようやく手放しました。
完璧な仕様書作成は諦めて、ノリでバイブコーディングするのもよいことにしました。
不思議なことに、このバイブスがあることで心の負担が一気に減りました。
行き当たりばったりでも良いのです。その過程を楽しみましょう。
人間には、「試行錯誤する余白」 が必要なのです。
仕様駆動開発で疲れている人は、「そこにバイブスはあるのか」 一度見直したほうが心が軽くなるのでオススメです。

勘違いしてほしくないのは、SDDは駄目な方法ではありません。
むしろAIと仕事をする上で正しい方法だと感じています。
しかし、これを実際の業務で、完璧な仕様書作成を目指すとものすごく疲れますし、まず「完璧な仕様を作る」ということ自体がかなり難しく、仮に「完璧な仕様を作る」ことができたとしても、AIの確率的な動作に悩まされます。結果として私は業務で完璧なSDDをするのはいったん止めにしました。緩い感じのSDDで開発しています。緩い感じのSDDとは、緩く仕様書を作って7割完成させて、あとはバイブコーディングで作っていくスタイルみたいな感じです。
自分にはこのぐらいのゆるい感じがよいと感じています。

AI疲れと付き合うための工夫

AI疲れに気づいてから、私は意識的に使い方を変えるようになりました。
まず取り組んだのは、AIを使う場面を明確に分けることです。
以前は、調査、設計、実装、文章作成まで何でもAIに投げていましたが、今は役割を決めています。
調査や下書きはAIに任せる。最終判断と責任は必ず自分が持つ。これを徹底しました。

次に、レビュー時間をまとめて確保するようにしました。
以前は、AIの出力が来るたびにすぐ確認していましたが、それをやめました。
30分や1時間など、まとめて確認する時間を決めることで、集中力が大きく改善しました。

また、AIのアウトプットを人間が全てレビューすることは諦めました。
AIの効率化が進めば進むほど、人間のレビューがボトルネックになります。
人間のレビューは最小限の重要な箇所に絞り、
コードが安全かどうかの担保は、自動テストを充実したり、静的解析だったり、AIの自動レビューに頼ることにしました。
少々のコードの粗さは目を瞑ることにしました。

また、プロンプトやAIに渡す仕様書を完璧にしようとしないことも重要でした。
以前は、「もっと良い指示を書けば、もっと良い答えが返るはずだ」と何度も書き直していました。
しかし、それは終わりのない作業になります。
今は「7割使えれば十分」と割り切り、残りは自分で補うようにしています。

さらに、AIを使わない時間を意図的に作っています。
例えば、午前中の1時間はAI禁止にし、自分の頭だけで設計を考えます。
その際は、PCも使わず紙やホワイトボードに設計をなぐり書きにします。ぐちゃぐちゃでよいのです。
最初は非効率に感じましたが、結果的に思考力が戻り、午後の作業効率も上がりました。

最後に、作業ログを簡単に残すようにしました。
どの作業でAIを使い、どこで詰まったのかを書いておくだけでも、自分の傾向が見えてきます。
これは疲れの原因を客観的に把握するのに役立っています。

心と体のバランスを守るという視点

AI疲れの対策で最も重要なのは、「自分は機械ではない」という前提を忘れないことだと思います。
AIは24時間働けますが、人間はそうではありません。
それにもかかわらず、私は無意識のうちにAIのスピードに合わせようとしていました。

以前の私は、「今日はここまで進められるはずだ」とAI基準で予定を立てていました。
その結果、計画通りに進まないと強いストレスを感じるようになっていました。
今は、人間基準でスケジュールを引くようにしています。
余白を最初から組み込むことで、精神的にかなり楽になりました。

また、身体的なケアも無視できません。
AI作業は長時間画面を見続けることが多く、目や肩への負担が大きくなります。
私は意識的に1時間に一度は立ち上がり、軽く体を動かすようにしています。
これだけでも、夕方の疲労感が大きく変わりました。

さらに、「何もしない時間」をあえて作るようにしました。
以前は、移動中や休憩中もAIの記事やSNSを見ていました。
今は、あえて何も考えない時間を作っています。
その時間はアタマをからっぽにして瞑想しています。
この時間が、思考のリセットに大きく役立っています。

効率や生産性は大切ですが、長く働き続けるためには持続可能性のほうが重要です。
AIと付き合ううえでは、「今日どれだけ進んだか」よりも、「明日も元気に働けるか」を基準にするべきだと、今は考えています。

まとめ

AIは、これからのエンジニアにとって欠かせない存在です。
しかし、使いこなすことと、使いすぎることは別物です。
AI疲れを感じたときは、一度立ち止まって使い方を見直してみてください。
この記事が、皆さんの働き方を見直すきっかけになれば幸いです。

追記： 結局のところAIと一緒に働き続けるしかない

私は「もうAIはいいや」と見るのも嫌になったこともあります。
思ったように動かない。原因が分からない。修正してもまたズレる。
そのたびに、自分の集中力と気力が削られていきました。

夜遅くまで画面に写ったAIとのやりとりを見つめながら、「何をやっているんだろう」と虚しくなったこともあります。AIを使えば楽になるはずだったのに、なんだか前より疲れている。その現実に、しばらく向き合えませんでした。

しかし、それでも、今も私はAIを使っています。たぶん、これからも使い続けると思います。

理由は単純で、「AIがすごいから」ではありません。「AIが万能だから」でもありません。
ただ、自分の限界を少しだけ広げてくれる存在だからです。

すべてをAIに任せるとすべてはすぐに壊れます。期待しすぎても壊れます。でも、適度な距離感で使えば、確実に助けてくれる瞬間があります。その瞬間があるから、私はまだAIと付き合っています。

AI疲れは、真面目に仕事をしている人ほど起こります。ちゃんと成果を出そうとしている人ほど、消耗します。それは決して弱さではありません。

もし今、AIに疲れているなら、一度距離を置いてもいいと思います。完璧を目指すのをやめてもいいです。今日はAIを使わない日があってもいいです。

エンジニアの仕事は、長く続けてこそ意味があります。
燃え尽きてしまったら、どんな技術も役に立ちません。

私はこれからも、迷いながら、文句を言いながら、それでもAIと付き合っていくと思います。
あの深夜に感じた違和感は、今でもときどき思い出します。でも今は、その違和感と上手に付き合えるようになりました。

そのくらいのゆるーい関係が、たぶん一番ちょうどいいのだと思っています。