長いClaude実行におけるコンテキスト制限の管理：ACツリーパターン

r/ClaudeAIの開発者が、長時間実行されるClaudeセッションで繰り返し発生する失敗パターンについて説明しています。これらの失敗は明らかなエラーではなく、モデルの出力が当初の意図から徐々にずれていくという漸進的なドリフトです。

問題点：自動圧縮とコンテキスト制限

情報源によると、最初の問題は自動圧縮にあります。生産的な作業が始まる前に、利用可能なコンテキストの重要な部分を消費し、その圧縮は中立ではありません。モデルが保存する情報を決定するため、情報損失が発生します。初頭効果と新近効果がこれを悪化させます：実行の中盤が最初に弱まり、初期の制約が薄れ、断片的な意図に対して決定が下されます。

自動圧縮をオフにすると、第二の問題が明らかになります：厳格なコンテキスト制限です。セッションがいっぱいになると、実質的に終了し、クリーンな継続や回復の道筋がありません。

解決策：ACツリー実行パターン

開発者は、設定を調整するだけでなく、実行の形状を変更することで成功を見出しました。このアプローチでは、入力を完成した仕様ではなく、人間の目標として扱います。システムはユーザーにインタビューして意図を明確にし、制約を抽出し、隠れた前提を表面化させ、これをACツリー（個別の検証可能な作業単位の依存関係グラフ）にコンパイルします。

ACツリーの各ノードは独自のセッションを持ち、ノード間は前方に渡される最小限の永続状態を通じてのみ互いを知ります。これにより、全体のワークフローは長時間実行されながらも、各生成は短く、境界が明確で、独立したものになります。ドリフトは実行全体を汚染するのではなく、ノードレベルで封じ込められます。

開発者はこのパターンをOuroborosというプロジェクトで実装し、github.com/Q00/ouroborosで公開しています。