AI疲れとの格闘

こんにちは、としまつです。
ここ1年以上noteを書いていなかったことに気づき、改めて最近の仕事や思考整理をしようと思い書いている次第です。

今回はタイトルの通り、AI利用によって高まる疲労感とどう向き合っているかの言語化です。

約1年前、Claude Codeを使い初めて以降、AI による開発を中心として、仕事の開発もプライベートの開発も圧倒的に実装量が増えました。当然、他の開発者も実装量が増え、プルリクエスト（以下 PR）の数、PRの中の変更行数も膨大に膨れ上がってきました。

少し前に参加したTSKaigi 2026にて、登壇されていた方の会社の例では開発量が約3倍になったと言われていました。自社でも体感3倍はあって、AI による実装量が数倍に増えたが、レビューをするのは基本的に人間なので、純粋に人間の負荷が3倍になったと考えられます。

そして、実装量増加もさることながら、読む文章量が膨大になってきています。AI が出力する文章は、網羅的で、叙述的で、膨大な量を出してくるので、人間が読むには相当体力を消耗します。

これらの疲労は最近「AI 疲れ」と言われ、よく耳にするようになりました。

以下ではこの「AI 疲れ」に関して、そもそもAi 疲れとは何か、そして自分がどのように対処しているかを書きます。

AI疲れの正体

AI疲れはなんとなく「気のせい」とか「慣れの問題」と思われがちですが、構造的な理由があると思っています。整理すると以下の3つです。

① 意思決定コストの増大

久松剛さんが「AI疲れの正体は『常に考え続けなければならない状態』に置かれることによる疲労」と書かれています。言い換えると、意思決定コストの増大です。

上記記事の「AI 疲れ」について要約すると、

• 以前の仕事は、与えられた業務をいかに正確に効率よくこなすかで、ある程度の正解があり、その範囲内で動けばよかった。

• しかしAIの登場によって「そもそもこの業務は必要か」「もっと別のやり方があるのではないか」という問いが常に浮かぶようになった。「最適化」から「再設計」へ転換した。

• 「どこまでやればいいか」の境界が曖昧になり、「なんでもやれるけど、なんでもやらないといけない」という状態になっており、疲弊する状態となっている。

今やっている優先プロジェクトの他で、AI に情報を与えれば調査から実装まで低コストで取り組んでくれます。AI がセキュリティ上の懸念点やリファクタリング案などを持ってきて、もっともらしいことを言うので「じゃあやっておくか」と言う気持ちになります。この「なんでもできる」が浸透し、あれもこれもやらないといけない雰囲気が生まれます。レビュワーからすると、投資対効果に見合うかどうかの検討もした方がいいとは思いつつ、もっともらしい修正なので無下にはできない。

そんな疲労が生まれやすい時代になっているかなと思います。

② 「読む」量の爆発的増加

tacoyakyさんの記事『生成AIが増やしたのは効率だけじゃない。「読む」という見えない疲れ』が刺さりました。

僕の1日の業務を棚卸しすると、要件定義書や技術設計書、QAの設計書、Slackのテキスト、PRの説明、コードレビューのコメントなど、文章を「読む」「書く」「考える」という言語処理系の作業がほぼすべてを占めています。

さらに言うと「考える」より「読む」が激増しています。以前は「考える ＞ 読む」だったのが逆転しています。

以前より脳が疲れている理由を把握するために言語化してみて思ったのが、「AIが生成した文章は自分の頭を通っていない」という点です。自分が指示を出した内容でも、出力された完成品は全く別物として目に入ってきています。自分の指示すらそうなのに、他人がAI を用いて書いたドキュメントを読むのはとても疲弊します。

認知負荷が高まりすぎてオーバーヒートする。途中から読んでいても頭に入ってこず、理解に時間がかかる状態。能力の問題を超え、情報処理の絶対量が人間の限界を超えてきているという構造の問題だと思っています。同じ会社のエンジニアも同じ感覚とのことで、「もはや（全ては）読んでない」とすら言っていました。

③ 「追いつかないといけない」強迫観念

みずくん（水谷享平）さんが「AIを使うこと自体が目標になると、全部キャッチアップしなければ、全部試さなければという強迫観念に駆られる」と書かれています。

これも非常にわかる感覚です。新しいツールのリリース情報が毎日流れてくる。試してみないと乗り遅れる気がする。Claude Codeの次はGemini、その次は...と、追いかける対象に果てがない。

「AIを使っていない時間がもったいない」と感じてしまうのも同じ構造です。「今こうやって休んでいる間にも誰かがAIを動かして生産をしている」と感じてしまいやすいです。

AIをうまく使いこなせていない自分は遅れている、という感覚はAI 疲れの一種だと思います。


では、この新たな疲弊の中、どう向き合うと良いのかを考えてみました。

AI 疲れとどう向き合うか

① 土台となる基礎知識・設計力の向上

これはAI 疲れの予防策として、長期的に取り組むべき解決策だと考えています。

設計の意図・制約を自分が理解していないと、AI が出した案の良し悪しを判断できない。判断できないから何度も聞き直す、読む量が増え疲れを生む、という悪循環になります。

「設計を考えるときは最初からAIに聞く」という癖がついてしまうと、自分の設計力が育たない。そのうちAI なしでは設計できなくなり、AI の出力の正しさも検証できなくなっていきます。

「なぜこの仕様なのか？」を問い続けることが設計力のトレーニングになると思っています。なぜ？を放置してAIに一気に出力させることもできますが、土台の基礎知識を高めるためには日々利用する際の意識と、体系的な勉強は続けていく必要があると思う次第です。

② 適切なマルチタスク管理

AI を使っていると、並列でタスクが膨らみやすいです。技術設計のスレッドで話しながら、別箇所で実装レビューの質問をして、また別箇所で実装タスクを回す...気づくとAIセッションが無数に増えていきます。

人間の脳みそは1つなので、マルチタスクといっても実態は1つ1つ取り組みをして高速にスイッチングしている状態です。なので本来は複数同時並列は避け、多くても3つまでとして、1つずつ終わらせるのが良いかとは思います。

少し前までは上記のように、直列にタスクを一つずつこなす意識が大事だと思っていましたが、最近はそれだと仕事がスタックしがちになってきたので、頑張ってより複数の並列をやり始めました。

しごできのエンジニアマネージャーとの1on1にて、その方は複数のclaude セッションを立ち上げ、それぞれで別の作業を回し、その並列数10 個くらいあると言ってました。3 個が人間の脳のメモリ（すぐ取り出せるRAM 的なポジションの数）限界だからそれ以上は増やさないでおこうと思っていた自分には衝撃の話でした。

「できる」と思えばできるベースで現実を再構築していくのが人間なので、どう多くを並行できるか考え、独自の業務ボードを構築し仕事の進め方を変えている最近です（これは次のnote で書こうと思います）。

複数並列数をどれくらい持つかは置いておくとしても、最低限守っているルールがあります。AIとの会話セッションをできる限り「1セッション＝1テーマ」としています。技術設計の話をしているセッションでQAの質問をし始めると、AIのコンテキストも自分のコンテキストも両方乱れて大変です。後からスイッチングして戻ってきたときに「このセッションは何をしていたっけ」という無駄なやりとりも生まれるので、「1セッション1テーマ」を守るのはおすすめです。

③ 認知資源の節約と回復

認知資源は有限です。1日に読める量・判断できる量には絶対的な上限があると思っています。

AIがそのキャパを超える量のアウトプットを出し続けるようになった今、認知資源をどう使うかを設計することが以前より重要になっています。ここは簡素に箇条書きで締めます。

節約について

• AI にまず背景や概要を聞き、その後詳細を深ぼっていくこと

• ドキュメントの全文精読をやめ、先にポイントを絞って読む

• 焦ってあれもこれも並行で走らせない。ハンドリングできる量に抑える。

回復について

• やはり睡眠が一番。ちゃんと寝ましょう。

• AI を使わない時間を意図的に設ける。人と話す、書籍を読むなど。

• 身体を動かす。軽く外を歩くなどすると脳疲労が回復する。

さいごに

散々、文章量が多くて疲れると言いながら、文章長くなり負担かけてすみません！

AI 疲れは「能力の問題」よりも「構造の問題」が大きいです。意思決定コストの増大・「読む」量の爆発・追いつかなければという強迫観念の3つが重なって起きています。

対処するには、土台（基礎力・設計力）を育てること、マルチタスクについて自分に適した管理方法を作ること、そして認知資源を節約と回復で意識的にコントロールすること。この3つが今のところ僕の答えです。

以上、長文読んでいただきありがとうございました。
次回は最近作ったタスク管理ボードについて書こうと思います。