ソフトウェアエンジニアのAlec Scollon氏は7月8日、自身のブログで「LLM燃え尽き症候群になったかもしれない」と告白した。仕事ではAnthropicのClaude Code、自宅ではOpenAIのCodexを毎日何時間も使い続けてきた同氏は、生産性の向上を実感する一方で、AI生成テキストに特有の「紋切り型の言い回し」や「過剰な絵文字」、そして繰り返される事実誤認(ハルシネーション)に強い疲労を感じ始めたという。この投稿はHacker Newsで328ポイント・266件のコメントを集め、多くの開発者から共感の声が上がっている。
「コーディング」から「LLM出力のレビュー」へ変わった仕事
Scollon氏の日々の仕事は、かつての「設計してコードを書く」というスタイルから、「設計を考え、Claude CodeやCodexに説明し、生成されたコードをレビューし、最後に自分でコードを書く」という流れに変化した。現在の主な取り組みは、社内のコードベースで大規模かつ人手を介さないコード生成の仕組みを構築することだ。Claude Codeでそのためのツールを作る一方、オープンウェイトモデルのQwenを使った自律型エージェントが生成した大量のコードをひたすらレビューする毎日を送っている。検索も同様で、知りたいことがあればまずChatGPTに聞くかGeminiの概要を読み、答えが怪しいときだけ従来型のブラウジングに戻るという。
疲労の正体は「ツールの不安定さ」ではなく「パターンの反復」
Scollon氏が強調するのは、LLMの間違いや癖そのものではなく、その「反復性」が疲労の原因だという点だ。断定的で短く区切られた文体、過剰な絵文字、同じ種類のハルシネーション――これらは個別には気にならなくても、毎日大量に浴び続けると精神的な負荷になる。人間の文章にも癖や間違いはあるが、LLMは無数の他人が生成した文章にも触れる機会が多く、自分では文体をカスタマイズできても、他者が生成したAIコンテンツの「型」までは制御できない。
実務への影響
日本のIT現場でも、Claude CodeやGitHub Copilot、ChatGPTなどを日常的に使うエンジニアやIT管理者が急増している。この記事が示すのは、AI活用の「量」を追いかけるフェーズが一段落し、次は「AI生成物とどう付き合うか」という質のフェーズに入ってきているということだ。具体的には次のような対策が現実的だ。
- カスタムインストラクションで文体を制御する: Claude Codeの CLAUDE.md やChatGPTのカスタム指示、Copilotのプロンプト設定などで、絵文字の使用や文体のトーンを事前に指定しておくと、反復疲労をある程度軽減できる
- レビュー方式を見直す: 生成コードを1行ずつ人間が読む方式のままでは、生成量が増えるほど疲弊が加速する。テストやCIでの自動検証を厚くし、人間のレビューは「設計判断」や「危険な変更」に絞り込む設計に切り替える
- チームのAI活用ルールを明文化する: 個人の裁量に任せると、生成文章の文体やレビュー負荷がメンバーごとにばらつく。ドキュメントやコミットメッセージの生成ルールをチームで統一すると、読み手の負担も減る
筆者の見解
この告白は率直に「あるある」だと感じた。人間がAIの生成物を一行ずつ検証し続ける限り、いくら生成速度が上がっても人間側のレビュー負荷はむしろ増える。これはAIエージェントの設計思想の問題で、確認や承認を人間に求め続ける「副操縦士」型の使い方をしている限り、燃え尽きは避けられない構造だと考えている。
本来AIエージェントが果たすべき役割は、人間の認知負荷を減らすことのはずだ。Scollon氏自身、Qwenによる自律エージェントの出力をひたすらレビューする作業に時間を取られているというが、これはまさに「人間がまだ確認係から抜け出せていない」状態を象徴している。目的とガードレールを渡したら、あとはエージェントが自律的にループを回して判断・実行・検証まで済ませ、人間は結果とリスクの高い判断だけを見る――そういう「ハーネスループ」的な設計に踏み込むフェーズに来ているはずだ。
情報を追いかけて「あれも試した、これも試した」と広く浅く手を広げるより、自分の手元の仕組みを一つ実際に動かし、そこで見えてきた摩擦(今回でいえば「レビュー疲れ」)を仕組みの改善にフィードバックしていく方が、今の時期は圧倒的に生産的だと思う。Scollon氏の疲労は、AIを使いすぎた結果ではなく、AIの使い方をまだアップデートできていないサインとして受け止めるのが正しい読み方ではないだろうか。
出典: この記事は I think I have LLM burnout の内容をもとに、筆者の見解を加えて独自に執筆したものです。