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

LLMは疲れることがある

2026年3月16日原文(tomjohnell.com)

概要

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

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

  • ClaudeCodex などの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ツールを使って自分たちのプロセスを自然に改善できるようにすべきだよ。これは本当なのか、それとも誇張なのか?本当なら、もっとバランスの取れた組織を探し始めるよ。

Hacker Newsで議論の続きを見る