- ClaudeやCodexのようなLLMと長時間協業していると、疲労が蓄積して生産性が急激に低下する
- 疲労によるプロンプト品質の低下が結果の質を悪化させ、途中でモデルを止めたり修正したりするほど性能はさらに悪くなる
- フィードバックループが遅く、コンテキストが過度に肥大化する問題が反復実験を難しくし、作業効率を下げる
- 効果的なアプローチは、プロンプト作成の楽しさと明確な目標意識を保ち、遅いループ自体を問題として定義して改善すること
- LLM活用の核心は高速なフィードバックと明確な成功基準の設定であり、それによってデバッグ時間を減らし、より賢い結果を得られる
疲労と遅い実験速度
- 精神的疲労が蓄積するとプロンプトの品質が落ち、その結果LLMの応答品質も低下する
- 疲れた状態で重要なコンテキストを落としたままプロンプトを送信し、その後に修正や中断を繰り返すと結果は悪化する
- Claude CodeやCodexでは、このような「途中介入」が一貫性を崩し、さらに悪い結果を招く
- フィードバックループの速度低下が問題として指摘されている
- 大容量ファイルのパースなど時間のかかる作業では、毎回の再実行が遅く、実験サイクルが長くなる
- コンテキストがほぼ飽和状態に達すると、モデルが「鈍く」なったり、直近の実験内容を適切に反映できなくなったりする
AIとの効率的な協業パス
- 悪いプロンプトによる悪循環（
doom-loop psychosis） を避ける必要がある
- プロンプト作成が楽しくなかったり、短く雑な入力を繰り返していたりする場合は休息が必要だ
- 問題を十分に考えないまま、AIが抜けを埋めてくれると期待するのは危険な落とし穴だ
- 明確な目標と確信を持ったプロンプトが成功の鍵である
- 望む結果を具体的に思い描きながら書いたプロンプトは、高品質な応答につながる
- 逆に、不確実だったり焦った気持ちで書いた場合、結果は満足のいくものにならない
遅いフィードバックループを問題として定義する
- フィードバックループの速度そのものを改善目標として設定すべきである
- たとえば、パースの問題を扱う際には、ループ時間を5分以下に短縮する目標を明示し、失敗事例をすばやく再現するよう求める
- これはテスト駆動開発（TDD） に似たアプローチであり、反復実験の速度を高める
- 明確な成功基準の提示がLLMの効率を最大化する
- 「5分以内に失敗事例を再現せよ」のような具体的条件を与えると、LLMはコードパスを最適化し、不要な部分を削ぎ落とす
- このように高速なフィードバックループを確保できれば、コンテキスト消費が減り、モデルはより「賢く」動作する
結論
- LLMとの作業で生じる疲労は、しばしば**技術的な問題ではなく「熟練度の問題（skill issue）」**である可能性がある
- 認知的疲労と要件の外注化（cognitive outsourcing） は、生産性を低下させる落とし穴である
- プロンプト作成の過程が楽しく、結果に95%以上満足できる自信があるときにだけ継続するのが望ましい
- 進行の遅さとコンテキスト過負荷を感じた場合は、それ自体を解決課題とみなし、LLMとともにより高速な反復構造を設計すべきである
まだコメントはありません。