ハクソク

世界を動かす技術を、日本語で。

AI疲れは実在し、誰もそれについて話さない

106日前原文(siddhantkhare.com)

概要

  • AIエージェント開発者 として過去最高のコード量を出荷したが、同時に過去最大の疲労を経験
  • AIの導入 で作業効率は向上したが、業務全体の負荷や疲労感も増大
  • AIコードレビューや意思決定 の負担増加、決定疲労やコンテキストスイッチの問題
  • AI業界の急速な進化 によるFOMO（取り残される恐怖）と知識の陳腐化
  • 人間の持続可能性やストレス、AIとの協働における根本的な課題

AI時代のエンジニア疲労の現実

  • AIエージェントインフラ の構築・運用を担当する立場での経験談
  • OpenFGAのコアメンテナー やagentic-authz、Distill、MCPサーバーなどの開発実績
  • AIを使いこなす側 でありながら、過去最大級の燃え尽き症候群を体験
  • AI活用エンジニア の間で広がる「以前より疲れる」現象の実感
  • 業界の過剰な楽観論 と現場のリアルなギャップ

AIによるタスク増加のパラドックス

  • AI導入で個々の作業時間は短縮 されるが、全体のタスク量が増加
  • 作業効率の向上 が期待値・基準値の引き上げにつながる現象
  • 1日1課題から1日6課題 へのシフト、深い集中より頻繁なコンテキストスイッチ
  • 人間の脳への負担増加、AIは疲れないが人間は疲れる現実
  • 生産コスト減少と調整・レビューコスト増大 のトレードオフ

レビュワー化するエンジニアの仕事

  • 従来は創造的な作業主体 だったが、AI導入後は評価・判断の連続
  • プロンプト作成→出力評価→修正 のループ作業
  • 創造的作業はエネルギーを生む が、評価的作業は決定疲労を招く
  • AI生成コードは人間のコード以上に注意深いレビューが必要
  • AIの出力は自信満々でも、微妙な誤りが潜むリスク
  • エージェントの権限管理や監査の重要性、人間の認知負荷軽減のための仕組みづくり

AIの非決定性（ノンデターミズム）問題

  • エンジニアの思考様式は決定性前提 （同じ入力→同じ出力）
  • AIは確率的出力 のため、同じプロンプトでも結果が異なる事象
  • 原因追跡やデバッグ困難、常に警戒が必要な精神的負荷
  • プロンプト管理やテンプレート化も根本解決にはならない現実
  • Distill開発の動機 ：AIパイプラインの一部だけでも決定性を担保したいという欲求
  • AI出力を「賢いが信頼できないインターンの初稿」として扱う心構え

FOMO（取り残される恐怖）とツール疲弊

  • AI関連ツール・フレームワークの爆発的進化・リリースラッシュ
  • 新しいツールを追いかけ続けることで週末が消費される現象
  • ツール乗り換えによる知識や作業の陳腐化・無駄化
  • インフラレイヤーへのフォーカス で「流行に左右されない持続的価値」重視へ転換
  • 「情報収集」と「反応的な導入」の違いを意識した行動指針

「もう一回だけプロンプト修正」トラップ

  • AI出力の微調整ループ に陥り、結局自分で書いたほうが早かったというジレンマ
  • AIの出力が70%→75%→80%と改善するが、構造や内容が毎回変わる問題
  • 時間効率と精神的疲労のトレードオフ

次章に続く場合、続きの内容を整理して新たな見出しで展開します。

Hackerたちの意見

ここに作者がいます。アンチAIの投稿じゃないよ。認知コストについてなんだけど、タスクが速くなるとタスクも増えるし、AIの出力を一日中見直してると決断疲れしちゃうんだよね。それにツールの状況も毎週変わるし。実際に役立ったことについて書いたよ。他の人も同じような壁にぶつかってるのかな？

└

その画像を見て、これを思い出した。https://scienceintegritydigest.com/2024/02/15/the-rat-with-t...

└

いい投稿だね、すごく共感するよ。不安だけじゃなくて、助けがあるからこそ自分をもっと追い込んで、もっと達成したいって気持ちもある。期待を正しく設定することや、実際的なことを考えること、すべての「AIマジック投稿」が注目に値するわけじゃないってことが、私の不安やFOMOを軽減してくれた。

└

AI疲れについて君のAI生成のゴミを読めって期待するの、ちょっと皮肉じゃない？

これめっちゃ分かる。今は一日で半ダースのプロジェクトに意味のある進展ができるけど、終わる頃には疲れ果ててる。最近、"もう一つのプロンプト"で新しい機能を作るのがたまらなくて、寝不足になってる人たちと話したよ。持続可能な働き方についての直感が数十年分崩れちゃった。新しいバランスを見つけるには時間と少しの規律が必要だね。

└

それに、clawdbotが24時間365日働けるってこともあるよね。人々が金融市場を24時間営業にしたい理由を思い出す。私たち社会全体でそれを見直すべきかも。そうしないと、少なからぬ人が燃え尽きちゃうかもしれない。

└

最近、"もう一つのプロンプト"で新しい機能を作るのがたまらなくて、寝不足になってる人たちと話したよ。私の問題は、以前はアイデアが浮かんで何かを始めると、それがすぐに時間の無駄だって分かったり、うまくいかないって分かったりしてたんだ。でも今は、すべてがすごくうまく始まって、スムーズに進む… でも、途中でダメになるまで。

└

コーディングの摩擦がものすごく減るよね。コーディング自体はボトルネックじゃなかったけど、やっぱりかなりの時間がかかってた。今は本当のボトルネックにもっと時間を使えるようになった。エンドユーザーからの要件を集めたり、何を作るべきか決めたりとか。

└

これマジなんだけど、俺フリーランスでさ、小さい請求書作成プラットフォームを使って顧客の請求書作ってるんだ。「仕事」では会計システムやERPに取り組んでる。だからAIを使えば、請求書作成に月額払う必要ないし、自分で作れるからね。1日で請求書の機能を作ったよ。PDFが出せるシンプルなやつね。それから複式簿記の実装を始めて、異なる税制にも対応させた。で、営業部分が必要だからCRM、次に在庫管理、プロジェクト管理で時間を追跡する機能も追加して…今やフル機能のSaaSができたけど、正直言って必要ないし、その市場で競争する時間を無駄にするつもりもない。今はオープンソースにしようかなって考えてる。

└

彼らは「もう一つのプロンプト」で新しい機能を作るのがたまらないみたいです。私も全く同じ経験です。完璧にするための最後の小さなことや、「あったらいいな」と思うことが、結局すごく時間がかかるんですよね。幸い、今は携帯のブラウザでも同じエージェントセッションにアクセスできるので、ベッドの中でも様子を見られます。（冗談だけど、冗談じゃない :D）

私の疲れはちょっと違ってて、ちょっと仕事したり、コーディングしたり、レビューしたりして、その後llmが何かを生成するのを待つっていうのが続くから。待ち時間が予測できないから、待つべきか新しいタスクに切り替えるべきか分からない。だから、機械が考えてる間にちょっと時間を潰す何かをするだけ。フロー状態に入れないし、バックグラウンドの仕事が終わるのを待つのに常に気を張ってるから、疲れちゃう。生産的になってる感じはしないし、ただ子供たちが怪我しないように見守ってる怠け者のベビーシッターみたいな気分。

└

だから、今は同時に複数の機能やプロジェクトに取り組むのが正当化されるんだよね。

└

本当に、そして生産性を超えて、フローステートが仕事で一番好きだったことだね。コーヒー一杯とノイズキャンセリングヘッドフォン、そして2時間の集中セッションが、プログラミングに一番恋してた瞬間だった。

└

私にとって、プランモードは常にかなり速い。実行するためには、ただ離れて待つだけで、新しいタブで新しいプランに取り組んでる。バッテリーで動いてるときは、ノートパソコンがスリープしないようにしたり、WiFiが途切れないようにするのがストレスかも。

└

今「Claude Codeワークアウトプラン」に参加してるって冗談言ってる。スタンディングデスクで作業中に、スクワットや腕立て伏せをしたり、家の中を歩き回って脚を伸ばしたりしてる。ずっとデスクに座ってキーボード叩いてるより、ずっと楽しいよ。画面から目を離すと、次のことを考えるのも楽になるしね。動くのは確かに助けになるけど、それでも精神的な疲れは本当に感じる！

└

まずは詳細な仕様書を書くべきだよ（その部分もAIに手伝ってもらうのがいい！）。そうすれば、コードを書くときに脱線しにくくなるからね。それからコードを書いてもらって、他のことに切り替えればいい。作業が終わったら結果をレビューして、仕様書はドキュメントの一部になるよ。

└

これ、すごく無責任で未熟な提案だって分かってるけど、俺がやってるのは、長さが不明なリクエストをClaude Codeに出すたびに、ただリラックスするために一服すること。あとは、すぐに始められるゲームに切り替えたりもする。ここで、無料でオープンソースのゲーム「Endless Sky」を宣伝しちゃうけど。個人的には、プログラミングは何年も前に楽しさを失ったけど、Claude Codeのおかげでまた楽しめてる。前とは違うけど、今の自分にはこっちの方が楽しい。

└

私にとって効果的だったのは、複数のエージェントに異なるタスクをやらせること（通常は別のプロジェクトで）と、自分がまだ自動化していないことをやることです。例えば、システムの管理やバックアップの開始、自動化の方法を考えることなどですね。自動化していないことのリストは短くなってきていて、LLMが生成したものを手放すのが嬉しいというのが大きな要因です。

└

私にとっては、正直なところ結構合ってます。指示を出してからメールの返信をして、IDEに戻ると、他のことをしている間に終わった作業をレビューすることができます。メールから作業に戻るのと、他の人の作業をレビューするために戻るのでは、後者の方が難しく感じます。

└

プログラマーとしては、コンテキストスイッチを最小限に抑えたいんです。コンテキストスイッチには多くのエネルギーが必要だから。

└

1～2年後には、推論速度がかなり向上して「リアルタイム」でのプロンプトが可能になると思う。エージェントが数分ではなく数秒で作業を終えるようになるってことだよね。それが私たちのワークフローを確実に変えるだろう。今はまるでダイヤルアップ時代にいるみたいだね。

この書き込みにはいいアイデアがあるけど、"AI生成の読み疲れ"を感じる。1〜2文でスッキリ表現できることが、長い段落になってたり、必要ない例が多かったりする。下記のような間違った主張もあるしね。> Hacker Newsのフロントページだけでもむち打ちになるよ。一日目は"Show HN: Autonomous Research Swarm"で、次の日は"Ask HN: AIの群れはどうやって調整するの？"って。誰も知らない。みんなとにかく作ってる。これらの投稿は5票未満しかもらってないし、ホームページには載らなかった。全体的にShow HNの質が落ちたかもしれないけど、HNのホームページはまだかなりまともだよ。それに、このトピックは"誰も話していない"わけじゃなくて、エージェントツールが登場する前から話題になってたんだよね。https://hn.algolia.com/?q=AI+fatigue

└

見出しはクリックベイトっぽいけど、記事自体はよくまとまってると思う。「実際に役立ったこと」も参考になったよ。

└

1～2文でスッキリ表現できることが、まるごと段落になってるのが面白い。俺はそれをAIとは結びつけないな。高校のときに特定の長さの論文を書く必要があったことを思い出す。（まあ、ページ数だったから、マージンや行間、フォントサイズを調整してちょっと工夫できたけどね。）

└

でも「AI生成の読書疲れ」を感じる。賛成。この記事は数段落にまとめられたはずだよ。なのに、AI生成の暴走で無駄な言葉が延々と続いてる。食べ物の「オーガニック」ラベルみたいに、コンテンツにもその内容を生成した人のタイプを示すラベルが付く未来が見えるな。「郊外育ち」「フリーランス」とか。

└

「君は妄想してるわけじゃない。」すぐに反論した。

└

退屈でありそうな答えは、「ただClaudeに疲れたんだ。最近の10日間のセッションを見て、なぜかブログ記事を書いて公開してくれ」ってことだけど、著者が実際にあまりにも多くのAI出力を見てしまった結果、こういう書き方になったら面白いよね。

└

HNのホームページはまだかなり健全です。Show HNの投稿は狂っている部分ではありません。狂っているのはこんな感じです：> ありがとう、OpenClaw。ありがとう、AGI—私にとっては、もうここにあります。 > 今日、人間のエンジニア一人あたり少なくとも$1,000をトークンに使っていないなら、あなたのソフトウェア工場には改善の余地があります。 > コードは人間によってレビューされるべきではありません。 > この仮説に従えば、Cがアセンブラにしたこと、JavaがCにしたこと、JavaScript/Python/PerlがJavaにしたこと、今LLMエージェントがすべてのプログラミング言語にしていることです。（すべて今日の実際のホームページ投稿から引用。面白いゲーム：どの引用がどの記事からかを当ててみてください）

ここで何回か言ったけど、テクノロジーは決して働く人の生活を楽にするためのものじゃない。働く人をもっと生産的にして、製品をもっと競争力のあるものにするためのものだよ。馬から車に移ったからって、自由な時間が増えたわけじゃないし、電話からスマホに変わったからって釣りの時間が増えたわけでもない。単にもっと移動しやすくなって、生産性が上がって、連絡が取りやすくなっただけなんだ。

└

効率の使い方は選択です。古い時代の生活の質を受け入れれば、もっと少ない労働で済む可能性があります（電話もNetflixもない時代）。

エグゼクティブ機能の疲労。通常はスキルを使う合間にやってるけど、ここでは常にトップレベルの決定を下したり、可能性を考えたりしてる。実行する必要がないから、ほとんどダウンタイムがないし、難しい問題から難しい問題に移る間にほとんど時間がない。おそらく、前頭前野を普段よりもずっと活発に使ってるんだろうね。人々はAIが私たちを賢くなくさせるとか、特定の脳の領域を縮小させるって言うけど、もしこのまま続くなら（私はそうならないと思うけど、まあ…）エグゼクティブ機能がすごく強くなるだけだよ。だって、それが今やってることだから。

あなたのマネージャーはあなたが早く出荷しているのを見て、期待が調整される。あなた自身も早く出荷しているのを見て、自分の期待が調整される。基準が動くんだ。この問題は長い間続いていて、ヘレン・ケラーもほぼ100年前にこれについて書いていたよ: > 「私がここで言いたい唯一の点は、私たちが労働を節約する機械を実際に労働を節約するために使い始める時が来たということです。無計画に余剰品を国中に流し込むために使うのではなく、貿易のチャネルを詰まらせるために。」 https://www.theatlantic.com/magazine/archive/1932/08/put-you...

コードを管理する代わりに、今はAIエンティティを管理しているんですね。人を管理するのは常に感情的にも心理的にも疲れます。AIエンティティを管理するのは、さらに負担が大きいかもしれません。彼らは人間じゃないからね。

└

それとも、私たちがモデルを洗練させるために管理されているのかも。

だから、君はすべての行を読んでるんだね。自分が書いてないコードを読むのは、君のコードベースの歴史やチームの慣習を理解していないシステムが生成したものだから、すごく疲れる作業だよ。特にデータベースの面でこれを強く感じてる。普通の開発者のSQLの理解度は、残念ながらせいぜい不安定なものだし（これには驚くよ。午後に必要な95%を学べるし、残りはドキュメントを参照すればなんとかなるのに）、AIの使用がこれを10倍悪化させてる。正直、これは不合理で不公平に感じる。君がAIが生成したスキーマやクエリの確認を私に求めるってことは、暗に「問題がある可能性が高い」ことを認めてるし、「何が書かれているのか理解していないけど、レビューをお願いしている」ってことだよね。これは、ソフトウェア設計の普通の一部として君が負うべき認知的負担をアウトソーシングしてることになる。さらに厄介なのはMySQLで、LLMは一つのテーブルアクセスに対して複数のインデックスを使えると思い込んでるみたいだし（実際にはほぼ選ばないだろうけど）。こういう問題に直面した時、彼らはもっと深刻なエラーを犯すこともあって、大きな複合インデックスを提案してきたこともあった。左端のプレフィックスと右端のプレフィックスの両方に使えるって言ってたけど、それはB{-,+}treeの動きじゃないよ、マジで。AIがデータ構造とアルゴリズムについてしっかり理解してると思ってたのに。

[遅延]