ハクソク

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

LLMは疲れることがある

71日前原文(tomjohnell.com)

概要

  • LLM（大規模言語モデル）との長時間作業で疲労や非効率を感じる体験の共有
  • 疲労によるプロンプト品質低下や、遅いフィードバックループの問題点を指摘
  • AI活用時のメタ認知と、最適なプロンプト作成の重要性を強調
  • フィードバックループ短縮や明確な成功基準の提示で効率化を提案
  • 疲労時や行き詰まり時の対処法と心構えについてまとめ

LLM作業で感じる疲労と非効率の原因

  • Claude や Codex などのLLMと数時間作業した後、進捗や成果に疑問を感じる体験
  • モデルの品質や設計、 コンテキストロット （文脈劣化）、 コードの肥大化 などを原因と考えがち
  • 一晩休んで翌日作業を再開すると、驚くほどスムーズに問題解決できるケースも多い

疲労とプロンプト品質の関係

  • 疲労が蓄積すると プロンプトの質が低下 し、AIの出力も悪化
  • 重要な文脈を抜かしたまま送信し、後から補足・修正を繰り返す悪循環
  • 途中での割り込みや「舵取り」 は、モデルのパフォーマンスをさらに低下させる要因

フィードバックループの遅さとコンテキスト肥大

  • 大きなファイルの解析やバグ修正など、 毎回の実験に時間がかかる課題
  • 10分以上かかる処理や、 コンテキスト枠の圧迫 によるAIの理解力低下
  • 結果として、AIが最新の実験内容を正しく把握できなくなるリスク

AI活用のための心構えと対策

  • プロンプト作成に楽しさや達成感がなくなった時が休憩のサイン
  • 問題を自分で十分に考えず、AIに丸投げする「要件の認知的外注」は危険
  • 理想の結果が明確にイメージできるプロンプト を目指すべき
  • 曖昧さや焦り、不満がある場合は、無理に進めず立ち止まる判断も重要

フィードバックループ短縮の実践例

  • フィードバックループが遅い場合、 新規セッションで問題と目標を明確化
  • 「5分以内で失敗ケースを再現して」といった 具体的な成功基準 を提示
  • AIがまず問題を再現し、 高速な実験サイクル を実現する工夫
  • TDD（テスト駆動開発） の発想に近いアプローチ
  • 明確な基準と高速なループで、 コンテキスト消費を抑えつつ効率化

結論と心構え

  • LLMとの作業で疲労や停滞を感じたら、 自分のスキルや状態を見直す重要性
  • 疲労や「プロンプト作成の楽しさ」の喪失がサイン
  • 要件の曖昧さやフィードバックループの遅さを問題として認識し、 AIと協力して高速化策を探る姿勢
  • 最適なプロンプトと効率的な実験サイクルで、 LLM活用の生産性向上

ブログ購読案内

  • メール または RSSフィード でブログ購読可能

Hackerたちの意見

LLMは手動コーディングよりもずっと疲れるよね。面白いことに、現代のLLMを使うと、一人の人間がどれだけのことを把握できるかすぐにわかる。LLMが全てのケースで人間より100%優れているわけじゃないから、私が関わっている限り、できることには結構厳しい上限があると思うし、どうやらその限界にはほぼ達しているみたい。面白いことに、最近のテクノロジー全般にそんな感覚を持つことが多い。iPhoneや現代のメッセージアプリなんかは、注意を無限に分散させるのが簡単すぎて、疲れちゃう。昔に比べてずっと疲れるよ。

└

上限は無限の可能性の中から何を作るかを決める能力だと思う。どう動かすべきか、使うとどんな感じになるか、何が一番理にかなっているか、などなど。コードを書くこと自体は些細なことで、何を作るかを決める時間に比べると無駄な時間だと思うこともある。時には、楽しいゲームを計画するための作業を避けるためにゲームエンジンを磨く（簡単なこと）ような、先延ばしになってしまうこともある。何を作るかが明確であればあるほど、大きな作業を委任したり外注したりできる。だから、LLMの圧倒的な部分は、実装作業のダウンタイムがないことだと思う。実装はもう簡単だから、舵取りや計画をするハードな部分に縛られてしまう。でも、それは良いことでもある。

└

コードレビューはコーディングとは全然違うスキルだと思う。コードを感じ取ると（自分のために書かれたコードを読んでいると仮定して）、コーダーレビューアーになる…新しいスキルを学んでいる気がする。

└

コードの品質を気にするなら、もちろん疲れるよね。それが本来のはずだし、同じ時間内に品質を確保するためのコードが増えているから。

└

以前はF1ドライバーだったんだね。今はF1の自動運転のインストラクター。速くて無茶な運転をするから、常に全力で見守らなきゃいけないよ。

└

LLMを使うのは手動でコーディングするよりもずっと疲れるって感じる。まさにその通りだよ。時間が経てば慣れて少し楽になるんじゃないかとも思う。高校と大学の頃、イタリアンレストランで働いてたんだけど、そこでデリバリードライバーとして雇われてすごく楽しかった。数年経った頃、急に人が辞めることが多くなって、オーナーにウェイターをやってみないかって頼まれた。最初の数ヶ月は、雑談や常に「オン」でいることが本当に疲れたけど、徐々にルーチンができて楽になった。デリバリードライバーの方が断然好きだったけど、最終的にはウェイターのシフトが終わった後も完全に疲れ切ることはなくなった。LLMでのコーディングも同じような感じになるんじゃないかと思う。自分でコードを書くのが好きだけど、いつかはLLMを使ってもそんなに疲れないって信じたいな。

└

制約された合理性の理論が当てはまる。テクノロジーツールはシステムの能力の限界を拡大するけど、3インチのチンパンジーの脳の限界は変わらない。物語は自ら書かれる。

コーディング中のアポリアの感覚はずっと好きだった。混乱や最終的なフラストレーションを受け入れることが仕事の一部だから、エージェントと一緒にループを回るのは気にしない。でも、生成されたPRをレビューするのは本当に嫌い。特に、提出者が自分のコードをほとんど見ていないと知っているときは余計に。企業がAIの使用を義務付けて、毎日10,000行のPRを求めているから、こういうのをレビューするのが疲れる。自分でコードを読んでないなら、あなたのコードを読む気にはならない。私のスタンスは、こういうのをレビューするのは本当に疲れるってこと。コーディング自体は実際楽しい部分だから。

└

HNの人たちがどこで働いているのか、いつも気になる。私たちは中〜大規模の企業向けにERPやレガシーシステムのトラブルシューティングをしているけど、人間が書いたPRもいつもかなりランダムで、ほとんど見られていなかった。人間が書いた（SOからコピー＆ペーストして少し変えた）にもかかわらず、何をしているのか説明できない人が多い。これは例外じゃなくて、HNの外では普通のことだと思う。よく喋る人が、何も理解せずにほとんど異星人のようなコードを書く。私たちにとってLLMは大きな進歩だ。ある会社のERPシステムでは、重要なShellで失敗を防ぐために40個のネストされたif文とループがあるけど、LLMはそんなことはしない。悪夢だけど、こういうのを運営することでかなりの利益を得ている。

└

エージェントと一緒にループを回すのが、PRをレビューするのとどう違うのかがよくわからないな。

└

AIを使ってレビューしよう。

└

今、企業がAIの使用を義務付けて、毎日1万行のPRを出すように求めてる。それは見逃せない大きな赤信号だね。企業はエンジニアリングチームがAIツールを使って自分たちのプロセスを自然に改善できるようにすべきだよ。これは本当なのか、それとも誇張なのか？本当なら、もっとバランスの取れた組織を探し始めるよ。

└

俺は「TDD」でLLMコーディングして、テストだけレビューしてる。そうすれば、テストが通ればそのまま出荷できるから。まだそれで痛い目にあったことはないよ。

└

10kって、本当に？そのコード全部理解しなきゃいけないの？マジでクレイジーだし、燃え尽き症候群への一本道だよ。

まるでストックホルム症候群か、100年前の伝統的な虐待関係みたいだね。女性が夫に何かをさせるためにどう促すかを考えている感じ。虐待的な関係からは離れられるって知ってるよね。そんなクズを捨てて、心を解放しよう。

LLMは実際には誰にとっても何も良くしない。常に修正し続けなきゃいけない。まるで、自分の下で全く学ばないジュニアコーダーを抱えているようなもの。誰かがそれを使って仕事をして生産的だと感じるなんて想像できない。

└

そんなにぶっ飛んだ意見を持ってるなら、ツールの使い方をもっと学んだ方がいいよ。

└

こういうコメントについてどう思えばいいのか悩む。新しいアカウントからのコメントが多いし、数日かせいぜい数週間しか経ってないアカウントがほとんど。これがアストロターフィングなのか、本当に新しいアカウントであなたの経験なのか、判断がつかない。40年近くコーディングしてきた自分からすると、実際にハイレベルで生産的な開発チームを運営する苦労を経験してきたけど、あなたの経験は自分とは全然違う。優れた開発者でも基本を忘れたりミスをしたりすることがあるし、すべてのジュニア（いや、シニアも）もLLMのように効果的であればいいのにと思う。LLMをプロジェクト管理やジュニア開発者のメンターのスキルを持ったベテランエンジニアに渡せば、強力な加速器になるよ。毎日その成果をチームで見てるけど、速度も質も上がってる。

└

ジュニアエンジニアが、なぜミューテックスを追加したのか理解するのに数時間かけて、一般的なパターンについてブログを読んだりすることがあるかもしれない。そういう場合、あなたが考えなかったケースで、なぜ同じスレッドで2回ロックしたのか質問してくるかも。経験や知識が足りないからって、学べないわけじゃないし、役に立てないわけでもない。学ぶことが多い人ほど、時間をかけて頑張ろうとすることがあるんだよね。

エージェントと非同期で作業するのが助けになると思う。通知をオフにして、いちいちエージェントの完了や入力が必要っていうのを気にしないようにしてる。[1] 自分のペースでいくつかの異なるタスクをこなしてるけど、これが結構うまくいってる。リズムが見つかれば、通常のプログラミングよりもずっと楽だし。タスクの切り替えが「常に」あると疲れると思うかもしれないけど、そんなに頻繁には切り替えないよ。主に一つのタスクに集中して、待ってる時間を使って関連するアイデアや次のプロンプトを考えたり、コードを軽く見直したりしてる。大きな複雑なタスクといくつかの簡単なタスクを同時に進めるのも助かるし、タスクごとに頭に入れておくべき詳細が少ないから、切り替えのコストも少ないと思う。詳細を忘れた時は、エージェントと1、2分チャットするだけで「リロード」できるしね。重要なのは、エージェントを最大効率で動かそうとしないことだと思う。自分の作業が終わるまで、エージェントをアイドルにしておいても大丈夫だよ。（KVキャッシュの効率には悪いかもしれないけど、どれくらいキャッシュを保持するのかはわからないし） （もちろん、承認が必要な数を制限するためにエージェントはサンドボックスで動かすべきだね）[1] 緊急ウィンドウのヒントを使って、どのワークスペースに入力待ちのエージェントがいるかをさりげなく確認してる。編集：注意書き - まだ使い始めたばかりで、今のところ超複雑なタスクには使ってない。

└

確かに、エージェントを忙しくさせなきゃって思ったこともあったけど、すぐにその考えは消えた。複数のことを同時に進めるのは、別のタスクに取り組むためだからね。

└

そう、私も同じようなパターンだよ。エージェントを待たせるのが大丈夫だって自分を納得させるのに時間がかかったけど、人間のコンテキストスイッチには役立つ。エージェントを交互に使うようにしてる。一つは計画やデザインをして、もう一つはコーディングをしてる。そうすれば、計画やデザインにもっと時間をかけられて、コーディングの方はそのまま進められる。

「エージェントAI」を使ってる人たちが、4つの画面で「完璧な」作業環境を整えるのに何日もかけてるのかなって思う。LLMはアイデアを作ったり、理解を深めたり、基本的なプロトタイピングにはすごく役立つ。でも、プロジェクトのライフサイクルの初期段階では有用だけど、リリースに近づくと、リファクタリングや大量のファイルやリソースの管理、ユーザーフィードバックに基づいた特定の変更が重要になってくる。数十年の経験がある私たちにとって、Vimのコマンドで30秒でバグを直せるのに、LLMはほとんどのコーディングタスクでは遅くなる可能性が高いよ。プロトタイピングや難しいバグ探しを除いてね。

└

何十年も同じコードベースに関わってきたなら、そうかもしれないけど。最近のコードベースで、5人が同じリポジトリにバンバン変更を加えてるのをやってみて。5秒ごとにコードベースが変わるから、誰も何が起こってるのか追えないっていうVIMの筋肉記憶に頑張ってね。

これらの多くが共感できる、特にメンタル疲労について。普通のコーディングは脳をスローダウンさせる感じだったけど、今は自分の思考が限界になってる。ちなみに、2025年6月にLLMだけで以前のプロジェクトを完全に再構築する実験を始めたんだ（「完全にバイブコード」 - ソースを読むことすらせずに）。何度も試行錯誤して、比較的うまくいくデザイン/プラン/デバッグループに落ち着いたけど、今は古い問題を新たに経験してる：やりすぎ！ジュニアエンジニアとして、タスクの範囲を過小評価して、締切を逃すまで余計な機能やエッジケースを積み重ねるのはよくあること。新しいプログラマーやソフトウェアエンジニアが必ず通る貴重な教訓だよ。「エージェントエンジニアリング」では、まるで最初からやり直しのような気分。コードを書くのが安くて早いから、最初から「正しい方法」でやろうとして、知ってるのに余計な機能を追加して、プロジェクトが立ち上がらない状態に膨れ上がってしまう。子供に戻った気分だよ（：

└

LLMやエージェントシステムを使っている時間よりも、ドメインを学んで自分でコーディングする時間の方が多かった。主にLLMには退屈な繰り返しのコードを書く仕事を任せてる。自分が専門じゃないことを与えると、めちゃくちゃにされるからね。

└

「最初から正しい方法」でやるってどういう意味？それが余計な機能を追加してプロジェクトが膨れ上がって、結局立ち上がらない理由なの？それが引用符付きなのは、正しい方法の反対だから？10年以上のプロのプログラミングで学んだことが一つあるとすれば、未来を予測することはできないってこと。それだけ、シンプルだよ。YANGNI。（データをモデル化することも大事だけど、ここで言いたいのはそれじゃない）私たちはコーディングが好きだからコーディングを始めた。もっとコードを書いたり、出荷したりする理由や正当化を自分で作り出す。開発者がもっとコードを出荷すれば、世界の問題は解決できるって思ってる。コードの出荷を愛し、気にかける人たちが、実際にはコードの出荷が重要じゃないってことを知っているとき、ニルヴァーナに達するんだ。

速いループが助けになってるかはわからない。むしろそれが問題かもしれない。最近は「コラボレーション」や「一時コード」のフォルダーを作って、そこにどんどん時間を費やしてる。実際に本物のコードに触れる準備ができる頃には、問題の説明やプランを何度も書き直して、いくつかのファイルやテストコードに広げてしまってることが多い。会社の他の開発者には、問題を理解して明確にするのに90%のトークンを使って、最後の10%で答えを生成してるって言ってる。そうしないと、機能変更に耐えられないプロトタイプコードができたり、意図的に隠されたバグがある「防御的」コードができたりする（try, except, ignoreはよくあるClaudeのパターン）。一番好きなのは、Claudeがユニットテストを通過して「その失敗は始める前からあったから無視できる…」って言うこと。実際に良いコードを書くためには、LLMが心配せずに最適化できる範囲に問題を収束させる必要があるけど、そのためには問題を小さく分ける作業をしなきゃいけない。そうすれば、構文を任せるのも全然OKだと思う。時にはスローダウンして、探求して考える方が良いのかもしれないね。ただ試してみて、（最終的に、なんとなく）うまくいくまで待つんじゃなくて。

LLMはすごく解放感があって、エネルギーをもらえる感じで、全然疲れないよ。やっと自分の好きなワークフローができるようになったんだ。リサーチして、（デザイン、批評）、（計画、批評、デザイン）、実装って感じ。デザインと計画はサクッと回るから、イライラしないしね。エージェントがコードを書いてる時には、もう関与しないから、設定して放置しておくだけ。30分くらい後に戻ってきて、できてるか確認する感じ。そんな間に、全体の流れを見ながら次のプロンプトサイクルを考えてる。例えば、このプロジェクトは全部LLMが書いたものだよ：https://github.com/kstenerud/yoloai 俺はこのコードの一行も書いてない（もちろんレビューはするけど、その重い作業もLLMに任せられるから、もっと広い問題に集中できる）。特に、docs/devのサブディレクトリを見て、計画やデザインを確認してみて。エージェントがそれを持っていれば、ミスをするのがずっと難しくなるんだ。完璧かって言われたら、そうじゃないけど、しっかりしたアーキテクチャがあって、ちゃんと仕事をしてるし、デバッグのインフラも整ってるから修正も早い。埋め込み系や最大パフォーマンスが必要なプロジェクトにはこのアプローチは使わないけど、普通のコードには最高だね！

2つか3つのプロジェクトを同時に切り替えるのが頭に負担かかって疲れちゃうんだ。手動で確認したりプロンプトを書いたりしたいし、全部を整理するのが大変。でも、その分すごく進んでるんだよね。